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.
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.
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.
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
# 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 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
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
To track rule usage and bandwidth, check out this HOWTO.
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.