Mailinglist Archive: opensuse-edu (21 mails)

[Thomas Adam <thomas_adam16@xxxxxxxxx>]

Oops.  I pressed the wrong button, and sent a partially-completed email.
Here's the full version.

--- Paul Taylor <ptaylor@xxxxxxxxxxx> wrote:

> On Friday 09 December 2005 22:34, Thomas Adam wrote:
> 
> > Do you mean this from the point of the computer being compromised
> > maliciously, or via your own tinkering?  If the former, then never.  If
> > that latter, then only once.
> >
> A bit of both perhaps.  My ISP told me that some critical system files had 
> been damaged by hackers which caused the system to segfault on normal mode.

I still fail to see how they could have arrived at that conclusion logically,
seeing as they would need to examine a lot more factors than just a
cursive-by-proxy diagnosis.  No, I am still very much of the opinion that
crackers haven't done much, but that the computer _possibly_ has some form of
inherent hardware failure.   

Tracking that down is often time-consuming, and benefits from experience, and
general observations over a period of time, depending on the hardware that's
assumed to have failed.
  
> I could log on in recovery moe and get my data files.  I'm not sure however
> 
> if the hacking was caused by my liberal application of open source files on
> 
> the server without detailed security oversight. 

The dichotomy you have, Paul, is that _suggestion_ of crackers invading your
machine has been brought to the forefront, when, on the other hand, it could
just simply be hardware failure.   If you really do suspect that your machine
has been compromised, then your safest bet is to backup ALL of your pertinent
data, and reinstall.

But consider for the moment, the effects this will have.   Even if you are
successful in doing just that, what's to say that reinstalling the machine's
OS is going to fix whatever exploit was present to have caused it in the
first place?   I've alluded already for the need of a firewall -- is there
such a setup in place, for the routed traffic to pass through one?  If not,
that's the first thing you should do -- and I can assist with that where
necessary (essentially -- using IPTables).

Backing up the data from a supposed infected machine may well mean (depending
on what was exploited) that you also backup infected files.   This is
unlikely, but it could happen.   There are a few general things you need to
consider though.  I'll go through some of them for you.

Assume for the moment, that this machine hadn't been cracked, and was just
being reinstalled for some reason.   The data you would backup (to preserve
persistency) would most likely be:

/etc/
/home/
/usr/local/

You move all of that to another partition, or CD, or what have you.  Then you
reinstall, and you move all of that data back.  Aside from having to play
about with making sure the UID/GID mappings from the old /etc/{shadow,passwd}
files matched the permissions for the files already created (the process of
this is another email topic in its own right, and serves only as a
theoretical concept in this context) -- it's also possible that you've moved
an existing (and infected) account with you.

So in situations like this, I would go as far as to employ a rigourous
approach of:

1.  For all Sixth-form students, allow login.
2.  For anyone else, set their shell to 'rbash', or some such.
 
Locking down "/tmp" has been something that people have been doing since the
year dot, and you'll see numerous references to setting "noexec" on the /tmp
partition (if you have split it out to be a partition -- always a good idea,
IMO), or creating a loopback file to act as a partition so that you can still
mount it with noexec.

But the problem with 'noexec' is that it is only effective as a 50% measure.
The idea behind the 'noexec' mount option is to disallow users to run binary
applications.   The reason why this is most often applied to /tmp is that
it's
the one place (usually) that is world read, write, and executable.  So I
could
place a program such as "wipeall" in /tmp.   If you hadn't set 'noexec', I
could run it:

/tmp/wipeall

... if you had, and I then try to:

/tmp/wipeall

... it would fail.  But to get around that, is trivial.  Assume it were a
shell script:

/bin/sh /tmp/wipeall

would work, since the calling program is coming from /bin/sh -- which just
exec()s /tmp/wipeall.  

> > One of the challenges I often set people, is to _fix_ their Linux box
> > without reinstalling.   It's a really good learning-curve, and through
> > doing it, it's surprising at just how much one can learn.   Of course,
> > I realise that it isn't always that straight forward -- especially
> > where the machine in question is in a critical environent.
> >
> I have done that on my home machine but was a bit nervy with a remote
> server.  
> I also naively thought that paying someone to look after my server meant
> they 
> would do just that.  Their argument is that it was a root server that was 
> managed by me (hence it was not very expensive).

That sounds like a quick money-spinner, and a very good getout clause.

> The ISPs communiques seemed to point to a hardware failure which they claim

> was caused by malicious intrusions.  Having said that, the ISP is Amen and 
> they had industrial action over the summer (I couldn't get any help for 2 
> months) due to their takeover by Claranet and sacking of lots of people.  
> Could it have been a disgruntled ex...
> With the ability of hindsight, I would not use Amen again.  The trouble is 
> that I needed a cheap server so that my 6th formers could learn the trade. 

See above.  I still disagree with their logic.

> This 
> latest incident has meant lots of candle burning for me which I could do 
> without as January exam season approaches. :(

:/   It's annoying, for sure.   I didn't realise you were taking exams in
January.   :)

-- Thomas Adam



		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com