Link to home
Start Free TrialLog in
Avatar of Ted James
Ted James

asked on

WAN traffic cyber monitoring

My team of SOC analysts is looking at captured internet traffic to provide cyber defense on behalf of several of our enterprise clients.  Each client has a non-intrusive tap (usually a gigamon or something similar).  The gigamon is situated outside the enterprise perimeter router just before the enterprise's public demark.  Therefore the tap passes thru all inbound and outbound WAN traffic.  To the analysts, the tap it is sending a copy of the traffic (some filtered, as in Netflow or IPFIX, and some as full PCAP) for monitoring and analysis.  If the enterprise is connected directly to the internet via an ISP, the analysis is relatively easy, as the analysts are looking directly at the internet traffic for behaviors and signatures that would indicate an attack or malware of some kind.  This first situation is shown here.  (with a downstream feed from the gigamon to the SOC not shown here):

Enterprise LAN<----->Perimeter Router<------>gigamon tap<-------public demark<----->ISP<------>INTERNET

The question arises when a client is not directly connected to the internet via an ISP, but rather  is connected thru another provider before it gets to the internet.
This second situation is shown here where the enterprise access to the outside world is through another provider before actually hitting the internet.  This makes the monitoring of internet traffic more complicated because there is extra encapsulation.  Here is that scenario:

Enterprise LAN<----->Perimeter Router<------>gigamon tap<-------public demark<----->Service Provider (MPLS, VXLAN, SDWAN, cloud provider)<------>INTERNET

I'd like to get some detail as to how the tapped downstream data that is going to the analysts would be different.  Four different cases here:  1. cloud provider (AWS, Azure, etc.);  2. SDWAN provider; 3.  VXLAN provider;  4.  MPLS provider.  For all four cases the traffic is encapsulated with the service provider's headers,

Questions for all four cases:
1.  How does the analyst know the traffic is going through the service provider and be able to identify that (is it AWS?, is it SDWAN? is it VXLAN?etc…)?
2. With that, can the analyst still be able to identify/analyze the raw user traffic as if they are looking at the actual internet traffic?

Hope I explained this right.

Thank you!
Avatar of David Johnson, CD
David Johnson, CD
Flag of Canada image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Use Wireshark and look at the raw packets and check the tags. You would have to filter by destination or source address. Since most traffic these days is encrypted end to end using TLS the amount of viewable data is greatly reduced.. Now you are left with strict traffic analysis. Volume of traffic from one location to another and the time of day and peaks and valleys.
Agree that the place for a tap In this situation is likely between the edge router and LAN. That way all the encapsulation is removed. More and more edge routers are going sdwan and encrypting everything on their wan side anyway.

Considering that, you probably want to look at sdwan edge integration for the next version of your product set instead of just a tap. Velocloud already integrates with netflow/Ipfix with vRNi and Nyansa is coming. Syslog and Api event tracing is becoming even more Important in tracking down the flows. A non application aware tap is simply not going to give you the data you need.
Avatar of Ted James
Ted James


Thank you both for chiming in.  So I have a couple follow-ups based on your comments:

1.  Agreed that a more convenient location is between the firewall and the LAN (In the sketch, forgot to include the FW that is at the perimeter router but I assume you knew that).  However, at this time the client does not want us getting feeds from their internal network.  We hope to be able to tap there in future, and we should.  So for now we are limited to the traffic outside their perimeter and inside the telco demark.
      For when that time comes, I would like your thoughts on the best place inside the LAN (from a SPAN port for instance, or VPN termination point, or where? etc.) where we would get the best "look",

2.  While looking at end to end TLS encrypted data we would like to be able to at least recognize the TLS.  Then if the client allows another feed to the gigamon that represents the "inside" LAN version of that stream that would be best.

3.  How would the edge router (owned by the client enterprise) connect with the SDWAN?  Vendor-configuration?  And from the existing tap location shown, does all it see is an encapsulated SDWAN "tunnel" to the SDWAN provider?

4. On the subject of SDWAN, can you point me to some docs and links about implementing SDWAN?  -both from a general tutorial point of view, and in particular how it plays in this scenario?

I have no idea why you are using a TAP outside the firewall instead of inside the firewall. You have no way to correlate traffic with the actual internal endpoint, unless it has static NAT. I have 2000 devices using a single public IP. Even if you saw something that looked suspicious, how would you know which device it is associated with?

IMHO the best place for a tap would be at a central traffic point, where you could see internet-internal traffic, and internal-external traffic. If you cant get that, you at least need to be at least just inside the firewall before NAT happens you you can see which device is making funny DNS requests, for example.

I also think you need to be able to see internal DNS requests, because getting a report that a DNS server is sending suspicious requests isn't significantly helpful if you can't further narrow it down.

You should also be looking at at least selective decryption of traffic, as much malware and C&C traffic is encrypted these days.
However, at this time the client does not want us getting feeds from their internal network. Fire the client. ​​​​​​ There obviously is a trust issue going on here. 
LOL David.  Good point, in fact I am meeting with them tomorrow and there is a good chance we will get an "inside" look.   I'll keep you posted.

Kevinhsieh, no way they will let us decrypt their traffic.  However, after our meeting tomorrow I am hoping they will feed us decrypted traffic, which traffic I do not know.
Hi everybody.  I have been AWOL the past three months I am back with apologies.

My work is still ongoing but obviously hampered with the latest shutdowns etc.

I do not have access to pcap so I couldn't see for myself, but I have a parting question  (similar to a question I posed in another thread)….  If I can capture a TLS encrypted session, can I tell if the TLS is encrypting web browsing (https), or email?    Same question in another example... If I capture an SSH session, can I tell if the encrypted session is an actual login session, or is it a secure FTP session.
Most of what we capture is TLS encrypted so that is the million dollar question... what is that actual underlining communication and how could I tell?
In all cases here, I want to know without having to depend on the port used (443, 22, etc.) because people could disguise the communication by using a different port.

What about an IPSEC VPN, besides being able to caplure which protocols are used (ESP, AH, etc)?

None of the above as it is all encrypted.
Thank you!