Known-exploit detection for the kernel

Posted Dec 19, 2013 20:35 UTC (Thu) by tshow (subscriber, #6411)
In reply to: Known-exploit detection for the kernel by RobSeace
Parent article: Known-exploit detection for the kernel

That's what I'm implying; it would be nice if this could export via some sort of file descriptor through which you could feed a userspace daemon, rather than shuffling stuff off to the logger. Logging is great, but if there's an exploit attempt I want to deal with it now, not after something gets done parsing the logs.

Known-exploit detection for the kernel

Posted Dec 19, 2013 20:45 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

you can feed it to your userspace daemon through syslog pretty darn fast, how fast do you think it needs to be acted on? and are you talking about an automated action or a manual action? if it's a manual action, the time taken to get a human's attention is FAR longer than the delay that syslog will introduce.

In addition, I'm not sure this is something you want to jump on every time (that the reason for rate limiting the alerts), you may just get flooded with alerts.

Known-exploit detection for the kernel

Posted Dec 20, 2013 16:21 UTC (Fri) by tshow (subscriber, #6411) [Link] (2 responses)

I'd want it for automated response, with a subsequent notification to the admin that the automated response has been made.

If someone is script kiddying their way through a series of exploits to see what sticks, I want the userspace daemon to be able to log them out and ban their IP (and possibly lock their account) *now*, this microsecond, before they get a chance to try the next one. Yes, that does imply potential scheduling hackery to get the data out the exploit alert pipe to the userspace daemon before control is allowed to return to the offending process.

In theory you'd only get flooded with alerts if the system was flooded with exploit attempts. You'd probably want to know if that was happening, but rate limiting could be done in the userspace daemon.

I think you'd want to be able to differentiate between local and remote exploits; if someone logged in is trying an exploit it's a very different kettle of fish from someone trying a remote exploit against the external interface.

Feeding the userspace daemon through syslog is kind of silly; a dedicated pipe the daemon could connect to would be better. Avoiding syslog as a transport means:

- being able to specify a consistent communication protocol
- possibly being able to avoid parsing entirely, but at the least the protocol can be designed to make the parsing trivial
- not needing to worry about some other syslog output source being tricked into spoofing valid-looking but manufactured exploit logs
- the daemon being able to sleep on data availability in the pipe rather than having to constantly chew on syslog and spit out the (1 - epsilon) it doesn't need, so the daemon will mostly just be asleep until its needed

Known-exploit detection for the kernel

Posted Dec 20, 2013 18:47 UTC (Fri) by dlang (guest, #313) [Link]

> I'd want it for automated response, with a subsequent notification to the admin that the automated response has been made.

There are a whole lot more tools available to do the alerting based on syslog message than there are going to be if you invent a new protocol.

> If someone is script kiddying their way through a series of exploits to see what sticks, I want the userspace daemon to be able to log them out and ban their IP (and possibly lock their account) *now*, this microsecond, before they get a chance to try the next one. Yes, that does imply potential scheduling hackery to get the data out the exploit alert pipe to the userspace daemon before control is allowed to return to the offending process.

This requires much more significant changes, and really is going to require that you put your response code into the kernel inside the detection routine.

> In theory you'd only get flooded with alerts if the system was flooded with exploit attempts. You'd probably want to know if that was happening, but rate limiting could be done in the userspace daemon.

given that the effort involved in generating the log compared to the action that triggers the log, not having this be rate limited would result in a very good DOS vector.

> Feeding the userspace daemon through syslog is kind of silly; a dedicated pipe the daemon could connect to would be better. Avoiding syslog as a transport means:

> - being able to specify a consistent communication protocol

why can't you use a consistent protocol in your syslog message?

> - possibly being able to avoid parsing entirely, but at the least the protocol can be designed to make the parsing trivial

you can make the parsing trivial in syslog as well

> - not needing to worry about some other syslog output source being tricked into spoofing valid-looking but manufactured exploit logs

you can do this inside syslog with filters today (only send to this output if the source is the kernel and the message contains blah)

> - the daemon being able to sleep on data availability in the pipe rather than having to constantly chew on syslog and spit out the (1 - epsilon) it doesn't need, so the daemon will mostly just be asleep until its needed

again, with filtering in syslog, your userspace daemon can do this today.

And as I noted up at the top, there are a lot more alerting engines around that understand syslog than ones that will understand your new protocol.

Any significant company is already going to have an alerting tool in place, it's far better to integrate with that than to require a new tool be written.

Known-exploit detection for the kernel

Posted Dec 29, 2013 8:06 UTC (Sun) by lamawithonel (subscriber, #86149) [Link]

this patch set uses the audit framework without any rate limiting, and in the somewhat more structured audit format. that sounds like what you want.

+ audit_log_format(ab, "exploit id=%s pid=%u uid=%u auid=%u ses=%u comm=",
+                  id, pid, uid,
+                  from_kuid(&init_user_ns, audit_get_loginuid(task)),
+                  audit_get_sessionid(task));