Events indicate the presence of an attack; but determining who, how and why an attack is taking place can be difficult. Often, a single event is not enough to analyze an attack, but several simple events taken together can elicit more detailed information.
Certain types of well known attacks can be identified by signatures. The signature feature is described later in this manual.
This section provides advice on what to look for and how to interpret specific indications, when a signature has not detected the nature of an attack.
New attack patterns are constantly evolving and a hacker may do their best to hide the purpose of the attacks.
The event type is the first thing to check. These are the three main types Connection Most events are connections and are caused by a client connecting to an open port on the sensor machine. These types of events provide the most information. Closed Port If a client tries to connect to a port with no service running on it then the host machine will immediately reject the connection attempt immediately. If there are a number of events on the same closed port number then it is worth defining a Listen definition on that port to gather more information on the purpose of that attack. Scan
Stealth scans cover a range of techniques used by hackers and pen testers to identify hosts, fingerprint OS versions and to determine which ports are open on a host. These techniques involve sending non-standard network packets or non-standard packet sequencing gain a response from a host without establishing a full connection. These are rarely recorded in system log files and can evade detection by certain security products such as firewalls.
nmap is the most popular stealth scanning tool.
When a network event can be positively identified as a scan then the event is assigned the event type "Scan". Previously these would have been recorded as type "Connection". An event with the type Scan is a much clearer indicator of malicious activity than a connection.
nmap Options decoded
Where possible a scan is decoded to show the nmap option that matches the scan technique. The event's Description field contains the matching nmap command line option.
The following options are individually identified:
Different services are expected to run on certain ports. For example, if an event occurs on port 80 then it is most likely an attack directed against a web server. Use the port number and Listen name to give you an indication of what the attack is likely to be directed at.
The event's Received data field contains the data sent to KFSensor by the visitor. Interpreting this data is the most important way of identifying the nature of the attack. This will not be available if the listen definition is set to 'Close'.
If the received data field is empty then this could indicate a system scan. A scanner may simply close the connection immediately after it has been opened as it may only be looking for the presence of open ports. If this is the case the Closed By field will indicate that the connection was closed by the visitor.
The received data is likely to be either a simple and legitimate request designed to get a server to display its version information, or may be a direct attempt to exploit a vulnerability.
The following data is an example from a Nimba attack attempting to exploit a trojan left by Code Red on port 80 of an infected IIS web server.
|
GET /scripts/root.exe?/c+dir HTTP/1.0 Host: www Connection: close |
Although this example is a well formed HTTP request it is very different in format to an HTTP request from a browser.
The Visitor's IP address field gives you the IP address of the machine that generated the event.
If the IP address is within the following range it indicates a private IP address that must be on your local area network and not from the public Internet.
The domain name field of the visitor that generated the event. This is obtained by a reverse DNS lookup on the visitor's IP address. It may not be possible to perform a reverse look up or the DNS server may have been compromised, so if in doubt rely on the IP address and not the domain name.
In the case of a UDP connection it is possible for a hacker to spoof the IP address, but this is not possible for a TCP connection.
Although the IP address shows where the connection was made from the attack may not have originated from that machine. Proxy servers, firewalls and trojans can be used to relay a request, so the hacker's machine may be hidden. This is a favorite trick of experienced hackers to cover their tracks. To find the hacker's machine it is necessary to consult the logs of the machine that made the request. This can be difficult or impossible, particularly if it is coming from a trojan installed on a home user's machine.
If a number of events occur on the same port in quick succession, (often several a second) then it is likely that an automated vulnerability scan is being run against a particular service. For example Whisker is a web server vulnerability scanner that runs numerous HTTP requests looking for different vulnerabilities.
A more slower and erratic request may indicate a human presence.
A large interval between events may indicate a slow scan. Some automated scanners are deliberately run slowly to try and avoid a network based IDS.
If connections are made to more than one port then this indicates a system scan. Such a scan is designed to fingerprint a server by examining all the services that are running on a particular machine.
Next: Visitor Rules