FirewallBuilder

The following example uses iptables module "recent". Quoting from the iptables manual, this module "allows you to dynamically create a list of IP addresses and then match against that list in a few different ways". We can use this module to throttle brute-force ssh scanning attacks where an attacker repeatedly connects to the ssh daemon trying to guess login name and password. The full explanation of how to use the custom service object in combination with swatch script on Linux to stop these attacks can be found in the Firewall Builder Cookbook (Chapter 14). Here we focus only on the Custom Service object and iptables rules that can be obtained with it.

Figure 5.125. 

The code string defined in this object is "--dport 22 -m recent --set". This matches port 22 (ssh), activates the module and adds source address of the packet to the default list maintained by the module.

The second custom service object also matches port 22 and checks if the address is already on the list and was seen during the past one minute twice:

Figure 5.126. 

Note that our goal is to match protocol SSH (tcp port 22) and at the same time activate iptables module "recent" and add some parameters for it. Both are done by means of a service object in Firewall Builder; however placing two service objects in the "Service" field of a rule joins them by a logical OR operation. That is, if we were to put TCP service object "ssh" and custom service object that defines parameter for module "recent" in the "Service" field of the same rule, we would end up with two iptables commands, one matching tcp port 22 and another trying to use module "recent". Since we need to match both in the same rule, we have to add "--dport 22" to the code defined in the custom service object.

Now, the rules using these objects:

Figure 5.127. 

Here are the iptables commands generated for these two rules:

# Rule 0 (global)
# 
$IPTABLES -N In_RULE_0
$IPTABLES -A INPUT  -i + -p tcp -m tcp  --dport 22 \
      -m recent --rcheck --seconds 60 --hitcount 2  -j In_RULE_0 
$IPTABLES -A In_RULE_0   -j LOG  --log-level info --log-prefix "RULE 0 -- DENY "
$IPTABLES -A In_RULE_0  -j DROP 
# 
# Rule 1 (global)
# 
$IPTABLES -A INPUT  -i + -p tcp -m tcp  --dport 22 -m recent --set \
      -m state --state NEW  -j ACCEPT 
# 

                

First, we match port 22 and check if we have seen this source address during the past minute at least 2 times. If yes, module "recent" returns a match and the packet matches the first iptables rule. Iptables passes control to the rules in chain "In_RULE_0" where the packet is logged and dropped. If the packet does not match the conditions set for the module "recent", it does not match the first iptables rule and will be inspected by the next one (generated for the original rule #1). If this is the opening packet of a new session, it matches state "NEW" and will be permitted. Since module "recent" was also called in this rule, the source address of the packet was added to the internal table of the module "recent" so it can be used in the previous iptables rule.

The custom service object allows you to inject arbitrary strings into the generated firewall configuration in the place where port matching normally occurs. Another feature in Firewall Builder that also allows for insertion of a code in the generated code is the custom action feature. The combination of custom service with custom action provides for a very flexible system where you can compose pretty much any required configuration line if it is not otherwise supported by the standard means. Suppose instead of just dropping SSH scan connections coming to our system, we want to slow them down, thus tying up the attacker's resources. Iptables has a target just for that called TARPIT. This target is specific for iptables and does not exist on the other firewalls supported by Firewall Builder and there is no standard action for it. You can use the custom action mechanism to generate an iptables command with this target. In the rule, the action in it is set to "Custom Action". Double-clicking the action in the rule opens a dialog with its parameters (if any). The custom action object has one parameter: a free-form string where you enter the code you want to appear in the generated command:

Figure 5.128. 

Here is what we now get when we compile this policy for iptables:

# 
# Rule 0 (global)
# 
$IPTABLES -N In_RULE_0
$IPTABLES -A INPUT  -i + -p tcp -m tcp  --dport 22 \
      -m recent --rcheck --seconds 60 --hitcount 2  -j In_RULE_0 
$IPTABLES -A In_RULE_0   -j LOG  --log-level info --log-prefix "RULE 0 -- CUSTOM "
$IPTABLES -A In_RULE_0 -j TARPIT
# 
# Rule 1 (global)
# 
$IPTABLES -A INPUT  -i + -p tcp -m tcp  --dport 22 -m recent --set \
      -m state --state NEW  -j ACCEPT 
# 

                

Now the first rule ends up sending the packet to the "TARPIT" target rather than to "DROP", which is what we wanted.