[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Script to self destruct a linux box...



On Fri, Mar 26, 2004 at 11:20:26PM -0800, jg wrote:
> Idea is this will be a loaner linux system.
> At a certain date it needs to just self destruct & be
> useless untill it can be retrieved.

Uh...you may want to be careful here.  Depending on who is using it,
and what they've got on it, not only is it un-neighborly to destroy any
data they may have had residing on the system, you may be held legally
liable for its destruction.

I would say a much better bet is to have a combination cron job and
network utility that buttons down the system security.  The idea would
be to have the system be contacted by an "authorized" program over an
open port if it's connected to the 'Net, which would change all passwords
and do other _reversible_ lockouts.

If it can't be contacted by a program, have a task which is started
on system startup trigger at a pre-specified date that does a canned
version of the same shutdown.  Note that it should NOT be run from cron or
at--maybe run a copy of it (from a different installation location, and
different program name) from cron/at so if someone, poking, finds it they
think they've disabled it.  Maybe start it as part of one or more existing
real system services--insert its startup in system rc files, for instance.

Note that if someone then fires up the system in recovery single-user
mode and resets passwords, your program will re-start when they bring
it back up unless they identify each and every vector you've installed.
(The classic problem with trojans...in fact, you could also take a real
trojan, strip its payload and replace it with your own.)

Why connect to the system externally?  Two reasons.  First, it allows for
more intelligent shutdown.  Secondly, if the scheduled resident program
is found, the net connection can still carry out the task any time after
that, if the system becomes net-accessible.  Note that if you're behind
a firewall, this may not work; you might have to do something like listen
on ports that firewalls commonly forward, like 80.

Just some observations.
-- 
	Dave Ihnat
	ignatz dminet com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]