How Your Rulebase Is Converted to INSPECT
| Your security policy is stored as a .W file on the management console as well as inside the rulebases_5_0.fws file. Your rulebase file contains all of the rules you have defined in the Security Policy Editor referencing network objects. Your objects_5_0.C file contains the definitions for the network objects referenced in your rulebase file as well as properties that further define your rulebase (the implicit rules ). When you load a policy, the .W file is put through a compiler that takes the .W file along with your objects_5_0.C file (and other files) and creates a .pf (packet filter) file. This .pf file contains INSPECT code that represents your security policy as well as some familiar-looking compiler directives: #include and #define . These directives work pretty much the same as they do in a normal C compiler. Each packet that enters the Stateful Inspection engine is processed according to your security policy as defined by the .pf file. The packet goes through, line by line, statement by statement, until it is accepted, rejected, dropped, or vanished. As an example, let's use the rulebase shown in Figure 14.1. Figure 14.1. Sample rulebase At the very top of the .pf file, you should see something like the following: // INSPECT Security Policy Script Generated by // dwelch@kermit at 16Mar2003 23:34:51 // from Rulebase pb-simple2.W by FireWall-1 NG // Feature Pack 3 Code Generation // Running under WindowsNT 5.0 This tells you who generated the INSPECT code on what platform. The next section is denoted by the following: ///////////////////////////// // Exported Rules Database // ///////////////////////////// This shows you what the rulebase looks like. It looks very similar to what rulebases_5_0.fws would show you for this rulebase. Listed after the rulebase are some tables that get defined as a result of the rulebase and objects_5_0.C . The next section is indicated by the following in the .pf file: /////////////////////////// // Beginning of Prologue // /////////////////////////// What follows is based on several things:
Actual INSPECT code is not in this section. The next section is denoted by the following in the .pf file: /////////////////////////////////////// // Beginning of Security Policy Code // /////////////////////////////////////// This section contains definitions for all of your network objects. For example: ADDR_gateway(oscar, 192.168.5.2) ADDR_host(broadcast-ones, 255.255.255.255) ADDR_host(cablemodem, 192.168.100.1) ADDR_host(mcast-224.0.0.1, 224.0.0.1) ADDR_network(net_10.0.0.0, 10.0.0.0, 255.255.255.0) ADDR_network(net_192.168.0.0, 192.168.0.0, 255.255.255.0) ADDR_network(net_10.0.116.0, 10.0.116.0, 255.255.255.0) ADDR_gateway(low, 3.3.3.1) ADDR_gateway(medium, 3.3.3.2) ADDR_gateway(high, 3.3.3.3) ADDR_gateway(hi-med-low_profile, 3.3.3.4) ADDR_gateway(bert, 10.0.0.41) ADDR_gateway(ernie, 10.0.0.42) ADDR_gateway_cluster(bernice, 10.0.0.43) ADDR_host(kermit, 10.0.0.2) The preceding list contains various network objects I had defined. After this, you will see your encryption domains, if appropriate. For example: // VPN and SecuRemote encryption domain tables for gateway oscar all@oscar sr_enc_domain = { <10.0.0.0, 10.0.0.255>, <10.0.116.0, 10.0.116.255>, <192.168.5.2, 192.168.5.2>, <192.168.0.0, 192.168.0.255> }; all@oscar sr_enc_domain_valid = { <10.0.0.0, 10.0.0.255>, <10.0.116.0, 10.0.116.255>, <192.168.5.2, 192.168.5.2>, <192.168.0.0, 192.168.0.255> }; all@oscar vpn_enc_domain = { <10.0.0.0, 10.0.0.255>, <10.0.116.0, 10.0.116.255>, <192.168.5.2, 192.168.5.2>, <192.168.0.0, 192.168.0.255> }; all@oscar vpn_enc_domain_valid = { <10.0.0.0, 10.0.0.255>, <10.0.116.0, 10.0.116.255>, <192.168.5.2, 192.168.5.2>, <192.168.0.0, 192.168.0.255> }; You will also see a number of other VPN- related items, such as VPN Routing tables and interface resolving tables. Next, you will see any NAT rules you have defined. Figure 14.2 shows the NAT rulebase I am using. Figure 14.2. Sample NAT rulebase The corresponding INSPECT code looks like this: // Address Translation Code all@target_list22 xlate_rulebase = { <0x80010001, FWXT_SRC_STATIC_SRVSIDE, RANGE_NETWORK(net_10.0.0.0), net_10.0.0.0, 0, FWXT_DST_STATIC_CLISIDE, RANGE_NETWORK(net_10.0.0.0), net_10.0.0.0, 0, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX >, <0x80010002, FWXT_SRC_STATIC_SRVSIDE, RANGE_NETWORK(net_10.0.0.0), net_10.0.0.0, 0, FWXT_DST_STATIC_CLISIDE, RANGE_NETWORK(net_192.168.0.0), net_192.168.0.0, 0, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX >, <0x80010003, FWXT_SRC_STATIC_SRVSIDE, RANGE_NETWORK(net_192.168.0.0), net_192.168.0.0, 0, FWXT_DST_STATIC_CLISIDE, RANGE_NETWORK(net_10.0.0.0), net_10.0.0.0, 0, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX >, <0x80010004, FWXT_SRC_STATIC_SRVSIDE, RANGE_NETWORK(net_192.168.0.0), net_192.168.0.0, 0, FWXT_DST_STATIC_CLISIDE, RANGE_NETWORK(net_192.168.0.0), net_192.168.0.0, 0, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX >, <0x80020001, FWXT_SRC_STATIC_SRVSIDE, RANGE_NETWORK(net_10.0.0.0), net_10.0.0.0, 0, FWXT_DST_STATIC_CLISIDE, RANGE_NETWORK(net_10.0.116.0), net_10.0.116.0, 0, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX >, <0x80020002, FWXT_SRC_STATIC_SRVSIDE, RANGE_NETWORK(net_192.168.0.0), net_192.168.0.0, 0, FWXT_DST_STATIC_CLISIDE, RANGE_NETWORK(net_10.0.116.0), net_10.0.116.0, 0, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX >, <0x80030001, FWXT_HIDE_SRVSIDE, RANGE_NETWORK(net_10.0.0.0), oscar, 0, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX >, <0x80030002, FWXT_HIDE_SRVSIDE, RANGE_NETWORK(net_192.168.0.0), oscar, 0, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX >, <0x80040001, FWXT_HIDE_SRVSIDE, RANGE_NETWORK(net_10.0.116.0), oscar, 0, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX, FWXT_EOX > }; The group internal-networks contains two networks: 10.0.0.0/24 and 192.168.0.0/24. The NAT rule that used this group generated four "internal" rules:
A group of three objects would generate nine rules, a group of four objects would generate sixteen rules, and so on. WARNING!
Further down the .pf file, you will see your NAT rules shown again. Note that these are for display purposes; this set of rules shows when the module is queried for its current rulebase. Next, you will see what defines the valid addresses for your gateway. For instance: // Interfaces valid addresses tables all@oscar valid_addrs_list1 = { <0.0.0.0, 9.255.255.255>, <10.0.1.0, 10.0.115.255>, <10.0.117.0, 126.255.255.255>, <128.0.0.0, 192.167.255.255>, <192.168.1.0, 192.168.5.1>, <192.168.5.3, 223.255.255.255>, <240.0.0.0, 255.255.255.254> }; all@oscar valid_addrs_list2 = { <10.0.0.2, 10.0.0.254>, <192.168.0.0, 192.168.0.255> }; all@oscar valid_addrs_list3 = { <10.0.116.1, 10.0.116.254> }; In many of the tables given in the preceding examples, you will see things listed as a range. For example, valid_addrs_list1 shows: <10.0.117.0, 126.255.255.255> This includes all IP addresses from 10.0.117.0 through 126.255.255.255, including the endpoints. Next are your address translation rules. The format should look very similar to the rules shown in the Security Policy Editor. The next interesting section is denoted by the following in the .pf file: // User defined init code and global init code In this section, various parts of FireWall-1's lib directory are included as well as your user-defined file, user.def . A call to include the file code.def is listed below this line. The main purpose of this file is to accept established connections and make sure the IPs that are trying to access the system are not blocked by Suspicious Activity Monitoring (SAM). This section would also include any anti-spoofing checking defined in the firewall's network object. You then have the following section: // Rule-Base And Before-Last Properties Code In this section, you start getting into the real security policy. For the rulebase shown in Figure 14.1, the first rule is represented by the following INSPECT code: all@oscar accept eitherbound, start_rule_code(1), (udp, dhcp-rep-localmodule or dhcp-req-localmodule), (ip_dst in ip_list12), RECORD_CONN(1), ALLOW_TEMPLATE_ACCELERATION; This code is translated into English line-by-line as follows.
If you want to put a rule in that generates a log entry, you might use the following rule: all@oscar accept eitherbound, start_rule_code(7), (udp, l2tp), (ip_dst in ip_list19), RECORD_CONN(7), LOG(long, LOG_NOALERT, 7), ALLOW_TEMPLATE_ACCELERATION; A translation of the preceding code into English follows.
Note that in either of these examples, if one of the statements after accept returns false , the rest of the statement is not evaluated. So, for example, if the packet were of type TCP, both of these rules would be bypassed before the destination port was evaluated. Services of Type OtherA service of type Other contains two parts that must be defined: the protocol number and the Match field. The protocol number depends on the protocol in question. For example, TCP is always 6, ICMP is 1, and UDP is protocol 17. The Match field should contain INSPECT code that matches the service. For example, if you want the code to match HTTP, the protocol number would be 6, and the Match field would contain dport=80 . You could also reference your own INSPECT code in this field.  |
EAN: 2147483647
Pages: 143