Re: iptables and INVALID packet filtering.

On Apr 4, 2013, at 18:58, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

> Hello,
>
> Daniel Curtis a écrit :
>>
>> I would only ask about iptables (1.4.14-3.1) rule, which is responsible for
>> filtering INVALID packets. If I decide to use this rule;
>>
>>>> iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
>
> Be aware that INVALID packets here means "packets in the INVALID state
> with respect to connection tracking". It has nothing to do with, e.g.,
> malformed packets.

If the tcp flags are illegitimate, it will catch it such as an Xmas scan

>
>> That's an example. By using this rule, iptables will also check tcp and udp
>> protocols or should I use something like;
>
> This rule applies to all protocols. That does not mean that connection
> tracking can handle correctly all protocols. AFAIK, UDP packets cannot
> be in the INVALID state (as there is no real stateful connection in UDP).

So that is not exactly correct. One example is ICMP messages in response to UDP (or other) packets.

>
>> But recently I came across on pretty strange rule also for
>> antispoof. This rule, concerns 'nat' table and PREROUTING chain;
>>
>>>> iptables -t nat -I PREROUTING 1 -i xx -s 192.168.0.0/16 -j DROP
>>
>> So, what do you think? Using PREROUTING chain is good for
>> antispoof or it is better to use rule mentioned above (INPUT chain)?
>
> My opinion is that the chains of the nat table are not intended for, and
> should not be used for filtering. They see only the first packet of a
> new connection, i.e. in the NEW state, but not the other packets. If you
> want to drop packets in a PREROUTING chain, use the mangle table instead.
>

This is not exactly true either. For instance, the FORWARD chain. In fact, I believe that is why the FORWARD chain exists.

>
> --
> To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/515E059E.4080508@plouf.fr.eu.org


--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/B57F1D41-A448-439A-A912-EF921511C1CD@AandRSecurity.com