Attack Indications

---

To detect security policy violations within a controlled area (network traffic of log file), it is necessary to know how to identify them and how to distinguish them from normal security events. The following events can be considered to be attack indications [Edward1-99]:

• Repeated occurrence of specific events

• Incorrect commands or commands that do not correspond to the current situation

• Exploiting vulnerabilities

• Inappropriate parameters of the network traffic

• Unexpected attributes

• Inexplicable problems

• Additional information on security violations

Any security tool (firewalls, authentication servers, access control systems, and so on) use one or two of the above-listed conditions, while intrusion detection systems (depending on the implementation) employ nearly all attack indications.

This chapter will help you understand how intrusion detection systems make decisions. It is also aimed at helping developers create custom systems for detection intrusions or unauthorized activity. This especially relates to those application developers working on financial applications or automated systems for communications. Furthermore, the description of the indications of the unauthorized activity will be useful if you have no automated intrusion detection system at your disposal and therefore need to detect these indications manually.

Repeated Occurrence of Specific Events

Recognizing specific actions or events that take place repeatedly represents one of the best methods of intrusion detection. This mechanism is based on the assumption that, if the first attempt has failed, the intruder repeats his attempts of unauthorized access to a specific resource. For example, port scanning in order to find available network services or any attempts of guessing the password can be considered to be such an attempt. Algorithms used for detecting unauthorized activity must recognize such repeated attempts and decide how many additional attempts are, in fact, indications of an attack. It should be noted that, if the intruder knows for sure how to access the resource (or manages to intercept or guess the ID and password of the authorized user) and does not make any errors, his attempt to gain unauthorized access would be practically impossible to detect. If the intruder manages to create an exact working model of the attack target, and has some practice in how to imitate authorized users, these actions will most probably also go unnoticed. However, creating an entirely identical working model of the attack target is very expensive, and most intruders acting on their own (or even those in organized hacker communities) can not afford it.

Detecting of repeated events represents a powerful approach, since it allows detection even of those attacks about which there is no additional information (in other words, it allows the detection of unknown attacks of a specific type). Either (or both) of the following events can be used as a criterion:

• The number of repeated events exceeds a specific threshold value (for example, the permitted number of network logons might be exceeded).

• Events are repeated within a specified time interval (for example, an attempt to connect host ports).

Controlling Threshold Values

In this case, one controls a specific threshold value in order to distinguish authorized repeated events from unauthorized ones. Unauthorized repeated events may correspond both to normal errors and to actual attacks. In any case, the system will detect every situation in which the threshold value has been exceeded. Based on practical experience, one can specify custom threshold values for different system components. Specifying the allowed number of login attempts is a typical example of controlling the threshold value. Setting a maximum number of permitted login attempts in Windows 2000 is a typical example of specifying a threshold value (Fig. 4.1).

Fig. 4.1. Specifying the maximum number of login attempts permitted in Windows 2000

Notice that incorrect selection of the threshold value might result in a false negative or a false positive problem. In other words, if the specified threshold value is too low, all control will be reduced to frequent activation of the intrusion detection system, i.e., false detection. On the other hand, if you specify a large value, some attacks will not be detected.

Attack on the Network of Westminster Bank 

A teller of Westminster Bank in Great Britain established a dial-up connection to the bank network from his home computer. After that, he performed 1,200 transactions, each time transferring £10 to his account. The security service did not notice it, since transfers of small amounts of money were not controlled at all. However, when he wanted to make a larger stake and transferred £984,252 to his friend's account, this event was immediately noticed. The bank fined the teller and demanded compensation in the sum of £15,000. However, the court dismissed this claim and even charged the bank for its inability to protect its own security.

Controlling Time Intervals

A typical example illustrating this method is the detection of port scanning (Listing 4.1), i.e., detecting the specified number of attempts to access host ports during a specified time interval. From now on, all fragments of listings that deserve special attention appear in bold. Also, I would like to emphasize the fact that most of the listing examples provided in this and subsequent sections were taken from http://www.incidents.org/logs/, or are based on practical exercises performed within the framework of preparing for the Global Information Assurance Certification (GIAC) Certified Intrusion Analyst exam (http://www.giac.org/GCIA.php). Port scanning can be performed using various programs, which differ in the implementation of this mechanism. The simplest programs, such as Haktek, just try all the ports, starting with the first and ending with the user-specified port (Listing 4.1).

Listing 4.1. Port Scanning Implemented Using Haktek (TCPdump Log File)

   17:17:21.966870 WS_LUKICH.2876 > WS_LUKA.1: S 713310:713310(0) win 8192   <mss 1460> (DF)   17:17:21.967698 WS_LUKICH.2877 > WS_LUKA.2: S 713329:713329(0) win 8192   <mss 1460> (DF)   17:17:21.968612 WS_LUKICH.2878 > WS_LUKA.3: S 713349:713349(0) win 8192   <mss 1460> (DF)   17:17:21.969095 WS_LUKICH.2879 > WS_LUKA.4: S 713364:713364(0) win 8192   <mss 1460> (DF)   17:17:21.969574 WS_LUKICH.2880 > WS_LUKA.5: S 713372:713372(0) win 8192   <mss 1460> (DF)   17:17:21.970041 WS_LUKICH.2881 > WS_LUKA.6: S 713381:713381(0) win 8192   <mss 1460> (DF)   17:17:21.970523 WS_LUKICH.2882 > WS_LUKA.7: S 713391:713391(0) win 8192   <mss 1460> (DF)   17:17:21.971031 WS_LUKICH.2883 > WS_LUKA.8: S 713402:713402(0) win 8192   <mss 1460> (DF)   17:17:21.971539 WS_LUKICH.2884 > WS_LUKA.9: S 713414:713414(0) win 8192   <mss 1460> (DF)   17:17:21.972014 WS_LUKICH.2885 > WS_LUKA.10: S 713427:713427(0) win 8192   <mss 1460> (DF)   17:17:21.973780 WS_LUKICH.2886 > WS_LUKA.11: S 713441:713441(0) win 8192   <mss 1460> (DF)   17:17:21.973814 WS_LUKICH.2887 > WS_LUKA.12: S 713455:713455(0) win 8192   <mss 1460> (DF)   17:17:21.973834 WS_LUKICH.2888 > WS_LUKA.13: S 713469:713469(0) win 8192   <mss 1460> (DF) 

Note that the incorrect selection of the time interval when controlling the threshold value can also result in false negative and false positive problems described in the previous section.

Recognizing such activities is relatively easy. However, such port scanners are used rarely and only by inexperienced users who do not know that there are more advanced and intelligent utilities. A good example of such a tool is Nmap (http://www.nmap.org), which runs in most Unix clones as well as in Windows. This utility implements a significant number of scanning types — for example, version 3.00 provides more than 10 scanning algorithms, including port scanning (Listings 4.2 to 4.4).

Listing 4.2. Port Scanning (-sT) Using Nmap (a Fragment of the TCPdump Log File)

   17:26:48.031721 WS_LUKA.2797 > WS_LUKICH.371: S 26274004:26274004(0) win   8192 <mss 1460> (DF)   17:26:48.034533 WS_LUKA.2798 > WS_LUKICH.344: S 26330728:26330728(0) win   8192 <mss 1460> (DF)   17:26:48.035510 WS_LUKA.2799 > WS_LUKICH.919: S 26396113:26396113(0) win   8192 <mss 1460> (DF)   17:26:48.036466 WS_LUKA.2800 > WS_LUKICH.1155: S 26439772:26439772(0) win   8192 <mss 1460> (DF)   17:26:48.037421 WS_LUKA.2801 > WS_LUKICH.117: S 26476417:26476417(0) win   8192 <mss 1460> (DF)   17:26:48.038372 WS_LUKA.2802 > WS_LUKICH.625: S 26518671:26518671(0) win   8192 <mss 1460> (DF)   17:26:48.039338 WS_LUKA.2803 > WS_LUKICH.220: S 26552575:26552575(0) win   8192 <mss 1460> (DF)   17:26:48.040281 WS_LUKA.2804 > WS_LUKICH.770: S 26588454:26588454(0) win   8192 <mss 1460> (DF)   17:26:48.041235 WS_LUKA.2805 > WS_LUKICH.619: S 26633584:26633584(0) win   8192 <mss 1460> (DF)   17:26:48.042170 WS_LUKA.2806 > WS_LUKICH.1652: S 26670889:26670889(0) win   8192 <mss 1460> (DF)   17:26:48.043264 WS_LUKA.2807 > WS_LUKICH.403: S 26734852:26734852(0) win   8192 <mss 1460> (DF) 

Listing 4.3. Port Scanning (-sS) Using Nmap (a Fragment of the TCPdump Log File)

   17:22:32.224567 WS_LUKA.52753 > WS_LUKICH.1544: S 866284386:866284386(0) win 1024   17:22:32.225413 WS_LUKA.52753 > WS_LUKICH.427: S 866284386:866284386(0) win 1024   17:22:32.225413 WS_LUKA.52753 > WS_LUKICH.447: S 866284386:866284386(0) win 1024   17:22:32.224845 WS_LUKA.52753 > WS_LUKICH.496: S 866284386:866284386(0) win 1024   17:22:32.225009 WS_LUKA.52753 > WS_LUKICH.597: S 866284386:866284386(0) win 1024   17:22:32.225207 WS_LUKA.52753 > WS_LUKICH.659: S 866284386:866284386(0) win 1024   17:22:32.225413 WS_LUKA.52753 > WS_LUKICH.159: S 866284386:866284386(0) win 1024   17:22:32.225582 WS_LUKA.52753 > WS_LUKICH.529: S 866284386:866284386(0) win 1024   17:22:32.225782 WS_LUKA.52753 > WS_LUKICH.2017: S 866284386:866284386(0) win 1024   17:22:32.225413 WS_LUKA.52753 > WS_LUKICH.427: S 866284386:866284386(0) win 1024   17:22:32.225945 WS_LUKA.52753 > WS_LUKICH.1380: S 866284386:866284386(0) win 1024   <99>   17:22:32.226153 WS_LUKA.52753 > WS_LUKICH.1522: S 866284386:866284386(0) win 1024   17:22:32.226356 WS_LUKA.52753 > WS_LUKICH.1109: S 866284386:866284386(0) win 1024   17:22:32.231078 WS_LUKA.52753 > WS_LUKICH.306: S 866284386:866284386(0) win 1024   17:22:32.233200 WS_LUKA.52753 > WS_LUKICH.274: S 866284386:866284386(0) win 1024   17:22:32.225413 WS_LUKA.52753 > WS_LUKICH.447: S 866284386:866284386(0) win 1024   17:22:32.235295 WS_LUKA.52753 > WS_LUKICH.1663: S 866284386:866284386(0) win 1024 

Listing 4.4. Port Scanning (-sU) Using Nmap (a Fragment of the TCPdump Log File)

   17:30:03.034865 WS_LUKA.48796 > WS_LUKICH.670: udp 0   17:30:03.035066 WS_LUKA.48796 > WS_LUKICH.1248: udp 0   17:30:03.035269 WS_LUKA.48796 > WS_LUKICH.25: udp 0   17:30:03.035448 WS_LUKA.48796 > WS_LUKICH.1017: udp 0   17:30:03.035653 WS_LUKA.48796 > WS_LUKICH.1415: udp 0   17:30:03.035815 WS_LUKA.48796 > WS_LUKICH.963: udp 0   17:30:03.036006 WS_LUKA.48796 > WS_LUKICH.11: udp 0   17:30:03.036160 WS_LUKA.48796 > WS_LUKICH.345: udp 0 

All three fragments of the TCPdump log file presented above are very interesting, since the number of the scanned port is not incremented by 1, which is what happens normally, but rather in a random way. In order to complicate the detection of port scanning, the port number is both increased and decreased. An additional mechanism, concealing the fact of scanning to deceive intrusion detection systems, implies repeat scanning of some ports that were already scanned (for example, 427 and 447).

Besides the classical types of scanning, easily detected by firewalls (Listing 4.5), there are more sophisticated methods of searching for vulnerabilities that can not be detected using traditional network security tools. These include so-called stealth scanning, which uses specific features characteristic for processing network packets that do not correspond to TCP/IP standards. Such methods of scanning will be covered later.

Listing 4.5. Detecting Host Scanning (a Fragment of the Check Point Firewall-1 Log File)

   "421316" "29Dec2000" "9:32:16" "daemon" "localhost" "alert" "accept" "" "x.x.x.x" "x.x.x.x" "ip" "" "" "" "" "" "" "" "" "" "" ""   MAD" "additionals:attack=blocked_connection_port_scanning"   "422255" "29Dec2000" "9:33:59" "daemon" "localhost" "alert" "accept"   "" "x.x.x.x" "x.x.x.x" "ip" "" "" "" "" "" "" "" "" "" "" ""   "MAD" "additionals:attack=blocked_connection_port_scanning"   "427220" "29Dec2000" "9:43:26" "daemon" "localhost" "alert" "accept"   "" "" "x.x.x.x" "x.x.x.x" "ip" "" "" "" "" "" "" "" "" "" "" ""   "MAD" "additionals: attack=blocked_connection_port_scanning" 

Another sophisticated scanning method that complicates scanning detection implies increasing the time interval during which scanning takes place. Usually, host scanners send requests at a rate of approximately 5 to 10 ports per second. If we change the default time settings (for example, the -SI mode of the Nmap 3.00 scanner, or the -T mode in Nmap 2.xx), most intrusion detection systems will not react to such activities, since they interpret it as normal (Listing 4.6).

Listing 4.6. Host Scanning (a Fragment of the TCPdump Log File)

   12:01:38.234455 200.0.0.200 > 200.0.0.67:icmp: echo request   12:03:51.543524 200.0.0.200 > 200.0.0.87:icmp:echo request   12:05:04.655342 200.0.0.200 > 200.0.0.134:icmp:echo request   12:07:18.573256 200.0.0.200 > 200.0.0.23:icmp:echo request   12:09:31.676899 200.0.0.200 > 200.0.0.11:icmp:echo request   12:11:44.896754 200.0.0.200 > 200.0.0.104:icmp:echo request   12:13:57.075356 200.0.0.200 > 200.0.0.2:icmp:echo request 

Controlling time intervals can also be used for detecting Denial of Service attacks. For example, the Smurf attack is characterized by the usage of broadcast packets transmitted for quite a long time interval. There have been some cases in which such packets were sent for several days, thus causing the attacked network to fail, due to its inability to process authorized traffic. Below, I provide a fragment of the Cisco router log file (Listing 4.7), where examples of the Smurf and Fraggle attacks are registered (Fraggle is similar to Smurf, but intended for the UDP protocol). In real-world practice, the number of such records will significantly exceed 100.

Listing 4.7. Detection of the SMURF and Fraggle Attacks (a Fragment of the Cisco Router Log File)

   Dec 22 16:15:26: %SEC-6-IPACCESSLOGDP:list Internet denied   icmp 172.20.20.1 ->200.0.0.255 (8/0), 1 packet   Dec 22 16:16:26: %SEC-6-IPACCESSLOGDP:list Internet denied   icmp 172.20.20.2 ->200.0.0.255 (8/0), 24 packets   Dec 22 16:16:56: %SEC-6-IPACCESSLOGP: list Internet denied udp 172.20.20.3(21820) ->200.0.0.255 (19), 1 packet   Dec 22 16:26:26: %SEC-6-IPACCESSLOGDP:list Internet denied   icmp   172.20.20.4 ->200.0.0.255 (8/0), 3 packets   Dec 22 16:27:26: %SEC-6-IPACCESSLOGDP:list Internet denied icmp   172.20.20.5 ->200.0.0.255 (8/0), 4 packets 

Incorrect Commands

Another method of identifying unauthorized activity involves detection of invalid or incorrect requests or responses expected from automated processes or programs. Lack of correspondence to the expected reactions enables us to come to the conclusion that one of the participants of the information exchange — either the one requesting information or the one returning the answer — has been replaced. It is impossible to illustrate the detection of various invalid or incorrect commands within a single book. Therefore, I will concentrate only on the most typical examples of incorrect command usage. As an example, let us consider vulnerable CGI scripts on the web server (as was shown in Chapter 2, this is one of the most common vulnerabilities all over the world). In the example provided below, a request for two non-existent CGI scripts — namely, Glimpse cgi-bin and test-cgi — can be detected by analyzing records of the server log file, or by using a network intrusion detection system (Listings 4.8 and 4.9).

Listing 4.8. Detecting Scanning for Vulnerable CGI Scripts (a Fragment of the WWW Server Log File)

   Mon Dec 27 01:42:58 1999] [error] [client 172.20.20.1] File does not   exist:/web/home/www/www_home/cgi-bin/aglimpse   [Mon Dec 27 01:42:58 1999] [error] [client 172.20.20.1] File does not   exist:/web/home/www/www_home/scripts/iisadmin/bdir.htr   [Mon Dec 27 01:42:58 1999] [error] [client 172.20.20.1] File does not   exist:/web/home/www/www_home/cgi-dos/args.bat   [Mon Dec 27 01:42:58 1999] [error] [client 172.20.20.1] File does not   exist:/web/home/www/www_home/cgi-bin/AnyForm2   [Mon Dec 27 01:42:58 1999] [error] [client 172.20.20.1] File does not   exist:/web/home/www/www_home/cgi-bin/campas   [Mon Dec 27 01:42:58 1999] [error] [client 172.20.20.1] File does not   exist:/web/home/www/www_home/cgi-bin/Count.cgi   [Mon Dec 27 01:42:58 1999] [error] [client 172.20.20.1] File does not   exist:/web/home/www/www_home/carbo.dll   [Mon Dec 27 01:42:58 1999] [error] [client 172.20.20.1] File does not   exist:/web/home/www/www_home/cgi-bin/finger   [Mon Dec 27 01:42:58 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/ogi-bin/faxsurvey   [Mon Dec 27 01:42:58 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/ogi-bin/htmlscript   [Mon Dec 27 01:42:58 1999] [error] [client 172.20.20.1] File does not   exist: /www/home/www/www_home/ogi-bin/handler   [Mon Dec 27 01:42:58 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/ogi-bin/man.sh   [Mon Dec 27 01:42:59 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/ogi-bin/jj   [Mon Dec 27 01:42:59 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/ogi-bin/pfdispaly.ogi   [Mon Dec 27 01:42:59 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/ogi-bin/nph-test-ogi   [Mon Dec 27 01:42:59 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/cgi-bin/php.cgi   [Mon Dec 27 01:42:59 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/cgi-bin/phf   [Mon Dec 27 01:42:59 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/search97.vts   [Mon Dec 27 01:42:59 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/cgi-bin/test-cgi   [Mon Dec 27 01:42:59 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/cgi-win/uploader.exe   [Mon Dec 27 01:42:59 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/cgi-bin/textcounter.p1   [Mon Dec 27 01:42:59 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/cgi-bin/view-source   [Mon Dec 27 01:43:00 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/cgi-bin/webdist.cgi   [Mon Dec 27 01:43:00 1999] [error] [client 172.20.20.1] File does not exist: /web/home/www/www_home/cgi-bin/websendmail   [Mon Dec 27 01:43:00 1999] [error] [client 172.20.20.1] File does not   exist: /web/home/www/www_home/cgi-bin/webgais   [Mon Dec 27 01:43:00 1999] [error] [client 172.20.20.1] File does not exist: /web/home/www/www_home/cgi-bin/www-sql 

Listing 4.9. Detecting Requests to Vulnerable CGI Scripts Such as Test-cgi and Aglimpse (a Fragment of the Snort Log File)

   22:00:08.952175 200.0.0.104.53558 > 200.0.0.110.80: P   1677621322:1677621391(69) ack 2335601879 win 8760 (DF) (tt1 242, id 12223)   0000:4500 006d 2fbf 4000 f206 0465 80af 0d4a E..m/.@....e...J   0010:0a00 0009 d136 0050 63fe 784a 8b36 74d7 .d...6.Pc.xJ.6t.   0020:5018 2238 4af8 0000 504f 5354 202f 6367 P."8J...POST/cg   0030:692d 6269 6e2f 7465 7374 2d63 6769 2048 i-bin/test-cgi H   0040:5454 502f 312e 300a 436f 6e74 656e 742d TTP/1.0.Content-   0050:7479 7065 3a20 2a0a 436f 6e74 656e 742d type:*.Content-   0060:6c65 6e67 7468 3a20 300a 0a00 19 length:0....   01:14:18.042722 200.0.0.104.42930 > 200.0.0.110.80:P   3053993825:3053993920(95) ack 2009011357 win 8760 (DF) (ttl 242, id 57632)   0000:4500 0087 e120 4000 f206 52e9 80af 0d4a E.... @...R....J   0010:0a00 0009 a7b2 0050 b608 3f61 77bf 149d .d.....P..?aw...   0020:5018 2238 8704 0000 4745 5420 2f63 6769 P."8....GET/cgi   0030:2d62 696e 2f61 676c 696d 7073 652f 3830 -bin/aglimpse/80   0040:7c49 4653 3d5f 3b43 4d44 3d5f 6563 686f |IFS=_;CMD=_echo   0050:5c3b 6563 686f 5f69 642d 6167 6c69 6d70\;echo_id-aglimp   0060:7365 5c3b 756e 616d 655f 2d61 5c3b 6964 se\;uname_-a\;id   0070:3b65 7661 6c24 434d 443b 2048 5454 502f ;eval$CMD; HTTP/   0080:312e 300a 0a00 20 1.0... 

Exploiting Vulnerabilities

According to the above-described definition and classification of vulnerabilities and the definition of the attack, any of the attack indications being considered would also be an indication of vulnerability. For example, unexpected attributes in various requests or packets can be classified as design or implementation vulnerabilities.

However, the process of using automated tools for searching for the most common vulnerabilities (the so-called security scanners) or attack implementation is generally distinguished as a separate category of attack indications. There is a wide range of such tools, from freeware utilities such as X-Spider, or ShadowSecurityScanner, up to commercial products such as the Internet Scanner or Retina. Despite the fact that vulnerability search tools are intended for noble purposes, they are quite often misused. This is especially true for cases when vulnerability searching tools are not protected from such misuse, or are themselves freeware.

There are two aspects of detecting such tools:

• Detection of vulnerability scanners. Some specialized tools, such as the Courtney system developed in Computer Incident Advisory Capability (CIAC), can detect the fact of the SATAN scanner usage.

• Detection of attack implementation. The RealSecure Network Sensor system developed by ISS can log that the intruder has imitated the action externally in relation to the host being scanned; this is committed by the intruder using various security scanners such as CyberCop Scanner or Queso.

However, merely using security scanners does not serve as evidence that attacks are in fact taking place. All these tools can also be used for regular authorized checks of the information system. Thus, it is necessary to perform an additional investigation of all registered facts of security scanner usage. For example, if shortly after detecting that some of your hosts are being scanned, the fact that the system's vulnerability is being exploited is registered can itself be considered to be evidence of an attack. Such an analysis and correlation can be performed both manually and using specialized tools such as RealSecure SiteProtector, developed by ISS, or netForensics from the netForensics company.

Inappropriate Parameters of Network Traffic

There are other parameters that can be used as indications of an attack. Certain characteristics of network traffic can be used for this purpose, for example:

• External network addresses detected within the internal network that access other external network addresses

• Unexpected network traffic (for example, bypassing the firewall or exceeding the amount of transmitted traffic)

• Unexpected parameters of network traffic (non-standard flag combinations, etc.)

• Detection of scanning attempts (such as identification of network hosts and services)

• Repeated half-open connections, which might characterize either DoS attacks or packet spoofing

• Successful attempts of connecting to rarely used or unusual services on the network hosts

• Sequential connections to network hosts or services running on a specific host

• Connections TO and FROM an unexpected location

• Repeated failed connection attempts

Parameters of the Inbound Traffic

The most illustrative example of attack indication is represented by incoming network packets arriving to the protected LAN from outside and having a source address corresponding to the address range of the internal network (Fig. 4.2). Most firewalls and other security systems generally register this attack indication.

Fig. 4.2. Replacement of the external address

If the intrusion detection system or other access control tool (firewall or router) can not control the traffic's direction, the so-called address-spoofing attack can be implemented. This attack enables the intruder to perform various unauthorized actions in the same way as if they were originating at one of the hosts within the internal network. Normally, security requirements are weaker for such hosts in comparison to those for external hosts.

Parameters of the Outbound Traffic

One example of an attack indication of this sort can be seen with outgoing network packets from the internal LAN that have a source address corresponding to the address range of the external network (Fig. 4.3). In this case, an intruder located within the internal network can attempt to conceal his actions by making them appear as if they have originated from the external network. By doing so, he can draw suspicion away from users within the internal network and mislead investigators.

Fig. 4.3. Replacement of the internal address

Unexpected Packet Addresses

In this case, packets with an unexpected source address (or recipient port for TCP/UDP protocols) can be interpreted as an attack indication. The first example is the detection of a packet arriving from an external network with an unavailable IP address (as was the case with the Kevin Mitnick attack) or with an IP address impossible for the external network. For example, there are specific addresses that are not routed on the Internet, for example:10.*.*.*, 172.16.0.0 through 172.31.255.255, and 192.168.*.* (Listings 4.10 and 4.11). These address ranges are described in RFC 1918 "Address Allocation for Private Internets". Besides this category of addresses, there is yet another set of address ranges impossible for packets arriving to your network from outside. These addresses are reserved by IANA. Reserved addresses include:0.0.0.0/8, 1.0.0.0/8, 2.0.0.0/8, 5.0.0.0/8, 7.0.0.0/8, 23.0.0.0/8, 27.0.0.0/8, 31.0.0.0/8, 36.0.0.0/8, 37.0.0.0/8, 39.0.0.0/8, 41 through 42.0.0.0/8, 58 through 60.0.0.0/8, 67 through 127.0.0.0/8, 219 through 223.0.0.0/8, 240 through 255.0.0.0/8.

Listing 4.10. Detecting the Usage of Reserved Addresses

   (a Fragment of the TCPdump Log File)   03:38:18.285290 10.1.100.23.2483 > 192.168.1.2.21:S 21101636:21101636(0)   win 8192 (DF)   03:38:12.287184 10.1.100.23.2483 > 192.168.1.2.21:S 21101636:21101636(0)   win 8192 (DF) 

Listing 4.11. Detecting the Usage of Reserved Addresses

   (a Fragment of the Cisco Router Log File)   May 10 09:20:33.328 UTC: %SEC-6-IPACCESSLOGP:list 100 denied tcp   10.1.2.73(0) -> 192.231.90.254(0), 1 packet   May 10 09:26:04.564 UTC: %SEC-6-IPACCESSLOGP:list 100 denied tcp   10.1.2.73(0) -> 192.231.90.254(0), 4 packets   May 10 09:26:34.260 UTC: %SEC-6-IPACCESSLOGP:list 100 denied tcp   10.0.0.57(0) -> 192.231.90.254(0), 1 packet   May 10 09:32:04.708 UTC: %SEC-6-IPACCESSLOGP:list 100 denied tcp   10.0.0.57(0) -> 192.231.90.254(0), 20 packets 

Another example is represented by the Land attack, in which the address and port of the source coincide with the address and port of the target (Listing 4.12). Processing such packets results in an endless loop.

Listing 4.12. Land Attack (TCPdump Log File Fragment)

   10:56:32.395383 200.0.0.104.139 > 200.0.0.104.139: S   10:56:35.145383 200.0.0.104.139 > 200.0.0.104.139: S   10:56:36.265383 200.0.0.104.139 > 200.0.0.104.139: S 

The next example relates to connection requests via Telnet protocol originating from an unknown host or from a host with which you have no trusted relationship. Mismatching MAC and IP addresses of network packets represents just another classical example. The final example of an attack using this feature is the Setiri Trojan, demonstrated at Def Con 10. This Trojan, which exploits Internet Explorer's vulnerabilities, is not detected by firewalls, and, consequently, can not be locked by them. The problem with detection of this Trojan lies in the fact that the Trojan itself does not initiate the Internet connection, like most other Trojans do. Rather, it opens invisible Internet Explorer windows to which the firewall does not react. These invisible windows implement all the unauthorized activities, such as connection to the anonymous proxy server, downloading files from unexpected hosts, and so on.

Unexpected Parameters of Network Packets

One can provide lots of examples of attacks upon unexpected network-packet parameters. These attacks are gradually becoming more and more numerous, since intruders are constantly looking for and finding new vulnerabilities in the TCP/IP stack implementations in practically all operating systems. For example, if you detect a network packet with SYN and ACK bits set (Listing 4.13) (the second stage of establishing a virtual TCP connection), this might conceal unauthorized penetration. The above-mentioned method is widely used in so-called stealth-scanning, which was rather common among intruders [Northcutt1-99].

Listing 4.13. Stealth Scanning Using SYN/ACK (Fragment of the TCPdump Log File)

   06:41:24.067330 stealth.bad.gay.org.113 > viper.infosec.ru.1004: S 4052190291:4052190291(0) ack 674711610 win 8192   06:42:08.063341 stealth.bad.gay.org.113 > www.infosec.ru.2039: S 2335925210:2335925210(0) ack 674711610 win 8192   06:42:14.582943 stealth.bad.gay.org.113 > un.infosec.ru.2307: S 2718446928:2718446928(0) ack 674711610 win 8192 

The appearance of a SYN/ACK packet without a previous SYN packet might also serve as evidence of the presence of asymmetric routers within the network. Consequently, if your network supports such routes, you need to do some additional investigation. Besides SYN/ACK bits, it is possible to use the following bits in the TCP packet header: FIN bits — FIN scanning (Listing 4.14), RESET — RESET scanning, and bit combinations — Xmas scanning (Listing 4.15) or a total lack of such bits — Null scanning (Listing 4.16).

Listing 4.14. FIN Scanning (-sF) Using Nmap

   (a Fragment of the TCPdump Log File)   18:18:03.436878 WS_LUKA.57239 > WS_LUKICH.9535: F 0:0(0) win 3072   18:18:03.437131 WS_LUKA.57239 > WS_LUKICH.1482: F 0:0(0) win 3072   18:18:03.437335 WS_LUKA.57239 > WS_LUKICH.617: F 0:0(0) win 3072   18:18:03.437501 WS_LUKA.57239 > WS_LUKICH.148: F 0:0(0) win 3072   18:18:03.437709 WS_LUKA.57239 > WS_LUKICH.638: F 0:0(0) win 3072   18:18:03.437872 WS_LUKA.57239 > WS_LUKICH.1467: F 0:0(0) win 3072   18:18:03.438089 WS_LUKA.57239 > WS_LUKICH.1475: F 0:0(0) win 3072   18:18:03.438286 WS_LUKA.57239 > WS_LUKICH.852: F 0:0(0) win 3072   18:18:03.438446 WS_LUKA.57239 > WS_LUKICH.653: F 0:0(0) win 3072   18:18:03.442145 WS_LUKA.57239 > WS_LUKICH.672: F 0:0(0) win 3072 

Listing 4.15. Xmas Scanning (-sX) Using Nmap (a Fragment of the TCPdump Log File)

   18:18:28.038171 WS_LUKA.57407 > WS_LUKICH.1031:FP 0:0(0) win 3072 urg 0   18:18:28.038378 WS_LUKA.57407 > WS_LUKICH.1112:FP 0:0(0) win 3072 urg 0   18:18:28.038643 WS_LUKA.57407 > WS_LUKICH.2048:FP 0:0(0) win 3072 urg 0   18:18:28.038846 WS_LUKA.57407 > WS_LUKICH.6666:FP 0:0(0) win 3072 urg 0   18:18:28.039015 WS_LUKA.57407 > WS_LUKICH.906:FP 0:0(0) win 3072 urg 0   18:18:28.039180 WS_LUKA.57407 > WS_LUKICH.135:FP 0:0(0) win 3072 urg 0   18:18:28.039369 WS_LUKA.57407 > WS_LUKICH.1003:FP 0:0(0) win 3072 urg 0   18:18:28.039575 WS_LUKA.57407 > WS_LUKICH.3141:FP 0:0(0) win 3072 urg 0   18:18:28.039739 WS_LUKA.57407 > WS_LUKICH.1448:FP 0:0(0) win 3072 urg 0 

Listing 4.16. Null Scanning (-sN) Using Nmap

   (a Fragment of the TCPdump Log File)   18:20:04.466572 WS_LUKA.53497 > WS_LUKICH.2766: . win 1024   18:20:04.466776 WS_LUKA.53497 > WS_LUKICH.534: . win 1024   18:20:04.466995 WS_LUKA.53497 > WS_LUKICH.206: . win 1024   18:20:04.467164 WS_LUKA.53497 > WS_LUKICH.119: . win 1024   18:20:04.467372 WS_LUKA.53497 > WS_LUKICH.636: . win 1024   18:20:04.467575 WS_LUKA.53497 > WS_LUKICH.313: . win 1024   18:20:04.467836 WS_LUKA.53497 > WS_LUKICH.372: . win 1024   18:20:04.468040 WS_LUKA.53497 > WS_LUKICH.378: . win 1024   18:20:04.468204 WS_LUKA.53497 > WS_LUKICH.532: . win 1024 

Null Scanning can be better illustrated with an example of a log file created by the Snort intrusion detection system (Listing 4.17).

Listing 4.17. Null Scanning Using Nmap

   (a Fragment of the Snort Log File)   [**] NULL Scan [**]   05/28-21:09:23.686988 200.0.0.200:27025 -> 200.0.0.104:1186 TCP TTL:44   TOS:0x0 ID:64660 DF******** Seq: 0xE4714 Ack: 0xFFFFFFFF Win: 0x0 

For comparison, we can provide an already-demonstrated example of FIN scanning (Listing 4.18).

Listing 4.18. FIN Scanning Using Nmap

    (a Fragment of the Snort Log File)    [**] SCAN-FIN [**]    02/02-04:49:15.135173 0:D0:58:4A:46:D0 -> 0:10:5A:6C:9A:55 type:0x800    1en:0x104 195.11.50.204:2931 -> my-squid:53 TCP TTL:39 TOS:0x0 ID:2037    *F**** Seq: 0x32563E Ack: 0x362C0000 Win: 0x0 

Any packet that does not conform to the RFC requirements can cause the failure of the communication equipment that processes this packet. Note that this relates not only to routers or switches, but also to firewalls and intrusion detection systems. There are many attacks that use invalid combinations of the TCP flags in network packets. Some combinations cause the hosts processing such packets to fail, while other combinations result in packets not being noticed by some intrusion detection systems or firewalls. RFC 793 describes how various systems must react to normal TCP packets. However, neither this nor other similar documents specify how the system should react to incorrect TCP packets. Consequently, different devices and different operating systems produce different reactions to network packets with invalid combinations of TCP flags. A TCP packet can contain six flags: SYN, ACK, FIN, RST, PSH, URG. Invalid combinations can be detected by at least one of the indications listed below [Frederick1-00]:

• SYN+FIN. This combination is invalid because these flags are mutually exclusive. The first flag establishes a connection, while the second one closes it. Various scanners, such as Nmap, use this combination quite frequently. Quite recently, most intrusion detection systems have not been able to detect this kind of scanning. Currently, the situation has changed for the better, and most intrusion detection systems are able to trace such combinations of flags. However, adding at least one extra flag to this combination (for example, SYN+FIN+PSH, SYN+FIN+RST, SYN+FIN+RST+PSH) once again prevents some intrusion detected systems from detecting the modified scanning (Listing 4.19). Some analysts have named such combinations the "Christmas Tree Pattern."

  Listing 4.19. The "Christmas Tree Pattern" (Fragment from a Snort Log File)

     01/23-01:15:22.237103 195.11.212.180:30975 -> 192.0.97.80:49708   TCP TTL:49 TOS:0x0 ID:12207 DF   SFRPAU21 Seq: 0x78FFC22C Ack: 0x78FFC22C Win: 0xC22C   TCP Options => Opt 120 (40): C22C 78FF C22C 78FF C22C 78FF   0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 78 FF C2 2C 78   FF x..,x.   01/23-01:15:43.538590 195.11.212.180:30975 -> 192.0.97.80:49708   TCP TTL:49 TOS:0x0 ID:31449 DF   SERPAU21 Seq: 0x78FFC22C Ack: 0x78FFC22C Win: 0xC22C   TCP Options => Opt 120 (40): C22C 78FF C22C 78FF C22C 78FF   0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 78 FF C22C 78 FF x..,x. 

  Norton Personal Firewall 2002 Does Not Detect SYN/FIN Scanning 

  In April, 2002, it was reported that Norton Personal Firewall 2002 running in Windows 2000 does not always detect SYN/FIN scanning when the "detect portscan" option is enabled. What was happening was that, when detecting port scanning, Norton Personal Firewall locks for half an hour on just SYN scanning, and "forgets" about SYN/FIN scanning.

• TCP packets must never contain only the FIN flag. Usually, if only the FIN flag is set, this serves as an indication of the stealth FIN scanning.

• TCP packets must have at least one flag (except FIN).

• If the ACK flag is not set in the TCP packet, and this packet is not the first in the three-way handshake process, this packet is blatantly abnormal, since ACK flag must be present in any TCP packet.

• Besides the above-mentioned combinations (Listing 4-20), the following combinations are also suspicious: RST+FIN, SYN+RST.

  Listing 4.20. Detecting a Suspicious Situation (a Fragment of the Dragon Log File)

     20:42:17 [T] 172.20.255.135 10.168.74.96 [TCP-FLAGS] (flags:-1-=-SR---, dp=11498,sp=0) (dragon-sensor) [PORT-ZERO] (tcp,dp=11498,sp=0) 

In the TCP protocol, there are reserved bits intended for future extensions to the protocols. Only a couple of years ago, these bits were not used. Therefore, the arrival of network packets where such bits were used could well indicate unauthorized activity, particularly an attempt of a remote OS identification (OS fingerprinting). Usually, the operating system is identified either by analyzing the packet headers (passive analysis), or by its reaction to packets of a specific format (this case we will cover in detail). At the time of writing, intruders used three utilities for remote OS fingerprinting — QueSO (Listing 4.21), hping, and Nmap.

Listing 4.21. OS Fingerprinting Using QueSO

   luka# queso -d 200.0.0.253   Starting luka.infosec.com:6363 -> 200.0.0.253:80   IN #0: 80->6363 S:1 A:+1 W:7C00 U:0 F: SYN ACK   IN #1: 80->6364 S:0 A:0 W:0000 U:0 F: RST   IN #3: 80->6366 S:0 A:0 W:0000 U:0 F: RST   IN #4: 80->6367 S:1 A:+1 W:7C00 U:0 F: SYN FIN ACK   IN #6: 80->6369 S:1 A:+1 W:7C00 U:0 F: SYN ACK XXX YYY   200.0.0.253:80  *Linux 1.3.xx, 2.0.0 to 2.0.34   luka# queso -d 200.0.0.200   Starting luka.infosec.ru:15690 -> 200.0.0.200:80   IN #0: 80->15690 S:1 A:+1 W:2180 U:0 F: SYN ACK   IN #1: 80->15691 S:0 A:+1 W:0000 U:0 F: RST   IN #2: 80->15692 S:0 A:+1 W:0000 U:0 F: RST ACK   IN #3: 80->15693 S:0 A:+1 W:0000 U:0 F: RST   IN #4: 80->15694 S:1 A:+1 W:2180 U:0 F: SYN ACK   IN #5: 80->15695 S:0 A:+0 W:0000 U:0 F: RST ACK   IN #6: 80->15696 S:1 A:+1 W:2180 U:0 F: SYN ACK   200.0.0.200:80  * Windoze 95/98/NT 

After starting, QueSO detects an open port on the scanned host and sends several packets that do not meet RFC requirements. The replies to these packets allow you to determine the OS type (Listing 4.22).

Listing 4.22. OS Fingerprinting Using QueSO (a Fragment of the TCPdump Log File)

   02:35:10.11 WS_LUKA.29709 > WS_LUKICH.80: S 1173826820:1173826820(0) ack 0   02:35:10.13 WS_LUKA.29710 > WS_LUKICH.80: F 1173826820:1173826820(0)   02:35:10.15 WS_LUKA.29711 > WS_LUKICH.80: F 1173826820:1173826820(0) ack 0   02:35:10.17 WS_LUKA.29712 > WS_LUKICH.80: SF 1173826820:1173826820(0)   02:35:10.19 WS_LUKA.29713 > WS_LUKICH.80: P   02:35:10.21 WS_LUKA.29714 > WS_LUKICH.80: S 1173826820:1173826820(0)       4500 0028 ee7b 0000 fc06 2f62 ab45 a42d       ac15 a569 7412 0017 45f7 2d04 0000 0000       50c2 1234 14d8 0000 0000 0000 0000 

The following combinations of flags might appear in sent packets:

• SYN+ACK with ACK off

• FIN only

• FIN+ACK with ACK off

• SYN+FIN

• PUSH only

• SYN+XXX+YYY, where XXX and YYY are reserved flags in the TCP header (two high-order bits in 13th byte of the TCP packet header)

The Nmap scanner uses a similar technique for detecting the OS type. However, its packets use somewhat different flag combinations:

• SYN only

• No flags

• SYN+FIN+URGENT+PUSH

• ACK only

• SYN only, sent to closed port

• ACK only, sent to closed port

• FIN+URGENT+PUSH, sent to closed port

With the arrival of RFC 2481 [RFC1-99] and 2884 [RFC1-00], the situation became even worse. According to the above-mentioned standards, reserved bits (Explicit Congestion Notification, ECN) can be used for transmitting service information. As shown in [Miller1-00], if the packet corresponding to Listing 4.23 appears in the network, this could serve as an indication that the network is being scanned using Queso, hping, or Nmap).

Listing 4.23. Using Reserved ECN Flags in the TCP Packet Header (a Fragment of the TCPdump Log File)

   12:25:38.650123 bad.guy.org.1641 > viper.infosec.ru.111: S   1533993767: 1533993767 (0)   win 512 (tt1 64, id 64461)   4500 0028 fbcd 0000 4006 91f5 xxxx xxxx   xxxx xxxx 0669 006f 5b6e e327 0000 0000   50c2 0200 7b16 0000 

To understand the meaning of the c2 fragment within the packet (two reserved bits are used), you will need to perform an additional investigation in order to know for sure whether or not this is an attack.

Taking into account the possibility of using ECN flags, the new version of TCPdump — version 3.5 — displays these bits as shown in Listing 4.24.

Listing 4.24. Using Reserved ECN Flags in the TCP Header

   (a Fragment of the TCPdump Log File)   12:25:38.650123 bad.guy.org.1641 > viper.infosec.com.111: S [ECN-Echo, CWR]   380601688:380601688 (0) win 4660 (tt1 244, id 55411)   4500 0028 d873 0000 f406 85b4 xxxx xxxx   xxxx xxxx 0669 006f 16af 8558 0000 0000   50c2 1234 39e5 0000 753a 0000 e3a8 

Such "intelligent" behavior results in confusing the analysts by the TCPdump system, which will think that the packet corresponds to the RFC 2481 standard, while in reality OS fingerprinting using Nmap is in progress. Thus, we are dealing with a false negative case.

Other indications of the packet "abnormality" are as follows:

• Source or recipient port (for TCP and UDP packets) set to 0 (Listing 4.25).

• If the ACK flag is set (for TCP packets), the acknowledgement number must never be set to 0.

Listing 4.25. Detecting Suspicious Activity (a Fragment of the TCPdump Log File)

   21:20:11.084066 172.20.20.1.0 > ftp.infosec.com.1030: F 1310724:1310728(4)   ack 3642168720 win 20496 urg 1250 

Quite often, a packet that has non-standard size can also be interpreted as an indication of an attack. For example, most ICMP Echo Request packets have an 8-bit header and a 56-bit data field. If packets of a non-standard length are sent to the network, one can draw the conclusion that unauthorized activity is taking place on the network. For example, the Loki attack already considered in Chapter 1 enables the intruder to tunnel various commands into the ICMP Echo Request and reactions to these commands into the ICMP Echo Reply packets. This significantly changes the size of the data field as compared to the standard one. Another well-known example is the Ping of Death command, during which the attacker creates an ICMP Echo Request packet larger than 65,535 bytes (Listing 4.26).

Listing 4.26. Detecting a Ping of Death attack (a fragment of the TCPdump log file)

   12:43:58.431 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321: 380@0+)   12:43:58.431 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@2656+)   12:43:58.431 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@3040+)   12:43:58.431 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@3416+)   12:43:58.431 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@376+)   12:43:58.431 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@3800+)   12:43:58.431 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@4176+)   12:43:58.431 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@760+)   ...   12:43:58.491 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@63080+)   12:43:58.491 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@63456+)   12:43:58.491 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@63840+)   12:43:58.491 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@64216+)   12:43:58.491 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@64600+)   12:43:58.491 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@64976+)   12:43:58.491 big.pinger.org > 200.0.0.104: icmp: echo request (frag   4321:380@65360) 

The length of this message, comprising several fragments, is 65,740 (380+65,360) bytes.

If fragmented packets are sent to your network, this is just another classical indication that, in most cases, allows you to detect an attack. Most network security tools cannot correctly assemble these fragmented packets. When receiving such packets, these security tools either fail or pass fragmented packets into the protected network. The first of these results (security-tool failure) can be achieved using fragments with an incorrect offset (in the example provided above for the Ping of Death, the transmitted fragment length is not a multiple of 8 — the fragment size is 380 bytes). To produce their second result, intruders use the so-called "Tiny Fragment" attack. In the latter case, one has to create two TCP fragments. The first fragment is so small that it does not even include the complete TCP header and — even more important — the recipient port. The second fragment contains the remaining part of the header. Most firewalls allow the first fragment (or even both fragments) to pass into the corporate network (Listing 4.27).

Listing 4.27. The Tiny Fragment Attack (a Fragment of the TCPdump Log File)

   06:25:55.315 [|tcp] (frag 38783:16@0+)   06:25:55.315 bad.guy.org > viper.infosec.ru: (frag 38783:4@16)   06:25:55.315 [|tcp] (frag 16422:16@0+)   06:25:55.315 bad.guy.org > viper.infosec.ru: (frag 16422:4@16)   06:25:55.315 [|tcp] (frag 18543:16@0+)   06:25:55.315 bad.guy.org > viper.infosec.ru: (frag 43143:4@16)   06:25:55.315 [|tcp] (frag 18544:16@0+)   06:25:55.315 bad.guy.org > viper.infosec.ru: (frag 18544:4@16)   06:25:55.315 [|tcp] (frag 8231:16@0+)   06:25:55.315 bad.guy.org > viper.infosec.ru: (frag 8231:4@16)   06:25:55.315 [|tcp] (frag 45846:16@0+)   06:25:55.315 bad.guy.org > viper.infosec.ru: (frag 6245:4@16)   06:25:55:315 [|tcp] (frag 6245:16@0+)   06:25:55.315 bad.guy.org > viper.infosec.ru: (frag 6245:4@16) 

The [|tcp] label specifies that TCPdump could neither grab the whole TCP header nor interpret packet destination.

Network Traffic Anomalies

Anomalies of network traffic are any deviations that network parameters may possess. These parameters include the workload factor, typical packet size, average number of fragmented packets, and so on. Deviations from the standard parameters can be an indication of an attack, as well as an indication of network problems caused by network equipment malfunctions.

Suspicious Characteristics of Network Traffic

Suspicious characteristics identifying attacks include the following:

• Suspicious traffic from a specific sender or to a specific recipient. In some cases, specific types of traffic or its contents can raise suspicion. For example, this might be an e-mail message containing specific keywords, access to certain servers, such as http://www.playboy.com, http://www.recruitment.com, http://www.vacation.com, or work by the protocol that is not expected from the specified address (for example, Telnet requests from a bank's operations department).

• Suspicious traffic (independent of the sender or recipient). Some kinds of traffic are suspicious in themselves, regardless of the recipient, such as traffic using unexpected protocols or traffic from addresses that do not belong to the internal network. For example, a security specialist in one of the banks using the RealSecure Network Sensor system detected unauthorized modem usage by one of their employees, who connected his office workstation from home and thus surfed the Internet using a faster connection. Another example of suspicious traffic involves sending confidential documents from a company to some address outside the company network. Such traffic can be detected by means of monitoring and tracing with appropriate keywords (such as "company confidential," "top secret" etc.).

Default Values

The default values of the attributes are just another common indication of an attack. Such attributes might include names of files or resident processes (for example, Trojans), used ports, etc. Let us take a look at this indication in more detail using the example of Trojan Horses.

Since most Trojans have predefined names of files or processes, their appearance on your computer might be considered unauthorized activity. For example, if you notice a file named Patch.exe, this might be interpreted as the presence of the NetBus, Digital RootBeer, Krenx, or Solid Gold Trojans on the host. A list of filenames of known Trojans can be downloaded from: http://www.simovits.com/trojans/trojans_files.html. Apart from this, there you can find information on the ports that are most frequently used by the Trojans. The list of active processes also can be used for detecting Trojans. In Unix, you can obtain this list using the ps utility, while in Windows NT/2000, you can get it by starting the Task Manager utility (Fig. 4.4). Naturally, you must be sure that the intruder has not installed rootkit on your computer.

Fig. 4.4. The Patch.exe process starting the NetBus Trojan

Another method of detecting Trojans implies the analysis of specific ports (control of requests or detection of an open port). According to this principle, it is possible to detect most Trojans, which are bound to specific port numbers. If the Trojan uses non-standard ports, it can be detected using specific keywords in network traffic, for example, by the commands received and sent, or by the password used for communication between its client and server parts. Provided below are several examples illustrating detection of the well-known SubSeven Trojan (Listings 4.28 through 4.34), which usually communicates via Port 1243 or 27374 (version 2.1).

Listing 4.28. Detecting the SubSeven Trojan (a Fragment of the Snort Log File)

   [**] BACKDOOR Attempt- Subseven [**]   12/26-23:09:42.219109 0:90:27:F:22:A2 <- 0:40:5:F6:34:51 type:0x800   len: 0x4E   216.192.29.30:3216 -> 206.18.108.130:1243 TCP TTL:64 TOS:0xDO ID:11841   S***** Seq: 0x4908C6 Ack: 0x0 Win: 0x2000   TCP Options => MSS: 536 NOP WS: 0 NOP NOP TS: 0 0 Opt 9 (40): 0000 0000   0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 

Listing 4.29. Detecting the SubSeven Trojan (a Fragment of the IPCHAINS Log File)

   Jan 5 02:56:39 input REJECT eth1 PROTO=TCP 152.166.212.218:2102   192.168.1.1:1243 L=48 S=0x00 I=38494 F=0x4000 T=108 SYN (#13) 

Listing 4.30. Detecting the SubSeven Trojan (a Fragment of the Ascend SecureConnect 3.03 Log File)

   Mar 30 19:44:02 209-30-73-81.flash.net ASCEND: wan5 tcp 209.30.73.80 ;27374   <- 24.29.78.48;1493 58 syn !pass (totcp-1)   Mar 30 19:44:02 209-30-73-81.flash.net ASCEND: wan6 tcp 209.30.73.81;27374   <- 24.29.78.48;1496 58 syn !pass (totcp-1)   Mar 30 19:44:02 209-30-73-81.flash.net ASCEND: wan5 tcp 209.30.73.82;27374   <- 24.29.78.48;1495 58 syn !pass (totcp-1   Mar 30 19:44:02 209-30-73-81.flash.net ASCEND: wan6 tcp 209 30.73.83;27374   <- 24.29.78.48;1496 58 syn !pass (totcp-1)   Mar 30 19:44:02 209-30-73-81.flash.net ASCEND: wan5 tcp 209.30.73.95;27374   <- 24.29.78.48;1508 58 syn !pass (totcp-1) 

Listing 4.31. Detecting the SubSeven Trojan (a Fragment of the ZoneAlarm Log File)

   Name Packet sent from 24.226.103.143 (TCP Port 3387)   to x.x.x.x (TCP Port 27374) was blocked     Status Dropped     Source IP Address 24.226.103.143     Destination IP Address x.x.x.x     Source Port 3387     Destination Port 27374     Link Layer Protocol 1     Network Layer Protocol 1     Transport Layer Protocol 2     Count 1     Status Code 100002     Lock Level 0     Security Information 0, 1, 0, 2     Operating System Windows 98-4.10.1998- -SP     Product ZoneAlarm     ProductVersion 2.0.26     Language 0409     State Find Code 13 

Listing 4.32. Detecting the SubSeven Trojan

   (a Fragment of the NFR Back Officer Log File)   17:54:19.596269 ip 60: 24-216-141-52.hsacorp.net .1566 > my.box.1243:     S 12759610:12759610(0) win 8192 <mss 1460> (DF) (tt1 19, id 61249)   17:54:19.624034 ip 54: my.box.1243 > 24-216-141-52.hsacorp.net.1566:     R 0:0(0) ack 12759611 win 0 (tt1 128, id 4263) 

Listing 4.33. Detecting the SubSeven Trojan

   (a Fragment of the BlackICE Defender Log File)   59 2000-05-04 19:35:31 2003105 SubSeven port probe 172.142.109.211     AC8E6DD3.ipt.aol.com 152.207.70.106 port=1243&name=Sub_7 8 

Listing 4.34. Detecting of the SubSeven Trojan

   (a fragment of the Pix firewall log file)   Jun 03 00:06:26 [FW1] Jun 03 2000 00:08:00: %PIX-2-106001:   Inbound TCP connection denied from 216.58.19.218/3483   to server1/27374 flags SYN   Jun 03 00:06:26 [FW1] Jun 03 2000 00:08:00: %PIX-7-106011:   Deny inbound (No xlate) tcp src outside:216.58.19.218/3487   dst outside:global/27374 

The Satans Trojan uses the number 666 for connection (the same port number is used also by the BackConstruction Trojan). Note that the Satans Trojan can also be detected by the presence of a running program named WinVMM32 (Listing 4.35).

Listing 4.35. Detecting the Satans Trojan (a Fragment of the Snort Log File)

   [**] BACKDOOR Attempt- Attack FTP / Satans Backdoor [**]   12/26-23:09:51.159109 0:0:0:0:0:0 -> 0:0:0:0:0:0 type: 0x800 len: 0x4E   216.192.29.30:3215 -> 206.18.108.130:666 TCP TTL:65 TOS: 0xC8 ID:25409   S***** Seq: 0x4907EF Ack: 0x0 Win: 0x2000   TCP Options => MSS: 536 NOP WS: 0 NOP NOP TS: 0 0 Opt 9 (40): 0000 0000   0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 

The BackOrifice Trojan communicates to the master via port 31337. Furthermore, it leaves traces of its activity in the Windows registry under HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices (Listings 4.36, 4.37).

Listing 4.36. Detecting the BackOrifice Trojan (a Fragment of the SHADOW Log File)

   15:20:48.698626 172.20.20.1.31338 > 192.168.1.1.31337: udp 19

Listing 4.37. Detecting the BackOrifice Trojan (a Fragment of the IPCHAINS Log File)

   Jan 4 20:59:40 input REJECT eth1 PROTO=UDP 24.114.172.74:3764   192.168.1.1:31337 L=47 S=0x00 I=65460 F=0x0000 T=123 (#16) 

As I mentioned above, Trojans can be detected not only by analyzing requests to specific ports, but also by tracing specific keywords in network traffic (this is especially useful if the Trojan does not use the default port). For example, BackOrifice can be detected by the following password signature: "ce 63 d1 d2 16 e7 13 cf," present in the first 8 bytes of the data field in the UDP packet (Listing 4.38).

Listing 4.38. Detecting the BackOrifice Trojan (a fragment of the TCPdump log file)

   09:39:36.695 200.0.0.104.1613 > 200.0.0.200.31337: udp 19          4500 002f cea7 0000 7d11 cd56 ab45 a49b          ac15 a5c9 064d 7a69 001b 30e7 ce63 dld2          16e7 13cf 38a5 a586 b275 4b99 ad32 58   09:39:36.695 200.0.0.200.31337 > 200.0.0.104.1613: udp 53          4500 0051 b408 0000 2011 44d4 ac15 a5c9          ab45 a49b 7a69 064d 003d bc7b ce63 d1d2          16e7 13cf 1ea5 a586 7a75 4b99 2d61 2196          c7fc 8502 192a   09:39:36.695 200.0.0.200.31337 > 200.0.0.104.1613: udp 48          4500 004c b508 0000 2011 43d9 ac15 a5c9          ab45 a49b 7a69 064d 0038 bb34 ce63 d1d2          16e7 13cf 1ba5 a586 7b75 4b99 6d71 2d97          c1fc 8656 5031 ... 

In Chapter 2, I mentioned that, apart from classical attacks based on the "one-to-one" or "one-to-many" models, there are the so-called distributed attacks, which correspond to "many-to-one" and "many-to-many" models. Some Trojans are based on this principle, such as WinTrin00 (Listing 4.39), TFN2K, Stacheldraht, mstream (Listing 4.40), etc. These Trojans can also be detected by the port numbers used.

Listing 4.39. Detecting the WinTrin00 Trojan (a Fragment of the Cisco Router Log File)

   Feb 25 21:14:38 134.161.1.101 21043: %SEC-6-IPACCESSLOGP:   list ingress denied udp 38.29.63.57(4419) -> 134.161.67.71 (34555), 1 packet   Feb 25 21:14:51 134.161.1.101 21044: %SEC-6-IPACCESSLOGP:   list ingress denied udp 38.29.63.57(4420) -> 134.161.67.71 (34555), 1 packet   Feb 25 21:14:57 134.161.1.101 21045: %SEC-6-IPACCESSLOGP:   list ingress denied udp 38.29.63.57(4421) -> 134.161.67.71 (34555), 1 packet   Feb 25 21:15:00 134.161.1.101 21046: %SEC-6-IPACCESSLOGP:   list ingress denied udp 38.29.63.57(4422) -> 134.161.67.71 (34555), 1 packet   Feb 26 00:35:40 134.161.1.101 22024: %SEC-6-IPACCESSLOGP:   list ingress denied udp 38.29.63.57(4523) -> 134.161.67.71 (34555), 1 packet   Feb 26 11:01:56 134.161.1.101 24967: %SEC-6-IPACCESSLOGP:   list ingress denied udp 38.29.63.170(4531) -> 134.161.67.71 (34555), 1 packet   Feb 26 11:09:24 134.161.1.101 25007: %SEC-6-IPACCESSLOGP:   list ingress denied udp 38.29.63.170(4541) -> 134.161.67.71 (34555), 1 packet   Feb 26 11:09:26 134.161.1.101 25008: %SEC-6-IPACCESSLOGP:   list ingress denied udp 38.29.63.170(4542) -> 134.161.67.71 (34555), 1 packet 

Listing 4.40. Detecting the mstream Trojan

   (a Fragment of the TCPdump Log File)   00:04:38.530000 192.168.0.20.1081 > 192.168.0.100.6838: udp 9          4500 0025 ef75 0000 4011 098a c0a8 0014 E..%.u..@.......          c0a8 0064 0439 1ab6 0011 2b63 6e65 7773 ...d.9....+cnews          6572 7665 7200 0000 0000 0000 0000 erver......... 

To detect Trojans, it is not necessary to control all of the network traffic — it is sufficient to just analyze the open ports. Using this approach, you can identify most Trojans that are bound to specific port numbers. You can find open ports both locally and remotely. Locally, you can view the list of all open ports by running netstat or a similar utility with the -a parameter (Listing 4.41).

Listing 4.41. Detecting the NetBus Trojan (the Output Produced by the Netstat -a Command)

   Active Connections   Proto   Local Address           Foreign Address   State   TCP     ws_lukich:135           0.0.0.0:0         LISTENING   TCP     ws_lukich:901           0.0.0.0:0         LISTENING   TCP     ws_lukich:2998          0.0.0.0:0         LISTENING   TCP     ws_lukich:9991          0.0.0.0:0         LISTENING   TCP     ws_lukich:12345         0.0.0.0:0         LISTENING   TCP     ws_lukich:12346         0.0.0.0:0         LISTENING   TCP     ws_lukich:1026          0.0.0.0:0         LISTENING   TCP     ws_lukich:1026          localhost:1027    ESTABLISHED   TCP     ws_lukich:1027          localhost:1026    ESTABLISHED   TCP     ws_lukich:137           0.0.0.0:0         LISTENING   TCP     ws_lukich:138           0.0.0.0:0         LISTENING   TCP     ws_lukich:nbsession     0.0.0.0:0         LISTENING   TCP     ws_lukich:nbsession     ws_luka:3055      ESTABLISHED   UDP     ws_lukich:135           *:*   UDP     ws_lukich:nbname        *:*   UDP     ws_lukich:nbdatagram    *:* 

In this case, we detected that the NetBus Trojan is present on the WS_LUKICH local host. This Trojan works on Ports 12345 or 12346. A list of ports used by Trojans can be found at http://www.simovits.com/trojans/trojans_files.html.

Remote detection of Trojans by analyzing open ports requires that you use the methods used by intruders — any port scanner, such as Nmap, which can run in most Unix clones and in Windows NT (Listing 4.42).

Listing 4.42. Detecting the NetBus Trojan

   (the Output Produced by the nmapnt -sS 200.0.0.200 Command)   Starting nmapNT V. 2.53 by [e-mail]   eEye Digital Security (http://www.eEye.com)   based on nmap by [e-mail] (www.insecure.org/nmap/)   We skillfully deduced that your address is 0.0.0.0   Interesting ports on WS_LUKICH (200.0.0.200):   (The 1518 ports scanned but not shown below are in state: closed)   Port         State   Service   135/tcp      open    unknown   139/tcp      open    unknown   901/tcp      open    unknown   12345/tcp    open    NetBus   12346/tcp    open    NetBus   Nmap run completed -- 1 IP address (1 host up) scanned in 1 second 

Fig. 4.5. Network scanning for detecting the NetBus Trojan

Remote scanning of the WS_LUKICH host additionally detected that Ports 12345 and 12346 were open, leading to the conclusion that the NetBus Trojan is present on that host. Finally, you can also use a non-traditional method. For example, some programs intended to manage Trojans provide the capability of scanning the specified address ranges and detecting the installed components. The NetBus Trojan also provides this function (Fig. 4.5).

Unexpected Attributes

Requests from any system, network or user are characterized by certain attributes that describe the so-called system, network, or user profile. These profiles are used for monitoring and analyzing the controlled object. The most frequently used parameters that provide the capability of detecting a potential attack are considered below.

Date and Time

Date and time represent the most characteristic attributes that are used when detecting security policy violations. Let us suppose, for example, that a system logon that happened after 18:30 was registered in the log. If the user who logged on was one of the system administrators, this might be an authorized logon by a user who is working overtime. However, if an intrusion detection system registers a system logon by an employee working in the financial department, this fact might be a reason for additional investigations (whether that user was authorized to log on in order to do their job or whether some intruder attempted to implement the attack by guessing the user's login name and password). Similar situations might arise if an intrusion detection system registers a logon attempt during weekends and holidays. Let's look at a more specific example related to banking. In most banks, all payments made after a specific hour are suspended until the next business day. For example, if a payment is made on Friday, activity on the concerned accounts will be delayed till the following Monday. If a transaction is accomplished after a specific period of time, this might be a signal indicating that an attempt of fraud has been detected. Let us consider yet another example which uses time as the attack indicator: If the time interval between data input and payment confirmation is too small (insufficient for normal procedure of review of the transaction), one can suppose that the payment is incorrect or fraudulent.

Location

Normally, the user logs onto the system from the same computer or connects to the Internet via a dial-up connection using the same phone number. Consequently, a logon from another computer or another phone number can be considered to be an abnormal event that needs to be investigated. In a large corporate network whose departments are distributed all over the country (or the world), intrusion detection systems often monitor the geographical location from where the logon is performed. Thus, a change of the typical location from where the user logs on can also be an attack indication. Let us consider another example, typical for financial applications. Operations such as data input for payment transaction and confirmation of that payment must be performed from different sites. These procedures are separated in order to prevent employees from abusing their work permissions. Thus, time is a rather important criterion, allowing you to determine if specific actions are authorized. In particular, control over the date and time allows you to detect an untimely launch of processes and programs, and unexpected reboots, startups, and shutdowns.

System Resources

Characteristics of most system resources can also serve as attack indicators. For example, a processor workload that differs significantly from the average can indicate various abnormal activities. For example, this might happen if the operating system or specific application works incorrectly, or if someone attempts a brute-force attack. Other resources that can indicate an active attack include intense memory or disk activities, requests to communication ports, etc. If you unexpectedly experience a shortage of hard disk space, this might serve as evidence of the appearance of a "bomb" in your system. The "bomb" is a packed file of small size, which, when expanded, will consume several dozens gigabytes (such "jokes" were rather common in FIDO in the early 1990s).

User and System Profiles

Using profiles represents a more general approach than does analysis of requests to services or system resources. User and system profiles include such requests. However, they are complemented by additional parameters that take into account specific characteristics of the user, process, or host. These parameters include, for example, the time of maximum and minimum workloads, duration of a typical session, normal logon and logoff time, and so on. Deviations of these parameters from typical values may serve as evidence of abnormal behavior.

A particular case of this attack indication might be control of the services that are most frequently requested by the subject (user, process, and so on) in its day-to-day activity. For example, if employees need to access the Internet in order to do their jobs, you can generate a list of the most frequently used web servers and trace requests to servers not included into this list. Such requests might be interpreted as security policy violations. Requests of specific files, sending or receiving e-mail to or from specific addresses, using specific services (such as FTP or Telnet), and other types of activities can also be classified as indications of security policy violations.

Other Parameters

There are other indicators that allow one to detect security policy violations. These include, for example, the above-mentioned procedure with input and authorization of the payment. Suppose, however, that an employee abusing his position performs this operation from different workstations in order to transfer money to fraudulent accounts. In reality, such a situation would not arise. The function of entering and authorizing a transaction must be distributed between different computers and different users.

Polling System Hacked 

In May 2002, the French corporation Vivendi Universal suspected that its wireless system of electronic polling used for shareholder meetings had been hacked. An abnormally high number of abstentions during one of the polls related to the payment of interest was interpreted as an indication of an attack.

The detection of a specific action performed on the account of an ex-employee (whose user account was not deleted from the controlled system for some reason) or an employee who is on vacation must also be considered to be a security policy violation.

Unexpected Problems

Any problem that arises in the corporate network must give occasion for additional investigations. Even if, in the course of this investigation, you find out that the problem does not relate to security, the fact of its detection will have a positive influence on system performance and reliability. Problems of this type include the following:

• Problems with software and hardware. Router failure, server reboots, or inability to start one of the system services might indicate an attempt to implement a Denial of Service attack.

• Unexpected user behavior. An unexpected request to a resource, which the user has never tried to access before, might well mean that the intruder has intercepted or cracked the password of the legitimate user and is now attempting to access important data on behalf of that user.

Cuckoo's Egg 

A classical example of intrusion detection is described in [Stoll1-96] by Clifford Stoll, a computer specialist and professional astronomer who accidentally detected a small discrepancy in the system's accounting machine time. After careful investigation, security specialists discovered that some unknown user had "borrowed" several seconds of machine time without paying (the sum was rather small, something like ¢0.75). As a result, the intruder was detected and turned out to have intruded upon dozens of top secret Pentagon systems.

Banners

This indicator is used only in security analyzers that will be covered later. Most network services generate responses to the requests they receive. This response is known as a "banner." Analysis of banner information (such as version number, for example) enables security specialists to determine whether or not the service is vulnerable.

Such an analysis often allows you to detect the version of the scanned service, the type of operating system, and so on, which enables you to investigate potential vulnerabilities in this component of the information system. For example, an attempt to establish a Telnet connection to Port 143 (IMAP service) will display a standard message containing information on the version and developer of the IMAP service (Listing 4.43).

Listing 4.43. Analysis of the Header Returned by the IMAP Service

   Trying x.x.x.x...   Connected to bank.ru   * OK bank IMAP4rev1 Service 9.0(157) at Wed, 14 Oct 1998 11:51:50 -0400 (EDT)   (Report problems in this server to [e-mail])   . logout   * BYE bank IMAP4rev1 server terminating connection   . OK LOGOUT completed   Connection closed by foreign host. 

This information, which at first might seem insignificant, enables the security administrator performing the security scan to find on hacker servers all information on the presence of vulnerabilities in the current IMAP version (Fig. 4.6).

Proceeding in a similar way, it is possible to analyze other software, such as web servers (Fig. 4.7).

Fig. 4.6. Searching for information on IMAP service vulnerabilities at the rootshell.com server

Fig. 4.7. Analysis of the header returned by a web server

A Practical Example 

Once, I had to deal with a unique Trojan (which could not be detected by antiviral software). According to the idea of its authors, this Trojan was to steal my Internet password imperceptibly. However, when implementing the Trojan, its authors did not take into account that the victim might connect to the Internet via a LAN, rather than a dial-up connection. Being launched on computer specially dedicated for this purpose, the Trojan tried to find the RAS service in vain. Since there was no RAS service installed, the Trojan finally failed and displayed an error message (through which it was detected).

Digital "Fingerprint"

This indicator also finds application in security analyzers and is based on a comparison of the software fragment's digital "fingerprint" and the "fingerprint" of a well-known vulnerability. Antiviral software products also use a similar method by comparing the fragments of software being scanned for viruses with virus signatures stored in a special database. Control sums or dates of the software being analyzed represent a variation of this indicator. If the current value does not match the standard one, this means that the object being controlled was changed (this change might have occurred as a result of the attack).

---