Home > Articles > Security > Network Security

  • Print
  • + Share This
From the author of

Making Your System More Secure

Your Linux system does a great job of tracking access through its system logs, and denying access through the wrapper means you've just added some useful information to those logs. Change to the /var/log directory and list the files there with ls.

# cd /var/log
# ls

Here's a sample of what you should see there.

boot.log cron cron.1  cron.2  dmesg   httpd
lastlog  lastlog.1   maillog  maillog.1
maillog.2 
messages messages.1   netconf.log  
netconf.log.1
netconf.log.2 secure  secure.1 secure.2
secure.3 secure.4 spooler  spooler.1 spooler.2
uucp   wtmp   wtmp.1  xferlog  xferlog.1
xferlog.2 

Notice how the various log files have a dot-1, 2, 3, or dot-4 extension. This happens on a regular basis when your system runs its cron.daily files. Actually, cron.daily is a directory under /etc and contains a number of administration scripts that your system runs automatically. Without you lifting a finger, Linux uses these scripts to keep things tidy, such as rotating your log files so they don't grow to enormous proportions (like in the old days of Unix, when I had to walk 14 miles to school uphill in both directions and had to do my own log file pruning).

Have a look at those cron jobs, and familiarize yourself with what happens there. These are text files—you can more them, or use vi, or read them in emacs. While you are at it, notice that the system also has a cron.hourly, cron.weekly, and cron.monthly. A couple of those directories may be empty. The actual dates and times for hourly, weekly, and so on are in the /etc/crontab file.

From a cracker-detection point of view, your secure.? file will be of particular interest. If you turned off all access (other than your local network) as described in the last section, you can check for possible attempts like this:

grep refused /var/log/secure*

Here's the output of an actual attempt. I've blanked out the address for (ahem) security reasons.

Sep 12 07:52:42 netgate in.rlogind[7138]: refused
connect from 2??.?.5?.?42
Sep 12 07:52:52 netgate in.rshd[7139]: refused
connect from 2??.?.5?.?42
Sep 12 07:52:55 netgate in.rexecd[7144]: refused
connect from 2??.?.5?.?42
Sep 12 07:52:59 netgate imapd[7146]: refused connect
from 2??.?.5?.42
Sep 12 07:52:59 netgate in.fingerd[7142]: refused
connect from 2??.?.5?.?42
Sep 12 07:53:00 netgate ipop3d[7143]: refused
connect from 2??.?.5?.?42
Sep 12 07:53:07 netgate in.ftpd[7147]: refused
connect from 2??.?.5?.?42
Sep 12 07:53:10 netgate gn[7145]: refused connect
from 2??.?.5?.?42
Sep 12 07:53:22 netgate in.telnetd[7149]: refused
connect from 2??.?.5?.?42
Sep 12 07:56:34 netgate imapd[7150]: refused connect
from 2??.?.5?.?42

As you can see, my cracker tried several ports, or services, on my server, netgate, all of which were refused because of my wrapper's configuration and the resulting logs. I took the information from this log and emailed it to the security authority of the ISP the cracker was using.

Now, this doesn't mean the cracker will never get in, but you know they are trying and that's a great start.

You can also more some of the other files for additional information. The maillog files will give you a picture of what email messages are routing through your machine. If you'd like to see ftp transfers to and from your machine, have a look at the xferlog files. The other file of interest here is wtmp.

To view the contents of wtmp, use the last command—you cannot simply cat or more this file. However, you might want to pipe the output of last to more.

# last | more
 
fishduck ttyp6    nexus      Tue Sep 28
16:03  still logged in
birdrat ttyp5    speedy      Tue Sep 28
15:57  still logged in
root   tty1             Tue Sep 28
12:54  still logged in

This will give you the contents of the wtmp file, which details who logged in when, for how long, and whether they are still logged in. Make sure these are all people who you want to have access. Maybe you don't know who birdrat is.

If you haven't checked your logs in a while and you would like to see what is in wtmp.1, use this version of the last command:

# last -f /var/log/wtmp.1 | more

Also consider the state of the logs themselves. If you find too little activity in your logs, or if the logs tend to be sized at 0 bytes or missing altogether, that is also important information. Knowing something is amiss is the first step toward doing something about it.

In the next section, we'll visit the various services, discuss what they do, and decide whether you need them at all. As a treat, I'll show how to use a popular hacker tool, the port scanner, to better secure your own system.

  • + Share This
  • 🔖 Save To Your Account