[ploxiln]

> we operate in networks where outbound MQTT and HTTPS is simply not allowed (which is why we rely on encrypted DNS traffic for device-to-Console communication)

HTTPS is not allowed (locked down for security!), so communication is smuggled over DNS? uhh ... I suspect that a lot of what the customer "security" departments do, doesn't really make sense ...

[jmprspret]

DNS tunneling, or smuggling through DNS requests, is like a known malware C2 method. Seems really weird to (ab)use it for ""security""

[thinkst]

Product builders can learn loads from malware in terms of deployment and operational ease. Malware needs to operate without any assistance in unknown environments. Nobody is allowing outbound comms deliberately for malware, so tunnel methods were developed.

Networks have these capabilities, inherently they're part of the specs. But only malware seems to realise that and use it. We love reusing offensive techniques for defence (see our Canarytokens stuff), and DNS comms fits that perfectly. Our customers get an actual 2-minute install, not a 2-minute-and-then-wait-a-week-for-the-firewall-rules install.

[marcosdumay]

The problem is that when you apply the malware lessons to your software, every anti-virus starts to work against you.

[jmprspret]

That could be true. Especially those that opt for a heuristic/application anomalous behaviour approach. But then, you can add white listing and exceptions to most AV products.

[jmprspret]

I didn't mean to imply that so for security was a bad thing. Now I read back my comment I see that is exactly how it sounds.

I agree with you

[thinkst]

We've got several product features that have been driven by our offensive security background... thanks for the prod, we'll blog it.