On Wed, Sep 28, 2016 at 08:54:14PM -0400, trondd wrote:
> On Wed, September 28, 2016 1:20 pm, Chris Bennett wrote:
> >
> > Right now I am using a simple script from the error log to block
> > permanently any requests from that IP using OpenBSD pf.
> >
> > That simply doesn't work well enough anymore due to the time lag between
> > 20+ requests at once getting to the log file.
> 
> I use a combination of overload in pf with a bruteforce table and log
> parsing.  I don't currently do the log parsing in real time.  You could
> use your own script or something like fail2ban for that.  The combination
> will quickly lock out rapid connection attempts, while eventually also
> getting the slow pokes.

I don't think bruteforce will be helpful in my case. I do occasionally
get bruteforce attacks, but not very often.
What I usually get are identical attacks of a certain set of variations
of URLs from one IP address. A little later the same thing from another
IP, then another, etc.

One of the reasons I am thinking of a mod_perl solution is that mod_perl
can step in very early in the Apache process. All kinds of things can be
done long before normal access is available to other processes.
But I have no experience using any of these parts of mod_perl. I have
only used later functions in the cycle.

> 
> > Plus, I
> > occasionally screw up and block my own IP address so I keep an SSH
> > session open before experimenting.
> >
> 
> Create a "safe" table in pf and put your often used IPs in it (assuming
> they are static enough for this) and match that before you check the
> bruteforce table.  Also, your rules and tables for ssh can be different
> than that of the web server.  No reason for accidentally going to a bad
> URL to lock you out of ssh.
> 

Thanks, I hadn't thought of that. Some of my IPs are static. But I also
travel a lot between parts of Mexico and Texas. But I will add to pf for
that. I can add hotel IPs, when their WiFi signal is actually
strong enough to connect. That should solve that problem.

For the list, the rest is me rambling on so don't bother reading any
further, is OT.


I can develop on my office/home systems, but some stuff I use requires
live testing since I don't have another production server. Live testing
since my software depends on what is sent from another company and then
processing on my server followed by an email customised for a customer
to access paid content on my server. I can fake the input to a certain
degree, but I had one customer a while ago request a refund before
getting a username/password from my end, so that input was unexpected
and did not follow the other company's documentation, which is of poor
quality, so I had to fix a problem that was unexpected and basically
undocumented.


Thanks. Very useful for my SSH problem.
Chris Bennett

Reply via email to