Mike Frantzen wrote:
Last, as for the signature that may be different on the same computer if
control by a webbot, is that possible? I guess not as the TCP stack
isn't changed, but anyone know for sure? I am curious on that part.
It will only change if the application does a setsockopt() and changes
the socket buffer size which can change the TCP window size (and the
scaling) on some OSes. It wouldn't surprise me if Linux or Windows had
a few more non-portable sockopts that diddle the TCP options which would
confuse the passive fingerprinting.
I spent a few hours looking into this to try to find some useful
informations. So far, I can't find one signature that would point to
this specific attack. I didn't have much hope but I needed to check to
see. Thanks for the help in doing so, even if the results were negative.
However one interesting finding out of this was that in EVERY SINGLE
cases, and I testes a bit over 5K IP's longed today for the last 5 hours
with the OSFP, even if from different OS, ALL have the same header in
the log of apache.
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Here this is not specific only to the attack as there is also legitimate
traffic with that as well, but in EVERY cases for the bad sources, they
ALL where like this and ALL didn't process header redirect.
So, this point me to my next test as to if I dropping the first SYN from
the connection of already identify offending sources, if that wouldn't
stop them. This bring me my next question, for the sources that are
proxy, isn't it the proxy that process that SYN, so dropping it for the
proxy wouldn't do anything as it would redo the connection, or is it
just clear passing of packets and that would be the device behind the
proxy that would redo the SYN and as it doesn't process the redirect,
may be, just may be it wouldn't redo the sync and as such would
accomplish the intended idea?
I am trying to do just that for IP's in my webbot table, but I am
running around a bit. I already have them all in there, so filter on
them only and let the other be process normally should be good. Not sure
how to do it here.
- All traffic not in webbot table pass no problem, yes.
pass in quick on $ext_if proto tcp \
from ! <webbot> to carp1 port www flags S/SA keep state
But how to drop the first sync of the connections that are in the
<webbot> and keep track of them for let say 5 minutes, or what not so
that if that's a proxy server, meaning the same IP address as a source,
but that behave well, pass it for the time of their session and then
restart the process later on if a new connection comes form the same IP
again?
If I would like to kill it with three connections in 30 seconds, yes
pass in quick on $ext_if inet proto tcp \
from ! <badbot> to carp1 port www flags S/SA keep state \
(max-src-conn-rate 3/30, overload <badbot> flush global)
But drop the first one and keep going for 5 minutes.
block drop in quick on $ext_if proto tcp \
from (! <badbot> AND <webbot>) to carp1 port www \
(max-src-conn-rate 1/300, overload <badbot> flush global)
And tehn clear the IP's older then 5 minutes from <badbot>.
Obviously the above is wrong and not good, plus I am not sure that I can
do logical bolean between tables?
