Re: disabling conntrack ...

[/dev/rob0 <rob0@gmx.co.uk>]

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