Taming the Rhino Pt ][: Setting the iptable…

This weeks Rhino taming lesson….is all about iptables. The linux based host firewall that can make or break your day at WRCCDC. The idea of a host based firewall is to give the individual host even more protection from your standard network based firewall. With a little bit of work iptables can be configured to be quite effective at stopping network recon as well as protecting your applications.

The Setup

For Ubuntu based linux distros, follow the HowTo. For CentOS and RHEL based distros, editing the /etc/sysconfig/iptables file and restarting the iptables service is all the setup you need.

The Basics

Listing the current tables:

sudo iptables -L

Allow established connections:

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Allow incoming ( server ) traffic:

sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT

* dport should be the port that the server or service you want your clients to connect to is listening on.

Blocking traffic:

sudo iptables -A INPUT -j DROP

* The differences between drop and reject are subtle — but have some serious implications. A ‘drop’ will silently discard the packet. A tcp client will keep resending until its timers expire and then finally give up. A ‘reject’ will notify the sender via an RST packet that we wish not to communicate. While this is prudent for tcp clients — it may also give away our position to a scanner.

The Fun Stuff:

Dealing with Portscans

Red Teans love looking for open services they can try to exploit. Pick a port that has no services running ( in this case 445 works — it is a common port for windows, and included in most scanes ), and then block the hosts who attempt the connection from talking to your server for an entire day. We will use the iptables recent module:

# Define the portscan profile
iptables -A INPUT   -m recent --name portscan_profile --rcheck --seconds 86400  -j DROP
iptables -A INPUT   -m recent --name portscan_profile --remove

# Add scanners to the portscan_profile list, and log the attempt.
iptables -A INPUT   -p tcp -m tcp --dport 445 
    -m recent --name portscan_profile --set -j LOG --log-prefix "Attempt:"
iptables -A INPUT   -p tcp -m tcp --dport 445 
    -m recent --name portscan_profile --set -j DROP

Syn Floods

SYN Flood protection is all based on rate limiting. Since a SYN is only sent when a client wishes to open a connection — if you dont expect your server to have a wave of incoming — then lets ratchet the SYN rate down.

# Protect against SYN floods by rate limiting the number of new
# connections from any host to 60 per second.  This does *not* do rate
# limiting overall, because then someone could easily shut us down by
# saturating the limit.
iptables -A INPUT -m state --state NEW -p tcp -m tcp --syn 
    -m recent --name  synflood --set
iptables -A INPUT -m state --state NEW -p tcp -m tcp --syn 
    -m recent --name synflood --update --seconds 1 --hitcount 60 -j DROP


SMURF attacks are interesting in that both the ‘attacker’ and the victim are really the victims. By crafting a ICMP packet with the victims FORGED address — and sending it to an un suspecting host – I can get that host to generate a large amount of traffic at the Victim machine. Both of which none the wiser of whats going on. The key to stopping this is to rate limit ICMP as we really shouldnt have a flood of ICMP packets.


# Allow most ICMP packets to be received (so people can check our
# presence), but restrict the flow to avoid ping flood attacks
iptables -A INPUT -p icmp -m icmp --icmp-type  address-mask-request -j DROP
iptables -A INPUT -p icmp -m icmp --icmp-type timestamp-request -j DROP
iptables -A INPUT -p icmp -m icmp -m limit --limit 1/second -j ACCEPT 

Bogus Packets

Since TCP SYN is used to request that a TCP connection be opened on a server, and TCP FIN is used to terminate an existing connection. Should we see the two together? Not at all. These kinds of packets are “bogus”, in that they use flag combinations which make no sense. However, some network implementations can be fooled into some strange behavior when such unexpected packets are received. The best defense, then, is just to reject them all.

# Drop invalid packets immediately
iptables -A INPUT   -m state --state INVALID -j DROP
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A OUTPUT  -m state --state INVALID -j DROP

# Drop bogus TCP packets
iptables -A INPUT -p tcp -m tcp  --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP

Iptables Tracking

To track rule usage and bandwidth, check out this HOWTO.

String Matching

Way beyond scope of this article, but if you want to get a bit more advanced. Take a look at the iptables string matching capability. Specify an offset and a string in the payload and the rule will match. Very powerful against malware.

Leave a CommentPlease be polite. We appreciate that.

Your Comment