Log Files and Linux.
by Isaac

        Ok.  Adrian asked me to write up a quick synopsis of the "lecture" I gave at the first meeting.  This is pretty basic stuff.  So if you already know how Linux log files work, don't expect to learn anything new or enlightening here.

        Most versions of Linux, as far as I'm aware, use syslogd as their logging utility.  syslogd is a fairly easy tool to learn and use.  Its configuration file resides in /etc/syslog.conf.  This is how it is on RedHat and more then likely any of the other systems.  Your mileage, may of course, vary.  If you open up this file, you'll see a little bit of information.  I'll try and explain it as well as I can.  The first thing that logs in mine that I see is:

*.info;mail.none;news.none;authpriv.none;cron.none              /var/log/messages

If you do a man on syslog.conf you'll get a lot more information about this.  However, if you are lazy, I'll do the explanation.  The loggable "things" are these.
auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, syslog, user,  uucp and local0 through local7.  The *.info means "Log info from all of these."  However, after that, it says mail.none;news.none and so forth.  What that means when all put together is "Log everything from these EXCEPT these things that are following it with '.none' behind them".  So inside your /var/log/messages, you'll get a lot of info.  Another line contains:

authpriv.*                                              /var/log/secure

All this means is log everything that authpriv does to /var/log/secure.  You can also redirect to different devices if you wish.  You could log everthing to the printer if you want by piping the information there.  Also, you could log everything to your console by pointing it to /dev/console or /dev/ttyS*.  Or anything of that nature.  All pretty simple.  Ok.  We understand how the log files work now, right?  Good.  Time to move on.

Now, if you are curious about which log files are important, feel free to look in your /etc/syslog.conf (May have a different location.  Do a find or a locate on syslog.conf and that'll get you on the right track.  Probably.)

Now, another thing.  Why doesn't this file contain anything about httpd?  Surely that is being logged somewhere right?  Well, it turns out that a lot of programs deal with their own logging.  Apache is one of those.  In your httpd.conf file you specify where you are logging things.  On RedHat, the httpd.conf is usually stored in /etc/httpd/conf/httpd.conf.  Do a locate / find on httpd.conf to be sure though.

My first log location is this.
ErrorLog /var/log/httpd/error_log.  Pretty simple, right?  Yes.  It is.  Then you can change your log level as well.  Make it do different things.  Very exciting yet more indepth then I want to get.  I just want to mention now the access log and the custom logging of Apache and that'll be done for Apache for the time being.  

CustomLog /var/log/httpd/access_log combined.

        This shows any hit to the main website that isn't being redirected to a customlog.  Now it is time to show you how to set up custom logs.  You can use CustomLog very well for virtual hosts and things of that nature.  Find out who is hitting which site and such.  Here is an example of a very stripped down VirtualHost entry.

        Pretty basic but shows some of the logging features.

        Ok.  Now you know where log files are being kept and how to set up your own log files?  What do you do with the log files once you have them?  That's a good question.  You look at them for any unusual activity.  Or, as Adrian suggested, you could set up a program that automatically keeps you informed.  Tripwire used to be a good one.  I'm not sure how good they are anymore though as I don't use them, personally.  I used them a looong time ago though.  Logwatch isn't that bad either.  It'll get the job done.  Thingsyou are looking for inside the log file vary.  Do you have cgi/sql on your box?  Then maybe you should be looking for some SQL injection exploits.  You can tell those easilly.  As they will look like people trying to run odd SQL commands on your box.  Things you didn't program in there.  Therefore they are easy to notice.  Also, you need to make sure that your CGI isn't exploitable.  Also that you are running a current version of Apache.  Things like that.

        If anyone wants any more information on a particular point, feel free to ask.