466 lines
8.2 KiB
HTML
466 lines
8.2 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Frequently Asked Questions</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="Linux Security HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Glossary"
|
|
HREF="x1357.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Conclusion"
|
|
HREF="conclusion.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"
|
|
>Linux Security HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x1357.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="conclusion.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="sect1"
|
|
><H1
|
|
CLASS="sect1"
|
|
><A
|
|
NAME="q-and-a"
|
|
></A
|
|
>13. Frequently Asked Questions</H1
|
|
><P
|
|
>
|
|
<P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> Is it more secure to compile driver support directly into the
|
|
kernel, instead of making it a module?
|
|
</P
|
|
><P
|
|
> Answer: Some people think it is better to disable the ability to load
|
|
device drivers using modules, because an intruder could load a Trojan
|
|
module or a module that could affect system security.
|
|
</P
|
|
><P
|
|
> However, in order to load modules, you must be root. The module
|
|
object files are also only writable by root. This means the intruder
|
|
would need root access to insert a module. If the intruder gains root
|
|
access, there are more serious things to worry about than whether he
|
|
will load a module.
|
|
</P
|
|
><P
|
|
> Modules are for dynamically loading support for a particular device
|
|
that may be infrequently used. On server machines, or firewalls for
|
|
instance, this is very unlikely to happen. For this reason, it would
|
|
make more sense to compile support directly into the kernel for
|
|
machines acting as a server. Modules are also slower than support
|
|
compiled directly in the kernel.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Why does logging in as root from a remote machine always fail?
|
|
</P
|
|
><P
|
|
> Answer: See <A
|
|
HREF="local-security.html#root-security"
|
|
>Section 4.2</A
|
|
>. This is done
|
|
intentionally to prevent remote users from attempting to connect via
|
|
<TT
|
|
CLASS="literal"
|
|
>telnet</TT
|
|
> to your machine as <TT
|
|
CLASS="literal"
|
|
>root</TT
|
|
>, which is a serious
|
|
security
|
|
vulnerability, because then the root password would be transmitted, in
|
|
clear text, across the network. Don't forget: potential intruders have time on their
|
|
side, and can run automated programs to find your
|
|
password. Additionally, this is done to keep a clear record of who
|
|
logged in, not just root.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> How do I enable shadow passwords on my Linux box?
|
|
</P
|
|
><P
|
|
> Answer:
|
|
</P
|
|
><P
|
|
> To enable shadow passwords, run <TT
|
|
CLASS="literal"
|
|
>pwconv</TT
|
|
> as root, and
|
|
<TT
|
|
CLASS="literal"
|
|
>/etc/shadow</TT
|
|
> should now exist, and be used by applications.
|
|
If you are using RH 4.2 or above, the PAM modules will automatically
|
|
adapt to the change from using normal <TT
|
|
CLASS="literal"
|
|
>/etc/passwd</TT
|
|
> to shadow
|
|
passwords without any other change.
|
|
</P
|
|
><P
|
|
> Some background: shadow passwords is a mechanism for storing your
|
|
password in a file other than the normal <TT
|
|
CLASS="literal"
|
|
>/etc/passwd</TT
|
|
> file. This has
|
|
several advantages. The first one is that the shadow file,
|
|
<TT
|
|
CLASS="literal"
|
|
>/etc/shadow</TT
|
|
>, is only readable by root, unlike <TT
|
|
CLASS="literal"
|
|
>/etc/passwd</TT
|
|
>,
|
|
which must remain readable by everyone. The other advantage is that as the
|
|
administrator, you can enable or disable accounts without everyone
|
|
knowing the status of other users' accounts.
|
|
</P
|
|
><P
|
|
> The <TT
|
|
CLASS="literal"
|
|
>/etc/passwd</TT
|
|
> file is then used to store user and group names, used
|
|
by programs like <TT
|
|
CLASS="literal"
|
|
>/bin/ls</TT
|
|
> to map the user ID to the proper user name
|
|
in a directory listing.
|
|
</P
|
|
><P
|
|
> The <TT
|
|
CLASS="literal"
|
|
>/etc/shadow</TT
|
|
> file then only contains the user name and his/her
|
|
password, and perhaps accounting information, like when the account
|
|
expires, etc.
|
|
</P
|
|
><P
|
|
> To enable shadow passwords, run <TT
|
|
CLASS="literal"
|
|
>pwconv</TT
|
|
> as root, and
|
|
<TT
|
|
CLASS="literal"
|
|
>/etc/shadow</TT
|
|
> should now exist, and be used by applications.
|
|
Since you are using RH 4.2 or above, the PAM modules will automatically
|
|
adapt to the change from using normal <TT
|
|
CLASS="literal"
|
|
>/etc/passwd</TT
|
|
> to shadow
|
|
passwords without any other change.
|
|
</P
|
|
><P
|
|
> Since you're interested in securing your passwords, perhaps you would
|
|
also be interested in generating good passwords to begin with. For
|
|
this you can use the <TT
|
|
CLASS="literal"
|
|
>pam_cracklib</TT
|
|
> module, which is part of PAM. It
|
|
runs your password against the Crack libraries to help you decide if
|
|
it is too-easily guessable by password-cracking programs.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> How can I enable the Apache SSL extensions?
|
|
</P
|
|
><P
|
|
> Answer:
|
|
</P
|
|
><P
|
|
>
|
|
<P
|
|
></P
|
|
><OL
|
|
TYPE="a"
|
|
><LI
|
|
><P
|
|
> Get SSLeay 0.8.0 or later from <A
|
|
HREF="ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL"
|
|
TARGET="_top"
|
|
>�</A
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Build and test and install it!
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Get Apache source
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Get Apache SSLeay extensions from
|
|
<A
|
|
HREF="ftp://ftp.ox.ac.uk/pub/crypto/SSL/"
|
|
TARGET="_top"
|
|
>here</A
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Unpack it in the apache source directory and patch Apache as
|
|
per the README.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Configure and build it.
|
|
</P
|
|
></LI
|
|
></OL
|
|
>
|
|
|
|
</P
|
|
><P
|
|
> You might also try <A
|
|
HREF="http://www.zedz.net"
|
|
TARGET="_top"
|
|
>ZEDZ net</A
|
|
>
|
|
which has many pre-built packages, and is located outside of the United States.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> How can I manipulate user accounts, and still retain security?
|
|
</P
|
|
><P
|
|
> Answer: most distributions contain a great number of tools to change
|
|
the properties of user accounts.
|
|
</P
|
|
><P
|
|
>
|
|
<P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
> The <TT
|
|
CLASS="literal"
|
|
>pwconv</TT
|
|
> and <TT
|
|
CLASS="literal"
|
|
>unpwconv</TT
|
|
> programs can be used to convert
|
|
between shadow and non-shadowed passwords.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> The <TT
|
|
CLASS="literal"
|
|
>pwck</TT
|
|
> and <TT
|
|
CLASS="literal"
|
|
>grpck</TT
|
|
> programs can be used to verify proper
|
|
organization of the <TT
|
|
CLASS="literal"
|
|
>passwd</TT
|
|
> and <TT
|
|
CLASS="literal"
|
|
>group</TT
|
|
> files.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> The <TT
|
|
CLASS="literal"
|
|
>useradd</TT
|
|
>, <TT
|
|
CLASS="literal"
|
|
>usermod</TT
|
|
>, and <TT
|
|
CLASS="literal"
|
|
>userdel</TT
|
|
> programs can be used to
|
|
add, delete and modify user accounts. The <TT
|
|
CLASS="literal"
|
|
>groupadd</TT
|
|
>,
|
|
<TT
|
|
CLASS="literal"
|
|
>groupmod</TT
|
|
>, and <TT
|
|
CLASS="literal"
|
|
>groupdel</TT
|
|
> programs will do the same for groups.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Group passwords can be created using <TT
|
|
CLASS="literal"
|
|
>gpasswd</TT
|
|
>.
|
|
</P
|
|
></LI
|
|
></UL
|
|
>
|
|
|
|
</P
|
|
><P
|
|
> All these programs are "shadow-aware" -- that is, if you enable shadow
|
|
they will use <TT
|
|
CLASS="literal"
|
|
>/etc/shadow</TT
|
|
> for password information, otherwise they won't.
|
|
</P
|
|
><P
|
|
> See the respective man pages for further information.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> How can I password-protect specific HTML documents using
|
|
Apache?
|
|
</P
|
|
><P
|
|
> I bet you didn't know about <A
|
|
HREF="http://www.apacheweek.com"
|
|
TARGET="_top"
|
|
>http://www.apacheweek.org</A
|
|
>, did you?
|
|
</P
|
|
><P
|
|
> You can find information on user authentication at <A
|
|
HREF="http://www.apacheweek.com/features/userauth"
|
|
TARGET="_top"
|
|
>http://www.apacheweek.com/features/userauth</A
|
|
> as well as other
|
|
web server security tips from <A
|
|
HREF="http://www.apache.org/docs/misc/security_tips.html"
|
|
TARGET="_top"
|
|
>http://www.apache.org/docs/misc/security_tips.html</A
|
|
>
|
|
</P
|
|
></LI
|
|
></OL
|
|
>
|
|
|
|
</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="x1357.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="conclusion.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Glossary</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Conclusion</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |