Hello everyone, today’s post is going to be something interesting that I’ve been wanting to do for a while. I had experimented in the past few months with implementing a security information event manager into my own environment, with the intentions to gain a better understanding on how to analyze log files and create rules for network traffic to be caught in my system. I wanted to connect the ideas in my head to be clearer in how I understood computer networking and security, so this was the approach I decided to use.
I happened to do this lab on vacation a few months ago, so I don’t have a whole lot of pictures to share in this blog post. However. I will periodically update this post as I revisit some of my steps, for those reading this to understand what all you can learn from a lab like this.
Setup and Installation
With Wazuh, I decided to deploy it using a Docker-Compose configuration. From there, I essentially just swapped out some information specific to my environment, and I was able to get it up and running.
Getting Familiar
I also took some time in this project to get familiar with the Wazuh dashboard as there were a lot of things to get familiar with. I wanted to try and understand all the amazing charts and filter mechanisms within. This was a clean dashboard, and didn’t take as much setup as the Graylog tutorials I had visited, although I do want to go back and do a similar lab with Graylog as well.
Creating Rules
After I had Wazuh up and running, I wanted to try and create some rules. I essentially created a rule to track RDP (port 3389) attempts and successful connections, so that when someone would be trying to remote desktop, be it externally or internally, I would be able to see it. I thought this was a good thing to get used to seeing and I wanted to see how it worked with my PfSense configuration as I had used Snort as one of the Intrusion Prevention/Intrusion Detection systems that would feed into Wazuh. This connection of the two programs (Snort and Wazuh) involved some slight configuration on PfSense, but I was able to get things set up.
I also tried a similar rule creation technique to try and catch nmap scans, although it wasn’t as successful, it did flag a few attempts I had made when scanning the network. It taught me how important it is to tune your rules to be considerably tighter. There’s a fine balance though, because if your rules are too tight, then you will perhaps gain inaccurate information, as some packets were being tagged under a certain rule that was intended to catch malicious traffic, when in reality the traffic was benign.
Lessons Learned
Getting hands on with a security information event manager, starting to create rules, and understanding how everything is being picked up by your system is important to the world of security. If you’re trying to become a security analyst, it helps to see the offensive side (scanning a network with nmap), in addition to the defensive side (seeing malformed packets or ARP broadcast storms, stuff like that), which helps you confirm both sides.