restricting syslogd's remote accessibility

[Andreas Heidebrecht]

Hello!

According to syslogd(1M), it is possible for a remote machine to use the syslog facility on the local machine by connecting to port 514/udp (/etc/services). I'm using this feature to collect all non-critical log messages from my user workstations in a central place.

It seems, though, that the access to this service is not restricted in any way. This would imply that anybody on the Internet could fill up my /var partition with a flood of bogus log messages (DoS).

Is my perception of the situation correct?
If so, is there any way to restrict the syslog access to a set of eligible machines short of installing a firewall?
Where do I look for more info on the subject?

Thanks in advance,

regards,

Andreas

[Stefan Farrelly]

add entries to /var/adm/inetd.sec allowing only those IP's you want to send to syslogs port.

[Kofi ARTHIABAH]

Yes, do a man on inetd.sec

If you are connected to the internet, ensure that the IP addresses of the machine that you are connecting to are the correct ones and not spoofed!!! In otherwords, take a good look at the security of your environment and harden your machines accordingly... a firewall is always a good idea....

[Kofi ARTHIABAH]

Yes, do a man on inetd.sec

If you are connected to the internet, ensure that the IP addresses of the machine that you are connecting to are the correct ones and not spoofed!!! In otherwords, take a good look at the security of your environment and harden your machines accordingly... a firewall is always a good idea....

[Andreas Heidebrecht]

Thanks to everybody for the speede response.

For testing I've singled out one of my user
workstations by adding the line
'syslog deny ip_of_workstation' to /var/amd/inetd.sec. I then
stopped inetd,
stopped syslogd,
restarted inetd,
restarted syslogd.
After that, I was still able to send messages to "server's" syslogd using logger on the user workstation.

Honetsly, I don't realy see how ined and syslogd could be made to work together.

inetd works by listening on all ports listed in '/etc/inetd.conf'. When a connection is requested on any of the ports, inetd opens a socket, starts the appropriate daemon, and passes the socket to it. When the daemon (say ftpd) is done servicing the request it simply exits.

syslogd is not realy a network daemon in that sense. Since it also needs to accept log messages from the local processes and the kernel (via a UNIX socket, a FIFO, and/or /dev/klog), it needs to be running permanently. Managing syslogd through inetd would, in effect, disable local logging.
Which is not a workable solution for my setup.

Regards,

Andreas

[Kofi ARTHIABAH]

Andreas,

Local processes could deliver syslog messages to "localhost" and you could setup inetd.conf to include localhost as an allowed host.

[James R. Ferguson]

Andreas:

This does not per se address the DoS issue you described in your initial post, but it might lead to something else useful.

Have you considered configuring /etc/syslog.conf with user.info and user.debug entries that point to a filesystem or directory other than "/var"?

This might provide a larger space, less critical, which can be better monitored and/or trimmed.

...JRF...

[Andreas Heidebrecht]

Diverting the log files from /var to some place where an overrun would not affect important things like mail, locks, spooling, etc. is possibly a temporary solution.

The trick with inetd and localhost would also possibly work. However, this would spawn a new syslogd for *every* log message. Under peak load this would mean spawning a new process every 1 or 2 seconds. It just doesn't seem to be a clean solution.

The syslog facility is so vital and the perceived vulnerability so severe that I must be a overlooking something very basic.

[Kofi ARTHIABAH · Accepted solution]

Andreas:

Here is another idea you can bounce around (since you are not going to put a firewall in):
install swatch on each of the servers to monitor the syslog output, and when a new entry is added, spawn a process that uses scp or sftp to send it to your central server.

This solution has the advantages that your traffic is encrypted (with sftp or scp) so no one can sniff your packets to find out what syslog messages are being sent to your central server.

You might also want to consider installing the tcp-based syslog daemon available at:
http://coombs.anu.edu.au/~avalon/nsyslog.html I do not believe it is available for HPUX yet, but you might be able to port it?

cheers.

[Jim Hendrick]

Did you ever find a way to simply restrict access to the syslogd?
I have seen a lot of "replacement" syslogd's, but I am amazed that someone hasn't added the basic "allow/deny from host/network" functionality to syslogd.
I saw a response to your original post that referred to /var/adm/inetd.sec, but I don't believe syslogd looks at it.
Did you ever get an answer?

Thanks,
Jim

[Tim Maletic]

HP's syslogd now supports a "-N" option to keep syslogd from listening to the network socket. So this is what you'll want to use on every system that is not a syslog server. (Typically you designate one highly secure system as a syslog server, and have all your other systems send their logs there.)

This functionality was introduced by syslog patches a couple of years ago. More recent syslog patches make /sbin/init.d/syslogd pay attention to /etc/rc.config.d/syslogd. So if you're up-to-date on syslog patches, you should just be able to modify /etc/rc.config.d/syslogd to say:
SYSLOGD_OPTS="-DN"

Back to your original question... I run syslog-ng on my syslog servers. See: http://www.balabit.hu/en/downloads/syslog-ng/

[Keith Buck]

"This would imply that anybody on the Internet could fill up my /var partition with a flood of bogus log messages (DoS)."

Actually, syslog will wrap at a certain log size (at least in more recent HP-UX versions), so you don't have to worry about filling up var. You would have to worry about losing older data in a concerted DoS attempt, but you said this data is 'non-critical'. If it is critical, you need to protect the network and/or use something other than syslog to transport it.

HP also ships ipfilter, which is a free host-based firewall that you can use to limit any type of network traffic. You are correct that inetd.sec will have no effect on non-inetd services. This still won't solve the ip-spoofing problem, since that relies more on knowledge of your network topology...something single hosts usually cannot know.

-Keith