A friend of mine recently challenged my post SIEM 102 — Detect WordPress bruteforce where he proposed a tool that can effectively bruteforce WordPress from a lot of different IPs:
Pushing back on the detection mechanism mentioned in your blog, are you aware that a tool like Fireprox allows an attacker to leverage AWS by sending every request from a different IP address?
— Guillaume Caillé (@OffenseTeacher) January 20, 2021
Some background
Some background are required to understand his response.
First, it is important to know that Guillaume is an excellent attacker / hacker (Red Team). He works at the same company as me (Okiok) on the offense side. He is hired by companies, through Okiok, to test their defenses. It’s his job to know the best attacking tools available. His job is to simulate an attack by a highly skilled bad actor.
Second, Fireprox is a tool that uses some features of Amazon Web Services (AWS) to send requests from AWS’s IPs. AWS is a cloud provider; they offer many cloud services like storage, computing, etc. They own a huge amount of IP addresses so Fireprox leverages this feature to send requests to website using a new IP on almost every request (with some limitations).
In my post, I explain that we can detect a simple bruteforce if the same IP does 10 tries in 5 minutes. Because Fireprox uses a different IP (almost) every request, it can bypass this detection pattern.
My answer: a good InfoSec Strategy
The short answer is: you need a good InfoSec Strategy. There are a few key elements to answer this comment:
- A SIEM, and any detection use cases, is not a silver bullet. One use case is designed to detect one pattern of attack, but there are always new attacks. A SIEM is something that keeps evolving. It’s important to add new detection use cases as needed, and remove the old ones that are out of date.
- A defense in depth approach is key. It’s important to have many layers of security measures.
- Understand your Threat Model. The idea is to understand who might target you, from an unskilled bad actor to an APT.
The lifecycle of a Use Case
When using a SIEM, we’ll develop more and more detection use cases as we learn of new attacks, we introduce new software and systems, etc. The problem with this is that the more use cases we have, the more resources are needed to run and operate the SIEM, without counting the false positive rate and time to maintain them.
As we add people, devices, systems and software in our environment, the existing use cases might start to generate more and more false positives. Because of this, it’s important to revisit the existing use cases and evaluate what strategy can be used to reduce the level of false positives. To get some ideas on false positive mitigation strategies, you can review the following posts:
- SIEM 102 — Detect WordPress bruteforce
- SIEM 102 — Detect Windows bruteforce
- Be creative! Try to find new ways to reduce the level of false positives without increasing the level of false negatives
As a use case ages, it might become obsolete if, for example, the technology we try to protect is not used anymore. For example, if I were to change from WordPress to another CMS for my blog, any use case base on WordPress would become obsolete, but they would continue to impact the SIEM’s performance and it’s maintenance. For this reason, it’s important to periodically revisit and question if the use case is still useful.
When I say it would impact maintenance, this is because when you have a lot of use cases, it clusters the view of the SIEM and/or reports and affects any statistics you have (ex: what’s the percentage of use cases that trigger every weeks)
A defense in depth strategy
I couldn’t presume to produce a better definition of what is Defense in Depth than the CIS:
Defense in Depth (DiD) refers to an information security approach in which a series of security mechanisms and controls are thoughtfully layered throughout a computer network to protect the confidentiality, integrity, and availability of the network and the data within. While no individual mitigation can stop all cyber threats, together they provide mitigations against a wide variety of threats while incorporating redundancy in the event one mechanism fails. When successful, this approach significantly bolsters network security against many attack vectors. An effective DiD strategy may include these (and other) security best practices, tools, and policies.
https://www.cisecurity.org/spotlight/cybersecurity-spotlight-defense-in-depth-did/
With an analogy, it’s like a car and it’s many defense mechanism to reduce injuries and deaths: Collision avoidance system, Anti-lock braking system, air bags, seatbelt, etc. Like with a car, it’s not completely risk proof. But the more layer you have, the less risk you have.
Using my WordPress server as an example, I have many layers to secure it as much as possible according to my Threat Model:
Note: this list is incomplete as I do not want this post to be too big, but it give a good idea of what I’ve done
- WordPress and all the plugins are always up to date
- I have a few security plugins, some of them provide bruteforce protection
- I have MFA enabled for the login
- The login page is unavailable (it is, but you need to know how. A little bit of security through obscurity can help sometime!)
Note: this point changed since I did this post. I am now using another security plugin and other tools and I needed to keep the normal URL for the login page. But I added other mitigation strategies around the login page. - The web server logs are sent to my logz.io stack with a few detection use cases and automated actions to block attacking IPs
- My server has fail2ban
- My server provider offers some basic protection, like DDOS.
- I have write-only backups (you need special access to read and restore)
- Etc.
Understand your Threat Model
A Threat Model analysis is where you carefully analyze what are your attack vectors, what bad actors might be interested in your assets and to which ones. There are many ways to analyze this and I will dedicate a post for this at some point.
I didn’t do a complete and thorough Threat Model analysis for my blog, but I am basing mine on my gut feeling and my experience (if you are doing this for an enterprise, don’t! You are way more interesting to bad actors than me!).
In my case, I don’t have much asset of value and I have backups in case of a ransomware or a DOS of some kind (like if I do an error in a config). The most important thing I try to protect is my time because restoring a backups or something like that is time consuming. From the bad actors point of view, my server could also be useful in a botnet. Since I started publicizing my blog, I know some script kiddies might try to hack my website in some way, including with a DDOS.
Based on this, I think that the protection layers I have are more than enough. If I look at the attacks I block almost everyday, I know I am protected against the most probable attacks on my server, including a distributed bruteforce, like my fiend was proposing.
Conclusion
Like I thought, it took me more than 280 characters to answer this question 😉
I know I touched some point I didn’t address yet in my blog, but I plan on talking in depth about most of them at some point. Don’t forget that the initial post name was “SIEM 102 (…)”. For the moment I am only talking about the base and I already have plans for some “SIEM 401” posts!
I am glad Guillaume asked me this question though, as this allowed me to see what subject I should address in the future. Thanks Guillaume!
Don’t hesitate to write to me, like Guillaume did, if you have any questions. This could also help me better understand how to write a good blog that answers most questions.
Feel free to leave your comment down here for any questions or comments.
