Daniel Ouellet wrote:
> Ray Lai wrote:
>> I thought you meant you could do something like:
>>
>> block in log-table <zombie> to port 25
>>
>> where <zombie> is updated automatically.
>
> If you read on the PF and look at what I send you, you will see that
> <bad-ssh> IS updated automatically.
>
> That's what the line:
>
> (max-src-conn-rate 5/30, overload <bad_ssh> flush global)
>
> does. After 5 connection in 30 seconds, the IP address is put
> automatically into the table <bad_ssh> and flush global remove any state
> in the PF table.
>
> Just adjust the max-src-conn-rate 5/30 for what you want.
>
> Hope this make it more clear.
Side note:
It's possible to have more than one rule, to approximate a "curve"
of sorts. I have the following rules on my router:
pass in on $ext_if proto tcp from any to ($ext_if) port ssh \
flags S/SA modulate state \
( max-src-conn-rate 5/30, overload <denied-hosts> flush global )
pass in on $ext_if proto tcp from any to ($ext_if) port ssh \
flags S/SA modulate state \
( max-src-conn-rate 8/60, overload <denied-hosts> flush global )
The second catches the slightly slower scans that may skirt by the first
rule. The "curve" for such scans can be approximated by as many of
these rules as necessary, though I've found that just the two seems to
work fine for me.
I have performed only the most cursory inspection of the code and
therefore am not entirely qualified to comment, but believe that it
ought not be prohibitively difficult to allow the construction of a
list of such rates within a single rule for optimization purposes
and/or easier readability of the configuration file, e.g.
pass in on $ext_if proto tcp from any to ($ext_if) port ssh \
flags S/SA modulate state \
( max-src-conn-rate { 5/30, 8/60, ... }, \
overload <denied-hosts> flush global )
... with the "table" portion being an implicit "or" of those rates
(5 in 30 OR 8 in 60 OR ...). I see a relatively small number of
functions and structures that would need to be changed, in net/pf.c
and net/pfvar.h mostly (change of pf_threshold structures to permit
multiple count/time/limit triads and logic to update them) with a wee
bit of spanking for the parser to get it to understand the "table"
specification for rate curves in addition to the current "limit/time"
specification. (Perhaps a new "curve" data structure, to go along with
the table structures? That seems to have some interesting implications
for some pf knobs used in certain places for queueing, timeout settings,
and so forth.)
Again, I am speaking ex ano, and expect (rightly) to be ignored until
I can produce a patch; I merely bring it up for comment. This behavior
can, as noted, be approximated with the current state of pf.
--
(c) 2005 Unscathed Haze via Central Plexus <[EMAIL PROTECTED]>
I am Chaos. I am alive, and I tell you that you are Free. -Eris
Big Brother is watching you. Learn to become Invisible.
|-------- Your message must be this wide to ride the Internet. --------|
