|
Project: Linux  Howtos
Securing Linux: Part 1
By Trevor Warren <trevor@freeos.com>
Posted: ( 2000-11-29 22:12:12 EST by )
Linux was built from the ground up with security in mind. However, this security
will amount to nothing if some basic security measures are not adopted. This is
the first in a series of articles that will show you some of the basic security
measures that you can adopt for your system.
"Security is not an option, but a way of life". This is the mantra given by Kurt
Seifried, the author of the famed 'Linux Administrators Security Guide' and
numerous other Security HOWTO's available out there. The theme in these series of articles is to make one aware of the trivial
security concerns on a stock Linux box. This article aims at giving novice users
an insight into conducting a security audit of their systems and helping them
take corrective measures in order to avoid any future security lapses.
Throughout this article, you will find pointers to various other security
howto's and research. This Security guide isn't a substitute for them but merely
a look at the various facets of insecure networking that are a part of our
everyday computing lives. Everyday as you log on to the Internet to transact your daily business, your
data has to pass through hundreds of machines out there before it reaches its
final destination. En route, from point A to B, anyone can sniff your packets of
data, analyze the contents and maybe even reframe the packet contents. There is
no dearth of sniffing, cracking tools and password breaking tools out there. You
have a lot to worry about before you can consider your network safe. Take it one step at a time, one day at a time. The only weapon by your side is
your Knowledge. Keep yourself updated with the latest news from the security
front. Look out for bug releases at the major security sites on the Internet.
Patch your software as soon as the exploits are revealed. You have to be very
active to ensure that you are always one step ahead of the rest.
Old habits die hardMany organizations use BIOS security passwords in order to restrict access to
machines. But in contradiction to this security, the employees have POST-IT
notes on their desktop with the BIOS password written on it. There have been instances where the organization's unofficial policy is to
maintain a single syllable password "x" for all the users of the machines in
their network. Certainly makes life so much simpler both for the system
administrator, user and the cracker. The point we are trying to make here is
the need to change people's attitude towards security. So who are we trying to condemn? No one to be precise. But what we are saying is
that the only way you can ensure that your data is 100% secure is to turn your
machine off. The worst part is that it's our attitude that keeps on telling us
"Hey among those millions of computers on the Internet, surely the chances
that our network will get broken into is remote." Trust us, don't bet your life
on it.
Security policyNo two organizations have similar security concerns. Thus, it makes no sense
having a common framework for comparing the policy framing scenarios among any
two corporate. For all of us, our data is precious and we will go any length to
see that redundancy is maintained in the form of daily incremental backups and
maybe restricting access to the systems containing that precious data. Then why do numerous organizations have no strategy when it comes to drawing up
a security policy and implementing it? Maybe some do not want to go the extra
mile in framing a security policy. Maybe some system administrators is so
overworked that they find implementing and enforcing a security policy, a waste
of time. Rather than speculating on the possibilities of not having a security
policy in place, let us figure out what it takes to get one up. Whatever the nature of the business a company is in, almost every company has an
extensive network that at some point is connected to the outside world. Probably
the only connection between the Internet and the Intranet is the proxy services
that sit between the two. The gateway may also be masquerading as a mail server
or fax server. The list of services running on the gateway is endless. But in
this whole scenario of having to provide all these services to the internal
staff, what kind of security measures have you put in place to ensure that your
internal network doesn't become a playground for any cracker? The cracker might
use your network to launch DOS attacks on a site. Framing and implementing a security policy requires a lot of thought and
debate to be put into it. You should not wake up to its need after having been
hit. It requires a collaborative effort by the system administrator as well as the
users. Certain rules and regulations should be strictly engraved into the
working of every employee. Alternatives and compromises have to looked at before
finalizing on major issues and freezing the whole thought process. Laying down
the framework and implementing the security measures are not the end of the
whole process. Employees must also be made to understand that following these
guidelines is what is going to make it all work in the end.
Basic security guidelinesLet us look at some basic security measures that will help you take care of the
small loose ends at least. Remember, a chain is only as strong as its weakest
link.
BIOS passwordsBIOS, stands for Basic Input Output System. The main function of the BIOS is
to initialize all the hardware on your computer. Using the BIOS, it is possible
to re-scan all the HDD on your systems or hide any HDD on your system. Changing
the boot sequence through the BIOS is also possible. Any intruder can boot off a
boot disk, mount your hard drive partitions and access all the data. Novices
messing around with BIOS parameters, is a very common sight at many companies,
and ultimately when things go wrong no one wants to claim responsibility. To prevent any such problems, set a BIOS password to protect your settings.
Also, ensure that you are prompted for a password at boot. Make sure that you
choose a password that is at least eight characters and is a combination of
numbers and non-dictionary words.
File permissions and attributesThere are many programs that you run on your system, which may have the SETUID
or SETGID bit set. The necessity of having the SETUID or the SETGID bit set is
so that these programs can access certain resources to which only root has
access. The drawback of allowing these programs is that in case of buffer
overflow attacks (the most common), any cracker can possibly gain access to the
system. Do not remove all the binaries that have the SETUID or SETGID bit set,
but make sure that you know what files carry those permissions. The following command will find you the files on your system that carry the
SETUID and SETGID bit. bash# find / -type f -perm +6000 -ls Next on the checklist are world readable files. Never leave any files world
readable or world writable unless necessary. Create a group and delegate all the
resources within that group to be managed by an admin of the group. This
prevents any unwanted sharing of resources among system users. Many a time, when the System security is compromised, the last thing the cracker
does is to remove all traces of his visit by cleaning out the log files. You can
remedy this situation partially, but there is no foolproof solution to this
crime. The following command "chattr" helps you go a step further than the "chmod"
command, which allows you to only change the files ownership rights and nothing
further. Using the "chattr" command, root can specify files and directories to
be "immutable" and "read-only". These implement restricted access to the files
and prevent tampering around with the actual system files or replacement with
any other alternate ones. bash# chattr +i /sbin/lets_rock <-- The immutable bit
bash# chattr +a /var/log/messages <-- The append only bit Take for example the second flag mentioned above, "+a". This allows root to set
the append only bit for /var/log/messages and prevents it from unwanted
tampering. At this point of time, it is suggested you lay your hands on a PDF document
available at www.linuxsecurity.com called "Quick Reference Card.pdf". It is an
Adobe Acrobat document (PDF format) and quite informative about the basic
security measures a system administrator should take.
Password protecting your boot sequenceMost of us are familiar with the boot loader that comes along with most Linux
distributions, LILO. Until sometime ago, most Linux distributions had
vulnerability as follows. Anyone with physical access to your machine could
reboot it and at the LILO prompt say 'linux single' to get to a root shell
without being prompted for a password. LILO: linux single <-- The LILO boot prompt Red Hat 6.2 works this way but other distributions, like SuSE, verifies the root
user by asking for a password before providing the user with a shell. You can remedy this situation by getting LILO to always ask for a password if
any command line parameters are passed to it while bootup.
To make the following changes to your /etc/lilo.conf file, su to root, open the
lilo.conf file in your favorite text editor and make the following changes. image = /boot/vmlinuz-2.2.17
label = Linux
read-only
restricted <--
password = your-password <-- You'll need to append the last two lines to your /etc/lilo.conf file. Add a
password of your choice and re-run lilo. bash# lilo There is a lot more but for now check out the following links.
Linux and open source security advisories
LinuxSecurity.com security reference info
LinuxSecurity.com security discussion lists
LILO configuration and usage
Other articles by Trevor Warren
Current Rating: [ 6.45 / 10 ]
Number of Times Rated: [ 22 ]
|
