summaryrefslogtreecommitdiffstats
path: root/doc/ulogd.sgml
blob: 3c29f9e7869c822360288b3ec65dd95133c61e38 (plain)
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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
<!doctype linuxdoc system>

<!-- $Id: ulogd.sgml,v 1.2 2000/11/20 19:40:14 laforge Exp $ -->

<article>

<title>ULOGD - the Userspace Logging Daemon</title>
<author>Harald Welte &lt;laforge@gnumonks.org&gt</author>
<date>Revision $Revision: 1.2 $, $Date: 2000/11/20 19:40:14 $</date>

<abstract>
This is the documentation for <tt>ulogd</tt>, the Userspace logging daemon.
ulogd makes use of the Linux 2.4 firewalling subsystem (netfilter) and the
ULOG target for netfilter.
</abstract>

<toc>

<sect>DESIGN

<sect1>CONECEPT
<p>
I want to provide a flexible, almost universal logging daemon for my netfilter 
ULOG target. It is not optimized in any way, the goal is to keep as simple as 
possible. These are my thoughts about how the architecture which is most 
capable of doing that:
<p>
<descrip>
<tag>Interpreter lugins</tag>
It should be possible to add plugins / runtime modules for new protocols, etc.
For example the standard logging daemon provides source-ip, dest-ip, 
source-port, dest-port, etc. Logging for variuos other protocols (GRE, 
IPsec, ...) may be implemented as modules.

<tag>Output plugins</tag>
... describe how and where to put the information gained by logging plugins. 
The easiest way is to build a line per packet and fprint it to a file. 
Some people might want to log into a SQL database or want an output 
conforming to the intrusion detection systems communication draft from the
IETF.

</descrip>

<sect1>DETAILS
<p>
The major clue is providing a framework which is as flexible as possible. 
Nobody knows what strange network protocols are out there :) Flexibility
depends on the communication between the output of the logging plugins 
and input of the output plugins.
<p>
Rusty advised me to use some kind of type-key-value triples, but I think
this is the total overkill and is too complicated for me to implement it 
in a reasonable short period of time. (3 hours later) Hmm... Rusty finally 
convinced me to use linked lists of type-key-value triples - and it wasn't 
that difficult.
<p>
Another issue is, of course, performance. Up to ulogd 0.3, ulogd did several
linked list iterations and about 30 malloc() calls _per packet_. This 
changed with the new 0.9 revision:
<itemize>
<item>Not a single dynamic allocation in the core during runtime. 
Everything is pre-allocated at start of ulogd to provide the highest
possible throughput.
<item>Hash tables in addition to the linked lists. Linked lists are only
traversed if we really want to access each element of the list.
</itemize>

<sect>INSTALLATION
<p>
<sect1>Linux kernel
<p>
First you will need a recent 2.4.x kernel. At the time this document was
written, 2.4.0-test11-pre5 was the latest development version. Ulogd should
work with all kernels &gt;= 2.4.0-test4.

<sect1>netfilter / iptables
<p>
In addition you need the latest iptables package, or even better: the latest
CVS snapshot. A description how to obtain this is provided on the netfilter
homepage <URL URL="http://netfilter.kernelnotes.org">.
<p>
ulogd is based on a special netfilter extension, called the netfilter ULOG
target module. You have to patch this extension into your kernel, as it
has not been integrated into the main kernel yet. To make this as easy
as possible, netfilter provides the 'patch-o-matic' subsystem. 
<p>
To run patch-o-matic, just type 
<tscreen><verb>
make patch-o-matic
</verb></tscreen>
in the userspace directory of netfilter CVS.

<sect1>ulogd
<sect2>Recompiling the source
<p>
Download the ulogd package from <URL URL="http://www.gnumonks.org/ftp/pub/netfilter"> and
untar it. 
<p>
If you want to build ulogd with MySQL support, type './configure --with-mysql'. You may also have to specify the path of the mysql libraries using '--with-mysql=path'. To build ulogd without MySQL support, just use './configure'.
<p>
To compile and install the program, call 'make install'.

<sect2>Using a precompiled package
<p>
I also provide redhat-6.2 and redhat-7.0 RPM's, available at <URL URL="http://www.gnumonks.org/ftp/pub/rpms/redhat-7.0/RPMS/i386"> and <URL URL="http://www.gnumonks.org/ftp/pub/rpms/redhat-6.2/RPMS/i386">.
<p>
Just download the package and do the usual 'rpm -i &lt;file&gt;'.

<sect>Configuration
<sect1>netfilter
<p>
Just add rules using the ULOG target to your firewalling chain. A very basic
example:
<tscreen><verb>
iptables -A FORWARD -j ULOG --ulog-nlgroup 32 --prefix foo 
</verb></tscreen>
<p>
To increase logging performance, try to use the
<tscreen><verb>
--ulog-qthreshold N
</verb></tscreen>
option (where 1 &lt; N &lt;= 50). The number you specify is the amout of packets
batched together in one multipart netlink message. If you set this to 20, the
kernel schedules ulogd only once every 20 packets. All 20 packets are then 
processed by ulogd. This reduces the number of context switches between kernel
and userspace.
<p>
Of course you can combine the ULOG target with the different netfilter match modules.
For a more detailed description, have a look at the netfilter HOWTO's, available on 
the netfilter homepage.

<sect1>ulogd
<p>
All configurable parameters of ulogd are in the configfile '/etc/ulogd.conf'
<p>
The following configuration parameters are available:
<descrip>
<tag>nlgroup</tag>
The netlink multicast group, which ulgogd should bind to. This is the same as given with the '--ulog-nlgroup' option to iptables.
<tag>logfile</tag>
The main logfile, where ulogd reports any errors, warnings and other unexpected 
conditions.
<tag>loglevel</tag>
This specifies, how verbose the logging to logfile is. Currently defined loglevels are: 1=debug information, 3=informational messages, 5=noticable exceptional conditions, 7=error conditions, 8=fatal errors, program abort.
<tag>plugin</tag>
This option is followed by a filename of a ulogd plugin, which ulogd shold load upon initialization. This option may appear more than once.
</descrip>

<sect>Available plugins
<p>
ulogd comes with the following plugins:
<descrip>
<tag>ulogd_BASE.so</tag>
Basic interpreter plugin for nfmark, timestamp, mac address, ip header, tcp header, udp header, icmp header, ah/esp header.
<tag>ulogd_PWSNIFF.so</tag>
Example interpreter plugin to log plaintext passwords as used with FTP and POP3. Don't blame me for writing this plugin! The protocols are inherently insecure, and there are a lot of other tools for sniffing passwords... it's just an example.
<tag>ulogd_OPRINT.so</tag>
A very simple output module, dumping all packets in the format
<tscreen><verb>
===>PACKET BOUNDARY
key=value
key=value
...
===>PACKET BOUNDARY
...
</verb></tscreen>
to a file.
<p>The module defines the following configuration directives:
<descrip>
<tag>dumpfile</tag>
The filename where it should log to. The default is <tt>/var/log/ulogd.pktlog</tt>
</descrip>

<tag>ulogd_LOGEMU.so</tag>
An output module which tries to emulate the old syslog-based LOG targed as far as possible. Logging is done to a textfile instead of syslog, though.
<p>
The module defines the following configuration directives:
<descrip>
<tag>syslogfile</tag>The filename where it should log to. The default is <tt>/var/log/ulogd.syslogemu</tt>
</descrip>

<tag>ulogd_MYSQL.so</tag>
An output plugin for logging into a mysql database. This is only compiled if you have the mysql libraries installed, and the configure script was able to detect them. (FIXME: how to do this)
<p>
The plugin automagically inserts the data into the configured table; It connects to mysql during the startup phase of ulogd and obtains a list of the columns in the table. Then it tries to resolve the column names against keys of interpreter plugins. This way you can easly select which information you want to log - just by the layout of the table.
<p>
If, for example, your table contains a field called 'ip_saddr', ulogd will resolve this against the key 'ip.saddr' and put the ip address as 32bit unsigned integer into the table. 
<p>
You may want to have a look at the file '<tt>doc/mysql.table</tt>' as an example table including fields to log all keys from ulogd_BASE.so. Just delete the fields you are not interested in, and create the table.
<p>
The module defines the following configuration directives:
<descrip>
<tag>mysqltable</tag>
Name of the table to which ulogd should log
<tag>mysqldb</tag>
Name of the mysql database
<tag>mysqlhost</tag>
Name of the mysql database host
<tag>mysqluser</tag>
Name of the mysql user
<tag>mysqlpass</tag>
Password for mysql
</descrip>

</descrip>
<sect> QUESTIONS / COMMENTS
<p>
All comments / questions / ... are appreciated.
<p>
Just drop me a note to laforge@gnumonks.org

</article>