Around The Globe ATG.WORLD

Visit our sister website :

http://www.atg.world/

This is a social network for enthusiasts just like us. No Junk! Only meaningful conversations with the people who share the same enthusiasm as us.

Around The Globe ATG.WORLD

Visit our sister website :

http://www.atg.world/

This is a social network for enthusiasts just like us. No Junk! Only meaningful conversations with the people who share the same enthusiasm as us.

Monday, July 6, 2009

STEALTH SCANNING

The definition of a "stealth" scan has varied over recent years from what Chris Klaus, author of a paper titled "Stealth Scanning: Bypassing Firewalls/SATAN Detectors" delineated. Originally the term was used to describe a technique that avoided IDS and logging, now know as "half-open" scanning.
However, nowadays stealth is considered to be any scan that is concerned with a few of the following:
* setting individual flags (ACK, FIN, RST, .. )
* NULL flags set
* All flags set
* bypassing filters, firewalls, routers
* appearing as casual network traffic
* varied packet dispersal rates

IP ID Header or "DUMB" scanning

IP ID Header or "DUMB" scanning
ID header scanning technique was discovered by antirez, who described it's technical details in a post to bugtraq. Evidently the basis of this scans implementation is reflective on the SYN scan method, although involves a third party host to use as a dummy source.

SILENT or DUMB HOST : is a server that sends and receives little to no traffic at all, hence the characteristic name endowed upon it. Locating one of these hosts requires much effort and host sweeping itself, and is probably more trouble than what it is worth.

Involved in this scenario are three hosts:
* A -> attackers host
* B -> dumb host
* C -> target host
Let's examine this cycle.
* Host A sends a series of ping's analysing the ID field, encapsulated within the IP header to Host B. A dumb host will have the ID increment the reply by 1 each time during the PING sequence.
60 bytes from BBB.BBB.BBB.BBB: seq=1 ttl=64 id=+1 win=0 time=96 ms
60 bytes from BBB.BBB.BBB.BBB: seq=2 ttl=64 id=+1 win=0 time=88 ms
60 bytes from BBB.BBB.BBB.BBB: seq=3 ttl=64 id=+1 win=0 time=92 ms
* Host A sends a spoofed SYN packet to Host C using the source address of Host B. The remote port is any arbitrary port (1-65535) that the attacker wishes to test for open/closed responses. Host C will reply to Host B with one of two standard responses:
-> SYNACK response indicates an open LISTENING port. Host B will then reply with an RST bit flagged in the packet (automated by kernel).
-> RSTACK will indicate a NON-LISTENING port, (a standard SYN scan method reply), and Host B will ignore that packet and send nothing in reply.

Now, how could Host A know what flags were sent to Host B ?
Well, assuming the port was open on the target server, our series of parallel PING's that Host A had been sending whilst the spoofed SYN packets were being sent will hold our answers.

Analyzing the ID field in these PING responses, one would notice a higher ID increment.
60 bytes from BBB.BBB.BBB.BBB: seq=25 ttl=64 id=+1 win=0 time=92 ms
60 bytes from BBB.BBB.BBB.BBB: seq=26 ttl=64 id=+3 win=0 time=80 ms
60 bytes from BBB.BBB.BBB.BBB: seq=27 ttl=64 id=+2 win=0 time=83 ms

Notice the second and third packets ID responses contain values greater than 1, hence an open port was located. Any further increment of more than 1 is indicative of an open port in Host B's responses, during this period.

Originally, the increment was 1, but because Host A sent a spoofed SYN to an open port, Host B had to reply to Host C with the SYNACK bit packet, thus incrementing the ID field. Following this the PING response to Host A would then in turn have a higher ID field, as suspected.
On the other hand, a closed port state on Host C would not require Host B to send anything, so the ID field in the PING response would not be incremented at all.
60 bytes from BBB.BBB.BBB.BBB: seq=30 ttl=64 id=+1 win=0 time=90 ms
60 bytes from BBB.BBB.BBB.BBB: seq=31 ttl=64 id=+1 win=0 time=88 ms
60 bytes from BBB.BBB.BBB.BBB: seq=32 ttl=64 id=+1 win=0 time=87 ms

Once again this is why a "dumb" host is required, so incoming and outgoing traffic is kept at a bare minimum in order to decrease false-positive results.

SYN SCAN

The implementation of this scan method is similar to a full TCP connect() three way handshake except instead of sending ACK responses we immediately tear down the connection.
client -> SYN
server -> SYN | ACK
client -> RST
This example has shown the target port was open, since the server responded with SYN ACK flags. The RST bit is kernel oriented, that is, the client need not send another packet with this bit, since the kernel's TCP/IP stack code automates this. Inversely, a closed port will respond with RST ACK.
client -> SYN
server -> RST | ACK

As such, this scan method will often go unlogged by connection based IDS', and will return fairly positive results (reliability of open/closed port recognition). Instead of sending ACK responses, we immediately tear down the connection.

As is displayed, this combination of flags is indicative of a non- listening port. Although, this technique has become rather easy to detect by many IDS, owing to the fact that a paramount of Denial of Service (DoS) utilities base their attacks by sending excess SYN packets.

Fairly standard intrusion detection systems are no doubt capable of logging these half-open scans: TCP wrappers, SNORT, Courtney, iplog. Notoriously, the SYN method was first used to avoid a well used IDS, named SATAN.

Advantages : fast, reliable, avoids basic IDS, avoids TCP three-way handshake

Disadvantages: require root privileges, rulesets block many SYN scan attempts