Possible reasons for INVALID packets ?

Possible reasons for INVALID packets ?

[Mikhail Zotov]

Hello everybody,

My iptables script drops (and logs) INVALID packets in
INPUT, OUTPUT, and FORWARD chains.  
Sometimes a router that is running the script generates ICMP
packets of type 11 that it considers INVALID.   (In other words, it
generates packets that by itself considers to be INVALID.)  The
problem is that I cannot figure out what makes the router generate
invalid packets.

Typical records of this kind look this way:

IN= OUT=eth0 SRC=ROUTER DST=193.108.155.115 LEN=68 TOS=0x00 PREC=0xC0 TTL=64 
ID=22467 PROTO=ICMP TYPE=11 CODE=0 [SRC=193.108.155.115 DST=A.LAN.HOST LEN=40 
TOS=0x00 PREC=0x00 TTL=1 ID=40760 PROTO=ICMP TYPE=8 CODE=0 ID=20244 
SEQ=45126 ] 

or:

IN= OUT=eth0 SRC=ROUTER DST=66.150.8.26 LEN=60 TOS=0x00 PREC=0xC0 TTL=64 
ID=30495 PROTO=ICMP TYPE=11 CODE=0 [SRC=66.150.8.26 DST=A.LAN.HOST LEN=32 
TOS=0x00 PREC=0x20 TTL=1 ID=1294 PROTO=UDP SPT=12895 DPT=33440 LEN=12 ] 

It seems that they appear in situations when an exterior host either pings or
"traceroutes" a host in the LAN.  Both pings and "traceroutes" are normally
logged and dropped.  In these cases, none of these types of packets were
registered _before_ invalid packets but a few seconds _later_.  No connection
breakdowns were logged either.  My question is: what can make a router
generate INVALID packets and how dangerous can this be in the sense of
security of the router and the LAN?


Thanks in advance,
Mikhail

Re: Possible reasons for INVALID packets ?

[Michael Tautschnig]

> Hello everybody,
> 
[...]

You said that already, didn't you? See my answer at

https://lists.netfilter.org/pipermail/netfilter/2005-February/058982.html



Regards,
Michael

Re: Possible reasons for INVALID packets ?

[Mikhail Zotov]

On Wednesday 02 March 2005 12:26, Michael Tautschnig wrote:
> > Hello everybody,
>
> [...]
>
> You said that already, didn't you? See my answer at
>
> https://lists.netfilter.org/pipermail/netfilter/2005-February/058982.html

Thank you for the replies!  There was a pause in receiving messages
from the mailing list around Feb 28 and I didn't see any reply to my question.

>
>> IN= OUT=eth0 SRC=ROUTER DST=193.108.155.115 LEN=68 TOS=0x00 PREC=0xC0
>> TTL=64  ID=22467 PROTO=ICMP TYPE=11 CODE=0 [SRC=193.108.155.115
>> DST=A.LAN.HOST LEN=40 TOS=0x00 PREC=0x00 TTL=1 ID=40760 PROTO=ICMP TYPE=8
>> CODE=0 ID=20244 SEQ=45126 ]
>>
[...]
>
> Why would you consider these packets invalid - TYPE=11 is "time exceeded", 
> CODE=0 is "maximum lifetime of the datagram exceeded" - for whatever 
> reason those packets are generated ...

I have (roughly) the following rules in the script:

iptables -A OUTPUT -m state --state INVALID -j LOG \
--log-prefix "Fired invalid:"
iptables -A OUTPUT -m state --state INVALID -j DROP

These rules worked at the records I posted.


Regards,
Mikhail

Re: Possible reasons for INVALID packets ?

[Michael Tautschnig]

[...]
>
>>
>>> IN= OUT=eth0 SRC=ROUTER DST=193.108.155.115 LEN=68 TOS=0x00 PREC=0xC0
>>> TTL=64  ID=22467 PROTO=ICMP TYPE=11 CODE=0 [SRC=193.108.155.115
>>> DST=A.LAN.HOST LEN=40 TOS=0x00 PREC=0x00 TTL=1 ID=40760 PROTO=ICMP TYPE=8
>>> CODE=0 ID=20244 SEQ=45126 ]
>>>
> [...]
>>
>> Why would you consider these packets invalid - TYPE=11 is "time exceeded",
>> CODE=0 is "maximum lifetime of the datagram exceeded" - for whatever
>> reason those packets are generated ...
>
> I have (roughly) the following rules in the script:
>
> iptables -A OUTPUT -m state --state INVALID -j LOG \
> --log-prefix "Fired invalid:"
> iptables -A OUTPUT -m state --state INVALID -j DROP
>
> These rules worked at the records I posted.

Well, IMHO these rules will work for tcp/udp connections - but as of icmp, 
the following occurs:

ICMP-echo request 193.108.155.115 -> A.LAN.HOST , which is unreachable, 
thus "time exceeded".

Now take a look at "man iptables", what it says about "INVALID":

"... Possible states are INVALID meaning that the packet could not be 
identified for some reason which includes running out of memory and ICMP 
errors which don't correspond to any known connection, ... "

and indeed, this is the case - your ICMP error does not correspond to any 
known connection, as an ICMP-echo request is always "NEW" .

You should probably allow any outgoing ICMP-traffic to resolv this issue.

Regards,
Michael