Re: iptables udp and output

From: Juha Laiho (Juha.Laiho_at_iki.fi)
Date: 01/15/04


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)


Relevant Pages

  • Google Summer of Code 2009: Student applies to create a Better IPTables Management Tool
    ... a student) and select the Linux Foundation ... The tool focuses on helping the user to perceive what a particular chains of rules in a particular table does to a user specified packet. ... As the project aims for better IPtables management tool, I can contribute with my hard earned 3 years experience in maintenance of firewalls. ... The tools helps the user to either select all the rules in the chain or some particular rules and tells the impact of the application of selected rules upon the incoming/outgoing packet. ...
    (Linux-Kernel)
  • RE: FW1 External Ruleset validation tools?
    ... FW1 External Ruleset validation tools? ... > What is the easiest way to find out what rule line the supposed packet ... in error, please contact us immediately at 816.421.6611, and delete the communication from any computer or network system. ... technology powered by the award-winning FoundScan engine. ...
    (Pen-Test)
  • Re: possible problem with scp/ssh/telnet
    ... packet to the corresponding service. ... The next line in your iptables file is your "ACCEPT" rule for connections to ... I would still expect a failure in tcp to show up in the log if they are not accepted in the tcp line as everything that isn't an accept should continue being processed until the log and reject? ... do I gather from this that iptables is accepting the tcp request and the problem is happening at sshd? ...
    (Fedora)
  • Re: Doubts with iptables (or ipchains)
    ... With iptables use the state module. ... > done with ipchains (using some alternative ... > of the connection would protect my LAN? ... Why would 'a packet' be 52 bytes? ...
    (comp.os.linux.security)
  • iptables: state & forward confusion
    ... $iptables -F -t mangle ... # set a default policy to allow established & related ... packet forwarded to eth1 or eth2...accept those that are explicitly ... forwarded say for outbound web requests and returning responses? ...
    (comp.os.linux.security)