Unix logfiles

We'll discuss the unix logfiles, how the administrator of the system can secure the system enough to have log files containing trustful and reliable information. We'll also discuss the possibilities for the hacker to trick the system logfiles and delete the traces of his activities. As always, I'm trying to discuss the things from 'both sides of chessboard'. Hackers and administrators are all the same, most of good and security-minded admins did some annoyance in past by hacking. In any case, if someone wants to secure his system well, its really important to understand things from both sides.


Adminstration of system logfiles guarantees the unix systems syslogd daemon. this software has been around for a while, in fact, it hasn't been changed really in principle within last 4-5 years. because of that, syslogd is almost identical at all commercial and noncommercial flavors of unix. all of them grew from old BSD sources. But the difference is in the way its defaultly configured at particular distribution. At fresh installation of AIX or Solaris, syslogd logs almost nothing by default. Its because commercial UNIX stations are still used for the purposes inside the company's intranet, rather than as Internet servers. But many times, when they're decided to serve as Intranet servers, administrators often do not configure syslogd for this kind of purpose. Distributions of Linux and FreeBSD are usually quite-well pre-configured. However 'quite-well' is often not enough anyway. Here comes a few possibilities how to improve security of logging:

Logging to remote server

If you start syslogd with '-r' switch, it enables you to forward the log entries to another machine. You need to add into /etc/syslogd.conf a line

*.* @loghost

and all of the logs will be stored at the machine loghost as well. Thus, in case anyone compromises your system, and deletes the log files, you can check the logs at 'loghost' machine (ofcourse, supposing it wasn't hacked as well). If there is more unix machines in your locality, as it is usually at the ISP's, its a good idea to dedicate a separate machine just to store system log files of all the other servers. This may really be just some old unused i386 computer, and it should be totally secured -- no running daemons, no remote access, no mail, nothing, except the console access. Such machine is not only perfectly secured, but its also useful to have all server's logs at one place, if the adminstrator needs to dig some information about the servers and network activity.

Logging to console

Any script kiddie is capable of deleting file. For this you can print the log entries to the terminal. Also, it's kinda useful to have such report by hand visible directly at the terminal in realtime. You can do that in linux with :

*.* /dev/ttyp12

Sure, its not so hard to trick that, its enough for hacker after he compromises the machine, to edit logs, delete the traces, followed by something like 'tail -100 /var/log/messages >/dev/ttyp12', and root will have faked information at the terminal. But honestly, nowadays, when the internet is just full of wannabe hackers who do not bother to peek into /etc/syslog.conf, it's highly probably that under-average wannabies won't notice that logs are logging to console (translator's note: until they read this article!). Regular script kiddie, who can just run exploit code from shell, can be tricked very easy by setting up syslogd to log to some unusual directory. In general we could say, if you configure your server daemons differently from default system settings, it may confuse hacker enough, that he won't be able to delete his traces. And for the hackers, there's a good rule to read carefully important /etc files, and to know how this system configured and where the important files are. To rely on default settings, may be for hacker a deadly mistake.

Kernel modifications

linux has the possibility to set up a kernel in such way, that some of the files wouldn't be deletable or modifiable, just allowing append, as described in one of phrack zines in the form of kernel patch.

Syslogd with encryption?

I have been thinking for a long time about syslogd version, that would encrypt the stored log files. I think it wouldn't be that hard to do, just to use some of regular DES libraries for example.. I doubt I'm the only one with this idea, but I haven't seen such syslgod version anywhere yet.

Binary log files

Another type of logs are binary logs: utmp, wtmp, lastlog, and acc. utmp (mostly /var/run/utmp) including the information about momentary logged users. wtmp (usually /var/log/wmp) holds information about who was logged from where, when and how long in the past. lastlog (/var/log/lastlog) holds the information about last log in of every user. acc (/var/log/acc) has info about all running programs. these files have binary structure, where you can study their formats in documentation available for each of them (for ex. # man utmp). However, there are trace wipers available for almost every platform. Still, many administrators trust the information stored in these binary logs. many of them have even no idea that they're editable, thus, if you wipe your traces from these files, you can trick a lot of administrators.

False traces

Regarding the aspect of psychology with adminstrators, in my opinion, its a better idea to create false traces, rather than just delete all the traces after the attack. For this purpose the ingenious bebet's wtkill, which allows to add records to wtmp. Think of this example: you hack a system and change index WWW page of some website there. Shocked root runs to the server and starts to dig in the logs. If you wiped all traces after you, it won't make him sleep well, and he'll just won't stop searching and searching and searching, until he really finds something that could be used to trace you. So by a psychological point of view, it is best to create some false log entries into /var/log/wtmp, messages, .bash_history, etc.. all information must of course fit other perfectly.

By this hack you can usually let your tools and helping scripts run on his server, he will find the false log entries, and being satisfied enough, he'll start to trace the attacker the way you align him. A good idea is to create false traces leading somewhere to another part of the world, to some university lab PC, where there is public access for students. This way, all the adminstrator can do is to exchange a couple of helpless e-mails with innoncent admins of that mentioned lab PC. Or, just create the traces leading to some gigantic US provider (AOL, AT&T, etc.). Even if root wants to trace the attacker, he'll be annoyed and frustrated soon enough by a 'nonpenetrable wall' of communication with AOL operators beaurocracy. If you ever decide to leave on the hacked machine a fake .bash_history, I strongly suggest to make it look like the bash was used by total lamer :) Put in repeatedly incorrectly typed commands that will 'paint a picture' of a real idiot, who found a remote root exploit script on the web, and tried it on this system. It's always a big advantage, if your opponent thinks that you're weaker and more stupid that you really are.

Shell history

After cramming you with various hackers' methods, let's go back to some boring technical things :) In terms of security it's good for an administrator to set the users login at least 500 lines of shell history. This history may be often be used by admin as a source of information in the case of an attack. Not every hacker knows how to turn logging of history off. Most elegant way is to change shell environment variables immediately after login, to not log the history.

For example in bash:

export HISTFILE=/dev/null

eventually by changing the values of HISTSIZE or HISTFILESIZE, for more info check '# man bash' or '# man tcsh'


A really funny way of logging is snooping - monitoring remote shell access to your server in real time. In linux, there is for ex. telnetsnoopd. For this purpose, by which you need to replace your telnetd, this program is a part of standard slackware distribution. Sure there are kernel modules that allow snooping, just dig the net.

For a hacker the snooping can be a source of many funny stories. many of regular users, even admins, don't know that such snooping tools exist. That's why, if you jump to someone's terminal session and write directly to his shell, he is going to deem you as ultra-genius hacker, and his jaw will fall down by surprise! There are numerous funny stories related to snooping. my favorite is when I once jumped into a telnet session of a friend of mine who was arguing with his former girlfriend via IRC. I was watching their quarrel for a while. After some time, he wrote to his gf that he'd be gone for a while (away of computer). Right after I entered his telnet session continuing conversation with his girlfriend (she's thinking that its my friend still), and I managed to get 'myself' (persuading I'm my friend) back together with the former girlfriend that way, that when he (having no idea about the conversation) came to her to dorm room, she was waiting for him... horny, wet and open :) Sure, it was a big surprise for my innocent and none suspecting friend :)

Other logs

Damn, yes I know, I promised pure technical information. Ok, ok. Except the syslogd and binary logs, there are numeours other programs which guarantee monitoring of a unix system. I personally like cZert sniffer 'czsniff', which sniffs traffic on the ethernet. You can set it up to log all the connections to the machine and encrypt data into the file. its a useful logger. DES encrypted and hidden files usually won't be modified or edited by a hacker who wants to wipe his traces.

As for all the other programs, I'll mention only real secure 4.2 from Internet Security Systems. Even though it is commercial and pretty expensive software, it has many interesting features. It's a complex sniffer that analyses traffic on the network, and which should be placed right behind the router (firewall). Real secure is able to recognize usual regular traffic from the hacker's attack, like for ex. someone starts a regular telnet session - it's fine, but if it detects 50 connections per minute, it immediately blocks the access from particular IPs etc. It can recognize by the packet pattern many remote root exploit scanners, scanning for a password using public services, dozens of denial of service attacks, and many types of flooding etc. It reports found attempts to compromise the network to console and writes reports to the files. As it should be installed on a separate machine, that is not running any remote services, it should be unhackable and invisible. It's easy to configure and it can only detect the attack, but alarm the admin by SMS/pager/email, and eventually react with a counter attack by access restrictions, etc.

It allows having a security management workstation where it will forward all logs and sniffer reports from all the servers. I have a vision and see the possibility to build business just on specialized teams of professionals, who's job is just to monitor, analyse incoming reports, and react in order to protect the customers' networks.

Access time file attributes

Security of internet servers progresses with mile steps. nowadays there is a lot of institutions who employ security professionals. Those are not so easily tricked, just by erasing traces from /var/log/wtmp and /var/log/messages.

When you're erasing the traces, you need to think even about the smallest of details. The example: access time file attributes. After the attack, it's essential to set (see '# man touch') the access times of all modified files - ones you've read, or copied. Especially if you're attacking the machine in order to gather particular information from the server. The administrator can easily tell if you've accessed sensitive documents, by checking access time attributes of those files (ls -lau). By setting these attributes you can hide the fact you've accessed something you were not allowed to.

On the other side, for the administrator, access time attributes are a rich source of information after the attack. If you, as admin, are suspicious that there was a hacked account of some particular user, but there is no trace in wtmp or syslogd logs, try to check access timestamps of the files in that user's home directory (for ex. .cshrc, .bash_login etc.). If wtmp says that the user logged last time a week ago, but his .cshrc was readed yesterday's night, it's clear that something is wrong.


If you're a beginner hax0r, note that cleaning /var/log/wtmp and /var/log/messages is in no way perfect hiding against traces. Realize that on the internet there has already been for a long time anarchy of the wild wild west, where you can mess without a penalty. If you've already hacked some machine, it's highly probably that it uses some of the mentioned logging methods described above, and that the admins will find out and --f*ck you up badly--. If you're an admin, the aim of this article was to not blindly believe information in log files, and that if you want to have a trusted and stable source of information about activity on your server, the default configured syslogd and binary logs are just not enough.


Make a free website with Yola