Member Avatar for ithilgore

In this guide, I am analyzing the process of making from scratch a fully functional SYN port scanner. The process goes through many different aspects of network security such as:

--Raw Sockets
--Libpcap/Sniffing
--Tcp/ip header analysis
--The Syn Scanning itself

Full source included.
I am waiting for feedback.

http://rapidshare.com/files/53266260/Coding-a-Syn-Scanner-eng-v1.1.txt.html

-ithilgore

  • 2 Contributors
  • 9 Replies
  • 184 Views
  • 3 Days Discussion Span
  • Latest Post Latest Post by Hamrick
Member Avatar for ithilgore

No responses but 80+ views ? strange ....

Member Avatar for Hamrick

Maybe nobody wants to download it...

Member Avatar for ithilgore

Judging a book by it's cover ?

Member Avatar for Hamrick

Judging a book by it's cover ?

Yeah. rapidshare looks kind of sketchy and I don't want to click any of those links to download your file. :)

Member Avatar for ithilgore

I would post it in the forum, if the formatting wasn't lost.

Member Avatar for ithilgore

ok posted as an attachment if clicking on 2 links more was so much trouble...

*****************************************
*       Coding a Syn Scanner            *
*            by ithilgore               *
*       ithilgore.ryu.L@gmail.com       *
*       version 1.1 - March 2007        *
*****************************************


0x0. Index
0x1. Prologue
0x2. Syn Scanning
0x3. Tcp/ip header analysis
0x4. Raw Sockets
0x5. Libpcap/Sniffing Session
0x6. The SYN port scanner(source)
0x7. Epilogue
0x8. References


--------------
0x1. Prologue
--------------

In the current article we are going to analyse the process of programming a Port Scanner which uses stealthier methods to 
scan its victim. In fact we shall see how a SYN scanner is made. It is not the result that counts so much, since there are 
already some high-quality tools in the open source community that support such a function ( see Nmap ). However, we are more
interested in the process of making such a tool, a process which includes many different interesting matters of the security
sector. What are these things in a few words?

--Raw Sockets
--Libpcap/Sniffing
--Tcp/ip header analysis
--The Syn Scanning itself

This guide's purpose, as you will realize, is not to just plainly give the source code of the SYN Scanner ( this in fact by
itself doesn't have any actual meaning since, as we have already mentioned there are such tools with an open source in public )
but to give some guidelines for someone who wants to go deeper into the Network Programming (in Unix) through the programming
and analysis of the creation of this particular tool.This means that with this guide, you will constantly have to refer to 
man pages,RFCs etc as well as to execute other tools such as tcpdump.

For someone to be able to understand the flow of this guide he will have to:
a) have a good understanding of the C language
b) have already delved into the basics of network programming ( see http://beej.us/guide/bgnet/ )
c) know some basic things about networks
d) have a box installed with a unix-flavored OS ( root priviledges required ) so as to be able to experiment with the 
code.
e) have a second box ( either as a virtual machine or real ) available (this is not required though)
f) have enough free time as some concepts are quite difficult to understand in the first place

Note down that the code has been successfully tested on a Slackware 11 box with kernel 2.4.33.3


------------------
0x2. SYN Scanning
------------------


The SYN scanning is based on a simple method called half-open connection. As we already know, when two computers communicate
with each other through the TCP, the below procedure is followed:

a) client ----------SYN J-------------->  server
b) client <--------SYN K / ACK J+1------  server
c) client --------ACK K+1 ------------->  server

The above is called 3-way handshake as it goes through 3 stages of handshake:
a) In the beginning, the client sends a TCP packet to the servers's port with an initial sequence (usually random).
b) During the second stage, if the server accepts connections on this particular port, he will send as an answer a TCP 
packet with a sequence ACK equal to SYN+1 (we suppose the client's sequence is SYN) as well as a new SYN sequence of his own.
c) In the end, the client will answer with an ACK incremented by 1 in relation to the SYN the server sent during the b 
part.

-->In case the server's port is closed, the server sends a RST packet in the b stage and terminates the handshake.

The above way is the classical way of a common port scanner, that scans through the ports that interest the attacker trying to 
open to each of them a full connection through the simple 3-way handshake. What a nice way for the victim's firewall or IDS to log 
the attack...

A better solution is given by the half-open connection:

a) client ----------SYN J-------------->  server
b) client <--------SYN K / ACK J+1------  server
c) client ----------RST --------------->  server


Which is the only difference? As you have already observed the last step during which the client who already knows that the
server has sent a positive answer, instead of opening the connection fully ( the usual state: Connection Established ), sends
a RST packet terminating the connection prematurely.

What is the benefit? A smaller chance to alarm any security mechanism of the victim as the connection is never opened fully.
This is in fact the stealth capability that the SYN scanner comes to use.
Details for how it is done, below.


----------------------------
0x3. TCP/IP header analysis
----------------------------

It is time to see more closely what exactly takes place behind the curtains. At this stage it would be a good chance to scan 
through the RFCs 791 ( Internet Protocol ) and 793 ( Transmission Protocol ) as their knowledge will come in handy later.

The TCP header's format is shown below. In fact, the important information that every TCP packet must have is untill the 
Urgent Pointer, which means 20 bytes in size.


    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Let's see more analytically each field of the header:

------                  -----           ------------
FIELD                   SIZE            DESCRIPTION
------                  -----           ------------

Source Port:            (16bits)        The client's Port number
Destination Port:       (16bits)        The server's (destination) Port number
Sequence Number:        (32bits)        The sequence number that is used for enumerating TCP packets
                                        (see 3-way handshake)
Acknowledgment Number:  (32bits)        The answer number to the previous SYN. It stands that ACK = previous_SYN + 1 
Data Offset:            (4 bits)        The number that defines the header's size.WARNING!-> it is counted by multiples of
                                        32bits/4bytes. This means that when the TCP packet has n options data_offset = 5
                                        
Reserved:               (6 bits)        Just reserved, these bits are all 0

Flags:                  (6 bits)        Each flag defines a special state.(1 bit each -on/off)
        URG:                            Urgent: for fast routing	   			    	
        ACK:                            cknowledgment: for the 2nd and 3rd stage of the 3way TCP handshake 
        PSH:                            Push: the system doesn't buffer the segment into the P stack
        RST:                            Reset: for immediate termination of a connection
        SYN:                            Synchronization: for a new connection and TCP handshake
        FIN:                            Final: for the normal termination of a connection ( see TCP termination)

Window:                 (16bits)        The maximum quantity of data that the client will receive
Checksum:               (16bits)        The packet's checksum, which we shall analyze later
Urgent Pointer:         (16bits)        It is used in combination with the urgent flag

These are in a few words the TCP header's fields with which we shall be occupied below when we create our own datagram.
We do not analyse each of them in depth since this is not our purpose.Instead of that we shall point out some of them
later as they will be of vital importance to our SYN scanner.For more information you are encouraged to see the corresponding
RFCs.

But now let's see in a code level how such a TCP header would be like.

/* TCP header */
typedef u_int tcp_seq;

struct sniff_tcp {
        u_short th_sport;               /* source port */
        u_short th_dport;               /* destination port */
        tcp_seq th_seq;                 /* sequence number */
        tcp_seq th_ack;                 /* acknowledgement number */
        u_char  th_offx2;               /* data offset, rsvd */
#define TH_OFF(th)      (((th)->th_offx2 & 0xf0) >> 4)
        u_char  th_flags;
        #define TH_FIN  0x01
        #define TH_SYN  0x02
        #define TH_RST  0x04
        #define TH_PUSH 0x08
        #define TH_ACK  0x10
        #define TH_URG  0x20
        #define TH_ECE  0x40
        #define TH_CWR  0x80
        #define TH_FLAGS        (TH_FIN|TH_SYN|TH_RST|TH_ACK|TH_URG|TH_ECE|TH_CWR)
        u_short th_win;                 /* window */
        u_short th_sum;                 /* checksum */
        u_short th_urp;                 /* urgent pointer */
};


As we see there is a 1 to 1 correlation between the struct's fields and the TCP header's fields.
We should point out that the above struct is not the classic BSD-flavored but a style proposed by Tim Carstens 
-> http://www.tcpdump.org/pcap.htm ( we shall refer to pcap later if this link moved your curiosity )

A little more patience to see the IP header and then we shall look into a live example with tcpdump!
Member Avatar for Hamrick

That's better. Clicking 2 links more that I don't trust _was_ too much trouble.

Member Avatar for ithilgore

ok. but rapdishare.com isn't generally considered untrustworthy at all. many people use to share files across the net. now if the file was sth of executable nature i would understand ur concern.

Member Avatar for Hamrick

but rapdishare.com isn't generally considered untrustworthy at all.

If I'm not comfortable using it, I won't. Simple. You don't need to understand my concern to respect it. :)

The file looks well written, but it'll take me a while to understand it.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.