PREROUTING & --state match etc.
Tue, 24 Jul 2001 19:36:24 -0400
OK. If you want to fully block an IP, ditch the -m state, since
you actually match _all_ states, AFAIK. OTOH, if you want to log INVALID
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
HOWEVER it is really not a good idea, AFAIK. A better place is the
after it's patched with mangle5hooks. As for blocking this stuff, you
it in PREROUTING/POSTROUTING, since it will protect the local machine
forwarded traffic. As for catching outgoing connects to those IPs, you
them, but it wouldn't do much good, since the return path from those IPs
rules in PREROUTING and you get `Connection refused'.
> Thanks for the quick response. Basically, what I was attempting to do
> was to block certain ip's from making any type of connection
> 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.
>> -----Original Message-----
>> From: email@example.com
>> [mailto:firstname.lastname@example.org]On Behalf Of Brad Chapman
>> Sent: Tuesday, July 24, 2001 12:44 PM
>> To: Frost
>> Cc: email@example.com
>> 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.
>> 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 22.214.171.124 --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 Frost En.gen (a Division of J. River, Inc.)
>>> <mailto:firstname.lastname@example.org>mailto:email@example.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