Firewall Fundamentals
| The information provided through the use of logging is arguably the most important tool that a firewall administrator has available. Through the use of logging, administrators gain tremendous insight as to the general health and status of their firewalls. I frequently equate the information gained from logging to being similar to how parents know what is going on with their children. Parents spend so much time with their kids that they just know when things are not right, and that allows them to intervene where necessary. Logging provides that kind of insight into the firewall. In fact, logging is really the only method most firewalls can use to inform an administrator what is going on. By collectingand, most important, by reviewingthe firewall logs, an administrator will rapidly learn the normal and abnormal behavior for the firewall, making it much easier to determine when and how to intervene where necessary to correct the situation. Generally speaking, there are two methods of logging:
The Syslog Protocol
The syslog protocol is the de facto standard method of providing event notification messages across the network. Syslog is defined by RFC 3164 and uses UDP as the default transport mechanism (by default and typically over UDP port 514). By using UDP, syslog gains the advantage of being a low-overhead connectionless delivery method (thus requiring less resources on the systems doing the logging), but that also results in syslog being an inherently unreliable delivery method. Although not common, this can result in messages being lost. To address this deficiency, many devices support using syslog over TCP to provide for reliable data delivery. This process is defined in RFC 3195. Syslog messages use what is known as a logging facility and severity level to determine where the message should be delivered and the importance of the message. The syslog protocol defines 24 logging facilities, as shown in Table 12-1.
The easiest way to think of the facility level is to think of each facility as a different pipe, allowing the syslog server to separate and distinguish messages that belong to different systems. The syslog server can then use this information to perform certain actions on messages from one facility while performing completely different actions on messages from other facilities, such as logging messages from each facility into unique files. Although there are 24 facilities, most firewalls use one of the 8 local-use facilities to define where the message originated from and is destined to. For example, the Cisco Secure PIX Firewall defaults to Local4 as the logging facility. The severity level is used to identify messages of different degrees of importance by grouping them into one of eight categories. Table 12-2 lists the different message severity levels.
The message severity is listed from highest to lowest importance, with Emergency messages being the highest importance and Debug messages being the lowest importance. As a general rule, it is a good idea when first implementing syslog to log only Information-level messages and above, and then restrict the logging even more as you fine-tune the messages that are important to you. For example, as a general rule, Cisco recommends that after the firewall is operational the logging severity level be set to either Warning or Error. The reason for this is that the lower the importance, the more potential messages that will be generated, which can put unnecessary stress and have a negative impact on the firewall performance. The flip side, of course, is that if you are not logging at a severity level that a given event is triggered under (for example, if you have set your logging to Warning but a Notice event occurs), that event will not be logged. You must determine for your environment the appropriate logging severity level. As shown in Figure 12-1, using syslog requires the implementation of a syslog client on the firewall and a syslog server somewhere on the network. Figure 12-1. Delivery of Syslog Messages Across the Network
The syslog client is then configured to deliver syslog messages to the syslog server. For example, you can configure a Cisco Secure PIX Firewall to use syslog by running the following basic commands. For Cisco Secure PIX Firewalls running versions of the PIX OS other than 7.0, the commands are as follows: logging on logging trap information logging host inside ip-address
For Cisco Secure PIX Firewalls running version 7.0 or later, you need to run the following commands from the configuration mode: logging enable logging trap information logging host inside ip-address In addition, I recommend that you log time stamps by running the following command for all versions of PIX OS 6.3 and greater (this only applies to log messages sent to the syslog server): firewall(config)# logging timestamp If you require the firewall to log using a different facility (for example, from the default Cisco PIX logging facility of 20 or local4), you can run the following command to change the logging facility, in this case changing it to Local1 (logging facility code 17, as displayed in Table 12-1): firewall(config)# logging facility 17
Configuring the syslog server to receive the syslog message depends largely on the syslog server software that you decide to run. Virtually all versions of UNIX and Linux ship with a built-in syslog server. In addition, a number of freeware as well as commercial syslog server products are available on the market, including the following:
Figure 12-2. Kiwi Syslog Daemon
All of these products do a good job at monitoring small- to medium-size environments. If you have an enterprise or large network with a lot of firewalls that generate a large number of syslog messages, however, consider implementing more specialized security incident management (SIM) and log management applications, such as the following:
Syslog Security Deficiencies
When you implement syslog, you need to be aware of a couple of significant security deficiencies with regard to how syslog data is delivered across the network. First, by default, syslog uses UDP as the transport mechanism, which makes it easy to spoof syslog messages. This could allow attackers to generate bogus log entries in an attempt to masquerade what they are really doing. The use of UDP also means that there is no way to ensure the successful delivery of syslog message. To address this issue, some firewalls implement syslog over TCP, which does not necessarily prevent spoofing but does make it a quite a bit more difficult to pull off. Using syslog over TCP also provides for guaranteed delivery of all syslog messages, albeit generally at a performance impact on the firewall. The following is a sample of enabling syslog over TCP on all versions of the Cisco Secure PIX Firewall: firewall(config)# logging host inside 192.168.1.110 tcp/1470
In this case, syslog has been configured to use TCP port 1470 (which is the default TCP port that Cisco uses) to communicate with the syslog server located at IP address 192.168.1.110. Keep in mind that your syslog server will also need to be configured to accept syslog messages over TCP. Refer to your syslog server documentation for instructions on how to do this. Caution When you configure the PIX Firewall to use TCP as the syslog delivery mechanism and the PIX Firewall cannot for some reason communicate with the syslog server (for example, the syslog server is down), by default the firewall will stop delivering all data (not just all syslog data, but all data effectively causing the firewall to fail closed). With PIX OS versions 7.0 and above, you can prevent the firewall from stopping delivering data by running the command logging permit-hostdown from the global configuration mode. Unless you require TCP, I recommend not implementing it. Another security deficiency of syslog is the lack of any method of performing authentication of the message sender, the lack of any method of providing message integrity, and the inability to ensure the privacy of the data through the use of encryption. No native methods within syslog address any of this. Instead, if you require the secure transmission of syslog data, encapsulate the data using a protocol such as IPsec. For more information about encapsulating syslog traffic in IPsec, see Chapter 10 of Hardening Network Infrastructure (Osborne/McGraw-Hill). Proprietary Logging Methods
Proprietary logging is a bit of a misnomer because many firewalls that do not implement syslog use a standard logging methodology developed by Check Point known as Open Platform for Security - Logging Export API (OPSEC LEA). Fundamentally, OPSEC LEA is similar to syslog in that you will need a logging server to retrieve the log information using OPSEC LEA procedure call. Other firewalls, such as Microsoft ISA Server 2004, use largely proprietary (or rather non-syslog-based) logging methods to log events to a database, typically a Microsoft Data Engine (MSDE) or Structure Query Language (SQL) database. One of the advantages of this kind of logging system is the ability to then be able to build and issue custom queries against the data in the database, providing tremendous functionality and flexibility for building reports. By default, the Microsoft ISA Server 2004 logging data is accessed via the ISA Server Management Console, as shown in Figure 12-3. Figure 12-3. Microsoft ISA Server Log Data
Why Logging Is Important
It is easy to say that you should log events from your firewalls because doing so provides insight as to the status of your firewall, but there are a number of specific and tangible benefits to logging:
Improved Network Administration, Troubleshooting, and Debugging
If there is one certainty in firewall administration, it is that sooner or later you will need to determine why traffic that should be permitted by the firewall is not being permitted. There are literally dozens of reasons why the firewall may not be allowing the traffic, and the easiest method of determining which reason is the cause is to put the firewall into a debugging mode and then observe the logged data to identify the error or reason why the firewall is not allowing the traffic to pass. Be aware that debug logging can negatively affect firewall performance. In addition, logging events from the firewall also reduces the time required to identify, troubleshoot, and isolate problems with the firewall. This frees the firewall administrator up to perform other administration tasks. In fact, one of the first troubleshooting steps when working with firewalls is to check the firewall logs to determine whether they can provide any insight on the current issue. Establishing a Baseline
The only effective method of determining what is normal and secure behavior for a firewall is to monitor the firewall events and identify patterns of activity. Doing so will provide a baseline that makes it much easier to identify when situations are occurring that are outside of the scope of normal operations and functionality. For example, it is quite routine and normal for a firewall to block all sorts of traffic. By monitoring the firewall logs, you can develop a baseline of the kinds of traffic that are typically denied. Doing so makes it much easier to notice exceptions to the baseline, which in turn makes it easier to identify situations and circumstances that warrant additional investigation. Determining the Health of the System
In conjunction with establishing a baseline, your firewall logs can also be used to determine what the health of the system is. By comparing the current logs to the known baseline, it is much easier to identify conditions that may result in negative performance. Doing so enables you to solve the issues that may be leading to the negative impact in a much more proactive fashion. Intrusion Detection and Incident Containment
One of the most important reasons for monitoring your firewall logs is that the logs can alert you to potential security compromises and security incidents. I am reminded of a news story I read about a company that discovered their proprietary information had been compromised when they found their internal documentation when performing a search of the Internet. When a legal investigation was launched, it was discovered that the firewall logs contained information relating to the security breach. Because no one was routinely monitoring the logs, however, this information went undetected. Had someone been monitoring the logs, the incident might have been preventable. Performing Forensic Analysis
The odds are that sooner or later you will have to deal with a security incident in your organization. The simple fact of the matter is that it is impossible to prevent every security incident, all the time. When the security incident occurs, one of the most important questions that will be asked is this: what happened? By collecting and archiving your firewall logs, you greatly increase your ability to determine what occurred so that you can begin the process of recovering from the incident. In addition, this information can be critical evidence in the event that legal action is necessary. To ensure the legal admissibility of your firewall logs, it is critical that your logging system provide a means of demonstrating that the logs have been unaltered and the data contained in the logs is accurate and adheres to the rules of chain of custody (for more information about the chain of custody, see http://www.cert.org/security-improvement/practices/p048.html). Many enterprise logging products provide this functionality as a standard function of their product. If your product does not do this, you can implement third-party solutions such as FSUM (http://www.slavasoft.com/fsum/) to provide file integrity checking and to ensure that the logs have not been altered (especially if the logs are written to a write once, read many [WORM] drive or similar media). Always review all data evidence policies with your organization's legal department to ensure that the process you are following will be admissible in court. |
Категории