El derecho a la integridad sexual y reproductiva en adolescentes

The dialog box in Figure 28 on page 72 appears.

Figure 28. Log facilities

2. Double-click on the entry <NEW>. The dialog box shown in Figure 29 will appear.

Figure 29. Adding log facilities

3. For Facility, choose Firewall Log.

4. For Priority, choose Warning. The priority specifies the level of detail of log messages. Warning is adequate for viewing denied packets, which we require for debugging firewall rule configurations.

5. Enter a name for the log file. Ensure that you place the file on a disk partition with adequate space (depending on how much traffic will be tested). We noticed that when specifying Debug priority, the log file grows very quickly and can cause the Firewall to lock up and even stop

functioning.

6. Click OK to complete.

3.4.3.2 Repor ting from the log file

The log file that is created is only a raw text file that is difficult to read and decipher. However there is a log conversion utility that comes with SWF called fwlogtbl. This utility converts the log file into a set of table files used for importing into an RDBMS. The only resulting file that we need to use is f_match.tbl. You can search for more details in the online documentation;

however, we used the following command to convert the log:

fwlogtbl -w -d c:\temp firewall.log

where -w overwrites any existing files (-a to append), -d is the destination directory for the table files, and firewall.log is the raw log file to convert. The raw log files are, by default, searched for in the \Program

Files\IBM\Firewall\log directory, unless the full path is specified.

A sample of the resulting f_match.tbl is shown below:

You can see clearly the packet details, its direction to the firewall (inbound), source and destination addresses, and so forth. You can easily use this command in a script to automate the log file conversion and filter the file according to source or destination address, and create a firewall block report.

Here is a reporting Perl script (fwlogfil.pl) we wrote to filter the f_match.tbl file,

C:\> fwlogtbl -w c:\temp d:\firewall\log\firewall.log

based on either source address, destination address, or both, and output to a file. The script is listed in Appendix D.1, “IBM SecureWay Log Reporter” on page 335.

The syntax for the script is:

fwlogfil.pl [-s source host/IPaddress] [-d destination host/IPaddress]

reportfile

Also make sure the script is in your environment path before running the script or else it will not be found, unless you specify a full path to the script (it is simpler to add a Path entry to your scripts directory).

Here is a sample output from the script to filter an f_match.tbl log file:

3.4.3.3 Tracing communications using a sniffer

In this section, we will demonstrate how a sniffer such as Ethereal or the Windows NT Network Monitor can trace the communication protocol details for an application. We will use our SNMP request and response as a simple example.

To run the script, you will need Perl installed on the system with the script (you can download most versions of Perl compilers from

www.activestate.com or www.perl.org). Once installed, you can simply execute it from the command line, or combine it in a batch file, if you always use the same log and output files.

Perl Installation

IBM SecureWay Firewall Block Report

Date: 2001-02-06-18.36.36.000000 Protocol: udp Source/port: 192.168.104.1[137] -->

Destination: 192.168.104.253[137] Status: deny Dir: outbound

Date: 2001-02-06-18.36.37.000000 Protocol: udp Source/port: 192.168.104.1[137] -->

Destination: 192.168.104.253[137] Status: deny Dir: outbound

Date: 2001-02-06-18.36.39.000000 Protocol: udp Source/port: 192.168.104.1[137] -->

Destination: 192.168.104.253[137] Status: deny Dir: outbound

Date: 2001-02-06-18.36.59.000000 Protocol: tcp Source/port: 192.168.104.1[1045] -->

Destination: 192.168.104.253[139] Status: permit Dir: outbound

Date: 2001-02-06-18.36.59.000000 Protocol: tcp Source/port: 192.168.104.1[1045] -->

Destination: 192.168.104.253[139] Status: permit Dir: outbound

Date: 2001-02-06-18.36.59.000000 Protocol: tcp Source/port: 192.168.104.1[1045] -->

Destination: 192.168.104.253[139] Status: permit Dir: outbound

Date: 2001-02-06-18.36.59.000000 Protocol: tcp Source/port: 192.168.104.1[1045] -->

Destination: 192.168.104.253[139] Status: permit Dir: outbound

Here are the steps we used to capture a trace of an SNMP communications exchange between ITSO8 (NetView for AIX) and MLM1:

1. Ensure that the Ethereal Sniffer is installed properly. See Appendix E,

“Installing the Ethereal Sniffer” on page 341 for help.

2. Attach the sniffer host to either side of the firewall FW1. (Note that for troubleshooting other scenarios, you may need to attach the sniffer to the network of the host that you suspect is having communication problems).

We will attach the sniffer host to the UN for this example, as shown in Figure 30 on page 76.

3. Configure the sniffer host with the appropriate network IP address and mask for that network. We chose 192.168.104.7 and 255.255.255.0.

4. Disable SWF so all communications can flow freely between the SN and UN. To do this:

a. Select System Administration, and then the Security Policy icon b. Select the Test Routing option and click OK.

c. Click Yes and OK to regenerate the rules.

The Ethereal Sniffer runs in promiscuous network mode and can capture all packets that pass the host’s ethernet network card. The native Windows NT Network Monitor is non-promiscuous and only captures packets to and from the host. Only the Microsoft SMS version Network Monitor runs in promiscuous mode. Ethereal was used because of its comprehensive coverage of features, including filtering different protocols, ease of use, and support of multiple platforms; also, it is freely available. Please refer to Appendix E, “Installing the Ethereal Sniffer” on page 341 for installation documentation of the Ethereal Sniffer.

Note

Figure 30. Sniffer host placement