intrusion detection system (IDS) / intrusion prevention system (IPS)

Development
1

Would an intrusion detection system (IDS) / intrusion prevention system (IPS) make any sense being combined with Whonix?

(Asking pretty openly. Not necessarily installed by default. Perhaps as part of (advanced) security guide.)

The following documentation page is related.

//cc @HulaHoop @entr0py @Ego @marmarek @torjunkie

1 Like
2

I researched the topic. Here are my notes. Please do disagree with me if you have good points, happy to stand corrected and learn.

IDS from the point of view of an end user, not server.

IDS can be compared with antivirus.

IDS:

  • like antivirus → also increases attack surface

TLS inspection:

  • like antivirus → also increases attack surface

An IPS is like an IDS but with the added feature to block the attack.

threat model dependent:

  • A Windows user with no clue: Should use antivirus. They employ lots of insecure practices anyhow (not checking software signatures, closed source software, no VM level compartmentalization, Windows) so that the extra attack surface of the antivirus is negligible. On balance it adds more good than harm.
  • A security conscious linux user: added attack surface by antivirus is non-negligible so on balance not worth it.

antivirus increasing attack surface:

  • It’s not a theoretic argument.
  • Download of signatures without verification. (ref)
  • Weakening security of TLS. (ref)
  • Introducing memory corruption exploits. (ref)

server vs client:

  • IDS / IPS seems to make more sense for servers

Are there any linux malware scanning gateways? Ones that are Open Source? Ones that can also inspect TLS encrypted traffic? And not creating a mess due to TLS inspection?

the combination issue:

  • one cannot encrypt ones traffic and at the same time DPI / IDS scan it
  • one cannot torify ones traffic and at the same time DPI / IDS scan it

How do corporates do it:

  • doesn’t apply to us, because
  • they have policies “this browser only, this mail client only, no Skype, no Tor, etc.”
  • block encrypted unknown traffic (ssh, etc.)

network based → more for company based policy enforcement
→ we have more traffic today? → someone using skype / torrent / emule?
→ configure a set of legitimate services and block the rest
→ conflicts with end users wanting to do whatever they want

the lone wolf issue:

  • doesn’t help to have super entropy for oneself while no one else has poor entropy
  • very very few people seem to decrypt and then IDS scan their traffic using Open Source
    – therefore no signatures for Malware that is using encrypted traffic
  • do we want to trust closed source to scan all our decrypted traffic?

How effective is the malware detection of IDS signatures vs antivirus signatures?

DPI:

  • The days for DPI are counted - more and more encryption is being used everywhere.
  • Encryption defeats DPI.

TLS Inspection issue:

  • man-in-the-middle encrypted SSL traffic so IDS / IPS / DPI can check it:
  • there are no general solutions to mitm ones’s own traffic
    – encryption is done on the application level
    – so a generic solution on the network level does not exist
  • only specific solutions exists
    – there are mail gateways (for pop, smtp, imap)
    – browser mitm might work (install SSL CA certificate)
    – mitm against arbitrary applications (everything that is not a browser) is hard
  • DPI / mitm against torified traffic
    – no easy way to DPI Tor - it is anti DPI
  • issues
    • some do not work with modern ciphers, diffie-hellmann and perfect forward secrecy (PFS)
    • do these even work for domains that use key pinning such as google?

From a ccc speech. TLS interception considered harmful
hanno: TLS interception considered harmful - YouTube

Takeaway:

  • biased
  • lots of TLS vulnerabilities lately (crime, heartbleed, poddle, etc.)
  • one needs to stay on top of TLS developments, browser vendors do, TLS inspectors don’t
  • current TLS inspectors don’t, and replace a good TLS stack with a weaker TLS stack
  • enterprise TLS solutions are as bad as forgetting to run integrity checks

a new TLS inspector with a sane design:

  • should re-use same code as modern browsers?
  • invent TLS secret leakage to IDS protocol

volunteer IDS / DPI scan of torified traffic

  • in theory one could modify Tor to voluntarily safe the clearnet traffic and send them to the IDS for inspection
  • but rather than depending on that complicated solution, we could as well as just run the IDS on the same machine (adds IDS attack surface)

snort:

  • not multi-core

first IDS scan in one VM, then forward to another VM to to torify:

  • breaks Tor stream isolation (because it needs help by the application layer)

network based vs host based virus scanning

  • [A] scan inside VM → easier to scan → vulnerable to antivirus being disabled
  • [B] scan traffic outside of VM → harder to scan (traffic only, no file activity, encrypted traffic issue)

virus scanning VM:

  • A new invention idea…
  • Could a Qubes (non-networked) VM get special access the read the whole RAM and disk of another VM to virus scan it?
  • That would combine the advantages of [A] and [B].

Open Source antivirus:

  • clam av → no serious detection rates
  • serious antivirus → closed source → with root/kernel rights → risk
  • do we want to decrypt our traffic so a commercial scanner can check it?

mail scanning gateway → most useful to protect windows computers

detect automated attacks (mostly against Windows) and see how these fail? → just noise

detect attacks by advanced adversaries? → no IDS can do (like no antivirus can do)

detect tailored attacks? / detect new malware (heuristic) → probably not using Open Source, there are no good antivirus scanners for linux so probably also no IDS (which is even harder)

hosted based IDS

  • alert “we have more traffic than usual” → installing new template?
  • alert “we have more CPU usages than usual” → running a new game?
    → not very useful

av-comparatives - backtest antiviurs heuristics

IDS from the point of view of an end user, not server conclusion:

  • default should be recommended against, for the same reason we recommend against antivirus
  • improvement is possible
    • sane, Open Source TLS inspectors, effective Open Source antivirus scanners and perhaps a Qubes virus scanning VM would ve possible in theory, but don’t exist in practice.
2 Likes
3

Based on:

  • Increases the attack surface.
  • Dependence on unverified downloads.
  • Weakening of TLS (MiTM effect).
  • Memory exploitation risks.
  • Not-open source in general.
  • Not very useful for encrypted/Tor traffic.
  • Trust is shifted to closed-source companies in all likelihood.
  • Poor compatibility with modern ciphers.
  • Potentially breaks Tor stream isolation.
  • A sane version of IDS doesn’t exist in practice to meet the security/privacy criteria normally expected of Qubes/Qubes-Whonix.

It sounds like a terrible idea.

1 Like
4

Network monitoring (using packet capture software) is as good as the people using it and spotting the anomalies. Organizations with cybersec defense responsibilities do use IDS to detect attacks and have a record to refer to in the future if an adversary’s exploit toolkit is “burned”, to see if it was used against them. Even if no data is being smuggled across the network, techniques like encoding messages by using patterns in packet delay are extremely hard to detect.

Automated solutions are limited as you said. Automated solutions with third party “experts” are even more problematic because they expose secure/private systems to untrustworthy organizations.

True. A world with perfect IDS is also one with perfect censorship since both Tor users and data exfiltrators want to hide their network activity from an observer. Luckily this is not the case though it means we don’t benefit for systems defense as much.

1 Like