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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
