Re: Is this config OK, plus where should I be logging...

[Antony Stone <Antony@Soft-Solutions.co.uk>]

On Sunday 04 April 2004 7:41 pm, Stuart Lamble wrote:

> Hi
>
> Ok, here is an update...
> I have added the results of iptables-save as is, without hacking
> anything off. ;-)
> I have the firewall box that is running the following...
> mail server on port 25
> ssh server on port 22
> webmin running port 10000 over SSL 443
> web server on port 80

So, this thing is not a firewall, it's a general purpose server which happens 
to run some netfilter rules :)

(Yes, I disapprove of firewalls running network services... :)

By the way, what do you mean by "webmin running port 10000 over SSL 443"?

Is this thing listening on port 10000, or port 443?   Set up one rule to allow 
whichever type of packets you need, and remove the other rule.

> DNAT to another lan server running oracle web services on port 7783 =
> 7783 (from the web)
> DNAT to another lan server running ssh services on port 22 = 555 (from
> the web)
>
> My internal 192.168.100.0/255.255.255.0 is masqueraded for internet
> browsing and prity much everything else.
> The firewall itself needs to do DNS lookups, browse the net and send
> SMTP traffic.
>
> All that I require, stated above is working.

Okay, good.

> I want to know if the config is secure, where are the holes, what are
> the best practices.

Best practice item 1: don't run network services on your firewall :)

As I said in my earlier reply, I can't see why you have bothered to put OUTPUT 
ACCEPT rules in place, when you then put a default ACCEPT policy on the 
OUTPUT chain (and you have no DROP rules).   Absolutely everything is allowed 
out of this box, so why not make it obvious that that is the case, instead of 
making someone (perhaps you, in six months' time) think that the ACCEPT rules 
are there for a purpose and anything not specified will not be allowed?

Also, whilst we're talking about those rules, why have you used multiport, and 
then specified only a single port in each rule?

The simpler your rules are, the easier they are to understand.

The more compilcated you make them, the easier it is to make mistakes.

> Also, I want to log suspicious behaviour, port scans, what gets dropped
> etc.
> I am stuck with that ;-(

Put your LOGging rules at the end of FORWARD and INPUT, just before the 
default DROP policy takes effect.   At first you may as well just log 
everything with a simple rule "iptables -A INPUT -j LOG", and then once you 
get bored of seeing loads of packets addressed to port 135 on your firewall, 
you can DROP those before the LOG rule and start to narrow down what you log 
to only the stuff you find interesting.

> # Generated by iptables-save v1.2.7a on Sun Apr  4 22:25:58 2004
> *filter
>
> :INPUT DROP [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT DROP [0:0]
>
> -A INPUT -i lo -j ACCEPT
> -A INPUT -i eth1 -j ACCEPT
> -A INPUT -p icmp -j ACCEPT
> -A INPUT -p tcp -m tcp --sport 25 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 25 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 80 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 443 -j ACCEPT
> -A INPUT -i ppp0 -p tcp -m tcp --dport 10000 -j ACCEPT
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A FORWARD -s 192.168.100.0/255.255.255.0 -j ACCEPT

I still disapprove of the above rule.   It will allow packets from the 
Internet which have a source address matching your internal network to get 
through the firewall.   You should tighten it by adding the source interface 
eth1 as well:

iptables -A FORWARD -s 192.168.100.0/24 -i eth1 -j ACCEPT

> -A FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 22 -j ACCEPT
> -A FORWARD -d 192.168.100.6 -p tcp -m tcp --dport 7783 -j ACCEPT
> -A OUTPUT -s 127.0.0.1 -j ACCEPT
> -A OUTPUT -o eth1 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --sport 80 -j ACCEPT

You still have INPUT rules for ports 80 and 443, but a OUTPUT rule only for 
port 80 (as well as a default ACCEPT policy which will allow the 443 packets 
as well as any others).   This inconsistency doesn't look good.

> -A OUTPUT -p tcp -m tcp --sport 25 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --sport 22 -j ACCEPT
> -A OUTPUT -o ppp0 -p udp -m udp -m multiport --ports domain -j ACCEPT
> -A OUTPUT -o ppp0 -p tcp -m tcp -m multiport --ports http -j ACCEPT
> -A OUTPUT -o ppp0 -p tcp -m tcp -m multiport --ports smtp -j ACCEPT
> -A OUTPUT -o ppp0 -p tcp -m tcp -m multiport --ports ndmp -j ACCEPT
> COMMIT
> # Completed on Sun Apr  4 22:25:58 2004

Personally I would prefer to see:

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT ......... -j ACCEPT
  .... for each type of traffic you want to allow in to the "firewall"
iptables -A OUTPUT ........ -j ACCEPT
  .... for each type of traffic you want to allow out
iptables -A FORWARD ........ -j ACCEPT
  .... for each type of traffic you want to allow through.

By using the ESTABLISHED,RELATED rules more effectively, you can focus only on 
the destination ports in all three chains, and not need to have matching 
rules in INPUT and OUTPUT, with source ports in one and destination ports in 
the other, as you have done.

Hope this helps,

Regards,

Antony.

-- 
One good tern deserves another.

                                                     Please reply to the list;
                                                           please don't CC me.