STATELESS

STATELESS

[Matthew Mileham]

Hi 

Does any know how to change Iptables from statefull to stateless ?

Thanks

Re: STATELESS

[Ray Leach]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

On Tue, 2003-09-16 at 13:36, Matthew Mileham wrote:
> Hi 
> 
> Does any know how to change Iptables from statefull to stateless ?
> 
Leave out the -m state parameters ?

> Thanks
> 
-- 
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
--

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: STATELESS

[Gavin Hamill]

On Tuesday 16 September 2003 12:36, Matthew Mileham wrote:

> Does any know how to change Iptables from statefull to stateless ?

Don't load the ip_conntrack module, and / or don't use any iptables rules that 
use "-m state"  in the arguments :)

Cheers,
Gavin.

Re: STATELESS

[Cedric Blancher]

Le mar 16/09/2003 à 13:49, Ray Leach a écrit :
> On Tue, 2003-09-16 at 13:36, Matthew Mileham wrote:
> > Does any know how to change Iptables from statefull to stateless ?
> Leave out the -m state parameters ?

And unload ip_conntrack module to save load, for once module is loaded,
connection tracking is still working, even if state match is not used.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: STATELESS

[Ray Leach]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

On Tue, 2003-09-16 at 13:56, Gavin Hamill wrote:
> On Tuesday 16 September 2003 12:36, Matthew Mileham wrote:
> 
> > Does any know how to change Iptables from statefull to stateless ?
> 
> Don't load the ip_conntrack module, and / or don't use any iptables rules that 
> use "-m state"  in the arguments :)
Yeah, connection tracking automagically implies state inspection.

> 
> Cheers,
> Gavin.
-- 
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
--

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: STATELESS

[Ramin Dousti]

On Tue, Sep 16, 2003 at 02:46:27PM +0200, Ray Leach wrote:

> > 
> > Don't load the ip_conntrack module, and / or don't use any iptables rules that 
> > use "-m state"  in the arguments :)
> Yeah, connection tracking automagically implies state inspection.

OK. Thanks for the informative comments but can you lay out the steps to
prevent stateful inspection? For example, how to unload "ip_conntrack" and
to prevent it from being reloaded again?

Thanks again.

Ramin

Re: STATELESS

[Ray Leach]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

On Tue, 2003-09-16 at 15:11, Ramin Dousti wrote:
> On Tue, Sep 16, 2003 at 02:46:27PM +0200, Ray Leach wrote:
> 
> > > 
> > > Don't load the ip_conntrack module, and / or don't use any iptables rules that 
> > > use "-m state"  in the arguments :)
> > Yeah, connection tracking automagically implies state inspection.
> 
> OK. Thanks for the informative comments but can you lay out the steps to
> prevent stateful inspection? For example, how to unload "ip_conntrack" and
> to prevent it from being reloaded again?
> 
Personally, I would re-compile the kernel without connection tracking
support.

> Thanks again.
> 
> Ramin
-- 
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
--

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: STATELESS

[Ramin Dousti]

On Tue, Sep 16, 2003 at 03:54:08PM +0200, Ray Leach wrote:

> > > Yeah, connection tracking automagically implies state inspection.
> > 
> > OK. Thanks for the informative comments but can you lay out the steps to
> > prevent stateful inspection? For example, how to unload "ip_conntrack" and
> > to prevent it from being reloaded again?
> > 
> Personally, I would re-compile the kernel without connection tracking
> support.

OK. If you recompile without conntrack, can you do NAT? I'm just wondering?

Thanks again.

Ramin

Re: STATELESS

[Gaël Le Mignot]

 >> > > Yeah, connection tracking automagically implies state inspection.
 >> > 
 >> > OK. Thanks for the informative comments but can you lay out the
 >> > steps to prevent stateful inspection? For example, how to unload
 >> > "ip_conntrack" and to prevent it from being reloaded again?
 >> > 
 >> Personally, I would re-compile the kernel without connection tracking
 >> support.

 > OK. If you recompile without conntrack, can you do NAT? I'm just wondering?

no, Netfilter's NAT relies upon the conntrack.

Can I ask you why do you want  to turn off the conntrack ? If it's for
speed or memory  reasons, then using NAT will  have a similar overhead
(maybe  not exactly  the same,  but similar)  anyway. When  you  NAT a
connection, you're  forced to  keep track of  the connection a  way or
another, to NAT further packets of the connection the same way.

-- 
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM         : 06.71.47.18.22 (in France)   ICQ UIN   : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA

Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org

Re: STATELESS

[Ramin Dousti]

>  > OK. If you recompile without conntrack, can you do NAT? I'm just wondering?
> 
> no, Netfilter's NAT relies upon the conntrack.
> 
> Can I ask you why do you want  to turn off the conntrack?

I don't. I just wanted to learn from the people who were saying "just don't
load the ip_conntrack..."

Ramin

> If it's for
> speed or memory  reasons, then using NAT will  have a similar overhead
> (maybe  not exactly  the same,  but similar)  anyway. When  you  NAT a
> connection, you're  forced to  keep track of  the connection a  way or
> another, to NAT further packets of the connection the same way.

Re: STATELESS

[Cedric Blancher]

Le mar 16/09/2003 à 17:50, Ramin Dousti a écrit :
> > Can I ask you why do you want  to turn off the conntrack?
> I don't. I just wanted to learn from the people who were saying "just don't
> load the ip_conntrack..."

I assume that if someone wants to fallback on stateless filtering is for
saving load on his box. I can miss something, but I really don't see
another reason. Once ip_conntrack is loaded, all packets are tracked
anyway, weither you use state match or not. Yes, one can write a whole
stateless ruleset with conntrack running, but what's the point : the
cost implied by a rule with state matching and one without is the same,
as state flaging is done anyway !

That's why assuming that stateless is for save load implies ip_conntrack
module removal. But, as it relies on conntrack, NAT is broken. It is as
simple as this.

So, the remaining question is "why does OP wants to fallback to
stateless filtering". If answer is "to save load", then he will have to
remove ip_conntrack. If answer is... Well, I don't know, anything else,
such as "I like writing weak ruleset for fun with powerful tools", then
not using state matching will be sufficient.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: STATELESS

[Ranjeet Shetye]

On Tue, 2003-09-16 at 09:57, Cedric Blancher wrote:
> Le mar 16/09/2003 à 17:50, Ramin Dousti a écrit :
> > > Can I ask you why do you want  to turn off the conntrack?
> > I don't. I just wanted to learn from the people who were saying "just don't
> > load the ip_conntrack..."
> 
> I assume that if someone wants to fallback on stateless filtering is for
> saving load on his box. I can miss something, but I really don't see
> another reason. Once ip_conntrack is loaded, all packets are tracked
> anyway, weither you use state match or not. Yes, one can write a whole
> stateless ruleset with conntrack running, but what's the point : the
> cost implied by a rule with state matching and one without is the same,
> as state flaging is done anyway !
> 
> That's why assuming that stateless is for save load implies ip_conntrack
> module removal. But, as it relies on conntrack, NAT is broken. It is as
> simple as this.
> 
> So, the remaining question is "why does OP wants to fallback to
> stateless filtering". If answer is "to save load", then he will have to
> remove ip_conntrack. If answer is... Well, I don't know, anything else,
> such as "I like writing weak ruleset for fun with powerful tools", then
> not using state matching will be sufficient.

hi,

I do believe that the 2.4 and 2.6 kernels contain an alternative NAT
mechanism associated with the Config variable: CONFIG_IP_ROUTE_NAT

This var is tied to CONFIG_NET_FASTROUTE and "Advanced Router" or
something similar. Internally the source code uses flags like RTCF_NAT
etc.

This mechanism is incomptabile with the whole netfilter infrastructure.
You MUST enable only ONE of the two mechanisms at any given time.
Moreover I have not used this mechanism and dont know if it works and
how well it works and what its limitations are.

-- 

Ranjeet Shetye
Senior Software Engineer
Zultys Technologies
Ranjeet dot Shetye2 at Zultys dot com
http://www.zultys.com/
 
The views, opinions, and judgements expressed in this message are solely
those of the author. The message contents have not been reviewed or
approved by Zultys.

Re: STATELESS

[Cedric Blancher]

Le mar 16/09/2003 à 20:22, Ranjeet Shetye a écrit :
> I do believe that the 2.4 and 2.6 kernels contain an alternative NAT
> mechanism associated with the Config variable: CONFIG_IP_ROUTE_NAT
> This var is tied to CONFIG_NET_FASTROUTE and "Advanced Router" or
> something similar. Internally the source code uses flags like RTCF_NAT
> etc.
> This mechanism is incomptabile with the whole netfilter infrastructure.
> You MUST enable only ONE of the two mechanisms at any given time.
> Moreover I have not used this mechanism and dont know if it works and
> how well it works and what its limitations are.

See documentation at :

	http://www.suse.de/~mha/linux-ip-nat/diplom/nat.html

With 2.2 kernels, one was able to achieve simple NAT with iproute, but
it was far from flexible.

I must admit that, even if this option is activated into my kernel, I
don't use it at all.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

Re: STATELESS

[Oskar Andreasson]

On Tue, 16 Sep 2003, Cedric Blancher wrote:

>
> See documentation at :
>
> 	http://www.suse.de/~mha/linux-ip-nat/diplom/nat.html
>
> With 2.2 kernels, one was able to achieve simple NAT with iproute, but
> it was far from flexible.
>

Yupp, not as flexible, but much faster than netfilter NAT. It doesn't rely
on any kind of connection tracking at all, which is part problem, part
good thing. Good thing is, you get much lower overhead (and hence can
shovel more packets through), bad thing is, it gets less flexible, and it
isn't secure per se (doesn't track, and hence no knowledge about 3-way
handshakes, and no filtering).

Of course, it may suite much better on a router I assume, and if you want
filtering like that, you may as well run netfilter NAT anyways.

> I must admit that, even if this option is activated into my kernel, I
> don't use it at all.
>

----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net

Re: STATELESS

[Julian Gomez]

On Tue, Sep 16, 2003 at 06:57:13PM +0200, Cedric Blancher spoke thusly:
>Le mar 16/09/2003 ? 17:50, Ramin Dousti a ?crit :
>> > Can I ask you why do you want  to turn off the conntrack?
>> I don't. I just wanted to learn from the people who were saying "just don't
>> load the ip_conntrack..."
>
>I assume that if someone wants to fallback on stateless filtering is for
>saving load on his box. I can miss something, but I really don't see
>another reason. Once ip_conntrack is loaded, all packets are tracked
>anyway, weither you use state match or not. Yes, one can write a whole
>stateless ruleset with conntrack running, but what's the point : the cost
>implied by a rule with state matching and one without is the same, as
>state flaging is done anyway !
>
>That's why assuming that stateless is for save load implies ip_conntrack
>module removal. But, as it relies on conntrack, NAT is broken. It is as
>simple as this.

(snip)

In regards to system load (stateful vs non-stateful) -- the following paper
states that might not always be the case. YMMV of course.

http://www.benzedrine.cx/pf-paper.html

Furthermore, the pf performance tricks do seem rather nice to me :-) But
I'm not a coder, so the logic complexity might be excessive.