APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

A strangely compromised Linux box

© November 2009 Anthony Lawrence

A customer reported that a Linux machine used for ssh access (to in turn give telnet access to an ancient SCO machine) was refusing logins. I asked him to try logging in as root at the console; he was unable to do so.

When I arrived on site, I found that I could not login as he had said. I rebooted to single use mode and started peeking around. The machine had been hacked; there was little doubt about that. It's HOW it was hacked that bothers me,

First, there was no attempt to hide any evidence. I could see in wtmp and the secure logs that someone had logged in from a German ISP address, attained su status, and created a new su user for himself. He then changed root's password.

Fine so far, right? But then he did something very strange. He hand edited /etc/passwd and added "/nologin" at the end of each line except root and his own. This was what was preventing people from logging in.

Why do that?

My first thought was that this was just a disgruntled employee doing minor mischief. But when I went multi-user and started checking more, I found this:

3       2614 root    3u  IPv4   8033       TCP *:ircd (LISTEN)

That looks like the machine has been put into a botnet. I ran rkhunter but didn't find anything else unusual.

This is very odd. If you want the machine for a botnet, why disable the user logins, which only serves to immediately call attention to the machine?

Another oddity: this same issue happened several months earlier. That is, users could not login and the root password was changed. That time, the user access came back before I could get there and I had them boot to single user mode to change the root password. I wish I knew if an irc daemon was running then, but I attributed all of that to user error or a router glitch.

Could it be just an inept hacker? A "kiddie script" that disables logins? But why undo its work? And why redo it now?

And he DID redo it. The time stamps are plain: he did all this just days ago. It makes no sense.

I suspect that this person got in because someone's home machine is already part of the botnet. I don't know how he attained escalated permission, but once you have physical access, all bets are off. We'll have to reinstall the machine, but if I can't identify the source, what's the point?

I don't know. I'm really not sure what to do. For the moment, I've locked down ssh so that only I can get on - I want to see if he does have another back door. But I'm also concerned about other machines in the network - any of these could be compromised also. So where do we go from here? I don't want to put this customer to a lot of expense for nothing, but the whole situation is disquieting.

It does offer a lesson though: when something odd like that happens, we should take the time to look more deeply. If I had spotted that ircd months ago, I'd have... what? I don't know. But still, I should have looked deeper then.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> A strangely compromised Linux box


Inexpensive and informative Apple related e-books:

Take Control of iCloud

Take control of Apple TV, Second Edition

Take Control of Parallels Desktop 12

iOS 10: A Take Control Crash Course

Take Control of IOS 11

More Articles by © Anthony Lawrence

Fri Nov 6 03:05:45 2009: 7444   anonymous

intrusion detection and eradication?

Fri Nov 6 03:26:49 2009: 7445   TonyLawrence

I don't know that you can ever trust eradication.

Fri Nov 6 05:57:59 2009: 7447   anonymous

Im new to Linux but why not just set up DenyHosts to work after one attempt? I know that an average hacker would be able to try from IP's all around the world and one attempt for them would not be that big of deal but for the script kids out there I think they would not have the patients.

Fri Nov 6 07:31:52 2009: 7448   drag

> Im new to Linux but why not just set up DenyHosts to work after one attempt?

Waste of time.

The correct action is really to just nuke the box from orbit and restore from backup. But since it seems likely that the machine has been hacked for a long time now then that is probably not a good approach...

So the solution is to nuke the box from orbit and then rebuild it from scratch. That is about it.

Really you shouldn't even let it shutdown. The way your suppose to do things is that as soon as you discovered the intrusion to literally just pull the plug from the device. Your only chance to really understand what is going on is by examine evidence on the file system. I don't know how common it is, but it is known that some rootkits look for certain commands and whatnot and sticking a script in runlevel 6 is a pretty simple way to go about covering your tracks. So you just pull the plug from the machine, image the drive using DD and then carry out your investigation using the image you created.

That would of been the right thing to do.

Of course the worst thing you could do would be to try and 'restore' the machine by running anti-rootkits and anti-virus and things like that. Anti-virus is snake oil and can't be trusted to ever make your machine safe again after a successful attack, regardless of what OS your running. The time, money, and effort you put into trying to 'save' a install is being wasted and you'll never know for certain. From a economic perspective it is just going to save time and effort to start over again.

So sorry. That is why we use secure passwords and keep our desktops secure, so we don't have to put up with this sort of*\***.


As far as what to do about the rest of the network of machines I think that if the owner uses similar passwords on multiple machines then those machines are probably hacked. Or are going to get hacked. Even if it is not necessarily true it is a safe assumption.

If the owner refuses to do the sensible and correct thing to pretty much wipe out his network then what still you can do is install a Network-based IDS like snort.

Build a passive ethernet tap and setup a nice machine that will be able keep up with all the network traffic and stick it on the line leading to the router out of the network. If it is just a script kiddie running IRC and doing file swapping it will be pretty easy to spot any other infected machine. Then you can setup email alerts and that sort of thing.

Fri Nov 6 12:23:27 2009: 7449   TonyLawrence

Ayuop - Drag is exactly right.

But - it's difficult to convince non-technical people to do that. A botnet compromised machine is generally not obviously harmful to them. As I noted above, if this guy hadn't disabled other people's logins, this might never have been noticed.

Fri Nov 6 13:33:45 2009: 7450   Petem

i'd turn the machine into a VM before nuking it.. that way you can study all aspects while keeping it segregated..

Fri Nov 6 13:38:04 2009: 7451   BruceGarlock

Some people still think you can get rid of a virus or Trojan. The only remedy is the nuke/pave option. I'd almost make an image of that machine, and turn it into a honeypot, and watch the bad guys. Maybe get enough evidence to actually prosecute them? Of course, if they are in a different country, US law probably is not enforceable.

I have not researched international law regarding computer break-ins, so what is the law? Can anything be done?

Fri Nov 6 13:41:51 2009: 7452   TonyLawrence

I was just talking to the owner of the hacked machine.

He thinks this might be another computer consultant he had a falling out with. That could explain the disabling of logins if the guys intent was to be annoying without really being vicious. But what is the IRC channel for? And of course, you still can't assume that other machines aren't compromised.


Fri Nov 6 14:00:40 2009: 7453   Marc

I can think of two reasons for the hacker to block user login:
1.- The hacker needs to guarantee some time on the machine for whatever reason, he knows there's no tech guy on site so he prevents remote login. He wins some hours before someone comes and has phisical access. long shot but who knows.
2.- the hacker is testing the company for future hacks. He may just want to know how long does it take for them to repair it.
The irc server, just something to draw attention.

Fri Nov 6 14:17:59 2009: 7454   TonyLawrence

But he left it disabled for days. He killed access on October 30th, and I didn't get there until November 4th. I see that he did login again on November 2d, also.

The "mildly ticked off consultant theory" gains credibility from the previous incident where it was disabled for a few weeks and then miraculously fixed itself.

The possible perp travels overseas a lot (not that he couldn't have used the German ISP from anywhere, of course).

The client's theory is that he just wants to be mildly annoying. He may have been surprised that I didn't get there to fix it quickly the last time (I had the flu!) and he may have just been busy with other things until now or maybe whatever ticked him off just crossed his mind again...

Great theories, but unless the guy left a message saying who he is (rather unlikely!), I don't feel comfortable with the "he just wants to be annoying" idea.

But... it's their system, their security, their choice.

Fri Nov 6 14:38:24 2009: 7455   meanasspenguin

This machine sounds like a standard infrastructure access point, where not a whole lot changes. I think that a baseline security scanner would have found this problem and alerted you to exactly what had been done -- much better than after-the-fact forensics. I prefer a product like samhain, but others also swear by tripwire.

Fri Nov 6 14:40:20 2009: 7456   anonymous


1) Pull the plug. Now.
2) Image the hard drive for later analysis.
3) Nuke the box.
4) Carefully restore from backups. Not the OS, just data. Install all apps from scratch.
4) Lock down ssh. No one needs to access an ssh box with a password. Use keys.
5) Install an IDS - Tripwire/snort, etc. Use them. Try to find out if he comes back.
6) Check every other system on the network for similar hacks.

Fri Nov 6 14:48:56 2009: 7457   anonymous

One of my servers was hacked in 1998. There was a perl script in /tmp, owned by named, running in a tight loop trying to gain access to root. The system was already patched against that vulnerability, but every time it ran, the break-in attempt was noted with an email. After 2 hours, I had over 2400 emails.

I unplugged the network, killed the main process that didn't make sense (a perl script) and began researching what had changed from an off-line disk mirror taken the prior weekend (7days earlier). Only files under /tmp were altered that weren't clearly user modified. I disabled bind, updated the version - bind was just 3 months behind on patches - redeployed it into a chroot'd environment, then wiped all the /tmp/named files. Plugged the box back into the network. No reboot.

Having a recent enough off-line mirror that you can use as validation is important. We retain 30 days of backups for every server. Further, any internet facing server is **expected to be hacked** and CxO folks understand it. We concentrate on what our recovery steps are post-hack for those boxes - push a static web site out ASAP from a read-only NAS mount while we perform the necessary "what happened" research. Dynamic content isn't available, but much of our content is static. Steps are different based on the services impacted, obviously.

Fri Nov 6 15:46:53 2009: 7458   RevEggplant

Don't forget to question any other boxes running Windows that login to that box. Think keyloggers. They tend to hide once installed. I agree with what the other gents are saying about pulling the plug and stopping everything immediately, then rebuilding from scratch with backups of data added. It's the only way to be sure.

Fri Nov 6 15:54:48 2009: 7459   TonyLawrence

Don't forget to question any other boxes running Windows t

Yeah. I know. I said "I'm also concerned about other machines in the network - any of these could be compromised also"

But take it from the clients perspective: We want him to immediately stop all business activity, and then reinstall ALL operating systems and software. That's a major and very expensive undertaking.

And if he's right that this is just a mildly annoyed ex-consultant, he could do all that for nothing. If he's wrong... he NEEDS to do this, and the sooner the better.

Imagine the expense. Some older machines won't have OS install disks - new hardware, new software. The old SCO machine is very troubling because of hardware. Because you would lose a lot of business income otherwise, you'd need to do all this very quickly - bringing in a team to sweep through the place identifying needs and taking action.

NOT pretty.

Fri Nov 6 16:17:27 2009: 7460   BruceGarlock

I need to dig out my copy of "The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage" by Cliff Stoll - have not read it in a while, and this break-in reminds me of that book.

If you have not read it, I *HIGHLY* recommend it - my wife even enjoyed it, and she's really not into computers - at all..

Fri Nov 6 16:36:15 2009: 7461   drag

Ya.. this is a extremely difficult situation.

Ideally they should clean house and just get a fresh start on the computer infrastructure.

But you may be able to figure out what is going on on the via a investigation of the drive contents. If you could figure out if it is a consultant or not then that is one thing, but I find that extremely unlikely. For all we know that the guy cleaned up the machine because he realized he was committing a felony then later on decided to post login information to some script kiddie channel to let the 13-15 year olds commit the crimes.

Regardless: Running a IRC channel is NOT revenge behavior.

Whatever compromise that you come up with make sure that it's a good one. You'll have to impress on him the seriousness of the issues here... For example do they handle customer information on any of the machines? Any credit card information? Then they could lose their ability to take credit cards or at least get a fine if information that they store ever gets traced back to them.

It is common for people to get blackmailed by hackers. It usually works; send some information about the company in a email and threaten to go public if they don't pay a couple thousand dollars. Businesses invariably pay the hacker, and then a few months later they come back for more blackmail money when they get broke again.

Any sort of government contraction? Do they handle any medical information? Theoretically they could be liable for hiding a information loss from people.

If they refuse to work with you then I'd say tell them they are on their own. Your a professional and you have a responsibility to do a job right... a foreman building a building wouldn't just leave out a structural member because the customer demanded that it would be to expensive to install, right? They would just walk away from a job. Tell them they can deal with somebody with no morals or ethics if they don't want to go through at least some of the correct steps.

Fri Nov 6 16:50:14 2009: 7462   TonyLawrence

This is outside of my scope anyway. I don't have the resources to handle it. Whatever they decide, someone else is going to have to handle it.

I can assist in specific areas (the SCO box, the mailserver) but I'm not able to handle a system reconstruction because I'm just one person (and no, I don't hire subs).

Also, this really should be overseen by someone who specializes in security. Thar's not me. I don't have the knowledge or the experience.

Fri Nov 6 17:07:20 2009: 7463   anonymous

Use rsync from another box every few minutes to return the computer to pristine condition every couple of minutes. That way even if the box does get compromised it is fixed again immediately. You could also block all IP's into the box and only allow people to come in from their home IP adress ranges.

Fri Nov 6 17:18:38 2009: 7464   TonyLawrence

Most home users have dynamic ranges. The better solution would be to force them into using ssh keys - (link) - but IF THE HOME MACHINE IS COMPROMISED, that doesn't help.

The "rsync" idea would be trivial for a hacker to stop. Moreover, it's not much more work to put up a fake rsync responder that would make the other machine think it had successfully copied.

Fri Nov 6 17:26:23 2009: 7465   TroyTruchon

So the customer has some telnet only boxes on an insecure but private network that he remote accesses through this box... well if thats all it does why does it have anything else installed? A customized version of microcore Linux set to reboot once a day with pretty much just sshd, telnet, and GNU Screen would be practically unhackable.

Fri Nov 6 17:29:40 2009: 7466   TonyLawrence

Check every other system on the network for similar hacks.

Having been through this before, I can explain the problem with that. It's the same issue as with fast propagating network worms: to kill the infection, you have to take EVERY machine off-network and keep them off until they are clean.

When dealing with a simple problem, you might be able to clean. People do that often with virus attacks - it's a lot better than reimaging every box. But with a hack, how do you know how clever the s.o.b. is? You don't, so your only real choice is full sanitation - horribly expensive and time consuming. Consider that old software may be lost, unavailable, operating systems like their ancient SCO may not work with new hardware... important data files have to be examined and proved free of intrusion... it's a major mess!

Fri Nov 6 17:35:52 2009: 7467   TonyLawrence

A customized version of microcore Linux set to reboot once a day with pretty much just sshd, telnet, and GNU Screen would be practically unhackable.

No, not if the source is a compromised home user.

I've said before that VPN's from home users are dangerous. I don't care WHAT they are connecting to, what security is in place - if the home machine has been compromised, everything is at risk.

Fri Nov 6 17:38:17 2009: 7468   TonyLawrence

I was reminded of this: (link)

Too many people are too trusting in letting people use VPN's. Great convenience, but a potential risk.

Fri Nov 6 17:38:21 2009: 7469   anonymous

Well true, but if you set it to reboot every three hours or so, thus giving you effectively a fresh install each time the Hacker will get tired of rehacking and installing everything three-four times a day.

Fri Nov 6 17:39:28 2009: 7470   mario

If you reboot the machine, a running trojan process might not be there anymore. The only solution is to have the server always keep a running terminal on the serial console. A running root shell on the serial console can not be exploited remotely, just with physical access. But this way, you could still login in such a case, where the local accounts or passwords have been tempered with. (As long as the intruder doesn't detect the running serial console.)

Fri Nov 6 17:48:55 2009: 7471   TonyLawrence

As long as the intruder doesn't detect the running serial console.)

No different than leaving root logged in on ALT-F3

And a simple "w" or "last" discovers that instantly. To hide that, you'd need to install your own root kit - spy vs. spy :-)

Fri Nov 6 18:01:59 2009: 7472   BigDumbDinosaur

Of course, my first question would be why wasn't the disgruntled ex-consultant's credentials immediately removed from the system when things went sour between him and the client? After all, the majority of security breaks that occur on UNIX-like systems are made possible by careless username and password policing. Is this another case of having an easy-to-remember root password because "it's convenient?"

Something I've hammered into my clients' heads is the need to keep administrative access to any machine under tight control and keep it limited only to those who have a compelling need. Nevermore so is this requirement than when a machine is exposed to the Internet. As someone above said, it should be assumed that any exposed machine will eventually be subject to a hack attack.

As for the Windows boxes...I believe Rent-A-Dumpster offers a solution... <Grin>

Fri Nov 6 18:38:56 2009: 7474   drag

And a simple "w" or "last" discovers that instantly. To hide that, you'd need to install your own root kit - spy vs. spy :-)

Yes. That is why playing hacker games is not going to get you anywhere. The _only_ correct action is to simply pull the power and make a image of the drive and you use that for forensics.

Think about a crime scene. Does the police start just tearing into everything, crawling in and out of all the windows, and trying to recreate the crime to try to see if they can find the criminal by accident?

NO.. They secure the scene and make sure that evidence is preserved.

And not only is it your job to preserve evidence, it is your job to do things like establish chains of custody and other things to make sure that you can prove that you have not tampered with the evidence.

It's such a simple thing to do... stick a drive into a external adapter and use dd to pull a image without mounting or otherwise touching any of the data on disk it's just a 'duh' to do it. Otherwise your just stomping all over everything with the digital equivalent of muddy boots in a ham fisted attempted to outsmart a unknown person.

Fri Nov 6 18:44:40 2009: 7475   DaemonZOGG

Here is an exerpt from "en.wikipedia.org/wiki/IRC" :
"..as a way of obtaining a bouncer-like effect, an IRC client (typically text-based, for example Irssi) may be run on an always-on server to which the user connects via ssh. This also allows devices that only have ssh functionality, but no actual IRC client installed themselves, to connect to the IRC and allows sharing of IRC sessions.[68]
To prevent the IRC client to be closed on termination of the ssh connection, it can be run inside a piece of screen-detaching software (e.g. GNU Screen or tmux), thus staying connected to the IRC network(s) at all time, being able to log channels the user is interested in, etc. Modelled after this setup[69], an IRC client following the client-server model, called Quassel IRC, has been developed. "

Who knows? Right? .. ;)

Fri Nov 6 18:46:27 2009: 7476   TonyLawrence

would be why wasn't the disgruntled ex-consultant's credentials immediately removed from the system when things went sour between him and the client?

I don't know. The first I heard about any unpleasant relations was today. It's quite possible that nobody but the owner knew about this and he may not have thought about hacking.

That assumes it WAS that guy. I think a compromised home machine is still in the running.

Fri Nov 6 18:50:20 2009: 7477   TonyLawrence

Right, who knows?

I keep cycling back to "Why call attention to yourself by disabling logins? Why leave an easily seen trail in /var/log/secure and wtmp?"

Whatever. As I said, it's not something I can handle.

Fri Nov 6 20:32:22 2009: 7481   Albinootje

What I really like is to use only Virtualization or sophisticated chrooted environments for the production servers, and then on the Hardware Node (The host) you would run process accounting (acct).
Having that will give you quite a bit history of what commands any intruder has used.

Fri Nov 6 20:36:21 2009: 7482   DaemonZOGG

What about the old SCO box that the linux box telneted into? Were there any intrusions, modifications, suspect log entries, copied files, etc? (It's difficult to say or type the word "sco" considering what they have done to the open-source community). But, let's press on...

Fri Nov 6 20:42:48 2009: 7483   TonyLawrence

What about the old SCO box that the linux box telneted into?

Nothing obvious. But again, who knows? I can't guarantee that.

Fri Nov 6 21:58:00 2009: 7484   drag

"""What I really like is to use only Virtualization or sophisticated chrooted environments for the production servers, and then on the Hardware Node (The host) you would run process accounting (acct).
Having that will give you quite a bit history of what commands any intruder has used. """

I am not necessarily disagreeing with you, but I just like to point the following out when this subject gets brought up.

Chroot != Security mechanism. It is simply a way to isolate one environment from another in a fairly weak manner. It is designed pretty much for developmental or software compatibility purposes and is really quite worthless at increasing system security.

If a user gains root access in a chroot environment then it's trivial to break out of it. So trivial that is is just laughable.

So if you think about it...

In a normal system if a user breaks into a web-facing applications they are restricted by the rights of the user of that application. If that application is running as 'root' then your system is compromised. If the application is not running as root then to fully take over a system the attacker must exploit a local privilege escalation vulnerability. So that means that they need a local kernel exploit or a insecure 'setuid root' program and that sort of thing.

If the attacker hacks a 'chroot'd program then they are still facing the same barriers. If the program is running with root privileges then they have your machine.. breaking out of chroot for root is a feature, not a bug. If the application is running as a regular user then the chroot environment may present something of a barrier by isolating the attacker from other applications, but seeing how a hacked network-facing application has the ability to download and execute any arbitrary code then most kernel-level problems should be exploitable.

So chroot really gains you nothing that a properly secured system without chroot can. Maybe a little bit, but not much. You'd be better off checking your file system permissions and that sort of thing. It's not really a slam-dunk that some people think it is.

Now virtualization can actually help somewhat... but the thing to remember with virtualization that it is a cost-saving feature rather then a security one.

Ideally you should isolate different services on separate physical machines. If you can't afford to do that then you can achieve similar levels of isolation by running multiple VMs... but it is still possible to break out of VMs.

So say you have 30 different guest operating systems running in their own virtual machines. If one of the VMs are hacked and the attacker is able to exploit a flaw in the virtual machine then they can get access to the host operating system. Once they get access to the host then they can get full access to all the guests automatically. The host operates in a 'trusted' fashion that the security of all the guests depend on. Lose the host and you lose everything. Having separate physical machines is better because that is not really possible.

Of course since we are constrained by a budget then having virtual machines is a very nice option.

Something that I would recommend to use other then chroot is to use OpenVZ for Linux, BSD Jails, or Solaris's Containers/Zones. These are forms of virtualization that have similar low-overhead when compared to chroot, but unlike chroot they are designed for security in mind. One of the good ways to look at them is that they create a environment were 'root' is a non-privileged user.. were as with chroot root retains all the same privileges and was never originally intended for increased security. That way you get most of both worlds; convenience and low overhead with reduced cost compared to running separate hardware.

Containers are my friend. <3

Fri Nov 6 23:30:13 2009: 7485   DaemonZOGG

Although it is worth looking in to, I don't think you'll find issues on the other workstations. It all seems centered around the Linux ssh box. Regardless if the intrusion came from the outside or not, I strongly believe that the intruder was using the box as either a file transfer relay over IRC, or utilizing the cpu resources on the box itself in order to assist in processing something they had. Why bog-down your own resources when you could utilize someone elses. Keeping all of the other users off of the system would free up most of the hardware resources just for you. No need to cover your tracks if your IP & MAC are spoofed through anonymous servers.
Stranger things have happened.
A few years ago, a hacker was arrested for breaking into the servers at Sandia National Labs for the sole purpose of obtaining extra drive space for his movie collection. Of course, I don't think he realized at the time exactly what type of organization he had broken into. ;)

Anywayz, if your client has the time, set up all of the usual tools (tripwire,wireshark,snort,etc). As Drag mentioned.. it is very important to know what commands they used or passed. Only then, will it give you some insight into the "why". :)

Best of luck!
- Daemon_ZOGG

Sun Nov 8 17:42:34 2009: 7496   James

I'd give myself a back door, then sit for a while running tcp dump both specific to the original point of entry (the German ISP) and a more general one that excludes traffic you know isn't dirty (like traffic from you.) It could be someone learning their way around just for fun or, something a bit more. Any time you get someone who doesn't cover their tracks it's either stupidity or, they just don't care. That second one could be extremely dangerous. I wouldn't be surprised to find that the irc traffic is encrypted, and now that you have changed things, they probable have gone away.

As for how they got in. yep someone using a botnetted box came in the IRC is key logging, sends the data to their home, and for now, I'd be very afraid that the "ancient SCO box" is the real target. I'd say t's time for a whole new login schema. SSH keys to start

Sun Nov 8 18:00:42 2009: 7497   nonymous

You are going to rebuild/clean the box (I'd rebuild...only those with more faith than me will try to clean and then re-use) and so the questions are:
-what diagnostics can you run to track down how the previous attempts have succeded
-what to do afterwards
on the second point, I'd be looking at iptables to log all remote acceses that fail and keep looking at the log for the next few weeks to see what happens. Maybe something will show up as the miscreant tries to get back in. Maybe, it'll be from the German ISP, maybe not. Maybe it'll always be from a country that the consultant is in, maybe not. Maybe you'll get a clue from the protocols used what was used last time, maybe not.
And you'll want to be double careful about using stuff like tripwire this time.

Sun Nov 8 18:12:02 2009: 7500   TonyLawrence

No, I'm not.

In my opinion, the whole network is suspect. It would be pointless to rebuild just this.

It's out of my hands anyway. The customer will do what they want to do.

Sat Nov 28 23:50:05 2009: 7676   xenoactive

I've read through this thread a couple of times. It's hard to make a good recommendation without knowing the network layout and the available access methods. Ideally the compromised server should be analyzed to positively identify the intrusion vector. Simply reloading the data onto a freshly installed server may not be sufficient. You could actually just wind up recreating the same vulnerability. In any event, the business owner is taking a calculated risk based on the information available to him. Inconvenience versus loss of business is their decision. There are many options available to the business owner. Hopefully the person who gets to clean it up can present enough information so the owner can make an informed decision.

Sun Nov 29 00:26:22 2009: 7678   TonyLawrence

I put them in touch with someone who does forensics. The ball is in their court now.


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

Computer Science is embarrassed by the computer. (Alan Perlis)

Linux posts

Troubleshooting posts

This post tagged:



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode