Mac OS X Unleashed

By John Ray and William C. Ray

• Table of Contents
  • Copyright
  • About the Author
  • Acknowledgments
  • Tell Us What You Think!
  • Introduction
  • Part I: Introduction to Mac OS X
  • Chapter 1. Mac OS X Component Architecture
  • Chapter 2. Installing Mac OS X
  • Chapter 3. Mac OS X Basics
  • Chapter 4. The Finder: Working with Files and Applications
  • Chapter 5. Running Classic Mac OS Applications
  • Part II: Inside Mac OS X
  • Chapter 6. Native Utilities and Applications
  • Chapter 7. Internet Communications
  • Chapter 8. Installing Third-Party Applications
  • Part III: User-Level OS X Configuration
  • Chapter 9. Network Setup
  • Chapter 10. Printer and Font Management
  • Chapter 11. Additional System Components
  • Part IV: Introduction to BSD Applications
  • Chapter 12. Introducing the BSD Subsystem
  • Chapter 13. Common Unix Shell Commands: File Operations
  • Part V: Advanced Command-Line Concepts
  • Chapter 14. Advanced Shell Concepts and Commands
  • Chapter 15. Command-Line Applications and Application Suites
  • Chapter 16. Command-Line Software Installation
  • Chapter 17. Troubleshooting Software Installs, and Compiling and Debugging Manually
  • Chapter 18. Advanced Unix Shell Use: Configuration and Programming (Shell Scripting)
  • Part VI: Server/Network Administration
  • Chapter 19. X Window System Applications
  • Chapter 20. Command-Line Configuration and Administration
  • Chapter 21. AppleScript
  • Chapter 22. Perl Scripting and SQL Connectivity
  • Chapter 23. File and Resource Sharing with NetInfo
  • Chapter 24. User Management and Machine Clustering
  • Chapter 25. FTP Serving
  • Chapter 26. Remote Access and Administration
  • Chapter 27. Web Serving
  • Part VII: Server Health
  • Chapter 28. Web Programming
  • Chapter 29. Creating a Mail Server
  • Chapter 30. Accessing and Serving a Windows Network
  • Chapter 31. Server Security and Advanced Network Configuration
    • Why Bother with Network Security
    • Disabling Access
    • Intrusion Detection
    • Where to Go from Here
    • Summary
  • Chapter 32. System Maintenance
  • Appendix A. Command-Line Reference
  • Appendix B. Administration Reference

Disabling Access

An important part of securing your machine is limiting access to it. In this section, we will look at choosing services that run on your machine, using TCP Wrappers to restrict access, and some common-sense preventive measures you can take.

Selecting Services in the Graphical User Interface

As you might recall, Apple ships OS X with many services disabled. In many of the Unix operating systems, you have to be careful to disable some common services that are turned on by default, but that you might not actually need. With OS X, however, many of these common services are disabled. Instead, if you want to run a common service, such as a remote login service, you specifically have to turn it on in OS X.

In the Sharing pane of the System Preferences panel, controls to enable or disable the SSH, FTP, Web, and AppleShare servers are available. Choose only those services that you really need. Remember, the more services you turn on, the more vulnerable to attack your machine becomes.

Selecting Services Manually

As you saw earlier in the book, the actual controls that can be accessed via a graphical user interface are stored in a variety of places on the system.

/etc/inetd.conf

Some of the common services on your system, such as FTP and telnet, are controlled in the /etc/inetd.conf file. If you remembered to look at the /etc/inetd.conf file before turning on FTP in the Sharing pane, you noticed that all the lines were commented out. In other words, all the services controlled in /etc/inetd.conf are turned off by default in OS X.

If you decide to turn on a service, as a precaution, make a backup copy of the /etc/inetd.conf file. Next, uncomment the line containing the service you want to enable and save the file. Finally, restart the inetd process. If you decide to disable a service that starts out of inetd, simply comment the line that contains the service, save the file, and restart the inetd process—either by rebooting your machine or using kill -HUP <inetd pid> .

You might have also noticed that some of the services listed in /etc/inetd.conf have ## at the beginning of the line, rather than #. These services are not yet implemented in the operating system.

StartupItems

As you also saw earlier in the book, some of the services that run in OS X are started in /System/Library/StartupItems. Some of the services started in /System/Library/StartupItems also have controls in /etc/hostconfig that the startup scripts in /System/Library/StartupItems check. The Web server, SSH server, and AppleShare server are controlled in such a fashion.

If you enabled those services, but later decided to disable them, set the appropriate /etc/hostconfig variable to NO and kill their current processes. The next time you reboot, the services won't start. To manually start one of those services, set the appropriate variable in /etc/hostconfig to YES, and manually execute the startup script. For example, for the SSH server, you would make the SSHSERVER line in /etc/hostconfig read SSHSERVER=-YES-. Then you would execute /System/Library/StartupItems/ SSH/SSH. To disable a service that does not have a control in /etc/hostconfig, simply rename the startup script and kill its process.

Using TCP Wrappers

A common way to restrict access to some TCP services is to use the TCP Wrappers program. TCP Wrappers is a package that monitors and filters requests for TCP (Transmission Control Protocol) services. We will not look at the protocol in any detail—that is a book subject in itself. Suffice it to say the protocol has enough control information in it that we can use a package like TCP Wrappers to filter some of that traffic. TCP Wrappers can be used to restrict certain network services to individual computers or networks.

To make use of this program on some flavors of Unix, TCP Wrappers has to be installed by the system administrator. This is not a necessary step in OS X because the TCP Wrappers program comes pre-installed on the system. The /etc/inetd.conf file in OS X already assumes that you will use TCP Wrappers, as evidenced by a line such as

#ftp    stream  tcp     nowait  root    /usr/libexec/tcpd               ftpd -l

The /usr/libexec/tcpd portion of the previous line indicates that TCP Wrappers will be used to call ftpd.

Configuring TCP Wrappers

The particularly difficult part about using TCP Wrappers is configuring it. We will look at two ways you can configure TCP Wrappers in OS X: the traditional method of using two control files and a newer method that uses only one control file.

Traditionally, TCP Wrappers has two control files: /etc/hosts.allow and /etc/hosts.deny. We will look at the traditional method in more detail because it is the default setup for a machine when extended processing options are not enabled. An understanding of the traditional method should carry over to the new method. Be sure to read the hosts_access and hosts_options man pages for detailed information.

Here is the format of the access control files:

daemon_list : client_list : option : option ...

Through /etc/hosts.allow, you can allow specific services for specific hosts.

Through /etc/hosts.deny, you can deny services to hosts and provide global exceptions.

The easiest way to think of and use these configuration files is to think of TCP Wrappers putting a big fence up around all the services on your machine.

The specifications in /etc/hosts.deny tell the fence what services are on the outside of the fence, and therefore not denied. The fence can appear to be around different sets of services for different clients. For example, an /etc/hosts.deny file might look like this:

ALL EXCEPT ftpd : 192.168.1. : banners /usr/libexec/banners
ALL : 140.254.12.100 140.254.12.135 : banners /usr/libexec/banners
ALL EXCEPT ftpd sshd : ALL : banners /usr/libexec/banners

This file says:

• For the subdomain 192.168.1., deny all connections except connections to the FTP daemon, ftpd.
• For the specific machines 140.254.12.100 and 140.254.12.135 (maybe they're troublemakers), deny absolutely all connections.
• For all other IP addresses, deny everything except connections to ftpd and to the secure-shell daemon sshd.

The banners /usr/libexec/banners entry is an option that tells tcpd that if it denies a connection to a service based on this entry, try to find an explanation file in this location. Use this option if you have a need to provide an explanation as to why the service is not available.

The specifications in /etc/hosts.allow make little gates through the fences erected by /etc/hosts.deny for specific host and service combinations. For example, an /etc/hosts.allow file might look like this:

ALL: 140.254.12.137 192.168.2. 192.168.3.
popd: 140.254.12.124 140.254.12.151 192.168.1.36

This file says:

• Allow connections to any TCP service from the host 140.254.12.137 and all hosts in the 192.168.2. and 192.168.3. subdomains. (Perhaps the 192.168.2. and 192.168.3. subdomains are known highly secure networks, and we really trust 140.254.12.137 because it's so well run.)
• Allow connections to the popd service for three specific machines 140.254.12.124, 140.254.12.151, and 192.168.1.36.

If used in combination with the previous /etc/hosts.deny file, these allowances still stand. They override the denials in /etc/hosts.deny, even though the 192.168.1. subdomain is denied all access except to ftpd by /etc/hosts.deny, the specific machine 192.168.1.36 has its own private gate that allows it access to the popd service as well.

Now that we have seen how the traditional method of controlling TCP Wrappers works, let's take a brief look at a newer method that uses only the /etc/hosts.allow file. The newer method can be used on systems where extended option processing has been enabled. This is indeed the case with OS X. Nevertheless, either method works in OS X.

In the single file, /etc/hosts.allow, you specify allow and deny rules all in the same file. With the /etc/hosts.allow only method, tcpd reads the file on a first-match-wins basis. Consequently, it is important that your allow rules appear before your deny rules.

For example, to restrict access to ftpd only to our host, 140.254.12.124, we would use these rules:

ftpd: 140.254.12.124 127.0.0.1 localhost: ALLOW
ftpd: ALL: DENY

In the first line, we allow our host, 140.254.12.124, access to ftpd using various addresses that it knows for itself. On the second line, we deny access to all other hosts. If we reversed these lines, even the host that we want to allow ftpd access to would be denied access.

After you have sufficiently tested that you have properly set up your allow and deny rules, there is nothing else you need to do to keep TCP Wrappers running. As you are testing your rules, check your logs carefully to see where, if at all, the behaviors are logged. You will rarely see entries for tcpd itself in your logs, but you might see additional logging for a wrapped service under that service.

Wrapping Services to Allow Tunneling over SSH

As you saw earlier in the book, it is possible to tunnel connections over SSH. If you do decide to run the FTP service on your machine, you might be interested in restricting access to the service so that anyone who uses the service has to tunnel it through SSH. You saw in detail how to configure a Mac client running traditional Mac OS to do this. We have not yet officially seen how to configure the OS X machine to permit this.

The key to setting this up is restricting access to the desired service to your host by its IP address and as localhost addresses. Sometimes it can be helpful to include your machine by its name, too, but we have not encountered this problem on an OS X machine.

To restrict access to ftpd so that a user would have to tunnel her FTP connection, you could have an /etc/hosts.deny file like this:

ALL EXCEPT sshd: ALL

In this example, all services are denied except sshd.

In the /etc/hosts.allow file, add a line for your host that includes your host's IP address, 127.0.0.1 and localhost.

ftpd: 140.254.12.124 127.0.0.1 localhost

In this example, our host, 124.254.12.124, is the only host allowed access to ftpd.

In the /etc/hosts.allow only method:

sshd: ALL: ALLOW
ftpd: 140.254.12.124 127.0.0.1 localhost: ALLOW
ftpd: ALL: DENY

Common Sense Preventive Measures

Before we continue any further in this chapter, we have reached a good time to point out some common sense preventive measures to provide basic security for your machine. They do not guarantee the safety of your machine, of course, but they provide good basic guidelines for you. These common sense activities apply not only to OS X, but also to any other operating system.

Common sense preventive security measures that you should always keep in mind are

• Keep your operating system current. You can easily do this by setting Software Update to a regular update schedule. If you prefer not to have Software Update check for updates automatically, make sure that you check Apple's Web site regularly for any updates and subsequently run Software Update. This is perhaps the most important common sense activity you can do.
• For OS X, do not turn on any network services that you don't need. For other operating systems, this often means turning off services you don't need, because many operating services tend to come with many network services turned on by default.
• Restrict access to the services you have to run. Using TCP Wrappers is one method for restricting access to some services.
• Replace insecure services with secure services. For many systems, this advice especially targets using sshd instead of telnetd because sshd typically has to be installed separately. For OS X, enabling remote login in the Sharing pane automatically starts sshd, which is included in the OS X distribution, rather than telnetd.
• Run services with the least privilege necessary for the job. Check the documentation for the service to see advice on this.

Using BrickHouse as an Interface to the Built-in Firewall Package

As we have already seen, OS X has basic tools available to help you secure your machine. In addition to the basic tools, OS X comes with a firewall package called ipfw. A nice graphical interface to configuring and using ipfw is a shareware product called BrickHouse, available at http://personalpages.tds.net/~brian_hill/.

There is another shareware graphical interface to configure the firewall package, called Firewalk X, which we will not discuss. It is available from http://www.users.qwest.net/~mvannorsdel/firewalkx/. We have not investigated this package. However, from the picture of the interface on the Web site, BrickHouse appears to be a friendlier package for the first-time ipfw user.

Preparation

Because you will probably want to see some of the before and after effects of BrickHouse, we suggest a couple commands that you might want to take a quick look at now before you get started with the application.

Run this command:

[localhost:/Users/joray] root# ipfw show

     65535 82606 46703351 allow ip from any to any

What you just did was ask ipfw to show you the current firewall settings. As you probably guessed, ipfw on OS X ships in an open state.

In order to correctly configure a firewall, you'll need to know the network interfaces being used on your system. The "ifcconfig" command displays and sets interface information on your system. Try this command, especially if you are hoping to use BrickHouse to help you set up your OS X machine as a gateway for your home network. This process will require you to correctly identify the interface of your internal (private) network and main Internet connection. ifconfig will be discussed at more length later in the chapter.

[localhost:~/security-misc] joray% ifconfig -a

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000
en0: flags=8863<UP,BROADCAST,b6,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 140.254.12.124 netmask 0xffffff00 broadcast 140.254.12.255
        ether 00:30:65:ca:f9:a2
        media: autoselect (100baseTX <half-duplex>) status: active
        supported media: none autoselect 10baseT/UTP <half-duplex>
            ore network-security related. —- JER'in network services to individual

      
    computers or networks.______________________________10baseT/UTP <full-duplex> 100baseTX

      
    <half-duplex> 100baseTX <full-duplex>

The utility ifconfig enables you to configure interface parameters. As shown previously, ifconfig -a produces a full listing of available interfaces.

Because the firewall package can be tricky to work with, what you try to do in BrickHouse might make your machine completely unusable. This is no fault of BrickHouse, but you should be prepared to remove components that you might have BrickHouse install. Depending on your situation, this might be possible only in single-user mode. If you have not yet put your machine in single-user mode, we suggest you do so before doing anything in BrickHouse. If you tried single-user mode a while ago, but have forgotten what you did, take this moment to try again. Use Command+S while rebooting to get into single-user mode. The last few lines that appear are

Singleuser boot - fsck not done
Root device is mounted read-only
If you want to make modifications to files,
run '/sbin/fsck -y' first and then '/sbin/mount -uw /'
localhost#

Using BrickHouse

After you have downloaded and uncompressed the BrickHouse disk image, you are ready to start using it.

1. The Setup Assistant appears. Please note that you can also use the Setup Assistant at any time later by clicking on the Assistant button in the main BrickHouse window. The first part of the Setup Assistant is the External Network sheet, shown in Figure 31.1. Select your connection type and IP address assignment method (dynamic or static). Connection-type choices are DSL or Cable Ethernet (Regular Ethernet), Dialup Modem (PPP), DSL or Cable PPPoE, AirPort (+ External AirPort Base Station).
   

   Figure 31.1 The BrickHouse Setup Assistant begins with your External Network settings.

2. The Public Services sheet, shown in Figure 31.2, is next. Check the boxes by the services that you want your machine to run. If you are not sure what a service is, select it and a description appears at the bottom of the window. Don't forget to check the appropriate AppleTalk services, if you typically share your machine over an AppleTalk network.
   

   Figure 31.2 In the Public Services sheet, select the services you want your machine to run.

3. The Blocked Services sheet, shown in Figure 31.3, is where you select specific ports to be blocked. The list primarily includes ports aimed at various known attacks. The sheet notes that incoming traffic is blocked by default.
   

   Figure 31.3 In the Blocked Services sheet, select additional ports to have blocked.

4. The next sheet to appear is the Firewall Setup Complete sheet, shown in Figure 31.4. To enable the configuration, click Apply Configuration. To install a startup script, click Install Startup Script. If you are interested in using your OS X machine as a gateway for an internal network, click the Setup IP Sharing button. If you decide you want to make changes to your configuration, you can make changes in the main window and apply a new configuration. Additionally, you can install or remove a startup script under the application's Options menu.
   

   Figure 31.4 In the Firewall Setup Complete sheet, you can preliminarily finalize your setup, or you can continue your setup by clicking on the Setup IP Sharing button to configure your machine to serve as a gateway for an internal network.

5. If you plan to set up your OS X machine as a gateway for your internal network, the next sheet that appears is the IP Sharing sheet, shown in Figure 31.5. Here you select how your machine connects to the internal network and what internal IP address should be used for the machine. Connection choices are Ethernet Card (en0), AirPort or Second Ethernet Card (en1).
   

   Figure 31.5 Make specifications about your local network in the IP Sharing sheet.

   After you are done with this sheet, this version of BrickHouse then displays another sheet giving you instructions on starting IP Sharing in BrickHouse. At this time, BrickHouse does not configure IP Sharing to start at boot time.

You have just completed the initial BrickHouse setup. Now let's take the time to examine the rest of the BrickHouse interface. The default interface is the Quick Configuration, shown in Figure 31.6. The filters you selected during the setup process are shown under the tab for your interface. The IP Gateway tab shows information that pertains to any IP sharing that you might have set up.

Figure 31.6 The default BrickHouse interface is the Quick Configuration interface.

The Advanced button, shown in Figure 31.7, allows you to edit some additional settings involving rules for some select protocols, DHCP, and your domain name service. The bottom-right buttons allow you to add, edit, and delete filters. When you add a filter, you can choose among the same options you saw in the Setup Assistant, as well as Custom Service, which allows you to specify a port or port range. The interface for adding a filter is shown in Figure 31.8. You can rearrange the order of filter rules by dragging them around in the main window.

Figure 31.7 The Advanced button allows you to edit rules involving some select protocols, DHCP, and your domain name service.

Figure 31.8 The Add Filter button opens this sheet, where you can add another filter. Specify the action, service, protocol, port, source host, and destination host.

From the toolbar, you can access the Setup Assistant any time by clicking on the Assistant button. The Setup Assistant always starts from scratch. The Monitor button allows you to monitor the firewall. A sample of what it looks like is shown in Figure 31.9.

Figure 31.9 The Firewall Monitor window is where you can monitor the firewall's activity.

Settings allows you to manipulate settings files. You can duplicate, rename, delete, import, or export. By clicking the Log button, you can access the Daily Firewall Log window, shown in Figure 31.10, from which you can enable logging. If you want to have logging enabled at startup, be sure to reinstall the startup script, which you can do by either clicking the Install button or under the Options menu. Even if you don't think you want to have logging all the time, you might find having logging on at this stage to be a way to help you troubleshoot problems with the firewall configuration.

Figure 31.10 Click the Enable button at the right in the Daily Firewall Log window to enable firewall logging. If you want to enable logging at startup, reinstall the startup script.

In addition to the default Quick Configuration mode is an Expert Configuration mode, accessible from the Expert button. The Expert Configuration window, shown in Figure 31.11, is a split window that displays the rules that are being passed to ipfw as well as a configuration file for natd, which redirects packets to another machine if you configured your machine as a gateway.

Figure 31.11 In the Expert Configuration window, you can edit the firewall rules more precisely.

It is worthwhile to experiment with some filters that you might be most concerned about while you are still in the BrickHouse interface. With each set you want to try, just click the Apply button to apply those settings. The Quick Configuration mode is useful for adding basic filters, whereas the Expert Configuration mode allows you to tweak the configuration. After you have a set that you are happy with, don't forget to save the settings. If you were working in the Expert Configuration mode, you might also want to save the settings in a text file in a terminal window, just to be sure that you can easily find the file without the graphical interface. After you are relatively satisfied with the results, install the startup script if you want the firewall to start at startup.

If your OS X machine is an NFS client, do not test to see whether the mounts still work in the graphical interface. If your mounts are not working properly, you will hang your console when you check. If you check in the terminal, you will be able to continue testing until you are finally satisfied. For an OS X machine that is an NFS client, you might ultimately find it necessary to add a line in the Expert mode that allows all traffic from your NFS server.

Finally, you should be aware of the options available under the Options menu: Allow Changes, Quick Configuration, Expert Configuration, Apply Settings, Install Startup Script, Clear All Rules, Remove Startup Script. All those options are not available in the toolbar.

When you are satisfied with your firewall configuration, reboot your machine— especially if you had BrickHouse install a startup script for you. This tells you exactly what behavior to expect from the firewall starting from scratch. If something undesirable occurs, the potential cause for the behavior is fresh in your mind and more easily fixed.

Behind the Scenes

So, what are some of the things that BrickHouse did for you?

First, if you decided to have BrickHouse install a startup script for you, you should have noticed a comment about the firewall starting.

Run the first command that you ran before you started:

[localhost:/Users/joray] root# ipfw show

01000 10656 1346992 allow ip from any to any via lo0
01002   607   40266 allow tcp from any to any established
01003     0       0 allow ip from any to any frag
01004   408   22848 allow icmp from any to any icmptype 3,4,11,12
01011     0       0 unreach host log ip from any to any ipopt ssrr,lsrr
01999     0       0 allow udp from any 67-68 to 140.254.12.124 67-68 via en0
02000   244   29380 allow ip from any to 255.255.255.255 via en0
02001     0       0 allow udp from any 123 to any 123 via en0
02002     0       0 allow icmp from any to any via en0
02003     0       0 allow tcp from any 20 to any in recv en0
02005    89    6372 allow udp from any to any 53 out xmit en0
02006    89   10357 allow udp from any 53 to any in recv en0
02007     0       0 allow tcp from any to 140.254.12.124 20-21 in recv en0
02007     0       0 allow tcp from 140.254.12.124 20-21 to any out xmit en0
02008     3     144 allow tcp from any to 140.254.12.124 22 in recv en0
02008     0       0 allow tcp from 140.254.12.124 22 to any out xmit en0
02010     0       0 allow tcp from any to 140.254.12.124 548 in recv en0
02010     0       0 allow tcp from 140.254.12.124 548 to any out xmit en0
02011     0       0 allow udp from any to 140.254.12.124 427 in recv en0
02011     0       0 allow udp from 140.254.12.124 427 to any out xmit en0
02012     0       0 allow tcp from any to 140.254.12.124 600-1000,111,2049 in recv en0
02012     0       0 allow tcp from 140.254.12.124 600-1000,111,2049 to any out xmit en0
02013     0       0 allow udp from any to 140.254.12.124 600-1000,111,2049 in recv en0
02013     0       0 allow udp from 140.254.12.124 600-1000,111,2049 to any out xmit en0
02014     0       0 deny log tcp from any to 140.254.12.124 1524 in recv en0
02015     0       0 deny log tcp from any to 140.254.12.124 12345 in recv en0
02016     0       0 deny log udp from any to 140.254.12.124 10067 in recv en0
02017     0       0 deny log tcp from any to 140.254.12.124 12361 in recv en0
02018     0       0 deny log udp from any to 140.254.12.124 31337 in recv en0
02019     0       0 deny log udp from any to 140.254.12.124 31338 in recv en0
02020     0       0 deny log tcp from any to 140.254.12.124 31337 in recv en0
02021     0       0 deny log udp from any to 140.254.12.124 2140 in recv en0
02022     0       0 deny log udp from any to 140.254.12.124 31785 in recv en0
02023     0       0 deny log tcp from any to 140.254.12.124 31789,31791 in recv   en0
02024     0       0 deny log tcp from any to 140.254.12.124 21554 in recv en0
02025     0       0 deny log tcp from any to 140.254.12.124 6969 in recv en0
02026     0       0 deny log tcp from any to 140.254.12.124 23456 in recv en0
02027     0       0 deny log tcp from any to 140.254.12.124 1243,6776 in recv  en0
02028     0       0 deny log tcp from any to 140.254.12.124 15104,12754 in recv  en0
02029     0       0 deny log udp from any to 140.254.12.124 10498,6838 in recv  en0
02030     0       0 deny log udp from any to 140.254.12.124 31335 in recv en0
02031     0       0 deny log tcp from any to 140.254.12.124 27665,27444 in recv  en0
02032     0       0 deny log tcp from any to 140.254.12.124 20432 in recv en0
02033     0       0 deny log udp from any to 140.254.12.124 18753,20433 in recv  en0
52034   304   20021 allow ip from 140.254.12.124 to any out xmit en0
52035     0       0 deny log ip from any to 140.254.12.124 in recv en0
65535 13048 1498445 allow ip from any to any

You should now have a bit more output than you did previously. The open rule, which was the only rule before you started, is now the last rule. The Firewall Monitor in BrickHouse appears to be a graphical view of ipfw show.

Next run ifconfig -a again:

[localhost:~/brickhouse-misc] joray% ifconfig -a

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000
en0: flags=8863<UP,BROADCAST,b6,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 140.254.12.124 netmask 0xffffff00 broadcast 140.254.12.255
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        ether 00:30:65:ca:f9:a2
        media: autoselect (100baseTX <half-duplex>) status: active
        supported media: none autoselect 10baseT/UTP <half-duplex> 10baseT/UTP
        <full-duplex> 100baseTX <half-duplex> 100baseTX <full-duplex>

If you configured your machine to be a gateway, you should now see information about your machine's interface to the internal and external networks. If you did not configure your machine to be a gateway, you should see no changes. Command documentation for ifconfig is included in Table 31.1.

Table 31.1. Command Documentation Table for ifconfig

ifconfig <interface> <address_family> [<address>

                     
                   
               [<dest address>]]
[<parameters>]

ifconfig <interface> [<protocol family>]

ifconfig -a [-d] [-u] [<address family>]

ifconfig -l [-d] [-u] [<address family>]

If you had BrickHouse install a startup script, you now have a /Library/StartupItems/ Firewall directory:

[localhost:~] joray% ls -l /Library/StartupItems/Firewall

     total 24
     -rwxrwxr-x  1 root  admin   535 Jun 19 11:30 Firewall
     -rw-rw-r—  1 root  admin   552 Jun 19 11:30 StartupParameters.plist
     -rwxrwxr-x  1 root  admin  2393 Jun 19 11:30 openniports.pl

Just as you saw earlier in the book with fonts and sounds, you can also place local startup items in the /Library directory, following the basic structure seen in /System; in this case, /Library/StartupItems. Here is a sample startup script installed by BrickHouse to start the firewall and its logging facilities:

[localhost:~] joray% more /Library/StartupItems/Firewall/Firewall

     #!/bin/sh
     # Firewall Boot Script
     # Generated by BrickHouse


     #===========================================================
     # Enable IP Firewall Logging
     #===========================================================
     /usr/sbin/sysctl -w net.inet.ip.fw.verbose=1

     # Put a limit on each rule's logging
     /usr/sbin/sysctl -w net.inet.ip.fw.verbose_limit=500

     #===========================================================
     # Process Firewall Rules File
     #===========================================================
     /sbin/ipfw -q /etc/firewall.conf

As you can see from the startup script, BrickHouse installed a configuration file that it called firewall.conf in /etc. Look at the configuration file, especially if you did not switch to the Expert Configuration mode in BrickHouse. The file is nicely commented. If you need to make additional changes to the ruleset, you can do so either in the BrickHouse interface, or you can edit the /etc/firewall.conf file directly. Be sure to check the ifpw man page for specific details. This configuration file works in a similar manner to the newer TCP Wrappers configuration method. The ipfw program reads the configuration file on a first-match-wins basis.

The general format of the lines the BrickHouse created in the /etc/firewall.conf file is

add <rule_number> <action> <protocol> from <source> to <destination> [<options>] [via

      
    <interface>]

If you selected AppleShare as one of your services, you have entries that look approximately like this:

#################################################
## AppleShare IP/iDisk
#################################################
add 2010 allow tcp from any to 140.254.12.124 548 in via en0
add 2010 allow tcp from 140.254.12.124 548 to any out via en0

The first line is a rule that enables incoming tcp packets from any host to the host machine on port 548 via the interface en0. The second AppleShare rule enables outgoing tcp packets from the host machine on port 548 to any host via the en0 interface.

As mentioned in the previous section, if your OS X machine is an NFS client, you might have to allow all incoming packets to the NFS server. You could do that with a rule like this:

add <rule_number> allow ip from <NFS_Server-IP> to <host_IP> via en0

The ip packet description means all packets. You can also use all. Command documentation for ipfw is included in Table 31.2.

Table 31.2. Command Documentation Table for ipfw

ipfw [-q] [-p <preproc> [-D <macro>[=<value>]] [-U 
               <macro>] <file>

ipfw [-f | -q] flush

ipfw [-q] zero [<number> ...]

ipfw delete <number> ...

ipfw [-aftN] list [<number>...]

ipfw [-ftN] show [<number>...]

ipfw [-q] add [<number>] <action> [log] <proto>

               
                  
                from <src> to <dst>
[via <name> | <ipno>] [<options>]

ipfw add 100 deny ip from any to any out recv en0 xmit en1

BrickHouse might also have installed a configuration file, /etc/natd.conf, for natd. Here is a sample /etc/natd.conf created by BrickHouse:

interface en0
use_sockets yes
same_ports yes

This configuration file specifies the interface to be used. In addition, the use_sockets option is included as well as the same_ports option. The use_sockets option allocates a socket for the connection, and is useful for guaranteeing connections when ports conflict. The same_ports option specifies that natd should try to keep the same port number when altering outgoing packets. This also aids in guaranteeing the success of the connection. Command documentation for natd is included in Table 31.3.

Table 31.3. Command Documentation Table for natd

natd [-ldsmvu] [-dynamic] [-i <inport>] [-o 
               <outport>] [-p <port>] [-a
<address>] [-n <interface>] [-f <configfile>]

natd [-log] [-deny_incoming] [-log_denied] [-use_sockets] [-same_ports]
[-verbose] [-log_facility <facility_name>] [-unregistered_only] [-
dynamic] [-inport <inport>] [-outport <outport>] [-port <port>] [-
alias_address <address>] [-interface <interface>] [-config
<configfile>] [-redirect_port <linkspec>] [-redirect_address <localIP>

               <publicIP>] [-reverse] [-proxy_only] [-proxy_rule 
               <proxyspec>] [-pptal
ias <localIP>]

alias_address 158.152.17.1

tcp inside1:telnet 6666

-redirect_address <localIP> 
               <publicIP>

            

redirect_address 10.0.0.8 0.0.0.0

redirect_address 192.168.0.2 <public_addr>
redirect_address 192.168.0.3 <public_addr>
redirect_address 192.168.0.4 <public_addr>

            

Recovery

After you are done with BrickHouse, you might leave your machine in an unusable state. If you need to uninstall BrickHouse while you work out a solution, the documentation suggests that you select Remove Startup Script under the Options menu and reboot, or throw out the /Library/StartupItems/Firewall folder and reboot. The documentation also points out that Clear All Rules under the Options menu will temporarily uninstall the firewall.

If your machine is so unusable that you can't do any of the previous suggestions, reboot into single-user mode and remove the /Library/StartupItems/Firewall directory. You can also remove the /etc/firewall.conf and /etc/natd.conf files. Upon rebooting, your machine is restored to the condition it was in before you used BrickHouse. The next time you are ready to use BrickHouse, just start with the Setup Assistant and work from there.

Share This