586 lines
14 KiB
HTML
586 lines
14 KiB
HTML
<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
|
|
> |