DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 

MorningStar PPP User's Guide

Systems, Devices, and Dialers - An Analogy

This example may help describe how the Systems, Devices, and Dialers files work in conjunction to allow an on-demand outbound connection. Consider the analogy that can be drawn between the communication needs of a small business and the needs of a system which supports PPP connections.

Before opening the business, the owner assesses the company's communication needs. Obviously, its telecommunications system must support on-demand communications and inbound and outbound calling. The list of communications needs includes:

How are these pieces of the business' telecommunications system analogous to the pieces of the PPP configuration? The table below provides the answer:

Need
Pizza Business System
PPP Configuration
Communications access
a line to the telephone company's local switch over which inbound and outbound calls are transmitted

Could also need a dedicated line for security alarm

the same

Could also handle a dedicated, or Direct connection

Interface device
the telephone to answer or place calls
the system's modem (device), listed in the PPP Devices file
Memory for dialing information
the telephone's memory for storing numbers for one-touch dialing
the PPP Dialers file containing modem dialing instructions
List of potential communications partners
a telephone directory including numbers, addresses, and contact names
the PPP Systems file containing numbers, logins, and passwords

Of course, the contemporary business could have many other communications needs, such as voice mail, fax machines, Internet service, etc. But those listed in the table are, at least, supportive of outbound, dialed connections. Hopefully they help illustrate the way the Systems, Devices, and Dialers files support on-demand, outbound PPP connections.

Arranging for Outbound and Inbound PPP Connections

Throughout the following examples the local machine running MST PPP will be called robin. The peer, or remote neighbor, with which robin will establish an outbound connection to is called lark.

If you follow the steps outlined below, substituting names and addresses for your own local and remote machines, you will be able to test a simple PPP connection. These procedures are not comprehensive and contain minimal instructions about such things as setting up a packet filter for security. This, and configuration of other important PPP options, such as Link Management, Data Compression and Authentication, are explained elsewhere, and the manual pages in the appendix contain details on incorporating those features, and more, in your PPP configuration.

Overview

The steps for setting up an outbound PPP connection include:

The steps for setting up an inbound PPP connection include:

When these steps are completed and the system robin is re-booted, the following events will occur:

1. Autostart starts the daeomn for an on-demand connection from robin to lark.
2. If IP traffic is initiatied to lark, pppd will dial out to lark as follows:
3. pppd searches the lines of the Systems file looking for an entry in the name field which matches lark's hostname or IP address.
4. When the match of a hostname or IP address is made, the Systems speed field provides an index to an entry in the Devices file with a matching speed.
5. The dialer field in Devices provides an index to an entry in the Dialers file.
6. Lark's phone number is dialed.
7. Robin's chat script (in the Systems file), sends robin's login name and password to lark.
8. Lark verifies robin's password by comparing it to the entry in the /etc/passwd file.
9. If the login is successful, /usr/lib/mstppp/Login-robin is run.
10. /usr/lib/mstppp/Login-robin will start pppd on lark, which will comunicate with pppd on robin to negotiate and establish a PPP connection.

The Outbound connection

Autostart - starting pppd

When robin is booted a PPP daemon will be started for the outbond link to lark. There is no example /usr/lib/mstppp/Autostart file; you must create it. It contains the one line necessary to start pppd. In our example, here's what we would put in Autostart:

pppd robin:lark auto idle 150

The pppd started here has this connection configuration:

local and remote hosts
robin and lark
daemon management option
respond to the arrival of a packet by initiating a connection to peer (auto)
link management option
idle timer in effect (idle)
idle timer value
shut down the link if 150 seconds pass without receiving or transmitting a packet

Systems - Adding an Entry for Connecting to lark

Add this line to robin's /usr/lib/mstppp/Systems file:

199.199.199.2 Any ACU 38400 5551212 "" \r\d in:--in: \dprobin word: \qpassword

This provides the following configuration for robin's connection to lark:

call what host
lark
when
Any day any time (Any)
using what device
Any Call Unit that matches the speed in the next field (ACU)
at what DTE speed
38400 BPS (38400)
at what telephone number
5551212
expect what string
in: substring of login: if true, send next field. If false, send string between dashes followed by carriage return and expect in: Can be used to elicit a response out of peer.
send what string
send Probin followed by a carriage return (implicit)
expect what string
word: a substring of password:
send what string
mypasswd followed by a carriage return (implicit)

Devices - Adding an entry for Connecting to lark

Add this line to robin's /usr/lib/mstppp/Devices file:

T1600 tty1A 38400 rtscts

This line provides this configuration for robin's connection to lark:

use what modem
Telebit model 1600 (T1600)
on which system device
outbound device (tty1A)
at what speed
38400 BPS (38400)
optional parameters
hardware flow control (rtscts)

Dailers - Adding an entry for Connecting to lark

The /usr/lib/mstppp/Dialers file is already installed on robin. Here's what the Telebit 1600 entry looks like:

T1600 ABORT NO\sCARRIER ABORT NO\sDIALTONE ABORT BUSY \ ABORT RRING\r\n\r\nRRING\r\n\r\nRRING ABORT ERROR \ TIMEOUT 5 "" AT OK-AT-OK ATS111=0DT\T TIMEOUT 60 CONNECT

This elaborate dialer string will cause pppd to abort the connection attempt if any of several things go wrong with the telephone call, then will disable UUCP spoofing in the modem before dialing the destination telephone number. Look through the Dialers file for modem entries for your type of modem. If none are defined, use the dialer entry "GENERIC".

Connection among the configuration files

The peer's machine name, lark, is used as an index into the Systems file. The first matching entry found is used. The DTE speed in the Systems file is used as an index into the Devices file. Lastly, the dialer entry specified in the Devices file is used as an index into the Dialers file.

The inbound connection

Adding an account for robin to login to lark

Although may bot initiate outbound calls, and therefore may not have to start pppd at boot time, it does need to be prepared for an inbounc connection from robin. To do this, add this entry to lark's /etc/passwd file and execute the following command:

Probin::105:42:Robin's PPP login:/usr/lib/mstppp:/usr/lib/mstppp/Login-robin # passwd Probin New password: some password Retype new password: some password #

The '105' in the password entry is a unique user ID (uid) for this PPP login. The '42' is the group ID (gid) associated with the 'ppp' group in lark's /etc/group file.

Creating robin's Login Shell Script

Robin's PPP user's login shell script can be located anywhere and named whatever you choose. For purposes of this illustration, the login script will be /usr/lib/mstppp/Login-robin. Look carefully at the last line in the sample script shown below before you create the file and manually add the lines. Notice that the word 'hostname' is surrounded by backquotes, not regular quotes or apostrophes. `hostname`, with the backquotes, tells the system to insert the output of the command hostname in this space in the pppd command line. We recommend that you make sure backquotes are used by copying this script from /usr/lib/mstppp/Examples/Login.ex, rather than inserting them manually.

#!/bin/sh # PPP login shell example for SystemV Unix PATH=/usr/bin:/usr/lib/mstppp:/etc:/bin PPPHOME=/usr/lib/mstppp export PATH PPPHOME mesg n stty -tostop exec pppd `hostname`:robin idle 150 rtscts

hostname will return lark, the current machine and robin is the peer. The idle timer is set to 150 seconds and pppd will use hardware flow control.

Checking Permissions

Following the creation of the shell script, make sure the script is executable with the following command:

# chmod 755 /usr/lib/mstppp/Login-robin

Lark's PPP daemon should be mode 4750, meaning it is suid root and executable by members of its group, but not by general users. Perform this test to find out if this is true:

# ls -l /usr/lib/mstppp/pppd

The results should look something like this:

-rwsr-x--- 1 root ppp 338527 Oct 2 07:37 /usr/lib/mstppp/pppd

If not, use chmod and chown to change mode and ownership as follows:

# chmod 4750 /usr/lib/mstppp/pppd # chown root:ppp /usr/lib/mstppp/pppd

Testing the robin-lark link

The PPP configuration is now complete. Follow these steps to test the outbound connection from robin to lark.

  1. You can either reboot your machine or run /usr/lib/mstppp/Sysinit to start pppd.
  2. Check to make sure pppd was started:
  3. Use telnet to bring up the link and type ^D to exit the login. There will be a half minute pause while robin dials the phone, the modems establish a carrier, the Systems chat script completes, the answering pppd is started on lark, and the two pppd's negotiate.

    Pause

The log file will be appended to and will show how the link was initiated:

8/4-14:14:53-14902 tcp 137.175.2.11/1204-> 131.187.1.131 \ telnet 40 syn bringup 8/4-14:14:54-14902 Dialing lark (cua 38400 5551212 T1600) 8/4-14:15:23-14902 PPP connected to 131.187.1.131

This log file snippet shows that the telnet session to lark caused the link to be initiated.

MST PPP is installed, configured, running and connected on both ends of our links. When the link is up, users should be able to access each peer machine using any TCP/IP application such as telnet, ftp, etc.

If either machine is connected to a local area network, you can set up IP routing on the two networks so that hosts on either network can communicate with hosts on the other, using machines on the ends of the PPP links as routers. Routing is discussed in later sections.

Additional Information

Non-Generic Login Scripts

In most cases, all inbound PPP logins can use the same generic Login script. But if you want a host to start pppd with a special option like "require authentication", make that login account use a specific login shell tailored to that host. Call it /usr/lib/mstppp/Login-host, for example, and change the pppd line to reflect whatever options you wish to have:

exec pppd `hostname`:robin idle 130 rtscts requireauth

Creating a Simple Filter File

Note: A filter file is not necessary for pppd operation. It is only discussed here as an example on how you might use the Filter file.

The MST PPP Filter file specifies the ways in which static packet filtering handles outbound and inbound TCP packets. Though the filtering can be very complex if desired, a simple filter will suffice for demonstration purposes between robin and lark.

An example other than the one shown below is in /usr/lib/mstppp/Examples/Filter.ex and a lengthy explanation of static packet filtering is included in this manual.

Here is the Filter file to use for testing the robin-lark link:

default bringup !ntp !3/icmp !who
keepup !send !ntp !3/icmp !who
pass !route
log !nntp tcp/syn /recv

This filter says to:

bringup the connection for any traffic other than:

    Network Time Protocol packets
    ICMP Network Unreachable messages
    packets from the in.rwhod daemon

(!ntp)
(!3/icmp)
(!who)
keepup the link for all packets except those sent by robin
and those that will not bringup the connection
(!send)
(!ntp) (!3/icmp) (!who)
pass all packets except for RIP routing messages between in.routed daemons
(!route)
log messages when an inbound TCP session is established
except for NNTP connections
(tcp/syn /recv)
(!nntp)

Note on Systems and Devices Entries

In both Systems and Devices, pppd selects the first line that matches its search criteria. If the connection attempt fails while using the method described by that line, pppd will search for the next matching line. Pppd will report a failure only when all the criteria-matching lines have been tried and exhausted.

For example, suppose two lines in Systems differed only by the values in the telephone number field like this:

lark Any;50 ACU 38400 5551212 in:--in: Probin word: mypasswd
lark Any;50 ACU 38400 5551223 in:--in: Probin word: mypasswd

Pppd would first try to connect by dialing 5551212. If pppd received a BUSY from the modem, it would dial the second number, 5551223.

Similarly, suppose a host has two different modems attached which can be used for outbound calls. The Devices entries might look like this:

T3000 tty1A 38400 rtscts
USRv32bis tty1B 38400 rtscts

Pppd would try to call out through /dev/tty1A. But suppose it's busy because an incoming UUCP connection is on /dev/tty1B. pppd will try /dev/tty1B instead.

IP Addresses on the pppd Command Line

Soft Addresses

If an IP address is input on the pppd command line, the address is offered during IPCP negotiations. However, at connection time, some terminal servers and other peers wish to assign an address for the host running MST PPP to use for the duration of the connection. Instruct MST PPP to allow assignment of an address that's different from the one on the pppd command line, by including a line like the following:

pppd `hostname`:192.0.2.5 auto idle 300

Because SLIP does not perform any IPCP negotiations, the tilde option will not function. See Common pppd Options for more information.

Dynamic address assignment

When an answering pppd is invoked in Login, it is told a pair of IP addresses on the command line. In the Login script, use any means to decide what IP addresses are put on the command line. Have them looked up in a file or a database, calculated algorithmically based on the incoming connection's username or other distinguishing feature, or invoke a program to ask a BOOTP server. The pppd command line arguments provide the mechanism; your Login script provides the policy.

Address Selected From a Small List

Here's an example Login script that uses the tty name to guarantee uniqueness of the addresses it assigns. This works fine for a small installation with few modem server serial ports and a fairly static configuration.

#!/bin/sh
TTY=`tty`
case $TTY in
/dev/tty1)
IP=192.0.2.1
;;
/dev/tty2)
IP=192.0.2.2
;;
esac
exec pppd `hostname`:$IP idle 300 rtscts

Address Calculated From tty Name

This script also uses the tty name to guarantee uniqueness of the addresses it assigns. You must define ttyN in your /etc/hosts file, NIS hosts map, NetInfo hosts map, or DNS database, according to the system used. This works better in a larger installation with more ports and a configuration that tends to change more often.

#!/bin/sh
TTY=`/bin/basename \`/bin/tty\``
exec pppd `hostname`:$TTY idle 300 rtscts

Security Techniques

It's impractical to impose thorough security policies on each internal host of the networks linked by an MST PPP connection. But MST PPP's strong security features support a variety of techniques that strengthen your network's ability to prevent loss.

In most cases, a single connection can be supported by more than one of MST PPP's security features. For example, a connection might use the following:

These features, and others, are discussed in the sections below.

Static Packet Filtering

Introduction

We recommend that you establish a security policy before you write a packet filter. A security policy is a statement based on thorough analysis of access needs, vulnerabilities, and real, or perceived, threats to your assets. You must identify the types of network traffic associated with these issues before you can create a packet filter that supports your security policy.

Morning Star Technologies' flexible filter-writing mechanism will also support your policy as you create your filter. Our philosophy is to provide a mechanism that won't force policy changes for the sake of writing acceptable rules.

The Foundations of Security Policies

In general, all security policies are based on one of two opposing strategies. Both types of policies are supported by MST filters.

The first strategy permits a few specific services and blocks everything else. If you follow this philosophy, a service will be unavailable if you commit an error of omission. This is a fail-safe, or closed, policy.

The second strategy blocks only specific services and permits everything else. If you begin from this premise, an error of omission may leave you unintentionally vulnerable when a fragile service is not blocked.

If you need aid in developing security policies, or would like more general information about network security and packet filtering, we recommend you begin by reading two books, "Firewalls and Internet Security " by Bill Cheswick and Steve Bellovin and "Building Internet Firewalls" by Brent Chapman and Elizabeth Zwicky.

Filter File Rulesets

Filter Basics

When pppd starts, the software checks for a filter file. If one is present, it is parsed and installed. The default filter filename for pppd isFilter'. If you want to give the file a different name, specify the new name as the argument for the pppd `filter' option. Only add the filter option if you want to change the name of the filter file.

A filter file contains rulesets for filtering packets. Each ruleset begins with one of the following:

You may write a specific ruleset for each connecting host, or a default ruleset will be used. The pppd parser will search for a ruleset that matches the IP address or hostname of the remote PPP/SLIP host, called the peer. This usually corresponds to the IP address placed on the right hand side of the colon on the pppd command line.

Ruleset Design

Hostname or IP Address

Rulesets are designed on a per-connecting-host basis rather than a per-interface basis. This provides support for devices acting as PPP or SLIP routing hubs. A hub workstation allows multiple hosts to establish IP connections and may support multiple hosts establishing connections at different times on the same interface.

If a hub supports different classes of users, MST PPP filters allow you to define different access policies for each group. A single hub workstation may support all of the following PPP/SLIP connections, each defined by a different ruleset:

Default Rulesets

Default rulesets are permitted. They simplify configuration when a single machine supports similar multiple hosts/connections which can be controlled by the same security policy.

Ruleset Order

The order in which rulesets appear is important. Default rulesets should appear early in the file because, after they are parsed, the parser continues searching for more matching rulesets. However, when addresses or hostnames in packets and rulesets match, the packet is processed and the parser stops its search.

When a match is found and the `non-default' ruleset is processed, its individual filters replace any default filters "remembered" from earlier in the file. This means that packet filtering may behave differently if thedefault' rule appears early or late in the file.

The Four Filters

A ruleset is made up of one to four filters which regulate the response to a packet. The filter's actions are defined by its initial keyword. Each type of filter may be used one time per connection. This table explains the keywords, the types of packets affected by the filters, and the filter's actions:

KEYWORD
PACKET TYPE
ACTION
bringup
outgoing dialup
defines packets which cause a connection to be established
keepup
inbound and outbound
dialup
defines packets which cause the idle timer to be reset, preventing the connection from going down
pass
all packets
defines packets which are allowed to pass through the filter. packets which don't pass don't bringup
log
all packets
defines the characteristics which will cause a message about a packet to be added to a log file

Defined and Default Filters

Filters defined in a ruleset replace any previous default definition for that filter. Defined filters are not additive with a default filter. If one of the keyword filters does not appear in a ruleset, that filter is defined by its the most recently parsed default ruleset. If there is no previous default ruleset, the implicit default is `all', except for the log filter, which defaults to ` !all'.

Filter Stanzas

Each filter is composed of a filter name followed by one or more stanzas (i.e., rules). Each packet passing through the interface is compared to the rules in the stanzas until a match is found, completing the filter operation. The ordering of the stanzas is therefore extremely important. Packets may match on many types of values, including:

Use of the Exclamation Mark to Negate

A stanza optionally begins with the negation operator, the exclamation mark (!). The mark is followed by one or more values and keywords, each separated by a slash (/). These value and keyword combinations create a specification for a packet.

An exclamation mark is a powerful specification in any filter rule. If an exclamation mark is placed at the beginning of a rule, it negates the action of the stanza's keyword. For example, compare the defaults for the Pass and Log filters:

Pass
all
Log
!all

The specification for Pass, and the lack of an exclamation mark, indicates the default is to pass all packets. On the other hand, the `!all' default designation for Log means no packets are logged.

Implicit Filter Endings

Each filter ends with an implicit stanza. The implicit ending stanza is `all' if the last stanza specified is negated by beginning with `!'. The implicit ending stanza is `!all' if the last stanza is not negated. While this is convenient and makes it unnecessary to actually define the final "match everything else" stanza, it is a good idea to explicitly specify this stanza to avoid simple errors that can greatly change the meaning of a filter.

Packets Overview

Each stanza represents a template used to find matching packets. The features you can place in your stanzas correspond to the fields in network messages. This allows you to filter at the IP level or the TCP /UDP/ICMP level.

IP - The Internet Protocol

The fields available at the IP level include the protocol (e.g., 1
[ICMP], 2 [IGMP], 6 [TCP], 8 [EGP], 17 [UDP], etc.), an address
(i.e., the source or destination address) and IP options (e.g., rr,
lsrr, etc.), and fragmentation.

MST does not provide a filter keyword for matching the version,
IHL, TOS, length, ID, TTL or checksum header fields.

ICMP - The Internet Control Message Protocol

ICMP messages may be filtered on the type and code fields.

In general, it is not a good idea to block all inbound or outbound ICMP messages because ICMP messages are an important way that status information is conveyed over an IP network. For instance, blocking ICMP Source Quench messages (Type 4), used to tell a packet source to slow down, can cause problems for other users and sites.

It is true that you should probably not permit ICMP Redirect messages (Type 5) to pass through your router since the routing on an internal node should not be changed by an external site.

If you want to block ping from being used for host discovery, then you should block inbound ICMP Echo packets (Type 8).

TCP - Transmission Control Protocol

The TCP header fields available for matching include port numbers (i.e., the source or destination port), the presence of the SYN bit without ACK, and the ACK, FIN and RST bits.

MST does not provide a method for filtering on TCP options, the presence of URG/EOM bits in the TCP options, or other TCP header fields.

Establishing a TCP connection requires synchronization. Each side must send it's own initial sequence nu