-
Notifications
You must be signed in to change notification settings - Fork 64
/
MISC
60 lines (53 loc) · 3.35 KB
/
MISC
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
====================
libnids-1.26
====================
1. Building
-----------
Libnids uses libpcap (can be retrieved from
http://www.tcpdump.org/release/) and libnet (available at
http://www.packetfactory.net/libnet). All credits to autors of these libs.
As already mentioned in README, currently libnids will compile on
Linux, any *BSD and Solaris. WIN32 port is mantained separately.
In order to build libnids, issue "./configure;make" command in top
directory. Library files libnids.so and libnids.a should be created in "src"
directory. "make install" will install library and header files. You may
wish to consult "./configure --help" output for available options.
2. Limitations
--------------
In their paper, T. Ptacek and T. Newsham observed that various
operating systems implement IP stack differently and can interpret
differently the same packet. It means that having seen a IP packet, NIDS has
to interpret it with regard to receiving operating system type. A perfect NIDS
E-component should possess knowledge on all operating systems network
implementation oddities. I don't know any actual NIDS implementation that
takes the previous into consideration.
Libnids 1.0 was meant to reliably emulate behavior of Linux 2.0.36
kernel. Thanks to libnids testing, some bugs in 2.0.36 networking code were
found. One of them enabled an attacker to perform blind TCP spoofing against
2.0.x kernels, including 2.0.36 and 2.0.37 (that is NOT the vulnerability
discovered by NAI; see my posting to Bugtrag from beginning of August 99). Info
on spotted bugs was submitted to Linux kernel mantainers on 25th May 99 (before
the release of 2.0.37), but none of them got fixed. File PATCH contains diffs
against 2.0.37, which stop blind spoofing attack and one of data insertion
attacks (now its equivalent is incorporated into Solar Designer's
secure-linux-0.9 patch). Currently, libnids predicts 2.0.37 behavior as
accurately as possible (with some unevitable exceptions - see my postings to
Bugtraq from beginning of August 99). In extreme conditions, libnids can
incorrectly emulate actions of other operating systems. However, libnids
should cope with simple attacks (like these implemented in fragrouter 1.3)
targetted at any OS type.
All NIDS are vulnerable to DOS attacks. Libnids uses efficient data
structures (i.e. hash tables) to minimize risk of CPU saturation. However, all
NIDS (including ones based on libnids) has to define some resources (most
notably, memory) limits. A determined attacker can attempt to make libnids use
up all of its memory, which can result in dropping some data. Libnids will
report such condition via its D-component interface.
3. Why does libnids emulate 2.0.x kernel instead of 2.2.x ?
-------------------------------------------------------
First of all, libnids development started when 2.0.36 was the current
stable kernel. Moreover, some people still prefer to use 2.0.x kernels, one of
the reasons being the fact that there is still no Solar Designer
non-executable stack patch for 2.2.x (not released oficially until July 99).
Finally, 2.2.x kernels are highly configurable during run-time (for instance
it's possible to change via proc interface the amount of kernel memory devoted
for IP fragments queuing), which generally makes them unpredictable.