7.6 Network Security

We'll now turn our attention beyond the single system and consider security in a network context. As with all types of system security, TCP/IP network security inevitably involves tradeoffs between ease-of-use issues and protection against (usually external) threats. And, as is true all too often with Unix systems, in many cases your options are all or nothing.

Successful network-based attacks result from a variety of problems. These are the most common types:

• Poorly designed services that perform insufficient authentication (or even none at all) or otherwise operate in an inherently insecure way (NFS and X11 are examples of facilities having such weaknesses that have been widely and frequently exploited).

• Software bugs, usually in a network-based facility (for example, sendmail) and sometimes in the Unix kernel, but occasionally, bugs in local facilities can be exploited by crackers via the network.

• Abuses of allowed facilities and mechanisms. For example, a user can create a .rhosts file in her home directory that will very efficiently and thoroughly compromise system security (these files are discussed later in this section).

• Exploiting existing mechanisms of trust by generating forged network packets impersonating trusted systems (known as IP spoofing).

• User errors of many kinds, ranging from innocent mistakes to deliberately circumventing security mechanisms and policies.

• Problems in the underlying protocol design, usually a failure to anticipate malicious uses. This sort of problem is often what allows a denial-of-service attack to succeed.

Attacks often use several vulnerabilities in combination.

Maintaining a secure system is an ongoing process, requiring a lot of initial effort and a significant amount of work on a permanent basis. One of the most important things you can do with respect to system and network security is to educate yourself about existing threats and what can be done to protect against them. I recommend the following classic papers as good places to start:

• Steven M. Bellovin, "Security Problems in the TCP/IP Protocol Suite." The classic TCP/IP security paper, available at http://www.research.att.com/~smb/papers/. Many of his other papers are also useful and interesting.

• Dan Farmer and Wietse Venema, " Improving the Security of Your Site by Breaking Into It," available at ftp://ftp.porcupine.org/pub/security/index.html. Another excellent discussion of the risks inherent in Internet connectivity.

We'll discuss TCP/IP network security by looking at how systems on a network were traditionally configured to trust one another and allow each other's users easy access. Then we'll go on to look at some of the ways that you can back off from that position of openness by considering methods and tools for restricting access and assessing the vulnerabilities of your system and network.

Security Alert Mailing Lists

One of the most important ongoing security activities iskeeping up with the latest bugs and threats. One way to do so is to read theCERT or CIAC advisories and then act on them. Doing so will often be inconvenient closing a security hole often requires some sort of software update from your vendor but it is the only sensible course of action.

One of the activities of the Computer Emergency Response Team (CERT) is administering an electronic mailing list to which its security advisories are posted as necessary. These advisories contain a general description of the vulnerability, detailed information about the systems to which it applies, and available fixes. You can add yourself to the CERT mailing list by sending email to [e-mail] with "subscribe cert-advisory" in the body of the message. Past advisories and other information are available from the CERT web site, http://www.cert.org.

The Computer Incident Advisory Capability (CIAC) performs a similar function, originally for Department of Energy sites. Their excellent web site is at http://www.ciac.org/ciac/.

7.6.1 Establishing Trust

Unless special steps are taken, users must enter a password each time they want access to the other hosts on the network. However, users have traditionally found this requirement unacceptably inconvenient, and so a mechanism exists to establish trust between computer systems which then allows remote access without passwords. This trust is also known as equivalence.

The first level of equivalence is the host level. The /etc/hosts.equiv configuration file establishes it. This file is simply a list of hostnames, each on a separate line.^[16] For example, the file for the system france might read:

^[16] The file may also contain NIS netgroup names in the form: +@name. However, the hosts.equiv file should never contain an entry consisting of a single plus sign, because this will match any remote user having the same login name as one in the local password file (except root).

spain.ahania.com  italy.ahania.com france.ahania.com

None, any, or all of the hosts in the network may be put in an /etc/hosts.equiv file. It is convenient to include the host's own name in /etc/hosts.equiv, thus declaring a host equivalent to itself. When a user from a remote host attempts an access (with rlogin, rsh, or rcp), the local host checks the file /etc/hosts.equiv. If the host requesting access is listed in /etc/hosts.equiv and an account with the same username as the remote user exists, remote access is permitted without requiring a password.

If the user is trying to log in under a different username (by using the -l option to rsh or rlogin), the /etc/hosts.equiv file is not used. The /etc/hosts.equiv file is also not enough to allow a superuser on one host to log in remotely as root on another host.

The second type of equivalence is account-level equivalence, defined in a file named .rhosts in a user's home directory. There are various reasons for using account-level instead of host-level equivalence. The most common cases for doing so are when users have different account names on the different hosts or when you want to limit use of the .rhosts mechanism to only a few users.

Each line of .rhosts consists of a hostname and, optionally, a list of usernames:

hostname [usernames]

If username is not present, only the same username as the owner of the .rhosts file can log in from hostname. For example, consider the following .rhosts file in the home directory of a user named wang:

england.ahania.com    guy donald kim russia.ahania.com     felix  usa.ahania.com        felix

The .rhosts allows the user felix to log in from the host russia or usa, and users named guy, donald, or kim to log in from the host england.

If remote access is attempted and the access does not pass the host-level equivalence test, the remote host then checks the .rhosts file in the home directory of the target account. If it finds the hostname and username of the person making the attempted access, the remote host allows the access to take place without requiring the user to enter a password.

Host-level equivalence is susceptible to spoofing attacks, so it is rarely acceptable anymore. However, it can be used safely in an isolated networking environment if it is set up carefully and in accord with the site's security policy.

Account-level equivalence is a bad idea all the time because the user is free to open up his account to anyone he wants, and it is a disaster when applied to the root account. I don't allow it on any of my systems.

7.6.1.1 The implications of trust

Setting up any sort of trust relationship between computer systems always carries a risk with it. However, the risks go beyond the interaction between those two systems alone. For one thing, trusts operates in a transitive manner (transitive trust). If hamlet trusts laertes, and laertes trusts ophelia, then hamlet trusts ophelia, just as effectively as if ophelia were listed in hamlet's /etc/hosts.equiv file (although not as conveniently). This level of transitivity is easy to see for a user who has accounts on all three systems; it also exists for all users on ophelia with access to any account on laertes that has access to any account on hamlet.

There is also no reason that such a chain need stop at three systems. The point here is that hamlet trusts ophelia despite the fact that hamlet's system administrator has chosen not to set up a trusting relationship between the two systems (by not including ophelia in /etc/hosts.equiv). hamlet's system administrator may have no control over ophelia at all, yet his system's security is intimately dependent on ophelia remaining secure.

In fact, Dan Farmer and Wietse Venema argue convincingly that an implicit trust exists between any two systems that allow users to log in from one to the other. Suppose system yorick allows remote logins from hamlet, requiring passwords in all cases. If hamlet is compromised, yorick is at risk as well; for example, some of hamlet's users undoubtedly use the same passwords on both systems which constitutes users' own form of account-level equivalence and a root account intruder on hamlet will have access to the encrypted passwords and most likely be able to crack some of them.

Taken to its logical conclusion, this line of reasoning suggests that any time two systems are connected via a network, their security to some extent becomes intertwined. In the end, your system's security will be no better than that of the least protected system on the network.

7.6.2 The Secure Shell

The secure shell is becoming the accepted mechanism for remote system access. The most widely used version isOpenSSH (see http://www.openssh.org). OpenSSH is based on the version originally written by TatuYlönen. It is now handled by the OpenBSD team. The secure shell provides an alternative to the traditional clear-text remote sessions using telnet or rlogin since the entire session is encrypted.

From an administrative point of view, OpenSSH is wonderfully easy to set up, and the default configuration is often quite acceptable in most contexts. The package consists primarily of a daemon, sshd; several user tools (ssh, the remote shell; sftp, an ftp replacement; and scp, an rcp replacement); and some related administrative utilities and servers (e.g., sftp-server).

Be sure you using a recent version of OpenSSH: some older versions have significant security holes. Also, I recommend usingSSH protocol 2 over the earlier protocol 1 as it closes several security holes.

The OpenSSH configuration file are stored in /etc/ssh. The most important of these is /etc/ssh/sshd_config. Here is a simple, annotated example of this file:

Protocol 2                          Only use SSH protocol 2. Port 22                             Use the standard port. ListenAddress 0.0.0.0               Only accept IPv4 addresses. AllowTcpForwarding no               Don't allow port forwarding. SyslogFacility auth                 Logging settings. LogLevel info Banner /etc/issue                   Display this file before the prompts. PermitEmptyPasswords no             Don't accept connections for accounts w/o passwords. PermitRootLogin no                  No root logins allowed. LoginGraceTime 600                  Disconnect after 5 minutes if no login occurs. KeepAlive yes                       Send keep alive message to the client. X11Forwarding no                    No X11 support. X11DisplayOffset 10 # sftp subsystem                    Enable the sftp subsystem. Subsystem  sftp  /usr/lib/ssh/sftp-server

This file is designed for a server using SSH in its simplest mode: user authentication occurs via normal user passwords (encrypted for transmission). The package also offers stricter authentication, which involves using public key cryptography to ensure that the remote session is originating from a known host. See the documentation for details on these features.

7.6.3 Securing Network Daemons

TCP/IP-related network daemons are started in two distinct ways. Majordaemons like named are started at boot time by one of the boot scripts. The second class of daemons are invoked on demand, when a client requests their services. These are handled by the TCP/IP "super daemon," inetd. inetd itself is started at boot time, and it is responsible for starting the other daemons that it controls as needed. Daemons controlled by inetd provide the most common TCP/IP user-oriented services: telnet, ftp, remote login and shells, mail retrieval, and so on.

inetd is configured via the file /etc/inetd.conf . Here are some sample entries in their conventional form:

#service  socket   prot  wait?   user  program arguments telnet    stream   tcp   nowait  root  /usr/sbin/in.telnetd in.telnetd tftp      dgram    udp   wait    root  /usr/sbin/in.tftpd in.tftpd -s /tftpboot

As indicated in the comment line, the fields hold the service name (as defined in /etc/services), the socket type, protocol, whether or not to wait for the command to return when it is started, the user who should run the command, and the command to run along with its arguments.

Generally, most common services will already have entries in /etc/inetd.conf. However, you may need to add entries for some new services that you add (e.g., Samba servers).

7.6.3.1 TCP Wrappers: Better inetd access control and logging

The free TCP Wrappers facility provides for finer control over which hosts are allowed to access what local network services than that provided by the standard TCP/IP mechanisms (hosts.equiv and .rhosts files). It also provides for enhanced logging of inetd-based network operations to the syslog facility. The package was written by Wietse Venema, and it is included automatically on most current Unix systems. It is also available from ftp://ftp.porcupine.org/pub/security/tcp_wrapper_7.6-ipv61.tar.gz (although the filename will undoubtedly change over time).

The package is centered around tcpd, an additional daemon positioned between inetd and the subdaemons that it manages. It requires that you modify inetd's configuration file,/etc/inetd.conf, replacing the standard daemons you want the facility to control with tcpd, as in these examples:

Before:  #service  socket  protocol  wait?  user  program arguments  shell     stream  tcp       nowait root  /usr/sbin/rshd rshd  login     stream  tcp       nowait root  /usr/sbin/rlogind rlogind  After:  #service  socket  protocol  wait?  user  program arguments  shell     stream  tcp       nowait root  /usr/sbin/tcpd /usr/sbin/rshd  login     stream  tcp       nowait root  /usr/sbin/tcpd /usr/sbin/rlogind

(Note that daemon names and locations vary from system to system). The tcpd program replaces the native program for each service that you want to place under its control. As usual, after modifying inetd.conf, you would send a HUP signal to the inetd process.

Once inetd is set up, the next step is to create the files /etc/hosts.allow and /etc/hosts.deny, which control what hosts may use which services. When a request for a network service comes in from a remote host, access is determined as follows:

• If /etc/hosts.allow authorizes that service for that host, the request is accepted and the real daemon is started. The first matching line in /etc/hosts.allow is used.

• When no line in hosts.allow applies, hosts.deny is checked next. If that file denies the service to the remote host, the request is denied. Again, the first applicable entry is used.

• In all other cases, the request is granted.

Here are some sample entries from hosts.allow:

fingerd         : ophelia hamlet laertes yorick lear duncan  rshd, rlogind   : LOCAL EXCEPT hamlet  ftpd            : LOCAL, .ahania.com, 192.168.4

The first entry grants access to the remote finger service to users on any of the listed hosts (hostnames may be separated by commas and or spaces). The second entry allows rsh and rlogin access by users from any local host defined as one whose hostname does not contain a period except the host hamlet. The third entry allows ftp access to all local hosts, all hosts in the domain ahania.com, and all hosts on the subnet 192.168.4.

Here is the /etc/hosts.deny file:

tftpd : ALL : (/usr/sbin/safe_finger -l @%h | /usr/bin/mail -s %d-%h root) &  ALL : ALL :

The first entry denies access to the Trivial FTP facility to all hosts. It illustrates the optional third field in these files: a command to be run whenever a request matches that entry.^[17] In this case, the safe_finger command is executed (it is provided as part of the package) in an attempt to determine who initiated the tftp command, and the results are mailed to root (%h expands to the remote hostname from which the request emanated, and %d expands to the name of the daemon for that service). This entry has the effect of intercepting requests to undesirable services (the package's author, Wietse Venema, refers to it as "bugging" that service and as "an early warning system" for possible intruder trouble). Note that the daemon must be active within /etc/inetd.conf for this to be effective; if you don't need or want such logging, it is better to comment out the corresponding line in /etc/inetd.conf to disable the service.

^[17] If you try to place a command into either of these files, you may get errors similar to this one from syslog:

The second entry in the example hosts.deny file serves as a final stopgap, preventing all access that has not been explicitly permitted.

tcpd uses the syslog daemon facility, using the warning (for denials of service) and info (for configuration file syntax errors) severity levels. You will probably want to use the swatch facility or a similar tool to sift thought the huge amounts of logging information it will generate (see Section 3.2).

This section describes basic TCP Wrappers functionality. There is also an extended configuration language available for more fine-grained access control. See the hosts_options manual page for details.

7.6.3.2 xinetd

Red Hat Linux systems provide an alternate version of inetd named xinetd, written by Panos Tsirigotis and Rob Braun. The package is also available for most Unix versions. xinetd provides many more features for access control and logging than the traditional daemon does. Some of its functionality overlaps with TCP Wrappers, although you can also use the two packages in concert. The package's home page is http://www.xinetd.org.

xinetd uses the configuration file /etc/xinetd . Here is an example from a Red Hat system:

defaults {      log_type                = SYSLOG authpriv      log_on_success          = HOST PID      log_on_failure          = HOST      instances               = 20 } includedir /etc/xinetd.d

The defaults section lists default settings that will apply to all subdaemons controlled by xinetd unless they are specifically overridden. In this case, the file specifies that logging should go to the syslog authpriv facility, and it selects the items to be included in log messages for successful and failing connection attempts. In addition, no server can have more than 20 processes running; this limit affects services that start additional server processes to handle increased request loads.

The final line specifies a directory location where additional configuration files are stored. Each file in the indicated directory will be used by xinetd. This feature allows you to store the settings for individual subdaemons in their own files.

Here is the configuration file for rlogin, which defines the same settings as a traditional /etc/inetd.conf entry:

service rlogin {         socket_type             = stream         protocol                = tcp         wait                    = no         user                    = root         server                  = /usr/sbin/in.rlogind         server-args             = -l         log_on_success          += USERID         log_on_failure          += USERID         disable                 = no }

The entry specifies items to include in log messages in addition to the defaults (the meaning of +=), and the final item enables the subdaemon.

If you want to use TCP Wrappers with xinetd, you specify tcpd as the server and the subdaemon as a server argument. For example, these configuration entries will cause TCP Wrappers to control the telnetd daemon:^[18]

^[18] Most inetd-controlled daemons take the daemon name as their first argument. xinetd knows this and so automatically passes the command name from the server entry as the first argument when the daemon is started. This is a convenience feature which makes it unnecessary to include the server name in the server_args entry. However, when TCP Wrappers is involved, this process would be incorrect, as the daemon is now specified in server_args rather than server. This flag is designed to handle this case, and it causes the command name from server_args to be inserted into the resulting daemon-starting command in the appropriate location.

    flags       = NAMEINARGS     server      = /usr/sbin/tcpd     server_args = /usr/sbin/in.telnetd

Here is a sample entry for the imapd daemon that illustrates the use of access control:

service imap {     socket_type    = stream     protocol       = tcp     wait           = no     user           = root     server         = /usr/sbin/imapd     only_from      = 192.168.10.0 localhost     no_access      = dalton.ahania.com     access_times   = 07:00-20:00     banner_fail    = /usr/etc/deny_banner }

The only_from entry specifies the hosts that are allowed to use this service; requests from any remote host not on the specified subnet will be refused. The no_access entry performs the opposite function and denies access to the specified host(s).

The access_times entry specifies when the service is available to users who are allowed to use it.

The final entry specifies a file to be displayed whenever a connection is refused (or fails for some other reason).

See the xinetd.conf manual page for details on all of the available configuration options.

7.6.3.3 Disable what you don't need

A better solution to securing some services is to remove then altogether. You can decide to disable some of the TCP/IPdaemons in the interest of system security or performance (each places a small but measurable load on the system). There are, naturally, consequences for eliminating certain daemons. If you disable rwhod, then the rwho and ruptime commands won't work.

To disable a daemon like rwhod, comment out the lines that start it in your system initialization files. For example, the following lines are typical of those used to start rwhod:

#if [ -f /etc/rwhod ]; then  #   /etc/rwhod; echo -n ' rwhod' > /dev/console  #fi

Disabling services managed by the inetd daemon is accomplished by commenting out the corresponding line from /etc/inetd.conf. For example, these lines disable the tftp and rexd services (both notorious security holes):

#service  socket     protocol wait?   user     program arguments # #tftp     dgram      udp      nowait  nobody   /usr/sbin/tftpdtftpd -n  #rexd     sunrpc_tcp tcp      wait    root     /usr/sbin/rpc.rexd  rexd 100017 1

When inetd is running, send it a HUP signal to get it to reread its configuration file.

In general, you should disable inetd services that you are not using. Make it one of your short-term goals to figure out what every entry in its configuration file does and to get rid of the ones you don't need. Some likely candidates for commenting out: tftp and bootps (except for boot servers for diskless workstations), rexd, uucp (seldom has any effect on the real uucp facility), pop-2 and pop-3 (if you are not using these mail-related services), and netstat, systat, and finger (the latter three give away too much gratuitous information that is helpful to crackers run the command telnet localhost for the first two to see why).

On AIX systems, use SMIT to remove services that are controlled by the system resource controller.

7.6.4 Port Scanning

Port scanning is the process of searching a network for available network services.The technique is used by potential intruders to find possible points of attack on a system. For this reason, you need to have at least a basic understanding of port-scanning tools.

The nmap utility is one of the most widely used port scanners. Its home page is http://www.insecure.org/nmap/.

Here is a sample nmap run that scans ports on host kali:

# nmap kali Starting nmap ( www.insecure.org/nmap/ ) Interesting ports on kali.ahania.com (192.168.19.84): (The 1529 ports scanned but not shown below are in state: closed) Port       State       Service 22/tcp     open        ssh 23/tcp     open        telnet 25/tcp     open        smtp 37/tcp     open        time 79/tcp     open        finger 80/tcp     open        http 512/tcp    open        exec 513/tcp    open        login 514/tcp    open        shell 515/tcp    open        printer 4559/tcp   open        hylafax 6000/tcp   open        X11 Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds

This information is quite useful to a system administrator. It reveals that at least one questionable service is running (the finger service). In addition, this one told me that I have forgotten to remove the web server from this system (why anyone would think it is a good idea to enable a web server as part of the operating system installation process is beyond me).

As this example illustrates, running nmap on your own hosts can be a useful security diagnostic tools. Be aware that running it on hosts that you do not control is a seriousethical breach.

There are many utilities that watch for and report port-scanning attempts. I don't have any recent experience with any of them and so can't recommend any particular package. However, a web search for "detect port scan" and similar phrases will yield a wealth of candidates.

7.6.5 Defending the Border: Firewalls and Packet Filtering

Firewall systems represent an attempt to hold on to some of the advantages of a direct Internet connection while mitigating as many of the risks associated with it as possible. A firewall is placed between the greater Internet and the site to be protected; firewalls may also be used within a site or organization to isolate some systems from others (remember that not all threats are external).

The definitive work on firewalls is Firewalls and Internet Security: Repelling the Wily Hacker by William R.Cheswick and Steven M. Bellovin (Addison-Wesley). Another excellent work is Building Internet Firewalls by Elizabeth D. Zwicky, Simon Cooper, and D. Brent Chapman (O'Reilly & Associates).

Don't underestimate the amount of work it takes to set up and maintain an effective firewall system. The learning curve is substantial, and only careful, continuous monitoring can ensure continuing protection. Don't let your management, colleagues, or users underestimate it either. And contrary to what the many companies in the firewall business will tell you, it's not something you can buy off the shelf.

By being placed between the systems to be protected and those they need to be protected from, a firewall is in a position to stop attacks and intruders before they ever reach their target. Firewalls can use a variety of mechanisms for doing so. Cheswick and Bellovin identify three main types of protection:

Packet filtering

Network packets are examined before being processed, and those requesting access that is not allowed or are suspicious in any way are discarded (or otherwise handled). For example, filtering out packets coming from the external network that claim to be from a host on the internal network will catch and eliminate attempts at IP spoofing.

Packet filtering can be done on a variety of criteria, and it may be performed by a router, a PC with special software, or a Unix system with this capability. The most effective packet filters, whether hardware or software based, will have these characteristics:

• The ability to filter on source system, destination system, protocol, port, flags, and/or message type.

• The ability to filter both when a packet is first received by the device (on input) and when it leaves the device (on output).

• The ability to filter both incoming and outgoing packets.

• The ability to filter based on both the source and destination ports. In general, the more flexibly combinable the filtering criteria are, the better.

• The ability to filter routes learned from external sources.

• The ability to disable source routing.

• The ability to disable reprogramming from the network (or any location other than the console).

Even if a server is not functioning as a firewall or a router, you may still want to perform packet filtering on it as doing so will circumvent many sorts of attacks. Minimal filtering includes ensuring that outgoing packets have a source address that belongs in your network (this is good-citizen filtering, which detects IP spoofing from within your network), and checking that incoming packets don't claim to have come from inside your network (this thwarts most incoming IP spoofing).

Application-level protection

Firewalls typically offer very little in the way of network services; indeed, one way to set one up initially is remove or disable every network-related application, and then slowly, carefully add a very few of them back in. All nonessential services are removed from a firewall, and the ones that are offered are often replacements for the standard versions, with enhanced authentication, security checking, and logging capabilities.

Substituting an alternate and most often, much simpler, more straightforward, and less feature-rich versions of the usual applications has the additional advantage that most cracker attacks will be simply irrelevant, since they are typically aimed at standard network components. The vulnerabilities of, say, sendmail, are not as important if you are using something else to move electronic mail messages across the firewall.

Connection relaying for outgoing traffic

Users inside the firewall perimeter can still access the outside world without introducing additional risk if the firewall completes the connection between the inside and outside itself (rather than relying on the standard mechanisms). For example, TCP/IP connections can be relayed by a simple program that passes data between the two discrete networks independently of any TCP/IP protocols.

Most firewalls employ a combination of strategies. (Note that Cheswick and Bellovin discourage the use ofpacket filtering alone in creating a firewall design.)

The firewall system itself must be secured against attack. Typically, all nonessential operating system commands and features are removed (not just networking-related ones). Extensivelogging is conducted at every level of the system, usually with automated monitoring as well (firewall systems need lots of disk space), and probably with some redundancy to a write-only logging host and/or a hardcopy device. The root account is usually protected with a smart card or another additional authentication system, and there are few or no other user accounts on the firewall system.

Figure 7-3 illustrates some possible firewallconfigurations.

Figure 7-3. Some firewall configuration options

Configuration 1 uses a single host connected via separate network adapters to the internal and external network. A router may also be placed in front of the computer in this scheme. Packets are not forwarded between the two network interfaces by TCP/IP; rather, they are handled at the application or circuit level. This type of configuration is very tricky to make secure, because the firewall host is physically present on both networks.

Configuration 2, an arrangement referred to as belt-and-suspenders from how their interconnections look in diagrams like this one, physically separates the connections to the internal and external networks across two distinct hosts. In a variation of this arrangement, the router between the two hosts is replaced by a direct network connection, using separate network adapters; this firewall mini-network need not even run TCP/IP.

Configuration 3 is a still more paranoid modification of number 2, in which the connection between the two firewall systems is not permanent but is created only on demand, again using a separate mechanism from the network interfaces to the internal and external networks.

Configuration 4 represents the only way you can be absolutely sure that your network is completely protected from external threats (at least those coming in over a network wire).

Most Unix systems are suitable for adaptation as firewalls, although using routers for this purpose is more common and generally more secure. However, free operating systems like Linux and FreeBSD systems make decent, low-cost choices when configured with the proper software, and they have the advantage that all the source code for the operating system is readily available.

At its heart, an effective firewall design depends on formulating a very thorough and detailed security policy (including how you plan to deal with potential intruders). You need to be able to state very precisely what sorts of activities and accesses you will and will not permit. Only then will yoxu be in a position to translate these restrictions into actual hardware and software implementations.