Practical Journal

To design and implement an intrusion detection system with a lightweight web application firewall that inspects incoming HTTP requests, detects common web attacks using signature-based rules and behavioural analysis, decides an action (allow, monitor, block or rate-limit), logs every decision and raises alerts for high-risk events.

• IDS vs WAF — an IDS observes and reports; a WAF sits inline and can reject the request. SentinelShield does both: it logs everything and blocks when confidence is high.
• Signature detection — regular expressions match known malicious patterns (e.g. ' OR 1=1, <script>, ../).
• Normalisation — payloads are URL-decoded twice, lower-cased and whitespace-collapsed so encoded attacks cannot evade the rules.
• Behavioural analysis — per-IP counters detect scanning, bursts and repeated failures even when no signature matches.
• Rate limiting — a fixed window counter limits requests per IP and temporarily blocks abusive sources.

Client / attacker
      |
      v
[ Request Inspection ]  normalise URL, query, body, headers
      |
      v
[ Rule Engine ]  regex signatures  ->  attack type + confidence
      |
      v
[ Behaviour Analysis ]  per-IP counters, scanning, bursts
      |
      v
[ Rate Limiter ]  window counter -> RATE_LIMIT / temp block
      |
      v
[ Decision Engine ]  ALLOW | MONITOR | BLOCK | RATE_LIMIT
      |                 |
      |                 +--> [ Logging ] security_events
      |                 +--> [ Alerts ]  high / critical
      v
[ Mock Test App ]  echoes the request, never executes it

1. Receive the request and extract method, endpoint, query, body and user agent.
2. Normalise every surface (double URL decode, lower-case, collapse whitespace).
3. Load enabled rules from the signature database.
4. Match each rule; keep the highest-confidence hit and its severity.
5. Update per-IP counters and compute behaviour metrics for the current window.
6. If the request count exceeds the limit, return RATE_LIMIT and block the IP temporarily.
7. Otherwise map confidence to a decision: ≥ BLOCK_CONFIDENCE → BLOCK, ≥ MONITOR_CONFIDENCE → MONITOR, else ALLOW.
8. Sanitise the payload and write the event to the log.
9. Raise an alert when the decision is BLOCK or the severity is CRITICAL.
10. Forward allowed requests to the mock application and return its response.

• Clean requests pass with confidence 0 and are logged as ALLOW.
• Classic SQLi and XSS payloads match with high confidence and are blocked immediately.
• Double-encoded payloads are only caught because of the normalisation step.
• Scanner user agents and burst traffic are caught by behaviour analysis, not signatures.
• Every blocked or critical event produces an alert in the alert queue.

A layered approach — normalisation, signatures, behaviour analysis and rate limiting feeding a single decision engine — detects the common OWASP-style web attacks reliably while keeping false positives low on legitimate traffic. The measured accuracy, precision, recall and F1 score for the practical test suite are shown on the Reports page. Signature detection alone is not sufficient; behavioural signals are what catch reconnaissance and abuse.