Help get Critical Mass going again with weekly articles. E-mail Damien and voice your wishes to have Critical Mass return. If he gets enough people wanting the return of Critical Mass, then he just might start writing again. So go ahead and e-mail Damien and voice your wishes to see more Critical Mass articles.
Mac OS X Security Part Nine: Configuring BrickHouse & ZoneAlarm
Last week we looked at an affordable solution to the security issues introduced by running Classic Mode, VirtualPC, and DAVE. This week we resume our firewall studies, and spend some time under the hood with BrickHouse for OS X and ZoneAlarm for Windows.
Let me begin by pointing out the reasons why we are spending any time at all with a Windows firewall. There are two reasons. The first is for the sake of those of you who run VirtualPC. The second is for the sake of your friends who run Windows. You'll be doing them a huge favor by helping them bolt down their machines.
To recap a couple of concepts, tcp/ip is a network language, one of many. It is the lingua franca of the internet. Tcp/ip defines a software entity known as a port. The tcp/ip port is the network connection point on each computer. There are 65,535 tcp (Transmission Control Protocol) ports, and another 65,535 udp (User Datagram Protocol) ports defined. Many tcp and udp ports are complements; the former are used where data integrity is paramount (e.g. a file download), and the latter where speed is paramount (e.g. streaming audio). The first 1024 ports are used for the most common internet functions. Port 80 is reserved for web servers. Port 21 is reserved for ftp connections. And so on. Many ports are discretionary. Just as ports are the connection points between networked computers, so also are they the entrance points for malicious hackers. Firewalls came into being for the purpose of controlling what enters and exits through those ports.
BrickHouse is a graphical interface to the firewall that is included, but disabled by default, in Mac OS X. Its modus operandi is to open or close tcp/ip ports for each of the local and internet network zones and for specific hosts. ZoneAlarm is a software firewall that runs on all recent versions of Windows. It runs as a normal program on the consumer versions of Windows, e.g. Win98, and as a service on Windows NT and its successor Windows 2000. A mere detail right now. Its modus operandi is to allow or deny specific programs access to specific ports for each of the local and internet zones. ZoneAlarm Pro gives the user much finer control over things than does ZoneAlarm, though the latter is plenty sufficient for most home use.
When BrickHouse is installed the first time, a set of nice settings are suggested. You'll do fine just by taking these defaults. Now we'll assume you did that, and are ready to tweak. If you didn't, run the Assistant wizard within BrickHouse now. BrickHouse has canned firewall rules that you can add, and one called Custom. That's the one you'll need to open up a port for your X server, for example. Rules are executed from the bottom up as they appear in the BrickHouse configuration window. So the green Allow rules are on top, and the red Deny ones below. The basic idea is to close everything down first, then open only the ports you need. Without further ado, let's do that and see where we go. If you already know that you need a certain port open for your favorite application, keep it in mind, as you'll be able to make your own Allow rule for it shortly.
Accidents can happen. In case you already have a pretty good rules set, let's save it. Open BrickHouse, punch in your password (remember, as owner you are also the administrator) to allow changes, then press Settings. A small dialog box pops up. Press Export, and supply a good name like MyFirstBrickHouse or something. Now you can play to your heart's content, and if all else fails you can restore your current firewall settings from this save file.
BrickHouse has a collection of canned Deny rules. In a moment, we'll select 'em all and go. You'll still be able to surf the 'Net. After that, let's see what stops working. For better or worse, that's the standard way to set up a firewall. By the way, BrickHouse's Quick setup applies to your default network card only. If you have a G3/G4 tower with multiple network cards, you'll need to use the Expert configuration screens. On the other hand, if you have multiple NICs you probably don't need me to tell you how to configure them.
Speaking of multiple, BrickHouse has firewall rules sets for the various ways you can connect. By default they're all disabled. Why not click the tab and enable the firewall for each of these now, even if you don't use them presently? The tabs are Ethernet, PPP, PPPoE, AirPort, and IP Gateway.
To select the canned Deny rules, open BrickHouse, punch in your password, then run the Assistant wizard. After the opening screen, a number of server services are listed. Unless you are using your Mac as a web server or something, all of these should remain unchecked. Do that now. The next Assistant screen lists a number of known vulnerabilities. Select them all, including the standard services. We'll open things up later. Apply the configuration and install the startup script if you haven't already. The latter is required for enabling the firewall at boot time. Now you should have a screenful of red Deny items.
Now press Add Filter at the bottom of the BrickHouse window. If, like I do, you have another machine on the same network at home, you'll eventually want to run ftp. You now need to open up your firewall for ftp connections. In the Add Filter dialog, select an Allow action, pick out the File Transfer service, and set the Source to Other and the Destination to My Computer. You need to specify a particular host under Other. Type in the IP address for your other machine, or, if you use dynamic IP addresses, the range. For a typical NAT gateway that assigns addresses in the range from 192.168.0.1 to 192.168.0.254 you would type in 192.168.0.1-192.168.0.254. If you wish to allow specific hosts, type them in and separated by commas like this: 192.168.0.1,192.168.0.2,192.168.0.3,192.168.04,192.168.0.5. Press OK to add the filter to the bottom of the list.
Let's do another one. Press Add Filter, Allow, Custom Service, Protocol tcp, Port 6000, Source Other, and Destination My Computer. You can type in a bogus host for Other. Press OK. Now you have a filter to allow your X server to receive X windows originating from a specific remote host. In my configuration, I have typed in the small handful of unix hosts I regularly use for X, each separated by a comma. Fine, now you can delete this filter if you wish.
You can secure shell into Mac OS X from any computer that has an ssh client. So you'd need to open up the ssh port 22 on your Mac in order to get in. Here you'd add the Allow filter for Remote Login (SSH). I'd be inclined to specify explicit hosts that you regularly ssh from, rather than opening it up wide, as convenient as that may be. You have to be the judge, though. If you travel a lot and sit at many keyboards, you'll need to leave this port wide open too. If you only expect to connect from your desktop at work, then it's easy to type in that one host name.
AIM, ICQ, and other instant messaging clients all require your machine to be listening. Given that the internet works by having two computers connect together via ports, it means that your machine must act as a server, as that's what a server does. It waits for someone (the client) to request its services. With instant messaging, your machine acts as a server insofar as it keeps the night light on for new messages. The alternative is to have your own machine go out and check for new messages once a minute, which would be messy and wasteful from the network's perspective. It also wouldn't be instant anymore. There we are.
So let's do an Allow rule for ICQ. In fact, you may need two rules. The first one gets you connected to the host ICQ machine; the second one gets you connected directly to your ICQ friends in a peer-to-peer relationship. BrickHouse already has a canned rule for the first one, called AOL Instant Messaging. Cook up an Allow rule with it, and set the Source host to be login.icq.com and the Destination to be My Computer. The second one is a little trickier. Cook a Custom rule this time, with tcp ports 1024-65535. The source will be The Internet and the Destination My Computer. Just before you press OK, though, consider that this single rule just about nullifies any good effect of having a firewall in the first place. So if you do all of your ICQ chit-chat through an ICQ host, then you only need the first rule. I suggest you give it a try before implementing the second rule. For now, since you've typed up the second rule, set it to Deny. You can edit it to Allow later if you absolutely have to.
Instant messaging may also require a tweak on your NAT gateway, if you use one. You'd need to enter port 5190 and the local address of your ICQ Mac (e.g. 192.168.0.2) into the gateway's configuration, so that the latter can redirect ICQ requests (new message alerts) to you. At the other end, you configure ICQ to look for your gateway's IP address. This will be a tad problematic if your ISP assigns you a dynamic IP address. If you ask nicely and you have full-time internet such as cable or DSL, your ISP may give you a static IP address. Alternately there is at least one service out there that offers name hosting, for lack of a better term, where you get a static name and IP address from them, and all network communications get forwarded to you. The trick is to check into the site when you boot up, so that the site knows what your IP address du jour is. I prefer a solution like this because of the inherent security factor in my own IP address being dynamic.
BrickHouse also has a canned rule for web serving, should you be doing that on OS X. Again, you'd need to tweak your gateway configuration to open port 80 and redirect http requests to your machine, just like ICQ. In fact, you'd have one line for every network service you might run, including port 22 for secure shell connections. Similarly, if you had two machines, one running a web server and the other running an ftp server, you'd configure your gateway for ports 80 and 21 to be redirected to the one (e.g 192.168.0.2) and to the other (e.g 192.168.0.3) respectively. A corollary of doing this is that gateway forwarding effectively exposes these ports of these machines to the internet directly. The basic watchword here is, open it if you need it, but otherwise leave it closed. For all of these, once again, the host at the other end dials in your gateway's IP name or address, not your Mac's private IP address.
Just for fun I set up BrickHouse to allow ssh connections and my gateway to forward all requests on port 22, the standard ssh port, to my iMac. As I mentioned earlier, I already had a firewall rule to open port 6000 for X Window graphics. Now I ssh to my linux server at work. I'm going there as a client, you understand. So I'm in. Now I have a shell open there. And from there I ssh back to my iMac, using my gateway's current IP address. Bingo! It asks me to verify the machine signature, then my own password, and I'm in! Not content to connect to my own machine with miles in-between, I type xeyes at the remote prompt. As I already have my X server running, instantly a pair of Xeyes pops up, looking at my mouse. So far I'm running an X application originating on my own machine across a 360* distant connection that goes in two hops. If I can do this, I surely can log in from anywhere else that has an ssh client. I for one think this is very cool. But not content for a less than scientific experiment, I now move the Allow SSH rule to just below the Deny Standard TCP Services rule. Sure enough, I no longer can connect, and the denied connection shows up in the firewall log. I move it back, and presto! I'm in again. This confirms that rules are exercised from the bottom up as seen in the BrickHouse Configuration window. Fun stuff, eh?
Once you have a number of explicit Allow filters and you believe you have all of your internet services covered, try choosing Deny in the Default Filters area as the default for outgoing as well as incoming connections. You can always undo it. Each time you make a change, press Apply to activate it, then test it with its corresponding application. When you're happy, press Save. This will be the rules set that gets loaded on your next boot. If you choose to not Save, then the firewall will revert back to the last-saved rules set next time.
As you play with these things, have the enabled Daily Firewall Log window open beside you so that you can see what gets denied. The BrickHouse log isn't live; you have to press Refresh every time, and it's painful after a while, but it works. If, say, you try to run an application against a denied port, it will show up in the log. Then you can open up that port in an appropriate way. Rules get carried out in the order they appear, starting from the bottom of the BrickHouse Configuration window list. So keep your Deny rules at the bottom, and your Allow rules above these. To move a rule, simply drag it.
Finally, you can use the Expert Configuration, which is equivalent to using a text editor on the firewall rules set file. But this is beyond the scope of this column. There will be little you can do there anyway that you cannot do by cooking up your own rules in the Quick Configuration panel. However, if you do develop the world's greatest rules set on your iMac and want to use the same set on another machine, you can use Export once again to save the set and email it or whatever elsewhere. The unix name for the rules set file updated by BrickHouse is firewall.conf located in the /etc folder. Thus BrickHouse.
The current version of ZoneAlarm asks you at installation time if you want to allow your browser network access automatically, and the default is to do so. To be consistent, I think you ought to let ZoneAlarm learn about your browser just like it learns about every other network application. Yes, ZoneAlarm learns your network habits. It queries you for your permission to allow an application network access when you run that application for the first time. Good plan. The only drawback to this is how ZoneAlarm totally shuts off your network connection until you answer. I personally wish it wouldn't do that, but that's how it is, even in the Pro version. Of course there is a strong rationale behind that, though I think it should be a user-settable option. You see, it becomes problematic if you do automatic software updates like Norton LiveUpdate or Critical Updates Notification, because ZoneAlarm pops up that query window again when those applications restart and attempt to access the network again. But I digress.
Let me reiterate why we bother to install ZoneAlarm at all if we're already running BrickHouse. It's because ZoneAlarm pays attention to specific Windows security holes. Why reinvent the wheel? Let ZoneAlarm cover you, and you can have that much more fault tolerance in your BrickHouse setup. At the same time, you want to avoid fighting firewalls as you tweak. I suggest pulling your internet connection for a while and disabling BrickHouse while you work on fine-tuning ZoneAlarm to work with Windows shares in your local network, should you be using them.
A little aside for a moment. I just tweaked one advanced setting in my Windows NT ZoneAlarm Pro setup at the same time I applied the latest Critical Updates from Microsoft. Now my machine BSODs (yes, in the NT world that's a verb!) every time. First lesson: Never do two changes simultaneously. Second lesson: Finish coffee before beginning any changes. Yep, I'm in trouble over there now. Here's a very good case for having two computers in the house. Later, I've booted via my second copy of NT (my back door!) and renamed the ZoneAlarm folder altogether. We're still BSODing! So it was the Critical Update. Yep, critical is the word alright.
While there is absolutely no sustainable reason for running secure shell from within a VirtualPC session since OS X supports ssh in a Terminal shell, you can do it nevertheless. You'd use Tera Term Pro with its Secure Shell plugin, for example. Simply install Tera Term Pro first, then unpack the plugin archive right in the TTermPro program folder. Make a shortcut to ttssh.exe and name it Tera Term Secure Shell. Use it in place of the default program shortcut. Once you've made your first ssh connection successfully, the rest come easily.
So let's make a firewall rule for it in ZoneAlarm. Simple. Just run Tera Term Secure Shell and try to connect somewhere. Of course you'll need admitting privileges on somebody's unix or VMS machine. ZoneAlarm will ask your permission to allow Tera Term access to the internet. Check the Remember box, and answer Yes. Later you can tweak this rule with a right-click (Cmd-Click with an Apple mouse) in ZoneAlarm's ttssh program entry. Of course the same procedure goes for any other network application you may care to run in Windows.
If you upgrade Tera Term Secure Shell or any other network program, ZoneAlarm will know, even though the executable file's name has not changed. This is one of the beauties of ZoneAlarm; it can detect when a binary has changed. So if you get the question and you know the program hasn't been upgraded by you, you can stop it in its tracks.
Where ssh in a Mac OS X Virtual PC session is pretty useless, of even less use to you will be an X server within a VirtualPC session, but let's do a firewall rule for it anyway. You need to open tcp port 6000 at the minimum, and a whack of ports in the 6000 to somewhere towards 7000 range to support X11 port forwarding (although it works every time for me with only port 6000 open). I believe you may need ZoneAlarm Pro for this level of tweaking, but I can't verify that for you right now, as my NT machine is still in a BSOD state. It could be terminal this time.
As I've said over and over, I think (who cares what I think!) that ZoneAlarm is the one to watch. Because it detects binary changes, it's hands-down the only firewall that will protect you reliably from trojan viruses that set you up as an instrument of Denial Of Service attacks. I will add, though, that the reliability stops with you; you are the one who grants or denies permission for an application to access the network. If you goof, then it's not ZoneAlarm's fault. At the same time, if you keep a reasonable vigilance about computer security, everything will work out fine.
Next time, we'll review some online security resources and tutorials. Ciao.