Re: Iptables example for mail/web/opevpn server

On Thu, 2012-02-16 at 21:19 +0100, Pascal Hambourg wrote:
> Raven a écrit :
> >
> > I probably should have mentioned this earlier, but my predecessor left
> > me with a firewall script that, when launched, locks me out of the
> > server.
> > It seems all kosher to me, so I wonder why it's behaving like that:
>
> IMO it contains a number of inconsistencies and redundances.
>

Pascal, thank you for your exhaustive review.
As I previously said, I "inherited" this firewall script from the IT guy
that came before me.
I'm trying to make it work and at the same time learn some iptables
basics..

> > #!/bin/sh
> > IPT="/sbin/iptables"
> > # Internet Interface
> > INET_IFACE="venet0"
> > INET_ADDRESS="xxx.xxx.xxx.xxx"
> > # OpenVPN
> > OV="172.16.0.0/16"
> >
> > # Localhost Interface
> > LO_IFACE="lo"
> > LO_IP="127.0.0.1"
> >
> > echo "Flushing Tables ..."
> >
> > # Reset Default Policies
> > $IPT -P INPUT ACCEPT
> > $IPT -P FORWARD ACCEPT
> > $IPT -P OUTPUT ACCEPT
>
> Why set the defaut policies to ACCEPT if you set them to DROP a few
> lines later ?
>

I was wondering the same thing..

> > $IPT -t nat -P PREROUTING ACCEPT
> > $IPT -t nat -P POSTROUTING ACCEPT
> > $IPT -t nat -P OUTPUT ACCEPT
> > $IPT -t mangle -P PREROUTING ACCEPT
> > $IPT -t mangle -P OUTPUT ACCEPT
>
> Either the script is very old, or the author was not aware that the
> mangle table has had three extra chains (INPUT, FORWARD, POSTROUTING)
> for a very long time now.

Given that it is a standalone server, do I really need nat and mangle
tables?

> > # Flush all rules
> > $IPT -F
> > $IPT -t nat -F
> > $IPT -t mangle -F
> >
> > # Erase all non-default chains
> > $IPT -X
> > $IPT -t nat -X
> > $IPT -t mangle -X
> >
> > #Set Policies
> >
> > $IPT -P INPUT DROP
> > $IPT -P OUTPUT DROP
> > $IPT -P FORWARD DROP
> >
> > # unlimited access to VPN
> > iptables -A INPUT -s $OV -j ACCEPT
> > iptables -A OUTPUT -s $OV -j ACCEPT
>
>
> > # Munin accounting stuff
> > /sbin/iptables -A INPUT -d $INET_ADDRESS
> > /sbin/iptables -A OUTPUT -s $INET_ADDRESS
>
> If the address is correct, these two rules set the host wide open
> inbound and outbound, so I do not see how the ruleset could possibly
> "lock you out".

AFAIK, this is a "dummy" ruleset to be used by a Munin plugin (the
monitoring tool we use).
Since the "open doors" is at the beginning of the script, doesn't it get
restricted later on?

>
> > /sbin/iptables -A INPUT -d 172.16.0.1
> > /sbin/iptables -A OUTPUT -s 172.16.0.1
>
> Mixing $IPT, iptables and /sbin/iptables is not very consistent.
>
> [...]
> > $IPT -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP
> > $IPT -A bad_tcp_packets -p tcp --tcp-flags ALL NONE -j DROP
> > $IPT -A bad_tcp_packets -p tcp --tcp-flags ALL ALL -j DROP
> > $IPT -A bad_tcp_packets -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
> > $IPT -A bad_tcp_packets -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG
> > \ -j DROP
> > $IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
> > $IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
>
> This is not really needed any more. The current Linux IP stack handles
> these patterns which are *not* all invalid (the TCP specification sets
> priorities among flags, so multiple conflicting flags may be present).
> It may be useful only on a firewall to protect vulnerable hosts.
>

Agreed.

> > #Time Exceeded
> > $IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT
>
> Valid ICMP time exceeded, along with other ICMP error types, are in the
> RELATED state, so this rule is not necessary.
>
> [...]
> > #NTP Server
> > $IPT -A udp_inbound -p UDP -s 0/0 --destination-port 123 -j ACCEPT
>
> You didn't mention that the host was an NTP server.

Indeed. It shouldn't be

>
> [...]
> > # FTP Client (Data Port for non-PASV transfers)
> > $IPT -A tcp_inbound -p TCP -s 0/0 --source-port 20 -j ACCEPT
>
> Don't do this. It accept anything from anyone using source port 20.

I was wondering: do I really need all this mumbo jumbo with packet
states and separate UDP/TCP chains?
I mean, won't the firewall be enough if I close it all down inbound on
the public IP and open ports on a need-to basis? (obviously lo and vpn
would have total IN/OUT access)

-RV

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1329428372.7003.37.camel@osmosis.gnet.eu