Re: Iptables example for mail/web/opevpn server

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.

> #!/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 ?

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

> # 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".

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

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

[...]
> # 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.

--
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/4F3D64D2.50401@plouf.fr.eu.org