re: ip_conntrack_max vs ip_conntrack

re: ip_conntrack_max vs ip_conntrack

[Jiann-Ming Su]

I'd like to know what some of these proc paremeters mean as well. 
What we're experiencing is a SYN flood attack that's filling up the
connection tables.  What I'd like to do is change the timeout to 5
seconds, instead of the default 30 seconds.
-- 
Jiann-Ming Su
"I have to decide between two equally frightening options.  
                                            If I wanted to do that,
I'd vote." --Duckman

re: ip_conntrack_max vs ip_conntrack

[Jason Opperisano]

On Mon, 2004-09-27 at 13:52, Jiann-Ming Su wrote:
> I'd like to know what some of these proc paremeters mean as well. 
> What we're experiencing is a SYN flood attack that's filling up the
> connection tables.  What I'd like to do is change the timeout to 5
> seconds, instead of the default 30 seconds.

in the case of a SYN flood attack--you'd probably be better off
utilizing the limit match, rather than mucking with global timeout
values.

in any case--the timeout value you would probably be interested in
changing in the case of a SYN flood attack would be:

sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv=X

where your proposed X=5.

the default i have here for that value is 60 seconds.

-j

-- 
Jason Opperisano <opie@817west.com>

re: ip_conntrack_max vs ip_conntrack

[Jose Maria Lopez]

El lun, 27 de 09 de 2004 a las 19:52, Jiann-Ming Su escribió:
> I'd like to know what some of these proc paremeters mean as well. 
> What we're experiencing is a SYN flood attack that's filling up the
> connection tables.  What I'd like to do is change the timeout to 5
> seconds, instead of the default 30 seconds.

The ip_conntrack_max parameter is used to set the maximum
entries in the conntrack table that the system can have at
a time. The ip_conntrack is the file that contains the
conntrack table, it lists the IPs and their states.

If you want to limit the SYN flooding you should use the
limit match of iptables, or you can use the TCP SYN cookie
feature of netfilter. It can be activated in
/proc/sys/net/ipv4/tcp_syncookies

For the limit match look at:
iptables -m limit --help

-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
                -- Jack Kerouac, "On the Road"

Re: ip_conntrack_max vs ip_conntrack

[Jiann-Ming Su]

On 27 Sep 2004 20:57:24 +0200, Jose Maria Lopez <jkerouac@bgsec.com> wrote:
> 
> For the limit match look at:
> iptables -m limit --help
> 
> 

There's some good info on what I was looking for at the end of this section:

http://www.iptables.org/documentation/HOWTO//packet-filtering-HOWTO-7.html#ss7.3

Does the limit option work on a per connection basis?  Or, does one
attacker's syn flood cause everybody to be limited as well?
-- 
Jiann-Ming Su
"I have to decide between two equally frightening options.  
                                            If I wanted to do that,
I'd vote." --Duckman

Re: ip_conntrack_max vs ip_conntrack

[Jason Opperisano]

On Thu, 2004-09-30 at 18:48, Jiann-Ming Su wrote:
> 
> There's some good info on what I was looking for at the end of this section:
> 
> http://www.iptables.org/documentation/HOWTO//packet-filtering-HOWTO-7.html#ss7.3
> 
> Does the limit option work on a per connection basis?  Or, does one
> attacker's syn flood cause everybody to be limited as well?

the limit match works per-rule.  however you define what matches the
rule is what will be limited.

-j

-- 
Jason Opperisano <opie@817west.com>

Re: ip_conntrack_max vs ip_conntrack

[Jiann-Ming Su]

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

On Thu, 30 Sep 2004 18:48:16 -0400, Jiann-Ming Su <sujiannming@gmail.com> wrote:
> 
> There's some good info on what I was looking for at the end of this section:
> 
> http://www.iptables.org/documentation/HOWTO//packet-filtering-HOWTO-7.html#ss7.3
> 

In case someone, like myself, should look through the archives,
another good place for info is
http://iptables-tutorial.frozentux.net/iptables-tutorial.html.  I'm
also including a snapshot of the rules we use to firewall off the
dorms at an academic institution.  Someone else out there may find
this helpful.  All IP's have been changed to protect the guilty.

-- 
Jiann-Ming Su
"I have to decide between two equally frightening options.  
                                            If I wanted to do that,
I'd vote." --Duckman

[-- Attachment #2: iptables --]
[-- Type: application/octet-stream, Size: 3922 bytes --]

# Generated by iptables-save v1.2.9 on Thu Oct 14 15:16:17 2004
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Thu Oct 14 15:16:17 2004
# Generated by iptables-save v1.2.9 on Thu Oct 14 15:16:17 2004
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Thu Oct 14 15:16:17 2004
# Generated by iptables-save v1.2.9 on Thu Oct 14 15:16:17 2004
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:FWD_SYN - [0:0]
:IN_ICMP - [0:0]
:IN_TCP - [0:0]
:IN_UDP - [0:0]
-A INPUT -i lo -j ACCEPT 
-A INPUT -p 89 -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p udp -j IN_UDP 
-A INPUT -p tcp -m state --state NEW -j IN_TCP 
-A INPUT -p icmp -j IN_ICMP 
-A INPUT -j ULOG --ulog-prefix "iptables input cleanup: " 
-A FORWARD -d ! 192.168.0.0/255.255.0.0 -p tcp -m tcp -m multiport --dports 135,445 -j DROP 
-A FORWARD -i eth1 -p tcp -m multiport --dports 135,445 -j DROP 
-A FORWARD -i eth2 -p tcp -m tcp --tcp-flags SYN SYN -j FWD_SYN 
-A FORWARD -i eth2 -j ACCEPT 
-A FORWARD -p 47 -j ACCEPT 
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -s 192.168.0.0/255.255.0.0 -j ACCEPT 
-A FORWARD -s 10.0.0.0/255.255.0.0 -j ACCEPT 
-A FWD_SYN -p tcp -m tcp --tcp-flags FIN FIN -m limit --limit 10/min -j ULOG --ulog-prefix "iptables SYN/FIN attack" 
-A FWD_SYN -p tcp -m tcp --tcp-flags FIN FIN -j DROP 
-A FWD_SYN -p tcp -m tcp --dport 80 -m limit --limit 100/sec --limit-burst 200 -j ACCEPT 
-A FWD_SYN -p tcp -m tcp --dport 135 -m limit --limit 50/sec --limit-burst 50 -j ACCEPT 
-A FWD_SYN -p tcp -m tcp --dport 443 -m limit --limit 50/sec --limit-burst 50 -j ACCEPT 
-A FWD_SYN -p tcp -m tcp --dport 445 -m limit --limit 50/sec --limit-burst 50 -j ACCEPT 
-A FWD_SYN -p tcp -m tcp --dport 80 -m limit --limit 1/sec -j ULOG --ulog-prefix "iptables syn limit: " 
-A FWD_SYN -p tcp -m multiport --dports 135,443,445 -m limit --limit 10/min -j ULOG --ulog-prefix "iptables syn limit: " 
-A FWD_SYN -p tcp -m tcp -m multiport --dports 80,135,443,445 -j DROP 
-A FWD_SYN -p tcp -m tcp -m limit --limit 50/sec --limit-burst 50 -j ACCEPT 
-A FWD_SYN -p tcp -m tcp -m limit --limit 10/min -j ULOG --ulog-prefix "iptables syn limit: " 
-A FWD_SYN -j DROP 
-A IN_ICMP -s 10.0.9.30 -p icmp -j ACCEPT 
-A IN_ICMP -s 10.0.218.128/255.255.255.224 -p icmp -j ACCEPT 
-A IN_ICMP -s 10.0.246.0/255.255.254.0 -p icmp -j ACCEPT 
-A IN_ICMP -s 192.168.53.224/255.255.255.224 -p icmp -j ACCEPT 
-A IN_ICMP -j ULOG --ulog-prefix "iptables input icmp cleanup: " 
-A IN_ICMP -j DROP 
-A IN_TCP -s 192.168.99.36 -p tcp -m tcp --dport 22 -j ACCEPT 
-A IN_TCP -s 192.168.149.53 -p tcp -m tcp --dport 22 -j ACCEPT 
-A IN_TCP -s 192.168.99.35 -p tcp -m tcp --dport 22 -j ACCEPT 
-A IN_TCP -s 192.168.99.34 -p tcp -m tcp --dport 22 -j ACCEPT 
-A IN_TCP -s 192.168.68.111 -p tcp -m tcp --dport 22 -j ACCEPT 
-A IN_TCP -s 10.0.218.128/255.255.255.224 -p tcp -m tcp --dport 22 -j ACCEPT 
-A IN_TCP -s 10.0.246.0/255.255.254.0 -p tcp -m tcp --dport 22 -j ACCEPT 
-A IN_TCP -s 192.168.53.224/255.255.255.224 -p tcp -m tcp --dport 22 -j ACCEPT 
-A IN_TCP -s 10.0.246.0/255.255.254.0 -p tcp -m tcp --dport 10000 -j ACCEPT 
-A IN_TCP -s 10.0.254.144/255.255.255.240 -p tcp -m tcp --dport 10000 -j ACCEPT 
-A IN_TCP -j ULOG --ulog-prefix "iptables input tcp cleanup: " 
-A IN_TCP -j DROP 
-A IN_UDP -s 10.0.246.223 -p udp -m udp --dport 161 -j ACCEPT 
-A IN_UDP -s 10.0.9.30 -p udp -m udp --dport 161 -j ACCEPT 
-A IN_UDP -s 10.0.218.128/255.255.255.224 -p udp -m udp --dport 161 -j ACCEPT 
-A IN_UDP -s 10.0.246.63 -p udp -m udp --dport 161 -j ACCEPT 
-A IN_UDP -s 192.168.53.224/255.255.255.224 -p udp -m udp --dport 161 -j ACCEPT 
-A IN_UDP -j ULOG --ulog-prefix "iptables input udp cleanup: " 
-A IN_UDP -j DROP 
COMMIT
# Completed on Thu Oct 14 15:16:17 2004

ip_conntrack_max vs ip_conntrack

[Michal Ludvig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

could someone please explain me what is the relation between the number
in /proc/sys/net/ipv4/ip_conntrack_max and number of lines in
/proc/net/ip_conntrack?

On one of our very loaded firewalls (with 1GB RAM) we are still getting
"ip_conntrack: table full, dropping packet." message. We tried to tweak
all different parameters, e.g. hashsize to up to 1048576,
ip_conntrack_max, ip_conntrack_tcp_timeout_established, etc.
Unfortunately sooner or later the kernel always starts dropping packets.
At the same time however there are at most a few thousands of lines in
/proc/net/ip_conntrack.

I instrumented the kernel to dump the same output via printk() once
ip_conntrack_count reaches ip_conntrack_max. When I set _max=128 and run
nmap through the firewall it of course very soon prints the "dropping
packets" message, but along with only 6 (=six!) lines of connections.
Where was the rest, 122 connections, lost? What does the
ip_conntrack_count actually count?

Thanks in advance!

Michal Ludvig
- --
SUSE Labs                    mludvig@suse.cz
(+420) 296.545.373        http://www.suse.cz
Personal homepage http://www.logix.cz/michal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBVKEQDDolCcRbIhgRAupGAKCF4F6Mvk0YARZMj5S21vI/95u71ACfWDn2
UVB5lEV0YC58et/rvFbJEEY=
=AryG
-----END PGP SIGNATURE-----

Re: ip_conntrack_max vs ip_conntrack

[Stephen J Smoogen]

Michal Ludvig wrote:
> Hi all,
> 
> could someone please explain me what is the relation between the number
> in /proc/sys/net/ipv4/ip_conntrack_max and number of lines in
> /proc/net/ip_conntrack?
> 
> On one of our very loaded firewalls (with 1GB RAM) we are still getting
> "ip_conntrack: table full, dropping packet." message. We tried to tweak
> all different parameters, e.g. hashsize to up to 1048576,
> ip_conntrack_max, ip_conntrack_tcp_timeout_established, etc.
> Unfortunately sooner or later the kernel always starts dropping packets.
> At the same time however there are at most a few thousands of lines in
> /proc/net/ip_conntrack.
> 
> I instrumented the kernel to dump the same output via printk() once
> ip_conntrack_count reaches ip_conntrack_max. When I set _max=128 and run
> nmap through the firewall it of course very soon prints the "dropping
> packets" message, but along with only 6 (=six!) lines of connections.
> Where was the rest, 122 connections, lost? What does the
> ip_conntrack_count actually count?
> 

Ok one thing you might want to do is check to see if you dont have a bug 
in your kernel somewhere.. I found the one I talked about earlier by 
doing the following:

cat /proc/slabinfo |grep ip_conntrack
cat /proc/net/ip_conntrack | wc -l

Not the best and very racy.. but the 2 did NOT match up in any shape or 
form. I then played around with various conntrack modules until I figure 
d it out to being something with conntrack_irc and conntrack_ftp in the 
kernel I was running. Removing those allowed for the 2 to match up 
closely when doing  HTTP crashloads on the firewall. Adding either one 
of them caused what looked like a resource leak.

As far as I can tell.. a POM-only patched 2.4.26 did not exhibit this 
problem.



-- 
Stephen John Smoogen	        | CCN-5 Security Team
LANL SIRT Team Leader           | SMTP:  smoogen@lanl.gov
Los Alamos National Laboratory  | Voice: 505.664.0645
Ta-03 SM-1498 MS: B255 DP 10S   | FAX:   505.665.7793
Los Alamos, NM 87545            |

Re: ip_conntrack_max vs ip_conntrack

[Michal Ludvig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen J Smoogen told me that:
> Michal Ludvig wrote:
> 
>> Hi all,
>>
>> could someone please explain me what is the relation between the number
>> in /proc/sys/net/ipv4/ip_conntrack_max and number of lines in
>> /proc/net/ip_conntrack?
>>
>> On one of our very loaded firewalls (with 1GB RAM) we are still getting
>> "ip_conntrack: table full, dropping packet." message. We tried to tweak
>> all different parameters, e.g. hashsize to up to 1048576,
>> ip_conntrack_max, ip_conntrack_tcp_timeout_established, etc.
>> Unfortunately sooner or later the kernel always starts dropping packets.
>> At the same time however there are at most a few thousands of lines in
>> /proc/net/ip_conntrack.
>>
>> I instrumented the kernel to dump the same output via printk() once
>> ip_conntrack_count reaches ip_conntrack_max. When I set _max=128 and run
>> nmap through the firewall it of course very soon prints the "dropping
>> packets" message, but along with only 6 (=six!) lines of connections.
>> Where was the rest, 122 connections, lost? What does the
>> ip_conntrack_count actually count?
> 
> Ok one thing you might want to do is check to see if you dont have a bug
> in your kernel somewhere.. I found the one I talked about earlier by
> doing the following:
> 
> cat /proc/slabinfo |grep ip_conntrack
> cat /proc/net/ip_conntrack | wc -l
> 
> Not the best and very racy.. but the 2 did NOT match up in any shape or
> form. I then played around with various conntrack modules until I figure
> d it out to being something with conntrack_irc and conntrack_ftp in the
> kernel I was running. Removing those allowed for the 2 to match up
> closely when doing  HTTP crashloads on the firewall. Adding either one
> of them caused what looked like a resource leak.
> 
> As far as I can tell.. a POM-only patched 2.4.26 did not exhibit this
> problem.

I can see it on 2.6.5 but not on 2.6.9-rc2. Does anyone have the patch
or the cset number that fixed this? I hope I won't have to binary search
for it... ;-)

Michal Ludvig
- --
SUSE Labs                    mludvig@suse.cz
(+420) 296.542.396        http://www.suse.cz
Personal homepage http://www.logix.cz/michal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBW9kTDDolCcRbIhgRAl3MAJ9T3SH/leXz3v4oScV/j4Q9vS6BggCfTFOh
WhXvdntlqi2W1bIs0o4E6as=
=48El
-----END PGP SIGNATURE-----

Re: ip_conntrack_max vs ip_conntrack

[Mohamed Eldesoky]

But still,
The /proc/net/ip_conntrack should contain all connections tracked by
that firewall (ie, passing through the firewall), am I right ??


On Sat, 25 Sep 2004 00:34:58 +0200, Michal Ludvig <mludvig@suse.cz> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> could someone please explain me what is the relation between the number
> in /proc/sys/net/ipv4/ip_conntrack_max and number of lines in
> /proc/net/ip_conntrack?
> 
> On one of our very loaded firewalls (with 1GB RAM) we are still getting
> "ip_conntrack: table full, dropping packet." message. We tried to tweak
> all different parameters, e.g. hashsize to up to 1048576,
> ip_conntrack_max, ip_conntrack_tcp_timeout_established, etc.
> Unfortunately sooner or later the kernel always starts dropping packets.
> At the same time however there are at most a few thousands of lines in
> /proc/net/ip_conntrack.
> 
> I instrumented the kernel to dump the same output via printk() once
> ip_conntrack_count reaches ip_conntrack_max. When I set _max=128 and run
> nmap through the firewall it of course very soon prints the "dropping
> packets" message, but along with only 6 (=six!) lines of connections.
> Where was the rest, 122 connections, lost? What does the
> ip_conntrack_count actually count?
> 
> Thanks in advance!
> 
> Michal Ludvig
> - --
> SUSE Labs                    mludvig@suse.cz
> (+420) 296.545.373        http://www.suse.cz
> Personal homepage http://www.logix.cz/michal
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFBVKEQDDolCcRbIhgRAupGAKCF4F6Mvk0YARZMj5S21vI/95u71ACfWDn2
> UVB5lEV0YC58et/rvFbJEEY=
> =AryG
> -----END PGP SIGNATURE-----
> 
> 



-- 
Mohamed Eldesoky
www.eldesoky.net
RHCE

Re: ip_conntrack_max vs ip_conntrack

[Alistair Tonner]

On September 28, 2004 03:59 am, Mohamed Eldesoky wrote:
> But still,
> The /proc/net/ip_conntrack should contain all connections tracked by
> that firewall (ie, passing through the firewall), am I right ??
>

	This list is all actively tracked connections, all not yet completed,  but 
possibly tracked connections (called expectations) that the netfilter code is 
watching for.  You need to pay attention to the state of the connection, but 
you've got  the right idea.

	I can't recall all the states off the top of my head, but they are fairly 
clearly labelled.

	Alistair Tonner.

	<< SNIPPAGE>>

Re: ip_conntrack_max vs ip_conntrack

[Ted Kaczmarek]

      * 
On Tue, 2004-09-28 at 08:31, Alistair Tonner wrote:
> On September 28, 2004 03:59 am, Mohamed Eldesoky wrote:
> > But still,
> > The /proc/net/ip_conntrack should contain all connections tracked by
> > that firewall (ie, passing through the firewall), am I right ??
> >
> 
> 	This list is all actively tracked connections, all not yet completed,  but 
> possibly tracked connections (called expectations) that the netfilter code is 
> watching for.  You need to pay attention to the state of the connection, but 
> you've got  the right idea.
> 
> 	I can't recall all the states off the top of my head, but they are fairly 
> clearly labelled.
> 
> 	Alistair Tonner.
> 
> 	<< SNIPPAGE>>
> 
Iptstate is nice for this.

Ted

Re: ip_conntrack_max vs ip_conntrack

[Jose Maria Lopez]

El mar, 28 de 09 de 2004 a las 09:59, Mohamed Eldesoky escribió:
> But still,
> The /proc/net/ip_conntrack should contain all connections tracked by
> that firewall (ie, passing through the firewall), am I right ??

Yes, and it will remember the connections made for a time. It's
a list of all the connections the conntrack system have seen, and
it's used to check the established and related connections.

-- 
Jose Maria Lopez Hernandez
Director Tecnico de bgSEC
jkerouac@bgsec.com
bgSEC Seguridad y Consultoria de Sistemas Informaticos
http://www.bgsec.com
ESPAÑA

The only people for me are the mad ones -- the ones who are mad to live,
mad to talk, mad to be saved, desirous of everything at the same time,
the ones who never yawn or say a commonplace thing, but burn, burn, burn
like fabulous yellow Roman candles.
                -- Jack Kerouac, "On the Road"

Re: ip_conntrack_max vs ip_conntrack

[Mohamed Eldesoky]

Well, I want to make sure that it remembers only connections that
passes THROUGH it !!


On 28 Sep 2004 16:27:53 +0200, Jose Maria Lopez <jkerouac@bgsec.com> wrote:
> El mar, 28 de 09 de 2004 a las 09:59, Mohamed Eldesoky escribió:
> > But still,
> > The /proc/net/ip_conntrack should contain all connections tracked by
> > that firewall (ie, passing through the firewall), am I right ??
> 
> Yes, and it will remember the connections made for a time. It's
> a list of all the connections the conntrack system have seen, and
> it's used to check the established and related connections.
> 
> 
> 
> --
> Jose Maria Lopez Hernandez
> Director Tecnico de bgSEC
> jkerouac@bgsec.com
> bgSEC Seguridad y Consultoria de Sistemas Informaticos
> http://www.bgsec.com
> ESPAÑA
> 
> The only people for me are the mad ones -- the ones who are mad to live,
> mad to talk, mad to be saved, desirous of everything at the same time,
> the ones who never yawn or say a commonplace thing, but burn, burn, burn
> like fabulous yellow Roman candles.
>                 -- Jack Kerouac, "On the Road"
> 
> 



-- 
Mohamed Eldesoky
www.eldesoky.net
RHCE

Re: ip_conntrack_max vs ip_conntrack

[Alistair Tonner]

On September 28, 2004 10:48 am, Mohamed Eldesoky wrote:
> Well, I want to make sure that it remembers only connections that
> passes THROUGH it !!

	Are you saying you don't want to track local connections?

	This file keeps track of anything that *_conntrack_* would watch.
	As far as I know this includes local connections -- 

	If you are accepting any connections locally, they are very likely in this
	table.  

	I've seen at least one discussion about breaking this up into different 
files.  That gets messy very quicky from a code point of view, as well as 
from a logic point of view.  I certainly prefer the idea of having one place 
to track connections.

	Alistair Tonner

	
>
> On 28 Sep 2004 16:27:53 +0200, Jose Maria Lopez <jkerouac@bgsec.com> wrote:
> > El mar, 28 de 09 de 2004 a las 09:59, Mohamed Eldesoky escribió:
> > > But still,
> > > The /proc/net/ip_conntrack should contain all connections tracked by
> > > that firewall (ie, passing through the firewall), am I right ??
> >
> > Yes, and it will remember the connections made for a time. It's
> > a list of all the connections the conntrack system have seen, and
> > it's used to check the established and related connections.
> >
> >
> >
> > --
> > Jose Maria Lopez Hernandez
> > Director Tecnico de bgSEC
> > jkerouac@bgsec.com
> > bgSEC Seguridad y Consultoria de Sistemas Informaticos
> > http://www.bgsec.com
> > ESPAÑA
> >
> > The only people for me are the mad ones -- the ones who are mad to live,
> > mad to talk, mad to be saved, desirous of everything at the same time,
> > the ones who never yawn or say a commonplace thing, but burn, burn, burn
> > like fabulous yellow Roman candles.
> >                 -- Jack Kerouac, "On the Road"

Re: ip_conntrack_max vs ip_conntrack

[Mohamed Eldesoky]

Well, I know its function, just wanted to make sure.
As there is a small network misconfiguration that I wanted to know its root.

Thanks for the help.


On Tue, 28 Sep 2004 11:19:35 -0400, Alistair Tonner <alistair@nerdnet.ca> wrote:
> On September 28, 2004 10:48 am, Mohamed Eldesoky wrote:
> > Well, I want to make sure that it remembers only connections that
> > passes THROUGH it !!
> 
>         Are you saying you don't want to track local connections?
> 
>         This file keeps track of anything that *_conntrack_* would watch.
>         As far as I know this includes local connections --
> 
>         If you are accepting any connections locally, they are very likely in this
>         table.
> 
>         I've seen at least one discussion about breaking this up into different
> files.  That gets messy very quicky from a code point of view, as well as
> from a logic point of view.  I certainly prefer the idea of having one place
> to track connections.
> 
>         Alistair Tonner
> 
> 
> 
> 
> >
> > On 28 Sep 2004 16:27:53 +0200, Jose Maria Lopez <jkerouac@bgsec.com> wrote:
> > > El mar, 28 de 09 de 2004 a las 09:59, Mohamed Eldesoky escribió:
> > > > But still,
> > > > The /proc/net/ip_conntrack should contain all connections tracked by
> > > > that firewall (ie, passing through the firewall), am I right ??
> > >
> > > Yes, and it will remember the connections made for a time. It's
> > > a list of all the connections the conntrack system have seen, and
> > > it's used to check the established and related connections.
> > >
> > >
> > >
> > > --
> > > Jose Maria Lopez Hernandez
> > > Director Tecnico de bgSEC
> > > jkerouac@bgsec.com
> > > bgSEC Seguridad y Consultoria de Sistemas Informaticos
> > > http://www.bgsec.com
> > > ESPAÑA
> > >
> > > The only people for me are the mad ones -- the ones who are mad to live,
> > > mad to talk, mad to be saved, desirous of everything at the same time,
> > > the ones who never yawn or say a commonplace thing, but burn, burn, burn
> > > like fabulous yellow Roman candles.
> > >                 -- Jack Kerouac, "On the Road"
> 
> 



-- 
Mohamed Eldesoky
www.eldesoky.net
RHCE