In Firewall Builder, service objects represent IP, ICMP, TCP, and UDP services such as "host unreachable" in ICMP, HTTP in TCP, GRE in IP, and DNS in UDP. Firewall Builder provides service objects for hundreds of well-known and frequently-used services in ICMP (IP protocol number 1), TCP (IP protocol number 6), and UDP (IP protocol number 17).
The IP service object describes protocols that are not ICMP, TCP, or UDP. (ICMP, TCP, and UDP have their own service objects.) An IP protocol is defined by the 8-bit field in the IP packet header. The screenshot below represents the ESP object (Encapsulating Security Payload, part of the IPSEC protocol family) which uses the IP protocol number 50.
Protocol numbers are assigned by IANA; you can look up the number for a particular protocol at the following URL: http://www.iana.org/assignments/protocol-numbers/
Besides the protocol number, the header of the IP packet also has a field called "Options" which is a variable-length list of optional information for the packet. Not all firewalls can examine options, and those that can usually have certain limitations as to what options they can match against. Firewall Builder tries to provide controls for many popular options supported by the most sophisticated firewalls. Not all options supported by Firewall Builder are supported by all target firewall platforms (Table 5.3).
Table 5.3. Support for IP options and fragmentation on various firewall platforms
|Firewall||lsrr||ssrr||rr||timestamp||all fragments||'short' packets|
||Normally IP routing is dynamic, with each router making decisions about which next hop router to send the packet to. However, another option exists where the sender can choose the route. In the case of the Loose Source Route, the sender (host) can specify a list of routers the packet must traverse, but it may also pass through other routers between any two addresses in the list. The Strict Source Route works very much the same way, except the packet must traverse only through the specified addresses. Source routing can potentially be used to reach hosts behind the firewall even if these hosts use private IP addresses, which normally are not reachable over the Internet.|
||This option causes every router that handles the packet on the way to add its IP address to a list in the options field. This option is used by the ping utility when it is called with the "-R" command line switch; it can potentially be exploited to discover the internal network addressing and layout behind the firewall. Although the risk is low, some firewall administrators prefer to block packets with this option set.|
||This option tells routers that handle the packet to record their timestamps and sometimes addresses (like in the case of the record route option). This option is seldom used, but can potentially be exploited to gather information about the protected network, so some firewall administrators prefer to block packets with this option set.|
||IP packets may sometimes become fragmented. This happens if the original datagram is larger than what a physical network layer can transmit. The IP packet header has special fields (called "Flags" and "Fragmentation Offset") that detect fragmented packets and help reassemble them. Many firewalls can check these bits as well. Certain combinations of flags and fragmentation offsets can never happen during normal operation but were seen to be used by attackers. Firewall Builder provides two options for handling the most commonly used cases: the "all fragments" option matches the second and further fragments, while the "short" option is used to match packets that are too short to contain even a complete IP header.|
Standard IP service objects that come with Firewall Builder appear in the Standard tree, in the branch.
You can create your own IP Service objects in the User library.
Service objects in the Standard are not editable. However, you can copy and paste a copy of a service object into the User tree and edit it there, or you can right-click the IP folder in the User tree and select to create a service object from scratch.
In either case, the controls are the same.
The IP Service dialog provides the following controls:
This is the name of the object
This is the protocol number.
You can specify DSCP or TOS using the radio buttons. In either case, specify a code (or class) in the field. If you do not specify a code or class, Firewall Builder ignores the DiffServ type (DSCP or TOS).
These flags represent "Options" flags in the IP header:
|lsrr (loose source route)|
|ssrr (strict source route)|
|rr (record route)|
This is a free-style text field used for comments.
Consider the following IP Service objects:
Object EF has DSCP matching turned on, matching traffic class EF. Object TOS 0x10 matches packets with TOS bits set to 0x10 (low delay). Object all_fragments has flag "all fragments" turned on, and finally object lsrr matches "loose source routing" option. Here is what we get for iptables when we use these objects in policy rules as follows:
# Rule 0 (global) # $IPTABLES -N RULE_0 $IPTABLES -A FORWARD -p all -f -j RULE_0 $IPTABLES -A FORWARD -p all -m ipv4options --lsrr -j RULE_0 $IPTABLES -A RULE_0 -j LOG --log-level info --log-prefix "RULE 0 -- DENY " $IPTABLES -A RULE_0 -j DROP # # Rule 1 (global) # $IPTABLES -A FORWARD -o + -p all -m dscp --dscp-class EF -m state \ --state NEW -j ACCEPT $IPTABLES -A FORWARD -o + -p all -m tos --tos 0x10 -m state --state NEW \ -j ACCEPT
The compiler for iptables uses the ipv4options module to match lsrr, the -f command line option to match all fragments, the tos module to match TOS and the dscp module to match DSCP class.
When compiled for IPv6, these rules yield the following iptables commands:
# Rule 0 (global) # $IP6TABLES -N RULE_0 $IP6TABLES -A FORWARD -m frag --fragmore -j RULE_0 $IP6TABLES -A RULE_0 -j LOG --log-level info --log-prefix "RULE 0 -- DENY " $IP6TABLES -A RULE_0 -j DROP # # Rule 1 (global) # $IP6TABLES -A FORWARD -o + -m dscp --dscp-class EF -m state --state NEW -j ACCEPT $IP6TABLES -A FORWARD -o + -m tos --tos 0x10 -m state --state NEW -j ACCEPT
ip6tables does not have the -f command line flag; instead, it uses the frag module to match fragments. Firewall Builder currently does not support the ip6tables ipv6header module, and source routing options do not exist in IPv6, so object "lsrr" cannot be used in rules.
PF cannot match DSCP bits and source routing options, but it can match TOS. Trying the same IP Service object "tos 0x10" in policy rules for PF:
pass out quick inet from any to (eth0) tos 0x10 keep state
Cisco IOS access lists cannot match source route options but can match fragments and TOS and DSCP bits. Here is what we get if we try to compile the same rules using the same IP service objects for Cisco IOS:
ip access-list extended e1_0_out ! ! Rule 0 (global) ! deny ip any any log fragments ! ! Rule 1 (global) ! permit ip any any tos 0x10 permit ip any any dscp EF exit
Copyright © 2000-2012 NetCitadel, Inc. All rights reserved.
Using free CSS Templates.