FP "DNS resolution without connection" in CTU-Normal-32/2017-05-02_normal_pcap

[AlyaGomaa]

cmd: ./slips.py -e 1 -f /data/Normal/CTU-Normal-32/2017-05-02_normal.pcap -o output/Normal/CTU-Normal-32/2017-05-02_normal_pcap/1 -m -c config/generated_config_files/experiments_CTU-Normal-32_0.8_threshold.yaml

FP : domain (domain time-inc-zwpajagg7p.xid.segment.com, ip 34.208.103.162)

[AlyaGomaa]

Same FP in this evidence
1970-01-01T02:01:27.108715+02:00 (TW 1): Src IP 10.0.2.15 . Detected domain detectportal.firefox.com resolved with no connection threat level: low.

[AlyaGomaa]

That FP is because slips generated the "DNS without connection" evidence way before it read the connection from conn.log
input process read the connection from conn.log as soon as slips started @ 2025 02:24 PM
profiler processed it @ 2:43:01.778380 (19 mins later!)

[AlyaGomaa]

I had an idea to make profiler process flows in 3 parallel threads
it reduced the time it took profiler to get the connection from 19 mins to 10, but we still have the FP "DNS without connection" evidence

[AlyaGomaa]

sebastian's purposed solution

‘how much to wait’ before saying ‘there is no connection for this DNS’ are
While 30 mins of zeek time did NOT passed since last check
- If slips stopped for any reason:
check if the connections happened and alert if not
- if not: do nothing and continue
else (more than 30 mins passed)
- check if the connection happened and alert if not
- start couting the 30 mins from now

[AlyaGomaa]

also set the threat level of this detection to info

[AlyaGomaa]

i'm concerned that this approach to detect "dns without connection" evidence will cause the evidence to be set after 30 mins of the dns flow, and the timewindow of that evidence may have been closed, that would cause us to detect the tw as malicious way after it ends. but this doesnt matter since the threat level of it is info.

this will be an issue if we ever decide to increase the threat level
of this evidence

for example if this evidence is threat level critical in the future, and we set it after 30 mins of the original DNS flow (lets say that dns arrived at the end of the timewindow) then, then we might be detecting that timewindow as malicious, 30 mins (zeek time) after it ended.

will put this comment in the code too.

[AlyaGomaa]

Fixed here #1184