Logging (the creation of logs by the firewall) is an important part of a properly configured firewall. Gauntlet Firewall system administrators use information in logs to analyze usage statistics, monitor activities, check for problems, and investigate potential attacks. The logging features of the Gauntlet Firewall provide system administrators with information about activities to and through the firewall. The logging features present information in several formats. Configure the Gauntlet Firewall's logging and reporting features to match your organization's security policies.
This chapter describes the concepts behind logging and reporting systems, configuring these systems, and understanding the logs and reports. The chapter consists of the following sections:
The Gauntlet Firewall follows the philosophy that it is easy to compress, consolidate, summarize, and delete log information; it is impossible to retroactively gather log information on an event that has already occurred. Disk space is a lot cheaper than spending many hours debugging a problem that a program would have written to the logs. For these reasons, the components of the Gauntlet Firewall log a wide variety of activities and attributes.
These are the components of the Gauntlet Firewall:
firewall kernel
proxies
authentication management system
DNS
sendmail
These are the attributes logged:
source IP address
destination IP address
source port
destination port
user name
session date and time
number of bytes transferred
individual commands (for some activities)
successful access attempts
unsuccessful access attempts
errors in configuration
The proxies, kernel, and authentication management system automatically write information to the logs. These programs call the standard IRIX system log command (syslog) to write information to the standard IRIX log file in /var/adm/SYSLOG. You do not need to do anything special to create the logs. Even if you choose not to do anything with the information in the logs, the programs still write the information. You never know when you might need it.
The system log file also contains information from other programs, such as bind, cron and other IRIX utilities that use the syslog command.
As with any other information that the syslog function writes, the firewall log information is ASCII text. People and shell scripts can easily parse the information.
The Gauntlet Firewall uses other standard IRIX tools to manage logs. Every night, the cron daemon runs a shell script that rotates, compresses, and removes log files. The Gauntlet Firewall stores the last two days of logs in ASCII format. By default, the firewall also stores the most recent 14 days in compressed format.
The default logging options included with the Gauntlet Firewall meet the needs of most security policies. You do not need to set or modify any options if you wish to use the default configuration, which logs all of the information described above, and retains the logs for 14 days. You can, however, customize the contents and retention of the log.
A few of the proxies (FTP, HTTP, lp, and the Info Server) can log specific commands. For example, the FTP proxy can create a log entry for each command (STOR, RETR, CWD, LIST) it receives.
To modify commands that the proxies log:
From within the Gauntlet Firewall Manager, select Services.
Select the tab for the proxy you wish to configure.
Turn on the logging options for that proxy.
The Gauntlet Firewall contains several reporting mechanisms that sort through the log files and summarize information. The Gauntlet Firewall automatically generates reports. The cron daemon runs a set of shell scripts that parse the information in /var/adm/SYSLOG. You do nothing to create reports; the Gauntlet Firewall does it automatically.
The Gauntlet Firewall includes two types of reports:
The Service Summary reports include usage and user information on a per service basis. For example, the default report for the TELNET gateway indicates the top 100 clients by connections, the top 100 clients by amount of traffic, and the top 100 denied clients.
To create the Service Summary reports, each night the cron daemon on the Gauntlet Firewall runs the scripts to summarize the logs for each service.
When you turn on this option (by default, it is off), the Gauntlet Firewall e-mails the Service Summary reports to root each night. You can modify the e-mail recipient and disable the mail notification. The Gauntlet Firewall does not store the daily Service Summary Report.
Each week, the cron daemon on the Gauntlet Firewall runs scripts to summarize services for the past week. By default, each week the Gauntlet Firewall e-mails the Service Summary reports to root. You can modify the mail recipient and disable e-mail notification, but the Gauntlet Firewall still creates the Service Summary Report. The Gauntlet Firewall does not store the weekly Service Summary Report.
Exception reports include noteworthy items. The Gauntlet Firewall defines a list of items that are not noteworthy and ignores those entries in the reports. The Gauntlet Firewall treats all other events as possible security events. Thus, any item that you do not specifically tell the Gauntlet Firewall to ignore, it reports. Exception reports include information that could indicate a possible attack or other problems.
For example, the Gauntlet Firewall default is to ignore successful authentications when parsing the log file. Successful authentication attempts are a normal part of Gauntlet Firewall activity. However, unsuccessful authentication attempts could be a sign of a potential attack. Therefore, the Exception Report includes all unsuccessful authentication attempts.
To create Exception reports, the cron daemon periodically (the default is once a day) runs a reporting script. The script scans log files for security alerts it can ignore, as defined in a different configuration file.
The script summarizes all noteworthy items since the last time the script created a report. By default, the Gauntlet Firewall e-mails Exception reports to root. You can modify the e-mail recipient, disable the e-mail notification, and set the frequency interval. The script does not store the Exception Report.
The Gauntlet Firewall default reporting options meet or exceed the needs of most organization's security policies. To use the reporting default configuration, you do not need to set or modify options. The Gauntlet Firewall e-mails weekly Service Summary reports to root. The firewall uses a set of default activities as items that the reporting scripts ignore.
You can customize the report recipient, and enable or disable daily or weekly Service Summary reports. You can customize the events that the Gauntlet Firewall ignores in the Exception reports, enable and disable Exception reports, and customize the Exception reports reporting interval.
To access the report configuration:
From within the Gauntlet Firewall Manager, select Reports.
Click the Configure tab.
The Configure window displays.
You can configure the report recipients for Exception and Service Summary reports.
 | Note: You must send these reports to the same people. You cannot send the Service Summary reports to one person and the exception reports to another. |
If you do not specify report recipients, the firewall e-mails the reports to root on the firewall.
To configure report recipients, type the name of the recipient in the e-mail address for Report Distribution field on the Configure window,
The report recipient can be one person, several people, one e-mail alias, or several e-mail aliases.
If you have made changes to your firewall's configuration, you may wish to receive reports more often. This can help you to detect a misconfiguration more quickly. If you suspect that someone is trying to attack your firewall, you may also wish to increase the report frequency.
To configure the frequency of Exception reports, click on one of the intervals under Exception Alarms. After each interval, the firewall scans the log, creates a report, and e-mails the report.
To configure the frequency of Service Summary reports:
If you want the firewall to create and e-mail Service Summary reports every day, under Summary Reports, select Daily.
If you want the firewall to create and e-mail Service Summary reports every week, under Summary Reports, select Weekly.
You can configure the patterns and security alerts that the event reporting scripts ignore when parsing the logs. This allows you to configure the Gauntlet Firewall to ignore patterns and routine security alerts.
The firewall still records all events in the log, even if events do not appear on the Exception Report.
You must use regular expressions to configure events to ignore. If you are not familiar with regular expressions, consult your operating system documentation or the programming reference section of a technical bookstore.
As an example, the Gauntlet Firewall creates information messages about the number of bytes transferred by the lp proxy.You do not find this information exceptional and do not want to display this information in the Exception reports. The regular expression
lp-gw.*bytes.*xferred |
causes the reporting script to ignore messages in the logs about the number of bytes the lp proxy transfers.
To modify items of interest:
Click Items of Interest.
This starts an editor that displays the current list of items of interest.
Enter regular expressions for items you do not wish to see in your reports.
Click OK.
A system on your trusted network often sends UDP requests on port 53 that cause security alerts on the Gauntlet Firewall. You know this is because of inadequate settings for time-outs in the DNS code that your system is running. You do not find this information exceptional and do not want to see it in your Exception reports. The regular expression
kernel: securityalert: udp from 10.0.1.126:53 to |
causes the reporting script to ignore messages from the kernel indicating UDP errors on port 53 from the problematic system.
To modify security alerts:
The Gauntlet Firewall writes logs and reports as ASCII text. People and shell scripts can easily use the logged information.
This section presents a brief overview of what the logs and reports look like and what each entry indicates.
The log file (/var/adm/SYSLOG) contains a chronological list of events written by the kernel, proxies, authentication management system, and other processes. The example below shows events the Gauntlet Firewall logged in a two-minute period between 10:47:00 and 10:48:59.
Oct 30 10:47:22 fire-in http-gw[12079]: permit host=unknown/10.0.1.17 use of gateway Oct 30 10:47:22 fire-in http-gw[12079]: log host=unknown/10.0.1.17 protocol=HTTP cmd=dir dest=www.sgi.com path=/ Oct 30 10:47:23 fire-in http-gw[12079]: content-type= text/html Oct 30 10:47:23 fire-in http-gw[12079]: exit host=unknown/10.0.1.17 cmds=1 in=2392 out=0 user=unauth duration=6 Oct 30 10:47:23 fire-in http-gw[12080]: permit host=unknown/10.0.1.17 use of gateway Oct 30 10:47:23 fire-in http-gw[12080]: log host=unknown/10.0.1.17 protocol=HTTP cmd=get dest=www.sgi.com path=/art/actual/title.gif Oct 30 10:47:25 fire-in http-gw[12080]: content-type= image/gif Oct 30 10:47:27 fire-in http-gw[12080]: exit host=unknown/10.0.1.17 cmds=1 in=5581 out=0 user=unauth duration=4 Oct 30 10:47:28 fire-in http-gw[12081]: permit host=unknown/10.0.1.17 use of gateway Oct 30 10:47:28 fire-in http-gw[12081]: log host=unknown/10.0.1.17 protocol=HTTP cmd=get dest=www.sgi.com path=/art/buttons/2.netsec.gif Oct 30 10:47:28 fire-in http-gw[12081]: content-type= image/gif Oct 30 10:47:28 fire-in http-gw[12081]: exit host=unknown/10.0.1.17 cmds=1 in=135 out=0 user=unauth duration=0 Oct 30 10:48:24 fire-in smap[12082]: connect host=cosmo.clientsite.com/192.94.214.96 Oct 30 10:48:24 fire-in smap[12082]: host=cosmo.clientsite.com/192.94.214.96 bytes=1005 from=<bob@clientsite.com> to=<@fire-out.trusted.com:clancy@yoyodyne.com > Oct 30 10:48:24 fire-in smap[12082]: exiting host=cosmo.clientsite.com/192.94.214.96 bytes=1005 Oct 30 10:48:39 fire-in sendmail[12084]: KAA12084: from=<bob@clientsite.com>, size=921, class=0, pri=30921, nrcpts=1, msgid=<9510301544.AA04030@clientsite.com>, relay=uucp@localhost Oct 30 10:48:39 fire-in smapd[12083]: delivered file=sma012082 Oct 30 10:48:40 fire-in sendmail[12086]: KAA12084: to=<@firewall.yoyodyne.com:clancy@yoyodyne.com>, ctladdr=<bob@clientsite.COM> (6/0), delay=00:00:01, mailer=smtp, relay=mail.yoyodyne.com. [10.0.1.126], stat=Sent (Ok) |
Service Summary reports contain a concise overview of events by service (proxy). The example shows weekly information for TELNET activity through the Gauntlet Firewall.
Telnet/Rlogin Proxy Usage
----------------------------------------------------------------
Top 100 telnet gateway clients (total: 308)
Connects Host/Address Input Output Total
-------- ------------ ----- ------ -----
287 dimension.yoyodyne.com/ 267484 11412 278896
6 eight.yoyodyne.com/10.0 495575 2249 497824
6 jersey.yoyodyne.com/10. 291915 3608 295523
3 lizardo.yoyodyne.com/10 4204 318 4522
2 john.yoyodyne.com/10.0. 472366 4719 477085
2 planet10.yoyodyne.com/1 123 64 187
1 blaze.clientsite.com/20 169588 1473 171061
1 unknown/204.254.155.2 0 0 0
Top 100 telnet gateway clients in terms of traffic
Connects Host/Address Input Output Total
-------- ------------ ----- ------ -----
287 dimension.yoyodyne.com/ 267484 11412 278896
2 john.yoyodyne.com/10.0. 472366 4719 477085
6 jersey.yoyodyne.com/10. 291915 3608 295523
6 eight.yoyodyne.com/10.0 495575 2249 497824
1 blaze.clientsite.com/20 169588 1473 171061
3 lizardo.yoyodyne.com/10 4204 318 4522
2 planet10.yoyodyne.com/1 123 64 187
1 unknown/204.254.155.2 0 0 0
|
Exception reports contain a chronological summary of security alerts and potential items of interest. Exception reports contain several sections: Security Alerts, System Warnings, and Possible Items of Interest.
The security alerts section includes information about potential security violations. Common items in this section include:
Requests for unserved ports. These requests come from other systems looking for a particular service on your firewall. For example, if someone tries to access print services on your firewall, and you are not running the lp proxy, the firewall creates a log message indicating that it received a request for service on port 515.
DNS spoofing problems. These problems may be malicious attempts by a host on the outside network to act as a host on your inside network. More commonly, the firewall receives DNS requests from misconfigured DNS servers.
The system warnings section includes information about possible configuration errors. Common items in this section include:
Incorrect lines in the netperm table. Check the spelling and capitalization. Make sure that you have also used the correct syntax.
System resource problems.
The possible items of interest section includes information from other components of the firewall, which may indicate a problem or concern. Common items in this section include:
Notices about disk space
Configuration problems in the sendmail program
Users becoming root
The example shows information captured and logged over a one-day interval by the Gauntlet Firewall about security alerts, system warnings, and possible areas of interest.
Security Alerts --------------- Aug 5 00:01:41 fire-in kernel: securityalert: udp from 10.0.1.68:1140 to 129.241.131.10 on unserved port 29659 Aug 5 09:01:16 fire-in kernel: securityalert: tcp from 10.0.1.128:3616 to 10.0.1.159 on unserved port 14464 Aug 5 09:01:29 fire-in kernel: securityalert: tcp from 10.0.1.128:3621 to 10.0.1.159 on unserved port 14464 Aug 5 12:32:01 fire-in kernel: securityalert: tcp from 10.0.1.68:2089 to 199.201.68.101 on unserved port 8888 System Warnings --------------- Aug 5 08:41:49 fire-in authsrv[17675]: fwtksyserr: srvhear: read error: Connection reset by peer Aug 5 08:41:49 fire-in authsrv[17677]: fwtksyserr: srvhear: read error: Connection reset by peer Possible Items of Interest --------------- Aug 5 16:09:39 fire-in authsrv[18432]: administrator LIST Aug 5 16:10:38 fire-in su: BAD SU crawhide to root on /dev/ttyp0 Aug 5 16:10:44 fire-in su: crawhide to root on /dev/ttyp0 Aug 1 17:02:31 fire-in gui[13316]: permit host=fire-in.trusted.com/10.0.1.159 use of server(5) Aug 1 17:02:32 fire-in gui[13316]: protocol=http file=/usr/local/etc/guidb/D/Dgui/Hstartup0html Aug 1 17:02:32 fire-in gui[13316]: exit in=22 out=3320 Aug 1 17:02:32 fire-in ahttp-gw[15822]: exit id=283 in=3416 out=240 Aug 1 17:02:32 fire-in gui[13316]: permit host=fire-in.trusted.com/10.0.1.159 use of server(5) Aug 1 17:02:32 fire-in gui[13316]: protocol=http file=/usr/local/etc/guidb/D/Dgui/Dimages/Hbackground00gif Aug 1 17:02:32 fire-in gui[13316]: exit in=32 out=3090 Aug 1 17:02:32 fire-in gui[13316]: permit host=fire-in.trusted.com/10.0.1.159 use of server(5) Aug 1 17:02:32 fire-in gui[13316]: protocol=http file=/usr/local/etc/guidb/D/Dgui/Dimages/Hiconbar-startup0gif Aug 1 17:02:32 fire-in gui[13316]: exit in=36 out=2999 Aug 1 17:02:32 fire-in gui[13316]: permit host=fire-in.trusted.com/10.0.1.159 use of server(5) Aug 1 17:02:32 fire-in gui[13316]: protocol=http file=/usr/local/etc/guidb/D/Dgui/Dimages/Hbanner-startup0gif Aug 1 17:02:32 fire-in gui[13316]: exit in=35 out=4425 Aug 1 17:02:32 fire-in ahttp-gw[15822]: exit id=285 in=3095 out=245 Aug 1 17:02:32 fire-in ahttp-gw[15822]: exit id=284 in=3186 out=241 |