The custom service object can be used to inject arbitrary code into the generated firewall script. Any combination of options allowed in the target firewall command line language that does not fit into a strict model of standard service object types can be expressed using the custom service object. For example, iptables comes with a collection of modules that adds an ability to match complex combinations of packet parameters or header fields that are not supported by a standard code. One of the modules adds the ability to match any string in the packet's payload which can be quite useful to quickly build firewall rule to block some new protocol that uses non-specific combination of ports and other parameters. This ability is sometimes used to write rules to block network trojans or viruses with known signatures.
The following screenshot represents a custom service object that uses the capabilities of the string module. Command-line options specific for this module are in the "Code String" field.
Note: The code specified in the custom service object is used literally; no validation is done either by the Firewall Builder GUI or the policy compilers.
The Custom Service dialog provides the following controls:
Name: This is the name of the object.
Platform: This is a pull-down menu that shows a list of all firewall platform targets available in Firewall Builder.
Code String: This is a line of code in the target firewall language. (This is the heart of the custom service object.)
Protocol Name: Use this option if you want to restrict the custom service object to a particular protocol: TCP, UDP, or ICMP. Default is "any". For example, if this field is set to "tcp", then policy compiler for iptables generates command with parameter "-p tcp" and then inserts code defined in the "Code String" field of the custom service object.
Address Family: Specify IPv4 or IPv6. Policy compilers use information about address family to properly use the object while compiling IPv4 or IPv6 rule sets.
Comments: This is a free-style text field used for comments.
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.
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:
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:
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:
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.
Copyright © 2000-2012 NetCitadel, Inc. All rights reserved.
Using free CSS Templates.