Re: iptables udp and output
From: Juha Laiho (Juha.Laiho_at_iki.fi)
Date: 01/15/04
- Next message: Cameron L. Spitzer: "Re: Getting Linux On CD"
- Previous message: Tim Haynes: "Re: iptables udp and output"
- In reply to: charly: "Re: iptables udp and output"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 15 Jan 2004 21:07:00 GMT
charly <spam@yahoo.fr> said:
[... something which I condensed to the essence]
So, here's the ruleset, re-ordered to provide a clearer view to
contents of INPUT and OUTPUT chains. Listing the chain policy as the
last item of the chain may seem counter-intuitive, until you realize
that it is actually just writing out in what order filter applies
the rules.
>$IPTABLES -A INPUT -m psd -j DROP
>$IPTABLES -A INPUT -f -j DROP
>$IPTABLES -A INPUT -i eth0 -m state --state INVALID -j DROP
>$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>$IPTABLES -A INPUT -p tcp --syn --match multiport --dports $LOCAL_SERVICES -j ACCEPT
>$IPTABLES -A INPUT -p tcp --sport 135:139 -j DROP
>$IPTABLES -A INPUT -p udp --sport 135:139 -j DROP
>$IPTABLES -A INPUT -p tcp --sport 445 -j DROP
>$IPTABLES -A INPUT -p udp -s $GATEWAY --sport 53 -j ACCEPT
>$IPTABLES -A INPUT -p icmp -m state --state INVALID -j DROP
>$IPTABLES -A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
>$IPTABLES -A INPUT -p ! icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>$IPTABLES -A INPUT -i lo -j ACCEPT
>$IPTABLES -P INPUT DROP
So, you drop all fragments past the first one of each fragmented packet.
Meaning if a packet was fragmented in transit, you'll never going to
receive it.
'state INVALID' messages are in the start dropped only if they arrive from
eth0. I don't see a reason to accept 'state INVALID' traffic from anywhere.
At rather early phase you're accepting all RELATED,ESTABLISHED traffic. This
means that the ICMP-specific RELATED,ESTABLISHED rule later is redundant,
as is the RELATED,ESTABLISHED part of the rule starting with '-p ! icmp'.
Also note that there all 'NEW' non-ICMP traffic is accepted, basically
turning the chain policy into ACCEPT, leaving the INPUT ruleset pretty
much identical to:
-m psd -j DROP
-f -j DROP
-i eth0 -m state --state INVALID -j DROP
-p icmp -m state --state INVALID -j DROP
-p tcp --sport 135:139 -j DROP
-p udp --sport 135:139 -j DROP
-p tcp --sport 445 -j DROP
-j ACCEPT
... so accepting most of all traffic, only blocking some select things.
This is the typical problem to making too selective matches in iptables
(or other firewalls as well): it makes unexpected holes.
Also, the 'RELATED,ESTABLISHED' rule will make the '--sport 53' ACCEPT
rule redundant. 'RELATED,ESTABLISHED' will allow all return packets
for currently known "sessions" to be passed. At netfileter level, "sessions"
also exist for datagram protocols like UDP (sending out a UDP packet will
open a "reverse channel" for a while (will accept packets originating from
the host and port that were marked as destination in the outgoing UDP packet).
Then after going through that tedious list of checks whether to allow or
deny, all packets from the loopback interface are allowed. This could
well be much earlier in the ruleset.
>$IPTABLES -A OUTPUT -p udp -d $GATEWAY --dport 53 -j ACCEPT
>$IPTABLES -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>$IPTABLES -A OUTPUT -p ! icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
>$IPTABLES -A OUTPUT -o lo -j ACCEPT
>$IPTABLES -P OUTPUT ACCEPT
As there are no DENY rules, it doesn't make sense to have any allow rules
here either. You're anyway accepting everything outbound.
>$IPTABLES -P FORWARD DROP
Ok, not forwarding. Might as well turn the IP forwarding support off in
the kernel, then.
Then to propose a fixed ruleset that should be closer to what you attempted:
>$IPTABLES -P FORWARD DROP
>$IPTABLES -P OUTPUT ACCEPT
>$IPTABLES -P INPUT DROP
>$IPTABLES -A INPUT -i lo -j ACCEPT
>$IPTABLES -A INPUT -m psd -j DROP
>$IPTABLES -A INPUT -m state --state INVALID -j DROP
>$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>$IPTABLES -A INPUT -p tcp --syn --match multiport --dports $LOCAL_SERVICES -j ACCEPT
Add the fragment-killing rule if you really wish, but I don't see the use
of it. Note, the ESTABLISHED,RELATED rule will allow some ICMP traffic
to your machine, as is necessary to carry the status information of
established TCP and/or UDP sessions. Inbound ICMP ehco (ping) is not
allowed by this ruleset. However, as you've opened two inbound service
ports, you might just as well allow inbound ping - the exitence of services
already gives out the fact that there's a live machine. What you might do
to the pings, though, is to rate-limit the traffic to conserve your uplink
bandwidth.
--
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)
- Next message: Cameron L. Spitzer: "Re: Getting Linux On CD"
- Previous message: Tim Haynes: "Re: iptables udp and output"
- In reply to: charly: "Re: iptables udp and output"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
