Linux NET-3-HOWTO, Linux Networking. Terry Dawson, VK2KTJ, terry@perf.no.itg.telstra.com.au v1.1, 29 March 1997 The Linux Operating System boasts kernel based networking support written almost entirely from scratch. The performance of the tcp/ip implementation in recent kernels makes it a worthy alternative to even the best of its peers. This document aims to describe how to install and configure the Linux networking software and associated tools. 1. Changes from the previous version Additions: ipip encap Corrections/Updates: removed duplicate of PLIP cabling diagram. minor cleanups. 2. Introduction. The original NET-FAQ was written by Matt Welsh and I to answer frequently asked questions about networking for Linux at a time before the Linux Documentation Project had formally started. It covered the very early development versions of the Linux Networking Kernel. The NET-2-HOWTO superceded the NET-FAQ and was one of the original LDP HOWTO documents, it covered what was called version 2 and later version 3 of the Linux kernel Networking software. This document in turn supercedes it and relates only to version 3 of the Linux Networking Kernel. Previous versions of this document became quite large because of the enormous amount of material that fell within its scope. To help reduce this problem a number of HOWTO's dealing with specific networking topics have been produced. This document will provide pointers to them where relevant and cover those areas not yet covered by other documents. 2.1. Feedback I always appreciate feedback and especially value contributions. Please direct any feedback or contributions to me by email . 3. How to use this HOWTO document (NET-3-HOWTO-HOWTO ?). The format of this document is differs from earlier versions. I've now regrouped the sections so that there is informative material at the beginning which you can skip if you are not interested, generic material next which you must ensure you understand before proceeding to the technology specific sections in the rest of the document. Read the generic sections These sections apply to every, or nearly every, technology described later and so are very important for you to understand. Consider your network You should know how your network is, or will be, designed and exactly what hardware and technology types you will be implementing. Read the technology specific sections related to your requirements When you know what you want you can address each component in turn. These sections cover only details specific to a particular technology. Do the configuration work You should actually try to configure your network and take careful note of any problems you have. Look for further help if needed If you experience problems that this document does not help you to resolve then read the section related to where to get help or where to report bugs. Have fun! Networking is fun, enjoy it. 4. General Information about Linux Networking. 4.1. A brief history of Linux Networking Kernel Development. Developing a brand new kernel implementation of the tcp/ip protocol stack that would perform as well as existing implementations was not an easy task. The decision not to port one of the existing implementations was made at a time when there was some uncertainty as to whether the existing implementations may become encumbered by restrictive copyrights because of the court case put by U.S.L., and when there was a lot of fresh enthusiasm for doing it differently and perhaps even better than had already been done. The original volunteer to lead development of the kernel network code was Ross Biro . Ross produced a simple and incomplete but mostly usable implementation set of routines that were complemented by an ethernet driver for the WD-8003 network interface card. This was enough to get many people testing and experimenting with the software and some people even managed to connect machines in this configuration to live internet connections. The pressure within the Linux community driving development for networking support was building and eventually the cost of a combination of some unfair pressure applied to Ross and his own personal commitments outweighed the benefit he was deriving and he stepped down as lead developer. Ross's efforts in getting the project started and accepting the responsibility for actually producing something useful in such controversial circumstances were what catalysed all future work and were therefore an essential component of the success of the current product. Orest Zborowski produced the original BSD socket programming interface for the Linux kernel. This was a big step forward as it allowed many of the existing network applications to be ported to linux without serious modification. Somewhere about this time Laurence Culhane developed the first drivers for Linux to support the SLIP protocol. These enabled many people who did not have access to Ethernet networking to experiment with the new networking software. Again, some people took this driver and pressed it into service to connect them to the Internet. This gave many more people a taste of the possibilities that could be realised if Linux had full networking support and grew the number of users actively using and experimenting with the networking software that existed. One of the people that had also been actively working on the task of building networking support was Fred van Kempen . After a period of some uncertainty following Ross's resignation from the lead developer position Fred offered his time and effort and accepted the role essentially unopposed. Fred had some ambitious plans for the direction that he wanted to take the Linux networking software and he set about progressing in those directions. Fred produced a series of networking code called the `NET-2' kernel code (the `NET' code being Ross's) which many people were able to use pretty much usefully. Fred formally put a number of innovations on the development agenda, such as the dynamic device interface, Amateur Radio AX.25 protocol support and a more modularly designed networking implementation. Fred's NET-2 code was used by a fairly large number of enthusiasts, the number increasing all the time as word spread that the software was working. The networking software at this time was still a large number of patches to the standard release of kernel code and was not included in the normal release. The NET-FAQ and subsequent NET-2-HOWTO's described the then fairly complex procedure to get it all working. Fred's focus was on developing innovations to the standard network implementations and this was taking time. The community of users was growing impatient for something that worked reliably and satisfied the 80% of users and, as with Ross, the pressure on Fred as lead developer rose. Alan Cox proposed a solution to the problem designed to resolve the situation. He proposed that he would take Fred's NET-2 code and debug it, making it reliable and stable so that it would satisfy the impatient user base while relieving that pressure from Fred allowing him to continue his work. Alan set about doing this, with some good success and his first version of Linux networking code was called `Net-2D(ebugged)'. The code worked reliably in many typical configurations and the user base was happy. Alan clearly had ideas and skills of his own to contribute to the project and many discussions relating to the direction the NET-2 code was heading ensued. There developed two distinct schools within the Linux networking community, one that had the philosophy of `make it work first, then make it better' and the other of `make it better first'. Linus ultimately arbitrated and offered his support to Alan's development efforts and included Alan's code in the standard kernel source distribution. This placed Fred in a difficult position. Any continued development would lack the large user base actively using and testing the code and this would mean progress would be slow and difficult. Fred continued to work for a short time and eventually stood down and Alan came to be the new leader of the Linux networking kernel development effort. Donald Becker soon revealed his talents in the low level aspects of networking and produced a huge range of ethernet drivers, nearly all of those included in the current kernels were developed by Donald. There have been other people that have made significant contributions, but Donald's work is prolific and so warrants special mention. Alan continued refining the NET-2-Debugged code for some time while working on progressing some of the matters that remained unaddressed on the `TODO' list. By the time the Linux 1.3.* kernel source had grown its teeth the kernel networking code had migrated to the NET-3 release on which current versions are based. Alan worked on many different aspects of the networking code and with the assistance of a range of other talented people from the Linux networking community grew the code in all sorts of directions. Alan produced dynamic network devices and the first standard AX.25 and IPX implementations. Alan has continued tinkering with the code, slowly restructuring and enhancing it to the state it is in today. PPP support was added by Michael Callahan and Al Longyear this too was critical to increasing the number of people actively using linux for networking. Jonathon Naylor has contributed by significantly enhancing Alan's AX.25 code, adding NetRom and Rose protocol support. The AX.25/NetRom/Rose support itself is quite significant, because no other operating system can boast standard native support for these protocols beside Linux. There have of course been hundreds of other people who have made significant contribution to the development of the Linux networking software. Some of these you will encounter later in the technology specific sections, other people have contributed modules, drivers, bug-fixes, suggestions, test reports and moral support. In all cases each can claim to have played a part and offered what they could. The Linux kernel networking code is an excellent example of the results that can be obtained from the Linux style of anarchic development, if it hasn't yet surprised you, it is bound to soon enough, the development hasn't stopped. 4.2. Where to get other information about Linux Networking. There are a number of places where you can find good information about Linux networking. Alan Cox, the current maintainer of the Linux kernel networking code maintains a world wide web page that contains highlights of current and new developments in linux Networking at: www.uk.linux.org . Another good place is a book written by Olaf Kirch entitled the Network Administrators Guide. It is a work of the Linux Documentatation Project and you can read it interactively at Network Administrators Guide HTML version or you can obtain it in various formats by ftp from the sunsite.unc.edu LDP ftp archive . Olaf's book is quite comprehensive and provides a good high level overview of network configuration under linux. There is a newsgroup in the Linux news heirarchy dedicated to networking and related matters, it is: comp.os.linux.networking There is a mailing list to which you can subscribe where you may ask questions relating to Linux networking. To subscribe you should send a mail message: To: majordomo@vger.rutgers.edu Subject: anything at all Message: subscribe linux-net On the various IRC networks there are often #linux channels on which people will be able to answer questions on linux networking. Please remember when reporting any problem to include as much relevant detail about the problem as you can. Specifically you should the versions of software that you are using, especially the kernel version, the version of tools such as pppd or dip, and the exact nature of the problem you are experiencing. This means taking note of the exact syntax of any error messages you receive, and of any commands that you are issuing. 4.3. Where to get some non-linux-specific network information. If you are after some basic tutorial information on tcp/ip networking generally, then I recommend you take a look at the following documents: tcp/ip introduction this document comes as both a text version and a postscript version . tcp/ip administration this document comes as both a text version and a postscript version . If you are after some more detailed information on tcp/ip networking then I highly recommend: "Internetworking with TCP/IP" by Douglas E. Comer ISBN 0-13-474321-0 Prentice Hall publications. If you are wanting to learn about how to write network applications in a Unix compatible environment then I also highly recommend: "Unix Network Programming" by W. Richard Stevens ISBN 0-13-949876-1 Prentice Hall publications. You might also try the comp.protocols.tcp-ip newsgroup. An important source of specific technical information relating to the Internet and the tcp/ip suite of protocols are RFC's. RFC is an acronym for `Request For Comment' and is the standard means of submitting and documenting Internet protocol standards. There are many RFC repositories. Many of these sites are ftp sites and other provide World Wide Web access with an associated search engine that allows you to search the RFC database for particular keywords. One possible source for RFC's is at: Nexor RFC database . 5. Generic Network Configuration Information. The following subsections you will pretty much need to know and understand before you actually try to configure your network. They are fundamental principles that apply regardless of the exact nature of the network you wish to deploy. 5.1. What do I need to start ? Before you start building or configuring your network you will need some things. The most important of these are: 5.1.1. Current Kernel source. Because the kernel you are running now might not yet have support for the network types or cards that you wish to use you will probably need the kernel source so that you can recompile the kernel with the appropriate options. You can always obtain the latest kernel source from: ftp.funet.fi . Normally the kernel source will be untarred into the /usr/src/linux directory. For information on how to apply patches and build the kernel you should read the Kernel-HOWTO . For information on how to configure kernel modules you should read the Module-HOWTO . Unless specifically stated otherwise, I recommend you stick with the standard kernel release (the one with the even number as the second digit in the version number). Development release kernels (the ones with the odd second digit) may have structural or other changes that may cause problems working with the other software on your system. If you are uncertain that you could resolve those sorts of problems in addition to the potential for there being other software errors, then don't use them. 5.1.2. Current Network tools. The network tools are the programs that you use to configure linux network devices. These tools allow you to assign addresses to devices and configure routes for example. Most modern linux distributions are supplied with the network tools, so if you have installed from a distribution and haven't yet installed the network tools then you should do so. If you haven't installed from a distribution then you will need to source and compile the tools yourself. This isn't difficult. The network tools are now maintained by Bernd Eckenfels and are available at: ftp.inka.de and are mirrored at: ftp.uk.linux.org . Be sure to choose the version that is most appopriate for the kernel you wish to use and follow the instructions in the package to install. To install and configure the version current at the time of the writing you need do the following: # # cd /usr/src # tar xvfz net-tools-1.32-alpha.tar.gz # cd net-tools-1.32-alpha # make config # make # make install # Additionally, if you intend configuring a firewall or using the IP masquerade feature you will require the ipfwadm command. The latest version of it may be obtained from: ftp.xos.nl . Again there are a number of versions available. Be sure to pick the version that most closely matches your kernel. To install and configure the version current at the time of the writing you need do the following: # # cd /usr/src # tar xvfz ipfwadm-2.3.0.tar.gz # cd ipfwadm-2.3.0 # make # make install # 5.1.3. Network Application Programs. The network application programs are programs such as telnet and ftp and their respective server programs. David Holland now manages a distribution of the most common of these. You may obtain it from: ftp.uk.linux.org . To install and configure the version current at the time of the writing you need do the following: # # cd /usr/src # tar xvfz /pub/net/NetKit-B-0.08.tar.gz # cd NetKit-B-0.08 # more README # vi MCONFIG # make # make install # 5.1.4. Addresses. Internet Protocol Addresses are composed of four bytes. The convention is to write addresses in what is called `dotted decimal notation'. In this form each byte is converted to a decimal number (0-255) dropping any leading zero's unless the number is zero, and written with each byte seperated by a `.' character. By convention each interface of a host or router has an IP address. It is legal for the same IP address to be used on each port of a single machine in some circumstances but usually each interface will have its own address. Internet Protocol Networks are contiguous sequences of IP addresses. All addresses within a network have a number of digits within the address in common. The portion of the address that is common amongst all addresses within the network is called the `network portion' of the address. The remaining digits are called the `host portion'. The number of bits that are shared by all addresses within a network is called the netmask and it is role of the netmask to determine which addresses belong to the network it is applied to and which don't. For example, consider the following: ----------------- --------------- Host Address 192.168.110.23 Network Mask 255.255.255.0 Network Portion 192.168.110. Host portion .23 ----------------- --------------- Network Address 192.168.110.0 Broadcast Address 192.168.110.255 ----------------- --------------- Any address that is 'bitwise anded' with its netmask will reveal the address of the network it belongs to. The network address is therefore always the lowest numbered address within the range of addresses on the network, and always has the host portion of the address coded all zeroes. The broadcast address is a special address that every host on the network listens to in addition to its own unique address. This address is the one thhat datagrams are sent to if every host on the network is meant to receive it. Certain types of data like routing information and warning messages are transmitted to the broadcast address so that every host on the network can receive it simultaneously. There are two commonly used standards for what the broadcast address should be. The most widely accepted one is to use the highest possible address on the network as the broadcast address. In the example above this would be 192.168.110.255. For some reason other sites have adopted the convention of using the network address as the broadcast address. In practice it doesn't matter very much which you use but you must make sure that every host on the network is configured with the same broadcast address. For administrative reasons some time early in the development of the IP protocol some arbitrary groups of addresses were formed into networks and these networks were grouped into what are called classes. These classes provide a number of standard size networks that could be allocated. The ranges allocated are: ---------------------------------------------------------- | Network | Netmask | Network Addresses | | Class | | | ---------------------------------------------------------- | A | 255.0.0.0 | 0.0.0.0 - 127.255.255.255 | | B | 255.255.0.0 | 128.0.0.0 - 191.255.255.255 | | C | 255.255.255.0 | 192.0.0.0 - 223.255.255.255 | |Multicast| 240.0.0.0 | 224.0.0.0 - 239.255.255.255 | ---------------------------------------------------------- What addresses you should use depends on exactly what it is that you are doing. You may have to use a combination of the following activities to get all the addresses you need: Installing a linux machine on an existing IP network If you wish to install a linux machine onto an existing IP network then you should contact whoever administers the network and ask them for the following information: · Host IP Address · IP network address · IP broadcast address · IP netmask · Router address · Domain Name Server Address You should then configure your linux network device with those details. You can not make them up and expect your configuration to work. Building a brand new network that will never connect to the Inter­ net If you are building a private network and you never intend that network to be connected to the Internet then you can choose whatever addresses you like. However, for safety and consistency reasons there have been some IP network addresses that have been reserved specifically for this purpose. These are specified in RFC1597 and are as follows: ----------------------------------------------------------- | RESERVED PRIVATE NETWORK ALLOCATIONS | ----------------------------------------------------------- | Network | Netmask | Network Addresses | | Class | | | ----------------------------------------------------------- | A | 255.0.0.0 | 10.0.0.0 - 10.255.255.255 | | B | 255.255.0.0 | 172.16.0.0 - 172.31.255.255 | | C | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 | ----------------------------------------------------------- You should first decide how large you want your network to be and then choose as many of the addresses as you require. 5.2. Where should I put the configuration commands ? There are a few different approaches to Linux system boot procedures. After the kernel boots, it always executes a program called `init'. The init program then reads its configuration file called /etc/inittab and commences the boot process. There are a few different flavours of init and it is this variation that is the largest cause of variation between distributions or machines. Usually the /etc/inittab file contains an entry looking something like: si::sysinit:/etc/init.d/boot This line specifies the name of the shell script file that actually manages the boot sequence. This file is somewhat equivalent to the AUTOEXEC.BAT file in MS-DOS. There are usually other scripts that are called by the boot script, and often the network is configured within one of many of these. The following table may be used as a guide for your system: ------------------------------------------------------------------------------- Distrib. |Interface Config/Routing |Server Initialisation ------------------------------------------------------------------------------- Debian |/etc/init.d/network |/etc/init.d/netbase | |/etc/init.d/netstd_init | |/etc/init.d/netstd_nfs | |/etc/init.d/netstd_misc ------------------------------------------------------------------------------- Slackware|/etc/rc.d/rc.inet1 |/etc/rc.d/rc.inet2 ------------------------------------------------------------------------------- RedHat |/etc/sysconfig/network-scripts/ifup-|/etc/rc.d/init.d/network ------------------------------------------------------------------------------- Most modern distributions include a program that will allow you to configure many of the common sorts of network interfaces. If you have one of these then you should see if it will do what you want before attempting a manual configuration. ----------------------------------------- Distrib | Network configuration program ----------------------------------------- RedHat | /sbin/netcfg Slackware | /sbin/netconfig ----------------------------------------- 5.3. Creating your network interfaces. In many Unix operating systems the network devices have appearances in the /dev directory. This is not so in Linux. In Linux the network devices are created dynamically in software and thus do not require device files to be present. In the majority of cases the network devices is automatically created by the device driver while it is initialising and has located your hardware. For example, the ethernet device driver creates eth[0..n] interfaces sequentially as it locates your ethernet hardware. The first ethernet card found becomes eth0, the second eth1 etc. In some cases though, notably slip and ppp, the network devices are created through the action of some user program. The same sequential device numbering applies, but the devices are not created automatically at boot time. The reason for this is that unlike ethernet devices, the number of active slip or ppp devices may vary during the uptime of the machine. These cases will be covered in more detail in later sections. 5.4. Configuring a network interface. When you have all of the programs you need and your address and network information you can configure your network interfaces. When we talk about configuring a network interface we are talking about the process of assigning appropriate addresses to a network device, and to setting appropriate values for other configurable paramaters of a network device. The program most commonly used to do this is the ifconfig (interface configure) command. Typically you would use a command similar to the following: # ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up In this case I'm configuring an ethernet interface `eth0' with the IP address `192.168.0.1' and a network mask of `255.255.255.0'. The `up' that trails the command tells the interface that it should become active. The kernel assumes certain defaults when configuring interfaces. For example, you may specify the network address and broadcast address for an interface, bit if you don't, as in my example above, then the kernel will make reasonable guesses as to what they should be based on the class of the IP address configured. In my example the kernel would assume that it is a class-C network being configured on the interface and configure a network address of `192.168.0.0' and a broadcast address of `192.168.0.255' for the interface. There are many other options to the ifconfig command. The most important of these are: up this option activates an interface. down this option deactivates an interface. -arp this option enables or disables use of the address resolution protocol on this interface -allmulti this option enables or disables the use of promiscuous mode on this interface. Promiscuous mode is where a device can be commanded to accept packets even if they are not destined for this device. This is very important for programs like tcpdump and other packet snoopers. mtu N this parameter allows you to set the MTU of this device. netmask addr this parameter allows you to set the network mask of the network this device belongs to. irq addr this parameter only works on certain types of hardware, but allows you to set the IRQ of the hardware of this device. -broadcast addr this parameter allows you to enable and set the accepting of datagrams destined to the broadcast address, or to disable reception of these datagrams. -pointopoint addr this parameters allows you to set the address of the machine at the remote end of a point to point link such as for slip or ppp. hw this parameter allows you to set the hardware address of certain types of network devices. This is not often useful for ethernet, but is useful for other network types such as AX.25. You may use the ifconfig command on any network interface. Some user programs such as pppd and dip automatically configure the network devices as they create them, so manual use of ifconfig is unnecessary. 5.5. Configuring your Name Resolver. The `Name Resolver' is a part of the linux standard library. Its prime function is to provide a service to convert human-friendly hostnames like `ftp.funet.fi' into machine friendly IP addresses such as 128.214.248.6. 5.5.1. What's in a name ? You will probably be familiar with the appearance of Internet host names, but may not understand how they are constructed, or deconstructed. Internet domain names are heirarchial in nature, that is, they have a tree-like structure. A `domain' is a family, or group of names. A `domain' may be broken down into `subdomain'. A `toplevel domain' is a domain that is not a subdomain. The Top Level Domains are specified in RFC-920. Some examples of the most common top level domains are: COM Commercial Organisations EDU Educational Organisations GOV Government Organisations MIL Millitary Organisations ORG Other organisations Country Designator these are two letters codes that represent a particular country. Each of these top level domains has subdomains. The top level domains based on country name are used next broken down into subdomains based on the com, edu, gov, mil and org domains. So for example you end up with: com.au and gov.au for commercial and government organisations in Australia. For historical reasons most domains belonging to one of the non-country based top level domains are for organisations within the United States, although the United States also has its own country code `.us'. The next level of division usually represents the name of the organisation. Further subdomains vary in nature, often the next level of subdomain is based on the departmental structure of the organisation but it may be based on any criterion considered reasonable and meaningful by the network adminstrators for the organisation. The very left most portion of the name is always the unique name assigned to the host machine and is called the `hostname', the portion of the name to the right of the hostname is called the `domainname' and the complete name is called the `Fully Qualified Domain Name'. To use my own email host as an example, the fully qualified domain name is `perf.no.itg.telstra.com.au'. This means that the host name is `perf' and the domain name is `no.itg.telstra.com.au'. The domain name is based on a top level domain based on my country, Australia and as my email address belongs to a commercial organisation we have `.com' as the next level domain. The name of the company is (was) `telstra' and our internal naming structure is based on organisational structure, in my case, my machine belongs to the Information Technology Group, Network Operations section. 5.5.2. What information you will need. You will need to know what domain your hosts name will belong to. The name resolver software provides this name translation service by making requests to a `Domain Name Server', so you will need to know the IP address of a local nameserver that you can use. There are three files you need to edit, I'll cover each of these in turn. 5.5.3. /etc/resolv.conf The /etc/resolv.conf is the main configuration file for the name resolver code. Its format is quite simple. It is a text file with one keyword per line. There are three keywords typically used, they are: domain this keyword specifies the local domain name. search this keyword specifies a list of alternate domain names to search for a hostname nameserver this keyword, which may be used many times, specifies an IP address of a domain name server to query when resolving names An example /etc/resolv.conf might look something like: domain maths.wu.edu.au search maths.wu.edu.au wu.edu.au nameserver 192.168.10.1 nameserver 192.168.12.1 This example specifies that the default domain name to append to unqualified names (ie hostnames supplied without a domain) is maths.wu.edu.au, and that if the host is not found in that domain to also try the wu.edu.au domain directly. Two nameservers entry are sup­ plied, each of which may be called upon by the name resolver code to resolve the name. 5.5.4. /etc/host.conf The /etc/host.conf file is where you configure some items that govern the behavious of the name resolver code. The format of this file is described in detail in the `resolv+' man page. In nearly all circumstances the following example will work for you: order hosts,bind multi on This configuration tells the name resolver to check the /etc/hosts file before attempting to query a nameserver and to return all valid addresses for a host found in the /etc/hosts file instead of just the first. 5.5.5. /etc/hosts The /etc/hosts file is where you put the name and IP address of local hosts. If you place a host in this file then you do not need to query the domain name server to get its IP Address. The disadvantage of doing this is that you must keep this file up to date yourself if the IP address for that host changes. In a well managed system the only hostnames that usually appear in this file are an entry for the loopback interface, and the local hosts name. # /etc/hosts 127.0.0.1 localhost loopback 192.168.0.1 this.host.name You may specify more than one host name per line as demonstrated by the first entry, which is a standard entry for the loopback interface. 5.6. Configuring your loopback interface. The `loopback' interface is a special type of interface that allows you to make connections to yourself. There are various reasons why you might want to do this, for example, you may wish to test some network software without interfering with anybody else on your network. By convention the IP address `127.0.0.1' has been assigned specifically for loopback. So no matter what machine you go to, if you open a telnet connection to 127.0.0.1 you will always reach the local host. Configuring the loopback interface is simple and you should ensure you do. # ifconfig lo 127.0.0.1 # route add -host 127.0.0.1 lo We'll talk more about the route command in the next section. 5.7. Routing. Routing is a big topic. It is easily possible to write large volumes of text about it. Most of you will have fairly simple routing requirements, some of you will not. I will cover some basic fundamentals of routing only. If you are interested in more detailed information then I suggest you refer to the references provided at the start of the document. Let's start with a definition. What is IP routing ? Here is one that I'm using: IP Routing is the process by which a host with multiple net­ work connections decides where to deliver IP datagrams it has received. It might be useful to illustrate this with an example. Imagine a typical office router, it might have a PPP link off the the Internet, a number of ethernet segments feeding the workstations and another PPP link off to another office. When the router receives a datagram on any of its network connections, routing is the mechanism that it uses to determine which port it should send the datagram to next. Simple hosts also need to route, all Internet hosts have two network devices, one is the loopback interface described above and the other is the one it uses to talk to the rest of the network, perhaps an ethernet, perhaps a PPP or SLIP serial port. Ok, so how does routing work ? Each host keeps a special list of routing rules, called a routing table. This table contains rows which typically contain at least at least three fields, the first is a destination address, the second is the name of the interface to which the datagram is to be routed and the third is optionally the IP address of another machine which will carry the datagram on its next step through the network. In linux you can see this table by using the following command: # cat /proc/net/route The routing process is fairly simple: an incoming datagram is received, the destination address (who it is for) is examined and com­ pared with each entry in the table. The entry that best matches that address is selected and the datagram is forwarded to the specified interface. If the gateway field is filled then the datagram is for­ warded to that host via the specified interface, otherwise the desti­ nation address is assumed to be on the network supported by the inter­ face. To manipulate this table a special command is used. This command takes command line arguments and converts them into kernel system calls that request the kernel to add, delete or modify entries in the routing table. The command is called `route'. A simple example. Imagine you have an ethernet network. You've been told it is a class-C network with an address of 192.168.1.0. You've been supplied with an IP address of 192.168.1.10 for your use and have been told that 192.168.1.1 is a router connected to the Internet. The first step is to configure the interface as described earlier. You would use a command like: # ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up You now need to add an entry into the routing table to tell the kernel that datagrams for all hosts with addresses that match 192.168.1.* should be sent to the ethernet device. You would use a command similar to: # route add -net 192.168.0.0 netmask 255.255.255.0 eth0 Note the use of the `-net' argument to tell the route program that this entry is a network route. Your other choice here is a `host' route which is a route that is specific to one IP address. This route will enable you to establish IP connections with all of the hosts on your ethernet segment. But what about all of the IP hosts that aren't on your ethernet segment ? It would be a very difficult job to have to add routes to every possible destination network, so there is a special trick that is used to simplify this task. The trick is called the `default' route. The default route matches every possible destination, but poorly, so that if any other entry exists that matches the required address it will be used instead of the default route. The idea of the default route is simply to enable you to say "and everything else should go here". In the example I've contrived you would use an entry like: # route add default gw 192.168.1.1 eth0 The `gw' argument tells the route command that the next argument is the IP address, or name, of a gateway or router machine which all datagrams matching this entry should be directed to for further rout­ ing. So, your complete configuration would look like: # ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up # route add -net 192.168.0.0 netmask 255.255.255.0 eth0 # route add default gw 192.168.1.1 eth0 If you take a close look at your network `rc' files you will find that at least one of them looks very similar to this. This is a very common configuration. Let's now look at a slightly more complicated routing configuration. Let's imagine we are configuring the router we looked at earlier, the one supporting the PPP link to the Internet and the lan segments feeding the workstations in the office. Lets imagine the router has three ethernet segments and one PPP link. Our routing configuration would look something like: # route add 192.168.1.0 netmask 255.255.255.0 eth0 # route add 192.168.2.0 netmask 255.255.255.0 eth1 # route add 192.168.3.0 netmask 255.255.255.0 eth2 # route add default ppp0 Each of the workstations would use the simpler form presented above, only the router needs to specify each of the network routes seperately because for the workstations the default route mechanism will capture all of them letting the router worry about splitting them up appropri­ ately. You may be wondering why the default route presented doesn't specify a `gw'. The reason for this is simple, serial link protocols such as PPP and slip only ever have two hosts on their network, one at each end. To specify the host at the other end of the link as the gateway is pointless and redundant as there is no other choice, so you do not need to specify a gateway for these types of network connec­ tions. Other network types such as ethernet, arcnet or token ring do require the gateway to be specified as these networks support large numbers of hosts on them. 5.7.1. So what does the routed program do ? The routing configuration described above is best suited to simple network arrangements where there only ever single possible paths to destinations. When you have a more complex network arrangement things get a little more complicated. Fortunately for most of you this won't be an issue. The big problem with `manual routing' or `static routing' as described, is that if a machine or link fails in your network then the only way you can direct your datagrams another way, if another way exists, is by manually intervening and executing the appopriate commands. Naturally this is clumsy, slow, impractical and hazard prone. Various techniques have been developed to automatically adjust routing tables in the event of network failures where there are alternate routes, all of these techniques are loosely grouped by the term `dynamic routing protocols'. You may have heard of some of the more common dynamic routing protocols. The most common are probably RIP (Routing Information Protocol) and OSPF (Open Shortest Path First Protocol). The Routing Information Protocol is very common on small networks such as small- medium sized corporate networks or building networks. OSPF is more modern and more capable at handling large network configurations and better suited to environments where there is a large number of possible paths through the network. Common implementations of these protocols are: `routed' - RIP, and `gated' - RIP, OSPF and others. The `routed' program is normally supplied with your Linux distribution or is included in the `NetKit' package detailed above. An example of where and how you might use a dynamic routing protocol might look something like the following: 192.168.1.0 / 192.168.2.0 / 255.255.255.0 255.255.255.0 - - | | | /-----\ /-----\ | | | |ppp0 // ppp0| | | eth0 |---| A |------//---------| B |---| eth0 | | | // | | | | \-----/ \-----/ | | \ ppp1 ppp1 / | - \ / - \ / \ / \ / \ / \ / \ / \ / \ / ppp0\ /ppp1 /-----\ | | | C | | | \-----/ |eth0 | |---------| 192.168.3.0 / 255.255.255.0 We have three routers A, B and C. Each supports one ethernet segment with a Class C IP network (netmask 255.255.255.0). Each router also has a PPP link to each of the other routers. The network forms a tri­ angle. It should be clear that the routing table at router A could look like: # route add -net 192.168.1.0 netmask 255.255.255.0 eth0 # route add -net 192.168.2.0 netmask 255.255.255.0 ppp0 # route add -net 192.168.3.0 netmask 255.255.255.0 ppp1 This would work just fine until the link between router A and B should fail. If that link failed then with the routing entry shown above hosts on the ethernet segment of A could not reach hosts on the ether­ net segment on B because their datagram would be directed to router A's ppp0 link which is broken. They could still continue to talk to hosts on the ethernet segment of C, and hosts on the C's ethernet seg­ ment could still talk to hosts on B's ethernet segment because the link between B and C is still intact. But wait, if A can talk to C, and C can still talk to B, why shouldn't A route its datagrams for B via C and let C send them to B ? This is exactly the sort of problem that dynamic routing protocols like RIP were designed to solve. If each of the routers A, B and C were running a routing daemon then their routing tables would be automatically adjusted to reflect the new state of the network should any one of the links in the network fail. To configure such a network is simple, at each router you need only do two things. In this case for Router A: # route add -net 192.168.1.0 netmask 255.255.255.0 eth0 # /usr/sbin/routed The `routed' routing daemon automatically finds all active network ports when it starts and sends and listens for messages on each of the network devices to allow it to determine and update the routing table on the host. This has been a very brief explanation of dynamic routing and where you would use it. If you want more information then you should refer to the suggested references listed at the top of the document. The important points relating to dynamic routing are: 1. You only need to run a dynamic routing protocol daemon when your Linux machine has the possibility of selecting multiple possible routes to a destination. 2. The dynamic routing daemon will automatically modify your routing table to adjust to changes in your network. 3. RIP is suited to small to medium sized networks. 5.8. Configuring your network servers and services. Network servers and services are those programs that allow a remote user to make user of your Linux machine. The remote user establishes a network connection to your machine and the server program, or network daemon, listening on that port accepts the connection and executes. There are two ways that network daemons may operate. Both are commonly employed in practice. The two ways are: standalone the network daemon program listens on the designated network port and when an incoming connection is made it manages the network connection itself to provide the service. slave to the inetd server the inetd server is a special network daemon program that specialises in managing incoming network connections. It has a configuration file which tells it what program needs to be run when an incoming connection is received on a particular combination of tcp or udp and service port. The ports are described in another file that we will talk about soon. There are two important files that we need to configure. They are the /etc/services file which assigns names to port numbers and the /etc/inetd.conf file which is the configuration file for the inetd network daemon. 5.8.1. /etc/services The /etc/services file is a simple database that associates a human friendly name to a machine friendly service port. Its format is quite simple. The file is a text file with each line representing and entry in the database. Each entry is comprised of three fields seperated by any number of whitespace (tab or space) characters. The fields are: name port/protocol aliases # comment name a single word name that represents the service being described. port/protocol this field is split into two subfields. port a number that specifies the port number the named service will be available on. Most of the common services have assigned service numbers. These are described in RFC-1340. protocol this subfield may be set to either tcp or udp. It is important to note that an entry of 18/tcp is very differ­ ent from an entry of 18/udp and that there is no technical rea­ son why the same service needs to exist on both. Normally common sense prevails and it is only if a particular service is avail­ able via both tcp and udp that you will see an entry for both. aliases other names that may be used to refer to this service entry. Any text appearing in a line after a `#' character is ignored and treated as a comment. 5.8.1.1. An example /etc/services file. All modern linux distributions provide a good /etc/services file. Just in case you happen to be building a machine from the ground up, here is a copy of the /etc/services file supplied with the Debian distribution. # /etc/services: # $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $ # # Network services, Internet style # # Note that it is presently the policy of IANA to assign a single well-known # port number for both TCP and UDP; hence, most entries here have two entries # even if the protocol doesn't support UDP operations. # Updated from RFC 1340, ``Assigned Numbers'' (July 1992). Not all ports # are included, only the more common ones. tcpmux 1/tcp # TCP port service multiplexer echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null systat 11/tcp users daytime 13/tcp daytime 13/udp netstat 15/tcp qotd 17/tcp quote msp 18/tcp # message send protocol msp 18/udp # message send protocol chargen 19/tcp ttytst source chargen 19/udp ttytst source ftp-data 20/tcp ftp 21/tcp ssh 22/tcp # SSH Remote Login Protocol ssh 22/udp # SSH Remote Login Protocol telnet 23/tcp # 24 - private smtp 25/tcp mail # 26 - unassigned time 37/tcp timserver time 37/udp timserver rlp 39/udp resource # resource location nameserver 42/tcp name # IEN 116 whois 43/tcp nicname re-mail-ck 50/tcp # Remote Mail Checking Protocol re-mail-ck 50/udp # Remote Mail Checking Protocol domain 53/tcp nameserver # name-domain server domain 53/udp nameserver mtp 57/tcp # deprecated bootps 67/tcp # BOOTP server bootps 67/udp bootpc 68/tcp # BOOTP client bootpc 68/udp tftp 69/udp gopher 70/tcp # Internet Gopher gopher 70/udp rje 77/tcp netrjs finger 79/tcp www 80/tcp http # WorldWideWeb HTTP www 80/udp # HyperText Transfer Protocol link 87/tcp ttylink kerberos 88/tcp kerberos5 krb5 # Kerberos v5 kerberos 88/udp kerberos5 krb5 # Kerberos v5 supdup 95/tcp # 100 - reserved hostnames 101/tcp hostname # usually from sri-nic iso-tsap 102/tcp tsap # part of ISODE. csnet-ns 105/tcp cso-ns # also used by CSO name server csnet-ns 105/udp cso-ns rtelnet 107/tcp # Remote Telnet rtelnet 107/udp pop-2 109/tcp postoffice # POP version 2 pop-2 109/udp pop-3 110/tcp # POP version 3 pop-3 110/udp sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP auth 113/tcp authentication tap ident sftp 115/tcp uucp-path 117/tcp nntp 119/tcp readnews untp # USENET News Transfer Protocol ntp 123/tcp ntp 123/udp # Network Time Protocol netbios-ns 137/tcp # NETBIOS Name Service netbios-ns 137/udp netbios-dgm 138/tcp # NETBIOS Datagram Service netbios-dgm 138/udp netbios-ssn 139/tcp # NETBIOS session service netbios-ssn 139/udp imap2 143/tcp # Interim Mail Access Proto v2 imap2 143/udp snmp 161/udp # Simple Net Mgmt Proto snmp-trap 162/udp snmptrap # Traps for SNMP cmip-man 163/tcp # ISO mgmt over IP (CMOT) cmip-man 163/udp cmip-agent 164/tcp cmip-agent 164/udp xdmcp 177/tcp # X Display Mgr. Control Proto xdmcp 177/udp nextstep 178/tcp NeXTStep NextStep # NeXTStep window nextstep 178/udp NeXTStep NextStep # server bgp 179/tcp # Border Gateway Proto. bgp 179/udp prospero 191/tcp # Cliff Neuman's Prospero prospero 191/udp irc 194/tcp # Internet Relay Chat irc 194/udp smux 199/tcp # SNMP Unix Multiplexer smux 199/udp at-rtmp 201/tcp # AppleTalk routing at-rtmp 201/udp at-nbp 202/tcp # AppleTalk name binding at-nbp 202/udp at-echo 204/tcp # AppleTalk echo at-echo 204/udp at-zis 206/tcp # AppleTalk zone information at-zis 206/udp z3950 210/tcp wais # NISO Z39.50 database z3950 210/udp wais ipx 213/tcp # IPX ipx 213/udp imap3 220/tcp # Interactive Mail Access imap3 220/udp # Protocol v3 ulistserv 372/tcp # UNIX Listserv ulistserv 372/udp # # UNIX specific services # exec 512/tcp biff 512/udp comsat login 513/tcp who 513/udp whod shell 514/tcp cmd # no passwords used syslog 514/udp printer 515/tcp spooler # line printer spooler talk 517/udp ntalk 518/udp route 520/udp router routed # RIP timed 525/udp timeserver tempo 526/tcp newdate courier 530/tcp rpc conference 531/tcp chat netnews 532/tcp readnews netwall 533/udp # -for emergency broadcasts uucp 540/tcp uucpd # uucp daemon remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem klogin 543/tcp # Kerberized `rlogin' (v5) kshell 544/tcp krcmd # Kerberized `rsh' (v5) kerberos-adm 749/tcp # Kerberos `kadmin' (v5) # webster 765/tcp # Network dictionary webster 765/udp # # From ``Assigned Numbers'': # #> The Registered Ports are not controlled by the IANA and on most systems #> can be used by ordinary user processes or programs executed by ordinary #> users. # #> Ports are used in the TCP [45,106] to name the ends of logical #> connections which carry long term conversations. For the purpose of #> providing services to unknown callers, a service contact port is #> defined. This list specifies the port used by the server process as its #> contact port. While the IANA can not control uses of these ports it #> does register or list uses of these ports as a convienence to the #> community. # ingreslock 1524/tcp ingreslock 1524/udp prospero-np 1525/tcp # Prospero non-privileged prospero-np 1525/udp rfe 5002/tcp # Radio Free Ethernet rfe 5002/udp # Actually uses UDP only bbs 7000/tcp # BBS service # # # Kerberos (Project Athena/MIT) services # Note that these are for Kerberos v4, and are unofficial. Sites running # v4 should uncomment these and comment out the v5 entries above. # kerberos4 750/udp kdc # Kerberos (server) udp kerberos4 750/tcp kdc # Kerberos (server) tcp kerberos_master 751/udp # Kerberos authentication kerberos_master 751/tcp # Kerberos authentication passwd_server 752/udp # Kerberos passwd server krb_prop 754/tcp # Kerberos slave propagation krbupdate 760/tcp kreg # Kerberos registration kpasswd 761/tcp kpwd # Kerberos "passwd" kpop 1109/tcp # Pop with Kerberos knetd 2053/tcp # Kerberos de-multiplexor zephyr-srv 2102/udp # Zephyr server zephyr-clt 2103/udp # Zephyr serv-hm connection zephyr-hm 2104/udp # Zephyr hostmanager eklogin 2105/tcp # Kerberos encrypted rlogin # # Unofficial but necessary (for NetBSD) services # supfilesrv 871/tcp # SUP server supfiledbg 1127/tcp # SUP debugging # # Datagram Delivery Protocol services # rtmp 1/ddp # Routing Table Maintenance Protocol nbp 2/ddp # Name Binding Protocol echo 4/ddp # AppleTalk Echo Protocol zip 6/ddp # Zone Information Protocol # # Debian GNU/Linux services rmtcfg 1236/tcp # Gracilis Packeten remote config server xtel 1313/tcp # french minitel cfinger 2003/tcp # GNU Finger postgres 4321/tcp # POSTGRES mandelspawn 9359/udp mandelbrot # network mandelbrot # Local services 5.8.2. /etc/inetd.conf The /etc/inetd.conf file is the configuration file for the inetd server daemon. Its function is to tell inetd what to do when it receives a connection request for a particular service. For each service that you wish to accept connections for you must tell inetd what network server daemon to run, and how to run it. Its format is also fairly simple. It is a text file with each line describing a service that you wish to provide. Any text in a line following a `#' is ignored and considered a comment. Each line contains seven fields seperated by any number of whitespace (tab or space) characters. The general format is as follows: service socket_type proto flags user server_path server_args service is the service relevant to this configuration as taken from the /etc/services file. socket_type this field describes the type of socket that this entry will consider relevant, allowable values are: stream, dgram, raw, rdm, or seqpacket. This is a little technical in nature, but as a rule of thumb nearly all tcp based services use stream and nearly all udp based services use dgram. It is only very special types of server daemons that would use any of the other values. proto the protocol to considered valid for this entry. This should match the appropriate entry in the /etc/services file and will typically be either tcp or udp. Sun RPC (Remote Procedure Call) based servers will use rpc/tcp or rpc/udp. flags there are really only two possible settings for this field. This field setting tells inetd whether the network server program frees the socket after it has been started, and therefore whether inetd can start another one on the next connection request, or whether inetd should wait and assume that any server daemon already running will handle the new connection request. Again this is a little tricky to work out, but as a rule of thumb all tcp servers should have this entry set to nowait and most udp servers should have this entry set to wait. Be warned there are some notable exceptions to this, so let the example guide you if you are not sure. user this field describes which user account from /etc/passwd will be set as the owner of the network daemon when it is started. This is often useful if you want to safeguard against security risks. You can set the user of an entry to the nobody user so that if the network server security is breached the possible damage is minimised. Typically this field is set to root though, because many servers require root priveledges in order to function correctly. server_path this field is pathname to the actual server program to execute for this entry. server_args this field comprises the rest of the line and is optional. This field is where you place any command line arguments that you wish to pass to the server daemon program when it is launched. 5.8.2.1. An example /etc/inetd.conf As for the /etc/services file all modern distributions will include a good /etc/inetd.conf file for you to work with. Here, for completeness is the /etc/inetd.conf file from the Debian distribution. # /etc/inetd.conf: see inetd(8) for further informations. # # Internet server configuration database # # # Modified for Debian by Peter Tobias # # # # Internal services # #echo stream tcp nowait root internal #echo dgram udp wait root internal discard stream tcp nowait root internal discard dgram udp wait root internal daytime stream tcp nowait root internal daytime dgram udp wait root internal #chargen stream tcp nowait root internal #chargen dgram udp wait root internal time stream tcp nowait root internal time dgram udp wait root internal # # These are standard services. # telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd #fsp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.fspd # # Shell, login, exec and talk are BSD protocols. # shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind #exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd talk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.talkd ntalk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.ntalkd # # Mail, news and uucp services. # smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.smtpd #nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/in.nntpd #uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico #comsat dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.comsat # # Pop et al # #pop-2 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop2d #pop-3 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop3d # # `cfinger' is for the GNU finger server available for Debian. (NOTE: The # current implementation of the `finger' daemon allows it to be run as `root'.) # #cfinger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.cfingerd #finger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.fingerd #netstat stream tcp nowait nobody /usr/sbin/tcpd /bin/netstat #systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx # # Tftp service is provided primarily for booting. Most sites # run this only on machines acting as "boot servers." # #tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd #tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /boot #bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120 # # Kerberos authenticated services (these probably need to be corrected) # #klogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k #eklogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k -x #kshell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd -k # # Services run ONLY on the Kerberos server (these probably need to be corrected) # #krbupdate stream tcp nowait root /usr/sbin/tcpd /usr/sbin/registerd #kpasswd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/kpasswdd # # RPC based services # #mountd/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.mountd #rstatd/1-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rstatd #rusersd/2-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rusersd #walld/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rwalld # # End of inetd.conf. ident stream tcp nowait nobody /usr/sbin/identd identd -i 5.9. Other miscellaneous network related configuration files. There are a number of miscellaneous files relating to network configuration under linux that you might be interested in. You may never have to modify these files, but it is worth describing them so you know what they contain and what they are for. 5.9.1. /etc/protocols The /etc/protocols file is a database that maps protocol id numbers against protocol names. This is used by programmers to allow them to specify protocols by name in their programs and also by some programs such as tcpdump to allow them to display names instead of numbers in their output. The general syntax of the file is: protocolname number aliases The /etc/protocols file supplied with the Debian distribution is as follows: # /etc/protocols: # $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $ # # Internet (IP) protocols # # from: @(#)protocols 5.1 (Berkeley) 4/17/89 # # Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992). ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol igmp 2 IGMP # Internet Group Management ggp 3 GGP # gateway-gateway protocol ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'') st 5 ST # ST datagram mode tcp 6 TCP # transmission control protocol egp 8 EGP # exterior gateway protocol pup 12 PUP # PARC universal packet protocol udp 17 UDP # user datagram protocol hmp 20 HMP # host monitoring protocol xns-idp 22 XNS-IDP # Xerox NS IDP rdp 27 RDP # "reliable datagram" protocol iso-tp4 29 ISO-TP4 # ISO Transport Protocol class 4 xtp 36 XTP # Xpress Tranfer Protocol ddp 37 DDP # Datagram Delivery Protocol idpr-cmtp 39 IDPR-CMTP # IDPR Control Message Transport rspf 73 RSPF # Radio Shortest Path First. vmtp 81 VMTP # Versatile Message Transport ospf 89 OSPFIGP # Open Shortest Path First IGP ipip 94 IPIP # Yet Another IP encapsulation encap 98 ENCAP # Yet Another IP encapsulation 5.9.2. /etc/networks The /etc/networks file has a similar function to that of the /etc/hosts file. It provides a simple database of network names against network addresses. Its format differs in that there may be only two fields per line, and that the fields are coded as: # networkname networkaddress An example might look like: loopnet 127.0.0.0 localnet 192.168.0.0 amprnet 44.0.0.0 When you use commands like the route command, if a destination is a network, and that network has an entry in the /etc/networks file then the route command will display that network name instead of its address. 5.10. Network Security and access control. Let me start this section by warning you that securing your machine and and network against malicious attack is a complex art. I do not consider myself an expert in this field at all, and while the following mechanisms I describe will help, if you are serious about security then I recommend you do some research of your own into the subject. There are many good references on the Internet relating to the subject. An important rule of thumb is: `Don't run servers you don't intend to use'. Many distributions come configured with all sorts of services configured and automatically started. To ensure even a minimum level of safety you should go through your /etc/inetd.conf file and comment out (place a `#' at the start of the line) any entries for services you don't intend to use. Good candidates are services such as: shell, login, exec, uucp, ftp, and informational services such as finger, netstat and systat. There are all sorts of security and access control mechanisms, I'll describe the most elementary of them. 5.10.1. /etc/ftpusers The /etc/ftpusers file is a simple mechanism that allows you to deny certain users from logging into your machine via ftp. The /etc/ftpusers is read by the ftp daemon program (ftpd) when an incoming ftp connection is received. The file is a simple list of those users who are disallowed from logging in. It might looks something like: # /etc/ftpusers - users not allowed to login via ftp root uucp bin mail 5.10.2. /etc/securetty The /etc/securetty file allows you to specify which tty devices root is allowed to login on. The /etc/securetty file is read by the login program (usually /bin/login). Its format is a list of the tty devices names allowed, on all others root login is disallowed: # /etc/securetty - tty's on which root is allowed to login tty1 tty2 tty3 tty4 5.10.3. The tcpd hosts access control mechanism. The tcpd program you will have seen listed in the same /etc/inetd.conf provides logging and access control mechanisms to services it is configured to protect. When it is invoked by the inetd program it reads two files containing access rules and either allows or denies access to the server it is protecting accordingly. It will searches the rules files until the first match is found. If no match is found then it assumes that access should be allowed to anyone. The files it searches in sequence are: /etc/hosts.allow, /etc/hosts.deny. I'll describe each of these in turn. For a complete description of this facility you should refer to the appopriate man pages (hosts_access(5) is a good starting point). 5.10.3.1. /etc/hosts.allow The /etc/hosts.allow file is a configuration file of the /usr/sbin/tcpd program. The hosts.allow file contains rules describing which hosts are allowed access to a service on your machine. The file format is quite simple: # /etc/hosts.allow # # : [: command] service list is a comma delimited list of server names that this rule applies to. Example server names are: ftpd, telnetd, and fingerd. host list is a comma delimited list of host names. You may also use IP addresses here. You may additionally specify hostnames or addresses using wildcard characters to match groups of hosts. Examples include: gw.vk2ktj.ampr.org to match a specific host, .uts.edu.au to match any hostname ending in that string, 44. to match any IP address commencing with those digits. There are some special tokens to simplify configuration, some of these are: ALL matches every host, LOCAL matches any host whose name does not contain a `.' ie is in the same domain as your machine, and PARANOID matches any host whose name does not match its address (name spoofing). There is one last token that is also useful. The EXCEPT token allows you to provide a list with exceptions. This will be covered in an example later. command is an optional parameter. This parameter is the full pathname of a command that would be executed everytime this rule is matched. It could for example run a command that would attempt to identify who is logged onto the connecting host, or to generate a mail message or some other warning to a system administrator that someone is attempting to connect. There are a number of expansions that may be included, some common examples are: %h expands to the name of the connecting host or address if it doesn't have a name, %d the daemon name being called. An example: # /etc/hosts.allow # # Allow mail to anyone in.smtpd: ALL # All telnet and ftp to only hosts within my domain and my host at home. telnetd, ftpd: LOCAL, myhost.athome.org.au # Allow finger to anyone but keep a record of who they are. fingerd: ALL: (finger @%h | mail -s "finger from %h" root) 5.10.3.2. /etc/hosts.deny The /etc/hosts.deny file is a configuration file of the /usr/sbin/tcpd program. The hosts.deny file contains rules describing which hosts are disallowed access to a service on your machine. A simple sample would look something like this: # /etc/hosts.deny # # Disallow all hosts with suspect hostnames ALL: PARANOID # # Disallow all hosts. ALL: ALL The PARANOID entry is really redundant because the other entry traps everything in any case. Either of these entry would make a reasonable default depending on your particular requirement. Having an ALL: ALL default in the /etc/hosts.deny and then specifically enabling on those services and hosts that you want in the /etc/hosts.allow file is the safest configuration. 5.10.4. /etc/hosts.equiv The hosts.equiv file is used to grant certain hosts and users access rights to accounts on your machine without having to supply a password. This is useful in a secure environment where you control all machines, but is a security hazard otherwise. Your machine is only as secure as the least secure of the trusted hosts. To maximise security, don't use this mechanism and encourage your users not to use the .rhosts file as well. 5.10.5. Configure your ftp daemon properly. Many sites will be interested in running an anonymous ftp server to allow other people to upload and download files without requiring a specific userid. If you decide to offer this facility make sure you configure the ftp daemon properly for anonymous access. Most man pages for ftpd(8) describe in some length how to go about this. You should always ensure that you follow these instructions. An important tip is to not use a copy of your /etc/passwd file in the anonymous account /etc directory, make sure you strip out all account details except those that you must have, otherwise you will be vulnerable to brute force password cracking techniques. 5.10.6. Network Firewalling. Not allowing datagrams to even reach your machine or servers is an excellent means of security. This is covered in depth in the Firewall- HOWTO . 5.10.7. Other suggestions. Here are some other, potentially religous suggestions for you to consider. sendmail despite its popularity the sendmail daemon appears with frightening regularity on security warning announcements. Its up to you, but I choose not to run it. NFS and other Sun RPC services be wary of these. There are all sorts of possible exploits for these services. It is difficult finding an option to services like NFS, but if you configure them, make sure you are careful with who you allow mount rights to. 6. Network Technology Specific Information. The following subsections are specific to particular network technologies. The information contained in these sections does not necessarily apply to any other type of network technology. 6.1. ARCNet ARCNET device names are `arc0s', `arc1e', `arc2e' etc. The first card detected by the kernel is assigned `eth0' and the rest are assigned sequentially in the order they are detected. The letter at the end signifies whether you've selected ethernet encapsulation packet format or RFC1051 packet format. Kernel Compile Options: Network device support ---> [*] Network device support <*> ARCnet support [ ] Enable arc0e (ARCnet "Ether-Encap" packet format) [ ] Enable arc0s (ARCnet RFC1051 packet format) Once you have your kernel properly built to support your ethernet card then configuration of the card is easy. Typically you would use something like: # ifconfig arc0e 192.168.0.1 netmask 255.255.255.0 up # route add 192.168.0.0 netmask 255.255.255.0 arc0e Please refer to the /usr/src/linux/Documentation/networking/arcnet- hardware.txt file for further information. ARCNet support was developed by Avery Pennarun, apenwarr@foxnet.net. 6.2. Appletalk (AF_APPLETALK) The Appletalk support has no special device names as it uses existing network devices. Kernel Compile Options: Networking options ---> <*> Appletalk DDP Appletalk support allows your Linux machine to interwork with Apple networks. An important use for this is to share resources such as printers and disks between both your Linux and Apple computers. Addi­ tional software is required, this is called netatalk. Wesley Craig netatalk@umich.edu represents a team called the `Research Systems Unix Group' at the University of Michigan and they have produced the netatalk package which provides software that implements the Appletalk protocol stack and some useful utilities. The netatalk package will either have been supplied with your Linux distribution, or you will have to ftp it from its home site at the University of Michigan To build and install the package do something like: # cd /usr/src # tar xvfz .../netatalk-1.4b2.tar.Z - You may want to edit the `Makefile' at this point, specifically to change the DESTDIR variable which defines where the files will be installed later. The default of /usr/local/atalk is fairly safe. # make - as root: # make install 6.2.1. Configuring the Appletalk software. The first thing you need to do to make it all work is add some new entries to your /etc/services file. The entries to add are: rtmp 1/ddp # Routing Table Maintenance Protocol nbp 2/ddp # Name Binding Protocol echo 4/ddp # AppleTalk Echo Protocol zip 6/ddp # Zone Information Protocol The next step is to create the appletalk configuration files in the /usr/local/atalk/etc directory (or wherever you installed the package). The first file to create is the /usr/local/atalk/etc/atalkd.conf file. Initially this file needs only one line that gives the name of the network device that supports the network that your Apple machines are on: eth0 The Appletalk daemon program will add extra details after it is run. 6.2.2. Exporting a Linux filesystems via Appletalk. You can export filesystems from your linux machine to the network so that Apple machine on the network can share them. To do this you must configure the /usr/local/atalk/etc/AppleVolumes.system file. There is another configuration file called /usr/local/atalk/etc/AppleVolumes.default which has exactly the same format and describes which filesystems users connecting with guest priveledges will receive. Full details on how to configure these files and what the various options are can be found in the afpd man page. A simple example might look like: /tmp Scratch /home/ftp/pub "Public Area" Which would export your /tmp filesystem as AppleShare Volume `Scratch' and your ftp public directory as AppleShare Volume `Public Area'. The volume names are not mandatory, the daemon will choose some for you, but it won't hurt to specify them anyway. 6.2.3. Sharing your Linux printer across Appletalk. You can share your linux printer with your Apple machines quite simply. You need to run the papd program which is the Appletalk Printer Access Protocol Daemon. When you run this program it will accept requests from your Apple machines and spool the print job to your local line printer daemon for printing. You need to edit the /usr/local/atalk/etc/papd.conf file to configure the daemon. The syntax of this file is the same as that of your usual /etc/printcap file. The name you give to the definition is registered with the Appletalk naming protocol, NBP. A sample configuration might look like: TricWriter:\ :pr=lp:op=cg: Which would make a printer named `TricWriter' available to your Appletalk network and all accepted jobs would be printed to the linux printer `lp' (as defined in the /etc/printcap file) using lpd. The entry `op=cg' says that the linux user `cg' is the operator of the printer. 6.2.4. Starting the appletalk software. Ok, you should now be ready to test this basic configuration. There is an rc.atalk file supplied with the netatalk package that should work ok for you, so all you should have to do is: # /usr/local/atalk/etc/rc.atalk and all should startup and run ok. You should see no error messages and the software will send messages to the console indicating each stage as it starts. 6.2.5. Testing the appletalk software. To test that the software is functioning properly, go to one of your Apple machines, pull down the Apple menu, select the Chooser, click on AppleShare, and your Linux box should appear. 6.2.6. Caveats of the appletalk software. · You may need to start the Appletalk support before you configure your IP network. If you have problems starting the Appletalk programs, or if after you start them you have trouble with your IP network, then try starting the Appletalk software before you run your /etc/rc.d/rc.inet1 file. · The afpd (Apple Filing Protocol Daemon) severely messes up your hard disk. Below the mount points it creates a couple of directories: directory you access it will create a .AppleDouble below it so it can store resource forks, etc. So think twice before exporting /, you will have a great time cleaning up afterwards. · The afpd program expects clear text passwords from the Macs. Security could be a problem, so be very careful when you run this daemon on a machine connected to the Internet, you have yourself to blame if somebody nasty does something bad. · The existing diagnostic tools such as netstat and ifconfig don't support Appletalk. The raw information is available in the /proc/net/ directory if you need it. 6.2.7. More information For a much more detailed description of how to configure Appletalk for Linux refer to Anders Brownworth Linux Netatalk-HOWTO page at thehamptons.com . 6.3. ATM Werner Almesberger is managing a project to provide Asynchronous Transfer Mode support for Linux. Current information on the status of the project may be obtained from: lrcwww.epfl.ch . 6.4. AX25 (AF_AX25) AX.25 device names are `sl0', `sl1', etc. in 2.0.* kernels or `ax0', `ax1', etc. in 2.1.* kernels. Kernel Compile Options: Networking options ---> [*] Amateur Radio AX.25 Level 2 The AX25, Netrom and Rose protocols are covered by the AX25-HOWTO . These protocols are used by Amateur Radio Opera­ tors world wide in packet radio experimentation. Most of the work for implementation of these protocols has been done by Jonathon Naylor, jsn@cs.nott.ac.uk. 6.5. DECNet Support for DECNet is currently being worked on. You should expect it to appear in a late 2.1.* kernel. 6.6. EQL - multiple line traffic equaliser EQL device name is `eql'. With the standard kernel source you may have only one EQL device per machine. EQL provides a means of utilising multiple point to point lines such as PPP, slip or plip as a single logical link to carry tcp/ip. Often this is cheaper to use multiple lower speed lines than to have one high speed line installed. Kernel Compile Options: Network device support ---> [*] Network device support <*> EQL (serial line load balancing) support To support this mechanism the machine at the other end of the lines must also support EQL. Linux, Livingstone Portmasters and newer dial- in servers support compatible facilities. To configure EQL you will need the eql tools which are available from: sunsite.unc.edu . Configuration is fairly straightforward. You start by configuring the eql interface. The eql interface is just like any other network device. You configure the IP address and mtu using the ifconfig utility, so something like: ifconfig eql 192.168.10.1 mtu 1006 route add default eql Next you need to manually initiate each of the lines you will use. These may be any combination of point to point network devices. How you initiate the connections will depend on what sort of link they are, refer to the appropriate sections for further information. Lastly you need to associate the serial link with the EQL device, this is called `enslaving' and is done with the eql_enslave command as shown: eql_enslave eql sl0 28800 eql_enslave eql ppp0 14400 The `estimated speed' parameter you supply eql_enslave doesn't do any­ thing directly. It is used by the EQL driver to determine what share of the datagrams that device should receive, so you can fine tune the balancing of the lines by playing with this value. To disassociate a line from an EQL device you use the eql_emancipate command as shown: eql_emancipate eql sl0 You add routing as you would for any other point to point link, except your routes should refer to the eql device rather than the actual serial devices themselves, typically you would use: route add default eql0 The EQL driver was developed by Simon Janes, simon@ncm.com. 6.7. Ethernet Ethernet device names are `eth0', `eth1', `eth2' etc. The first card detected by the kernel is assigned `eth0' and the rest are assigned sequentially in the order they are detected. To learn how to make your ethernet card working under Linux you should refer to the Ethernet-HOWTO . Once you have your kernel properly built to support your ethernet card then configuration of the card is easy. Typically you would use something like: # ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up # route add 192.168.0.0 netmask 255.255.255.0 eth0 Most of the ethernet drivers were developed by Donald Becker, becker@CESDIS.gsfc.nasa.gov. 6.8. FDDI FDDI device names are `fddi0', `fddi1', `fddi2' etc. The first card detected by the kernel is assigned `fddi0' and the rest are assigned sequentially in the order they are detected. Lawrence V. Stefani, stefani@lkg.dec.com, has developed a driver for the Digital Equipment Corporation FDDI EISA and PCI cards. Kernel Compile Options: Network device support ---> [*] FDDI driver support [*] Digital DEFEA and DEFPA adapter support When you have your kernel built to support the FDDI driver and installed, configuration of the FDDI interface is almost identical that for an ethernet interface. You just specify the appropraite FDDI interface name in the ifconfig and route comands. 6.9. Frame Relay The Frame Relay device names are `dlci00', `dlci01' etc for the DLCI encapsulation devices and `sdla0', `sdla1' etc for the FRAD(s). Frame Relay is a new networking technology that is designed to suit data communications traffic that is of a `bursty' or intermittent nature. You connect to a Frame Relay network using a Frame Relay Access Device (FRAD). The Linux Frame Relay supports IP over Frame Relay as described in RFC-1490. Kernel Compile Options: Network device support ---> <*> Frame relay DLCI support (EXPERIMENTAL) (24) Max open DLCI (8) Max DLCI per device <*> SDLA (Sangoma S502/S508) support Mike McLagan, mike.mclagan@linux.org, developed the Frame Relay support and configuration tools. Currently the only FRAD suported are the Sangoma Technologies S502A, S502E and S508. To configure the FRAD and DLCI devices after you have rebuilt your kernel you will need the Frame Relay configuration tools. These are available from ftp.invlogic.com . Compiling and installing the tools is straightforward, but the lack of a top level Makefile makes it a fairly manual process: # cd /usr/src # tar xvfz .../frad-0.15.tgz # cd frad-0.15 # for i in common dlci frad; do cd $i; make clean; make; cd ..; done # mkdir /etc/frad # install -m 644 -o root -g root bin/*.sfm /etc/frad # install -m 700 -o root -g root frad/fradcfg /sbin # install -m 700 -o root -g root dlci/dlcicfg /sbin After installing the tools you need to create an /etc/frad/router.conf file. You can use this template, which is a modified version of one of the example files: # /etc/frad/router.conf # This is a template configuration for frame relay. # All tags are included. The default values are based on the code # supplied with the DOS drivers for the Sangoma S502A card. # # A '#' anywhere in a line constitutes a comment # Blanks are ignored (you can indent with tabs too) # Unknown [] entries and unknown keys are ignored # [Devices] Count=1 # number of devices to configure Dev_1=sdla0 # the name of a device #Dev_2=sdla1 # the name of a device # Specified here, these are applied to all devices, and can be overriden for # each individual board. # Access=CPE Clock=Internal KBaud=64 Flags=TX # # MTU=1500 # Maximum transmit IFrame length, default is 4096 # T391=10 # T391 value 5 - 30, default is 10 # T392=15 # T392 value 5 - 30, default is 15 # N391=6 # N391 value 1 - 255, default is 6 # N392=3 # N392 value 1 - 10, default is 3 # N393=4 # N393 value 1 - 10, default is 4 # Specified here, these set the defaults for all boards # CIRfwd=16 # CIR forward 1 - 64 # Bc_fwd=16 # Bc forward 1 - 512 # Be_fwd=0 # Be forward 0 - 511 # CIRbak=16 # CIR backward 1 - 64 # Bc_bak=16 # Bc backward 1 - 512 # Be_bak=0 # Be backward 0 - 511 # # # Device specific configuration # # # # The first device is a Sangoma S502E # [sdla0] Type=Sangoma # Type of the device to configure, currently only # SANGOMA is recognised # # These keys are specific to the 'Sangoma' type # # The type of Sangoma board - S502A, S502E, S508 Board=S502E # # The name of the test firmware for the Sangoma board # Testware=/usr/src/frad-0.10/bin/sdla_tst.502 # # The name of the FR firmware # Firmware=/usr/src/frad-0.10/bin/frm_rel.502 # Port=360 # Port for this particular card Mem=C8 # Address of memory window, A0-EE, depending on card IRQ=5 # IRQ number, do not supply for S502A DLCIs=1 # Number of DLCI's attached to this device DLCI_1=16 # DLCI #1's number, 16 - 991 # DLCI_2=17 # DLCI_3=18 # DLCI_4=19 # DLCI_5=20 # # Specified here, these apply to this device only, # and override defaults from above # # Access=CPE # CPE or NODE, default is CPE # Flags=TXIgnore,RXIgnore,BufferFrames,DropAborted,Stats,MCI,AutoDLCI # Clock=Internal # External or Internal, default is Internal # Baud=128 # Specified baud rate of attached CSU/DSU # MTU=2048 # Maximum transmit IFrame length, default is 4096 # T391=10 # T391 value 5 - 30, default is 10 # T392=15 # T392 value 5 - 30, default is 15 # N391=6 # N391 value 1 - 255, default is 6 # N392=3 # N392 value 1 - 10, default is 3 # N393=4 # N393 value 1 - 10, default is 4 # # The second device is some other card # # [sdla1] # Type=FancyCard # Type of the device to configure. # Board= # Type of Sangoma board # Key=Value # values specific to this type of device # # DLCI Default configuration parameters # These may be overridden in the DLCI specific configurations # CIRfwd=64 # CIR forward 1 - 64 # Bc_fwd=16 # Bc forward 1 - 512 # Be_fwd=0 # Be forward 0 - 511 # CIRbak=16 # CIR backward 1 - 64 # Bc_bak=16 # Bc backward 1 - 512 # Be_bak=0 # Be backward 0 - 511 # # DLCI Configuration # These are all optional. The naming convention is # [DLCI_D_] # [DLCI_D1_16] # IP= # Net= # Mask= # Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames # DLCIFlags=TXIgnore,RXIgnore,BufferFrames # CIRfwd=64 # Bc_fwd=512 # Be_fwd=0 # CIRbak=64 # Bc_bak=512 # Be_bak=0 [DLCI_D2_16] # IP= # Net= # Mask= # Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames # DLCIFlags=TXIgnore,RXIgnore,BufferFrames # CIRfwd=16 # Bc_fwd=16 # Be_fwd=0 # CIRbak=16 # Bc_bak=16 # Be_bak=0 When you've built your /etc/frad/router.conf file the only step remaining is to configure the actual devices themselves. This is only a little trickier than a normal network device configuration, you need to remember to bring up the FRAD device before the DLCI encapsulation devices. # Configure the frad hardware and the DLCI parameters /sbin/fradcfg /etc/frad/router.conf || exit 1 /sbin/dlcicfg file /etc/frad/router.conf # # Bring up the FRAD device ifconfig sdla0 up # # Configure the DLCI encapsulation interfaces and routing ifconfig dlci00 192.168.10.1 pointopoint 192.168.10.2 up route add 192.168.10.0 netmask 255.255.255.0 dlci00 # ifconfig dlci01 192.168.11.1 pointopoint 192.168.11.2 up route add 192.168.11.0 netmask 255.255.255.0 dlci00 # route add default dev dlci00 # 6.10. IP Accounting The IP accounting features of the Linux kernel allow you to collect and analyse some network usage data. The data collected comprises the number of packets and the number of bytes accumulated since the figures were last reset. You may specify a variety of rules to categorise the figures to suit whatever purpose you may have. Kernel Compile Options: Networking options ---> [*] IP: accounting After you have compiled and installed the kernel you need to use the ipfwadm command to configure IP accounting. There are many different ways of breaking down the accounting information that you might choose. I've picked a simple example of what might be useful to use, you should read the ipfwadm man page for more information. Scenario: You have a ethernet network that is linked to the internet via a PPP link. On the ethernet you have a machine that offers a number of services and that you are interested in knowing how much traffic is generated by each of telnet, rlogin, ftp and world wide web traffic. You might use a command set that looks like the following: # # Flush the accounting rules ipfwadm -A -f # # Add rules for local ethernet segment ipfwadm -A in -a -P tcp -D 44.136.8.96/29 20 ipfwadm -A out -a -P tcp -S 44.136.8.96/29 20 ipfwadm -A in -a -P tcp -D 44.136.8.96/29 23 ipfwadm -A out -a -P tcp -S 44.136.8.96/29 23 ipfwadm -A in -a -P tcp -D 44.136.8.96/29 80 ipfwadm -A out -a -P tcp -S 44.136.8.96/29 80 ipfwadm -A in -a -P tcp -D 44.136.8.96/29 513 ipfwadm -A out -a -P tcp -S 44.136.8.96/29 513 ipfwadm -A in -a -P tcp -D 44.136.8.96/29 ipfwadm -A out -a -P tcp -D 44.136.8.96/29 ipfwadm -A in -a -P udp -D 44.136.8.96/29 ipfwadm -A out -a -P udp -D 44.136.8.96/29 ipfwadm -A in -a -P icmp -D 44.136.8.96/29 ipfwadm -A out -a -P icmp -D 44.136.8.96/29 # # Rules for default ipfwadm -A in -a -P tcp -D 0/0 20 ipfwadm -A out -a -P tcp -S 0/0 20 ipfwadm -A in -a -P tcp -D 0/0 23 ipfwadm -A out -a -P tcp -S 0/0 23 ipfwadm -A in -a -P tcp -D 0/0 80 ipfwadm -A out -a -P tcp -S 0/0 80 ipfwadm -A in -a -P tcp -D 0/0 513 ipfwadm -A out -a -P tcp -S 0/0 513 ipfwadm -A in -a -P tcp -D 0/0 ipfwadm -A out -a -P tcp -D 0/0 ipfwadm -A in -a -P udp -D 0/0 ipfwadm -A out -a -P udp -D 0/0 ipfwadm -A in -a -P icmp -D 0/0 ipfwadm -A out -a -P icmp -D 0/0 # # List the rules ipfwadm -A -l -n # The last command lists each of the Accounting rules and displays the collected totals. An important point to note when analysing IP accounting is that totals for all rules that match will be incremented so that to obtain differential figures you need to perform appropriate maths. For example if I wanted to know how much data was not ftp, telnet, rlogin or www I would substract the individual totals from the rule that matches all ports. # ipfwadm -A -l -n IP accounting rules pkts bytes dir prot source destination ports 0 0 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 20 0 0 out tcp 44.136.8.96/29 0.0.0.0/0 20 -> * 0 0 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 23 0 0 out tcp 44.136.8.96/29 0.0.0.0/0 23 -> * 10 1166 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 80 10 572 out tcp 44.136.8.96/29 0.0.0.0/0 80 -> * 242 9777 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 513 220 18198 out tcp 44.136.8.96/29 0.0.0.0/0 513 -> * 252 10943 in tcp 0.0.0.0/0 44.136.8.96/29 * -> * 231 18831 out tcp 0.0.0.0/0 44.136.8.96/29 * -> * 0 0 in udp 0.0.0.0/0 44.136.8.96/29 * -> * 0 0 out udp 0.0.0.0/0 44.136.8.96/29 * -> * 0 0 in icmp 0.0.0.0/0 44.136.8.96/29 * 0 0 out icmp 0.0.0.0/0 44.136.8.96/29 * 0 0 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 20 0 0 out tcp 0.0.0.0/0 0.0.0.0/0 20 -> * 0 0 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 23 0 0 out tcp 0.0.0.0/0 0.0.0.0/0 23 -> * 10 1166 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 80 10 572 out tcp 0.0.0.0/0 0.0.0.0/0 80 -> * 243 9817 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 513 221 18259 out tcp 0.0.0.0/0 0.0.0.0/0 513 -> * 253 10983 in tcp 0.0.0.0/0 0.0.0.0/0 * -> * 231 18831 out tcp 0.0.0.0/0 0.0.0.0/0 * -> * 0 0 in udp 0.0.0.0/0 0.0.0.0/0 * -> * 0 0 out udp 0.0.0.0/0 0.0.0.0/0 * -> * 0 0 in icmp 0.0.0.0/0 0.0.0.0/0 * 0 0 out icmp 0.0.0.0/0 0.0.0.0/0 * # 6.11. IP Aliasing There are some applications where being able to configure multiple IP addresses to a single network device is useful. Internet Service Providers often use this facility to provide a `customised' to their World Wide Web and ftp offerings for their customers. Kernel Compile Options: Networking options ---> .... [*] Network aliasing .... <*> IP: aliasing support After compiling and installing your kernel with IP_Alias support configuration is very simple. The aliases are added to virtual network devices associated with the actual network device. A simple naming convention applies to these devices being :, e.g. eth0:0, ppp0:10 etc. For example, assume you have an ethernet network that supports two different IP subnetworks simultaneously and you wish your machine to have direct access to both, you could use something like: # # ifconfig eth0:0 192.168.1.1 netmask 255.255.255.0 up # route add -net 192.168.1.0 netmask 255.255.255.0 eth0:0 # # ifconfig eth0:1 192.168.10.1 netmask 255.255.255.0 up # route add -net 192.168.10.0 netmask 255.255.255.0 eth0:0 # To delete an alias you simply add a `-' to the end of its name and refer to it and is as simple as: # ifconfig eth0:0- 0 All routes associated with that alias will also be deleted automati­ cally. 6.12. IP Firewall IP Firewall and Firewalling issues are covered in more depth in the Firewall-HOWTO . IP Firewalling allows you to secure your machine against unauthorised network access by filtering or allowing datagrams from or to IP addresses that you nominate. There are three different classes of rules, incoming filtering, outgoing filtering and forwarding filtering. Incoming rules are applied to datagrams that are received by a network device. Outgoing rules are applied to datagrams that are to be transmitted by a network device. Forwarding rules are applied to datagrams that are received and are not for this machine, ie datagrams that would be routed. Kernel Compile Options: Networking options ---> [*] Network firewalls .... [*] IP: forwarding/gatewaying .... [*] IP: firewalling [ ] IP: firewall packet logging Configuration of the IP firewall rules is performed using the ipfwadm command. As I mentioned earlier, security is not something I am expert at, so while I will present an example you can use, you should do your own research and develop your own rules if security is important to you. Probably the most common use of IP firewall is when you are using your linux machine as a router and firewall gateway to protect your local network from unauthorised access from outside your network. The following configuration is based on a contribution from Arnt Gulbrandsen, . The example describes the configuration of the firewall rules on the Linux firewall/router machine illustrated in this diagram: - - \ | 172.16.37.0 \ | /255.255.255.0 \ --------- | | 172.16.174.30 | Linux | | NET =================| f/w |------| ..37.19 | PPP | router| | -------- / --------- |--| Mail | / | | /DNS | / | -------- - - The following commands would normally be placed in an rc file so that they were automatically started each time the system boots. For maximum security they would be performed after the network interfaces are configured, but before the interfaces are actually brought up to prevent anyone gaining access while the firewall machine is rebooting. #!/bin/sh # Flush the 'Forwarding' rules table # Change the default policy to 'accept' # /sbin/ipfwadm -F -f /sbin/ipfwadm -F -p accept # # .. and for 'Incoming' # /sbin/ipfwadm -I -f /sbin/ipfwadm -I -p accept # First off, seal off the PPP interface # I'd love to use '-a deny' instead of '-a reject -y' but then it # would be impossible to originate connections on that interface too. # The -o causes all rejected datagrams to be logged. This trades # disk space against knowledge of an attack of configuration error. # /sbin/ipfwadm -I -a reject -y -o -P tcp -S 0/0 -D 172.16.174.30 # Throw away certain kinds of obviously forged packets right away: # Nothing should come from multicast/anycast/broadcast addresses # /sbin/ipfwadm -F -a deny -o -S 224.0/3 -D 172.16.37.0/24 # # and nothing coming from the loopback network should ever be # seen on a wire # /sbin/ipfwadm -F -a deny -o -S 127.0/8 -D 172.16.37.0/24 # accept incoming SMTP and DNS connections, but only # to the the Mail/Name Server # /sbin/ipfwadm -F -a accept -P tcp -S 0/0 -D 172.16.37.19 25 53 # # DNS uses UDP as well as TCP, so allow that too # for questions to our name server # /sbin/ipfwadm -F -a accept -P udp -S 0/0 -D 172.16.37.19 53 # # but not "answers" coming to dangerous ports like NFS and # Larry McVoy's NFS extension. If you run squid, add its port here. # /sbin/ipfwadm -F -a deny -o -P udp -S 0/0 53 \ -D 172.16.37.0/24 2049 2050 # answers to other user ports are okay # /sbin/ipfwadm -F -a accept -P udp -S 0/0 53 \ -D 172.16.37.0/24 53 1024:65535 # Reject incoming connections to identd # We use 'reject' here so that the connecting host is told # straight away not to bother continuing, otherwise we'd experience # delays while ident timed out. # /sbin/ipfwadm -F -a reject -o -P tcp -S 0/0 -D 172.16.37.0/24 113 # Accept some common service connections from the 192.168.64 and # 192.168.65 networks, they are friends that we trust. # /sbin/ipfwadm -F -a accept -P tcp -S 192.168.64.0/23 \ -D 172.16.37.0/24 20:23 # accept and pass through anything originating inside # /sbin/ipfwadm -F -a accept -P tcp -S 172.16.37.0/24 -D 0/0 # deny most other incoming TCP connections, and log them # (append 1:1023 if you have problems with ftp not working) # /sbin/ipfwadm -F -a deny -o -y -P tcp -S 0/0 -D 172.16.37.0/24 # ... for UDP too # /sbin/ipfwadm -F -a deny -o -P udp -S 0/0 -D 172.16.37.0/24 Good firewall configurations are a little tricky. This example should be a reasonable starting point for you. The ipfwadm manual page offers some assistance in how to use the tool. If you intend to configure a firewall, be sure to ask around and get as much advice from sources you consider reliable and get someone to test/sanity check your configuration from the outside. 6.13. IPIP Encapsulation Why would you want to encapsulate IP datagrams within IP datagrams? It must seem an odd thing to do if you've never seen an application of it before. Ok, here are a couple of common places where it is used: Mobile-IP and IP-Multicast. What is perhaps the most widely spread use of it though is also the least well known, Amateur Radio. Kernel Compile Options: Networking options ---> [*] TCP/IP networking [*] IP: forwarding/gatewaying .... <*> IP: tunneling IP tunnel devices are called `tunl0', `tunl1' etc. "But why ?". Ok, ok. Conventional IP routing rules mandate that an IP network comprises a network address and a network mask. This produces a series of contiguous addresses that may all be routed via a single routing entry. This is very convenient, but it means that you may only use any particular IP address while you are connected to the particular piece of network to which it belongs. In most instances this is ok, but if you are a mobile netizen then you may not be able to stay connected to the one place all the time. IP/IP encapsulation (IP tunneling) allows you to overcome this restriction by allowing datagrams destined for your IP address to be wrapped up and redirected to another IP address. If you know that you're going to be operating from some other IP network for some time you can set up a machine on your home network to accept datagrams to your IP address and redirect them to the address that you will actually be using temporarily. 6.13.1. A tunneled network configuration. As always, I believe a diagram will save me lots of confusing text, so here is one: 192.168.1/24 192.168.2/24 - - | ppp0 = ppp0 = | | aaa.bbb.ccc.ddd fff.ggg.hhh.iii | | | | /-----\ /-----\ | | | | // | | | |---| A |------//---------| B |---| | | | // | | | | \-----/ \-----/ | | | - - The diagram illustrates another possible reason to use IPIP encapsulation, virtual private networking. This example presupposes that you have two machines each with a simple dial up internet connection. Each host is allocated just a single IP address. Behind each of these machines are some private local area networks configured with reserved IP network addresses. Suppose that you want to allow any host on network A to connect to any host on network B, just as if they were properly connected to the Internet with a network route. IPIP encapsulation will allow you to do this. Note, encapsulation does not solve the problem of how you get the hosts on networks A and B to talk to any other on the Internet, you still need tricks like IP Masquerade for that. Encapsulation is normally performed by machine functioning as routers. Linux router `A' would be configured with: # PATH=/sbin:/usr/sbin # # Ethernet configuration ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up route add 192.168.1.0 netmask 255.255.255.0 eth0 # # ppp0 configuration (start ppp link, set default route) pppd route add default ppp0 # # Tunnel device configuration ifconfig tunl0 192.168.1.1 up route add -net 192.168.2.0 netmask 255.255.255.0 gw fff.ggg.hhh.iii tunl0 Linux router `B' would be configured with: # PATH=/sbin:/usr/sbin # # Ethernet configuration ifconfig eth0 192.168.2.1 netmask 255.255.255.0 up route add 192.168.2.0 netmask 255.255.255.0 eth0 # # ppp0 configuration (start ppp link, set default route) pppd route add default ppp0 # # Tunnel device configuration ifconfig tunl0 192.168.2.1 up route add -net 192.168.1.0 netmask 255.255.255.0 gw aaa.bbb.ccc.ddd tunl0 The command: route add -net 192.168.1.0 netmask 255.255.255.0 gw aaa.bbb.ccc.ddd tunl0 reads: `Send any datagrams destined for 192.168.1.0/24 inside an IPIP encap datagram with a destination address of aaa.bbb.ccc.ddd'. Note that the configurations are reciprocated at either end. The tunnel device uses the `gw' in the route as the destination of the IP datagram in which it will place the datagram it has received to route. That machine must know how to decapsulate IPIP datagrams, that is, it must also be configured with a tunnel device. 6.13.2. A tunneled host configuration. It doesn't have to be a whole network you route. You could for example route just a single IP address. In that instance you might configure the tunl device on the `remote' machine with its home IP address and at the A end just use a host route (and Proxy Arp) rather than a network route via the tunnel device. Let's redraw and modify our configuration appropriately. Now we have just host `B' which to want to act and behave as if it is both fully connected to the Internet and also part of the remote network supported by host `A': 192.168.1/24 - | ppp0 = ppp0 = | aaa.bbb.ccc.ddd fff.ggg.hhh.iii | | /-----\ /-----\ | | | // | | |---| A |------//---------| B | | | | // | | | \-----/ \-----/ | also: 192.168.1.12 - Linux router `A' would be configured with: # PATH=/sbin:/usr/sbin # # Ethernet configuration ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up route add 192.168.1.0 netmask 255.255.255.0 eth0 # # ppp0 configuration (start ppp link, set default route) pppd route add default ppp0 # # Tunnel device configuration ifconfig tunl0 192.168.1.1 up route add -host 192.168.1.12 gw fff.ggg.hhh.iii tunl0 # # Proxy ARP for the remote host arp -s 192.168.1.12 xx:xx:xx:xx:xx:xx pub Linux host `B' would be configured with: # PATH=/sbin:/usr/sbin # # ppp0 configuration (start ppp link, set default route) pppd route add default ppp0 # # Tunnel device configuration ifconfig tunl0 192.168.1.12 up route add -net 192.168.1.0 netmask 255.255.255.0 gw aaa.bbb.ccc.ddd tunl0 This sort of configuration is more typical of a Mobile-IP application. Where a single host wants to roam around the Internet and maintain a single usable IP address the whole time. You should refer to the Mobile-IP section for more information on how that is handled in practice. 6.14. IPX (AF_IPX) The IPX protocol is most commonly utilised in Novell NetWare(tm) local area network environments. Linux includes support for this protocol, and may be configured to act as a network endpoint, or as a router for IPX. Kernel Compile Options: Networking options ---> [*] The IPX protocol [ ] Full internal IPX network The IPX protocol and the NCPFS are covered in greater depth in the IPX-HOWTO . 6.15. IPv6 Just when you thought you were beginning to understand IP networking the rules get changed! IPv6 is the shorthand notation for version 6 of the Internet Protocol. IPv6 was developed primarily to overcome the concerns in the Internet community that there would soon be a shortage of IP addresses to allocate. IPv6 addresses are 32 bytes long (128 bits). IPv6 incorporates a number of other changes, mostly simplifications, that will make IPv6 networks more managable than IPv4 networks. Linux already has a working, but not completed, IPv6 implementation in the 2.1.* series kernels. If you wish to experiment with this new generation Internet technology, or have a requirement for it, then you should read the IPv6-FAQ which is available from www.terra.net . 6.16. ISDN The Integrated Services Digital Network (ISDN) is a series of standards that specify a general purpose switched digital data network. An ISDN `call' creates a synchronous point to point data service to the destination. ISDN is generally delivered on a high speed link that is broken down into a number of discreet channels. There are two different types of channels, the `B Channels' which will actually carry the user data, and a single channel called the `D channel' which is used to send control information to the ISDN exchange to establish calls and other functions. In Australia for example, ISDN may be delivered on a 2Mbps link that is broken into 30 discreet 64kbps B channels with one 64kbps D channel. Any number of channels may be used at a time and in any combination. You could for example establish 30 seperate calls to 30 different destinations at 64kbps each, or you could establish 15 calls to 15 different destinations at 128kbps each (two channels used per call), or just a small number of calls and leave the rest idle. A channel may be used for either incoming or outgoing calls. The original intention of ISDN was to allow Telecommunications companies to provide a single data service which could deliver either telephone (via digitised voice) or data services to your home or business without requiring you to make any special configuration changes. There are a few different ways to connect your computer to an ISDN service. One way is to use a device called a `Terminal Adaptor' which plugs into the Network Terminating Unit that you telecommunications carrier will have installed when you got your ISDN service, and presents a number of serial interfaces. One of those interfaces is used to enter commands to establish calls and configuration, and the others are actually connected to the network devices that will use the data circuits when they are established. Linux will work in this sort of configuration without modification, you just treat the port on the Terminal Adaptor like you would treat any other serial device. Another way, which is the way the kernel ISDN support is designed for allows you to install an ISDN card into your Linux machine and then has your Linux software handle the protocols and make the calls itself. Kernel Compile Options: ISDN subsystem ---> <*> ISDN support [ ] Support synchronous PPP [ ] Support audio via ISDN < > ICN 2B and 4B support < > PCBIT-D support < > Teles/NICCY1016PC/Creatix support The Linux implementation of ISDN support a number of different types of internal ISDN cards. These are those listed in the kernel configuration options: · ICN 2B and 4B · Octal PCBIT-D · Teles ISDN-cards and compatibles Some of these cards require software to be downloaded to them to make them operational. There is a seperate utility to do this with. Full details on how to configure the Linux ISDN support is available from the /usr/src/linux/Documentation/isdn/ directory and an FAQ dedicated to isdn4linux is available at www.lrz-muenchen.de . (You can click on the english flag to get an english version). A note about PPP. The PPP suite of protocols will operate over either asynchronous or synchronous serial lines. The commonly distributed PPP daemon for Linux `pppd' supports only asynchronous mode. If you wish to run the PPP protocols over your ISDN service you need a specially modified version. Details of where to find it are available in the documentation referred to above. 6.17. IP Masquerade Many people have a simple dialup account to connect to the Internet. Nearly everybody using this sort of configuration is allocated a single IP address by the Internet Service Provider. This is normally enough to allow only one host full access to the network. IP Masquerade is a clever trick that enables you to have many machines make use of that one IP address, by causing the other hosts to look like, hence the term masquerade, the machine supporting the dialup connection. There is a small caveat, and that is that the masqerade function nearly always works only in one direction, that is the masqueraded hosts can make calls out, but they cannot accept or receive network connections from remote hosts. This means that some network services do not work such as talk and others such as ftp must be configured to operate in passive (PASV) mode to operate. Fortunately the most common network services such as telnet, World Wide Web and irc do work just fine. Kernel Compile Options: Code maturity level options ---> [*] Prompt for development and/or incomplete code/drivers Networking options ---> [*] Network firewalls .... [*] TCP/IP networking [*] IP: forwarding/gatewaying .... [*] IP: masquerading (EXPERIMENTAL) Normally you have your linux machine supporting a slip or PPP dialup line just as it would if it were a standalone machine. Additionally it would have another network device configured, perhaps an ethernet, configured with one of the reserved network addresses. The hosts to be masqueraded would be on this second network. Each of these hosts would have the IP address of the ethernet port of the linux machine set as their default gateway or router. A typical configuration might look something like this: - - \ | 192.168.1.0 \ | /255.255.255.0 \ --------- | | | Linux | .1.1 | NET =================| masq |------| | PPP/slip | router| | -------- / --------- |--| host | / | | | / | -------- - - The most relevant commands for this configuration are: # Network route for ethernet route add 192.168.1.0 netmask 255.255.255.0 eth0 # # Default route to the rest of the internet. route add default ppp0 # # Cause all hosts on the 192.168.1/24 network to be masqueraded. ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0 You can get more information on the Linux IP Masquerade feature from the IP Masquerade Resource Page 6.18. IP Transparent Proxy IP transparent proxy is a feature that enables you to redirect servers or services destined for another machine to those services on this machine. Typically this would be useful where you have a linux machine as a router and also provides a proxy server. You would redirect all connections destined for that service remotely to the local proxy server. Kernel Compile Options: Code maturity level options ---> [*] Prompt for development and/or incomplete code/drivers Networking options ---> [*] Network firewalls .... [*] TCP/IP networking .... [*] IP: firewalling .... [*] IP: transparent proxy support (EXPERIMENTAL) Configuration of the transparent proxy feature is performed using the ipfwadm command. An example that might useful is as follows: ipfwadm -I -a accept -D 0/0 80 -r 8080 This example will cause any connection attempts to port 80 (www) on any host to be redirected to port 8080 on this host. This could be used to ensure that all WWW traffic from your network is automatically directed to a local WWW cache program. 6.19. Mobile IP The term "IP mobility" describes the ability of a host that is able to move its network connection from one point on the Internet to another without changing its IP address or losing connectivity. Usually when an IP host changes its point of connectivity it must also change its IP address. IP Mobility overcomes this problem by allocating a fixed IP address to the mobile host and using IP encapsulation (tunneling) with automatic routing to ensure that datagrams destined for it are routed to the actual IP address it is currently using. A project is underway to provide a complete set of IP mobility tools for Linux. The Status of the project and tools may be obtained from the: Linux Mobile IP Home Page . 6.20. Multicast IP Multicast allows an arbitrary number of IP hosts on disparate IP networks to have IP datagrams simultaneously routed to them. This mechanism is exploited to provide Internet wide "broadcast" material such as audio and video transmissions and other novel applications. Kernel Compile Options: Networking options ---> [*] TCP/IP networking .... [*] IP: multicasting A suite of tools and some minor network configuration is required. One source of information on how to install and configure these for Linux is provided at www.teksouth.com