disabling conntrack ...
rob0 at gmx.co.uk
Sat Aug 27 06:25:00 CEST 2005
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:
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
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.
> :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
> -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
> -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
mail to this address is discarded unless "/dev/rob0"
or "not-spam" is in Subject: header
More information about the netfilter