So I was trying to enhance my firewall to the point of inoperability and...

Question

Situation:
Like what all really cool people do on a Saturday night, I was perusing the bowels of my unix stuff on my Mac last night, and did a sudo ipfw list. I noticed that ports 67, 68, 69, 137, 138, and 139 were open from any to any. I know that 13x ports are used for Windoze sharing, and that /etc/services shows those ports are for something to do with netbios and tftp. Windows Sharing did not show up as being enabled in SysPrefs Sharing Services, and no other services using any of these six ports showed up as being enabled in SysPrefs Sharing Firewall.
I have no idea how or why those ports would be enabled. At work, I have Macs. My sons and daughter have Macs. Nobody would be connecting to my home network, either internally or from the internet at large and doing anything windoze-like. And I never recall having ever seen this ports opened before when doing a ipfw list.
So, I got scared. I figured that I would do a sudo ipfw flush, which I did, and then just use SysPrefs Sharing Firewall to click checkboxes to reenable the services that I want. Well, that was the start of my enhancing my firewall to the point of inoperability. When I go into the SysPrefs Sharing Firewall panel, I get a splash screen that says something to the tune of "another firewall is active on this computer, so if you want to do anything here on this Firewall panel, turn off the other firewall software."
Fortunately, I had done a sudo ipfw list > portList.txt so I could at least manually sudo ipfw add back the ports that I thought I wanted (and the ports I thought I wanted denied). So that's where I'm at now. But now it's a real annoyance that I don't have "checkbox control" of services and ports through the SysPrefs Sharing Firewall panel anymore, and instead have to do the "sudo ipfw add/subtract/multiply/divide {rule#} {whatever}" thing now. I don't know how to regain control of my Apple firewall and the SysPrefs Sharing Firewall panel.
Of course this doesn't address the issue of what opened those ports, and if it happens again, an "archive and reinstall" of the OS, along with an install of fink/macports tripwire, may be in order. But that's an inconvenience to have to do, and hopefully I can avoid having to do that. In the meantime, regaining control of my Apple firewall and the SysPrefs Sharing Firewall panel, would realy be nice, and that is my question. What do I do, and how do I do it?
Thanks in advance.

Answer 1

First, take a deep breath...
For one, the System Preferences knows nothing about the command line ipfw changes that you made. It expects to be the interface for setting and changing firewall rules, so when you've changed them manually (ipfw flush) it sees that the current rules doesn't match what it expects and hence the error message.
Secondly, the presence, or otherwise, of those ports does not mean they are active. Just that ipfw isn't blocking them. There still has to be some process on the machine listing to the port in order for anything to actually happen. It's akin to leaving a door open - it's fine when all that's behind that door is a brick wall.
A better test is to see what's actually being used on your machine, and ipfw cannot tell you that (at least, not easily). Better tools include netstat and lsof.
netstat -a will give you a list of every network connection in use. Just don't be shocked if there are more there that you expect - the OS uses a lot of them internally. What you're most interested in is the ports in LISTEN state (piping the output through 'grep LISTEN' is a simple solution).
Now you can focus on which ports your machine will actually respond to (assuming the firewall also allows traffic through).
If you have a port number that you don't recognize then you can invoke lsof which has the ability to list all open files, network ports, etc. To track a port number, use the form:
<pre class=command>sudo lsof -i :port</pre>
This will tell you any process that is using the specified port number. From there you should be able to determine whether or not there's an issue.