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

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

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

Mike D. Schiffman

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

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

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







Sample Program–Descry

Descry, as shown in Figure 11.1, is a small tool that exhibits the network intrusion detection defensive technique. It is a port scan detection tool that attempts to identify TCP port scans to open ports across a network segment by using a state transition analysis of TCP session initiation and teardown.


Figure 11.1: Descry network intrusion detection tool.

Descry, unlike many conventional implementations of similar tools, works in a sophisticated manner to uncover TCP port scans. Consider the TCP port scan detection functionality inside libnids, which works by using a time-based threshold model that sounds an alarm if x number of TCP packets are received in y number of seconds. Descry instead appr0ximates a finite state machine and keeps a limited state of TCP connections and can detect TCP port scans, often with the first offending probe. The program's logic, as shown in Figure 11.2, is actually rather simple.


Figure 11.2: Descry program logic.

After initialization, Descry begins capturing TCP packets. When it sees a SYN|ACK, it adds the connection to its state database. The SYN|ACK is the second packet in the three-way handshake, indicating that a service is listening on the particular TCP port and responding to a TCP session request (a SYN). When Descry sees an RST, RST | ACK, or FIN | ACK, it checks its state database for a matching connection. If a connection is found, and the TCP session close request is coming from the initiating side of the connection (the client), it checks to see whether the sequence number of the connection has incremented by more than one. If the sequence number has not incremented more than one, this situation is Chapter 9: the scanner sends a SYN to a port and a SYN | ACK is returned, indicating that the port is open. Nominally, this process completes the half-open scan process for that port, and the scanner moves on to the next port. Under the covers, however, the underlying operating system upon which the half-open scanner is running receives and processes this SYN | ACK. Because the half-open scanner forges the SYN | ACK packet and no state exists for the connection, the operating system has no choice but to send an RST back to the scanned system. This behavior is hard to prevent without egress filtering or kernel modifications to the scanning host. To Descry, this state is the same state transition as earlier, and it flags it as a possible port scan.

The major advantage of this model is that it is state-based, not time-based. There is no number of packets over a time threshold to tune in order to properly detect port-scanning activity. Furthermore, this method enables the detection of "single shot" port scans, where the attacker connects to a single service to see whether it is listening in order to target it for subsequent attack. Note that Descry does not attempt to detect TCP connection attempts to closed ports. There are several reasons why it limits what it tries to detect. Although detecting possible port scans to closed ports is easy (SYN from the initiator followed by RST sent from the server), this condition happens a lot in the real world without the presence of port scanners and therefore is rife with false-positive detections. Many available NIDS detect attempts to closed ports well enough, and it is just less important to detect that someone is looking for a service that is not running on your hosts than someone who is looking for services that you are running. Also, if a server uses a program such as tcpwrapper to provide network connection access control based on the IP source address, the server might close a TCP connection before the client sends any data or a port scan program gets the chance to terminate the connection. In this case, Descry does not detect the connection as a possible port scan. This behavior is completely appropriate given that it was the server's choice to terminate the connection, and the access control program should log the offender's address information.

Descry keeps all of its TCP connection state in a PATRICIA (practical algorithm to retrieve information coded in alphanumeric) trie. PATRICIA tries are somewhat like a combination of binary trees and hash tables but with an optimization that makes it efficient to use a large lookup key space with sparse data. These features make PATRICIA tries a well-suited data type for storing and searching network connections, because TCP connections are uniquely identifiable by the following tuple: source IP address, source TCP port, destination IP address, and destination TCP port. Given that IP addresses are 32 bits and TCP ports are 16 bits, the identifying tuple is 96 bits. That is a lot of search key space. Obviously, the program will never monitor 2% active connections at once, so creating a hash table to store and search the TCP connections would be prohibitive or clumsy—and comparing two 96-bit values to make decisions for binary trees would be inefficient. PATRICIA tries offer a fast and efficient solution to these problems.

By specifying the -h argument, Descry dumps its usage as such:


tradecraft: ∼# ./descry -h
Descry 1.0 [TCP port scan detection tool]
usage ./descry [options] (-i and -f are mutually exclusive)
-a monitor all hosts in the same segment
-i interface specify device or
-f capture file specify tcpdump capture file
-s log to syslog instead of stderr

By default, Descry monitors only the local host on which it is invoked. To change this behavior and have it monitor the entire collision domain, specify the -a option (which puts the interface into promiscuous mode). Like every other program (save one) in this book, the -i option specifies an interface to usefor network activity. Unlike any other program in this book, however, Descry also has the option to read from a libpcap savefile with the -f switch (which is mutually exclusive from the -i switch). Finally, the user can choose to have the program log port scan warnings to syslog rather than to the screen with the -s switch. A sample invocation of Descry is as follows:


tradecraft: ∼# ./descry -a
Descry 1.0 [TCP port scan detection tool]
[May 27 23:21:15] TCP probe from 66.123.162.116:54112 to
66.123.162 118:25
[May 27 23:25:02] TCP probe from 66.123.162.116:1923 to
66.123.162.118:23
[May 27 23:45:28] TCP probe from 66.123.162.116:9838 to
66.123.162.118:13
[May 28 02:05:00] TCP probe from 66.123.162.116:2012 to
66.123.162.118:80
[May 28 05:41:01] TCP probe from 66.123.162.116:4001 to
66.123.162.118:139
^C
tradecraft: ~#

Descry found five connections that seemed suspicious, none of which adhered to any time or port grouping convention.

/ 135