Re: Babysitting on iptables requested :-)

From: Juha Laiho (Juha.Laiho@iki.fi)
Date: 04/24/03 

From: Juha Laiho <Juha.Laiho@iki.fi>
Date: Thu, 24 Apr 2003 17:17:01 GMT

peetgr@absa.co.za (Peet Grobler) said:
>On Wed, 23 Apr 2003 17:30:01 -0400, Carlos Moreno
><moreno_at_mochima_dot_com@xx.xxx> wrote:
>>Shields Up reports my machine 100% stealth, and I do have the
>>usual functionality (i.e., I can do whatever I want from my LAN).

Actually Shields Up isn't testing that thoroughly..

>>So, that seems like good news, but I was wondering if I might
>>be doing something the wrong way, or if there may be holes that
>>Shields Up is not seeing/reporting. Any comments on the following
>>script will be appreciated:

>>iptables -P INPUT DROP
>>iptables -P OUTPUT ACCEPT
>>
>> # A policy of ACCEPT worries me... But I guess it can't be that
>> # harmful if it is in the OUTPUT chain?
>
>Not harmful at all. Unless you want to restrict output from your
>machine to the internet?

There might be set-ups where you want to restrict even the outgoing
traffic. But it requires some monitoring to find out what all
outbound traffic is needed (I'm maintaining some systems where I
want to be absolutely certain about what kind of traffic can go
out of the host, so the first level is restricting the outgoing
traffic on the host itself, and the next level is the firewall
external to the machine).

>>iptables -P FORWARD DROP
>>
>>iptables -A INPUT -i eth1 -j ACCEPT
>>iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>>
>> # Now that I think about it, I guess I should also add a rule
>> # to accept anything that comes through the lo interface??
>> # i.e., iptables -A INPUT -i lo -j ACCEPT ??
>
>Yes, you should. Unless you want to drop all localhost traffic. Add a
>similar OUTPUT rule as well.

I think the '-o lo' is redundant; if it is going to 'lo', it had to
come from 'lo'. But the '-i lo -j ACCEPT' is needed. I also seem to
have "-m state --state INVALID -j DROP" always just before the
"-m state --state ESTABLISHED,RELATED -j ACCEPT".

>>iptables -A INPUT -p tcp --dport 22 -j ACCEPT
>>iptables -A INPUT -p tcp --dport 10112:10115 -j ACCEPT
>>
>> # Ports 10112 to 10115 are used by a custom application that I
>> # developed, and I often use my home machine for debugging tests.
>
>You should specify it like this:
>iptables -A INPUT -p tcp -i eth0 --dport 22 -j ACCEPT
>iptables -A INPUT -p tcp -i eth0 --dport 10112:10115 -j ACCEPT
>
>e.g. add the source interface aswell. Makes it simpler to manage.

If I read his set-up correctly, the interface is redundant here;
everything else but eth0 is already handled. However, what is missing
is that here you should only accept SYN packets, i.e. "--syn" should
be added to flags. This is to prevent some forms of not-so-visible
scanning.

>>iptables -A FORWARD -i eth1 -j ACCEPT

This depends on what kind of machines you have in your local LAN, but
if there's anything from Microsoft, you might like to block anything
that is destined to port range 137-139, tcp as well as udp, incoming
as well as outgoing. These ports are used for authentication services
between Windows machines, so without this a Windows machine in your
internal network might leak sensitive data to outside your network.
However, this also prevents the Windows file/printer sharing protocols
across your firewall machine, so if this is something you're depending
on, you'll have to reconsider.

>>iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
>>iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>>
>>iptables -t nat -A PREROUTING -p tcp --dport 1234 -j REDIRECT --to-ports 80
>>
>> # My ISP blocks incoming packets to port 80, so I want to be able to
>> # use my own machine as a web server
>>
>>iptables -A INPUT -p tcp --dport 80 -j ACCEPT
>
>Add the -i eth0 as well.
>
>>
>> # This one seemed necessary, or apache would not respond (is there
>> # a way to set it up such that it would accept it, but only if it
>> # came through port 1234, and not if it came directly to port 80?)
>
>Dunno. Probably.

Haven't tried this, but would it work to drop or reject packets destined
to port 80 in nat PREROUTING table before you do the redirect?

>>Thanks for any comments!! I know there are aesthetic flaws,
>>but I'm mainly worried about possible red flags that I might be
>>overlooking due to my lack of knowledge on this.

No major problems; my suggestions can be considered to be fine-tuning.

>I would, however, add rules at the bottom to '-j LOG' everything else.
>Just so you know you're dropping traffic.

Agreed, but this needs to be divided in two: things that you just drop,
and things that you log before dropping. If you log everything, you'll
drown in log files.

Here's a rule sturcture I've developed along the time; this is in
"iptables-save" -syntax, but should be readable without too much
problems.

I'll skip mangle and nat tables; nothing special in them.

In filter table, the INPUT ruleset (policy DROP);
the "common" table I discuss later.

###
#
# Incoming:
#
# Sanity check; allow return packets
-A INPUT -j common
# Allow ICMP echo (ping) requests
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
#
# Specify here the accepted incoming sessions; example: allow ssh in
# -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
#
# Specify here the incoming requests you want to actively reject
# and not log (f.ex. ident queries from upstream SMTP servers)
# -A INPUT -p tcp -m tcp --dport 113 --tcp-flags SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable
# Log&drop all the rest
-A INPUT -j LOG --log-prefix "Forbidden incoming session: "
#
# Specify here the incoming requests you want to actively reject
# after they've been logged
#
###

In filter table, the OUTPUT ruleset (policy DROP);

###
#
# Outgoing:
#
# Sanity check; allow return packets
-A OUTPUT -j common
# Accept ICMP echo (ping) requests
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
#
# Specify here the accepted outgoing sessions; example: allow pop3 out
# -A OUTPUT -d my-pop-serv-ip -p tcp -m tcp --dport 110 -j ACCEPT
# Allow DNS out; fill in the provider DNS serv ip
-A OUTPUT -d my-dns-serv-ip -p tcp -m tcp --dport 53 -j ACCEPT
-A OUTPUT -d my-dns-serv-ip -p udp -m udp --dport 53 -j ACCEPT
#
# Log all the rest
#
-A OUTPUT -j LOG --log-prefix "Forbidden outbound session: "
#
# Actively reject all the rest
# (no "DROP" here; it'd just cause a delay; REJECT terminates the
# session immediately)
#
-A OUTPUT -p tcp -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -p udp -j REJECT --reject-with icmp-port-unreachable
#
###

The "common" chain then (can't have a policy, as it is a user-defined chain;
this returns control back to the calling chain if none of the rules matched):

###
#
# Common: rules common for both incoming and outgoing sessions;
# - acceptance of return packets for allowed sessions
# - dropping of packets in nonsense session states
# - acceptance of all localhost traffic
-A common -m state --state RELATED,ESTABLISHED -j ACCEPT
-A common -p tcp -m state --state NEW -m tcp ! --tcp-flags SYN,RST,ACK SYN -j LOG --log-prefix "New not SYN: "
-A common -p tcp -m state --state NEW -m tcp ! --tcp-flags SYN,RST,ACK SYN -j DROP
-A common -m state --state INVALID -j LOG --log-prefix "Invalid state: "
-A common -m state --state INVALID -j DROP
-A common -i lo -j ACCEPT
# If needed, this would be good place to accept also interface traffic
# to/from local network adapters.
-A common -j RETURN
#
###

Here I've allowed ICMP ECHO (ping) packets in both directions; it might
be good idea to rate-limit these (at least incoming). Other needed ICMP
protocols are already accepted with the 'RELATED,ESTABLISHED' rule. Ping
is good to have allowed for connectivity troubleshooting purposes - it
confuses the hell out of people if they can't ping but still can connect.

On some hosts I've done things like splitting the INPUT chain to several
sub-chains, most often by protocol (tcp, udp, icmp), but anyway the
basic order is that first accept what you want to accept; then reject or
drop unwanted traffic that you know you don't want to see in your logs;
then log what is left and leave the packets to the "DROP" policy - or
reject them - whatever you wish.

The sub-chains for processing packets per protocol could improve
efficiency (you're not going through piles of TCP rules when handling
an UDP packet; instead you check once in INPUT against the protocol,
and just don't branch to the chain containing all the TCP rules). For
me the main reason has been safety: when I set up such a system, 'ssh'
is allowed (from some known addresses) somewhere before the actual
per-protocol sub-chains. All further changes I do happen within these
sub-chains, but regardless of how badly I mangle them, I always keep my
ssh connection.

As for improving efficiency, this design doesn't leave much room for
optimization; for each connection only one packet (the one initiating
the connection) goes somewhere beyond the rules in the 'common' chain;
so most packets that you want to allow are allowed at second rule line
(the first being the branch to the "common" chain). 

-- 
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

  • Re: HTB + NAT on Debian (outgoing traffic shaping problems)
    ... > 192.168.0.0 subnet ... > incoming and outgoing traffic with possibility to borrow unused channel. ... get it's packets from its associated queue. ...
    (comp.os.linux.networking)
  • Re: looking for a free/low cost firewall with low system requirements
    ... that does more than just NAT and State on both incoming and outgoing ... Something that blocks all the usual malware holes. ...
    (alt.comp.hardware.pc-homebuilt)
  • Re: Over 2 billion packets sent, 27k received- virus???
    ... > I have reboot my machine and router, but after a while the outgoing ... packets are very high while the incoming are reasonable. ... Outgoing mail is certified Virus Free. ...
    (microsoft.public.windowsxp.network_web)
  • Re: Boo - NetMeeting
    ... >> Did they jbex on incoming or outgoing calls? ... >> for both, but I 'think' from what I saw today, that incoming may ... Incoming Calls definitely do work differently (through a Router) ... Which is why the Router has to be Set to Forward the Packets to ...
    (uk.people.silversurfers)
  • Re: major problem with mail
    ... >I have set up an IPTABLES rule set that I converted from ... -A OUTPUT -j common ... # Specify here the accepted outgoing sessions; ...
    (comp.os.linux.security)