I'm trying to stem the flood of wordpress brute force attacks coming into our network (we host a lot of WP sites).
Detecting WP logins is relatively easy, by setting up a signature that looks for the regex wp\-login\.php in the http-req-uri-path context with the http-method = POST qualifier. I can now see all of the wp-login requests coming into our network.
However, detecting a failed WP means also detecting the 200 response code from the web server (WordPress issues a 302 redirect upon sucessful login, a 200 upon failure).
I have tried adding an extra AND condition to my signature which checks for http-rsp-code = 200 but it doesn't trigger. So...
Custom Vuln Signature:
Severity : Informational
Default Action : Alert
Direction : client2server
Affected System : server
Scope : Transaction
Ordered Condition Match
Condition 1 : pattern-match http-req-uri-path ~= wp\-login\.php
Condition 2 : equal-to http-rsp-code == 200
Why is this failing to work? Without Condition 2 it shows up all wp logins, but with Condition 2 it sees nothing. Help :-)
Could you please post your query to DEVCENTER, they might help you for your custom signature.
We control wordpress logins in the following manner:
force your web content management staff us only access the Wordpress login page from on the network (internal zone) and if they require it from of the network then require them to use a vpn solution. This then means that any wordpress login request from the internet is not desirable and can be blocked with the signature that just identifies the incoming request from the internet. We have been doing this for over a year now with a lot of success.
Thanks Phil, unfortunately this won't work - we are a web host and host thousands of wp sites - we need to block/reset incoming connections from external/public IP addresses that repeatedly fail to log into WP correctly.
The signature does look correct for the response code 200. Can you do a packet capture on a failed login and confirm what the data looks like in the response?
If you look at the document located here: Creating Custom Threat Signatures in particular look at Example 4 located on page 45. You can create a combination signature to detect brute force attempts with variables you can set (# of connection attempts in a time period) that will separate the valid users from those who are up to no good.
Hey Steven, thanks for your reply. I captured the transaction - and here is the "Follow TCP Stream" output from Wireshark of the relevant packets...
POST /wp-login.php HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
HTTP/1.1 200 OK
Date: Mon, 04 Aug 2014 09:36:41 GMT
Content-Type: text/html; charset=UTF-8
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/
The actual Hex dump of the POST and the response (respectively) are:
Wireshark has no difficulty seeing this transaction and correctly decodes the Status Code as 200 in the analysis frame at the bottom of the window.
I can only assume that there is a bug in PAN OS or this is by design (i.e. unable to mix req and rsp contexts in a single signature)?
Thanks for your reply - I have read that document backwards and forwards several times, trying to see if I'm missing something obvious :-)
Unfortunately, the approach highlighted in the example is too simplistic. It is quite possible that an IP address might log into numerous WP sites legitimately. Web designers in particular are a customer group we don't want to annoy by being overly zealous. As we are a web host, we have a LOT of legitimate WP login requests. We already block clear cases of abuse using a similar combination signature, but a lot of attacks are characterised by a handful of failed logins from an IP every hour - not enough to trigger the combination signature, but still a problem, especially when we have several hundred IPs exhibiting similar behaviour.
Making the scope Session is not appropriate - and doesn't work anyway :-)... In a session it would be expected that at some point a POST request for wp-login.php will be made, and at some point later in the session a 200 status will be issued (not necessarily as the direct result of a login, but precipitated by a later page request in the same session).
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!