Re: Possible syslogd DoS ?

["Pavel Kankovsky" <peak () argo troja mff cuni cz>]

On Thu, 4 Oct 2001, Robert van der Meulen wrote:

> Quoting Pavel Kankovsky (peak () argo troja mff cuni cz):
> > 2. implement a method allowing syslogd to identify a subject sending
> >    messages and...
> >    2a. make syslogd record that information (making syslog
> >        spamming accountable and punishable)
> >    2b. implement some kind of quotas in syslogd using
> >        this information
> This doesn't fill up the harddisk, but creates a DoS attack against syslog
> (which was already present); so this only fixes the problem for people who
> have their logs on partitions that shouldn't fill up.

Excuse me? (2a) would not prevent the attack but guarantees you will be
able to identify and punish the culprit after the fact, providing a
very strong incentive not to do such things (deliberately). (2b) makes
it possible to limit the amount of data sent by any individual subject (I
assume the methods for autentication and enforcement of quotas are cheap
...see below).

> There are a couple of problems that need to be solved:
> - Everyone can fill up a partition by logging things to syslog
> - Syslog can't log anymore when the partition where the log resides gets
>   full

I think these problems are closely related.

First, you are right the space where logs can be stored is always finite
but for each system, there is a ``natural amount'' of data logged in a
unit of time, and if you limit the time window you need to keep--or buy
more backup media frequently enought, you can always have enough space to
store this ``natural size'' of logs.

Second, the ``natural rate'' of messages changes slowly and it is very
suspicious whenever this rate (plus some liberal cushion) is exceeded.
One should interpret any such increase of logging activity as an attack
of sorts (a real DoS attack or a side-effect of some other anomalous
activitity), should identify the culprit as narrowly as possible and
should stop the attack.


On Thu, 4 Oct 2001, Thiago Conde Figueiro wrote:

>       http://www.w00w00.org/files/SRS/
>
> This utility is a syslogd replacement.  It's no longer being
> developed, but the author claims that, in the current state, it
> provides authentication and secure (encrypted) multiple remote
> logging.  I checked out the code, it's kinda well documented, one
> shouldn't have trouble figuring it out.

It might be a good thing and it is certainly worth looking.

Anyway it should be noted that cryptographic authentication is a waste
of resources for local communication (you have already got a trusted
third party--the OS--knowing the identity of your counterpart) and its
use makes it possible to flood the authentications subsystem with bogus
data. On the other hand, if we assume the authenticated connections
established by ``vital'' parts of the system are less of more permanent
and unaffected by attacks against authetication subsystem, than such
an approach might be quite successful.


On Thu, 4 Oct 2001, Brian McKinney wrote:

> I could be missing something here but doesn't newsyslog solve this
> problem by rotating logs based on size, date or both?

Rotation based on size makes the log a sort of bounded buffer between
syslogd (or other source of data) and /dev/null. A proper implementation
could guarantee the total size of logger data would never exceed the given
limit but as Petr Baudis pointed out, it creates a new opportunity for an
attacker: flood the log with junk until interesting data (assuming the log
contains something ``intesting'') is rotated into oblivion.

Rotation based on time (date) cannot help much...alone. But it turns
limits on size into limits on rate, and this is an important thing (see
above).


On Thu, 4 Oct 2001, White Vampire wrote:

> By outright disabling 006 on the device what common daemons
> would it affect in the long right?

Most ``common daemon'' run under euid 0, ergo the answer is ``few'' or
even ``none'' On the other hand, it is not very desirable to extend the
set of reasons to run code with unlimited privileges.


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."