Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.