Iptables Firewall
Source: tty1.netthere
This page presents a simple firewall script. It is probably not the best of all possible firewalls, nor the most secure, but may be a starting point for your experiments. Please send any comments and suggestions to <tehpeh-web@tty1.net>.
Update 2011-05-28: IPv6 script
Please see the page for a newer firewall script with IPv6 support.
Turning on native Kernel IPv4 protection
The Linux kernel provides some basic protections against manipulated IP packets. A configuration could be:
echo 1 > /proc/sys/net/ipv4/tcp_syncookies # enable syn cookies (prevent against the common 'syn flood attack') echo 0 > /proc/sys/net/ipv4/ip_forward # disable Packet forwarning between interfaces echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # ignore all ICMP ECHO and TIMESTAMP requests sent to it via broadcast/multicast echo 1 > /proc/sys/net/ipv4/conf/all/log_martians # log packets with impossible addresses to kernel log echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # disable logging of bogus responses to broadcast frames echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter # do source validation by reversed path (Recommended option for single homed hosts) echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects # don't send redirects echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route # don't accept packets with SRR option
Further reading:
- The file Documentation/networking/ip-sysctl.txt in your kernel source directory
- Network Security with /proc/sys/net/ipv4
Limit ping responses
Any iptables rule can be tuned to respond only to a limited number of times per time unit by using the limit module. This can be extremely useful for log entries (A ping flooding will not lock down your computer by writing to log files). I will show an example on how to limit on ICMP responses. This is not really useful, because it imposes a maximum number of responses for ALL source IP addresses, but it may help to reduce network traffic on brute force attacks (and reduce volume in the log file).
iptables -A INPUT -p icmp -m limit --limit 10/second -j ACCEPT iptables -A INPUT -p icmp -j DROP
This will limit the ICMP responses to a maximum of 10 replies per second. All the rest is silently dropped. Beware: dropping ICMP responses may slow down or cut off legitimate users (for example when ICMP « Fragmentation Needed » packets are dropped).
Dealing with brute force ssh attacks
A stateful firewall can make brute force ssh scans more painful to the attacker by slowing down the responses. I will present a simple teergrubing strategy against ssh scans. This method relies on the IPTables/Netfilter Recent Module, written by Snow-man. The idea is simple: permit only a limited number of new connections per source IP address; drop any further connection attempt for a while.
iptables -A INPUT -p tcp --dport 22 -m recent --rcheck --seconds 60 --hitcount 2 --name SSH -j LOG --log-prefix "SH " iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 2 --name SSH -j DROP iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT iptables -A INPUT -i $int_if -m state --state ESTABLISHED,RELATED -j ACCEPT
Line 1 of the script checks if the source IP has already marked as ‘Bad Guy’ and logs the packet, if so. The second line drops the packet if it comes from a marked IP address and marks the source again. This ensures that the source will stay blacklisted as long as the attack continues. The third line marks the source IP as ‘Bad Guy’ if there are more than 2 connection attempts per minute. Note that already established connections continue to work (because the packets will no more arriving on 22).
Further reading:
- IPTables/Netfilter Recent Module
- Securing Debian Manual
- Defending against brute force ssh attacks
