Filtering content inside packets , specifically RELATED data in the various ICMP TYPE 3 packets

Filtering content inside packets , specifically RELATED data in the various ICMP TYPE 3 packets

[André Paulsberg-Csibi (IBM Consultant)]

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

Re: Filtering content inside packets , specifically RELATED data in the various ICMP TYPE 3 packets

[Pascal Hambourg]

Le 13/01/2017 à 11:52, André Paulsberg-Csibi (IBM Consultant) a écrit :
>
> 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 .
(...)
> 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 ).
(...)
> 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 ...

The u32 match may be more precise as it allows to match a pattern at a 
specific offset.

> Since the IPTABLES normally can find this data in its RELATED function in the STATE-MODULE ,

Conntrack is independent of iptables.
Conntrack sets the state, and iptables just checks it.

But I'd like to ask why do you bother to log such packets ?

RE: Filtering content inside packets , specifically RELATED data in the various ICMP TYPE 3 packets

[André Paulsberg-Csibi (IBM Consultant)]

APC >> Now the problem is to create a rule that would perform this task , but looking at the module for string match
APC >> and searching google has left me a bit unsure if I am going in the right direction ...

PH  > The u32 match may be more precise as it allows to match a pattern at a specific offset.

Thank you , I will search "iptables u32 match" on google :-)


APC >> Since the IPTABLES normally can find this data in its RELATED function in the STATE-MODULE ,

PH  > Conntrack is independent of iptables.
PH  > Conntrack sets the state, and iptables just checks it.

I was hoping it was not so , but this explains why I have not found options for this so far .


PH  > But I'd like to ask why do you bother to log such packets ?

I am not sure I 100% understand what exactly you are asking , since I want to remove these from my logs ...
... I will assume you are asking generally why I log INVALID / OUT-OF-STATE packets .

The reason is simple , if there is some kind of TIME-OUT issue , you will in most cases find it almost immediately with a fast look in the LOG .
and you will not have to create some massive tcpdump / pcap files to investigate why something is not working or being broken .

Logging level is also adjusted for this for most systems that have to be PCI-DSS compliant ,
or at least the general "understanding" or conception is that such is needed .
This typically means that all systems follow the same standard , even when it does not have to be PCI-DSS compliant at the moment or ever .


Best regards
André Paulsberg-Csibi
Senior Network Engineer 
Fault Handling
IBM Services AS