Forem: Dipesh Kumar

Building a SIEM-Style Threat Detection Dashboard Using ELK Stack and Docker

Dipesh Kumar — Fri, 03 Apr 2026 09:16:12 +0000

Building a SIEM-Style Threat Detection Dashboard Using ELK Stack and Docker

In modern cybersecurity operations, centralized log collection and real-time visibility are essential for identifying suspicious behavior before it turns into a real incident. Security teams rely heavily on log analysis platforms to detect failed logins, brute-force attempts, abnormal DNS activity, and other indicators of compromise.

To better understand how this works in practice, I built a SIEM-style threat detection lab using the ELK Stack (Elasticsearch, Logstash, Kibana) deployed with Docker. The goal of this project was to ingest logs, simulate attack patterns, and visualize security events through a dashboard that could support threat hunting and incident response.

This hands-on project gave me practical exposure to:
log ingestion and parsing
dashboard creation in Kibana
basic detection engineering
attack simulation
security monitoring workflows

🎯 Objectives:
The main goals of this project were:

Deploy the ELK Stack using Docker
Configure Logstash pipelines for log ingestion
Forward logs from a macOS host
Simulate suspicious activity from Kali Linux
Detect attack patterns such as:
credential stuffing
brute-force behavior
suspicious DNS activity
Build interactive dashboards in Kibana

🖥️ Lab Environment:
This project was implemented in a small lab setup using the following environment:

Component Specification
Host System macOS
ELK Deployment Docker Desktop
ELK Version 8.x
Attacker Machine Kali Linux VM
Log Source macOS system/application logs
Memory Allocation 8 GB for Docker
Storage 50 GB free space

🏗️ Architecture Overview:
The overall setup was designed to simulate a basic security monitoring workflow.

Kali Linux (Attacker)
|
| Simulated Attack Traffic
v
macOS Host (Docker Desktop + Log Sources)
├── Elasticsearch
├── Logstash
├── Kibana
└── Filebeat / Native Log Forwarding

This setup allowed me to generate both normal and malicious traffic, send logs into the ELK pipeline, and monitor the resulting events visually in Kibana.

🛠️ Tools and Technologies Used
Tool Purpose
Elasticsearch Centralized log storage and search
Logstash Log ingestion and processing
Kibana Visualization and dashboards
Docker Containerized ELK deployment
Filebeat Lightweight log shipper
Kali Linux Attack simulation
macOS Host system and log source
🐳 Deploying ELK Stack with Docker
1) Verify Docker Installation:
Before starting, I verified that Docker was installed correctly:
docker --version
docker compose version

2) Create the Project Directory:
mkdir elk-stack && cd elk-stack
nano docker-compose.yml

3) Docker Compose Configuration:
I used the following docker-compose.yml file to deploy Elasticsearch, Logstash, and Kibana.

version: '3.8'
services:
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
container_name: elasticsearch
environment:
- discovery.type=single-node
- ES_JAVA_OPTS=-Xms2g -Xmx2g
- xpack.security.enabled=false
ports:
- "9200:9200"
- "9300:9300"
volumes:
- elasticsearch_data:/usr/share/elasticsearch/data
networks:
- elk-network

logstash:
image: docker.elastic.co/logstash/logstash:8.11.0
container_name: logstash
volumes:
- ./logstash/pipeline:/usr/share/logstash/pipeline
- ./logstash/config:/usr/share/logstash/config
ports:
- "5000:5000"
- "5044:5044"
- "9600:9600"
depends_on:
- elasticsearch
networks:
- elk-network

kibana:
image: docker.elastic.co/kibana/kibana:8.11.0
container_name: kibana
environment:
- ELASTICSEARCH_HOSTS=http://elasticsearch:9200
ports:
- "5601:5601"
depends_on:
- elasticsearch
networks:
- elk-network

volumes:
elasticsearch_data:
driver: local

networks:
elk-network:
driver: bridge

Note: For lab simplicity, xpack.security.enabled=false was used. In a production environment, authentication, TLS, and role-based access control should always be enabled.

4) Create the Logstash Pipeline:
mkdir -p logstash/pipeline
nano logstash/pipeline/logstash.conf

I used the following Logstash configuration:

input {
tcp {
port => 5000
codec => json
type => "application_logs"
}

udp {
port => 5001
type => "syslog"
}

beats {
port => 5044
}
}

filter {
date {
match => ["timestamp", "ISO8601"]
target => "@timestamp"
}

grok {
match => { "message" => "%{IP:client_ip}" }
}

if [message] =~ /login.*failed/ {
mutate {
add_tag => ["credential_stuffing_candidate"]
}
}

if [message] =~ /dns.*query/ {
mutate {
add_tag => ["dns_activity"]
}
}

geoip {
source => "client_ip"
target => "geo"
}
}

output {
elasticsearch {
hosts => ["elasticsearch:9200"]
index => "logs-%{+YYYY.MM.dd}"
}

stdout {
codec => rubydebug
}
}

This pipeline was used to:

parse timestamps
extract IP addresses
tag suspicious login failures
identify DNS-related activity
enrich IP addresses with GeoIP data

5) Start the ELK Stack:
docker compose up -d

To verify everything was running correctly:

 docker ps

Expected containers:
Elasticsearch
Logstash
Kibana

6) Verify Services:
Check Elasticsearch:

  curl http://localhost:9200

Then open Kibana in the browser:

  http://localhost:5601

📥 Collecting Logs from macOS
1) Install Filebeat (Optional)

To forward logs more efficiently, Filebeat can be installed:

   brew install elastic/tap/filebeat-full

2) Configure Filebeat

  Edit the Filebeat configuration:

     nano /usr/local/etc/filebeat/filebeat.yml

Use the following configuration:

filebeat.inputs:

type: log enabled: true paths:
- /var/log/system.log
- /var/log/apache2/*.log
- /var/log/nginx/*.log

output.logstash:
hosts: ["localhost:5044"]

3) Start Filebeat
sudo filebeat -e -c /usr/local/etc/filebeat/filebeat.yml
4) Send a Test Log

To confirm that logs were reaching Logstash correctly:

echo '{"timestamp":"2024-01-15T10:30:00","message":"login failed for user admin from 192.168.1.100"}' | nc localhost 5000

If everything is working correctly, the event should appear in Elasticsearch and later in Kibana.

🎯 Attack Simulation

To test the detection pipeline, I simulated suspicious behavior from a Kali Linux machine and from generated log events.

1) Credential Stuffing / Failed Login Simulation

A simple way to simulate repeated failed login events:

for i in {1..100}; do
echo "{\"timestamp\":\"$(date -Is)\",\"message\":\"login failed for user test$i from 192.168.1.$((RANDOM % 255))\"}" | nc localhost 5000
done

This creates a spike of failed authentication events that can be detected and visualized.

2) Simulated Brute Force Testing

For brute-force style testing, tools such as Hydra can be used in a lab environment:

sudo apt install hydra -y

Example concept:

hydra -L users.txt -P passwords.txt http-post-form "/login:user=^USER^&pass=^PASS^:F=incorrect"

This was used only in a controlled lab environment for detection testing.

3) Suspicious DNS Activity Simulation

To simulate suspicious DNS-style logs:

for i in {1..50}; do
random_string=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
echo "{\"timestamp\":\"$(date -Is)\",\"message\":\"dns query for $random_string.malicious.com\"}" | nc localhost 5000
done

This helped simulate basic indicators often associated with suspicious DNS activity.

Important: This is not full DNS tunneling detection, but rather a lab-based approximation using long/suspicious DNS query patterns.

🧠 Threat Detection Logic

This project focused on detecting suspicious activity using simple but useful logic.

Credential Stuffing Detection

Credential stuffing behavior was approximated by detecting a high volume of failed login attempts in a short period of time.

Detection idea:
repeated "login failed" events
clustering by source IP
spikes over time

Example detection query:

{
"name": "Credential Stuffing Detection",
"index": "logs-*",
"query": {
"bool": {
"must": [
{ "match": { "message": "login failed" } }
],
"filter": [
{ "range": { "@timestamp": { "gte": "now-5m" } } }
]
}
}
}
Suspicious DNS Activity Detection

Suspicious DNS activity was simulated by generating log entries containing long, random-looking subdomains.

Detection idea:
DNS query logs
unusually long domain strings
repeated unusual query behavior

Example detection logic:

{
"name": "Suspicious DNS Activity",
"index": "logs-*",
"query": {
"bool": {
"must": [
{ "match": { "message": "dns query" } }
]
}
}
}
📊 Building the Kibana Dashboard

Once logs were being ingested successfully, I created a Security Monitoring Dashboard in Kibana.

1) Create an Index Pattern

In Kibana:

Go to Stack Management
Open Index Patterns / Data Views
Create:
logs-*
Select:
@timestamp

as the time field.

2) Create Visualizations

I built the following visualizations:

Failed Logins Over Time
Type: Line Chart
X-axis: @timestamp
Y-axis: count of failed login events
Top Attack Sources
Type: Horizontal Bar Chart
Bucket: client_ip
Event Types Distribution
Type: Pie Chart
Bucket: message.keyword
Geographic Source Distribution
Type: Map / Coordinate Visualization
Based on GeoIP data
3) Dashboard Layout

The dashboard was designed like this:

┌─────────────────────────────────────────────────────────────┐
│ Security Monitoring Dashboard │
├────────────────────────────-─┬──────────────────────────────┤
│ Failed Logins Over Time │ Top Attack Sources │
│ [Line Chart] │ [Bar Chart] │
├─────────────────────────────-┼──────────────────────────────┤
│ Event Types Distribution │ Geographic Distribution │
│ [Pie Chart] │ [Map] │
├─────────────────────────────-┴──────────────────────────────┤
│ Recent Alerts / Log Table │
└─────────────────────────────────────────────────────────────┘

This dashboard made it much easier to quickly identify spikes, suspicious IPs, and recurring event types.

🧪 Testing and Validation

To validate the setup, I performed multiple tests.

1) Verify Elasticsearch Indices
curl http://localhost:9200/_cat/indices
2) Search Ingested Logs
curl -X GET "http://localhost:9200/logs-*/_search?pretty"
3) Confirm Detection Visibility in Kibana

Expected observations:

spike in failed logins
suspicious DNS-related events visible
top source IPs shown in charts
logs searchable through Kibana Discover

📈 Detection Results:
The dashboard successfully surfaced suspicious behavior during testing.

Attack / Activity Detection Method Status
Credential Stuffing Failed login spike ✅ Detected
Brute-Force Activity

Repeated authentication attempts ✅ Detected
Suspicious DNS Activity Long/random DNS query patterns ✅ Detected
Suspicious Visibility GeoIP enrichment + IP grouping ✅ Identified

🛡️ Incident Response Workflow:
Once suspicious activity was identified, the following investigation workflow was used.

1) Investigate in Kibana

Example query:

client_ip: "192.168.1.100"

Time-based filtering:

@timestamp: [now-1h TO now]

Specific failed login investigation:

message: "login failed" AND client_ip: "192.168.1.100"

2) Correlate with Other Logs
client_ip: "192.168.1.100" OR source_ip: "192.168.1.100"

This helped determine whether the same IP appeared across multiple suspicious events.

3) Example Response Actions
block suspicious IPs
investigate repeated authentication failures
document findings
escalate as needed

Example ticket format:

{
"title": "Potential Credential Stuffing Activity",
"source_ip": "192.168.1.100",
"timestamp": "2024-01-15T10:30:00",
"severity": "HIGH",
"recommendation": "Investigate source IP and implement rate limiting"
}

⚠️ Challenges Faced:
A few practical challenges came up during the project:

  Challenge                           Solution

Docker memory allocation issues Increased Docker memory to 8 GB
Logstash pipeline errors Validated pipeline configuration carefully
Kibana connectivity issues Verified Docker networking and service dependencies
Noisy or weak detections Tuned detection logic and thresholds
Inconsistent log formats Used parsing and extraction rules

These issues were useful because they reflected the kind of troubleshooting that often happens in real-world deployments.

📌 Limitations:
This lab setup was useful for learning, but it still has limitations:

i. single-node Elasticsearch only
ii. not production-scale
iii. basic rule logic
iv. no automated response
v. detection quality depends on available logs
vi. security disabled for lab simplicity

This project was built for hands-on learning and detection workflow understanding, not as a production-ready SIEM.

🚀 Future Improvements:
There are several ways this project could be improved:

i. integrate Elastic Agent
ii. enable TLS and authentication
iii. add Slack / email alerting
iv. build custom SOC dashboards
v. use Elastic Security detection rules
vi. add machine learning-based anomaly detection
vii. expand to a multi-node ELK cluster

📚 Key Learning Outcomes:
This project helped me build practical experience in:

i. deploying the ELK Stack with Docker
ii. configuring Logstash pipelines
iii. forwarding and parsing logs
iv. building Kibana dashboards
v. writing simple threat detection logic
vi. simulating suspicious security events
vii. performing basic log-based threat hunting

🎯 Conclusion:
This project helped me understand how centralized log collection and visualization can support security monitoring and threat detection in a practical way.

By building an ELK Stack lab using Docker, simulating suspicious activity, and creating a security-focused dashboard in Kibana, I was able to experience a simplified SIEM workflow end-to-end — from log ingestion to detection to investigation.

For anyone learning cybersecurity, blue teaming, SOC analysis, or SIEM fundamentals, this is a very valuable hands-on project.

🔗 References:
i. Elastic Stack Documentation
ii. Elasticsearch Docker Guide
iii. Logstash Pipeline Documentation
iv. Kibana Dashboard Documentation
v. OWASP Credential Stuffing Guidance

Building a Network Intrusion Detection System (NIDS) with Snort on Linux: A Complete Hands-on Guide

Dipesh Kumar — Fri, 03 Apr 2026 08:17:54 +0000

Introduction: In today’s rapidly evolving digital environment, organizations face a growing number of cyber threats such as port scans, brute-force attacks, denial-of-service (DoS) attacks, and web-based exploitation attempts. Detecting these threats in real time is essential for maintaining network security and system availability.

This project focuses on the design and implementation of a Network Intrusion Detection System (NIDS) using Snort and Wireshark on Ubuntu Linux. The main goal of this project was to monitor network traffic, identify suspicious activities, and generate alerts based on custom-defined detection rules.

Through this implementation, I gained hands-on experience in network traffic analysis, intrusion detection, Snort rule writing, and basic incident response mechanisms.

Objectives: The main objectives of this project were:

To install and configure Snort IDS on Ubuntu Linux
To monitor live network traffic for malicious activity
To create and test custom Snort rules
To detect common network attacks in a lab environment
To analyze suspicious packets using Wireshark
To perform basic incident response actions after attack detection

Lab Environment: The project was implemented in a controlled lab environment with the following specifications:

Component Specification
Operating System Ubuntu 22.04 LTS
RAM 4 GB
CPU 2 Cores
Storage 20 GB Free Space
IDS Tool Snort
Packet Analyzer Wireshark

Project Architecture: The architecture of this project consists of an attacking system, a target monitoring system, and traffic inspection tools.

Attacker Machine (Kali Linux / Test System)
|
| (ICMP / TCP / HTTP / SSH Attack Traffic)
v
Target Ubuntu Monitoring System
├── Snort IDS
├── Custom Detection Rules
├── Wireshark Packet Analysis
├── iptables Firewall
└── fail2ban (SSH Protection)

This setup allowed me to generate controlled attack traffic and verify whether the intrusion detection system was able to identify suspicious behavior successfully.

Tools and Technologies Used: The following tools and technologies were used during this project:

Snort – for real-time intrusion detection
Wireshark – for packet capture and traffic analysis
Ubuntu Linux – as the deployment environment
iptables – for firewall-based blocking
fail2ban – for brute-force mitigation
Nmap – for port scan simulation
Hydra – for SSH brute-force simulation
ping / flood traffic – for ICMP flood testing
sqlmap – for SQL injection testing

Installation and Configuration:
6.1 System Update:
The system was first updated to ensure all packages were current.

cmd: sudo apt update && sudo apt upgrade -y`

6.2 Install Required Dependencies:
The necessary libraries and development tools required for Snort were installed using the following command:

cmd: sudo apt install -y build-essential libpcap-dev libpcre3-dev \
cmd: libdumbnet-dev bison flex libnghttp2-dev zlib1g-dev \
cmd: libssl-dev libnetfilter-queue-dev libdnet-dev

6.3 Install Snort:
cmd: Snort was installed and verified using:
cmd: sudo apt install snort -y
cmd: snort -V

This step confirmed that Snort was successfully installed and ready for configuration.

6.4 Install Wireshark:
Wireshark was installed for network traffic capture and packet inspection.

cmd: sudo apt install wireshark -y
cmd: sudo dpkg-reconfigure wireshark-common
cmd: sudo usermod -a -G wireshark $USER

Wireshark was used throughout the project to visually inspect suspicious packets and confirm Snort alerts.

Snort Rule Configuration:
7.1 Understanding Snort Rule Structure:
Each Snort rule consists of two main parts:

Rule Header → Defines traffic conditions
Rule Options → Defines alert message, classification, SID, thresholds, and payload matching

General Snort rule format:

 [action] [protocol] [source IP] [source port] -> [destination IP] [destination port] (options)

7.2 Creating a Custom Rule File:
A custom rule file was created to store locally written detection rules.

  cmd: sudo nano /etc/snort/local.rules

Custom Detection Rules: The following custom Snort rules were created to detect common attack patterns.

8.1 ICMP Flood Detection (DoS Attack):
This rule detects excessive ICMP echo requests from the same source within a short time window.

alert icmp $EXTERNAL_NET any -> $HOME_NET any (
    msg:"ICMP FLOOD ATTACK DETECTED";
    threshold:type both, track by_src, count 100, seconds 5;
    classtype:attempted-dos;
    sid:1000001;
    rev:1;
)

Purpose:
  Detects possible ICMP flood or ping flood attacks.

8.2 Nmap SYN Port Scan Detection:
This rule detects rapid SYN packets sent to the monitored host, which may indicate an Nmap SYN scan.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (
    msg:"NMAP SYN SCAN DETECTED";
    flags:S;
    threshold:type both, track by_src, count 20, seconds 10;
    classtype:attempted-recon;
    sid:1000004;
    rev:1;
)

Purpose:
  Detects suspicious reconnaissance activity such as port scanning.

8.3 SSH Brute Force Detection:
This rule monitors repeated connection attempts targeting the SSH service.

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (
    msg:"SSH BRUTE FORCE ATTEMPT";
    flow:to_server,established;
    detection_filter:track by_src, count 10, seconds 60;
    classtype:attempted-recon;
    sid:1000009;
    rev:1;
)

Purpose:
   Detects repeated SSH authentication attempts from a single source IP.

8.4 SQL Injection Detection:
This rule attempts to identify common SQL injection patterns in HTTP requests.

alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (
    msg:"SQL INJECTION ATTEMPT";
    flow:to_server,established;
    content:"union"; http_uri; nocase;
    content:"select"; http_uri; nocase;
    classtype:web-application-attack;
    sid:1000012;
    rev:2;
)

Purpose:
  Detects simple SQL injection attempts in web traffic.

Note: This rule was implemented for educational demonstration purposes and would require more tuning for real-world production environments.

8.5 Cross-Site Scripting (XSS) Detection:
This rule detects possible XSS payloads in HTTP requests.

alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (
    msg:"CROSS-SITE SCRIPTING (XSS) ATTEMPT";
    flow:to_server,established;
    content:"<script"; http_uri; nocase;
    pcre:"/(\<script|\%3Cscript)/Ui";
    classtype:web-application-attack;
    sid:1000013;
    rev:2;
)

Purpose:
  Detects simple reflected or encoded XSS payload attempts.

Including Custom Rules in Snort Configuration:
The local rule file was included in the Snort configuration file:

cmd: sudo nano /etc/snort/snort.conf

The following line was added:

 include $RULE_PATH/local.rules

This allowed Snort to load the custom detection rules during execution.

Running Snort in IDS Mode:
Snort was executed in IDS mode to inspect live traffic and generate alerts in real time.

cmd: sudo snort -A console -q -c /etc/snort/snort.conf -i eth0
Explanation:
-A console → Displays alerts in terminal
-q → Quiet mode
-c → Specifies configuration file
-i eth0 → Selects the network interface

Attack Simulation and Testing:
To verify the effectiveness of the intrusion detection system, several attack simulations were performed in a controlled environment.

11.1 Port Scan Detection Test:
A SYN scan was launched using Nmap:

 cmd: nmap -sS [TARGET_IP]
Expected Snort Alert
 [**] [1:1000004:1] NMAP SYN SCAN DETECTED [**]
 [Priority: 3]
 04/03 14:30:12 192.168.1.100 -> 192.168.1.10

11.2 ICMP Flood Test:
An ICMP flood was generated using:

  cmd: ping -f [TARGET_IP]
 Expected Outcome:
    Snort generated repeated alerts once the threshold was crossed.

11.3 SSH Brute Force Test:
A brute-force attempt was simulated using Hydra:

 cmd: hydra -l root -P pass.txt ssh://[TARGET_IP]
 Expected Outcome:
    Snort detected repeated SSH connection attempts from the attacking source.

11.4 SQL Injection Test:
SQL injection traffic was simulated using:

   cmd: sqlmap -u "http://[TARGET_IP]/page?id=1"
 Expected Outcome:
   Snort generated an alert when matching suspicious SQL keywords were identified.

Packet Analysis with Wireshark:
Wireshark was used to inspect and validate the traffic that triggered Snort alerts.

Traffic Analysis Activities Performed
Observed SYN packets during Nmap scanning
Monitored repeated ICMP echo requests during flood testing
Analyzed SSH traffic patterns during brute-force attempts
Inspected suspicious HTTP requests containing SQLi/XSS payloads

Using Wireshark alongside Snort improved visibility into the exact packet behavior and helped confirm whether alerts were legitimate or false positives.

Detection Results: The custom intrusion detection system successfully identified multiple attack patterns during testing.

Attack Type Command Used Detection Status
ICMP Flood ping -f target Detected
Port Scan nmap -sS target Detected
SSH Brute Force hydra -l root -P pass.txt ssh://target Detected
SQL Injection sqlmap -u "http://target/page?id=1" Detected

The results demonstrate that Snort, when configured with custom rules, can effectively detect suspicious traffic patterns in a controlled lab setup.

Incident Response Actions Taken:
After attack detection, basic incident response measures were applied to reduce further malicious activity.

14.1 Blocking Malicious IP Addresses:
The attacking IP was blocked using iptables:
```
  cmd: sudo iptables -A INPUT -s 192.168.1.100 -j DROP
```
14.2 Rate Limiting ICMP Requests:
To mitigate ICMP flood attacks, rate limiting was applied:
```
    cmd: sudo iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT
```
14.3 Enabling SSH Protection with fail2ban:
fail2ban was installed and enabled to reduce SSH brute-force attempts.
```
       cmd: sudo apt install fail2ban -y
       cmd: sudo systemctl enable fail2ban
       cmd: sudo systemctl start fail2ban
```
14.4 Viewing Firewall Rules:
Firewall rules were verified using:
```
        cmd: sudo iptables -L -n
```
Challenges Faced:
During the implementation of this project, several practical challenges were encountered:

Configuring Snort correctly on Ubuntu required careful attention to rule paths and interface settings
Some initial rules generated noisy alerts and required threshold tuning
Application-layer attacks such as SQL injection and XSS were more difficult to detect reliably than network-layer attacks
Testing needed to be performed in a controlled environment to avoid accidental impact on normal traffic

These challenges helped improve my understanding of real-world intrusion detection limitations and the importance of tuning.

Limitations: Although the project was successful, it also had some limitations:

The IDS was tested only in a small lab environment
Detection logic for web attacks was basic and signature-based
Some attacks may evade detection through encoding or obfuscation
The system currently focuses mainly on detection, not full automated prevention
Performance under high enterprise-level traffic was not evaluated

These limitations highlight areas for future improvement.

Future Improvements: This project can be further enhanced in several ways:

Integrate ELK Stack for centralized logging and visualization
Add Zeek for deeper protocol and behavioral analysis
Automate response actions using Python scripts
Configure email or Slack alerts for real-time notifications
Improve rule quality using more advanced Snort signatures
Store and correlate alerts for better incident investigation

Key Learning Outcomes: This project provided strong practical exposure to several core cybersecurity concepts.

Skills Gained
Hands-on experience with Snort IDS
Network traffic analysis using Wireshark
Writing and tuning custom detection rules
Understanding attack patterns such as:
Port scanning
ICMP flood attacks
SSH brute-force attempts
Basic web attack payloads
Performing basic incident response
Applying layered defense concepts using IDS + firewall + fail2ban

Conclusion: This project demonstrated how a Network Intrusion Detection System (NIDS) can be designed and implemented using Snort and Wireshark in a Linux environment.

By configuring Snort, writing custom detection rules, simulating attack scenarios, analyzing traffic, and applying response measures, this project provided practical exposure to real-world network defense techniques. It also emphasized the importance of traffic visibility, rule tuning, and defense-in-depth in cybersecurity operations.

Overall, this project significantly improved my understanding of network monitoring, threat detection, and incident response, and it served as a valuable hands-on learning experience in cybersecurity.

References: i. Snort Official Documentation ii. Wireshark Official Documentation iii. Nmap Documentation iv. Hydra Tool Documentation v. sqlmap Documentation