bugtraq - RE: DoS-ing sysklogd?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <BA40AC55499E124C89FE407343F61B9E959211@webmail.sktice.com>
Date: Sun, 2 Apr 2006 16:43:06 -0500
From: "Justin Shore" <justin.shore@...bcs.com>
To: "Milen Rangelov" <mrangelov@...bul.bg>,
	<bugtraq@...urityfocus.com>
Subject: RE: DoS-ing sysklogd?

> I know that good IP filtering on the sysklogd box is the best fix, but
> always resolving hostnames of the log messages' sender is definitely
not
> a good idea..

The -x switch takes care of this problem.

	-x	Disable name lookups when receiving remote messages.
This avoids deadlocks when the nameserver is run-ning on the same
machine that runs the syslog daemon.

This is on sysklogd-1.4.1-30.  That said performing rudimentary ingress
filtering at all borders of both internal IP netblocks and 514/udp will
also effectively mitigate this problem, unless an internal host is
compromised to the point of being able to send spoofed UDP packets.

To further mitigate the problem with basic syslog security you should
use a simple host-based packet filter to only accept 514/udp packets
from known syslog devices.  Setting the source interface for syslog
messages to an internally routed private IP on a loopback interface (not
using an interface's IP that could be found via a traceroute) will make
this filtering more secure.

Ultimately the most secure way to ensure that syslog messages are
delivered is to create a GRE tunnel between each syslog device and the
syslog server.  None of these methods of mitigation are difficult to
implement.

Justin