Security

It’s one of those things that usually gets pushed to the back burner because it seems like too much work for too little gain: setting up a central syslog server which all your other systems can report back to.

This is a shame, because there’s lots of benefits to having such a server:

You can analyse what’s going on in your network from a single, central location – saving you from having to log into a variety of devices for troubleshooting.
Improved security – if you have a security breach, the offender has to break into the logging server as well if they’re to cover their tracks properly. (I wouldn’t recommend re-purposing an existing server for precisely this reason – you want your syslog server to be as secure as possible, which means it needs to be running as few services as possible).
You only need to remember one set of tools to manage logs from a range of devices. Most routers will happily send logs back to a remote syslog server; there are also third-party products you can install on Windows.

It’s trivially easy to set this up in any reasonably modern Linux distribution. Once again, I’m going to use Debian for this example.

Out of the box, Debian uses rsyslog and stores the configuration file in /etc/rsyslog.conf. Fortunately, the default configuration only needs minor changes to two lines as shown in this excerpt:

# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

Uncomment the lines beginning $ModLoad and $UDPServerRun by removing the # symbols:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

Restart rsyslogd (service rsyslog restart) and…. that’s it. Done.

Well, that’s not quite it. A remote syslog server isn’t much good unless you have equipment sending logs to it. On any other Debian servers you may have, this is just a matter of adding a line to /etc/rsyslog.conf:

*.* @192.168.42.39:514

(substitute your own logging server’s IP address or hostname for 192.168.42.39).

Restart rsyslog on the server that will be sending logs to your remote syslog server. Now when you check your remote syslog server, you should find logs appearing from both itself and anything else that’s configured to send logs to it.

Advanced Tweaks

Once you’ve got this done, there’s all sorts of things you can add. You can separate logfiles according to the host that generated them, you can have new logfiles created every day with an appropriate filename… or you can just stick with the basic configuration which will put everything in the same set of log files and just use grep to separate the interesting information.

Whatever you do, keep a sharp eye on disk space on your logfile server. Logs can grow very large very quickly, and a syslog server with a full disk won’t log anything at all.

I recently watched a talk given by Raphael Mudge, the creator of Armita, entitled “Dirty Red Team Tricks”. In this talk he basically goes over the basics of how to play the hacker version of capture the flag from the point of view of the offensive team or attackers, the red team (pretty self explanatory right?). It was a really good watch, and he demonstrated some really neat little tricks to the audience, including how to use Armitage effectively. Here is the link If you would like to view the presentation.

There was one very curious trick he mentioned in his talk that I want to focus this post on and to save as a note to myself for future reference. That is the chattr command.

The main use case for this command is to essentially make a file immutable by setting the “+i” flag. This is similar to using the attrib command in dos on Windows. So for instance, you could do something like change the attributes of a password file or any other important file that you didn’t want getting altered by issuing the following command:

chattr +i some_file_name

Note, you must be root or in the sudo group to use this. Until the flag to turn this off is issued, even the root user cannot change the file, how cool is that?! I see why Mudge likes to use this dirty little trick when competing in capture the flag games now. So to check what attributes a particular file has applied to it you can use the lsattr command as follows, notice that the i flag is now set for the file:

lsattr some_file_name ----i------------e- some_file_name

And finally, to switch this flag off use the following command:

chattr -i some_file_name

We can check again to see if the flag actually got turned off:

lsattr some_file_name -----------------e- some_file_name

That’s it. I couldn’t believe how simple this nasty little trick was to use but how effective it may be in a given situation. I hope this post was helpful for you, and seriously, you should check out Armitage if you are messing around with penetration testing tools, Raphael Mudge is a really smart dude.

Centralising logs for fun and profit

Advanced Tweaks

A Brief Overview of the Linux chattr Command