Some of my colleagues are going to make fun of me because I titled this blog, “How to Monitor SSL Traffic” knowing that I absolutely hate when people call Transport Layer Security, SSL. What I’ve learned, though, is that most people still call it by the old Secure Socket Layers name, or SSL. Anyway, I digress. In this post, as the title self-defines, I will show you how you can monitor SSL and TLS traffic using NetFlow and metadata from the devices on your network. Read more
Author: Justin
Justin Jett is Director of Audit and Compliance at Plixer with roles ranging from system administration of web services to technical product marketing for Plixer’s incident response system, Scrutinizer. Jett, a graduate of the University of Maine at Farmington, is an avid learner of all things security, with a particular interest in TLS and DNS attacks.
Flow Hopper for Root Cause Analysis
We recently released an update to Scrutinizer that had many improvements to Flow Hopper. Now, for those of you that don’t know, Flow Hopper is a patent pending technology created by our engineers here at Plixer. Many utilities that display the path a flow took through the network topology rely on routing tables or SNMP information, which are fairly unreliable in a redundant architecture, especially one with several path options to get from point A to point B. Flow Hopper works with nearly all versions of NetFlow, IPFIX, and other flow technologies. It allows Scrutinizer administrators to see the path a flow took through the topology. The user can click on each hop along the way to see details on how the flow may have changed.
How to access Flow Hopper
Before I outline some of the useful aspects of Flow Hopper, let me first explain how you can access it.
To start, you need to run a report on the exporter where the data you want to see is located. Because of the nature of Flow Hopper and multi-hop network communication, there are a handful of reports that will allow you to see the hop-to-hop details that Flow Hopper can show you. As such, when you select your report, be sure to choose either a Pair Report > Connections By Bytes, or a Pair Report > Connections By Flows report (see below). You can also view Flow Hopper if you are in Flow View, although, that will contain all the flow template details reported from the exporter, and may contain more information than you need.
Now that you are in an appropriate report, make sure you have selected one minute intervals (we want to see the raw data associated with the conversations) because that is the only way for the Flow Hopper option to show up in the report.
Once you are viewing one minute intervals for your report, you will see the option for Flow Hopper within the report itself. Notice the new icon that shows up next to the report details.
Viewing Flow Hopper Details
After clicking the Flow Hopper icon, a modal will open over the report. Flow Hopper will then run through a number of checks to provide an image of the bi-directional flows for the given conversation; this includes all devices (i.e. routers, switches, etc.) that the conversation went through. If any of those devices are experiencing performance degradation (high bandwidth utilization), the report will highlight those so you can view further details specific to those devices.
A major benefit of seeing the device-specific information, is that you can quickly identify where performance issues may be, and determine if your performance routing configurations are optimized. In an network configured with performance routing, for example, we shouldn’t see any degraded routers because the traffic should have been sent through another router to optimize the network. With that in mind, if you are seeing a report like the above, it may be a good idea to check your configurations. If you don’t use performance routing but see the above, it may be a good idea to set up routing policies to help move traffic through the network to prevent degradation on two of the hops.
With that in mind, when you see a degraded device in Flow Hopper, you can click the device and view additional information. In the case of the degraded router (10.99.3.1) we can see that it was on the return trip that (Backward B – A) that had performance issues. Specifically, we can see that there was both excessive jitter and latency compared to the Forward (A – B) traffic. This is interesting information that can provide us with some insight regarding where to look to determine root cause.
While there are a variety of different paths that you can see with Flow Hopper, any report that you will run will provide you with additional information to help you determine what is causing network performance degradation. To learn more about determining root cause delay, check out a previous article I wrote on Cisco AVC Flow Exports. I highlight our Root Cause Delay report about halfway through.
Petya: Four Things You Need to Know
UPDATE: For those infected by older versions of Petya, you can find a decryptor here.
With the recent release of the Petya ransomware, it is important to understand a few things about it. In this article, I hope to provide you with a brief history of Petya, and provide you with four things that you should know about this latest release of a new ransomware attack.
What is it?
Before we begin, allow me to provide a brief history of Petya. Based on initial reporting, this Petya campaign involves multiple methods of initial infection and propagation, including exploiting vulnerabilities in Server Message Block (SMB). Microsoft released a security update for the MS17-010 vulnerability on March 14, 2017. This security update resolves vulnerabilities in Microsoft Windows. The most severe of the vulnerabilities could allow remote code execution if an attacker sends specially crafted messages to a Microsoft Server Message Block 1.0 (SMBv1) server.
1. How does it work?
Petya encrypts the victim’s files with a dynamically generated, 128-bit key and creates a unique ID of the victim. Petya spreads using the SMB exploit as described in MS17-010 and by stealing the user’s Windows credentials. Some variants of Petya are notable for installing a modified version of the Mimikatz tool, which can be used to obtain the user’s credentials. The stolen credentials can be used to access other systems on the network. Petya will also attempt to identify other hosts on the network by checking the compromised system’s IP physical address mapping table. Next, it scans for other systems that are vulnerable to the SMB exploit and installs the malicious payload.
The compromised system’s files are encrypted with a 128-bit Advanced Encryption Standard (AES) algorithm during runtime. Petya writes a text file on the “C:\” drive with the Bitcoin wallet information and RSA keys for the ransom payment. It modifies the master boot record (MBR) to enable encryption of the master file table (MFT) and the original MBR, then reboots the system. Based on the encryption methods used, it appears unlikely that the files can be restored even if the attacker received the victim’s unique ID.
2. Who has been infected?
Major networks across Russia, Ukraine, Australia, and India are among the hardest hit by Petya, while a total of at least 65 countries have reported infections. The National Bank of Ukraine said it has been hit by an “unknown virus” and is having difficulty providing customer services and banking operations as a result. According to Microsoft, “we saw the first infections in Ukraine — more than 12,500 machines encountered the threat.” Petya is still affecting airports and ATMs in Ukraine and hampering international businesses from the shipping giant Maersk to the drug company Merck. Its victims also include hospitals in Pennsylvania’s Heritage Valley Health System.
3. How is it different from WannaCry?
While Petya has many similarities to WannaCry, there is one major difference that should be noted. WannaCry only infects the files on an infected system. Petya, however, locks down the entire hard drive, and, because of the way that Petya works, it is highly unlikely that you will ever recover your files, even if you pay the ransom.
4. How can you avoid it?
There are a number of things that users and organizations can do you prevent being infected by Petya.
- First, apply the Microsoft patch for the MS17-010 SMB vulnerability dated March 14, 2017.
- Make sure you have strong spam filters in place to prevent phishing emails from reaching the end users and authenticate inbound email using technologies like Sender Policy Framework (SPF), Domain Message Authentication Reporting and Conformance (DMARC), and DomainKeys Identified Mail (DKIM) to prevent email spoofing.
- Scan all incoming and outgoing emails to detect threats and filter executable files from reaching the end users.
- Manage the use of privileged accounts. Implement the principle of least privilege. No users should be assigned administrative access unless absolutely needed. Those with a need for administrator accounts should only use them when necessary.
- Run regular penetration tests against the network, no less than once a year. Ideally, run these as often as possible and practical.
- Test your backups to ensure they work correctly upon use. You don’t want to find yourself in a position where not only are your files gone or encrypted, but your backups are useless.
That, of course, is only a handful of the things you should do to protect yourself from such attacks, but they should be part of a well-developed incident response plan.
If you want to gain additional context with regard to your network, download our network traffic analytics platform, Scrutinizer, to see where everything is going on your network.
Contextual Insight from Gigamon Devices
When it comes to networks, organizations are overwhelmed with the amount of data that traverses them. Even with all this data, though, it can be extremely difficult to uncover unwanted or malicious behaviors. Gigamon appliances export unique information that can be used to provide contextual insight into the network for both networking and security professionals alike. In this article, I’d like to explore what a Gigamon and Plixer joint solution would look like to bring better value to the heaps of network data you already have.
A practical guide to finding NAT Traffic
In a previous post, we described how to search for NATed traffic within Scrutinizer. No matter which solution you are using to collect NetFlow and metadata, you’ve likely noticed that when your firewall creates a NAT address, that address becomes the source and destination within your flows. This makes your flow data less useful. In this post, I’ll share how you can better leverage your flow and metadata to see exactly which devices on your network are making external requests. In addition, I will provide an updated guide on how to search for devices and IP in Scrutinizer. Given that the last post was back in 2009, many things have changed!