Hi all ,
I have detected in my iptables that someone(s) are sending spoofed DNS request to various targets ( I assume DNS servers ),
from this I have also counted that this accounts for approximately 25% of all log entries so it would helpful to just DROP
these prior to the log rule for OUT-OF-STATE / INVALID packets sent to my FIREWALL .
FireWall:~/FireWall # fwlog | grep ^Jan | grep INVALID | grep PROTO=ICMP | grep SPT=24116 | wc
1270 37026 344056
FireWall:~/FireWall # fwlog | grep ^Jan | grep INVALID | grep PROTO=ICMP | wc
1331 38903 361959
FireWall:~/FireWall # fwlog | grep ^Jan | grep INVALID | wc
1882 49010 454195
FireWall:~/FireWall # fwlog | grep ^Jan | wc
5248 114384 1081222
Based on the log entries I have tracked down some very specific details that "identifies" the packets in the ICMP RELATED data payload :
SRC= always my IP ( obviously )
PROTO= always UDP ( normal for DNS traffic )
DPT= always 53 ( normal for DNS traffic )
SPT= always port 24116 ( The trigger that makes this filter viable )
Jan 13 11:03:08 FW-GET-INVALID IN=vlan0 OUT= SRC=177.10.109.210 DST=Aa.Bb.Cc.Dd LEN=56 TOS=0x00 PREC=0x00 TTL=242 ID=0 PROTO=ICMP TYPE=11 CODE=0
[SRC=Aa.Bb.Cc.Dd DST=177.10.97.81 LEN=69 TOS=0x00 PREC=0x00 TTL=1 ID=36278 DF PROTO=UDP SPT=24116 DPT=53 LEN=49 ]
Jan 11 07:50:05 FW-GET-INVALID IN=vlan0 OUT= SRC=177.10.109.209 DST=Aa.Bb.Cc.Dd LEN=101 TOS=0x00 PREC=0x00 TTL=51 ID=7445 PROTO=ICMP TYPE=3 CODE=0
[SRC=Aa.Bb.Cc.Dd DST=177.10.100.1 LEN=73 TOS=0x00 PREC=0x00 TTL=239 ID=36278 DF PROTO=UDP SPT=24116 DPT=53 LEN=53 ]
Jan 13 10:40:11 FW-GET-INVALID IN=vlan0 OUT= SRC=189.5.192.3 DST=Aa.Bb.Cc.Dd LEN=56 TOS=0x00 PREC=0x00 TTL=53 ID=16683 PROTO=ICMP TYPE=3 CODE=1
[SRC=Aa.Bb.Cc.Dd DST=189.123.123.253 LEN=82 TOS=0x00 PREC=0x00 TTL=243 ID=36278 DF PROTO=UDP SPT=24116 DPT=53 LEN=62 ]
Jan 13 10:41:27 FW-GET-INVALID IN=vlan0 OUT= SRC=115.224.146.173 DST=Aa.Bb.Cc.Dd LEN=56 TOS=0x00 PREC=0x00 TTL=52 ID=58805 DF PROTO=ICMP TYPE=3 CODE=3
[SRC=Aa.Bb.Cc.Dd DST=115.224.146.173 LEN=71 TOS=0x00 PREC=0x00 TTL=229 ID=36278 DF PROTO=UDP SPT=24116 DPT=53 LEN=51 ]
Jan 08 14:00:38 FW-GET-INVALID IN=vlan0 OUT= SRC=93.182.24.46 DST=Aa.Bb.Cc.Dd LEN=93 TOS=0x00 PREC=0x00 TTL=53 ID=49810 PROTO=ICMP TYPE=3 CODE=9
[SRC=Aa.Bb.Cc.Dd DST=93.182.24.46 LEN=65 TOS=0x00 PREC=0x00 TTL=240 ID=36278 DF PROTO=UDP SPT=24116 DPT=53 LEN=45 ]
Jan 13 10:06:02 FW-GET-INVALID IN=vlan0 OUT= SRC=210.135.86.225 DST=Aa.Bb.Cc.Dd LEN=106 TOS=0x00 PREC=0x00 TTL=53 ID=16769 PROTO=ICMP TYPE=3 CODE=10
[SRC=Aa.Bb.Cc.Dd DST=210.135.86.225 LEN=78 TOS=0x00 PREC=0x00 TTL=241 ID=36278 DF PROTO=UDP SPT=24116 DPT=53 LEN=58 ]
Jan 13 07:02:14 FW-GET-INVALID IN=vlan0 OUT= SRC=93.181.16.83 DST=Aa.Bb.Cc.Dd LEN=56 TOS=0x00 PREC=0x00 TTL=54 ID=36278 PROTO=ICMP TYPE=3 CODE=13
[SRC=Aa.Bb.Cc.Dd DST=93.181.16.83 LEN=71 TOS=0x00 PREC=0x00 TTL=245 ID=36278 DF PROTO=UDP SPT=24116 DPT=53 LEN=51 ]
Since this system runs named ( a linux based DNS resolver ) , filtering ICMP for all DNS could impact valid packets also ...
... but my conclusion is that making any filter after the RELATED rules and also limiting it to the very specific combo
of only those with source port SPT=24116 ( and UDP 53 ) should virtually make it impossible to go wrong ( at least in theory ).
FireWall:~/FireWall # iptables -m string -help
iptables v1.4.21
[cut]
string match options:
--from Offset to start searching from
--to Offset to stop searching
--algo Algorithm
--icase Ignore case (default: 0)
[!] --string string Match a string in a packet
[!] --hex-string string Match a hex string in a packet
Now the problem is to create a rule that would perform this task , but looking at the module for string match
and searching google has left me a bit unsure if I am going in the right direction ...
... if anyone has any experience with similar filtering on the DATA part of packets it would be appreciated .
Since the IPTABLES normally can find this data in its RELATED function in the STATE-MODULE ,
I am hoping that there might be a more relevant way to look at this data since it obviously can be
analyzed internally in that module ( maybe there is also a way for the ruleset to use that same dataset ).
Best regards
André Paulsberg-Csibi
Senior Network Engineer
Fault Handling
IBM Services AS
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
