Day 38 –
#100DaysOfCybersecurity 🔐
Today, I continued working on my NIDS project and focused on configuring and troubleshooting Suricata. I ran into several challenges that highlighted how fragile IDS visibility can be when misconfigured.
Challenges I encountered:
- My IDS sensor interface was not in promiscuous mode, so it couldn’t see traffic traversing the infrastructure (victim) server.
→ Attacks were happening, but Suricata had no visibility.
- Suricata logs were stored in pretty-printed JSON, which made correlation and CLI parsing with tools like jq harder than with line-delimited JSON.
- I initially bound Suricata to the wrong network interface, so no alerts were generated even though rules were correct.
- My custom SSH detection rule failed due to HOME_NET misconfiguration, causing Suricata to treat the victim as out-of-scope.
- Debugging required repeated restarts and config validation, reinforcing how small misconfigurations can completely break IDS visibility.
Key takeaway:
Today’s work reinforced that an IDS is only effective if:
- It is listening on the correct interface
- It has proper network visibility
- Its logs are usable for analysis
Even when attacks are occurring, detection fails if the sensor cannot see or correctly interpret the traffic.
These challenges gave me hands-on insight into real-world NIDS tuning and troubleshooting, and they set a strong foundation for improving my detection logic and log analysis in the next phase of the project.
Next:
Refine rules, fix logging format, and begin correlating Suricata alerts with attacker activity.
On to Day 39. 🛡️📊
@jay_hunts @ireteeh @segoslavia
#RedTeamer #NIDS #Suricata #SOC #CyberSecurityLab #LearningInPublic #100DaysOfCybersecurity