SNORT rule for detecting/preventing unauthorized VPN or encrypted traffic

Question

Here's my not so theoretical scenario: A day-one Trojan horse attack where the attacker sets up a secure connection back to himself using a well known trusted port, such as 80 21 443. Or for instance, if a malicious user takes advantage of an open source tool such as openvpn to secure and route a connection out through a trusted port from within the company, effectively making all security mitigations useless.

Is there any way that snort could detect an initializing secure connection whether it be SSL/TLS or IPSEC? I realize that once the connection is established it becomes very difficult to find, that's my problem.

My main question: Is there any way to detect the exchange of public keys and log who's doing it?

Thanks in advanced!

Answer 1

In the case of TLS the answer is yes. (IPSEC?) The screenshot below shows a TLS exchange being caught by Wireshark. I don't know if Snort can do this directly.

---

DISCUSSION I'll assume that you're within the same security boundary as the server. If you weren't, then simply tunnelling one protocol (eg. TLSxx on TCP) within another (eg. OpenVPN on UDP) will be enough to mask any connection establishment, such that you will be reliant on statistical analysis to try and determine what the specific network activity is.

Generally speaking, however, it really depends on the exploit.

If the attacker compromises a public-facing host, and manages to open a privileged port on this host, then you could capture this activity either on the host, or on the host's network, preferably both!

But what if the adversary modified (or worse: installed!) some upstream edge router to redirect packets to a different internal host, and then, instead of this new host listening for expected protocols (eg. HTTPS), the conditional host was now listening for some other protocol (eg. SSH)? I might configure HAProxy with a layer-4 reverse proxy that chooses between TLS, or SSH on a different internal host only when the client IP is specifically w.x.y.z or port 0FF0, etc.

Here's an example of configuring HAProxy to respond differently, depending on the protocol (HTTPS vs SSH) of the client Lim '16

Here's another interesting example showing discretionary back-ends depending on the contents of the TLS-SNI hostname Gornstein '17

HAProxy documenation on acl directives

(Yes, this example shows picking the SSH backend depending on the first 7 bytes, which your monitoring would also pick up on, but the protocol could just as easily be hand-rolled to use- or hardened with- a pre-shared key, eg. WireGuard or ZeroTier. In these cases the protocol is designed to mask the exchange of keys; IMHO the direction newer privacy-oriented protocols are trending toward.)

Now you might only see data flowing over the socket (encrypted, of course!) and never actually register any protocol. Any monitoring performed on host X will not even see the packets associated with the malicious activity. Monitoring on the network will see activity from host Y, but it might be mistaken for some other protocol.