Re: Anti Hijacking tools

[avalon () coombs anu edu au (Darren Reed)]

> > ------- =_aaaaaaaaaa0
> > Content-Type: text/x-pgp; charset="us-ascii"
> > Content-ID: <22906.791264012.1 () merde dis org>
> > Content-Description: Pgp signed cleartext
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> >
> > Here is a program that does some of what der Mouse's device
> > driver does but runs as program that edits /dev/kmem to disable
> > the device /dev/vd.
> >
> > I did what can to bullet proof the code so that it does not stomp on
> > the wrong device driver.
> >
> > Written and tested under 4.1.3u1
> >
> >             -Pete
> >             shipley () dis org
>
>
> AntiHijacking tool? It disables sun4's kernel ability to modload modules
> on fly, thus also disables things like ppp, slip, et al. I won't call it
> a solution.

There are other (obvious) problems too...the most obvious being get root,
alter /etc/rc* and either reboot or wait for it.  Unless they store a
TripWire DB on a storage device which is removable and can have read-write
toggled easily (ie floppy disk) and they use it daily, you're defeated even
with these tools.  And, I might add, there is little to be done to stop it,
it would seem.  If you've got a SunOS4.x machine, want to run Sun stuff,
and are desperately worried about its security, you'll gain a *lot* more by
putting NetBSD(current)-sparc on it.  You'll also save yourself a lot of
time trying out these other solutions.  The only thing NetBSD doesn't offer
is a way to defeat guessing the ISN, but the only safe way I would consider
changing this is to have it increase (at all stages) by a random amount at
regular intervals rather than once per packet at any stage.

darren

p.s. yes, a reboot is obvious, and even if you have security-mode full,
     you may not notice if they wait for you to reboot or they cause a
     panic through some kernel bug.  And by this time it is too late.

p.p.s unless upon rebooting you check *every* binary you execute for
      changes since the last (something like running TripWire *very*
      early in /etc/rc*) you may or may not know if anything has been
      changed before you go into multi-user mode.  This is getting
      towards the extreme paranoia end of the spectrum, however.  By
      making all directories and files involved with rebooting restricted
      to be changed by root (under NetBSD), you stand a chance of being
      immune to a trojan taking advantage of the boot procedure.

Depressed yet, about unix security ?