Hacker News Reader

Comment by smashed | Hacker News Reader

How relevant is a rule based IDS in today's environment?

With most everything fully encrypted, what's left for the rules to detect? If I remember correctly, one of the first performance optimization recommended by snort/suricata is to detect and skip encrypted traffic, to not waste cpu cycles on random bits.

If a malware wants to exfiltrate data or receive commands from a remote command and control, won't they simply masquerade their traffic as regular outgoing https requests and bypass the IDS easily?

View on HN

Ban outgoing encrypted traffic. Terminate TLS at the load balancer.

(I previously worked for Sourcefire / Cisco, which owned snort)

You can force everyone to go over a proxy where you can MitM it, or have MitM that swaps out all TLS negotiations to use your own certs and replace things (but then all clients need to have your local CA cert installed on all machines egressing the network.

IPS's have had this downfall for a long while, and likely just keeps getting worse. I think MitM is the only way to do deep packet inspection. Otherwise you're just going to do host/traffic analysis to look for oddities in the hosts being connected to and how much is flowing. Host analysis can give you some data, but no where near as good as what Snort can do with deep packet inspection.

"You can force everyone to go over a proxy where you can MitM it, or have MitM that swaps out all TLS negotiations to use your own certs and replace things"

You've only unwrapped one layer of the onion this way, which only works if the data inside it is in plaintext. If it's encrypted you're back to square one.

it can be blocked as well, because most other benign and good apps dont do double layer encryption

mitm is the only way to secure egress with tls 1.3 native forward secrecy. root ca trusted cert on each device.

ingress is tls offloading at waf

If your WAF is terminating TLS, can't it also initiate outgoing TLS connections? In this case the ephemeral Diffie-Hellman secrets would be created on the WAF, so it would have full ability to inspect traffic.

it won't work for devices/website that do certificate pinning, device won't accept MitM'd certificates, only original non-intercepted certs are accepted

https://www.thesslstore.com/blog/an-introduction-to-pinning/

Right, you pin the cert deployed on your WAF and you should still be able to terminate TLS at it.

I see no issues here - your WAF itself is initiating and terminating outgoing and incoming TLS connections. DHE keys are generated on the WAF. The WAF's cert could be the authoritative one.

The WAF could then re-establish a new connection to applications behind it.

There does not seem to be any technical boundary here.

there are embedded/IoT devices that pin ssl themselves and do not allow you to change that

Just don't use devices you can't configure?

For a home network that might be feasible but for a business/shared network you have to be careful about terminating all incoming traffic since you might deal with HIPPA or finance privacy issues.

In my professional opinion requiring insecure internal connections is also a bad idea.

Reasonable plan, until your service needs to interact with an external service (esp 3rd party). Then what?

Perfect security is commonly unusable and therefore often useless, because the business requirements still come in and need a solution.

Reply on news.ycombinator.com