<HTML
><HEAD
><TITLE
>General Tips</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="Security Quick-Start HOWTO for Red Hat Linux"
HREF="index.html"><LINK
REL="PREVIOUS"
TITLE="Intrusion Detection"
HREF="intrusion.html"><LINK
REL="NEXT"
TITLE="Appendix"
HREF="appendix.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Security Quick-Start HOWTO for Red Hat Linux</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="intrusion.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="appendix.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="GENERAL">7. General Tips</H1
><P
> This section will quickly address some general concepts for maintaining a
more secure and reliable system or network. Let's emphasize
<SPAN
CLASS="QUOTE"
>"maintaining"</SPAN
> 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.
</P
><P
> <P
></P
><UL
><LI
><P
>
Do not allow remote root logins. This may be controlled by a configuration
file such as <TT
CLASS="FILENAME"
>/etc/securetty</TT
>. Remove any lines
that begin <SPAN
CLASS="QUOTE"
>"pts"</SPAN
>. This is one big security hole.
</P
></LI
><LI
><P
> In fact, don't log in as root at all. Period. Log in on your user account
and <B
CLASS="COMMAND"
>su</B
> to root when needed. Whether the login is remote
or local. Or use <B
CLASS="COMMAND"
>sudo</B
>, which can run individual commands
with root privileges.
(Red hat includes a <B
CLASS="COMMAND"
>sudo</B
> package. )
This takes some getting used to, but it is
the <SPAN
CLASS="QUOTE"
>"right"</SPAN
> way to do things. And the safest. And will become
more a more natural way of doing this as time goes on.
</P
><P
> I know someone is saying right now <SPAN
CLASS="QUOTE"
>"but that is so much trouble, I am
root, and it is my system"</SPAN
>. 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 <SPAN
CLASS="QUOTE"
>"trusts"</SPAN
> 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!
</P
><P
> As an example, let's say you start X as root, open
<SPAN
CLASS="APPLICATION"
>Netscape</SPAN
>, 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 <SPAN
CLASS="QUOTE"
>"right"</SPAN
> way.
</P
></LI
><LI
><P
> 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 <SPAN
CLASS="QUOTE"
>"dictionary"</SPAN
> words that are easy
to guess like <SPAN
CLASS="QUOTE"
>"cat"</SPAN
> or <SPAN
CLASS="QUOTE"
>"dog"</SPAN
>. Don't incorporate
personal information like names or dates or hostnames. Don't write down
system passwords -- memorize them.
</P
><P
> Use the more secure <SPAN
CLASS="QUOTE"
>"shadow"</SPAN
> passwords.
This has been the default on Red Hat for some time now. If
the file <TT
CLASS="FILENAME"
>/etc/shadow</TT
> exists, then it is enabled
already. The commands <B
CLASS="COMMAND"
>pwconv</B
> and
<B
CLASS="COMMAND"
>grpconv</B
>, can be used to convert password and group files
to shadow format if available.
</P
></LI
><LI
><P
> Avoid using programs that require clear text logins over untrusted networks
like the Internet. <B
CLASS="COMMAND"
>Telnet</B
> is a prime example.
<B
CLASS="COMMAND"
>ssh</B
> 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
Red Hat releases do include <SPAN
CLASS="APPLICATION"
><A
HREF="http://www.openssl.org/"
TARGET="_top"
>openssl</A
></SPAN
>, and many
Linux applications can use SSL where support is available.
</P
></LI
><LI
><P
> 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. <B
CLASS="COMMAND"
>quota</B
> (<TT
CLASS="LITERAL"
>man
quota</TT
>) can be used to set disk space limits.
<SPAN
CLASS="APPLICATION"
>Bash</SPAN
> includes the <B
CLASS="COMMAND"
>ulimit</B
>
command (<TT
CLASS="LITERAL"
>man ulimit</TT
> or <TT
CLASS="LITERAL"
>man bash</TT
>),
that can limit various functions on a per user basis.
</P
><P
> Also, not discussed here at any length, but <SPAN
CLASS="APPLICATION"
>PAM</SPAN
>
(Pluggable Authentication Modules) has a very sophisticated approach to
controlling various system functions and resources. See <TT
CLASS="LITERAL"
>man
pam</TT
> to get started. <SPAN
CLASS="APPLICATION"
>PAM</SPAN
> is configured
via either <TT
CLASS="FILENAME"
>/etc/pam.conf</TT
> or
<TT
CLASS="FILENAME"
>/etc/pam.d/*</TT
>. Also files in
<TT
CLASS="FILENAME"
>/etc/security/*</TT
>, including
<TT
CLASS="FILENAME"
>/etc/security/limits.conf</TT
>, where again various sane
limits can be imposed. An in depth look at <SPAN
CLASS="APPLICATION"
>PAM</SPAN
>
is beyond the scope of this document. The
User-Authentication HOWTO (<A
HREF="http://tldp.org/HOWTO/User-Authentication-HOWTO/index.html"
TARGET="_top"
>http://tldp.org/HOWTO/User-Authentication-HOWTO/index.html</A
>) has more on this.
</P
></LI
><LI
><P
> Make sure someone with a clue is getting root's mail. This can be done with an
<SPAN
CLASS="QUOTE"
>"alias"</SPAN
>. Typically, the mail server will have a file such
as <TT
CLASS="FILENAME"
>/etc/aliases</TT
> where this can defined. This can
conceivably be an account on another machine if need be:
</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>
# Person who should get root's mail. This alias
# must exist.
# CHANGE THIS LINE to an account of a HUMAN
root: hal@bigcat
</PRE
></FONT
></TD
></TR
></TABLE
>
</P
><P
> Remember to run <B
CLASS="COMMAND"
>newaliases</B
> (or equivalent) afterward.
</P
></LI
><LI
><P
> Be careful where you get software. Use trusted sources. How well do you
trust complete strangers? Check
Red Hat's ftp site (or mirrors) 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 <SPAN
CLASS="QUOTE"
>"Trojan horse"</SPAN
> that opens a backdoor to
your system. Then the jig is up.
</P
></LI
><LI
><P
> 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 <SPAN
CLASS="QUOTE"
>"abuse@someisp.com"</SPAN
>. 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.
</P
></LI
><LI
><P
> Red Hat users can install the <SPAN
CLASS="QUOTE"
>"Bastille
Hardening System"</SPAN
>, <A
HREF="http://www.bastille-linux.org/"
TARGET="_top"
>http://www.bastille-linux.org/</A
>.
This is a multi-purpose system for <SPAN
CLASS="QUOTE"
>"hardening"</SPAN
> Red Hat and
Mandrake system security. It has a GUI interface which can be used to
construct firewall scripts from scratch and configure
<SPAN
CLASS="APPLICATION"
>PAM</SPAN
> among many other things. Debian support
is new.
</P
></LI
><LI
><P
> 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
<SPAN
CLASS="QUOTE"
>"the only truly secure system, is a disconnected system"</SPAN
>.
Well, that's certainly one option. So take that interface down, or stop the
controlling daemon (<B
CLASS="COMMAND"
>dhcpcd</B
>, <B
CLASS="COMMAND"
>pppoed</B
>,
etc). Or possibly even set up <SPAN
CLASS="APPLICATION"
>cron</SPAN
> jobs to bring your
connection up and down according to your normal schedule and usage.
</P
></LI
><LI
><P
> What about cable and DSL routers that are often promoted as
<SPAN
CLASS="QUOTE"
>"firewalls"</SPAN
>? 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.
</P
></LI
><LI
><P
> 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 <SPAN
CLASS="APPLICATION"
>ssh</SPAN
>
only! Even if it is just one LAN box to another.
</P
></LI
><LI
><P
> 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, <B
CLASS="COMMAND"
>sshd</B
> 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 <B
CLASS="COMMAND"
>sshd</B
>
man page.
</P
></LI
><LI
><P
> What about firewalls that block Internet connections according to the
application (like <SPAN
CLASS="APPLICATION"
>ZoneAlarm</SPAN
> from Windowsdom)?
These were designed with this feature primarily because of the plethora
of virii and trojans that are so common with MS operating systems. This
is really not a problem on Linux. So, really no such application exists
on Linux at this time. And there does not seem to be enough demand for it
that someone has taken the time to implement it. A better firewall can be
had on Linux, by following the other suggestions in this document.
</P
></LI
><LI
><P
> 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 <SPAN
CLASS="QUOTE"
>"the right way"</SPAN
> of
doing things. This has stood the test of time. What may seem unnecessary or
burdensome now, will make sense in due time.
</P
><P
> 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 <SPAN
CLASS="QUOTE"
>"just because I can"</SPAN
>, 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.
</P
></LI
></UL
></P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="intrusion.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="appendix.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Intrusion Detection</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
> </TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Appendix</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
