Tips for a secure iptables config to defend from attacks. (client side!)

Question

Own examples:

###############
# KERNEL PARAMETER CONFIGURATION

# PREVENT YOU SYSTEM FROM ANSWERING ICMP ECHO REQUESTS
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

# DROP ICMP ECHO-REQUEST MESSAGES SENT TO BROADCAST OR MULTICAST ADDRESSES
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# DONT ACCEPT ICMP REDIRECT MESSAGES
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

# DONT SEND ICMP REDIRECT MESSAGES
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

# DROP SOURCE ROUTED PACKETS
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

# ENABLE TCP SYN COOKIE PROTECTION FROM SYN FLOODS
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# ENABLE SOURCE ADDRESS SPOOFING PROTECTION
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

# LOG PACKETS WITH IMPOSSIBLE ADDRESSES (DUE TO WRONG ROUTES) ON YOUR NETWORK
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

# DISABLE IPV4 FORWARDING
echo 0 > /proc/sys/net/ipv4/ip_forward

###############
# INPUT

# DROP INVALID
$IPTABLES -A INPUT -m state --state INVALID -j DROP

# ALLOW ONLY ESTABLISHED, RELATED
$IPTABLES -A INPUT -p tcp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -p udp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT

# DROP INVALID SYN PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

# MAKE SURE NEW INCOMING TCP CONNECTIONS ARE SYN PACKETS; OTHERWISE WE NEED TO DROP THEM 
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# DROP PACKETS WITH INCOMING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS
$IPTABLES -A INPUT -f -j DROP

# DROP INCOMING MALFORMED XMAS PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j DROP

# DROP INCOMING MALFORMED NULL PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

###############
# OUTPUT

# DROP INVALID
$IPTABLES -A OUTPUT -m state --state INVALID -j DROP

# DROP INVALID SYN PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP
$IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

# MAKE SURE NEW OUTGOING TCP CONNECTIONS ARE SYN PACKETS; OTHERWISE WE NEED TO DROP THEM 
$IPTABLES -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP

# DROP PACKETS WITH OUTGOING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS
$IPTABLES -A OUTPUT -f -j DROP

# DROP OUTGOING MALFORMED XMAS PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ALL -j DROP

# DROP OUTGOING MALFORMED NULL PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL NONE -j DROP

Can we gather more great iptables related ideas to protect clients from attacks? E.g.: an Ubuntu 11.04 Desktop PC's "defend from attacks" ~kind rules.

Thank you!

p.s.: of course:

$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

p.s.2: both on IPv4 and IPv6!

p.s.3: I don't need rules like: only allow UDP and TCP on port 53 outbound, I just want "defending" rules from e.g.: portscanning, attacks, etc.

p.s.4: The PC is behind a router/NAT or connected "directly to the internet".

Answer 1

I realize there are different opinions, but one major attitude of people who really know about networking and security is that most of these iptables/sysctl rules are redundant, if not damaging to you and the network. Some will aggressively criticize you for breaking with standard behavior without reason. Some examples:

• The standard TCP/IP behavior is to REJECT so that the peer gets some hint on what is going on. Maybe someone just typed a URL wrong or your admin is counting the hosts or somebody wants to connect to your gaming server but typed the wrong port. With DROP they only get obscure and annoying timeouts.

• There is no need to drop invalid or malformed packets, all of these attacks are a decade old. The Linux kernel devs are much more up to date than you concerning which kind of packets are valid and which not. "What about future flaws", some might argue. Well, how do you know the future flaw will be in the TCP handler and not in the iptables TCP parser?

• Most of the sysctl settings are default. If they are not, there is usually a reason. Eg, why disable sending redirects? I find it very useful to be informed by a peer that my routing is bad, even if I would never react("accept_redirects", default=0) automatically.

• With your log_martians and other logging rules I hope you also have a quota on /var/log, or it will be big fun to remotely fill your disk, usually killing your services/apps. In addition, you should use a rate limit for the logging or someone might fill the quota to prevent you from seeing the SSH password bruteforce attempts in auth.log, or other stuff. Are you actually reading those logs on a desktop? I recommend logcheck.

• You appear to block ICMP. Apart from the mentioned DHCP issue, this also prevents PMTU discovery. Without PMTUD, you will get strange behavior when you use the system in places with DSL connection or other network settings. Some packets will just be dropped and nobody tells you why.

• Filtering outbound packets is kind of obscure. Do you not trust yourself? You should generally not run any programs you cannot trust. Commodity operating systems are mostly incapable of isolating these programs from eavesdropping or even manipulating other program's data (e.g., cache timing attacks)

• You require NEW packets to have SYN. This will break if a TCP connection is continued after the respective state in iptables already timed out. Not sure what the default timeouts are, but some netfilter guy warned about it.

So, when should a desktop have a firewall?

• If there is a specific attack in the news that your current OS or servers are vulnerable to, and one of the recommended quick fixes is a firewall rule.

• You have to run certain services that do not allow secure configuration. Most do, and the rest is best replaced by secure alternatives.

• You have more complex networks with several VMs and/or interfaces on your desktop.

The first and foremost tool for your network security is the system update. Secondly, there is netstat and nmap, which you should use to find and confirm what services you are running. Then just disable those you don't need or confine them to 127.0.0.1.

Bonus if you read this far: Packets are either ESTABLISHED,RELATED or NEW, everything else you drop. You also drop NEW unless only SYN is set. Since ESTABLISHED,RELATED seems to check flags, this makes all of the --tcp-flags rules and also the -f rule redundant. Same for OUTPUT, but since no packets are ACCEPTed for OUTPUT anyhow, that probably doesn't matter.

Answer 2

I would be careful in making these part of the same ruleset for devices inside a trusted network and those in a DMZ. By using the rules you've got defined there, you're not going to respond to a DHCP server asking (ICMP echo) if your IP is in use. This could lead to a duplicate address situation.

I would create two different sets of rules to apply to each scenario, something like what's listed above is a good baseline for a DMZ machine, but creates some challenges on a typical LAN.

Also I would definitely recommend adding logging to martians, outbound drops, inbound dropped connections etc. This can be crucial for troubleshooting and can be more useful data for your SIEM to eat.

Answer 3

For a client PC, connected directly to the internet via ppp, the following ruleset is a good start:

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -j REJECT
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
ip6tables -A INPUT -j REJECT

1. It allows everything on the internal local interface.
2. It allows any packet that is an answer for a packet you send out. This includes packets within an TCP connection, answers to UDP packets such as small DNS queries. For the old style unencrypted FTP protocol, this includes the data connection, assuming the ip_conntrack_ftp is loaded
3. Reject all tries to open a tcp connection from the outside
4. Reject all initial (non answer) udp packets.

Alternatively you can use -j DROP in the last two rules. For a discussion on this topic see Reject IP packets with an ICMP error, or just drop them?

Answer 4

So to elaborate on your question here's what I've been running (and I'll use your examples with notes, since mine are pretty much devoid of comments having been carried on to net fliter since IPCHAINS died all those years ago.)

This could work for an internal system, but you'll often spend time configuring your iptables for new applications not taken into account. I also removed my SSH rule, but that's a pretty standard one you'll see (and in many configs the only one you'll see to allow input.)

###############
# VARIABLE DEFINITIONS
IPTABLES=/sbin/iptables

#Your DHCP Server for input of ICMP packets
DHCPSERVER=127.0.0.1
PUBIF=eth0

# KERNEL PARAMETER CONFIGURATION
#
# DROP ICMP ECHO-REQUEST MESSAGES SENT TO BROADCAST OR MULTICAST ADDRESSES
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
#
# DONT ACCEPT ICMP REDIRECT MESSAGES
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
#
# DONT SEND ICMP REDIRECT MESSAGES
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
#
# DROP SOURCE ROUTED PACKETS
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
#
# ENABLE TCP SYN COOKIE PROTECTION FROM SYN FLOODS
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
#
# ENABLE SOURCE ADDRESS SPOOFING PROTECTION
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

# LOG PACKETS WITH IMPOSSIBLE ADDRESSES (DUE TO WRONG ROUTES) ON YOUR NETWORK
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

# DISABLE IPV4 FORWARDING
echo 0 > /proc/sys/net/ipv4/ip_forward
###############
$IPTABLES -F
###############
# LOGDROPPER
$IPTABLES -N LOGNDROP > /dev/null 2> /dev/null 
$IPTABLES -F LOGNDROP 
$IPTABLES -A LOGNDROP -j LOG --log-prefix "LOGNDROP: " 
$IPTABLES -A LOGNDROP -j DROP

###############
# LO allowance
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT

###############
# Only bring what you need to survive
$IPTABLES -A INPUT -p icmp -s $DHCPSERVER -j ACCEPT
$IPTABLES -A INPUT -i $PUBIF -s $DHCPSERVER -p tcp --sport 68 --dport 67 -j ACCEPT
$IPTABLES -A INPUT -i $PUBIF -s $DHCPSERVER -p udp --sport 68 --dport 67 -j ACCEPT
###############
# INPUT
#
# DROP INVALID
$IPTABLES -A INPUT -m state --state INVALID -j LOGNDROP

# ALLOW ONLY ESTABLISHED, RELATED
$IPTABLES -A INPUT -p tcp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -p udp -i $PUBIF -m state --state ESTABLISHED,RELATED -j ACCEPT

# DROP INVALID SYN PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j LOGNDROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOGNDROP
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j LOGNDROP

# MAKE SURE NEW INCOMING TCP CONNECTIONS ARE SYN PACKETS; OTHERWISE WE NEED TO DROP THEM
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOGNDROP

# DROP PACKETS WITH INCOMING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS
$IPTABLES -A INPUT -f -j LOGNDROP

# DROP INCOMING MALFORMED XMAS PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL ALL -j LOGNDROP

# DROP INCOMING MALFORMED NULL PACKETS
$IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j LOGNDROP

###############
# OUTPUT

# DROP INVALID
$IPTABLES -A OUTPUT -m state --state INVALID -j LOGNDROP

# DROP INVALID SYN PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j LOGNDROP
$IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOGNDROP
$IPTABLES -A OUTPUT -p tcp --tcp-flags SYN,RST SYN,RST -j LOGNDROP

# DROP PACKETS WITH OUTGOING FRAGMENTS. THIS ATTACK RESULT INTO LINUX SERVER PANIC SUCH DATA LOSS
$IPTABLES -A OUTPUT -f -j LOGNDROP

# DROP OUTGOING MALFORMED XMAS PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL ALL -j LOGNDROP

# DROP OUTGOING MALFORMED NULL PACKETS
$IPTABLES -A OUTPUT -p tcp --tcp-flags ALL NONE -j LOGNDROP

$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -A INPUT -j LOGNDROP
$IPTABLES -A FORWARD -j LOGNDROP

If your network is noisy, or you have lots of stuff going on, this will fill up your log volume quickly. But I'm paranoid, and also bust people's chops if they're creating configs that are noisy unnecessarily.