Attempt to detect and Block Bad Hosts
Network administrators are in a constant battle trying to keep attacks from virus infected computers, computers that have been taken over by malicious people and malicious people them selfs. It's a never ending barrage of attacks trying to exploit any flaw in your network possible. I keep a list of hosts/networks that I consider to be "bad-hosts", this is a manual built list and it works great but I don't always have time to sit and watch for candidates for this list, so I created a set of rules to do it for me.
When a packet reaches the bottom of the forward chain it will be rejected, so before it is we will run it through this set of rules.
- The ip address is added to a address list with life span of 30 seconds
- if the ip address is then seen 20 more times in this 30 second span it is then added to another list that will have a life span of 24 hours
- if it is in the 24 hour list it will be rejected.
Here is some names I will be using.
- Address Lists
- our-networks (ip's/networks in this list are not included in this process, we don't want to block our own traffic.)
- 30-second-list (this list holds ip's for 30 seconds)
- 24-hour-list (the ip's in this list have a life span of 24 hours. Ip's in this list are rejected)
- bogons (bogons are non route able ip's such as 192.168.0.0/16)
- Filter Chains
- bad-host-detection (this is the main chain for this process)
- open-customers (this chain checks for customers/bussiness that don't want my help firewalling)
- bad-hosts (this chain checks a manual created list that contains hosts/networks that appear to be bad)
Rule to add in the forward chain:
Make sure this rule is at the top of your forward chain, This is what my top 3 forward chain rules are:
|The bad-host-detection chain:
|More rule's for the forward chain:
This rule needs to be at the bottom just before the packet is dropped, once again here is how I have mine (my last 3 forward rules)
- The list's in this process can get very large and your router must be capable of handling them. If you have a problem with lists sizes, reducing the timeout will reduce the size of the list.
- 20 rejected attempts in 30 seconds is what I believe is sufficient evidence of an attack, you may adjust them to your liking.
- This rule set could also be used in the input chain.
- Other Ideas
- Using the API to keep an eye on the list's count would be a good idea. Maybe even condense it into subnets.
- Another idea is to use the API and create a chart showing where the "bad hosts" are coming from.