Re: iptables performance

From: Juha Laiho (Juha.Laiho_at_iki.fi)
Date: 10/12/03 

Date: Sun, 12 Oct 2003 12:32:01 GMT

max4 <max@nowhere.com> said:
>well you were right
>i asked the guy from shorewall
>and 30 min after the patch was ready :)
>now i finaly have 8MB/s on my lan
>question : if the blacklist is checked for new conexions
>what happen with udp packets ??

Ah, yes. There are connections and connections. Netfilter does maintain
"connection-like" information for UDP traffic as well. So, if you send
a UDP packet to some destination, netfilter will for a while (I don't
actually know for how long) keep the way open for packets coming back the
same route (so, reversing source and destination IP and port numbers).

For example, NTP (network time protocol) is built on top of UDP. For
that I don't have any specific inbound openings (and am currently
accepting all outbound traffic). For inbound traffic, I have set this
"allow established and related" rule. When the time server on my machine
wishes to check the correctness of time from my upstream time server,
it will send a UDP packet. The response packet (UDP also), is permitted
because the outbound packet created a "connection" at netfilter level.
Still, an unsolicited packet from the time server would be blocked.

The "related" also includes the important ICMP types related to existing
connections, so when using that there's no necessity to allow any
specific inbound ICMP, and still you're not breaking your networking
(as dropping all inbound ICMP would do -- f.ex. you wouldn't get the
failure information returned by outbound UDP packets which were refused
by the other party). As ICMP echo (ping) isn't part of any other normal
protocol communication, allowing "related" will not allow inbound ICMP
echo, though.

As to your question in the other message, I'm not using any frontend;
my rule sets tend to stay rather simple -- and at least for now I believe
that creating the rulesets in certain structure will keep them simple
even for rather complicated needs.

Below is the basic structure I use for my INPUT chain (edited snippet
from iptables-save output; the INPUT chain policy is DROP):

# Allow everything from interfaces internal to my network
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
# Handle packets by connection state
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Handle TCP SYN packets that don't belong to any established session
# (so, if I'm a target of TCP scan using some other than SYN, those
# packets don't even enter my tcp-ext processing -- and that's where
# I have most of my address-based decisions)
-A INPUT -i eth1 -p tcp -m state --state NEW -m tcp --tcp-flags SYN,RST,ACK SYN
-j tcp-ext
# Handle new UDP traffic
-A INPUT -i eth1 -p udp -m state --state NEW -j udp-ext
# Handle new ICMP traffic
-A INPUT -i eth1 -p icmp -m state --state NEW -j icmp-ext
# Log what was not handled (note: this is the only place where
# my rulesets log anything)
-A INPUT -j LOG
# ... and DROP by chain policy all packets that made it this far

In tcp-ext chain (a locally created chain that is called from INPUT) I have
things like:

# Allow SSH from certain address
-A tcp-ext -s x.y.z.w -p tcp -m tcp --dport 22 -j ACCEPT
# Drop tcp/135 traffic (I think this was the Windows RPC port; anyway
# something I don't want to see in my network -- and something I don't
# even want into my logs)
-A tcp-ext -p tcp -m tcp --dport 135 -j DROP
# Actively reject inbound ident connection attempts from certain address
-A tcp-ext -s a.b.c.d -p tcp -m tcp --dport 113 -j REJECT --reject-with tcp-reset

... so, the above were from a system where no public services are provided
to the network, so it is set to more or less stealth mode (from outsiders'
point of view there's nothing responding in any way in this address). I
believe this greatly reduces the amount of port scans I see. Other reasons
for not generating responses to unsolicited communications is to keep my
uplink traffic at a minimum, and also to prevent the use of my machine as
an attack redirector. 

-- 
Wolf  a.k.a.  Juha Laiho     Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
         PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Relevant Pages