´ Raul Siles Pelaez ´

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

NS

GIAC Certified Intrusion Analyst (GCIA)
(Version 3.3)

© SANS Institute 2004,

©

SA

In

sti

tu

As part of GIAC practical repository.

te

20

04

,A

December 24, 2003

ut

ho

rr

eta

ins

Detecting Real World ARP Spoofing attacks and other IDS detects analysis

fu ll r igh ts.

Author retains full rights.

Raul Siles - GCIA ´

Abstract
This paper is the practical assignment required to obtain the GIAC Certified Intrusion Analyst, GCIA, certification (version 3.3). It consists of three parts:

- Second part analyzes three network detects and all their details: a stealth NULL scan, a specific ICMP ping type (speedera) and the LovSan worm, exploiting a Windows RPC vulnerability.

Acknowledgments
“The only thing necessary for evil to triumph is for good men to do nothing.” -Edmund Burke ´ Monica, for sure this paper wouldn’t have seen the ligth of day without all Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D Let’s enjoy A169 4E46 your help, support and “publishing” guidance ;-). F8B5 06E4 our first Christmas married !!!! Everything in life is all about you !!

tu

te

20

04

,A

ut

ho

rr

eta
A ´ Thanks so much to the three LTEX gurus: Monica, Vic
1 2

ins

- Third part provides a extensive report of a security audit for a University, obtained by analyzing several days’ worth of IDS log files.

Vicente Navarro Jorge Ortiz 3 David Perez

©

SA

Thanks both, David and Jorge for your review.

NS

David 3 , it has been a pleasure sharing the GCIA certification period and even finding Snort bugs together ;-)

In

sti

2

© SANS Institute 2004,

As part of GIAC practical repository.

fu ll r igh ts.
1

- First part focuses on analyzing the network detection solutions below layer-3, presenting a white paper based on detecting real world ARP spoofing attacks.

and Jorge 2 .

Author retains full rights.

Contents
1 Real World ARP Spoofing detection 1.1 Attack description . . . . . . . . 1.2 Situation without IDS sensors . . 1.3 IDS signatures and detects . . . 1.3.1 HIDS: arpwatch . . . . . 1.3.2 NIDS: Snort . . . . . . . . 1.4 Snort ARP history . . . . . . . . 1.5 Conclusions . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 7 8 8 10 12 14 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 16 16 18 23 24 27 31 34 37 39 41 42 42 43 46 47 47 50 52 53 54 55 57 57 57 60

2 Three network detects 2.1 DETECT 1: “NULL scan” . . . . . . . . . . . . . . . . . . . . 2.1.1 Source of Trace . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Detect was generated by . . . . . . . . . . . . . . . . 2.1.3 Probability the source address was spoofed . . . . . . 2.1.4 Description of attack . . . . . . . . . . . . . . . . . . . 2.1.5 Attack mechanism . . . . . . . . . . . . . . . . . . . . 2.1.6 Correlations . . . . . . . . . . . . . . . . . . . . . . . . 2.1.7 Evidence of active targeting . . . . . . . . . . . . . . . 2.1.8 Severity . . . . . . . . . . . . . . . . . A169 . . Key fingerprint = AF19 FA27 2F94. 998D FDB5 .DE3D F8B5 06E4 . . . .4E46 . 2.1.9 Defensive recommendation . . . . . . . . . . . . . . . 2.1.10 Multiple choice test question . . . . . . . . . . . . . . 2.2 DETECT 2: “PING speedera” . . . . . . . . . . . . . . . . . . 2.2.1 Source of Trace . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Detect was generated by . . . . . . . . . . . . . . . . 2.2.3 Probability the source address was spoofed . . . . . . 2.2.4 Description of attack . . . . . . . . . . . . . . . . . . . 2.2.5 Attack mechanism . . . . . . . . . . . . . . . . . . . . 2.2.6 Correlations . . . . . . . . . . . . . . . . . . . . . . . . 2.2.7 Evidence of active targeting . . . . . . . . . . . . . . . 2.2.8 Severity . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.9 Defensive recommendation . . . . . . . . . . . . . . . 2.2.10 Multiple choice test question . . . . . . . . . . . . . . 2.3 DETECT 3: “Reached by the LovSan worm” . . . . . . . . . . 2.3.1 Source of Trace . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Detect was generated by . . . . . . . . . . . . . . . . 2.3.3 Probability the source address was spoofed . . . . . .

©

SA

NS

In

sti

tu

te

20

04

,A

ut

© SANS Institute 2004,

As part of GIAC practical repository.

ho
3

rr

eta

ins

fu ll r igh ts.

Author retains full rights.

. . . . . . . . . . . . . . . . .4. . . . . .4. . Multiple choice test question .possibleF8B5 WormA169 4E46. . . . . . . .11 Alert #11: ICMP SRC and DST outside network . . . . SA NS In sti tu te 20 © SANS Institute 2004.9 Alert #9: FA27 2F94 998D FDB5 DE3D Red 06E4 . . .8 Top ten talkers . .4. . . . . . . .4. . . . . . . . .7 List of top OOS . . . .CONTENTS 2. . . . . . . . .7 2. . . .4. . . . . . . . . . . . . . . . . . . .4 activity . . . . . . . . . . .30. . . . . . . . .2 Source of data . . .4. . Raul Siles . . . . . . . . . 3. . . . .4. 3. . . . . . . . . . . . . .NET. . . 04 . . . . 3. . . . . . . . . . . . . . . 3. . . . . . . . . . . . . 3. . . . . . . . . . . 3. . . . . . . . . . . . . . . . 3. . . . . .4. Author retains full rights. . . . . . . . . . . .4.9 Registration information (whois) . . . . .30. . . . . . . . . . . 3. . . . . . . . .3. . . . . . . 3.GCIA ´ . . . . . . .3 Network topology . . . . . . . . . . . 3. . . . . . . . . . . . . . . .traffic Key fingerprint = AF19High port 65535 tcp . . . . .4. . . . . . . . . . . . . . . . . . . 3. . . .4 Alert #4: EXPLOIT x86 NOOP . . . . As part of GIAC practical repository. . . .6 2. . .7 Alert #7: TCP SRC and DST outside network . 3. . . . . . . . . . . . . . . . . . . . . . . 3. . 3. . . . .11 Description of the analysis process . . . . . . . . . 3. 3. . . . . . .1 Executive summary .10 The link graph . . Evidence of active targeting . .10 Description of attack . . . .13 Alert #13 and beyond: Other relevant alerts . . . . . . 3. .8 2. . . . . . . . . . . . . . . . . . . . . Attack mechanism . . . Defensive recommendation . .9 2. . . . . . . . . . . . . . .5 List of portscan alerts .8 Alert #8: External RPC call . . . . .6 Alert #6: MY. . . . . . . . . . . .4. . . . . .3. . . . . . . . 3. . .12 Alert #12: All different IRC alerts . . . . . .4 List of top detects (alerts) . . . 3.3. . .A 4 ut ho rr eta ins fu ll r igh ts. . .3. . . . . . . . . . . . . . . . . .5 2. . . . . . 3. . .3 activity . . .10 Alert #10: Possible trojan server activity . . . . . . . . . . . Severity . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . . . .1 Alert #1: SMB Name Wildcard . . . . . . .6 List of top scans . . . . . . 61 63 65 66 67 68 70 71 71 73 74 77 77 80 82 84 85 87 87 89 91 93 95 96 98 99 100 103 105 106 110 110 113 References © 3 Analyze This 3. . . . .4. . .3. . . . . . .3 Alert #3: MY. . . . . . . . . . . . . . . . 3. . . . .NET. . . . .4 2.3.3. . . . . . . . . . . . Correlations . . . . . .2 Alert #2: SMB C access . . . .5 Alert #5: connect to 515 from inside . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . .

1. it will inform the destination system. So from this moment. To be able to detect ARP attacks. through a second crafted ARP packet. . ” Extracted from [ARPS1]. In the same way. both systems will interchange information through the attacker’s system and only because attacker’s system has asked them politely to do so . The network diagram in figure 1. method known as packet crafting.2(8)SA5. and “NIDS” is the system monitoring all network 5 © SANS Institute 2004. The “Real World ARP Spoofing” document [ARPS1] has been used as the reference for all the aspects related with the attack. with an example developed in a real environment.Chapter 1 Real World ARP Spoofing detection Abstract This paper is focused on the detection of real world ARP spoofing attacks using the latest versions of the most common open-source freely available IDS tools. that the IP address of the source is associated to his MAC address too.1 Attack description Lab environment description: An Ethernet switched network was used. based on a Cisco WS-C2924-XL. IOS version 11. making the two ends of a communication believe that the other end is the attacker’s system. © SA “ The ARP spoofing attack is based on impersonating a system in the network. number 2. the attacker FDB5 DE3D send a previously modified ARP packet. intercepting the traffic interchanged. It describes the basic theory around this attack and how it could be detected. Author retains full rights. KeyTo achieve= AF19 FA27 2F94 998D just needs toF8B5 06E4 A169 4E46 fingerprint this goal. to the source system of a given communication saying that the destination IP address belongs to his own MAC address. “Attacker” is the system the attack is coming from. This document covers how the defensive methods work nowadays. “System A” and “B” were the target systems. The ARP Snort preprocessor module is analyzed in detail along with its evolution over time in the last Snort versions. its signatures and the alerts generated.-). The main difference between both is that system A is more protected because it has arpwatch running. te 20 04 . the IDS solution must work below layer 3.A ut ho rr eta ins fu ll r igh ts. “Brief Description” section (page 10). Snort (network based) and arpwatch (host based). All system ports belong to the same VLAN. NS In sti tu As part of GIAC practical repository.1 will be used all along this paper.

GCIA ´ Figure 1.0. . All IP and MAC addresses have been sanitized. 04 .NIDS © SA NS Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 traffic using Snort. ATTACK DESCRIPTION Raul Siles .1a11-17.A 6 ut ho rr eta ins fu ll r igh ts.0e00.1 (Build 88) and 2. The attack is focused on redirecting all traffic from A to B (and vice versa) from (and to) “Attacker”.-------------------0e0e.---. As part of GIAC practical repository.1: ARP spoofing network diagram Switch#sh mac-address-table Dynamic Address Count: 4 Secure Address (User-defined) Count: 0 Static Address (User-defined) Count: 0 System Self Address Count: 50 Total MAC addresses: 52 Maximum MAC addreses: 2048 Non-static Address Table: Destination Address Address Type VLAN Destination Port ------------------.2 (Build 92).1.0. The operating system running in each system has been shown in the diagram.-----------. The Snort versions used were 2.0.0001 Dynamic 2 FastEthernet0/15 <-. Author retains full rights. acting as a man in the middle (MITM) box. The switch presents the following MAC address and port associations: In sti tu te 20 © SANS Institute 2004. The arpwatch version used was 2. the one included as an RPM package in Linux RedHat 8.1.

1.2 0E:0E:0E:00:00:03 192. there are two types of ARP spoofing attacks from the attacker perspective: a) The noisy version or broad attack: it is simpler because a unique packet directed to the broadcast MAC address makes all hosts in the subnet to think a given host is located at the attacker MAC address./arpplet 0E:0E:0E:00:00:99 192. because it will be received by the system the attacker is trying to impersonate. Therefore.GCIA ´ 1. As part of GIAC practical repository.0002 0e0e.System A FastEthernet0/10 <-.1.2 20 04 .168. SITUATION WITHOUT IDS SENSORS 0e0e. ho 7 rr eta ins fu ll r igh ts. and therefore it will log a “duplicate IP address!!” message. b) The silent version or selective attack: a specific packet is sent to every host the attacker is interested in redirecting its traffic.Raul Siles .2 (System A) has associated the MAC address ended in [:99]: 1. This attack requires a great effort from the attacker point of view in order to poison several hosts because different packets must be sent continuously to all them.0e00.0099 0e0e.2) that the IP at . first one redirects all traffic from A to B.System B As explained in the reference document.168.168.168. The attacker uses the “arpplet” tool [ARPS1] and issues two commands.A ut © SANS Institute 2004. more polite and elegant.1. This type of packet is usually detected even in networks without detection mechanisms (see next section). Option “b)” is the one that will be used in this paper due to be more used in the wild.2 Situation without IDS sensors In an environment without specific defensive countermeasures in place it is very difficult to detect this type of attack. broadly speaking.3) that the IP at . but no one inspects and analyzes this information in real time. Author retains full rights./arpplet 0E:0E:0E:00:00:99 192. when the ARP spoofing attack is addressed to poison all the systems in the subnet with a single packet. the paper is focused on detecting the packets that help to develop an ARP spoofing attack like the one described.Attacker FastEthernet0/14 <-. © SA NS In # . Every system could be able to figure out something strange is happening looking at their own ARP cache table.3 (System B) has associated fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 the MAC address ended in [:99] (belonging to the attacker system): The command says to System B (. It typically passes through undetected.3 0E:0E:0E:00:00:02 192. the MAC broadcast address must be used.2.0003 Dynamic Dynamic Dynamic 2 2 2 FastEthernet0/16 <-.0e00.0e00. As explained in [ARPS1]. This is a very noisy packet.1.3 sti tu te # . and second redirects the return traffic: KeyThe command says to System A (. .

almost at the sime time. the “root” user receives (by default) the e-mail in figure 1. It is a very stable tool. page 106].1.2. host based.1. fu ll r igh ts. A basic description of this tool and the type of detections it is capable of is described in [ARPW1.3) at 0E:0E:0E:00:00:03 [ether] on eth0 [root@systemA root]# arp -an ? (192.3.3) at 0E:0E:0E:00:00:99 [ether] on eth0 The same alert would be generated for the second packet if System B would have arpwatch running. see below). System A ARP table is poisoned and changes its state.1 HIDS: arpwatch Oct 20 13:23:35 systemA arpwatch: changed ethernet address 192. but it doesn’t prevent or protect against the attack: SA NS In The most common publicly available tool used as a HIDS for ARP is arpwatch [ARPW1]. such as. . due to the fact that Unix systems log this message in the generic “syslog” file. available since June 1992 for lots of different Unix platforms. arpwatch generates the following message in the syslog file: sti tu As part of GIAC practical repository.1. NIDS.168. IDS SIGNATURES AND DETECTS This situation can be easily identified using: Raul Siles .3 IDS signatures and detects 1. However. .168. Author retains full rights.3. © And. Remember arpwatch is a detection countermeasure. no false positives were generated and all ARP changes were notified Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 as expected. te 20 04 .Log parsing tools.3 0e:0e:0e:0:0:99 (0e:0e:0e:0:0:3) [root@systemA root]# arp -an ? (192.A ut ho rr eta ins This section is focused in the detection process from a practical point of view using the two most common IDSes available.GCIA ´ 1. .1. Example: When the first ARP packet (described in the attack) is received by System A and considering it already knew about System B (if this is the first packet it sees from System B it is considered a “new station”.The default notification mechanisms implemented in the TCP/IP stack of the nowadays operating systems [ARPS1]: Unix systems log the message while Windows hosts generate a pop-up window. and network based. SWATCH [SWAT1] or Logcheck [LOGC1]. HIDS. 8 © SANS Institute 2004.168. The tool has been used in the lab environment used for this paper and it works like a charm.

2003 13:24:18 +0200 Monday. sometime later. te Figure 1.domain. a non-crafted ARP packet is received from System B containing the previous.168. October 20.A ut ho 9 rr If for some reason.1. because although it is a HIDS solution it monitors all traffic seen in the wire. 20 Oct 2003 13:23:55 +0200 From: root@systemA. a new ARP-IP association is seen for the first time (figure 1.domain.Raul Siles . it has a major disadvantage if it is going to be installed in all hosts we want to protect: the huge administrative overhead associated to this deployment.4).com (Arpwatch) To: root@systemA.3: arpwatch mail for a flip-flop 20 eta ins Figure 1.1.3 0e:0e:0e:0:0:99 <unknown> 0e:0e:0e:0:0:3 Hewlett-Packard Monday.1.com Subject: changed ethernet address hostname: ip address: ethernet address: ethernet vendor: old ethernet address: old ethernet vendor: timestamp: previous timestamp: delta: <unknown> 192.168.domain. 2003 13:23:35 +0200 43 seconds NS In sti As an addition.domain. real MAC address.3 0e:0e:0e:0:0:3 (0e:0e:0e:0:0:99) Message 79: From pcap@systemA. An alternative solution could be to install it in a switch SPAN port. October 20. that is. © SA tu As part of GIAC practical repository.domain. 20 Oct 2003 13:24:38 +0200 From: root@systemA. 2003 13:23:35 +0200 Monday.com (Arpwatch) To: root@systemA.domain. these are the messages generated when a new workstation is detected.168.3): hostname: ip address: ethernet address: ethernet vendor: old ethernet address: old ethernet vendor: timestamp: previous timestamp: delta: <unknown> 192. 2003 13:22:17 +0200 1 minute Oct 20 13:24:18 systemA arpwatch: flip flop 192.3.com Mon Oct 20 13:25:56 2003 Date: Mon. Although arpwatch works really well. Author retains full rights. October 20.2: arpwatch mail for a change F8B5 06E4 A169 4E46 fu ll r igh ts. October 20. IDS SIGNATURES AND DETECTS Message 78: From pcap@systemA. . The main difference with Snort is that arpwatch can learn the MAC-IP associations in two modes: © SANS Institute 2004.com fingerprint =flop AF19 FA27 2F94 998D FDB5 DE3D Subject: flip Key 04 .com Mon Oct 20 13:26:38 2003 Date: Mon.3 0e:0e:0e:0:0:3 Hewlett-Packard 0e:0e:0e:0:0:99 <unknown> Monday. the following syslog alert would be generated (e-mail in figure 1.GCIA ´ 1.

A 10 ut ho 1.domain.168.99 0e:0e:0e:0:0:99 Message 77: From pcap@systemA. allows specifying a set of address pairs.conf” file) identified by [112:SID:1]: # Arpspoof uses Generator ID 112 and uses the following SIDS for that GID: # SID Event description © SA NS preprocessor arpspoof_detect_host: 192. This fingerprint = AF19 FA27 2F94 998D in the DE3D F8B5 06E4 A169 4E46NIDS Key module introduced a big change FDB5 NIDS philosophy because typically work at the layer 3 level. called arpspoof.dat” file.Real time learning.domain. .com Subject: new station hostname: ip address: ethernet address: ethernet vendor: timestamp: <unknown> 192. or above. IDS SIGNATURES AND DETECTS Oct 20 12:17:38 systemA arpwatch: new station 192.168. based on acquiring the new associations from the traffic listened on the wire. called preprocessor in Snort terminology.Fixed database. to detect ARP attacks. 20 Oct 2003 12:17:58 +0200 From: root@systemA. it implemented a new module. Author retains full rights. Typically. Since around August 2001 [SNOR2]. such as Linux.99 0e:0e:0e:0:0:99 <unknown> Monday. It can detect four different situations (extracted from “snort. IP.com (Arpwatch) To: root@systemA.3. 04 .1. asking for a new MAC address.168.4: arpwatch syslog message and mail for a new station Apart from that it is possible to specify if the ARP unicast requests will be monitored. The new Snort preprocessor (spp ). ins fu ll r igh ts. For example: sti tu te 20 © SANS Institute 2004.3. These packets will trigger lots of false positive messages when the “-unicast” option is used.com Mon Oct 20 12:19:59 2003 Date: Mon.1. manually configured in its “arp. .domain.1 0E:0E:0E:00:00:01 In The most common publicly available tool used as a NIDS is Snort [SNOR1]. As part of GIAC practical repository. Snort starts at the IP header to be able to perform the configured actions in order to alert or log a packet.1. 2003 12:17:18 +0200 Raul Siles . defining the relationships between a given IP address and its MAC address. a broadcast ARP request is sent to all systems in the subnet.1. but there is no layer 2 information that can be specified in the configuration or ruleset files. October 20.2 NIDS: Snort rr eta . but some OSes. implement an ARP entry validation procedure that sends unicast ARP request messages to an individual host to confirm its associated ARP entry.GCIA ´ Figure 1.

1 0E:0E:0E:00:00:01 preprocessor arpspoof_detect_host: 192. B and NIDS. the main “snort. ‘‘-d’’ (application layer) or ‘‘-X’’ (raw packet data starting at the link layer) don’t apply. As part of GIAC practical repository.conf -l . The timestamp is used to match both data sources.168.conf” statements were: Author retains full rights. so it is required to look at the packet logged in order to know the information about sender and receiver.conf” file was modified: the default variables (var) were kept untouched.GCIA ´ 1.168.A ut # snort -c /opt/snort-2.765347 In sti Example: (using Snort 2. only the binary logging mode was used and all ruleset were removed.150363 As can be appreciated. all the preprocessors were commented except the “arpspoof” one./log © SANS Institute 2004. To develop this analysis the default “snort.3.0. the Snort alert is not self-descriptive.3 0E:0E:0E:00:00:03 # Binary logging output log_tcpdump: tcpdump.2 0E:0E:0E:00:00:02 preprocessor arpspoof_detect_host: 192. such as ‘‘-e’’ (Ethernet header).1. from attacker to System B generates the same type of alert and packet (not showed): NS [**] [112:4:1] (spp_arpspoof) Attempted ARP cache overwrite attack [**] 10/20-13:23:35.168. IDS SIGNATURES AND DETECTS # ----# 1 # 2 # 3 # 4 ------------------Unicast ARP request Etherframe ARP mismatch (src) Etherframe ARP mismatch (dst) ARP cache overwrite attack Snort should be invoked in the following way when interested only in ARP packets: [**] [112:4:1] (spp_arpspoof) Attempted ARP cache overwrite attack [**] 10/20-13:23:37.0. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 .1. Therefore. .Raul Siles .1.log ins fu ll r igh ts.5: tu te 20 04 All other Snort payload and header options.2/etc/snort.2): When the first ARP packet is received by System A and Snort generates the following message in the “alert” file and logs the ARP packet (obtained through ethereal [ETHE1]) in figure 1. preprocessor arpspoof: -unicast preprocessor arpspoof_detect_host: 192. © SA The second packet. ho rr 11 eta # ARP preprocessor containing all hosts: System A.

It is not an important element because new improvements were introduced in version 2.... Snort 2.... Author retains full rights.org) for all the information provided during this research. somewhere in time.0. .x: Different Web forums talk about the existence of a verbose patch for the arpspoof Snort preprocessor [PATC1].4.0. He was the father of the spp arpspoof code. a Snort ARP related option was documented Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 but not implemented.4 Snort ARP history .. but the packet was not 12 © SANS Institute 2004. it is documented in “snortman.1. 42 bytes captured) Arrival Time: Oct 20.A ut ho rr Figure 1....1. you can see the host generating the alert..1.. Dst: 0E:0E:0E:00:00:02 Destination: 0E:0E:0E:00:00:02 (0E:0E:0E:00:00:02) Source: 0E:0E:0E:00:00:99 (0E:0E:0E:00:00:99) Type: ARP (0x0806) Address Resolution Protocol (reply) Hardware type: Ethernet (0x0001) Protocol type: IP (0x0800) Hardware size: 6 Protocol size: 4 Opcode: reply (0x0002) Sender MAC address: 0E:0E:0E:00:00:99 (0E:0E:0E:00:00:99) Sender IP address: 192..0. First of all..Snort 2. some changes were made to spp arpspoof before releasing version 2. © SA ..168..... it can be downloaded from [PATC1]. Searching in the Snort “doc” directory..2 (192.1...765347000 .1 version was capable of detecting the ARP spoofing attack and generates an alert for the evil packet..1 or above: snort -a. Src: 0E:0E:0E:00:00:99. but it doesn’t exist in version 2....3 (192. The Snort command line parameter is said to display ARP data. SNORT ARP HISTORY Frame 17 (42 bytes on wire.0..168.... te 20 04 ...1: Jul 22 18:28:29 2003 GMT In theory. . ins fu ll r igh ts.Before version 2.2) 0000 0010 0020 0e 0e 0e 00 00 02 0e 0e 0e 00 00 99 08 06 00 01 08 00 06 04 00 02 0e 0e 0e 00 00 99 c0 a8 01 03 0e 0e 0e 00 00 02 c0 a8 01 02 Raul Siles .5: ARP packet captured by Snort from H to A eta . used to dump the packets associated to the alerts.. Ethernet II..0. NS In sti Thanks to Jeff Nathan (jeff@snort.tex”: “item [decode arp]Turn on arp decoding (snort -a)”.GCIA ´ 1. If a system other than ascii logging is used.3) Target MAC address: 0E:0E:0E:00:00:02 (0E:0E:0E:00:00:02) Target IP address: 192. In practice...1 so that the packet triggering the ARP alert is sent to the logging system.168. Evolution of the arpspoof module over time and Snort versions: tu As part of GIAC practical repository.1. 2003 13:23:35.1.168.+ .....

belonging to the tcpdump binary file header: -rw------1 root root 24 Sep 17 12:05 tcpdump.conf. The previously mentioned patch supported the “-textonly” option.150363 ut © SANS Institute 2004.4.Raul Siles .1 behavior research: [**] [112:1:1] (spp_arpspoof) Unicast ARP request [**] 09/17-11:04:46.0.2 release showed “Cleanup of spp arpspoof (Jeff Nathan)”. the log file is only 24 bytes in length.1063790353 • Snort 2. the following three cases were found: ins fu ll r igh ts. no error will be generated when Snort starts. Once the Snort instance is closed.0. Apart from this.1 (Build 88) over Linux Red-Hat 7.GCIA ´ 1.log.962616 [**] [112:4:1] (spp_arpspoof) Attempted ARP cache overwrite attack [**] 09/17-10:23:37.0. the patch that supports “-textonly” was not committed to Snort CVS because it is incompatible with unified alerting and at the time. As part of GIAC practical repository. SNORT ARP HISTORY logged. and the Snort Changelog [SNOR2] details the “spp arpspoof patches from Jeff Nathan”.2: Sep 17 21:49:34 2003 sti c) “preprocessor arpspoof” plus “preprocessor arpspoof: -unicast” The three alert types were triggered but again.0. no logging. tu te 20 b) “preprocessor arpspoof: -unicas”t Only the following type of alert was Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 generated without logging: 04 . ho rr 13 a) “preprocessor arpspoo”f Only the following two types of alert were generated without logging: eta When using Snort Version 2. Be careful because if the “unicast” option is used instead of “-unicast”. but the unicast checking won’t work. SA NS This version logs (in binary mode) and alerts about the malicious ARP packets. In .0.3 with the same configuration as the one described in this paper (default variables + spp arpspoof + binary output plug-in).819208 © The Snort 2. .Snort 2. and running snort -l /tmp -c /opt/snort-2.1/etc/snort. that was considered a poor solution.A [**] [112:2:1] (spp_arpspoof) Ethernet/ARP Mismatch request for Source [**] 09/17-10:12:12. Author retains full rights.

The latest Snort version tested was 2. See the arpwatch section for the type of alerts generated in this case. There are other interesting ARP packet considerations that should be mentioned: Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 .A 14 ut ho rr eta ins fu ll r igh ts. Snort is a complex IDS tool. tu te The two most common open-source IDS applications were tested in a real environment checking their capabilities for detecting ARP spoofing attacks. Author retains full rights. This situation is being researched at the time this paper was finished. It will be interesting to see how it matures in future versions.5 Conclusions . © SA NS In sti At first sight it doesn’t seem to influence the IDS.2 and it generates lots of false positives associated to standard. When the traffic has been redirected to the attacker system and the attack has finished.5. . such as in this case. Snort is a very noisy IDS ARP detector when the “-unicast” option is used in Linux environments. CONCLUSIONS Raul Siles . the attacker could be interested in restore the previous ARP entry in the target system not to interrupt the communications (in order to shutdown his own box).GCIA ´ 1. such as ARP broadcast requests and the corresponding replies. all packets are detected given the fact that they have been received by the sensor and it is not overflowed. To do so he must send a new ARP packet associating the target IP address with the real MAC address and not with the attacker MAC. layer 2.How do the IDS sensors behave when an ARP “backward” packet is sent? A backward packet refers to the ARP packet that could be sent by the attacker in order to leave everything in its previous state.0. As part of GIAC practical repository. not evil. called “flip-flop”.Is there any difference in the detection method based on the number of times per time unit the forged ARP packet is sent? 20 © SANS Institute 2004. It develops its goal really well. 04 . It seems this second ARP change is also detected by the IDS as a new address swapping. This module will be really helpful against the attacks described in this paper but some tuning is needed. traffic. and it is mainly focused on detecting all kind of attacks at layer 3 or above. arpwatch is an stable and accurate tool whose only purpose is detecting changes between the IP and MAC addresses associations.1. The detection of ARP attacks introduce a new idea on the way IDS network solutions work: attack detection at layer 3 or below. so it is converted into an alert. A new preprocessor was introduced to detect ARP attacks but it is considered by itself as “experimental”.

Stephen Hansen and Todd Atkins.A ut [SWAT1] “Swatch”.org (23 Nov. 2003) Author retains full rights.org/practical/GCIH/Raul_Siles_GCIH. Raul Siles Pelaez. 2003) [SNOR2] “Snort Change Log”. Marti Roesch.gov/arpwatch. 2003) © SANS Institute 2004. 2003) Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SA NS In sti tu te 20 04 . http://www-nrg. [ARPW1] “Arpwatch”. lbl. http://sourceforge. .ethereal.Raul Siles . http:// marc.gov/nrg. purdue. Snort-devel.cerias. ftp://ftp.tar.pdf (1 Nov. http://www.net/projects/sentrytools (5 Dec.theaimsgroup. http:// ´ www. 2003) [SNOR1] “Snort NIDS”. 2003) [ETHE1] “Ethereal”.ee.com/?l=snort-devel&m=104700273309905&w=2 (5 Dec.ee. As part of GIAC practical repository.GCIA ´ BIBLIOGRAPHY Bibliography ´ [ARPS1] “Real World ARP Spoofing”.html ftp://ftp.org/downloads/ (3 Dec. http://www.edu/pub/tools/unix/logutils/swatch/README (5 Dec.giac.gz (10 Nov.org (17 Nov. 2003) [PATC1] “spp arpspool patch to generate verbose alerts”. August 2003.snort.snort. http://www. ho rr 15 eta ins fu ll r igh ts. 2003) [LOGC1] “Logcheck”.lbl.

Chapter 2 Three network detects I received some responses in the intrusions. It is important to note for the analysis that all ICMP.cs. apart from being used for the reliable SYSLOG service (syslog-conn).de/archive/intrusions/2003/11/msg00147. Any of them are very common applications. only the packets that violate the ruleset will appear in the log. it can be used by AFS. Other Data Grid environments also use TCP port 601 4 .ps 4 http://gass. The file analyzed is named “2002.23” and as it has been already pointed out by other GIAC students. 04 .org mailing list related to this detect posted on Wed. [**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 The log file analyzed has been obtained from “incidents. is unknown.A The following alert message corresponds to the detect that is going to be analyzed: 16 ut 2.th/~bank/project/dig/Untitled-1. for remote authentication ta-rauth. . there is a one month mismatch between the date in the file name and the timestamps in the network traces.uni-stuttgart. This file is the result of a Snort instance running in binary logging mode so.htp 3 http://www.ltsw. typically associated to TCP/UDP ports 997. This port.1. Apart from the possible set of official services that can listen in this port.incidents.org/logs/Raw/ © SA NS In sti tu te 2. it seems the port was selected to reach a port that very likely will be closed. As part of GIAC practical repository. Andrew File System. This process exports tasks in load sharing environments 3 . so the remote system would reply with a RST packet to the original XMAS packet.berkeley.org” 5 . DNS. The ruleset used to generate the log file.1 DETECT 1: “NULL scan” ho rr eta ins fu ll r igh ts.html http://www. SMTP and Web traffic has been removed from these logs. David Barroso asked me to provide more information about the purpose of scanning TCP port 601. Author retains full rights.1 Source of Trace 20 © SANS Institute 2004.ac. 19 Nov 2003 1 . that is. the one that triggered the alerts.htm 5 http://www.8.cpe. The packets reflect 23rd 1 2 http://cert.se/knbase/tcp/tcp1. Other references assign TCP port 601 to “maitrd” 2 .ku. For example.edu/projects/sprite/papers/thesis-Douglis.

1n -k2.GCIA ´ 2.4n # tcpdump -nn -e -r 2002. Organization Unique Identifiers. NS In sti • IP addresses involved in the conversations from [0:3:e3:d9:26:c0] to [0:0:c:4:b2:33]: tu te b) Layer 3 information: IP network spaces associated to all the traffic in the binary log file. while the second command is used to extract the information about the destination addresses.3n -k4.8.org/regauth/oui/index.X. 2002 (09/23/2002). The Snort IDS was placed between both Cisco devices. 20 Therefore.23 | \ grep -F "0:3:e3:d9:26:c0 0:0:c:4:b2:33" | cut -d ’ ’ -f 6.74.23 | cut -d ‘ ’ -f 2.23 | cut -d ’ ’ -f 2.3 | sort -u ins • The same information can be extracted from all the traffic contained in the binary log file: fu ll r igh ts. so it is likely that both are routers interconnecting different networks.ieee. Author retains full rights. Inc.2.X address range.4 | sort -u The first command is used to extract all conversations sorted by source address. .3. Both use the tcpdump command-line tool [TCPD1].8 | \ sort -u -b -t\. are registered to Cisco Systems. To get the network topology where the sensor was running the traffic captured must be analyzed.2n -k3. Snort -y option let you show the year in the timestamps: 09/23/02. all layer 2 traffic in the Snort log file occurs between two devices with the following MAC addresses: [0:0:C:4:B2:33] and [0:3:E3:D9:26:C0]. ho rr 17 eta # tcpdump -nn -e -r 2002.8. a) Layer 2 information: Source and destination MAC addresses in all conversations. 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 = AF19 FA27 04 .8.23 | \ grep -F "0:3:e3:d9:26:c0 0:0:c:4:b2:33" | \ cut -d ’ ’ -f 8 | cut -d ’. DETECT 1: “NULL SCAN” of September.1.2002. All traffic goes from several public IP addresses (around 71 addresses) to 9 different addresses belonging to the 115. obtaining information such as: • MAC addresses involved in all Snort alerts reported: # grep -F ‘‘type:0x800’’ alert.A ut © SANS Institute 2004. -k1.shtml SA # tcpdump -nn -e -r 2002. Both OUIs.. The MAC addresses registration information can be obtained from the Key fingerprint the IEEE at 6 . As part of GIAC practical repository.’ -f 1. 00-000C and 00-03-E3.Raul Siles .4 | \ sort -u 0:0:C:4:B2:33 0:3:E3:D9:26:C0 \ 0:3:E3:D9:26:C0 0:0:C:4:B2:33 © 6 http://standards.8.

51. running on a RedHat Linux 9.0.74. As part of GIAC practical repository.65.80: 115.3. getting the source and destination addresses respectively: Author retains full rights.239.2 (Build 92).2 while analyzing this traffic (2003-10-28) 7 .2. The detect was generated through the Snort [SNOR1] Network Intrusion Detection System.202 (there is only one connection from this IP) and .2 configuration file has 21714 bytes and its timestamp is Jul 1 16:32.4 | sort -u ins fu ll r igh ts.74.Cisco device --.’ -f 1. The Snort version 2.1n -k2.8.0/5 (Internet) IDS sensor (Snort) (IANA reserved) 18 ut ho Based on this layer 2 and 3 analysis.sourceforge.0.16. The data has been extracted using a similar procedure.249.4n 115. the one involved in the alert analyzed.0. The 11 “include” rule lines commented by default in this file were activated. -k1.0. the topology of the network monitored by the Snort IDS reporting the alerts should look like the one in figure 2.1.0/24 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 115.61107 216. 04 .net/viewcvs.1: IDS Network Topology for detect1 20 192.202.2 Detect was generated by sti tu te Figure 2.2.0/16 © SANS Institute 2004.py/snort/snort/ChangeLog?rev=HEAD © SA NS In 2. rr eta # tcpdump -nn -e -r 2002.8.0.0.80 193. The bug affects the number of alerts that are 7 http://cvs.249.8 | \ sort -u -b -t\. The ruleset used to generate the binary log files provided in the “Raw” directory is unknown.Cisco device --. Apart from using this default file.1.Hub/Switch/Tap --.23 | \ grep -F "0:0:c:4:b2:33 0:3:e3:d9:26:c0" | \ cut -d ’ ’ -f 8 | cut -d ’.101.198.1.0 system for an Intel platform.2n -k3.31.65.33. version 2. . a bug was found on Snort 2. therefore. NIDS. .A External network ---.conf” were used.23 | \ grep -F "0:0:c:4:b2:33 0:3:e3:d9:26:c0" | cut -d ’ ’ -f 6.74.1213: The last line shows the specific address ranges involved in the alerts analyzed. # tcpdump -nn -e -r 2002. DETECT 1: “NULL SCAN” Raul Siles .GCIA ´ • IP addresses involved in the conversations from [0:0:c:4:b2:33] to [0:3:e3:d9:26:c0]: All traffic goes from 2 internal IP addresses.61.3n -k 4. to several different public IP addresses (around 198).Internal 0:3:E3:D9:26:C0 | 0:0:C:4:B2:33 network | 112. a default ruleset slightly modified and Snort configuration file “snort.

also commented by David Markle in his GCIA practical. Thanks to Chris Green from Sourcefire for this piece of information. When the flow:established keyword is used within any given rule and the TCP Stream Reassembly preprocessor is active.html © The reason for this. Snort has not been able to recreate its exact output from its own output for quite some time or versions. therefore. if a packet is sent with the ACK bit set and no previous SYN or SYN/ACK packets were seen. Snort would not consider the packet for testing against the given rule.uni-stuttgart. Analyzing the default Snort ruleset. Therefore.1. can be easily explained by the fact that those logs do not include the TCP session information to recognize a session as established. Snort will maintain the state of all connections the IDS is monitoring. there are 1998 alert rules.fixed Author retains full rights.23.A ut © SANS Institute 2004.Raul Siles .8.log. about ten times smaller in size: • Original Snort binary file: -rwxr-x--1 rsiles rsiles 3895751 Oct • Processed file: -rwxr-x--1 rsiles rsiles 319286 Oct 29 # cd /opt/snort-2.8. ho rr 19 eta ins fu ll r igh ts.2002.html http://rain. apart from the one associated to the probable difference between the ruleset and the configuration file used when the alerts were generated and the ones available nowadays. they are not able Keyto get all the AF19 FA27 2F94 998D FDB5 DE3DaF8B5 06E4 A169 4E46 cannot be fingerprint = packets that triggered an alert so session reconstruction performed.23 snort. This is one of the main problems IDSes have. verifying if the alert corresponds to a established session. To be able to do so. analyzed at the end of this section.prohosting. As part of GIAC practical repository. more than 75% of the rules generate alerts only when the status information about the session is available: SA NS In sti tu te 20 04 .2/rules # cat * | grep "alert" | grep -v "^#" | wc -l 1998 # cat /opt/snort-2. Therefore. There is a good bit of detection state information lost in the process.2/rules/* | grep "flow" | grep "established" | wc -l 1516 8 9 http://cert.de/archive/intrusions/2003/11/msg00031.0. In 1516 of them stateful checking is performed through the flow:established statement. a network audit trail is a must. It must be noted that the binary log file obtained after processing the original one (using the Snort -b option) is very different from it.com/rsiles/snort. .0. 9 2002. DETECT 1: “NULL SCAN” reported by Snort. the configuration file was modified with the recommended workaround to develop the rest of this analysis 8 9 .GCIA ´ 2. Snort has the ability to monitor state in its Stream Reassembly Preprocessor.

2.2. © # cat alert. binary log file to get the network traces from (libpcap format).2002. dump the raw packet data starting at the link layer. 04 . turns off the entire checksum verification subsystem.txt 121 [**] [1:648:5] SHELLCODE x86 NOOP [**] 55 [**] [1:1390:3] SHELLCODE x86 inc ebx NOOP [**] 24 [**] [1:1394:3] SHELLCODE x86 NOOP [**] 11 [**] [1:628:2] SCAN nmap TCP [**] 6 [**] [111:11:1] (spp_stream4) STEALTH ACTIVITY (Vecna scan) detection [**] 5 [**] [116:46:1] (snort_decoder) WARNING: TCP Data Offset is less than 5! [**] 5 [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**] 4 [**] [111:8:1] (spp_stream4) STEALTH ACTIVITY (FIN scan) detection [**] 3 [**] [1:650:5] SHELLCODE x86 setuid 0 [**] 3 [**] [1:649:5] SHELLCODE x86 setgid 0 [**] 2 [**] [1:522:1] MISC Tiny Fragments [**] 2 [**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] 1 [**] [1:653:5] SHELLCODE x86 unicode NOOP [**] 1 [**] [1:523:4] BAD-TRAFFIC ip reserved bit set [**] SA NS The file triggered a total of 243 alerts: # grep -F "[**]" alert. . lots of alerts will be missed due to the sanitization process. as exposed in the “README.8.1.23_summary. -c FILE: -l DIR: -r FILE: -A full: -q: -e: -d: -U: -X: -N: -k none: specifies the \snort{} configuration file (described above) and run \snort{} in NIDS mode.8./log/alerts_by_file \ -r 2002. display the application layer data.8. due to the fact that the IP addresses have been sanitized and the checksums have been modified in order to hide the original addresses.23 | wc -l 243 10 http://www.incidents.23 | grep -F "[**]" | sort | uniq -c | sort -rn | tee alert.2/etc/snort.23 -k none -A full -qedUX -N Snort options are shown in figure 2. It will only generate the alerts file.0.A 20 ut ho rr Figure 2. Author retains full rights.GCIA ´ # snort -c /opt/snort-2. turn off logging. The complete set of alerts triggered by this file and its number of occurrences are Key fingerprint =2.8.3: Alerts triggered for detect1 sti tu te 20 All packets have an incorrect checksum. use UTC reference for timestamps. display layer-2 header information.2: Snort Options for detect1 eta ins fu ll r igh ts.2002.org/logs/Raw In Figure 2.3: FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 shown in figure AF19 © SANS Institute 2004.2002.txt” file of the binary log repository at 10 . such as Ethernet. As part of GIAC practical repository. generate alerts showing full decoded header and the alert message. don’t show banner and status/summary report. If not used. both at the IP and TCP headers. DETECT 1: “NULL SCAN” The following command was used to analyzed the log file: Raul Siles . logging directory: alerts and packet logging.conf -l .

=since then for every byte that is exchanged.23”. They were IP packets (type:0x800) and 74 bytes (len:0x4A) were captured in the wire for both.TTL: 50. A169 4E46 is set.249.GCIA ´ 2.16.19. Other packet features are: . going to MAC address [0:3:e3:d9:26:c0]. to destination host 198. As part of GIAC practical repository.A ut © SANS Institute 2004. [**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] 09/23-19:38:49. .Raul Siles . 20 of TCP header and 20 of TCP options (4 options x 5 bytes/option). Therefore. The packets that triggered both alerts were traveling from source host 115.19:21 TCP TTL:50 TOS:0x0 ID:57688 IpLen:20 DgmLen:60 ******** Seq: 0xD53E5D5B Ack: 0x0 Win: 0x800 TcpLen: 40 TCP Options (4) => WS: 10 NOP MSS: 265 TS: 1061109567 0 Figure 2. The TCP specification defines that at least one of the 6 flag bits in the TCP header must be set. 20 bytes of IP header (IpLen:20) and 40 bytes of TCP (TcpLen:40).61.16. © SA NS In sti tu te 20 04 .836507 0:0:C:4:B2:33 -> 0:3:E3:D9:26:C0 type:0x800 len:0x4A 115.249. the SYN Keyflag is set. .74.3 seconds between them. A fingerprint AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 the ACK flag connection can be terminated through the usage of the RST (abortive) or FIN-ACK (orderly) flags.65:61616 -> 198.136507 0:0:C:4:B2:33 -> 0:3:E3:D9:26:C0 type:0x800 len:0x4A 115.65:61616 -> 198. coming from MAC address [0:0:c:4:b2:33].74.61. although more than one can be activated [STEV1]. DETECT 1: “NULL SCAN” This Snort instance generated an “alert” file of 88206 bytes. Summarizing the TCP flags usage. the datagram at layer-3 has 60 bytes (DgmLen:60). when a connection is established.16. typically associated to the FTP service (control channel).4: Network detects for detect1 Alerts were triggered because Snort detected two TCP packets without any flag set.The IP identification field is different between both packets which is normal: 11286 and 57688. The detect was selected based on the fact that no one had analyzed the “NULL scan” previously and that the file I’m focusing on has only been analyzed in one practical (referenced in the Correlations section).74.2002. Both packets come from TCP source port 61616 (ephemeral port) and go to TCP destination port 21.19:21 TCP TTL:50 TOS:0x0 ID:11286 IpLen:20 DgmLen:60 ******** Seq: 0x417A1598 Ack: 0x0 Win: 0x800 TcpLen: 40 TCP Options (4) => WS: 10 NOP MSS: 265 TS: 1061109567 0 [**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] 09/23-19:39:00.1.65.8.61.249. The default Snort “alert” file was renamed to “alert. Author retains full rights. ho rr 21 eta ins fu ll r igh ts. The IDS detected two NULL scan activities with an interval of exactly 10. 14 bytes belonging to the Ethernet header.

2.1. DETECT 1: “NULL SCAN”

Raul Siles - GCIA ´

- The TCP sequence numbers are also different between both packets, showing they belong to a different TCP session because the difference between both is huge: 1098519960 and 3577634139. - The TCP window size for both is 2048.

"[111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection"

has not been triggered by an standard Snort rule but by a Snort preprocessor (spp_) called stream4. The stream4 preprocessor spp_stream4 or “Stateful inspection/Stream reassembly”, initially developed by Marty Roesch, is the Snort component in charge of detecting protocol anomalies and ensure Snort will interpret the packets as the destination host would do. It normalizes TCP sessions, using TCP stateful inspection and correlation techniques between packets, so other Snort preprocessors and rules obtain a reliable TCP stream. It is also responsible of detecting portscan and fingerprinting attacks. The default Snort stream4 preprocessor options were used to generate the alert: “preprocessor stream4: detect scans, disable evasion alerts”

©

SA

NS

In

sti

tu

The Window Scale option can only appear in a SYN segment [STEV1, page 347] so the scale factor could be defined in each direction when the connection is established. The NOP option is used for padding to a multiple of 4-bytes. A MSS option can only appear in a SYN segment [STEV1, page 237], defining the largest amount of data that TCP will send to the other end. Finally, the Timestamp option can be used by the sender, placing a timestamp value in every segment, in order to let the receiver resend this value in the ACK packet, being possible for the sender Key fingerprint = This FA27 must be sent in the SYN packet to be used in future to calculate the RTT. AF19option 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 segments [STEV1, page 349]. It must be noted that the “Host Requirements” [RFC1122, page 84] requires TCP to accept any TCP option in any segment. The type of alert corresponding to this detect:

te

20

© SANS Institute 2004,

As part of GIAC practical repository.

04

,A

22

ut

ho

rr

eta

-

Window scale: 10 (multiply by 1024: 210 ) - defined in [RFC1323]. NOP (No option) - defined in the original TCP [RFC793]. Maximum Segment Size (MSS): 265 - [RFC793]. Timestamp: 1061109567, tsecr: 0 - [RFC1323].

ins

fu ll r igh ts.

These TCP/IP values don’t correspond with any of the default OS values used in passive fingerprinting methods [PASS1]. The most probable reason is that the packets used have been crafted and have not been generated by the default TCP/IP stack of one of the nowadays most common OS. This information would have helped us to know more about the OS of the systems involved in the alert. Finally, both contain 4 TCP options:

Author retains full rights.

Raul Siles - GCIA ´

2.1. DETECT 1: “NULL SCAN”

2.1.3

The log files have been sanitized, modifying the IP addresses of the protected network. The external IP addresses have not been changed. This information must be considered when analyzing the IP addresses involved in the detect. Typically, the TCP sessions are difficult to be spoofed, due to the fact that the 3-way handshake must be completed and, continuously, the sequence number validation must be synchronized in order to continue sending and receiving data. The packet inside this detect, a NULL packet, cannot belong to an existing TCP 23

© SANS Institute 2004,

©

SA

Probability the source address was spoofed

NS

These directives tell Snort to look for stealth scans, as the one analyzed, and turn off the noisy mitigation of overlapping sequences, a technique used to evade the IDS detection (see the Snort documentation [SNOR2]). Stream4 uses GID (Generator ID) 111 and NULL scan has been given the SID (Signature ID) 9. It is using the first revision (:1) of this signature, so the alert identifier is [111:9:1]. The Snort generators (GID) are defined in the “generators” file inside the configuration directory, “etc”, while the messages associated to each GID are defined in the “gen-msg.map” file. The scan attacks try to obtain as much information as possible from the target system. This alert has been classified as STEALTH ACTIVITY, SIDS 6 to 13. The stealth scans pretend the scan traffic not to be logged, pass through clandestine, not like the SYN scans detected by the typical network monitoring tools, such as firewalls, packet filters, Synlogers... Snort has a stateful inspection capability associated to the stream4 preprocessor to reduce the amount of spoofing/evasion against Snort. If activated, through the -z switch, it checks the TCP state of a packet and generate alerts only for packets belonging to a known established session. This switch acts as if the flow:established keyword were used in ALL the Snort rules. This state monitoring was added to counter attack obfuscation attempts [ROBE1] as the ones performed by tools such as Stick [STIC1] and Snot [SNOT1]. These Keytools build randomFA27 2F94 998D FDB5on the Snort06E4 A169 4E46 only goal of fingerprint = AF19 noise packets based DE3D F8B5 ruleset with the generating a huge amount of bogus alerts. If the -z switch is used within the Snort instance previously run for this detect, both stream4 alerts, the NULL scan and the XMAS scan (described later), are triggered again. The reason is that both packets are anomalies of the TCP protocol, they would never be part of a “normal/standard” TCP session, so the stateful information associated to the established connections doesn’t influence their detection. Another reason is that both alerts are not generated by a rule, but by the preprocessor itself.

In

sti

tu

As part of GIAC practical repository.

te

20

04

,A

ut

ho

rr

eta

ins

fu ll r igh ts.

Author retains full rights.

2.1. DETECT 1: “NULL SCAN”

Raul Siles - GCIA ´

The detect belongs to a reconnaissance attack, a method that implies informaKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 tion/intelligence gathering. The attacker is trying to find what hosts and services are available. Sometimes this is done in preparation for a future attack, or sometimes it is done to see if your system might have a service which is susceptible of being attacked. Due to the fact that TCP doesn’t define packets without any flag turned on, these packets have been crafted. It seems there is no CVE [CVE1] number associated to this type of scan. Due to the fact that it is a generic scanning technique, it is not possible to find references in Bugtraq either [BUGT1]. A very important point about the type of attack associated to a given detect is trying to obtain information about the tool used to run it, the one that generated the packet. Due to the fact that this is a kind of portscan, nmap [NMAP1] was checked at first instance. nmap supports a large number of scanning techniques, such as NULL scans, using the -sN option. The first test run tried to simulate the generation of a NULL scan against port 21 using the command in Figure 2.5. The nmap version used was 2.54BETA31, the default version in Red Hat 7.3. The
11

http://www.cuny.edu

©

SA

NS

In

sti

tu

te

20

© SANS Institute 2004,

As part of GIAC practical repository.

04

,A

2.1.4

Description of attack

24

ut

ho

connection, therefore the source IP address can be easily forged. The port scan reconnaissance technique used to be developed using real addresses, because the attacker’s main goal is to be able to receive the responses generated by the destination host scanned, so it is almost certain that the source address has not been spoofed. This statement is also supported by the fact that the source address belongs to the internal network, more accurately to a possibly compromised system (see the next sections), so the detect was generated by an outgoing packet. Checking the source IP address, 115.74.249.65, in ARIN, the American Registry of Internet Numbers [ARIN1], the network address space this IP belong to is 96.0.0.0 - 126.255.255.255, declared as IANA Reserved. Specifically it belongs to network 112.0.0.0/5. Therefore, it is the source IP address the one that belongs to an IANA reserved block, thus, the one that have been sanitized. The same type of search associated to the destination address, 198.61.16.19, shows it corresponds to the address range belonging to the York College of the City University, 198.61.16.0 - 198.61.31.255. This college belongs to the City University of New York 11 and is located in Jamaica, NY, USA. Trying to resolve this destination IP address there is no public hostname associated to it.

rr

eta

ins

fu ll r igh ts.

Author retains full rights.

don’t use reverse DNS resolution of the host it finds.1. When nmap [NMAP1] is used to fingerprint the operating system of a remote host.7... the default version available in Red Hat 8.There are no TCP options inside the packet. .168.... As part of GIAC practical repository.54BETA31 # nmap -sN -P0 -n -p 21 192.14 Options: -sN: -P0: -n: -p 21: 192. The packet generated by nmap is shown in Figure 2.r. a set of specially crafted packets are sent in order to analyze the responses generated by the host [NMAP2].00.. P. ItFDB5 DE3D F8B5 06E4 A16955 for NULL scans: 54.. Besides..6.48-1 was run on a Red Hat 7. instead.505065 0:1:2:3:45:f 2 > 192.14: 2. therefore the packet length has been reduced in 20 bytes.0 and 9. ...GCIA ´ # nmap -V nmap V........ fingerprint = AF19 is 55 instead of 50. 14:27:28.TCP sequence number and ACK has a zero value. DETECT 1: “NULL SCAN” Figure 2.1.49.It uses a TCP window of 4096.168. another packet crafting tool could have been used. So initially. the same test was developed using nmap version 3. it seemed nmap was not used to generate it. although it doesn’t allow to set all the TCP options seen in the packets of this detect. A deeper research analysis helped in obtaining which tool generated these packets. len 40) 3706 cccc c0a8 0131 E. . .1.... The packets generated are very similar but with a different TCP window.The TTL value FA27 2F94 998D seems nmap uses values around 4E46 55.1.. Using nmap version 2.6: Nmap different packet Key To confirm these results.7)..Raul Siles . it varies in every execution: 1024.1 with similar results. destination_IP Author retains full rights. 20 04 .. scan port 21. By default hping sends TCP packets without any flag set. the latest nmap version. ho rr 25 eta ins fu ll r igh ts. 2. 3072.. [tcp sum ok] 0:0(0) win 4096 0x0000 4500 0028 8d8a 0000 0x0010 c0a8 010e e472 0015 0x0020 5000 1000 9393 0000 0:1:2:3:45:41 0800 54: 192.5: Nmap options IP addresses inside the packet were sanitized and the checksums modified. like hping [HPIN1].1.21: . id 36234..A This packet differs from the one analyzed in several elements: ut © SANS Institute 2004. 3.168.. 57. don’t ping host before scanning them.54BETA31 the same packet as the one present in the detect can be generated (see figure 2.(.1 0000 0000 0000 0000 .14.. © SA NS In sti tu te .0.. ..168.5848 (ttl 55. . using the -O option. Figure 2. 2048.. use a NULL scan.

which could indicate that one of the local hosts (the source IP address) has been compromised and it is being used to scan other external systems..229. nmap uses some random ports and add to them the ones indicated by the user. This NULL packet differs from the one available in the detect in some elements: ins fu ll r igh ts.... len 60) 0x0000 4500 003c 7279 0000 3206 0f0f c0a8 01e5 E. It must be noted that TTL value is network topology dependant because it is influenced by the number of hops the packet has gone through.229.1.nmap uses a variable TCP window: 1024.[..167563 192. This is not relevant. 0x0030 080a 3f3f 3f3f 0000 0000 0000 . 2048. The scanning packets are going out from the internal network.7: Nmap similar packet All the other important fields. but valid.mss 265... [tcp sum ok] 2889333191:2889333191(0) ack 0 win 3072 <wscale 10.168.. like the one reflected in the destination IP address (see the Attack mechanism section for more information). DETECT 1: “NULL SCAN” Raul Siles ..228.. id 29305... going out from an internal system.<ry...62395 > 192.... len 60) Figure 2... 20 © SANS Institute 2004.????...31708: .1... 0x0010 c0a8 01e4 f3bb 7bdc ac37 b9c7 0000 0000 .. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D in the06E4 A169 4E46argu.168.eol> (ttl 50.168. As part of GIAC practical repository.. as the ACK value. one of the possible values used by nmap when fingerprinting a system..The TTL value is 50. Author retains full rights. value..31708: .timestamp 1061109567 0. © SA NS In sti tu te .168.timestamp 1061109567 0.228. In a future and deeper analysis it would be interesting trying to simulate the retransmissions and sequence of packets (see the next section) obtained in the detect network traces associated to the NULL and the XMAS packets. One of those appear in the detect..mss 265.The destination port doesn’t match the specified F8B5 command line ments. Other values seen are in a range between 37 and 56. 04 .1.1.2.62395 > 192. these are two NULL packets.GCIA ´ # nmap -sN -P0 -n -p 21 -O 192. .A 26 ut ho rr eta NOTE: As it will be analyzed in the next section. 3072.TCP sequence number: it has another..nop.1. apart from the NULL packet there are other packets associated to the same scanning process.. 0x0020 a010 0c00 9a5b 0000 0303 0a01 0204 0109 .. all TCP options and the packet size are the same..2. id 29305.168. [tcp sum ok] 2889333191:2889333191(0) ack 0 win 3072 <wscale 10.{. . 4096..eol> (ttl 50. 13:01:23... Once the fingerprinting method has been completed. being part of a reconnaissance attack whose purpose is to fingerprint the OS of a remote host.nop. To sum up.. the most probable next stage in the attacker activities will be a specialized attack again the target operating system and services based on the information obtained. ...7.. 13:01:23..1.167563 192...14 .

61. binary log file to get the network traces from (libpcap format).....8: Packets that generate alert for detect1 ....16.. [bad tcp cksum 6d70!] 1098519960:1098519960(0) win 2048 <wscale 10.>][. The tcpdump command output also shows the invalid checksums..19 with no TCP flags set: NS tu As part of GIAC practical repository.61616 > 198.2.19...timestamp 1061109567 0. © tcp[13]&63==0’ and ’host 115.74.. 0x0030 080a 3f3f 3f3f 0000 0000 0000 .8. ascii and hexadecimal....16.16.nop... len 60.A # tcpdump -ennvvX -r 2002.... The second step is to analyze the complete set of packets exchanged between these two nodes: 27 © SANS Institute 2004.61.19. 04 Figure 2.. trying to obtain information about the target host type (OS fingerprinting) based on the replies obtained.. 21:39:00.eol> (ttl 50.... len 60...61..21: .9.\sJ.. ut ho rr eta ins fu ll r igh ts. bad cksum f419!) 0x0000 4500 003c e158 0000 3206 f419 734a f941 E..61616 > 198.<.A 0x0010 c63d 1013 f0b0 0015 d53e 5d5b 0000 0000 .=....249.mss 265...65 and host 198. 0x0030 080a 3f3f 3f3f 0000 0000 0000 .5 Attack mechanism In sti -e: -nn: -vv: -X: -r FILE: display Ethernet (layer-2) information.Raul Siles .A 0x0010 c63d 1013 f0b0 0015 417a 1598 0000 0000 .GCIA ´ 2. the eol option (end of option list) and how both packets contain no TCP data. id 11286.249..74..19’ 21:38:49. .mss 265..65. 0x0020 a000 0800 ea8c 0000 0303 0a01 0204 0109 .nop..<.????..65 and 198.....21: .9: Tcpdump options for detect1 20 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 tcpdump options description in Figure 2. display payload in both.74..sJ...X.836507 0:0:c:4:b2:33 0:3:e3:d9:26:c0 0800 74: 115. [bad tcp cksum 6d70!] 3577634139:3577634139(0) win 2048 <wscale 10...eol> (ttl 50.61.. The scanning technique used is based on sending individual NULL packets to a specific IP address. if any...timestamp 1061109567 0.74.????..... The first step to analyze this detect in-depth is to analyze the packets that generate the alerts and all their details.61.249.249..74...1.19’ SA The command uses a tcpdump filter which selects all packets coming from and going to hosts 115. no name and port traslation through DNS.16.. There is not too much additional and relevant information to add to the explanation previously made during the Snort output analysis associated to the alert messages...2. DETECT 1: “NULL SCAN” 2.. 0x0020 a000 0800 c614 0000 0303 0a01 0204 0109 .. Author retains full rights. See Figure 2.Az.8. bad cksum a95c!) 0x0000 4500 003c 2c16 0000 3206 a95c 734a f941 E. This detect appears to be an information gathering attempt against an external network. very verbose output.. te Figure 2...=. id 57688.65 and host 198.65.136507 0:0:c:4:b2:33 0:3:e3:d9:26:c0 0800 74: 115.23 ’tcp[13]&63==0’ and ’host 115..16.1..249..

19.65.74.836507 21:38:49.52. but both types are using the same TCP options: In The traffic exchanged between the two hosts only contains a total of 10 TCP packets. the following command should be used before running it: export TZ=UTC.16.19.65 to 198.52.74. • Port 601: Packets going to port 601 always have the following flags set.136507 21:39:00.249.249.74.2. In Linux.1.65.19.601: FP 1254329565:1254329565(0) 198. The source host is sending 2 packets at a time.19.16. . 2. one to destination port 21 (FTP control channel by default) and another to destination port 601 (Reliable SYSLOG service by default [RFC3195]).61621 115.16. win 2048 198.65.16. This double-packet set is repeated using the following interval pattern between packet pairs: 3.61.Those without TCP flags (2 packets.16. and always come from port 61621.23 log file between both hosts without using name and port resolution. DETECT 1: “NULL SCAN” Raul Siles .249.249.21: .65 and host 198. FIN and PSH.74.249.74.42 and 3.601: FP 1098519960:1098519960(0) 198.74.249.65.836507 21:38:54.249.21: .61621 115.19. always coming from port 61616.timestamp 1061109567 0. As part of GIAC practical repository.61616 115.61621 > > > > > > > > > > 198.16.136507 115. TCP options for all packets are <wscale 10.61618 115.601: FP 3577634139:3577634139(0) ins tcpdump is not capable of showing the timestamps using the UTC reference so its output is influenced by the timezone defined in the analysis system.19’ ut 21:38:46.65. This type of packet is known as a NULL packet (see the Correlations section for a definition). ack 0 win 2048 198. .249. 04 .601: FP 3577634139:3577634139(0) 198.21: .61621 115. ack 1 win 2048 198.61.61.A 28 fu ll r igh ts.61.356507 21:38:56.61621 115. The command shows all traffic from 2002.61. win 2048 urg 0 win 2048 urg 0 win 2048 urg 0 win 2048 urg 0 win 2048 urg 0 Author retains full rights. ack 1 win 2048 198.21: .61.249.74.19.61. always coming from port 61618.fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Key and all them always go from address 115.mss 265. Therefore. the file “/etc/localtime” defines this information. URG.Those having only the ACK flag set (3 packets). In this case I used “/usr/share/zoneinfo/Europe/Madrid”.74.74.16.249.19.316507 21:38:49.nop. the tcpdump output shows the same timestamp as the Snort output plus 2 hours (CET = UTC+2).19.65.61.249.61616 115.eol>: eta rr ho . win 2048 198.61. This type of packet is known as a XMAS packet (see the Correlations section for a definition).21: .74.65.61618 115.16.74.36 seconds respectively.74.776507 21:39:00.61.GCIA ´ # tcpdump -nn -r 2002. © SA NS • Port 21: There are two types of packets going to port 21 differentiated by the TCP flags.356507 21:38:54.316507 21:38:46.19.61.19.16.601: FP 1098519960:1098519960(0) 198.16. the two alerts analyzed).65. The packets addressed to each of these two ports are very different: sti tu te 20 © SANS Institute 2004. In order to run tcpdump in Linux showing the timestamps using the UTC reference.249. 4.65.16.19.61.65.776507 21:38:56.8.61618 115.16.8.23 ’host 115.

mss 265.168.10.7.61.. although in the detect they were incremented by 5.1.7963 seconds © SA NS In 13:01:23.Both.74.. use a URG flag with zero value....31708: FP [tcp sum ok] 2889333191:2889333191(0) win 3072 urg 0 <wscale 10.2.23 ’src host 115.nmap sends the XMAS packet to the same destination port as the NULL packet. As part of GIAC practical repository.A ut © SANS Institute 2004.19’ Some curious facts are: .62396 > 192.1..????. . we have two possible different sets: ACK set (ACK + XMAS) and NULL set NULL + XMAS. ho Figure 2.65’ Run time for packet processing was 0. See Figure 2.74.10: Packets over time rr set ACK 1 0x417A1598 (ACK+XMAS) ---> set NULL 1 0x417A1598 (NULL+XMAS) ---> set ACK 2 0x4AC38CDD (ACK+XMAS) ---> eta ins ..The source port is incremented by one.A.._. it is necessary to compare it with the XMAS packet generated by the nmap tool showed in the previous section: Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 .).228. it is not possible to know if a response was generated or not: # snort -qdevUX -r 2002..16.. Therefore. nmap and detect.8. TCP options.GCIA ´ 2.<. due to the fact that only alerting packets were logged.65 and dst host 198..... Once the XMAS packets associated to every NULL packet has been analyzed. TTL. 0x0010 c0a8 01e4 f3bc 7bdc ac37 b9c7 0000 0000 .61.timestamp 1061109567 0.. len 60) 0x0000 4500 003c 925f 0000 3206 a9a9 c0a8 01e5 E...eol> (ttl 50... Author retains full rights. DETECT 1: “NULL SCAN” To sum up.). the following command could be used.. 0x0020 a029 0c00 9a41 0000 0303 0a01 0204 0109 . set ACK 3 0xD53E5D5B (ACK+XMAS) ---> set NULL 2 0xD53E5D5B (NULL+XMAS) 29 fu ll r igh ts... sti tu te 20 04 It seems clear that the same tool is generating all these packets.The same TCP window. . Packets in the detect follow the same pattern. . ..249.nop. the next set containing the NULL packet uses the same TCP sequence number as the ACK set. As mentioned before.16.19 and dst host 115.23 ’src host 198.8. 0x0030 080a 3f3f 3f3f 0000 0000 0000 .249. To be able to analyze all these 10 packets in-depth...Once a set containing the packet with just the ACK flag set has been sent. showing all packet contents: # snort -qdevUX -r 2002..Raul Siles . there were no replies in the logs for all this traffic because the replies didn’t triggered any alert.167566 192. packet length and ACK value are used between both packets.229..Both packets in the same set always contain the same TCP sequence number.. id 37471.{..168..... .1..

. so the attacker would never receive accurate information about the OS running in the remote scanned host.GCIA ´ # ndd -set /dev/tcp tcp_text_in_resets 0 This fact can be used to FA27 2F94 998D FDB5 DE3D F8B5 06E4scan finds open Key fingerprint = AF19 distinguish between platforms. apart from the previous one mentioned: The standard port scan methods (using a SYN packet) are based on the following idea: a closed port is required to reply to a probe packet with a RST. the attacker got an accurate view of the target OS. As part of GIAC practical repository. a default HP-UX 11i system introduces.1. All those send resets from the open ports when they should just drop the packet.. and it is very useful in fingerprinting the OS of the remote node. This will be very useful for fingerprinting purposes. This “useful” functionality can be disabled through the following command: ho rr eta ins fu ll r igh ts. it is possible there were no response because some intermediate filtering device. XMAS and NULL.TCP/No. One of the reasons for this could be that the remote system runs an OS that never replies to a RST packet when the destination port is opened.-) and fingerprint this OS. Apart from that. 04 . then you are probably looking at one of these boxes. The NULL and XMAS methods depend on the fact that different operating systems respond differently to these scans. when an HP-UX 11i system receives a NULL packet to a TCP opened or closed port it also replies using a RST packet. for example. In this case. the text “No.listener” when the port is closed. This is one of the reasons why nmap include NULL packets as part of the methods to guess the OS. The nmap man page [NMAP1] explains that this scan type won’t work against the Microsoft systems (Windows95/NT) because they always respond with a RST packet. but a SYN scan shows them opened. . Author retains full rights. If the NULL scan shows all ports closed.0 and Solaris 8 systems responds with a RST packet when the port is closed and doesn’t respond at all when it is opened. helping potential attackers to determine the port status . Windows XP. © SA NS In sti tu te 20 © SANS Institute 2004.2.TCP” in the RST packet when the port is opened. while an open port must ignore/process the packets in question [RFC793. and the text “No. The focus is going to be on the NULL scan.A 30 ut Let’s analyze how this scan type could behave and some reasons that would justify the lack of responses. page 64]. These different behaviours help to know if a service is listening or not in a remote host. for debugging purposes. Windows 2000. Linux RH 8. the source host sent unique TCP packets that we don’t know if they were replied. Making some tests. DETECT 1: “NULL SCAN” Raul Siles . the machine is not one of the previous boxes. In the worst case. if the host itself is active. If the A169 4E46 ports. placed between the local network and the destination network is silently dropping the NULL packets. The same behaviour has been tested with Cisco IOS devices. Apart from all this stimulus/response analysis.

.249. echo $i.2002. only the same 10 packets mentioned before can be found. All of the 10 packets analyzed previously triggered a Snort alert. The definition is slightly different from the one described here. Author retains full rights.23 (cutting and pasting Extracting all the files posted the same day F8B5 06E4 A169 4E46 from the Web page into the file “posted. Obtaining all the packets related with the two IP addresses analyzed.txt). because it expects a sequence number of 0.packets.16.org” website 12 .txt.23 | \ grep -F "198. DETECT 1: “NULL SCAN” It is important to analyze not only the traffic that has been exchanged between the two hosts involved in the detect./posted.txt”.6 Correlations The arachNIDS signatures database 13 defines the NULL scan probe 14 .8.com/ids/index. do tcpdump -nn -r $i \ ’host 115.html 14 http://www.1. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D as 2002.A ut © SANS Institute 2004.com/info/IDS4 © SA NS # for i in $(cat . but also the alerts that have been triggered due to traffic between these hosts. It is important to analyze also the XMAS packets related to the NULL packets: 12 13 incidents.19’ >> .74.txt -rwxr-xr-x 1 rsiles rsiles 1353 Nov 2 13:50 In sti tu In order to correlate the information from the file analyzed with other data from the other log files available in the “incidents.packets.74. like the one set by nmap when not fingerprinting. there are 33 files based on the same sanitization process.Raul Siles .8./posted.65" -B 3 -A 3 alert.249.19" -B 3 -A 3 | grep -F "[**]" [**] [1:628:2] SCAN nmap TCP [**] [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**] [**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**] [**] [1:628:2] SCAN nmap TCP [**] [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**] [**] [1:628:2] SCAN nmap TCP [**] [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**] [**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**] 2.1.whitehats.org http://www.whitehats.GCIA ´ 2. ho 31 rr eta ins fu ll r igh ts. As part of GIAC practical repository./posted. corresponding to 1353 bytes: te 20 04 . it must be considered that IP addresses were sanitized consistently only for the files posted the same day. done # ll .65 and host 198. and the sequence of events over time was: # grep -F "115.61.61.16. The same type of NULL scan is defined in the ISS database [ISS1].

The winner post can be found at 18 . Shinberg talks in its GCIH paper about a NULL scan performed using nmap.html 19 http://www.org/scans/scan23/ 18 http://project.pdf © SA NS In sti tu te 20 © SANS Institute 2004. All these. page 230]: “RFC 1025.” All these names come from the idea of having every lamp (bit) turned on. RST and PSH flags in a single segment. Shinberg: “A Management Guide to Penetration 15 16 http://www.whitehats. PSH. FIN and PSH flags and no TCP data is sent.honeynet. Author retains full rights. consisted on A169 4E46 binary log file associated to five different scanning methods. 04 . Its also known as a nastygram. so it is slightly different from the one analyzed here. although no reports about NULL scans against the destination address were found on Internet. Andy Millican analyzed the NULL scan method. -sX. Traffic similar to the one of this detect has been analyzed in the following instances: David A. Again. at 19 . Although the packet type seen here only has the URG. the packet shown matches the packets analyzed in this paper when using fingerprinting methods: David A.org/practical/GSEC/Andy_Millican_GSEC.com/info/IDS144 http://www. FIN.Detection and Prevention”.whitehats.giac. a “Probe FULL XMAS Scan” 15 . adding some fingerprinting methods. The NULL scan was generated by nmap. This type of packet is known as a XMAS packet [STEV1. 17 The HoneyNet = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4the analysis of a Key fingerprint project. is different and sets the TCP sequence and ACK numbers to zero. DETECT 1: “NULL SCAN” Raul Siles .honeynet. URG. Some references use the term XMAS packet to define a TCP segment where all the flags have been turned on.1. A Google search for “STEALTH ACTIVITY (NULL scan)” detection provided several previous postings of this type of scanning activity. Apart from that. Christmas tree packet (XMAS) and lamp test segment. and PUSH flags. The ones seen in the traces correspond to a “Probe XMAS scan” 16 . FIN and 1 byte of data) a Kamikaze packet. As part of GIAC practical repository. Snort considers it as a XMAS packet. URG.A 32 ut ho rr eta ins fu ll r igh ts. Scan of The Month 23 . . should be analyzed by the participants. calls a segment with the maximum combination of allowable flags bit turned on at once (SYN.2. 2003.org/scans/scan23/sol/Nick/index. so it is very likely nmap fingerprinting was used to generate the detect traffic.com/info/IDS30 17 http://project. although normally only one is set at a time. the default nmap XMAS scan.GCIA ´ It is possible to have more than one of the SYN. January 23. The nmap Xmas tree scan turns on the FIN. including a NULL scan. as in the NULL packet case. in its GSEC paper called “Network Reconnaissance . again based on nmap and slightly different from the detect.

wpi.com/forum/viewtopic. mainly through Snortsnarf reports.org/acid/acid_stat_alerts. Author retains full rights. thus. Jae Chung. All of them present reasonable variations. DETECT 1: “NULL SCAN” Key .A ut But typically. ho rr 33 . consult and analyze the alerts reported by their IDSes.Raul Siles . allowing anyone to check. Inc. .84. php?caller=most_frequent\&sort_order=occur_d eta Testing”. Zach Lawson. generating a packet very similar to the one analyzed here. TTL variations.security-forums.91. because nmap changes them randomly.org” through ACID [ACID1]: http://www.kr/snort_data/snort_04/211/38/45/src211.“Honeypots: Tracking the Blackhat Community”.homelinux. html 20 21 http://www.html 23 http://www.com/archives/snort/2001-12/0086. There is an example 23 of a Snort NULL scan detection related to NULL packets generated by hping.neohapsis. publicly and openly on Internet.greyskull. IP addresses and ports.http://www.pdf http://archives.“www.org/acid/acid/acid_ fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 stat_alerts. What surprised me a lot was the huge amount of people publishing its Snort logs.1.54BETA30. like timestamp.org” through ACID: http://longinus.129. Some examples are: © SANS Institute 2004. Matt Hartling.dyndns. Logs at 22 also show the same type of NULL packet and alert. SANS GCIH.“longinus.cyberarmy. .greyskull.org/practical/GCIH/David_Shinberg_GCIH.138-3001. sequence numbers and TCP windows.GCIA ´ 2.giac. It is less similar to this detect than the nmap scan.edu/~goos/CS525T/proj-report © This was one of the reasons why I selected it from the whole set of alerts available at “incidents. version 2.com/info/news/snort.html 22 http://delorian. As part of GIAC practical repository.dmzs.co.php .net/snortlog/80/91/84/src80.phtml 04 . All packets and references described maintain the same structure as the one analyze in the detect.38. Year 2003 20 . this alert is reported as one of the less repeated warnings in the IDSes. This could provide clues to a potential attacker because he can test if certain “evil” activities are detected or not.etxea.org”. Some web pages have published information about the top alerts triggered by their IDS.45. not involved in nmap fingerprinting: SA NS In sti tu te 20 . fingerprinting scanning.dyndns. Frank Posluszny 24 .php?t=6423 24 http://users. being the NULL scan one of them: ins fu ll r igh ts. from different sources and different from the packet analyzed.DMZ Services. Other NULL scans. The logs available at 21 show a nmap. http://www. Everything is the same except that the DF bit has been set (DF: don’t fragment).

198. To understand the following analysis it must be taken into account that the logKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D Snort alerts.38.19 (src): 0 hosts are contacted from this host.Traffic from 198.1. and would let perform a more detailed analysis about the remote operating system and the information obtained.8.61. 115.74.A 34 ut ho rr eta ins fu ll r igh ts.19 © SA # tcpdump -nn -r 2002.74. # tcpdump -nn -r 2002.html 2. so some ging information only contains packets that generated F8B5 06E4 A169 4E46 information was missed and it is unknown today.http://www. html .8.38.Traffic to 198. is the one analyzed (10 packets).uni-stuttgart. DETECT 1: “NULL SCAN” Raul Siles .16.23 ’dst host 198.org/ipinfo. The XMAS scan related to the NULL scan analyzed here was studied by Johnny Calhoun in its GCIA practical 25 . “2002.php?ip=198.org web page 26 and no information about active targeting.19 (dst): 10 packets are sent to it from 115.61." --fields=1.16.23 ’src host 198. 04 . It would be very useful to have a complete network audit trail to be able to analyze all the traffic.org” mailing list repository it was found that only 1 post used the same binary file.1.4 | sort | uniq -c 10 115. • Source System: 25 26 http://cert.249.61.16.19’ | cut -d " " -f 4 | sort -u | wc -l 0 NS .19.co.dshield.74.7 Evidence of active targeting .61. The non-sanitized destination IP was run through the database at Dshield. was reported.249.kr/snort_data/snort_04/211/38/45/src211. coming from the source system.2.co.16. In • Destination system: The only traffic addressed to the destination system.65: sti tu te The scan activity is addressed against one specific system.kr/snort_04/211/38/45/src211. Searching into the “incidents.8.65 These packets correspond to the 10 alerts analyzed previously. .cyberarmy.GCIA ´ . This analysis should be performed from the raw network traffic and from the Snort alerts generated. An additional step will be analyzing all the traffic generated from the source address and all the traffic addressed to the destination system in order to understand what is taking place and the relationships with other hosts.3.249.61. As part of GIAC practical repository. Author retains full rights.html http://www.16.16.45.48-1101. from or to it.174-1501.23”. A complete network audit trail would provide information about the responses generated due to the fingerprinting activities.http://snort.45. trying to get more information about it.2.65.19’ | cut -d " " -f 2 | \ cut -d ".61.cyberarmy.de/archive/intrusions/2003/01/msg00026. 20 © SANS Institute 2004.

249.249\.173.23 ’dst host 115.3.65: # cat alert.249.2002.4 | 197 $ tcpdump -nn -r 2002.A .4 | 891 216.47 142 64.1. DETECT 1: “NULL SCAN” Key However.80.154.7. . Due to the fact that the only 10 packets going to the destination system generated an alert.74\.74. host 115.2.48.65’ | cut -d " " -f 4 |\ sort -u | wc -l host 115.65" | wc -l 10 . As part of GIAC practical repository.GCIA ´ 2.74\.68.188.74.3.154.74.23 ’src 3553 $ tcpdump -nn -r 2002.65’ | cut -d " " -f 2 | \ cut -d ". .80.3.44 161 64. Most traffic is exchange with the 4 hosts shown below: ut © SANS Institute 2004.51 457 64.154. it is important to analyze not only all the network traffic but also the alerts generated by Snort.45 191 64.8.4 | sort -u | wc -l 49 # tcpdump -nn -r 2002.80. all these packets generate an alert even nowadays.23 | grep "^115\.39.74.Traffic to 115.2.249\..56.154." --fields 1. addressed to this host from 48 different hosts: as mentioned before.74. Most traffic goes to the set of IP addresses shown below: Author retains full rights.50 .Raul Siles ." --fields=1.23 ’src cut -d ".249..65’ | wc -l host 115.80.8.23 ’dst host 115. ho rr 35 $ tcpdump -nn -r 2002.65: # cat alert.8.Alerts where destination host is 115.23 | grep -e "-> 115\.65’ | wc -l 211 fingerprint #=tcpdump -nn -r 2002. 3553 packets going out of it addressed to 197 different hosts.8.3.23 ’dstFDB5 DE3D F8B5 06E4 A169 4E46 AF19 FA27 2F94 998D host 115.74.Alerts where source host is 115.10 11 202. although “nowadays” it only generates the 10 alerts previously analyzed (remember all these packets generated an alert when Snort was run.65 (src): It seems there is too much activity in the source host.150 44 63.16 518 64.4 | sort | uniq -c | sort -rn 51 207.249. we are going to focus on all the other alerts related to the source system: .74.8. the system has also received some traffic (211 packets) and the conversations that generate them were originated in 49 different source hosts.23 ’src cut -d ".249..136.65’ | cut -d " " -f 4 | \ sort | uniq -c | sort -rn eta ins fu ll r igh ts.249. tu te 20 04 .74.2.80." --fields=1.249.8.80..65" | wc -l 211 © SA NS In sti # tcpdump -nn -r 2002.133 17 207.74.49 228 64.249. that’s the reason why they were logged).65 (dst): on the other side.132.65’ | cut -d " " -f 2 | \ cut -d ". 211.8.249.154.249.154.74.Traffic from 115.2.8.2002." --fields 1.25 .111.

2.1. DETECT 1: “NULL SCAN”

Raul Siles - GCIA ´

Using the information extracted from Snortsnarf it is possible to easily see that this host is the only destination for all the SHELLCODE Snort alerts. Snortsnarf has been used to extract information about the analyzed file, “2002.8.23” (see table 2.1). Alerts are classified by name and not by SID, as was made manually in section 2, but Snortsnarf also obtains 243 alerts. Analyzing the statistics extracted by this tool there is no relationship between the source addresses generating the “SCAN nmap TCP” and the “SHELLCODE” alerts. Looking into all this information, we could guess that the source host has received a lot of network activity (stimulus), and has generated lot of responses. Part of the traffic generated corresponds to the NULL scan analyzed, so it seems that

©

SA

NS

In

sti

tu

10 packets, 1 host -----------------------> (10 alerts) Src. host: 115.74.249.65 Dst. host: 198.61.16.19 Key fingerprint = <----------------------AF19 FA27 2F94 998D FDB5 ^ DE3D F8B5 | ^ | | | 0 p (0 a) | 0 p | 0 packets 3543 packet| | 211 packets |(0 a)| (0 alerts) 196 hosts | | 49 hosts | | (0 alerts) | | (211 alerts) | | | | | | --> <Other systems> --> <Other systems>

04

,A

ut

ho

To sum up all this information, the source system 115.74.249.65 has only generated 10 alerts as source host, all them associated to traffic going out from it to the other host analyzed, 198.61.16.19, but it has been the most addressed system in the binary file, with 211 alerts directed to it as destination host (one per packet received), summarized in 6 different signatures. From all the above information the simplified link diagram showed in figure 2.11 can be obtained:

rr

eta

ins

te

Figure 2.11: Link diagram

20

36

© SANS Institute 2004,

As part of GIAC practical repository.

fu ll r igh ts.

# cat alert.2002.8.23 | grep -e "-> 115\.74\.249\.65" | \ cut -d " " -f 1 | cut -d ":" -f 1 | sort -u | wc -l 49 # cat alert.2002.8.23 | grep -B 4 -e "-> 115\.74\.249\.65" | \ grep -F "[**]" | sort | uniq -c | sort -rn 121 [**] [1:648:5] SHELLCODE x86 NOOP [**] 55 [**] [1:1390:3] SHELLCODE x86 inc ebx NOOP [**] 24 [**] [1:1394:3] SHELLCODE x86 NOOP [**] 4 [**] [1:628:2] SCAN nmap TCP [**] 3 [**] [1:650:5] SHELLCODE x86 setuid 0 [**] 3 [**] [1:649:5] SHELLCODE x86 setgid 0 [**] 1 [**] [1:653:5] SHELLCODE x86 unicode NOOP [**]

06E4 A169 4E46

Author retains full rights.

Raul Siles - GCIA ´
Priority 2 2 2 1 1 1 Signature SHELLCODE x86 setuid 0 SHELLCODE x86 setgid 0 SCAN nmap TCP SHELLCODE x86 unicode NOOP SHELLCODE x86 inc ebx NOOP SHELLCODE x86 NOOP

2.1. DETECT 1: “NULL SCAN”
# alerts 3 3 11 1 55 145 # src 2 3 6 1 29 13 # dst 1 1 3 1 1 1

Table 2.1: Alerts classified by Snortsnarf

the host has been compromised and it is being used for other attacks. A deeper analysis of all these alerts should be made to confirm this statement. The NULL packet belongs to a very specific scanning against one individual host.

Severity = (Criticality + Lethality) - (System countermeasures + N etwork countermeasures)

©

Packets going to/from the source host:
$ tcpdump -nn -r 2002.8.23 ’host 115.74.249.65’ | wc -l $ tcpdump -nn -r 2002.8.23 ’dst host 115.74.249.65’ | wc -l $ tcpdump -nn -r 2002.8.23 ’src host 115.74.249.65’ | wc -l --> 3764 --> 211 --> 3553

SA

- Destination: Due to the fact that the target system doesn’t belong to our network, and that there is no information about the response packets received from it, it is not possible to know the system purposes and value. Therefore I will assume a value of 2, a Unix user workstation. - Source: Instead, the source system can be evaluated, as it belongs to our network, and obtain how critical it is. The alerts data has been analyzed to get the potential services this system is running:

NS

In

• Criticality:

sti

tu

Typically, an alert is analyzed from the destination host perspective in order to evaluate the impact it had over the target, but in this detect, the destination system Keyattacked doesn’t belong 2F94 998D FDB5 DE3D F8B5it06E4 A169 4E46 comment on fingerprint = AF19 FA27 to the analyst’s network, so is important to some facts associated to an alert being triggered from our own network. Therefore, I’m going to analyze the formula twice, from the destination host perspective (as usual) and from the local network point of view where the sensor had been installed.

te

20

04

,A

ut
37
© SANS Institute 2004, As part of GIAC practical repository.

ho

There is an attack metric, called Severity, which can be measured based on the formula shown below; in order to obtain a final value, each variable should be ranked from 1 (lowest) to 5 (highest):

rr

eta

2.1.8

Severity

ins

fu ll r igh ts.

Author retains full rights.

2.1. DETECT 1: “NULL SCAN”

Raul Siles - GCIA ´

List of destination ports addressed by some packet directed to this host:
# tcpdump -nn -r 2002.8.23 ’dst host 115.74.249.65’ | cut -d ’ ’ -f 4 |\ cut -d ’.’ -f 5 | cut -d ’:’ -f 1 | sort -un 53, 4100, 61010, 61011, ..., 65074

# tcpdump -nn -r 2002.8.23 ’src host 115.74.249.65’ | cut -d ’ ’ -f 2 |\ cut -d ’.’ -f 5 | sort -un | more 61000, 61001, 61002...

• Lethality:

• System countermeasures: - Destination: Due to the fact that there are no data about responses from the destination host, it is not possible to evaluate the applied protections. Let’s imagine it is a modern OS, with the security patches applied but not very advanced security features in place, so it scores a 4. - Source: Again, the local system will be analyzed to see the protections involved. Almost all traffic is associated to client ports. Based on the lack of information, suppose there is no personal firewall running, and the system have some security patches applied: the value associated would be 3.

©

SA

NS

In

- Destination: If the attack were successful the damage on the end system would not be very high. As have been already stated, the detect is part of a reconnaissance scan, and the result obtained will provide, in the worse case, accurate information about the operating system Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 of the remote host. This information would be helpful to run other future specific attacks. Its associated value is 2; it is an early phase within the attack process. - Source: As a conclusion I figure out that this system has been compromised and is being used to launch other attacks. To be able to generate raw network packets in the local system, as the NULL and XMAS packets, the attacker has obtained root access. So, this variable value is 5.

sti

tu

te

20

© SANS Institute 2004,

As part of GIAC practical repository.

04

,A

38

ut

ho

rr

Initially it seems this system was acting as a DNS server (port 53). Analyzing the typical server ports, 53 and 4100, it is confirmed that this traffic was part of some scanning process but we don’t know if the packets were replied (only alerting traffic was logged). Based on this information, let’s suppose the system was a DNS server. Therefore, it has a value of 5.

eta

ins

fu ll r igh ts.

List of source ports associated to packets going out from this host: all them are client ports.

Author retains full rights.

using a perimeter firewall. ingress filtering will block or drop the packets addressed to the internal network. Other methods are not effective against it. .Discover available services in a given host. generic rules filtering not allowing packets. egress filtering will filter the packets going out to other networks. as the ones involved in the detect analyzed. it is not possible to know if some “Administratively prohibited” notification was received. This protection won’t allow external attackers to discover new internal system and services or fingerprint them.. As part of GIAC practical repository. .Destination: For the same reason as the system protections. ho 2. so this is the reason why no responses were received. . There is a firewall for ingress filtering but it allowed the attack that compromised the box through.Discover the OS of a target host (OS fingerprinting).1. . Image that a firewall was protecting the remote network. Author retains full rights. .Discover new active hosts.Source: Due to the fact that ICMP packets have been omitted from the log files.A ut © SANS Institute 2004. Two types of filters are recommended. Suppose that there is no local perimeter device filtering evil packets from going out. ingress and egress.. by means2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 bypass the fingerprint = AF19 FA27 of personal firewalls. its value is 2. tu te 20 NULL packets. On the one side. as mentioned. that is. so no one is dropping the outgoing evil packets. because they will never belong to an already established TCP connection. This type of packets can be filtered at the border level. there is no data to evaluate this variable. Its value is 4. such as a firewall.Raul Siles . blocking attacks originated from the internal systems and developed by internal users or external users that have compromised local systems. the final value for both formulas are: The main protection against this kind of undesired traffic. They are sent hoping to firewall/packet filter policy in order to: 04 . is filtering. On the other side. Therefore. like operating system hardening.GCIA ´ • Network countermeasures: 2. It is recommended to generate filter rules in the way the anti spoofing filtering rules are created. or at Keythe host level. DETECT 1: “NULL SCAN” To sum up. can be silently dropped by a packet filter device. security patches upgrades. such as NULL © SA NS In sti .1.9 Defensive recommendation rr 39 Severity on the destination system = (2 + 2) − (4 + 4) = −4 Severity on the source system = (5 + 5) − (3 + 2) = 5 eta ins fu ll r igh ts. usage of encryption protocols.

and even at the host level HIDS. in a Gigabit network you will need about 21 Gbytes (10Gbps/8bits ∗ 17s) of RAM memory space to be able to save 17 seconds of network traces. packets. therefore reducing the possibility of further and more dangerous attacks. but the previous ones. XMAS packets and other packet variations that can never be part of a valid TCP connection/session. Roughly speaking. additional traffic associated to the same source host can be logged. . This would allow to obtain the responses generated after the NULL packets. it is possible to define rules for the Linux “iptables” firewall to block these types of packets: Author retains full rights. were logged. Snort has a keyword called tag that allows to log just more than one single packet.2. Checkpoint. it will be possible to tweak the TCP/IP stack of some operating systems and applications (Linux. Having a full network trail would also improved the analysis process. The problem with this kind of implementation resides in the fact that it doesn’t scale well. 04 . This type of scan should always be triggered by the IDS solution because it represents anomalous traffic. so when a rule is triggered. . FA27 2F94 998D prelude to a future 06E4more dangerous Key fingerprint = AF19 and it may be a FDB5 DE3D F8B5 and A169 4E46 attack. This would allow detecting scans from outside and scans originated from inside. For example. DETECT 1: “NULL SCAN” Raul Siles . therefore. this is the least used rule option in Snort . prepare the defensive countermeasures. As part of GIAC practical repository. *BSD. These other types could be FIN packets without the ACK bit set.GCIA ´ # NULL packets: no flags set iptables -A INPUT -p tcp --tcp-flags ALL NONE -j LOG --log-prefix "Firewall: NULL packet received !!" iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP # Full XMAS packets: iptables -A INPUT -p "Firewall: Full XMAS iptables -A INPUT -p all flags set tcp --tcp-flags ALL ALL -j LOG --log-prefix packet received !!" tcp --tcp-flags ALL ALL -j DROP Apart from the protection countermeasures.) in order to defeat the results obtained by the nmap fingerprinting methods [BARR1]. There is a cheaper alternative solution to the full network audit trail. By the way.1. © SA NS In sti tu te 20 © SANS Institute 2004. it would be technically possible to let the IDS buffer the packets so when an alert is trigger not only the following packets. having a monitoring solution to detect this kind of activities is desirable at both. SYN packets with FIN or RST bits set. . This protection would reduce the success of a potential fingerprinting scanning attack.-) Besides. Finally..A 40 ut ho rr eta ins fu ll r igh ts. the network perimeter and the internal networks NIDS. It would be important for the analyst to research this type of alerts. providing the required information to understand the whole picture..

Raul Siles . DETECT 1: “NULL SCAN” This defensive countermeasure is based on the “security through obscurity” philosophy and. SA NS In sti tu te 20 04 Correct answer: c) Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 . the nmap fingerprinting NULL packets include TCP Options.GCIA ´ 2.16.1. ho rr 41 Options. As part of GIAC practical repository.A a) b) c) d) A NULL packet cannot have TCP Alert was triggered by a XMAS Alert was triggered by a NULL A NULL packet must have a TCP ut © SANS Institute 2004. For example.65:61616 -> 198. others dont. nmap generates NULL packets with a valid TCP sequence number value.74.249. eta Which of the following clauses is true in relation with the packet that triggered the above Snort alert? ins [**] [111:9:1] (spp_stream4) STEALTH ACTIVITY (NULL scan) detection [**] 09/23-19:38:49. Author retains full rights. and the RFC 1122 defines that the TCP options could be accepted in any TCP packet. based on learning the network topology and its elements in order to add contextual information to the IDS infrastructure [RNA1]. d) Although some documents defines a NULL packet with a TCP sequence number of zero.1.61. it is not recommended in this case because it would break the next generation of IDSes. from my point of view. c) NULL packet triggered the alert.10 Multiple choice test question Explanations: © a) As has been analyzed. packet. 2. packet.19:21 TCP TTL:50 TOS:0x0 ID:11286 IpLen:20 DgmLen:60 ******** Seq: 0x417A1598 Ack: 0x0 Win: 0x800 TcpLen: 40 TCP Options (4) => WS: 10 NOP MSS: 265 TS: 1061109567 0 fu ll r igh ts.836507 0:0:C:4:B2:33 -> 0:3:E3:D9:26:C0 type:0x800 len:0x4A 115. . sequence number value of zero. b) An XMAS packet is a completely different packet with several TCP flags turned on.

1 Source of Trace $ tcpdump -nn -e -r snort.A ut ho The detect has been generated by a Snort instance running in a LAN production network.3.23.GCIA ´ 2.6 |\ cut -d’.3.168.2.190 and 10.4 | sort -u | grep -F "0:e0:34:ca:50:23" | wc -l 63 This includes hosts from the following networks: 10.6 |\ cut -d’. the same MAC is used to represent different IP addresses: rr eta ins 42 © SANS Institute 2004. 10.181. DETECT 2: “PING SPEEDERA” Raul Siles . HP-UX.1063894999 | cut -d’ ’ -f 2. Linux.. 10.log.178.log.3.3.log.2 DETECT 2: “PING speedera” The following alert corresponds to the detect that it is going to be analyzed: [**] [1:480:2] ICMP PING speedera [**] 2. The sensor is monitoring all traffic going to and coming from all the systems placed in the class C LAN network.4 | sort -u | cut -d’ ’ -f 1 | uniq -d 0:2:a5:9c:6e:6e 0:e0:34:ca:50:23 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 0:e0:34:ca:c0:23 04 . NS In $ tcpdump -nn -e -r snort.’ -f 1.2. The Snort alert file is the data source and only the packets that violate the ruleset were logged.’ -f 1.6 |\ cut -d’.206.’ -f 1.2.167 0:2:a5:9c:6e:6e 192.2.20 sti tu te Once the MAC addresses are known. In order to find the router devices.132.1063894999 | cut -d’ ’ -f 2. fu ll r igh ts.181.1063894999 | cut -d’ ’ -f 2. It is a multivendor infrastructure LAN with different OS systems and versions: Windows. .132.0.log.180. Solaris. Tru64..2. 10. As part of GIAC practical repository.’ -f 1.2.1063894999 | cut -d’ ’ -f 2. that is.2. it is needed to get all associations between one source MAC address and different source IP addresses. $ tcpdump -nn -e -r snort.181. Cisco.4 | sort -u | grep -F "0:e0:34:ca:c0:23" | wc -l 7 © SA The first MAC address corresponds to a host that associates two logical subnets to the same physical network interface. 10.4 | sort -u | grep -F "0:2:a5:9c:6e:6e" 0:2:a5:9c:6e:6e 10. it is possible to obtain which IP addresses they are representing: 20 $ tcpdump -nn -e -r snort.6 | \ cut -d’. A169 4E46 Author retains full rights.0/24. 10.

0. due to the multivendor Keynature of thisAF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 one hand.External --.0/8 OR | 0:e0:34:ca:c0:23 | (HSRP) Snort IDS In sti SA 10.255 and 255. NIC.139.197. .2.NETWORK ---networks 0:e0:34:ca:50:23 | 10. version 2. © SANS Institute 2004. 10. as a conclusion we can determine there are two default Cisco routers using the HSRP protocol. and on the other. represents the subnet broadcast address.181.2. The same MAC is also used to reference all IP hosts (global broadcast address).2 Detect was generated by The detect was generated through the Snort [SNOR1] Network Intrusion Detection System.12: te 20 04 .255. DETECT 2: “PING SPEEDERA” This includes hosts from the following networks: 10.1063894999 | cut -d’ ’ -f 3. To get this information the following command could be used: Figure 2. NIDS.’ -f 1.0/24 10.132.2. 10.3) at 00:E0:34:CA:50:23 [ether] on eth0 (10. 10. 10.255.Cisco router ------.1) at 00:00:0C:07:AC:03 [ether] on eth0 # tcpdump -nn -e -r snort.79 10.3.0”. 10.255.0. except two addresses: rr 43 eta ins The same process cannot be applied to the destination associations. because instead of providing information about gateways it will show multiaddress hosts where several IP addresses are associated to the same network interface card.Raul Siles . The Cisco OUIs are [‘‘00-E0-34’’] [IEEE1].8 |\ cut -d’.255. ut ho All destination associations belong to the local class-C network analyzed.Router -.132.255”.181. Therefore. 10.181. fingerprint = network. and the virtual HSRP address uses group 3 and the [‘‘00:00:0C:07:AC:0 ’’] MAC: # ? ? ? arp -an (10. 10.3 system for an Intel platform. running on a RedHat Linux 7.139.228.132.0.142.Switch ---. on the using the typical notation.147 tu First one corresponds to multicast traffic. using the BSD-style.181.197.206.132.132.0. Therefore.181. the network topology is shown in figure 2.255. © As part of GIAC practical repository.4 | sed -e ’s/:$//’ | sort -u | cut -d’ ’ -f 1 | uniq -d NS Internet -. 2.49 Author retains full rights.GCIA ´ 2. . Second one.0/24.1 (Build 88).132.195. “. “.181.4 and 10.43. fu ll r igh ts.2) at 00:E0:34:CA:C0:23 [ether] on eth0 (10.181.log.12: IDS Network Topology for detect2 Last lines show the IP addresses of the specific systems involved in this detect.250 --> 10.231.132.A 1:0:5e:7f:ff:fa ff:ff:ff:ff:ff:ff --> 239.

dump the raw packet data starting at the link layer.197.132.2. te Both fingerprint = AF19 FA27 packets coming from two different external source Key detects correspond to 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 hosts. 10. . [**] [1:480:2] ICMP PING speedera [**] [Classification: Misc activity] [Priority: 3] 10/03-10:23:56.181.13. generate alerts showing full decoded header and the alert message.139. don’t show banner and status/summary report.181. and were detected with an interval of 2 days and 6 hours between both (the 3rd and 5th of October of 2003). NS In Figure 2. 44 © SANS Institute 2004./log -A full -qbdX -c FILE: -l DIR: -A full: -q: -b: -d: -X: specifies the Snort configuration file (described above) and run Snort in NIDS mode.147.231. were used. Author retains full rights.197. In order to fully understand the type of alert analyzed and its impact it is recommended to study all its fields and meaning: 20 04 . the different ICMP sequence numbers and the Type Of Service (TOS). like the different IP identification values.A # grep -F "[**]" alert | wc -l 25508 ut ho Snort options are shown in figure 2. “snort.13: Snort Options for detect2 fu ll r igh ts. Type:8 and Code:0.49 ICMP TTL:121 TOS:0x0 ID:43307 IpLen:20 DgmLen:60 Type:8 Code:0 ID:512 Seq:27680 ECHO [**] [1:480:2] ICMP PING speedera [**] [Classification: Misc activity] [Priority: 3] 10/05-16:46:30.181.79 -> 10.142. The monitoring was not using the UTC time reference but the one of the system where Snort was running.051515 10.0. DETECT 2: “PING SPEEDERA” Raul Siles .GCIA ´ The default ruleset slightly modified and Snort configuration file. logging directory: alerts and packet logging.132.79 and 10.139.603552 10. 10. CET for Spain. to the same destination system. log in binary tcpdump format.1/etc/snort. There are several fields that are normal.231. display the application layer data.2.conf”. The “include” rule lines commented by default in this file were activated.14: Network detects for detect2 sti tu As part of GIAC practical repository. The analysis is focused on the following two alerts selected from a total of 25508 alerts triggered in a period of about 20 days between 09/18-16:27:18 and 10/07-16:33:26 (obtained from the timestamp of the first and last alerts in the file): rr eta ins Figure 2.132.49 ICMP TTL:121 TOS:0x0 ID:19679 IpLen:20 DgmLen:60 Type:8 Code:0 ID:512 Seq:65084 ECHO © SA Both packets correspond to ICMP echo requests.142.49.147 -> 10. The following command was used to analyzed the log file: # snort -c /opt/snort-2.conf -l .

147 traceroute to 10.509 ms 15. The alert was triggered by the following Snort rule that belongs to the Snort “icmp.3) 1.132.32.23 (10.994 ms 146.195.15: Traceroute to each source host alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP PING speedera".596 ms 70.181.79).cnns.186.191.231.171 ms 1.251.279 ms 3 10.987 ms 7 emgt4.951 ms 2 10.615 ms 66.424 ms 6 babncat121wangw1. © SA This system was not available at the time this research was made (it was a DHCP address as explained later) but it seems to be at the same distance as the previous host.15 (10.021 ms 77.79 (10.057 ms 105.10 (10. First 1 indicates that the alert was 45 © SANS Institute 2004.10) 107.191. classtype:misc-activity.com (10.33) 143.488 ms 100. 10.240. meaning there was a previous version in older Snort versions.142. itype: 8.79 traceroute to 10.company.13) 145.245 ms 2 10.345 ms 141.195. however this can be just a coincidence.15) 67. DETECT 2: “PING SPEEDERA” Figure 998D FDB5 DE3D F8B5 06E4 A169 4E46 Key fingerprint = AF19 FA27 2F942.2.251. content: "|3839 3a3b 3c3d 3e3f|".467 ms 161.Raul Siles .191.228. although they belong to different networks. It is most likely that the initial TTL was 128.252 ms 21.428 ms 1.921 ms 19.948 ms 7 * * * ut ho rr eta ins fu ll r igh ts.142.750 ms 114.181.240.680 ms 85.240.181.147) 102.babn.139.babn.0 web server.com (10. 38 byte packets 1 10.312 ms 123.700 ms 109. . te 20 04 .191.13) 110.15 (10. 30 hops max. The ICMP ID had a value of 512.23) 15.026 ms 6 babncat121wangw1.431 ms 100.139. revision 2.197 and 10. as expected.139.23) 25. This was confirmed remotely in a later analysis checking that they run the Microsoft-IIS/5.rules” set: NS In sti tu As part of GIAC practical repository.company.3) 2.191. such as ICMP scannings.228.com (10.132.181.186.147 (10.company.058 ms 5 babnhgw1.231.) This ruleset file contains potential bad ICMP traffic.588 ms 132.company.197.982 ms 3 10.babn.191.895 ms # traceroute 10.3 (10.339 ms 1.191.228. sid:480.741 ms 142.147).195.A # traceroute 10.23 (10. At first instance it is strange that both packets have the same TTL value. All other packet fields will be analyzed in section 5.197.139. is 480. SID.com (10.142. The alert has been categorized as miscellaneous traffic and its signature ID.33) 143.142.cnns.rules” file.148 ms 17.231.132. 30 hops max. Other ICMP traffic is defined in the “icmp-info.191.139. Therefore it is identified as “1:480:2”.132.393 ms 108.908 ms 4 10.3 (10.191.292 ms 5 babnhgw1. and this information can be confirmed tracing back the source hosts from the Snort or the target system (both are placed in the same subnet) as shown in figure 2.139.15) 75.GCIA ´ 2.195.186.15: Author retains full rights.731 ms 4 10. depth: 100.33.922 ms 131.094 ms 1.191.10 (10.company.com (10. 38 byte packets 1 10.240.139. rev:2.228. 121. Some of the packet features can help in determining the source OS generating the probes [PASS1]: based on the TTL it seems both source system were Windows boxes.186.197.10) 101. The packet length is 60 bytes: 20 bytes for the IP header (IpLen) and 40 for the ICMP header plus the payload.407 ms 119.

79 10.2. and their name resolution is: . Probably.49 10. However.142. © SA ICMP packets can be easily spoofed having enough privileges in the source system. it is known that there are antispoofing filters in this topology between Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 the class-B network boundaries.emgt4. to be able to generate raw packets.com .babn.A ut ho rr eta 2.com . te 20 04 . The hexadecimal value searched can be translated to the following ASCII string: ‘‘89:.2. 46 © SANS Institute 2004.0. The ICMP types and codes can be found in the Snort “decode. using a dynamic IP address (‘‘dhcp’’) at the time the detect was triggered. source and destination addresses belong to the company internal network private range.181. there are times where there are no antispoofing filters in place.197.0. The packet must contain the following binary pattern: ‘‘3839 3a3b 3c3d 3e3f’’. such as root in a Unix box. the other source system.com NS In sti tu As part of GIAC practical repository. Besides.139. is a test host running management probes and this is the reason why it was not active when this analysis was developed. because the attacker’s main goal is to be able to receive the responses generated by the destination host. Author retains full rights.132. The notification is triggered when an echo ICMP packet. The ICMP protocol is typically used in reconnaissance techniques.company.0/8. Both. . DETECT 2: “PING SPEEDERA” Raul Siles .147 The “mgt” in the hostname of the third system would probably determine it is a management system. in the packet payload within the first 100 bytes (‘‘depth: 100’’).target. Look for ICMP ECHOREPLY string.3 Probability the source address was spoofed ins generated by the main Snort Rule Engine and not by any of its preprocessors (see Snort “/etc/generators” file). commonly developed using real addresses. Due to this fact it is almost certain that the source address has not been spoofed.2. Snort implements the Boyer-Moore pattern matching function for this type of comparison [SNOR2].company. and because both source and the destination IP addresses belong to different class-B subnets.babn. represented as a set of hexadecimal values. fu ll r igh ts.<=>?’’. 10.GCIA ´ 10. ‘‘itype: 8’’ (Type:8 Code:0) is received from an external network addressed to the internal network.h” file inside the “src” directory.dhcp-10-197-231-79.231. and it is possible for an attacker to use a spoofed IP address and use reconnaissance methods. this fact confirms that the IP addresses were not spoofed.company. He just needs to have control of an intermediate system located in the path between the spoofed host and the destination to monitor all the traffic generated as the responses to the scans.

GCIA ´ 2. In sti Alerting packets between 10. It would be always recommended. running the ipcheck ([IPCK1]) software. Apart from 47 © SANS Institute 2004. The ICMP packet (second one) corresponds to the detect analyzed. no name and port translation through DNS. Due to the fact that it is a generic scanning technique. The ICMP sequence number is ‘‘6c20’’.17. The DF bit has not been set.<=>?./0123456789:. it can be mentioned that the ICMP header is 8 bytes long.132. te Figure 2. 32 bytes.181.16: As part of GIAC practical repository. Author retains full rights.79 and 10.Raul Siles . and that the payload.2. very verbose output.197. The attacker is trying to find if the destination hosts is active. It seems there is no CVE [CVE1] number associated with this type of ping variant.5 Attack mechanism SA NS -e: -nn: -vv: -X: -r FILE: display Ethernet (layer-2) information. Additionally to the information provided during the alert analysis. The detect seems to be a false positive notification originated from two network management servers. it is not possible to find references in Bugtraq [BUGT1] either. © tu This detect appears to be an information gathering attempt against an specific host. [‘‘0800 96dc 0200 6c20’’]. having the intrusion analyst enough time to do so. Key fingerprint =to understand why theFDB5 DE3D F8B5 06E4 A169 4E46 arrive to the In order AF19 FA27 2F94 998D packets that triggered the alerts destination system it is important to analyze all the logged traffic exchanged between the hosts involved: tcpdump options description used in the commands shown in figure 2.2.!"#$%&’()*+. a method that implies information/intelligence gathering.49 may be seen in figure 2.-.16: Tcpdump options for detect2 20 04 . contains the string .A ut ho rr The detect seems to belongs to a reconnaissance attack. This conclusion doesn’t reduce the value of the analysis because it is really important to be able to know about all the legitimate traffic crossing the network in order to discard the false positives and tune the network IDSes. ascii and hexadecimal. eta ins fu ll r igh ts. Sometimes this is done in preparation for a future attack. .231. based on sending as stimulus an ICMP echo request and expecting to receive a response. binary log file to get the network traces from (libpcap format). to follow this kind of analysis for all the alerts triggered by the IDS during the initial deployment and tuning process.2. DETECT 2: “PING SPEEDERA” 2. display payload in both.4 Description of attack 2.

..181..6 .231.3.79 and host 10.231..0.231.197..7} } (ttl 121. id 18671. sysName.1.2..1.2..2..1.. sysContact.49” The same scenario is repeated with the second alert..132.132..1.c. 0x0050 0500 300b 0607 2b06 0102 0101 0405 0030 .132.139.1.1.4 . This confirms the source as a probable SNMP management station.. sysObjectID.Linux 2.181.. 0x0040 0101 0105 0030 0b06 072b 0601 0201 0102 .log.public.6.49” ins $ tcpdump -nnevvX -r snort.3.20-20.132.17: Alerting packets between “10.0.4.1.4 .142.0h.142..1..1.79 > 10.181... Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 (payload Alerting packets between 10...181...197.2.1.1.3.6.. DETECT 2: “PING SPEEDERA” Raul Siles .+.0.log.6.1 .102415 0:e0:34:ca:c0:23 0:1:2:9:52:f 0800 148: 10..1258 > 10..&.3.49: icmp: echo request (ttl 121.1.1.+.. As part of GIAC practical repository.2..1.1..O 0x0010 0ab5 8431 0800 96dc 0200 6c20 2021 2223 . id 39462.1. 04 ..181..1..6. 0x0030 0201 0002 0100 304e 300b 0607 2b06 0102 .l.181.142. 0x0070 2b06 0102 0101 0605 0030 0b06 072b 0601 +...3.1.3.132.1..1...... although this time the SNMP packet arrived only 3 seconds before the ICMP packet.1060 > 10.9) © SA NS In sti tu te 20 the ICMP packet..1..3.132....6.49. 0x0020 0004 0670 7562 6c69 63a1 5b02 0301 63bb . 0x0080 0201 0107 0500 ..<.49A169 4E46is not shown) appear in figure 2.79” and “10. sysLocation and sysServices.. len 134) 15:46:30.1.3.161: [udp sum ok] { SNMPv1 { GetNextRequest(91) R=433814 .181..1 ..0N0. len 60) 0x0000 4500 003c a92b 0000 7901 0d9b 0ac5 e74f E..F.1.+.!"# 0x0020 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&’()*+..+.1..+.5 .197.2.132..1.181.2..6..6..231.161: [udp sum ok] { SNMPv1 { GetNextRequest(91) R=91067 ...1.142.2.139.Linux: (RH 9 .5 ..1.147 and host 10.197. len 134) 0x0000 4500 0086 9a26 0000 7911 1c46 0ac5 e74f E.<=>? fu ll r igh ts.1063894999 ’host 10. id 43307.1.79. It generated the [**] [1:1411:3] SNMP public access udp [**] Snort alert due to being a SNMP request (GET-NEXT) using the “public” read community and asking for the following values: SNMPv2-MIB::sysDescr.2.2 .132.1..603552 0:e0:34:ca:c0:23 0:1:2:9:52:f 0800 74: 10.3.re..051515 0:e0:34:ca:c0:23 0:1:2:9:52:f 0800 74: 10.6..1.139.139.2 .49’ 15:46:27.147.A 48 ut ho rr eta Figure 2...602417 0:e0:34:ca:c0:23 0:1:2:9:52:f 0800 148: 10. 09:23:56..7} } (ttl 121. .1.2.1.1..142.1.1.6 ... Author retains full rights.147” and “10.1.49’ 09:23:43.1.181.2.2.y..3.1.18: © SANS Institute 2004.....6.[.+.2..-. there was an SNMP packet 13 seconds before..3...1.132.1.O 0x0010 0ab5 8431 04ea 00a1 0072 6591 3068 0201 .1.1063894999 ’host 10.6.GCIA ´ # tcpdump -nnevv -r snort.1.... len 60) Figure 2..18: Alerting packets between “10..49: icmp: echo request (ttl 121.2..3.1.49. id 19679..1.0 0x0060 0b06 072b 0601 0201 0105 0500 300b 0607 .6. A rough analysis has been developed for some common OS available in this environment in order to understand the type of ICMP packet involved in the detect: ..y..1..6./0123 0x0030 3435 3637 3839 3a3b 3c3d 3e3f 456789:.1..1.139.1.1.147 and 10. The standard pattern of an ICMP echo request using the ping command varies between different operating systems...0..147 > 10.1.

Based on this info the source system seems to be a Windows 2000 box without SP applied.Other OS features are covered in section 6. a NULL value (00) appears and it adds a sequence from ‘‘0x08’’ (25 non printable ASCII chars) to ‘‘0x35’’: .. ho • DATA payload: Where ‘‘XX’’ is an increasing sequential number and ‘‘WWWW’’ is a fixed number per ping execution (some values are maintained between executions). round trip time) of a client and find the nearest cache from the client system. TTL values and DF bit. and the IP ID field is always zero for the ping ICMP requests.. • IP layer: The original TTL value is 128. • IP layer: They used to have the don’t fragment bit. The Snort signature database 27 defines this detect packets. using the most significant byte for the value (the less significant byte is zero).2. set. In • = AF19 FA27 2F94 998D FDB5 DE3D F8B5 is increased by Key fingerprint ICMP layer: The ICMP sequence number 06E4 A169 4E46 one starting at a random value. DF. the DF bit and the IP length.Raul Siles . after this. DETECT 2: “PING SPEEDERA” IP Length: 84 bytes = 20 (IP hdr) + 8 (ICMP hdr) + 56 (ICMP data) ICMP data: ‘‘XXWW WWWW YYYY ZZ00 0809 0a0b .com uses them to measure the “location” (the RTT.Windows: (2000 SP4) © SANS Institute 2004.org/snort-db/sid. All these changing values within the ICMP data payload should require a deeper analysis. 512. rr 49 eta ins fu ll r igh ts...GCIA ´ 2.speedera. 3233 3435’’ The amount of data in the ICMP echo request packets is confirmed in [OFIR1]. The ICMP ID field is a fixed value. This document also provides information about the ID. As part of GIAC practical repository. . and how they can be used to fingerprint the source OS.!"#$%&’()*+. Then. the DF bit is not set and the IP ID starts at a random sequential value (increased by one). 27 http://www. but the data payload is different. specifying that it seems that http://www. Its original TTL value is 64.A IP Length: 60 bytes = 20 (IP hdr) + 8 (ICMP hdr) + 32 (ICMP data) ICMP data: ‘‘abcdefghijklmnopqrstuvwabcdefghi’’ (fixed string) ut . It specifies Unix OSes typically send 84 bytes (56 bytes of ICMP data) while Windows OSes use 60 bytes (32 bytes of ICMP data). Author retains full rights. The detect is similar to this packet in the TTL.html?sid=480 © SA NS .-. ‘‘ZZ’’ is a value that changes for every execution of the ping command. the ICMP ID..snort. • ICMP layer: The ICMP sequence number starts at 1 and is increased by one for every request and the ICMP ID is a fixed value that changes for every ping execution. ‘‘YYYY’’ is an identifier that matches between request and reply packets and that can be repeated along time. although it is not using the standard ping utility. sti tu te 20 04 ./012345.

so they try to improve its QoS. Someone asked for this type of Snort alert and its meaning in July. 04 . so Speedera solution is not the reason for this traffic.com (previously “. after a specific on-site analysis and research. as a counterpart.GCIA ´ First of all it is important to denote that it won’t be possible to find the same ICMP packets coming from the same source IP addresses from other Internet environments because the packets associated to this detect belong to an internal production network and it was confirmed that these packets never left the company networks. 2002: http://archives. verifying if they belong to the speedera. The rule was added to Snort in order to distinguish the usually benevolent speerera pings from normal. measuring the “best” (closest) server to a specific user. the packet that triggered this detect was generated by “IPCheck” [IPCK1]. DETECT 2: “PING SPEEDERA” Raul Siles . the Speedera traffic seems A169 4E46datagram length of 84 bytes (the detect has 60 bytes) and different/random ICMP IDs. To be able to confirm this fact.com/pipermail/firewall-wizards/2002-August/012860. As part of GIAC practical repository.Exploiting Weaknesses in Intrusion Detection Systems” 29 .org/print. Author retains full rights. Then. When the nameserver queries Speedera’s nameserver.trusecure.hackinthebox. the user will receive several pings to his host 28 . It then returns a DNS reply containing the IP address of the fastest cache for your location. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 to have a As will be mentioned in section 6.html http://www. The detect has been generated over a internal network not able of receiving Internet ICMP traffic.2. These blackhat recommendations also appear in “Hack In The Box .6 Correlations In sti The traffic is generated after visiting certain speedera.com/archives/snort/2002-07/thread. the nameserver asks the root nameservers who point the nameserver at the authoritative Speedera nameservers.com domain (although they can be spoofed). Speedera usually sends its probes to the nameservers instead of the end clients in order to make work their load balancing solution. It must be considered that an attacker could masquerade its ICMP packets as this type of pings not to raise suspicions.A 50 ut ho rr eta ins fu ll r igh ts. quality of service.net”) sites.2.neohapsis. the source IP addresses can be resolved.php?sid=4654 © SA NS 2. possibly malevolent pings. Speedera is a streaming/web content delivery company. The client queries the local nameserver to resolve the address of a Speedera load-balanced cache hosted client website. . tu te 20 © SANS Institute 2004. it pings the IP address of the system making the query (the nameserver) using their distributed network.html#546 28 29 http://honor.2. Therefore.

http://www.html 31 30 © The IPCheck [IPCK1] tool generates the same type of packets as the one present in the detect.5. As part of GIAC practical repository.html 33 http://project.jp/200209/211/13/227/src211. and more information is provided in 31 . Solaris 2.GCIA ´ 2.org/lists/snort-users/Jul-02/msg00545.mdcom. Google is full of Snort reports showing this alert.html 36 http://www.5. BSD/OS 4.linuxsecurity. looking for the following content: Key|08 09 0a = AF19 FA27 2F94 10 11 FDB5 DE3D F8B5 06E4 A169 4E46 fingerprint 0b 0c 0d 0e 0f 998D 12 13 14 15 16 17|. Solaris 2. The Speedera activities were summarized in the following article in year 2000. .org/y2k/121100-1200.5.mcabee.com/incidents/2003/02/0009. probably it was the time this signature was created: http://www.http://w3i. 2002.Raul Siles . .6. com/articles/firewalls_article-2064.7.3. Solaris 2. Other ICMP tools are known to generate the type of alerts seen in this detect: sti tu te 20 04 .jp/200301/sig/sigsid-480.mdcom.1. such as: SA NS .htm 32 http://www. The main differences are the ICMP ID. BSD/OS 3.sans. This information has been extracted from the arachNIDS database 34 . on May 05. “Intrusion Detection In-Depth”. DETECT 2: “PING SPEEDERA” Other public Snortsnarf reports have detected the same Snort alert: . Version 3.org/lists/snort-users/Jul-02/msg00577.227.net/modules/XNORT/?op=showAllSignature&sid=480.66. OpenBSD 2.org/archives/intrusions/msg02727. Another reference redirects to a Honeynet Scan which is supposed to include this type of traffic 33 . The detect was triggered in a DSL connection and the packets used a different datagram length. FreeBSD 2.html http://www. http://w3i.13.dc.2.incidents.org/scans/scan17/som/som3/IDS152.1.1.org/nxana/sn_index178.IPCheck 36 In The same alert detect was analyzed by Cory Steers in his GCIA Practical.mcabee. A similar behaviour is performed by 3DNS from F5 Labs 32 . called ‘‘BSD-type pings’’: BSD/OS 2.1.jammed. OpenBSD 2.0.html .html.pdf 34 http://www.1. 104 bytes.2.A ut © SANS Institute 2004.html.co.http://lists. Author retains full rights.2. Solaris 2. the TTL and the datagram length 30 .com/info/ids152 35 http://www. ho rr 51 eta ins fu ll r igh ts. .honeynet.whitehats.6 and FreeBSD 3.coolping 35 . This signature is similar to the Linux ping.html (similar packet to the previous reference).http://eservaas. It specifies that the following OS can generate this type of ping packets.co.

. Let’s analyzed the network information where this system acted as source host (figure 2...E.132.132\. among other things.incidents..2 Windows [**] 137 [**] [1:1411:3] SNMP public access udp [**] 25 [**] [1:1417:2] AF19 FA27 2F94 Key fingerprint = SNMP request udp [**] 998D FDB5 DE3D F8B5 06E4 5 [**] [1:477:1] ICMP Source Quench [**] 3 [**] [1:469:1] ICMP PING NMAP [**] 2 [**] [1:628:2] SCAN nmap TCP [**] 2 [**] [1:480:2] ICMP PING speedera [**] 2 [**] [1:1292:7] ATTACK-RESPONSES directory listing [**] 2 [**] [111:12:1] (spp_stream4) NMAP FINGERPRINT (stateful) detection [**] 1 [**] [1:620:3] SCAN Proxy (8080) attempt [**] 1 [**] [1:618:4] SCAN Squid Proxy attempt [**] 1 [**] [1:1418:2] SNMP request tcp [**] 1 [**] [1:1228:2] SCAN nmap XMAS [**] 1 [**] [111:10:1] (spp_stream4) STEALTH ACTIVITY (XMAS scan) detection [**] 04 ..log.2. even the official Snort FAQ [SFAQ1] mentions this alert: “ 6.../012345 6789:.49" | grep -F "[**]" | sort | \ uniq -c | sort -rn 880 [**] [1:483:2] ICMP PING CyberKit 2.@. As part of GIAC practical repository. . !"#$% &’()*+... if the speedera traffic is coming from a Dialup account (as there have been reports of) it’s likely a hacker tool..2. this host has been involved in other different scanning processes..1063894999 ’dst host 10.A ut ho rr It would be important to analyze all the other alerts going to the destination host to understand the activity taking place in the network (see Figure 2. Windows update uses speedera based DNS.<.2.. Of course..GCIA ´ 0000 0010 0020 0030 0040 00 00 22 26 36 00 3c 02 27 37 0c 17 08 28 38 00 f8 00 29 39 00 00 c0 2a 3a 0c 00 fc 2b 3b 00 40 04 2c 3c 00 01 00 2d 3d 0c 9d 40 2e 3e 00 9b 00 2f 3f 00 C0 20 30 0b 22 21 31 08 22 22 32 00 01 23 33 45 C0 24 34 00 22 25 35 ..<=>? Good defensive recommendations and considerations are discussed in one of the incidents..... Mainly composed by ICMP traffic and SNMP read queries and requests..html © SA NS # tcpdump -nnevv -r snort.P.6.-) ” As can be easily deduced..org thread 37 . 37 http://www. is this bad? Quite ordinary.181\. Author retains full rights. fu ll r igh ts.7 Evidence of active targeting ins A169 4E46 In Figure 2. .-..&!. DETECT 2: “PING SPEEDERA” Raul Siles .20). .@.28 I’m getting lots of *ICMP Ping Speedera*.181... Finally..org/archives/intrusions/msg03580. eta 2.19). .49’ | wc -l 1063 # cat alert | grep -B 4 -e "-> 10\.19: Other alerts to destination host sti tu te 20 52 © SANS Institute 2004.

132.49’ | wc -l 77 # cat alert | grep -B 4 -e "[0-9] 10\.8 Severity Severity = (Criticality + Lethality) .4.log.21: Alerts from both source hosts 20 04 . DETECT 2: “PING SPEEDERA” Figure 2.3 over an Intel platform. eta ins fu ll r igh ts.147’ | wc -l # cat alert | grep -B 4 -e "[0-9] 10\.132\.49"| grep -F "[**]" | \ sort | uniq -c | sort -rn 13 [**] [1:620:3] SCAN Proxy (8080) attempt [**] 13 [**] [1:1421:2] SNMP AgentX/tcp request [**] 12 [**] [1:618:4] SCAN Squid Proxy attempt [**] 12 [**] [1:615:4] SCAN SOCKS Proxy attempt [**] 12 [**] [1:1420:2] SNMP trap tcp [**] 12 [**] [1:1418:2] SNMP request tcp [**] 3 [**] [1:469:1] ICMP PING NMAP [**] Author retains full rights.20: Alerts from target as source host Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 7 # tcpdump -nnevv -r snort.18 box running Red Hat 7.2.(System countermeasures + N etwork countermeasures) • Criticality: The target systen is a Linux 2.197\.79" | grep -F "[**]" |\ sort | uniq -c | sort -rn 7 [**] [1:1411:3] SNMP public access udp [**] 1 [**] [1:480:2] ICMP PING speedera [**] ut © SANS Institute 2004.142\.231\.139\.1063894999 ’src host 10. Some network management servers are polling managed stations through the ICMP and SNMP protocols. # tcpdump -nnevv -r snort.181. In sti tu te Figure 2. ho rr 53 This alert summary seems to show that this system has an SNMP agent running that generates SNMP traps and requests.1063894999 ’src host 10.147" | grep -F "[**]" | \ sort | uniq -c | sort -rn 6 [**] [1:1411:3] SNMP public access udp [**] 1 [**] [1:480:2] ICMP PING speedera [**] 2.139.Raul Siles .log.181\.79’ | wc -l 8 # cat alert | grep -B 4 -e "[0-9] 10\. both hosts launched several SNMP queries (figure 2.21). The information associated to both source hosts must also be extracted. This validates the hypothesis about being queried in the detect by SNMP management servers.231.A # tcpdump -nnevv -r snort. © SA NS This information confirms the previous statement about the packets origin. . Therefore its value is 3.1063894999 ’src host 10. As part of GIAC practical repository.197.GCIA ´ 2. It is a production system running CVS for some company software developments and it also contains a Web server without relevant information.2. and as can be seen.142.log.

2. It is recommended to configure packet filtering devices between these network zones. The ICMP protocol is always a controversial element from the network/firewall administrators perspective: it is very useful to troubleshoot the network and systems status. However. so it can be accessed from all the organization. it is recommended to use the “iptables” packet filtering solution. iptables. Apart from that. 2. protected by firewalls. if it is active or not. such as in this case. it has been hardened and only secure and encrypted services have been allowed. A host/personal firewall it is always recommended to control the network traffic. ICMP filtering configuration based on a default “DROP” action for the INPUT chain: © SA NS In sti tu te 20 © SANS Institute 2004.GCIA ´ • Lethality: Due to the fact that this is a reconnaissance attack. but restrictive. like. • Network countermeasures: The subnet where this detect was notified is an internal LAN network without direct Internet access. although antispoofing filters have been configured between networks. As part of GIAC practical repository. Therefore.2. that only allow the HTTP and HTTPS protocols. based on ICMP “unreachables.A 54 ut −3 = (3 + 1) − (4 + 3) ho So the resultant Severity value is: rr eta ins fu ll r igh ts. if successful. its value is 3. Author retains full rights. using “ICMP echo requests and replies”. At the host level it is possible to control which systems will allow incoming ICMP traffic based on its importance and criticality. and it is even essential for some network services and applications. Therefore it is a network design decision to allow or deny it in every portion of the network. It has a good level of protection. is not only the external layer interconnecting the internal network to Internet. but also the boundaries between the existent internal networks.9 Defensive recommendation TheKey fingerprint to AF19 FA27 2F94 998D FDB5 DE3D F8B5 system is alive using simplest way = avoid a scan that tries to figure out if a 06E4 A169 4E46 the ICMP protocol is filtering it at some level. so it scores 4. 04 . however all traffic originated from this system is allowed. so its associated value is 1. DETECT 2: “PING SPEEDERA” Raul Siles . applying a restrictive ingress policy. All hosts located in it can only access Internet through very specific proxies. that is. • System countermeasures: System has been protected using a host firewall. SSH. The following example shows a basic. It can be done at the perimeter or at the host level.2. it will only provide the attacker information about the status of the target. parameter problems or source-quenchs” types. The perimeter. . as this detect shows the network is widely open for other hosts in the internal subnets. Due to the fact that the target system is running Linux. timeexceeded.

Sys-Security. “pubKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 lic”. DETECT 2: “PING SPEEDERA” # PING: echo request input (See "iptables -p icmp -h") -A INPUT -p icmp --icmp-type echo-request -j ACCEPT # ICMP types needed: -A INPUT -p icmp --icmp-type -A INPUT -p icmp --icmp-type -A INPUT -p icmp --icmp-type -A INPUT -p icmp --icmp-type a) b) c) d) !"#$%&’()*+. classtype:misc-activity. it is recommended not to use the default SNMP read community.A ut © SANS Institute 2004. sid:480. for example. destination-unreachable source-quench time-exceeded parameter-problem -j -j -j -j ACCEPT ACCEPT ACCEPT ACCEPT Author retains full rights. depth: 100. itype: 8.2. 04 . content: "|3839 3a3b 3c3d 3e3f|". ICMP broadcast messages to avoid smurf attacks. As part of GIAC practical repository.) In sti What of the following ICMP echo request packet payloads is associated to the following “ICMP PING speedera” alert? tu te 2.!"#$%&’()*+. . ho rr 55 eta ins fu ll r igh ts. From a monitoring point of view. The rule base also alerts for a legitimate ICMP Type with a bad ICMP Code./012345 .2. Most of the nowadays commonly used OS implement methods to tune their communication stack disabling the reply of. It is recommended to analyze all them in order to protect a given network.-. These signatures will help to identify all the main and most common different ICMP packets types because they provide an initial ICMP categorization.-. to manage SNMP environments.Raul Siles ./0123456789:. The “ICMP Usage In Scanning” [OFIR1] defines the different methods the ICMP protocol can be used to attack a remote system. rev:2.10 Multiple choice test question 20 Due to the fact that the detect is based on ICMP echo request packets it is not possible to apply other ICMP defensive recommendation at the host TCP/IP stack level.com [ICMP1] released a more advanced basic ICMP rules for Snort.GCIA ´ 2.<=>? abcdefghijklmnopqrstuvwabcdefghi 495353504e475251 Correct answer: b) © SA NS alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP PING speedera". Finally.

A 56 ut ho rr eta ins fu ll r igh ts. . The alert search for the “89:. DETECT 2: “PING SPEEDERA” Explanations: Raul Siles . a) This is the ICMP payload associated to the default Linux 2. d) This is the ICMP content searched by the “ICMP ISS Pinger” alert. As part of GIAC practical repository. Author retains full rights.GCIA ´ Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SA NS In sti tu te 20 © SANS Institute 2004. 04 .rules”.2. See Snort “icmp. c) This is the ICMP payload associated to the default Windows 2000 ping packet. specified in the content parameter: “|3839 3a3b 3c3d 3e3f|”.2.4 ping packet.<=>?” string. b) This is the packet content that triggered the “ICMP PING speedera” alert.

3.Internal 00:04:76:94:D3:81 | host | 00:0C:29:47:E1:7F | 192.3. all traffic sent to the external address is redirected to the internal host (192.3 DETECT 3: “Reached by the LovSan worm” The following alert corresponds to the detect that it is going to be analyzed: [**] [1:2192:1] NETBIOS DCERPC ISystemActivator bind attempt [**] 2.168.200. version 2. more specifically. This routing device is configured to nat the internal network. running on a RedHat Linux 9 system for an Intel platform.0/24.conf”): the 11 “include” rule lines commented by default in this file were activated.2 Detect was generated by tu te Figure 2. The Snort stable ruleset available on October 11th was downloaded from the Snort website 38 and applied using a slightly modified version of the Snort configuration file (“snort.168.ADSL router ----. to the external valid Internet address.snort.22: IDS Network Topology for detect3 20 192. NIDS.200.gz © SA NS In sti 2.HUB ----.168.3.0.org/dl/rules/snortrules-stable.tar. The sensor monitors all traffic going to and coming from the unique system available. 192.200.168.1 Source of Trace Key The detect was generated through the Snort [SNOR1] Network Intrusion Detection System.GCIA ´ 2.150 | fingerprint = AF19 FA27 2F94 998D FDB5 DE3D Snort IDS 04 .0. The internal host was a Windows 2000 SP4 system. As part of GIAC practical repository.23.200. The following command was used to analyzed the log file: # snort -c /opt/snort-2. network.2/etc/snort. Small Office/Home Office. eta ins F8B5 06E4 A169 4E46 fu ll r igh ts.A ut ho The detect was generated by a Snort instance running in a SOHO.150).conf -l . This was the network topology involved: rr 57 © SANS Institute 2004. Author retains full rights.Raul Siles . The network scenario is based on an ADSL router connected to Internet with a fixed/static public IP address. ./log -qebUX Snort options are shown in figure 2. DETECT 3: “REACHED BY THE LOVSAN WORM” 2.0/24 Internet ----. 38 http://www.2 (Build 92).

don’t show banner and status/summary report.24: Alerts triggered for detect3 The alert details are shown in figure 2.200. Author retains full rights..438”).183. 8:25 (from “10/14-22:56:27.mitre. display layer-2 header information.A ut ho $ cat alert | grep -F "[**]" | sort | uniq -c | sort -rn 5426 [**] [1:2192:1] NETBIOS DCERPC ISystemActivator bind attempt [**] 4436 [**] [1:1463:5] CHAT IRC message [**] 205 [**] [1:648:5] SHELLCODE x86 NOOP [**] 133 [**] [1:2251:3] NETBIOS DCERPC Remote Activation bind attempt [**] .35.config” file. use UTC time reference. It was detected by the main Snort Rule Engine. See figure 2. rr eta ins $ grep -F "[**]" alert | wc -l 10939 fu ll r igh ts.163:4011 -> 192. 58 © SANS Institute 2004. Therefore the alert identifier is “[1:2192:1]”.200. te $ grep -F "80. by default a high priority attack (Priority:1).150:135 TCP TTL:118 TOS:0x0 ID:53361 IpLen:20 DgmLen:112 DF ***AP*** Seq: 0x6BA757B7 Ack: 0xDAF15574 Win: 0xFAF0 TcpLen: 20 [Xref => http://cve.2. Figure 2.342444 0:4:76:94:D3:81 -> 0:C:29:47:E1:7F type:0x800 len:0x7E 80.GCIA ´ specifies the Snort configuration file (described above) and run Snort in NIDS mode.924” to “10/21-08:25:40.168. 22:56 and 21st of October. dump the raw packet data starting at the link layer. Figure 2.35. The high signature number (2192) denotes it has been created recently (near August 2003).25. We focused on one2F94 998DcomingDE3D host 80. Alert signature classification and priorities are defined in Snort “etc/classification.183.3. © In Figure 2.24.183. and its signature is 2192. logging directory: alerts and packet logging. revision 1. which appeared 5426 times. .org/cgi-bin/cvename. [**] [1:2192:1] NETBIOS DCERPC ISystemActivator bind attempt [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] 10/15-07:32:48.cgi?name=CAN-2003-0352] SA NS The alert is classified by Snort as an attempt to get privilege access in the destination system.163:4011 -> 192. such as Ethernet. FDB5 from F8B5 06E4 A169 4E46 was only one specific alert generated by this source host: 04 .150:135 TCP TTL:118 TOS:0x0 ID:53361 IpLen:20 DgmLen:112 DF 20 The alert this detect is focused on was the top alert in the list.25: Network detect for detect3 sti tu As part of GIAC practical repository..163" alert 80.35.183. between 14th of October. log in binary tcpdump format.23: Snort Options for detect3 The generated “alert” file contained a total of 10939 alerts triggered during a one week period.168.35. identified by first 1 number. confirmed by the fact that it is the first revision. There Key fingerprint = AF19 FA27 of these. DETECT 3: “REACHED BY THE LOVSAN WORM” -c FILE: -l DIR: -q: -e: -b: -U: -X: Raul Siles .163.

All these fields could help to determine the source system based on fingerprinting methods [PASS1]. As part of GIAC practical repository.GCIA ´ 2. content:"|05|". was on. from a client ephemeral port (4011) addressed to the typical Windows DCE RPC server port (135). DF. Therefore. with two flags set. CAN-2003-0352. ACK and PUSH. within:1. © SA NS The alert is triggered every time a TCP packet going to port 135 is detected an the following conditions are met: In alert tcp $EXTERNAL_NET any -> $HOME_NET 135 (msg:"NETBIOS DCERPC ISystemActivator bind attempt".A ut © SANS Institute 2004. No TOS flags were set but the don’t fragment bit. although it is epmap 135/tcp loc-srv #DCE endpoint resolution . within:1.The following set of patterns should match in the packet payload: • A “05” value (content:"|05|") within first byte (within:1). The alert references a CVE vulnerability associated to this detect (analyzed in section 4).Raul Siles . the IP ID field is 53361 while the TCP window is 64240. skipping zero bytes from the beginning of the packet (distance:0). 14 bytes belong to the Ethernet header.3. .rules” file: 04 . .established. classtype:attempted-admin.35. flow:to_server. Of those. coming from the previously mentioned IP address (80. The source host seems to be running Windows 2000 at first sight. the datagram at layer-3 has 112 bytes (DgmLen:112).relative. It corresponds to a TCP packet. so the TCP payload is 72 bytes (not shown in the alert message).183.1. ho rr 59 eta ins fu ll r igh ts.0. so probably the original TTL was 128 and the source was 10 hops away (this will be verified later).Packet must belong to a existing TCP session and go from client to server (flow:to server.163) to the local system IP address (192. rev:1. DETECT 3: “REACHED BY THE LOVSAN WORM” The datagram is an IP packet (type:0x800) and was sent by the local gateway [0:4:76:94:D3:81] to the local host [0:C:29:47:E1:7F] at layer 2. reference:cve. distance:1. The TTL value was 118. distance:29. distance:0. This means the DCE RPC version must be 5. The alert was FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Key fingerprint = AF19 triggered by the following Snort rule that belongs to the Snort “netbios. content:"|A0 01 00 00 00 00 00 00 C0 00 00 00 00 00 00 46|".&.200.) sti tu te 20 The segment was 126 bytes in length (len:0x7E).established). sid:2192. byte_test:1. This directive is used by the “stream4” Snort preprocessor. It has 20 bytes of IP header (IpLen:20) and 20 bytes of TCP header (TcpLen:20). This port is defined in the Windows “services” file (“%WINDIR%\system32\drivers\etc\services”) as: Author retains full rights. within:16.168. content:"|0b|".150). TCP sequence number and ACK value are normal.

In this case “byte test:1. The source address was checked in RIPE [RIPE1] and it belongs to the following address space.). that is.).3. so its IP address seems legitimate. • The content “A0 01 00 00 00 00 00 00 C0 00 00 00 00 00 00 46” must be found within the next 16 bytes (within:16) starting at byte 33 (d:0 + w:1 + d:1 + w:1 + d:29 (distance:29). this is the first fragment of this RPC command. rev:1.35. DETECT 3: “REACHED BY THE LOVSAN WORM” Raul Siles . registered © SA NS In sti 2. the sequence number validation must be synchronized in order to continue sending and receiving data. continuously. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Typically. and the LSB defines the “First Fragment” flag.0 . In this case.CAN-2003-0352.2.&. 04 . and due to the fact that thousand of attempts to exploit this vulnerability were received.GCIA ´ • A “0b” value (content:"|0b|") within next byte skipping 1 byte (distance:1). that is. a complete network audit trail was captured. . To sum up. next byte is 33rd). It was possible to confirm the establishment of some complete TCP sessions from the source. due to the fact that the 3-way handshake must be completed and. In the detect packet.0.0.3 Probability the source address was spoofed tu te The DCE RPC protocol packet format can be obtained from “DCE 1.3. the test will be true if the next byte after the “0b” has the LSB set. not spoofed. A external CVE reference has been provided by Snort (reference:cve. 20 © SANS Institute 2004. . Next RPC packet field defines the packet flags.32. so 03 & 01 = 01. in the third packet octet. the next byte value is “03” (flags “First Frag” and “Last Frag” were set).) and classified (classtype:attempted-admin.0. and process it going 0 bytes into the payload. meaning the tested flag is set. 80.Finally the alert signature has been given an identifier (sid:2192.observed TTL (118)).relative. See figure 2.80.A 60 ut ho rr eta ins fu ll r igh ts.26. This byte specifies the DCE RPC packet type.32. • The “byte test” operator tells Snort to test a field against a specific value based on numerical/binary operations.” means pick up 1 byte from packet. This field corresponds inside the RPC protocol to the “Interface UUID” value. It was confirmed that there were 10 hops from the IDS box segment to the source system (original TTL (128) . This statement is also supported by the fact that a TTL test comparison was made against the source address to determine if the address was spoofed or not using the traceroute command. As part of GIAC practical repository.255 (80. Author retains full rights.255. apply the logical AND operator (&) against value “01”.1. the TCP sessions are difficult to be spoofed.1 RPC Specification” [DCE1] [RFC1057] [RFC1831] or Ethereal [ETHE1].0/16). The “relative” keyword means to use an offset from the last pattern matching. in this case a “Bind” packet (0x0b).

0... 2000.183..0. .. = Last Frag: Set . = Maybe: Not set . It allows a remote attacker to execute arbitrary code via a malformed RPC message. rima-tde. ... te 20 Figure 2. © 2. DCE RPC Version: 5 (*) Version (minor): 0 Packet type: Bind (11) (*) Packet Flags: 0x03 0..Raul Siles ..35.. and seems to be an address associated to a pool used for end users....26: DCE RPC packet format fu ll r igh ts... Description of attack NS In sti tu As part of GIAC practical repository.microsoft.1066164714 -R ’ip.1 = First Frag: Set (*) Data Representation: 10000000 Byte order: Little-endian (1) Character: ASCII (0) Floating-point: IEEE (0) Frag Length: 72 Auth Length: 0 Call ID: 127 Max Xmit Frag: 5840 Max Recv Frag: 5840 Assoc Group: 0x00000000 Num Ctx Items: 1 Context ID: 1 Num Trans Items: 1 Interface UUID: 000001a0-0000-0000-c000-000000000046 (*) Interface Ver: 0 Interface Ver Minor: 0 Transfer Syntax: 8a885d04-1ceb-11c9-9fe8-08002b104860 fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 Syntax ver: 2 Key 04 .pooles.0.log. XP.. .4 SA ˜ by “RIMA (Red IP Multi Acceso). . The detect belongs to an attempt to exploit the Microsoft MS003-26 vulnerability associated to the Windows operating systems.3..net” what confirms the previous information..183.. 39 39 http://www.. <<graphical view>> ........ . DETECT 3: “REACHED BY THE LOVSAN WORM” $ ethereal -r snort.. = Did Not Execute: Not set .35.. 06E4 A169 4E46 Author retains full rights.1. = Object: Not set .com/technet/security/bulletin/MS03-026.. = Cancel Pending: Not set .A ut ho rr 61 eta ins (*) Fields checked by the alert signature. and Server 2003..TELEFONICA DE ESPANA” a Telecom Service Provider company located in Spain. 0..0 ..3.addr == 80.. This IP address (80.GCIA ´ 2.. version NT 4.... .asp © SANS Institute 2004. = Reserved: Not set .Red-80-35-183.0.163) can be resolved to “163... . = Multiplex: Not set .163’ & ..

com/avcenter/venc/data/w32. such as Blaster. There are also some Bugtraq [BUGT1] references 44 .com/search/ 56 http://www.symantec. Snort provides a CVE [CVE1] reference about the vulnerability that the packets that triggered the alert is trying to exploit 43 .mcafee.vsantivirus. W32. 04 . Author retains full rights. therefore they published a really good analysis about it 41 42 . therefore having complete control of it.html 42 http://www. So.com/vinfo/virusencyclo/ 57 http://www.GCIA ´ http://www. Panda .asp?VName=WORM_MSBLAST.vsantivirus.com/lovsan-c.mitre. More information about all the mentioned © SANS Institute 2004. GEN 51 http://www.asp?cid=9043 54 http://www.htm 52 http://www.Worm 49 (best description).org/cgi-bin/cvename.cert. The vulnerability is based on a buffer overflow in certain DCOM interface for RPC in Microsoft Windows versions. The following documents describe how to detect. Blaster.C or C version.cert.com/ 41 © SA NS In sti tu te 40 20 Through a successful attack of this type. the same vulnerability has been exploited by different worm variants.C.org/advisories/CA-2003-16. CVE provides several additional useful references.c 47 .xfocus.worm. Finally. The original vulnerability was discovered by LSD (Last Stage of Delirium) 40 . 2003.trendmicro.org/advisories/CA-2003-19.C 51 .2. LovSAN.org http://www.symantec.html 53 http://us.com/vinfo/virusencyclo/default5.html 47 http://us.aspx?idvirus= 40390 49 http://securityresponse.com/virus_info/ 55 http://www.xfocus.Blaster.cert.blaster. WORM MSBLAST.org/advisories/CA-2003-20. the system will be totally compromised. Nachi and Welchia. CERT also released two security advisories due to the huge and critical impact associated to the enormous Internet Windows installed base 45 46 .A 62 ut ho rr eta ins fu ll r igh ts. also known as Blaster. The “teekids. MSblast.com/bid/8205 45 http://www.cgi?name=CAN-2003-0352 44 http://www.3.trendmicro.exe” file is associated to the LovSan variant.com/virusInfo/default.com/virus_info/encyclopedia/overview.C 48 . DETECT 3: “REACHED BY THE LOVSAN WORM” Raul Siles . an attacker would be able to obtain admin privileges in the system.c. The following antivirus websites has been selected to get the information as53 54 sociatedfingerprint = AF19 FA27 2F94 998Ddetect: DE3D F8B5 06E4 A169 Symantec Key to the worm that generated the FDB5 McAfee . after a successful attack.pandasoftware. patch and understand the worm actions and purpose: W32/Lovsan. 4E46 55 56 57 .html 50 http://www. As part of GIAC practical repository. CERT generated a specific advisory for the Blaster worms variants 52 .GEN 50 and W32/Lovsan.securityfocus.com/virusInfo/default.org/advisories/200307/4.org/documents/200307/2.html 43 http://cve. clean.xfocus. on July 16th.pandasoftware.mcafee.worm.asp?id=description&virus_k=100552 48 http://www.html 46 http://www. . TrendMicro and VS Antivirus .

4 seconds after closing the TCP connection a second TCP session was established from the same source host.).GCIA ´ 2. Exploitation of this issue could result in execution of malicious instructions with Local System privileges on an affected system.183. the attacker sends an RPC request packet using the same TCP session.5 Attack mechanism The detect was generated due to an attempt to exploit a Windows DCE RPC vulnerability announced in a Microsoft Security Bulletin: MS003-26. first one Keyhas 1514 bytes (the maximum Ethernet DE3D including the Ethernet header (14 fingerprint = AF19 FA27 2F94 998D FDB5 MTU F8B5 06E4 A169 4E46 bytes)): 20 (IP hdr. In order to simulate a vulnerable host. 2. The previous session pretended to open a backdoor in this port exploiting the Windows RPC vulnerability. 0.35.exe. a special environment was set up.exe” file. the attacker established the new TCP session and launched the following command: tftp -i 80. ho rr 63 eta ins fu ll r igh ts.3. Based on the complete network audit trail it was observed that. As part of GIAC practical repository.C worm.Raul Siles . Once acknowledged. The configuration changes will be shown along the attack description.) plus 1460 (TCP payload) . Given the fact that in the described environment the local system (Windows 2000 SP4) was not vulnerable to this attack. 20 (TCP hdr. © SA NS In sti tu te 20 04 . Both RPC commands conforms the exploit. .27. configuring the host firewall to allow traffic addressed to the ports used after launching the RPC command (see below). This RPC command is divided in two TCP packets because its length. Author retains full rights.163 GET teekids. Then a second TCP packet is received with a payload of 244 bytes associated to the rest of the RPC operation. Specifically. The originator was a host infected by the LovScan. In order to understand the attack associated to the huge amount of attempts received against TCP port 135. netcat [NETC1] was configured to listen in port 4444 of the internal host to receive all traffic.A ut © SANS Institute 2004. This RPC attack is based on establishing a TCP connection through the 3way handshake and sending the packet that triggered this detect. a specially customized layout was prepared to get as much information as possible of this type of threat and to identify the specific worm variant (described in the next section). The problem is due to insufficient bounds checking of client DCOM object activation requests. Finally the TCP session is closed. The second RPC request has the RPC header (obtained through Ethereal) of figure 2. and RPC bind attempt.RPC header plus 1436 bytes of RPC payload (Stub Data). addressed to TCP port 4444. the one using the “teekids. in this detect.3. DETECT 3: “REACHED BY THE LOVSAN WORM” worms can be found there.

. (244 bytes) Raul Siles . As part of GIAC practical repository. = Maybe: Not set . = Multiplex: Not set ...3. 0..exe”. lots of exploits were made public. There are several tools. DETECT 3: “REACHED BY THE LOVSAN WORM” DCE RPC Version: 5 Version (minor): 0 Packet type: Request (0) Packet Flags: 0x03 0. 04 . freely available on Internet.. .. without error checking.exe.2.1 = First Frag: Set Data Representation: 10000000 Byte order: Little-endian (1) Character: ASCII (0) Floating-point: IEEE (0) Frag Length: 1704 Auth Length: 0 Call ID: 229 Alloc hint: 1680 Context ID: 1 Opnum: 4 Stub data (1436 bytes) .... because the netcat process running didn’t generate the expected output. not only worms.. = Did Not Execute: Not set . The worm uses TCP ports 135 and 4444. the 06E4 A169 4E46 to retrieve a binary file called “teekids. .. it just received the data. = Cancel Pending: Not set .....exe” files in the target system. implementing this attack...0. = Reserved: Not set . . All these actions are executed atomically..0 . = Object: Not set .27: Second RPC request packet header ho rr eta ins fu ll r igh ts..exe” and the “root32. First one is used to exploit the vulnerability and second one to provide a network backdoor... ..1..0.... Author retains full rights.. In this case.. Initially a DoS exploit appeared and then a shell exploit.exe and teekids. ..A 64 ut Figure 2.. This file is the worm itself. It also uses UDP port 69..GCIA ´ Therefore.. if any.. the one used by © SA NS In sti tu te 20 © SANS Institute 2004.0.. the attacker tries to run the new file using the command start teekids. . Since the vulnerability was found. because the TFTP service is used as a transport/copy mechanism.. the opened backdoor seems to be a Windows command prompt thatKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5Windows TFTP client allows to launch commands remotely. .. Then.. Some variants of the teekids worm introduce the “index. = Last Frag: Set ..

Author retains full rights. “0a 01 00 00 00 00 00 00 c0 00 00 00 00 00 00 46”. .com/map/ Number of virus incidents reported by region and/or country.c.com/ehines_gcia_detect1. NS In sti tu te 20 04 .A ut © SANS Institute 2004.255 times in October 2003 (2nd position). and its variants since it was created.Jason Bowen analyzed the Welchia variant in his GCIA Practical 63 .win2kdos.A appeared 23. plus some statistics about this threat (all statistics were extracted the 3rd of Dec of 2003): DShield: AF19 FA27 2F94 998D FDB5 Key fingerprint = http://www.GCIA ´ 2. hit 227. During the past 30 days.dshield.asp Numbers by month and virus type. 2003: . then a DoS exploit 59 .dshield.org/port_report.3.c”). Instead it has more sense to provide a set of Internet references that could help in knowing the Internet virus status and health. being possible to specify a time period.21. Due to the huge expansion of this worms.com/bid/8205/exploit/ http://www. The hexadecimal “strings” placed inside the C-language code contain the string searched by Snort.A.c.com/exploits/07.com/pipermail/full-disclosure/2003-July/007092.org/ DE3D F8B5 06E4 A169 4E46 Even nowadays the top most attacked port is TCP 135 65 . Summary reports: http://wtc.appliedwatch. Hines analyzed the alert in his GCIA practical. August 2003. the worms 58 . The reports about this port 66 associate to it 3 different vulnerabilities that are being exploited: CAN-20030605. Virus Map: http://www. a shell exploit 60 all referenced in this thread 61 (very busy during July 2003).securityfocus.trendmicro. Blaster.25.de/archive/intrusions/2003/08/msg00234. For example.com/pipermail/full-disclosure/2003-July/thread.org/topports. It is based in the original LSD proof-of-concept code and uses the TCP port 4444 62 .php 60 http://www.netsys.uni-stuttgart. DETECT 3: “REACHED BY THE LOVSAN WORM” 2.6 Correlations http://www.com/wtc/summary. but the exploit is used by a hacker and not by a worm 64 .145 times in Europe (3rd place).k-otik. it has no sense to analyze some specific references about people getting incoming connections associated to it. .3.k-otik. MSBlast.html 63 http://cert. This list includes one of the first RPC exploit released (“dcom.dshield.winrpcdcom.pdf 65 http://www.php 61 http://lists.html 64 http://www. MSBlast.Eric S. used later by several worms as the one involved in this detect.com/exploits/07.netsys. ho rr 65 eta ins fu ll r igh ts.php 66 http://www. As part of GIAC practical repository.php?port=135 59 © 58 SA The Snort alert appeared in Google 3 times (2 of them contain the same data) the 3rd of Dec.Raul Siles . 0528 and 0352.html 62 http://lists.trendmicro.

mcafee.com/virus_info/encyclopedia/overview.38. but to compare the different threats.40..E was in the 3rd position during last month in Europe.183.40.168.asp?Cmd=Map\&b=NS\&ft=JPEG\&lang=en http://www.66 31 80.38.3.36.htm 70 http://www. Different metrics and time periods allowed.7 Evidence of active targeting http://mastdb2. Virus Infection Map 69 and Global Virus Observatory 70 : Blaster.16 20 80.0. from or to it.0. From all these systems it is possible to obtain the top attacker list and how many times they tried this attack during the time period analyzed: 20 © SANS Institute 2004.67 39 80. 80.129.231.167 26 80.pandasoftware.168.200.aspx?idvirus= 40390&lst=est 72 http://www.163 68 67 © Most attackers belong to the same class-A network.129.php?ip=80.A $ cat alert | grep -F "NETBIOS DCERPC ISystemActivator" -A 5 | \ grep -F "192. which belongs to different telecom providers based on the whois information: SA NS $ cat alert | grep -F "NETBIOS DCERPC ISystemActivator" -A 5 | \ grep -F "192.211 29 80.pandasoftware.38. was reported.0/8.org/ipinfo. As part of GIAC practical repository. Although the source host analyzed only launched the attack against the internal host one time. All numbers are based on the notifications received by the different antivirus centers.37.pandasoftware. In sti tu te There was 2771 AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 the Key fingerprint = different infected host launching the same attack against local host.150" | cut -d’:’ -f 1 | sort -u | wc -l 2771 66 ut ho The source IP address was run through the database at Dshield.pandasoftware.36.224.com/virus_info/map/observatory.197 .htm 71 http://www. 04 .2.38. it was interesting to know how many different host generated the same alert in the network analyzed: rr eta ins fu ll r igh ts.40. Author retains full rights.C specific statistics showing the most affected countries. Virusometer 68 . Blaster.org 72 and no information about active targeting.GCIA ´ 2. and cannot be used as an absolute measure.htm 69 http://www.150" | cut -d’:’ -f 1 | sort | uniq -c | sort -rn 48 80.com/virus_info/virusometer/detail. .35.dshield.com/virus_info/map/map..com/VirusMap3. the location where this detect was observed 71 . DETECT 3: “REACHED BY THE LOVSAN WORM” Raul Siles . Spain is one of them.39 25 80.3. World Virus Map 67 : Real time worldwide information.200.

40. 80. sti tu te 20 04 . providing high-speed Internet (ADSL) access to end-users.my/graphs/W32.(System countermeasures + N etwork countermeasures) • Criticality: The target system is a home host running Windows 2000 and used mostly as a client system. placed on 80. like 80.200.RIMA: The network portion referenced on section 3. .html http://www.34 106 80. is part of a set of class-B networks owned by the same provider.0.0/16. This fact justifies why all the end-user systems..3. 73 74 http://www. other references contain similar information 73 . The creator of the “teekids” worm was arrested on August 29.2 | sort |\ uniq -c | sort -r 1704 80.3.com/ac2/wp-dyn/A64800-2003Aug29?language=printer © SA NS In The owners of these networks are national ISPs. 2003 74 75 . Rough worldwide Internet numbers for this worm variant can be obtained from the sources provided in the correlation section.37 649 80. ho rr 67 eta ins fu ll r igh ts. As part of GIAC practical repository..Raul Siles . Due to the high number of systems trying to exploit the same vulnerability against a randomly chosen home systems it seems clear the detect correspond to some type of Internet worm. could be infected by the worm.pcsympathy.washingtonpost. It contains some important personal information.8 Severity Severity = (Criticality + Lethality) . Author retains full rights. Besides.32. that is. Most worms select their victims using a random function to generate the destination IP addresses. DETECT 3: “REACHED BY THE LOVSAN WORM” . 2.0/16. located in UK.37. As deducted from all the information collected lots of systems Keyconnected = AF19 FA27 2F94 998D FDB5 DE3Dare launching the4E46 fingerprint to Internet have been infected and F8B5 06E4 A169 described attack against the local network. . therefore its value is 2. the public IP address associated to the ADSL connection.UK-TELINCO: Tiscali.0.mycert.0/13.40 583 80.A ut © SANS Institute 2004.33 .’ -f 1.com/article199.html 75 http://www.Nachi/blaster_nachi.org.35 172 80. If there are lots of systems running the function.38 1597 80. $ cat alert | grep -F "NETBIOS DCERPC ISystemActivator" -A 5 | \ grep -F "192.Blaster_W32. It owns the top attacker hosts.150" | cut -d’:’ -f 1 | cut -d’. Windows based.168.36 271 80. the probability that some of them generate a specific IP address is very high.GCIA ´ 2.0.

Besides. • System countermeasures: System patches were up to date. the Severity value is: Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 2 = (2 + 5) − (4 + 1) On the one hand. This made the system not vulnerable to the attack presented in this detect. it is not always enforced.A 68 ut ho rr eta ins fu ll r igh ts. 22.com/?kbid=826369 78 http://support. and if exploited successfully.9 Defensive recommendation te 20 © SANS Institute 2004. .com/technet/security/bulletin/MS03-039. without filters. This fact grants this threat a value of 5. The latest Microsoft Security Bulletins and patches 76 77 http://www.3. Apart from the already commented Microsoft bulletin. such as no egress filtering: all traffic from inside to Internet was allowed. System was also running a personal firewall with a not very restrictive policy. This is one of the basic defensive countermeasures that can be applied and although it seems obvious and simple. the filtering solution allowed some services.microsoft. Its value is 4.GCIA ´ • Lethality: The vulnerability that the traffic associated to this detect is trying to exploit is really dangerous.2. having last Windows Service Pack installed. 04 .microsoft. 53. such as TCP port 21. Author retains full rights. in section 4. system patches must be up to date. Microsoft released an update. DETECT 3: “REACHED BY THE LOVSAN WORM” Raul Siles .microsoft. Therefore. The following Microsoft Knowledge Base articles are also a recommended reading to be protected:77 and 78 . in this case SP 4 for Windows 2000.3.asp http://support. As part of GIAC practical repository. It is recommended to patch the Windows systems in order to fix the referenced vulnerability based on the information available in these Microsoft Security bulletins. all traffic going to the available public Internet address was redirected to the internal host. in order to mitigate or even completely stop the effects of a exploit similar to the one associated to this detect.com/?kbid=827363 © SA NS In sti tu 2. and also all the individual patches published by Microsoft. based on all the information retrieved. MS003-39 76 that covered the original vulnerability plus 3 newly discovered RPC vulnerabilities. • Network countermeasures: There were no perimeter firewall configured. 135 and 443. 80. will provide remote access with the highest privileges in the system. the special configuration developed in order to let the attack process continue to be able to get all the required information for the analysis (described in section 5) has not been considered. The value associated to this situation is 1. To evaluate the severity of this detect. the highest possible value. This time this fact is directly associated to the Snort “priority” value. MS003-26.

Raul Siles . It should be located in “C:\Windows\System32\”. this incident should be reported through the recommended procedures.com/security/incident/blast. As part of GIAC practical repository. It is very difficult to determine the real utility and necessity of the RPC service in the Windows operating systems. the RPC service is killed. Once the attack is received.3. The “Recovery” tab associated to the properties menu of this service specifies the acKeytion that should beFA27 2F94 a failure. Keep yourself as much informed as possible about the worm actions and effects.htm 81 http://www.asp 80 SA NS 1 Change the default behaviour to “Take No Action” until a protection has been applied. although in cases of widely spread worms there is no too much the provider could do: . it is recommended not only to clean the system but to rebuild the system using a fresh install. those services that are not required in the system must be disabled or at least not being accessible from outside.com/WIN2K/servicecfg. Some pages provide information about the relationship between the Windows services 80 . the antivirus solutions would be very helpful in determining if a system has been infected by the RPC worms. TCP port 135 shouldn’t be opened to Internet. If 4E46 fingerprint = AF19 applied in 998D FDB5 DE3D F8B5 06E4 A169 a system reboots continuously due to the high number of worm attempts. because the system has been compromised with high privileges.microsoft. a personal firewall must be installed in all systems enforcing the incoming/outgoing traffic allowed. and some Windows versions are configured to shutdown the system if this service is not alive. If this is the case.exe” file in order not to transfer the malicious binary. “Restart the computer”.RIMA: remarks: remarks: 79 © http://support. Author retains full rights. In this case.GCIA ´ 2. rename the “tftp. 2 To avoid be infected.A ut © SANS Institute 2004. *************************************************** For ABUSE/SPAM/INTRUSION issues In sti tu te can be found in Microsoft website 79 . For this type of worms.aspx?pr=security http://www. two actions can be accomplished: 20 04 . See all the references provided in section 4. For example. ho rr 69 eta ins fu ll r igh ts. such as installing additional backdoors or keyloggers.blackviper. DETECT 3: “REACHED BY THE LOVSAN WORM” Following the information provided through the WHOIS service by the source IP address owners. so the second option is the recommended one. . On the other hand.com/default. Therefore. and other unknown actions could have been performed. “C:\Winnt\System” and/or “C:\Windows\System32\dllcache”. Microsoft suggests some defensive recommendations in “What You Should Know About the Blaster Worm and Its Variants” 81 .microsoft.

tiscali. 04 .200.3.163:4011 -> 192. As part of GIAC practical repository.es will be ignored *************************************************** 2. although they develop different actions once the target system has been compromised..TISCALI: trouble: trouble: PLEASE CONTACT THROUGH LINK http://www.com/nemesys/ or send mail to nemesys@telefonica. all them exploit the same Windows DCOM RPC vulnerability.183.cgi?name=CAN-2003-0352] © SA NS In Explanations: As has been mentioned along this paper.A 70 ut ho rr eta ins fu ll r igh ts.10 Multiple choice test question Which of the following Internet worms propagated during year 2003 would generate the following Snort alert? [**] [1:2192:1] NETBIOS DCERPC ISystemActivator bind attempt [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] 10/15-07:32:48.35.com Concerning abuse and spam .org/cgi-bin/cvename.es any mail to adminis.GCIA ´ remarks: remarks: remarks: remarks: remarks: . Information: http://www. .ripe@telefonica.150:135 TCP TTL:118 TOS:0x0 ID:53361 IpLen:20 DgmLen:112 DF ***AP*** Seq: 0x6BA757B7 Ack: 0xDAF15574 Win: 0xFAF0 TcpLen: 20 [Xref => http://cve. sti tu te 20 a) Blaster b) LovSan c) Nachi d) Welchia e) All of the above Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Correct answer: e) © SANS Institute 2004.com Author retains full rights. DETECT 3: “REACHED BY THE LOVSAN WORM” Raul Siles . mailto: abuse@uk..tiscali.342444 0:4:76:94:D3:81 -> 0:C:29:47:E1:7F type:0x800 len:0x7E 80.2.3.mitre.telefonicaonline.168.

the top alerts.1: Number of alerts. © In sti Figure 3. OOS. te 20 04 . During this period there were 2 peaks of more than 400 thousands scans per hour. The most interesting security events will be analyzed in detail.Chapter 3 Analyze This 3. Author retains full rights.1 Executive summary The “GIAC” University IDS network audit analysis produced a total of 286108 alerts. with more than 11.5 million scan packets (11699719) and 18225 out-of-specs.2). 1114145 portscans.A ut ho rr eta ins fu ll r igh ts. the number 71 © SANS Institute 2004. during a 5 days period. and was kept until 7:00 of day 23rd. the data was normalized removing the scan events (figure 3. for about 15 hours. scans and oos. this analysis focuses on describing the information extracted from the different data sources. while providing statistical and in depth information for all the relevant selected detects. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 SA NS During the 5 days period analyzed (figure 3. . 2003. from 19th to 23rd of October.1). analyzing the internal network topology. it can be seen that on day 22nd at 22:00 was a huge growth in the number of scans. After the huge scan period. scans and OOS over time tu As part of GIAC practical repository. At the end of the analysis there was another peak of more than a quarter million scans. Due to the huge amount of information collected. In order to analyze the alert and OOS information.

DNS (53) and Web (80). It seems that all the information obtained through the scanning process was used later trying to exploit potentially found vulnerabilities.GCIA ´ © SA NS Figure 3.1. As part of GIAC practical repository. although some other non-standard scans were discovered. Most alert events are associated to portscans and they were analyzed with other scanning activities. and almost all scans were generated from the University network. Author retains full rights. the analysis was focused on the top eleven most frequent events plus some additional sporadic alerts that could indicate compromised systems. This type of activities should be reduced in order to mitigate the organization liability. Additionally. From the different fifty alerts identified. Web (80). is associated to general scanning processes using the TCP and UDP protocols. the most frequent OOS event is related with one of the most frequent scans types: a TCP SYN packet with the ECN flags set (“12****S*”). such as IRC traffic.A 72 ut ho rr eta ins fu ll r igh ts. from 11:00 of day 23rd until the end of the data analyzed. and IRC traffic (Ultima Online. network worms and DDoS tools. The OOS information logged is negligible compared to the alert or scans data sets. The top destination target services were RPC (135). EXECUTIVE SUMMARY Raul Siles .2: Number of alerts and OOS over time In sti tu te 20 © SANS Institute 2004. Almost all scanning targets belong to a wide number of external networks. Most scanning traffic. 04 of alerts increased. . 8887). The WHOIS public registration information has been extracted for those exterKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 . The top 5 destination OOS ports (97%) correspond to Mail (25).3. 99%.

MY.NET. ho rr 73 eta nal IP addresses considered most interesting during the analysis. It must be noted that there are lot of activity associated to Comcast systems. located in Europe. America and Iceland).254.114 and MY. so they require immediate investigation in order to evaluate their status and take the appropriate actions: ins fu ll r igh ts.34. .255.2. The log files © .16.Analyze the relationship between MY.Back Orifice traffic addressed mainly to net MY.NET.162.153. .16.NET.51.2 The data have been provided by the “GIAC” university in order to develop a security audit of the information captured by their intrusion detection system.NET. .0-68.NET.NET. different data tables related with the top talkers systems.84.195. MY.The top target system for lots of potentially exploit traffic: MY.NET.24.198.255. . and other traffic generated from several telecom/Internet providers addresses all over the world (Europe.NET.It must be investigated the strictly relationship between the University systems and lots of Comcast computers: 68.169. .NET.NET.235.70.1.NET.190.150.GCIA ´ 3.63. There is evidence to consider that several internal systems have been compromised or behave in an unexpected way.249 and MY. .Hosts potentially involved in DDoS activities: MY.X. 193. . . .NET. As part of GIAC practical repository.190.NET.List of possible compromised host by a trojan: MY.180 (involved in P2P exchanges). Asia.106. SOURCE OF DATA 3.Two hosts are infected with the MS Blaster worm: MY.NET.244. like 169.Some Windows systems generating lots of potentially evil NetBIOS traffic.NET.3 and MY. . from inside and outside the local network.30. For a detailed reference of the most relevant systems involved in the IDS logged activities.190.4.NET.30. MY.It is recommended to review the activities associated to MY. MY.60.163. A link graph was generated focusing on one of the top external hosts involved in huge amounts of very different traffic types against MY.2.NET. MY.133 and MY.114.163 and MY. have been obtained.56.41 and one host located in the NASA. SA Source of data NS In sti tu te 20 04 . a specific relationship with a system located in the NASA.150.0.84.32.80.NET. Author retains full rights.A ut © SANS Institute 2004.Investigate the configuration of the dynamic address hosts and DHCP enviKey fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 ronments.Raul Siles .

031019. therefore some assumptions should be made in order to obtain a generic network topology map. ut ho # src 947 310 310 2 © SANS Institute 2004. 2003: Name alert.gz 20.031023. not to loose events of interest.incidents.NET.X in the data files.031022.A 74 The files had an initial number of entries but some of them were corrupted.gz 23. Based on the information logged it is possible to extract some numbers about the existent hosts: sti After analyzing all the extracted data.gz scans. NETWORK TOPOLOGY Raul Siles .gz alert. It is assumed that a recent Snort version was used to trigger the alerts.org/logs © Log type Alerts spp portscans Scans (not MY. Correlating the information between the scan files and the alerts.gz scans.X. rr eta # dst 2421 N/A 16695 102 ins Author retains full rights. . except the scan files. ” The analyzed files belong to a period between 19th and 23rd of October.gz alert.85. SA As part of GIAC practical repository.gz scans.gz alert.3.NET.GCIA ´ have been downloaded from “incidents.gz size 2095723 1624229 2383883 3614074 6812139 Name OOS Report OOS Report OOS Report OOS Report OOS Report size 176588 153019 199739 108064 81022 fu ll r igh ts.031020. so the Snort ruleset from 9th of December of 2003 was used to match the signatures found [RULE1].031022. The monitored internal network is a class-B network labeled MY.031019.X.3 NetworkAF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 04 .gz 22.X. so they were preprocessed in order to remove the invalid entries before populating the database. NOTE: The preprocesing process has not been included to reduce the paper length due to GIAC length constraints.gz scans.031020.gz 21. As explained in the URL above: “ The log files are the result of a Snort instance running in binary logging mode. The scan 1 http://www. it was confirmed that there were 2613 different MY.gz Name scans.X.NET hosts belonging to 89 different class-C subnets.031021. This means that only the packets that violate the ruleset will appear in the log. spp portscans and OOS it was confirmed that MY.3.gz alert.NET) OOS tu te 20 Key fingerprint = topology 3.031021.org” 1 and correspond to 5 consecutive days worth of data. 2003 2003 2003 2003 2003 10 10 10 10 10 19.gz size 10462579 8408852 13060702 26665110 38516849 NS In The only source of data was the raw log files.031023.X is the network 130.

This is the reason why some of the customized alerts contain the strings “[UMBC NIDS]” or “[UMBC NIDS IRC Alert]”.NET.NET.On the one hand the destination addresses and ports were visualized trying to guess valid requests received by the internal systems. the UMBC web page provide information about their network and equipment 3 and the residential network (ResNet) they manage 4 .On the other hand.NET. MY.A ut © SANS Institute 2004. . . . This alert was triggered 5 times trying to access 3 different FTP servers: 216.24.edu http://www.88. . NETWORK TOPOLOGY Based on all this information the following assumptions were made: .There is a TFTP server in MY. the source data was used to analyze the traffic generated by the internal systems.rules”).229: “TFTP .15.X”. eta ins fu ll r igh ts.85) belong in the real world to the University of Maryland.47. 2 3 http://www.umbc.143. 205. 53 and 70. files have not been sanitized so this data files provided a new set of destination hosts scanned.NET.74.70.209.umbc. 27 and Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 .136. Although not used at all along this paper.41 and 64. All the different alert types were analyzed with the goal of determining the services offered by the internal hosts. addressed to port 21.NET. all them placed in net MY.44 generating traffic from TCP port 69 to 64.edu/oit/sans/physnet/noc/ 4 http://resnet.NET. As part of GIAC practical repository.Using the alert “FTP passwd attempt”.29.70.3.X.umbc.19.251.13.html © SA NS In sti tu te 20 04 . although this information can potentially generate false statements.227.24.49.There are specific alerts detecting FTP access to Helpdesk: “External FTP to HelpDesk MY.196. Two types of information were analyzed: Author retains full rights.GCIA ´ 3. The existence of a FTP server in MY.27 seems to be confirmed by the different attempts from several sources to exploit a ftpd vulnerability: “FTP DoS ftpd globbing”.Raul Siles . The University network MY. that contain 3 systems associated to HelpDesk tasks: MY. Therefore it seems there are 2 internal class-C networks. at least one HelpDesk host is monitored when accessing external FTP servers. similar to the default Snort alert “FTP passwd retrieval attempt” (“ftp.70.18. Baltimore County (UMBC 2 ) as it’s summarized in the whois information extracted from ARIN [ARIN1].X: . it is possible to identify several FTP servers.External TCP connection to internal tftp server”. . ho rr 75 .9.edu/resnet_layout. Besides. .NET. “HelpDesk MY. .53.49 to External FTP”.50.24.NET.NET (class-B 130.49 and MY.

30. This information was correlated with the different alerts captured for these hosts. Their specific purpose will be analyzed during “Alert #3” description. NTP traffic used to go from port 123 to port 123. such as MY. These systems belong to 46 different MY.44.NET.NET subnets. Yahoo caches (l8.NET.NET. As can be appreciated.14 and MY.NET.24.NET.5.4.3.bharath.NET.Initially it seems there were some NTP servers based on alert “EXPLOIT NTPDX buffer overflow” (see Snort “exploit.streamos.A 76 ut ho . As part of GIAC practical repository.cache.NET.24. Network MY.50.X is mainly populated by Windows and Novell hosts.34. network MY. the sensor seems to be located in a border network due to the overall alert categorization and the lack of alerts involving at the same time source and destination addresses of MY. NETWORK TOPOLOGY Raul Siles .24. so it is probably some kind of DMZ network.20. It was confirmed that the detects belong to evil traffic: . .Additionally there are lot of IRC traffic that must be investigated (see “Alert #12”). MY.153. 04 .12.com) that probably have been compromised. 20 © SANS Institute 2004.216.There are 2 SMTP (25) mail servers: MY.NET.24.17 and MY.NET.74. Therefore.NET.67.3.4 and MY.24.53.Based on the alert messages there are some specific networks.There are several Web (80) servers: MY. eta ins fu ll r igh ts.NET.152 and . being the top talkers subnets Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 MY.sjc.12.29.3.com) or portal servers (winserver1. MY.NET.60. Checking the source systems to confirm NTP relationships there was no normal NTP traffic.24.NET. False positives could be identified based on source port. Only some OOS packets are inside this type of traffic.NET. rr .NET. .60. tu te .30.rules”.vip.There are 2 POP3 (110) mail servers: MY.100.NET.165. “EXPLOIT ntpdx overflow attempt”).162.NET.30. MY.There are 3 HTTPS (443) Web servers: MY.3.NET.NET. In sti .yahoo.NET. MY.75 and MY. Finally.12. mainly located in MY.NET. only the hosts receiving this traffic would be NTP servers.NET.There are lots of Windows systems generating traffic from port 137.GCIA ´ .150. Author retains full rights.NET. all generated by MY. The originators are dynamic IP addresses or streaming servers (lwmod20.20.NET.dal.33. © SA NS .153 nets. MY. MY.X contain lots of servers accessible from Internet.com).6 and MY. MY.7 and MY. MY.83.NET.

there are 50 different alert types.Criticality: detects that belong to activities that show signs of compromised systems will be analyzed.ext. int. Of those.rules” Priority/Category: ”Recon” References: http://www. The distribution of this traffic based on the destination system is very high. lots of different systems received this traffic (132215).2). it seems the University perimeter devices are dropping the inbound NetBIOS traffic. therefore all alerts match traffic that goes to TCP port 137. The main portion of this traffic has been generated from the following top 5 internal sources. backdoors.4.whitehats. addressed to several distinct destinations (table 3.Raul Siles . © SA NS In sti tu te 20 04 Apart from that. As part of GIAC practical repository. The events triggered make a total of 50 different non-corrupted alerts.4. but only the “External RPC call” matched one of these vulnerabilities. therefore they are false positives. a basic comparison against the SANS Top 20 vulnerabilities [TOP20] was made. The top 20 list of detects and the number of alerts. rr 77 eta ins fu ll r igh ts.int. the “U2”.1. It is important to evaluate if they belong to normal traffic.com/info/IDS177 Number src.Frequency : detects above one thousand entries will be analyzed in order to reduce the amount of IDS noise they generate and to minimize the impact of a potential dangerous detect. The detects were selected for an in depth analysis following these criteria: Author retains full rights. Due to the fact that there are no source external addresses. from 4233 different sources addressed to 136429 different destinations. /src. ho . .GCIA ´ 3. or if they are part of high rates of evil activity. that is. worms. source and destination systems and ports are shown in table 3. All other typical Windows and Unix services exploitation don’t seem to be detected in these logs..A ut © SANS Institute 2004.1 Alert #1: SMB Name Wildcard Message: ”SMB Name Wildcard” (count: 199026) SID: ”custom” Snort ruleset: ”netbios. At least a basic analysis should be made over the traffic associated to IRC.NET network addressed to thousands of external systems.. /dst.: 884/0/0/132215 (all outgoing) This alert message corresponds to normal NetBIOS name resolution traffic. 947 sources and 2421 destinations belong to the internal University network. . Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 . DDoS tools. LIST OF TOP DETECTS (ALERTS) 3. Analyzing specifically the alert information.4 List of top detects (alerts) 3. All the captured events were originated from MY. ext. This pattern used to be associated to some kind of worm random spread activities. /dst. This traffic is commonly associated to Windows networks and it allows listing the resources available for sharing in a computer.

po NIMDA .NET.running XDCC [ UMBC NIDS IRC Alert ] Possible trojaned box78 detec Raul Siles .traffic Possible trojan server activity ICMP SRC and DST outside network NMAP TCP ping! SUNRPC highport access! Null scan! High port 65535 udp .Attempt to execute cmd from campus host [ UMBC NIDS ] Internal MSBlast Infection Request External FTP to HelpDesk MY.70.Internal UDP connection to external tftp s Incomplete Packet Fragments Discarded [ UMBC NIDS IRC Alert ] Possible sdbot floodnet det EXPLOIT x86 stealth noop NETBIOS NT NULL session Key fingerprint handler DDOS shaft client to = AF19 FA27 2F94 998D FDB5 [ UMBC NIDS IRC Alert ] Possible drone command dete EXPLOIT x86 setuid 0 EXPLOIT x86 setgid 0 EXPLOIT NTPDX buffer overflow FTP DoS ftpd globbing DDOS mstream client to handler TFTP .49 Probable NMAP fingerprint attempt TFTP .GCIA ´ count # src # srcp 199026 884 102 28531 619 7325 15603 447 2697 11557 1412 4590 7126 1 1 5726 100 597 4517 26 984 3265 4 1581 3164 99 22 2006 84 688 1825 102 1 752 150 15 494 20 8 455 60 110 438 75 26 341 49 6 182 4 173 105 35 101 103 48 101 84 2 2 83 17 15 74 57 1 55 7 55 53 10 23 50 3 47 DE3D38 F8B5 06E4 A169 5 1 37 2 1 27 25 24 26 21 16 25 8 13 14 5 7 14 3 2 13 3 2 12 2 1 11 7 7 10 7 7 10 3 4 5 1 5 4 1 2 4 4 4 3 2 1 2 2 2 2 1 2 2 1 1 2 2 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 # dst 132215 959 1 936 1 1 111 1829 111 327 1498 59 25 54 79 51 3 6 1 84 27 46 2 7 12 4E46 2 6 18 20 13 1 2 3 1 7 6 5 3 2 3 3 1 2 1 1 2 2 1 1 1 # dstp 1 1 38 100 1 37 65 1 25 44 1 59 1 29 30 307 1 1 1 1 14 1 4 21 1 1 15 17 23 1 1 2 3 2 1 6 1 1 1 1 3 1 1 1 1 2 2 1 1 1 © SA © SANS Institute 2004.29 connect to 515 from outside Traffic from port 53 to port 123 External FTP to HelpDesk MY.4.External TCP connection to internal tftp s External FTP to HelpDesk MY.traffic [ UMBC NIDS IRC Alert [ IRC user /kill detected. .NET.30.53. po [ UMBC NIDS IRC Alert ] XDCC client detected attemp FTP passwd attempt [ UMBC NIDS ] External MiMail alert Back Orifice TFTP .70.3. Author retains full rights. NS In Table 3.49 to External FTP [ UMBC NIDS IRC Alert ] K\:line’d user detected.3 activity TCP SRC and DST outside network External RPC call High port 65535 tcp .NET.NET.possible Red Worm .4 activity EXPLOIT x86 NOOP connect to 515 from inside MY.NET.50 IRC evil .Internal TCP connection to external tftp s [ UMBC NIDS IRC Alert ] Possible Incoming XDCC Send TFTP .A ut ho rr eta ins fu ll r igh ts.010708-1 Attempted Sun RPC high port access HelpDesk MY.70.1: All alerts detected by the IDS As part of GIAC practical repository.Possible WinVNC .possible Red Worm . sti tu te 20 04 .External UDP connection to internal tftp s RFB .30.NET. LIST OF TOP DETECTS (ALERTS) attack SMB Name Wildcard SMB C access MY.

although this theory could be wrong because at the IP level they are not related at all between them.176 199.198 MY.150.70.109 MY. eta count 1 2 4 30 97 408 64874 115590 ins fu ll r igh ts.150.205.51 ut ho All these systems scanned different hosts and only generated this alert type.115.80.74 193. There could be two reasons for this: rr 79 © SA NS In Table 3.NET. LIST OF TOP DETECTS (ALERTS) dst 169. Apart from that.70. In Windows network this type = traffic is very common.62.150. The top external destinations don’t seem to have any relationship between them (table 3. Therefore. so for sure the traffic A169 4E46 Key fingerprint of AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4generated by and going to internal systems is discarded by the IDS.NET.197.70.3: Top destinations alert #1 Author retains full rights.150.4 shows the hosts compromised and the information summary about the evil attempts.6 count 710 878 1208 1251 1265 Table 3.153. te 20 .29. that also generated one “[UMBC NIDS IRC Alert] XDCC client detected attempt” alert.NET.2: Top sources alert #1 sti tu So it seems some internal devices are trying to access or scan Internet hosts. it was possible to discard false positives.181. Table 3.80.NET.NET. there is no traffic going to internal systems. .114.NET.NET.224 MY.29. normal Windows traffic from port 137 to port 137.Raul Siles .NET.159 MY.169 151. except MY. MY.143 198. from real evil scanning packets.198 MY.6 MY.44 MY.NET.The alert signature only matches outgoing traffic.84.The IDS sensor is placed in a border network where the traffic between internal hosts never passes through.NET.GCIA ´ src MY.NET.NET.4: Top evil sources for alert #1 Based on source port analysis.21 MY.224 is probably sharing files with 5 specific hosts.2 MY. looking for Windows fileshare resources outside.2.133 MY.150.A src MY. 04 .3).45. Correlations: © SANS Institute 2004.51 count 474 1290 3099 72063 115590 # dst 234 5 2148 13745 115582 3.NET. As part of GIAC practical repository.4.150.254. these hosts will probably contain some kind of NetBIOS scanning tool used to map wide address ranges.134.133 MY.NET. table 3.NET. .84.

. .int. LIST OF TOP DETECTS (ALERTS) Raul Siles . /src. it seems the signature has been customized and now only generates alerts for traffic coming into the local network from outside (filtered by the perimeter) and outgoing traffic going from MY.The perimeter configuration seems to be correct.org/resources/idfaq/port_137.established. so it seems some outsiders are scanning MY.4.2 Alert #2: SMB C access .A 80 ut .The eight evil talkers systems should be investigated to determine the reason why they are generating all this outbound traffic. This will help to reduce the huge IDS noise generated by it but will miss the attempts generated from inside. Author retains full rights. so it is difficult the IP source addresses have been spoofed. . 5 http://www. content: "|5c|C$|00 41 3a 00|". rev:5.ext. denying all inbound NetBIOS traffic.NET to external networks. sid:533. specifically.sans. int.GCIA practicals (refers to honor practicals): [BEAR1] [DON1] [JASO1] Based on the information provided in other practicals.: 0/619/959/0 (all incoming) te 20 © SANS Institute 2004. /dst. /dst.Other practicals recommended to reduce the amount of alerts generated limiting the signature of this traffic to match only when the source address doesn’t belong to MY.whitehats.GCIA ´ Defensive recommendations: This alert is associated to NetBIOS filesharing traffic and the event indicates an attempt to access the default administrative share C$. .4.NET trying to find open Windows shares. This traffic occurs as part of a NetBIOS TCP established session going to TCP port 139. classtype:attempted-recon.Detailed technical description about this detect 5 .reference:arachnids. the attacker can access the “C:” filesystem. The IDS sensor location compared to other IDS logs has probably been modified too.See the arachnids reference above in the summary alert table. as the ones detected here.NET. flow:to_server. 04 3.339. ext.com/info/IDS339 Number src. the C$ share associated to the typical main hard disk partition (C:). . If allowed.rules” Priority/Category: ”Recon” References: http://www. .php © SA NS alert tcp $EXTERNAL_NET any -> $HOME_NET 139 (msg:"NETBIOS SMB C$ access".) In sti Similar Snort signature: tu Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Message: ”SMB C access” (28546) SID: ”[1:533:5]” Snort ruleset: ”netbios.3. ho rr eta ins fu ll r igh ts. All detects come from external systems going to internal hosts. As part of GIAC practical repository.

Besides.51 80.4.228 count 149 1146 5088 # src 16 16 68 Table 3. Second talker only received this type of NetBIOS traffic.89. MY.147. Top external sources only generate this type of alert addressed to dozens of different systems (table 3.Although previous alert analysis (“Alert #1”) concluded that NetBIOS traffic is blocked at the perimeter level.com/archives/snort/2000-01/0220.166 received 8 “EXPLOIT x86 NOOP” alerts from 8 sources.191. . it seems that not all NetBIOS traffic is filtered. Therefore all this detects should be blocked because they are part of some scanning activities. 04 .152.42 count 236 295 663 dst MY.Thread 6 describes who and why this alert signature was created.166 MY.168. Key fingerprint = AF19detail by [WESE1] in “detect 2” 7 .50.A ut 81 As part of GIAC practical repository.NET. LIST OF TOP DETECTS (ALERTS) The source of this traffic is highly distributed around 600 systems. .NET. 06E4 A169 4E46 . rr eta ins fu ll r igh ts.html © .152.6: Top destinations alert #2 Author retains full rights. such as C$ and to advise users about the importance of reducing the number of open resources.11.See the arachnids reference above in the summary alert table.84.Therefore.169. TCP port 139 is allowed and lots of requests have been logged. src 61.Analyzed in FA27 2F94 998D FDB5 DE3D F8B5 .5).NET.70.52 MY. it would be a desired countermeasure to filter this type of incoming traffic because all these detects are part of some scanning activities.ch/itsecurity/detect2. First and third top destinations also received an “External RPC call” from 193.GCIA practicals: [DON1] .wesi. In this case.GCIA ´ 3. it is recommended to harden the Windows systems in order not to share unnecessary resources.5: Top sources alert #2 6 7 http://archives. .html http://www.NET.195 138. Correlations: © SANS Institute 2004.6).114. SA NS In sti tu Defensive recommendations: te 20 .Raul Siles .18. Table 3.Apart from that. ho All activities are targeting about a thousand hosts but have three top specific targets (table 3.neohapsis.

It is recommended to contact “Comcast” (see section 9) in order Key fingerprint = AF19 this traffic.30. /dst.: 0/447/1/0 (all incoming) This traffic corresponds to a customized event alerting about traffic going to a specific system: MY.4 activity” (15603) SID: ”custom” Snort ruleset: N/A Priority/Category: N/A References: N/A Number src.91. /dst. was analyzed in order to understand its purpose: .55.147 68. sti tu As part of GIAC practical repository.3. int.ext.MY.180 count 997 1124 2743 2933 Table 3.GCIA ´ 3.51443: Always accessed from ephemeral source ports. to evaluate the reason for FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 The traffic was mainly addressed to the previous ports.x servers and clients (524) and by Netware 6.NET. MY.54.0 offering secure Web services (HTTPS) access (51443.30.70.4. . 445.85. .A ut ho rr src 151. accessed from ephemeral source ports. Web.202 172.NET.30.30. /src. Windows services (135.4. Netware Core Protocol. dst 139 554 445 135 524 80 51443 count 6 8 17 30 1210 3901 10378 Message: ”MY.169. and all alerts addressed to it were categorized as this traffic except a specific “External RPC call” alert from 193. that is. . NCP. Several source system attempted to access this host from outside. All the traffic going to or coming from this net.X.196.int.30.NET.MY. LIST OF TOP DETECTS (ALERTS) Raul Siles .8: Top destinations ports alert #3 eta ins fu ll r igh ts.142.524: Again.NET. Author retains full rights. te Almost all traffic comes from the class-A networks 68 (7870 attempts) and 66 (2587 attempts).4 activity Table 3. but there was no activity from inside.114.3: (See also “Alert #6”) Again. © SA NS In . see the Correlations section below).4: There were no alerts generated from this system. 139) and two specific ports: 20 04 .232 68.3 Alert #3: MY.110.7: Top external sources alert #3 These ports are used by Novell Netware 5.30. no traffic was generated from this host. and all traffic correspond to the alert number #6 but two “External RPC 82 © SANS Institute 2004.19. ext.4.NET. So it seems there are systems integrating Windows and Novell services.NET.

GCIA ´ 3.X net is populated by Windows systems using ports 111.Update the target system not to contain potential vulnerabilities associated to the public Novell services running.9: Alerts to MY.com/article2/0.asp 11 http://novell2.3973. discarded later).GCIA practicals: [WESE1] .83. Besides.Netware 6.htm 10 http://www.4.82.uni-stuttgart.30. port 51443.net-burg. Interaction between Windows and Novell hosts 10 . Author retains full rights. . te 20 04 . Based on the alert information it seems the MY.html http://www. As part of GIAC practical repository. ho rr 83 eta ins attack EXPLOIT x86 NOOP External RPC call NETBIOS NT NULL session SMB C access count 86 39 1 81 fu ll r igh ts. 135 and 139 (table 3. See “Alert #8” for an analysis of this RPC traffic.Netware 6. .30.30.4.pdf 9 8 © SA NS In sti Defensive recommendations: tu .Other MY.A ut © SANS Institute 2004. LIST OF TOP DETECTS (ALERTS) Table 3. specifically from . It references the NetStorage application.Worm spreading through port 524 9 (initially considered potential traffic associated AF19 detect. http://cert.NET.0 access methods.0 Web Services Training 11 . .From the IDS perspective and trying to reduce this signature noise.67.9).169. . excluding all the normal Novell packets.70. not allowing everyone on Internet to send packets to this host.X Correlations: .The thread “Increased traffic to port 524” describes the usage of this port by Netware systems 8 .de/archive/incidents/2000/10/msg00170. Besides. it should be analyzed why so many different external hosts are accessing its services.org/y2k/102000.86. dstp 135 111 139 139 call” alerts from 193. .NET. Key fingerprint =to this FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 .sans.X hosts: there were some traffic originated in this network going to external systems triggering the “SMB Name Wildcard” alert.114.Raul Siles .30.NET. .84 and .NET.00.1157504.com/Docs/NetWare/WebServicesTraining. it would be better to focus the alert on the specific traffic the University is interested in. . there were 207 additional alerts going to different systems located in this network.extremetech.It is recommended to filter the traffic addressed to the Novell servers from the specific source systems that must access host MY. . .

The detect has associated a unique inbound pattern and both. all top source addresses are associated to systems in high-speed. /dst. classtype:shellcode-detect.10: Top external sources alert #4 Table 3. Based on other analysis it was confirmed that some of this traffic (the top destination port.) rr The packets triggering this alert come from several external addresses going to lots of different internal systems. DS and HTTP). so unlike other references below.198 count 235 366 375 ho Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 The traffic this detect is related to is mainly focused against Windows systems and its services (DCE.27.: 0/1412/936/0 (all incoming) Message: SID: ”custom” References: Number src.A ut src 216.4 Alert #4: EXPLOIT x86 NOOP ”EXPLOIT x86 NOOP” (11557) Snort ruleset: ”shellcode. Apart from that. Sometimes the assembler NOP operation is part of normal data as image files downloaded when browsing the Web (the third top destination port). classtype:shellcode-detect.ext.4.NET.rules” file) alert ip $EXTERNAL\_NET $SHELLCODE\_PORTS -> $HOME\_NET any (msg:"SHELLCODE x86 NOOP". The alert seems to match packets containing x86 NOP instructions (0x90 or 0x61) but without any additional information. int.22 24.GCIA ´ 3. dstp 80 445 135 count 785 2069 8398 Author retains full rights. LIST OF TOP DETECTS (ALERTS) Raul Siles . Similar Snort signatures: (“shellcode. All packets come from ephemeral client ports. eta ins .rules” Priority/Category: ”exploit” http://www.12. ext. sid:1394.GCIA practicals: [WESE1] [DON1] 84 © SANS Institute 2004. this traffic is not associated to responses from external Web servers. cable and dynamic ISP address pools. 135) belong to the MS Blaster worm (see “Alert #13”).com/info/IDS181 /src.6. reference:arachnids. rev:4. Chapter 2 detect 3 must be used to understand how this worm works.whitehats. depth: 128.97. such as the packet payload.94 209.181. content: "|90 90 90 90 90 90 90 90 90 90 90 90 90 90|". All packets come from ephemeral client ports. sid:648.int.11: Top internal destinations alert #4 Table 3.NET. /dst.3.168 count 412 418 764 dst MY.NET.87.12: Top destinations ports alert #4 fu ll r igh ts.15. there is not too much that can be said about the evil or benign nature of this traffic.4.95 MY. are highly distributed. content:"|61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61|".153. te 20 04 Table 3. Correlations: .103 MY. © SA NS In sti tu As part of GIAC practical repository.5. rev:6.208.232. source and destination addresses. .) alert ip $EXTERNAL\_NET $SHELLCODE\_PORTS -> $HOME\_NET any (msg:"SHELLCODE x86 NOOP". See table 3.

The destination system only appeared in this event. int. Apart from this alert. ho rr 85 Message: SID: ”custom” References: Number src. and all the alerts were distributed over the 5 days period analyzed (see figure 3.41.NET.Glenn also references the necessity of having a complete network audit trail to be able to analyze this detect 13 .: 1/0/0/1 (all outgoing) eta ins fu ll r igh ts.4.183.NET.int. These attempts could be associated to an external portscan. because this port is used by the Unix LPR service.org/practical/David_Oborn_GCIA. The attempts were addressed to MY.183.rice.3). the same alert from outside was reported 2 times: “connect to 515 from outside”.Raul Siles .110.GCIA ´ 3.rules” (sid:301.5 Alert #5: connect to 515 from inside Internal source: MY. Correlations: 12 13 http://www.74. .html © SA NS In sti tu te 20 04 . the IDS policy seems to be interested in monitoring the printing traffic (TCP port 515) through customized rules.242 is an external printer server used by the internal host. they define vulnerabilities over the LPD implementations.60. ”connect to 515 from inside” (7126) Snort ruleset: N/A Priority/Category: N/A N/A /src. as source or destination.14 from 64.edu/~glratt/practical/Glenn_Larratt_GCIA.Technical analysis of this type of alert 12 .See the arachnids reference above in the summary alert table.44 and MY.209. Defensive recommendations: Author retains full rights. Besides.The packets generating this detect should be analyzed in order to classify them as a false positives or as the exploitation of a specific vulnerability.ext.41 External destination: 128. /dst. As part of GIAC practical repository.162. probably a buffer-overflow due to the usage of assembler code (NOPs).giac.229.162. MY.242 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 At first sight it seems that 128. ext. 3.A ut Similar Snort signatures: There are only 3 rules in “exploit.110. The source port used is always TCP 721. © SANS Institute 2004. Analyzing the activities associated to both systems it was confirmed that there were only 4 “SMB Name Wildcard” alerts from the same source and a few “EXPLOIT x86 NOOP” (3) and “SMB C access” (4) addressed to it.4.24. . . LIST OF TOP DETECTS (ALERTS) . /dst.NET. 302 and 1821) related with port 515 but none of them seems to be related with this event. .html#detect4 http://is.NET.

com/mirror/bucket/Brian_Coyle_GCIA. . 20 © SANS Institute 2004.mitre.If the remote printing traffic must be controlled.linuxwidows.Glenn analyzed this detect. Author retains full rights.org/cgi-bin/cvekey.cve.3: Distribution of alert #5 eta ins fu ll r igh ts. LPD/LPR. summarizing that it belongs to internal printing traffic 14 .mitre.A 86 ut ho rr Figure 3.pdf © SA . due to the fact that it is not common to make use of printers out of the local networks. As part of GIAC practical repository.There have been several vulnerabilities associated to this service.cgi?keyword=lpr 17 http://www.org/cgi-bin/cvekey.Brian stated this detect as valid traffic and even generated a link graph for it 17 . . it would be better to block these packets at the perimeter firewalls/routers.4.rice. if any.It is recommended to make use of more specific IDS rules that show the type of LPR vulnerability that someone is trying to exploit. NS In sti tu te . . Key the past. 04 .html http://www. not allowing them to cross the network boundaries in any direction (inside or outside).edu/~glratt/practical/Glenn_Larratt_GCIA.GIAC practicals: [BEAR1] [JASO1] [DON1] .cgi?keyword=lpd 16 http://www. LIST OF TOP DETECTS (ALERTS) Raul Siles .GCIA ´ Defensive recommendations: 14 15 http://is.cve.3. Searching in the CVE databaseDE3D F8B5 06E4 A169 4E46 . in fingerprint = AF19 FA27 2F94 998D FDB5 15 and 16 .

© SA NS In sti 3.4. Top talker. /dst. trying to detect spoofed packets or missconfigured devices consuming network resources. See also “Alert #3” for a deep analysis of this event. /dst. src 68.27.NET. /dst. non-resolvable.146 count 639 735 1224 count 12 17 28 5607 Table 3. int.4.51 68.int.244. don’t belong to MY. int.A ut ho eta ins Table 3.4.30.56 to 211.3 activity fu ll r igh ts. Most traffic were addressed to ports 21 (FTP control channel) and 996 (vsinet or Xtree License Server) (see table 3.ext.NET.3 activity” (5726) SID: ”custom” Snort ruleset: N/A Priority/Category: N/A References: N/A Number src. Other Windows typical traffic has been also observed so it seems it represent normal Novell behaviour.NET.254.124. /dst.55. 18 19 (*) From 169.16.7 Alert #7: TCP SRC and DST outside network tu As part of GIAC practical repository.17 18 19 ).14: Top destinations ports alert #6 Author retains full rights. 20 04 . Most traffic comes from subnets of the class-A network 68 (4305 alerts) belonging to “Comcast” (see section 9). This time no Novell HTTPs traffic was captured.56 to 218.131 (2854 times) © SANS Institute 2004. /src. te As in “Alert #3”. almost all traffic correspond to TCP port 524.: 0/26/0/111 (all external) This alert is detected when both addresses.int.144.91. related with Novell systems.Raul Siles . .57.254. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Correlations: See “Alert #3”. dstp 445 80 135 524 Message: ”MY.90.55. ext.72 (1420 times) (**) From 169. the top source talker.ext.GCIA ´ 3. Both services were accessed from sequential ephemeral/client ports originated from the same system.30. Traffic go to two.244. As mentioned in “Alert #3” this system also received two “External RPC call” alerts.6 Alert #6: MY. Defensive recommendations: See “Alert #3”. LIST OF TOP DETECTS (ALERTS) 3. /src.13: Top external sources alert #6 rr 87 Message: ”TCP SRC and DST outside network” (4517) SID: ”custom” Snort ruleset: N/A Priority/Category: ”spoofing” References: N/A Number src.233. source and destination. different systems.: 0/100/1/0 (all incoming) All traffic associated to this event comes from one hundred external systems going to an specific address.157 68. ext.

4.X and 192. 169. unable to successfully negotiate a DHCP lease.144.168.55. as I did above.131 count 14 42 1420 2854 Raul Siles .0.X. These source hosts are registered by “Comcast” (see section 9).0.91. mainly Windows. There is another possibility associated to this type of traffic: if the University staff and students have home access through Comcast. also generated 5 packets going to port 21 to two different external hosts. and most other traffic belong to [RFC1918] private addresses.X. SA NS In sti tu te Table 3. some additional packets belong to some networks starting with 68. Author retains full rights.55.89. related with specific traffic directed to some internal Novell Netware hosts.254.16: Top external destinations alert #7 Table 3.18: Comcast sources in alert #7 20 src count 68. rr 88 © SANS Institute 2004. . However.56.36 FDB5 DE3D 2F94 998D 68. It is possible that these networks belong to the University infrastructure.55.16.220 1 68.64 169.0/16.X.0.66.18).56 count 42 78 4279 dstp 80 996 21 count 68 (*) 1420 (**) 2860 Table 3.254. .108. eta ins F8B5 06E4 A169 4E46 fu ll r igh ts. LIST OF TOP DETECTS (ALERTS) dst 63.Glenn also analyzed the different networks involved. it is possible they connect their home systems to the University network using the Comcast configuration addresses.64 78 04 . as the method used by Windows systems to generate its own DHCP address (described above). This fact must be checked with the network administrators.48.254.244.55 and 68.244. The IP address range. networks 10.55.61.55. corresponds to systems.1. Both belong to “Comcast Cable Communications” (see table 3.8 3 4 FA27 68.253 211. As part of GIAC practical repository.A ut ho 169.72 218.12 68.15: Top external sources alert #7 Table 3.GCIA ´ src 10.48.0. mainly 68. and he © This network was analyzed in “Alert #3 and #6”.50.211. In this case most traffic belong to an IP address associated to this DHCP automatic Windows range.X.17: Top destinations ports alert #7 Key fingerprint = AF19 Correlations: . Automatic Private Internet Protocol Addressing. so the company should be contacted in order to figure out why its traffic is crossing the internal network. This activity corresponds to the 94% of this detect.3.115 68. This situation associated to the nowadays mobility world is very common.GCIA practicals: [DON1] Don defined the term APIPA.124.

they should be at least applied on the perimeter devices. Iceland and 2 different USA states. probably this is the reason why the top talker couldn’t get a DHCP lease.4. being two of them the main top talkers. Message: ”External RPC call” (3265) Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 ”exploit” SID: ”custom” Snort ruleset: ”rpc.rules” Priority/Category: References: N/A Number src. Therefore anti-spoofing filters should be enforced in all network boundaries. concluding that most of the traffic comes from AOL source addresses.NET. The RPC scanning has been a common source of attack. These systems scanned lots of internal hosts probably trying to find a specific RPC vulnerability. The wide destination address range (the most used destination address only appeared 18 times) hit by these packets confirms the scanning activity mentioned. The alerts originated only in 4 external hosts. or probably the host with this IP address is missconfigured. blocking internal packets originated from a network different from MY.8 Alert #8: External RPC call ut © SANS Institute 2004. If this is not possible at first instance.A 3. .NET. change the configuration of the systems generating the traffic.Michael also analyzed it. If so. . int. Defensive recommendations: . If not. Author retains full rights. ext.4. to block external packets with a source IP address of MY. /dst. .There is no reason why traffic coming from and addressed to external networks should pass through the University network. /src. This fact is ratified by the different set of source port numbers used. As part of GIAC practical repository. ingress. the RPC portmapper.html http://www.edu/~glratt/practical/Glenn_Larratt_GCIA.GCIA ´ 3.ext. and egress. not as in this case 21 .rice.giac.Check if some networks use [RFC1918] address spaces.org/practical/michael_wilkinson_gcia. LIST OF TOP DETECTS (ALERTS) also found AOL source addresses 20 . ho rr 89 eta ins fu ll r igh ts. /dst. that is. The attacks are coming from service providers all around the globe: UK (Europe).int. all ephemeral. . The public registration information about these 4 systems was analyzed in section 9. 1581 distinct ports.Check if the DHCP servers are working properly. .: 0/4/1829/0 (all incoming) This RPC traffic goes to port 111. listed under the “Top 20 vulnerabilities” list [TOP20]. tune the IDS in accordance to avoid false positive alerts. a service that maps RPC service names with the corresponding TCP/UDP ports. 20 21 http://is.doc © SA NS In sti tu te 20 04 .Raul Siles .Two types of filters must be used.

229 Possible trojan server activity MY. The previous RPC assumption about events along time is confirmed: MY. The difference between these sources is that 166. NTP and Back Orifice.229 TFTP .74.alltel. server responses from services like 22 (ssh).NET.44 MY.GCIA ´ src 64.60.669023 10/22-19:04:55.209.4..19 ). This high port attempts are subject to false positives.209.NET.229 81.704936 10/22-19:03:29. I found two suspicious packets coming from port 7 (echo) from 202.99.209. This is the only traffic of this type in all alert files.net Non-resolvable Non-resolvable te 20 04 .NET.44 MY. As part of GIAC practical repository.229 MY. This situation typically indicates that the initial “External RPC call” was succesful and the Unix server replied with the requested information.209.6.NET. The top source scanned hosts involved in other alerts.705012 10/22-19:03:30.243 going to MY.229 SUNRPC highport access! 64.24.209. as a consequence.74.333135 connect to 515 from outside 64. so more dangerous) while the other systems launched noisy scans from several ephemeral ports.24. 1912 1912 69 1912 1912 2291 27374 2291 The typical RPC attack is based on scanning the RPC portmapper for information and then. There were some of these events coming from low ports.28. This type of alert was also captured.209.229 MY.74.9 MY. It seems this host is scanning for specific vulnerabilities: RPC.99. 25 (smtp).44 MY. only the source host 64.44 64.74.332634 10/22-19:05:00.171303 10/22-19:03:29.43.NET. based on the data acquisition. because several client services use the same port number. 494 times. 80 (http).166.44 External RPC call 64.19: Top external sources alert #8 Table 3. Correlating the first high port alert with the alert analyzed here.14 515 69 1912 111 3277 111 2291 515 eta ins dst MY.ip.NET.209.74.External TCP connection to int MY. or “Attempted Sun RPC high port access”. such as MY.NET. src scans 1363 0 284 19164 SA NS In count 2 7 420 2836 sti tu resolution Non-resolvable h229.99. The echo port was used to simulate valid responses.74.387312 10/22-19:05:00.97. 443Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 (https) and 53 (DNS).60.15 MY. received some responses to the stimulus.229 166.NET.3 and .45. scan high RPC ports.209.NET.4.15.102. LIST OF TOP DETECTS (ALERTS) Raul Siles .74.14 64.102.NET.229 fu ll r igh ts. With the goal of confirming the scanning activities associated to this alert the number of scans from this 4 source addresses were obtained (see table 3.24.24.External TCP connection to int 64.14 connect to 515 from outside 64.70. It seems clear it is scanning the network and.169 © None of the second high port RPC alert come from one of the four sources analyzed neither they match with the first high port RPC alert sources.74.NET.65 count 6 8 18 Table 3.60.NET.229 External RPC call 64. .209.229 generated specific packets from port 111 to port 111 (not detected as scans.NET. found 10 times.180169 10/22-19:03:31..209.A ut ho rr .114.102.31:32771.30. such as “SUNRPC highport access”.20: Top internal destinations alert #8 90 © SANS Institute 2004.229 generated it.3.24.1 193.74. 10/22-19:03:29.39.229 TFTP .74. Author retains full rights.24.

also called Adore Worm.Al analyzed it 22 . The worm tries to exploit old vulnerabilities associated to 4 Linux services: wuftpd. He described some of the different RPC services that are typically published through the portmapper. and that there were other LPD alerts analyzed (see “Alert #5”).66.21: Top int. 22 23 www.13.153.80. /dst.Raul Siles .traffic” (3164) Snort ruleset: N/A Priority/Category: ”backdoor” see Correlations section for antivirus /src. sources and int.int.116 202. is a specific Linux trojan that listen on the top port.86.Shutdown all unneeded RPC services and patch those that must be running.44 MY. .157 13 15 283 1022 MY.116 202. correlation between both was developed.NET. ”High port 65535 tcp . No relationship was found.NET.: 40/59/42/69) ut ho rr 3.156. 65535. where both.ext.pdf http://www.ca/main/members/Herc_Man/Files/Al_Williams_GCIAPractical. bind.NET. Initially. Table 3. and if it has success.254.10.71.Mark described this attack and also associate it the importance of real reconnaissance activity 23 . Due to the fact that the LPD service can be a method for this worm to infect a system.53.4.153. ins fu ll r igh ts.156.92 200. LIST OF TOP DETECTS (ALERTS) Defensive recommendations: int src count ext src count int dst count ext dst Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 MY. As part of GIAC practical repository.68 66.NET.possible Red Worm .NET infection.GCIA practicals: [DON1] [JASO1] .96.20 MY.NET. & ext.141 MY. so this detect is a potential sign of have been compromised. internal and external systems are trying to infect several targets that belong to any network.NET.157 04 . Author retains full rights.A Message: SID: ”custom” References: Number src. allowing the access only to systems with a trust relationship.153.105 15 17 268 1022 198.NET.traffic eta . Typically.4.44 MY.105 23 24 309 1112 198. . He also correlated the information between both RPC alerts analyzed.NET.86.doc © SA NS In sti tu te count 18 23 320 1112 20 91 © SANS Institute 2004.80.254. ext.96.giac. . lprng.94 MY. no other services (except client ephemeral ports) use this port.71.13. destinations alert #9 The Red Worm. int.possible Red Worm . this services should only be accessed by internal host and it is recommended to filter based on IP address.24.Block the portmapper port as well as other high ports associated to the real RPC services. opens a backdoor in the affected system.10.whitehats.66.141 MY. & ext.92 200.GCIA ´ Correlations: 3. . or statd. /dst.68 66.24.9 Alert #9: High port 65535 tcp . It seems there is a wide MY.org/practical/Mark_Menke_GCIA.

20 65535 12.543787 High port 65535 tcp .NET.837566 High port 65535 tcp .GCIA ´ There is another alert. such as.24. this host never generated the TCP alert against the mentioned target.From the top internal sources. again.92. only MY.164. Worm description in Spanish http://www.24. 66. .164. .71.136. .71.543802 High port 65535 tcp . that appeared 438 times.24. related to the UDP protocol.188 25 10/22-14:41:07.symantec.164..NET.165329 High port 65535 tcp .NET.136.66.12.80. Technical description of the Adore worm http://www.NET. “High port 65535 udp .165493 High port 65535 tcp ..NET.164.com/avcenter/venc/data/linux.edu/~glratt/practical/Glenn_Larratt_GCIA.164. . 4E46 Author retains full rights.3.136.NET.MY.uk/News/1120176.136.92 is the most common system.20 65535 12.NET.66.MY.20 65535 12. HTTPS or SMTP. it was point out from MY.71.com/adore.80.164.24.188 25 10/22-14:41:12. a portion of a SMTP session is showed: . Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 10/22-14:41:07.MY. As in the next alert. fu ll r igh ts. All UDP traffic always goes to 66.136.164.629854 High port 65535 tcp .NET.vsantivirus.20 65535 10/22-14:41:07.MY.html http://securityresponse. As part of GIAC practical repository.worm.html © SA NS In sti tu te 20 92 © SANS Institute 2004.153.66.71.105 appeared.4. almost the same top sources and destinations were repeated. MY.136.20 65535 12. 66. Adore Worm in the press http://www.136.24.htm. Defensive recommendations: 24 25 http://is.164. However. to and from ephemeral ports. The worm is only associated to TCP. HTTP.188 25 10/22-14:41:11.itweek.188 25 MY.66.adore.12.20 65535 12.From the top internal destinations.136.A ut ho rr eta ins Correlations: - GCIA practicals: [DON1] [JASO1] [LES1] Glenn also covered both alerts 24 .NET.From the top external sources.NET.htm.co.188 25 10/22-14:41:07. POP3. all them addressed to one of the top external destinations.org/y2k/adore. so these hosts were involved in sending and receiving traffic from port 65535.MY.From the top external destinations.141.92 was also involved in UDP traffic: as source it always used source port 65535 and as destination it always used destination port 65535.94 and 153.24.24. 66. . Some false positives were detected when clients used 65535 (ephemeral port) as the source port for accessing other services.MY. Symantec description 25 .rice.188 25 MY.105 generated this UDP alert 4 times.traffic”. again.188 25 10/22-14:41:12.20 65535 12.188 25 04 . LIST OF TOP DETECTS (ALERTS) Raul Siles .sans.possible Red Worm .20 65535 10/22-14:41:12.161467 High port 65535 tcp . Generally speaking.24.482664 High port 65535 tcp .92 from port 2740.NET.

100 200. .NET. This theory will be confirmed when analyzing the ports involved in the alerts.249 ext dst 200.NET. int.163.6 MY.163.61. such as. Due to the very generic nature of this alert message.121. LIST OF TOP DETECTS (ALERTS) Key fingerprint = AF19 FA27 2F94 998D FDB5and int.NET. destinations alert #10 Table 3.146.100 64.34 MY. ”backdoor” int dst MY.61.Raul Siles .6 MY.105. FTP.31 66.23: Top destination ports alert #10 © SA Table 3. sources DE3D F8B5 06E4 A169 4E46 The same top systems are involved as source and destinations.24: Top source ports alert #10 It was checked that the alert was triggered when port 27374 appears as source or destination.rules” Priority/Category: http://www. LPD or statd.NET.10 Alert #10: Possible trojan server activity fu ll r igh ts.141.163. /dst.whitehats. .NET.int. ”Possible trojan server activity” (2006) Snort ruleset: ”backdoor. internal and external (see table 3.23 and table 3. As part of GIAC practical repository.: 25/59/277/50 eta ins 3.4.146.4.130 200.169.41.It is not recommended to filter the traffic addressed to port 65535.24.74 MY.NET.24. .175 count 10 15 18 402 ut srcp 25 443 80 6667 27374 count 21 24 69 409 727 # dst 2 5 23 2 34 Table 3.GCIA ´ 3. There are 1279 where it appears as destination and 727 where it 93 © SANS Institute 2004.24.NET. the ports that are originating and being targeted must be analyzed (see table 3.249 count 15 21 25 409 ext src 67. & ext. it is a must to patch all Linux systems (all Linux distribution provided fixes) referenced in this alert and all other Linux systems inside MY. TCP and UDP.12.127.NET.22).234 66.12.163.95. ext.ext. This pattern is commonly associated to conversations between them.183. DNS.The infected hosts must be investigated and the trojan binaries associated to the worm removed. at the perimeter because there is a special reason to allow it: some client hosts can use it as an ephemeral port. Author retains full rights.NET.To avoid the same compromise in the future.22: Top int.34 MY.169. count 14 21 29 560 . & ext. NS dstp 443 25 80 6667 27374 In sti count 25 29 66 561 1279 tu te 20 # src 5 2 29 3 31 04 . /dst.74 212.30. See the Correlations section for instruction to do so.com/info/IDS279 /src.175 count 63 71 303 553 ho rr Message: SID: ”custom” References: Number src.74 MY.24).24.A int src MY. Instead it is recommended to filter other unneeded vulnerable services that allow the worm expansion.

NET.41.130 MY. associated to the SubSeven trojan that runs on Windows.25 and table 3.41.41.130 MY.130 64. dstp 443 25 80 6667 count 25 29 66 560 MY.41.25: Traffic going to 27374 comes from ho srcp 25 443 80 6667 count 21 24 69 409 ins 27374 25 25 27374 27374 27374 27374 25 is the source port.130 25 27374 27374 25 25 25 25 27374 Author retains full rights. .Host MY.6 MY.12.6 MY.6 64. © SA NS . port 27374 is associated to SubSeven version 2. Table 3..211.6 64.146.Host MY.183.NET. . Checking when this port has been used as a source port and accessing what service can help in determining real event of interest.26).183. fu ll r igh ts.169.NET. The analysis concludes that some hosts were probably compromised: . This ephemeral traffic is the one that must be analyzed looking for evil packets. Some of these alerts are false4E46 associated to clients using source port 27374 when accessing other services.100.41.106 received lot of traffic to port 27374 from: 24.35.Host MY.12.6 rr eta In sti As part of GIAC practical repository.GCIA ´ All other activities are mainly based on ephemeral ports.10.NET.149.211883 10/22-15:50:48.A ut Table 3.NET.127.130 64. Apart from that.2 received lot of traffic to port 27374 from: 212.NET. It is a Remote Administration Tool that allows an attacker to have complete control over the victim system.41.211296 10/22-15:50:39. 94 © SANS Institute 2004.130 64.6 MY.6 64.16. the top source and destination ports are the same.183.16. LIST OF TOP DETECTS (ALERTS) Raul Siles .95.183. Due to the fact that this is a possible ephemeral/client port.26: Traffic coming from 27374 goes to 64.64.41.135.956792 10/22-15:51:02.12.190.680183 10/22-15:50:55.183.12.12. the portion of a session is showed: server server server server server server server server 20 04 activity activity activity activity activity activity activity activity .105.611793 10/22-15:51:23.6 MY. not only SubSeven but Ramen or Lion. based on the old Netbus trojan.NET.678433 Possible Possible Possible Possible Possible Possible Possible Possible trojan trojan trojan trojan trojan trojan trojan trojan tu te Almost all conversations seem to be from the analyzed port to some common Key (see table AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 positives servicesfingerprint =3.601697 10/22-15:51:23.143. false positives must be discarded.192.NET.69. The most accessed port is 27374. . IRC or SMTP.NET..12.190.33.31.NET. This tool associates the 27374 port to several different trojans. like HTTP.1 received lot of traffic to port 27374 from: 66.114 received lot of traffic to port 27374 from: 67. Specifically.248 and 24.121. 10/22-15:50:39.199.4. .183. 67.130 MY. The “Treachery Port Lookup Utility” [TREA1] is very helpful in determining port to software associations.611643 10/22-15:51:02.1. As an example.130 64.Host MY.NET.41.12.183. HTTPS.183.74 and 24.12.NET.3.

. The top source networks were various class-B 172 subnets. . A network classification has been made based on the source information (see table 3. Doug also asked for the ruleset used to log these detects in order to know why this alert was triggered and identify a compromised host and built a link graph around it 28 .GCIA ´ Correlations: - 3.org/subseven/ 31 http://www. SubSeven technical analysis 27 . http://is. /src. ext. America OnLine 31 : 172.NET.4. is not involved in the source or the destination addresses.html http://www. some network defined in [RFC1918] were logged.30).Raul Siles .128. . It references the Treachery tool used above. .com 27 26 © SA NS In sti tu te 20 04 . /dst. Author retains full rights.int.php 28 http://www. ut © SANS Institute 2004. in this way all the trojan commands will be captured.ext. To do so alert only when destination port is 27374. This address range is associated to AOL. int. not belonging to RFC1918.pdf 30 http://www.hackfix.SubSeven information 30 .4. . /dst. All ICMP alerts captured by the IDS sensor are represented in this event. 29 .rice.0 .255.0.172.191.255. As part of GIAC practical repository.A filtering improvement cannot be applied due to the ephemeral nature of the port number.It is recommended to improve the IDS signature to filter the noise produced by the usage of port 27374 as an ephemeral port. again. The ICMP protocol is involved here and.giac.11 Alert #11: ICMP SRC and DST outsideA169 4E46 fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 network Message: ”ICMP SRC and DST outside network” (1825) SID: ”custom” Snort ruleset: N/A Priority/Category: ”spoofing” References: N/A Number src.aol.Remove the trojan on all compromised systems based on the instruction provided in the Correlations section documents. ho rr 95 eta ins Defensive recommendations: fu ll r igh ts. LIST OF TOP DETECTS (ALERTS) Key3.The same detect was researched by Al.org/practical/GCIA/Doug_Kite_GCIA.sans.A .edu/~glratt/practical/Glenn_Larratt_GCIA.: 0/102/0/1498 (all external) As in “Alert #7” this detect is generated when the local net. GCIA practicals: [JASO1] [LES1] [BEAR1] [DON1] This detect is analyzed including its relationship with port 27374 26 .whitehats. MY.org/resources/idfaq/subseven.ca/main/members/Herc_Man/Files/Al_Williams_GCIAPractical.pdf 29 www.

and in case it is coming from this company.203.com ACABD88A.GCIA ´ dstp 211. such as “Alert #7” (see its Correlations section).org/practical/esperanza_lopez-wilkin_gcia.ipt.4.0.3 activity TCP SRC and DST outside network EXPLOIT x86 NOOP MY.138.3.168.30.168.203 192. attack High port 65535 udp . there were other detects considered interesting. The same anti-spoofing mechanisms must be used at the IP level.29: AOL addresses alerts ut 96 ho rr Table 3.possible Red Worm .28: Top external destinations alert #11 It was checked that there are lots of different alerts (not ICMP) were systems belonging to the AOL address range take a role (source or destination) (see table 3. tu te 20 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Correlations: © SANS Institute 2004.Esperanza found the same behaviour in her practical 32 .29).195.4.150.com Non-resolvable Table 3.2 211.ipt. .27: Top external sources alert #11 Table 3. they must be contacted trying to reduce the number of these “missing” packets. 3.A Table 3.211.aol. Author retains full rights.aol.The reason for the AOL traffic must be researched.30: Source networks for alert #11 fu ll r igh ts.The AOL traffic was analyzed in other papers when generating TCP alerts.168.235 count 98 98 129 resolution AC8A2825.212 count 17 55 82 129 srcp 172.37 172.NET. net 68 192.traffic Possible trojan server activity MY. 04 .doc © SA NS In sti .0. As part of GIAC practical repository. It is a must to determine the nature of this traffic. so independently of the protocol used: ICMP.4 activity SMB Name Wildcard count 3 10 14 18 163 1267 3049 eta ins src.216. TCP or UDP.giac.0 172 count 63 283 1474 Defensive recommendations: . 32 http://www.67 211.30.138 192.150.See “Alert #7”.171. LIST OF TOP DETECTS (ALERTS) Raul Siles . This and next sections focus on them.40.150.NET. .12 Alert #12: All different IRC alerts Apart from the top events. .

MY.82.NET.NET.NET.42.219 and MY.[12] From port 6667: “[UMBC NIDS IRC Alert] Possible Incoming XDCC Send Request Detected.. Some GCIA honor practicals focused on these IRC events: SA NS In sti tu .80.NET. although they are not in the SANS Top 20 list [TOP20].NET.” (dst: MY. possible trojan. As part of GIAC practical repository.163.NET.153. at least it should be checked if they follow the University policy that seems to contain statement about the IRC traffic controls and restrictions because most IRC alerts have been customized using the string ‘‘[UMBC NIDS IRC Alert]’’. © All the referenced hosts involved in the IRC activities should be investigated because they probably have been compromised. Internet Relay Chat. Due to the fact that the IRC. possible trojan.163. MY.[341] From port 6667: “[UMBC NIDS IRC Alert] IRC user /kill detected. MY. .4.GCIA ´ 3.156 and MY. This section contains the specific IRC alerts addressed to external systems from MY.150.153. .NET.236) .NET.149.NET.NET.NET.97.80.149.195. MY.135.NET.X.81.NET. MY. protocol is being used nowadays as a communication channel for lots of trojan and DoS applications.) and from server to client (From port .126.NET. The number of alerts has been included between brackets.NET.91.” (dst’s: host placed mainly in MY. MY.21. 6664.97.151.[182] To port 6667: “[UMBC NIDS IRC Alert] XDCC client detected attempting to IRC” (src’s: MY.[LES1] covered “IRC evil .97. ho rr 97 eta ins fu ll r igh ts. If this is not the case.[55] To ports 6663..NET.Raul Siles .NET. Author retains full rights. MY.249) Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 .29.NET.15.198.174.NET.79) .72) .97.97.” (dst’s: MY..NET. MY.running XDCC” (src: MY.[1] To port 6667: “[UMBC NIDS IRC Alert] Possible trojaned box detected attempting to IRC” (src: MY.running XDCC”.NET.18) .NET.[4] From ports 6969 and 6883: “[UMBC NIDS IRC Alert] K\:line’d user detected.).80.NET.” (dst’s: MY. 6666 and 6667: “[UMBC NIDS IRC Alert] Possible sdbot floodnet detected attempting to IRC” (src’s: MY. MY.194 and MY.16 and MY.[37] From port 6667: “[UMBC NIDS IRC Alert] Possible drone command detected.[DON1] analyzed several of these IRC alerts.2.NET from client to server (To port . MY. 60 and 97) te 20 04 .249.97. One of the top networks managing IRC traffic is MY.5) .69.97.A ut © SANS Institute 2004. it is interesting to analyze all the distinct IRC alerts generated.133) .[1] To port 6666: “IRC evil . LIST OF TOP DETECTS (ALERTS) .NET. MY.42.97..

This time the alert was “NIMDA .211.249 4444 212. .241.level3.4.NET.163. .163.Alert “[UMBC NIDS] External MiMail alert” appeared 103 times from about 50 different sources against 1 specific host.Attempt to execute cmd from campus host” [LES1].html © SA NS In sti tu te 20 © SANS Institute 2004.NET.70.rules”: sid:247 and sid:249.Two host are infected with the MS Blaster worm (analyzed in Chapter 2 detect 3): MY.Back Orifice traffic. four additional hosts potentially infected by the Nimda worm were detected: MY. . LIST OF TOP DETECTS (ALERTS) Raul Siles . that spreads via e-mail and exploits 2 distinct Windows vulnerabilities.19 (a suspicious Web server) to the same internal host.There is a compromised host receiving control connections from a DDoS tool.NET. 04 .NET.150 and MY. 12 times and one time from 61. They reflect a compromise.6.13 Alert #13 and beyond: Other relevant alerts This section include all other alerts not relevant by their total number of entries but that were selected for a fast analysis because they suggest some kind of investigation over the internal systems involved on them.X. First rule (to port 12754) was reported from 63.symantec.75.249 and MY. The alert generated was “[UMBC NIDS] Internal MSBlast Infection Request”.NET. .249 135 10/22-19:03:38.NET. some kind of worm infection or DDoS agent running. a well known Windows trojan software [BO1]. and port 25. addressed mainly to net MY.NET.97. The specific packet payloads triggering this alert should be analyzed in order to discard false positives because this host received lot of SMTP connection as well as other scans.GCIA ´ 3.net) to MY.a@mm.195.218. The activity is associated to the MiMail worm.163.81.4.A 98 ut ho rr eta ins fu ll r igh ts.84.130.176.218.714721 [UMBC NIDS] Internal MSBlast Inf MY.NET.97. This system must be investigated because it can just be a Windows host 33 http://securityresponse. As part of GIAC practical repository.153. Author retains full rights. More information about the worm and how to remove it is located at 33 .190.In the same way.50 2066 Lots of attempts to exploit this Windows RPC vulnerability were captured as “EXPLOIT x86 NOOP” alerts (see “Alert #4”).12. MY. .81. In this case all them seem to be false positives Key fingerprintother traffic at 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 because no = AF19 FA27 all was captured.115 (it is a Web server: http://unknown. .235.50 1753 MY.NET. This was confirmed by the fact that a previous exploit was launched against the RPC service in both cases: 10/22-19:03:38. MY.010514 EXPLOIT x86 NOOP 212. “mstream”. The message was “DDOS mstream client to handler” and corresponds to 2 different standard Snort rules from “ddos.NET.NET.103.com/avcenter/venc/data/w32. MY.228.mimail.66.3.

.154.5. In both DDoS alerts.NET.html © SA NS In Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 All them correspond to Snort “shellcode.180.225.154. 650 and 651. All the external hosts have suspicious Web servers where directory listing is denied or the GET method is not implemented. . “mstream” and “shaft”. Further investigation is required. “shaft”.84.85.rules” signatures: 649.114.216. As part of GIAC practical repository.NET. 211.46.223. The top target system for all them is MY. referred as “spp portscan” due to the Snort preprocessor (spp) that generate them.GCIA ´ 3.5 List of portscan alerts The same alert files contain a set of different events that correspond to portscan activities. 34 35 http://bitconjurer.223. Author retains full rights.163 and it’s being contacted from 209. First host is MY. trying to simulate Web server responses for real attacks. not a very common situation. some of those correspond to the MS Blaster worm scans. 211.145.24.119.196. The same number of internal sources was reported when analyzing the scan files.rules” signature reported is “DDOS shaft client to handler”. Second host is MY.99 and 61. Second rule (to port 15104) was reported one time from 68. a P2P solution 35 .netsys. The Snort “ddos.A ut 99 © SANS Institute 2004.185. so the information is coherent. associated to BitTorrent 34 .34.NET.Again.33. two host were identified as compromised receiving communications from a new DDoS tool.Raul Siles . LIST OF PORTSCAN ALERTS 3.84. and others go to port 6881. As mentioned before.60. so it should be investigated. sid:230.NET.org/BitTorrent/ http://lists.55. All traffic exchanged between these two systems goes from and to ephemeral ports. sti tu te 20 04 1 EXPLOIT x86 stealth noop 2 EXPLOIT x86 setuid 0 3 EXPLOIT x86 setgid 0 . ho browsing the Web or a compromised system (it received lot of traffic to some vulnerable Windows services ports). given the fact that this internal host seems to be a web server.com/pipermail/full-disclosure/2003-September/010932. The alert portscan data reported 1114145 events and these were launched from 4724 different sources where 310 of them belong to the internal network.235 and it is being contacted from 4 different sources: 207. the traffic comes from TCP port 80.There were 3 different and not very frequent exploit alerts reported: rr eta ins fu ll r igh ts.188 to MY. The internal host was analyzed in the previous alert.10 (a default iPlanet Web server). .

Author retains full rights.196.NET.70.72 20920 MY. combining type and flags. 5 UDP scans to 5 hosts: fu ll r igh ts.94 16876 MY.140.NET. it seems that there were about 118000 different portscan “attacks” from over 4710 distinct sources. There were 140 different scans.114.NET.16. ho Table 3.84.111. The top talkers all correspond to internal addresses (see table 3.31 contains the different portscan reports notified.121.NET.5 23943 MY.3.154 76081 MY.163 808 158.149.31: Total portscans captured 10/19-00:17:01. © SA As part of GIAC practical repository.163.NET. UDP(5) Key src count MY.1. As a conclusion. the analysis has been developed using statistical processes.1 15485 MY.NET.174.66 902 212.34. and discarding the differences produced by the corrupted entries in the original log files. and the top 20 scan types are in table 3.98.32).180.61 776 eta ins From this information.32: Top source portscan talkers NS In sti tu te 20 04 998D FDB5 3.NET.33: Top external source portscan talkers rr src count 63.3 5 connections across 5 hosts: TCP(0). The top internal source portscanner hosts match with the ones obtained from the scan logs.NET.1.249 69350 MY.NET. so will be analyzed in the next section.203.3 200840 fingerprint = AF19117572 2F94 FA27 MY.110.111.68 217.A ut The portscans logs only provide information about the source address.70.42.0. LIST OF TOP SCANS Raul Siles . the number of each type and the different number of source systems that generate them. such as.195.70.129 13822 .163.10 5116 DE3D193. .6.GCIA ´ Table 3. attack spp portscan: End of portscan spp portscan: PORTSCAN DETECTED spp portscan: portscan status count 115979 118308 879858 # src 4701 4723 4718 Table 3.1.NET.250.145 1062 195.66.193. 100 © SANS Institute 2004.107 111670 MY. The “portscan status” events summarize a set of scan packets within a portscan attack.271722 spp_portscan: portscan status MY.73.93 936 195.33 893 219.1.6 List of top scans Due to the huge amount of data associated to the scanning traffic. Table 3.NET.169 2456 F8B5 06E4 A169 4E46 2125 213.159.194 MY.87 878 24. the analysis shows a total of 11699719 scan events.

Windows [NMAP1].GCIA ´ type SYN UDP SYN FIN INVALIDACK UNKNOWN NULL UNKNOWN UNKNOWN UNKNOWN INVALIDACK NOACK VECNA UNKNOWN NOACK NOACK NOACK INVALIDACK UNKNOWN NOACK flags ******S* 12****S* *******F ***A*R*F 1**A*R** ******** 1****R** *2*A**S* *2*A**** ***AP*S* *****RS* ****P*** *2***R** **U**RSF **U**RS* **U*P*S* ***APR*F *2*A*R** *****R*F count 8577404 3108290 6639 2707 2386 1276 343 70 65 62 57 44 40 29 22 22 20 16 12 10 # src 1029 622 406 172 1832 1061 63 43 6 7 19 19 5 10 9 13 16 6 9 8 3. difficult to be detected without an IDS sensor.NULL scan: no flags were set.6. as explained at the beginning of this document. te 20 04 . Fourth top scan is based on sending a TCP FIN packet (nmap -sF).Raul Siles . as for example. It is needed when checking for specific UDP services. . LIST OF TOP SCANS # srcp 37839 9211 4689 2591 54 6 110 11 4 1 3 4 13 10 14 11 17 8 2 2 # dst 4877732 368421 73 147 160 111 56 52 12 16 19 25 5 22 8 12 15 9 10 10 # dstp 40623 23189 55 23 1697 1066 30 65 64 60 20 31 4 25 11 9 6 8 10 10 Let’s summarize the top three as the typical TCP and UDP scans (nmap examKeyple options= AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 fingerprint have been used as a reference). © SA NS In sti tu As part of GIAC practical repository. All other scans can be classified in the following groups: . The three top scans represent the 99% of all scan packets received. occurred in a 15 hour period. although not all OS behaves like this. but both can be used in a “connect” scan (nmap -sT) or in a “half-open” scan (nmap -sS). Analyzing those scans with more than a hundred entries it must be pointed out that the first and third top scans correspond to the typical scan using a TCP SYN packet. a closed port will reply with a RST packet while an open one will ignore it. a stealthier scan. Most scan activity. The difference between both is the usage of the TCP reserved bits (see the OOS section). The second top scan in the list is based on the UDP protocol (nmap -sU). Typically. Author retains full rights. where the last packet of the TCP 3-way handshake is never sent.A ut Table 3. The alert “Null scan!” that appeared 455 101 © SANS Institute 2004.34: Total portscans captured ho rr eta ins fu ll r igh ts.

85.6. DNS and HTTP. the top source scanning systems must be analyzed. while the second set includes all the other scans. in order to bypass the firewall controls because both. ins dstp count 0 270 110 85 3802 39 80 29 1214 27 6883 20 135 16 F8B5 06E4 A169 3264 13 25 8 1306 7 20 Table 3. HTTP and DNS.A ut ho eta The alert “NMAP TCP ping!” that appeared 752 times in this case was not triggered by logged scans packets with the ACK bit set and an ACK value of zero as in [BEAR1]. All packets associated to a established TCP connection must have the ACK bit set. are the most typical open ports.GCIA ´ Key Table 3. HTTP.UNKNOWN: Some of the two ECN bits have been set. computers (see the Top talkers section).36: Destination ports for all other scans While the top scan types were focused on RPC. There was a wide distribution of external source hosts. . The scan data was divided in two sets. but it is a small value compared with the huge amount of external systems scanned during the period analyzed. It mostly goes from port 0 to port 0. © SA NS In sti 102 © SANS Institute 2004. As part of GIAC practical repository.35: Destination ports for 4 top scans tu te dstp 135 53 80 445 22321 6257 137 fingerprint = 4000 554 7674 count 5808381 2370289 2048608 211497 132539 109499 93326 AF19 FA27 73032 63768 50813 rr 2F94 998D FDB5 DE3D 04 .3.INVALIDACK: the ACK flag has been set but also other combination of not valid flags. times was triggered by these packets. . more than 5 millions (5203279).NOACK: No ACK flag set. scanning the network.36). . fu ll r igh ts. There were thousands of internal hosts identified as targets of this scanning traffic. RPC or SMTP. . . The first one correspond to the top four detects. This division was used during the destination port analysis (see table 3.NET. 4E46 Author retains full rights. 130.35 and table 3. LIST OF TOP SCANS Raul Siles . As a recommendation. such as POP3. accurately 16695 systems (probably most of them correspond to unused IP addresses). Most of these alerts go from port 80 to port 53. All them correspond to internal MY.VECNA: this is a specific stealth scan [BEAR1]. associated to the NULL scans. the most “strange” ones are mainly oriented to port 0. but also they used other known ports. 4480.

LIST OF TOP OOS Therefore.A © SANS Institute 2004.com/ageofshadows/viscent. therefore the transmitted packets are corrupted.Raul Siles . 25). Trying to known more about these events. The top 5 destination ports (97%) correspond to SMTP (mail.37 and table 3.A specific network implementation that doesn’t follow the TCP [RFC793]. . Network Interface Card. Besides. . As 36 http://www.2%) has both TCP reserved bits set. The Out Of Specs. OOS. and has been generated 18086 times from 501 different source IP addresses. There were 18225 OOS events and most of them have a TTL value between 45 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 and 52. 3. it is interesting to see the source and destination ports the TCP packets reference (see table 3. 17988 events have the DF bit set. . ut ho 103 rr eta ins fu ll r igh ts. All them have an IP header of 20 bytes. Finally. As part of GIAC practical repository.html © SA NS In sti tu te 20 04 . 4662 (P2P . the reason is that most OOS packets are generated from ephemeral (client) ports. There were 313 events with an IP ID field of zero while all the others have a random value set. usually because a bad combination of TCP flag and/or options were used. a datagram length of 60 and a TCP length of 40. packets logs are generated when Snort finds an erroneous TCP packet (all OSS logged packets use the TCP protocol). “12****S*”. and due to the fact that the flags used are the main cause for a TCP packet to be reported as an OOS. a TOS equal to zero. or trying to exploit a specific vulnerability.7 List of top OOS Author retains full rights.GCIA ´ 3. and almost all scans were generated from the University network. like IDSes or firewalls. HTTP (web.Generation of crafted (manually manipulated) packets. The top source ports are HTTP and FTP (data connection) although the number of events is negligible.A malfunctioning NIC. This type of activities should be reduced in order to mitigate the organization liability. 80). This type of packets can be observed in a network due to several different reasons: .39). The most frequent OOS event has the following flags set. probably with the goal of evade the security protection systems.38). 8887 (Ultima Online IRC 36 .A broken TCP/IP stack. The most frequent case (99.7. the ECN (Explicit Congestion Notification) and the CWR (Congestion Window Reducted). almost all scanning targets belong to a wide number of external networks.edonkey2000) and identd (113). these are the 17 different values collected with the different number of source systems generating them (see table 3. respectively.uo. .

Table 3.3.NET. that is. Therefore all top internal systems belonged to MY. Both never were the destination of an OOS packet and none of these two hosts appeared in the alert log files. As part of GIAC practical repository. Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 These bits have been set in other anomalous packets.93.40). such as. were analyzed. LIST OF TOP OOS Raul Siles .216. a total of 32 IP addresses. All top source talkers were external hosts and there were only two internal source systems involved in the OOS traffic. Apart from that. and there are 501 different sources.GCIA ´ flags 12U*P*** 2*A**SF 12UA*RS* 2UA*RSF 12**PR** 12**PRSF 12*A*RS* 12U***** *UA**SF 12U***S* 2***RSF 12*AP**F **A**SF *U*P*SF ******* ***P*** 12****S* count 1 1 1 1 1 1 1 1 1 1 1 2 5 7 20 94 18086 # src 1 1 1 1 1 1 1 1 1 1 1 2 2 3 10 4 501 rr Table 3.41). The external host generated 936 spp portscan events and 312 scan packets.NET. these can be set by an intermediate router with ECN support. being only four external OOS destination hosts (see table 3.165 © SA NS In sti tu te 20 © SANS Institute 2004. one from the internal network MY. MY. presenting “impossible” TCP flags combinations. with the idea of finding why these strange packets were generated.39: OOS flags Author retains full rights.50 and one from outside 195. 04 . Why? Because it specifically launched 312 scans (312 x 3 = 936) (see table 3. ‘‘12UA*RS*’’.A 104 ut ho ins fu ll r igh ts. the top OOS talker.NET. a TCP SYN scan using the ECN and CWR bits.100. As an initial investigation countermeasure it would be interesting to analyze the different sources involved in all these packets apart from the most common one.1. In most cases they have been set when establishing a new connection. SYN and RESET. SYN packet. . addressed to port 80 (HTTP) and mainly to a specific host. so it doesn’t seem an ECN router is the cause here.111.7. All these scan packets were the same.37: Top destination ports for OOS Table 3.38: Top destination ports for OOS eta srcp 25 80 8887 4662 113 1214 6881 22 18753 81 count 11456 3580 1351 989 300 87 55 24 20 19 dstp 80 20 3931 51144 33540 37650 36799 35732 52627 3399 count 20 18 15 12 11 11 11 11 11 11 mentioned by [LES1].

208.7 count 6904 3291 1551 1366 1115 769 591 423 244 213 Table 3. table 3.50.34 MY.218 192.16 count 95 8 count 4 2 1 1 3.100.75.NET.67. This host generated OOS packets addressed to 11 different internal systems.NET.47.GCIA ´ src 195.9.12.14.16.24.NET. ‘‘12****S*’’. table 3.143 MY. As part of GIAC practical repository.16 216.69.NET going to MY.238.62.29.64.43.206.41: Top external OOS host: portscans This section includes statistical information about the top TEN talkers of all the different log types analyzed along this paper.Raul Siles . tu te 20 04 .40: Top OOS source (all external) and destinations (all internal) attack spp portscan: PORTSCAN DETECTED spp portscan: portscan status spp portscan: End of portscan count 312 312 312 fu ll r igh ts.NET.111.196.61 213.NET.216.42.8. There is no activity in other log files for the internal host.98.230 MY.52 MY. type SYN Table 3.44 and table 3.99 82.23.6. the information between all the different log files is consistent.82.A © SANS Institute 2004.251.NET.NET.1.2 195.240 MY.100.NET also correspond to packets with the same flags.135.93 217. Analyzing the OOS packets it can be seen that it generated the same type of OOS as the external system. SMTP. The OOS distribution by 998D FDB5 DE3D this 06E4 A169 a bit.216.143 62. .109. source and destination IP address analysis has been developed.15. As can be seen. all generated by MY. © SA NS 3.NET. The top talkers list includes a generic list and two specific list classifying the top internal and external systems.50 MY. SSH. In all cases.NET. both.111.202 count 1102 932 864 792 784 682 559 446 429 410 int src MY.174.181 MY.45. The top talkers list for the portscan alerts (spp portscan) and OOS were analyzed in the corresponding sections.37.209 195.6 MY.137.49 ext dst 35. 95 packets with the ‘‘12****S*’’ flags.NET. The only OOS traffic coming from MY. LDAP and NNTP.145 212. ut ho 105 rr eta ins flags 12****S* count 312 Author retains full rights.165 MY.NET.NET.194 158. TOP TEN TALKERS dst MY.44 MY.24.8 Top ten talkers In sti (1075 OOS packets).25.0.NET. See table 3.46.84.33 194.225 194. Key fingerprint = AF19 FA27 2F94destination port in F8B5case varies 4E46 although it is mainly centered in the HTTP/HTTPS ports and other common services: IMAP.149.47.

141 MY.NET.55.254.NET.NET.NET.51 MY.96.56 68.42: Top ten source alert talkers dst MY.224 MY.3 130.44: Top ten source scan talkers sti tu te 106 © SANS Institute 2004.105 MY.4 MY.6 151.79 200.85.29.51.30.124.52 count 15604 7126 5728 5090 2854 1420 1265 1251 1208 1146 dst int MY.80.228 218. REGISTRATION INFORMATION (WHOIS) src MY.91.70.6 151.202 209.191.103 MY.43: Top 998D FDB5 alert talkers Key fingerprint = AF19 FA27 2F94ten destination DE3D F8B5 06E4 A169 4E46 20 04 . The IP addresses this research is focused on also cover 4 of the 5 top external source © In Table 3.NET.133 MY.85.NET.98 ins NS 3.NET.52 MY.1 130.196.183.62.115.181.169 MY.70.131 211.183.3.169 68.249 130.205.254.70.163.198 MY.91.157 151.29.123.41. fu ll r igh ts.133 MY.10 213.5 219.NET.72 198.72 198.9.197.55.56 MY.250.NET.147 68.51 MY.168.1.74 169.80.176 162.30.57.5 130.84.162.NET.105 MY.NET.NET.85.205.16 count 15604 5728 5090 1146 1035 600 412 379 375 354 Table 3.54.94.NET.131 211.NET.85.66.80.NET.242 MY.NET.19.85.2 68.163.85.NET.249 MY.1.84.150.33 ut ho rr eta SA src 130.191.180 193.16.54.NET.70.224 68.42. As part of GIAC practical repository.228 MY.55.41 169.70.110.115.162.168 count 4279 2933 2889 2743 1251 1124 1046 1022 997 771 Table 3.153.41 MY.107 130.NET.134.143 193.NET.85.157 199.30.163.213 213.149 130.NET.42.194 130.228.84.80.85.NET.180.72 count 2166933 1294187 966595 888185 669973 273705 213577 211571 175961 171526 src ext 165.163.4 128.70.13.9 count 115590 72063 7130 3100 1290 1117 474 445 310 195 Raul Siles . count 7126 2854 1420 1265 1251 1208 1112 878 710 489 count 14452 14548 14827 15688 16244 18246 19164 27734 30239 74607 Author retains full rights.169 200.1.80.142.91.9 Registration information (whois) The selection of the external IP addresses for a WHOIS investigation was made based on specific and interesting criteria while analyzing the top alerts.195.15.254.97.144.85.NET.146 count 115590 72063 7130 4279 3100 2933 2889 2743 1290 1251 src int MY.114.45. .129 130.194.143 193.110.84.114.NET.42.179.216.62.144.154 130.158.99.78.NET.124.80.191 68.NET.NET.242 218.NET.114.57.85.A dst ext 128.244.90.114.70.13.27.84.90.96.85.85.169 63.85.3 MY.121.114.62.91.188 193.150.6.146 172.193.110.197.180 193.232 68.249 MY.GCIA ´ src ext 169.3 MY.150.198 MY.16.169 68.2 MY.206 217.30.68 218.244.147 MY.NET.111.87 200.3 MY.

NET.55.150.27 count 2182 2324 2512 2613 2835 3002 3067 3177 18825 30276 dst ext 205.55.17 131.109.118.0.0. Beijing CN ZH97-AP LY261-AP MAINT-CNNIC-AP MAINT-CN-263 ipas@cnnic.10 130. CMCS sti tu te 20 04 inetnum: 211.255 . such as.104 130.comcast. The contact persons registered in the WHOIS databases have been omitted.15. they were checked against APNIC [APNI1] in Asia.153.51 130.244.4 activity” and “MY.0.30 203.Raul Siles .15.com http://www.152.29.NET.0 network was also involved in other alerts.109.152. America.150.35 131.5 130.118. The 68.35 count 57085 43945 32455 32276 30276 26947 26036 25707 24599 23570 3. Inc. They belong to a telecom.116.cn 20010726 apnic-dbm@apnic.30 192.189 131.85.24.83.net 20010806 ALLOCATED PORTABLE APNIC .254. called “Comcast” 38 . ins fu ll r igh ts. The dynamic Windows DHCP top talker address (169.26.net 20010730 hostmaster@apnic.85.55.254.85.net23.33 216.3 activity” were found in ARIN [ARIN1].56) is the only one not covered by this registration information section.186.152.153 130.254.34 131. © OrgName: OrgID: 37 38 SA http://www.111. “TCP SRC and DST outside network”.85.5 192.33 204.85.116.85.85.94.30.30 192. .254.211.52 130.118.97.34 216.83.85.85.32.17 131.6.53.254.254.189 130.net NS In Comcast Cable Communications.38 130.255. involved in the top external sources for alert “MY.GCIA ´ dst 192.118.92.20.94.175 130.152.30 count 19972 23570 24599 25707 26036 26947 32276 32455 43945 57085 Table 3.20. They belong to a company called “Entegration One” 37 located in Beijing. As part of GIAC practical repository.6.net.153.30 130.A .30.0.186. Author retains full rights.254.26. © SANS Institute 2004.153.52.118.52. high-speed Internet provider company of New Jersey. It is a technology corporation for the public service sector.27 204.92.231.85.34 130.45: Top ten destination scan talkers netname: NET263 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 descr: descr: country: admin-c: tech-c: mnt-by: mnt-lower: changed: changed: changed: status: source: Beijing 263 network group.The networks belonging to 68.244 131.85. ut ho 107 rr eta talkers.The top external destinations referenced by the alert “ICMP SRC and DST outside network” are non-resolvable systems.10 203.9. REGISTRATION INFORMATION (WHOIS) dst int 130. China.0 .249 130.118.

242.3.183. Author retains full rights. It was investigated in the link graph (see section 10).GSFC. 128.160 .255.NET ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE 2001-11-29 2003-11-05 1993-04-01 2003-02-05 .0.183.GSFC. inetnum: netname: 39 40 © http://www.GCIA ´ Address: Address: City: StateProv: PostalCode: Country: NetRange: CIDR: NetName: NetHandle: Parent: NetType: NameServer: NameServer: Comment: RegDate: Updated: 3 Executive Campus 5th Floor Cherry Hill NJ 08002 US 68.70. referenced in the “connect to 515 from inside” alert has been analyzed through ARIN and it belongs to the NASA organization 39 .A ut ho .114. a network and hosting supplier.JDC01. 193.110.0 . Due to the fact that it is an European company.70.128.255 68.com SA 193.193.GOV sti tu te 20 OrgName: National Aeronautics and Space Administration OrgID: NASA Address: AD33/Office of the Chief Information Officer City: MSFC StateProv: AL PostalCode: 35812 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D Country: US 04 .GOV NS2.9.The unique external destination.JDC01.0.114. the involved registry is RIPE [RIPE1].COMCAST.255 128.0 .PA.nasa. rr 108 © SANS Institute 2004.68. It is a non-resolvable address that belongs to an UK company called “PSINet Europe” 40 . .psi. eta ins F8B5 06E4 A169 4E46 fu ll r igh ts.169. As part of GIAC practical repository.PA.COMCAST.32.0. REGISTRATION INFORMATION (WHOIS) Raul Siles .uk. was investigated.255.NET DNS02.gov http://www.The top external scanning system for the “External RPC call” alert.183.NASA.0/16 GSFC NET-128-183-0-0-1 NET-128-0-0-0-0 Direct Allocation NS.183.0/11 JUMPSTART-1 NET-68-32-0-0-1 NET-68-0-0-0-0 Direct Allocation DNS01.191 FIRST-PROCUREMENT-ASSOCIATES-LIMITED NS NetRange: CIDR: NetName: NetHandle: Parent: NetType: NameServer: NameServer: Comment: RegDate: Updated: In 128.32. It is possible that a trust relationship has been established between the University and the NASA but it is probable too that the internal system is trying to compromise the NASA host.114.NASA.0.63.70.

102.alltel.9.229 (h229. using 28 bits of netmask: In • 166.45. fu ll r igh ts.166.com PSINET-UK-SYSADMIN sysadmin@uk.net SA But.15.A ut ho rr • 81.255 IS-LINANET-20020805 Lina.Net PROVIDER IS RIPE 81.psi.net 20030813 04 .com 19990903 RIPE Key The class-B network range is registered to “Alltel” 43 : OrgName: OrgID: Address: City: StateProv: PostalCode: Country: NS © 41 42 http://www.net” located in Iceland (IS). the address corresponds to a small network.alltel.net): It is part of a network registered to a service provider called “Lina.99.0/15 EUNETGB-114-AGG AS1290 PSINET-MNT network-ripe@uk. specifically.com RIPE 20021015 eta ins .net 43 http://www. .102. Only the relevant information is showed.1: This IP belongs to a service provider called “Lina. Little Rock AR 72203 US tu te inetnum: netname: descr: descr: country: source: route: origin: fingerprint descr: = AF19 mnt-by: notify: changed: 81.psi.0.GCIA ´ 3.psi.ip.127. REGISTRATION INFORMATION (WHOIS) route: descr: origin: mnt-by: changed: source: 193.net markom@lina.net” 42 located in Iceland (IS).lina.114. sti ALLTEL Corporation ALLT 1 Allied Dr.0/17 AS15605 FA27 2F94network FDB5 DE3D Lina. descr: country: admin-c: tech-c: status: notify: mnt-by: changed: source: FIRST PROCUREMENT ASSOCIATES LIMITED GB JB7221-RIPE AB480-RIPE ASSIGNED PA ripe-notify@uk.0 .lina.0. As part of GIAC practical repository.Raul Siles . Author retains full rights.81.99.15.0.15. 41 F8B5 06E4 A169 4E46 20 109 © SANS Institute 2004.All the other 3 different sources associated to the “External RPC call” alert were investigated.net 998D LINANET-MNT noc@lina.net http://www.15.

209.209. also analyzed in the Registration section..0. and in the global alerts.4. 166. Microsoft Excel 2002 SP2.0/17 GBLX-11A NET-64-0-0-0-0 Direct Allocation The following software was used to analyze all the IDS logs: Linux RH 9. OrgName: OrgID: Address: City: StateProv: PostalCode: Country: NetRange: CIDR: NetName: Parent: NetType: Global Crossing GBLX 14605 South 50th Street Phoenix AZ 85044-6471 US 64.8.127. 44 http://www.0.169. 04 3.114. portscans and scans data sets.A 110 ut ho rr eta ins fu ll r igh ts.255 64.229: The IP corresponds to another IP services company. sed.208.11 Description of the analysis process NS In Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 The link graph (see figure 3. Perl: v5. MySQL: 3.54a-11.102. NOTE: The unique UDP scan to port 1085 goes to 130.gblx.70. .9.224 .99.10.GCIA ´ CustName: Address: City: StateProv: PostalCode: Country: NetRange: CIDR: Parent: NetType: Export Market LAN 4792 Old William Penn Highway Export PA 15632 US • 64.20-20. As part of GIAC practical repository. 64.10 The link graph .net © SA 3.208.3.99.198.102. based in USA.0. sort.0/16.99. Other Unix scripting tools: grep.0 . The reason to select it was that it is involved as a source top talker in “Alert #1” and “#8”. uniq. kernel 2.209.166.4) has been designed with the goal of obtaining all the relationships around the external host 193.74.239 166.0.102. sti tu te 20 © SANS Institute 2004. THE LINK GRAPH Raul Siles .0.85.150. “Global Crossing” 44 .23.64..224/28 NET-166-102-0-0-1 Reassigned Author retains full rights.

© sti tu Figure 3.4: Link diagram for host 193. . mainly the database tables creation and population method. DESCRIPTION OF THE ANALYSIS PROCESS Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 SA NS In An initial step before starting this analysis was reviewing other people practicals.114. ut 111 ho rr eta ins fu ll r igh ts.11.169 te 20 04 . Author retains full rights.Raul Siles . mainly those considered as honors.70.GCIA ´ 3.A © SANS Institute 2004. As part of GIAC practical repository. This information help to design the analysis process. to get an idea of the tools and methods that could be used.

some special cases were investigated. it was discarded due to memory requirements (512 MB. to finalize checking the OOS data. although it would be very helpful for other people trying to get the GCIA.A 112 ut ho rr eta ins fu ll r igh ts. MySQL was selected as the main platform to query and search into the captured data. unique files. the systems queried for their registration information were selected with the idea of understanding the reason why these external hosts were involved in the alerts. once the information was loaded in the MySQL database. The top talkers lists were extracted from the beginning in order to complement the analysis. Although several methods could be used to extract the information. Then the scans statistics were studied and correlated. Other relevant SQL queries has been extracted from [BRAN1] plus a new set of customized additional SQL sentences. The link graph was generated when it was determined that more information was needed to understand all the activitiesF8B5 06E4 A169 4E46 top Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D develop by one of the external individual hosts. all processing was mainly developed using SQL sentences.3. Google [GOOG1] was the main search engine used to obtain the correlation data. for example basic Unix commands as in Part2 (“Networks Detects”). The research was focused on the top alerts and all its details. Then a elaborated preprocessing work was developed in order to remove corrupted entries. 04 . Author retains full rights. During the process. In sti tu te 20 © SANS Institute 2004. Excel was used to draw the statistical diagrams over time. Once all the alerts were described. As part of GIAC practical repository. The analysis process started getting the top different alerts. 45 © SA NS First of all the original datafiles were combined into individual. DESCRIPTION OF THE ANALYSIS PROCESS Raul Siles . as the IRC traffic or the hints for compromised systems. Although Snortsnarf was tested. of RAM was not enough). based on the environment described in [BRAN1] and [LES1]. Then the top sources and destinations were extracted using similar SQL sentences to the ones showed by [DON1]. so all input files were preprocessed in order to load all events into the database 45 . The basic information was used to guess the network topology and the different services available.11.GCIA ´ NOTE: Due to length constraints related with this GIAC practical the detailed steps to acomplish these tasks have not been included. used to extract all the statistical information from the DB. . Both papers were really useful in setting the DB environment.

http://voodoo. © [HEE1] ”GCIA Practical”. cmu.giac. 2003) rr eta ins fu ll r igh ts. http://www.giac. December 20.mitre.com. IANA. 2003) sti tu [DCE1] ”DCE 1.sans. http: //www.sys-security.org/practical/ GSEC/David_Barroso_GSEC.pdf (1 Dec. http: //ws.com/bid/ (3 Nov.1 RPC Specification”.html (19 Dec. 2000. Hee So.org (1 Aug. Salvatore Sanfilippo. CAE Specification. American Registry for Internet Numbers. 2003) [ARAC1] ”arachNIDS database”. Document Number: C706. http://www. http://www. 2003) SA [GOOG1] ”Google”.giac. 2003) Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 [CVE1] ”CVE”. 2003) [ARIN1] ”ARIN Whois database”. http://www.andrew.cultdeadcow.org/ onlinepubs/9629399/toc.iana.org/practical/Hee_So_ GCIA.giac. te 20 [BUGT1] ”Bugtraq”.1: Remote Procedure Call.ethereal.edu/~rdanyliw/snort/snortacid. Whitehats. Brandon Newport. 2003) 113 © SANS Institute 2004.com/IDS/28 (1 Oct. 2003) http://www. 2003) NS [ETHE1] ”Ethereal”. http://www.pdf (19 Nov. http://www. http://www.hping. http://www. Tod Beardsley. http://www.org/assignments/ [ICMP1] ”Advanced Basic ICMP Rule Base for Snort”. Don Murdoch.doc (1 Dec. David Barroso. 2003) [BEAR1] ”GCIA Practical”.securityfocus. 2003) [IANA1] ”Port numbers”.rdg. http://www.com/archive/snort/icmp_rules/ICMP_basic_plus (3 Dic. http://www. 2003) [APNI1] ”APNIC: Asian registry”. Author retains full rights. http://www.somoslopeor.org/rr/papers/index. Analysis Control for Intrusion Databases”.doc.html (9 Nov.whitehats.cve.arin. DCE 1.com (17 Nov.php?id=826 (1 Sep.net (1 Dec.google.com (17 Dec.com/ tools/bo.org/practical/ Brandon_Newport_GCIA. http://www.giac. 2003) [HPIN1] ”Hping”.Raul Siles . http://www. 2003) ut ho [BO1] ”Back Orifice”.org/cve/ (3 Nov.org/practical/Tod_ Beardsley_GCIA.GCIA ´ BIBLIOGRAPHY Bibliography [ACID1] ”ACID. Cult of the Dead Cow. port-numbers (12 Dic.apnic. 2003) [BARR1] ”A practical approach for defeating nmap OS-Fingerprinting”.zip (1 Dec. 2003) As part of GIAC practical repository. http://www. http://www.opengroup. . 2003) In [DON1] ”GCIA Practical”.org/practical/GCIA/ Don_Murdoch_GCIA. 2003) 04 .A [BRAN1] ”GCIA Practical”.net/cgi-bin/whois.pl (October 10.htm (3 Dec.

rfc-editor.insecure. March. July 2001. Version 2.org/nmap/ (1 Jul.org/papers/finger/ traces.txt (3 Dic.giac.grandgent. October 1989.doc (1 Dec. Richard. http://www.com/research/tools/network_ utilities/ (17 Nov. 2000. Institute of Electrical and Electronics Engineers.com/ tom/programming. http://www. Inc. May 1992. W. http://www. Tom Grandgent. ftp://ftp. June 1988.ieee. June 11. html (10 Nov. Braden.com/html/projects/icmp. 2003) [ISS1] ”TCP null scan . 2003) [NMAP1] ”Nmap”. sti tu te [OFIR1] ”ICMP Usage In Scanning”. IETF. http:// www. 2003) [RFC1122] ”RFC1122: Requirements for Internet Hosts – Communication Layers”. 2003) Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 [PASS1] ”Lists of fingerprints for passive fingerprint monitoring”. ftp://ftp.org/practical/Jason_ Lam_GCIA. Braden. Editor. Jason Lam. Internet Security Systems. 2003) ho rr eta [NETC1] ”Netcat”. ISBN: 0201633469. Ofir Arkin. Lance Spitzner.org/in-notes/rfc793. 2000.honeynet.org/nmap/nmap-fingerprinting-article. http://www.org/regauth/oui/index. http://www.rfc-editor.txt (1 Sep. 2002.org/in-notes/rfc1057.html (3 Dic.org/in-notes/ rfc1323. 2003) © SA NS [RFC793] ”RFC793: TCP .A 114 ut [NMAP2] ”Remote OS detection via TCP/IP Stack FingerPrinting”. Updated 23 May.0.org/practical/GCIA/ Les_Gordon_GCIA.GCIA ´ [IEEE1] ”IEEE OUI and Company id Assignments”. Fyodor. Borman. http://project. ftp://ftp. http://standards.ISS Intrusions Database”. The Protocols”. DARPA. http://www. Fyodor. 2003) [RFC1323] ”RFC1323: TCP Extensions for High Performance”.txt (1 Sep.insecure. R.atstake. Jacobson.BIBLIOGRAPHY Raul Siles . 2003) In [STEV1] ”TCP/IP Illustrated. Les M Gordon. 2003) 20 © SANS Institute 2004. As part of GIAC practical repository.txt (3 Dec.org/ in-notes/rfc1122.net/security_center/advice/Intrusions/2000309/ default. shtml (October 2. Version 3. V. R. D.iss. 2003) [SFAQ1] ”The Snort FAQ”.rfc-editor. 2003) [JASO1] ”GCIA Practical”. 2003) [IPCK1] ”IPCheck”. 1994. Author retains full rights.htm (10 Nov. Volume 1.snort.txt (1 Sep. Addison Wesley Longman. http://www. http://www.Transmission Control Protocol”.sys-security. ftp://ftp.htm (10 Dec. 2003) ins [LES1] ”GCIA Practical”.rfc-editor. 04 . .org/docs/FAQ.giac.doc (1 Dec. September 1981. 2003) fu ll r igh ts. Stevens.txt (1 Nov. 2003) [RFC1057] ”RPC: Remote Procedure Call Protocol Specification”. Inc.

http://www.org (17 Sep. 2003) [RIPE1] ”RIPE: European registry”.GCIA ´ BIBLIOGRAPHY [RFC1831] ”RPC: Remote Procedure Call Protocol Specification Version 2”.net (1 Dec. ftp://ftp. http://www. 2003) [TREA1] ”Treachery Port Lookup Utility”. http: //www.snort. 8th Port.0.txt (3 Dec.txt (1 Sep.org/dl/rules/snortrules-stable.oreillynet. ftp://ftp. 2003) © SA NS [TOP20] ”The Twenty Most Critical Internet Security Vulnerabilities”. Daniel Wesemann.com/products/rna. M. ftp://ftp. 2003) [SNOR1] ”Snort”.tar.sans.net/sniph/ index.sourcefire. 2003) 20 04 . D. August 1995.A © SANS Institute 2004. Robert G.org/top20/ (1 Nov.pdf (12 Dec. As part of GIAC practical repository. 2003) [TCPD1] ”Tcpdump”.html (6 Nov. http://www. 2003) [RULE1] ”Snort configuration & signatures”. 2003) [WESE1] ”GCIA Practical”.html (6 Nov.org (17 May 2003) [SNOR2] ”Snort Documentation”.tcpdump. 2003) tu te [SNOT1] ”Snot”. Byrnes. Sniphs cavern o’ c0de. 2003) [RFC1918] ”Address Allocation for Private Internets”.com/pub/a/linux/2003/06/ 02/snort.net/stick/projects8.rfc-editor. 6 Feb.stolenshoes.org/in-notes/rfc1918. http://www.org/in-notes/rfc1831. ut ho 115 rr eta ins fu ll r igh ts. http://www. http://www.net/security_ tools/ports/ (16 Dec.New. SANS.eurocompton.pdf (10 Nov.snort. http://www.sans.giac. 2003) In sti [STIC1] ”Stick”. Sourcefire.Real-Time Network Awareness”. 2003) [RNA1] ”Sourcefire RNA technology .org/docs/ Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 SnortUsersManual-2.php?webcastid=90419 (14 Nov. http://www. .1. http://linux.org/in-notes/rfc3195. Rose.txt (1 Oct.org/ practical/GCIA/Daniel_Wesemann_GCIA.rfc-editor.html (6 Nov. 2003. coauthor of Linux Security Cookbook. http://www.snort.gz (10 Dec. http://www.html. http://www. Author retains full rights.treachery.Raul Siles . (Tue Dec 9 23:15:15 2003 GMT). org/webcasts/show. February 1996. 2003) [ROBE1] ”Saving Our Bacon: Snort Security Holes and Strategies for Safe Network Monitoring”. 2003) [RFC3195] ”RFC3195: Reliable Delivery for syslog”. rfc-editor.ripe. November 2001.

Sign up to vote on this title
UsefulNot useful