diff --git a/handbook/firewalls.sgml b/handbook/firewalls.sgml index 655830e745..e8a94354f0 100644 --- a/handbook/firewalls.sgml +++ b/handbook/firewalls.sgml @@ -1,521 +1,521 @@ - + Firewalls

Contributed by &a.gpalmer; and &a.alex;. Firewalls are an area of increasing interest for people who are connected to the Internet, and are even finding applications on private networks to provide enhanced security. This section will hopefully explain what firewalls are, how to use them, and how to use the facilities provided in the FreeBSD kernel to implement them. Note: People often think that having a firewall between your companies internal network and the ``Big Bad Internet'' will solve all your security problems. It may help, but a poorly setup firewall system is more of a security risk than not having one at all. A firewall can only add another layer of security to your systems, but -they will not be able to stop a really determined hacker from +they will not be able to stop a really determined cracker from penetrating your internal network. If you let internal security lapse because you believe your firewall to be impenetrable, you have just -made the hackers job that bit easier. +made the crackers job that bit easier. What is a firewall?

There are currently two distinct types of firewalls in common use on the Internet today. The first type is more properly called a packet filtering router, where the kernel on a multi-homed machine chooses whether to forward or block packets based on a set of rules. The second type, known as proxy servers, rely on daemons to provide authentication and to forward packets, possibly on a multi-homed machine which has kernel packet forwarding disabled.

Sometimes sites combine the two types of firewalls, so that only a certain machine (known as a bastion host) is allowed to send packets through a packet filtering router onto an internal network. Proxy services are run on the bastion host, which are generally more secure than normal authentication mechanisms.

FreeBSD comes with a kernel packet filter (known as IPFW), which is what the rest of this section will concentrate on. Proxy servers can be built on FreeBSD from third party software, but there is such a variety of proxy servers available that it would be impossible to cover them in this document. Packet filtering routers

A router is a machine which forwards packets between two or more networks. A packet filtering router has an extra piece of code in its kernel, which compares each packet to a list of rules before deciding if it should be forwarded or not. Most modern IP routing software has packet filtering code in it, which defaults to forwarding all packets. To enable the filters, you need to define a set of rules for the filtering code, so that it can decide if the packet should be allowed to pass or not.

To decide if a packet should be passed on or not, the code looks through its set of rules for a rule which matches the contents of this packets headers. Once a match is found, the rule action is obeyed. The rule action could be to drop the packet, to forward the packet, or even to send an ICMP message back to the originator. Only the first match counts, as the rules are searched in order. Hence, the list of rules can be referred to as a ``rule chain''.

The packet matching criteria varies depending on the software used, but typically you can specify rules which depend on the source IP address of the packet, the destination IP address, the source port number, the destination port number (for protocols which support ports), or even the packet type (UDP, TCP, ICMP, etc). Proxy servers

Proxy servers are machines which have had the normal system daemons (telnetd, ftpd, etc) replaced with special servers. These servers are called proxy servers as they normally only allow onward connections to be made. This enables you to run (for example) a proxy telnet server on your firewall host, and people can telnet in to your firewall from the outside, go through some authentication mechanism, and then gain access to the internal network (alternatively, proxy servers can be used for signals coming from the internal network and heading out).

Proxy servers are normally more secure than normal servers, and often have a wider variety of authentication mechanisms available, including ``one-shot'' password systems so that even if someone manages to discover what password you used, they will not be able to use it to gain access to your systems as the password instantly expires. As they do not actually give users access to the host machine, it becomes a lot more difficult for someone to install backdoors around your security system.

Proxy servers often have ways of restricting access further, so that only certain hosts can gain access to the servers, and often they can be set up so that you can limit which users can talk to which destination machine. Again, what facilities are available depends largely on what proxy software you choose. What does IPFW allow me to do?

IPFW, the software supplied with FreeBSD, is a packet filtering and accounting system which resides in the kernel, and has a user-land control utility, ipfw(8). Together, they allow you to define and query the rules currently used by the kernel in its routing decisions.

There are two related parts to IPFW. The firewall section allows you to perform packet filtering. There is also an IP accounting section which allows you to track usage of your router, based on similar rules to the firewall section. This allows you to see (for example) how much traffic your router is getting from a certain machine, or how much WWW (World Wide Web) traffic it is forwarding.

As a result of the way that IPFW is designed, you can use IPFW on non-router machines to perform packet filtering on incoming and outgoing connections. This is a special case of the more general use of IPFW, and the same commands and techniques should be used in this situation. Enabling IPFW on FreeBSD

As the main part of the IPFW system lives in the kernel, you will need to add one or more options to your kernel configuration file, depending on what facilities you want, and recompile your kernel. See for more details on how to recompile your kernel.

There are currently three kernel configuration options relevant to IPFW: syslogd(8). Without this option, even if you specify that packets should be logged in the filter rules, nothing will happen. syslogd(8) on a per entry basis. You may wish to use this option in hostile environments in which you want to log firewall activity, but do not want to be open to a denial of service attack via syslog flooding.

When a chain entry reaches the packet limit specified, logging is turned off for that particular entry. To resume logging, you will need to reset the associated counter using the ipfw(8) utility: ipfw zero 4500 Where 4500 is the chain entry you wish to continue logging. Previous versions of FreeBSD contained an IPFIREWALL_ACCT option. This is now obsolete as the firewall code automatically includes accounting facilities. Configuring IPFW

The configuration of the IPFW software is done through the ipfw(8) utility. The syntax for this command looks quite complicated, but it is relatively simple once you understand its structure.

There are currently four different command categories used by the utility: addition/deletion, listing, flushing, and clearing. Addition/deletion is used to build the rules that control how packets are accepted, rejected, and logged. Listing is used to examine the contents of your rule set (otherwise known as the chain) and packet counters (accounting). Flushing is used to remove all entries from the chain. Clearing is used to zero out one or more accounting entries. Altering the IPFW rules

The syntax for this form of the command is: ipfw [-N] command [index] action [log] protocol addresses [options]

There is one valid flag when using this form of the command: The command given can be shortened to the shortest unique form. The valid commands are: Previous versions of IPFW used separate firewall and accounting entries. The present version provides packet accounting with each firewall entry.

If an index value is supplied, it used to place the entry at a specific point in the chain. Otherwise, the entry is placed at the end of the chain at an index 100 greater than the last chain entry (this does not include the default policy, rule 65535, deny).

The log option causes matching rules to be output to the system console if the kernel was compiled with IPFIREWALL_VERBOSE.

Valid actions are: pass and accept)

Each action will be recognized by the shortest unambiguous prefix. The protocols which can be specified are:

The address specification is: from <address/mask>[port] to <address/mask>[port&rsqb [via <interface>]

You can only specify port in conjunction with protocols which support ports (UDP and TCP).

The via is optional and may specify the IP address or domain name of a local IP interface, or an interface name (e.g. ed0) to match only packets coming through this interface. Interface unit numbers can be specified with an optional wildcard. For example, ppp* would match all kernel PPP interfaces.

The syntax used to specify an <address/mask> is: <address> or <address>/mask-bits or <address>:mask-pattern

A valid hostname may be specified in place of the IP address. mask-bits is a decimal number representing how many bits in the address mask should be set. e.g. specifying 192.216.222.1/24 will create a mask which will allow any address in a class C subnet (in this case, 192.216.222) to be matched. mask-pattern is an IP address which will be logically AND'ed with the address given. The keyword any may be used to specify ``any IP address''.

The port numbers to be blocked are specified as: port[,port[,port[...]]] to specify either a single port or a list of ports, or port-port to specify a range of ports. You may also combine a single range with a list, but the range must always be specified first.

The options available are: spec/Matches if the IP header contains the comma separated list of options specified in spec. The supported list of IP options are: ssrr (strict source route), lsrr (loose source route), rr (record packet route), and ts (timestamp). The absence of a particular option may be denoted with a leading '!'. established rules early in the chain. flags/Matches if the TCP header contains the comma separated list of flags. The supported flags are fin, syn, rst, psh, ack, and urg. The absence of a particular flag may be indicated by a leading '!'. types/Matches if the ICMP type is present in the list types. The list may be specified as any combination of ranges and/or individual types separated by commas. Commonly used ICMP types are: 0 echo reply (ping reply), 5 redirect, 8 echo request (ping request), and 11 time exceeded (used to indicate TTL expiration as with traceroute(8)). Listing the IPFW rules

The syntax for this form of the command is: ipfw [-atN] l

There are three valid flags when using this form of the command: ipfw(8) utility. Flushing the IPFW rules

The syntax for flushing the chain is: ipfw flush

This causes all entries in the firewall chain to be removed except the fixed default policy enforced by the kernel (index 65535). Use caution when flushing rules, the default deny policy will leave your system cut off from the network until allow entries are added to the chain. Clearing the IPFW packet counters

The syntax for clearing one or more packet counters is: ipfw zero [index]

When used without an index argument, all packet counters are cleared. If an index is supplied, the clearing operation only affects a specific chain entry. Example commands for ipfw

This command will deny all packets from the host -evil.hacker.org to the telnet port of the host +evil.crackers.org to the telnet port of the host nice.people.org by being forwarded by the router: -ipfw add deny tcp from evil.hacker.org to nice.people.org 23 +ipfw add deny tcp from evil.crackers.org to nice.people.org 23

The next example denies and logs any TCP traffic from the entire -hacker.org network (a class C) to the nice.people.org +crackers.org network (a class C) to the nice.people.org machine (any port). -ipfw add deny log tcp from evil.hacker.org/24 to nice.people.org +ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org If you do not want people sending X sessions to your internal network (a subnet of a class C), the following command will do the necessary filtering: ipfw add deny tcp from any to my.org/28 6000 setup To see the accounting records: ipfw -a list or in the short form ipfw -a l You can also see the last time a chain entry was matched with ipfw -at l Building a packet filtering firewall

Note: The following suggestions are just that: suggestions. The requirements of each firewall are different and I cannot tell you how to build a firewall to meet your particular requirements.

When initially setting up your firewall, unless you have a test bench setup where you can configure your firewall host in a controlled environment, I strongly recommend you use the logging version of the commands and enable logging in the kernel. This will allow you to quickly identify problem areas and cure them without too much disruption. Even after the initial setup phase is complete, I recommend using the logging for of `deny' as it allows tracing of possible attacks and also modification of the firewall rules if your requirements alter. Note: If you use the logging versions of the accept command, it can generate large amounts of log data as one log line will be generated for every packet that passes through the firewall, so large ftp/http transfers, etc, will really slow the system down. It also increases the latencies on those packets as it requires more work to be done by the kernel before the packet can be passed on. syslogd with also start using up a lot more processor time as it logs all the extra data to disk, and it could quite easily fill the partition /var/log is located on.

As currently supplied, FreeBSD does not have the ability to load firewall rules at boot time. My suggestion is to put a call to a shell script in the /etc/netstart script. Put the call early enough in the netstart file so that the firewall is configured before any of the IP interfaces are configured. This means that there is no window during which time your network is open.

The actual script used to load the rules is entirely up to you. There is currently no support in the ipfw utility for loading multiple rules in the one command. The system I use is to use the command: # ipfw list to write a list of the current rules out to a file, and then use a text editor to prepend ``ipfw '' before all the lines. This will allow the script to be fed into /bin/sh and reload the rules into the kernel. Perhaps not the most efficient way, but it works.

The next problem is what your firewall should actually DO! This is largely dependent on what access to your network you want to allow from the outside, and how much access to the outside world you want to allow from the inside. Some general rules are: Block all incoming access to ports below 1024 for TCP. This is where most of the security sensitive services are, like finger, SMTP (mail) and telnet. Block all incoming UDP traffic. There are very few useful services that travel over UDP, and what useful traffic there is is normally a security threat (e.g. Suns RPC and NFS protocols). This has its disadvantages also, since UDP is a connectionless protocol, denying incoming UDP traffic also blocks the replies to outgoing UDP traffic. This can cause a problem for people (on the inside) using external archie (prospero) servers. If you want to allow access to archie, you'll have to allow packets coming from ports 191 and 1525 to any internal UDP port through the firewall. ntp is another service you may consider allowing through, which comes from port 123. Block traffic to port 6000 from the outside. Port 6000 is the port used for access to X11 servers, and can be a security threat (especially if people are in the habit of doing xhost + on their workstations). X11 can actually use a range of ports starting at 6000, the upper limit being how many X displays you can run on the machine. The upper limit as defined by RFC 1700 (Assigned Numbers) is 6063. Check what ports any internal servers use (e.g. SQL servers, etc). It is probably a good idea to block those as well, as they normally fall outside the 1-1024 range specified above.

Another checklist for firewall configuration is available from CERT at

As I said above, these are only guidelines. You will have to decide what filter rules you want to use on your firewall yourself. I cannot accept ANY responsibility if someone breaks into your network, even if you follow the advice given above. diff --git a/handbook/userppp.sgml b/handbook/userppp.sgml index 25e3cfc159..e667f992c0 100644 --- a/handbook/userppp.sgml +++ b/handbook/userppp.sgml @@ -1,919 +1,919 @@ - + Setting up User PPP

User PPP was introduced to FreeBSD in release 2.0.5 as an addition to the existing kernel implementation of PPP. So, what is different about this new PPP that warrants its addition? To quote from the manual page: This is a user process PPP software package. Normally, PPP is implemented as a part of the kernel (e.g. as managed by pppd) and it is thus somewhat hard to debug and/or modify its behavior. However, in this implementation PPP is done as a user process with the help of the tunnel device driver (tun). In essence, this means that rather than running a PPP daemon, the ppp program can be run as and when desired. No PPP interface needs to be compiled into the kernel, as the program can use the generic tunnel device to get data into and out of the kernel. From here on out, user ppp will be referred to simply as ppp unless a distinction needs to be made between it and any other PPP client/server software such as pppd. Unless otherwise stated, all commands in this section should be executed as root. Before you start

This document assumes you are in roughly this position: You have an account with an Internet Service Provider (ISP) which lets you use PPP. Further, you have a modem (or other device) connected and configured correctly which allows you to connect to your ISP. You are going to need the following information to hand:

Your ISPs phone number(s).

Your login name and password. This can be either a regular unix style login/password pair, or a PPP PAP or CHAP login/password pair.

The IP address of your ISP's gateway. The gateway is the machine to which you will connect and will be set up as your default route. If your ISP hasn't given you this number, don't worry. We can make one up and your ISP's PPP server will tell us when we connect.

This number is known from now on as HISADDR.

Your ISP's netmask setting. Again, if your ISP hasn't given you this information, you can safely use a netmask of 255.255.255.0.

The IP addresses of one or more nameservers. Normally, you will be given two IP numbers. You MUST have this information unless you run your own nameserver.

If your ISP allocates you a static IP address and hostname then you will need this information too. If not, you will need to know from what range of IP addresses your allocated IP address will belong. If you haven't been given this range, don't worry. You can configure PPP to accept any IP number (as explained later). If you do not have any of the required information, contact your ISP and make sure they provide it to you. Building a ppp ready kernel

As the description states, ``ppp'' uses the kernel ``tun'' device. It is necessary to make sure that your kernel has support for this device compiled in. To check this, go to your kernel compile directory (/sys/i386/conf or /sys/pc98/conf) and examine your kernel configuration file. It needs to have the line pseudo-device tun 1 in it somewhere. The stock GENERIC kernel has this as standard, so if you have not installed a custom kernel or you do not have a /sys directory, you do not have to change anything.

If your kernel configuration file does not have this line in it, or you need to configure more than one tun device (for example, if you are setting up a server and could have 16 dialup ppp connections at any one time then you will need to use ``16'' instead of ``1''), then you should add the line, re-compile, re-install and boot the new kernel. Please refer to the section for more information on kernel configuration.

You can check how many tunnel devices your current kernel has by typing the following: # ifconfig -a tun0: flags=8051 mtu 1500 inet 200.10.100.1 --> 203.10.100.24 netmask 0xffffffff tun1: flags=8050 mtu 576 tun2: flags=8051 mtu 1500 inet 203.10.100.1 --> 203.10.100.20 netmask 0xffffffff tun3: flags=8050 mtu 1500 which in this case shows four tunnel devices, two of which are currently configured and being used.

If you have a kernel without the tun device, and you can not rebuild it for some reason, all is not lost. You should be able to dynamically load the code. Refer to the appropriate modload(8) and lkm(4) pages for further details.

You may also wish to take this opportunity to configure a firewall. Details can be found in the section. Check the tun device

Most users will only require one ``tun'' device (tun0). If you have used more (i.e., a number other than `1' in the pseudo-device line in the kernel configuration file) then alter all references to ``tun0'' below to reflect whichever device number you are using. The easiest way to make sure that the tun0 device is configured correctly is to re-make it. To do this, execute the following commands: # cd /dev # ./MAKEDEV tun0

If you require 16 tunnel devices in your kernel, you will need to create more than just tun0: # cd /dev # ./MAKEDEV tun15

Also, to confirm that the kernel is configured correctly, the following command should give the indicated output: $ ifconfig tun0 tun0: flags=8050 mtu 1500 $ Name Resolution Configuration

The resolver is the part of the system that turns IP addresses into hostnames and vice versa. It can be configured to look for maps that describe IP to hostname mappings in one of two places. The first is a file called /etc/hosts (man 5 hosts). The second is the Internet Domain Name Service (DNS), a distributed data base, the discussion of which is beyond the scope of this document.

This section describes briefly how to configure your resolver.

The resolver is a set of system calls that do the name mappings, but you have to tell them where to find their information. You do this by first editing the file /etc/host.conf. Do not call this file /etc/hosts.conf (note the extra ``s'') as the results can be confusing. Edit the /etc/host.conf file

This file should contain the following two lines: hosts bind which instructs the resolver to first look in the file /etc/hosts, and then to consult the DNS if the name was not found. Edit the /etc/hosts(5) file

This file should contain the IP addresses and names of machines on your network. At a bare minimum it should contain entries for the machine which will be running ppp. Assuming that your machine is called foo.bar.com with the IP address 10.0.0.1, /etc/hosts should contain: 127.0.0.1 localhost 10.0.0.1 foo.bar.com foo The first line defines the alias ``localhost'' as a synonym for the current machine. Regardless of your own IP address, the IP address for this line should always be 127.0.0.1. The second line maps the name ``foo.bar.com'' (and the shorthand ``foo'') to the IP address 10.0.0.1. If your provider allocates you a static IP address and name, then use these in place of the 10.0.0.1 entry. Edit the /etc/resolv.conf file

/etc/resolv.conf tells the resolver how to behave. If you are running your own DNS, you may leave this file empty. Normally, you will need to enter the following line(s): nameserver x.x.x.x nameserver y.y.y.y domain bar.com The x.x.x.x and y.y.y.y addresses are those given to you by your ISP. Add as many ``nameserver'' lines as your ISP provides. The ``domain'' line defaults to your hostname's domain, and is probably unnecessary. Refer to the resolv.conf manual page for details of other possible entries in this file. PPP Configuration

Both user ppp and pppd (the kernel level implementation of PPP) use configuration files located in the /etc/ppp directory. The sample configuration files provided are a good reference for user ppp, so don't delete them.

Configuring ppp requires that you edit a number of files, depending on your requirements. What you put in them depends to some extent on whether your ISP allocates IP addresses statically (i.e., you get given one IP address, and always use that one) or dynamically (i.e., your IP address can be different for each PPP session). PPP and Static IP addresses

You will need to create a configuration file called /etc/ppp/ppp.conf. It should look similar to the example below. Note that lines that end in a ``:'' start in the first column, all other lines should be indented as shown using spaces or tabs. 1 default: 2 set device /dev/cuaa0 3 set speed 115200 4 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" ATE1Q0 OK-AT-OK \\dATDT\\T TIMEOUT 40 CONNECT" 5 provider: 6 set phone "(0123) 456 7890" 7 set login "TIMEOUT 10 gin:-BREAK-gin: foo word: bar col: ppp" 8 set timeout 300 9 deny lqr 10 set ifaddr x.x.x.x y.y.y.y 11 delete ALL 12 add 0 0 HISADDR Do not include the line numbers, they are just for reference in this discussion. /dev/cuaa0 and COM2: is /dev/cuaa1. chat(8) program. Refer to the manual page for information on the features of this language. J. Random Provider login: foo password: bar protocol: ppp You will need to alter this script to suit your own needs. If you're using PAP or CHAP, there will be no login at this point, so your login string can be left blank. See for further details. 10.0.0.2/0. If you need to use a ``guessed'' address, make sure that you create an entry in /etc/ppp/ppp.linkup as per the instructions for . If this line is omitted, ppp cannot run in -auto or -dynamic mode. HISADDR is replaced with the gateway address specified on line 9. It is important that this line appears after line 9, otherwise HISADDR will not yet be initialized.

It is not necessary to add an entry to ppp.linkup when you have a static IP address as your routing table entries are already correct before you connect. You may however wish to create an entry to invoke programs after connection. This is explained later with the sendmail example.

Example configuration files can be found in the /etc/ppp directory. PPP and Dynamic IP addresses

If your service provider does not assign static IP numbers, ppp can be configured to negotiate the local and remote addresses. This is done by "guessing" an IP number and allowing ppp to set it up correctly using the IP Configuration Protocol (IPCP) after connecting. The ppp.conf configuration is the same as , with the following change: 10 set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 Again, do not include the line numbers, they are just for reference in this discussion. Indentation of at least one space is required. 0.0.0.0 argument: set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 This tells ppp to negotiate using address 0.0.0.0 rather than 10.0.0.1. Do not use 0.0.0.0/0 as the first argument to set ifaddr as it prevents ppp from setting up an initial route in -auto and -ddial mode.

You will also need to create an entry in /etc/ppp/ppp.linkup. Ppp.linkup is used after a connection has been established. At this point, ppp will know what IP addresses should really be used. The following entry will delete the existing bogus routes, and create correct ones: 1 provider: 2 delete ALL 3 add 0 0 HISADDR ppp.linkup according to the following rules: First, try to match the same label as we used in ppp.conf. If that fails, look for an entry for the IP number of our gateway. This entry is a four-octet IP style label. If we still haven't found an entry, look for the MYADDR entry. HISADDR. HISADDR will be replaced with the IP number of the gateway as negotiated in the IPCP.

See the pmdemand entry in the files /etc/ppp/ppp.conf.sample and /etc/ppp/ppp.linkup.sample for a detailed example. Receiving incoming calls with PPP

This section describes setting up ppp in a server role.

When you configure ppp to receive incoming calls, you must decide whether you wish to forward packets for just ppp connections, for all interfaces, or not at all. To forward for just ppp connections, include the line enable proxy in your ppp.conf file. If you wish to forward packets on all interfaces, use the gateway=YES option in /etc/rc.conf (this file used to be called /etc/sysconfig). Which getty?

provides a good description on enabling dialup services using getty.

An alternative to getty is , a smarter version of getty designed with dialup lines in mind.

The advantages of using mgetty is that it actively talks to modems, meaning if port is turned off in /etc/ttys then your modem won't answer the phone.

Later versions of mgetty (from 0.99beta onwards) also support the automatic detection of PPP streams, allowing your clients script-less access to your server.

Refer to for more information on mgetty. PPP permissions

PPP must normally be run as user id 0. If however you wish to allow ppp to run in server mode as a normal user by executing ppp as described below, that user must be given permission to run ppp by adding them to the network group in /etc/group. Setting up a PPP shell for dynamic-IP users

Create a file called /etc/ppp/ppp-shell containing the following: #!/bin/sh IDENT=`echo $0 | sed -e 's/^.*-\(.*\)$/\1/'` CALLEDAS="$IDENT" TTY=`tty` if [ x$IDENT = xdialup ]; then IDENT=`basename $TTY` fi echo "PPP for $CALLEDAS on $TTY" echo "Starting PPP for $IDENT" exec /usr/sbin/ppp -direct $IDENT

This script should be executable. Now make a symbolic link called ppp-dialup to this script using the following commands: # ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-dialup

You should use this script as the shell for all your dialup ppp users. This is an example from /etc/password for a dialup PPP user with username pchilds. (remember don't directly edit the password file, use vipw) pchilds:*:1011:300:Peter Childs PPP:/home/ppp:/etc/ppp/ppp-dialup

Create a /home/ppp directory that is world readable containing the following 0 byte files -r--r--r-- 1 root wheel 0 May 27 02:23 .hushlogin -r--r--r-- 1 root wheel 0 May 27 02:22 .rhosts which prevents /etc/motd from being displayed. Setting up a PPP shell for static-IP users

Create the ppp-shell file as above and for each account with statically assigned IPs create a symbolic link to ppp-shell.

For example, if you have three dialup customers fred, sam, and mary, that you route class C networks for, you would type the following: # ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-fred # ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-sam # ln -s /etc/ppp/ppp-shell /etc/ppp/ppp-mary

Each of these users dialup accounts should have their shell set to the symbolic link created above. (ie. mary's shell should be /etc/ppp/ppp-mary). Setting up ppp.conf for dynamic-IP users

The /etc/ppp/ppp.conf file should contain something along the lines of default: set debug phase lcp chat set timeout 0 ttyd0: set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255 enable proxy ttyd1: set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255 enable proxy

Note the indenting is important.

The default: section is loaded for each session. For each dialup line enabled in /etc/ttys create an entry similar to the one for ttyd0: above. Each line should get a unique IP from your pool of ip address for dynamic users. Setting up ppp.conf for static-IP users

Along with the contents of the sample /etc/ppp/ppp.conf above you should add a section for each of the statically assigned dialup users. We will continue with our fred, sam, and mary example. fred: set ifaddr 203.14.100.1 203.14.101.1 255.255.255.255 sam: set ifaddr 203.14.100.1 203.14.102.1 255.255.255.255 mary: set ifaddr 203.14.100.1 203.14.103.1 255.255.255.255

The file /etc/ppp/ppp.linkup should also contain routing information for each static IP user if required. The line below would add a route for the 203.14.101.0 class C via the client's ppp link. fred: add 203.14.101.0 netmask 255.255.255.0 HISADDR sam: add 203.14.102.0 netmask 255.255.255.0 HISADDR mary: add 203.14.103.0 netmask 255.255.255.0 HISADDR More on mgetty, AutoPPP, and MS extensions Mgetty and AutoPPP

Configuring and compiling mgetty with the AUTO_PPP option enabled allows mgetty to detect the LCP phase of PPP connections and automatically spawn off a ppp shell. However, since the default login/password sequence does not occur it is necessary to authenticate users using either PAP or CHAP.

This section assumes the user has successfully configured, compiled, and installed a version of mgetty with the AUTO_PPP option (v0.99beta or later)

Make sure your /usr/local/etc/mgetty+sendfax/login.config file has the following in it: /AutoPPP/ - - /etc/ppp/ppp-pap-dialup

This will tell mgetty to run the ppp-pap-dialup script for detected PPP connections.

Create a file called /etc/ppp/ppp-pap-dialup containing the following (the file should be executable): #!/bin/sh TTY=`tty` IDENT=`basename $TTY` exec /usr/sbin/ppp -direct pap$IDENT

For each dialup line enabled in /etc/ttys create a corresponding entry in /etc/ppp/ppp.conf. This will happily co-exist with the definitions we created above. papttyd0: enable pap set ifaddr 203.14.100.1 203.14.100.20 255.255.255.255 enable proxy papttyd1: enable pap set ifaddr 203.14.100.1 203.14.100.21 255.255.255.255 enable proxy

Each user logging in with this method will need to have a username/password in /etc/ppp/ppp.secret file, or alternatively add the enable passwdauth option to authenticate users via pap from the /etc/passwordd file. (*)

(*) Note this option only available in 2.2-961014-SNAP or later, or by getting the updated ppp code for 2.1.x. (see MS extensions below for details) MS extentions

From 2.2-961014-SNAP onwards it is possible to allow the automatic negotiation of DNS and NetBIOS name servers with clients supporting this feature (namely Win95/NT clients). See RFC1877 for more details on the protocol.

An example of enabling these extensions in your /etc/ppp/ppp.conf file is illustrated below. default: set debug phase lcp chat set timeout 0 enable msext set ns 203.14.100.1 203.14.100.2 set nbns 203.14.100.5

This will tell the clients the primary and secondary name server addresses, and a netbios nameserver host. PAP and CHAP authentication

Some ISPs set their system up so that the authentication part of your connection is done using either of the PAP or CHAP authentication mechanisms. If this is the case, your ISP will not give a login: prompt when you connect, but will start talking PPP immediately. PAP is less secure than CHAP, but security is not normally an issue here as passwords, although being sent as plain text with PAP, are being - transmitted down a serial line only. There's not much room for hackers + transmitted down a serial line only. There's not much room for crackers to "eavesdrop". Referring back to the or sections, the following alterations must be made: 7 set login ..... 13 set authname MyUserName 14 set authkey MyPassword As always, do not include the line numbers, they are just for reference in this discussion. Indentation of at least one space is required. MyUserName. MyPassword. You may want to add an additional line 15 accept PAP or 15 accept CHAP to make it obvious that this is the intention, but PAP and CHAP are accepted by default.

NOTE: Your authkey will be logged if you have command logging turned on (set log +command). Care should be taken when deciding the ppp log file permissions. Changing your ppp configuration on the fly

It is possible to talk to the ppp program while it is running in the background, but only if a suitable password has been set up.

By default, ppp will listen to a TCP port of 3000 + tunno, where tunno is the number of the tun device acquired, however, if a password for the local machine is not set up in /etc/ppp/ppp.secret, no server connection will be created. To set your password, put the following line in /etc/ppp/ppp.secret: foo MyPassword where foo is your local hostname (run hostname -s to determine the correct name), and MyPassword is the unencrypted password that you wish to use. /etc/ppp/ppp.secret should NOT be accessable by anyone without user id 0. This means that /, /etc and /etc/ppp should not be writable, and ppp.secret should be owned by user id 0 and have permissions 0600.

It is also possible to select a specific port number or to have ppp listen to a local unix domain socket rather than to a TCP socket. Refer to the set socket command in manual page for further details.

Once a socket has been set up, the pppctl(8) program may be used in scripts that wish to manipulate the running program. Final system configuration

You now have PPP configured, but there are a few more things to do before it is ready to work. They all involve editing the /etc/rc.conf file (was /etc/sysconfig). Working from the top down in this file, make sure the ``hostname='' line is set, e.g.: hostname=foo.bar.com

If your ISP has supplied you with a static IP address and name, it's probably best that you use this name as your host name.

Look for the network_interfaces variable. If you want to configure your system to dial your ISP on demand, make sure the tun0 device is added to the list, otherwise remove it. network_interfaces="lo0 tun0" ifconfig_tun0= Note, the ifconfig_tun0 variable should be empty, and a file called /etc/start_if.tun0 should be created. This file should contain the line ppp -auto mysystem This script is executed at network configuration time, starting your ppp daemon in automatic mode. If you have a LAN for which this machine is a gateway, you may also wish to use the -alias switch. Refer to the manual page for further details.

Set the router program to ``NO'' with the line router_enable=NO (/etc/rc.conf) router=NO (/etc/sysconfig) It is important that the routed daemon is not started (it's started by default) as routed tends to delete the default routing table entries created by ppp.

It is probably worth your while ensuring that the ``sendmail_flags'' line does not include the ``-q'' option, otherwise sendmail will attempt to do a network lookup every now and then, possibly causing your machine to dial out. You may try: sendmail_flags="-bd" The upshot of this is that you must force sendmail to re-examine the mail queue whenever the ppp link is up by typing: # /usr/sbin/sendmail -q

You may wish to use the !bg command in ppp.linkup to do this automatically: 1 provider: 2 delete ALL 3 add 0 0 HISADDR 4 !bg sendmail -bd -q30m

If you don't like this, it is possible to set up a "dfilter" to block SMTP traffic. Refer to the sample files for further details.

All that is left is to reboot the machine.

After rebooting, you can now either type # ppp and then ``dial provider'' to start the PPP session, or, if you want ppp to establish sessions automatically when there is outbound traffic (and you haven't created the start_if.tun0 script), type # ppp -auto provider Summary

To recap, the following steps are necessary when setting up ppp for the first time:

Client side: Ensure that the tun device is built into your kernel. Ensure that the tunX device file is available in the /dev directory. Create an entry in /etc/ppp/ppp.conf. The pmdemand example should suffice for most ISPs. If you have a dynamic IP address, create an entry in /etc/ppp/ppp.linkup. Update your /etc/rc.conf (or sysconfig) file. Create a start_if.tun0 script if you require demand dialing.

Server side: Ensure that the tun device is built into your kernel. Ensure that the tunX device file is available in the /dev directory. Create an entry in /etc/passwd (using the vipw(8) program). Create a profile in this users home directory that runs ``ppp -direct direct-server'' or similar. Create an entry in /etc/ppp/ppp.conf. The direct-server example should suffice. Create an entry in /etc/ppp/ppp.linkup. Update your /etc/rc.conf (or sysconfig) file. Acknowledgments

This section of the handbook was last updated on Sun Sep 7, 1997 by &a.brian

Thanks to the following for their input, comments & suggestions:

&a.nik

&a.dirkvangulik

&a.pjc