From time to time, I'll add some notes to this collection, either things that we have 
discussed in class, or thinks that we didn't have time to cover. The emphasis will 
primarily be upon security efforts, since security is generally a high priority for IT 
managers, and thus for those who would like to work for one.

Is your system under attack? Are hackers trying to break in? How would you know? What 
should you be looking for?

It's usually easy to tell after the attack succeeds. If you're Amazon, and your web page 
now says welcome to Barnes and Noble, there's no question. Of course, it's better to catch 
thye attack in progress and stop it. Since I'm sure you've already taken every precaution 
to keep hackers out, we can move on to the symptoms.

In the /var/log directory you should find a series of files named messages, like these:

ls -l /var/log/messages*
-rw-r--r--  1 root root     459 2008-11-23 07:47 /var/log/messages
-rw-r--r--  1 root root  892633 2008-11-23 04:21 /var/log/messages.1
-rw-r--r--  1 root root  178685 2008-11-16 04:21 /var/log/messages.2
-rw-r--r--  1 root root 3666936 2008-11-09 04:21 /var/log/messages.3
-rw-r--r--  1 root root 1231786 2008-11-02 04:21 /var/log/messages.4

First, observe the permissions. The sysadmin wants you to be able to look in the files. Not 
all do, so you may need special permission to proceed. Not here.

The next thing you'll notice is that the messages files are backed up every seven days, so 
that no one file becomes too large to work with. If you only look in the latest file, you 
won't find much. But if you look in them all, you'll get about one month's worth of data.

The seven-day file sizes can be suggestive. For example, the first week in November above 
was a busy week,  ut then it slowed down. Why? Could the attacks be from schools that have 
just returned from a quarter break?

When you examine the files, you might see something like this:

Nov 23 04:40:01 sextant syslogd 1.4.1: restart.
Nov 23 05:01:57 sextant -- MARK --

This tells you the current log file start date and time, and the time hack used to verify 
that the log is being recorded. The timestamp 04:40:01 suggests that there is s scheduling 
daemon that triggers the logs (and a number of other things.)  As installed, the scheduler 
looks, in part, like this:

# The crontab fields: min hour day-of-month month day-of-week
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null

The odd times were chosen in the hope that these scheduled tasks wouldn't conflict with 
other jobs users might be running.

Remember that we're discussing Slackware 10's default "out-of-the-box" installation. Your 
own system may well look different, but should be similar.

Now lets look at a log entry showing an attack:

Nov 16 13:46:32 sextant sshd[28223]: Illegal user admin from 168.176.197.2
Nov 16 13:46:32 sextant sshd[28223]: Failed password for illegal user admin from 168.176.197.2 port 38862 ssh2

Most of the fields are self-evident, like the date and time, the host name and the name of 
the aemon making the log entry, The next entry says that someone is trying to log in as 
'admin' from the address shown. The next line shows that they didn't have the correct 
password; it also shows the port and protocol they were using.

The password they tried was hashed and compared to the entry in the passwd file, which 
didn't match. Hence we don't see the password they tried.

A closing thought: we can scan the logs for all the account names tried for a period of 
time. This can be very revealing.

By the way, if you've looked at the end of these notes and seen the list of IP addresses of 
those who have, like you, read them, you can probably visualize how the list was made.

To relieve the unbearable tension of anticipation, here's one way to get the list:

# Note that while this is a shell script, the magic file and the web server 
# sees it as a cgi script. This script must be located in /usr/bin
cat /var/log/apache/access_log | grep blog.html | awk '{print $1}' | sort -u

We'll skip over the details of why it's a cgi script (not to mention what a cgi script is, 
how they're made, and how and why you would want to use one) as that's the topic of an entire 
class (IT 140.) It suffices to know that this script works the same way from the command line 
(that's you) and the web server (me.)

This nicely illustrates three of the principal Unix tools, awk, grep and sort. These 
programs, called filters because the change only the output, not the input. There are 
hundreds of them, but only 20 or so that the average sysadmin uses routinely.

Another question: Is it better to count web page accesses (the page counter at the bottom) 
or to count the separate addresses of people viewing the page? Clearly, we're doing both here, 
If a corporate client offered you 12 cents for each visitor, would that color your thinking? 
What if you wanted to know geographic region? You already have access to date and time of 
day in the messages logs, so that's not a problem. These are typical of the questions a 
sysadmin might expect from the marketing folks.

If you examine the source of the page showing unique IP addresses of viewers, you'll note 
something else that may be useful: cgi scripts produce output to the web page, but the 
browser cannot see the source code, only the output. So you may guess at how I'm counting 
the IP addresses, but you cannot be sure without a shell account. You can see that the 
script is called notes.cgi, but that's all.

Your turn: How would you determine the number of time the computer-bug was viewed? (Hint: 
your approach depends on how well you know the website; it harms your credibility if your 
first response is "What?" You may not be the webmaster (then again, maybe you are) but it's 
your server and you need to know what's on it. Naturally, until you take the class and 
have a shell account, you can only make intelligent guesses, but this is real life, 
not academia, and there's no penalty for guessing; sometimes you have no choice, and after 
all, with practice you may guess right...