Oops. I pressed the wrong button, and sent a partially-completed email.
Here's the full version.
--- Paul Taylor
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