brutal SSH attacks

[Daniel.Hartmeier at swisscom.com]

Ah, so I guess this does deserve some further debugging :)

First, make sure those connections are matching the expected rule:

Watch an ongoing scan, note the scanner's IP. Run

  # pfctl -vvss | grep -A 2 <IP>

Note the rule number printed right-most in every third line, and compare them to the output
of

  # pfctl -gsr

i.e. for each state entry, find the rule with the corresponding rule number (the left-most @nr).
Is it always the same rule, and does it have max-src-conn-rate/overload? This should also
be the same rule number shown for pflog (e.g. "rule 5/0(match)").

Second, verify that the source node is being tracked:

  # pfctl -vvsS | grep -A 1 <IP>
  <IP> -> 0.0.0.0 ( states 8, connections 8, rate 7.9/60s )
     age 00:00:01, 72 pkts, 9384 bytes, filter rule 105

If it's found, how does it change as the scan progresses?
If it's not found, check if you're hitting the limit of source nodes:

  # pfctl -sS | wc -l
       9025
  # pfctl -sm
  src-nodes     hard limit    10000

(it can be increased in pf.conf with set limit src-nodes <nr>)

Third, exclude the possibility that it did get added to the table, but somehow got removed again:

If you watch an ongoing scan, see the source tracking node getting updated to the limit,
and then check

  # pfctl -t abusive_hosts -vvTt <IP>

do you get a match?

Are you running anything manually or through cron that might manipulate or flush the table,
like a (often superfluous) pfctl -Fa when reloading the ruleset?

Regards,
Daniel