On Apr 4, 2013, at 18:58, Pascal Hambourg <[email protected]> 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 [email protected] > with a subject of "unsubscribe". Trouble? Contact [email protected] > Archive: http://lists.debian.org/[email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
