Saturday, May 28, 2011

How to grab server banners!

Banner Grabbing

In the context of Computer Networking, Banner Grabbing is an enumeration technique used to glean information about computer systems on a network and the services running its open ports. Administrators can use this to take inventory of the systems and services on their network. An intruder however can use banner grabbing in order to find network hosts that are running versions of applications and operating systems with known exploits.

Some examples of service ports used for banner grabbing are those used by Hyper Text Transfer Protocol (HTTP), File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP); ports 80, 21, and 25 respectively. Tools commonly used to perform banner grabbing are Telnet, which is included with most operating systems, and Netcat.

For example one could establish a connection to a target host running a web service with netcat, then send a bad html request in order to get information about the service on the host:

[root@proxy] telnet www.targethost.com 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Mon, 11 May 2009 22:10:40 EST
Server: Apache/2.0.46 (Unix) (Red Hat/Linux)
Last-Modified: Thu, 16 Apr 2009 11:20:14 PST
ETag: "1986-69b-123a4bc6"
Accept-Ranges: bytes
Content-Length: 1110
Connection: close
Content-Type: text/html


The administrator can now catalog this system or an intruder now knows what for what version of Apache to look for exploits.

To prevent this Network Administrators should restrict access to services on their networks to appropriate networks and shut down unused or unnecessary services running on network hosts.

Is your server secure??

Friday, May 27, 2011

Intro to Netstat!

Netstat (NETwork STATistics) is a command-line tool that provides information about your network configuration and activity.

To display the routing table:

#netstat -rn
-r: Kernel routing tables.
-n: Shows numerical addresses instead of trying to determine hosts.

Kernel IP routing table
Destination
192.168.1.0
0.0.0.0 Gateway
0.0.0.0
192.168.1.1 Genmask
255.255.255.0
0.0.0.0 Flags
U
UG MSS
0
0 Window
0
0 irtt
0
0 Iface
eth1
eth1
To display the quick interfaces statistics:

#netstat -i
-i: Interface

Kernel Interface table
Iface
ath0
eth0
eth1
lo MTU
1500
1500
1500
16436 Met
0
0
0
0 RX-OK
0
0
1156
225 RX-ERR
250
0
0
0 RX-DRP
0
0
0
0 RX-OVR
0
0
0
0 TX-OK
0
0
568
225 TX-ERR
0
0
0
0 TX-DRP
0
0
0
0 TX-OVR
0
0
0
0 FLG
BMRU
BMU
BMRU
LRU
To display the extended interfaces statistics:

#netstat -ie
-i: Interface
-e: Extended information

Kernel Interface table
eth0 Link encap:Ethernet HWaddr AA:00:11:22:33:44
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:169

eth1 Link encap:Ethernet HWaddr AA:00:11:22:33:44
inet addr:192.168.1.101 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::a100:0aa:aa00:a01/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1212 errors:0 dropped:0 overruns:0 frame:0
TX packets:580 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:216479 (211.4 KiB) TX bytes:56987 (55.6 KiB)
Interrupt:201 Memory:dfcff000-dfcfffff

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:238 errors:0 dropped:0 overruns:0 frame:0
TX packets:238 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:8688 (8.4 KiB) TX bytes:8688 (8.4 KiB)

Note that "netstat -ie" is equivalent to "ifconfig -a".

To display all the opened network sockets:

#netstat -uta
-u: UDP
-t: TCP
-a: All

Active Internet connections (servers and established)
Proto
tcp
tcp
tcp
tcp
tcp
tcp
tcp
tcp
tcp
tcp6
udp Recv-Q
0
0
0
0
0
0
0
0
0
0
0 Send-Q
0
0
0
0
0
0
0
0
0
0
0 Local Address
localhost:48898
localhost:39524
localhost:mysql
localhost:ipp
192.168.1.101:49041
localhost:39524
192.168.1.101:43706
192.168.1.101:43704
localhost:53920
*:www
*:bootpc Foreign Address
*:*
*:*
*:*
*:*
lm-in-f104.google.c:www
localhost:53920
fk-in-f104.google.c:www
fk-in-f104.google.c:www
localhost:39524
*:*
*:* State
LISTEN
LISTEN
LISTEN
LISTEN
CLOSE_WAIT
ESTABLISHED
ESTABLISHED
ESTABLISHED
ESTABLISHED
LISTEN
The listening state sockets are included in the output only if you specify the --listening (-l) or --all (-a) option.

The possible socket states are as follows:
(taken from the "man netstat" page)

ESTABLISHED:
SYN_SENT:
SYN_RECV:
FIN_WAIT1:
FIN_WAIT2:

TIME_WAIT:
CLOSED:
CLOSE_WAIT:
LAST_ACK:

LISTEN:

CLOSING:
UNKNOWN: The socket has an established connection.
The socket is actively attempting to establish a connection.
A connection request has been received from the network.
The socket is closed, and the connection is shutting down.
Connection is closed, and the socket is waiting for a shutdown from the remote end.
The socket is waiting after close to handle packets still in the network.
The socket is not being used.
The remote end has shut down, waiting for the socket to close.
The remote end has shut down, and the socket is closed. Waiting for acknowledgement.
The socket is listening for incoming connections. Such sockets are not included in the output unless you specify the --listening (-l) or --all (-a) option.
Both sockets are shut down but we still don�t have all our data sent.
The state of the socket is unknown.
To display all the opened network sockets (extended informations):

#netstat -aute
-a: All
-u: UDP
-t: TCP
-e: Extended

Active Internet connections (servers and established)
Proto
tcp
tcp
tcp
tcp
tcp
tcp
tcp
tcp6
udp Recv-Q
0
0
0
0
0
0
0
0
0 Send-Q
0
0
0
0
0
0
0
0
0 Local Address
localhost:48898
localhost:39524
localhost:mysql
localhost:ipp
localhost:39524
localhost:53920
192.168.1.101:42745
*:www
*:bootpc Foreign Address
*:*
*:*
*:*
*:*
localhost:53920
localhost:39524
lm-in-f147.google.c:www
*:*
*:* State
LISTEN
LISTEN
LISTEN
LISTEN
ESTABLISHED
ESTABLISHED
ESTABLISHED
LISTEN
User
hplip
hplip
mysql
root
hplip
hplip
po
root
dhcp Inode
12383
12321
12635
12447
12324
12389
15781
13141
14513
To display all the listening state sockets:

#netstat -lt
-t: TCP
-l: Listening state sockets

Active Internet connections (only servers)
Proto
tcp
tcp
tcp
tcp
tcp6 Recv-Q
0
0
0
0
0 Send-Q
0
0
0
0
0 Local Address
localhost:48898
localhost:39524
localhost:mysql
localhost:ipp
*:www Foreign Address
*:*
*:*
*:*
*:*
*:* State
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
To display the summary statistics for each protocol

#netstat -s
-s: Summary statistics for each protocol.

Ip:
604 total packets received
1 with invalid addresses
0 forwarded
0 incoming packets discarded
485 incoming packets delivered
507 requests sent out
Icmp:
0 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
0 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
Tcp:
21 active connections openings
4 passive connection openings
0 failed connection attempts
0 connection resets received
3 connections established
351 segments received
388 segments send out
0 segments retransmited
0 bad segments received.
2 resets sent
Udp:
119 packets received
0 packets to unknown port received.
0 packet receive errors
119 packets sent
TcpExt:
5 TCP sockets finished time wait in fast timer
21 delayed acks sent
Quick ack mode was activated 10 times
31 packets directly queued to recvmsg prequeue.
15765 of bytes directly received from prequeue
105 packet headers predicted
17 packets header predicted and directly queued to user
36 acknowledgments not containing data received
11 predicted acknowledgments
0 TCP data loss events

Your suggestions are highly welcomed!
Thanks

Tcpdump intro and examples!

TCPdump is a very powerful command line interface packet sniffer.

It must be launched as root or with superuser rights because of the its use of the promiscuous mode or to be sure to have sufficent privilileges on a network device or a socket.

Wireshark (formerly ethereal) can be used as an alternative to TCPdump but with a GUI interface. Wireshark can be used to read the logs captured by TCPdump too.

1. TCPDUMP DOWNLOAD 2. TCPDUMP SYNTAX 3. TCPDUMP EXAMPLES

---------------------------------------------------------------------------

1. TCPDUMP DOWNLOAD:

To download TCPdump:

#apt-get install tcpdump
To see the TCPdump dependencies:

#apt-cache depends tcpdump
tcpdump
Depends: libc6
Depends: libpcap0.8
Depends: libssl0.9.8

To see the installed TCPdump version:

#apt-cache policy tcpdump
tcpdump:
Installed: 3.9.4-2ubuntu0.1
Candidate: 3.9.4-2ubuntu0.1
Version table:
*** 3.9.4-2ubuntu0.1 0
500 http://security.ubuntu.com dapper-security/main Packages
100 /var/lib/dpkg/status
3.9.4-2 0
500 http://ch.archive.ubuntu.com dapper/main Packages



---------------------------------------------------------------------------

2. TCPDUMP SYNTAX

Syntax: Protocol Direction Host(s) Value Logical Operations Other expression
Example: tcp dst 10.1.1.1 80 and tcp dst 10.2.2.2 3128
Protocol:
Values: ether, fddi, ip, arp, rarp, decnet, lat, sca, moprc, mopdl, tcp and udp.
If no protocol is specified, all the protocols are used.

Direction:
Values: src, dst, src and dst, src or dst
If no source or destination is specified, the "src or dst" keywords are applied.
For example, "host 10.2.2.2" is equivalent to "src or dst host 10.2.2.2".

Host(s):
Values: net, port, host, portrange.
If no host(s) is specified, the "host" keyword is used.
For example, "src 10.1.1.1" is equivalent to "src host 10.1.1.1".

Logical Operations:
Values: not, and, or.
Negation ("not") has highest precedence. Alternation ("or") and concatenation ("and") have equal precedence and associate left to right.
For example,
"not tcp port 3128 and tcp port 23" is equivalent to "(not tcp port 3128) and tcp port 23".
"not tcp port 3128 and tcp port 23" is NOT equivalent to "not (tcp port 3128 and tcp port 23)".





3. TCPDUMP USE

To display the Standard TCPdump output:

#tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

21:57:29.004426 IP 192.168.1.2.1034 > valve-68-142-64-164.phx3.llnw.net.27014: UDP, length 53
21:57:31.228013 arp who-has 192.168.1.2 tell 192.168.1.1
21:57:31.228020 arp reply 192.168.1.2 is-at 00:04:75:22:22:22 (oui Unknown)
21:57:38.035382 IP 192.168.1.2.1034 > valve-68-142-64-164.phx3.llnw.net.27014: UDP, length 53
21:57:38.613206 IP valve-68-142-64-164.phx3.llnw.net.27014 > 192.168.1.2.1034: UDP, length 36

To display the verbose output:

#tcpdump -v
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

22:00:11.625995 IP (tos 0x0, ttl 128, id 30917, offset 0, flags [none], proto: UDP (17), length: 81) 192.168.1.2.1034 > valve-68-142-64-164.phx3.llnw.net.27014: UDP, length 53
22:00:20.691903 IP (tos 0x0, ttl 128, id 31026, offset 0, flags [none], proto: UDP (17), length: 81) 192.168.1.2.1034 > valve-68-142-64-164.phx3.llnw.net.27014: UDP, length 53
22:00:21.230970 IP (tos 0x0, ttl 114, id 4373, offset 0, flags [none], proto: UDP (17), length: 64) valve-68-142-64-164.phx3.llnw.net.27014 > 192.168.1.2.1034: UDP, length 36
22:00:26.201715 arp who-has 192.168.1.2 tell 192.168.1.1
22:00:26.201726 arp reply 192.168.1.2 is-at 00:04:11:11:11:11 (oui Unknown)
22:00:29.706020 IP (tos 0x0, ttl 128, id 31133, offset 0, flags [none], proto: UDP (17), length: 81) 192.168.1.2.1034 > valve-68-142-64-164.phx3.llnw.net.27014: UDP, length 53
22:00:38.751355 IP (tos 0x0, ttl 128, id 31256, offset 0, flags [none], proto: UDP (17), length: 81) 192.168.1.2.1034 > valve-68-142-64-164.phx3.llnw.net.27014: UDP, length 53

Network interfaces available for the capture:

#tcpdump -D

1.eth0
2.any (Pseudo-device that captures on all interfaces)
3.lo

To display numerical addresses rather than symbolic (DNS) addresses:

#tcpdump -n

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

22:02:36.111595 IP 192.168.1.2.1034 > 68.142.64.164.27014: UDP, length 53
22:02:36.669853 IP 68.142.64.164.27014 > 192.168.1.2.1034: UDP, length 36
22:02:41.702977 arp who-has 192.168.1.2 tell 192.168.1.1
22:02:41.702984 arp reply 192.168.1.2 is-at 00:04:11:11:11:11
22:02:45.106515 IP 192.168.1.2.1034 > 68.142.64.164.27014: UDP, length 53
22:02:50.392139 IP 192.168.1.2.138 > 192.168.1.255.138: NBT UDP PACKET(138)
22:02:54.139658 IP 192.168.1.2.1034 > 68.142.64.164.27014: UDP, length 53
22:02:57.866958 IP 125.175.131.58.3608 > 192.168.1.2.9501: S 3275472679:3275472679(0) win 65535

To display the quick output:

#tcpdump -q

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

22:03:55.594839 IP a213-22-130-46.cpe.netcabo.pt.3546 > 192.168.1.2.9501: tcp 0
22:03:55.698827 IP 192.168.1.2.9501 > a213-22-130-46.cpe.netcabo.pt.3546: tcp 0
22:03:56.068088 IP a213-22-130-46.cpe.netcabo.pt.3546 > 192.168.1.2.9501: tcp 0
22:03:56.068096 IP 192.168.1.2.9501 > a213-22-130-46.cpe.netcabo.pt.3546: tcp 0
22:03:57.362863 IP 192.168.1.2.1034 > valve-68-142-64-164.phx3.llnw.net.27014: UDP, length 53
22:03:57.964397 IP valve-68-142-64-164.phx3.llnw.net.27014 > 192.168.1.2.1034: UDP, length 36
22:04:06.406521 IP 192.168.1.2.1034 > valve-68-142-64-164.phx3.llnw.net.27014: UDP, length 53
22:04:15.393757 IP 192.168.1.2.1034 > valve-68-142-64-164.phx3.llnw.net.27014: UDP, length 53

Capture the traffic of a particular interface:

tcpdump -i eth0
To capture the UDP traffic:

#tcpdump udp
To capture the TCP port 80 traffic:

#tcpdump port http
To capture the traffic from a filter stored in a file:

#tcpdump -F file_name
To create a file where the filter is configured (here the TCP 80 port)

#vim file_name
port 80
To stop the capture after 20 packets:

#tcpdump -c 20
To send the capture output in a file instead of directly on the screen:

#tcpdump -w capture.log
To read a capture file:

#tcpdump -r capture.log
reading from file capture.log, link-type EN10MB (Ethernet)

09:33:51.977522 IP 192.168.1.36.40332 > rr.knams.wikimedia.org.www: P 1548302662:1548303275(613) ack 148796145 win 16527
09:33:52.031729 IP rr.knams.wikimedia.org.www > 192.168.1.36.40332: . ack 613 win 86
09:33:52.034414 IP rr.knams.wikimedia.org.www > 192.168.1.36.40332: P 1:511(510) ack 613 win86
09:33:52.034786 IP 192.168.1.36.40332 > rr.knams.wikimedia.org.www: . ack 511 win 16527

The captured data isn't stored in plain text so you cannot read it with a text editor, you have to use a special tool like TCPdump (see above) or Wireshark (Formerly Ethereal) which provides a graphical interface.

To display the packets having "www.openmaniak.com" as their source or destination address:

#tcpdump host www.openmaniak.com

To display the FTP packets coming from 192.168.1.100 to 192.168.1.2:

#tcpdump src 192.168.1.100 and dst 192.168.1.2 and port ftp

To display the packets content:
#tcpdump -A
Packets capture during a FTP connection. The FTP password can be easily intercepted because it is sent in clear text to the server.

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ath0, link-type EN10MB (Ethernet), capture size 96 bytes
20:53:24.872785 IP ubuntu.local.40205 > 192.168.1.2.ftp: S 4155598838:4155598838(0) win 5840
....g....................
............
20:53:24.879473 IP ubuntu.local.40205 > 192.168.1.2.ftp: . ack 1228937421 win 183
....g.I@.............
........
20:53:24.881654 IP ubuntu.local.40205 > 192.168.1.2.ftp: . ack 43 win 183
....g.I@.......8.....
......EN
20:53:26.402046 IP ubuntu.local.40205 > 192.168.1.2.ftp: P 0:10(10) ack 43 win 183
....g.I@......`$.....
...=..ENUSER teddybear

20:53:26.403802 IP ubuntu.local.40205 > 192.168.1.2.ftp: . ack 76 win 183
....h.I@.............
...>..E^
20:53:29.169036 IP ubuntu.local.40205 > 192.168.1.2.ftp: P 10:25(15) ack 76 win 183
....h.I@......#c.....
......E^PASS wakeup

20:53:29.171553 IP ubuntu.local.40205 > 192.168.1.2.ftp: . ack 96 win 183
....h.I@.,...........
......Ez
20:53:29.171649 IP ubuntu.local.40205 > 192.168.1.2.ftp: P 25:31(6) ack 96 win 183
....h.I@.,...........
......EzSYST

20:53:29.211607 IP ubuntu.local.40205 > 192.168.1.2.ftp: . ack 115 win 183
....h.I@.?.....j.....
......Ez
20:53:31.367619 IP ubuntu.local.40205 > 192.168.1.2.ftp: P 31:37(6) ack 115 win 183
....h.I@.?...........
......EzQUIT

20:53:31.369316 IP ubuntu.local.40205 > 192.168.1.2.ftp: . ack 155 win 183
....h.I@.g...........
......E.
20:53:31.369759 IP ubuntu.local.40205 > 192.168.1.2.ftp: F 37:37(0) ack 156 win 183
....h.I@.h.....e.....
......E.

We see in this capture the FTP username (teddybear) and password (wakeup).


Please refer to this link for other useful examples of tcpdump: http://www.thegeekstuff.com/2010/08/tcpdump-command-examples/

Thanks.

nmap scan examples!

ping scan

nmap -v -sP 192.168.2.0/24 or nmap -sP 192.168.2.*


Starting Nmap 4.53 ( http://insecure.org ) at 2009-03-03 10:17 IST
Initiating Ping Scan at 10:17
Scanning 256 hosts [1 port/host]
Completed Ping Scan at 10:17, 0.61s elapsed (256 total hosts)
Initiating Parallel DNS resolution of 256 hosts. at 10:17
Completed Parallel DNS resolution of 256 hosts. at 10:17, 13.63s elapsed
Host 192.168.2.0 appears to be down.
Host 192.168.2.1 appears to be up.
Host 192.168.2.2 appears to be down.
Host 192.168.2.3 appears to be down.
Host 192.168.2.4 appears to be down.


UDP scan

sudo nmap -v -sU 192.168.2.0/24

T.C.P connect scan

Ex:-
sudo nmap -sT -p 80 192.168.2.42

Starting Nmap 4.53 ( http://insecure.org ) at 2009-03-03 10:24 IST
Interesting ports on 192.168.2.42:
PORT STATE SERVICE
80/tcp closed http
MAC Address: 00:1B:38:7D:84:A4 (Compal Information (kunshan) CO.)

Nmap done: 1 IP address (1 host up) scanned in 0.601 seconds


Ex:- nmap -sT 192.168.2.1-254 -p 1433-1435

syn stealth scan

Ex:- sudo nmap -sS -v 192.168.2.42
Starting Nmap 4.53 ( http://insecure.org ) at 2009-03-03 10:25 IST
Initiating ARP Ping Scan at 10:25
Scanning 192.168.2.42 [1 port]
Completed ARP Ping Scan at 10:25, 0.02s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 10:25
Completed Parallel DNS resolution of 1 host. at 10:25, 0.31s elapsed
Initiating SYN Stealth Scan at 10:25
Scanning 192.168.2.42 [1714 ports]
Completed SYN Stealth Scan at 10:26, 33.22s elapsed (1714 total ports)
Host 192.168.2.42 appears to be up ... good.
All 1714 scanned ports on 192.168.2.42 are filtered (1652) or closed (62)
MAC Address: 00:1B:38:7D:84:A4 (Compal Information (kunshan) CO.)

Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 33.809 seconds
Raw packets sent: 3373 (148.410KB) | Rcvd: 63 (2894B)

NB:- syn scan is used when you dont want much traffic sent


O.S Detection scan

Ex:- sudo nmap -O --vv 192.168.2.0/24
nmap -O -v 127.0.0.1


Other examples


nmap -v scanme.nmap.org
This option scans all reserved TCP ports on the machine scanme.nmap.org . The -v option enables verbose mode.
nmap -sS -O scanme.nmap.org/24
Launches a stealth SYN scan against each machine that is up out of the 256 IPs on the class C sized network where Scanme resides. It also tries to determine what operating system is running on each host that is up and running. This requires root privileges because of the SYN scan and OS detection.
nmap -sV -p 22,53,110,143,4564 198.116.0-255.1-127
Launches host enumeration and a TCP scan at the first half of each of the 255 possible eight-bit subnets in the 198.116 class B address space. This tests whether the systems run SSH, DNS, POP3, or IMAP on their standard ports, or anything on port 4564. For any of these ports found open, version detection is used to determine what application is running.
nmap -v -iR 100000 -Pn -p 80
Asks Nmap to choose 100,000 hosts at random and scan them for web servers (port 80). Host enumeration is disabled with -Pn since first sending a couple probes to determine whether a host is up is wasteful when you are only probing one port on each target host anyway.
nmap -Pn -p80 -oX logs/pb-port80scan.xml -oG logs/pb-port80scan.gnmap 216.163.128.20/20
This scans 4096 IPs for any web servers (without pinging them) and saves the output in grepable and XML formats.

Introduction to nmap

NMAP Overview

Port States NMAP will categorize ports as being in one of the following states:
  • Open – The port is accepting TCP connections and UDP packets. This means that an application is running that is using this port.
  • Closed – The port responds to NMAP probe requests but no application is using this port
  • Filtered – The port state cannot be determined because packet filters prevent NMAP probes from reaching the port
  • Unfiltered – The port is accessible but NMAP cannot determine if it is open or closed
  • Open | Filtered – NMAP cannot determine if the port is open or filtered
  • Closed | Filtered – NMAP cannot determine if the port is closed or filtered

Port Scanning Techniques

NMAP supports different methods of port scanning. These methods are called scan techniques. Each technique is tailored to solving a specific problem. Often times you will have to run several scans using different techniques in order to get a more complete picture of the host(s) you are scanning.
  • TCP SYN scan (-sS) – Can be performed on many thousands of hosts very quickly on a fast network with no firewalls. It starts to open a connection by sending a SYN packet, but it never finishes the connection. The response from this packet is used to determine the port status:
    1. A SYN'ACK response indicates that the port is open and listening
    2. A RST response indicates that the port is closed
    3. A no response or ICMP unreachable error will result in the port being marked as filtered
    TCP SYN scans are difficult to detect since a connection is never actually opened. This scan type uses RAW sockets and requires root access under UNIX. This is the default scan.  
  • TCP connect scan (-sT) – Uses the OS to establish a TCP connection to the host. This scan type is slower and has more overhead than a SYN scan. A TCP connect scan is the default when a SYN scan (RAW sockets) is not possible.  
  • UDP scan (-sU) – Sends a data less UDP header to every specified port. The response from this header is used to determine the UDP port status:
    1. An ICMP Unreachable error response indicates that the port is closed
    2. Other ICMP errors indicate that the port is filtered
    3. UDP bases services (DHCP, DNS and SNMP) may respond. This indicates that the port is open.
    4. If after several attempts of communication no response is received, the port will be marked as open|filtered. This could mean that packet filtering may be blocking communication with an otherwise open port. The version detection option (-sV) may be used in order to determine if ports marked as open|filter are actually open.
    UDP port scanning may be done at the same time as TCP port scanning in order to speed up the process.  
  • Custom TCP scan (--scanflags) - Custom scans allow advanced users to create a scan type tailored to specific needs. This is useful to create scans that will less likely be detected by intrusion detection systems.  
  • IP protocol scan (-sO) – This scan scans a host for the protocols it supports by cycling through the 8 bit protocol header of an IP packet.
NMAP offers the following additional scans. I list them here for completeness, but will not discuss them further.
  • TCP Null, FIN and Xmas scans – Uses a loophole in TCP RFC to determine if a port is open or closed.
  • TCP ACK scan – Used to map firewall rulesets. It cannot tell between open and closed ports.
  • TCP Window scan – Used to map firewall rulesets. It can tell between open and closed ports depending on the host being scanned.
  • TCP Maimon scan – Similar to the TCP Null, Fin and Xmas scans but exploits a slightly different TCP stack implementation detail specific to many BSD systems.
  • Idlescan – Scans hosts using packets with a “falsified” ip address such that the scan appears to originate from another host.
  • FTP bounce scan – Scans for ftp servers configured as ftp proxies.
Note: NMAP is an open source application and may be downloaded for free from insecure.org.

hping3 examples!

How to test the rules of your firewall by example using hping3.

In this how to I will be showing you a few ways you can test your firewall to see what is allowed and what is not.  I will be testing the rules of a WRT54G v2 router with the newest Linksys firmware.  These tests will be from the WAN since testing from the LAN would not be practical to someone trying to get through the perimeter.

The process in which we want to take is to first determine if something is actually at the ip address, second can we determine what is at the other end, and finally are there any open ports.
Let us start by simply sending a icmp echo command and see if we get a reply.
hping3 -c 1 -V -I eth0 -1 208.81.226.42
-c = count
-V = verbose
-I = Network Interface to use
-1 = ICMP packet
root@Ububox:/# hping3 -c 1 -V -I eth0 -1 208.81.226.42
using eth0, addr: 192.168.2.108, MTU: 1500
HPING 208.81.226.42 (eth0 208.81.226.42): icmp mode set, 28 headers + 0 data bytes
— 208.81.226.42 hping statistic —
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
No reply! Good so the router is not responding to pings from the WAN.  So how do we even know if anything is actually at that ip address?  What if we tried to do a half-open SYN connection to the http port (80).  Since most routers have an admin login (sometimes allowing remote login from the web).  Issue the following command:
hping3 -c 1 -V -I eth0 -s 8765 -p 80 -S 208.81.226.42
-s = source port
-p = destination port
-S = set the SYN flag in the packet
root@Ububox:/# hping3 -c 1 -V -I eth0 -s 8765 -p 80 -S 208.81.226.42
using eth0, addr: 192.168.2.108, MTU: 1500
HPING 208.81.226.42 (eth0 208.81.226.42): S set, 40 headers + 0 data bytes
— 208.81.226.42 hping statistic —
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
From the result we still get no reply.  Now lets try a little test of no flags which is called a null scan and we will see later that hping3 has an option built in for it.  If it works and something is there we should get a RST packet back.  Type the following hping3 command:
hping3 -c 1 -V -I eth0 -s 8765 -p 80 208.81.226.42
root@Ububox:/# hping3 -c 1 -V -I eth0 -s 8765 -p 80 208.81.226.42
using eth0, addr: 192.168.2.108, MTU: 1500
HPING 208.81.226.42 (eth0 208.81.226.42): NO FLAGS are set, 40 headers + 0 data bytes
len=46 ip=208.81.226.42 ttl=127 id=0 tos=0 iplen=40
sport=80 flags=RA seq=0 win=0 rtt=1.0 ms
seq=0 ack=1069346811 sum=fb6c urp=0
— 208.81.226.42 hping statistic —
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 1.0/1.0/1.0 ms
Success! We got a RST+ACK packet sent back to us.  So now we know for sure something is at the ip-address, but was this a fluke? Will the same result happen to a port that might not exist (port 3486).  Lets run the same test using a different non existing (hopefully) port.  So change the “-p 80″ to “-p 3486″ and lets see what happens.
hping3 -c 1 -V -I eth0 -s 8765 -p 3486 208.81.226.42
Same result we get a RST+ACK back again.  So now what?  We have made sure that some kind of equipment is there and it does respond.  Lets move on to another kind of test we will come back to the port testing later.  Lets see what happens when we do a icmp timestamp request (icmp type 13).
hping3 -c 1 -V -I eth0 -1 -C 13 208.81.226.42
-1 = icmp packet
-C 13 = icmp type 13 (timestamp)
root@Ububox:/# hping3 -c 1 -V -I eth0 -1 -C 13 208.81.226.42
using eth0, addr: 192.168.2.108, MTU: 1500
HPING 208.81.226.42 (eth0 208.81.226.42): icmp mode set, 28 headers + 0 data bytes
— 208.81.226.42 hping statistic —
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
No luck there.  If it would of succeeded you would seen the exact time set on the remote host.  Most routers/firewalls these days will not respond to these but at this point we do not know the type of equipment sitting at the other end so you never know so at least give it a try.
Next will try the icmp address subnet mask test.  What we hope will happen is this.  We send the packet the remote end replies back with the subnet mask for the local network. (the more we know is better)
hping3 -c 1 -V -I eth0 -1 -C 17 208.81.226.42
-C 17 = icmp address mask
root@Ububox:/# hping3 -c 1 -V -I eth0 -1 -C 17 208.81.226.42
using eth0, addr: 192.168.2.108, MTU: 1500
HPING 208.81.226.42 (eth0 208.81.226.42): icmp mode set, 28 headers + 0 data bytes
— 208.81.226.42 hping statistic —
1 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
No response from this either.  I was not expecting this to work, but again you don’t know till your try.  Now lets return to the port testing procedures and lets try testing using the different types of flags being set in the packet.  The first one we will try is the FIN flag.  In a TCP connection the FIN flag is used to start the connection closing routine.
hping3 -c 1 -V -I eth0 -s 8765 -p 53 -F 208.81.226.42
-F = set FIN flag
root@Ububox:~# hping3 -c 1 -V -I eth0 -s 8765 -p 53 -F 208.81.226.42
using eth0, addr: 192.168.2.108, MTU: 1500
HPING 208.81.226.42 (eth0 208.81.226.42): F set, 40 headers + 0 data bytes
len=46 ip=208.81.226.42 ttl=127 id=0 tos=0 iplen=40
sport=53 flags=RA seq=0 win=0 rtt=0.9 ms
seq=0 ack=1790142628 sum=76c9 urp=0
— 208.81.226.42 hping statistic —
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.9/0.9/0.9 ms
We received a RST+ACK back.  What we are wanting to see with this scan is not a reply back from the ip if we do not receive a reply then that port will be open.  If you firewall rules are working correctly though it should send a RST+ACK back even if the port is open.
So now lets move on to the next flag to set.  This next one will be using the ACK flag.  Using the ACK flag in a probe will help us determine if a host is at the ip we are probing.  If the host is not responding to pings from the outside then you can use the ACK flag to probe a port that is most likely open (aka 80,8080).
hping3 -c 1 -V -I eth0 -s 8765 -p 80 -A 208.81.226.42
-A = Set ack flag
root@Ububox:~# hping3 -c 1 -V -I eth0 -s 8765 -p 80 -A 208.81.226.42
using eth0, addr: 192.168.2.108, MTU: 1500
HPING 208.81.226.42 (eth0 208.81.226.42): A set, 40 headers + 0 data bytes
len=46 ip=208.81.226.42 ttl=127 id=0 tos=0 iplen=40
sport=80 flags=RA seq=0 win=0 rtt=0.9 ms
seq=559274943 ack=2094401506 sum=e61a urp=0
— 208.81.226.42 hping statistic —
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.9/0.9/0.9 ms
We are looking for a RST packet to be sent back from the host.  In this example we did receive a packet back and so we know that there is something at that ip.
Next scan to be used is known as the XMAS scan.  What this does is set the seqence number to zero and set the URG + PSH + FIN flags in the packet.
hping3 -c 1 -V -I eth0 -s 8765 -p 8080 -M 0 -UPF 208.81.226.42
-M 0 = set sequence number to zero
-U = set URG flag
-P = set PUSH flag
-F = set FIN flag
root@Ububox:~# hping3 -c 1 -V -I eth0 -s 8765 -p 8080 -M 0 -UPF 208.81.226.42
using eth0, addr: 192.168.2.108, MTU: 1500
HPING 208.81.226.42 (eth0 208.81.226.42): FPU set, 40 headers + 0 data bytes
len=46 ip=208.81.226.42 ttl=127 id=0 tos=0 iplen=40
sport=8080 flags=RA seq=0 win=0 rtt=0.8 ms
seq=0 ack=1 sum=727d urp=0
— 208.81.226.42 hping statistic —
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.8/0.8/0.8 ms
If the target device’s TCP port is closed, the target device sends a TCP RST packet in reply. If the target device’s TCP port is open, the target discards the TCP XMAS scan, sending no reply. Only if the firewall rules have not been configured to block this type of scan.
The next and final example of this how to will show you the NULL scan.  What this scan does is set the sequence number to zero and have no flags set in the packet.
hping3 -c 1 -V -I eth0 -s 8765 -p 8080 -Y 208.81.226.42
-Y = Null scan
root@Ububox:~# hping3 -c 1 -V -I eth0 -s 8765 -p 8080 -Y 208.81.226.42
using eth0, addr: 192.168.2.108, MTU: 1500
HPING 208.81.226.42 (eth0 208.81.226.42): Y set, 40 headers + 0 data bytes
len=46 ip=208.81.226.42 ttl=127 id=0 tos=0 iplen=40
sport=8080 flags=RA seq=0 win=0 rtt=1.2 ms
seq=0 ack=1350561991 sum=2c3c urp=0
— 208.81.226.42 hping statistic —
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 1.2/1.2/1.2 ms
If the target device’s TCP port is closed, the target device sends a TCP RST packet in reply. If the target device’s TCP port is open, the target discards the TCP NULL scan, sending no reply.
I hope you have learned a thing or two about using hping3 from these examples.  Hping3 is a great tool to have handy if you need to test security of your firewall(s) or IDS systems.  So just play around with the different flags being set or the different icmp or udp packets.  Different operating systems respond differently depending on the rules set so try different combonations of the flags and use tcpdump to see the whole packets being sent and received.  I will have more examples using hping3 in later articles so stay tuned and have fun.

Source: http://www.compuhowto.com/