asked on

Monitoring encrypted traffic

I need to create a white paper based on actual usage in the field for monitoring traffic. In particular, monitoring encrypted traffic. Our data center is receiveing netflow and IPFIX data from a few dozen client enterprises that we are serving. The netflow/IFIX data that is being sent to us real-time but we do not have control over where our clients are sourcing. It is up to them. In other words, the "tap' they use is most likely outside their firewall, and probably outside their boundary router, but may not always be. So in the case of encrypted traffic, obviously we are not reading their payload, but we need to be able to detect whether specific traffic is encrypted. For both cases, for SSL traffic and for IPSEC VPN traffic, we need to identify as much as we can for our clients sake, without deciphering the payload.

Can you point me to explanations and scenarios (preferably real case scenarios) where this is done, and how the security techs, who are monitoring this in our data center, are handling this? Especially, as is most like the cases, if the data we are receiving is from the encrypted data flow.

noci

Without the content you cannot find out if data is encrypted or not. The Netflow data (counts of occurrences, volume of: source, target identifiers = ipaddress, port and possibly some flags) is not sufficient for that. See: https://en.wikipedia.org/wiki/NetFlow (IPFIX is the RFC specified version of Netflow).

You will need the packets themselves. It is even possible to use TLS and the content not being encrypted if a NULL key/encryption is negotiated during session setup. So without the contents of the negotiation records you cannot determine if the the actual stream is encrypted or not. (even then it may be an issue for generic protocol because they may be binary or compressed with might look encrypted on a glance.)

Ted James

ASKER

Can I monitor the session details and be able to at least determine that the traffic is encrypted? How could I otherwise identify it? Whether it is SSL or IPSEC or cleartext.

noci

For IPSEC you need the ESP or UDP/4500 traffic itself to validate if it is encrypted.

While the IKE (key negotiation = UDP/500)

For TLS you need the heads of each session (first 10 or so packet exchanges). (For HTTPS, IMAPS, POPS, ... etc. )

for IMAP + STARTTLS / SMTP + STARTTLS etc. you will need the packet exchange after the STARTTLS command.)

So effectively without some measuring in stream there is no way to verify.

Ted James

ASKER

If a flow meter is used to send the metadata to the data center, could the analyst on the receiving end of that flow "see" if protocol ESP is being used or UDP500/4500 are being used etc? And that way they can recognize that the traffic is encrypted between the two endpoints?

Similarly for TLS, would they be able to recognize a pattern that would indicate a TLS exchange? (Without being the man-in-the-middle of course)

noci

ESP with NULL-encryption method (yes it exists) will not encrypt the traffic. If a SINGLE-DES encryption is used it effectively is using a broken cipher....

Those will be reported as "encrypted" en effectively do nothing.

For the TLS exchange you need the stream ITSELF. Not meta data.

Ted James

ASKER

I think the first part of your answer is getting to the point of what I'm looking for. All I'm looking for is the analysts' ability to recognize and "flag" whether or not the data they receive from the taps is representing encrypted traffic. So if the IPFIX data is saying that ESP is being used, then the analyst can assume the traffic is encrypted (via IPSEC)

Plus anything else (trend of packet sequence for example) that may indicate to the analyst that the traffic is being encrypted.

Also, are you familiar with the SILK Cert tools? It is proposed here to download and build out a SILK tool set to incorporate that as well. I am not familiar with that yet, it had been brought up a couple times here recently.

Thanks for hanging with me.

noci

Encryption with NULL method means ESP is used and text is sent as cleartext. So ESP is an indication encryptions is attempted, not about how successfull the actual encryption is.

If you receive data from taps you get the content anyway.

You probably mean SiLK tools. Have read on them, not actually used them. It is about the numbers of bytes transferred, not evidence of any stream content qualities.

SiLK provides a toolset to collect & select from a corpus of Flow data. therefor getting it to managable/related chunks.

So it will help with filtering on relevant data.

Ted James

ASKER

Good info thank you. I have learned that I'll need to make a deeper dive on the SiLK tools. Since there is a lot of interest. So I'll open another question about SiLK specifically, feel free to jump in on that. :-)

Also, I misrepresented what I meant about a "tap" because the content is not what is being transported down. The tap is tapping the traffic flow and sending (similar to a SPAN) to an on-premise device (not sure if it is a router or firewall or just a configured server) that is listening and periodically sending the IPFIX stream to the analysts..

noci

RFC 7110 ( https://tools.ietf.org/html/rfc7011 ) gives more info in transport details.

Ted James

ASKER

Before I close this out, I would like to explore all the different encryption methods that an enterprise would use when browsing, or transferring a file or other ways of encrypting using the internet. So far the main vehicles I am aware of are TLS/SSL, SSH, SCP (I guess same as SSH), IPSEC, SFTP, FTPS...
Can I get a pointer to all the different approaches?

From that I would try to learn a perspective of each one from the point of view of a security analyst sitting in a SOC that receives the metadata of these traffics.

ASKER CERTIFIED SOLUTION

noci

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Ted James

ASKER

Thank you!