Afctl automatic firewall

Question

I am having a fair number of ssh brute force attacks on my server. The afctl firewall takes care of these attacks initially by adding rules with ipfw. The rule numbers start at 1700, and the it looks like multiple rules are added for each offending IP address (about 10 rules as it seems). After a short while, the rule number reaches 1899, and then no more rules get added. The system.log list the following error message:
Jun 19 16:14:54 computer_name afctl[32548]: Too many rules, entry not added to the blacklist
Is this behavior normal, i.e., why are so many rules added for the same IP, and why does the system stop adding at rule number 1899? I could not fine any way to configure the rule numbering in any of the configuration files.
Any help would be highly appreciated.
-Stefan

Answer 1

Botnets are routinely large enough to bypass IP-based blocks; one probe from each of a gazillion hosts.
Botnets routinely render user-based evasion schemes ineffective; evasion is an old scheme, and the botnets defeated that approach years ago.
Got a couple of scrap x86 boxes and some spare PCI NICs? Congratulations. Add pfSense or M0n0wall or Smoothwall open-source packages, and you've got a firewall.
Watch any of the used-equipment sources, and wait for a surplus (insert vendor) firewall.
As for other options...
:: fwknop or knockd or other port-knocking.
:: Move ssh off port 22, and relocate the port somewhere up in the non-privileged port range and often somewhere up near the ephemeral range, preferably on an unallocated port. (With port-forwarding at a mid-grade firewall, you could potentially relocate the port at the firewall and leave the server unmodified, as various of the server-grade firewalls permit forwarded ports to be retargeted to other ports. Otherwise, you're reconfiguring ssh at your server.)
:: VPN. Preferably at your new firewall.
:: [Denyhosts|http://denyhosts.sourceforge.net>.
Regardless, move your ssh-enabled users over to certificates or certificates with passphrases and not passwords, and only enable specific users for ssh access. That reduces your exposures, even if it doesn't avoid filling your logs with failed accesses and your server with ssh overhead.