Mailing List Archive

PREROUTING & --state match etc.
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 2727 W. Baseline Rd #13
http://www.engen.com Tempe, AZ 85283
ftp://ftp.engen.com Tel: 602-438-1110
Re: PREROUTING & --state match etc. [ In reply to ]
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
>
RE: PREROUTING & --state match etc. [ In reply to ]
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
> >
>
>
Re: PREROUTING & --state match etc. [ In reply to ]
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
>>>
RE: PREROUTING & --state match etc. [ In reply to ]
Brad, you're so very right. The rulesets work in the mangle table but NOT in
the nat table. Not sure why but I've experimented with it and mangle is able to
log as well before dropping the packet. Thanks a million!!

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 4:36 PM
> To: Frost
> Cc: netfilter@lists.samba.org
> Subject: Re: PREROUTING & --state match etc.
>
>
> 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
> >>>
>