Firewall musings…
Yesterday I had a bit of a realization. I had just been looking at a wireless router/firewall setup and was thinking about the firewalling rules (which seemed to be geared at the WIRELESS lan… i.e. blocking that activity on the Wireless segment.) You know, traditionally firewalls have had the attitude of defending the internal network from the outside. Of course, these days firewalls sometimes protect the internal network from a WLAN (Wireless segment as well.) But, I put a few events together and started looking for a new feature in a firewall.
OK, well maybe it’s not a NEW feature, but a slightly unusual application of existing features. Here are the thoughts I put together. Back in February, I was configuring an open access point for a company that REALLY wanted an open access point. I was configuring it at my home before taking it onsite. Within 30 minutes of plugging in the access point, my connection was down. It was 8-10 hours before I was online again and really a few weeks worth of auditing systems to verify that none of them were compromised. The long and short of it is that a port scan had come from my cable account and my best explanation to this day is that the access point was where it came from. So the question came – HOW could someone have an open access point (assuming it’s ok by their ISP’s terms….) WITHOUT being at risk of an outbound port scan getting out.
Here’s the second piece of the puzzle… last week (or two weeks ago), I had a large number of brute-force ssh login attempts, now my ssh setup seems fairly solid, but I wanted to tighten it even further. Among the solutions I found were denyhosts, a script that updates hosts.deny when repeated invalid connections are made, but the other was a firewall rule for iptables that would block out an ip address if it attempted more than 4 ssh connections in 60 seconds.
From what I recall of my cable “incident”, the support desk said that an entire netblock had been scanned, so…. slowing down outbound scanning would certainly put a crimp in any wireless-based hackers excursion. (Limiting it to 4 attempts a minute would likely force them to move on.)
So, I started looking at the iptables rules using ipt_recent and there are quite a few good examples for inbound traffic filtering that way. I’m still working on getting a successful outbound filter setup this way (using an ipcop firewall VM). As I searched though, I found a few interesting ideas on the subject. In general this is called an “adaptive firewall” rule, where the firewall policy changes as events change. For inbound filtering it’s something that should be treated with caution… say for instance the attacker realizes that they’re being blackholed dynamically…. Their next step might be to spoof the address of your DNS server, or popular websites so that THOSE addresses get blackholed which can disrupt your network access.
But there’s not a lot of talk of adaptive firewall rules used for an internal network. There is talk of using portsentry on an internal network and using that to detect viral infected hosts that are scanning for other pcs to infect. There are also a few ideas about Reverse IDS (Reverse Intrusion Detection or Extrusion Detection)… Essentially setting up Snort to monitor outbound traffic and then using a script such as guardian to affect firewall rules in reaction to what is seen.
Anyway… This is the ipt_recent modules page for iptables. This snort page talks about dynamically adding iptables rules (although I don’t know that protecting against egress traffic is what’s in mind.) snortsam is another snort plugin to deal with the autoblocking. This comment is related to iptables use of ipt_recent modules to block ssh bruteforcers…. This message talks about using the –limit option in iptables to throttle the number of connections per minute. THIS document on ActivePortal gives a GOOD general idea of the RIDS (reverse Intrusion Detection System).
OK – so, I have made some progress on the idea, now the main problem is refining it for real-world usability….
Oh, one more reference… This good writeup on blocking bruteforce ssh attacks using iptables. Finally, here is a pretty good iptables overview.
In theory it seems like it’s VERY do-able to setup adaptive firewalling to “limit” an internal network machine from accessing resources outside the firewall (throttling a network scan for instance.) I don’t see too many linux firewall distributions that make this kind of setup very easy though. It seems like you would have to resort to command line iptables alterations to make it work. In practice it seems like it might be a tricky balance to strike between protecting against a flood of outgoing traffic and not clamping the choke down TOO tightly to interfere with legitimate traffic.