This section will quickly address some general concepts for maintaining a
more secure and reliable system or network. Let's emphasize
"maintaining" here since computer systems change daily, as does
the environment around them. As mentioned before, there isn't any one thing
that makes a system secure. There are too many variables. Security is an
approach and an attitude more than it is a reliance on any particular
product, application or specific policy.
Do not allow remote root logins. This may be controlled by a configuration
file such as /etc/securetty. Remove any lines
that begin "pts". This is one big security hole.
In fact, don't log in as root at all. Period. Log in on your user account
and su to root when needed. Whether the login is remote
or local. Or use sudo, which can run individual commands
with root privileges.
(There should be a sudo package
available from your vendor.)
This takes some getting used to, but it is
the "right" way to do things. And the safest. And will become
more a more natural way of doing this as time goes on.
I know someone is saying right now "but that is so much trouble, I am
root, and it is my system". True, but root is a specialized account that
was not ever meant to be used as a regular user account. Root has access to
everything, even hardware devices. The system "trusts" root.
It believes that you know what you are doing. If you make a mistook, it
assumes that you meant that, and will do it's best to do what you told it
to do...even if that destroys the system!
As an example, let's say you start X as root, open
Netscape, and visit a web site. The web page has
badly behaved java script. And conceivably now that badly written java
script might have access to much more of your system than if you had done
it the "right" way.
Take passwords seriously. Don't give them out to anyone. Don't use the same
one for everything. Don't use root's password for anything else -- except
root's password! Never sign up or register on line, using any of your
system passwords. Passwords should be a combination of mixed case letters,
numbers and/or punctuation and a reasonable length (eight characters or
longer). Don't use so-called "dictionary" words that are easy
to guess like "cat" or "dog". Don't incorporate
personal information like names or dates or hostnames. Don't write down
system passwords -- memorize them.
Use the more secure "shadow" passwords. This
should be the default for any recent Linux distribution now.
If
the file /etc/shadow exists, then it is enabled
already. The commands pwconv and
grpconv, can be used to convert password and group files
to shadow format if available.
Avoid using programs that require clear text logins over untrusted networks
like the Internet. Telnet is a prime example.
ssh is much better. If there is any support for
SSL (Secure Socket Layers), use it. For instance, does your ISP offer POP
or IMAP mail via SSL? Recent distributions should include
openssl, and many
Linux applications can use SSL where support is available.
Set resource limits. There are various ways to do this. The need for
this probably increases with the number of users accessing a given system.
Not only does setting limits on such things as disk space prevent
intentional mischief, it can also help with unintentionally misbehaved
applications or processes. quota (man
quota) can be used to set disk space limits.
Bash includes the ulimit
command (man ulimit or man bash),
that can limit various functions on a per user basis.
Also, not discussed here at any length, but PAM
(Pluggable Authentication Modules) has a very sophisticated approach to
controlling various system functions and resources. See man
pam to get started. PAM is configured
via either /etc/pam.conf or
/etc/pam.d/*. Also files in
/etc/security/*, including
/etc/security/limits.conf, where again various sane
limits can be imposed. An in depth look at PAM
is beyond the scope of this document. The
User-Authentication HOWTO (http://linuxdoc.org/HOWTO/User-Authentication-HOWTO/index.html) has more on this.
Make sure someone with a clue is getting root's mail. This can be done with an
"alias". Typically, the mail server will have a file such
as /etc/aliases where this can defined. This can
conceivably be an account on another machine if need be:
# Person who should get root's mail. This alias
# must exist.
# CHANGE THIS LINE to an account of a HUMAN
root: hal@bigcat
Remember to run newaliases (or equivalent) afterward.
Be careful where you get software. Use trusted sources. How well do you
trust complete strangers? Check your vendor
first if looking for a
specific package. It will probably be best suited for your system any way.
Or, the original package's project site is good as well. Installing from raw
source (either tarball or src.rpm) at least gives you the ability to
examine the code. Even if you don't understand it ;-) While this does not
seem to be a wide spread problem with Linux software sites, it is very
trivial for someone to add a very few lines of code, turning that harmless
looking binary into a "Trojan horse" that opens a backdoor to
your system. Then the jig is up.
So someone has scanned you, probed you, or otherwise seems to want into
your system? Don't retaliate. There is a good chance that the source IP
address is a compromised system, and the owner is a victim already. Also,
you may be violating someone's Terms of Service, and have trouble with
your own ISP. The best you can do is to send your logs to the abuse
department of the source IP's ISP, or owner. This is often
something like "abuse@someisp.com". Just don't expect to
hear much back. Generally speaking, such activity is not legally
criminal, unless an actual break-in has taken place. Furthermore,
even if criminal, it will never be prosecuted unless significant
damage (read: big dollars) can be shown.
Red Hat,Mandrake and Debian users can install the "Bastille
Hardening System", http://www.bastille-linux.org/.
This is a multi-purpose system for "hardening" Red Hat and
Mandrake system security. It has a GUI interface which can be used to
construct firewall scripts from scratch and configure
PAM among many other things. Debian support
is new.
So you have a full-time Internet connection via cable-modem or DSL. But
do you always use it, or always need it? There's an old saying that
"the only truly secure system, is a disconnected system".
Well, that's certainly one option. So take that interface down, or stop the
controlling daemon (dhcpcd, pppoed,
etc). Or possibly even set up cron jobs to bring your
connection up and down according to your normal schedule and usage.
What about cable and DSL routers that are often promoted as
"firewalls"? The lower priced units are mostly equating
NAT (Network Address Translation), together with the ability to open holes
for ports through it, as a firewall. While NAT itself does provide a fair
degree of security for the systems behind the NAT gateway, this does not
constitute anything but a very rudimentary firewall. And if holes are
opened, there is still exposure. Also, you are relying on the router's
firmware and implementation not to be flawed. It is wise to have some kind
of additional protection behind such routers.
What about wireless network cards and hubs? Insecure, despite what
the manufacturers may claim. Treat these connections just as you would an
Internet connection. Use secure protocols like ssh
only! Even if it is just one LAN box to another.
If you find you need to run a particular service, and it is for just you,
or maybe a relatively small number of people, use a non-standard port. Most
server daemons support this. For instance, sshd runs on
port 22 by default. All worms and script kiddies will expect it there, and
look for it there. So, run it on another port! See the sshd
man page.
Lastly, know your system! Let's face it, if you are new to Linux, you can't
already know something you have never used. Understood. But in the process
of learning, learn how to do things the right way, not the easiest way.
There is several decades of history behind "the right way" of
doing things. This has stood the test of time. What may seem unnecessary or
burdensome now, will make sense in due time.
Be familiar with whatever services you are running, and the implications
these services might have to the overall health of your system if
something does go wrong. Read what you can, and ask questions. Don't run
something as a service "just because I can", or because the
installer put it there. You can't start out being an experienced System
Administrator clearly. But you can work to learn enough about your own
system, that you are in control. This is one thing that separates *nix from
MS systems: we can never be in complete control with MS, but we can with
*nix. Conversely, if something bad happens, we often have no one else to
blame.