Since a couple of days my little router appearances a lot of connections to port 22 from a bunch of same hosts which my pf firewall correctly drops. How can I put those attemps automatically to a table "attackers"?

I had something like the following in mind. Is that possible?

Code:

table <attackers> persist
block in quick on $EXT from <attackers>
block in quick on $EXT from any to ($EXT:0) port 22 (max 1, overload <attackers> flush)

Obvious. The third rule does not work. But how can I accomplish something like that?

I have a similar rule in my pf.conf for port 80. Since ssh listens on another port than 22 (for safety reasons) I just simply want to make a similar rule but altogether with block instead of pass. So that everyone who tries connection to port 22 is being put on the table attackers automatically.

Edit the rule accordingly and do not flush it at all? (verify this plz i am not certain), it will keep the table of offenders in PF. Something like this maybe helpful, i just typed this out, have not run in PF to test, feel free

However I was only able to use overload in conjunction with pass and keep state so far. Any other clues?

Have you tried changeing the "pass" to "drop" and not keeping state? then add a table rule perhaps? If your basically looking to drop port 22 TCP and drop offenders into a table, start with a simple "block log drop on $EXT from any to any port 22" and expand on that.

__________________
The more you learn, the more you realize how little you know ....

Some time ago I read an analysis of these SSH probes. There are two stages. In stage one, bots scans network blocks for open SSH ports 22. Then after distributing the addresses found, bots are starting to do these ssh login probes in the second stage.

So simply moving your incoming SSH LISTEN port to something else than the default port 22, will usually save you from being probed in stage two.

Previously a single bot, and thus a single IP address, probed several login names and passwords in a row. So in the past you could block multiple failed connection attempts from a single IP address.

Nowadays a couple of coordinated bots each probe a single name/password . So now each individual probe use a different IP address.

And because you don't want to automatically blacklist an IP address because of one failed login attempt, dealing with these idiots has becoming more challenging.
How would you like it if gmail would block you for one single mistyped password?

My tips:

move incoming ssh to a different port

Use public key authorization

If you cannot use publick keys, use non-English login names.
I have never seen logs where these bots use names like 'Guillaume , Didier, Dieter, Jan-Peter, Wouter, Isidoor, Henk or Sven.

Or for more complexity add underscores "_" , numbers or dashes '-' to the names.
If these bots cannot guess the right names, they already stand no chance.

__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump

And because you don't want to automatically blacklist an IP address because of one failed login attempt, dealing with these idiots has becoming more challenging.

Its not that I want to block them forever... I'd have added a rule to crontab that removes expired hosts after 1 day (pfctl -t bad_guys -T expire 3600). I'm seeing probes on other ports and simple icmp echo requests as well.

I asked him for any suggestions or tips about parsing pflog and extracting IP's and if there was a way to put them into a table or whatever was possible, awaiting a reponse on that question.

Peter's reply to that question;

Quote:

There is a at least deamon in the base system that reads data off
pflog interfaces already: spamlogd.

By looking at /usr/src/libexec/spamlogd/spamlogd.c and likely the
table parts of pfctl it should be feasible to hack together something
that reads a specific pflog interface (I would suggest logging each
rule you're interested in to a separate pflog interface or at least
clustering the blocks that should be treated similarly), looks for
blocks instead of passes, updates table entries. Might even be a fun
project. I'm not sure I'll have the time to do much about in the short
run though.

I actually use snort and have it drop offending IP's into /etc/hosts.deny, i am certain that snort can be configured to your specifications regarding blocking port 22 TCP requests and blocked/logged accordingly.

__________________
The more you learn, the more you realize how little you know ....

I actually use snort and have it drop offending IP's into /etc/hosts.deny, i am certain that snort can be configured to your specifications regarding blocking port 22 TCP requests and blocked/logged accordingly.

Ok. I'll look into it.

Its quite true that the ssh probe behaviour has changed during the last months. But not with other ports (e.g. 5900).

I actually use snort and have it drop offending IP's into /etc/hosts.deny

Was kind of a lie actually i use portsentry for that purpose, i use snort to get more info on scans and attempts. It's a good little program for baiting, and denying, i certainly recommend that one as well.

__________________
The more you learn, the more you realize how little you know ....