14.2.3. Creating Rules
Each rule creation requires one invocation of iptables/ip6tables. Typing these commands manually can be tedious, so the calls are usually stored in a script so that the same configuration is set up automatically every time the machine boots. This script can be written by hand, but it can also be interesting to prepare it with a high-level tool such as fwbuilder.
The principle is simple. In the first step, one needs to describe all the elements that will be involved in the actual rules:
the firewall itself, with its network interfaces;
the networks, with their corresponding IP ranges;
the servers;
the ports belonging to the services hosted on the servers.
The rules are then created with simple drag-and-drop actions on the objects. A few contextual menus can change the condition (negating it, for instance). Then the action needs to be chosen and configured.
As far as IPv6 is concerned, one can either create two distinct rulesets for IPv4 and IPv6, or create only one and let fwbuilder translate the rules according to the addresses assigned to the objects.
Figure 14.2. Fwbuilder's main window
fwbuilder can then generate a script configuring the firewall according to the rules that have been defined. Its modular architecture gives it the ability to generate scripts targeting different systems (iptables for Linux 2.4/2.6, ipf for FreeBSD and pf for OpenBSD).
Versions of the fwbuilder package since Squeeze contain both the graphical interface and the modules for each firewall system (these were previously split over several packages, one for each target system):
# aptitude install fwbuilder
14.2.4. Installing the Rules at Each Boot
If the firewall is meant to protect an intermittent PPP network connection, the simplest way to deploy the script is to install it as /etc/ppp/ip-up.d/0iptables (note that only files without a dot in their name are taken into account). The firewall will thus be reloaded every time a PPP connection is established.
In other cases, the recommended way is to register the configuration script in an up directive of the /etc/network/interfaces file. In the following example, the script is stored under /usr/local/etc/arrakis.fw.
Example 14.1. interfaces file calling firewall script
auto eth0
iface eth0 inet static
address 192.168.0.1
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
up /usr/local/etc/arrakis.fw
14.3. Supervision: Prevention, Detection, Deterrence
Monitoring is an integral part of any security policy for several reasons. Among them, that the goal of security is usually not restricted to guaranteeing data confidentiality, but it also includes ensuring availability of the services. It is therefore imperative to check that everything works as expected, and to detect in a timely manner any deviant behaviour or change in quality of the service(s) rendered. Monitoring activity can enable the detection of intrusion attempts and enable a swift reaction before they cause grave consequences. This section reviews some tools that can be used to monitor several aspects of a Debian system. As such, it completes the section dedicated to generic system monitoring in Chapter 12, Advanced Administration.
14.3.1. Monitoring Logs with logcheck
The logcheck program monitors log files every hour by default. It sends unusual log messages in emails to the administrator for further analysis.
The list of monitored files is stored in /etc/logcheck/logcheck.logfiles; the default values work fine if the /etc/syslog.conf file has not been completely overhauled.
logcheck can work in one of three more or less detailed modes: paranoid, server and workstation. The first one is very verbose, and should probably be restricted to specific servers such as firewalls. The second (and default) mode is recommended for most servers. The last one is designed for workstations, and is even terser (it filters out more messages).
In all three cases, logcheck should probably be customized to exclude some extra messages (depending on installed services), unless the admin really wishes to receive hourly batches of long uninteresting emails. Since the message selection mechanism is rather complex, /usr/share/doc/logcheck-database/README.logcheck-database.gz is a required — if challenging — read.
The applied rules can be split into several types:
those that qualify a message as a cracking attempt (stored in a file in the /etc/logcheck/cracking.d/ directory);
those cancelling such a qualification (/etc/logcheck/cracking.ignore.d/);
those classifying a message as a security alert (/etc/logcheck/violations.d/);
those cancelling this classification (/etc/logcheck/violations.ignore.d/);
finally, those applying to the remaining messages (considered as system events).
CAUTION Ignoring a message
Any message tagged as a cracking attempt or a security alert (following a rule stored in a /etc/logcheck/violations.d/myfile file) can only be ignored by a rule in a /etc/logcheck/violations.ignore.d/myfile or /etc/logcheck/violations.ignore.d/myfile-extension file.
A system event is always signaled unless a rule in one of the /etc/logcheck/ignore.d.{paranoid,server,workstation}/ directories states the event should be ignored. Of course, the only directories taken into account are those corresponding to verbosity levels equal or greater than the selected operation mode.
TIP Your logs as screen background
Some administrators like seeing their log messages scroll by in real time; the root-tail command (in the root-tail) package can be used to integrate the logs into the background of their graphical desktop. The xconsole program (in the x11-apps package) can also have them scrolling in a small window. Messages are directly taken from syslogd via the /dev/xconsole named pipe.
14.3.2. Monitoring Activity
14.3.2.1. In Real Time
top is an interactive tool that displays a list of currently running processes. The default sorting is based on the current amount of processor use and can be obtained with the P key. Other sort orders include a sort by occupied memory (M key), by total processor time (T key) and by process identifier (N key). The k key allows killing a process by entering its process identifier. The r key allows renicing a process, i.e. changing its priority.
When the system seems to be overloaded, top is a great tool to see which processes are competing for processor time or consume too much memory. In particular, it is often interesting to check if the processes consuming resources match the real services that the machine is known to host. An unknown process running as the www-data user should really stand out and be investigated, since it's probably an instance of software installed and executed on the system through a vulnerability in a web application.