From 5fea29df559dc956035fb97fec3229efac8300f9 Mon Sep 17 00:00:00 2001 From: gferg <> Date: Wed, 10 Jan 2001 21:41:32 +0000 Subject: [PATCH] new; change filename --- .../linuxdoc/ISP-Setup-RedHat-HOWTO.sgml | 1895 +++++++++++++++++ 1 file changed, 1895 insertions(+) create mode 100644 LDP/howto/linuxdoc/ISP-Setup-RedHat-HOWTO.sgml diff --git a/LDP/howto/linuxdoc/ISP-Setup-RedHat-HOWTO.sgml b/LDP/howto/linuxdoc/ISP-Setup-RedHat-HOWTO.sgml new file mode 100644 index 00000000..f4ad364f --- /dev/null +++ b/LDP/howto/linuxdoc/ISP-Setup-RedHat-HOWTO.sgml @@ -0,0 +1,1895 @@ + + +
+ +"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> +<VirtualHost 111.222.333.555> +ServerAdmin webmaster@you.com +DocumentRoot /home/httpd/yoursite1 +ServerName www.yoursite1.com +ErrorLog yoursite1-error_log +TransferLog yoursite1-access_log +</VirtualHost> + + +<VirtualHost 111.222.333.666> +ServerAdmin webmaster@you.com +DocumentRoot /home/httpd/yoursite2 +ServerName www.yoursite2.com +ErrorLog yoursite2-error_log +TransferLog yoursite2-access_log +</VirtualHost> + +<VirtualHost 111.222.333.777> +ServerAdmin webmaster@you.com +DocumentRoot /home/httpd/yoursite3 +ServerName www.yoursite3.com +ErrorLog yoursite3-error_log +TransferLog yoursite3-access_log +</VirtualHost> +</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>