Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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

share|improve this question
5  
Please describe the attacks you want to defend from. What are you seeing? –  user185 Jun 19 '11 at 12:47
    
Nobody has ideas? –  LanceBaynes Jun 21 '11 at 17:14
    
@Graham Lee: Attacks over networks, that can be avoided with iptables rules. –  LanceBaynes Jun 21 '11 at 17:15
    
@Graham Lee: slow down portscans, or detect them? –  LanceBaynes Jun 21 '11 at 17:16
2  
despite getting some excellent answers, this question, once again is not really on topic. Please read the FAQ, and the comments. The reason you aren't getting more answers is because your question doesn't have enough data. Every firewall rulebase is, and should be different, as everyone has different assets to protect from different threats. –  Rory Alsop Jun 23 '11 at 22:33

4 Answers 4

up vote 12 down vote accepted
+350

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.

share|improve this answer
    
Just to note, the rules are not redundant from a logging perspective. They (new not syn) will take hits in the case of some strange network behavior (split routing scenarios or attempted man in the middle comes to mind) it can and does happen that the rules get triggered, it's just not normal for it to be the case. –  Ori Jun 26 '11 at 9:07
    
Ack, but he is not logging :-) If you want to have some kind of warning system, I recommend installing a real IDS, not scripting your own. Though, I still prefer the minimalistic approach to simply use secure protocols/software in the first place :-) –  pepe Jun 28 '11 at 20:54

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?

share|improve this answer
    
You should add a catch-all REJECT at the end, I think. There are protocols that are neither tcp nor udp. Or, just delete -p udp from the last line of your ruleset. –  D.W. Jun 20 '11 at 3:51

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.

share|improve this answer

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.

share|improve this answer
1  
thanks for the comment, but as I said: this isn't my full iptables script, it's just the "defending" from attacks part. –  LanceBaynes Jun 19 '11 at 10:10
1  
As I said, it's a good ruleset to a point. If you're not concerned with availability on a LAN handing out DHCP, it would work for most scenarios. And having good logging definitely is a good defense, especially if it's going to a SIEM with the ability to respond actively. –  Ori Jun 19 '11 at 17:04

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.