A secure, standard iptables rule-set for a basic HTTP(s) webserver
Solution 1:
The most secure way to work with iptables is close everything and only open what you need. I'm kind of distracted, so I always try to be as lazy as possible, so I do not make mistakes which can lead the server to be unsecure.
I use this one, only a little bit of varible assignment must be done in order to make it work.
#!/bin/bash +x
# first author: marcos de vera
# second: joan marc riera
ip=/sbin/iptables
mriera="xx.xx.xx.xx"
nsancho="yy.yy.yy.yy"
admins="$mriera $nsancho "
sshers=""
mysqlrs="zz.zz.zz.zz/23"
snmprs="uu.uu.uu.uu"
tcpservices="80 443 22"
udpservices=""
# Firewall script for servername
echo -n ">> Applying iptables rules... "
## flushing...
$ip -F
$ip -X
$ip -Z
$ip -t nat -F
# default: DROP!
$ip -P INPUT DROP
$ip -P OUTPUT DROP
$ip -P FORWARD DROP
# filtering...
# localhost: free pass!
$ip -A INPUT -i lo -j ACCEPT
$ip -A OUTPUT -o lo -j ACCEPT
# administration ips: free pass!
for admin in $admins ; do
$ip -A INPUT -s $admin -j ACCEPT
$ip -A OUTPUT -d $admin -j ACCEPT
done
# allow ssh access to sshers
for ssher in $sshers ; do
$ip -A INPUT -s $ssher -p tcp -m tcp --dport 22 -j ACCEPT
$ip -A OUTPUT -d $ssher -p tcp -m tcp --sport 22 -j ACCEPT
done
# allow access to mysql port to iReport on sugar
for mysql in $mysqlrs ; do
$ip -A INPUT -s $mysql -p tcp -m tcp --dport 3306 -j ACCEPT
$ip -A OUTPUT -d $mysql -p tcp -m tcp --sport 3306 -j ACCEPT
$ip -A INPUT -s $mysql -p udp -m udp --dport 3306 -j ACCEPT
$ip -A OUTPUT -d $mysql -p udp -m udp --sport 3306 -j ACCEPT
done
# allowed services
for service in $tcpservices ; do
$ip -A INPUT -p tcp -m tcp --dport $service -j ACCEPT
$ip -A OUTPUT -p tcp -m tcp --sport $service -m state --state RELATED,ESTABLISHED -j ACCEPT
done
for service in $udpservices ; do
$ip -A INPUT -p udp -m udp --dport $service -j ACCEPT
$ip -A OUTPUT -p udp -m udp --sport $service -m state --state RELATED,ESTABLISHED -j ACCEPT
done
$ip -A INPUT -j LOG --log-level 4
# VAS and VGP
#88 tcp udp
#389 tcp ldap queries , udp ldap ping
#464 tcp upd kerberos
#3268 tcp global catalog access
for dc in ip.ip.ip.ip ; do # our dc servers for some ldap auth
vas=88
$ip -A INPUT -s $dc -p tcp -m tcp --dport $vas -j ACCEPT
$ip -A OUTPUT -d $dc -p tcp -m tcp --dport $vas -j ACCEPT
$ip -A INPUT -s $dc -p udp -m udp --dport $vas -j ACCEPT
$ip -A OUTPUT -d $dc -p udp -m udp --dport $vas -j ACCEPT
ldap=389
$ip -A INPUT -s $dc -p tcp -m tcp --dport $ldap -j ACCEPT
$ip -A OUTPUT -d $dc -p tcp -m tcp --dport $ldap -j ACCEPT
$ip -A INPUT -s $dc -p udp -m udp --dport $ldap -j ACCEPT
$ip -A OUTPUT -d $dc -p udp -m udp --dport $ldap -j ACCEPT
kpasswd=464
$ip -A INPUT -s $dc -p tcp -m tcp --dport $kpasswd -j ACCEPT
$ip -A OUTPUT -d $dc -p tcp -m tcp --dport $kpasswd -j ACCEPT
$ip -A INPUT -s $dc -p udp -m udp --dport $kpasswd -j ACCEPT
$ip -A OUTPUT -d $dc -p udp -m udp --dport $kpasswd -j ACCEPT
gca=3268
$ip -A INPUT -s $dc -p tcp -m tcp --dport $gca -j ACCEPT
$ip -A OUTPUT -d $dc -p tcp -m tcp --dport $gca -j ACCEPT
vgp=445
$ip -A INPUT -s $dc -p tcp -m tcp --dport $vgp -j ACCEPT
$ip -A OUTPUT -d $dc -p tcp -m tcp --dport $vgp -j ACCEPT
done
# allow the machine to browse the internet
$ip -A INPUT -p tcp -m tcp --sport 80 -m state --state RELATED,ESTABLISHED -j ACCEPT
$ip -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
$ip -A INPUT -p tcp -m tcp --sport 443 -m state --state RELATED,ESTABLISHED -j ACCEPT
$ip -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
$ip -A INPUT -p tcp -m tcp --sport 8080 -m state --state RELATED,ESTABLISHED -j ACCEPT
$ip -A OUTPUT -p tcp -m tcp --dport 8080 -j ACCEPT
# don't forget the dns...
$ip -A INPUT -p udp -m udp --sport 53 -j ACCEPT
$ip -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
$ip -A INPUT -p tcp -m tcp --sport 53 -j ACCEPT
$ip -A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT
# ... neither the ntp... (hora.rediris.es)
#$ip -A INPUT -s 130.206.3.166 -p udp -m udp --dport 123 -j ACCEPT
#$ip -A OUTPUT -d 130.206.3.166 -p udp -m udp --sport 123 -j ACCEPT
$ip -A INPUT -p udp -m udp --dport 123 -j ACCEPT
$ip -A OUTPUT -p udp -m udp --sport 123 -j ACCEPT
# and last but not least, the snmp access
for monitor in $snmprs ; do
$ip -A INPUT -s $monitor -p tcp -m tcp --sport 161 -j ACCEPT # monitoring service
$ip -A OUTPUT -d $monitor -p tcp -m tcp --dport 161 -j ACCEPT # monitoring service
end
# outgoing SMTP
$ip -A INPUT -p tcp -m tcp --sport 25 -j ACCEPT
$ip -A OUTPUT -p tcp -m tcp --dport 25 -j ACCEPT
# temporary backup if we change from DROP to ACCEPT policies
$ip -A INPUT -p tcp -m tcp --dport 1:1024 -j DROP
$ip -A INPUT -p udp -m udp --dport 1:1024 -j DROP
echo "OK. Check rules with iptables -L -n"
# end :)
I've been using it for some time , and any kind of modification will be very appreciated if it makes it easier to administrate.
Solution 2:
This looks pretty good, but you could tighten things down a little bit more. The -s flag is the source IP or domain name, and you add "-s 198.23.12.32" or whatever your IP address is to only allow SSH from your source IP. You can also choose a range of source IPs by using CIDR style notation.
You should use caution when logging denied calls. Your server's IP address will get scanned by bots, script kiddies, etc, and the log file could get large rather quickly. Unless you're trying to diagnose a specific problem that you think might be related to someone trying to break your firewall, I would remove this option.
You could also tie in fail2ban to iptables for a pseudo-IDS. fail2ban will scan your log files and can block an IP if they attempt to force their way into your system. For example, if a certain IP address fails to login to SSH 5 times, you can lock them out for an entire day. It also works on FTP and lots of others (including bad bots hitting Apache).I use it on all of my servers to provide some extra cushion from brute-force attacks.
Solution 3:
I would say this is a pretty good firewall, except that it is geared towards stopping inbound traffic, and not focused on egress or outbound traffic. It is in many cases just as important to focus on connections outbound from a box as those inbound. In the unfortunate case that the machine is actually exploited, it would be nice to be able to prevent downloading additional root kits, or connecting to command and control nodes, or whatever.
BillThor started talking about this above, but I'm just answering with specific examples. One of the nice things about iptables is that it can remember connection state, this can have performance implications on heavily trafficked sites but you could change your inbound access on http/https to only allow reply on established connections for example, or specifically limit certain unprivileged users from having outbound access at all. Then your outbound rules would have RELATED,ESTABLISHED clauses which would prevent a whole host of ancillary attacks and slow down the ones that require a secondary stage to actually exploit a box, which is very common.
Finally, I would say that it is better to set your iptables policy -P DROP rather than have an appended REJECT at the end. It is mostly a matter of preference, but can reduce mistakes when appending to chains with existing rules instead of inserting or flushing/resetting.