I am trying to set up some firewall for my 10.5 server, but I just cannot seem to get it to work. The main aim is to try to stop the constant brute force mail login attempts.

To this end I installed fail2ban, to spot and ban the failed logins. For the most part this works, ie the mechanics of submitting the banned IP addresses and sending me an email to that effect is accomplished. If I start up a terminal session I get dozens of IP addresses listed with the following command:

sudo ipfw list

With an entry looking like:

12345 deny tcp from to any in

But, the ban just isn't effective - the same IP address will try again later, sometimes every few seconds for hours.

When I check the fail2ban log it complains (after it has detected a malicious login attempt multiple times):

"WARNING [sasl-ipfw] already banned"

I have tried formatting the ban in different ways:

12345 deny tcp from to dst-port 25
12345 deny tcp from to dst-port 25

But just not making any difference. I even tried just a local network network ban to the web service:

12345 deny tcp from to dst-port 80

But again that does not have any effect. The other rules, seem to be default, in the IPFW list look like:

12300 allow log logamount 1000 tcp from any to any established
12301 allow log logamount 1000 tcp from any to any out
12302 allow log logamount 1000 tcp from any to any dst-port 22 …

and one final rule in the list (which I read somewhere cannot be changed):

65535 allow ip from any to any

Server admin app indicates that the firewall service is running, there are no "deny" listings in the ipfw log. The entries patched in to IPFW by fail2ban do not appear in the Server Admin entries anywhere, nor in the ipfw.conf or ipfw.conf.apple files (so I'm not sure where they are stored). But I do see them when I get "ipfw list" in the terminal and they are listed in the "Active Rules" tab of the Firewall section in Server Admin.

Thanks for any help on this issue.


It looks like your fail2ban script is using too high a rule number. ipfw evaluates rules in numeric order, and the first that applies to a given packet determines what's done with it. This means that lower-numbered rules have higher priority. Since the fail2ban "deny" rules are getting added with the number 12345, but the Server Admin-configured "allow" rules start at 12302, at least some of the allow rules are overriding fail2ban's deny rules.

Simple fix: find where the rule number is defined in your fail2ban script, and lower it to something like 12200.

BTW, the fact that fail2ban's rules aren't getting added to the config files is normal, and probably good. These files are used when the firewall is reloaded (e.g. when you reboot), but don't necessarily reflect the "live" firewall state. If you wanted, you could edit the fail2ban script to add its rules to those files as well as setting them in the live state, but that means that your ruleset would grow arbitrarily large over time. IMO, the only time you should bother with such "permanent" bans is if you keep seeing abuse from the same IPs over and over for a long period of time... but I'd expect this to be rare.

  • Gordon, thank you so much, that fixed it. I was relying on IPFW to set a rule number, and also misunderstood the 'LOG' keyword from the man page, and what it said about processing these rules last: logging is done after all other packet matching conditions have been successfully verified, and before performing the final action. Anyway, naughty packets now denied! Understand your point about the rules not being in the config files too. – typonaut Sep 28 '16 at 11:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.