Red Hat NETSCAPE MANAGEMENT SYSTEM 6.2 - COMMAND-LINE Guida di Installazione Scaricare il pdf (Pagina 36)

5.8. Logging

Linux does a lot of logging. Usually to more than one file. It is not always obvious what to make of all these

entries −− good, bad or indifferent? Firewall logs tend to generate a fair amount of each. Of course, you are

wanting to stop only the "bad", but you will undoubtedly catch some harmless traffic as well. The 'net has a

lot of background noise.

In many cases, knowing the intentions of an incoming packet are almost impossible. Attempted intrusion?

Misbehaved protocol? Mis−typed IP address? Conclusions can be drawn based on factors such as destination

port, source port, protocol, and many other variables. But there is no substitute for experience in interpreting

firewall logs. It is a black art in many cases.

So do we really need to log? And how much should we be trying to log? Logging is good in that it tells us

that the firewall is functional. Even if we don't understand much of it, we know it is doing "something". And

if we have to, we can dig into those logs and find whatever data might be called for.

On the other hand, logging can be bad if it is so excessive, it is difficult to find pertinent data, or worse, fills

up a partition. Or if we over re−act and take every last entry as an all out assault. Some perspective is a great

benefit, but something that new users lack almost by definition. Again, once your firewall is verified, and you

are perplexed or overwhelmed, home desktop users may want to disable as much logging as possible. Anyone

with greater responsibilities should log, and then find ways to extract the pertinent data from the logs by

filtering out extraneous information.

Not sure where to look for log data? The two logs to keep an eye on are /var/log/messages and

/var/log/secure. There may be other application specific logs, depending on what you have installed,

or using. FTP, for instance, logs to /var/log/xfer on Red Hat.

Portsentry and tcpwrappers do a certain amount of logging that is not adjustable. xinetd has logging

enhancements that can be turned on. Both ipchains and iptables, on the other hand, are very flexible as to

what is logged.

For ipchains the −l option can be added to any rule. iptables uses the −j LOG target, and requires its own,

separate rule instead. iptables goes a few steps further and allows customized log entries, and rate limiting.

See the man page. Presumably, we are more interested in logging blocked traffic, so we'd confine logging to

only our DENY and REJECT rules.

So whether you log, and how much you log, and what you do with the logs, is an individual decision, and

probably will require some trial and error so that it is manageable. A few auditing and analytical tools can be

quite helpful:

Some tools that will monitor your logs for you and notify you when necessary. These likely will require some

configuration, and trial and error, to make the most out of them:

A nice log entry analyzer for ipchains and iptables from Manfred Bartz:

http://www.logi.cc/linux/NetfilterLogAnalyzer.php3. What does all that stuff mean anyway?

•

LogSentry (formerly logcheck) is available from http://www.psionic.org/products/logsentry.html, the

same group that is responsible for portsentry. LogSentry is an all purpose log monitoring tool with a

flexible configuration, that handles multiple logs.

•

http://freshmeat.net/projects/firelogd/, the Firewall Log Daemon from Ian Jones, is designed to

watch, and send alerts on iptables or ipchains logs data.

•

Security Quick−Start HOWTO for Red Hat Linux

5.8. Logging 33

1 2 ... 31 32 33 34 35 36 37 38 39 40 41 ... 81 82

Commenti su questo manuale

Nessun commento

Red Hat NETSCAPE MANAGEMENT SYSTEM 6.2 - COMMAND-LINE Guida di Installazione Pagina 36

Commenti su questo manuale