Script to self destruct a linux box...

[Daevid Vincent]

At first I thought this was just a troll or some script kiddie, but now I
see the rationale. We do something less harsh ourselves -- we just disable
the program.

The advice below is sound, however your logic needs to be inverted. The idea
is to think in terms of negatives or "not"s. What I mean is, think of how a
'watchdog' works. You want the script to be ready to "kill stuff" all the
time UNLESS it is told not to. Your flaw here is that you rely upon the
connection to be alive to shut the system down, when in reality, someone is
likely to pull the plug. Therefore, have your script try to phone home and
if it can't, it locks the system down. It could be 'nice' and if it gets
back online the next time it runs, it could unlock it too. But you get the
idea...

Also, google a bit and you'll find out how to disable the lilo/grub bypass.
Our appliances still require a root password to login, even in single user
mode.

Daevid Vincent
http://www.interactnetworks.com
 

> -----Original Message-----
> From: redhat-list-bounces at redhat.com 
> [mailto:redhat-list-bounces at redhat.com] On Behalf Of Dave Ihnat
> Sent: Saturday, March 27, 2004 6:01 AM
> To: General Red Hat Linux discussion list
> Subject: 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 at dminet.com
> 
> 
> -- 
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>