Log Sentinel: A Lightweight Behavioural Threat-Hunting Tool for Web Attack Detection by IRJET Journal

Log Sentinel: A Lightweight Behavioural Threat-Hunting Tool for Web Attack Detection

Dhanraj Gangnaik1 , Bala Krishna Sanneboyain2 , Aditya Kale3 , Dr. Sandeep Kulkarni

1,2,3

School of Engineering, Ajeenkya D Y Patil University, Pune

4 Department of Computer Science, Ajeenkya D Y Patil University, Pune, Maharashtra, India

Abstract - Web services face continuous threats from attacks such as SQL injection, cross-site scripting, path traversal, and command injection [18]. Traditional approaches create a difficult operational trade-off: simple signature-based systems lack the sophistication to detect evasive variants, while heavyweight SIEM platforms demand significant infrastructure and sustained operational overhead [19]. This paper introduces Log Sentinel, a lightweight behavioural threat-hunting framework designed for real-time web attack detection on access logs. The system bridges this gap by combining deterministic rule matching with per-IP behavioural analytics to identify both explicit attack indicators and suspicious traffic patterns. It continuously monitors Nginx-style logs, applies transparent URL normalization, and processes events through a staged detection pipeline. Key architectural contributions include a hybrid detection layer that fuses signature-based rules with temporal behavioural features such as endpoint diversity, error-rate shifts, and user-agent churn, an incident-correlation mechanism that groups related alerts into campaign-level views to reduce analyst fatigue, and a user-friendly Portal interface built with FastAPI and Next.js. Integration with observability infrastructure via Prometheus and Grafana enables operational monitoring. Evaluation results from two experiments demonstrate the system’s effectiveness: a controlled benchmark with 280 records achieved zero false positives and sub-millisecond latency, while a live containerized test with 125 generated requests achieved precision of 0.9394, recall of 0.4429, and F1-score of 0.6019. The framework exhibits a precision-first profile suitable for low-noise alert triage. Log Sentinel provides small teams with an interpretable, maintainable solution for continuous threat hunting without complex infrastructure.

Key Words: Threat Hunting, Web Log Monitoring, Behavioural Detection, Access Log Analysis, Intrusion Detection, Attack Correlation, Anomaly Detection, Risk Scoring, Security Operations

1. INTRODUCTION

Public-facing applications operate in a continuously scanned environment. Commodity reconnaissance tools enumerate routes at scale, while patient attackers probe payload variants over longer windows to avoid obvious patterns [17]. Both behaviours leave measurable traces in access logs: repeated requests to rare paths, bursts of client errors, and structured requestrhythmsthatdifferfromtypicaluseractivity.Inpractice,however,manyteamsstillusetheselogsprimarilyforpostincidentforensicsratherthancontinuousdetection[20].

This gap is largely operational. Signature detectors are computationally efficient and interpretable, yet brittle against encoding tricks, token fragmentation, and syntax mutation. At the opposite end, SIEM-centric platforms offer broad correlationbutrequireinfrastructure,tuning,andanalystcapacitythatsmallerenvironmentsrarelyhaveinabundance[12], [15].Theresultisarecurringtoolinggap:systemsareeithertoonarrowtobedependableortooheavytomaintain.

Behavioural monitoring offers a practical middle path. Rather than relying only on payload text in a single request, it evaluates source behaviour over time: endpoint diversity, error-rate shifts, burst intensity, and user-agent churn. These temporal signatures often remain visible even when payload strings are obfuscated. Crucially, this approach can remain lightweightandinterpretablewithoutintroducingcomplexmodel-trainingpipelines[19].

Log Sentinel is built around this design choice [17]. It ingests Nginx-style logs as a stream, applies transparent normalizationanddetectionstages,andemitsprioritizedalertswithexplicitevidence.Thispapercontributes:(1)amodular hybriddetectorthatfusessignatureswithper-IPbehaviouralstate,(2)anincident-correlationlayerthatconvertsalertbursts into campaign-level context, and (3) a reproducible evaluation workflow that reports both accuracy and runtime characteristics.Theremainingsectionspresentscope,relatedwork,methodology,implementationdetails,andresults.

Volume: 13 Issue: 04 | Apr 2026 www.irjet.net

2. PROBLEM STATEMENT

-0056

-ISSN: 2395-0072

Thisworktargetsweb-exposedservicesthatalreadygeneratestructuredaccesslogs(forexample,NginxorApacheformats). TheassumedadversarycansendarbitraryHTTPrequestsoverthenetwork butdoesnotcontrol thehost.Defensively,the operatorseeksnear-real-timevisibilityusingonlyexistinglogtelemetry,withoutintroducingSIEM-scaleinfrastructure.The keyattackerbehavioursinscopearesummarizedbelow.

2.1 Adversary Capabilities

 Reconnaissance and Enumeration: Attackers may perform directory and endpoint discovery using automated scanners, producing high volumes of requests to non-existent resources (404 spikes) and probing common administrativepaths(e.g., /admin, /login, /. git). Theymayalsoattemptparameterdiscoverybyvaryingquerykeys andpathssystematically[17].

 Payload Injection: Attackers attempt to inject SQLi, XSS, command injection, and traversal payloads into query strings,URLpaths,andheaders.Payloadsmaybeencoded(URLencoding,mixedcase,commentinsertion)toevade simplepatternchecks[18].

 Credential Attacks: Adversaries may execute credential stuffing and brute-force attempts against authentication endpoints,observableviarepeatedPOSTstologinforms,abnormalsessionbehaviour,orhigherrorrates.

 Evasion: Attackersmayrotateuseragents,distributescanningacrossmultipleIPs,introducedelaystomimicbenign traffic,orusedecoyrequeststoreducedetectionconfidence[17].

2.2 Defender Assumptions and Scope

ThedefendercanreadaccesslogsandruntheLogSentinelengineonthesamehostoron anearbymonitoringnode.The designdoesnotrequiredeeppacketinspection,host-basedEDRinstrumentation,orTLSinterception.Detectionisdriven by request metadata (IP, method, path, query, status code, user agent, timestamp) and temporal relationships across events[15].

2.3 Out-of-Scope

Theframeworkisintendedfordetectionandtriage,notattackprevention.Capabilitiesoutsidescopeincludeinspectionof encryptedpayloadcontentbeyondwhatislogged,insidermisusewithprivilegedaccess,andapplication-specificsemantic checks such as business-logic abuse detection. The system also does not attempt strong attribution; the objective is actionable,low-overheadalertingforresource-constrainedenvironments.

3. LITERATURE REVIEW

Intrusion detection research divides broadly into signature matching, statistical anomaly detection, and hybrid approaches. Rule-based systemshaveremainedthe mostwidelydeployed form becausetheir outputis easyto interpret andthey perform reliablyagainstdocumentedthreats. Thecore weaknessis brittleness:a payloadthat evades a pattern throughencoding,commentinjection,orcasevariationgoesundetected,andkeepingrulefilescurrentdemandsongoing effort[11],[12],[14].

Anomaly detection tackles this differently by modelling normal traffic and flagging deviations. Machine-learning classifiers have been applied extensively to this problem and often show strong results in controlled evaluations. In practice,buildingandmaintainingsuch asystemisharder:labelledtrainingdataisscarce,normaltrafficshiftsovertime requiring regular retraining, and the model’s decision is difficult to explain to an analyst who needs to respond quickly [13].Computeandmemoryrequirementsalsotendtoexceedwhatsmalldeploymentscanprovide.

Log-based detection occupies a useful middle ground because access logs already exist as a by-product of running any web service. Tools that scan log lines for known bad paths, brute-force patterns, or injection strings can be deployed without changes to network topology or application code. The practical problem is alert noise: benign crawlers, health checkers, and misconfigured clients trigger the same signatures as real attackers, so purely rule-driven log scanners can generatemorenoisethansignalunlesscorrelationisapplied[15].

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 04 | Apr 2026 www.irjet.net p-ISSN: 2395-0072

Log Sentinel sits in the hybrid category. It pairs explicit pattern rules with per-IP behavioural counters so that attacks whichevadepatternmatchingmaystilltriggerabehaviouralalert,andviceversa.Theemphasisonlog-onlyanalysis,zero external dependencies, and a sub-millisecond event processing budget distinguishes it from tools that require dedicated agents,persistentdatabases,orcloud-basedthreatfeeds.

3.1 Research Gap and Design Rationale

Priorworkestablishesthatsignaturesystemsareinterpretableandoperationallytrusted,whileanomalysystemsimprove variant detection but often add training, maintenance, and explainability burden [13], [14]. In practical small-team deployments, this creates a recurring gap: available tools are either too narrow (single-request pattern scanners) or too heavy (full SIEM plus model ops). Existing literature discusses this trade-off, but fewer implementations demonstrate a reproduciblemiddlepathwithexplicitanalyst-facingevidenceandresourceusagelowenoughforedgedeploymentonthe monitoredhostitself.

Thisprojecttargetsthatspecificgapthroughfourdesignchoices.First,logparsingandnormalizationaredeterministic and transparent, avoiding hidden model state. Second, rule and behavioural signals are fused at alert time rather than replaced, preserving explainability while broadening coverage. Third, incident correlation is treated as a first-class component to reduce analyst fatigue in scanner-heavy conditions. Fourth, evaluation includes both a controlled labelled harness and a live containerized run, because strong metrics on synthetic-only traffic can overestimate real-world performance.

3.2 Research Questions

Theimplementationandexperimentsarestructuredaroundfourresearchquestions. RQ1: Canalog-onlyhybriddetector sustain real-time performance on commodity hardware? RQ2: Does combining behavioural counters with rules improve operationalusefulness(loweralertnoisewithacceptablerecall)overa rule-onlybaseline? RQ3: Whichattackcategories remain weakest under current pattern coverage, and are those gaps linked to known obfuscation families? RQ4: Does simpleincidentcorrelationmateriallyimprovetriagereadabilityinscanningscenarioscomparedwithrawalertstreams? TheresultsreportedinlatersectionsanswerRQ1directlyvialatency,throughput,andmemorymeasurements;answer RQ3through per-category recall;partiallyanswerRQ2 through the ablationtemplateandconservative precisionprofile; andanswerRQ4qualitativelythroughcampaign-levelincidentgrouping.Thesequestionsprovideaclearpathforiterative improvementwithoutchangingthesystem’slightweightdeploymentobjective.

4. METHODOLOGY

The framework is implemented as a staged pipeline with explicit boundaries between ingestion/parsing, detection, correlation,andpresentation.Thisseparationkeepscomponentsindependentlymaintainable:ruleupdatesdonotrequire changestocorrelationlogic,andvisualizationlayerscanbereplaced withoutalteringthedetectorcore.Thearchitecture now has four principal components: the Log Sentinel Engine, the Dashboard/Integration Service, the Portal Workspace (API + UI), and the Evaluation Harness. Figure 1 provides an end-to-end view of the layering and data flow across these components.

4.1 Log Sentinel Engine

The engine runs continuously, tails a configured Nginx access log, and processes new lines as they arrive. Each event is parsedintoanormalizedrecordcontainingsourceIP,HTTPmethod,requestpath/query,responsestatus,useragent,and timestamp.Beforerulematching,pathandqueryfieldsundergotworoundsofURLdecodingandcanonicalcleanup.This normalizationstep iscritical because manyattacksuse layered encodingto evade naivesubstringchecks;for example,a singledecodecanleave%2527unresolved,whereasaseconddecoderecoverstheapostropherelevanttoSQLirules. The normalized event then passes through three stages. Stage one applies compiled regex rule sets for SQLi, XSS, traversal, scanner, and command-injection indicators. Stage two updates per-IP behavioural windows and evaluates deviations such as endpoint bursts, sustained 4xx spikes, and request rates above local baseline. Stage three correlates temporallyrelatedalertsfromthesamesourceintoincidentrecords,producingcampaign-levelcontextinsteadofisolated eventfragments.

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 04 | Apr 2026 www.irjet.net p-ISSN: 2395-0072

4.2 Dashboard Service

A lightweight threaded HTTP service exposes detector output through a REST API. The endpoints /api/alerts, /api/stats, and /api/incidents provide evidence-backed alert and campaign views. Additional helper endpoints support dashboard composition and observability: /api/prometheus/query-range and /api/grafana/embed-preview. This layer enables both theclassicdashboardUIandthenewerPortalAPI/UIstacktoconsumethesameenricheddetectiondata.

4.3 Evaluation Harness

To support reproducible measurement, the project includes a self-contained benchmark harness. A dataset generator emitslabelledtrafficacrossfiveattackclassesplusbenignexamplesusingafixedseed,producingthesame280recordson each run. The evaluator then replays records through the live detector, compares predictions with labels, and reports accuracy, precision, recall, F1-score, per-event latency, throughput, and peak memory. Metrics persisted to a single report.json artifactforversion-to-versioncomparisonafterruleorthresholdupdates.

Phase 1: Ingestion and Detection Core

1)TrafficSources(reallogs+simulator)

2)NginxAccessLogCollection

3)SentinelEngine(parse, detect,score,dedup)

4)alerts.log(append-onlyevidencestore)

Phase 2: Analytics and API Surface

5)DashboardAPI:alerts,stats,incidents,Prometheus/Grafanahelpers

Phase 3: Portal and Observability Experience

6)PortalAPI(FastAPI+Postgres+Redis)

7)PortalUI(Next.jsanalystworkspace)

8) ObservabilityRoute: DashboardAPI → Prometheus → Grafana → PortalUI

9)LauncherLayer(Homarr):personalizedlinkstoPortal,Grafana,Prometheus,andSentineldashboard

Fig. 1. Layeredsystemarchitectureshowingcoreingestion/detection,analyticsAPIs,andportal-observabilitydelivery.

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 04 | Apr 2026 www.irjet.net p-ISSN: 2395-0072

4.4 Detection Methodology

Detectioncombinestwocomplementarysignalfamilies.PatternmatchingcapturesexplicitpayloadindicatorssuchasSQL tautologies, script fragments, and traversal tokens. Behavioural analysis captures source-level deviations over time that align with scanning or probing behaviour. Either signal alone is incomplete: rules may miss encoded or fragmented variants, while behavioural thresholds can fire during legitimate bursts. Fusing both signals improves practical coverage whilepreservinginterpretabilityandavoidingheavymodeldependency.Thefullnumberedprocessingsequenceisshown inFigure2.

4.5 Log Parsing and Normalization

Log lines are parsed with a regular expression matching the Nginx combined log format [2]. The extractor pulls out IP, timestamp,method,requestpath,statuscode,responsesize,referrer,anduseragent.Normalizationappliestwopassesof URLdecodingtothepathandquerystring,lowercasesthemwhereappropriate,andstripsredundantseparators.Double decodingisimportant:someattacksencodecharacterstwicesothatasingle-passdecoderstilloutputsanencodedstring thatbypassessubstringchecks.URIencodingconventionsfollowRFC3986[16].

2)Parsingandnormalization(doubleURLdecode)

3)Signatureanalysis(SQLi,XSS,traversal,CMDi,scanner)

4)Behaviouralanomalychecks(rate,404ratio,endpoint/UAnovelty)

5)Riskscoring+reason-codeenrichment+severityassignment

6)Duplicatesuppressionviaalertfingerprintwindow

7)IncidentcorrelationbysourceIPandtimewindow

8)Analystoutputs:APIs,Portalwidgets,andobservabilityembed

Fig. 2 Numbereddetectionpipelinefromnormalizedingestionthroughscoring,deduplication,andincident-level delivery.

4.6

Rule-Based Detection

Pattern files for each attack category live in rules/ and are loaded at startup as compiled, case-insensitive regular expressions. The five files cover SQLi, XSS, path traversal, command injection, and scanner user agents. Matching runs against both the raw and the decoded-normalized path, so payloads using encoded special characters are still caught. Whena patternmatches,theenginerecordsthematchedexpressionalongsidethe decodedrequestpath,givinganalysts directevidenceratherthanabarealertflag.Table1summarizesthecategory-levelruleinventoryusedintheevaluation.

Detection Flow: Hybrid Rule + Behavioural Pipeline

International

Volume: 13 Issue: 04 | Apr 2026 www.irjet.net p-ISSN: 2395-0072

4.7 Behavioural Anomaly Detection

ForeachsourceIP,theenginemaintainsasmallsetofcountersinsideaslidingtimewindow:requestsperminute,count ofdistinctendpointsaccessed,fractionof4xxresponses,andnumberofdistinctuseragentsseen.Whenametriccrossesa configurable threshold relative to that IP’s own rolling baseline, a behavioural alert is raised. Global thresholds are deliberately avoided because a busy crawler and a quiet end user have very different normal traffic volumes; a per-IP baseline comparison avoids the false positives that global limits produce [14]. The new-endpoint and new-user-agent detectors additionally require a minimum history count before they fire, preventing spurious alerts on an IP’s very first fewrequests.

TABLE -1:DETECTIONRULECATEGORIESANDPATTERNSUMMARY

Attack

SQL Injection sqli_patterns

XSS xss_patterns

33 UNIONSELECT,SELECT.*, FROM

35 <script>,onerror=,onload=

PathTraversal traversal_patterns 25 ../,%2e%2e%2f

CmdInjection cmdi_patterns 38 ;ls,whoami,$.*

Sec Scanner scanner_patterns 24 nikto,sqlmap

4.8 Risk Scoring and Correlation

Each alert is assigned a numeric risk score before emission. The base score depends on attack category, with command injection and SQLi rated higher than scanner detection. Context adjustments then add points: a doubly encoded path scoreshigher thana plaintextone;a spikein the requestingIP’srecentvolumeamplifiesthescore;a highanomalyratio addsafurtherincrement.Theformulausedis:

Factor

Patternconfidence(P)

TABLE -2: RISKSCORINGCOMPONENTWEIGHTS

0.50

Anomalyintensity(A) 0.30

Frequencyamplification (F) 0.20

Baseseverity byattackcategory (High:1.0,Medium: 0.6)

Behaviouralsignalstrength:ratespike,endpointburst, errorratio

Repeat alertcount withindeduplication window

where P represents pattern-match confidence, A represents anomaly intensity, and F captures frequency amplification (e.g.,repeatedtriggersinashortinterval).AlertsfromthesamesourceIPthatfallwithinaconfigurabletimewindoware then merged into a single incident record, replacing a flood of individual events with a campaign-level summary that shows attack type, peak score, and duration. To ensure stable behaviour across deployments, each component is normalized to a bounded interval before weighting: P ∈ [0, 1], A ∈ [0, 1], and F ∈ [0, 1]. The alert score is therefore constrained to RiskScore ∈ [0, 1] when (w1 +w2 +w3) = 1. The normalized form prevents one detector from dominating purely due to scale and makes threshold tuning interpretable: for example, raising the alert threshold from 0.60 to 0.70 hasconsistentmeaningindependentofrawfeatureranges.ThebaselinecomponentweightsarereportedinTable2.

Volume: 13 Issue: 04 | Apr 2026 www.irjet.net

4.9 Implementation

-0056

-ISSN: 2395-0072

The entire system is written in Python 3, chosen for broad availability and ease of modifying detection logic without a compilation step. The sentinel process uses a tail-like loop to ingest new log lines; each parsed record passes through detectionandisappendedto data/alerts.log inastructuredblockformatthatthedashboardserverreadswithoutneeding adatabasebackend. TheanalystworkspaceextendsthisPythoncorewithaFastAPI-basedPortalAPIandaNext.jsPortal UIforconfigurabledashboardworkflowsandembeddedvisualizations[4],[5]. Patternfilesareplaintextwithoneregex per line, so adding a new indicator means editing a text file rather than changing source code. Behavioural counters use bounded deque structures per IP so that memory footprint stays predictable as the number of tracked sources grows. A duplicate-suppressionwindowdeduplicates identical alert fingerprints withina configurableinterval,preventinga burst ofidenticalrequestsfromfloodingthealertlog.

Therepositorynowshipsamulti-profileDockerComposestack.Thecoreprofilerunssentinel+dashboard,Portaladds Postgres, Redis, Portal API, and Portal UI, observability enables Prometheus/Grafana dashboards, homarr enables the launcher layer, demo runs a synthetic target and traffic generator, and full launches all components together. The runstack wrappers for PowerShell, CMD, and Bash standardize profile lifecycle actions (up/down/logs/ps) and reduce operatorerrorduringdemonstrations.Thispackagingkeepsexperimentsreproduciblewhilesupportingbothlightweight andfull-stackanalystworkflows.Thecompletesourceispubliclyavailable[1],[6]–[10].

4.10 Computational Complexity and Resource Model

Per-event cost is intentionally bounded to support continuous operation. Let m denote the number of compiled regex patternsacrossallrulefiles,ℓthenormalizedrequest-stringlength,andkthenumberofmetricsintheper-IPbehavioural state. In the expected case, one event update has time cost O(mℓ + k): regex matching dominates, while counter updates are constant-time deque operations per metric. Incident correlation uses a bounded time window and hashable fingerprints,soinsertionsandduplicatechecksremainamortized O(1)peralert.

MemoryusagescaleswithactivesourceIPsinthecurrentwindowratherthanwithtotalhistoricaltraffic.IfnisactiveIP countandeachIPstoresboundeddequesofmaximumlengthbforkmetrics,statememory isO(nkb)withfixedconstants configured by policy. This bound explains why the measured peak memory remains low in the benchmark despite sustained event flow. Operationally, this makes capacity planning straightforward: increasing window size or per-IP historydepthtradesmemoryforsmootherbehaviouralbaselines.

4.11 Experimental Protocol

Allcontrolledexperimentsareexecutedwithdeterministicdatageneration,single-processsentinelexecution,andmetric capture in one report artifact. To reduce run-to-run variability, the benchmark is performed on an idle host with background workloadsminimized, and wall-clock measurementsare taken per record fromparse entry to alertdecision completion. Throughput is derived as total processed records divided by elapsed processing time, while latency is reportedasbothmeanandP95tocapturetailbehaviour.

For the live containerized experiment, labels are generated by the traffic simulator and post-hoc matched to alerts by timestampproximityandrequest-pathsimilarity.BecausenoglobalrequestidentifierispresentintheNginxlogline,this

TABLE -3: OVERALLEVALUATIONMETRICS

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 04 | Apr 2026 www.irjet.net p-ISSN: 2395-0072

mapping introduces a controlled uncertainty channel that is discussed explicitly in the validity section. Reporting both controlledandlivemetricsisthereforeessential:controlledrunsisolatedetectorbehaviourunderknownlabels,whilelive runsreflectpipelinerealitiesincludingtimingjitter,containerschedulingvariance,andpathcanonicalizationsideeffects.

TABLE -4: PER-TYPERECALL(CURRENTEVALUATIONRUN)

5. Results

Thissection reports quantitative outcomes from two evaluationsettings:(1) a controlledharness based ona 280-record labelleddataset(160attack, 120benign),and(2)a separatelivecontainerizedrun. Controlled metricsaretakendirectly from log-sentinel/evaluation/report.json generatedonthecurrentcodebase.

5.1 Reproducibility Setup

Thedatasetisgenerateddeterministicallyusingafixedrandomseed,sotheexactsame280recordsappearoneveryrun. Attack records span SQL injection, XSS, path traversal, command injection, and scanner user-agent patterns across five attack categories.Benign recordsuse realistic-looking paths suchas /home,/products?id=2,and /blog/1. Running python log-sentinel/evaluation/generate_dataset.py from the repository root writes the records to dataset.json. Running python log-sentinel/evaluation/evaluate.py thenprocesseseachlinethroughthelivesentinelengine,measuresper-recordlatency and memory, and writes all metrics to log-sentinel/evaluation/report.json. This setup enables reproducible comparison afterruleorthresholdupdates.

5.2 Detection Accuracy

Table 3 shows the aggregate results from log-sentinel/evaluation/report.json. Precision is 1.0, meaning no benign record was flagged as an attack. Recall is 0.5375, indicating that just over half of labelled attacks were detected. This precisionheavy profile is operationally desirable for reducing alert fatigue, while the recall gap highlights where signature and behavioural coverage should be expanded.Figure 3 visualizesthe sameaggregate metrics.Category-level performance is tabulatedinTable4andplottedinFigure4tohighlightrecallgaps.

Fig. 3. Overallclassificationmetricsfromthecurrentevaluationrun.

International Research Journal of Engineering and

Volume: 13 Issue: 04 | Apr 2026 www.irjet.net

-ISSN: 2395-0072

Fig. 4. Per-attack-typerecall,highlightingcoveragegapsinSQLi/XSS/CMDi.

TABLE -5:LIVECONTAINERIZEDEXPERIMENTMETRICS(125REQUESTS)

5.3 Live Containerized Experiment

Tovalidatebehaviouroutsidethesyntheticharness,weranaliveDocker-basedtestbedwithattack-trafficreplayandLog Sentinel tailing Nginx-style access logs using container orchestration for reproducibility [3]. These live-run results are reported from a separate experiment artifact and are intentionally presented alongside (not inside) the controlled evaluation/report.json benchmark file. The traffic generator emitted 125 labelled requests (70 attack, 55 benign) across SQLi,XSS,pathtraversal,commandinjection,andscanner-styleprobes.Alertswerematchedtolabelsusingtimestampand pathsimilaritybecauseasharedrequestidentifierisnotpresentinthelogpipeline.

Theresultingconfusion-matrixcountswereTP=31,FP=2,FN=39,andTN=53,yieldingprecision0.9394,recall0.4429,F1score 0.6019, and accuracy 0.6720. Relative to the controlled harness, precision remains strong while recall drops, suggestingthatthecurrentconfigurationisintentionallyconservativeundermixedlivetraffic andmaymisssomeevasive variants. Detailed live metrics are listed in Table 5, while direct controlled-vs-live comparisons are shown in Table 6 and Figure5.

TABLE -6: CONTROLLEDHARNESSVSLIVEEXPERIMENT

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 04 | Apr 2026 www.irjet.net p-ISSN: 2395-0072

5. Metriccomparisonbetweencontrolledharnessandlivecontainerizedevaluation.

6. Confusionmatrixcountsforthecontrolled280-recorddataset.

5.4 Latency and Throughput

Averageper-recordlatencywas0.283ms,witha95th-percentileof0.666ms,bothwithintherangerequiredforreal-time logtailing.Throughputreachedapproximately3219.84recordspersecondinthebenchmark.Peakmemoryduringtherun was about 271.17 KB, reflecting the bounded deque design: per-IP state is capped so that tracking a large number of sources does not cause unbounded memory growth. Figure 6 reports the controlled-run confusion matrix counts underlyingtheseaggregateoutcomes.

5.5 Incident Correlation Effectiveness

Inalivedeploymentthewindow-basedgroupercollectsalertsfromthesameIPwithina 10-minutewindowandmerges themintoasingleincidentrecord.Forscanning-heavytraffic,whereonesourcecangeneratedozensof404alertsinquick succession,thiscompressionismeaningful:insteadoffiftyindividualalerts,ananalystseesoneincidentlabelledwithtype breakdown,peakscore,andduration.Movinganalystfocusfromisolatedalertstocampaign-levelcontextimprovestriage efficiencyandreducesthechancethatslow-movingactivityisobscuredbyrepetitivelow-levelnoise.

Fig.

TABLE -7: ABLATION TEMPLATE FOR BEHAVIOURAL CONTRIBUTION

Volume: 13 Issue: 04 | Apr 2026 www.irjet.net

5.6 Ablation Plan (Rule-Only vs Rule+ Behavioural)

-0056

-ISSN: 2395-0072

To measure the behavioural component’s contribution in isolation, the same dataset can be evaluated with enable_behavioral_detection_false in the config, and then with the default enabled setting. The table below shows the template;therule-onlycolumncanbepopulatedinthenextevaluationcycleafterthesamedatasetisreplayedunderboth configurations.TheplannedreportingformatappearsinTable7.

5.7 Security Analysis

Threedesignchoicesdrivedetectionusefulness.First,everyalertcarries explicitevidence:thematchedregex,adecoded copyoftheflaggedpath,andbehaviouralcontextsuchastheIP’srecentrequestrate.Ananalystreadingthealertoutput can immediately see why it fired without consulting raw log files. Second, behavioural signals are harder to evade than staticpatterns.Anattackerwhoencodeseverypayloadandcyclesthroughuseragentsstillproducesadetectablespikein endpointdiversityorerrorratebecausethosesignalscomefromtrafficvolumeanddistribution,notpayloadcontent[14]. Third,thesmallmemoryandCPUfootprintmeansthetoolcanrunonthesamehostastheservicebeingmonitored,with noseparateforwardingpipelinerequired.

Known limitations are worth stating directly. Threshold values that work on a lightly loaded home lab server may generatefalsepositivesonahigh-trafficproductionservice.Thecurrentdefaultsfavourprecisionoverrecall,whichisthe right trade-off for avoiding alert fatigue but means some attacks go undetected. Log-based monitoring also has a hard ceiling:POSTbodycontentthatNginxlogsatdefaultsettingsisnotcaptured,soinjectionattackshiddeninrequestbodies are invisible to this tool. A patient adversary who spreads requests well below the rate spike threshold may also avoid behaviouraldetection,thoughtherulelayerwouldstillcatchexplicitpayloads.

Despitetheseconstraints,LogSentinelfitsagenuineoperationalneed.ItcomplementsratherthanreplacesafullSIEM andisusefulasalightweightfirst-alertlayerforenvironmentswhereheaviertoolingisnotanoption.

5.8 Discussion

Per-category results reveal a clear pattern. Path traversal and scanner traffic reach perfect recall because those classes usually contain stable lexical or structural indicators. By contrast, SQLi (0.225), XSS (0.343), and command injection (0.333)remainhardertocaptureunderconservativerulesettings,particularlywhenpayloadsareobfuscated.

The weakest area is SQLi coverage. The current pipeline correctly handles common URL encodings through double decoding (for example %27), but evasive forms such as comment-fragmented keywords (un/**/ion), mixed token separators, and unusual encoding combinations reduce recall. Similar limitations apply to XSS and command injection familieswhereattackstringscanbedistributedacrosssyntaxelementsthatareindividuallybenign.

To mitigate this, the rule corpus has already been expanded and currently contains 33 SQLi, 35 XSS, 25 traversal, 38 command-injection, and 24 scanner patterns. These additions emphasize observed evasion behaviours, including comment-basedmutations,broaderevent-handlervectors,shellsubstitutionforms,andcommandchainsassociatedwith privilege checks or exfiltration. Although the current benchmark reflects a comparatively basic controlled set, the expandedrulesareintendedtoimproveresilienceundermoreadversarialpayloadvariation.

The primary engineering trade-off is unchanged: improving recall without sacrificing the low false-positive profile. In practical operations,persistent falsealarmsquicklyerodeanalysttrustandreduce response quality.Forthisreason,rule broadening should be validated incrementally against benign traffic partitions before full deployment, with the ablation processusedasaguardrail.

Overall,theresultssupportaprecision-firstdeploymentposturewithexplicittuningcontrols(thresholds,whitelists,and rulesets)thatoperatorscanadapttolocaltrafficcharacteristics.Thenextstepisnotarchitecturalredesign, buttargeted refinementofvariantcoverageandbaselineadaptationwhilekeepingthedetectorlightweightandexplainable.

5.9 Threats to Validity

 Internal validity: Controlledlabelsaregeneratedfromsynthetictemplates;ifthosetemplatesunder-represent evasive payload families, recall may appear stronger or weaker than in production. The label-to-alert matching used in the live run is based on time and path similarity rather than a unique request identifier, which can introduceoccasionalassignmenterrorinbothfalse-positiveandfalse-negativecounts.

 External validity: Thedatasetandlivetestbedfocusonweb-accesslogtelemetryfromNginx-likeformats.Results maynottransferdirectlytoenvironmentswithverydifferentloggingschemas,reverse-proxybehaviour,ortraffic profiles(forexample,API-heavybackendswithhighlegitimateerrorratesandburstymobile-clientretries).

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 04 | Apr 2026 www.irjet.net p-ISSN: 2395-0072

 Construct validity: Precision,recall,andF1quantifyclassificationqualitybutdo notfullycaptureanalysteffort. Incidentcorrelationquality,alertreadability,andtime-to-triageareonlypartiallyrepresentedbythesemetrics.A user study or SOC-style tabletop exercise would better measure whether campaign-level grouping materially improvesinvestigationoutcomes.

 Conclusion validity: The reported metrics are based on specific rule versions and threshold settings. Small configurationchangescanshifttheprecision-recallbalance,especiallyinSQLiandXSScategories.Forthisreason, metriccomparisonsacrossversionsshouldalwaysincludetheexactrulesnapshotandconfigurationhashusedfor evaluation.

5.10 Operational Deployment Guidance

For production-like usage, threshold tuning should follow a staged rollout. Begin with an observation phase and export alert counts per category, per-IP, and per-time-of-day to establish local baselines. Continue with a progressive hardening phase by tightening thresholds gradually while monitoring false-positive complaints from operators. Only after stable behaviourisobservedshouldhigh-riskactions(suchasautomatedblockingthroughexternaltooling)beenabled.

Whitelisting should remain minimal and evidence based. Permanent suppression of entire subnets can hide compromised internal hosts, so narrow path-aware rules are preferable. Periodic rule review is also necessary: scanner signatures and payload conventions evolve, and stale patterns can silently reduce recall. In resource-constrained environments, the recommended architecture is to keep Log Sentinel as an edge detector and forward only enriched incidentsupstream,reducingstorageandanalystloadwhilepreservinghigh-valuecontext.

6. FUTURE WORK

The current implementation establishes a practical baseline for lightweight hybrid detection, but several technical extensionscanimproverecallandoperationalrobustnesswhilepreservingthelow-overheaddesigngoal.

 Adaptive baselines without heavy ML: A key extension is replacing fixed behavioural thresholds with light statisticaladaptationpersourceandperendpointclass.Exponentialmovingstatisticsandrobustquantilebounds can capture traffic drift while remaining interpretable for analysts. This approach keeps the system explainable andavoidsthemaintenanceburdenoffullmodelretrainingpipelines.

 Expanded normalization for evasions: Current double URL decoding handles many encoded payloads but not all obfuscation families. Future preprocessing can add canonicalization for mixed encodings, repeated delimiter folding, and safer normalization of Unicode-like confusable. Improved canonicalization should be paired with strictregressiontestingonbenigntraffictoavoidraisingfalse-positiverates.

 Richer correlation semantics: Incident grouping currently uses temporal and source-IP proximity. A stronger campaign view can include path-similarity graphs, attack-sequence motifs (for example recon to injection progression), and confidence-aware merge rules. These additions would improve analyst context by linking relatedlow-severitysignalsintoahigher-confidencenarrative.

 Evaluation breadth and portability: Beyond the current controlled and live testbed runs, broader validation shouldincludemultiplelogformats,higher-trafficprofiles,andAPI-heavyworkloadswherebenignerrorpatterns are common. This would test external validity and help tune defaults for diverse deployment environments withoutchangingcorearchitecture.

 Interoperability with existing SOC tooling: A lightweight export layer for STIX-compatible events or SIEMfriendly JSON schemas can make Log Sentinel a drop-in edge signal generator for larger security programs. The emphasisshouldremainonforwardingenrichedincidents,notraweventfloods,sothatupstreamsystemsreceive high-valuecontextwithmanageableingestioncost.

 Portal-native editing and launcher automation: The current stack supports dashboard registration through APIs and launcher-level navigation. Future releases can add direct in-portal drag-and-drop widget editing, template-based tenant presets, and automated Homarr tile synchronization so non-technical users can manage personalizeddashboardswithoutAPIcalls.

7. ETHICAL AND RESPONSIBLE USE

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Volume: 13 Issue: 04 | Apr 2026 www.irjet.net p-ISSN: 2395-0072

AlthoughLogSentinelisdesignedfordefensivemonitoring,operationalusemustrespectlegal,ethical,andorganizational boundaries.Access-loganalysiscancontainpersonaldataelementssuchasIPaddresses,user-agentstrings,andrequested pathsthatmayindirectlyrevealuserbehaviour.Deploymentsshouldthereforefollowdata-minimizationprinciples:collect only required fields, retain records for the shortest practical duration, and apply role-based access controls to alert and incidentviews.

7.1 Privacy and Data Governance

Defensive visibility should be balanced with privacy protection. Where policy permits, identifying fields can be partially masked in analyst-facing dashboards while preserving forensic utility through reversible controls available only to authorized responders. Organizations should document retention policy, investigation access boundaries, and incident audittrailssothatmonitoringactivitiesremainaccountableandreviewable.

7.2 Fairness and False-Positive

HarmEvenlowfalse-positiveratescancreateoperationalharmifalertsrepeatedlytargetsharedNATgateways,university proxies, or regional mobile carriers. Such concentration can bias response behaviour against benign users behind noisy infrastructure.Toreducethisrisk,responseactionsshouldbeproportionaltoconfidencelevelandevidencequality;highimpactcontrols(forexample,hardblocking)shouldrequirecorroboratingindicatorsbeyondasingletrigger.

7.3 Safe Response Design

The system is intentionally positioned as a detection and triage aid rather than an autonomous enforcement engine. Automated response integrations should default to reversible actions such as temporary rate limits, challenge flows, or staged quarantine policies instead of permanent bans. This design reduces the chance of prolonged service disruption causedbymisclassificationwhilepreservingrapidcontainmentcapabilitywhenalertsarestronglycorroborated.

7.4 Security of the Monitoring Pipeline

The monitoring stack itself can become a target. Alert logs, rule files, and dashboard APIs should be treated as securitysensitive assets: integrity checks, least-privilege file permissions, and authenticated API access are essential. Tampering with rule files or suppression lists can silently blind detection, so configuration changes should be versioned, peerreviewed,andauditable.

7.5 Academic and Defensive Use Statement

Thisworkispresentedtoimprovedefensivemonitoringcapabilityineducationalandresource-constrainedenvironments. The framework is not intended to support offensive activity, unauthorized surveillance, or policy-violating monitoring. Responsibleuserequiresexplicitauthorizationfromsystemowners,transparentoperationalpolicy,andcompliancewith applicablelawandinstitutionalethicsrequirements.

8. CONCLUSION

Thisworkdemonstratesthatpracticalthreathuntingcanbeperformeddirectlyfromwebaccesslogswithoutheavyweight infrastructure.LogSentinel combines interpretablerule signalswith per-IPbehavioural contextandincidentcorrelation, producingalertsthatremainexplainableforanalystswhilemeetingreal-timeprocessingconstraints.

On the controlled 280-record dataset, the system achieved zero false positives, perfect recall for path traversal and scanner categories,precisionof 1.0,recall of0.5375, averagelatency of0.283ms,andpeak memoryof 271.17 KB.In the live containerized experiment (125 requests), it achieved precision 0.9394, recall 0.4429, F1-score 0.6019, and accuracy 0.6720.Together,theseresultsshowstablehighprecisionwithmoderaterecallundermixedtraffic.

The implementation remains fully reproducible through the open-source codebase, Docker Compose deployment, and built-in evaluation harness. Current rule files already include expanded SQLi, XSS, and command-injection coverage, and theremainingengineeringfocusisimproveddetectionofheavilyobfuscatedpayloadvariantswhilepreserving lowfalsepositiveoperation.

International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056

Froman operational perspective,the mostrelevantoutcome isconsistentsignal qualityunderconstraineddeployment conditions:alertsremainexplainable,resourceusagestaysbounded,andtheplatformscalesfromaminimalsentinel-only deploymenttoaricherPortal+observabilityworkflowwithoutarchitecturalchanges.

REFERENCES

[1] Bala Krishna Sanneboyain, “Behavioral Threat Hunting (Log Sentinel) Repository,” GitHub, 2026. [Online]. Available: https://github.com/BalaKrishnaS7/Behavioral-Threat-Hunting.

[2] NGINX, Inc., “Module ngx http log module,” 2026. [Online]. Available: https://nginx.org/en/docs/http/ngx http log module.html.

[3]Docker,Inc.,“Dockerdocumentation,”2026.[Online].Available:https://docs.docker.com

[4]FastAPI,“FastAPIdocumentation,”2026.[Online].Available:https://fastapi.tiangolo.com/

[5]Vercel,“Next.jsdocumentation,”2026.[Online].Available:https://nextjs.org/docs

[6]PostgreSQL Global Development Group, “PostgreSQL documentation,” 2026. [Online]. Available: https://www.postgresql.org/docs/.

[7]RedisLtd.,“Redisdocumentation,”2026.[Online].Available:https://redis.io/docs/.

[8]PrometheusAuthors,“Prometheusdocumentation,”2026.[Online].Available:https://prometheus.io/docs/

[9]GrafanaLabs,“Grafanadocumentation,”2026.[Online].Available:https://grafana.com/docs/grafana/latest/

[10]Homarr,“Homarrdocumentation,”2026.[Online].Available:https://homarr.dev/docs/

[11]D.E.Denning,“Anintrusion-detectionmodel,”IEEETrans.Softw.Eng.,vol.SE-13,no.2,pp.222–232,Feb.1987.

[12] M. Roesch, “Snort – Lightweight intrusion detection for networks,” in Proc. 13th USENIX Conf. Syst. Admin. (LISA), Seattle,WA,USA,1999,pp.229–238.

[13]V.Chandola,A.Banerjee,andV.Kumar,“Anomalydetection:Asurvey,”ACMComput.Surv.,vol.41,no.3,Art.no.15,Jul. 2009.

[14]S.Axelsson,“Thebase-ratefallacyandthedifficultyofintrusiondetection,”ACMTrans.Inf.Syst.Secur.,vol.3,no.3,pp. 186–205,Aug.2000.

[15]K.ScarfoneandP.Mell,“Guidetointrusiondetectionandpreventionsystems(IDPS),”NISTSpecialPublication800-94, Feb.2007.[Online].Available:https://csrc.nist.gov/publications/detail/sp/800-94/final.

[16]T.Berners-Lee,R.Fielding,andL.Masinter,“UniformResourceIdentifier(URI):Genericsyntax,”RFC3986,Jan.2005. [Online].Available:https://www.rfc-editor.org/rfc/rfc3986

[17]MITRE,“ATT&CKFramework,”2025.[Online].Available:https://attack.mitre.org

[18] OWASP Foundation, “OWASP Top 10:2021 web application security risks,” 2021. [Online]. Available: https://owasp.org/Top10/2021/

[19]R.Sommerand V. Paxson,“Outsidetheclosedworld:Onusingmachinelearningfor network intrusiondetection,”in Proc.IEEESymp.SecurityandPrivacy,Oakland,CA,USA,May2010,pp.305–316.

[20] Verizon, “2023 Data Breach Investigations Report,” Verizon Business, 2023. [Online]. Available: https://www.verizon.com/business/resources/reports/dbir/