Network Monitoring Tools


Source : http://www.insecure.org/nmap/nmap_doc.html



    Over time, a number of techniques have been developed for surveying the protocols and ports on which a target machine is listening. They all offer different benefits and problems. Here is a line up of the most common.

       TCP connect() scanning :  This is the most basic form of TCP scanning. The connect() system call provided by your operating system is used to open a connection to every interesting   port on the machine. If the port is listening, connect() will succeed, otherwise the port isn't reachable. One strong advantage to this technique is that you don't need any special privileges. Any user on most UNIX boxes is free to use this call. Another advantage is speed. While making a separate connect() call for every targeted port in a linear fashion would  take ages over a slow connection, you can hasten the scan by using many sockets in parallel. Using non-blocking I/O allows you to set a low time-out period and watch all the sockets at
 once.  The big downside is that this sort of scan is easily detectable and filterable. The  target hosts logs will show a bunch of connection and error messages for the services which take the connection and then have it immediately shutdown.

       TCP SYN scanning :  This technique is often referred to as "half-open" scanning, because you don't open a full TCP connection. You send a SYN packet, as if you are going to open a real   connection and wait for a response. A SYN|ACK indicates the port is listening. A RST is indicative of a non- listener. If a SYN|ACK is received, you immediately send a RST to tear    down the connection . The primary advantage to this scanning technique is that fewer sites will log it. Unfortunately you need root privileges to build  these custom SYN packets.

       TCP FIN scanning :  There are times when even SYN scanning isn't clandestine enough. Some firewalls and packet filters watch for SYNs to restricted ports, and programs like synlogger  and Courtney are available to detect these scans. FIN packets, on the other hand, may be able to pass through unmolested.  The idea is that closed ports tend to reply to your FIN packet with the proper RST. Open ports, on the other hand, tend to ignore the packet in question. This is required TCP behavior. However, some systems (notably Micro$oft boxes), are broken in this regard. They send RST's regardless of the port state,   and thus they aren't vulnerable to this type of scan. It works well on most other systems.. Actually, it is often useful to discriminate between a *NIX and NT box, and this can be        used to do that.

       Fragmentation scanning : This is not a new scanning method in and of itself, but a modification of other techniques. Instead of just sending the probe packet, you break it into a couple of  small IP fragments. You are splitting up the TCP header over several packets to make it harder for packet filters and so forth to detect what you are doing.  Some    programs have trouble handling these tiny packets.  While  this method won't get by packet filters and firewalls that queue all IP fragments (like the CONFIG_IP_ALWAYS_DEFRAG option in Linux), a lot of networks can't afford the   performance hit this causes. This feature is rather unique to scanners.

       TCP reverse ident scanning : As noted by Dave Goldsmith in a 1996 Bugtraq post, the ident protocol (rfc1413) allows for the disclosure of the username of the owner of any process   connected via TCP, even if that process didn't initiate the connection. So you can, for example, connect to the http port and then use identd to find out whether the server is running as    root. This can only be done with a full TCP connection to the target port.

          UDP ICMP port unreachable scanning : This scanning method uses the UDP protocol instead of TCP. While this protocol is simpler, scanning it is     actually significantly more difficult. This is because open ports don't have to send an acknowledgement in response to our probe, and closed ports aren't even required to send an error    packet. Fortunately, most hosts do send an ICMP_PORT_UNREACH error when you send a packet to a closed UDP port. Thus you can find out if a port is NOT open, and by exclusion     determine which ports which are. Neither UDP packets, nor the ICMP errors are guaranteed to arrive, so UDP scanners of this sort must also implement retransmission of packets that   appear to be lost (or you will get a bunch of false positives).

       UDP recvfrom() and write() scanning : While non-root users can't read port unreachable errors directly, Linux is cool enough to inform the user indirectly when they have been received.    For example a second write() call to a closed port will usually fail. A lot of scanners such as netcat and Pluvius' pscan.c does this. This is the     technique used for determining open ports when non-root users use -u (UDP). Root users can also use the -l (lamer UDP scan) options to force this, but it is a really dumb idea.

       ICMP echo scanning : This isn't really port scanning, since ICMP doesn't have a port abstraction. But it is sometimes useful to determine what hosts in a network are up by pinging them   all.