SSH Tunnels and IPC(?)

[fuzzyping]

I have a project that I'm trying to iron out some details for. First, a brief description:

I'm building a centralized database for logging from a series of distributed firewalls. The logging will take place via a perl script I've written that opens a pipe on the logging interface (OpenBSD's pflog0), parses the output, and inserts the data into a MySQL table.

For security's sake, and to be able to maintain a "pull" mode from the database server, I've been using a remote SSH tunnel (forwards remote port to local port), then using SSH to run the remote script. The script connects to the firewall's local port, forwarding the connection through the tunnel to the database server securely. Unfortunately, this brings up a couple of issues: 1) How to monitor that the tunnel stays up, and 2) How to monitor that the script is still running/connected?

I'd consider moving the SSH connection task into the Perl code, but I haven't found any tunnelling methods in the Net::SSH or Net::SSH::Perl modules. As far as the process monitoring goes, I don't have any experience with process communication or error trapping, so any "high-level" suggestions will be greatly appreciated.

Example use of script:

$ ssh -C -x -R 3307:192.168.0.10:3306 root@192.168.0.1 'perl pfdb2.pl'

TIA,
-fp

[Thelonius]

Here is my suggestion for a fairly simple solution. Change pfdb2.pl to open a socket connection to a monitoring program. In pfdb2.pl, where you do a read on the logging interface pipe, set a time limit on the read (either using alarm or select (IO::Select::can_read)), and every _n_ seconds (say 30 seconds), send a short "OK" message to the socket connection. Also, if you get a mysql or any other serious error, send a "NOTOK" message.

These monitoring messages don't seem sensitive to me, so you could send them unencrypted. You could even use UDP, since there's no serious consequence to losing one message.

But if you do feel the need to encrypt, I think you can just add another "-R" option to ssh and forward that port to the monitoring machine.

The monitoring software is pretty simple, you just keep a list (a hash, probably) of the last time each logging process sent us an "OK" message. You have to have a timeout on the read, obviously. If you haven't heard from a process in, say, 90 seconds, then you raise an alarm.

If you are using TCP (including if you are using SSH), you could do a fork on accept and have one process for each connection, but I don't think that's necessary. I would use the IO::Select method.

If you are using UDP, then you don't have to worry about that.

Some other things to watch out for:

Don't have pfdb2.pl die if it gets an error opening a connection to or writing to the monitoring process. Just have it try again in 30 seconds. You want your logging to continue even if the monitor is down.

You'll need to have some logic to make sure that the monitoring process knows which connections to expect. Otherwise a process that never starts up will never give an error.

I hope that's clear. If not, feel free to ask more questions.