Re: [SSHGuard-users] A minor bug in Wordpress brute force protection

[Gary <li...@la...>]

I think 444 is strictly user generated. Nginx will generate a 400 return by itself. There is some virus/botnet/??? that sends \xx type data. Some attacks I have determined are attempts to hack RDP. Others I haven't a clue, but they sure aren't browsing. You also get a 400 on a "connect", which I assume some server software uses to set up proxies. 

Besides WordPress hackers, I snag the Struts attacks, php administrators attacks, and hackers that somehow assume they can escape out of the web root. They look for /usr for example. 

Maybe once a week I take the access file and delete the obvious legit stuff. Self referrals, favicon loads, Google searches (real or spoofed), just to data reduce the log. Then I look at the 404 returns to see if there is some new attack. 

Mind you none of this activity is dangerous in a well patched system. I'm more concerned about the zero day stuff. If I can block via IP likely sources of hacking, I've reduced my exposure to the unknowns. 

As a bonus, all this data center IP space in my "noeyes" blacklist gets banned from all mail ports other than 25. 

  Original Message  
From: ton...@gm...
Sent: January 27, 2018 11:06 AM
To: li...@la...; kev...@gm...; ssh...@li...
Subject: Re: [SSHGuard-users] A minor bug in Wordpress brute force protection

I slightly configured my nginx a bit, so it only sends 401 logs to 
syslog for two reverse proxies that has http basic auth, and only log 
wp-login.php accesses when there is a POST + 200 response.

I do wonder though, on what scenario will nginx sends a 444 proactively 
(other than configured doing so).

在 2018/1/27 下午 2:03, Gary 写道:
> I hadn't realized you were looking at web server logs.
> 
> I don't run WordPress, but I use Nginx maps to snag all these obvious hackers. Perhaps a different approach, at least for Nginx users, would be to look for the 444 response code rather than trying to come up with regex for every scenario.
> 
> On my freeBSD server, I've been using swatch to give the hacker a three minute timeout. From my experiments, that is what it takes for these hacking scripts like Jorgee to go away.
> 
> They must have 60+ attacks in Jorgee. These are all easy enough for a non-coder like me to snap with a map. I think it would be more flexible, at least for Nginx, to just look for 444. Actually what I do is set up a custom log format so I can easily parse the log for the 444 return and then the IP address. I have a script to make a list of the offending IP addresses and see which go to data centers. I then block the IP space of that data center and then pest is gone forever.
> 
>    Original Message
> From: kev...@gm...
> Sent: January 27, 2018 10:42 AM
> To: ssh...@li...; ton...@gm...
> Subject: Re: [SSHGuard-users] A minor bug in Wordpress brute force protection
> 
> Hi Tony,
> 
> Thanks for the report.
> 
> On 01/25/2018 08:33, Tony Zhou wrote:
>> I tried to implement Wordpress login brute force protection with my
>> SSHGuard 2.1.0 (2.1.0-1 from Arch Linux repo), and found that SSHGuard
>> will not react to access log of attempts to wp-login.php if there is an
>> argument passed to wp-login.php.
>>
>> I am using iTheme Security to hide my wp-login.php address, and when a
>> failed login happens, the following log was captured:
>>
>> server nginx: my.client.ip.addr - - [25/Jan/2018:11:20:57 -0500] "POST
>> /wp-login.php?itsec-hb-token=somewploginentry HTTP/2.0" 200 2159
>> "https://my.server.domain.tld/wp-login.php?itsec-hb-token=somewploginentry"
>> "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:58.0) Gcko/20100101
>> Firefox/58.0"
> 
> I didn't expect to see the '?' in POST requests, so the parser does not
> recognize characters after 'wp-login.php' when detecting the attack.
> 
> I think I'll go ahead and add a catch-all to the regex?
>