I have been having difficulty identifying various vendors that offer
solutions for providing IP encryption products that can accomodate the
following design. I can't imagine there wouldn't be other customers who
would also not want to see this either.
We want to extend our facilities to provide general IP connectivity from
the employees' home/travel systems into our corporate network. We do
not want to have any service providers being able to snoop/tamper with
the data between the end systems and the corporate network. In essence,
we are looking for a solution that provides end-to-end encryption from
the various flavors of home systems into the corporate network. We wish
to use PPP with CHAP authentication, and possibly augment the
authentication process with some other challenge-response/token system.
In addition, we want all the data between the end system and the gateway
system into the corporate network to be encrypted, preferably including
the IP headers (and re-encapsulating the entire packet in another IP/IP
packet directed to the gateway host, so as to even prevent traffic
analysis, but we'll settle for IP payload encrFrom firewalls-owner Thu Dec 7 19:24:20 1995
Received: (majordom @
localhost) by miles.greatcircle.com (8.7.1/Miles-950430-1) id SAA00935 for firewalls-outgoing; Thu, 7 Dec 1995 18:24:31 -0800 (PST)
Received: from iconz.co.nz (iconz.co.nz [202.14.100.2]) by miles.greatcircle.com (8.7.1/Miles-950430-1) with SMTP id SAA00896 for <firewalls @
greatcircle .
com>; Thu, 7 Dec 1995 18:24:15 -0800 (PST)
Received: from un04.UUCP (Upst @
localhost) by iconz.co.nz (8.6.12/8.6.10) with UUCP id PAA10493 for firewalls @
greatcircle .
com; Fri, 8 Dec 1995 15:25:09 +1300
Received: from manukau.govt.nz (wpsmtp.manukau.govt.nz) by un04.manukau.govt.nz with SMTP
(1.37.109.16/16.2) id AA104256351; Fri, 8 Dec 1995 14:32:31 +1300
Received: from INTERNALIP-Message_Server by manukau.govt.nz
with Novell_GroupWise; Fri, 08 Dec 1995 14:31:31 +1200
Message-Id: <s0c84c43 .
060 @
manukau .
govt .
nz>
X-Mailer: Novell GroupWise 4.1
Date: Fri, 08 Dec 1995 13:56:15 +1200
From: Matthew Thompson <un04!mthomps1%manukau .
govt .
nz @
iconz .
co .
nz>
To: firewalls @
greatcircle .
com
Subject: RE: NT Security and NTFS -Reply
Sender: firewalls-owner @
GreatCircle .
COM
Precedence: bulk
If you can physically access the box and reboot it you can do anything
you want with Unix, Netware or anything else. B level security and Type
Enforcement don't help against binary disk editors. Encryption of disk
data would.
Try this as a plan.
Down your favorite unix box, open the case, plug the root disk into your
DOS notebook with PCMCIA SCSI adaptor. Get a disk editor such as
norton and search the raw disk for the word "root". once you find the
password entry zero it out, and reboot. ( or just mount it on another
system which you are already root on or boot recovery media like DAT
or CDROM if your vendor supports this ) .
ON NT, take the disk and plug it into the above mentioned notebook now
running NT on which you are administrator and view all files. (or reinstall
NT over the top of the current installation).
ON Netware, boot off floppy, search for the directory entry for the
bindery files, overwrite the first byte of each bindary file, reboot the
server. it will assume the bindery is corrupt and create a new one with
null password for supervisor. Or, assuming the file server console is not
locked (bad move) just load an NLM which creates you a new
supervisor equivalent account.
The method used here to break these systems are crude physical
attacks. They require physical access to the box and disrupt it's normal
operation. However what this really goes to show is that if the user has
physical access to your Unix, NT, Netware server, then they can do to it
what they will, even steal the whole damn thing if they want.
There is no way to defend against these sort of attacks on the systems
described, just ensure that the user cannot get physical access to the
system. Lock it in a room, guard it, encrypt the disks and require a boot
password to unencrypt, build this into the disk controller, or place in
under the user's desk in a locked safe, with only keyboard and monitor
cables coming out, make it explode if tampered with :)
The real question is how easy is it to subvert the system when you don't
have physical access to it, because there's certainly no challange when
you do have physical access.
Best Regards,
Matthew Thompson
|
|
