Layering an IDS on Linux - prepwork
mitr at volny.cz
Sun Aug 5 14:31:48 UTC 2007
Steve G napsal(a):
> When a core dump is attempted, the audit system gets control briefly. It records
> the event as an ANOM_ABEND event. ANOM_ is the whole class of events that are
> intended for use by the IDS/IPS code. ABEND is the subtype that means the program
> ended abnormally.
> Now, the reason that I'm writing all this in an email is that there are programs
> that can cause false positives. No one is attacking my system via the dhcdbd
> command. The aborted tells me that the application must be calling abort(). In
> many cases people want their program to exit due to some problem. Calling abort()
> means end the program AND dump core. This will trigger the IPS part of the system
> at some point.
> Anyways, I wanted to point this out so that as new code is written, people
> understand that an abort() may be confused with an attack. Please don't call
> abort() unless you really intend to dump core. User space will need some cleaning
> up to make an IDS/IPS effective. From what I can see, there's only a couple
> offending programs.
abort() is the traditional way to abort a program when an assertion
fails (developers might need the core file in that case), and SIGABRT
terminations are very unlikely to be caused by buffer overflows and
similar attacks. They are much more likely to be caused by application
bugs that can not be used for unauthorized code execution (although they
might be used for denial of service.)
Changing all software to use some other mechanism to report assertion
failure is completely impractical (even the POSIX standard requires
assert() to call abort() on failures); besides, what alternative
mechanism is available?
Repeated SIGABRT terminations might indicate an ongoing DoS attack, but
isolated SIGABRT terminations need to be ignored, IMHO.
More information about the fedora-devel-list