Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I recently had my linux server hacked into and after reading over all the information I could find about how root kits work I've come up now with a VERY SIMPLE but VERY GOOD Unix security solution.
It seems most of these hacks rely on gaining UID (0) access - or root access.
Here's my solution - how about during installation of Linux (any Unix) on a server that during installation and setup a random UID be assigned root priveledges and do away with the (0) UID idea - it seems to me that giving hackers a known UID to try to obtain - does half the job for them. If they have no idea what UID has root priveledges then its going to be a Heck of a lot harder to hack a system.
Also do away with the username "root" altogether. Again it just makes it so much easier for the hacker since half the jobs done for them, they only have to guess the password. Why not let the administrator select their own username to be the traditional "root" during installation !!!!
I hope someone reads this! The way things are now, especially with the way the world is going - hackers are laughing.
actually its easy to get rid of "root", iv done that, altho some installs are very picky and require the user be called root, and requires certain groups, only for the install tho,,,, still, these i feel are badly made programs, also "su" command complained of no root user, but it su'ed anyway, still complaining,,, i must say, poor poor poor
about that non user 0 thing, i think it looks good, it presents a few problems with certain installed, but that could be solved if they asked you what # is the super user
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
You always need some way to indicate "highest privileges possible", so if you used a random UID for root, and renamed root to fubar, you would still need a way for programs to recognize what kind of privileges they're being called with, else how could you restrict access to certain things just to super user?
As long as there's a super user, hackers will have something to shoot for in their exploits.
Are you sure. You could have a file somewhere that holds the informatin about the Super Users actual username and UID.
I believe this would work because hackers know already before they hack a system just what to shoot for - as in UID (0) and root. If they no longer know what to shoot for - as in which UID or username - how is their initial hack going to succeed? In order to find out the Super Users UID and username (this special file) - they'd first need to hack the system, which would be at least a lot harder because they have no idea what user UID has root priviledges nor the username.
These root exploits many try to become UID (0) - so they then have root access. If you have the root UID randomly assigned during installation - say UID 134452 or something - these root kits may give them UID (0) - but this UID would not have Super User (or root) priviledges.
Is this feasible? I should find out more on how the Linux system works - but I assume its just the UID (0) that tells the system "root" is accessing this or that file - so allow access. If that UID is some other random number - couldn't it be setup so the system then simply allows root access to that random UID only, instead of zero.
Unfortunately, randomising the root UID & name (especially UID) would not be a simple solution. It is possible, but as things stands now would break an awful lot of software and the kernel too; so it would be a lot of work to implement.
Another issue I can see is that programs have to be able to find out which UID the superuser has. If a program can figure it out, an attacker probably can too. Security through obscurity is brittle, remember.
A more workable solution might be to use kernel patches such as LIDS, or others (grsecure?) to prevent someone who has root access from doing too much damage.
Don't think of root as an account with UID=0 or LOGNAME=root. Like Chort already said it's all about privileges. Think of "root" as a placeholder for a set of privileges (grep ".*define CAP_.*[0-9]$" /usr/include/linux/capability.h). The account is necessary to be able to manage capabilities usage. Anything except taking away or restricting access to those privileges is a "security by obscurity" thing and doesn't address the root cause. With Lcap you're able to remove some capabilities (until reboot and be warned you can make your box inoperable, heh). Kernel patches like Grsecurity also incorporate features to take away caps and much more.
Ok, it looks like I need to do some more reading up on things. Thanks for your responses.
After the recent server hacking (my server) I've just become aware first hand that once a hacker finds a way in you're basically stuffed - what's even worse is you may never even know a hacker ever hacked your server (esp. with LKM rootkits) and they can do as they will whenever they like - this is scary. The only defence against this is regular OS re-installs and for webhosts its just not something you can do at the drop of a hat.
Is not allowing users any ssh access at all the only real way to help ensure greater server security? Or can FTP be used just as easily? What would your tips be to help ensure no hackers can gain that first initial access?
Distribution: FreeBSD,Debian, RH, ok well most of em...
Originally posted by bjdea1 Is not allowing users any ssh access at all the only real way to help ensure greater server security? Or can FTP be used just as easily? What would your tips be to help ensure no hackers can gain that first initial access?
Allowing access to a server from the net at all will invite trouble. When you bring up a sytem that will need to have a service port punched thru your firewall, if someone wants in, they will get in. Your best defense is to make it as difficult as possible for them so they get bored and move on.
Keep the packages you have running patched and up to date. And research more about hardening a box. I would never put a webserver in a DMZ without stripping it to the basics then adding things like Tripwire, etc.
Also since you seem to be OpenSource inclined, try learning about using an IDS like Snort. This will help correlate events but shouldn't distract you from checking your logs.
What are the ways a hacker can make that initial crack? I know of brute force, but are there other ways? The recent hack on our server was done by using a standard account on the server from which to run an exploit progrtam that gained him root access.
Does this mean that their only way to gain root access is to find some server username and password? As in do they first need to be able to get an account? I'd feel better if this is the case because then I could re-issue all users on the system, new passwords (long random passwords) on a regular basis. Or can they hack directly through an exploit or something?
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Going back to your original comment about re-installing the OS frequently, that's not necessary. As cyph3r7 pointed out, what's important is that you keep installing the latest security patches to keep up-to-date.
Regarding how hackers break in, there are more ways than can easily be explained. Usually it's one of the following: cause some sort of overflow in the program instructions in order to hijack a program running with privileges, find a user account that they can crack the authentication to, or user a flaw in an application that gives them access to the system in a way it should not.