Ftp Web Hosting - J2Ee Hosting Sun Java Developing Blog

Chapter 9 - TCP/IP Firewall Security is increasingly important for companies and individuals alike. The Internet has provided them with a powerful tool to distribute information about themselves and obtain information from others, but it has also exposed them to dangers that they have previously been exempt from. Computer crime, information theft, and malicious damage are all potential dangers. An unauthorized and unscrupulous person who gains access to a computer system may guess system passwords or exploit the bugs and idiosyncratic behavior of certain programs to obtain a working account on that machine. Once they are able to log in to the machine, they may have access to information that may be damaging, such as commercially sensitive information like marketing plans, new project details, or customer information databases. Damaging or modifying this type of data can cause severe setbacks to the company. The safest way to avoid such widespread damage is to prevent unauthorized people from gaining network access to the machine. This is where firewalls come in. WARNING: Constructing secure firewalls is an art. It involves a good understanding of technology, but equally important, it requires an understanding of the philosophy behind firewall designs. We won’t cover everything you need to know in this book; we strongly recommend you do some additional research before trusting any particular firewall design, including any we present here. There is enough material on firewall configuration and design to fill a whole book, and indeed there are some good resources that you might like to read to expand your knowledge on the subject. Two of these are: Building Internet Firewalls by D. Chapman and E. Zwicky (O’Reilly). A guide explaining how to design and install firewalls for Unix, Linux, and Windows NT, and how to configure Internet services to work with the firewalls. Firewalls and Internet Security by W. Cheswick and S. Bellovin (Addison Wesley). This book covers the philosophy of firewall design and implementation. We will focus on the Linux-specific technical issues in this chapter. Later we will present a sample firewall configuration that should serve as a useful starting point in your own configuration, but as with all security-related matters, trust no one. Double check the design, make sure you understand it, and then modify it to suit your requirements. To be safe, be sure. Methods of Attack As a network administrator, it is important that you understand the nature of potential attacks on computer security. We’ll briefly describe the most important types of attacks so that you can better understand precisely what the Linux IP firewall will protect you against. You should do some additional reading to ensure that you are able to protect your network against other types of attacks. Here are some of the more important methods of attack and ways of protecting yourself against them: Unauthorized access This simply means that people who shouldn’t use your computer services are able to connect and use them. For example, people outside your company might try to connect to your company accounting machine or to your NFS server. There are various ways to avoid this attack by carefully specifying who can gain access through these services. You can prevent network access to all except the intended users. Exploitation of known weaknesses in programs Some programs and network services were not originally designed with strong security in mind and are inherently vulnerable to attack. The BSD remote services (rlogin, rexec, etc.) are an example. The best way to protect yourself against this type of attack is to disable any vulnerable services or find alternatives. With Open Source, it is sometimes possible to repair the weaknesses in the software.

ever the telephone call supporting the link fails. Persistent dialing ensures that the link is always available by automatically rebuilding the connection if it fails. You might be fortunate to not have to pay for your telephone calls; perhaps they are local and free, or perhaps they’re paid by your company. The persistent dialing option is extremely useful in this situation. If you do have to pay for your telephone calls, then you have to be a little careful. If you pay for your telephone calls on a time- charged basis, persistent dialing is almost certainly not what you want, unless you’re very sure you’ll be using the connection fairly steadily twenty-four hours a day. If you do pay for calls, but they are not time charged, you need to be careful to protect yourself against situations that might cause the modem to endlessly redial. The pppd daemon provides an option that can help reduce the effects of this problem. To enable persistent dialing, you must include the persist option in one of your pppd options files. Including this option alone is all you need to have pppd automatically invoke the command specified by the connect option to rebuild the connection when the link fails. If you are concerned about the modem redialing too rapidly (in the case of modem or server fault at the other end of the connection), you can use the holdoff option to set the minimum amount of time that pppd will wait before attempting to reconnect. This option won’t solve the problem of a fault costing you money in wasted phone calls, but it will at least serve to reduce the impact of one. A typical configuration might have persistent dialing options that look like this: persist holdoff 600 The holdoff time is specified in seconds. In our example, pppd waits a full five minutes before redialing after the call drops out. It is possible to combine persistent dialing with demand dialing, using idle to drop the link if it has been idle for a specified period of time. We doubt many users would want to do so, but this scenario is described briefly in the pppd manual page, if you’d like to pursue it.

4. Configure pppd as server as described in this section. 5. Consider routing. Will you need to provide a network route to callers? Routing can be performed using the ip-up script. Demand Dialing When there is IP traffic to be carried across the link, demand dialing causes your telephone modem to dial and to establish a connection to a remote host. Demand dialing is most useful when you can’t leave your telephone line permanently switched to your Internet provider. For example, you might have to pay timed local calls, so it might be cheaper to have the telephone line switched on only when you need it and disconnected when you aren’t using the Internet. Traditional Linux solutions have used the diald command, which worked well but was fairly tricky to configure. Versions 2.3.0 and later of the PPP daemon have built-in support for demand dialing and make it very simple to configure. You must use a modern kernel for this to work, too. Any of the later 2.0 kernels will work just fine. To configure pppd for demand dialing, all you need to do is add options to your options file or the pppd command line. The following table summarizes the options related to demand dialing: Option Description demand This option specifies that the PPP link should be placed in demand dial mode. The PPP network device will be created, but the connect command will not be used until a datagram is transmitted by the local host. This option is mandatory for demand dialing to work. active- This option allows you to specify which data packets are to be considered active traf filterex fic. Any traffic matching the specified rule will restart the demand dial idle timer, pression ensuring that pppd waits again before closing the link. The filter syntax has been borrowed from the tcpdump command. The default filter matches all datagrams. holdoffn This option allows you to specify the minimum amount of time, in seconds, to wait before reconnecting this link if it terminates. If the connection fails while pppdbelieves it is in active use, it will be re-established after this timer has expired. This timer does not apply to reconnections after an idle timeout. idlen If this option is configured, pppd will disconnect the link whenever this timer expires. Idle times are specified in seconds. Each new active data packet will reset the timer. A simple demand dialing configuration would therefore look something like this: demand holdoff 60 idle 180 This configuration would enable demand dialing, wait 60 seconds before re-establishing a failed connection, and drop the link if 180 seconds pass without any active data on the link. Persistent Dialing Persistent dialing is what people who have permanent dialup connections to a network will want to use. There is a subtle difference between demand dialing and persistent dialing. With persistent dialing, the connection is automatically established as soon as the PPP daemon is started, and the persistent aspect comes into play when

and give it a script or program as a login shell that invokes pppd with these options. Alternatively, if you intend to support PAP or CHAP authentication, you can use the mgetty program to support your modem and exploit its “/AutoPPP/” feature. To build a server using the login method, you add a line similar to the following to your /etc/passwd file:58 ppp:x:500:200:Public PPP Account:/tmp:/etc/ppp/ppplogin If your system supports shadow passwords, you also need to add an entry to the /etc/shadow file: ppp 10913:0:99999:7::: Of course, the UID and GID you use depends on which user you wish to own the connection, and how you’ve created it. You also have to set the password for the mentioned account using the passwd command. The ppplogin script might look like this: #!/bin/sh # ppplogin -script to fire up pppd on login mesg n stty -echo exec pppd -detach silent modem crtscts The mesg command disables other users from writing to the tty by using, for instance, the write command. The stty command turns off character echoing. This command is necessary; otherwise, everything the peer sends would be echoed back to it. The most important pppd option given is -detach because it prevents pppd from detaching from the controlling tty. If we didn’t specify this option, it would go to the background, making the shell script exit. This in turn would cause the serial line to hang up and the connection to be dropped. The silent option causes pppd to wait until it receives a packet from the calling system before it starts sending. This option prevents transmit timeouts from occurring when the calling system is slow in firing up its PPP client. The modem option makes pppd drive the modem control lines of the serial port. You should always turn this option on when using pppd with a modem. The crtscts option turns on hardware handshake. Besides these options, you might want to force some sort of authentication, for example, by specifying auth on pppd’s command line or in the global options file. The manual page also discusses more specific options for turning individual authentication protocols on and off. If you wish to use mgetty, all you need to do is configure mgetty to support the serial device your modem is connected to (see “Configuring the mgetty Daemon” for details), configure pppd for either PAP or CHAP authentication with appropriate options in its options file, and finally, add a section similar to the following to your /etc/mgetty/login.config file: # Configure mgetty to automatically detect incoming PPP calls and invoke # the pppd daemon to handle the connection. # /AutoPPP/ -ppp /usr/sbin/pppd auth -chap +pap login The first field is a special piece of magic used to detect that an incoming call is a PPP one. You must not change the case of this string; it is case sensitive. The third column is the username that appears in who listings when someone has logged in. The rest of the line is the command to invoke. In our example, we’ve ensured that PAP authentication is required, disabled CHAP, and specified that the system passwd file should be used for authenticating users. This is probably similar to what you’ll want. Remember, you can specify the options in the options file or on the command line if you prefer. Here is a small checklist of tasks to perform and the sequence you should perform them to get PPP dial in working on your machine. Make sure each step works before moving on to the next: 1. Configure the modem for auto-answer mode. On Hayes-compatible modems, this is performed using a command like ATS0=3. If you’re going to be using the mgetty daemon, this isn’t necessary. 2. Configure the serial device with a getty type of command to answer incoming calls. A commonly used getty variant is mgetty. 3. Consider authentication. Will your callers authenticate using PAP, CHAP, or system login? The useraddor adduser utility, if you have it, will simplify this task.

quest. When it is necessary for us to send our credentials to the peer, pppd uses the secret that has a user field equal to the local username and the server field equal to the remote hostname. A sample PAP secrets file might look like this: # /etc/ppp/pap-secrets # # user server secret addrs vlager-pap c3po cresspahl vlager.vbrew.com c3po vlager DonaldGNUth c3po.lucas.com The first line is used to authenticate ourselves when talking to c3po. The second line describes how a user named c3po has to authenticate itself with us. The name vlager-pap in the first column is the username we send to c3po. By default, pppd picks the local hostname as the username, but you can also specify a different name by giving the user option followed by that name. When picking an entry from the pap-secrets file to identify us to a remote host, pppd must know the remote host’s name. As it has no way of finding that out, you must specify it on the command line using the remotename keyword followed by the peer’s hostname. To use the above entry for authentication with c3po, for example, we must add the following option to pppd’s command line: # pppd … remotename c3po user vlager-pap In the fourth field of the PAP secrets file (and all following fields), you can specify what IP addresses are allowed for that particular host, just as in the CHAP secrets file. The peer will be allowed to request only addresses from that list. In the sample file, the entry that c3po will use when it dials in — the line where c3po is the client -allows it to use its real IP address and no other. Note that PAP is a rather weak authentication method, you should use CHAP instead whenever possible. We will therefore not cover PAP in greater detail here; if you are interested in using it, you will find more PAP features in the pppd(8) manual page. Debugging Your PPP Setup By default, pppd logs any warnings and error messages to syslog’s daemon facility. You have to add an entry to syslog.conf that redirects these messages to a file or even the console; otherwise, syslog simply discards them. The following entry sends all messages to /var/log/ppp-log: daemon.* /var/log/ppp-log If your PPP setup doesn’t work right away, you should look in this log file. If the log messages don’t help, you can also turn on extra debugging output using the debug option. This output makes pppd log the contents of all control packets sent or received to syslog. All messages then go to the daemon facility. Finally, the most drastic way to check a problem is to enable kernel-level debugging by invoking pppd with the kdebug option. It is followed by a numeric argument that is the sum of the following values: 1 for general debug messages, 2 for printing the contents of all incoming HDLC frames, and 4 to make the driver print all outgoing HDLC frames. To capture kernel debugging messages, you must either run a syslogd daemon that reads the /proc/kmsg file, or the klogd daemon. Either of them directs kernel debugging to the syslogkernel facility. More Advanced PPP Configurations While configuring PPP to dial in to a network like the Internet is the most common application, there are those of you who have more advanced requirements. In this section we’ll talk about a few of the more advanced configurations possible with PPP under Linux. PPP Server Running pppd as a server is just a matter of configuring a serial tty device to invoke pppd with appropriate options when an incoming data call has been received. One way to do this is to create a special account, say ppp,

The CHAP Secrets File When it has to authenticate itself with a server using CHAP, pppd searches the chap-secrets file for an entry with the client field equal to the local hostname, and the server field equal to the remote hostname sent in the CHAP challenge. When requiring the peer to authenticate itself, the roles are simply reversed: pppd then looks for an entry with the client field equal to the remote hostname (sent in the client’s CHAP response), and the server field equal to the local hostname. The following is a sample chap-secrets file for vlager:56 # CHAP secrets for vlager.vbrew.com # # client server secret addrs #——————————————————————— vlager.vbrew.com c3po.lucas.com “Use The Source Luke” vlager.vbrew.com c3po.lucas.com vlager.vbrew.com “arttoo! arttoo!” c3po.lucas.com * vlager.vbrew.com “TuXdrinksVicBitter” pub.vbrew.com When vlager establishes a PPP connection with c3po, c3po asks vlager to authenticate itself by sending a CHAP challenge. pppdon vlager then scans chap-secrets for an entry with the client field equal to vlager.vbrew.com and the server field equal to c3po.lucas.com, and finds the first line shown in the example.57 It then produces the CHAP response from the challenge string and the secret (Use The Source Luke), and sends it off to c3po. pppd also composes a CHAP challenge for c3po containing a unique challenge string and its fully qualified hostname, vlager.vbrew.com. c3po constructs a CHAP response in the way we discussed, and returns it to vlager. pppd then extracts the client hostname (c3po.vbrew.com) from the response and searches the chap- secrets file for a line matching c3po as a client and vlager as the server. The second line does this, so pppd combines the CHAP challenge and the secret arttoo! arttoo!, encrypts them, and compares the result to c3po’s CHAP response. The optional fourth field lists the IP addresses that are acceptable for the client named in the first field. The addresses can be given in dotted quad notation or as hostnames that are looked up with the resolver. For instance, if c3po asks to use an IP address during IPCP negotiation that is not in this list, the request is rejected, and IPCP is shut down. In the sample file shown above, c3po is therefore limited to using its own IP address. If the address field is empty, any addresses are allowed; a value of “-” prevents the use of IP with that client altogether. The third line of the sample chap-secrets file allows any host to establish a PPP link with vlager because a client or server field of * is a wildcard matching any hostname. The only requirements are that the connecting host must know the secret and that it must use the IP address associated with pub.vbrew.com. Entries with wildcard hostnames may appear anywhere in the secrets file, since pppd will always use the best match it can find for the server/client pair. pppd may need some help forming hostnames. As explained before, the remote hostname is always provided by the peer in the CHAP challenge or response packet. The local hostname is obtained by calling the gethostname( 2) function by default. If you have set the system name to your unqualified hostname, you also have to provide pppd with the domain name using the domain option: # pppd … domain vbrew.com This provision appends the Brewery’s domain name to vlager for all authentication related activities. Other options that modify pppd’s idea of the local hostname are usehostname and name. When you give the local IP address on the command line using local:remote and local as a name instead of a dotted quad, pppd uses this as the local hostname. The PAP Secrets File The PAP secrets file is very similar to CHAP’s. The first two fields always contain a username and a server name; the third holds the PAP secret. When the remote host sends its authentication information, pppd uses the entry that has a server field equal to the local hostname, and a user field equal to the username sent in the re 56 The double quotes are not part of the secret; they merely serve to protect the whitespace within it. 57 This hostname is taken from the CHAP challenge.

not allow foreign hosts to use any IP address they choose, but restrict them to at most a few. The following section will deal with these topics in detail. Authentication with PPP With PPP, each system may require its peer to authenticate itself using one of two authentication protocols: the Password Authentication Protocol (PAP), and the Challenge Handshake Authentication Protocol (CHAP). When a connection is established, each end can request the other to authenticate itself, regardless of whether it is the caller or the callee. In the description that follows, we will loosely talk of “client” and “server” when we want to distinguish between the system sending authentication requests and the system responding to them. A PPP daemon can ask its peer for authentication by sending yet another LCP configuration request identifying the desired authentication protocol. PAP Versus CHAP PAP, which is offered by many Internet Service Providers, works basically the same way as the normal login procedure. The client authenticates itself by sending a username and a (optionally encrypted) password to the server, which the server compares to its secrets database.55 This technique is vulnerable to eavesdroppers, who may try to obtain the password by listening in on the serial line, and to repeated trial and error attacks. CHAP does not have these deficiencies. With CHAP, the server sends a randomly generated “challenge” string to the client, along with its hostname. The client uses the hostname to look up the appropriate secret, combines it with the challenge, and encrypts the string using a one-way hashing function. The result is returned to the server along with the client’s hostname. The server now performs the same computation, and acknowledges the client if it arrives at the same result. CHAP also doesn’t require the client to authenticate itself only at startup time, but sends challenges at regular intervals to make sure the client hasn’t been replaced by an intruder, for instance by switching phone lines, or because of a modem configuration error that causes the PPP daemon not to notice that the original phone call has dropped out and someone else has dialed in. pppd keeps the secret keys for PAP and CHAP in two separate files called /etc/ppp/pap-secrets and /etc/ppp/chap-secrets. By entering a remote host in one or the other file, you have fine control over whether PAP or CHAP is used to authenticate yourself with your peer, and vice versa. By default, pppd doesn’t require authentication from the remote host, but it will agree to authenticate itself when requested by the remote host. Since CHAP is so much stronger than PAP, pppd tries to use the former whenever possible. If the peer does not support it, or if pppdcan’t find a CHAP secret for the remote system in its chap- secrets file, it reverts to PAP. If it doesn’t have a PAP secret for its peer either, it refuses to authenticate altogether. As a consequence, the connection is shut down. You can modify this behavior in several ways. When given the auth keyword, pppd requires the peer to authenticate itself. pppd agrees to use either CHAP or PAP as long as it has a secret for the peer in its CHAP or PAP database. There are other options to turn a particular authentication protocol on or off, but I won’t describe them here. If all systems you talk to with PPP agree to authenticate themselves with you, you should put the auth option in the global /etc/ppp/options file and define passwords for each system in the chap-secrets file. If a system doesn’t support CHAP, add an entry for it to the pap-secrets file. That way, you can make sure no unauthenticated system connects to your host. The next two sections discuss the two PPP secrets files, pap-secrets and chap-secrets. They are located in /etc/ppp and contain triplets of clients, servers, and passwords, optionally followed by a list of IP addresses. The interpretation of the client and server fields is different for CHAP and PAP, and also depends on whether we authenticate ourselves with the peer, or whether we require the server to authenticate itself with us. “Secret” is just the PPP name for passwords. PPP secrets don’t have the same length limitation as Linux login passwords.

Initially, the async map is set to 0xffffffff — that is, all control characters will be escaped. This is a safe default, but is usually much more than you need. Each character that appears in the async map results in two characters being transmitted across the link, so escaping comes at the cost of increased link utilization and a corresponding performance reduction. In most circumstances, an async map of 0×0 works fine. No escaping is performed. The Maximum Receive Unit (MRU), signals to the peer the maximum size of HDLC frames we want to receive. Although this may remind you of the Maximum Transfer Unit (MTU) value, these two have little in common. The MTU is a parameter of the kernel networking device and describes the maximum frame size the interface is able to transmit. The MRU is more of an advice to the remote end not to generate frames larger than the MRU; the interface must nevertheless be able to receive frames of up to 1,500 bytes. Choosing an MRU is therefore not so much a question of what the link is capable of transferring, but of what gives you the best throughput. If you intend to run interactive applications over the link, setting the MRU to values as low as 296 is a good idea, so that an occasional larger packet (say, from an FTP session) doesn’t make your cursor “jump.” To tell pppd to request an MRU of 296, you give it the option mru 296. Small MRUs, however, make sense only if you have VJ header compression (it is enabled by default), because otherwise you’d waste a large amount of your bandwidth just carrying the IP header for each datagram. pppd also understands a couple of LCP options that configure the overall behavior of the negotiation process, such as the maximum number of configuration requests that may be exchanged before the link is terminated. Unless you know exactly what you are doing, you should leave these options alone. Finally, there are two options that apply to LCP echo messages. PPP defines two messages, Echo Request and Echo Response. pppd uses this feature to check if a link is still operating. You can enable this by using the lcpecho- interval option together with a time in seconds. If no frames are received from the remote host within this interval, pppd generates an Echo Request and expects the peer to return an Echo Response. If the peer does not produce a response, the link is terminated after a certain number of requests are sent. This number can be set using the lcp-echo-failure option. By default, this feature is disabled altogether. General Security Considerations A misconfigured PPP daemon can be a devastating security breach. It can be as bad as letting anyone plug their machine into your Ethernet (and that can be very bad). In this section, we discuss a few measures that should make your PPP configuration safe. NOTE: Root privilege is required to configure the network device and routing table. You will usually solve this by running pppd setuid root. However, pppd allows users to set various security-relevant options. To protect against any attacks a user may launch by manipulating pppd options, you should set a couple of default values in the global /etc/ppp/options file, like those shown in the sample file in “Using Options Files”, earlier in this chapter. Some of them, such as the authentication options, cannot be overridden by the user, and thus provide reasonable protection against manipulations. An important option to protect is the connect option. If you intend to allow non-root users to invoke pppd to connect to the Internet, you should always add the connect and noauth options to the global options file /etc/ppp/options. If you fail to do this, users will be able to execute arbitrary commands with root privileges by specifying the command as their connect command on the pppd line or in their personal options file. Another good idea is to restrict which users may execute pppd by creating a group in /etc/group and adding only those users who you wish to have the ability to execute the PPP daemon. You should then change group ownership of the pppd daemon to that group and remove the world execute privileges. To do this, assuming you’ve called your group dialout, you could use something like: # chown root /usr/sbin/pppd # chgrp dialout /usr/sbin/pppd # chmod 4750 /usr/sbin/pppd Of course, you have to protect yourself from the systems you speak PPP with, too. To fend off hosts posing as someone else, you should always require some sort of authentication from your peer. Additionally, you should

Argument Name Purpose $5 remote_addr The IP address of the remote end of the link in dotted quad notation In our case, the ip-up script may contain the following code fragment:54 #!/bin/sh case $5 in 172.16.3.1) # this is vbourbon route add -net 172.16.3.0 gw 172.16.3.1;; … esac exit 0 Similarly, /etc/ppp/ip-down can be used to undo any actions of ip-up after the PPP link has been taken down again. So in our /etc/ppp/ip-down script we would have a route command that removed the route we created in the /etc/ppp/ip-up script. However, the routing scheme is not yet complete. We have set up routing table entries on both PPP hosts, but so far none of the hosts on either network knows anything about the PPP link. This is not a big problem if all hosts at the subsidiary have their default route pointing at vbourbon, and all Brewery hosts route to vlager by default. If this is not the case, your only option is usually to use a routing daemon like gated. After creating the network route on vlager, the routing daemon broadcasts the new route to all hosts on the attached subnets. Link Control Options We already encountered the Link Control Protocol (LCP), which is used to negotiate link characteristics and test the link. The two most important options negotiated by LCP are the Asynchronous Control Character Map and the Maximum Receive Unit. There are a number of other LCP configuration options, but they are far too specialized to discuss here. The Asynchronous Control Character Map, colloquially called the async map, is used on asynchronous links, such as telephone lines, to identify control characters that must be escaped (replaced by a specific two-character sequence) to avoid them being interpreted by equipment used to establish the link. For instance, you may want to avoid the XON and XOFF characters used for software handshake because a misconfigured modem might choke upon receipt of an XOFF. Other candidates include Ctrl-l (the telnet escape character). PPP allows you to escape any of the characters with ASCII codes 0 through 31 by specifying them in the async map. The async map is a 32-bit-wide bitmap expressed in hexadecimal. The least significant bit corresponds to the ASCII NULL character, and the most significant bit corresponds to ASCII 31 decimal. These 32 ASCII characters are the control characters. If a bit is set in the bitmap, it signals that the corresponding character must be escaped before it is transmitted across the link. To tell your peer that it doesn’t have to escape all control characters, but only a few of them, you can specify an async map to pppd using the asyncmap option. For example, if only ^S and ^Q (ASCII 17 and 19, commonly used for XON and XOFF) must be escaped, use the following option: asyncmap 0×000A0000 The conversion is simple as long as you can convert binary to hex. Lay out 32 bits in front of you. The right- most bit corresponds to ASCII 00 (NULL), and the left-most bit corresponds to ASCII 32 decimal. Set the bits corresponding to the characters you want escaped to one, and all others to zero. To convert that into the hexadecimal number pppd expects, simply take each set of 4 bits and convert them into hex. You should end up with eight hexadecimal figures. String them all together and preprend “0x” to signify it is a hexadecimal number, and you are done. If we wanted to have routes for other sites created when they dial in, we’d add appropriate case statements to cover those in which the … appears in the example.

noipdefault option will stop pppd from trying to use the IP address associated with the hostname as the local address. If you want to set only the local address but accept any address the peer uses, simply leave out the remote_addr part. To make vlager use the IP address 130.83.4.27 instead of its own, give it 130.83.4.27: on the command line. Similarly, to set the remote address only, leave the local_addr field blank. By default, pppd will then use the address associated with your hostname. Routing Through a PPP Link After setting up the network interface, pppd will usually set up a host route to its peer only. If the remote host is on a LAN, you certainly want to be able to connect to hosts “behind” your peer as well; in that case, a network route must be set up. We have already seen that pppd can be asked to set the default route using the defaultroute option. This option is very useful if the PPP server you dialed up acts as your Internet gateway. The reverse case, in which your system acts as a gateway for a single host, is also relatively easy to accomplish. For example, take some employee at the Virtual Brewery whose home machine is called oneshot. Let’s also assume that we’ve configured vlager as a dialin PPP server. If we’ve configured vlager to dynamically assign an IP address that belongs to the Brewery’s subnet, then we can use the proxyarp option with pppd, which will install a proxy ARP entry for oneshot. This automatically makes oneshot accessible from all hosts at the Brewery and the Winery. However, things aren’t always that simple. Linking two local area networks usually requires adding a specific network route because these networks may have their own default routes. Besides, having both peers use the PPP link as the default route would generate a loop, through which packets to unknown destinations would ping-pong between the peers until their time to live expired. Suppose the Virtual Brewery opens a branch in another city. The subsidiary runs an Ethernet of its own using the IP network number 172.16.3.0, which is subnet 3 of the Brewery’s class B network. The subsidiary wants to connect to the Brewery’s network via PPP to update customer databases. Again, vlager acts as the gateway for the brewery network and will support the PPP link; its peer at the new branch is called vbourbon and has an IP address of 172.16.3.1. This network is illustrated in Figure 24.2 in Appendix A, Example Network: The Virtual Brewery. When vbourbon connects to vlager, it makes the default route point to vlager as usual. On vlager, however, we will have only the point-to-point route to vbourbon and will have to specially configure a network route for sub- net 3 that uses vbourbon as its gateway. We could do this manually using the route command by hand after the PPP link is established, but this is not a very practical solution. Fortunately, we can configure the route automatically by using a feature of pppd that we haven’t discussed yet — the ip-up command. This command is a shell script or program located in /etc/ppp that is executed by pppd after the PPP interface has been configured. When present, it is invoked with the following parameters: ip-up iface device speed local_addr remote_addr The following table summarizes the meaning of each of the arguments (in the first column, we show the number used by the shell script to refer to each argument): Argument Name Purpose $1 iface The network interface used, e.g., ppp0 $2 device The pathname of the serial device file used (/dev/tty, if stdin/stdout are used) $3 speed The speed of the serial device in bits per second $4 local_addr The IP address of the link’s remote end in dotted quad notation