On Wednesday 16 January 2002 14:38, you wrote:
It´s true, that you can use a 486 for Firewall, but a prefer to a P-II or AMD K6-2 as minium requieremnt for 1 Mbit. The problem ist not the traffic, but the syslog. We have serveral costumers, who are connected with 2 mbit. If someone portscan your system or tries an dos-attack, increased your system load dramaticly and the traffic stops :(
The syslog.conf manpage states that if a logfile is preceded with a "-" (like in
*.* -/var/log/allmessages
), then the syslogd will not call fsync() after a write() to this file. By consequence, the load will remain small.
Generally, it's a good idea to fsync() all logfiles especially if something really urgent has been logged (like a failing disk). Typically, such logs are from the kernel, which leads to believe that all kernel logs should be synced at once. Unfortunately, firewall messages are kernel logs as well, and then you have to change the perspective. If your syslogd takes to much time to sync the data to disk, the kernel messages ringbuffer (/proc/kmsg) might overflow and some messages might geht lost.
Doesn't -m limit with --limit and --limit-burst help matters considerably? Would it be a nice feature if klogd was extended, so that messages lower than console logging level, could be matched against RE patterns, like '^IN=.* OUT=.* MAC=' and '^APIC error on CPU', could be diverted to one of the local syslog facilites? Pattern matching is fairly efficient with modern CPUs, and under SuSE /var/log/messages and /var/log/firewall tends to collect far too much duplicated rubbish and irrelevant messages. The lack of an fscync(), explains issues with corruption in log files, I thought that was due to ReiserFS not flushing data. It would be nice to have really important kernel messages logged and saved immediately to help in post morterms. Rob