How to SECURE Linux Boxes ?
 

Hi,

I need help from this forum regarding “Securing Linux Boxes”.

We have around 100 Linux Boxes which are needed to be secured.

For example, if anybody gets root access and try to fire out commands then we must be able to Track that person, who fired out those commands?

Who tried to ‘manipulated the server?

Who misfired wrong commands in that particular server ?

These things we must be able to Track …

So, can anybody help me in knowing How to do this ?


Regards,
Aparna.

i'm not exactly what you would call an 'expert' but I can give you some pointers

1) uninstall any software packages not used or required as dependencies for other software packages you do use

2) don't install a gui on a server

3) make sure that only services that need to run are running

4) make sure to keep user accounts up to date and lock any user account that isn't actively using the system, secondly make sure they only belong to groups to which they need to be part of and assign privileges to shared resources based on group rather than user, this way adding/revoking privileges is a matter of simply adding/removing the user from said group

5) again with users think least privilege, users only need enough privilege to do their job nothing more/less, it's easier to start overly restrictive and loosen the belt so to speak rather than to start overly permissive and have to clean up after an attack or a disgruntled worker

6) any users who only need file access and not shell access should have their shell defined in /etc/passwd as /sbin/nologin

7) install a file system monitor such as tripwire, and configure it properly, also a rootkit hunter such as rkhunter would help

8) with that many machines a hardware firewall should be deployed, or a decently powered computer with a pair of network cards and a firewall distribution of linux such as smoothwall or ipcop, possibly a DMZ if any servers (such as a webserver) need to be publicly accessible, in case you are wondering, a DMZ is a separate network that sits in between the primary router for the internet connection and the Firewall that protects the internal network that allows the public access to the publicly accessable services and not get anywhere near the important internal servers, also make sure that no UN-necessary ports are opened to the internet (hence the firewall)

9) another often overlooked aspect of security, but one of the most important, make sure to restrict physical access to said machines is restricted to those who need access, physical access trumps any security measures you can put in place, hands down, if they can physically sit in front of the machine or walk out off the premises with the machine, you're sunk

10) lastly, and most importantly, make sure you can trust the people who have access to your system, the people with the potential to do the most damage are the very people who work for you, since they already have access to do damage, hence the least privilege, but even then they can do damage potentially, so don't allow anyone you don't trust access... period.

p.s. you can also set up a file server that only a handful of people have access to,and store duplicates of the logs from each machines, that way if someone tries to cover their tracks, you have a copy of the logs which which to compare from

Before you begin, you need to determine what your security needs are. What will you be running, especially server applications.
Second, the biggest thing you need to realize, and this can not be stressed enough, is that security is an ongoing process. It is not an application you install, it is not using a particular tool, nor is there one right answer on how to secure the box. Once the machines are in operating, maintaining security involves tasks like examining your log files, looking for unexpected changes to the system, performing updates, and monitoring the general state of the system on a regular basis.

Stop here, as again, this is important. If an intruder gains root access to your system, your ability to investigate the system will be completely compromised. An intruder with root access can easily wipe out all of your log files, erase all command history, change all of the login credentials, reconfigure the network, install any application include "trojan horse" ones that are designed for nefarious purposes.

You may or may not be able to track 'who' did this. In fact, the who will only probably matter if it is someone from within your organization. Otherwise, it could be anyone in the world and if they have managed to compromise your system(s) to this level, they are likely hidden behind several layers of compromised systems that it would take a multinational police effort to track them.

Setting the who aside, you are now talking about an investigative process rather than securing a system, yet the two are related. If you have taken proper steps to secure your system, the investigative process may be easier. By proper methods I mean having followed a sensible, routine security process having early warning intrusion detection in place, having log files intact, having the ability to verify your system binaries, being able to identify the network connections associated with your machines, etc. The investigative process involves combing through large amounts of data and looking for anomalies and trying to correlate that data. This forum has published cases of such investigations that will give you some insight into what this involves.

Another aspect that needs to be mentioned is your containment procedures. If you suspect a machine has been compromised, it is imperative that you remove it from service and isolate it immediately. All too frequently we get requests for help with an intruder only to be given excuses like, "I can't take this machine off line, it is too important.", which is a bunch bull because if the machine were that important you would have a backup. Isolating the machine is also meant to preserve the evidence so that the questions you have asked can be answered.


Yes, this forum can do exactly that. In particular, I would recommend two things. One review the STICKY post in this forum on the security references. There are some in there on performing an investigative process. Two, review some of the recent incidents that we have dealt with here in LQ. Here is a good one: http://www.linuxquestions.org/questi...y-help-940481/

all of the above
BUT to add

add a boot password and use full drive encryption

if someone has physical access to it ... all bets are off
a boot password will add one more layer to booting into "single user mode"

"single user mode" is a auto boot into ROOT with NO PASSWORD NEEDED

"full drive encryption "
if i have physical access i can plug in a laptop and READ the drives
or
remove the drive , and take it home with me.

basically there is NO real 100% sure fire way to lock it down

but
( and there is always one )
fallowing the NORMAL everyday " good safe practices" will stop 99% of most problems

that 1% ???? that takes time
and the 0.01% you WILL NEVER SOLVE , there is NO stopping that .

The guys above have given you some fine pointers that I completely agree with.

Given the difficulty already discussed of tracing who did what if a system's superuser account is compromised you have to look at another management layer to encompass this. There are a number of options to do this, one I've seen in use before is Novell's NPUM, might be worth checking out options in this area:

http://www.novell.com/promo/home/pum.html

Hope this helps.

SANS, Nist, NSA, Red Hat, others, all have hardening guidelines.

1. run SELinux, GRsec, etc
2. have a robust logging solution (LogLogic, Splunk), etc

those two alone should get you the alerting part.

beyond that there are a zillion ways to lockdown a system. having installed only whats needed is a task that most dont understand or are unwilling to do.

strong password requirements (10char in 4char class) minimum, and/or key auth should be enforced.

enforce use of sudo so that root UID login is never needed (unless you need it for single user mode) and use of su can be restricted to only root. monitor use of such UID, etc.

beyond those basics applications themselves pose most risk, so patching is crucial. monthly patching if possible, quarterly at minimum.

if you have legacy apps that are no longer supported by their vendor then its time to migrate up/off, etc.

use encrypted filesystems (many ways to do this).

basics-101 will get you about 90% of the way, the last 10% is a challenge.

Mysql --Follow the link http://www.greensql.com/articles/mys...best-practices
ssh --http://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html

Tighten ur server selinux,Firewall
Remove Off unrequired packages in server .Try to install the package via rpm rather than yum
Never enable telnet service try to connect server using ssh
Filetransfer use secure scp rather than ftp.


These are the few thing make sure to make ur server box secure from hackers

Further to what Noway2 wrote, if they are root when they 'fire out' commands, the person they will be (at that time) will be root. I don't think that knowing this does you any good, so what would be the information that you would want? I don't think that we'll be able to give you their social security number.

By this point, you'll have a number of elements of your security procedure documented, but maybe there are key elements missing, or incomplete. If you want help, tell us what is there and what you think is missing. Additionally, some kind of clue about what these boxes are doing could, possibly, decrease the amount of work that you are asking for from quasi-infinite to a somewhat more manageable level.

come to think of it, I forgot to mention, but if they (attackers) manage to get root, you already have a problem, the goal is to prevent systems from being rooted, trying to figure out what to do after someone gets root is like mending the barn door after the horses have already gotten out, once someone has root, they can do anything, including deleting the logs (which is why it's a good idea to keep a copy of logs on an off-server network drive).