65535 default firewall rule

Yes, this second to last rule should deny the remaining packets, which is why I never concerned myself with it... until today.

Somehow, with the 65534 rule enabled (and it gets listed in the "active rules" area in Tiger server's firewall pane), the 65535 rule still gets matching packets! This makes no sense to me, as the rule that is right before it denies everything, so no datagrams should ever make it to 65535.

I'm also having a weird rule, "00001 allow udp from any 626 to any dst-port 626", which gets inserted no matter what -- if I say "sudo ipfw delete 1" -- it only goes away for a few moments and then it is back... I've read that it is serial number support, and also that it is apple asia's imap admin port. Is 626 an essential? -- but that's another topic in and of itself.

How are packets getting from 64534 to 65535 when 65534 is deny all?

Should I post a copy of the active rules?

Hello and much thanks for looking at the"active rules" I'm getting ready to paste.

My setup is one ldap od master, colocated with my isp, and running afp, dns, firewall, mail, open directory, and web services; it has no subnets... I run slave dns for it on a panther server running at home.

With the 10.4 GUI firewall tool, merely allowing the services I wanted to run with the appropriate check boxes, seemed to let too many ips request too many things... web logs get clogged with requests for files which don't exist, like login, or prxychk... smtp logs get swarmed with denied spam... except for the ones that didn't get denied, but somehow kept ips out of the log...

So I decided to try and move to a stateful firewall, by unchecking all the services, so serveradmin didn't create the 12000 series rules, but leaving the 65534 rule checked in advanced, and making all of my rules fit between 100 and 1000.

Rules 100-998 were loaded through a custom set that I placed in ipfw.conf, and based on the example at http://macenterprise.org/content/view/124/77/.

I was going to paste ipfw.conf, as it has the respective services #commented with each rule, but unfortunately, working with ipfw remotely has inherent risks, and I have lost contact and must wait til morning to get my isp to run remote power cycle and hopefully have a window to make my corrections.

So all I have are the results of "active rules" from Tiger Admin's GUI, which I had copied earlier when I asked if I should post it before I was locked out:

As of 2005-08-23 00:36:04 -0700
00001 27 1647 allow udp from any 626 to any dst-port 626
## I've read other postings, where you suggested that this rule come later in a set, but I am not making this rule, it mysteriously appears even when deleted!
00100 35650 5992232 allow ip from any to any via lo0
00101 0 0 deny log logamount 1000 ip from any to 127.0.0.0/8
00102 0 0 deny log logamount 1000 ip from any to 127.0.0.0/8
00111 0 0 check-state
00113 0 0 deny ip from any to any frag in via en0
00115 90 4764 deny tcp from any to any established in via en0
00222 4602 532872 allow tcp from my.remote.ip to me dst-port 22 in via en0 setup keep-state
00223 0 0 allow tcp from my.ispz.ip to me dst-port 22 in via en0 setup keep-state
00224 0 0 allow tcp from any to any dst-port 22 out via en0 setup keep-state
00266 25 8516 deny ip from 220.0.0.0/8 to me in via en0 keep-state
00267 244 36207 deny ip from 221.0.0.0/8 to me in via en0 keep-state
00269 57 5988 deny ip from 218.0.0.0/8 to me in via en0 keep-state
00333 0 0 allow tcp from any to any dst-port 80 out via en0 setup keep-state
00334 0 0 allow tcp from any to any dst-port 16080 out via en0 setup keep-state
00335 0 0 allow tcp from any to any dst-port 443 out via en0 setup keep-state
00444 0 0 allow tcp from any to my.dns.server dst-port 53 in via en0 setup keep-state
00445 0 0 allow tcp from my.dns.server to my.ispz.dns1 dst-port 53 out via en0 setup keep-state
00446 0 0 allow tcp from my.dns.server to my.ispz.dns2 dst-port 53 out via en0 setup keep-state
00447 0 0 allow tcp from my.dns.server to my.slave.dns dst-port 53 out via en0 setup keep-state
00448 60 7247 allow udp from my.dns.server to my.ispz.dns1 dst-port 53 out via en0 keep-state
00449 0 0 allow udp from my.dns.server to my.ispz.dns2 dst-port 53 out via en0 keep-state
00450 0 0 allow udp from my.dns.server to my.ispz.dns3 dst-port 53 out via en0 keep-state
00554 0 0 allow tcp from any to any dst-port 311 out via en0 setup keep-state
00555 23877 7479280 allow tcp from any to me dst-port 311 in via en0 setup keep-state
00556 0 0 allow tcp from any to me dst-port 625 in via en0 setup keep-state
00557 0 0 allow tcp from any to me dst-port 626 in via en0 setup keep-state

It appears that size restrictions cropped the last post, so here is the rest of the "active rules":

00558 0 0 allow tcp from any to me dst-port 687 in via en0 setup keep-state
00600 0 0 allow udp from any to any dst-port 123 out via en0 keep-state
00601 0 0 allow tcp from any to any dst-port 123 out via en0 setup keep-state
00611 0 0 allow tcp from any to me dst-port 106 in via en0 setup keep-state
00612 0 0 allow tcp from any to me dst-port 3659 in via en0 setup keep-state
00613 0 0 allow udp from any to me dst-port 106 in via en0 keep-state
00614 0 0 allow udp from any to me dst-port 3659 in via en0 keep-state
00615 0 0 allow tcp from any to any dst-port 106 out via en0 setup keep-state
00616 0 0 allow tcp from any to any dst-port 3659 out via en0 setup keep-state
00617 0 0 allow udp from any to any dst-port 106 out via en0 keep-state
00618 0 0 allow udp from any to any dst-port 3659 out via en0 keep-state
00680 758 120823 allow tcp from any to me dst-port 80 in via en0 setup keep-state
00681 0 0 allow tcp from any to me dst-port 16080 in via en0 setup keep-state
00682 8 416 allow tcp from any to me dst-port 443 in via en0 setup keep-state
00700 0 0 allow tcp from any to my.mail.server dst-port 143 in via en0 setup keep-state
00707 0 0 allow tcp from my.mail.server to any dst-port 143 out via en0 setup keep-state
00722 0 0 allow tcp from any to any dst-port 389 in via en0 setup keep-state
00723 0 0 allow tcp from any to any dst-port 389 out via en0 setup keep-state
00724 0 0 allow udp from any to any dst-port 389 in via en0 keep-state
00725 0 0 allow udp from any to any dst-port 389 out via en0 keep-state
00748 0 0 allow tcp from any to me dst-port 548 in via en0 setup keep-state
00749 0 0 allow tcp from any to any dst-port 548 out via en0 setup keep-state
00777 0 0 allow tcp from any to any dst-port 25 out via en0 setup keep-state
00888 0 0 deny tcp from any to 224.0.0.0/4 in via en0 setup keep-state
00889 22082 1711893 deny ip from any to 224.0.0.0/4 in via en0 keep-state
00890 0 0 deny log logamount 1000 icmp from any to any icmptypes 5 in via en0 keep-state
00891 0 0 deny log logamount 1000 ip from me to me in via en0 keep-state
00892 1 92 deny log logamount 1000 icmp from any to me icmptypes 0,8 in via en0 keep-state
00893 0 0 deny log logamount 1000 igmp from any to me in via en0 keep-state
00894 459 22663 deny log logamount 1000 tcp from any to any setup in via en0 keep-state
00895 0 0 deny tcp from any to any dst-port 137,138,139 in via en0 setup keep-state
00896 58 9866 deny udp from any to any dst-port 137,138,139 in via en0 keep-state
00897 0 0 deny log logamount 1000 tcp from any to me dst-port 113 in via en0 setup keep-state
00898 0 0 deny log logamount 1000 tcp from any to any dst-port 0 in via en0 setup keep-state
00899 0 0 deny log logamount 1000 udp from any to any dst-port 0 in via en0 keep-state
00998 2187 237110 deny log logamount 500 ip from any to any
01000 0 0 allow ip from any to any via lo0
01030 0 0 deny udp from any to any dst-port 626 in
01040 0 0 deny ip from 82.165.178.175 to any in
63200 0 0 deny icmp from any to any in icmptypes 0,8
63300 0 0 deny igmp from any to any in
65000 0 0 deny tcp from any to any in setup
65001 0 0 deny udp from any to any in
65534 0 0 deny ip from any to any
65535 1472 180429 allow ip from any to any
## Dynamic rules (545):
00222 4565 528924 (144s) STATE tcp my.remote.ip 42685 <-> my.xservez.ip 22

How did 1472 packets match 65535?

And I found this with man ipfirewall:

"There is one rule that always exists, rule number 65535. This rule normally causes all packets to be dropped. Hence, any packet which does not match a lower numbered rule will be dropped. However, the kernel compile time option IPFIREWALL DEFAULT_TOACCEPT allows the administrator to change this fixed rule to permit everything."

So Apple has already changed the fixed rule to permit everything. I would like to find out more about "compile time" options and how to change them -- I used sysctl -a | grep default , as well as trying grep firewall, but did not find this "compile time" option here.

I discovered that once I made an outbound rule for udp to any port 626, the rule number 00001, which allowed udp from any 626 to any 626, was no longer automatically inserted before everything. That rule 00001, I think, is just Apple checking up on serial numbers, and does not represent as I first feared, a system compromise.

I, too, don't understand why Mr. Rinehart denies ip to 127.0.0.0/8 twice in a row with identical rules, but thought that maybe there was an advanced reason for it that I had yet to learn.

The 998 deny rule I thought should discard all remaining packets, and Apple's deny wouldn't be necessary, but I left it for overkill. I was shocked to see matches in the all inclusive 65535. This must be changed.

I wish someone could share how to force ipfw to only load the rules from ipfw.conf, and to skip the rules generated by server admin. Although server admin's firewall gui got better from panther to tiger, it doesn't seem to begin to access the traffic shaping capabilities of ipfw and dummynet--it doesn't make pipes or queues--nor does it create stateful rules.

Yes.... I believe you are on to something!

Also in man ipfw:

"The typical use of dynamic rules is to keep a closed firewall configur-
ation, but let the first TCP SYN packet from the inside network install a
dynamic rule for the flow so that packets belonging to that session will
be allowed through the firewall"

and later,

"BEWARE: stateful rules can be subject to denial-of-service attacks by a
SYN-flood which opens a huge number of dynamic rules."

So the LAN/NAT context is one where the fist tcp syn packet comes from inside network. If the first tcp syn were to come from external network, then the rule becomes a target of d-o-s attacks.

I think Mr. Rinehart's example is not selective enough with his "keep-state"s. For example, his rule
"ipfw add 470 allow log icmp from any to me icmptype 0,8 in via en0 keep-state"
would create a dynamic rule every time anyone tried to ping him, so a hacker could command a zombie farm to ping Mr. Rinehart, and he might have trouble that even duplicate deny rules couldn't get him out of:(

I hope this is why my current config is unstable and requires occasional reboots. Tomorrow, I shall try making it more selectively stateful.

I'm not much further along in my quest to fix 65535. But I did find a file, " /System/Library/Frameworks/Kernel.framework/Headers/netinet/ip_fw.h", which is a header with all sorts of ipfw options, but haven't found this default yet.

I must give Tiger's Server Admin's firewall gui more credit: it does create stateful rules! For example, it adds "keep-state" on outbound DNS rules. It also incorporates features of ipfw2, such as allowing the creation of "address groups", so you can create a group "yourips" and a group "evilips" and control services to the groups! Way easier than making rules on a per ip basis. I'm migrating back to the GUI, and will just use ipfw.conf for the rules the GUI can't make, such as pipes and queues.

I've also learned that ipfw is not the only option. Has anyone experimented with HLFL (high level firewall language, described at http://www.hlfl.org/ )? There is an os x port with fink available. I've just not ready to learn a new firewall syntax after all this work with ipfw. But if anyone has experience with HLFL, and found it preferable, any feedback about it would be appreciated.

In a perfect world, where everything works the way the documentation suggests, your logic is impeccable: the 65534 deny all should stop all packets--so why deny udp, tcp, igmp, icmp, etc. before this rule, when we have a deny "all"?

I don't know. But I do know that ipfw -a list, or the "active" rules, shows a 65534 deny all, yet 65535 still has matching packets?

My conclusion is that it is an imperfect world, and that hackers are able to modify and forge different components of datagrams, to sneak past these rules. So that is the logic: to trying to deny every form of everything you can deny before the final deny all rule.

I am currently in the cold room, starting from scratch. I did notice, with netstat -a an established ssh connection that was not authorized--fearing the worst, I am even rezeroing all data before a clean install. Then I am going to create an address group for the bad guys from the logs and deny everything to that group, and be much more selective about what gets allowed in the "any" address group.

Stateful rules I will only use on outbound traffic that I want to track (dns, smtp, etc.) I don't have enough internal users to worry about a flood of SYN signals from the inside.

Hello again:

I discovered that I probably did the clean install our of paranoia--I don't think it was necessary. After the install, at the console, when I started to only allow the services I was providing, I experienced the same behavior that I had remotely: super slow; application server, which wasn't even turned on, would report that it had experienced an error; and after a few minutes, server admin lost the connection. From the remote location, I thought my rules weren't good enough, and that evil users were wreaking havoc.

After much trial and error at the console, I learned that I was the main evil user causing problems for myself--I was disabling essential ports running essential services which I did not know were essential. I posted a list of these ports here:

Everett Fuller, "Slow internet....DNS problem?" #3, 03:44am Aug 26, 2005 CDT