disabling conntrack ...

disabling conntrack ...

[Kerryn Wood]

Hi All,

 

I need to disable connection tracking and, although I've seen an old
post here and a few mentions doing a search of the web, I haven't been
able to find any conclusive information.

 

I *think* I've removed all the connection tracking modules from
/lib/modules/<kernel version>/kernel/net/ipv4/netfilter/ (I removed all
ip_conntrack* files). When I try and start iptables again I get an error
from iptables-restore. The error message is: "line 57 failed".

 

I'm running FC3, kernel version 2.6.10-1.766 with iptables version
1.2.11.

 

Is there a FAQ or information documented on how to do this (that's I've
missed and will be wholly embarrassed when you point it out)? Does
anyone have any experience doing this they could share?

 

Many thanks,

Kerryn

 

Re: disabling conntrack ...

[Jörg Harmuth]

Kerryn Wood schrieb:
> Hi All,
> 
>  
> 
> I need to disable connection tracking and, although I've seen an old
> post here and a few mentions doing a search of the web, I haven't been
> able to find any conclusive information.

If you *really* want to disable connection tracking, configure your
kernel without NAT support. If this is no option for you, compile in raw
table and use the NOTRACK target.

Have a nice time,

Joerg

Re: disabling conntrack ...

[/dev/rob0]

On Friday 2005-August-26 07:20, Kerryn Wood wrote:
> I need to disable connection tracking and, although I've seen an old

Oh my, what a strange need this is! Tell us why you think you need it, 
and we can answer your questions more effectively (likely explaining 
why you are wrong.)

> I *think* I've removed all the connection tracking modules from
> /lib/modules/<kernel version>/kernel/net/ipv4/netfilter/ (I removed
> all ip_conntrack* files).

Ouch. This is a reckless approach to system administration. Do not 
delete files whose purpose you do not understand.

> When I try and start iptables again I get an error from
> iptables-restore. The error message is: "line 57 failed".

The rule on line 57 of your iptables-restore rules (check your OS 
documentation to find out where that file is) depends on connection 
tracking. My crystal ball tells me it's a MASQUERADE rule.

> I'm running FC3, kernel version 2.6.10-1.766 with iptables version
> 1.2.11.

As was suggested already, use the raw table NOTRACK target to bypass 
connection tracking for the traffic you specify.

> Is there a FAQ or information documented on how to do this (that's
> I've missed and will be wholly embarrassed when you point it out)?
> Does anyone have any experience doing this they could share?

Good heavens no! Connection tracking is the jewel in netfilter's crown. 
Why would I want to disable it?
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

RE: disabling conntrack ...

[Kerryn Wood]

*bows head in shame*

I'm relatively new to iptables (landing the role of administrator
because nobody else wanted it!) so was trying different options, albeit
the wrong ones :)

The scenario is this:
I'm running a machine that's generating a HUGE amount of traffic. 

I was seeing many of the "ip_conntrack: table full, dropping packet"
errors and this I suspected was causing major problems with the software
I was running on the machine. (It looks like it may be because the
machine at the time was working on a network in the US so timeouts (etc
...) were taking longer.) I've increased the hashsize substantially
because as far as I understand the default hashsize is configured (max)
for 2GB of RAM where the machine is running with 12GB. The error
messages just took longer to appear.

As the dropping packets are currently the top of the "what's causing our
problems" list I was (mistakenly apparently :D) investigating disabling
connection tracking (we're not NAT'd), but based on your response I'm
guessing it was the wrong way to go about it!

I think the rules file that iptables-restore was trying to read is
/etc/sysconfig/iptables which I've included at the end of the mail. Line
57 (I've removed all the superfluous documentation lines) is the COMMIT.

Thanks for the help,
Kerryn

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:MYRULE-INPUT - [0:0]
-A INPUT -j MYRULE-INPUT

-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,PSH FIN,SYN,PSH -j LOG
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,PSH FIN,SYN,PSH -j REJECT
--reject-with icmp-port-unreachable

-A MYRULE-INPUT -m state --state NEW -m tcp -p tcp --dport 199 -j ACCEPT
-A MYRULE-INPUT -m state --state NEW -m udp -p udp --dport 161 -j ACCEPT
-A MYRULE-INPUT -p udp -m udp --sport 123 --dport 123 -m state --state
RELATED,ESTABLISHED -j ACCEPT
-A MYRULE-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A MYRULE-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A MYRULE-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A MYRULE-INPUT -i lo -j ACCEPT

-A MYRULE-INPUT -p tcp -m tcp --dport 0:1023 --syn -j REJECT
-A MYRULE-INPUT -p tcp -m tcp --dport 2049 --syn -j REJECT
-A MYRULE-INPUT -p udp -m udp --dport 0:1023 -j REJECT
-A MYRULE-INPUT -p udp -m udp --dport 2049 -j REJECT
-A MYRULE-INPUT -p tcp -m tcp --dport 6000:6009 --syn -j REJECT
-A MYRULE-INPUT -p tcp -m tcp --dport 7100 --syn -j REJECT

COMMIT





-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of /dev/rob0
Sent: 26 August 2005 14:17
To: netfilter@lists.netfilter.org
Subject: Re: disabling conntrack ...

On Friday 2005-August-26 07:20, Kerryn Wood wrote:
> I need to disable connection tracking and, although I've seen an old

Oh my, what a strange need this is! Tell us why you think you need it, 
and we can answer your questions more effectively (likely explaining 
why you are wrong.)

> I *think* I've removed all the connection tracking modules from
> /lib/modules/<kernel version>/kernel/net/ipv4/netfilter/ (I removed
> all ip_conntrack* files).

Ouch. This is a reckless approach to system administration. Do not 
delete files whose purpose you do not understand.

> When I try and start iptables again I get an error from
> iptables-restore. The error message is: "line 57 failed".

The rule on line 57 of your iptables-restore rules (check your OS 
documentation to find out where that file is) depends on connection 
tracking. My crystal ball tells me it's a MASQUERADE rule.

> I'm running FC3, kernel version 2.6.10-1.766 with iptables version
> 1.2.11.

As was suggested already, use the raw table NOTRACK target to bypass 
connection tracking for the traffic you specify.

> Is there a FAQ or information documented on how to do this (that's
> I've missed and will be wholly embarrassed when you point it out)?
> Does anyone have any experience doing this they could share?

Good heavens no! Connection tracking is the jewel in netfilter's crown. 
Why would I want to disable it?
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

RE: disabling conntrack ...

[Derick Anderson]

Someone else will probably jump on this who knows more than I do...

1. Going to assume that your firewall is set up with at least two NICs
and thus is a router or a bridge of some kind. What this means is that
the packets you care about most (i.e., those going through the firewall)
are going through the FORWARD chain in the filter table, not INPUT and
OUTPUT. You are accepting all FORWARD traffic. You are not filtering on
it at all (unless this is being done in mangle or nat tables...?). That
would explain the hideous number of connections you are getting. All
those filtering rules ought to be using the FORWARD chain (i.e., -A
FORWARD -j MY_RULE-FORWARD). You will still need some rules for INPUT
like allowing SSH and RELATED,ESTABLISHED connections.

2. Your INPUT and FORWARD chains should have a default DROP policy.
Whether the OUTPUT chain should is a matter of great debate. For a
beginner I'd say use ACCEPT for OUTPUT. The default DROP policy does the
same thing that your -j REJECT statements are doing, except that it
simply drops the connection, which reduces the load on your system by
not sending "this port closed" messages to millions of zombie machines.

3. Your stateful filtering needs a lot of work. Things are working
because you are allowing any connection higher than port 1023 (for
INPUT; FORWARD accepts anything). What you need is something like this:

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

as your first FORWARD rule. Why? The vast majority of legitimate packets
that will traverse through your system (provided you are using
connection tracking) will be accepted by this rule. Because a packet
will traverse a chain until it hits a rule that it matches, for
performance reasons you should have the most "popular rules" as high as
possible in the chain. Next you should only accept NEW packets into your
specific ports. You can either create a custom chain for this or append
'-m state --state NEW' to the rest of your FORWARD rules. It's to your
advantage (both for typing and firewall performance) to create a custom
chain.

Example:

-A FORWARD -m state --state NEW -j MY_RULE
-A MY_RULE-FORWARD -p tcp ...[accept port whatever]...

4. Since you weren't using FORWARD you aren't validating which packets
are inbound and which are outbound. Some people do this with just source
or destination addresses; I prefer to do it with interfaces as well. My
(and others I'm sure) way requires knowing which interface is
Internet-facing and which is internally-facing but it ties the packet to
a physical source rather than a potentially faked virtual one. Let's say
that eth0 is your Internet-facing interface and eth1 is your
internal-facing interface. Your filtering rules should look something
like this:

# For allowing inbound HTTP to a specific server.
-A MY_RULE-FORWARD -p tcp -i eth0 -o eth1 -d 192.168.1.5 --dport 80 -j
ACCEPT

# For allowing outbound HTTP to the Internet
-A MY_RULE-FORWARD -p tcp -i eth1 -o eth0 --dport 80 -j ACCEPT

5. Just allowing a specific port without qualifying what IPs have a
valid server for it will still let in a ton of unnecessary packets. Your
mail server doesn't have a web server? Then don't allow inbound HTTP to
it.

I suggest a thorough reading of Oskar Andreasson's iptables tutorial at
http://iptables-tutorial.frozentux.net/iptables-tutorial.html which will
help to enlighten you from a very technical perspective. This tutorial
was the difference for me between hacking random scripts I found on the
Internet and actually understanding iptables.

Derick Anderson

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org 
> [mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of 
> Kerryn Wood
> Sent: Friday, August 26, 2005 10:42 AM
> To: netfilter@lists.netfilter.org
> Subject: RE: disabling conntrack ...
> 
> *bows head in shame*
> 
> I'm relatively new to iptables (landing the role of 
> administrator because nobody else wanted it!) so was trying 
> different options, albeit the wrong ones :)
> 
> The scenario is this:
> I'm running a machine that's generating a HUGE amount of traffic. 
> 
> I was seeing many of the "ip_conntrack: table full, dropping packet"
> errors and this I suspected was causing major problems with 
> the software I was running on the machine. (It looks like it 
> may be because the machine at the time was working on a 
> network in the US so timeouts (etc
> ...) were taking longer.) I've increased the hashsize 
> substantially because as far as I understand the default 
> hashsize is configured (max) for 2GB of RAM where the machine 
> is running with 12GB. The error messages just took longer to appear.
> 
> As the dropping packets are currently the top of the "what's 
> causing our problems" list I was (mistakenly apparently :D) 
> investigating disabling connection tracking (we're not 
> NAT'd), but based on your response I'm guessing it was the 
> wrong way to go about it!
> 
> I think the rules file that iptables-restore was trying to 
> read is /etc/sysconfig/iptables which I've included at the 
> end of the mail. Line
> 57 (I've removed all the superfluous documentation lines) is 
> the COMMIT.
> 
> Thanks for the help,
> Kerryn
> 
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> :MYRULE-INPUT - [0:0]
> -A INPUT -j MYRULE-INPUT
> 
> -A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,PSH FIN,SYN,PSH 
> -j LOG -A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,PSH 
> FIN,SYN,PSH -j REJECT --reject-with icmp-port-unreachable
> 
> -A MYRULE-INPUT -m state --state NEW -m tcp -p tcp --dport 
> 199 -j ACCEPT -A MYRULE-INPUT -m state --state NEW -m udp -p 
> udp --dport 161 -j ACCEPT -A MYRULE-INPUT -p udp -m udp 
> --sport 123 --dport 123 -m state --state RELATED,ESTABLISHED 
> -j ACCEPT -A MYRULE-INPUT -m state --state NEW -m tcp -p tcp 
> --dport 80 -j ACCEPT -A MYRULE-INPUT -m state --state NEW -m 
> tcp -p tcp --dport 443 -j ACCEPT -A MYRULE-INPUT -m state 
> --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A 
> MYRULE-INPUT -i lo -j ACCEPT
> 
> -A MYRULE-INPUT -p tcp -m tcp --dport 0:1023 --syn -j REJECT 
> -A MYRULE-INPUT -p tcp -m tcp --dport 2049 --syn -j REJECT -A 
> MYRULE-INPUT -p udp -m udp --dport 0:1023 -j REJECT -A 
> MYRULE-INPUT -p udp -m udp --dport 2049 -j REJECT -A 
> MYRULE-INPUT -p tcp -m tcp --dport 6000:6009 --syn -j REJECT 
> -A MYRULE-INPUT -p tcp -m tcp --dport 7100 --syn -j REJECT
> 
> COMMIT
> 
> 
> 
> 
> 
> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org
> [mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of /dev/rob0
> Sent: 26 August 2005 14:17
> To: netfilter@lists.netfilter.org
> Subject: Re: disabling conntrack ...
> 
> On Friday 2005-August-26 07:20, Kerryn Wood wrote:
> > I need to disable connection tracking and, although I've seen an old
> 
> Oh my, what a strange need this is! Tell us why you think you 
> need it, and we can answer your questions more effectively 
> (likely explaining why you are wrong.)
> 
> > I *think* I've removed all the connection tracking modules from 
> > /lib/modules/<kernel version>/kernel/net/ipv4/netfilter/ (I removed 
> > all ip_conntrack* files).
> 
> Ouch. This is a reckless approach to system administration. 
> Do not delete files whose purpose you do not understand.
> 
> > When I try and start iptables again I get an error from 
> > iptables-restore. The error message is: "line 57 failed".
> 
> The rule on line 57 of your iptables-restore rules (check 
> your OS documentation to find out where that file is) depends 
> on connection tracking. My crystal ball tells me it's a 
> MASQUERADE rule.
> 
> > I'm running FC3, kernel version 2.6.10-1.766 with iptables version 
> > 1.2.11.
> 
> As was suggested already, use the raw table NOTRACK target to 
> bypass connection tracking for the traffic you specify.
> 
> > Is there a FAQ or information documented on how to do this (that's 
> > I've missed and will be wholly embarrassed when you point it out)?
> > Does anyone have any experience doing this they could share?
> 
> Good heavens no! Connection tracking is the jewel in 
> netfilter's crown. 
> Why would I want to disable it?
> -- 
>     mail to this address is discarded unless "/dev/rob0"
>     or "not-spam" is in Subject: header
> 
> 
> 

Re: disabling conntrack ...

[/dev/rob0]

On Friday 2005-August-26 09:42, Kerryn Wood wrote:
> *bows head in shame*
>
> I'm relatively new to iptables (landing the role of administrator

Be not ashamed, none of us are born knowing the ways of Unix / Linux. 
You can learn. You're doing fine.

Some general advice: trust in your OS distributor. All of the major 
Linux distributors know what they are doing, to some extent, and their 
OS generally works well when set up and managed per instructions.

> The scenario is this:
> I'm running a machine that's generating a HUGE amount of traffic.

What kind of traffic, mostly?

> I was seeing many of the "ip_conntrack: table full, dropping packet"

I posted a solution to this just Wednesday, and someone else posted a 
nice link to some of the sysctl documentation today.

Your solution may simply be to echo a larger number to the file 
"/proc/sys/net/ipv4/ip_conntrack_max". This is explained at:

http://www.wallfire.org/misc/netfilter_conntrack_perf.txt

Is this a low-memory machine?

> errors and this I suspected was causing major problems with the
> software I was running on the machine. (It looks like it may be
> because the machine at the time was working on a network in the US so
> timeouts (etc ...) were taking longer.) I've increased the hashsize
> substantially because as far as I understand the default hashsize is
> configured (max) for 2GB of RAM where the machine is running with
> 12GB. The error messages just took longer to appear.

Ah, no, not low memory. :) So something might be wrong in the software 
which is generating all the traffic, or in the iptables rules.

> As the dropping packets are currently the top of the "what's causing
> our problems" list I was (mistakenly apparently :D) investigating
> disabling connection tracking (we're not NAT'd), but based on your
> response I'm guessing it was the wrong way to go about it!

Yes. Deleting your modules will prevent them from loading, but as you 
saw, it prevents you from using rules which need them.

> I think the rules file that iptables-restore was trying to read is
> /etc/sysconfig/iptables which I've included at the end of the mail.
> Line 57 (I've removed all the superfluous documentation lines) is the
> COMMIT.

Right. I could have told you /etc/sysconfig/iptables, but it's crucial 
for you to be able to find these things on your own. See? No shame. 
You'll learn what you need to learn, and most importantly, where to 
find what you need.

Thanks for trimming the excess from that. Please also consider trimming 
superfluous quoted material in your messages, and not top-posting.

> *filter
>
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]

If this machine is not acting as a router, which it appears not, you 
should set a DROP policy.

> :OUTPUT ACCEPT [0:0]
> :MYRULE-INPUT - [0:0]
>
> -A INPUT -j MYRULE-INPUT

I like using user chains, but I give mine names which are a bit more 
descriptive. The -INPUT part is good, but "MYRULE" doesn't tell me 
anything. Also, since you're only using this one target, you have not 
made the structure cleaner.

> -A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,PSH FIN,SYN,PSH -j LOG
> -A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,PSH FIN,SYN,PSH -j REJECT
> --reject-with icmp-port-unreachable

OUTPUT filtering is not generally useful. These rules won't cause much 
heartache, but then, why are you doing it? What does it do for you? If 
you're originating traffic you don't want, change the process that's 
generating the traffic.

> -A MYRULE-INPUT -m state --state NEW -m tcp -p tcp --dport 199 -j
> ACCEPT 
> -A MYRULE-INPUT -m state --state NEW -m udp -p udp --dport 161 
> -j ACCEPT
> -A MYRULE-INPUT -p udp -m udp --sport 123 --dport 123 -m 
> state --state RELATED,ESTABLISHED -j ACCEPT
> -A MYRULE-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j
> ACCEPT
> -A MYRULE-INPUT -m state --state NEW -m tcp -p tcp --dport 443 
> -j ACCEPT
> -A MYRULE-INPUT -m state --state NEW -m tcp -p tcp --dport 
> 22 -j ACCEPT

All of those are using connection tracking. And only the NTP rule will 
allow in replies. (Yours come in on the default policy, ACCEPT.)

> -A MYRULE-INPUT -i lo -j ACCEPT 

Usually a good idea.

> -A MYRULE-INPUT -p tcp -m tcp --dport 0:1023 --syn -j REJECT
> -A MYRULE-INPUT -p tcp -m tcp --dport 2049 --syn -j REJECT
> -A MYRULE-INPUT -p udp -m udp --dport 0:1023 -j REJECT
> -A MYRULE-INPUT -p udp -m udp --dport 2049 -j REJECT
> -A MYRULE-INPUT -p tcp -m tcp --dport 6000:6009 --syn -j REJECT
> -A MYRULE-INPUT -p tcp -m tcp --dport 7100 --syn -j REJECT

This is what I call an ipchains-style ruleset, which tries to list all 
the traffic you don't want. That's not necessary with connection 
tracking. In fact it's not as secure, either.

The Packet-Filtering-HOWTO (found at netfilter.org) has the definitive 
quick and easy guide to iptables. Basically you use default DROP 
policies in INPUT and FORWARD, -m state --state RELATED,ESTABLISHED -j 
ACCEPT rules at the top of both, and -m state --state NEW -j ACCEPT 
rules for your chosen services. Follow those with default policies of 
DROP, perhaps preceded by a -p tcp -j REJECT if you wish. (OUTPUT 
should be ACCEPT.)

For you that would be two rules:
-A INPUT -p tcp -m multiport --dports 22,80,199,443 -j ACCEPT
-A INPUT -p udp --dport 161 -j ACCEPT
Note there is no explicit rule for NTP. You don't need it, because the 
blanket --state RELATED,ESTABLISHED allows it.

Now, why is your ruleset causing you problems with connection tracking? 
That's a good question. I don't know. But perhaps an iptables-style 
ruleset would work better. If not, post again and we'll try to debug. 
Or maybe someone else will be along with a theory about your conntrack 
troubles.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header