Re: Secure 2.4.x kernel - kernel patches
hi ya
for a simple 5 minute kernel patch...
http://www.Linux-Sec.net/Harden/kernel.gwif.html
- apply openwall if you are using 2.2.x kernels
- ruh libsafe if you wanna try a prevent some buffer overflows
- if you wanna get into all the fun stuff... lots of other
patches to evaluate for oyur networks
remember that most security exploits is mostly internal or self created
- if they have physical access to the machine ... all security
rests in "do you trust them" to not steal data or take your
server offline ..and having to work with them daily makes it
a big challenge
- turn off telnet, pop3, ftp, etc... ( self created holes )
( i dont like clear text passwds )
- another sanity check is give your proported security auditor
the passwd for the users... and see if they can become root
- had a manager that said give um(or cracker) root access
to the server and he expected no data loss upon restore
from backups and an hour downtime to recover was
acceptable...
attacks from outside your network is probably easier to defend against
than to "nervously watch your less experienced winNT types mucking with
your companies web/email/db server ... nothing oyu can do when
they( ceo/managers) wanna read their emails from home or out of the office
- just gotta make them use a more secure email methodology
-- i'd worry about local/obvious holes in security before i'd worry
about buffer overflows ...
-- a good/knowledgeable cracker will get in... no matter what you did...
- if you're a bank... you have to be one step ahead of them ...
c ya
alvin
On Mon, 24 Dec 2001, Gary MacDougall wrote:
> > On Friday, December 21, 2001, at 03:25 , Gary MacDougall wrote:
> >
> > > Wouldn't it be nice to be able to run the kernel in "secure mode"?
> > > I'm curious to know if we could limit the amount of "root exploits"
> > > by this method, it would REALLY harden up security on a
> > > Linux box... anyone have any opinions on that?
> >
> > No, it wouldn't, at least from someone who is determined to hack
> > your box in particular (as opposed to a script kiddy who just
> > wants zombies). Script kiddies for the most part can be stopped
> > fairly easily by making their rootkit fail. Examples:
> > o Mount filesystems read-only.
> > o Make disks physically read-only [e.g., CD-ROM]
> > o apt-get remove gcc
> > and, most important:
> > o apt-get update && apt-get upgrade
> >
> > Remember, exec'ing a shell is just convenient; no reason you
> > can't, for example, just make normal syscalls like
> > open/close/read/write to do your dirty work. I'm sure, given
> > enough time attacking, you could manage to malloc enough memory
> > to upload bash/csh/tcsh/ksh/etc. and then execute it without
> > even touching the exec syscall.
>
> No, actually, if you read my previous messages, I proposed that the
> kernel protect against "buffer overruns" by limiting or restricting the
> event *after* the overrun occurs.
> Someone said that St. Jude was what I was looking for, and I think
> its pretty much *exactly* what I was pointing out.
>
>
>
> > The problem you're trying to solve is to get the kernel to
> > refuse to execute exploit code. Exploit code looks just like any
> > other code to CPU. Good luck trying to get the kernel to tell
> > the difference.
>
> The problem really isn't the code that an exploit executes, the problem
> is that the exploit can allow for "root" access by allowing the malicious
> code to spawn a new shell.
>
>
> > In short: Would EPERM from exec stop a script kiddie? Probably.
> > Would it stop a dedicated attacker? No.
>
> Ok, maybe i'm missing something, but a "script kiddie" basically needs
> access to your box to trojan it right? An attacker, needs access to the
> box to attack it, right? Whats the difference?
>
> I don't see the difference. A "dedicated attacker" in my mind is probably
> someone who wants to take ownership of the box and do malicious stuff.
> A script kiddie wants to pretty much plant a trojan to have access to the
> box whenever they want... whats the difference?
>
> g.
>
>
> --
> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: