Specifications

Recognizing an Intrusion
First, understand which actions are defined as intrusions. Unfortunately, it
is normal these days that a host connected to the Internet will be scanned
for open and vulnerable ports. It is just as common that ports recognized
as vulnerable (such as POP3, qpopper, rpc-mountd, smtp, or sendmail) are
attacked. Most of these attacks are carried out by “script kiddies”. Pre-
fabricated “exploits” published on relevant web sites (e. g., http://www.
rootshell.com) are used. These web pages also exist as valuable infor-
mation sources for network and system administrators. They can usually
be identified by the fact that the hack is only carried out once and is not
repeated if the action fails on the first attempt. The first measure to take in
case of such an event is to check if a break-in really did happen. Further-
more, raise the log level, for example by logging accepted packets (expert
configuration of IP filter and NAT module), and refine the evaluation (e. g., a
selective search aimed at an intruding IP address in the log files or any un-
usual port numbers).
Determine for yourself what is a dangerous attack on your system. At least
determine how to react to such an event. The following literature is recom-
mended if you suspect an intrusion: “Steps for Recovering from a Unix Root
Compromise” (
http://www.cert.org/tech_tips/root_compromise.
html) and RFC 2196 Site Security Handbook. Both publications describe pro-
cedures that should follow any successful break-in. The documents provide
a formal starting point as to how a company, agency, or educational institu-
tion can react. The procedure discussed there necessitates a certain amount
of memory to take “snapshots” of the system and requires colleagues to
carry out the analysis and to examine the security problem. Situations are
described that may necessitate taking punitive action.
Responding to an Intrusion
If you suspect a successful attack:
It is important to stay calm. Hasty actions can destroy important infor-
mation (e. g., processes initiated by the cracker that contain information
about what the cracker is doing or how he is attacking).
The course of action, as well as who to inform, should be outlined in
the security policy. The communication should not take place by e-
mail, but by telephone or fax.
Physically cut the network connection to the firewall. It is not a good
idea to shut down the computer. Important information could be lost,
such as programs started by the cracker.
144 Detecting Attacks