المساعد الشخصي الرقمي

مشاهدة النسخة كاملة : How to Set Up a Linux Internet Server



bahattab
09-04-2010, 02:36 PM
Tutorial: Set Up a Linux Internet Server Part 1

http://www.atyafonline.com/vb/imgcache/5810.imgcache
By Paul Dunne

See that old 25MHz, 386-based PC? Yes, that's right, the one gathering dust over in the corner of the office. It can't run Windows 95, but it still boots -- surely it's not quite ripe for use as that proverbial boat anchor? In this series of articles, I will show how such a modest box can do sterling work on your network -- providing Internet access, file and print services, and even firewall protection -- simply by add ing Linux. So to start with, lets get Linux up and running and connected to the Net. It will be presumed throughout that our attempt is very much a budget one: a simple dialup account to the nearest ISP, a no-name modem, and so forth.





Introduction (http://www.networkcomputing.com/unixworld/tutorial/013/013.part1.html#01)
Installation (http://www.networkcomputing.com/unixworld/tutorial/013/013.part1.html#02)
Configuration (http://www.networkcomputing.com/unixworld/tutorial/013/013.part1.html#03)
Basic Network Configuration (http://www.networkcomputing.com/unixworld/tutorial/013/013.part1.html#04)
Internet Connection (http://www.networkcomputing.com/unixworld/tutorial/013/013.part1.html#05)
Conclusion (http://www.networkcomputing.com/unixworld/tutorial/013/013.part1.html#06)



Questions regarding this article should be directed to the author at paul@tiny1.demon.co.uk
Other installments of this Linux Internet server tutorial series include:


Set Up a Firewall (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html)
Set Up a Mail Hub (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html)
Providing Internet Services (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html)





Introduction

A previous article (http://www.networkcomputing.com/unixworld/tutorial/004.html) in UnixWorld Online has already covered Linux background issues, and contain s plenty of useful resources. If you're not sure quite what Linux is, it might be helpful to take a look there first.




Installation

Installing Linux is straightforward nowadays -- just pick a distribution and run the install program. Before we go anywhere, though, we must check that we CAN install Linux.


Hardware requirements

Linux is modest in its hardware requirements when compared to those of most other modern OSes. Any Intel 386 or later CPU will do. In a pinch we can get by with 40 megabytes or so of hard disk space. Though it will run in only two megabytes of memory, the minimum practical RAM required is four megabytes. Even that can be a tight squeeze for some distribution's installation programs, including Slackware's, so eight megabytes is the practical base line. Linux supports a very wide range of PC hardware, so most PCs will work without further ado. To find out if a particular piece of hardware is supported, see the Linux Hardware HOWTO (http://sunsite.unc.edu/LDP/HOWTO/Hardware-HOWTO.html).
Installation can be via floppy diskettes, from a CDROM, or by NFS over the local network or the Internet.



My choice of Linux distribution (Slackware) explained

In this article, I will be using the Slackware distribution for my examples. Why Slackware? It was for long the ``standard'' distribution. It remains the easiest to adjust to one's needs, as long as one is not afraid to ``get one's hands dirty,'' so to speak. It is also in my experience the quickest to install.


Slackware installation routine

The Slackware setup program is simple and takes the user through all the stages of installation and even does some basic configuration. Rather than simply describe what the install program does, step by step, which would be superfluous, I will concentrate on explaining what is going on ``behind the scenes.''





However, first let's back up a step and make boot and root diskettes. You will most probably be doing this from DOS, with the rawrite.exe program provided on the CD. The diskettes must be formatted first in DOS; then rawrite.exe is run to write the boot and root images.





Secondly, reboot the computer with the boot diskette in the ``A:'' drive. If all goes well, Slackware will present you with a prompt to enter additional parameters. Usually, you can just ignore this and continue by pressing Enter. Sometimes, however, you may need to pass parameters to the Linux kernel to tell it what I/O address your CD-ROM drive uses, for example. A full explanation of all the options is available from the Linux BootPrompt HOWTO (http://sunsite.unc.edu/LDP/HOWTO/BootPrompt-HOWTO.html).





Your computer will then be booted into the Linux operating system, and when the boot process is complete, you will be prompted to replace the boot diskette with the root diskette.





The root diskette contains an image of a basic root file system, a minimal system from which the rest of the Linux distribution can be installed. Once this file system is mounted, you can login as root, and type ``setup'' on the command line to start installing the system.





To start with, the fdisk program will be run, and you will be asked how many partitions you wish to set up, and what types they should be. The simplest partition procedure is simply to create two partitions, one to hold the root file system, the other for swap space. This may be said to be mandatory for a machine with only four megabytes of RAM, and still highly recommended for those with more. As a crude rule of thumb, let the swap space be twice the amount of physical RAM, but always give yourself at least 16 megabytes total (physical and virtual) memory.





A more sophisticated procedure, particularly if the PC has two or more hard drives, is to create several more partitions. A good basic split is five partitions: / , /usr , /var , /tmp , and the swap partition. This makes no difference to performance when using a single IDE drive. For multiple SCSI devices, however, it would make more sense to split the file system appropriately among the various disks. More details on optimising disk partitions for Linux may be found in the Linux Partition mini-HOWTO (http://sunsite.unc.edu/LDP/HOWTO/mini/Partition).





Once the partitions have been set up, you select the installation media and the destination media. Most commonly, these will be respectively the CD-ROM drive and the hard disk that you have just prepared. But, you do have the option of installing from floppy disks, or over a network using NFS.





The installation process formats your chosen partition(s), using the Ext2 file system, by default. You have no good reason to chose any other file system. Formatting may be quick, or complete (that is, including checking for bad blocks); it is advisable to chose the latter. The time this takes will var y according to the size of hard disk, of course; it is somewhat slower than the DOS format program, but then it is serving a rather more sophisticated file system.





With the hard disk ready, we may choose which of the sets of applications to install. Some are mandatory, others are recommended, and others still are purely optional extras. For our purposes, the ``A'' series should be installed in toto, together with the ``N'' series. A minimal installation will fit comfortably on a 40 megabyte partition; everything takes about 150 megabytes; however, you will want to allow considerably more than that as working space.


Configuration

Once Linux is installed, the Slackware setup program does several of the simpler configuration tasks. Here's the low-down on what it does.


Local keyboard map

For anyone save U.S. readers, a keymap other than the default U.S. keymap is preferable. An alternative keyboard map file is loaded by the loadkeys(1) pr ogram. Please note that some versions of Slackware have a broken installation routine that offers to change your keyboard map, then happily continues to use the U.S. keyboard! This is simple to fix: for example, to use a U.K. keyboard, add the following line to the /etc/rc.d/rc.local system boot configuration file:

loadkeys /usr/lib/kbd/keytables/uk.map

By the way, the Linux keyboard is fully remappable. The *.map files are simple text files, easy to understand and hack. As an example, on my standard 102-key keyboard, I've swapped Caps Lock and Right Ctrl, so that the Control key is where the Good Lord intended it to be!


Mouse

Linux supports most sorts of mouse. Although we won't be running X on this box, a mouse is still useful, as Linux supports mouse-assisted cut-and-paste between virtual text consoles. The selection(1) program supports this, by running as a daemon installing it is an option during the p ackage installation phase. A link is made from the generic /dev/mouse file to the actual device file controlling the serial port to which the mouse is attached.



Modem

Modem configuration is usually a matter of making an optional link from the actual device file to /dev/modem . Any standard internal or external modem should work, with the only configuration work needed being to chose a free IRQ. Those few modems that rely on a DOS program to download firmware at runtime are obviously a problem; the solution is a garage sale! Seriously, in a pinch, if we are really stuck with such a device, booting DOS, setting up the modem, then warm-booting into Linux will work around this problem.



Host Name

Give the machine a name. You'll probably have local naming conventions to follow, so that the new machine fits in with the existing network.



Basic Network Configuration

There is a wealth of information on Linux networking, in a variety of sources, including The Linux Journal (http://www.ssc.com/lj/) and The Linux Documentation Project (http://www.linuxdoc.org/).



Ethernet

Configuring the Ethernet link is simple, and is done for us by the setup program. Here, I will run through what that program does ``"behind the scenes.''
There are two scripts, rc.inet1 and rc.inet2 . The first sets up basic networking, which is what we will be concerned with here. The second deals with NFS, which will be considered later.

HOSTNAME=`hostname`

This sets the host name by running hostname(8) . But how does hostname know what he host name is (if you see what I mean)? In Slackware, the file /etc/HOSTNAME should be manually edited so that it holds the fully-qu alified domain name. This file can then be read at boot-up, and used to set the hostname using hostname(8) , like so:

/bin/hostname `cat /etc/HOSTNAME`

Next, we configure a special device called ``lo'', short for ``loopback''. The loopback device is like a dummy network, in which the machine talks to itself. It has the standard address of 127.0.0.1, and is always required. We use:

/sbin/ifconfig lo 127.0.0.1
/sbin/route add -net 127.0.0.0

Now an optional part, that can be useful if the internet connection is a dial-up one, and is thus intermittent. We don't want the Internet host name to be unusable when the link is down; the special Linux ``dummy'' interface is designed specifically with this in mind.

/sbin/ifconfig dummy ourhost
/sbin/route add ourhost

Rather then typing in these values over and over, we set them once here.

IPADDR="192.168.1.1" # REPLACE with YOUR
IP address!
NETMASK="255.255.255.0" # REPLACE with YOUR netmask!
NETWORK="192.168.1.0" # REPLACE with YOUR network address!
BROADCAST="192.168.1.255" # REPLACE with YOUR broadcast address, if you
# have one. If not, leave blank and edit below.

Set up the Ethernet device:

/sbin/ifconfig eth0 ${IPADDR} broadcast ${BROADCAST} netmask ${NETMASK}

Add a route to the local network to the routing table:

/sbin/route add ${NETWORK}

Finished! The other networking configuration file, rc.inet2 , does not concern us here. However, note that it starts various daemons, including the various NFS servers, rpc.portmapi , and more. The install program will take care of this for you.



Name Service

Several files in /etc determine how host name to IP address translation is done.
The /etc/host.conf file


order hosts,bind
multi on

This file determines in what order name resolution shall be attempted. Here, we have specified that first the resolver will attempt to look up names in /etc/hosts , then, if that fails, attempt to use the default nameserver (as specified in /etc/resolv.conf ). The ``multi on'' means the more than one nameserver can be used.
The /etc/hosts file

This file holds a few hostname-to-address mappings that need to be available at boot-time, when no name service is available. Indeed, it can be used instead of a name server. A typical minimum file looks like this:

# For loopbacking (this is mandatory)
127.0.0.1 local localhost
# this host
xxx.xxx.xx.xxx this.hosts.ip.address
# gateway
xxx.xxx.x.xxx the.gateway.to.the.internet

The /etc/resolv.conf file


nameserver 127.0.0.1
domain mycompany.com

The file /etc/resolv.conf file controls how the resolver library routines operate. Here, we specify localhost for the address of the name server because I run a caching name server. Alternatively, this could be the IP address of your ISP's name server(s) -- there can be a list. If you are running a local name server on another machine, then put its IP address here. The domain parameter indicates the default domain for unqualified host names.



Caching named

It can be useful to set up a minimal named . This serves as a cache, so that name lookups only have to go out over the Net once; thereafter, they are stored locally, decreasing latency.
This is not the place for a tutorial in configuring named . For further details, there is a good DNS HOWTO (http://sunsite.unc.edu/LDP/HOWTO/DNS-HOWTO.html). For more general background, you may want to look at the "DNS Database Files." (http://www.packetstorm.securify.com/linux/admin/nag/node88.html) .
You may wish to use the Linux box to provide name service for the local network. This is a subject for a later article; for now, we will assume that this is being taken care of.
With installation complete, it is advisable to add a root password, and set up one or more ordinary users. Do not succumb to the temptation to use root for everyday work; this account is far too powerful, and sooner or later you will do something you will regret, such as the proverbial rm -fr / , which zaps EVERYTHING! Slackware comes with a nice little ``adduser'' program, which will do everything necessary. In any case, the manual steps are easy enough: edit /etc/passwd to add the user, the file being in the format:

user name:password:user id:group id:real name:home directory:shell

Then, create the user's home directory; and copy any useful files that may be in /etc/skel (common ones are a basic .profile , .less and .term ). Reboot and enjoy!



Internet Connection

Having installed and configured Linux, our final step is to get the Internet link up and running.



Dialup Link

The mechanics of setting up a dial-up link are so dependent on the particular ISP chosen that there isn't much to say in a general article like this one. I prefer SLIP, but many ISPs don't give you the choice anymore. Again, I prefer a static IP address, but most ISPs are now using dynamic addressing. It is worth shelling out a little more to get either a dial-up link with a static address, or a permanent line; but there are work arounds for the worst-case scenario, PPP with dynamic addressing. Space is too limited to consider to delve into making a Linux box happy with dynamic addressing.
Using PPP: The pppd program, which generally has path name /usr/sbin/pppd , is used. Here, for example, is the command line invocation (put in a script so I don't have to type it out each time) that I would use to connect to my ISP using PPP:

pppd connect 'chat "" ATDT01716640666 CONNECT "" \
ogin: tiny1 word: duh! ocol: PPP' \
/dev/cua3 115200 -detach debug cr
tscts modem defaultroute \
158.152.37.217:158.152.1.222

Where chat is another program called by pppd to actually dial up and log in to the remote termianl server.
The arguments to the chat program are expect-send string pairs:
"" Expect nothing (don't wait for a prompt)

ATDT01716640666 Send the dialing command to the modem

CONNECT Expect the answer ``CONNECT''

"" Send a return (null text followed by usual return)

ogin: tiny1 word: duh! ocol: PPP This is the sequence of expect-send strings needed to log in to my ISP. You can also think of these sequences as question-answer pairs, the first being the ``question'' (sent from the ISP), the second the ``answer'' (returned by chat ). Note: only the last few characters need to be specified, as in ``word:'' instead of ``password:'', which has the advantage that you don't need to worry if ``Password:'' is capitalized or not. The other options are as follows:
Here, /dev/cua3 is the callout serial port that my modem is on; 115200 is the baud rate on that line; -detach tells pppd not to put itself in the background; crtscts says to use hardware flow control on the line; modem tells pppd that this is a modem device so that the program will hang up the phone before terminating; defaultroute makes the PPP link the default route, which is usually what you want; and finally, 158.152.37.217:158.152.1.222 specifies the local and the remote IP addresses, respectively. Note that if you're using dynamic IP addressing, then the noipdefault option would be specified to request this second IP address from the remote hos t.



Permanent Line

A permanent line is simplicity itself, given what has gone before. Use slattach(8) to attach the SLIP interface to the device, like so:

slattach -p slip -s 19200 /dev/ttyS0

The -p option sets the protocol to use on the line. The default is set to cslip , that is, compressed SLIP. Other possible values are slip (normal SLIP), ppp (Point-to-Point Protocol) and kiss (AX.25 TNC protocol). The -s option sets a specific line speed, other than the default.
Then ifconfig and route are used to configure the interface and add the routing table entries respectively, in just the same way as the Ethernet device was configured above.

/etc/ifconfig sl0 $IPADDR pointtopoint $REMADDR up
/etc/route add default gw $REMADDR


Conclusion

At the end of this process, we have a fully-fledged Internet host, capable of performing any of the tasks we might expect such a box to undertake. In our next installment, we set up a Firewall to protect your local network.


Author Biography

Paul Dunne is a writer and consultant who specializes in Linux.




http://www.networkcomputing.com/unixworld/tutorial/013/013.part1.html

bahattab
09-04-2010, 02:44 PM
Tutorial: Linux Internet Server: Set Up a Firewall Part 2
http://www.atyafonline.com/vb/imgcache/5811.imgcache

By Paul Dunne (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html#bio)


This article examines how to set up a Linux box to provide routing services between the local network and the Internet, and to address the security issues raised by such a connection by having the Linux box act as a firewall. This article deals with setting up a Linux PC for use as a firewall between the Internet and a local network. It is a tutorial that takes the reader through installing, configuring and administering a L inux firewall. Some knowledge of TCP/IP networking and Linux is assumed, as well as a basic acquaintance with firewalls.





Introduction (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html#01)
Routing (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html#02)
Types of Firewall (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html#03)
Hardware Requirements (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html#04)
Configuration (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html#05)
Rule-sets (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html#06)

Blocking (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html#07)
Forwarding (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html#08)
Accounting (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html#09)

Conclusion (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html#10)


Questions regarding this article should be directed to the author at paul@tiny1.demon.co.uk
Other installments of this Linux Internet server tutorial series include:





Set Up a Linux Internet Server (http://www.networkcomputing.com/unixworld/tutorial/013/013.part1.html)
Set Up a Mail Hub (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html)
Providing Internet Services (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html)






Introduction

It is assumed that you are familiar with the theory behind firewalls. If not, a bit of background readin g might help. There is a good collection of papers at AT&T's Research site (http://research.att.com/dist/internet_security). The set of papers at the TIS site (ftp://ftp.tis.com/pub/firewalls) is also worth a read.



Routing

As it stands, our Linux box is connected to the Internet and to the local network, but our local network is still unable to talk to the Internet, and vice versa. For this, we must enable routing on the Linux box, so that packets from one network interface destined for addresses outside the local network are sent on through the other network interface.
There are two different ways to provide routing, depending on whether or not the local network has been allocated IP addresses by InterNIC, or whether it uses the ``private'' addresses allowed by RFC 1597 (http://www.internic.net/rfc/rfc1597.txt).
For the purpose of this article, we will assume that the local network has not had Internet addresses allocated to it, and must thus be kept hidden from the Internet. Our firewall set-up will serve the dual purpose of providing the routing services for the hidden network, and also acting as a security barrier.





Types of Firewalls

There are two types of firewalls. The first is a filtering firewall, where packets are allowed or denied routing according to a rule-set. The other type is the proxy firewall, which blocks off the internal network from the external network entirely, and provides proxy services as requested by the internal network. Further, there are two types of proxy firewall: firstly, the application proxy gateway, secondly, the circuit-level relay.
In this article, we will be setting up a basic filtering firewall. For more information about the other kinds, see the Firewalling and Proxy Server HOWTO (http://sunsite.unc.edu/LDP/HOWTO/Firewall-HOWTO.html).





Hardware Requirements

Any PC capable of running Linux can be used as a firewall. There are certain features that a firewall relies on more than others. A filtering firewall needs a decent amount of RAM, if only to hold the routing tables in memory; a proxy firewall's hardware needs are determined by the requirements of the services for which it provides proxy support. For example, providing WWW proxy support can demand plenty of RAM and high-performance hard disk space, depending on how much caching is done.





Configuration

Using a Linux box as a firewall can be done either by using the built-in firewall capability, or by installing additional packages. This article looks specifically at turning a Linux machine into a packet-filtering router, using no additional packaged software.



The Kernel

The Linux kernel needs to be compiled with certain options enabled in order to use the firewall code. Most generic kernels -- that type usually supplied with a distribution -- will have these options turned off, so that it is nece ssary to recompile the kernel. This is a simple task, and we will quickly run through the steps here. For more details, see the Linux Kernel HOWTO (http://sunsite.unc.edu/LDP/HOWTO/Kernel-HOWTO.html).
I should also point out that it is a good idea to take this opportunity to upgrade your kernel to the latest stable release. At time of writing, this is 2.0.30. The kernel is brought up to date in one of two ways: either by downloading the latest source tree en masse, or by applying all the patch files released between your version, and the current stable release. The former is easier, the latter cheaper if you pay for telephone calls to your ISP, or are billed for usage. Either way, many sites carry both. See the Linux v2 Information HQ (http://www.linuxhq.com/) for details.



Configuring The Kernel

The Linux kernel is configured by the ``make config'' command. The following options must be switched on.
CONFIG_FIREWALL=y
CONFIG_INET=y
CONFIG_IP_FORWAR
D=y
CONFIG_SYN_COOKIES=y
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_VERBOSE=y
CONFIG_IP_MASQUERADE=y
CONFIG_IP_ACCT=y


Recompiling The Kernel

The following command sequence will re-compile the kernel:

make dep && make clean && make zImage

Installing the New Kernel

The following sequence of commands copies the new kernel image and its associated symbol table to the root directory, and reruns LILO so that the boot loader knows about the new kernel:

cp /usr/src/linux/arch/i386/boot/zImage /
cp /usr/src/linux/System.map /
/sbin/lilo

It's not a bad idea to put the new kernel on a floppy only at first, and reboot using that diskette, just to make sure everything is working right. You can then install the new kernel on the hard disk as shown above when this has been done. You can use a simple copy operation, like:

cp /usr/src/linux/arch/i386/boot/zImage /dev/fd0

Getting ipfwadm

The ipfwadm(8) utility is used to administer the IP accounting and IP firewall services offered by the Linux kernel. You can get this utility from the X/OS site in source and binary form (http://simba.xos.nl/linux/ipfwadm/). It is very easy to compile the source and install.





Filtering Rule-Sets

The core of firewall functionality is contained in the rule-sets that determine what happens to packets. There are four types of rule-sets: those governing input, those governing output, those in charge of forwarding, and those controlling accounting. Rule-sets are maintained by ipfwadm(8) (http://www.networkcomputing.com/unixworld/tutorial/013/ipfwadm.8).
Rather than bludgeoning you with a great list of options and arguments that ipfwadm can take, we will introduce the most important gradually through examples. The manual page provides more details on the more esoteric arguments.
In the examples that follow, we shall construct a firewall machine tha t is connected to the local network via interface 192.168.1.1, and to the Internet via 192.168.20.1. Please note that the 192.168.0.0 net is a non-routed net address block set aside specifically for use on networks that are not connected to the Internet, or are screened from contact with the Internet by a firewall of the type we are building. They should NOT be used on any network which will be directly connected to the Net. The system acts as a mail relay hub for the local network, as a router for the local network, provides local DNS services, and provides HTTP and FTP services.
Note that in the rules that follow are taken from an ``rc script'' on my machine, where the following variables are defined at the head of the file to simplify maintenance:
LOCALHOST=`hostname`
IFEXTERN="158.152.37.217"
IFINTERN="192.168.1.1"
LOCALNET="192.168.1.0/24"
ANYWHERE="0.0.0.0/0"
UNPRIVPORTS="1024:65535"






Blocking

The blocking rules control going directly to or fro m the firewall itself. In what follows, I will build up step by step a set of blocking rules for our basic firewall. With ipfwadm , blocking rules are controlled by two parameters: -I for input rules and -O for output rules.
Firstly, we block everything! The idea here is that we deny access wherever we do not explicitly permit it.


# Sure we're paranoid, but are we paranoid enough?
ipfwadm -I -p deny
ipfwadm -O -p deny
ipfwadm -F -p deny

The -b option specifies that the rule is bidirectional, that is, will match IP packets in both directions. The -p option sets the default policy, which will be used when no matching rule is found. So, as it stands, our firewall will reject all packets coming in or going out. Obviously, this won't do! So, we will add some rules to selectively allow traffic to and from the firewall. First though, we need a way of protecting ourselves from packet spoofing. The fol lowing two rules will ensure that we do not fall victim to such attacks:


# Handle spoofed packets.
ipfwadm -I -a deny -V $IFEXTERN -S $LOCALNET -D $ANYWHERE
ipfwadm -I -a deny -V $IFEXTERN -S $IFEXTERN -D $ANYWHERE

For a start, we can allow packets between the firewall and our local network:


# Unlimited traffic within the local network.
ipfwadm -I -a accept -V 192.168.1.1 -S 0.0.0.0/0 -D 0.0.0.0/0
ipfwadm -O -a accept -V 192.168.1.1 -S 0.0.0.0/0 -D 0.0.0.0/0


# Unlimited traffic to localhost
ipfwadm -I -a accept -V 127.0.0.1 -S 127.0.0.1 -D 127.0.0.1
ipfwadm -O -a accept -V 127.0.0.1 -S 127.0.0.1 -D 127.0.0.1

Here, we see the use of the input ( -I and output ( -O ) categories, to control what direction of traffic our rule will be applied to. The -V option states that only traffic originating from that interface will be checked by this rule. In this example, I have assumed that the network card c onnecting our firewall to the local network has the address 192.168.1.1.
Now, in one fell swoop, we add SMTP, FTP, WWW and DNS access:


# SMTP
ipfwadm -I -a accept -P tcp -S $ANYWHERE -D $LOCALHOST smtp
ipfwadm -O -a accept -P tcp -S $LOCALHOST $UNPRIVPORTS -D $ANYWHERE
ipfwadm -O -a accept -P tcp -S $LOCALHOST smtp -D $ANYWHERE
ipfwadm -I -a accept -P tcp -S $ANYWHERE -D $LOCALHOST $UNPRIVPORTS


# DNS
ipfwadm -I -a accept -P tcp -S $ANYWHERE -D $LOCALHOST domain
ipfwadm -I -a accept -P udp -S $ANYWHERE -D $LOCALHOST domain
ipfwadm -O -a accept -P udp -S $LOCALHOST domain -D $ANYWHERE


# FTP
ipfwadm -I -a accept -P tcp -S $ANYWHERE -D $LOCALHOST ftp
ipfwadm -I -a accept -k -P tcp -S $ANYWHERE -D $LOCALHOST ftp-data
ipfwadm -O -a accept -P tcp -S $LOCALHOST ftp -D $ANYWHERE


# WWW
ipfwadm -I -a accept -P tcp -S $ANYWHERE -D $LOCALHOST www
ipfwadm -O -a accept -P tcp -S $LOCALHOST www -D $ANYWHERE

Because we intend to allow traffic to be forwarded to and from the in ternal network, we must also add some input and output rules to allow for this, in addition to the forwarding rules in the next section:


# Outgoing packets.
ipfwadm -O -a accept -P tcp -S $LOCALNET $UNPRIVPORTS \
-D $ANYWHERE smtp ftp ftp-data www telnet domain
ipfwadm -O -a accept -P tcp -S $IFEXTERN $UNPRIVPORTS \
-D $ANYWHERE smtp ftp ftp-data www telnet domain
ipfwadm -O -a accept -P udp -S $LOCALHOST $UNPRIVPORTS \
-D $ANYWHERE domain


# Incoming packets.
ipfwadm -I -a accept -k -P tcp -S $ANYWHERE ftp www telnet domain \
-D $LOCALNET $UNPRIVPORTS
ipfwadm -I -a accept -k -P tcp -S $ANYWHERE ftp www telnet domain \
-D $IFEXTERN $UNPRIVPORTS
ipfwadm -I -a accept -P tcp -S $ANYWHERE ftp-data -D $LOCALNET $UNPRIVPORTS
ipfwadm -I -a accept -P tcp -S $ANYWHERE ftp-data -D $IFEXTERN $UNPRIVPORTS
ipfwadm -I -a accept -P udp -S $ANYWHERE domain -D $LOCALHOST $UNPRIVPORTS


Firstly, we allow input TCP packets from anywhere into our local network, provided they are f rom our allowed services. We also allow UDP packets to the name server. The -k option says to only allow packets with the ACK bit set. Then, we have two output rules, again, one for TCP, one for UDP. These should be easy to understand now, as they are but the mirror-image of the input rules.





Forwarding

The forwarding rules control which packets will be forwarded by the firewall. In addition, our forwarding rules must take care of masquerading. As mentioned above in the section on routing, we are using ``private'' IP numbers for our network, and we cannot allow packets with source addresses set to these numbers out onto the Internet. Therefore, our firewall will ``masquerade'' as our other machines for the purposes of sending packets to and from the Internet.
Once again, we start by denying everything, before explicitly allowing some sorts of traffic.


ipfwadm -F -p deny

Here, the -F option specif ies a forwarding rule. And, -p deny as we have seen before, sets the default policy to deny everything, then we explicitly allow the services we wish to permit:

ipfwadm -F -m -a accept -P tcp -S $LOCALNET $UNPRIVPORTS \
-D $ANYWHERE ftp ftp-data www telnet
ipfwadm -F -m -a accept -k -P tcp -S $ANYWHERE ftp www telnet \
-D $LOCALNET $UN PRIVPORTS
ipfwadm -F -m -a accept -P tcp -S $ANYWHERE ftp-data \
-D $LOCALNET $UNPRIVPORTS

Here, the -m option enables masquerading, and -P specifies the protocol involved. The numeric argument after the network/port source is the range of non-privileged ports this operation is permitted to use. The destination is set to ``any''.





Accounting

The accounting rules are used to build up packet and byte counts for selected traffic. There is a single set, used for both incoming and outgoing traffic. Every packet is checked against each rule, and the counts of ea ch matching rule incremented.
Now, ipfwadm controls accounting with the -A option. A direction can be specified (in, out, or both; default both) indicating whether only packets in the specified direction should be counted. For example, the following keeps track of all traffic to and from the local Web server:

ipfwadm -A -a -b -P tcp -S 0.0.0.0/0 -D 192.168.1.2 www

Where we assume that a machine on the local network with address 192.168.1.2 hosts the Web server.
The rule I use is rather more simple, just:

ipfwadm -A -a -b






Conclusion

This article has shown you how to set up a Linux box as a combined router and firewall, using the network capabilities built in to the Linux kernel. It does not attempt to provide a complete, robust firewalling solution; but it will prove sufficient for sites without grave security concerns. For further information, a good starting p oint is Linux Journal Firewall Resources (http://www.ssc.com/lj/issue25/TIS.html)





Author Biography

Paul Dunne is a writer and consultant who specialises in Linux. He has a home page (http://www.cix.co.uk/%7Edunnp) that describes in more detail what he does.



http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html

bahattab
09-04-2010, 02:52 PM
Tutorial Article: Linux Internet Server: Setting Up a Mail Hub Part 3
http://www.atyafonline.com/vb/imgcache/5812.imgcache

By Paul Dunne (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#bio)



Read on to learn how to use Linux to serve the mail transport needs of your organization.



Introduction (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#01)
Getting and Compiling Sendmail (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#02)
Configuring the Mail Hub (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#03)

Introduction (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#03A)
Generating the Mail-hub configuration (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#03B)
The root ``.mc'' file (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#03C)
The sendmail.cf file (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#03D)
Installing Sen dmail (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#03E)

Operations (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#04)

Starting Sendmail on boot-up (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#04A)
The Mail Queue (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#04B)
Logging (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#04C)
Security (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#04D)

Clients (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#05)

/etc/aliases (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#05A)
Other Linux boxes (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#05B)
Windows (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#05C)

Conclusion (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#06)
Addendum: Editing /etc/sendmail.cf by hand (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#07)

Questions regarding this article should be directed to the author at paul@tiny1.demon.co.uk
This article builds on my two earlier articles on installing Linux and configuring Linux for Internet access, listed here:


Set Up a Linux Internet Server (http://www.networkcomputing.com/unixworld/tutorial/013/013.part1.html)
Set Up a Firewall (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html)
Providing Internet Services (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html)






Introduction

In this article, we will cover setting up a Linux machine to act as a mail hub for the local network, allowing workstations to send and receive Internet mail without themselves being directly connected to the outside world. You should already know how to install Linux and connect a Linux machine to the Internet: previous articles in this series have examined these issues.





Getting and Compiling Sendmail

Although Sendmail comes ready built with almost any Linux distribution you care to name, there are advantages to knowing how to ``roll your own.'' A widely-used, important program such as Sendmail inevitably attracts a lot of attention from crackers. Updates to the program incorporating fixes for the latest security holes are regularly being made available. These updates are available as patches against the source code, so you need the source if you want to keep up. To provide the optimum degree of security for your site, down-load the Sendmail source from a reputab le site, then configure, compile and install Sendmail yourself,
There is a Sendmail Web page (http://www.sendmail.org/) (<URL:http://www.sendmail.org/>), and many sites mirror the source code from there.
Extract the source into a directory -- /usr/src/sendmail-x.x.xx -- and change into the /src directory therein. In there is a makesendmail shell script that will do all the work for you. It is easiest to do the configuration in the source directory, before actually installing the binary and configuration files.





Configuring the Mail Hub



Introduction

Tackling the Sendmail configuration process from scratch is tough, no two ways about it. The main configuration file, sendmail.cf , is designed to be easy for the Sendmail program to read and parse; therefore, it appears somewhat inscrutable to humans. Fortunately, it is a task that rarely has to be done from the beginning.
The Sendmail distribution includes several sample sendmail.cf files, one or other of which can be adapted to most configurations with a few changes; and any modern Linux distribution will also include these in its Sendmail installation.
Version 8 Sendmail has introduced an important simplification into the configuration process, by shifting the user intervention from direct editing of the Sendmail configuration file to making changes to files of m4(1) (http://www.networkcomputing.com/unixworld/man/m4.1) macros, which is easier and more intuitive. I consider use of the m4 macros in this section, whereas the section on configuring a Sendmail client that connects to our mail hub will deal with the /etc/sendmail.cf file directly, as that process is sufficiently simple to be easily accomplished without the aid of the m4 macros.





Generating a Sendmail configuration

The Sendmail configuration apparatus is in the cf/ subdirectory. T he structure of this subdirectory is as follows:
[ Editor's note: Thus, the first subdirectory listed below is cf/m4 , the second cf/cf , and so forth.]
m4/ This contains support routines, which should not be changed. cf/ The configuration files themselves. They have ``.mc'' suffixes, and must be run through the Unix m4 program to become usable. The resulting output should have a ``.cf'' suffix. ostype/ Definitions describing a particular operating system type. These should always be referenced using the OSTYPE macro in the ``.mc'' file. domain/ Definitions describing a particular domain, referenced using the DOMAIN macro in the ``.mc'' file. mailer/ Descriptions of mailers, referenced using the MAILER macro in the ``.mc'' file. sh/ Shell files used when building the ``.cf'' file from the ``.mc'' file in the cf/ subdirectory. feature/ These hold special features that you might want to include. They should be referenced using the FEATURE macro. hack/ Local hacks from Berkeley (the home of Sendmail), of no more than voyeuristic interest, if that. siteconfig/ Site configuration -- for instance, tables of locally connected UUCP sites.




A root ``.mc'' file for the Mail-hub

The base ``.mc'' file forms the starting point for m4 directives that invoke other macro files. All of the definitions in our base ``.mc'' file in turn reference other ``.mc files. Thus, order is important: follow that given here.
VERSIONID(`@(#)unixworld-online.mc 8.5 (Virtual Reality, Maan) 19/8/97')
OSTYPE(linux)
FEATURE(nouucp)
MAILER(local)
MAILER(smtp)

In what follows, I shall simply explicate what I have done here. For the full in formation, see the README file in the cf/ subdirectory. There is also a good explanation in a previous UnixWorld Online Sendmail tutorial (http://www.networkcomputing.com/unixworld/tutorial/008/008.txt.html).
The first line is for housekeeping, and puts the version line into the output file so you can keep track of changes.



OSTYPE

The first macro defines our operating system. You must define an operating system environment, or the configuration file build will not work. For us, the OS is Linux, so we use the file in the ostype directory named linux.mc . This contains such things as default file locations and other OS-specific material. You shouldn't need to change it.



FEATURE

nouucp The only feature we use is nouucp, which says, don't do anything special with UUCP addresses at all. nullclient This feature could be used to do what we will do later on by hand, that is, generate a stripped-do wn configuration file that does noting but forward all mail to a central hub via a local SMTP-based network. The argument is the name of that hub.


MAILER

The MAILER macros use macro files to specify rules to handle one or more mailers. Here, we invoke definitions for a local mailer and an SMTP mailer. As a general rule, put the MAILER definitions last in your .mc file, and always put MAILER(smtp) before MAILER(uucp) -- several features and definitions will modify the definition of mailers, and the SMTP mailer modifies the UUCP mailer.
local The local and prog mailers. You will almost always need these; the only exception is if you relay ALL your mail to another site. This mailer is included automatically. smtp The Simple Mail Transport Protocol mailer. This does not hide hosts behind a gateway or another other such hack; it assumes a world where everyone is running a name server. This file actually defines four mailers: smtp for regular (old-style) SMTP to other servers, esmtp for extended SMTP to other servers, smtp8 to do SMTP to other servers without convertin g 8-bit data to MIME (essentially, you are saying here that you know the other end is 8-bit clean even if it doesn't say so), and relay for transmission to our RELAY_HOST, LUSER_RELAY, or MAILER_HUB.




The sendmail.cf File

The final Sendmail configuration file is produced by invoking m4 with the .mc file specified above as its argument. The command line looks like this:

m4 ../m4/cf.m4 config.mc > config.cf

Where cf.m4 -- in ../m4 relative to the current directory -- is a general set of macro definitions that is always required, config.mc is the macro file we've developed above, and config.cf the output, the Sendmail configur ation file, which will be installed as /etc/sendmail.cf .





A Sendmail Installation

After you complete the configuration, as root type ``pmake install'' to install the new Sendmail program. (Note: that's pmake, to use the 4.4BSD make, not the GNU make which Linux uses). Of course, you should back up your old program first in case you need to ``back off'' and return to it. The files installed include:
/usr/sbin/sendmail This is the actual Sendmail program binary. There may be a symbolic link in Sendmail's historic location, /usr/lib , pointing here, but /usr/sbin/ is now the actual directory location. /etc/sendmail.cf This is the configuration file that we generated. /usr/bin/newaliases This is another symbolic link to /usr/sbin/sendmail . When invoked by this name, Sendmail will rebuild the aliases database. /var/spool/mqueue This is the directory, where incoming and outgoing mail is kept awaiting delivery. It should have mode 700, to prevent inquisitive users from peeking at other users' mail. /etc/aliases This is the systemwide aliases file. /usr/lib/sendmail.hf This is the help file for Sendmail. /etc/sendmail.st This optional file can be used by Sendmail to record statistics. /usr/bin/mailq This is also a symbolic link to /usr/sbin/sendmail . When invoked under this name, Sendmail prints the contents of the mail queue.




Operations



Starting Sendmail on boot-up

You will most likely want to have the Sendmail daemon started every time the machine boots up. In Slackware, this is done by adding a line to the appropriate ``rc'' file in the /etc/rc.d directory. The Slackware insta ll procedure puts this in /etc/rc.d/rc.M . The code should look like this:

if [ -x /usr/sbin/sendmail ]
echo "sendmail "
/usr/sbin/sendmail -bd -q1h
fi

This checks to see if the file is executable, then tells the system console that it's about to invoke Sendmail, invokes Sendmail in daemon mode ( -bd ), and sets it to process the mail queue every hour ( -q1h ).





The Mail Queue

The mail queue lives in the /var/spool/mqueue directory, by default. All mail messages are held as two files, one named df XXXnnnnn , the other qf XXXnnnnn , where XXX is a three-letter sequence, nnnnn a five-digit sequence, both used simply to give every message a unique identifier. The ``qf'' or queue control file contains the e-mail message header and various processing information, whereas the ``df'' or data file contains the body of the e-mail message. There are other files, but they are transient and usually of interest only to Sendmail.





Logging

Sendmail uses the Unix syslogd(8) (http://www.networkcomputing.com/unixworld/tutorial/013/syslogd.8) facility. Usually, this is set up to log all Sendmail transactions to /var/log/maillog , by default.





Security

Sendmail has a reputation as a security nightmare, but this is largely undeserved, particularly with Version 8, which has solved a lot of the problems that plagued previous versions. Actually, the degree of Sendmail security is largely the responsibility of the system administrator (you!). Some specific points to watch for:


Make sure the aliases file isn't writable except by trusted system personnel. This includes both the text and database version.
Make sure that other files that Sendmail reads, such as the mailertable, are only writable by trusted system personnel.
The queue directory sh ould definitely not be world writable. In fact, opinions vary on the correct permissions for the mail queue. One school of thought holds that 700 is the safest way; the other that 711 is permissible, allowing the queue to be searched by a Sendmail process that has relinquised its root privileges. Use 700 to be on the safe side; it will always be possible to relax this slightly should it cause problems.






Clients

Providing e-mail service to other machines in the network can be done in two ways. The first is to use SMTP to act as a ``mail hub'' that sends and receives internal network (and optionally local) mail on behalf of the other machines. Secondly, a POP service can be set up, where local users use client software on their computers to collect their mail via the POP3 protocol, and send mail via SMTP to the server.





The /etc/aliases File

Users on the local network must be identifiable by the Sendmail process running on the server machine. In the case of POP mailboxes, this is done by creating a normal user account. In the case of Linux clients collecting mail through Sendmail themselves, this is done by adding the appropriate alias to /etc/aliases . For example, on my local network, any mail arriving at my mail server (tiny1.demon.co.uk) destined for user bob is sent on to bob@donner.example.com on my internal network by the following line in /etc/aliases :
bob: bob@donner.example.com

The simplest way to make sure that mail comes back to the right place is to set the Reply-To header in all outgoing mail to point to the account on the mail-hub system, not the originating machine. This can be done in the options settings of your POP3 mailer, or will be handled for you by Sendmail on a Linux client.



It's recommended to have the mail-hub use the Sendmail ``masquerade'' feature, so that the headers of mail messages originating from your priv ate network are rewritten to look as though they came from the hub.



First, we turn on masquerading:



MASQUERADE_AS(mailhub.example.com)

where mailhub.example.com is the name by which your mail-hub is known on the Internet.
Normally, the only addresses that are masqueraded are those that come from this host. In our situation, that doesn't do a lot of good, as it's mail from other local hosts we want altered by the mail-hub to make it look as though the mail-hub sent it. We do this with the line:



MASQUERADE_DOMAIN(otherhost.example.com)

which has the effect that any mail from otherhost.example.com will, when relayed, be rewritten to have the MASQUERADE_AS address. This can be a space-separated list of names, or you can keep the list in a file, in which case the line to use in the ``.mc'' file is:
MASQUERADE_DOMAIN_FILE(filename)






Other Linux boxes

There are two ways o f handling the configuration for a Sendmail client that merely routes all outbound mail to a mail-hub. One can use the m4 configuration process, as described above for the mail-hub, and I'll run through that here.



The ``.mc'' file is simple, just:



divert(0)dnl
VERSIONID(`@(#)dumbclient.mc 28/10/97')
OSTYPE(linux)
FEATURE(nullclient, mailhost)

Where mailhost is the fully qualified domain name of the mail-hub to which all mail is to be forwarded.



This case is simple enough that the /etc/sendmail.cf file is not so arcane as it can be, so it is worth taking the opportunity to examine it in detail.



There isn't the space for a full run-down on the syntax of the file. For the full story, consult the irreplaceable Sendmail book, published by O'Reilly & Associates (http://www.oreilly.com/), available at a discount from Amazon books (http://www.amazon.com/exec/obidos/ISBN=1565922220/unixworldonlineA/).



The file is divided into sections, not for Sendmail, but to make it easier for humans to maintain (and explain).



Sendmail ``commands'' are usually one-letter in length, and must be at the beginning of a line. Generally, there is no whitespace between a command letter and its arguments.



The first part, Macros, shows variables (known as ``macros'' in Sendmail parlance) defined by use of the ``D'' (Define Macro), command. All the macros defined here are explained by comments on the line preceding them -- a wise practice that should not be confined to example files!



### Defined Macros (1)
# The name of the mail hub
DRwotan.example.com
# The hub as it is known to the outside world
DHtiny1.demon.co.uk
# The local official domain name
Dj$w
# Our domain name
DDexample.com
# Identity of the error message sender
DnMailer-Daemon
# Look of the Unix From line
DlFrom $g $d
# The characters that separate address components
Do.:%@!^=/[]
# Default form for the sender's a
ddress
Dq<$g>

The second section, Classes, is for a special type of variable, a class, which can hold multiple values. The command letter here is ``C''. The class we define in this example is w , which holds a list of alternative host names for the machine (that is, other than the fully-qualified domain name, or FQDN).
### Defined Classes (2)
# All possible names for local machine
Cw localhost donner

The third section specifies Sendmail options. These can be provided on the command line used to invoke Sendmail, but because they are so numerous, it makes more sense to specify them in the configuration file.
# default delivery mode (in background)
Odbackground
# temporary file permissions---0600 for secure mail
OF0600
# default UID & GID
Ou1
Og1
# level at which to syslog errors
OL9
# Wait for SMTP replies.
Or1h
# default messages to old style
OoTrue
# Replace unquoted spaces with a dot
OB.

The fourth part specifies the headers that must appear in every mail message. These are the headers that Sendmail will add if the mail user agent (MUA) has not already done so.
### Header Declarations (4)
HFrom: $q
HReceived: by $j id $i; $b
H?x?Full-Name: $?x$x$.
H?D?Date: $a
H?M?Message-Id: <$t.$i@$j>

The fifth section is a set of priority settings. Sendmail will process the mail in its queue in order of decreasing priority, beginning with ``special-delivery''. The level of priority is set by the MUA with the Precedence: header line.
### Priorities (5)
Pspecial-delivery=100
Pfirst-class=0
Plist=-30
Pbulk=-60
Pjunk=-100

The sixth section defines a set of mailers that Sendmail will use to actually deliver mail. Sendmail is a mail transport agent , it doesn't deliver the message itself. These lines all begin with a capital ``M''. The ``local'' and ``prog'' mailers are mandatory. The real work here is done by the special mailer , which invokes internal Sendmail routines rather than an exter nal mailer program, to send all mail to a ``smart host'' using SMTP.
### Mailer Delivery Agent Definitions (6)
# Mailer to forward all mail to the hub machine
Mhub, P=[IPC], S=10, R=0, F=xmDFMuCX, A=IPC $h
# Sendmail requires these, but we won't use them
Mlocal, P=/bin/mail, S=0, R=0, F=lsDFMShP, A=deliver $u
Mprog, P=/bin/sh, S=0, R=0, F=lsDFMeu, A=sh -c $u

The seventh and last section is the heart of Sendmail, the rule sets. These define the re-writing of addresses. The basic idea here is that there are two sides, a left-hand side (LHS) and a right-hand side (RHS). The LHS represents a pattern to match against input, and the RHS is the transformation to effect upon the input if a match is made. LHS and RHS are separated by tabs; comments are in the third column. You can learn more about these rules from this tutorial article (http://www.networkcomputing.com/unixworld/tutorial/01/01.txt.html).
### The Rules Sets (7)
S0 select delivery agent
R@$+ $#error $: Missing user name
R$+ $#
hub $@$R $:$1 forward to hub
<p>
S3 preprocessing for all rule sets
R$*<>$* $n handle <> error addresses
R$*<$*<$*>$*>$* $2<$3>$4 de-nest brackets
R$*<$*>$* $2 basic RFC822 parsing

S10 rewrite the sender for the hub
R$- $@$1@$H user -> user@hub
R$-@$w $@$1@$H user@local -> user@hub
R$-@$=w $@$1@$H user@othernames -> user@hub
R$-@$=w.$D $@$1@$H user@domain -> user@hub

S1 dummy ruleset 1 (unused)

For more information on the Sendmail configuration files and their customization see our Sendmail tutorial article (http://www.networkcomputing.com/unixworld/tutorial/008/008.txt.html).





Windows

Collecting e-mail from the mail-hub from a Windows box is a simple matter of using the POP3 protocol to collect the mail from a POP3 server, which grabs mail from the standard Unix mail spool, /var/spool/mail . A POP service should be installed as part of your standard Linux set-up. If its not, then use pkgtool or whatever to install it from the CD.
The entry in /etc/services should be as follows:
pop-2 109/tcp # PostOffice V.2
pop-3 110/tcp # PostOffice V.3

The service will be started automatically by inetd when a service request is received. This behavior is set up by the following lines in /etc/inetd.conf :
pop-2 stream tcp nowait root /sbin/tcpd /usr/sbin/in.pop3d
pop-3 stream tcp nowait root /sbin/tcpd /usr/sbin/in.pop3d

To use this approach, each mail account must be a ``real'' Unix account on the mail hub, not just an entry in /etc/aliases . It's best to make the account unusable for log in by entering a * in the password field of /etc/passwd and specifying a bogus shell -- like /bin/false -- in the last field of the password file entry.
I use Eudora Lite, which is a freeware, stripped-down version of Eudora Pro. It is a fine e-mail client in its own ri ght, available from Qualcomm (http://www.qualcomm.com/). Setting it up is simply a matter of pointing it at the mail hub, telling it the POP user name and password. One glitch I found was that not all options are saved to the EUDORA.INI file. Specifically, I had to set ``UseWinSock=1'' and ``UseDialup=0'' by editing the ``ini'' file, as changing these options from the menu had no effect.





Conclusion

Thus, we now have a working mail hub, providing Internet e-mail services to the local network.





Addendum: Editing /etc/sendmail.cf by hand

Let's say you have an existing Sendmail installation, one that ``came free'' when you installed Linux. You don't want to go to the bother of fussing about with getting the Sendmail source, figuring out m4, and the rest. Well, while I can't hope to cover all the details of the Sendmail configuration file syntax here, I can tell you the minimum changes yo u need to make to transform a generic sendmail.cf into one you can use. Because of the complexity of this file, I will list here only the things one [I]has to change.
In the section above on configuring a Linux client for the local network (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html#sendmail.cf), I have gone into more detail, which should suffice to give you a general understanding of the file syntax. Here, I will presume that there is already a suitable sendmail.cf on the machine (provided either by the Linux distribution, or from the Sendmail sources).
The ``w'' macro contains any other names that this host is known by, besides the FQDN. So, if the machine is known to your ISP as example1.com, say, but to your local network as example2.com, you need to put example2.com here. You might as well put ``localhost'' here, too.
Cwlocalhost example2.com

The ``S'' macro can contain the name of a smart relay host, to which all non-local mail is forwarded without further ado. Some sites can deliver mail to the local network, but cannot look up hosts on the Internet with DNS. To ensure delivery of all mail, such sites need to forward all non-local mail to a smart (or well-connected) host. For example, a customers of Demon, a UK ISP, would use post.demon.co.uk here.
DSpost.demon.co.uk

If you are on the end of a SLIP or PPP link, and you use a dial-on-demand system (controlled by diald(8) (http://www.dna.lth.se/%7Eerics/diald.html), for example), you won't want Sendmail to try to deliver mail straight-away, because that would keep the link going up and down all the time, with a phenomenal inflationary effect on your phone bill. To make Sendmail only attempt to deliver mail when actually processing the queue, set the Delivery Mode option to `deferred,'' as in:
O DeliveryMode=deferred

Those are all the changes you should need to make. The other parameters changes how Sendmail behaves, but should wo rk on your site without modification.





Author Biography

Paul Dunne is a writer and consultant who specializes in Linux. He has a home page (http://www.tiny1.demon.co.uk/) that describes in more detail what he does.




http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html

bahattab
09-04-2010, 03:23 PM
Linux Internet Server: Providing Internet Services Part 4
http://www.atyafonline.com/vb/imgcache/5813.imgcache

By Paul Dunne (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#bio)



Introduction (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#01)
Internet Services And Linux (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#02)
HTTP (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#03)

Getting A pache (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#03A)
Compiling Apache (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#03B)
Installing Apache (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#03C)
Configuring Apache (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#03D)

FTP (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#04)

Getting wu-ftpd (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#04A)
Compiling wu-ftpd (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#04B)
Configuring wu-ftpd (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#04C)

Telnet (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#05)

Configuring Telnetd (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#05A)

Invoking Services with inetd (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#06)

httpd (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#06A)
FTP (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#06B)
Telnet (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#06C)
Telling inetd about your changes (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#06D)

Conclusion (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#07)



Questions regarding this article should be directed to the author (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#bio)
This article builds on my three earlier articles on installing and configuring Linux for Internet access, listed here:





Set Up a Linux Internet Server (http://www.networkcomputing.com/unixworld/tutorial/013/013.part1.html)
Set Up a Firewall (http://www.networkcomputing.com/unixworld/tutorial/013/013.part2.html)
Set Up a Mail Hub (http://www.networkcomputing.com/unixworld/tutorial/013/013.part3.html)






Introduction

HTTP is probably the most likely service you'll want to provide from your Linux box. FTP and Telnet can be useful subsidiary services too, especially if you host Web sites for other users, and need to provide them with some ability to maintain their site content.





Internet Services And Linux

Linux uses the inetd ``super server'' to control what Internet services your machine makes available. Rather than having all the network daemons that you might require running all the time, inetd can handle all incoming requests for service, and start up the appropriate daemon only when a request for the associated service arrives. This makes much better use of system resources for services that a re not heavily used. It may be appropriate for example, if you want to offer Telnet access to the host, but do not expect this to be heavily used.
Inetd consults two files, /etc/inetd.conf and /etc/services . The inetd.conf file is for daemon configuration and services is used to describe the services that are available from the TCP/IP subsystem. This latter file specifies the port number and protocol (tcp, udp) for each service. As we proceed to deal with individual services, I show how each one can be set to be run from the inetd server, not just invoked as a stand-alone application.





HTTP

The most popular Internet service today is undoubtedly the World Wide Web. Linux can run any of the popular Unix HTTP servers. The one we'll be using as an example is Apache, probably the best of the freeware HTTP daemons.





Getting Apache

Apache is the server of choice for most Linux distrib utions, so chances are you can install the binary directly from your distribution CD. If not, both source and binary packages are available from the Apache web site (http://www.apache.org/).
Information on the latest version of Apache can be found on the Apache web site (http://www.apache.org/), giving the current release, any more recent beta-test release, and details of mirror web and anonymous FTP sites. If you already have a binary distribution, skip to Installing Apache (http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html#03C); otherwise, read the next section for how to compile the server.





Compiling Apache

Compiling Apache actually consists of three steps: selecting modules, creating a configuration, and finally compiling the program. All configuration of Apache is performed in the src directory of the Apache distribution. Change into this directory first.



Select modules to compile

This is done by editing the configuration file -- called, logically enough, Configuration . Uncomment those lines in this file corresponding to those optional modules you wish to include (among the Module lines at the bottom of the file), or add new lines corresponding to additional modules you have downloaded or written.
It is possible to comment out some of the default modules if you are sure they will not need them (be careful though, because many of the default modules are vital for the correct operation and security of the server). You should also read the instructions in the Configuration file to see if you need to set any of the Rule lines.



Run configure script

Normally, you can just type ``./Configure'' to run the Configure script as shown (with some sample output):
tiny1:/usr/src/apache_1.2b10/src$
./Configure

Using config file: Configuration
Using Makefile template file: Makefile.tmpl
+ configured for Linux platform
+ setting C compiler to gcc

These steps g enerate a Make file for use in the next stage. It also creates a Make file in the support directory, for compilation of the optional support programs.



make

The modules included with the Apache distribution have been tested and are used regularly by various members of the Apache development group. Additional modules, contributed by members or third parties with specific needs or functions, may be found at the Apache Web site contribution page (http://www.apache.org/dist/contrib/modules/). There are instructions on that page for linking these modules into the core Apache code.





Installing Apache

If you compiled Apache from source, you will have a binary file called httpd in the src directory. A binary distribution of Apache will supply this file. The next step is to configure the program. Apache is designed to be configured and run from the same set of directories where it is compiled. If you want to run it from somewhere else, ma ke a directory and copy contents of the conf, logs and icons directories there.





Configuring Apache

Configuring server operation is done by setting directives in three text-based configuration files with your favorite text or program editor. By default, these files are located in the conf directory and are named srm.conf , access.conf , and httpd.conf . Chances are you'll need to customize all three files.
To help you get started, the conf directory contains distribution-file templates named srm.conf-dist , access.conf-dist and httpd.conf-dist . Make copies of these files named srm.conf , access.conf , and httpd.conf , respectively. Before changing these files read the comments supplied in these files carefully. Failure to edit these files correctly could cause your server to quit working or perhaps operate insecurely. You should also have an additional f ile in the conf directory named mime.types , but this file rarely needs changing.



The httpd.conf configuration file

First configure httpd.conf , which controls general attributes of the server: the port number the server listens on, the user-ID the server runs as, and much more. Each configuration directive in the file is on its own line, and is often followed by a comment explaining the directive. I've discussed some of the more important directives below.
ServerType standalone ServerType is either inetd, or standalone. If you are running from inetd, the next relevant variable is ``ServerAdmin'' (see below). A Web server should generally run standalone in a production environment to minimize invocation overhead. Port 80 The port on which the daemon listens for requests from a client. For ports less than 1024, you will need to invoke httpd as root. However, most of these so-called ``well-known ports'' are reserved for ot her services. Only port 80 is reserved for the HTTP service, the protocol used by the Web. User www User identity for child process instance that serves the request. User nobody employed by default. Group wwwgroup Group identity for the child process. If you wish httpd to run as a user or group different from the default (nobody), you must invoke httpd as root, and then it will switch user and group identity during initialization. ServerAdmin you@your.address The address to which problems about the server should be mailed. Displayed for the user during certain error conditions, such as the 500 class of server errors. ServerRoot /usr/local/etc/httpd The directory that contains the httpd binary. Configuration files and log files are generally contained in conf and log subdirectories. ErrorLog logs/error_log The location of the error log file. If this does path does not start with /, ServerRoot is assumed prefixed to the path name. TransferLog logs/acce ss_log The location of the transfer log file. The server writes an entry in this file for each request made of it. PidFile logs/httpd.pid The server writes its process id (pid) number to this file. ServerName your.other.name Use this directive on systems where the gethostbyname() call may not work on the local host or where the host name returned should be a DNS alias, such as www.yoyodyne.com (http://www.yoyodyne.com/) instead of, say, host1.yoyodyne.com. However, such an alias must be defined, say, with a CNAME DNS aliases record.
The srm.conf configuration file

Next configure the srm.conf file, which defines the location of your HTML documents and CGI scripts. It's also employed to establish special functionality like server-parsed HTML (server-side includes) or internal imagemap parsing, etc.
DocumentRoot /usr/local/etc/httpd/htdocs The top-level directory of your document tree, from which files are served. By default, /usr/local/etc/httpd/htdocs . Note that symbolic links and aliases may be used to point to other locations. UserDir public_html Lets users serve documents from their home directories without necessity of creating links to them. Here's an example: if you were to specify UserDir Web then a request for the file ~user/foo.gif would cause the server to actually retrieve ~user/Web/foo.gif . Specify DISABLED to defeat this feature. DirectoryIndex index.html This directives specifies the name of the pre-written index file for a given directory. (This file is returned automatically if the directory, but not a file in that directory, was specified in the request). AccessFileName .htaccess The name of the file to look for in each directory for access control information. DefaultType text/plain DefaultType is the default MIME type for files of unknown file-name extension. That is, there's no entry in the mime.types file (or entry in srm.conf ) that maps the given file-name extension to a MIME type. AddType type/subtype ext1 AddType allows you to add or override an entry in the mime.types file. Generally, you would use this directive rather than changing the mime.types file. AddEncoding x-compress Z AddEncoding x-gzip gz AddEncoding directives define new encoded file types, which are used by browsers that have the capability to decode compressed files ``on the fly''. Except for some X Window System- based browsers, most browsers don't support this uncompression feature. Redirect oldpath newURL Redirect allows you to direct clients to documents that have been relocated, perhaps to a different server. Alias /icons/ /usr/local/etc/httpd/icons/ Use this directive to create a virtual document (or directory). Any accesses to it will be satisfied by a different file or directory. Multiple Alias directives may appear in the configuration file, up to 20. ScriptAlias /cgi-bin / /usr/local/etc/httpd/cgi-bin/ Use this directive to create a virtual directory where accesses to that directory are satisfied by returning the output of a CGI program in that directory. Multiple ScriptAlias directives may appear in the configuration file, up to 20. AddType text/x-server-parsed-html .shtml If the server supports server-side includes, then it recognizes this special MIME type to identify files (by file-name extension) subject to inclusion. Specify .html or .htm to support server-side inclusion in most of your documents. Caution: This approach can place a significant additional load on the server. AddType application/x-httpd-cgi .cgi Specify this MIME type to have the server execute files whose names end with .cgi as CGI programs, instead of displaying their contents. Although, any available (not already used) file-name extension could be used here, .cgi is commonly used.
The access.conf configuration file

Finally, configure the access.conf file. The default configuration enables all features for all external users without any restrictions. Chances are you'll want to impose some security restrictions, such as to prevent directory indexing. In the examples that follow, assume that /usr/local/etc/httpd is the document root directory.
To illustrate the file structure, the following directives could be used to impose the default minimal-security configuration:
<Directory /usr/local/etc/httpd/cgi-bin>

Options Indexes FollowSymLinks

</Directory>

<Directory /usr/local/etc/httpd/htdocs>

Options Indexes FollowSymLinks

AllowOverride All

<Limit GET>
order allow,deny
allow from all
</Limit>

</Directory>

Here are some modifications you may need to make:


Change the sectioning Directory directives as necessary if you don't employ the directories we use in our example.
Remove the Indexes optio n to prevent users from listing files. Recommendation: at least disable directory indexing for the CGI bin directory because users don't need to list files in that directory for security reasons.
Change the parameter for the AllowOverride option from All to None to disallow override of your security directives in the access.conf file by a per-directory access-control file (often named .htaccess ) that could be installed by another local system user.

<Directory /usr/local/etc/httpd/cgi-bin>

All entries in the access.conf file are specified on a directory basis using the <Directory>...</Directory> sectioning directives. All the directives within a section only apply to the specified directory (and all subdirectories, unless overridden with another sectioning directive). Options This directive may have values ``None'', ``All'', or any combination of ``Indexes'', ``Includes'', or ``FollowSymLinks''. Th e specification of ``Indexes'', ``Includes'', or ``FollowSymLinks'' enables directory indexing, server-side includes, or the ability to follow symbolic links to locate a document, respectively. <Limit GET>
order allow,deny
allow from all
</Limit>

Limit is a sectioning directive used within the Directory sectioning directive to control the resources a client can access. The argument to Limit can be one of GET, PUT, or POST to specify the request method. The order and allow subdirectives in this example specify that the server will allow resource access to any user (from any system). There are many more directives available for customizing server operation, but their discussion is beyond the scope of this article. More information about these directives can be found at this Web page (http://www.apache.org/docs/).



The Per-Directory Access-Control File

In addition to the three configuration files discussed above, serv er behavior can be configured on a per-directory basis by using the per-directory access control file named .htaccess , by default. This name can be changed with the AccessFileName directive in the srm.conf configuration file.



The mime.types File

This file defines the relationship between file-name extensions for files on the server and the MIME type associated with the file. When a browser requests a file, the MIME type of that file is sent from server to browser so the browser knows how to handle the file.
Generally, you don't need to edit this file. If you need to define a new MIME type, then use the AddType directive discussed earlier.





FTP

Nowadays, FTP (File Transfer Protocol) service is often handled through a Web server. Of course, it can be provided as a stand-alone service, though, and -- as such -- is particularly useful as a means of uploading files to the server.





Gettin g wu-ftpd

The FTP daemon developed at Washington University in St. Louis and named wu-ftpd is the FTP server daemon chosen by most Linux distributions, so it may well be on your system already. If not, it is available on many Linux and other FTP sites throughout the world. Its home (primary) site starts at this directory at the Washington University FTP site (ftp://wuarchive.wustl.edu/packages/wuarchive-ftpd).





Compiling wu-ftpd

Compiling the FTP server is simple. There are a whole set of path names that can be changed in src/pathnames.h , but, it is quite sensible to leave them set to their default values. So, without further ado, type ``build lnx'' (No, I don't know why it isn't ``build linux''). Once the compile is over, change user identity (with su ) to the root account and type ``build install'' to install the new FTP server programs.





Configuring wu-ftpd

Copy the compress binary to the ~ftp/bin/compress location.



Copy the ftpconversions , ftpusers , and ftpgroups files to the locations specified in pathnames.h . There are examples of these files in the doc/examples directory.



Create the directory for the SITE EXEC programs, as specified in pathnames.h . Put any executables that you want anonymous users to be able to run in this directory. However, be careful what you put here for obvious security reasons.



Note that if you are using the pre-compiled wu-ftpd that comes with Slackware, be aware that some versions of this distribution have an incorrect setting for _PATH_EXECPATH in the ftpd binary (/bin). Recompile with this set to a special path, such as /bin/ftp-exec.



Run bin/ckconfig to make sure that all the support files are properly installed.



The ftpd(8) man page that came with your operating system should do a goo d job of explaining how to set up the anonymous FTP hierarchy. If you don't have the man pages on your system, they are available on-line (http://www.landfield.com/wu-ftpd/man.html).



At the very least, you will need the directory ~ftp/bin set to execute-only (mode 111) with a copy of ls also set to execute-only, and the directory ~ftp/etc set to execute-only, with an edited copy of /etc/passwd and /etc/group . The only reason for the password files is so that directory listings will show user and group names rather than numbers. The directories are execute-only to prevent the curious from snooping around. We are following the general principle of not giving more authority than is actually needed.



The ~ftp/pub , ~ftp/usr , and ~ftp/var directories should all be set to mode 555 (read and execute permission enabled for all user categories), and /incoming to set to mode 0333 (write and execute permission enabled). Make sure that you have an /etc/shells file that lists all valid shells on your system. Otherwise, those who have shells not listed there will not be able to use this FTP facility.



/etc/ftpaccess

This is the main ftpd configuration file. In what follows, I've extracted lines from a typical file, and followed them with a discussion of the sample lines:
#deny *.example.com /var/spool/ftpd/message.deny
#deny 0.0.0.0 /var/spool/ftpd/message.deny
#deny * /var/spool/ftpd/msg.dead

The first directive here is one that denies access to the FTP server from certain hosts (those in the ``example.com'' domain). The three example lines are commented out, but left in the file to serve as aide memories. The general form is deny address message-file , where, by convention, the message file contains an explanation of why access is being denied.

loginfails 3

The loginfails directive specifies the maximum number of unsuccessful log-in attempts that will be tolerated until the server logs a ``repeated login failures'' message and terminates the connection. The default value is 5.

class local real,guest,paul 192.168.1.*
class remote guest,anonymous *

The class directive sets up a class of users. Here, the third field (which we call the type list ) can have the value ``real'' for users that already have accounts on the system, ``anonymous'' for anonymous FTP access, and ``guest'' for guest accounts. The guest account keyword is for use with the ``guestgroup'' directive, which allows real user accounts to be restricted.

guestgroup ftponly

In the example, if a real user is a member of ftponly, the session is set up exactly as with anonymous FTP. In other words, a change root system call ( chroot() ) is done, and the user is no longer permitted to issue the USER and PASS commands. The user 's home directory must be properly set up, exactly as anonymous FTP would be. The home directory field of the passwd file entry is divided into two directories: first, the root directory, which will be the argument to the chroot() call, and second, the user's home directory relative to the root directory, with the two halves separated by a dot.
The standard use for this directive is to allow greater access for local users than for remote users, especially if it's unlikely that real users will be using their accounts from remote locations. You can add a bit of security by not allowing the ``real'' user to log in from remote locations, as in the example above.

passwd-check rfc822 enforce

Here, we specify the level of password checking that should be done. Remember, the password for anonymous FTP is the user's electronic mail address. The syntax is as follows:

passwd-check <none|trivial|rfc822> (<enforce|warn>)

The meaning of the allo wed values can be described:
none no password checking performed. trivial password must contain an @ character. rfc822 password must be an RFC822-compliant address. warn warn the user, but allow them to log in. enforce warn the user, and then log them out.

limit dead 0 Any /var/spool/ftpd/msg.dead
limit local 2 Any /var/spool/ftpd/msg.toomany
limit remote 2 SaSu|Any1800-0600 /var/spool/ftpd/msg.toomany
limit remote 6 Any /var/spool/ftpd/msg.toomany

The limit directive serves to control the load on the machine by limiting the number of users who can be connected at any one time. The general meaning is, ``limit class to n users at times times , displaying message_file if the user is denied access''. The check is performed at log-in time only. Multiple limit commands can be specified, but only the first applicab le one is used. Failing to define a valid limit, or a limit of -1, is equivalent to allowing unlimited access.
The next two directives deal with informational messages for users. Some sites are required to have these. The readme directive tells the user when the message file was last changed, while the message directive holds the actual text to be shown to the user.

readme README* login
readme README* cwd=*

The FTP daemon will notify the user at log-in time or upon using the change working directory command that the file exists and was modified on such-and-such date. The format of the entries is readme path when user-class .
The when parameter (field three) may be ``login'' or ``cwd= directory ''. The users affected are listed in the fourth field. If this field is omitted all users are affected.
If when is cwd= dir , dir specifies the new default directory that will trigger the notification. The message will only be displayed once, to avoid bothering users. Remember, that when read-me messages are triggered by an anonymous FTP user, the path name must be relative to the base of the anonymous FTP directory tree. The optional class specification allows the message to be displayed only to members of a particular class, where more than one class may be specified.
message /etc/mirrors.msg cwd=/mirrors
message /etc/welcome.msg login
message .message cwd=*

These message lines define various messages that are displayed to the user when logging in or changing working directory, as controlled by the when parameter. If when is CWD= dir , dir specifies the new default directory that will trigger the notification. The optional class specification allows the message to be displayed only to members of a particular class. More than one class may be specified.
There can be ``magic cookie s'' in the read-me file that cause the FTP server to replace the cookie with a specified text string, as specified here:
%T local time (format: Thu Nov 15 17:12:42 1990)
%F free space in partition of CWD (in kilobytes)
%C current working directory
%E the maintainer's email address as defined in ftpaccess
%R remote host name
%L local host name
%U username specified at log-in time
%M maximum allowed number of users in this class
%N current number of users in this class

The message will only be displayed once to avoid annoying the user. When messages are triggered by an anonymous FTP user, the path must be relative to the base of the anonymous FTP directory tree.
log commands real

There are two types of ``log'' directives. One type (denoted by ``commands'' in field two) enables logging of individual commands by users. Here, the third field contains a comma-separated list of keywords that denote the class of users -- either anonymous, guest, or real -- for anonymous FTP, guest-account, and real-account access, respectively.
log transfers anonymous,real inbound,outbound

The second type enables logging of file transfers. The third field in our example above denotes the user classification, like in type-one logging. Here, the fourth fields denotes the transfer direction. Thus, logging of transfers to the server (incoming) can be enabled separately from transfers from the server (outbound).
There are other directives in the file which I have not mentioned, restricting my comments to the most important ones. See the ftpaccess(5) man page for details of the others. If you don't have the man pages on your system, they are available on-line (http://www.landfield.com/wu-ftpd/man.html).



ftphosts

The ftphosts file, also known as the FTP daemon host-access file, has entries are of the form:
allow
username addrglob

deny
username addrg
lob


Where, addrglob can be any pattern representing one or more Internet addresses, either hostnames or IP-address numbers. For example:
allow bartm example.com
deny fred example.com 131.211.32.*

allows user ``bartm'' to connect from the host or domain example.com, while denying access requests from user ``fred'' at example.com or the IP address range 131.211.32.1-131.311.32.254.



ftpusers

This file describes the names of the users who are not allowed to log into the system via the FTP server. This usually includes accounts, such as ``root'', ``bin'', ``uucp'', ``news'' and other system-related accounts. These accounts are used for administrative purposes, and are not meant for general system access.





Telnet

Telnet provides interactive log-in (shell) sessions on the server. It is a basic network application that should always come ready-installed with a Linux distribution.





Configuring telnetd

Little configuration is necessary for the Telnet daemon, once Linux is correctly installed. The /etc/ttys file controls the default terminal type for the pseudo-terminals that Telnet uses, and should normally be set to vt100, like so:
vt100 ttyp0
vt100 ttyp1
vt100 ttyp2
vt100 ttyp3






Invoking Services with inetd



httpd

Generally, one would run the HTTP daemon standalone in a production environment, typically started from one of the run-command files on boot-up. However, you may wish to have it invoked by inetd for occasional, testing purposes. To accomplish the latter, add the following line to the /etc/inetd.conf file:
www stream tcp nowait root /sbin/tcpd /usr/local/etc/httpd

Please note the specification of Wietses Venema's tcpd ``wrapper'' program in the fifth column. A traditional Unix entry here would be the name of the daemon program itself. Running all the daemons from tcpd is a better approach.
Now, tcpd logs the client host name of incoming Telnet, Ftp, Rsh, Rlogin, Finger and related requests. Further security options available include: access control based on host, domain and/or service; detection of host name spoofing or host address spoofing; booby traps to implement an early-warning system.
More about ``Wrappers'' package can be found in Wietse's collection of tools and papers (http://www.trouble.org/security/ftp.win.tue.nl/).
The /etc/services file line -- which you shouldn't need to change -- looks like this:
www 80/tcp httpd # WWW

FTP

The line to add to /etc/inetd.conf is this:
ftp stream tcp nowait root /sbin/tcpd /usr/local/etc/ftpd

Where the final field value must be change d to point to where the FTP daemon is actually installed, in case you moved it from its original location.
The lines in /etc/services (again, they should already be there) looks like this:
ftp-data 20/tcp
ftp 21/tcp






Telnet

The line to add to /etc/inetd.conf appears:
telnet stream tcp nowait root /sbin/tcpd /sbin/in.telnetd

Where the final argument would need to point to the actual location of the Telnet daemon.
The line in /etc/services (which you should not have to change) looks like this:
telnet 23/tcp






Telling inetd about your changes

Remember to send the hangup (HUP) signal to inetd, to make it re-read the updated /etc/inetd.conf file. You can do this semi-automatically using the command line:
kill -HUP `ps ax|egrep '?.*inetd'|awk '{print $1}'`






Con clusion

This article has examined how some of the more popular Internet services that can be provided for a Linux system. It contains the information you need to get all three services up and running.





Author Biography

Paul Dunne is a writer and consultant who specializes in Linux. He has a home page (http://www.cix.co.uk/%7Edunnp) that describes in more detail what he does.





http://www.networkcomputing.com/unixworld/tutorial/013/013.part4.html