17.1 Protecting Against Log-Altering Attacks

   

Log file security starts by protecting the files from being altered . Because log files are stored as plain text files it is very easy for an attacker who has gained access to a system to edit the log files and cover his or her tracks.

There are multiple methods to secure log files. These methods can be used alone, or in conjunction with others. The more log file security methods used, the more secure the logging infrastructure of the network will be.

Whenever possible, the logs from all network devices should be directed to a separate server. Most network devices, including routers, switches, firewalls, and servers, have the capability to do this. Storing log files on a secured remote server that is only accessed across a management network can be a primary step in securing the logging infrastructure. This will be discussed later in this chapter.

In cases where log files cannot be directed to a dedicated logging server, steps should be taken to secure the log files created on the server. This means protecting not only the log files but configuration files as well. If an attacker is prevented from accessing the log files, but can change the configuration that generates those files, a lot of damage can be done.

Only the administrative user for the system should be able to read and write to log files and make changes to the configuration information for those files. This means that no other groups should have any sort of access to the files. Even applications that are run by a nonprivileged user should be configured so that only the administrative user has access to the log files generated by the applications.

Of course, protection against nonadministrative users accessing the log files is pointless if an attacker is able to gain administrative access to the network device. To that end, the log files need to be protected against those who have gained unauthorized administrative access. The most common way to do this is to encrypt the log files.

Log file encryption is not supported in many applications, and there are some problems associated with encrypting log files. Most notably, encryption requires a lot of CPU usage, which can be a serious hindrance to a busy server. For example a busy website, with a lot of CGI and database calls, will create a heavy load on a web server. Adding the burden of encrypting log files in real time has the potential to slow a server to a crawl. This can be especially apparent while other CPU- intensive applications are running.

That is not to say that an administrator should not encrypt log files, but it is important to weigh the security needs against the available system resources of the network device. If a server is already heavily loaded an attacker might be able to force it offline by launching a DoS attack against it, forcing even heavier CPU usage because the device will have to encrypt all of the requests .

Products like Syslog-ng from BalaBit IT, Ltd., and Core Wisdom from Core Security Technologies can be used to encrypt log files on Unix servers, and ELM Log Manager from TNT Software for Windows servers. It is also possible to write custom applications to encrypt log files. The syslog daemon is open source, so the code is freely available, and Microsoft makes an API available for the Event Manager, which other programs can tie into.

NOTE

When encrypting log files never leave the encryption key on the server. A common mistake administrators make is to store the key in a file on the server, making it relatively simple for an attacker to find the key and use it to alter the log files.


Another way administrators protect against log-altering attacks is to write the log files to a write once, read many (WORM) device. A WORM device can be a CD-W, tape, or any type of storage media that support one-time only writing. Some SAN devices can be configured to support WORM mode, and some operating systems, BSD, for example, can support this mode as well.

When a storage device is in WORM mode, information can be appended to the log files, but the files themselves cannot be overwritten. As the name implies, the data contained within the files can be read repeatedly. It can even be extracted into a database or some other monitoring tool. But, once written into the file, the data cannot be overwritten, affording server administrators an additional level of protection.

Aside from being in WORM mode, the storage media should be either a separate partition, or at least the log files should be on a separate partition. If there is an attack designed to overload the logging system, the separate partition will limit the amount of damage an attack can do.

In extreme cases a printer can be used as a logging device. Log information is sent to the printer, then printed. This is not advised, as printed data is much more difficult to sort through to find patterns. Busy servers also generate a large amount of log files, and storing that amount of paper would quickly become difficult ”especially if an attacker intentionally floods the log files.

When log files cannot be propagated to a remote server, it is generally considered best practice to write the files to some form of WORM-enabled media. In addition, log files should have very restrictive permissions, only granting the administrative user the ability to read them. In most cases, this provides enough security. In extreme cases, encryption can be used, but again, weigh the use of encryption carefully against the performance of the network device.

   


The Practice of Network Security. Deployment Strategies for Production Environments
The Practice of Network Security: Deployment Strategies for Production Environments
ISBN: 0130462233
EAN: 2147483647
Year: 2002
Pages: 131
Authors: Allan Liska

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net