Building.Open.Source.Network.Security.Tools.Components.And.Techniques [Electronic resources] نسخه متنی

This is a Digital Library

With over 100,000 free electronic resource in Persian, Arabic and English

Building.Open.Source.Network.Security.Tools.Components.And.Techniques [Electronic resources] - نسخه متنی

Mike D. Schiffman

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید







Sample Program–Knock

Knock, as shown in Figure 9.13, is a small tool that exhibits the port scanning active reconnaissance technique. It is a port scanner that scans both TCP and UDP ports at the behest of the user. It supports standard UDP port scanning in addition to TCP half-open scanning and TCP stealth scanning, using both FIN and XMAS packets.


Figure 9.13: Knock port scanner.

By specifying the -h argument or invoking it with no arguments, Knock dumps its usage as follows:


tradecraft: ~# ./knock
Knock 1.0 [TCP / UDP port scanning tool]
usage ./knock [options] target_host port_list
-h this blurb you see right here
-i device specify a device
-T timeout seconds to wait for a resonse
-t scantype scan TCP ports (1 == TCP SYN, 2 == TCP FIN, 3 == TCP
XMAS)
-u scan UDP ports

Like so many programs we have seen in this book, the user can specify a specific device to use. The -T option enables the user to specify a timeout value controlling how long Knock will wait for a response from a target host. The -t scantype option specifies a TCP port scan. The scantype field contains a user-specified number corresponding to the scan type. The -u option specifies a UDP port scan. After all the options are specified, Knock requires a target host (in either presentation format or numeric IP address) and a libnet-style list of ports to scan. A sample invocation of Knock is as follows:


tradecraft: ~# ./knock 10.0.1.9 22, 23, 80, 135-139
Knock 1.0 [TCP / UDP port scanning tool]
TCP Half-open-based port scan
<ctrl-c> to quit
port 22: open
port 23: closed
port 80: open
port 135: closed? (timeout)
port 136: closed? (timeout)
port 137: closed? (timeout)
port 138: closed? (timeout)
port 139: closed? (timeout)
2 ports open

Knock scanned ports 22,23, 80, and 135-139 on 10.0.1.9 by using the default scanning method, a TCP half-open scan. Ports 22 (SSH) and 80 (HTTP) returned SYN|ACK packets and were found to be open and ready for business while port 23 (telnet) returned an RST packet indicating that it was closed. The scanning probes to ports 135-139 timed out and appeared to be closed. Due to the fact that our other probes did not time out, this situation looks a little suspicious. Another invocation of Knock against the same ports using a different TCP scanning method enables us to investigate this situation a bit further:


tradecraft: ~# ./knock -t2 10.0.1.9 22,23,80,135-139
Knock 1.0 [TCP / UDP port scanning tool]
TCP Stealth FIN-based port scan
<ctrl-c> to quit
port 22: open
port 23: closed
port 80: open
port 135: closed
port 136: closed
port 137: closed
port 138: closed
port 139: open? (timeout)
3 ports open

We scanned the same ports with a TCP stealth FIN port scan. This time, ports 135-138 were closed while port 139 still timed out, but this time Knock thinks that it is open. The situation is that host 10.0.0.1 is probably behind either a filtering firewall or a router that is allowing certain types of traffic through, such as SSH and HTTP, but not any of the NetBIOS protocols that run on those ports. The filtering device prevents TCP SYN packets to these ports, which prevents any active TCP connections from being established and prevents our half-open scan from working correctly. Our stealth scan, however, uses TCP FIN packets (which can pass through the filter). Ports 135-138 then return RST packets indicating that they are closed, but port 139 times out. Recall that when performing a FIN scan, we can definitively determine which ports are closed while open ports will drop the FIN packets. In this case, the timeout indicates that the port is-probably open. Knock displays a question mark next to any timeouts, because they could be indicative of port status or possibly due to either network instability or filtering firewalls. It depends on the scan type and general network saturation levels.

Here is another invocation of Knock to scan UDP ports on a different host:


tradecraft: ~# ./knock -u 192.168.0.131 10-20,111
Knock 1.0 [TCP / UDP port scanning tool]
TCP Stealth XMAS-based port scan
<ctrl-c> to quit
port 10: closed
port 11: closed
port 12: closed
port 13: closed
port 14: closed
port 15: closed
port 16: closed
port 17: closed
port 18: closed
port 19: closed
port 20: closed
port 111: open? (timeout)
1 port open

This time, a UDP scan for ports 10-20 and 111 executes against 192.168.0.131. Ports 10-20 returned ICMP port unreachable packets, indicating that they are closed, while port 111 (RFC) did not receive a response and timed out. Remember that UDP port scanning, like the FIN scan mentioned earlier, times out when a port is open. In this case, however, a firewall or router could filter the port and Knock would not be capable of telling the difference. The only way to be sure would be to craft a legitimate RFC packet and send it to 192.168.0.131 on UDP port 111.

/ 135