[FEATURE] Add xmlrpc.php to http-bf-wordpress_bf #863
Comments
|
@adam-ah: Thanks for opening an issue, it is currently awaiting triage. In the meantime, you can:
DetailsI am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository. |
|
@adam-ah: There are no 'kind' label on this issue. You need a 'kind' label to start the triage process.
DetailsI am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository. |
|
Transferring parser/scenario request to the hub repository |
|
Hey 👋🏻 I don't use word press personally but if repeated calls to xmlrpc in short duration is not normal behavior then you can open a pull request on this repository with your changes you purposed |
|
thanks for moving the ticket to the right repo, @LaurenceJJones I'll keep that in mind for future reference |
|
this sounds like a bad idea, especially when you take into consideration 3rd party plugins that use the xmlrpc API endpoint heavily. |
|
@GNU-Plus-Windows-User your point of view is inaccurate for the following reasons:
Further reading on fail2ban and xmlrpc 1 2 In your response, could you please address each of these, with a special focus about the concern regarding adding a correct brureforce filter with the appropriate leakspeed and capacity parameters, with evidence (logs) showing that indeed, it is not possible or downright harmful? |
I don't know about this, plugins like jetpack do use the xmlrpc endpoint a fair bit. I don't use jetpack anymore so this may have changed. I can test this if you like.
Maybe, it depends on what the xmlrpc.php is used for, and the use case, this is my main concern by expanding the scenario to cover xmlrpc.
That doesn't mean anything, the xmlrpc api endpoint wasn't created for hackers to hack wordpress. Yes, it's a common attack vector but so is port 443, that doesn't mean you should be shutting off port 443. If you don't need it then it makes sense to disable it since that's a basic attack surface reduction technique.
I understand that concern and I fully support expanding brute force protection to XMLRPC, if it doesn't cause any additional FPs which is my main concern.
You shouldn't be blindly following the advise of security guides online, if you don't need the xmlrpc.php endpoint then it makes sense to disable it. Disabling xmlrpc is something that should be taken on a case by case basis, disabling stuff without knowing what it does is a sure fire way to break stuff. I've seen a lot of very bad takes in the wordpress community, to be fair many of these people aren't security experts.
Agreed, CrowdSec should add a disclaimer for the scenario to prevent confusion. |
|
These logs are from using the wordpress app: You'd have to have a seperate scenario with a fairly leniant leak speed and capacity, maybe 5s leak speed and a capacity of 20. |
|
I also just realized, we have a separate scenario It is NOT included by default due to reasons outlined by @GNU-Plus-Windows-User https://app.crowdsec.net/hub/author/crowdsecurity/collections/wordpress |
|
Great find, @LaurenceJJones The solution could be (?) then to add it to the description of the collection to encourage installing the optional http-bf-wordpress_bf_xmlrpc as in most cases this would be needed. I think these all come back to the high suprise factor of CrowdSec defaults - I would not expect a wordpress scenario made by CrowdSec to be not included in the WordPress collection (probably most users would not expect it, even though it is a critical scenario for most of wp users). Taking 3 days and 3 people to find this may suggest that something is not quite right... |
Yeah I agree, we have over 200 scenarios so adding links in the markdown is easy to aid other to find them. We are also working on a recommendation system in the hub depending on tags. So when viewing the wordpress collection it will offer other scenarios with similar tags (Excluding the ones inside the collection itself) Edit: Plus when our WAAP (waf) comes out, we can easily generate rules based on the HTTP body itself rather than having a vague scenarios based on higher limits |
What would you like to be added?
/kind enhancement
What
WP brute force often comes as repeated
200requests toxmlrpc.php. The currenthttp-bf-wordpress_bfdoes not catch this.Sample log (this repeated 20 times before WordFence blocked it)
Sample explanation
Why
WP will assess login requests sent to
xmlrpc.phpand return200. WordFence will eventually block the user but that is much more compute-intensive task. Without WordFence this would not get blocked, letting bruteforce attacks through.How
Simply add checking for
xmlrpc.phpinhttp-bf-wordpress_bf.yaml:Sample after the change
The parsing is as-expected after the change:
Why is this needed?
xmlrpc.phpbrute force attacks are not captured correctlyThe text was updated successfully, but these errors were encountered: