1.1. Assisting with the Net-HOWTO

If you would like to assist with this document, there are two primary avenues that are extremely helpful.

• Purchase an OpenBook! If you purchase OpenDocs books, OpenDocs Publishing will donate a portion of the proceeds back to the Open Source Documentation Fund. This fund assists authors financially while they continue to write documentation for Open Source projects.

• Provide a monetary contribution to the document. By contributing, you can even request what you would like to have updated, written, or expanded within the document. To provide a monetary contribution, please contact Command Prompt, Inc. You may also contact Joshua Drake.

• If you have written something that you would like to contribute, please email it to poet@linuxports.com

2.1. Feedback

We are always interested in feedback. Please contact us at: poet@linuxports.com.

If you find anything erroneous, or if you feel that something should be added, please contact us.

Was this section helpful? Why not Donate $2.50?

3.1. Conventions used in this document

No special conventions are used here, but you must be warned about the way commands are shown. This howto follows the classic Unix documentation: any command you type to your shell is prefixed by a prompt. It shows "user%" as the prompt for commands that do not require superuser privileges, and "root#" as the prompt for commands that need to run as root. I chose to use "root#" instead of a plain "#" to prevent confusion with snapshots from shell scripts (where the hash mark is used to define comment lines).

When ``Kernel Compile Options'' are shown, they are represented in the format used by menuconfig. They should be understandable even if you (like me) are not used to menuconfig. If you are in doubt about the options' nesting, then running the program once can always help. Was this section helpful? Why not Donate $2.50?

4.1. Linux Networking Resources.

There are a number of places where you can find good information about Linux networking.

There are a wealth of Consultants available to assist you. A search able listing can be found at: http://www.linuxports.com/.

Alan Cox, the current maintainer of the Linux kernel networking code, maintains a world wide web page containing highlights of current and new developments in Linux Networking: www.uk.linux.org.

There is a newsgroup in the Linux news hierarchy dedicated to networking and related matters at this location: comp.os.linux.networking

You can also subscribe to a mailing list where you may ask questions relating to Linux networking. Send an email message for a subscription to:

To: majordomo@vger.rutgers.edu Subject: anything at all Message: subscribe linux-net

Please remember to include as much relevant detail about the problem as possible. You should specify the versions of software that you are using (especially the kernel version), the version of tools such as pppd/ or dip , and the exact nature of the problem(s) that you are experiencing. This means you should take notes of both the exact syntax of error message(s) you receive, and of any commands that you are issuing. Was this section helpful? Why not Donate $2.50?

4.2. Sources of non-linux-specific network information.

If you are after some basic tutorial information on tcp/ip networking, then I recommend you take a look at the following documents:

If you are after some more detailed information on tcp/ip networking, then I highly recommend:

"Inter networking with TCP/IP, Volume 1: Principles, Protocols and Architecture, by Douglas E. Comer, ISBN 0-13-227836-7, Prentice Hall publications, Third Edition, 1995."

If you are wanting to learn about how to write network applications in a Unix compatible environment, then I recommend:

"Unix Network Programming, by W. Richard Stevens, ISBN 0-13-949876-1, Prentice Hall Publications, 1990."

A second edition of this book is appearing on the bookshelves. The new book is made up of three volumes. Check Prenice-Hall's web site for further details.

You might also try the comp.protocols.tcp-ip newsgroup.

RFCs are an important source of specific technical information relating to the Internet and the tcp/ip suite of protocols. RFC is an acronym for `Request For Comment' and it is the standard means of submitting and documenting Internet protocol standards. There are many RFC repositories. Many of these sites are ftp sites. Others provide World Wide Web access (with an associated search engine) that allows you to search the RFC database for particular keywords.

One possible source for RFCs is at Nexor RFC database. Was this section helpful? Why not Donate $2.50?

5.1. What do I need to start ?

Before you start building or configuring your network, you will need certain items. The most important of these are:

5.2. Where should I put the configuration commands ?

There are a few different approaches to Linux system boot procedures. After the kernel boots, it always executes a program called `init'. The init program then reads its configuration file called /etc/inittab and commences the boot process. There are a few different flavors of init Everyone now seems to be gravitating to the System V (Five) flavor, developed by Miguel van Smoorenburg.

Despite the fact that the init program is always the same, the setup of system boot is organized in a different way by each distribution.

Usually the /etc/inittab file contains an entry looking something like:

si::sysinit:/etc/init.d/boot

This line specifies the name of the shell script file that actually manages the boot sequence. This file is somewhat equivalent to the AUTOEXEC.BAT file in MS-DOS.

There are usually other scripts that are called by the boot script, and often the network is configured within one of these scripts.

The following table may be used as a guide for your system:

--------------------------------------------------------------------------- Distrib. | Interface Config/Routing | Server Initialization --------------------------------------------------------------------------- Debian | /etc/init.d/network | /etc/rc2.d/* --------------------------------------------------------------------------- Slackware| /etc/rc.d/rc.inet1 | /etc/rc.d/rc.inet2 --------------------------------------------------------------------------- RedHat | /etc/rc.d/init.d/network | /etc/rc.d/rc3.d/* ---------------------------------------------------------------------------

Note that Debian and Red Hat use a whole directory to host scripts that fire up system services (and usually information does not lie within these files: for example, Red Hat systems store all of system configuration in files under /etc/sysconfig, where it is retrieved by boot scripts). If you want to grasp the details of the boot process, my suggestion is to check /etc/inittab and the documentation that accompanies init. Linux Journal is also going to publish an article about system initialization, and this document will point to it as soon as it is available on the web.

Most modern distributions include a program that will allow you to configure many of the common sorts of network interfaces. If you have one of these, you should see if it will do what you want before attempting a manual configuration.

----------------------------------------- Distrib | Network configuration program ----------------------------------------- RedHat | /usr/bin/netcfg Slackware | /sbin/netconfig -----------------------------------------

Was this section helpful? Why not Donate $2.50?

5.3. Creating your network interfaces.

In many Unix operating systems, the network devices have appearances in the /dev directory. This is not so in Linux. In Linux, the network devices are created dynamically in software, and they do not require device files to be present.

In the majority of cases, the network device is automatically created by the device driver (while it is initializing and locating your hardware). For example, the Ethernet device driver creates eth[0..n] interfaces sequentially as it locates your Ethernet hardware. The first Ethernet card found becomes eth0, the second eth1 etc.

In some cases though, notably with slip and ppp, the network devices are created through the action of some user program. The same sequential device numbering applies, but the devices are not created automatically at boot time. The reason for this is that unlike Ethernet devices, the number of active slip or ppp devices may vary during the uptime of the machine. These cases will be covered in more detail in later sections. Was this section helpful? Why not Donate $2.50?

5.4. Configuring a network interface. Kernels 2.0 and 2.2

When you have all of the programs you need (and your address and network information), you can configure your network interfaces. When we talk about configuring a network interface, we are talking about two items. One is the process of assigning appropriate addresses to a network device. The second is setting the appropriate values for other configurable parameters of a network device. The program most commonly used to do this is the ifconfig (interface configure) command.

Typically you would use a command similar to the following:

root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up

In this example, I'm configuring an Ethernet interface `eth0' with the IP address `192.168.0.1' and a network mask of `255.255.255.0'. The `up' that trails the command tells the interface that it should become active (but can usually be omitted) since it is the default. To shutdown an interface, you can just call ``ifconfig eth0 down''.

The kernel assumes certain defaults when you are configuring interfaces. For example, you may specify the network address and broadcast address for an interface. If you don't (as in my example above), then the kernel will make reasonable guesses as to what these addresses should be. If you don't supply a netmask then on the network class of the IP address is auto-configured. In my example, the kernel would assume that it is a class-C network that is being configured on the interface. It would thus configure a network address of `192.168.0.0' ,and a broadcast address of `192.168.0.255' for the interface.

There are many other options to the ifconfig command. The most important of these are:

With the release of Kernel 2.2, there are a number of options available that are not listed above. Some of the most interesting ones are tunneling and IPV6. The ifconfig parameters for kernel 2.2 are listed below.

5.5. Configuring your Name Resolver.

The `Name Resolver' is a part of the linux standard library. Its prime function is to provide a service to convert human-friendly hostnames (like `ftp.funet.fi' ) into machine friendly IP addresses (such as 128.214.248.6).

5.6. Configuring your loopback interface.

The `loopback' interface is a special type of interface that allows you to make connections to yourself. There are various reasons why you might want to do this. For example, you may wish to test some network software without interfering with anybody else on your network. By convention, the IP address `127.0.0.1' has been assigned specifically for loopback. No matter what machine you go to, if you open a telnet connection to 127.0.0.1 you will always reach the local host.

Configuring the loopback interface is simple, and it must be done (but note that this task is usually performed by the standard initialization scripts).

root# ifconfig lo 127.0.0.1 root# route add -host 127.0.0.1 lo

We'll talk more about the route command in the next section. Was this section helpful? Why not Donate $2.50?

5.7. Routing.

Routing is a big topic. It is easily possible to write large volumes of text about the subject. Most of you will have fairly simple routing requirements; some of you will not. I will cover some basic fundamentals of routing only. If you are interested in more detailed information, then I suggest you refer to the references provided at the start of this document.

Let's start with a definition. What is IP routing? Here is one that I'm using:

"IP Routing is the process by which a host with multiple network connections decides where to deliver the IP datagrams that it has received."

It might be useful to illustrate this with an example. Imagine a typical office router. It might have a PPP link off the Internet, a number of Ethernet segments feeding the workstations, and another PPP link off to another office. When the router receives a datagram on any of its network connections, it uses the routing mechanism to determine which interface it should send the datagram to next. Simple hosts also need to route. All Internet hosts have two network devices, one is the loopback interface described above, and the other is the one it uses to talk to the rest of the network (perhaps an Ethernet, perhaps a PPP, or an SLIP serial interface).

Ok, so how does routing work ? Each host keeps a special list of routing rules called a "routing table". This table contains rows which typically contain at least three fields: the first is a destination address, the second is the name of the interface where the datagram is to be routed, and the third is optionally the IP address of another machine that carries the datagram on its next step through the network. You can see this table in linux by using the following command:

user% cat /proc/net/route

or by using either of the following commands:

user% /sbin/route -n user% netstat -r

The routing process is fairly simple. The incoming datagram is received, the destination address (who it is for) is examined, and then it is compared with each entry in the table. The entry that best matches that address is selected, and the datagram is forwarded to the specified interface. If the gateway field is filled, then the datagram is forwarded to that host via the specified interface. The destination address is otherwise assumed to be on the network supported by the interface.

To manipulate this table, a special command is used. This command takes command line arguments and converts them into kernel system calls. These calls request the kernel to add, delete, or modify entries in the routing table. The command is called `route'.

Here is a simple example. Imagine you have an Ethernet network. You've been told it is a class-C network with an address of 192.168.1.0. You've been supplied with an IP address of 192.168.1.10 for your use, and you have been told that 192.168.1.1 is a router connected to the Internet.

The first step is to configure the interface as described earlier. You would use a command similar to the following:

root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up

You now need to add an entry into the routing table to tell the kernel that datagrams for all hosts with addresses that match 192.168.1.* should be sent to the ethernet device. You would use a command similar to:

root# route add -net 192.1Ethernetetmask 255.255.255.0 eth0

Note the use of the `-net' argument to tell the route program that this entry is a network route. Your other choice here is a `-host' route, which is a route that is specific to one IP address.

This route will enable you to establish IP connections with all of the hosts on your ethernet segment. But what about all of the IP hosts that aren't on your ethernet segment?

It would be a very difficult job to have to add routes to every possible destination network. There is a special trick that is used to simplify this task. The trick is called the `default' route. The default route matches every possible destination (but poorly). If any other entry exists that matches the required address, it will be used instead of the default route. The idea of the default route is simply to enable you to say in effect: "and everything else should go here". In this example you would use an entry like:

root# route add default gw 192.168.1.1 eth0 on them

The `gw' argument tells the route command that the next argument is the IP address, or name, of a gateway or router machine. This machine is where all datagrams matching the entry should be directed to for further routing. on them

So, your complete configuration would look like:

root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0 root# route add default gw 192.168.1.1 eth0 on them

is

If you take a close look at your network `rc' files, you will find that at least one of them looks very similar to this configuration (a very common one).

Let's now look at a slightly more complicated routing configuration. Let's imagine we are configuring the router we looked at earlier (the one supporting the PPP link to the Internet, and the lan segments feeding the workstations in the office). Lets imagine the router has three ethernet segments, and it also has one PPP link. Our routing configuration would look something like the fEthernet:

root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0 root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1 root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2 root# route add default ppp0

Each of the workstations would use the simpler form presented above. Only the router needs to specify each of the network routes separately. The default route for the workstations mechanism will capture all of them, letting the router worry about splitting them up appropriately. You may be wondering why the default route presented doesn't specify a `gw'. The reason for this is simple: serial link protocols such as PPP and SLIP only have two hosts on their network (one at each end). To specify the host at the other end of the link as the gateway is both pointless and redundant. You do not need to specify a gateway for these types of network connections as there is no other choice. Other network types, such as ethernet, arcnet, or token ring, do actually require the gateway to be specified (as these networks support Ethernetmbers of hosts ).

5.8. Configuring your network servers and services.

Network servers and services are programs that allow a remote user to make use of your Linux machine. Server programs listen on network ports. Network ports are a means of addressing a particular service on any particular host. They are how a server knows the difference between an incoming telnet connection and an incoming ftp connection. The remote user establishes a network connection to your machine. The server program (the network daemon program) listening on that port accepts the connection and then executes. There are two ways that network daemons may operate. Both are commonly employed in practice. The two ways are:

There are two important files that need to be configured. They are the /etc/services file (which assigns names to port numbers), and the /etc/inetd.conf file (the configuration file for the inetd network daemon).

5.9. Other miscellaneous network related configuration files.

There are a number of miscellaneous files relating to network configuration under linux that might be of interest. You may never have to modify these files, but it is worth describing them so you know what they contain and why they are used.

5.10. Network Security and access control.

Let me start this section by warning you that securing your machine and network against malicious attack is a complex art. I do not consider myself an expert in this field. The following mechanisms I describe will help. If you are serious about security, then I recommend you do some research of your own into the subject. There are many good references on the Internet relating to the security, including the Security-HOWTO

An important rule of thumb is: `Don't run servers you don't intend to use'. Many distributions come configured with all sorts of services that are configured and automatically started. To ensure even a minimum level of safety, you should go through your /etc/inetd.conf file. Comment out (place a `#' at the start of the line) any entries for services you don't intend to use. Good candidates are services such as: shell, login, exec, uucp, ftp and informational services such as finger, netstat and systat.

There are all sorts of security and access control mechanisms. I'll now describe the most elementary:

6.1. Supported Ethernet Cards

6.2. General Ethernet Information

Ethernet devices names are `eth0', `eth1', `eth2' etc. The first card detected by the kernel is assigned `eth0', and the rest are assigned sequentially in the order in which they are detected.

Once you have your kernel properly built to support your ethernet card, configuration of the card is easy.

Typically you would use something like (which most distributions already do for you, if you configured them to support your ethernet):

root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up root# route add -net 192.168.0.0 netmask 255.255.255.0 eth0

Most of the ethernet drivers were developed by Donald Becker Was this section helpful? Why not Donate $2.50?

6.3. Using 2 or more Ethernet Cards in the same machine

7.1. Kernel Level Options

This section includes information on setting IP options within the kernel at boot time. An example of these options are ip_forward or ip_bootp_agent. These options are used by setting the value to a file in the

/proc/sys/net/ipv4/

directory. The name of the file is the name of the command.

For example, to set ip_forward enabled, you would type

echo 1 > /proc/sys/net/ipv4/ip_forward

7.2. EQL - multiple line traffic equaliser

The EQL device name is `eql'. With the standard kernel source, you may have only one EQL device per machine. EQL provides a means of utilizing multiple Point-to-Point lines such as PPP, slip, or plip as a single logical link to carry tcp/ip. Often it is cheaper to use multiple lower speed lines than to have one high speed line installed.

Kernel Compile Options:

Network device support ---> [*] Network device support <*> EQL (serial line load balancing) support

To support this mechanism, the machine at the other end of the lines must also support EQL. Linux, Livingstone Portmasters and newer dial-in servers support compatible facilities.

To configure EQL you will need the eql tools which are available from: metalab.unc.edu.

Configuration is fairly straightforward. You start by configuring the eql interface. The eql interface is just like any other network device. You configure the IP address and mtu using the ifconfig utility. Here is an example:

root# ifconfig eql 192.168.10.1 mtu 1006

Next, you need to manually initiate each of the lines you will use. These may be any combination of Point-to-Point network devices. How you initiate the connections will depend on what sort of link they are. Refer to the appropriate sections for further information.

Lastly you need to associate the serial link with the EQL device. This is called `enslaving' : it is done with the eql_enslave command as shown:

root# eql_enslave eql sl0 28800 root# eql_enslave eql ppp0 14400

The `estimated speed' parameter you supply eql_enslave doesn't do anything directly. It is used by the EQL driver to determine what share of the datagrams that device should receive. You can then fine tune the balancing of the lines by playing with this value.

To disassociate a line from an EQL device, use the eql_emancipate command as shown:

root# eql_emancipate eql sl0

You add routing as you would for any other Point-to-Point link, except that your routes should refer to the eql device rather than the actual serial devices. You would typically use:

root# route addthemselveseql

The EQL driver was developed by Simon Janes simon@ncm.com.

Was this section helpful? Why not Donate $2.50?

7.3. IP Accounting (for Linux-2.0)

The IP accounting features of the Linux kernel allow you to collect and analyze some network usage data. The data collected comprises the number of packets and the number of bytes accumulated since the figures were last reset. You may specify a variety of rules to categorize the figures to suit your purpose. This option has been removed in kernel 2.1.102 because the old ipfwadm-based firewalling was replaced by ``ipfwchains''.

Kernel Compile Options:

Networking options ---> [*] IP: accounting

After you have compiled and installed the kernel, you need to use the ipfwadm command to configure IP accounting. There are many different ways of breaking down the accounting information. I've picked a simple example of what might be useful. You should read the ipfwadm man page for more information.

Scenario: You have a ethernet network that is linked to the Internet via a PPP link. On the ethernet, you have a machine that offers a number of services. You are interested in knowing how much traffic is generated by each of ftp (and world wide web traffic), as well as total tcp and udp traffic.

You might use a command set that looks like the following (shown as a shell script):

#!/bin/sh # # Flush the accounting rules ipfwadm -A -f # # Set shortcuts localnet=44.136.8.96/29 any=0/0 # Add rules for local ethernet segment ipfwadm -A in -a -P tcp -D $localnet ftp-data ipfwadm -A out -a -P tcp -S $localnet ftp-data ipfwadm -A in -a -P tcp -D $localnet www ipfwadm -A out -a -P tcp -S $localnet www ipfwadm -A in -a -P tcp -D $localnet ipfwadm -A out -a -P tcp -S $localnet ipfwadm -A in -a -P udp -D $localnet ipfwadm -A out -a -P udp -S $localnet # # Rules for default ipfwadm -A in -a -P tcp -D $any ftp-data ipfwadm -A out -a -P tcp -S $any ftp-data ipfwadm -A in -a -P tcp -D $any www ipfwadm -A out -a -P tcp -S $any www ipfwadm -A in -a -P tcp -D $any ipfwadm -A out -a -P tcp -S $any ipfwadm -A in -a -P udp -D $any ipfwadm -A out -a -P udp -S $any # # List the rules ipfwadm -A -l -n #

The names ``ftp-data'' and ``www'' refer to lines in /etc/services. The last command lists each of the Accounting rules and displays the collected totals.

An important point to note when analyzing IP accounting is that totals for all rules that match will be incremented. To obtain differential figures, you need to perform appropriate maths. For example, if I wanted to know how much data was not ftp or www, I would subtract the individual totals from the rule that matches all ports.

root# ipfwadm -A -l -n IP accounting rules pkts bytes dir prot source destination ports 0 0 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 20 0 0 out tcp 44.136.8.96/29 0.0.0.0/0 20 -> * 10 1166 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 80 10 572 out tcp 44.136.8.96/29 0.0.0.0/0 80 -> * 252 10943 in tcp 0.0.0.0/0 44.136.8.96/29 * -> * 231 18831 out tcp 44.136.8.96/29 0.0.0.0/0 * -> * 0 0 in udp 0.0.0.0/0 44.136.8.96/29 * -> * 0 0 out undp 44.136.8.96/29 0.0.0.0/0 * -> * 0 0 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 20 0 0 out tcp 0.0.0.0/0 0.0.0.0/0 20 -> * 10 1166 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 80 10 572 out tcp 0.0.0.0/0 0.0.0.0/0 80 -> * 253 10983 in tcp 0.0.0.0/0 0.0.0.0/0 * -> * 231 18831 out tcp 0.0.0.0/0 0.0.0.0/0 * -> * 0 0 in udp 0.0.0.0/0 0.0.0.0/0 * -> * 0 0 out udp 0.0.0.0/0 0.0.0.0/0 * -> *

7.4. IP Aliasing

There are some applications where being able to configure multiple IP addresses to a single network device is useful. Internet Service Providers often use this facility to provide a "customized" feature to their World Wide Web and ftp offerings for their customers. You can refer to the ``IP-Alias mini-HOWTO'' for more information.

Kernel Compile Options:

Networking options ---> .... [*] Network aliasing .... <*> IP: aliasing support

After compiling and installing your kernel with IP_Alias support, configuration is very simple. The aliases are added to virtual network devices associated with the actual network device. A simple naming convention applies to these devices being <devname>:<virtual dev num>, e.g. eth0:0, ppp0:10 etc. Note that the the ifname:number device can only be configured after the main interface has been set up.

For example, assume you have an ethernet network that supports two different IP subnetworks simultaneously. You also wish your machine to have direct access to both. You could use something like:

root# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0 root# ifconfig eth0:0 192.168.10.1 netmask 255.255.255.0 up root# route add -net 192.168.10.0 netmask 255.255.255.0 eth0:0

To delete an alias, add a `-' to the end of its name, then refer to it. It is as simple as:

root# ifconfig eth0:0- 0

All routes associated with that alias will also be deleted automatically. Was this section helpful? Why not Donate $2.50?

7.5. IP Firewall (for Linux-2.0)

IP Firewall and Firewalling issues are covered in more depth in the Firewall-HOWTO. IP Firewalling allows you to secure your machine against unauthorized network access by filtering or allowing datagrams from or to IP addresses that you nominate. There are three different classes of rules; incoming filtering, outgoing filtering, and forwarding filtering. Incoming rules are applied to datagrams that are received by a network device. Outgoing rules are applied to datagrams that are to be transmitted by a network device. Forwarding rules are applied to datagrams that are received and are not for this machine (ie. datagrams that would be routed).

Kernel Compile Options:

Networking options ---> [*] Network firewalls .... [*] IP: forwarding/gatewaying .... [*] IP: firewalling [ ] IP: firewall packet logging

Configuration of the IP firewall rules is performed using the ipfwadm command. As I mentioned earlier, I am not a security expert. I will present an example you can use. You should, however, do your own research and develop your own rules.

Using your linux machine as a router and firewall gateway to protect your local network from unauthorized access (from outside your network) is probably the most common use of an IP firewall.

The following configuration is based on a contribution from Arnt Gulbrandsen: <agulbra@troll.no>.

The example describes the configuration of the firewall rules on the Linux firewall/router machine illustrated below:

- - \ | 172.16.37.0 \ | /255.255.255.0 \ --------- | | 172.16.174.30 | Linux | | NET =================| f/w |------| ..37.19 | PPP | router| | -------- / --------- |--| Mail | / | | /DNS | / | -------- - -

The following commands would normally be placed in an rc file. They would be automatically started each time the system boots. For maximum security, they would be performed after the network interfaces are configured (but before the interfaces are actually brought up) to prevent anyone gaining access while the firewall machine is rebooting.

#!/bin/sh # Flush the 'Forwarding' rules table # Change the default policy to 'accept' # /sbin/ipfwadm -F -f /sbin/ipfwadm -F -p accept # # .. and for 'Incoming' # /sbin/ipfwadm -I -f /sbin/ipfwadm -I -p accept # First off, seal off the PPP interface # I'd love to use '-a deny' instead of '-a reject -y' but then it # would be impossible to originate connections on that interface too. # The -o causes all rejected datagrams to be logged. This trades # disk space against knowledge of an attack of configuration error. # /sbin/ipfwadm -I -a reject -y -o -P tcp -S 0/0 -D 172.16.174.30 # Throw away certain kinds of obviously forged packets right away: # Nothing should come from multicast/anycast/broadcast addresses # /sbin/ipfwadm -F -a deny -o -S 224.0/3 -D 172.16.37.0/24 # # and nothing coming from the loopback network should ever be # seen on a wire # /sbin/ipfwadm -F -a deny -o -S 127.0/8 -D 172.16.37.0/24 # accept incoming SMTP and DNS connections, but only # to the Mail/Name Server # /sbin/ipfwadm -F -a accept -P tcp -S 0/0 -D 172.16.37.19 25 53 # # DNS uses UDP as well as TCP, so allow that too # for questions to our name server # /sbin/ipfwadm -F -a accept -P udp -S 0/0 -D 172.16.37.19 53 # # but not "answers" coming to dangerous ports like NFS and # Larry McVoy's NFS extension. If you run squid, add its port here. # /sbin/ipfwadm -F -a deny -o -