David,
I would take a look at adding synproxy to your rules before worrying about

max-src-states. Synproxy will allow max-src-conn-rate to work more

reliably.
By default, pf(4) passes packets that are part of a tcp(4) handshake be-

tween the endpoints.  The synproxy state option can be used to cause pf(4)

itself to complete the handshake with the active endpoint, perform a

handshake with the passive endpoint, and then forward packets between the

endpoints.
No packets are sent to the passive endpoint before the active endpoint

has completed the handshake, hence so-called SYN floods with spoofed source

addresses will not reach the passive endpoint, as the sender can't complete

the handshake.
The proxy is transparent to both endpoints, they each see a single

connection from/to the other endpoint.  pf(4) chooses random initial se-

quence numbers for both handshakes.  Once the handshakes are completed, the

sequence number modulators (see previous section) are used to translate

further packets of the connection. Synproxy state includes modulate state.
(pf.conf man page)
--

 Calomel @ http://calomel.org
On Tue, Oct 23, 2007 at 11:23:05PM -0500, david l goodrich wrote:

quoted text
>On Tue, Oct 23, 2007 at 05:46:45PM -0400, Calomel wrote:

>> David,

>>

>> Was the offending client completing the 3-way handshake everytime it

>> connected?

>>

>> For stateful TCP connections, limits on established connections (connec-

>> tions which have completed the TCP 3-way handshake) can also be enforced

>> per source IP. The max-src-conn-rate / limit the rate of

>> new connections over a time interval.  The connection rate is an

>> approximation calculated as a moving average.

>>

>> You may also want to use synproxy for ssh and take a look at

>> max-src-states. I have examples here: http://calomel.org/pf_config.html

>

>I didn't respond to this until now, because I wanted to do some

>research first.  As the hosts that are being blocked by this

>aren't hosts I control, I needed to set up some access on the

>outside.

>

>So it looks like i can run  'nmap -sS -p22 25.103.82.80/28' until

>doomsday and it will always show as a passed connection.

>

>But when i start telnetting to port 22 on machines in this

>subnet, the fourth 'telnet' connection is blocked, no matter

>which host I hit previously.  So I think that you are correct

>in that the attackers are not initially completing the 3-way

>handshake, and are thus not tripping the filter.

>

>I'll look in to max-src-states, but I think now that I've shown

>that the actual "attack" (if that's what they are) attempts are

>blocked properly, I'm not terribly concerned if they can scan the

>subnet.

>

>Thanks,

>  --david

>

>>

>> --

>>  Calomel @ http://calomel.org

>>

>> On Tue, Oct 23, 2007 at 03:58:52PM -0500, david l goodrich wrote:

>> >Nobody?  Sad, it's still doing it.

>> >

>> >

>> >On Sun, Oct 21, 2007 at 02:22:43PM -0500, david l goodrich wrote:

>> >> I've set up a max-src-conn-rate rule on my gateway router to

>> >> mitigate brute-force ssh attacks.  This router protects a /28

>> >> subnet, 25.108.82.80/28.

>> >>

>> >> The relevant rules:

>> >>

>> >> # pfctl -sr | grep attack

>> >> block drop in log quick proto tcp from  to any

>> >> pass in log proto tcp from any to any port = ssh keep state

>> >> (source-track rule, max-src-conn-rate 3/30, overload

>> >>  flush global, src.track 30)

>> >> #

>> >>

>> >> What the three columns of output in the below tcpdump output are:

>> >> timestamp, rule action, and target host.  As you can tell from

>> >> the tcpdump command, the sending host is the same in all cases,

>> >> 208.53.147.204

>> >>

>> >> # tcpdump -enr /var/log/pflog host 208.53.147.204 \

>> >> >       | awk '{print ,,}' | sed s/.22:// | head -30

>> >> reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file)

>> >> 12:09:45.849594 pass 25.103.82.80

>> >> 12:09:45.850279 pass 25.103.82.82

>> >> 12:09:45.850827 pass 25.103.82.83

>> >> 12:09:45.851310 pass 25.103.82.84

>> >> 12:09:45.852003 pass 25.103.82.85

>> >> 12:09:45.852496 pass 25.103.82.86

>> >> 12:09:45.853007 pass 25.103.82.87

>> >> 12:09:45.866580 pass 25.103.82.88

>> >> 12:09:45.867345 pass 25.103.82.89

>> >> 12:09:45.868339 pass 25.103.82.92

>> >> 12:09:45.902389 pass 25.103.82.95

>> >> 12:25:52.632295 pass 25.103.82.80

>> >> 12:25:52.632973 pass 25.103.82.82

>> >> 12:25:52.648804 pass 25.103.82.83

>> >> 12:25:52.684792 pass 25.103.82.84

>> >> 12:25:52.687989 pass 25.103.82.85

>> >> 12:25:52.688652 pass 25.103.82.86

>> >> 12:25:52.690882 pass 25.103.82.87

>> >> 12:25:52.691371 pass 25.103.82.88

>> >> 12:25:52.692290 pass 25.103.82.89

>> >> 12:25:52.695340 pass 25.103.82.92

>> >> 12:25:52.698864 pass 25.103.82.95

>> >> 13:08:36.949178 pass 25.103.82.87

>> >> 13:08:38.864585 pass 25.103.82.87

>> >> 13:08:40.452215 pass 25.103.82.87

>> >> 13:08:42.038388 pass 25.103.82.87

>> >> 13:08:46.923469 block 25.103.82.88

>> >> 13:08:49.922116 block 25.103.82.88

>> >> 13:08:50.212040 block 25.103.82.87

>> >> 13:08:51.099435 block 25.103.82.87

>> >> #

>> >>

>> >> It seems to me like this host should have been blocked back at

>> >> 12:09:45, not 13:08:46.  Am I misunderstanding the rule?

>> >>   --david

>> >>

>> >> [demime 1.01d removed an attachment of type application/pgp-signature

>which

>> >had a name of signature.asc]

>> >

>> >[demime 1.01d removed an attachment of type application/pgp-signature which

>had a name of signature.asc]

>

>[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]