There is the potential for the syslogd daemon to be used as a conduit
for a denial of service attack. Thanks go to John Morrison (jmor-
firstname.lastname@example.org) for alerting me to this potential. A rogue pro-
gram(mer) could very easily flood the syslogd daemon with syslog mes-
sages resulting in the log files consuming all the remaining space on
the filesystem. Activating logging over the inet domain sockets will
of course expose a system to risks outside of programs or individuals
on the local machine.
There are a number of methods of protecting a machine:
1. Implement kernel firewalling to limit which hosts or networks
have access to the 514/UDP socket.
2. Logging can be directed to an isolated or non-root filesystem
which, if filled, will not impair the machine.
3. The ext2 filesystem can be used which can be configured to limit
a certain percentage of a filesystem to usage by root only.
NOTE that this will require syslogd to be run as a non-root pro-
cess. ALSO NOTE that this will prevent usage of remote logging
since syslogd will be unable to bind to the 514/UDP socket.
4. Disabling inet domain sockets will limit risk to the local
5. Use step 4 and if the problem persists and is not secondary to a
rogue program/daemon get a 3.5 ft (approx. 1 meter) length of
sucker rod* and have a chat with the user in question.
Sucker rod def. -- 3/4, 7/8 or 1in. hardened steel rod, male
threaded on each end. Primary use in the oil industry in West-
ern North Dakota and other locations to pump 'suck' oil from oil
wells. Secondary uses are for the construction of cattle feed
lots and for dealing with the occasional recalcitrant or bel-
Are you a Linux advocate? Post your success stories here.
3 posts • Page 1 of 1
I just ran across a humorous item in the syslogd man page (naaa, syslogd? who'da thunk?). Check out step number 5 under the "SECURITY THREATS" section: