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–Lilt

The following small program illustrates some of the basic functionality in the libnids library. Lilt is a bare-bones TCP watching tool. It offers the user the capability to monitor the network for TCP connections and TCP port scans. Once Lilt locks on to a TCP connection, the user has the option of watching or terminating the connection. Connection watching is generally only useful if the connection in question is not transaction-oriented (in other words, HTTP) and largely consists of printable ASCII characters such as Telnet or Internet Relay Chat (IRC). Lilt is pretty stupid in that no post-libnids processing on the TCP streams occurs in order to decode or analyze the data—so only textual data prints as it is found in the data portion of the TCP packet. Another major drawback of Lilt is that it can only handle a single TCP connection at a time. As soon as it sees a connection that it wants to monitor, Lilt locks on to this connection and ignores all others until it ends—either naturally or as a result of the user deciding to terminate it (optionally, the user can discard the connection by pressing D). Connection termination (via spoofed RST packets) works for any TCP connection to which libnids locks on.

Lilt is both user-input and network-driven in that it performs synchronous input/output (I/O) multiplexing across the libnids network file descriptor and standard input. Once invoked, it sits and waits for TCP activity or commands from the user. The following sample invocation of Lilt shows its command summary:


tradecraft: ~# ./lilt
Lilt 1.0 [the littlest network watcher]
TCP monitoring callback registered
Monitoring connections to the following ports: 23 6667
Libnids engine initialized, waiting for events...
<?>
-[lilt command summary]-
[?] - this blurb
d - discard connection from scope
k - kill connection
[p] - display ports being monitored
[q] - quit lilt
[s] - statistics
w - watch connection
<q>
-[later dorkus!]-

The commands available to the user appear within brackets, and the other commands are unavailable until a connection comes into scope.

Lilt also accepts a single argument: a comma-delimited list of TCP well-known ports to monitor (if this argument is omitted as it was earlier, Lilt defaults to monitoring connections to port 23 and port 6667). The following example is a sample invocation of libnids across a relatively quiet network:


tradecraft: ~# lilt -m22, 23, 6667
Lilt 1.0 [the littlest network watcher]
TCP monitoring callback registered
Monitoring connections to the following ports: 22 23 6667
Libnids engine initialized, waiting for events...
-[Dec 30 11:44:03: TCP connection: 192.168.0.94.1680 -> 10.0.0.7.23]-
<?>
-[lilt command summary]-
[?] - this blurb
[d] - discard connection from scope
[k] - kill connection
[p] - display ports being monitored
[q] - quit lilt
[s] - statistics
[w] - watch connection
<w>
-[watching connection]-
%%%%& #'$& #' $PANSI"!"!
FreeBSD/i386 (dork.parade.net) (ttyp2)
login: rroooott
Password:110v4d&D
Last login: Mon Dec 31 02:03:22 from 192.168.0.94
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights
reserved.
FreeBSD 4.1-RC (DORK) #25: Tue Jul 17 17:57:52 EDT 2001
---------------------------------------------------------------------
- Unauthorized use of this computer is really frowned upon
- If anyone has any spare 20 sided dice pls send mail to root
---------------------------------------------------------------------
You have mail.
"Deliver yesterday, code today, think tomorrow."
dork:~> llss
Mail monster-manual.pdf
dork:~>
<k>
-[killing connection]-
-[Dec 30 11:45:08: TCP connection terminated]-
-[Dec 30 11:48:13: TCP connection: 192.168.0.94.1683 ->
10.16.10.22.6667]-
<k>
-[killing connection]-
-[TCP connection terminated]-
<s>
-[lilt statistics]-
TCP connections: 2
TCP connections killed: 2
Port scans detected: 0
-[Dec 30 11:54:41: portscan detected from 192.168.0.94]-
10.0.1.3:22
10.0.1.3:23
10.0.1.3:25
10.0.0.1:80
10.0.1.3:110
10.0.1.3:135
10.0.1.3.139
10.0.1.3.443
<s>
-[lilt statistics]-
TCP connections: 2
TCP connections killed: 2
Port scans detected: 1
<q>
-[later dorkus!]-

The first connection that Lilt saw that matched its filter list was a Telnet connection (TCP/23). Notice that because a connection was in scope, all of Lilt's commands were available. The user pressed W to watch the connection and nabbed the root login and password. Shortly thereafter, the user issued a kill command (pressed the K key) to terminate the connection. The user also immediately killed the next connection (established to an IRC server [TCP/6667]). Later on, a portscan was detected; the user checked statistics and then quit the program.

One small footnote to Lilt is its slightly inconsistent behavior on different platforms. Under OpenBSD, the user notices a lag between network activity and what is displayed in "real-time" on the Lilt console. Under Linux, this lag is non-existent due to differences in how the operating systems handle libpcap read timeouts. OpenBSD supports the timeout, and Linux does not. So what is happening is that Lilt, under OpenBSD, is technically being more efficient by attempting to read many packets at once—but it is a poor performer for a real-time application (BPF buffers packets inside the kernel). Linux, while utilizing more kernel time, provides a friendlier operation to the user.

In order to fix this problem, the application programmer would have to change the libpcap timeout to 0 and call an ioctl to set the BPF device to return immediately when a packet becomes available. At this writing, because there is no high-level primitive to change the libpcap timeout in libnids, in order to make this behavior more consistent the application programmer has to modify the libnids source directly and rebuild the library. We revisit this problem (with a portable solution) in Chapter 12.

/ 135