and File system Security
A few minutes of preparation and planning ahead before putting your systems online
can help to protect them and the data stored on them.
• There should never be a reason for users’ home directories to allow SUID/SGID
programs to be run from there. Use the nosuid option in /etc/fstab for partitions
that are writable by others than root. You may also wish to use nodev and noexec
on users’ home partitions, as well as /var, thus prohibiting execution of programs,
and creation of character or block devices, which should never be necessary anyway.
• If you are exporting file-systems using NFS, be sure to configure /etc/exports
with the most restrictive access possible. This means not using wild cards, not allowing
root write access, and exporting read-only wherever possible.
• Configure your users’ file-creation umask to be as restrictive as possible. See the
Section called Umask Settings.
• If you are mounting file systems using a network file system such as NFS, be sure
to configure /etc/exports with suitable restrictions. Typically, using ‘nodev’, ‘nosuid’,
and perhaps ‘noexec’, are desirable.
• Set file system limits instead of allowing unlimited as is the default. You
can control the per-user limits using the resource-limits PAM module and
/etc/pam.d/limits.conf. For example, limits for group users might look like
this:
@users hard core 0
@users hard nproc 50
@users hard rss 5000
This says to prohibit the creation of core files, restrict the number of processes to
50, and restrict memory usage per user to 5M.
You can also use the /etc/login.defs configuration file to set the same limits.
• The /var/log/wtmp and /var/run/utmp files contain the login records for all users
on your system. Their integrity must be maintained because they can be used to
determine when and from where a user (or potential intruder) has entered your
system. These files should also have 644 permissions, without affecting normal
system operation.
• The immutable bit can be used to prevent accidentally deleting or overwriting a
file that must be protected. It also prevents someone from creating a hard link to
the file. See the chattr(1) man page for information on the immutable bit.
• SUID and SGID files on your system are a potential security risk, and should be
monitored closely. Because these programs grant special privileges to the user who
is executing them, it is necessary to ensure that insecure programs are not installed.
A favorite trick of crackers is to exploit SUID-root programs, then leave a SUID
program as a back door to get in the next time, even if the original hole is plugged.
Find all SUID/SGID programs on your system, and keep track of what they are,
so you are aware of any changes which could indicate a potential intruder. Use the
following command to find all SUID/SGID programs on your system:
root# find / -type f \( -perm -04000 -o -perm -02000 \)
The Debian distribution runs a job each night to determine what SUID files exist. It
then compares this to the previous night’s run. You can look in /var/log/setuid*
for this log.
You can remove the SUID or SGID permissions on a suspicious program with
chmod, then restore them back if you absolutely feel it is necessary.
• World-writable files, particularly system files, can be a security hole if a cracker
gains access to your system and modifies them. Additionally, world-writable directories
are dangerous, since they allow a cracker to add or delete files as he wishes.
To locate all world-writable files on your system, use the following command:
root# find / -perm -2 ! -type l -ls
and be sure you know why those files are writable. In the normal course of operation,
several files will be world-writable, including some from /dev, and symbolic
links, thus the ! -type l which excludes these from the previous find command.
•
Unowned files may also be an indication an intruder has accessed your system.
You can locate files on your system that have no owner, or belong to no group with
the command:
root# find / \( -nouser -o -nogroup \) -print
• Finding .rhosts files should be a part of your regular system administration duties,
as these files should not be permitted on your system. Remember, a cracker
only needs one insecure account to potentially gain access to your entire network.
You can locate all .rhosts files on your system with the following command:
root# find /home -name .rhosts -print
•
Finally, before changing permissions on any system files, make sure you understand
what you are doing. Never change permissions on a file because it seems
like the easy way to get things working. Always determine why the file has that
permission before changing it.
Files and File system Security
Local Security
The next thing to take a look at is the security in your system against attacks from
local users. Did we just say local users? Yes!
Getting access to a local user account is one of the first things that system intruders
attempt while on their way to exploiting the root account. With lax local security,
they can then "upgrade" their normal user access to root access using a variety of
bugs and poorly setup local services. If you make sure your local security is tight,
then the intruder will have another hurdle to jump.
Local users can also cause a lot of havoc with your system even (especially) if they
really are who they say they are. Providing accounts to people you don’t know or for
whom you have no contact information is a very bad idea.
Creating New Accounts
You should make sure you provide user accounts with only the minimal requirements
for the task they need to do. If you provide your son (age 10) with an account,
you might want him to only have access to a word processor or drawing program,
but be unable to delete data that is not his.
Several good rules of thumb when allowing other people legitimate access to your
Linux machine:
• Give them the minimal amount of privileges they need.
• Be aware when/where they login from, or should be logging in from.
• Make sure you remove inactive accounts, which you can determine by using the
’last’ command and/or checking log files for any activity by the user.
• The use of the same userid on all computers and networks is advisable to ease
account maintenance, and permits easier analysis of log data.
• The creation of group user-id’s should be absolutely prohibited. User accounts also
provide accountability, and this is not possible with group accounts.
Many local user accounts that are used in security compromises have not been used
in months or years. Since no one is using them they, provide the ideal attack vehicle.
Root Security
The most sought-after account on your machine is the root (superuser) account. This
account has authority over the entire machine, which may also include authority
over other machines on the network. Remember that you should only use the root
account for very short, specific tasks, and should mostly run as a normal user. Even
small mistakes made while logged in as the root user can cause problems. The less
time you are on with root privileges, the safer you will be.
Several tricks to avoid messing up your own box as root:
• When doing some complex command, try running it first in a non-destructive
way...especially commands that use globing: e.g., if you want to do rm foo*.bak,
first do ls foo*.bak and make sure you are going to delete the files you think you
are. Using echo in place of destructive commands also sometimes works.
• Provide your users with a default alias to the rm command to ask for confirmation
for deletion of files.
• Only become root to do single specific tasks. If you find yourself trying to figure
out how to do something, go back to a normal user shell until you are sure what
needs to be done by root.
• The command path for the root user is very important. The command path (that is,
the PATH environment variable) specifies the directories in which the shell searches
for programs. Try to limit the command path for the root user as much as possible,
and never include . (which means "the current directory") in your PATH. Additionally,
never have writable directories in your search path, as this can allow attackers
to modify or place new binaries in your search path, allowing them to run as root
the next time you run that command.
• Never use the rlogin/rsh/rexec suite of tools (called the r-utilities) as root. They
are subject to many sorts of attacks, and are downright dangerous when run as
root. Never create a .rhosts file for root.
• The /etc/securetty file contains a list of terminals that root can login from. By
default (on Red Hat Linux) this is set to only the local virtual consoles(vtys). Be
very wary of adding anything else to this file. You should be able to login remotely
as your regular user account and then su if you need to (hopefully over the Section
called ssh (Secure Shell) and stelnet or other encrypted channel), so there is no
need to be able to login directly as root.
• Always be slow and deliberate running as root. Your actions could affect a lot of
things. Think before you type!
If you absolutely positively need to allow someone (hopefully very trusted) to have
root access to your machine, there are a few tools that can help. sudo allows users to
use their password to access a limited set of commands as root. This would allow you
to, for instance, let a user be able to eject and mount removable media on your Linux
box, but have no other root privileges. sudo also keeps a log of all successful and
unsuccessful sudo attempts, allowing you to track down who used what command
to do what. For this reason sudo works well even in places where a number of people
have root access, because it helps you keep track of changes made.
Although sudo can be used to give specific users specific privileges for specific tasks,
it does have several shortcomings. It should be used only for a limited set of tasks,
like restarting a server, or adding new users. Any program that offers a shell escape
will give root access to a user invoking it via sudo. This includes most editors, for
example. Also, a program as innocuous as /bin/cat can be used to overwrite files,
which could allow root to be exploited. Consider sudo as a means for accountability,
and don’t expect it to replace the root user and still be secure.
Physical Security
This summary is not available. Please click here to view the post.
Read more >>>Developing A Security Policy
Create a simple, generic policy for your system that your users can readily understand
and follow. It should protect the data you’re safeguarding as well as the privacy
of the users. Some things to consider adding are: who has access to the system
(Can my friend use my account?), who’s allowed to install software on the system,
who owns what data, disaster recovery, and appropriate use of the system.
A generally-accepted security policy starts with the phrase
“ That which is not permitted is prohibited”
This means that unless you grant access to a service for a user, that user shouldn’t
be using that service until you do grant access. Make sure the policies work on your
regular user account. Saying, "Ah, I can’t figure out this permissions problem, I’ll just
do it as root" can lead to security holes that are very obvious, and even ones that
haven’t been exploited yet.
rfc124411 is a document that describes how to create your own network security policy.
rfc128112 is a document that shows an example security policy with detailed descriptions
of each step.
Finally, you might want to look at the COAST policy archive at
ftp://coast.cs.purdue.edu/pub/doc/policy to see what some real-life security
policies look like.
Security How To (part 2)
Overview
This document will attempt to explain some procedures and commonly-used software
to help your Linux system be more secure. It is important to discuss some of
the basic concepts first, and create a security foundation, before we get started.
Why Do We Need Security?
In the ever-changing world of global data communications, inexpensive Internet connections,
and fast-paced software development, security is becoming more and more
of an issue. Security is now a basic requirement because global computing is inherently
insecure. As your data goes from point A to point B on the Internet, for example,
it may pass through several other points along the way, giving other users the opportunity
to intercept, and even alter, it. Even other users on your system may maliciously
transform your data into something you did not intend. Unauthorized access
to your system may be obtained by intruders, also known as "crackers", who then
use advanced knowledge to impersonate you, steal information from you, or even
deny you access to your own resources. If you’re wondering what the difference is
between a "Hacker" and a "Cracker", see Eric Raymond’s document, "How to Become
A Hacker", available at http://www.catb.org/~esr/faqs/hacker-howto.html.
How Secure Is Secure?
First, keep in mind that no computer system can ever be completely secure. All you
can do is make it increasingly difficult for someone to compromise your system. For
the average home Linux user, not much is required to keep the casual cracker at bay.
However, for high-profile Linux users (banks, telecommunications companies, etc),
much more work is required.
Another factor to take into account is that the more secure your system is, the more
intrusive your security becomes. You need to decide where in this balancing act your
system will still be usable, and yet secure for your purposes. For instance, you could
require everyone dialing into your system to use a call-back modem to call them back
at their home number. This is more secure, but if someone is not at home, it makes it
difficult for them to login. You could also setup your Linux system with no network
or connection to the Internet, but this limits its usefulness.
If you are a medium to large-sized site, you should establish a security
policy stating how much security is required by your site and what auditing
is in place to check it. You can find a well-known security policy example at
What Are You Trying to Protect?
Before you attempt to secure your system, you should determine what level of threat
you have to protect against, what risks you should or should not take, and how vulnerable
your system is as a result. You should analyze your system to know what
you’re protecting, why you’re protecting it, what value it has, and who has responsibility
for your data and other assets.
• Risk is the possibility that an intruder may be successful in attempting to access
your computer. Can an intruder read or write files, or execute programs that could
cause damage? Can they delete critical data? Can they prevent you or your company
from getting important work done? Don’t forget: someone gaining access to
your account, or your system, can also impersonate you.
Additionally, having one insecure account on your system can result in your entire
network being compromised. If you allow a single user to login using a .rhosts
file, or to use an insecure service such as tftp, you risk an intruder getting ’his
foot in the door’. Once the intruder has a user account on your system, or someone
else’s system, it can be used to gain access to another system, or another account.
• Threat is typically from someone with motivation to gain unauthorized access to
your network or computer. You must decide whom you trust to have access to
your system, and what threat they could pose.
There are several types of intruders, and it is useful to keep their different characteristics
in mind as you are securing your systems.
• The Curious - This type of intruder is basically interested in finding out what type
of system and data you have.
• The Malicious - This type of intruder is out to either bring down your systems, or
deface your web page, or otherwise force you to spend time and money recovering
from the damage he has caused.
• The High-Profile Intruder - This type of intruder is trying to use your system to
gain popularity and infamy. He might use your high-profile system to advertise
his abilities.
• The Competition - This type of intruder is interested in what data you have on
your system. It might be someone who thinks you have something that could
benefit him, financially or otherwise.
• The Borrowers - This type of intruder is interested in setting up shop on your
system and using its resources for their own purposes. He typically will run
chat or irc servers, porn archive sites, or even DNS servers.
• The Leapfrogger - This type of intruder is only interested in your system to use
it to get into other systems. If your system is well-connected or a gateway to a
number of internal hosts, you may well see this type trying to compromise your
system.
• Vulnerability describes how well-protected your computer is from another network,
and the potential for someone to gain unauthorized access.
What’s at stake if someone breaks into your system? Of course the concerns of a
dynamic PPP home user will be different from those of a company connecting their
machine to the Internet, or another large network.
Security How To (part 1)
Introduction
This document covers some of the main issues that affect Linux security. General
philosophy and net-born resources are discussed.
A number of other HOWTO documents overlap with security issues, and those documents
have been pointed to wherever appropriate.
This document is not meant to be a up-to-date exploits document. Large numbers of
new exploits happen all the time. This document will tell you where to look for such
up-to-date informati
New Versions of this Document
New versions of this document will be periodically posted to comp.os.linux.answers.
They will also be added to the various sites that archive such information, including:
http://www.linuxdoc.org/
The very latest version of this document should also be available in various formats
from:
• http://scrye.com/~kevin/lsh/
• http://www.linuxsecurity.com/docs/Security-HOWTO
• http://www.tummy.com/security-howto
Feedback
All comments, error reports, additional information and criticism of all sorts should
be directed to:
kevin-securityhowto@tummy.com5
and
dave@linuxsecurity.com6
Note: Please send your feedback to both authors. Also, be sure and include "Linux"
"security", or "HOWTO" in your subject to avoid Kevin’s spam filter.
Disclaimer
No liability for the contents of this document can be accepted. Use the concepts, examples
and other content at your own risk. Additionally, this is an early version,
possibly with many inaccuracies or errors.
A number of the examples and descriptions use the RedHat(tm) package layout and
system setup. Your mileage may vary.
As far as we know, only programs that, under certain terms may be used or evaluated
for personal purposes will be described. Most of the programs will be available,
complete with source, under GNU7 terms.
Copyright Information
This document is copyrighted (c)1998-2000 Kevin Fenzi and Dave Wreski, and distributed
under the following terms:
3
• Linux HOWTO documents may be reproduced and distributed in whole or in part,
in any medium, physical or electronic, as long as this copyright notice is retained
on all copies. Commercial redistribution is allowed and encouraged; however, the
authors would like to be notified of any such distributions.
• All translations, derivative works, or aggregate works incorporating any Linux
HOWTO documents must be covered under this copyright notice. That is, you
may not produce a derivative work from a HOWTO and impose additional restrictions
on its distribution. Exceptions to these rules may be granted under certain
conditions; please contact the Linux HOWTO coordinator at the address given below.
• If you have questions, please contact Tim Bynum, the Linux HOWTO coordinator,
at
tjbynum@metalab.unc.edu8
Profile
I am not a perfectionist, but I like to feel that things are done well. More important than that, I feel an endless need to learn, to improve,to evolve, not only to please the coach and the fans, but also to feel satisfied with myself. It is my conviction that here are no limits to learning, and that it can never stop, no matter what our age.
criticism and suggestion : twitter Read more >>>