|
|
|
|
|
Securing a Redhat/Fedora install
|
 |
 |
 |
|
Written by wunk
|
|
|
|
Wednesday, 12 May 2004
I've been a Linux sysadmin for a couple of years now, and learnt most
through trail and error, I've summarized the biggest security bumps on
a new server install into a nice tutorial, this should apply to most
Redhat/Fedora installs, most parts apply to Linux in general too.
When installing a fresh copy of Fedora or Redhat, one of the first choices to make is the partitioning scheme..
Take the following rules into account:
Keep the user writable partitions seperate from the rest, that means at least /home and /var Keep the /boot partition seperate Keep /tmp seperate
Motivation:
The /home and /var can be filled up with user data (/home for sites and
personal data, /var for mail and logs), and are commonly set with
quota's, you don't want a filled up filesystem crashing your server
because of a user, or users with weird quota's due to files on the rest
of the filesystem being set to an owner that it's not supposed to be
set to (untarring a file for example, which was set to a certain user
on another system can fill up quota's quickly)
It's smart to
keep /boot seperate too, in case of partition corruption, you can
always fall back to that partition to at least boot the kernel.
Now for /tmp.., this is actually a dangerous directory, especially on
webservers or servers with a lot of users.., it's writable and
accessable by anyone and all applications.., last thing you want is
/tmp filling your filesystem till the server dies.., 1 GB should be
more then plenty for /tmp..
The installation itself:
Do NOT install what you don't need.., ask yourself.., do I need X, Gnome, KDE etc on a webserver ?
No, I didn't think you did.., so don't select them, waste of space and
the more software is installed, the more exploits are able to pop up :-)
After finishing the install you have a working Fedora/Redhat install, time to continue security..
We'll secure /tmp first, all that should be done on this
partition/directory is temprary storing of files, we don't want users
executing scripts from here, so we'll narrow down the permissions on it
Open up /etc/fstab, and look up the /tmp part, it'll most likely show something like:
LABEL=/tmp /tmp ext3 defaults 1 2
Let's change that into: LABEL=/tmp /tmp ext3 rw,noexec,nosuid 1 2
Now issue the command: mount -o remount /tmp
What this does, is locking down the permissions on /tmp, although you
can still read and write to it, it's not possible anymore to execute
anything from it, so no applications or scripts can be ran from it, and
it nullifies the suid bits on files..
The most commonly used hack I
encounter on webservers, is due crappy PHP programming, executing
scripts and applications (ftp, irc, shells, etc) in /tmp, this will
kill off any possibility of that happening from /tmp, locking out the
first wave of hackers..
Next: Update your applications.., look up a mirror near you, and hit the Updates directory..
Issue an rpm -qa > /root/packagelist.txt
And see in /root/packagelist.txt which applications you have installed,
and which ones have updated versions.., download these and do an: rpm
-Uvh .i386.rpm (You could download a whole set of
packages in a directory and rpm -Uvh *.rpm to do it all at once to
speed things up)
At least make sure your kernel, SSH, Apache, SSL
and FTP are up-to-date, you don't want anyone hacking you through one
of these open services, and even WHEN they'd get in, you don't want
them to rootexploit the kernel ;-)
If you'd like to take it the easiest way, just issue a yum update, which will check and update your system quick and through (hit fedoralegacy.org
if you're running older redhat installs like 7.3 and 9, or a
discontinued Fedora version. You'll find longer term support for
updates here)
Next disable RootLogin through SSH, for some iffy
reason this is on by default, edit /etc/ssh/sshd_config, uncomment and
change: PermitRootLogin No
Restart ssh: service sshd restart
We're also going to close down some local tools that are commonly used
by hackers to achieve their goal, by chmodding them to 700 (rwx------),
so only root can execute and use them.., these are the ones we'll
handle (if appropriate):
Compilers (cc, gcc, bcc, i386-redhat-linux-gcc in /usr/bin) so hackers can't compile their applications they want and need /usr/bin/wget, this way they can't download their tools in the first place Same goes for the ncftp binaries ping, you really don't want anyone DDoS'ing using a simple too like ping from your server on a thick connection
It may also be smart to change the users that are allowed to su - to
root, into a single group (like wheel), and do a chown root.wheel on
the su util and chmod it to 750, this way normal users can't even try
switching users..
Last but not least, the firewall.., WOULD any
hacker make it through the basic defenses, and start up something like
an FTP server, Shell, or IRC server from a directory outside /tmp, the
firewall will block the port they want to start it on anyways, so the
whole thing would be useless.., personally I use Arno's IPTABLES firewall script,
it's easy to configure and works like a charm, put it somewhere in
/etc/rc.d/rc.local or one of the runlevel directories so it'll start
when the system boots.., close down any ports you don't use, and if
possible, secure SSH down to specific IP's
A good way to
see if anything weird is running on your server, is by doing a 'ps aux'
and see if any processes in the form of ./processname show up, or look
for any processes running as the apache user which shouldn't be ran:
'ps aux | grep apache', if anything other then apache/httpd shows up,
kill it and start digging for logs.
That's it, if you go by
this list you'll have a fairly secure server which isn't going to be
hacked at the first oppertunity, there's a lot more tools like
chkrootkit, tripwire, nessus, etc, etc to make it even more secure, but
this should help you with the biggest holes.
|
| Last Updated (
Thursday, 28 April 2005 ) |
|
 |
|
