On Thu, 4 Oct 2001, Robert van der Meulen wrote: > Quoting Pavel Kankovsky (peakat_private): > > 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."
This archive was generated by hypermail 2b30 : Sun Oct 07 2001 - 11:02:24 PDT