2000-08-30
|
1.1 INTRODUCTION
The purpose of this paper is to help Intrusion detection analysts and firewall administrators identify NMAP & QUESO scans.
This paper will provide bit level analysis in detecting NMAP and QUESO scans. This type of analysis is vital for individuals
who are performing firewall administration and need to understand more details relating to these scanners and the scans they
perform. A port scanner is a tool used by both system administrators and attacker(s) to identify vulnerabilities in operating
systems. Port scanners identify vulnerabilities by sending normal and abnormal packets to computer ports and waiting for a
response to determine what port(s) are 'open'. From this data, a system administrator, or an attacker, can determine what
holes need to be patched or what holes can be exploited. There are several different types of port scanners. There are free port scanners such as NMAP and QUESO. Free port
scanners allow for a lot of flexibility in scanning for vulnerabilities. There are commercial scanners available to use if
you or your company requires a licensed product. A comparison of commercial scanners vs. free scanners is beyond the scope of
this paper. NMAP is a freely distributed port scanner developed and maintained by Fyodor (www.insecure.org). NMAP can run on a variety of operating systems such as Linux, FreeBSD,
Open BSD, Solaris and even NT (thanks to eEye security). NMAP is probably the most popular freely available scanner on the
Internet. Because of its ease of use, it can be used by everyone from a novice to an expert. Since NMAP is so easy to use
and is ported to almost every available operating system this raises one question: how do we (IDS & Firewall community) detect
NMAP? Detecting NMAP is not an easy task to do. NMAP has many switches available for a person to use - covering every switch and
its option's are beyond the scope of this paper. For the purpose of explanation, the following switches will be used (each of
the selected switches will be described in detail later): Figure 1 (below) shows the -sS scan along with a couple of common signatures associated with NMAP. Some lines are
wrapped. First, let's look at some of the common NMAP signatures. Figure 1 shows that NMAP sends out one- (1) echo requests
(highlighted in red). This is done to ensure the victim is up and running. The second signature in this scan is the lone ACK
packet that that set the 32 -bit Acknowledgement field to 0. (Figure 1 - in red) This ACK field
should always be >1 when sent in an ACK packet. Why is this done? The reason for setting the ACK field to 0 is simple: "stealth". Why would NMAP send two (2) ACK packets
anyway? RFC 793 can shed some light on this question and help you understand why certain packets are used in network mapping.
RFC 793 pp. 64 covers how TCP responds to specific packets; these responses are based on two TCP states. These states are
CLOSED and LISTEN. RFC 793 states that when a port is in the closed state, the following rules apply: For a port in the LISTEN state, the following rules apply: Knowing this, we can conclude that the two ACK packets are sent to verify that the computer to be scanned is up and
running. Another common signature of NMAP are the high source ports. Normally, NMAP's source ports are above 20000 (this feature
can be changed with the -p switch). The thought process behind setting the port so high is that some IDS and firewall
programs will not flag these scans because of this. That thought process still holds true today in some cases, many times the
high source ports alert an IDS analyst or firewall administrator that they are being scanned. The first switch we will look at is the -sS switch (Figure 1). The -sS switch sends a SYN(s) to a port(s) and waits for a
response. The response should be either a SYN | ACK if the port is open or a RST | ACK if the port is closed. This scan is
considered a "half-scan", the theory behind a "half -scan" is NMAP will send SYN's to a computer, if the port(s) are closed
then a rest is sent back notifying NMAP that the port is closed. If NMAP sends a SYN to an open port, that port will respond
with a SYN | ACK. Once NMAP detects the SYN | ACK it automatically replies back with a RST. This RST will break the
connection and in some cases, a computer will not log this attempt. This also lets NMAP know what ports are open and what
ports are closed. The -sX switch does performs a Xmas tree scan (Figure 2). Because of the odd TCP flags (FIN, PSH and URG) set by this
scan, some firewalls (poorly configured) will allow these packets to pass through. Figure 2 indicates that once again NMAP
sends out two echo request and ACK packets to ensure that the target is in fact up and running. What is so strange about FIN, PSH and URG all set at the same time? To answer that question lets take a look at what each
flag does: In short what the FIN, PSH, URG combination tells the computer is to begin tearing down the connection, pass the data ASAP
and then there is "urgent" data to be passed on the normal stream of data. In my experience, this does not make since (unless
you're trying to map a network). Another signature of NMAP is when it uses the Xmas tree scan also check the Urgent pointer -
it is always set to 0 (blue in Figure 2). Finally, we are going to look at the -sF switch along with the -O switch. The -sF scans computers with the FIN bit set.
The -O switch does Operating System fingerprinting. If you get a chance before you compile NMAP take a look at the
fingerprinting file. It's impressive, the collection of OS fingerprints Fyodor has collected really amazes me. Figure 3
shows -sF scan with the -O option also being used. The theory behind NMAP's -sF scan is quite simple and we covered it at the beginning of this paper. It all revolves around
TCP and what state the port(s) are in (CLOSED or LISTENING). Here is a real quick summary: This method may get past a few Intrusion Detection System's and Firewalls because there are a few out there who only
look for a FIN | ACK combination not just a FIN. NMAP's -O function identifies a probbable Operating System to the user. As you can see in Figure 3 NMAP is a combination
of packets which include FIN | PUSH | URG, SIN | FIN | PSH, SYN packets and a few UDP packets. From my experience, most of
the UDP packets have been 300 bytes. Although QUESO is not as popular or robust as NMAP, it still provides great signatures to look at and analyze. QUESO is
written by savage@apostols.org. It is available at any of your local neighborhood
port scanning websites - and best of all, it is free.
QUESO usually sends out seven (7) packets at a time. If you read the documentation.txt (file that comes with QUESO), it
states that QUESO sends out seven (7) packets at a time. QUESO send out the following packets: QUESO allows a user to spoof his/her address and to choose what port he/she wants to scan. QUESO also chooses random
source ports (4000 -65000). Figure 4 shows us what a scan by QUESO looks like: Looking at the scan (Figure 4), we see all seven (7) packets are there. What we need the hex dumps for are the
signatures that do not stand out. The first signature that we see is one (1) lonely FIN packet. What makes these packets
stand out is that there is no connection (why would you send a FIN to a terminate a connection that never was made.) and the
FIN does not contain an ACK. Although, TCP uses a three - way handshake to make a connection, it uses a four - way handshake
to disconnect. The process of connection termination goes like this: Still looking at the scan, we see a PSH flag set, this should raise some eyebrows as well because in TCP a PSH flag should
be accompanied by an ACK (as long as a connection has been made). We see that QUESO sets the SYN | FIN flags which tell the receiving computer to OPEN and CLOSE a connection all at
once. The most interesting signature that QUESO sends is one (1) SYN packet that sets the reserved bits (figure 4. Bold in
pink). Figure 5 shows what byte 13 in the TCP header looks like. The last two bits on the left (labeled n/a) are reserved
and should not be set. This is easy to identify, if you see c2 set in the 13th byte of the TCP header, you know that someone
has malicious intentions for your network. In conclusion, this paper was written to help administrators understand some detailed information about NMAP and QUESO.
With this level of understanding, IDS analyst(s) and firewall administrators will be able to identify these scans in the wild
and respond accordingly. Any questions or comments can be addressed at infowar@erols.com. Toby Miller currently works at SYTEX Inc. based out of Pennsylvania. Toby holds a
B.S in Computer Information Systems . Toby is a GIAC Certified Intrusion Analyst and a Microsoft Certified Professional. In
his seven years in the computer field he has worked in many area such as Firewalls, Unix administration, NT Administration and
some mainframe work. |
||||||||||||||||||||
 |
