Hi, I am slowly working on a host based IDS/IPS system. For a full overview of the design (and the audit system) there is a presentation here from the Red Hat Summit at San Diego: http://people.redhat.com/sgrubb/audit/summit07_audit_ids.odp I'll probably start the real work on this in the F9 cycle. In the mean time, I wanted to raise awareness of an issue that will affect its accuracy. I did a basic threat model of Fedora and one of the branches to intrude is by trying buffer overflow or other attacks. Thanks to protective measures in place, this usually results in a segfault or glibc detecting the problem and terminating the application. In the 2.6.22 kernel, I was able to get the foundation in place for detecting this attempt so that I can write software to detect it later. The way the mechanism works is to hook the core dump routine inside the kernel. Its the easiest way to hook all arches in a way that doesn't impact performance. 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. You can see these events on you system by running "aureport --start today" and looking at the anomaly entry. Further details can be seen by running the anomaly report, "aureport --start today --anomaly -i" which gives out put like this: # aureport --start today --anomaly Anomaly Report ========================================= # date time type exe term host auid event ========================================= 1. 08/05/2007 08:47:46 ANOM_ABEND dhcdbd ? ? -1 272 To see more details about the event, you can issue this command, "ausearch --start today -m ANOM_ABEND -a 272 -i". This tells it to pull the ANOM_ABEND event number 272 from the logs and interpret it. This is what it looks like: # ausearch --start today -m ANOM_ABEND -a 272 -i ---- type=ANOM_ABEND msg=audit(08/05/2007 08:47:46.696:272) : auid=unset uid=root gid=root subj=system_u:system_r:dhcpc_t:s0 pid=2489 comm=dhcdbd sig=Aborted 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. Thanks, -Steve Signal Value Action Comment SIGQUIT 03 Core Quit from keyboard SIGILL 04 Core Illegal Instruction SIGABRT 06 Core Abort signal from abort(3) SIGFPE 08 Core Floating point exception SIGSEGV 11 Core Invalid memory reference ____________________________________________________________________________________ Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
