This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: svlug@svlug.org Date: Fri, 29 Sep 2000 17:35:18 -0700 From: J C Lawrence <claw@kanga.nu> Subject: [svlug] Kernel module that logs all user commands This has come up on a couple of the lists I'm on: http://home.xnet.com/~perly/exec.c Very cute for shell account systems, especially if used with a remote loghost (think about how large and how fast the logs will grow). Among other things I could see using this as part of a simple Intrusion Detection Systems -- just run a log checker to trigger on suspect command lines (I've recently been reading about some of the protocol unwrapping that some Network Intrusion Detection Systems do to spot attempted buffer overflows and other Bad JuJus on the wire). === To: dfox@belvdere.vip.best.com Subject: Re: [svlug] Kernel module that logs all user commands Date: Sun, 01 Oct 2000 16:45:41 -0700 From: J C Lawrence <claw@kanga.nu> On Sun, 1 Oct 2000 16:37:54 -0700 (PDT) dfox <dfox@belvdere.vip.best.com> wrote: >> be too too difficult to come up with a set of filters which >> attempt to match rootkits, standard script kiddie stuff, etc. > It would be useful - but what constitutes a sufficiently wierd > command line? I'd argue for command lines that contain binary data, arguments that contain single arguments longer than a couple hundred bytes, arguments with long strings of repeated non-space characters, arguments to setuid binaries that contain repacement parameters (eg %s), and a few other bits like that on first thought. ITs something that you'd have to evolve over time tho -- much like virii signatures. Its definitely not an ideal (and once the recipies are known, is trivial to avoid triggering on the part of crack authors), but its something. > While on the subject: I notice a bunch of attempted scans to port > 80 from someplace at ucalgary.ca. Will be firing off a note.... My port 139 scan rate has fallen to roughly one every 15 minutes. NANOG has had some interesting traffic on the area. More amusingly to me, my port 1080 (socks) scan rate is up to a dozen a day (used to be one or two a week). The fact that portsentry basically holds every port on the system open as waiting honeypots must surely be confusing some script kiddies out there. === From: "David E. Fox" <dfox@belvdere.vip.best.com> To: J C Lawrence <claw@kanga.nu> Subject: Re: [svlug] Kernel module that logs all user commands Date: Sun, 1 Oct 2000 12:24:34 -0700 Cc: svlug@svlug.org On Fri, 29 Sep 2000, you wrote: > Very cute for shell account systems, especially if used with a > remote loghost (think about how large and how fast the logs will > grow). Among other things I could see using this as part of a Wouldn't BSD-style process accounting (i.e., accton, sa, etc) be sufficient for this? You're right about the log file size; as an experiment once, I turned process accounting on for about a week, and after that week (just one user here, personal workstation, etc.) it was about 20 mb. === To: dfox@belvdere.vip.best.com Subject: Re: [svlug] Kernel module that logs all user commands Date: Sun, 01 Oct 2000 15:47:10 -0700 From: J C Lawrence <claw@kanga.nu> On Sun, 1 Oct 2000 12:24:34 -0700 David E Fox <dfox@belvdere.vip.best.com> wrote: > On Fri, 29 Sep 2000, you wrote: >> Very cute for shell account systems, especially if used with a >> remote loghost (think about how large and how fast the logs will >> grow). Among other things I could see using this as part of a > Wouldn't BSD-style process accounting (i.e., accton, sa, etc) be > sufficient for this? You're right about the log file size; as an > experiment once, I turned process accounting on for about a week, > and after that week (just one user here, personal workstation, > etc.) it was about 20 mb. Partially, but you really don't get everything with that. I'd be more interested in features like this as Instrustion Detection Systems. Don't even run the log to disk -- just pipe it thru a filter looking for sufficiently "odd" command lines. It shouldn't be too too difficult to come up with a set of filters which attempt to match rootkits, standard script kiddie stuff, etc. ===