PREROUTING & --state match etc.

[Brad Chapman]

Mr. Frost,

   OK. If you want to fully block an IP, ditch the -m state, since 
without it
you actually match _all_ states, AFAIK. OTOH, if you want to log INVALID 
traffic
or something, you may have to hang on to it.
   If you only _want_ to block state NEW connections and are sure that 
no one is
spoofing you before you load your firewall, then you can do this in the 
nat table,
HOWEVER it is really not a good idea, AFAIK. A better place is the 
mangle table,
after it's patched with mangle5hooks. As for blocking this stuff, you 
should do
it in PREROUTING/POSTROUTING, since it will protect the local machine 
and all
forwarded traffic. As for catching outgoing connects to those IPs, you 
can block
them, but it wouldn't do much good, since the return path from those IPs 
hit your
rules in PREROUTING and you get `Connection refused'.

Brad

Frost wrote:

> Brad,
> Thanks for the quick response.  Basically, what I was attempting to do
> was to block certain ip's from making any type of connection
> (NEW,RELATED,ESTABLISHED).
> I figured I could catch incoming NEW connections in the PREROUTING chain, and
> catch outgoing NEW connections to these banned ip's in POSTROUTING.  Maybe
> I should be doing all of this in INPUT, OUTPUT, and FORWARD chains instead.
> Perhaps it's only the difference of writing three rules versus two?  Any
> additional thoughts would be greatly appreciated.
> 
> Thanks,
> Harv
> 
>> -----Original Message-----
>> From: netfilter-admin@lists.samba.org
>> [mailto:netfilter-admin@lists.samba.org]On Behalf Of Brad Chapman
>> Sent: Tuesday, July 24, 2001 12:44 PM
>> To: Frost
>> Cc: netfilter@lists.samba.org
>> Subject: Re: PREROUTING & --state match etc.
>> 
>> 
>> Mr. Frost,
>> 
>>    Not really. Anything having to do with state NEW, AFAIK that will
>> work. But AFAIK
>> you can't match all packet states anywhere in the nat table, because
>> it's special and contains
>> code that allows state ESTABLISHED,RELATED to bypass the chains. For
>> example, your rule to drop
>> incoming packets with a source of 10.0.0.0/8 would work, but it would
>> only drop NEW packets. If someone
>> had already spoofed using this address _before_ you loaded your
>> firewall, _AFAIK_ this would not stop
>> that connection (big AFAIK). You should really do this in the mangle
>> table, because (for now) its hooks
>> are called before the nat table's hooks are called. BTW if you want to
>> do this at POSTROUTING or INPUT
>> in the mangle table, or even at FORWARD, head for the netfilter-devel
>> archives and grab my mangle5hooks
>> patch, which adds more hooks to mangle and makes it use all five.
>> 
>> Brad
>> 
>> Frost wrote:
>> 
>>> Hi all,
>>> 
>>> I'm curious as to the amount of things that can be performed within
>>> the PREROUTING chain.  Though this is in the nat table, which (if any)
>>> of the following arguments to the iptables command would be invalid.
>>> My external interface is eth0.
>>> 
>>> 
>>> 
>>> 1) iptables -t nat -A PREROUTING -i eth0 -s 10.0.0.0/8 -j DROP  #
>>> invalid ip's
>>> 
>>> 
>>> 
>>> 2) iptables -t nat -A PREROUTING -i eth0 -p tcp --syn \  # SYN matching
>>> 
>>>     -d $MY_IP --dport 23 -j DROP
>>> 
>>> 
>>> 
>>> 3) iptables -t nat -A PREROUTING -i eth0 -p tcp --syn -m state --state
>>> NEW \ # state
>>> 
>>>     -d 204.75.165.10 --dport 80 -j ACCEPT
>>> 
>>> 
>>> 
>>> I guess my basic question is whether or not I can perform most of the
>>> packet matching rules that we would normally use in the filter table
>>> within the nat table.
>>> 
>>> 
>>> 
>>> And lastly, at what points within the nat chain would these checks be
>>> made.  My assumption is that the checks would take place after
>>> conntrack, mangle, and dnat.  If I'm in error on this, I would
>>> appreciate someone to help clarify.
>>> 
>>> 
>>> 
>>> Thanks a million!
>>> 
>>> Harv
>>> 
>>> ____________________________________________________________________
>>> Harv Frost                     En.gen (a Division of J. River, Inc.)
>>> <mailto:frost@engen.com>
>>> <mailto:frost@engen.com>mailto:frost@engen.com         2727 W.
>>> Baseline Rd #13
>>> <http://www.engen.com/> <http://www.engen.com/>http://www.engen.com
>>> <http://www.engen.com/>           Tempe, AZ 85283
>>> <ftp://ftp.engen.com/> <ftp://ftp.engen.com/>ftp://ftp.engen.com
>>> <ftp://ftp.engen.com/>            Tel: 602-438-1110
>>>