Syslogd: Remote logging

There are times when you need a central syslog server which collects system logs from various systems. In order to preserve logs in the case of a system compromise, for example, remote syslog’ing is a wonderful solution, where logs are sent to the remote syslog server the moment they are created on the client system. Even if the attacker removes the log directory on the compromised client system, copies of logs have already been moved over to the remote syslog server. Remote syslog’ing also provides for centralised log analysis and correlation, which can become a nightmare if done on a per host basis in a decentralised syslog enviornment.

This nice tutorial describes setting up remote syslog daemon as well as clients that connect to the remove syslog server.

Following the tutorial, I set up remote syslog on two Slackware boxes. On the system on which I wanted to set up the syslog server, I added the following piece of BASH code to /etc/rc.d/rc.syslog

syslogd_remote() {
if [ -x /usr/sbin/syslogd -a -x /usr/sbin/klogd ]; then
echo -n "starting sysklogd daemons: "
echo -n "/usr/sbin/syslogd "
/usr/sbin/syslogd -r -m 0
sleep 1
echo "starting kernel logger "
/usr/sbin/klogd -c 3 x
fi
}
'remote')
syslogd_remote
;;
*)
echo "usage $0 start|stop|restart|remote"

I restarted rc.syslog with the ‘remote’ argument, and headed over to the client system to set up syslog to send logs to the syslog server. I appended the following line just to /etc/syslog.conf

*.info;mail.none;authpriv.none;cron.none @remote_syslog_server_ip

Restarted rc.syslog, and I was done.

SSH Tunnels (Port Forwarding)

It is surprisingly easy to set up SSH tunnels. All you need is SSH access to a box with Internet connection that will act as the port forwarder. Something as simple as the following command with set up an encrypted tunnel that will forward the local_port on the ssh box to the remote_port on the remote_host.

ssh -N -L local_port:remote_host:remote_port user@local_host

And that’s it. The “-N” argument tells SSH not to run any commands, which is the behaviour required when setting up tunnels. The “-L” argument sets up the port forwarding stuff.

That command will run in the foreground, or background if you suffix an ampersand to it, and will gladly service requests destinted for local_port on the ssh box (localhost, here).

It is important that TCP-Forwarding be enabled for this to work. In order to enable that, the directive

AllowTcpForwarding yes

must be set in the SSH daemon’s config file (man sshd_config(5)).

Remote X Login (GDM, XDMCP, Xmins, oh my)

At work, I’ve got a separate CentOS box on which development [by one other colleague besides me] is done, and an XP workstation which I use most of the time. I have used the XDMCP HOWTO to configure GDM on the CentOS to listen for remote connections. On the XP workstation, I use Xmins to easily access the remote X (with GDM and all).

The XDMCP HOWTO is pretty straightforward, and if the instructions are followed religiously, the results are pleasing. Like GDM, KDM as well and the frugal XDM can also be tweaked to enable XDMCP and listen fro remote login requests. I have not yet tried this on Slackware. As soon as I find some time, I’ll experiment with Slackware. I don’t have windows at home [only Slackware], so there is obviously and naturally no need for remote X login [at home].

The place in all this where you might get stuck is choosing a good tool to connect remotely to the X on the Windows side. There are many great tools available, but most of them are proprietary [and their demo versions don’t quite do what you want them to]. There is X-Win from Cygwin, but that requires Cygwin to be installed. Overlooking all those options, I ran a search across Freshmeat.net and bumped into Xmins. It is a great tool. The good thing about Xmins is that it requires zero configuration setting, is not more than 2-MB big, and does not need Cygwin installed to work. What more could one ask for?

And for those of you who love looking at screenshots, here is one.

Happy remote X’ing. :-)

Deathful wishing :(

Today has been one of those days where I wished, driving at 102+ on a busy highway, that I rammed into a car and died. :-(

Running PHP4 and PHP5 on the same box.

As the sole systems administrator for the Linux box hosting the University’s website, I was asked nicely by the lead web developer, last to last week, to set up php5 alongside the existing php4 installation. A new component of the website uses php5, and rolling out that component was on top of the list.

I used Tim Dorr’s simple article, “PHP4 and PHP5 Side-By-Side“, to get php5 up and running on the system.

Logflusher

Logflusher is a dirty little tool to clean login traces on a Linux box. I needed a tool that could conveniently and quietly clean login information from WTMP and UTMP files (under Linux). There were a few tools around, but I wasn’t satisfied. Thus, I wrote logflusher.

I released version 1.1 of logflusher last week (I think). You can read the changelog here.