One easy way to DoS some firewalls is to flood their log files with messages until the partition fills up and the firewall either fails open or quits. As well, many firewalls have evidence of attacks in their logs that are ignored because of inadequate log processing. Logging everything is OK but looking at those logs is more important. A moderate size site will easily have 1GB of log files a day. You can't scan that with the naked eye so some form of digest needs to be created. Most of the summary programs that do exist (Webtrends is one) are more oriented to usage accounting than security analysis. Swatch has some features but doesn't handle all the logfile formats.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mikael Olsson Sent: Sun April 28 2002 08:02 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [OT] Re: Syslogd capacity and disk i/o (Was: Re: PIX logging) Rafi, Rafi Sadowsky wrote: > > We're getting rather off topic - so lets take this off > the list - OK ? Hm, no, I think this is actually very on-topic, given that one of the most important aspects of firewalling is logging, and that many firewalls send their logs through syslog. > Quote from syslog.conf(5) man page on a RedHat system: > --- > You may prefix each entry with the minus ``-'' sign to omit syncing the > file after every logging. Note that you might lose information if the > system crashes right behind a write attempt. Nevertheless this might give > you back some performance, especially if you run programs that use logging > in a very verbose manner. > --- > > I read that as the default being flushing after every packet ... :-( Yes, the default in the good old plain syslogd is flushing the output stream after every packet written. For any serious firewalling, I think that this blows. Yes, the argument FOR flushing after every packet is "but if the log server crashes, you'll lose the last couple of packets". I think this is a bogus argument. If the server crashes, you'll lose MANY packets. > Also under some OS's(I don't recall which) syncing a large (log)file > takes *much* longer than a small file - combine that with syncing after > every log message and "painful" would be quite an understatement ... The syslog server I was talking about earlier, the one that was receiving about 1 GB of logs daily, was running at _very_ high loads before we disabled forced flushing. In fact, I'm ready to bet that it was losing packets constantly just because the input UDP queue filled up. "lsof" was showing ridiculously high input queue lengths at times -- upwards of 64KB, IIRC. This in and of itself would, IMHO, constitute a forceful argument for not flushing the output file after every write. On a related note, I'd like to say that the default *nix syslogd and spin-offs may not be the best one to handle firewall logs. If nothing else, I always curse loudly over its config file format. Somehow, one always forgets to exclude the firewall log data from one or more of the lines, and end up with two or three gigabytes of logs daily instead of "just" the one. Argh. And this brings me to the topic of log rotation. Just _how_ much fun is it to kill your syslogd process in order to be able to rotate your logs properly? I've been trying out syslog-ng for a year or so, and it has some nice features like being able to name the output file according to the current date (gives you "atomic" log rotation with zero effort), and a filtering logic that, to my mind, is far easier to get right than the old syslogd.conf. My main concern with it is that it is under quite heavy development, and an episode of me accidentally upgrading to a devel branch (the FTP tree wasn't all-too-clear on which was what) and having it crash on me about 5-10 times a day sort of made me leery of using it for anything _really_ serious. But then again, I'm a distrustful sort of guy when it comes to these things. I've been toying with the idea of writing a specialized syslogd that ONLY handles remote logs, ONLY writes to date-tagged output files, and does so efficiently with a minimum amount of fuzz. Leave the fancy triggers and log-to-SQL-servers to others. I don't know. Maybe such a syslogd already exists. (Please tell me if it does; I'd switch almost instantly) (OK, I'd audit the code first, so shoot me -- I'm like that :)) Some people like being able to specify regular expressions in the syslog receiver itself (a'la syslog-ng) and trigger external programs to take action. I don't. I much prefer being able to run my analysis scripts at pre-defined intervals and avoid silly situations like a regex triggering ~50 new processes a second. Ouch. I don't know. Maybe I'll actually get around to doing it some day. Regards, Mikael -- Mikael Olsson, Clavister AB Storgatan 12, Box 393, SE-891 28 �RNSK�LDSVIK, Sweden Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05 Fax: +46 (0)660 122 50 WWW: http://www.clavister.com _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
