Layering an IDS on Linux - prepwork

[Steve G]

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