At the risk of sounding last decade… Sourcing a scanner that attempts to illustrates the goals of an attacker could make for a worthwhile project.
As an aside a postfix version really ought to exist with it’s myriad of status codes. Regards Patrick > On Sep 28, 2016, at 9:04 PM, Chris Bennett <chrisbenn...@bennettconstruction.us> wrote: > > 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
