This document shows system administrators how to secure their systems better. There are no guarantees of its completeness. In addition, the author takes no responsibility if a person misuses this information.
For a shortened version, please see our security checklist
Often the subject of internal security is overlooked. However,
often it is fairly easy for someone to get access to systems they
are not supposed to have access by simply walking up to a valid users
desk. This can be the cleaning staff or a disgruntled (ex)employee
making a visit. This is the easiest type of security to implement
and should definitely be included in any security plan.
Machines and consoles need to be secure. A person can simply turn off
a computer if one has access to it. If they have access to the console,
they can often interrupt the boot process to get access to the root
prompt. If this doesn't work, they can keep guessing the root password
in hopes of compromising the system. For these reasons (and more),
the computers and associated consoles should be kept in a secure room.
A limited number of people should have access to this room, of course
with a limited number of keys. Some places actually have security guards
let people into the computer rooms for guaranteed secure access.
If your data is sensitive, be certain to verify that there are no alternative
methods for getting into the room. This includes hidden spare keys
in an unsecured place, gaps in the raised floors that go past the locked
access point, and space above the ceilings.
Companies that value their data need a detailed backup recovery scheme.
This includes on site backups for least amount of down time, a copy
of this data off site in case of computer room disasters, as well as
contingency plans in place. Unfortunately, an easy way to
get access to a companies data is to gain access to backup tapes
and sensitive printouts.
Hence, all sensitive information should be stored in locked cabinets.
Backup tapes sent off site should be in locked containers.
Old sensitive printouts and tapes should be destroyed.
To protect against computer damage from power outages (and spikes),
be certain to have your computers on a UPS. This provides consistent
power, protects against outages, as well as protects the computer from
power spikes. Ideally, there should be a backup generator for production
systems. For non-production systems, there should be a automatic way to
shutdown the computer if the power has switched to the UPS for more than
1/2 the time the UPS is rated to supply.
To prevent snooping, secure network cables from exposure.
Always have users lock their screen when away from their desk.
It is best if they log off of their terminal/workstation at night.
There should be no written passwords or password hints on a users desk.
If users are using X, verify that they are using xauth/xhost
to prevent others from reading their screen.
Court cases have shown that initial banners must NOT say "welcome".
Once you put a computer on a network, you allow many more people potential
access to the machine. Without networks, often a machine is not useful.
The key to network security is to allow only those functions that the
users actually need. Make those services as secure as possible. By
disabling non-used functions, you have much less monitoring/securing.
Think of filtering as a way to prevent unwanted access.
If on the internet or large network, you will want a firewall machine or router with firewalling capabilities for maximum protection.
Hosts themselves can limit the services
provided and what hosts can access them.
A firewall machine is a machine between the internet and your
network. It provides a point of resistance. It protects your inside
systems from external users. A firewall machine can filter your packets
and/or be a proxy server.
By filtering
out services you do not use, at the router level (or firewall machine), potential infiltraters
are stopped very early on. Unless you use NFS between networks,
turn off all RPC ports on the router. Better yet, only enable specific ports
that you use, adding new ones as needed. The next steps are on the host itself.
Create access control lists /var/adm/inetd.sec to say what hosts can connect
to your machine. This limits access even further. In addition,
do not enable services you are not using by turning them off in /etc/inetd.conf.
TCP wrappers for logging incoming requests allows for easier tracing and protection.
One can imitate another host on a network by using the same host name.
To prevent this from happening outside your network, you need to
make modifications to your router and your hosts system files.
Turn off source routing on your router. Once this is turned off,
apply a filter that guarantees that packets coming in from the outside network do not have a source IP address that matches the inside network. This prevents
another machine from pretending it is a trusted host.
On your system side, only use qualified hostnames only in any system file (NFS, hosts.equiv, ...). If possible, do not allow
hosts.equiv or .rhosts. Having a cron job remove non-agreed upon ones is great.
Verify that all .rhost and .netrc files (if allowed) permissions are 600.
Having the cron job automatically fix this is great too.
As with other services, if you do not need this functionality, turn it off.
You can turn off incoming FTP or simply certain users. If you
need full FTP functionality, be certain to enable logging and monitor syslog.
Since you only want valid users using FTP,
make sure you have /etc/ftpusers include all system accounts (uucp, bin, daemon, sys, adm, lp, root, ...). If there are other users who do not need
FTP, also place them in this file.
Only allow the users that actually need them. Give them the
least amount of access possible. Do not allow writable
directories unless absolutely necessary. If writable directories are needed,
sometimes write only directories can be utilized.
Having modems hooked up to one central point makes security easier.
All modems should have additional dial-up password for additional security.
To do this, setup /etc/d_passwd (see d_passwd man page). Once you are
finished, verify that passwords are not guessable by using CRACK.
As usual, use one password per user. Be certain to disable the account
when the user no longer needs access.
All dial-up modems should log users out upon disconnect (hupcl in /etc/gettydefs)
Use SATAN to make sure you haven't missed any obvious holes.
Add all your networking patches. Try to break into your site.
If your accounts are not secure, then your other steps won't help much.
There is general password security as well as special steps to
take for each type of account.
You want to make sure all accounts have a non-guessable password.
To ensure that the passwords are not guessable, use crack on a regular
basis. In addition, be certain that passwords are changed from time to
time. Ideally, use one time passwords such as skey.
Accounts should be disabled when there are several bad logins in a row.
An easy way to implement password security on HP systems is
using HP's trusted system package (via SAM). This is only
available if you are NOT running NIS or NIS+.
Be certain that passwords are not written down. Often people
will use their license plate numbers or children's names. Unfortunately,
these are easy to guess passwords. Also, they will use passwords from
their favorite hobby. Have your password dictionary include checking these
passwords.
Having no .netrc files strengthens security.
It is easiest to track changes and security violations when
very few people who have root access,
The root password needs to be a strong non-guessable password.
In addition, change the root password every 3 months & whenever someone leaves company.
Always logout of root shells; never leave root shells unattended.
The only place where root should be able to log onto directly
should be the console (as specified in /etc/securetty).
Only root should have UID 0.
Check root dot files for security holes. Aliases should have
full pathnames. Root should NEVER have "." in path. The root dot
files should ONLY have 700 permissions.
The minimal umask for root is 022 (rwxr-xr-x). It is better to have
a umask of 077 (rwx------) but often this isn't practical.
To avoid trojan horse programs,
always use full path when not at console.
Also, never allow non-root write access to ANY directories in root's path.
If possible, do not create root's tmp files in publicly
writable directories.
As with any account, only create guest accounts for the time it s needed.
Remove the account when its purpose is completed.
Use non-standard account names for guest accounts. Do not use "guest".
Instead use account names such as: "fixomni" or "oratmp".
Guest accounts should have a strong password and a restricted shell.
If reasonable, give guest accounts a strong umask such as 077.
User accounts should not be shared. Remove user accounts upon termination.
Disable login for well known accounts that do not need direct login access (bin,daemon,sys,uucp,lp,adm).
User accounts should have a strong password and in some cases, a restricted shell.
If reasonable, give guest accounts a strong umask such as 077.
File system security is about making sure your users can only do what
you want them to be able to do. This means that you want system programs
to be secure and users to only be able to write where you want them to be able to do so.
Only run NFS as needed, apply latest patches. When creating
your /etc/exports file, be certain to use limited access flags when
possible such as readonly or nosuid. By using fully qualified hostnames,
you are guaranteed that only the host you want to be able to access
the filesystem can access it.
Device files /dev/null, /dev/tty & /dev/console should be world writeable but NEVER executable.
Most other device files should be unreadable and unwriteable by regular users.
Never write setuid/setgid shell scripts (can break out). Instead,
write a compiled program in a language like "C".
Scripts should ALWAYS have full pathnames.
Always get your programs from a known source. Verify that it
hasn't been hampered with via checksum. If you are compiling your
own program, make sure you know that the compiler hasn't been tampered
with as well.
Create minimal writable filesystems (esp. system files/directories!).
Generally, users should only be able to write in their own directories,
and /tmp. In addition, there will be directories for a specific group
to write in. This way you control how each user can access specific
areas of the system.
Make sure that important files are only accessible by authorized personnel.
Use setuid/setgid only where necessary.
COPS will find many of these problems.
Security is an ongoing process. However, once the software is installed and initial checks completed,
it can be a simple maintenance task of installing latest patches, verifying user accounts, running security software (and their extensions) and monitoring logs.
Subscribe to security mailing lists. Read security newsgroups. Keep up to date on the latest security procedures.
Test w/ SATAN (network security), COPS (Various system checks), TIGER (ways for root to be compromised), and CRACK (password checker).
Install Tripwire to detects changes to files).
Check btmp, wtmp, syslog, sulog etc. regularly. Set up
automatic email or paging to warn system administrators of any
suspicious behavior.
Here is a list of security books that I have found useful. Hopefully,
you will like them too!
This is the book crackers seem to read. Hence, read it so you can protect your machines from them. It is not as advanced as many books -- but it does go through many of the basics as well as giving ideas and concepts.
A personal favorite. If you are in charge of internet security, read it.
Comprehensive and well written.
Straight forward. Basic Unix security. Somewhat dated but still quite helpful.
Very nice for Unix security. Easy to read.
If you are starting, this is a great book to begin with. It is a useful overview though somewhat outdated.
Nice book -- has alot on IP filtering.
Useful.
Pages are © Copyright 1998 Lorraine Venner.
File System Security * Testing Security * Security Websites
Security Books
Your banner should say something like: "Only authorized access allowed;
violators will be prosecuted". In addition, change /etc/issue to NOT include the machine type/OS revision.
File System Security * Testing Security * Security Websites
Security Books
File System Security * Testing Security * Security Websites
Security Books
File System Security * Testing Security * Security Websites
Security Books
File System Security * Testing Security * Security Websites
Security Books
File System Security * Testing Security * Security Websites
Security Books
General
A multiple project, multiple investigator laboratory in computer security research in the Computer Sciences Department at Purdue University
A list of links to information sources on Network and Computer Security.
The source for Java Technology
Security Resource Net
ISS Security Library: Adaptive Network Security
A great resource of the latest security sites by COAST
Includes nice section on why to publish this information and great links
Great network security guidelines, information, and conferences
Sun Security Information, patches, FAQs
Nice site on securing linux - though work on it is suspended.
Links: Security Advisories, "White" Papers, Organizations/Research Groups, Companies and Commercial Products, Security Archives/References, Projects, Security Mailing lists
File System Security * Testing Security * Security Websites
Security Books
File System Security * Testing Security * Security Websites
Security Books