[Logwatch] Suggestion/Request: feature for next version

NWCWEB Administration nwcwebadmin at nwcweb.com
Thu Apr 8 11:24:34 MST 2004

>-----Original Message-----
>From: ken at srv01.nwcweb.com [mailto:ken at srv01.nwcweb.com] On 
>Behalf Of ken
>Sent: Thursday, April 08, 2004 1:57 PM
>Subject: RE: [Logwatch] Suggestion/Request: feature for next version
>At 11:21 (UTC-0400) on Sun, 4 Apr 2004 NWCWEB Administration said:
>= Ken,
>= 	What is it that you're missing clues on?  Most of what
>= Logwatch contains comes from standard locations, so depending
>= on the box you have and it's OS you should be able to dig up
>= those clues reasonably easy.
>It would help greatly if the time field from the logs were left in the 
>logwatch output.  Yes, I could search the logs for the event 
>in question and find out the time, but if it were simply left in the 
>output, then it would save me from having to do the search.  Also, I could see 
>from the logwatch output if there was a relationship in time between messages 
>reported by logwatch.

	Gotcha, yes the times for the e-mails listed in that
section would be nice, but you may note that the original
ID for the e-mail should be in your Logwatch report.  When
we have an issue (which is rare that we need to dig in to
find the original log entry), we simply pull up the e-mail
logfile (depends on your server OS) and search for that
ID using pico.  Again, it's rare we have to do that, so again
I'd ask what issues are you hitting that require you to do 
such an intensive search?

	As far as spam e-mail, it should be come obvious from
any listings that pop up as to how to deal with them.  In our
case, we dump all nonexistent e-mail addresses into the aliases
file (located OS dependent) so they trigger a report that would
appear in Logwatch.  These include many basics like 'info', 
'contacts', etc. that spammers scan websites for or simply 
guess when they bomb servers.  Those triggers then show us the
skimpy Logwatch report entry that contains the IP of the source
(far easier than searching headers).

	We then run that IP through ARIN to get the main source,
and once we determine what that is it's rather easy to simply dump
the entire IP range into your firewall (we highly recommend APF by
rfxnetworks) and you never see it again.  Takes a bit of time to
build up a good list to block, but you'll find most of that spam
comes from outside the USA and from Hosting companies in the US
that the ARIN report provides the entire IP range to use in your
firewall.  Not only does that kill spam, but it also ID's places
hackers use to look for open doors and spam information they turn
into giant spam lists.

	Note that Spamassasin also works, but we feel it's labor 
intensive and tends to drop e-mails that are actually legitimate.
By IP range blocking all ports from spammers and hackers, that 
tends to put it to rest quickly and you're done with it.  There
are other options in APF you can use, but contact me offlist if
you decide to go that route.

	Also note that spam from Cable, DSL and other dynamic locations
is damn near impossible to block without nailing innocent customers.
That's where something like Spamassasin might be an excellent 
complimentary tool.

>= 	You can turn on more verbose details in Logwatch from
>= what we've found, but I'd hate to have that level of detail
>= every day as it would use up more resources that already 
>= exist.
>Yes, that is a nice feature and the one that I always use now 
>because it provides more of the information I am looking for.  It is nice that
>sometimes shows the command being run which produces the 
>logwatch output and sometimes the logfile from which the output has been
culled.  It
>would be very nice if, where possible, both the command names and the
>logfiles relevant to the logwatch output were reported... these in 
>addition to the output date/time field.
	Well we have to block our daily processes into a small
time window to leave the servers at maximum power for most
users, that ends up being at 4AM.  My MRTG reports on CPU usage
at 4am go sky-high, so adding these elements would burden things
even more.  That's just me, if it were added as a switch-selectable
feature then I'd second that option.

	Again, out of curiosity, could you detail a bit more of
what it is you're called on to research?  Is it spam reports, 
hacking/intrusion attempts or something else?  These answers
would help determine what tools might work better for you to 
solve the problems without the effort.  

	To us, just as an opinion, Logwatch was created and then subsequently
added to many Linux OS-based server setups (like Ensim Pro, which we use)
as a 'review' of the previous day's traffic without a huge rundown to
sift through.  It was designed to report basic elements of traffic
that the Admins should then follow up on, but it's up to them as to how
to do that.  I personally thought it skimpy when I saw it start up, 
but once I toyed with the switches and customization features inside
we were able to turn it into a valuable tool.  I don't think we could
live without it at this point!


      David J. Duffner
      VP Operations
      NWC Corporation
NWCWEB.com - Your Design & Hosting Solution!
Featuring Ensim Pro/Linux Servers, Hosted
Accounts, Web Design and e-Commerce services
NWC Corporation - Global e-Pay Solutions

More information about the Logwatch mailing list