As with the rest of the Linux operating system and its numerous components development of networking stack within Linux has been both a slow and complex journey that has resembled that journey that has been faced by people in the development of networking stacks of other operating systems such as Microsoft Windows and Free BSD. As has been stated in the Linux Networking HOWTO (http://tldp.org/HOWTO/NET3-4-HOWTO.html) the actual implementation of the TCP/IP protocol stack was done basically from scratch due to concerns with regards to copyright issues as well as the possibilty that developers would be able to come up with a protocol stack that was superior to existing protocol stacks. Ross Biro originally implemented the first ethernet driver for the WD-8003 network interface card which led to an increase in pressure among the open source community for the development of more complete networking support. However, due to increased personal commitments he was unable to continue to do so and soon after left this project having formed a crucial base for the development of better networking support under Linux. Orest Zborowski obz@Kodak.com 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. Soon after Laurence Culhane developed the first Linux drivers to support the SLIP protocol which meant that an increasing number of people were able to access the Internet from Linux. It also led to a greater number of people who understood the implications of what full networking support meant for Linux which meant there was an increasing community of people who went on to experiment with this software and further develop it. Eventually Fred van Kempen took over the task of leading the development of networking support under Linux. The primary difference between himself and his former predecessors was that he was far more ambitious in his desire to expand the Linux networking code. He laid the plans for the development of a dynamic device interface, Amateur Radio AX.25 protocol support and a more abstract and modular networking implementation. Obviously, like his predecessor there was increasing pressure on him to deliver a product that was both reliable and satisfied the requirements of most users. This issue was resolved by Alan Cox who eventually debugged the code so that it was reliable enough to use in the general community. He also became the new leader of the Linux networking effort. Donald Becker then went on to make a name for himself through his implementation of a huge range of ethernet drivers. Alan continued to develop the networking code and through the aid of other people added support for a multitude of other protocols such as AX.25, IPX, PPP (Michael Callahan and Al Longyear), and AX.25/NetRom/Rose protcol set (Jonathan Naylor). While the current state of Linux networking is extremely stable (and in some cases surpasses the capabilities and performance of commercial implementations of Linux), there still seems to be significant issues with regards to driver development. This is most especially the case with regards to wireless driver development where while most internal cards are supported there a small minority where support is non-existant and companies seem to be unwilling to disclose enough information regarding the card to develop something that is workeable. Linux Networking HOWTO, http://tldp.org/HOWTO/NET3-4-HOWTO.html ---------- this parameter allows you to set the network mask of the network this device belongs to. irq this parameter only works on certain types of hardware and 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 parameter 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 hierarchical 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 Organizations EDU Educational Organizations GOV Government Organizations MIL Military Organizations ORG Other organizations NET Internet-Related Organizations Country Designator these are two letters codes that represent a particular country. For historical reasons most domains belonging to one of the non- country based top level domains were used by organizations within the United States, although the United States also has its own country code `.us'. This is not true any more for .com and .org domains, which are commonly used by non-us companies. Each of these top level domains has subdomains. The top level domains based on country name are often 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 organizations in Australia; note that this is not a general rule, as actual policies depend on the naming authority for each domain. The next level of division usually represents the name of the organization. Further subdomains vary in nature, often the next level of subdomain is based on the departmental structure of the organization but it may be based on any criterion considered reasonable and meaningful by the network administrators for the organization. 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 Terry's 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 his country, Australia and as his email address belongs to a commercial organization, `.com' is there as the next level domain. The name of the company is (was) `telstra' and their internal naming structure is based on organizational structure, in this case the machine belongs to the Information Technology Group, Network Operations section. Usually, the names are fairly shorter; for example, my ISP is called ``systemy.it'' and my non-profit organization is called ``linux.it'', without any com and org subdomain, so that my own host is just called ``morgana.systemy.it'' and rubini@linux.it is a valid email address. Note that the owner of a domain has the rights to register hostnames as well as subdomains; for example, the LUG I belong to uses the domain pluto.linux.it, because the owners of linux.it agreed to open a subdomain for the LUG. 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 supplied, 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 behaviour 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.5.6. Running a name server If you want to run a local nameserver, you can do it easily. Please refer to the DNS-HOWTO and to any documents included in your version of BIND (Berkeley Internet Name Domain). 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 (but note that this task is usually performed by the standard initialization scripts). root# ifconfig lo 127.0.0.1 root# 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 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 interface 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 interface. 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 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: user% cat /proc/net/route or by using either of the following commands: user% /sbin/route -n user% netstat -r The routing process is fairly simple: an incoming datagram is received, the destination address (who it is for) is examined and compared 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 forwarded to that host via the specified interface, otherwise the destination address is assumed to be on the network supported by the interface. 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: root# 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: root# route add -net 192.168.1.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: root# 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 routing. So, your complete configuration would look like: root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0 root# 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: root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0 root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1 root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2 root# 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 separately because for the workstations the default route mechanism will capture all of them letting the router worry about splitting them up appropriately. 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 connections. 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 are 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 appropriate 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 triangle. It should be clear that the routing table at router A could look like: root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0 root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0 root# 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 ethernet 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 segment 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: root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0 root# /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. An example of this would be if you plan to use IP Masquerading. 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. Server programs listen on network ports. Network ports are a means of addressing a particular service on any particular host and are how a server knows the difference between an incoming telnet connection and an incoming ftp connection. The remote user establishes a network connection to your machine and the server program, the network daemon program, 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 specializes 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. Any service port may be configured for either of the tcp or udp protcols. 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 separated 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 different from an entry of 18/udp and that there is no technical reason why the same service needs to exist on both. Normally common sense prevails and it is only if a particular service is available 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 an old Debian distribution: # /etc/services: # $Id$ # # 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 convenience 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 In the real world, the actual file is always growing as new services are being created. If you fear your own copy is incomplete, I'd suggest to copy a new /etc/services from a recent distribution. 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 separated 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 minimized. Typically this field is set to root though, because many servers require root privileges 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$ # # 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 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, including the Security-HOWTO 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 file 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 search 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 appropriate 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 maximize 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, and (more concisely) in a later section of this document. 5.10.7. Other suggestions. Here are some other, potentially religious 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. IP- and Ethernet-Related Information This section covers information specific to Ethernet and IP. These subsections have been grouped together because I think they are the most interesting ones in the formerly-called ``Technology Specific'' Section. Anyone with a LAN should be able to benefit from these goodies. 6.1. 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. By default, the Linux kernel only probes for one Ethernet device, you need to pass command line arguments to the kernel in order to force detection of furter boards. To learn how to make your ethernet card(s) 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 (which most distributions already do for you, if you configured them to support your ethernet): root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up root# route add -net 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. 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.8.1. A tunneled network configuration. 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 encapsula­ tion, 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 net­ work A to connect to any host on network B, just as if they were prop­ erly connected to the Internet with a network route. IPIP encapsula­ tion 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 a script like the following: #!/bin/sh PATH=/sbin:/usr/sbin mask=255.255.255.0 remotegw=fff.ggg.hhh.iii # # Ethernet configuration ifconfig eth0 192.168.1.1 netmask $mask up route add -net 192.168.1.0 netmask $mask 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 $mask gw $remotegw tunl0 Linux router `B' would be configured with a similar script: #!/bin/sh PATH=/sbin:/usr/sbin mask=255.255.255.0 remotegw=aaa.bbb.ccc.ddd # # Ethernet configuration ifconfig eth0 192.168.2.1 netmask $mask up route add -net 192.168.2.0 netmask $mask 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 $mask gw $remotegw tunl0 The command: route add -net 192.168.1.0 netmask $mask gw $remotegw 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.8.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: #!/bin/sh PATH=/sbin:/usr/sbin mask=255.255.255.0 remotegw=fff.ggg.hhh.iii # # Ethernet configuration ifconfig eth0 192.168.1.1 netmask $mask up route add -net 192.168.1.0 netmask $mask 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 $remotegw 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: #!/bin/sh PATH=/sbin:/usr/sbin mask=255.255.255.0 remotegw=aaa.bbb.ccc.ddd # # 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 $mask gw $remotegwtunl0 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.9. 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 masquerade 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 | / | | | / | -------- - - Masquerading with IPFWADM The most relevant commands for this configuration are: # Network route for ethernet route add -net 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 Masquerading with IPCHAINS This is similar to using IPFWADM but the command structure has changed: # Network route for ethernet route add -net 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. ipchains -A forward -s 192.168.1.0/24 -j MASQ You can get more information on the Linux IP Masquerade feature from the IP Masquerade Resource Page. Also, a very detailed document about masquesrading is the ``IP-Masquerade mini-HOWTO'' (which also intructs to configure other OS's to run with a Linux masquerade server). 6.10. 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 be useful is as follows: root# ipfwadm -I -a accept -D 0/0 telnet -r 2323 This example will cause any connection attempts to port telnet (23) on any host to be redirected to port 2323 on this host. If you run a service on that port, you could forward telnet connections, log them or do whatever fits your need. A more interesting example is redirecting all http traffic through a local cache. However, the protocol used by proxy servers is different from native http: where a client connects to www.server.com:80 and asks for /path/page, when it connects to the local cache it contacts proxy.local.domain:8080 and asks for www.server.com/path/page. To filter an http request through the local proxy, you need to adapt the protocol by inserting a small server, called transproxy (you can find it on the world wide web). You can choose to run transproxy on port 8081, and issue this command: root# ipfwadm -I -a accept -D 0/0 80 -r 8081 The transproxy program, then, will receive all connections meant to reach external servers and will pass them to the local proxy after fixing protocol differences. 6.11. 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 16 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 complete, IPv6 implementation in the 2.2.* series kernels. If you wish to experiment with this next generation Internet technology, or have a requirement for it, then you should read the IPv6-FAQ which is available from www.terra.net. 6.12. 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.13. 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. Please check the Multicast-HOWTO for more information on Multicast support in Linux. 6.14. NAT - Network Address Translation The IP Network Address Translation facility is pretty much the standardized big brother of the Linux IP Masquerade facility. It is specified in some detail in RFC-1631 at your nearest RFC archive. NAT provides features that IP-Masquerade does not that make it eminently more suitable for use in corporate firewall router designs and larger scale installations. An alpha implementation of NAT for Linux 2.0.29 kernel has been developed by Michael.Hasenstein, Michael.Hasenstein@informatik.tu- chemnitz.de. Michaels documentation and implementation are available from: Linux IP Network Address Web Page Newer Linux 2.2.x kernels also include some NAT functionality in the routing algorithm. 6.15. Traffic Shaper - Changing allowed bandwidth The traffic shaper is a driver that creates new interface devices, those devices are traffic-limited in a user-defined way, they rely on physical network devices for actual transmission and can be used as outgoing routed for network traffic. The shaper was introduced in Linux-2.1.15 and was backported to Linux-2.0.36 (it appeared in 2.0.36-pre-patch-2 distributed by Alan Cox, the author of the shaper device and maintainer of Linux-2.0). The traffic shaper can only be compiled as a module and is configured by the shapecfg program with commands like the following: shapecfg attach shaper0 eth1 shapecfg speed shaper0 64000 The shaper device can only control the bandwidth of outgoing traffic, as packets are transmitted via the shaper only according to the routing tables; therefore, a ``route by source address'' functionality could help in limiting the overall bandwidth of specific hosts using a Linux router. Linux-2.2 already has support for such routing, if you need it for Linux-2.0 please check the patch by Mike McLagan, at ftp.invlogic.com. Refer to Documentationnetworking/shaper.txt for further information about the shaper. If you want to try out a (tentative) shaping for incoming packets, try out rshaper-1.01 (or newer), from ftp.systemy.it. 6.16. Routing in Linux-2.2 The latest versions of Linux, 2.2 offer a lot of flexibility in routing policy. Unfortunately, you have to wait for the next version of this howto, or go read the kernel sources. There are four categories of high level abstract connections: - point-to-point - point-to-multipoint - multipoint-to-point - multipoint-to-multipoint In network terminology the word "point" is usually synonymous with "device". 4. Networking hardware supported Linux supports a great variety of networking hardware, including some obsolete equipment. Some interesting documents: · Hardware HOWTO · Ethernet HOWTO 6.9. Authentication There are also various ways of authenticating users in mixed networks. · For Linux/Windows NT:http://www.mindware.com.au/ftp/smb-NT- verify.1.1.tar.gz · The PAM (pluggable authentication module) which is a flexible method of Unix authentication: PAM library . · Finally, LDAP in Linux 7. Remote execution of applications One of the most amazing features of Unix (yet one of the most unknown to new users) is its great support for remote and distributed execution of applications. 7.2. Remote commands In Unix, and in particular in Linux, remote commands exist that allow for interaction with other computers from the shell prompt. Examples are: rlogin, which allows for login in a remote machine in a similar way to telnet, rcp, which allows for the remote transfer of files among machines, etc. Finally, the remote shell command rsh allows the execution of a command on a remote machine without actually logging onto that machine. 2.2. What makes Linux different? Why work on Linux? Linux is generally cheaper (or at least no more expensive) than other operating systems and is frequently less problematic than many commercial systems. But what makes Linux different is not its price (after all, why would anyone want an OS - even a free one - if it is not good enough?) but its outstanding capabilities: · Linux is a true 32-bit multitasking operating system, robust and capable enough to be used in organizations ranging from universities to large corporations. · It runs on hardware ranging from low-end 386 boxes to massive ultra-parallel machines in research centres. · Out-of-the-box versions are available for Intel, Sparc, and Alpha architectures, and experimental support exists for Power PC and embedded systems, among others such as SGI, Ultra Sparc, AP1000+, Strong ARM, and MIPS R3000/R4000. · Finally, when it comes to networking, Linux is choice. Not only because networking is tightly integrated with the OS itself and a plethora of applications is freely available, but for the robustness under heavy loads that can only be achieved after years of debugging and testing in an Open Source project. 5. File Sharing and Printing The primary purpose of many PC based Local Area Networks is to provide file and printer sharing services to the users. Linux as a corporate file and print server turns out to be a great solution. 8. Network Interconnection Linux networking is rich in features. A Linux box can be configured so it can act as a router, bridge, etc... Some of the available options are described below. Common Network Protocols As mentioned earlier, network protocols are sets of rules and standards for data commnucations over networks. A network architecture (such as Ethernet) can support multiple protocols, and even multiple protocols currently. Protocols are typically organized into protocol suites, or sets of compatible protocols. These are also referred to as protocol stacks. A stack includes protocols for several different layers of the OSI model. Lower-level protocols provide services for use by upper-level protocols. The highest level protocols communicate directly with applications. Communications protocols can be divided into two basic types, connection-orientated and connectionless: - Connection-orientated protocols establish a connection, or virtual circuit, before, communicating, and disconnect it when finished. Connection-orientated protocols generally have a lower speed due to the bandwidth used for session maintenance. - Connectionless protocols do not establish a virtual circuit. Data is sent withoug establishing a connection, and may be sent at any time. These protocols have low overhead, and are generally used where speed is a high priority. Another distinction between protocols is their reliablity. Some protocols send acknowledgements for each transmitted packet. This makes for a more reliable connection, but leaves less bandwidth for actual data transmission. These are called reliable protocols. Protocols without acknowledgements are known as unreliable, although this does not necessarily mean they are undependable. Common Network Protocols and Characteristics Protocol Overhead Routable? Typical Application TCP/IP Medium Yes Large networks; Internet and UNIX compatibility NetBEUI Low No Small Windows-based networks IPX/SPX Medium Yes NetWare compatiblity Appletalk Medium Yes Apple Macintosh compatiblity DLC Medium No IBM mainframe compatiblity; some network printers Common WAN Architectures - Circuit Switching Circuit switching is a connection-orientated method of communication. A circuit is dedicated to the connection, and a connection must be specifically established when needed and disconnected when not needed. - Message Switching Message switching is a connectionless method of communication. Individual message units are sent across the network with routing information without establishing a dedicated nework. - Packet Switching Packet switching is a more efficient connectionless communication method. Packets (smaller than message units) are sent individually and can follow different routes to their destination. Some packet switching systems use virtual circuits for a logical connection, but don't use a dedicated physical connection. Switched networks are generally less expensive and allow networking with multiple locations; non-switched lnks are usually dedicated between two locations and provide more consistent available bandwidth. WAN connections typically require different (and more expensive) hardware than LAN connections. Typical WAN equipment includes specialized types of routers, CSU/DSUs (Channel Service Unit/Digital Service Unit), and multiplexers, which combine multiple signals (such as voice and data) for tranmissions on a single WAN connection. A number of WAN technologies and public networks are available. FDDI, explained earlier in this chapter, can also be used for wide-are networks. The common WAN technologies are described in detail in the sections below. 3.5. WAN Networking: X.25, Frame-relay, etc... Several third parties provide T-1, T-3, X.25 and Frame Relay products for Linux. Generally special hardware is required for these types of connections. Vendors that provide the hardware also provide the drivers with protocol support. · WAN resources for Linux: http://www.secretagent.com/networking/wan.html ]]> >Start Binh Attentuation is a physical phenomenon which causes a signal to gradually lose power as it propogates through a medium. This is mainly due to due to two factors, signal dispersion and signal absorption. Unfortunately, there is some noise which generates a constant noise power, N, and so eventually, as the signal travels a long enough distance, the signal poower will decrease to a value less than the noise power. This is similar to the effect observed when you are attempting to communicate with another person with your natural voice. As the person moves further away the voice is harder to hear as the signal power spreads out and is absorbed by obstacles, etc.... Attenuation is generally a factor of distance and frequency. This is very much in accordance with our current laws of physics. The intensity if a signal is inversely proportional to the inverse square of the the signal distance. You'll often notice that in military applications the usage of broad frequency radar for spotting targets over great ranges and then the utilisation of higher frequency signals as greater precision positioning is required. Most transmission medium will have a rating which gives the attenuation as a function of frequency and distance, eg. the attenuation per kilometer. Ideally the attenuation is zero because this represents no loss in the signal power. This leads us to the issue of digital transmission versus analogue transmission. The primary advantage of digital transmission over analogue transmission is the reduction in noise. The digital transmission system reduces noise over successive transmissions because small variations in the signal can be rounded off to the nearest level. Analogue transmission systems need to filter out the noise, but the filter itself can sometimes be a source of noise and generally, noise can accumulate to an unacceptable level in an analogue tranmission system. Consider two types of repeater to understand of digital transmission. In the first instance (analogue) the situation is roughly synonymous with someone who doesn't know Korean and who is trying to relay a message from one Korean to another. It can be done if the person simply repeats the sounds that are heard. In digital tranmission repitition would be more along the lines of someone knowing Korean and actually "re-saying" what was heard (perhaps even correcting for errors in what was heard). Systems which transmit ananlogue signals (such as the calssical radio and television broadcasting systems) can use one of three well known techniques, Amplitude Modulation (AM), Frequency Modulation (FM), and Phase Modulation (PM). AM works by varying the amplitude of a signal to code the bit stream. FM works by varying frequency of a signal to code the bit stream. PM works by varying the phase of a signal to code the bit stream. To allow two transmission medium (usually of the same type) to be directly connected the concept of a switch was developed. A general switch can be built from many basic switches and is somtimes referred to as a switching fabric. A lot of research and development contines in an attempt to build better switching fabrics. A circuit switched network operates at the physical layer to provide a single, continuous transmission medium between any two hosts or end devices in the network. Circuit switching is perhaps the most straightforward approach to building communication network. Computer networks didn't actually evolve using circuit switching though circuit switching is being considered for certain computer applications such as video and voice. Because circuit switching constucts a single long transmission medium with at most analogue repeaters the end devices (in this case telephones) are able to modulate the signal on the medium however they choose. This is also why two modems can communicate with one another over a telephone network. Multiplexing is used to share a single transmission medium among a number of individual transmissions. The demultiplexer just undoes what the multiplexer does. Therefore the multiplexer and demultiplexer must directly cooperate. Multiplexers and demultiplexers are not so much network devices are not so much network devices but functionality that is contained within a network device. Switches (in the sense described here) may be similarly categorized in this way. The transmission medium can be multiplexed in the time domain, called TDM (Time Domain Multiplexing), using a simple switch and clocked control. Because of delays incurred in the transmission line, the clocks may need to be out of phase with one another. See that with the TDM, the shared medium must be able to transmit at a bit rate that equals (or is better than) the sum of input bit rates. The swithes must also be able to switch fast enough. The previous example was assuming a synchronous transmission mode. In general, bit streams can be divided into DU's called cells. Cells are fixed in length so that the receiver knows when one cell finishes and the next cell begins. Alternatively there is ATM (Asynchronous Transmission Mode, ATM is also the name given to a popular network layer device that uses this multiplexing technique.), where signals are irregularly multiplexed. How does the receiver know what order the signals were multiplexed in? Additional information is needed in the multiplexed signal. One way is to add a header or label to the front of each cell. The header identifies the cell. Using a header means using additional bits, which becomes overhead. Thus, to reduce the overhead the cells should be reasonably larger than the header. Cells for modern ATM transmission systems are about 50 butes in size. Because modulators can transmit signals at different frequency bands, it is possible to transmit several signals at one, with each signal transmitted within a different frequency band. In this case the different signals have been frequency domain multiplexed. This is known as FDM, (Frequency Domain Multiplexing). Similar to FDM, WDM (Wavelength Division Multiplexing) uses each wavelength of light to transmit a signal. WDM is for fiber optic systems. The number of wavelengths per fiber, currently available, is about 300. Each wavelength can carry about 10Gbps. This makes 3Tbps. AT&T predict that up to 1024 wavelengths may be available in the future. The hub/optical hub is clearly an analogue device - input signals are reflected to all outputs. It is also called passive, because it does not introduce any power to the signal (otherwise it would be called active). Considering the hub as a device which repeats input from an incoming signal on all outputs is quite simplistic however the basic function should be understandable. When examining the Data-link layer it will become clearer how computers communicate using a hub. For wireless communication, the transmission of each device is implicity received by every other device. This is an implicit hub. Wireless communication usually takes place using the IEEE 802.11 standard which specifies an unlicensed radio spectrum at 2.4GHz and provides wireless Ethernet access at 11Mbps. There is also some spectrum allocated between 5GHz ad 6GHz that provides 54Mbps. Sophisticated codes and frequency sharing technology is used to maximise the usage of this communication medium. This topic is strictly concerned with Medium Access Control, to be discussed later. Wireless also allows point-to-point communication in the sense that each point-to-point link or channel is a dedicated frequency range that no other pair of devices will use. Analogue telephone networks use conventional circuit switching networks to construct a connection between two telephones. You have seen that a modem converts digital signals to analogue to be transmitted over an analogue telephone network. Digital telephone networks use a codec or coder-decoder to convert analogue telephone (or modem) signals into digital form! This is so that new digital techniques can be used within a conventionally an analogue network, ie. transparently to the analogue devices. The codec is used to convert from analogue to digital and digital to analogue. Enough is known now to consider the complexity of a large digital network that supporst communication of various kinds. As technologies improve some networks become more dominant than others. In todays world we see a significant shift towards computer networks, away from conventional telecommunication networks. This doesn't mean the end of telecommunications, but rather a collapse of outdated technological layers towards the "core" networks that they connect to. It will become more apparent to you as we progres through this subject that networks can be built on top of other networks which are themseleves built on top of ther networks. The size and scale of a network can vary substantially from Local Area Networks (LANs) which usually connect 10-15 computers in a small area (usually a small building) to Metropolitan Area Networks (MANs) which use long-distance links (such as telephone lines or dedicated media) to connect two or more locations within a single city or metropolitan area to Wide Area Networks (WANs) which use the same technology as MANs to connect computers in distant locations but in different cities or even different countries. There are two basic types of networks: client-server networks, which use dedicated servers; and peer-to-peer networks, which (normally) share files between workstations. Server-based networks (also called client-server networks) use a dedicated server machine which provides files and printers to network workstations called clients. Client machines are simply used by network users, and usually do not share files or printers. The key benefit of the server-client model is in centralization. There is only a single point of control for network acccess, security, and management. The disadvantages of a server-based network are the higher cost of dedicated servers and network operating systems, as well as the increased level of administrative effort required. Conversely, peer-to-peer networks consist solely of workstations called peers. Each workstation can be used by a user, and can also make shared files or printers available to users at other workstations. The advantages of peer networks include their ease of installation and use, their relative inexpensiveness in comparison with server-based networks (since a dedicated server is not required) and the fact that an administrator mightn't be required (if users are able to manage resource sharing). The primary disadvantage of peer networks is the lack of a central control mechanism. Each user controls access to their own workstation's shared files and printers. In a large scale network, such a security policy is difficult to manage without compromising security. Further, a workstation that is being accessed by peers can also be slowed down, inconveniencing the user at that workstation. Hence, its clear that this system is best suited to smaller networks. Internet is not described as a network of any single kind. It can be construed as a large set of heterogenous networks that support a certain set of protocols (TCP/IP) and provide certain common services. A good way to learn about the Internet is to use the Internet! Linux is a great platform to act as an Intranet / Internet server. The term Intranet refers to the application of Internet technologies inside an organisation mainly for the purpose of distributing and making available information inside the company. Internet and Intranet services offered by Linux include mail, news, WWW servers and many more that will be outlined further on in this document.