<!doctype linuxdoc system>

<article>

<title>"Pocket" ISP based on RedHat Linux HOWTO
<author>Anton Chuvakin, <tt>
<htmlurl url="mailto:anton@chuvakin.org" name="anton@chuvakin.org"></tt>
<date>v2.0.0 10 January 2001</date>
<abstract>
  This document outlines the setup of a single RedHat box for dialins, virtual
  web hosting, virtual email, POP3 and ftp servers. Why anybody might need
  this in one box is beyond the scope of this document. The idea is a complete
  ISP solution based on RedHat Linux. Any part of this setup can be
  implemented separately though. I will try to emphasize all the commands so
  one can just paste them to configure his own box.  The list of documents
  that I borrowed from and some further reading is provided below (see References section).
I will keep security in mind on all stages of the setup and will make
clear all the security limitations of this setup, that I am aware of.
I should add that assets that are to be
protected in this case are considered not very valuable (e.g. personal pages etc) thus
efforts spent on securing the setup are allowed to be limited.
</abstract>
<toc>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
  <sect> Introduction
<p>
    The guide assumes some familiarity with Linux functionality and general
    Linux/UNIX setup procedure (although not very detailed). Fully functional
    brain is also required for some stages of the procedure. All setup would
    be done manually (without the use of <htmlurl url="http://www.solucorp.qc.ca/linuxconf/" name="linuxconf">,
<htmlurl url="http://www.webmin.com/webmin/" name="Webmin"> or other
    tools). Not that those are bad or that there is anything wrong with them. The
reasons for that are: 1) it is comparatively hard to give step by step directions
that produce predictable results as these tools pretend they are intelligent
and "know better" (also known as "Windows syndrome") 2) layout of tools changes with time and is different
 in some distributions 3) manual setup gives better understanding of system works
 (not that it is always required though) 4)some tools allow only limited
configuration of Linux system or do not keep up with updated features of
services they try to configure.
<p>
I should add, that another solution seems to be very promising. It is
<htmlurl url="http://www.prongs.org/virtfs" name="virtfs">
developed by
<htmlurl url="mailto:afra@prongs.org" name="Afra Ahmad">. Its main part is a
perl script so it does not suffer from being a "black box". It will
automatically configure all virtual services in a highly customizable fashion.

It is based on taking
advantage of the chroot environment. A separate and smaller filesystem is
created for each virtual server, and when a service is requested, the main
server will chroot to the desired virtual server.

This method may take up more disk space, but it is much more flexible,
especially when dealing with the services. For example, it is possible to have
two different email accounts bob@vdomain1.com and bob@vdomain2.com (as you are
dealing with two different passwd files). It might be essential for a bigger
hosting site.

For more information please visit the Virtfs page at
<htmlurl url="http://www.prongs.org/virtfs" name="http://www.prongs.org/virtfs">.

While many improvements are possible to the setup described in this HOWTO they might be
    described in later editions of this document - I just outline one possible
    way (accidentally, the one I used). The writeup is aimed at RedHat Linux,
    but with trivial changes can be used on any modern Linux distribution.
 The resulting configuration loosely follows
the setup of some particular machines built by the author.
    <p>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
  <sect> Changes<p>
<bf>from 1.1.1 to 2.0.0</bf>
<p>
<itemize>
<item>
References updated (single IP hosting)
<item>
RedHat 7.0 based
<item>
</itemize>

<bf>from 1.1.0 to 1.1.1</bf>
<p>
<itemize>
<item>
Partitioning scheme described
<item>
Some comments to dialin server setup added (based on user feedback)
<item>
Some comments to ftp server setup added (based on user feedback)
</itemize>

<bf>from 1.0.3 to 1.1.0</bf>
<p>
<itemize>
<item>
Description of virtfs added
<item>
Qpopper and WUftpd bugs described

<item>
Double connections issue mentioned as requested by one of the readers
<item>
POP-only accounts described
  <item>
References added                                                                              
</itemize>

<bf>from 1.0.2 to 1.0.3</bf>
<p>
<itemize>
<item>
Some spelling errors corrected (thanks to Eugene Shishkin for that)
</itemize>

<bf>from 1.0.1 to 1.0.2</bf>
<p>
<itemize>
<item>
<it>Some</it> errors corrected (spelling)
<item>
Method to chroot non-anonymous ftp users ("guest" users; those with password
and usernames, but with access only to their home directories;
used for <it>easy</it> web updates)
<item>
References section updated
<item>
Troubleshooting subsections added to two sections
<item>
Qpopper update
</itemize>

<bf>from 1.0.0 to 1.0.1</bf>
<p>
<itemize>
<item>
<it>Many</it> errors corrected (both spelling and factual)
<item>
References section updated
<item>
Minor changes in wording and syntax to improve clarity
<item>
More security info added to several sections
<item>
Windows configuration for dialup added
</itemize>
<p>
<bf>Next update planned at:</bf> upon request or when new program versions are released

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
  <sect> TODO Tue Jan  9 13:14:15 EST 2001
<p>
<itemize>
<item>
How to test each service section added! (including maybe strace:
(mkdir /tmp/strace; mv .../in.ftpd .../in.ftpd.binary, create               
    a two line shell script named in.ftpd with: #!/bin/sh  and                  
    'strace -o /tmp/strace/ftpd.out .../in.ftpd.binary' ---                     
    I've described strace wrappers and reading strace output                    
    in past LG articles; search for some hints))

<item>
More on security of all the services we install (clear text password, DoS by
overflowing partition in mail and ftp, http access configs etc), including
maybe the very basic ipchains setup (ipchains as safer alternative to tcp wrappers)
<item>
Add info on POP3 and ftp tunneling via ssh (just for fun) or refer to other HOWTOs
<item>
Add troubleshooting subsections to various sections
<item>
Add SSL-enabled Apache install and basic configuration
<item>
Add news server setup - who needs it?
<item>
User accounting setup (acc, acua)
<item>                                                                         
Description of  mail-only users (playing with proxyarp and restricting their     
access only to the local machine)
</itemize>

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<sect1> New versions of this document
<p>
New versions of this document can be found at

<tt>
<htmlurl url="http://www.chuvakin.org/ispdoc" name="http://www.chuvakin.org/ispdoc">
</tt>

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect1> Feedback
<p>
All comments, error reports, additional information (very much appreciated!!!) and criticism
of all sorts should be directed to:
<tt>
<htmlurl url="mailto:anton@chuvakin.org" name="anton@chuvakin.org">
</tt>
<p>
<tt>
<htmlurl url="http://www.chuvakin.org/"
name="http://www.chuvakin.org/">
</tt>
<p>
My PGP key is located at <tt>
<htmlurl url="http://www.chuvakin.org/pgpkey" name="http://www.chuvakin.org/pgpkey"></tt>
<p>
Please direct spelling error comments to your friendly local spell checker.<p>
If you plan to ask for <bf>help</bf>, see support section first.

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect1> Standard disclaimer
<p>
No liability for the contents of this document can be accepted.
Use the concepts, examples and other content at your own risk.
Additionally, this is an early version, with many possibilities
for inaccuracies and errors.
<p>
One of many possible setups will be described. In the Linux
world, there is usually a number of ways in which to accomplish
things.
<p>
As far as I know, only programs that under certain terms may be
used or evaluated for personal purposes will be described. Most
of the programs will be available complete with source under
GNU-like terms.
<p>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect1> Support
<p>
This is ridiculous, right? Who may ask for support after seeing such a
comprehensive doc ;-) ? <p>
Anyhow, if you are curious about some particular aspect of this setup or some
of my writing is unclear, just drop me an email and I <it>might</it> answer it
(at least, be assured that I will read it).
<p>
Now, if you require a phone, hand-holding style support or <bf>my</bf> work on
<bf>your</bf> system, I <it>might</it> be able to provide it on certain terms
(if I have time and your case seems interesting enough ;-) )
<p>

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect1> Copyright information
<p>
This document is copyrighted (c) 2000,2001 Anton Chuvakin and
distributed under the following terms:
<p>
<itemize>
<item> Linux HOWTO documents may be reproduced and distributed in
whole or in part, in any medium physical or electronic, as long
as this copyright notice is retained on all copies. Commercial
redistribution is allowed and encouraged; however, the author
would like to be notified of any such distributions.
<item> All translations, derivative works, or aggregate works
incorporating any Linux HOWTO documents must be covered under
this copyright notice.  That is, you may not produce a derivative
work from a HOWTO and impose additional restrictions on its
distribution. Exceptions to these rules may be granted under
certain conditions; please contact the Linux HOWTO coordinator at
the address given below.
<item> If you have questions, please contact Greg Hankins, the
Linux HOWTO coordinator, at
</itemize>
<tt>
<htmlurl url="mailto:gregh@sunsite.unc.edu" name="gregh@sunsite.unc.edu">
</tt>

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect> Step by step guide
<p>

Ingredients needed:
 <itemize>
      <item>
RedHat Linux distribution (the instructions are exactly applicable to RedHat
6.x or 7.x and, I think,  with some minor changes to 5.x))
      <item>
        <htmlurl url="http://www.redhat.com/support/hardware/"
        name="compatible"> hardware (also known as a PC), that includes
        network card and modem (at least one)
      <item>
3-256 IP addresses (as the machine will give out some IP addresses for modem
callers and use others for virtual hosting more than 1 is needed, the upper
number is the maximum number of IP-based virtual hosts allowed without
recompiling the stock RedHat kernel, lower is one real IP, one modem and one virtual
IP - see reference for sinlge IP virtual hosting below).
<item>
some sort of permanent network connection (using some modems for dialin while
providing the Internet access via another modem is considered <it>totally weird</it>
and not recommended)
</itemize>
<p>
Here follows the procedure:
<p>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
      <sect1>Get RH
<p>
        Purchase or otherwise procure the RedHat 7.0 (further referred as RH,
        latest version number is 7.0 at the time of updating) distribution and
        <htmlurl url="http://www.redhat.com/support/hardware/"
        name="compatible"> hardware.  One can get a full RH CDROM for about
        $3.00 including shipping and handling at <htmlurl
        url="http://www.cheapbytes.com"
name="http://www.cheapbytes.com">. This version will not contain such luxuries
as secure web server and extra software. For those you should turn to
 <htmlurl url="http://www.redhat.com" name="RedHat website">.
Or probably buying the PC with Linux RH pre-installed is  an option for some. 

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->     
      <sect1> Install RH
<p>
        Install the RH following the *instructions on the package* (might be
        added here later). CDROM install is very easy to perform. I suggest
        using text-mode setup, in my case their graphical one failed
        miserably. When asked about the installation type
        (Server/Workstation/Custom) choose Server or Custom (if you know what
        you are doing)-you can always add software later. Some other important
        installation decisions are outlined further. For RH 6.0 and 6.1 you
might be able to add packages to Workstation setup as well, but in RH 6.2 and
later (7.0) all
the server services are disabled and significant amount of tweaking is
required-so only Server or Custom is strongly recommended.
      
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
      <sect1> Some install tips
<p>
        If your hardware really is <htmlurl url="http://www.redhat.com/support/hardware/"
 name="compatible"> the installation
        process will detect and configure it correctly. Otherwise, refer to
        corresponding documentation for troubleshooting network card, modem,
        video card, etc problems
(mostly HOWTOs and mini-HOWTOs, some are in References section below).
<p>
Here are some ideas on disk space partitioning. Read 
<htmlurl url="http://linuxdoc.org/HOWTO/Multi-Disk-HOWTO.html" name="Linux Partitions HOWTO">  (a bit outdated)
to get some general hints on functions of partitions and their sizes for
different kinds of server setups. 
<p>Lest assume we are setting up a server for under one hundred users. We will
need separate /tmp, /var and /home partititons (and swap, of course).
If you hard drive is around 4 GB than roughly 300 MB is /tmp, 100MB swap, 1 GB /var (you
want ample logging) and 1GB /home.
The remaining  1.6GB will be root partition (no separate /usr). The split between
/home  and / might depend upon the amount of web pages you plan to host - the
more pages the more space goes to /home. To enhance security it is nice to put
some restricions (in /etc/fstab) to /tmp, /var and /home partitions (similar to those
described in my
<htmlurl url="http://www.chuvakin.org/kiodoc" name="Public Browser Station HOWTO ">.
        <p>
        If your network card is detected properly you will be asked for an IP
        address of your machine, gateway address and network mask and the
        address of the DNS server (might be your own machine if you plan to
        set it up this way). Have all this info handy.
Also you will be asked for a machine name and domain name.
We will use a sample domain name <bf>you.com</bf> and the machine will be
named <bf>ns</bf> (that gives us a fully qualified domain name (FQDN)
<bf>ns.you.com</bf>). You should use whatever domain you registered (see
Setting Up Your New Domain Mini-HOWTO, link in References section below)
and intend to use as your primary domain (not a virtual).
For the gateway address we will use a sample 111.222.333.111 address. Gateway
is likely the router that connects your machine (or your LAN) to the outside world.
        <p>
        Enable <bf>shadow</bf> and <bf>MD5</bf> passwords for greater security.
First of those makes the file that contains encrypted
passwords readable only to <tt>root</tt> user
and the second allows longer and harder to crack passwords.
        As it will be a standalone machine do not enable NIS/NFS.
<p>
      After installation finishes and machine reboots you will see the login
    prompt.
    Enter login and password (for the root account) and start configuring you
    new Linux station.

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
      <sect1>Some preliminary security configuration
<p>
      First (and fast), add a line:
      <tt>
      ALL:ALL
      </tt>
      to your <it>/etc/hosts.deny</it> file. That would (to some known extent)
      prevent other people from accessing your machine while you are doing the
      configuration. That will also prevent you from doing the same. For
      further configuration efforts (that can be done remotely, by the way)
      <htmlurl url="http://www.ssh.com" name="secure shell"> is
      recommended. Download the RPM package for RH from one of the many sites
      and install it (as root) using: <bf> rpm -U ssh*rpm</bf> or similar
      command (depends upon the version). You will have to get both client and
      server packages (if you want to ssh from this machines as well as to
this machine). Upon installation all necessary post-installation commands
(like server key generation)
      are run automatically by the RPM package. You will have to start server
      manually using command <bf>/etc/rc.d/init.d/sshd start</bf>.Some early
      versions of ssh1 and also all versions of ssh1 compiled with RSAREF library
      contain a buffer-overflow bug. Use ssh2 or the latest version of ssh1
      without RSAREF. If you do this you will have to allow access using ssh
      from some trusted machine (described later) in
<it>/etc/hosts.allow</it> file. RedHat 7.0 now includes OpenSSH clone that
supports both ssh1 and ssh2 protocols. Its configuration is almost the same
as ssh. It has some minor configuration advantages over ssh (for instance, no X11 forwarding
by default) and is otherwise the same. Sshd (when run as daemon) will also
refer to  <it>/etc/hosts.deny</it> and  <it>/etc/hosts.allow</it> for access control.
<p>
 If you want to be really rigorous in you configuration pursuits go to single
 use mode by giving the command <bf>init 1</bf>, in this case all work is to
 be done locally and you would not be able to test you network-related
 configuration as network is not available in this mode.
<p>To further enhance your security <bf>ipchains</bf> software (that is
usually part of your Linux distribution) can be
used (for that refer to IPCHAINS HOWTO, link in References).
It takes quite a bit more efforts to configure it than TCP wrappers,
although some automated tools are available for that too.

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <sect1>Remove unnecessary services
<p>
      Now lets deal with unnecessary services. Please note that my idea of
"unnecessary" might not be 100% same as yours. Also, telnet is now considered
by many to be not only unnecessary, but really utterly undesirable. <bf>Use ssh</bf>, and
forget telnet once and for all!
      <enum>
        <item>
          Services started from <it>/etc/inetd.conf</it> (RedHat 7.0
introduced the more advanced <it>/etc/xinetd.conf</it> which uses somewhat
different syntax, see below):<p>
          comment out all the lines, but those
          <tscreen><verb>
ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd -L -l -i -a
telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd
         </verb></tscreen>
          Check this by using the command: <bf>grep -v '\#' /etc/inetd.conf</bf>
<p>If you will be using the secure shell (ssh), telnet is also not necessary and can
be removed. Secure shell can either be started as a daemon on system startup
or as a service from <it>/etc/inetd.conf</it>. Default configuration (used by
the RPM package) is to start is as a daemon. Sshd can be compiled to refer to
<it>/etc/hosts.allow</it> file for access control. In this case, while you
will not have it in your <it>/etc/inetd.conf</it>, it will still use the
settings from <it>/etc/hosts.allow</it> and <it>/etc/hosts.deny</it>. The
advantages of this method is faster connection as the sshd will not have to
regenerate server key every time somebody connects. On the other hand, if you
start it from  <it>/etc/inetd.conf</it> it will be more isolated from the
outside world.
More lines will be added to <it>/etc/inetd.conf</it> as necessary (POP3 is one
of those).
<p>
Here goes the note for RedHat 7.0 users. Inetd daemon (while still present
in  the distribution) is now replaced with xinetd. Its configuration file
format is  as follows:
<tscreen><verb>
#
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/

defaults
{
        instances               = 60
        log_type                = SYSLOG authpriv
        log_on_success          = HOST PID
        log_on_failure          = HOST RECORD
}

includedir /etc/xinetd.d
</verb></tscreen>
where <it>/etc/xinetd.d</it> directory looks like (with probably more file in
your case):
<tscreen><verb>
-rw-r--r--    1 root     root          498 Aug 23 00:17 tftp
-rw-r--r--    1 root     root          414 Jul 21 08:43 rsh
-rw-r--r--    1 root     root          362 Jul 21 08:43 rexec
-rw-r--r--    1 root     root          361 Jul 21 08:43 rlogin
-rw-r--r--    1 root     root          347 Aug  9 05:55 wu-ftpd
</verb></tscreen>
<p>
Files in the directory configure individual services like finger, telnet or
ftp. There format is (this service, ftp, defaults to <bf>on</bf> on stock
RedHat 7.0)
<tscreen><verb>
# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
#       normal, unencrypted usernames and passwords for authentication.
service ftp
{
        socket_type             = stream
        wait                    = no
        user                    = root
        server                  = /usr/sbin/in.ftpd
        server_args             = -l -a
        log_on_success          += DURATION USERID
        log_on_failure          += USERID
        nice                    = 10
}
</verb></tscreen>
<p>
Or (this service, tftp, defaults to <bf>off</bf> on stock
RedHat 7.0)
<tscreen><verb>
# default: off
# description: The tftp server serves files using the trivial file transfer \
#       protocol.  The tftp protocol is often used to boot diskless \
#       workstations, download configuration files to network-aware printers, \
#       and to start the installation process for some operating systems.
service tftp
{
        socket_type             = dgram
        wait                    = yes
        user                    = nobody
        log_on_success          += USERID
        log_on_failure          += USERID
        server                  = /usr/sbin/in.tftpd
        server_args             = /tftpboot
        disable                 = yes
}
</verb></tscreen>
<p>
So, to disable services add "disable= yes" to the end of correspondent file or just remove the file. 
<p>
        <item>
          Services started on system startup from <it>/etc/rc.d</it> directory:<p>
          Check what services are running by using: <bf>ps ax</bf>. You will
get something similar to the <tt>sample</tt> output below:
<tscreen><verb>
    PID TTY      STAT   TIME COMMAND
    1 ?        S      0:04 init
    2 ?        SW     0:30 [kflushd]
    3 ?        SW     0:32 [kupdate]
    4 ?        SW     0:00 [kpiod]
    5 ?        SW     0:03 [kswapd]
    6 ?        SW<    0:00 [mdrecoveryd]
  296 ?        SW     0:00 [apmd]
  349 ?        S      0:00 syslogd -m 0
  360 ?        S      0:00 klogd
  376 ?        S      0:00 /usr/sbin/atd
  392 ?        S      0:00 crond
  412 ?        S      0:00 inetd
  454 ttyS0    S      0:00 gpm -t ms
  533 tty2     SW     0:00 [mingetty]
  534 tty3     SW     0:00 [mingetty]
  535 tty4     SW     0:00 [mingetty]
  536 tty5     SW     0:00 [mingetty]
  537 tty6     SW     0:00 [mingetty]
  667 tty1     SW     0:00 [mingetty]
 4540 ?        S      0:00 httpd
 5176 ?        S      0:00 httpd
 5177 ?        S      0:00 httpd
 5178 ?        S      0:00 httpd
 5179 ?        S      0:00 httpd
 5180 ?        S      0:00 httpd
 5181 ?        S      0:00 httpd
 5182 ?        S      0:00 httpd
 5183 ?        S      0:00 httpd
 7321 ?        S      0:00 /usr/sbin/sshd                 <<< only after you installed sshd to run on startup
 7323 pts/0    S      0:00 -bash
 7336 pts/0    R      0:00 ps ax
</verb></tscreen>

          Lets concentrate on processes that listen to network, such as
          lpd. Since we do not plan to use our server for printing (we sure
          might, I just don't describe it here), I suggest we remove the
          printer daemon by: <bf>rpm -e lpd </bf>. If rpm complains about any
          dependencies (like, in my case, printfilter and rhprinttool), add
          them to your <bf>rpm -e</bf> command and repeat it. Other services
          that should be removed are NFS, NIS, samba etc, if they got installed
          by mistake. Make sure you remove NFS/NIS (if you are not using
them) as bugs are often found in them. Again, these are useful things, I am just following the
          *golden rule* <bf>"remove the software you don't currently use"</bf>. And,
          with RH RPM it is really easy to add it any time in the future.
      </enum>

      Some more basic security settings can be obtained from <htmlurl
      url="http://www.enteract.com/~lspitz/linux.html" name="Armoring Linux">
      paper. As suggested there, lets make a wheel group with trusted users
(in our case, only user <tt>you</tt>will be able to do <tt>/bin/su</tt> and to
run cron jobs (together with root).
<itemize>
<item>
wheel group for sensitive commands:<p>
<enum>
<item>
<tt>vi /etc/group</tt>, add a line (if it doesn't exist):
<verb>wheel:x:10:root,you</verb> If line exists, just add <tt>you</tt> in the end
as shown.
You don't have to use vi (and somehow I understand it very well ;-)), just use your favorite editor
(for a nice reasonably user-friendly non-X editor try <tt>pico</tt>, distributed
together with mail program <tt>pine</tt>, the latter is part of most Linux distributions)
<item>
<verb>/bin/chgrp wheel /bin/su</verb> change group ownership to
<tt>wheel</tt> group on <tt>/bin/su</tt>
<item>
<verb>/bin/chmod 4750 /bin/su</verb>  change mode on <tt>/bin/su</tt>
</enum>
<item>
restrict cron:<p>
To only allow <tt> root</tt> and <tt>you</tt> to submit cron jobs create a
file called <it>/etc/cron.allow</it> that contains usernames that you want to
be able to run cron jobs. This file might look like this:
<tscreen><verb>
root
you
</verb></tscreen>
Why should one restrict cron jobs? Local exploits to elevate privileges to <tt>root</tt>
from, say, <tt>nobody</tt>, exist for some versions of cron.
</itemize>
<p>
 I suggest you do not install X Windows as it will bring new concern that
 you might not be prepared to deal with.

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <sect1>Enable multiple IP addresses 
<p>
Now we are ready to enable our machine to handle multiple IP addresses for
virtual hosting. At that point, the IP Aliasing HOWTO might come
handy (see link in References).
For several reasons, IP-based virtual hosting is better (if you have
enough IP addresses, that is). For instance, reverse lookups would succeed, if
done from the browser side. It might also be needed for hosting
cryptographically enabled websites (commonly known as "secure websites").
Older browsers (not supporting HTTP 1.1) will get unhappy too.
<p>
The changes would be concentrated in <it>/etc/rc.d/</it> directory.
To enable multiple IP addresses your kernel should support this. On a freshly
installed RH Linux it does. To verify it one should look into the config file
that was used to compile the kernel. In my case, it was
<it>/usr/src/linux/configs/kernel-2.2.17-i686.config</it> since the machine
has Pentium III processor.  This file exists, if the <tt>kernel-source</tt> RPM
package was installed. If line <tt>CONFIG_IP_ALIAS=y</tt> is present in the
file than you are OK.  While we are here, we can also confirm the ability to
forward IP packets (needed for dialup users PPP). This ability is present, but
not turned on by default (to turn it on do execute the following command
<tt>echo 1 > /proc/sys/net/ipv4/ip_forward</tt> or add a line into <it>/etc/sysctl.conf</it>). Also needed is the support for PPP protocol (line
<tt>CONFIG_PPP=m</tt>, this means PPP support is compiled as a kernel loadable
module, <tt>CONFIG_PPP=y</tt> is also OK)
<p>
The examples will use the ridiculous IP addresses
111.222.333.444-111.222.333.777 from C block 111.222.333.0. 111.222.333.444 is
a real host IP (that is configured during RH installation),
111.222.333.555-777 are virtual addresses and 111.222.333.888 is a dialin user address
(can be more of those).

<p> Lets assume we want to configure 3 virtual hosts.

Two sets of commands will be used:
<enum>
<item>
<tscreen><verb>
/sbin/ifconfig eth0:0 111.222.333.555
/sbin/ifconfig eth0:1 111.222.333.666
/sbin/ifconfig eth0:2 111.222.333.777
</verb></tscreen>
<p>
These will bind the IP addresses to (virtual) interfaces
<tt>eth0:0-eth0:2</tt>.
<p>
<item>
<tscreen><verb>
/sbin/route add -host  111.222.333.555 dev eth0
/sbin/route add -host  111.222.333.666 dev eth0
/sbin/route add -host  111.222.333.777 dev eth0
</verb></tscreen>
<p>
These commands will add routes for those addresses and connect those to real
interface <tt>eth0</tt> (ethernet card).
</enum>
After doing them the ifconfig command output (<tt>ifconfig</tt>) will look
like this:
<tscreen><verb>
eth0      Link encap:Ethernet  HWaddr 02:60:8C:4D:24:CE  
          inet addr:111.222.333.444  Bcast:255.255.255.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:901597 errors:33 dropped:0 overruns:0 frame:823
          TX packets:433589 errors:0 dropped:0 overruns:0 carrier:0
          collisions:128327 txqueuelen:100 
          Interrupt:5 Base address:0x280 

eth0:0    Link encap:Ethernet  HWaddr 02:60:8C:4D:24:CE  
          inet addr:111.222.333.555  Bcast:111.222.333.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:5 Base address:0x280 

eth0:1    Link encap:Ethernet  HWaddr 02:60:8C:4D:24:CE  
          inet addr:111.222.333.666  Bcast:111.222.333.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:5 Base address:0x280

eth0:2    Link encap:Ethernet  HWaddr 02:60:8C:4D:24:CE  
          inet addr:111.222.333.777  Bcast:111.222.333.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:5 Base address:0x280

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:3924  Metric:1
          RX packets:26232 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26232 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 

</verb></tscreen>
All commands can be added to the bottom of <it>/etc/rc.d/rc.local</it> so that
the changes are saved after reboot. Strictly speaking, rebooting machine is
not required for adding new IP addresses. Please, do document all changes
you do to your machines. Many a good sysadmin (or, should I say not-so-good?)
were burned on that at some point in their careers.
<p>
<bf>TO TEST THE CHANGES</bf><p>
<tt>Do:</tt> ping virtual addresses as
<verb>
ping 111.222.333.555
ping 111.222.333.666
ping 111.222.333.777
</verb>
<p>
<tt>Should get:</tt>
interfaces should be up
<p>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <sect1>Configure DNS
<p>
Now we are ready to configure DNS.
The easiest way would be to add the hostnames (real and all the virtual) that
we want to be seen by the world to the configuration of some machine that
already has bind (DNS daemon) running. But, since we are setting up
ISP-in-a-box we might not be able to avoid "DNS fun".
<p>
Now, let me
also try to defend the (well, questionable) choice of "outdated" version of bind 4.9.7
(last of the pre-8 series). I know that my arguments can be beaten, now that
even bind 9 is out, but
I consider bind 4.9.7 much more time-tested and stable. The arguments for
upgrading to 8.x
(provided <htmlurl url="http://www.acmebw.com/askmrdns/00444.htm" name="http://www.acmebw.com/askmrdns/00444.htm">
and 
<htmlurl url="http://www.dns.net/dnsrd/servers.html" name="http://www.dns.net/dnsrd/servers.html">
and, I guess, at many other places. Here is a
<htmlurl url="http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=651139761" name="message">
from Theo de Raadt 
himself (the head of OpenBSD development) where he justifies the choice of
bind 4 as part of OpenBSD-the most secure UNIX OS around. He also shudders at
the amount of bugs the OpenBSD auditing team saw in BIND 8 source code) 
still didn't seem to convince many people. And, lets not forget the "exploit of 1999" -
ADMROCKS, that gives remote root access to almost any Linux machine running bind prior to
8.1.2 patch 3. Judging by the INCIDENTS mailing list, this is still a very
popular way to attack RH versions 5.0-6.1 if no recommended upgrades are
installed.
It is claimed that named (whatever version) should always be run in a chroot jail.
<p>
Here are the instructions, loosely following the DNS book from O'Reilly (a good
one, highly recommended to all, but very casual DNS user).
<p>
<enum>
<item>
Find and install bind 4.9.7 either from RPM package (RH 4.2, if I am not
mistaken - for that you can use <htmlurl url="http://rpmfind.net/linux/RPM/" name="RPMFIND.net">,
personally I didn't try this and so I am somewhat skeptical
about installing RH 4.2 package on RH 6.1 system, but it might work)
or from source (<htmlurl url="ftp://ftp.isc.org/isc/bind/src/4.9.7/" name="bind 4.9.7">,
 compiling it is a bit troublesome, but reading all the README files
in the archive will definitely help).
<item>
Create files and directories needed for bind:
<itemize>
 <item>
 <it>/etc/named.boot</it>
 <item>
 <it>/etc/namedb</it>
 <item>
 <it>/etc/namedb/db.you</it>
 <item>
 <it>/etc/namedb/db.111.222.333</it>
 <item>
 <it>/etc/namedb/db.127.0.0</it>
 <item>
 <it>/etc/namedb/db.yoursite1</it>
 <item>
 <it>/etc/namedb/db.yoursite2</it>
 <item>
 <it>/etc/namedb/db.yoursite3</it>
</itemize>
This will be used for 3 virtual domains: <bf>yoursite1.com</bf>,<bf>yoursite2.com</bf> and
<bf>yoursite3.com</bf>. One more important comment refers to secondary DNS issue.
 As all your domains and all their services will be hosted on the same machine,
DNS backup in the form of secondary server doesn't make much sense:
if your primary DNS is down everything else (mail, www, ftp, pop, etc)
is down as well. But you do have to have a secondary DNS to register a domain.
Try to convince somebody to put you in as a secondary or use a free DNS service
(link is in Setting Up Your New Domain Mini-HOWTO).

<item>
<p>
That is how they look like (if you are unfamiliar with bind 4.x configuration
file format, please, do read either the O'Reilly DNS book or any
of the HOWTOs or documents at
<htmlurl url="http://www.dns.net/dnsrd/" name="bind pages">, or, better, all of the above.
You also have an option of using them without understanding, but this is a bad idea in general):
<p>
<it>/etc/named.boot</it>
<p>
This is the main config file for bind 4.9.x.
<tscreen><verb>
directory /etc/namedb

;cache-obtained from internic, usually
cache   .                               db.cache

;main config files
primary you.com                         db.you
;reverse lookups
primary 333.222.111.in-addr.arpa        db.111.222.333
;localhost.localnet configs
primary 0.0.127.in-addr.arpa            db.127.0.0

;virtual Domains
primary yoursite1.net                     db.yoursite1
primary yoursite2.net                     db.yoursite2
primary yoursite3.net                     db.yoursite3

</verb></tscreen>
<item>
<p>
<it>/etc/namedb/db.you</it>
<p>
<tscreen><verb>
; defines our local hosts at you.com, just one in our case, and its aliases
@                       IN      SOA     ns.you.com. root.ns.you.com. (
                                        2000012190 7200 1800 3600000 7200 )
;name servers and mail servers
                        IN      NS      ns.you.com.
                        IN      MX      10 ns.you.com.
                        IN      A       111.222.333.444
ns                      IN      A       111.222.333.444

;address of the canonical names
localhost               IN      A       127.0.0.1
gateway                 IN      A       111.222.333.111

;aliases (to use in ftp: ftp ftp.you.com etc, for clarity)
www                     CNAME   ns
mail                    CNAME   ns
ftp                     CNAME   ns
pop3                    CNAME   ns

</verb></tscreen>
<item>
<p>
<it>/etc/namedb/db.111.222.333</it><p>
<tscreen><verb>
;reverse mapping of our IP addresses
.
;origin is 333.222.111.in-addr.arpa
333.222.111.in-addr.arpa. IN    SOA     ns.you.com. root.ns.you.com. (
                                        1999121501 7200 1800 3600000 7200 )
;name Servers
                        IN      NS      ns.you.com.

;addresses point to canonical name
444.333.222.111.in-addr.arpa.   IN      PTR     ns.you.com.
;dialins
888                             IN      PTR     dialup.you.com.

;virtual hosts
555                             IN      PTR    yoursite1.com.
666                             IN      PTR    yoursite2.com.
777                             IN      PTR    yoursite3.com.

</verb></tscreen>
<item>
<it>/etc/namedb/db.127.0.0</it><p>
<tscreen><verb>
;local loop config file
0.0.127.in-addr.arpa.   IN      SOA     ns.you.com. root.ns.you.com. (
                                        1997072200 7200 1800 3600000 7200 )
                        IN      NS      ns.you.com.
1                       IN      PTR     localhost.
</verb></tscreen>
<item>
<it>/etc/namedb/db.yoursite1</it><p>
<tscreen><verb>
; yoursite1.com
@                       IN      SOA     virtual root.virtual (
                                        1999092201      ; Serial: update each time the file is changed
                                        7200            ; refresh, sec
                                        1800            ; retry, sec
                                        3600000         ; expire, sec
                                        7200 )          ; minimum TTL
;name servers
                        IN      NS      ns.you.com.
                        IN      MX      10 virtual
                        IN      A       111.222.333.555 
;address of the canonical names
localhost               IN      A       127.0.0.1
gateway                 IN      A       111.222.333.111
virtual                 IN      A       111.222.333.555
                        IN      MX      10 virtual
;aliases
www                     CNAME   virtual
mail                    CNAME   virtual
ftp                     CNAME   virtual
pop3                    CNAME   virtual
</verb></tscreen>
<item>
<it>/etc/namedb/db.yoursite2</it><p>
<tscreen><verb>
; yoursite2.com
@                       IN      SOA     virtual root.virtual (
                                        1999092201      ; Serial: update each time the file is changed
                                        7200            ; refresh, sec
                                        1800            ; retry, sec
                                        3600000         ; expire, sec
                                        7200 )          ; minimum TTL
;name servers
                        IN      NS      ns.you.com.
                        IN      MX      10 virtual
                        IN      A       111.222.333.666 
;address of the canonical names
localhost               IN      A       127.0.0.1
gateway                 IN      A       111.222.333.111
virtual                 IN      A       111.222.333.666
                        IN      MX      10 virtual
;aliases
www                     CNAME   virtual
mail                    CNAME   virtual
ftp                     CNAME   virtual
pop3                    CNAME   virtual
</verb></tscreen>
<item>
<it>/etc/namedb/db.yoursite3</it><p>
<tscreen><verb>
; yoursite3.com
@                       IN      SOA     virtual root.virtual (
                                        1999092201      ; Serial: update each time the file is changed
                                        7200            ; refresh, sec
                                        1800            ; retry, sec
                                        3600000         ; expire, sec
                                        7200 )          ; minimum TTL
;name servers
                        IN      NS      ns.you.com.
                        IN      MX      10 virtual
                        IN      A       111.222.333.777 
;address of the canonical names
localhost               IN      A       127.0.0.1
gateway                 IN      A       111.222.333.111
virtual                 IN      A       111.222.333.777
                        IN      MX      10 virtual
;aliases
www                     CNAME   virtual
mail                    CNAME   virtual
ftp                     CNAME   virtual
pop3                    CNAME   virtual
</verb></tscreen>
</enum>
These configuration files will allow you to host these three virtual domains
and your real domain <bf>you.com</bf>.
<p>
<bf>TO TEST THE CHANGES</bf><p>
<tt>Do:</tt> check address resolution
<verb>
nslookup www.you.com
nslookup www.yoursite1.com
nslookup www.yoursite2.com
nslookup www.yoursite3.com
</verb>
<p>
<tt>Should get:</tt>
nslookup returns the correct IP addresses for all hostnames
<p>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <sect1>Configure httpd
<p>
      To server html pages httpd daemon is used. RH 7.0 comes with Apache
1.3.12 (latest version is currently 1.3.14 and the alpha of the upcoming 2.0 is
released).
At that point it is wise to check RH site or its mirrors
(<htmlurl url="http://www.redhat.com/mirrors.html" name="RH Mirrors">) for updates. 

Most changes that we are about to make
 concentrate in  <it>/etc/httpd/httpd.conf</it> (RH standard
location for Apache configuration). Default location for html pages (shown
when you go to <bf>www.you.com</bf>) is <it>/home/httpd/html</it>. You can
allocate directories for virtual hosts within the same  <it>/home/httpd</it>,
shown below are the following locations for them:
<it>/home/httpd/yoursite1</it>, 
<it>/home/httpd/yoursite2</it> and
<it>/home/httpd/yoursite3</it>.
<p>
Below I provide the minimum necessary changes for your
<it>/etc/httpd/httpd.conf</it> file:
<p>
<tscreen><verb>
&lt;VirtualHost 111.222.333.555&gt;
ServerAdmin webmaster@you.com
DocumentRoot /home/httpd/yoursite1
ServerName www.yoursite1.com
ErrorLog yoursite1-error_log
TransferLog yoursite1-access_log
&lt/VirtualHost&gt;


&lt;VirtualHost 111.222.333.666&gt;
ServerAdmin webmaster@you.com
DocumentRoot /home/httpd/yoursite2
ServerName www.yoursite2.com
ErrorLog yoursite2-error_log
TransferLog yoursite2-access_log
&lt/VirtualHost&gt;

&lt;VirtualHost 111.222.333.777&gt;
ServerAdmin webmaster@you.com
DocumentRoot /home/httpd/yoursite3
ServerName www.yoursite3.com
ErrorLog yoursite3-error_log
TransferLog yoursite3-access_log
&lt/VirtualHost&gt;
</verb></tscreen>

That configuration will cause all logs to be stored in one directory (whatever
is specified as such) for all sites. If that is not desired the <bf>ErrorLog</bf> and
<bf>TransferLog</bf> directives can be changed to point to the proper
location separately for each virtual host. The pages for the "real"
<bf>www.you.com</bf> will be stored in default location <it>/home/httpd/html</it>.

<p>
For more information, look at <htmlurl url="http://www.apache.org"
name="http://www.apache.org">, Apache http server homepage. They have a lot of
support pages, including those for virtual hosting setup (both IP-based and
name-based [uses just 1 IP address]). Also useful is Linux WWW HOWTO (link in
References section), section on virtual hosting.
<p>
<bf>TO TEST THE CHANGES</bf><p>
<tt>Do:</tt> access the test pages via Lynx browser or telnet to port 80
<verb>
lynx http://www.you.com
lynx http://www.yoursite1.com
lynx http://www.yoursite2.com
lynx http://www.yoursite3.com
</verb>
<p>
<tt>Should get:</tt>
Test pages will be returned (if you put them in the proper directories)
<p>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <sect1>Configure sendmail
<p>
<sect2>Setup
<p>
      Now we will deal with sendmail. Again, proposed are the minimum necessary
changes to the stock RH <it>/etc/sendmail.cf</it> and  <it>/etc/sendmail.cw</it>.
<enum>
<item>
look for the lines that starts from <tt>Dj$w.foo.com</tt> and change it to
point to your main ("real", not virtual) server name (<bf>you.com</bf>, so it
will looks like this <tt>Dj$w.you.com</tt>).
<item>
locate file <it>/etc/sendmail.cw</it> and make it look like this
<tscreen><verb>
# sendmail.cw - include all aliases for your machine here.
you.com
ns.you.com
mail.you.com
yoursite1.com
mail.yoursite1.com
yoursite2.com
mail.yoursite2.com
yoursite3.com
mail.yoursite3.com
</verb></tscreen>
These are necessary so that sendmail accepts mail for these domains.
</enum>
<p>
This <bf>does not</bf> address the issue of <tt>user@yoursite1.com</tt> and
<tt>user@yoursite2.com</tt> mail getting to different mailboxes. For that
look into <tt>/etc/mail/virtusertable</tt>  functionality
 (appropriate line in <it>/etc/sendmail.cw</it> is <tt>Kvirtuser hash -o
/etc/mail/virtusertable</tt>, detailed info may be added here later).
Excellent documentation on that is on
<htmlurl url="http://www.sendmail.org/virtual"
name="http://www.sendmail.org/virtual">, sendmail reference on virtual
hosting.
<p>It is worthwhile to add that linuxconf proposes a somewhat different
scheme for virtual email with separate spool directories for all domains (that
cleanly solves the above "name-conflict" issue"), but
that requires a special virtual-aware POP/IMAP server (included with RH) and
is somewhat more complicated. It is recommended for bigger email volume sites
with many users within each domain.
<p>
A few words about sendmail, it is a good idea (good from the security
standpoint) to have sendmail run from
<it>inetd.conf</it> and not as a standalone daemon. For that we need to add it
to <it>/etc/inetd.conf</it>, remove it from <it>/etc/rc.d/init.d</it>, add the
sendmail queue processing to cron. Here is what you have to do:
<enum>
<item>
Add the following line to <it>/etc/inetd.conf</it>:
<verb>
smtp  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/sendmail -bs
</verb>
<p>
Or, if using xinetd create a file <it>sendmail</it>  in
<it>/etc/xinetd.d/</it>
similar to
<tscreen><verb>
# default: on
service sendmail
{
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/bin/sendmail -bs
}
</verb></tscreen>
<item>

Edit <it>/etc/rc.d/init.d/sendmail</it> to have <tt> exit 0 </tt> somewhere in
the very beginning (might not be the best way, be sure to document the changes
you do to these files) so that this file does nothing instead of starting sendmail

<item>

By editing your (root's) crontab (to edit do <bf>crontab -e</bf>) add a line like this

<verb>
*/20 * * * * /usr/sbin/sendmail -q
</verb>

That would process sendmail queue every 20 min (if it exists).
The described steps will simplify sendmail access control and will let you
regulate who can talk to your 25 port, not just who can send email through you.
The lines in <it>/etc/hosts.allow</it>
that let all machines from .com and .org domains send you email are as follows
<verb>
sendmail: .com .org
</verb>
Please, note, that the daemon name, not protocol name is used here (sendmail,
NOT smtp).

</enum>
<p>
That would allow your system to handle email for all those domains.
<p>
<sect2>Troubleshooting
<p>
<bf>PROBLEM:</bf> mail that you are trying to send is denied with a message
<tt>Relaying denied</tt><p>
<bf>SOLUTION:</bf>Look into your <it>/etc/sendmail.cw</it>. Are you sure all
possible variations of your hostname and of your virtual hostnames are here?
Look in the message headers and see from what machine it was rejected from: does it
look like another name of yours that you missed?
<p>
<bf>TO TEST THE CHANGES</bf><p>
<tt>Do:</tt> access the SMTP port 25 via telnet
<verb>
telnet www.you.com 25
telnet www.yoursite1.com 25
telnet www.yoursite2.com 25
telnet www.yoursite3.com 25
</verb>
<p>
<tt>Should get:</tt>
Sendmail should respond with prompt and version number! Type QUIT to get out
of the prompt.
<p>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect1>Configure POP3
<p>
<sect2>Setup
<p>
POP3 configuration is easy (no "virtualization" is required for this setup). RH comes
equipped with imapd IMAP server. If you do not want to use IMAP functionality
or do not like this particular implementation (buffer overflow bugs were discovered in it at
some point) the good idea is to use
<tt>qpopper</tt>, free POP3 daemon from Eudora
<htmlurl url="http://www.eudora.com/freeware/qpop.html"
name="http://www.eudora.com/freeware/qpop.html">. At the time of writing the
released version is qpopper 3.0.2.
It is important to note that versions earlier than 2.5 contain a
buffer overflow error that allows remote root exploit to be executed. Same
problem plagues "public betas" up to 3.0 release 21. Use either 2.53 or the
latest 3.0 (the former is better audited and the latter is better suited
for RH - seamlessly works with PAM authentication). I suggest using 3.0, so
the instructions below apply to that case. As of April 13, Qpopper 3.0 is no
longer beta, but a regular software. As of recently, the bug was discovered
even in Qpopper 2.53 that allows the attacker  to
obtain a shell with group-id 'mail', potentially allowing read/write
access to all mail. 

<p>
<enum>
<item>
<tt>wget ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper3.0.tar.Z</tt>
<p>Retrieve the archive from Eudora site.
<item>
<tt>tar zxvf qpopper3.0.tar.Z</tt>
<p>Uncompress and untar the contents.
<item>
<tt>cd qpopper</tt>
<p>If you need explanation for this step, please, discontinue reading the document.
<item>
<tt>./configure --enable-specialauth --with-pam --enable-log-login --enable-shy</tt>
<p>The options here are:
<p><tt>--enable-specialauth</tt> : allows MD5 and shadow passwords
<p><tt>--with-pam</tt>: allows the use of RH Pluggable Authentication Modules (PAM) technology
<p><tt>--enable-log-login</tt>: log successful logins, not only failures (not really that
useful as it will use tcpd wrappers logging anyway)
<p><tt>--enable-shy</tt>: conceal version number (yeah, a little pesky
manifestation of "security through obscurity")
<item>
<tt>make</tt>
<p>That compiles the popper
<item>
<verb>
/bin/cp popper/popper /usr/local/bin
</verb>
<p>Copies the binary to <it>/usr/local/bin</it>
<item>
Now set the mode to
<verb>
-rwx------   1 root     root       297008 Feb 16 15:41 /usr/local/bin/popper
</verb>
by using the command:
<verb>
chmod 700 /usr/local/bin/popper
</verb>
<item>
Add a line to <it>/etc/inetd.conf</it>
<verb>
pop3  stream tcp        nowait root /usr/sbin/tcpd /usr/local/bin/popper -s
</verb>
That would cause the tcpd wrapper to control access to popper.

 The lines to add in <it>/etc/hosts.allow</it> are
<verb>
popper: .good.com .nice.org
</verb>
That will allow people from domains <tt>good.com</tt> and <tt>nice.org</tt>
to read email via POP3 client from your machine.
<p>
To cause qpopper to use PAM authentication one must create a file for POP3
service in <tt>/etc/pam.d/</tt> directory. File should be named "pop3" (same as line in
<tt>/etc/services</tt> and qpopper compile-time option). The file looks like
this:

<tscreen><verb>
auth       required     /lib/security/pam_pwdb.so shadow 
account    required     /lib/security/pam_pwdb.so
password   required     /lib/security/pam_cracklib.so
password   required     /lib/security/pam_pwdb.so nullok use_authtok md5 shadow
session    required     /lib/security/pam_pwdb.so
</verb></tscreen>

<item>
For whatever reason stock RH lists line in <it>/etc/services</it>
file for POP3 protocol as "pop-3". And since qpopper prefers to see "pop3",
it should be edited to be:
<verb>
pop3		110/tcp		# pop3 service
</verb>
</enum>
That would allow all user to get their email via any reasonable mail client.
<p>
<sect2>Troubleshooting
<p>
<bf>PROBLEM:</bf> you are connecting to your POP server with valid password
and username and they are rejected with a message <tt>Password incorrect</tt>.
<p>
<bf>SOLUTION:</bf> PAM doesn't like your setup. This message is common for
qpopper 2.53, use 3.0 and it should disappear. Otherwise, look into
<tt>/etc/pam.d/pop3</tt> that you created. Is it OK?
<p>
<bf>TO TEST THE CHANGES</bf><p>
<tt>Do:</tt> access the POP3 port 110 via telnet
<verb>
telnet www.you.com 110
</verb>
<p>
<tt>Should get:</tt>
Qpopper should respond with prompt and version number! Type QUIT to get out
of the prompt.
<p>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<sect1>Configure FTP server
<p>
<sect2>Anonymous FTP setup
<p>
We will use only anonymous ftp and will not allow any non-anonymous user any
access.  Here we describe the anonymous ftp server setup that allows anonymous
uploads.  Any self-respecting guide on the subject will tell you that "this is
a bad thing". But how is it worse than allowing users to ftp from untrusted
location and transfer their passwords in clear text? Not everybody
(especially, using Windows) can easily setup an ftp tunnel via ssh. But you
definitely should restrict access via tcp wrappers and watch for "warez
puppies" (people who will try to exchange stolen software via your ftp site if
you allow unlimited downloads!).
<p>
I suggest using the stock RH wu-ftpd (version 2.6.1 at the time of
writing). While it is rumored that there are "more secure" ftp daemons
(Pro-ftpd), wu-ftp appears to be one most commonly used. Recently a series of
bugs was again discovered in wu-ftp (even in 2.6.x versions)  and its reputation as the most popular ftp
daemon seem to be dwindling. CERT has issued an advisory concerning WU-FTPD and all ftp daemons derived
from BSD's final release.
<p>
RH installs the wu-ftpd (package wu-ftpd-2.6.1-1) by default in server
configuration. You are encouraged to check for updates as running ftp is an important
security concern. There is also a separate rpm package that creates a separate
directory structure for anonymous ftp home (anonftp-2.8-1).
As anonymous ftp always does a <tt>chroot()</tt>
system call (puts the user in the restricted file system) all necessary
binaries and libraries are required. The typical directory looks like this
(output of <bf>ls -lRa</bf> in <it>/home/ftp</it>):

<tscreen><verb>
.:
total 20
d--x--x--x   2 root     root         4096 Feb 15 06:22 bin
d--x--x--x   2 root     root         4096 Feb 15 06:22 etc
drwxrws-wt   2 root     wheel        4096 Feb 18 19:51 incoming
drwxr-xr-x   2 root     root         4096 Feb 15 06:22 lib
drwxr-sr-x   3 root     ftp          4096 Feb 15 23:34 pub

bin:
total 344
---x--x--x   1 root     root        15204 Mar 21  1999 compress
---x--x--x   1 root     root        52388 Mar 21  1999 cpio
---x--x--x   1 root     root        50384 Mar 21  1999 gzip
---x--x--x   1 root     root        29308 Mar 21  1999 ls
----------   1 root     root        62660 Mar 21  1999 sh
---x--x--x   1 root     root       110668 Mar 21  1999 tar
lrwxrwxrwx   1 root     root            4 Feb 15 06:22 zcat -> gzip

etc:
total 40
-r--r--r--   1 root     root           53 Mar 21  1999 group
-rw-r--r--   1 root     root        31940 Mar 21  1999 ld.so.cache
-r--r--r--   1 root     root           79 Mar 21  1999 passwd

incoming:
total 0

lib:
total 1212
-rwxr-xr-x   1 root     root        77968 Mar 21  1999 ld-2.1.1.so
lrwxrwxrwx   1 root     root           11 Feb 15 06:22 ld-linux.so.2 -> ld-2.1.1.so
-rwxr-xr-x   1 root     root      1031004 Mar 21  1999 libc-2.1.1.so
lrwxrwxrwx   1 root     root           13 Feb 15 06:22 libc.so.6 -> libc-2.1.1.so
-rwxr-xr-x   1 root     root        77196 Mar 21  1999 libnsl-2.1.1.so
lrwxrwxrwx   1 root     root           15 Feb 15 06:22 libnsl.so.1 -> libnsl-2.1.1.so
-rwxr-xr-x   1 root     root        33596 Mar 21  1999 libnss_files-2.1.1.so
lrwxrwxrwx   1 root     root           21 Feb 15 06:22 libnss_files.so.2 -> libnss_fi
les-2.1.1.so

pub:
total 0

</verb></tscreen>
<p>
Notice though, that for whatever reason, RH puts a copy of <it>/bin/sh</it> in
<it>/home/ftp/bin</it>.
I do not feel good about having it there, so it is chmoded to 0 by
<bf>chmod 0 sh</bf> (can also be removed completely, but RPM might be slightly
unhappy if you attempt to remove the package afterwards).
<p>
Permissions on <it>/home/ftp</it> directories and files should be carefully
considered. In the above example, all of the system files are owned by root
and are only readable (executable where necessary) by all. Files in
<it>bin</it> are only executable (as is the directory itself to prevent
listing of its contents).
<p>The interesting part is permissions on <it>pub</it> and <it>incoming</it>.

<p>
Below follows the configuration file for ftp daemon
(<it>/etc/ftpaccess</it>). It is well commented to the degree of being self-explanatory:
<tscreen><verb>
#ideas from <htmlurl url="ftp://ftp.wu-ftpd.org/pub/wu-ftpd/upload.configuration.HOWTO" name="ftp://ftp.wu-ftpd.org/pub/wu-ftpd/upload.configuration.HOWTO"> 
#only allow anonymous users-no other classes defined
class anonftp anonymous *

#number of users restriction with message shown when too many
limit   remote  10  Any                 /toomany.msg

#prevent uploads everywhere (for now)
upload /home/ftp * no

#display the contents of some files upon login/cd
readme  README*    login
readme  README*    cwd=*
message /welcome.msg            login
message .message                cwd=*

#log all file transfers DISABLED
#log transfers anonymous

#prevent these file operations for anon users
delete          no      anonymous
overwrite       no      anonymous

#fast cd and aliasing for the same reason (not really necessary, but convenient)
alias   inc:    /incoming
cdpath  /incoming
cdpath  /pub
cdpath  /

#what is allowed in paths
path-filter  anonymous  /etc/pathmsg  ^[-A-Za-z0-9_\.]*$  ^\.  ^-

#prevent the retrieval of some file
noretrieve .notar

#allow upload with NO subdirectory creation by anon users
upload    /home/ftp    /incoming   yes root wheel 0400 nodirs

#allow upload with subdirectory creation by anon users DISABLED
#upload    /home/ftp    /incoming   yes root wheel 0400 dirs

#prevent anon users to GET files from incoming (you might not like it, but it
#is a good idea-to prevent some people from using your ftp server to store
#their own stuff, pics, warez etc)
noretrieve /home/ftp/incoming

</verb></tscreen>
That would allow only anonymous users to do downloads and uploads in somewhat (<bf>!</bf>)
controlled manner. Make sure you update the permissions on files that you
changed  after you upgrade the RPM packages next time.
<p>
<sect2>Guest FTP setup
<p>
Guest FTP users are those that have valid usernames and passwords (unlike
anonymous), but do not have access to the whole directory structure (unlike
real ones). So they are chrooted after authentication. Guest users can do
uploads in this configuration.
<p>
Easy <bf>21-step</bf> directions for that are provided below ;-)
<p>
Software used: <tt>wu-ftpd-2.6.1</tt><p>
Sample username will be created: <bf>ftpguy</bf>, user ID=505.<p>
Her group will be: <bf>lusers</bf>, group ID=701.<p>
If you want more users of the same sort, they should be the members of the
same group. For that it might be good to change the directory structure
somewhat so that all of them use the same <it>passwd</it> file and the same
static <tt>ls</tt>. But, for better separation you can give each of them their
own files.
<p>
<enum>
<item>
<tt>adduser ftpguy</tt>
<p>creates an entry in <it>/etc/passwd</it>
<item>
<tt>passwd ftpguy</tt>
change password to whatever
<item>Edit file <it>/etc/passwd</it>, last line (that contains our new user)
should look like this
<verb>
ftpguy:x:505:701::/home/ftpguy/./:/etc/ftponly
</verb>
yes, that is "slash"-"dot"-"slash" after his home directory.
<item>Edit file <it>/etc/shells</it>, add line, below
<verb>/etc/ftponly</verb>
This file has to exist in some newer Linux distributions (contrary to what is
claimed at 
<htmlurl url="ftp://ftp.fni.com/pub/wu-ftpd/guest-howto" name="Guest FTP HOWTO">). 
Sometimes one can put <it>/bin/true</it> in its place.
<item>Edit file  <it>/etc/group</it>, add line, below
<verb>
lusers:x:701:ftpguy
</verb>
<item>
<tt>cd /home</tt>
<item>
<verb>chown ftpguy.lusers ftpguy</verb>
this directory is created by adduser command
<item>
<verb>cd ftpguy; mkdir etc bin ; chown root.daemon etc bin</verb>
this creates a directory tree for chroot
<item>
<verb>chmod 111 etc bin</verb>
this sets <bf>very</bf> conservative permissions on directories within the
chrooted tree
<item>
<verb>cp ~/static_ls /home/ftpguy/bin/ls</verb>
obtaining static (not calling any libraries) version of <it>/bin/ls</it>:
this directory
(<htmlurl url="http://www.stanford.edu/group/itss-ccs/security/binaries/linux/redhat/" name="http://www.stanford.edu/group/itss-ccs/security/binaries/linux/redhat/">)
contains static version of many RH 6.x/7.x-compatible utilities, including ls
(local copy is
<htmlurl url="http://www.chuvakin.org/ispdoc/ls.gz"
name="http://www.chuvakin.org/ispdoc/ls.gz"> here, <tt>gunzip ls.gz</tt> to run)
<item>
<verb>cd bin ; chown root.bin ls</verb>
<item>
<verb>chmod 111 ls</verb>
this sets <bf>very</bf> conservative permissions on binaries within chroot
<item>
<verb>cd ../etc</verb>
<item>
Create file <it>/home/ftpguy/etc/passwd</it> as follows
<tscreen><verb>
root:*:0:0::/:/etc/ftponly
ftpguy:*:505:701::/home/ftpguy/./:/etc/ftponly
</verb></tscreen>
<item>
Create file <it>/home/ftpguy/etc/group</it>, contents follow
<tscreen><verb>
root::0:root
lusers::701:ftpguy
</verb></tscreen>
<item>
<verb>chown root.daemon passwd group</verb>
this sets proper ownership of these files
<item>
<verb>chmod 444 passwd group</verb>
this sets minimum necessary permission on that file
<item>
<verb>cd ~ftpguy; touch .forward</verb>
this creates <it>.forward</it> file 
<item>
<verb>chown root.root .forward ; chmod 400 .forward</verb>
and locks it for security reasons
<item>
<verb>cd /etc</verb>
<item>
Add the facilities for handling guest users into <it>/etc/ftpaccess</it>
<tscreen><verb>
#=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-           
class anonftp guest,anonymous *                                                 
                                                                                
delete     no   anonymous,guest               # delete permission?              
overwrite  no   anonymous,guest               # overwrite permission?           
rename     no   anonymous,guest               # rename permission?              
chmod      no   anonymous,guest               # chmod permission?               
umask      no   anonymous,guest               # umask permission?               
                                                                                
guestgroup lusers                                                               
                                                                                
limit   remote  10  Any                 /toomany.msg                            
upload /home/ftp * no                                                           
readme  README*    login                                                        
readme  README*    cwd=*                                                        
message /welcome.msg            login                                           
message .message                cwd=*                                           
                                                                                
alias   inc:    /incoming                                                       
cdpath  /incoming                                                               
cdpath  /pub                                                                    
cdpath  /                                                                       
                                                                                
path-filter  anonymous  /etc/pathmsg  ^[-A-Za-z0-9_\.]*$  ^\.  ^-               
noretrieve .notar                                                               
upload    /home/ftp    /incoming   yes root wheel 0400 nodirs                   
noretrieve /home/ftp/incoming
</verb></tscreen>
</enum>
<p>
Lets test this beast:

<tscreen><verb>
localhost[anton]#1008: ftp localhost
Connected to anton.
220 anton FTP server (Version wu-2.6.1(1) Mon Feb 28 10:30:36 EST 2000) ready.
Name (localhost:anton): ftpguy
331 Password required for ftpguy.
Password:
230 User ftpguy logged in.  Access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls -la
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 4
drwx------   4 505      701          1024 Apr  8 02:16 .
drwx------   4 505      701          1024 Apr  8 02:16 ..
-r--------   1 0        0               0 Apr  8 02:16 .forward
d--x--x--x   2 0        2            1024 Apr  8 02:09 bin
d--x--x--x   2 0        2            1024 Apr  8 02:15 etc
226 Transfer complete.
ftp> mkdir TEST
257 "/TEST" new directory created.
ftp> ls -l
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 3
-r--------   1 0        0               0 Apr  8 02:16 .forward
drwxr-xr-x   2 505      701          1024 Apr  8 02:32 TEST
d--x--x--x   2 0        2            1024 Apr  8 02:09 bin
d--x--x--x   2 0        2            1024 Apr  8 02:15 etc
226 Transfer complete.
ftp> 
</verb></tscreen>

and so on.
<p>
<bf>TO TEST THE CHANGES</bf><p>
<tt>Do:</tt> access the ftp server using ftp client
<verb>
ftp www.you.com
</verb>
<p>
<tt>Should get:</tt>
ftp daemon should respond with prompt and version number!
<p>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <sect1>Configure dialin
<p>
Now the fun part starts. We want the machine to allow dial-in access via
attached (inserted?) modem or modems. It will provide either regular shell or
restricted shell (that only executes pppd daemon). Windows 95/98 users should be
able to effortlessly dial in using all default settings of their computers.

<sect2>Linux setup
<p>
To handle login via serial line some version of <tt>getty</tt> program is
needed. This program  monitors the serial line (<it>/dev/ttyS1</it> will be used
throughout the document, see serial HOWTO for details) and upon connection
shown the login prompt or starts a program.
<p>
I suggest using the mgetty program (as it has more features and is easier to
setup than some of the competitors).
<p>RH comes with <tt>mgetty-1.1.21-2</tt>, that also has extensions to receive
faxes and voice mail (if the modem supports this). Check whether mgetty is
installed by doing: <bf>rpm -qa | grep mgetty</bf>.

After installing mgetty some reconfiguration is necessary.
The files that should be changed and the details follow:

<enum>
<item>
<it>/etc/inittab</it><p>
That enables mgetty to start when system is booted and be respawned accordingly.
These lines should be added in the end.

<tscreen><verb>
#for dialins use mgetty
#note this S1 in the beginning of the line and ttyS1 in the end
S1:2345:respawn:/sbin/mgetty ttyS1
</verb></tscreen>

<item>
<it>/etc/ppp/options</it><p>
This file controls the pppd daemon whenever it is started.
Some of the options here are optional (hey, that why they are called options, right?).

<tscreen><verb>
auth -chap +pap login modem crtscts debug proxyarp lock
ms-dns 111.222.333.444
</verb></tscreen>

Here is their brief meaning:

<itemize>
<item>
<bf>auth </bf>: use some sort of authentication for dialin clients
<item>
<bf>-chap</bf>: not CHAP
<item>
<bf> +pap</bf>: use PAP
<item>
<bf> login </bf>: use the  system  password file for authenticating the client
using PAP and record the user in the system wtmp  file, <it>/etc/ppp/pap-secrets</it> should
still be present (see below)
<item>
<bf>modem </bf>: use the modem control lines (for carrier detection and other stuff)
<item>
<bf> crtscts </bf>: use hardware flow control
<item>
<bf>debug </bf>: log extra info (might be removed after everything is fine)
<item>
<bf> proxyarp </bf>: this is needed to connect from the client to the
Internet, not just to the LAN you dialed into 
<item>
<bf>lock</bf>: pppd should create a lock  file  for the serial device
<item>
<bf>ms-dns 111.222.333.444</bf>: this info is provided to Windows box as a default
DNS server
</itemize>
Look at pppd man page for all the juicy details (parts of the above info is
adapted from there)
<p>Another note is appropriate here. Some people reported that they had more
success with <bf>+chap -pap</bf> in authenticating both Windows and Linux
dial-up clients. If you are having problems, try changing
<tt>/etc/ppp/options</tt> to have <bf>+chap -pap</bf>. In this case the new
file  <it>/etc/ppp/chap-secrets</it> should be created (same contents as
recommended <it>/etc/ppp/pap-secrets</it>).
<p>Some other people reported that
having default line from <it>/etc/mgetty+sendfax/login.config</it> works
fine. I am very happy to hear that, and I never claimed that my way to set
things up is the only true way.
<item>
<it>/etc/ppp/options.ttyS1</it><p>
This file serves purpose similar to the previous one, but only applies to
particular modem line. It specifies the IP address given to the remote machine
(dynamic, in some sense, if you have more than one line) and the local IP as well.

<tscreen><verb>
111.222.333.444:111.222.333.888
</verb></tscreen>

<item>
<it>/etc/mgetty+sendfax/login.config</it><p>

This file is the main mgetty control file. Mgetty is Windows-PPP-aware, so it
has provisions to start pppd automatically upon receiving connect from the Windows machine.

These lines should be present:

<tscreen><verb>
/AutoPPP/ -     -       /usr/sbin/pppd
</verb></tscreen>

Before adding them, check that some other version of similar command is absent
there (commented out by default).

<item>
<it>/etc/ppp/pap-secrets</it><p>
This is similar to <it>/etc/password</it> file, but only used for dialins and
contains <bf>plain text passwords</bf> (apparently, only visible to root). All users
that you want to be able to dialin must have their usernames and password
listed in this file. They should enter the same username and password into
Windows Dial Up Networking configuration.

<tscreen><verb>
# Secrets for authentication using PAP
# these two users below can use dialin
# client        server  secret pword   remote IP addresses
dialinuser1     *       b1ab1a!?         111.222.333.888
dialinuser2     *       p8sSw0rD         111.222.333.888
</verb></tscreen>
</enum>

<p>

Check that mgetty is running by looking for similar line in the output of
<tt>ps ax</tt> command.

<tscreen><verb>
 4625 ?        S      0:00 /sbin/mgetty ttyS1
</verb></tscreen>

Now this machine will allow modem calls from any Windows 95/98 box.
<p>
As was noted by one of the readers some steps are to be taken to prevent users
from sharing their dialin password with others. A simple perl/shell script
will do the job by killing and logging connections that use the same
username.
<p>Also, if it is desirable to prevent users from using dialing in their
usernames should not be put into <it>/etc/ppp/pap-secrets </it>.
<sect2>Windows setup
<p>
This is <bf>really</bf> straightforward.
<enum>
<item>
Click on <bf>My Computer</bf>
<item>
Click on <bf>Dial Up networking</bf>
<item>
Click on <bf>Make New Connection</bf>
<item>
Proceed according to directions, enter the phone number etc
<item>
After a new connection is created click on it and enter the username and
password (same as mentioned in <it>/etc/passwd</it> and
<it>/etc/ppp/pap-secrets</it>)
<item>
Click <bf>Connect</bf> and it should work (it did in my case ;-) )
</enum>
<p>
<p>
<bf>TO TEST THE CHANGES</bf><p>
<tt>Do:</tt> try to dial in using terminal program (UNIX:minicom
/Windows:terminal or other)
<p>
<tt>Should get:</tt>
Mgetty should respond with prompt and you Linux distribution version!
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <sect1>Open access
<p>

Now, after testing all the services, we are ready to open the access to this
machine. The main access control facility in our case is TCP wrappers
(tcpd). In case of RH 7 the xinetd will check the same access control files
itself without any need to wrap services with /usr/sbin/tcpd.
These facilities are controlled by 2 files <it>/etc/hosts.allow</it> and
<it>/etc/hosts.deny</it>, as was mentioned in the sections devoted to various
network services. TCP wrappers configuration can be done in 2 distinct
ways and we will employ the simplest.
<p>Let our <it>/etc/hosts.deny</it> contain <tt>ALL:ALL</tt> clause, thus
denying the access to all services (started from <it>/etc/inetd.conf</it> ) for
all hosts and all users on them. Now we can allow what we need explicitly in
<it>/etc/hosts.allow</it>, thus following the philosophy <bf>"what is not
expressly allowed is denied"</bf>.
<p>Lets assume we want to allow people to read and send email, we want some
trusted hosts to update contents of the web pages and we want admin
workstation to have full access. So we arrive at the following
<it>/etc/hosts.allow</it>:
<tscreen><verb>
#
# hosts.allow   This file describes the names of the hosts which are
#               allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
ALL: 127.0.0.1 adminbox.some.net
#we rely on anti-relaying features of sendmail 8.9+ to fight spam
#and also restrict some sites that we don't want to see email from
sendmail: ALL EXCEPT .kr .cn
popper: .com .edu .gov .mil
#these people can upload/download stuff, make it restrictive to avoid warez!
in.ftpd: .this.net .that.net
</verb></tscreen>

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <sect>
      Conclusion
<p>
There must be the conclusion, right?

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
 <sect>
      References
<p>
Useful LDP HOWTOs (well, actually, all others are useful too)
<enum>
<htmlurl url="http://www.linuxdoc.org/HOWTO/mini/Domain.html" name="Setting Up Your New Domain Mini-HOWTO.">, really good guide of DNS setup and general network setup (recommended reading)
<item>
<htmlurl url="http://www.linuxdoc.org/HOWTO/WWW-HOWTO.html" name="Linux WWW HOWTO">, provides more details on Apache setup, including virtual hosting
<item>
<htmlurl url="http://www.linuxdoc.org/HOWTO/mini/Home-Network-mini-HOWTO.html" name="Red Hat Linux 6.X as an Internet Gateway for a Home Network">, some hints on network setup
<item>
<htmlurl url="http://www.linuxdoc.org/HOWTO/mini/IP-Alias.html" name="IP Aliasing On A Linux Machine">, used for multiple IP on the same interface
<item>
<htmlurl url="http://www.linuxdoc.org/HOWTO/Ethernet-HOWTO.html" name="Ethernet HOWTO">, look here in case of network card trouble
<item>
<htmlurl url="http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html" name="IPCHAINS HOWTO">, turn to this if more security is desired
<item>
<htmlurl url="http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html" name="Serial HOWTO">, serial ports, lines, modems and related stuff
<item>
<htmlurl url="http://www.linuxdoc.org/HOWTO/PPP-HOWTO.html" name="PPP HOWTO">,some notes on PPP server setup
</enum>
<p>
Software (used or mentioned) websites
<p>
<enum>
<htmlurl url="http://www.eudora.com/qpopper/" name="Eudora POP3 server">
<item>
<htmlurl url="http://www.wu-ftpd.org/" name="WU-FPTD ftp server">
<item>
<htmlurl url="http://www.sendmail.org" name="Sendmail MTA">
<item>
<htmlurl url="http://alpha.greenie.net/mgetty/" name="Mgetty pages">
<item>
<htmlurl url="http://www.apache.org/httpd.html" name="Apache httpd server">
</enum>
<p>
Other documents
<enum>
<item>
<htmlurl url="http://www.enteract.com/~lspitz/linux.html" name="Armoring Linux">
<item>
<htmlurl url="http://www.linuxgazette.com/issue36/ali.html" name="Setting Up
POP/PPP server">
<item>
<htmlurl url="http://www.buoy.com/isp/mgetty.html" name="Mgetty and Windows
dialin info">
<item>
<htmlurl url="http://www.best.com/~aturner/RedHat-FAQ/DOCS/tips4.html"
name="Using RedHat 5.1 to Start an ISP">, the short article on how to start an
ISP if all you have is a Linux RH ;-)
<item>
<htmlurl url="ftp://ftp.fni.com/pub/wu-ftpd/guest-howto" name="Guest FTP
server setup">
<item>
<htmlurl url="http://www.swcp.com/~jgentry/pers.html" name="Linux Dialin
Server Setup Guide"> Yet Another Guide about that
<item>
<htmlurl url="http://www.prongs.org/virtfs" name="virtfs"> a nice automatic
tool for configuring virtual services based on Perl script
<item>
<htmlurl url="http://www.linuxisp.com/Linux-ISP.HOWTO"
name="Linux Public Access HOWTO">an old and not updated for 5 years document
describing Linux-based ISP, some nice hints on equipment (serial boards) and performance
<item>
<htmlurl url="http://www.globalserve.net/~vertigo/virtual.html" name="Sinlge
IP virtual hosting">, nice doc describing how to host everything on a single IP.
</enum>
<p>
Resources, not related to the topic of the document ;-)
<p>
<enum>
<item>
I also maintain a list of computer/network security related books with
(where available) reviews and online availability. It is posted at
<htmlurl url="http://www.chuvakin.org/books" name="http://www.chuvakin.org/books">.
If you have a book that I don't list please use the form on the page and I will add it to the list and maybe review
it later.
<item>
<htmlurl url="http://www.chuvakin.org/kiodoc" name="Public Browser Station
HOWTO">, my mini-HOWTO on web-access terminal based on RedHat Linux
<item>
<htmlurl url="http://www2.linuxjournal.com/articles/culture/0018.html"
name="Access the Web Anywhere">, my article in Linux Journal about Internet Kiosks
</enum>
<p>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
</article>
