Active Server Ports

I spent most of last week on the road visiting customers. Many of them were working on projects to reduce the number of physical servers hosted in their data centers. In some cases, they wanted to move the servers to cloud services such as AWS or Azure. In others, they wanted to virtualize the servers locally on platforms such as VMWare ESX.

One of the challenges many network managers have is how to determine what network ports are active on servers and what ports were active in the past. When one device sends traffic to another, the IP address is used to route that traffic to the appropriate place. Once the traffic reaches the right place, the device needs to know which app or service to send the traffic on to. That’s where ports come in. An active server port is one which is ready to accept connections from a clients. Examples include TCP port 80 for HTTP and TCP port 25 for SMTP email.

Network managers need a real time and historical report showing them what ports were in use so that they can update firewall rules and access lists. Many networks now contain trusted systems such as company owned PC’s, but also non trusted systems such as contractor’s laptops. It is vital that you protect servers by only allowing connections on certain ports and from certain networks.

Generating a list of active server ports

While command line utilities such as netstat can give you a real-time view of network connections (both incoming and outgoing), it does not provide historical reporting. Some network ports on a server may only become active when certain applications are used.

Another option is to monitor network traffic going to and from your servers. If the server accepts a connection on a certain port, it will generate network traffic. All you need to do is monitor that traffic using a SPAN, mirror port or TAP, and capture the active port metadata. The metadata will reveal the source IP addresses, port information and the amount of data transferred.

Network traffic analysis systems, which are application aware, can also reveal what applications are running on the server. You may have a web server running over a non standard port like TCP port 8000, for example.

Reporting on active server ports using LANGuardian

Our LANGuardian product can provide a real-time and historical view of what ports are active on your servers. It does this by analyzing network traffic and then extracting application and port information which is stored in a database.

The screenshot below shows a sample report where I focus on a server (10.1.1.97). Use the search box at the top of the LANGuardian GUI and enter ports. Select the report Bandwidth :: Ports, Services and Protocols. Enter the IP address of the server you want to query into the Destination IP/Subnet field, select a time range for the report, and then run it. Click on the image below to access a sample report on our online demo.

The total column in this report shows the amount of data that has been sent or received by the server on each port number for the selected time period. The Server Port (Service) column lists the ports that were active on the server. Clicking on the Total column will also reveal what applications are using the ports. You just need to drill down to the Bandwidth :: Sessions report and check the protocol column. Click on the image below to access a sample report on our online demo.

If you have any questions about how to monitor traffic on your network using LANGuardian, or would like to know more about how it can be used to report on what ports your servers are using, do not hesitate to contact us and speak with our technical support team.

What is DNSpionage?

Late last year, Cisco Talos discovered a DNS hijacking attack targeting Lebanon and the United Arab Emirates (UAE) affecting .gov domains, as well as a private Lebanese airline company.

Talos said the perpetrators of DNSpionage were able to steal email and other login credentials by hijacking the DNS servers for these targets, so that all email and virtual private networking (VPN) traffic was redirected to an Internet address controlled by the attackers.

How can you detect the presence DNSpionage activity on your network?

Earlier this year, security firm CrowdStrike published a blog post listing IP addresses and domain names known to be used by the espionage campaign to date. If you want to check for the presence of DNSpionage activity on your network, you should monitor network traffic at your networks perimeter and watch out for any activity associated with the IP addresses or domains.

Using LANGuardian to detect DNSpionage activity

Our LANGuardian product includes both a network traffic analysis module which can capture IP addresses and a DNS decoder to extract metadata from DNS queries. You just need to monitor network traffic going to and from your Internet gateways to gain visibility into what is happening and root out any suspicious activity.

Once you have LANGuardian deployed, you need to check two reports for DNSpionage activity.

Check applications report for any traffic associated with the IP addresses connected to the espionage campaign.

1. Log onto your LANGuardian and click on All Reports / Applications in Use
2. Enter the IP range listed above into the Source or Destination IP/Subnet report filter
3. Run report
4. Optionally you can save this as a custom report by clicking on Actions / Save As

You should not see any results in the report when you run it. If you do, you need to check the systems on your network that are communicating with the IP addresses. The image below shows the report output from my lab network, no results returned which is what you are aiming for. Click on this image to access this report on our online demo.

Check DNS queries for any lookups associated with the domains connected to the espionage campaign.

1. Log onto your LANGuardian and type DNS Lookups into the search box top center. Select the report Network Events (DNS Lookups)
2. Enter the domain list shown above into the Domain report filter. Select Matches regexp from the dropdown
3. Run report
4. Optionally you can save this as a custom report by clicking on Actions / Save As

You should not see any results in the report when you run it. If you do, you need to check the systems on your network that are trying to resolve one or more domains from the list. The image below shows the report output from my lab network. I do show some activity and I will need to do further analysis of the local client 10.1.1.159.

How to monitor network traffic going to and from the Internet.

The video below shows the steps needed to get traffic monitoring in place so that you can check for DNSpionage activity on your network

Click here to see a list of other DNS posts on our blog.

https://www.netfort.com/search/dns

What are network security monitoring tools?

Network Security Monitoring is the collection, analysis, and escalation of indications and warnings to detect and respond to intrusions on computer networks. Network security monitoring tools typically have features such as:

• Network-based threat detection
• Proactive network queries for security data and/or “hunting” for suspicious behavior
• Integration with one or more threat feeds
• Create and automate security alerts

A lot of the development focus in recent years has been in the areas of better threat feeds and web front-ends. We now have network security monitoring tools which can pull threat intelligence from multiple sources and display alerts in fancy dark themed web interfaces. The image below shows a typical output of a modern network security monitoring application.

Recently, I heard about an interesting LANGuardian use case where a customer used their system to carry out forensics on an event triggered by their network security monitoring tool. While LANGuardian can be used as a network security monitoring tool, this customer had a secondary system to make use of other threat feeds.

Why traffic capture is very important when it comes to network security monitoring.

One of the issues with many network security monitoring tools is that they only generate alerts; often good alerts or “actionable alerts” as some of our customers call them. A typical event will display the source IP address (system that caused the event), destination IP address (system that was targeted), event description, and a priority rating.

However, sometimes you need more than just an alert in order to fix problems on a network. Other pieces of metadata can be just as important as the alert itself. Examples include:

1. What inbound and outbound network connections were active to the destination IP address at the time the event was triggered?
2. Any other events associated with the destination IP address?
3. What DNS queries were associated with the destination IP address?
4. If the source IP address is on the LAN, is there any unusual activity associated with it (items 1 to 3 above)?

Network traffic metadata is an ideal data source to compliment your network security monitoring tool because it will provide you with extra context, so you can gain a better understanding as to why security events are triggering on your network. It delivers detail without the complexity and costs associated with full packet capture.

Network metadata is typically captured via a SPAN, mirror port or TAP. A common setup is to monitor network traffic at your networks core; where the most interesting traffic converges. Network packets are sent to a deep-packet inspection application which can extract readable information such as filenames, web sites, applications, protocol versions, etc. This information is then stored in a database which can be used for real time or historical analysis.

Using LANGuardian to combine network security monitoring and traffic analysis.

Our LANGuardian product includes both network security monitoring and traffic analysis modules. The image below shows a sample output where we are looking at activity associated with a single IP address. On the left we have traffic and application information, and on the right we have the output of it’s intrusion detection system. Click on the image to access this dashboard on our online demo.

If you have any questions about how to monitor traffic on your network using LANGuardian, or would like to know more about how it can be used with other network security monitoring tools, do not hesitate to contact us and speak with one of our technical support team.

Alert on Rogue DHCP Servers Using Network Traffic as a Data Source

Recently a customer came to us with the following query:

“We were wondering whether there is a way to setup an alert on LANGuardian if we see any other DHCP servers on the network other than our own – particularly on the 192.168.0.0/24 range. We have DHCP snooping on all our newer switches, but not on some the older ones. We have used LANGuardian to do this manually with a report – but an email alert would be great.”

The ability to detect DHCP servers is a feature that has been in LANGuardian for some time, but more and more customers want alerts if a rogue DHCP server appears on the network.

Rogue DHCP Servers & Their Risks

A rogue DHCP server can be defined as one which is not managed by IT. It could be a wireless router added to the network by a user or someone enabling DHCP services on a server.

As clients connect to the network, both the rogue and legal DHCP server will offer them IP addresses as well as a default gateway; DNS servers, WINS servers, and others. If the information provided by the rogue DHCP differs from the real one, clients accepting IP addresses from it may experience network access problems, as well as an inability to reach other hosts because of an incorrect IP network or gateway. IP conflicts can cause problems for existing clients and they may also experience network access problems.

In addition, if a rogue DHCP is set to provide as a default gateway, such as an IP address of a machine controlled by a misbehaving user, it can sniff all the traffic sent by the clients to other networks. This is typically referred to as a man in the middle attack.

Detecting DHCP Servers

One of the easiest ways to detect DHCP servers on your network is to monitor network traffic via a SPAN, mirror port or TAP. Once you have your packet data source, watch out for DHCP offer packets. These are sent by DHCP servers when a client sends out a broadcast packet looking to discover a DHCP server.

The image below shows the output of a DHCP request sequence which was captured using Wireshark. You can use the bootp filter to exclude other packets from the display. This approach is particularly useful for smaller networks where the traffic volumes are low. For larger networks, you may want to consider a dedicated traffic analysis system such as our own LANGuardian.

LANGuardian comes with a set of DHCP reports. To access these, type DHCP into the search bar at the top of the web GUI and select Services :: DHCP Servers. You can filter based on a specific subnet by using the Server report variable on the left hand side. The image below shows an example of the report output. It lists all active DHCP servers for a selected time period. Click on it to access this report on our online demo.

Generating Alerts if Rogue DHCP Servers Are Detected.

While running DHCP server reports are useful, most of us do not have the time to do this on a regular basis. Another useful feature of LANGuardian which can help here is the in built alerting engine. For example, I want to generate an alert if a DHCP server is detected within my 192.168.0.0/24 network range. The steps involved to get this alert setup are:

1. Log onto your LANGuardian web interface and click on the gear symbol top left. Select Settings
2. Within settings select Alert rules
3. Click on Add New Rule.
4. Assign a name to the rule, like Rogue DHCP Servers
5. Select the DHCP module from the dropdown
6. Enter the text server_ip=192.168.0.0/24 && message_type=2 as the rule and then save

You may need to change the IP range to match your own network IP ranges. The image below shows the rule definition on my LANGuardian.

If you have any questions about how to monitor traffic on your network using LANGuardian, or would like to know more about how our network traffic monitoring tool can be used to detect rogue DHCP servers, do not hesitate to contact us and speak with our technical support team.

What is RYUK Ransomware?

An advisory from the US based Department of Health and Human Services notes that attacks involving RYUK appear to be targeted. In fact, its encryption scheme is intentionally built for small-scale operations, so that only crucial assets and resources are infected in each targeted network by a manual distribution from the attackers.

Targeted companies are selected one at a time, either via spear-phishing emails or Internet-exposed, poorly secured RDP connections. RDP allows remote use, even of fully-graphical applications that can’t be scripted or operated via a command prompt.

RYUK uses an AES-RSA combo encryption that’s usually undecryptable, unless the RYUK team made mistakes in its implementation. The encryption method that RYUK uses is more or less identical to that of the Hermes malware.

Previous versions of the Hermes ransomware have been an on-and-off threat that surfaces at random intervals with a mass spam campaign. The new RYUK ransomware strain appears to be a new attempt from the Lazarus Group at developing a SamSam-like strain to use in precise surgical strikes against selected organizations

Monitoring File Activity on Your Network

You need to be monitoring file and folder activity before you can detect active Ransomware, like RYUK, on your network. One of the easiest ways to do this is to monitor network traffic going to and from your network file servers. Most managed switches support SPAN or mirror ports and these allow you to get a copy of the network packets going to and from your file servers.

Once you have your data source in place, you can use a tool like our own LANGuardian to extract file and folder metadata from the network packets. Metadata includes information such as filenames, actions and usernames.

As well as monitoring traffic associated with your file servers, we also recommend that you monitor all traffic at your network perimeter (just inside your firewall). Ransomware needs to communicate with the outside world, so having visibility at the network edge is important when it comes to detecting and alerting on Ransomware like RYUK.

The image below shows some of the things that you should watch out for when it comes to RYUK Ransomware.

1. Watch out for an increase in file renames.

2. Watch out for any files on your network with the .RYK extension.

RYUK encrypts data using a cryptography algorithm, thereby rendering files stored on a computer unusable. It appends the “.RYK” extension to each encrypted file, thus renaming all affected files. For example, “budget.xlsx” becomes “budget.xlsx.RYK”.

Use LANGuardian’s Search by File/Folder Name report to filter any file with the .RYK extension.

3. Check network shares for ransom notes

When files are encrypted on your network by RYUK Ransomware it will leave a ransom note in the format of a text file. The ransom message within “RyukReadMe.txt” is from RYUK developers who inform victims that all data has been encrypted using a strong cryptography algorithm. They state that encrypted backups and shadow copies have also been encrypted.

RYUK ransomware developers also state that only they can provide victims with a decryption tool, and no other tools are capable of decryption. In summary, they make it clear that no other party can help with RYUK infected computers. These cyber criminals also warn users that shutting down or restarting a computer might cause damage or data loss. They urge people not to delete or rename the “RyukReadMe.txt” text files.

RYUK developers offer free decryption of two files to prove decryption is possible and in an attempt to give the impression that they can be trusted. To decrypt the remaining data, users must contact them. However, it is recommended that you do not contact the RYUK developers under any circumstances.

Instead, use LANGuardian’s Search by File/Folder Name report to filter any file with the name RyukReadMe.txt

If you have any questions about how to detect RYUK Ransomware or other variants on your network, do not hesitate to contact us and speak with one of our helpful technical support team.

What is RADIUS?

RADIUS stands for Remote Authentication Dial In User Service. A RADIUS server can support a variety of methods to authenticate a user. When it is provided with the username and original password, given by the user, it can support PPP, PAP or CHAP, UNIX login, and other authentication mechanisms.

Typically, a user login consists of a query (Access-Request) from the NAS to the RADIUS server and a corresponding response (Access-Accept or Access-Reject) from the server. The Access-Request packet contains the username, encrypted password, NAS IP address, and port.

Why the need to capture username from RADIUS traffic?

Many of our customers who provide wireless access on their networks use RADIUS to authenticate users. Active Directory is often used to authenticate wired devices or devices which can be managed and added to the Active Directory domain. However, if you allow unmanaged devices onto your network, like you would in a University, RADIUS is a better choice for user authentication.

A few years ago, we added Active Directory integration to our LANGuardian product as customers wanted to associate network activity to usernames rather than IP addresses. We implemented this by collecting user logon events from domain controllers and storing them locally on LANGuardian where they could be cross referenced by running a report.

Initially, RADIUS integration seemed to be more complicated. As you can deploy the system on different platforms, you never have a standard source of user logon events. However, a customer of ours, an Information Security Manager at a Scottish university, suggested a new way to capture usernames during an onsite meeting. He said that it may be possible to capture usernames directly from network traffic.

They had large wireless networks and wanted usernames so they could save time troubleshooting operations and security issues. Their LANGuardian instance was highlighting user and application issues, but the source was always an IP address. They then had to spend more time working out what user was responsible by manually checking logs.

We took a sample PCAP from their network and used it to build a passive RADIUS username capture module. The image below shows how usernames can be seen within RADIUS.

Passive capture of usernames from RADIUS traffic using LANGuardian

LANGuardian captures traffic from both a SPAN port and other traffic sources. It then uses deep packet inspection techniques to consolidate and correlate the data gathered by the traffic collection engine. In essence, we have a series of application decoders for popular applications like SMB, SQL, Web, and Email. Our latest release includes a decoder for RADIUS traffic.

The image below shows the basics of how our RADIUS traffic decoder works. Firstly, we receive network packets (1) from a SPAN mirror port or TAP (2). The LANGuardian content based recognition engine (CBAR) then detects the CBAR protocol (3) and sends the data to the RADIUS traffic decoder. This decoder extracts relevant metatdata (4) like username, IP address and time/date of logon. RADIUS Accounting needs to be enabled as LANGuardian utilises RADIUS Accounting to retrieve usernames from the traffic.

Once you capture usernames with LANGuardian, you can use this data with any LANGuardian report. The first example below shows how you can monitor network traffic to find out who is doing what on the Internet. Click on the image to view the report on our online demo.

In the next example, we show how you can generate an audit trail of file and folder activity (SMB and NFS) with usernames. This can also be used to root out security issues such as SMBv1 use on a network. Click on the image to view the report on our online demo.

If you have any questions about how to analyse RADIUS traffic on your network and extract usernames, or would like to know more about how our network traffic monitoring tool can meet your organization´s requirements, do not hesitate to contact us and speak with one of our helpful technical support team.

More reasons to check inbound traffic on your network

Looking though the latest infosec news this week I spotted two exploits which use similar attack methods.

• Printers targeted via TCP port 9100 by external clients
• Poorly configured Ethereum nodes targeted over port 8545

In both cases hosts located outside your network try to connect to devices hosted inside your LAN or cloud environments. The printer exploit is an unusual one. It’s main purpose is to deliver PewDiePie propaganda around the world. PewDiePie is currently the most subscribed to channel on YouTube. Recently it has been in a battle for this position with an Indian company called T-Series.

Over the last couple of days, Twitter users have been posting screenshots of unsolicited printouts from internet-connected printers that say that PewDiePie needs their help. A Twitter user called TheHackerGiraffe has claimed responsibility but had claimed they did this to raise awareness of printers and printer security.

The second inbound exploit attempt has a more sinister background. A cybercriminal group has managed to steal a total of 38,642 Ethereum, worth more than $20,500,000, from clients exposing the unsecured interface on port 8545. The process behind this is simple. External clients scan your network on port 8545, looking for geth clients and stealing their cryptocurrency. Geth is a multipurpose command line tool that runs a full Ethereum node implemented in Go.

How to monitor inbound traffic on your LAN

One quick check you can do to check for port 9100 or 8545 activity is to check if the ports are open on your firewall. While this is not an indication of activity you should consider shutting them down for all external clients.

A better approach is to monitor network traffic going to and from the Internet using a SPAN, mirror port or network TAP. Once a traffic source is established you can use a product like our own LANGuardian to report on what ports and applications are been used.

The image below shows an example of what to look out for. In this case we can see evidence of SMB activity. Ports like 9100 or SMB which uses 445 should not be open for unknown clients. Click on the image below to access this report on our online demo.

In the next example we are looking at what ports are accepting connections from external clients. Again we can see the activity on TCP port 445. Looking though the results, I also need to check the activity on port 49158. Click on this image to access the report on our online demo.

In order to check your firewall configuration and get visibility of traffic at an application level allowed in through your firewall, simply deploy a traffic analysis system such as LANGuardian and configure the sensor SPAN or mirror port correctly.

You can easily use a SPAN port for example to monitor traffic from your  internal network to and from the firewall. A very useful and simple validation of those firewall rules sometimes configured by an external consultant. The video below goes through what is needed to get network traffic analysis in place at your network edge together with the steps to get LANGuardian in place monitoring this traffic.

How to monitor inbound traffic in the cloud

When an infosec alert like the ones mentioned above goes out, the oblivious thing to do is check your on premise data centers for suspicious activity. This is certainly a good starting point. However, don’t forget about your cloud based networks. They may be targeted even more than your on premise networks. Getting visibility in the cloud is not as straightforward as with a more traditional on premise network.

Recently we announced support for AWS VPC Flow Log Analysis and we will also have an option for Azure monitoring shortly. I took a look at reports associated with our AWS estate and sure enough there is evidence of inbound activity on port 9100, see image below. In our case this was blocked. I observed similar activity for inbound connections on 8545.

If you have any questions about how to monitor traffic on your network using LANGuardian, or would like to know more about how our network traffic monitoring tool can meet your organization´s requirements, do not hesitate to contact us and speak with one of our helpful technical support team.

What our customers want to extract from PCAP files

In my previous blog post on the topic of PCAP file management, I looked at how you can import and export PCAP files from LANGuardian. Since then we had a number of queries come in from customers and website visitors. One in particular caught my eye. It came from a network engineer who had very specific requirements. They have a large PCAP repository and they need a tool to process these files and provide reporting on:

1.  Identify all the unique IP addresses involved in the PCAP, sources and destinations
2. Identify the “big talkers” which IP’s account for sending and receiving the most traffic. ideally a list of IP’s, packets sent, and the number of packets received  WITH the ability to sort by # of packets sent or received (that would show the big talkers)
3. The types of traffic by protocol
4. I need to have some ability to utilize an AV engine against the traffic. One way to do this with Wireshark is typically via tcpreplay, you set up a “clean system” with IDS enabled then tcpreplay to it suspect packets and watch it’s alarms/logs.

Why can’t you use Wireshark for analyzing PCAP files?

Wireshark is an excellent tool and I use it a lot myself. The most common features I use are the packet analysis and Follow TCP Stream options. What it is not good at is giving you a top level view, a summary of what went on with drill down capability to get to the detail. Another limitation is the ability to cross reference the data in the packets with threat databases or IDS signatures.

Wireshark doesn’t work well with large network capture files (you can turn all packet coloring rules off to increase performance). Some of the most interesting network data can be sourced from a SPAN or mirror port but these data sources will result in large PCAP files.

Identify all the unique IP addresses involved in the PCAP, sources and destinations

Every packet of data in a PCAP file will contain source and destination IP addresses. A modest sized PCAP could contain thousands of addresses so you need a quick and efficient way to capture these and store them in a database.

Wire data analytics is often referred to the process where metadata such as IP addresses is extracted from PCAP files or directly from the network when you monitor network traffic from a SPAN or mirror port. The image below shows a sample of this network inventory type information which LANGuardian can extract from a PCAP file. Click on the image to access this report in our online demo.

Identify the “big talkers” which IP’s account for sending and receiving the most traffic

Some time ago I spoke to a LANGuardian customer who had just purchased the system for a client. They had found us while searching on the Internet for a tool which would “analyze PCAP files that I had collected from a customer’s network that was struggling with VOIP quality issues and massive bandwidth utilization“.

They also reported that “While I read and understand PCAP files fairly well, when it came time to analyze the date and determine who my top talkers are I was at a loss.” This is one of the big problems with tools like Wireshark, sometimes it can be hard to get that summary information. Who are the top talkers on the network.

Our customer installed LANGuardian and within a short period reports that “The LANGuardian software quickly pointed out several computers that were flooding the network with data and a network switch that was faulty. Our customer mitigated those problems and has had great VOIP quality and lower total bandwidth utilization on their LAN and WAN.”

The image below shows the output of the LANGuardian Top Talkers by Traffic Volume report. If you click on the demo you can access this report on our online demo.

The types of traffic by protocol

Protocol recognition is the art and science of identifying the applications that are in use on a network and understanding the impact of each application in terms of bandwidth usage, user behavior, security, and compliance.

LANGuardian content-based application recognition (CBAR) approach to application recognition combines a unique deep packet inspection algorithm with detailed understanding of the underlying protocols. Unlike other traffic monitoring technologies such as NetFlow, which analyzes packet headers only, LANGuardian CBAR analyzes entire traffic packets and inspects their content.

By inspecting the packet content in addition to the header, LANGuardian CBAR can see past the port and address information to identify the application and/or protocol that generated the packet. The image below shows the output of the LANGuardian Applications in Use report which shows the top protocols found in a PCAP file ordered by total bandwidth. Click on the image to access this report on our online demo.

Ability to utilize an AV engine against the traffic

When I read this requirement first I was confused. How could we replay traffic against an antivirus engine. Most antivirus systems run as a service and may check memory, disk, and other data sources for the presence of malware or viruses. I checked back and what they meant was if we could run the contents of the PCAP files past an IDS or threat database.

In the case of LANGuardian, we have both an IDS and traffic analysis module running in parallel. When you import a PCAP file, the contents is sent to each analysis engine where it is checked for signs of suspicious content. You can also write your own IDS signatures to search for specific text strings within the PCAP files. The video below goes through the process of creating a custom IDS signature to check for the presence of a text string.

If you have any questions about how to monitor traffic on your network using LANGuardian, or would like to know more about how our network traffic monitoring tool can meet your organization´s requirements, do not hesitate to contact us and speak with a member from our technical support team.

Working With PCAP Files

PCAP or packet capture files can be extracted from the network by using applications such as Wireshark or exporting them from network devices such as firewalls. They contain one or more network packets which can be used for troubleshooting network or application problems.

While they are useful for troubleshooting a very focused event, they can become difficult to work with if you capture traffic from multiple network devices. You may end up with millions of network packets which can be very time consuming if you try and review each one.

PCAP Features of LANGuardian

Capturing network metadata is an ideal approach when it comes to handling large packet captures. Just capture the human readable bits like IP address or SMB filename and discard the rest of the packet data. This is the approach we have used in our LANGuardian product for many years.

However, when reviewing customer feature requests, we noticed that a few had requested direct access to the traffic on the actual SPAN/mirror port or TAP connected to the LANGuardian. When we asked why the response made perfect sense:

“Sometimes when troubleshooting issues we need to direct access to all the traffic to get to the detail and proof we need. So we usually  take a packet capture and analyze it with tools like Wireshark.

Instead of grabbing a laptop, going down to the server room plugging it into the correct location, why not use our LANGuardian sensors? You guys are already connected and have access to the traffic across our network, we would like to use your sensors to take a PCAP very easily when we need to.”

A simple request, took some effort to implement but has been very well received. Even this week for example I was on a call with a prospect who was using our LANGuardian and our GEO IP reports had spotted a machine on his network trying to make a connection to a server in China. He reckoned it was probably a bug in our software and said ‘Let me get my laptop and take a PCAP’. I  immediately told him that we can do it immediately using the LANGuardian.

He took the PCAP, we analyzed it, it had the same strange IP address and it verified our LANGuardian reports. Turns out that a well knows security appliance was making the connection request for some reason and he immediately contacted them.  Interesting use case which also shows how important it is to have ‘eye on the traffic’ everywhere and have easy access to the traffic.

Extracting PCAP files from LANGuardian

You can extract network packets with or without filters by using the PCAP File Management page. To extract network packets, you must follow these steps:

1. Choose a network interface to capture packets from. It can be a local interface or an interface on a remote LANGuardian sensor.
2. The filter field is optional. Common examples would be:
   • host 10.1.1.100 – which captures all traffic associated with 10.1.1.100
   • host 10.1.1.100 and port 80 and port 25. Traffic associated with host 10.1.1.100 can be captured on ports 80 and 25.
   • Further examples can be found on this wireshark wiki page
3. When it comes to the number of packets, choose a small value like 100 initially. The more packets you capture, the larger the PCAP file.
4. Choose a file name. Be sure to use the .PCAP extension if you want applications like Wireshark to recognize them.

The video below shows an example of this feature in use:

Importing PCAP files into LANGuardian

PCAP files can be sourced from many applications and systems. The most popular would be standalone applications like Wireshark or extracted directly from firewall appliances. If you capture traffic for an extended period or from a SPAN or mirror port, they can be large and take time to analyze if you go through one packet at a time.

You can import a PCAP file from any source into LANGuardian. Once the file is imported, it is sent to an IDS and traffic analysis application. The steps involved to import and view the data are:

1. Log onto your LANGuardian instance and click on the gear symbol on the top right. Select PCAPs
2. Choose the option to Upload PCAP file
3. Upload your PCAP file and then click on Process
4. Click on reports and select Applications in Use. This will show what application activity was captured within the PCAP.
5. From the sensor drop down, select your PCAP sensor and then run the report
6. You can repeat the process with the Top Network Events report to check for any Malware or suspicious activity within the PCAP

The video above goes through this process. PCAP import section starts at 3:40.

If you have any questions about how to monitor traffic on your network using LANGuardian, or would like to know more about how our network traffic monitoring tool can meet your organization´s requirements, do not hesitate to contact us and speak with a member from our technical support team.

Why does Google sometimes show unusual traffic messages?

Recently I worked with a number of network managers who downloaded our LANGuardian software to try and find the source of malware on their networks. The issue they faced was that clients were been presented with the message “Our systems have detected unusual traffic – possibly Malware from your computer network” when they tried to access Google services.

You then get a reCAPTCHA. To continue using Google, you have to solve the reCAPTCHA. It’s how Google knows you’re a human, not a robot. After you solve the reCAPTCHA, the message will go away and you can use Google again. The image below shows an example of what is displayed.

Google closely monitors what network traffic is directed at their infrastructure. If devices on your network seem to be sending automated traffic to Google, you might see “Our systems have detected unusual traffic from your computer network.” Google considers automated traffic to be:

• Searches from a robot, computer program, automated service, malware (true?) or search scraper
• Software that sends searches to Google to see how a website or webpage ranks on Google

The main reason behind all of this is that Google does not want any automated traffic which is designed to influence search results.

How can I monitor Google traffic on my network?

All Google traffic will flow in and out of your Internet gateways so this is where you need to capture traffic. Use a SPAN or mirror port to capture a copy of traffic going to and from your firewall. Make sure you capture the data inside your network so you can identify what client is sending unusual traffic.

The image below shows a typical setup if you want to detect any unusual traffic on your network. In this we use our LANGuardian traffic analysis tool to monitor traffic coming from a SPAN\Mirror port on our core switch. LANGuardian is deep-packet inspection software that monitors network and user activity. The core switch is configured to send a copy of all traffic going to and from the firewall to the monitoring port which is also known as a SPAN or mirror port.

What traffic reports do I need to look at?

Our LANGuardian product is available as a 30 day trial. This should give you enough time to get to the root of the problem. Once you have the trial installed there are two key reports to focus on. Use the search bar at the top of the LANGuardian GUI to search for these reports:

• Top Website Domains with Client IPs (Page Hits)
• Top Website Domains with Client IPs

In both cases enter Google into the Website Domain report filter on the left. The first report will show the top clients connecting to Google services based on the number of connections. The second report shows the top clients on your network connecting to Google services based on traffic volumes. Unusual traffic would be seen as a client which is establishing thousands of connections in a short time period like one hour. Unusual traffic volumes can be seen as multiple gigabyte levels to Google search or Google API services.

Click on the image below to access our online demo and see what the reports look like.

If you have any questions about how to monitor traffic on your network using LANGuardian, or would like to know more about how our network traffic monitoring tool can meet your organization´s requirements, do not hesitate to contact us and speak with one of our helpful technical support team.

Monitoring traffic on your network is important if you want to keep it secure and running efficiently. The information obtained by network traffic monitoring tools can be used in multiple security and IT operational use cases to identify security vulnerabilities, troubleshoot network issues and analyze the impact new applications will have on the network. These 5 tips should help you get the most out of your network traffic monitoring application.

1.    Choose the right data source

Whatever your motive for monitoring network traffic, you have two main data sources to choose from:

1. Flow data: which can be acquired from layer 3 devices like routers
2. Packet data: which can be sourced from SPAN, mirror ports or via TAPs

Flow data is great if you are looking for traffic volumes and mapping the journey of a network packet from its origin to its destination. This level of information can help detect unauthorized WAN traffic and utilize network resources and performance. However, flow-based tools for monitoring network traffic lack the detailed data to detect many network security issues or perform true root cause analysis.

Packet data extracted from network packets can help network managers understand how users are implementing/operating applications, track usage on WAN links, and monitor for suspicious malware or other security incidents. Deep packet inspection tools provide 100% visibility over the network by transforming the raw metadata into a readable format and enabling network managers to drill down to the minutest detail.

The image below shows a good approach when it comes to network traffic monitoring for most networks. A SPAN or mirror port is configured at the network core which allows for the capture of any traffic passing through. In my example this would allow me to capture traffic going to and from the Internet as well as traffic associated with important servers.

4.   Associate the data with usernames

Traditional network traffic monitoring tools usually report on activity using IP or MAC addresses. While this is useful information, it can be problematic in DHCP environments if you are trying to find a problematic device. One piece of information that can bring together network activity and devices is usernames. Username association will let you know who is doing what on the network.

5.    Check the flows and packet payloads for suspicious content

Many networks have intrusion detection systems at the edge but very few have this type of technology monitoring internal traffic. All it takes is one rogue mobile or IoT device to compromise a network. Another issue I often see are firewalls allowing  suspicious traffic through where a rule was misconfigured.

The image below shows an example of this: someone created a rule to allow traffic inbound on TCP 5901 (VLC remote desktop sharing), but they did not limit it to one source and destination. The source addresses in this case appear to be registered in China and connections from this country would not be expected to connect to this network.

Summary

Not all tools for monitoring network traffic are the same. Generally they can be broken down into two types – flow-based tools and deep packet inspection tools. Within these two types you have the choice of tools that use/don´t use software agents, tools that store/don´t store historical data, and tools with intrusion detection systems that monitor network traffic within the network as well as at the network edge.

• Choose flow based analysis tools if you want to get traffic volumes and IP addresses associated with WAN or other layer 3 links
• Choose packet analysis tools if you need traffic volumes, IP addresses and more detail to investigate security or operational issues.

If you would like to discuss any of the points raised in this article, do not hesitate to contact us.

Tracking Mobile Devices on Your Network

In this video we look at how you can monitor mobile devices on your network using LANGuardian. LANGuardian is deep-packet inspection software that monitors network, device, and user activity. It uses network traffic as a data source and is typically connected to a SPAN or mirror port at the core of a network.

The video also has a section on how you can choose the best point on your network to monitor traffic associated with mobile devices. A traffic analysis approach does not require the installation of client or agent software on your wireless or mobile devices.

As the video shows, every device (fixed and mobile) and user on a network leaves a traffic trail. This traffic trail contains very useful information and context but due to the large volumes on traffic on network these days and the inherent complexity of traffic, this trail is not easy to read and interpret. Our LANGuardian network traffic analysis engine tries to do the ‘heavy lifting’ extracting the application specific metadata and making it useful and usable for organizations of sizes, even SMEs with limited resources and time.

The screenshot above is a very good example of the useful detail buried deep in normal network traffic. This packet payload shows an iPhone making a HTTP request, our LANGuardian DPI engine looks inside the packets extracting and storing crucial information like the IP address, operating system and device type. Vendor agnostic, always ‘on’, network traffic is a very useful data source on any network. You just have to ‘tap into it’ to get immediate internal visibility of devices, users and activity.

Network Traffic Metadata – Four recent customer use cases

The rising popularity of network traffic metadata is because it’s in the sweet spot between full packet capture like Wireshark and PCAPs on one hand and NetFlow on the other, which lacks detail and drill down. Drill down, granularity, context, and continuous internal visibility are now absolutely critical for organizations of all sizes including SMEs.

Historically, network traffic analysis based technologies (mostly full packet capture) were seen as too complex and expensive for SMEs and only ever seen on Enterprise networks. Application centric metadata has now made internal visibility a reality for all organizations.

Use Case 1: Monitoring Web Activity Over HTTPS

The opening packets of a TLS/HTTPS session are not encrypted and are sent in clear text. However, the NetFort DPI (Deep Packet Inspection) engine has the ability to conduct an IDP (Initial Data Packet) analysis on these clear text packets, extract the SNI (Server Name Indication) field sent by the client, and the certificate that the server presents.

This allows LANGuardian to report on the domain being accessed, the client and server IPs, port numbers, as well at other attributes of the connection such as the protocol used (SSL 1.0, 2.0 or TLS 1.0 1.2 etc), ciphers used or attributes of the server certificate (SHA1 or SHA256 etc). A similar technique works with Google QUIC encrypted UDP protocol.

Click on the image below to see how this report works on our online demo

Use Case 2: Alert on Rogue DNS Servers

LANGuardian includes a DNS metadata decoder which monitors DNS traffic, decodes and logs all DNS replies, and enables the ability to go back and review all resolutions clients are receiving. As a result, it generates an inventory of DNS servers by Geo IP location.

Use Case 3: Contractors’ iPhone Copying Data

The LANGuardian’s web client, user agent module generates every web client packet payload and records useful metadata such as source IP address, device and operating system information.

Metadata also results in a 400:1 data reduction over full packet capture in a granular but cost-effective data retention, ideal for forensics and investigations. LANGuardian includes a Google like search utility for all user activity retained in the built in database. This information was recently used to investigate the activity of a contractor on an medium enterprise network who had used an iPhone to access and copy internal data.

Use Case 4: Monitor File and Internet Access For a Single User.

LANGuardian’ s network traffic analysis engine also includes decoders for all ‘unstructured data’ activity, including Windows (SMB), UNIX and (NFS) file shares and even MS SQL databases. This results in an inventory of such systems on the internal network and an audit trail of all activity by IP, MAC address and user name.

Using our search facility, it is possible to achieve a consolidated view of all internal and Internet network activity by user name for any time period. It is also possible to configure alerts for certain file activity, including file or folder deletes. No agents or clients required, therefore network metadata is an excellent non-intrusive option for monitoring network user activity.

Visit our live system HERE to see more examples of the unparalleled levels of visibility you can easily achieve on your network by using traffic metadata.

Users Leaving? How to get an audit trail

Network users come and go. When new employees start we create sign on accounts and assign any relevant permissions. When employees leave we typically transfer their data over to someone else and disable any logon accounts.

During this transition period, an audit trail can be an invaluable resource. Sometimes users think they are doing everyone a favor by deleting what they think is old data or they move data around without telling anyone. In other cases, users may copy large volumes of data from the network with the intention of using it in their new job.

There are two main ways of getting an audit trail of user activity on your network. You can either install client\agent software on every network device or you can monitor network traffic inside your network. Client or agent software can be problematic as users can disable it or it may not be feasible to install it on personal devices.

Network traffic analysis is the most independent with no requirement for any client software or server logs. You just need to capture network traffic at the correct points and extract the relevant metadata. It is an ideal data source for network visibility, security, and compliance.

Monitoring Network Traffic

Network traffic analysis tools use deep packet inspection technologies to extract certain metadata from network traffic. Traffic is typically captured at the core of a network using a SPAN, mirror port, TAP or packet broker. Metadata can be something like a filename or a SQL query. When captured and stored this metadata can be then used to build an audit trail of user activity.

Focusing on an individual user for a specific time period

Recently we heard from a customer who had an issue when an employee was leaving. This employee moved, renamed and deleted some files off network shares. Using their LANGuardian, the network manager was able to get an audit trail of file and folder activity to find out what had been changed. It was then just a matter of putting everything back in its original location which saved the IT department a lot of time trying to figure out what files needed to be restored.

The image below shows a sample of the LANGuardian file activity monitoring reports. Data in this report is acquired by analyzing the network traffic associated with the SMB or NFS protocols.  Here we can see where user Leo deleted a profit and loss database together with the exact date and time when this action was seen.

It may also be worth looking at other user metadata when suspicious file activity is observed. The image below from a LANGuardian system shows that this user accessed some customer and sales data (1) and at the same time, data transfers were associated with Dropbox (2).

Cloud-based storage systems like Dropbox can be used to copy data out of a network and you may want to set up alerts if activity like this is detected on your network. We will follow up with another post showing how you can set this up with LANGuardian, just subscribe to our blog to get updates.

Click on the image below to access the user forensics section of our online demo.

What is RDP? (Remote Desktop Protocol)

RDP is a proprietary protocol developed by Microsoft. It provides a user with a graphical interface to connect to another computer over a network connection. It has been a native OS feature since Windows XP.

Most of the time, RDP is used for legitimate remote administration: when companies outsource IT, or remote admins have to access a server or a network users machine, they most commonly use RDP to connect to it.

Risks Associated With RDP

One of the main risks associated with RDP comes when you allow external clients access to your network. The RDP protocol typically uses TCP port 3389. Attackers often find instances of this port open by scanning infrastructure exposed to the Internet and using brute force to access open ports. Automated tools and the Shodan search engine help them find systems configured for RDP access online.

Once on a system attackers can disable endpoint protection, establish a foothold in the organization and more. Once this happens, no endpoint security solution can save you. They might download and install low-level system tweaking software and use it to disable or reconfigure anti-malware software on the machine, Sophos researchers explained in a post on RDP and ransomware distribution. RDP connections can also be used to transfer data out of a network.

Recently I spoke to a network manager who was running a trial of our LANGuardian product. Their business need was around getting visibility inside their network and not for RDP specifically. Shortly after they started to monitor network traffic they noticed a lot of inbound RDP connections from many different countries.

When their firewall was checked they found what they described as a legacy rule to allow third party vendor access. Nobody checked this and as they had no visibility inside their network they had no idea systems running RDP were exposed to external clients. They implemented a quick fix which was to block inbound RDP connection attempts.

In July this year, the SamSam group infected some 7,000 Windows PCs and 1,900 servers at LabCorp with ransomware via a brute force attack on an RDP server. In another incident this year, Hancock Health was forced to pay over $50,000 in ransom to regain access to critical data that criminals had encrypted after breaking into its network via a hospital server running RDP services.

How to Detect RDP Activity

One quick check you can do to check for RDP activity is to see if TCP port 3389 is open on your firewall. While this is not an indication of activity you should consider shutting it down for all external clients. It is also possible to run RDP over a different port number so focusing on TCP port 3389 alone is not enough.

A better approach is to monitor network traffic going to and from the Internet using a SPAN, mirror port or network TAP. Once a traffic source is established you can use a product like our own LANGuardian to detect if RDP is in use on your network. You will need a system which is application aware as RDP can run over any network port so looking for activity on TCP port 3389 alone is not sufficient.

The image below shows an example of what to look out for. In this case we can see evidence of RDP activity.  Clicking on the traffic total allows us to drill down to investigate further.

Further drilldown reveals that the RDP activity is originating from a client in China and it is connecting to a host located inside the network. An immediate action would be to block that IP address on the firewall if a connection to the network from China is not expected. Blocking port 3389 would also be recommended in this case.

Getting an alert if an external client connects to your network using RDP

While running reports are useful when it comes to forensics on a past event, most network and security managers want to be notified immediately if someone external connects to their network using RDP. Follow these steps to get alerting setup on your LANGuardian:

1. Select the report Applications in Use and enter all subnets in use on your network preceded with the ! symbol into the source report filter.
2. Select Remote Desktop Protocol from the Protocol drop down
3. Run report and then click on the Actions option and choose Save As. Enter a report name and then save.

The final step is to use this custom report to trigger an alert if RDP is detected. Click on gear symbol top right then Settings / Email and alerts configuration.

Select Add New List and then give it a name, add email addresses, select custom report and tick the last 3 boxes as per the image below.

We host everything in the cloud. Should we worry about RDP?

Absolutely. It does not matter where you host your servers. If RDP is left open on a server it increases your attack vector. Verify that all cloud-based virtual machine instances with public IPs have no open RDP ports, especially port 3389, unless there is a valid business reason to keep open RDP ports. Place any system with an open RDP port behind a firewall and require users to use a virtual private network (VPN) to access that system.

Recently we announced support in LANGuardian for AWS VPC Flow Logs. This new feature provides for visibility inside your AWS estate. I just checked our cloud based LANGuardian and I can see lots of inbound RDP connections from all over the world. The image below shows a report from this system. I had to mask some of the data as it is from our live environment. In our case we can see that all connections are rejected.

What Should You do About RDP?

1. Audit your network for systems that use RDP for remote communication. Disable the service if unneeded or install available patches. Users may need to work with their technology vendors to confirm that patches will not affect system processes.
2. Limit access: Consider changing the default port of TCP 3389, using virtual networking/VLANs/etc. to limit access to critical systems via RDP. Block inbound RDP access from the Internet, it is far too risky to leave open.
3. Make sure systems that have RDP enabled use network level authentication with complex passwords and all activity is monitored closely.
4. Monitor endpoints. Make sure you have visibility on your network and you know who is connection to what. This is especially true for inbound connections from hosts on the Internet.
5. If you have a requirement for remote desktop access from outside your network, consider using a commercial product with encryption and more advanced user account options.

What is Hostname Annotation?

In computer networking hostname annotation is typically referred to the way a text based name is assigned to an IP address. This makes it easier for users to remember what they need to connect to. This concept is nothing new, we use a similar approach when it comes to phone numbers. Our phone contains a database of names and their corresponding numbers and most of us just remember the name part.

A hostname may be a domain name like www.netfort.com or it could be the name assigned to your laptop. In corporate environments computer names usually follow a naming convention so when you see the hostname you will also instantly know who the computer was assigned to.

Hostnames are also very useful when it comes to network incident response. Many logs on devices such as firewalls and servers will have IP address information but then you are left with the question “what hostname does this IP address represent?” Knowing this usually speeds up the process to get to the root cause of the problem.

How to capture hostnames

Gathering a comprehensive database of hostnames requires multiple data sources. Local machine names could be gathered from DHCP logs and Internet hostnames can sometimes be gathered by doing a reverse DNS lookup.

Away from logs there is a rich data source for hostnames on all networks. If you monitor network traffic at strategic locations you can use deep packet inspection to extract the hostnames. Network traffic can be captured using a SPAN, mirror port or network TAP. Capturing hostnames this way is passive and you don’t need to enable any logging on any network device. Strategic locations to capture network traffic would include

• Local DNS servers
• DHCP servers
• Internet gateways

A look at hostnames captured from network traffic

The following screenshots were taken from a LANGuardian system that I have in my lab. It uses network traffic as a data source and captures the hostname information using a series of application aware analysis engines. While you can capture hostname information manually from traffic using tools like Wireshark, LANGuardian delivers automatic hostname annotation capture which is always on.

1. DNS Traffic

In this first example we can see the output of the LANGuardian DNS lookup report. As you can see DNS traffic contains a wealth of hostname information. Click on the image to access the report in our online demo.

2. DHCP Requests

Hostnames are transmitted when a client (wired or wireless) requests an IP address from a DHCP server. In my example I am using LANGuardian to build an inventory of all wired and wireless devices that connect. Click on the image to access the report in our online demo.

3. HTTP Headers

HTTP header fields are components of the header section of request and response messages in the Hypertext Transfer Protocol (HTTP). They define the operating parameters of an HTTP transaction. When users want to browse a website the hostname of the site can be found in the HTTP header generated by their browser. The image below shows how this information can then be used to build an Internet domain style report. Click on the image to access the report in our online demo.

4. SSL/TLS Certificates

An SSL/TLS certificate is like a driver’s license, it serves two functions. It grants permissions to use encrypted communication via Public Key Infrastructure, and also authenticates the identity of the certificate’s holder. This identity information will contain a hostname and it is transmitted in clear text during the cert negotiation process.

The image below shows an example of this hostname annotation which LANGuardian extracted from network traffic captured at the perimeter of a network. Click on the image to access the report in our online demo.

For more information on how LANGuardian works, check out this page. You can also download a trial version of LANGuardian if you want to test how hostname annotations can be quickly captures from network traffic.

What is Apache Struts and vulnerability CVE-2018-11776

Apache Struts is a free and open-source framework used to build Java web applications. On Wednesday, August 22, 2018, the Apache Foundation released a security bulletin for a critical vulnerability in the Apache Struts framework. Applications developed using Apache Struts are potentially vulnerable.

The vulnerability (CVE-2018-11776) was identified and reported by Man Yue Mo from the Semmle Security Research Team, which works to find and report critical vulnerabilities in widely used open source software. This is not the first remote code execution vulnerability discovered on Apache Struts. Previously the framework was targeted with vulnerabilities CVE-2017-9793, CVE-2017-9804, and CVE-2017-9805

Cryptocurrency miners have begun using these vulnerabilities to compromise servers to mine the Monero digital currency. Tools such as Apache Struts Version 3 can also be used to exploit vulnerabilities on ApacheStruts. The reality is that unpatched Apache Struts installations can leave organizations open to significant risks.

How to detect if attackers are targeting the CVE-2018-11776 vulnerability on your network

When in comes to monitoring, there are certain packet payloads and DNS requests that you should watch out for. Suspicious payloads can be detected by using an Intrusion Detection System (IDS) and DNS lookups can be tracked down by using a traffic analysis application like our own LANGuardian.

There are two IDS signatures in our current LANGuardian ruleset which focus on the Apache Struts Vulnerability CVE-2018-11776:

• ET EXPLOIT Apache Struts RCE CVE-2018-11776 POC M1′  sid 2026025
• ET EXPLOIT Apache Struts RCE CVE-2018-11776 POC M2′  sid 2026026

Constant monitoring of DNS queries is a good way to keep an inventory of what types of services clients on your network are trying to connect to. At the moment attackers who are successfully exploiting Apache Struts deployments via CVE-2018-11776 are using them to mine Cryptocurrency. One of the indicators of this is any DNS lookups to the domain:

• us-east.cryptonight-hub.miningpoolhub.com

Running LANGuardian reports associated with CVE-2018-1177

Conclusion

The Apache Struts framework continues to be targeted by attackers due to a steady stream of vulnerabilities. It is important that organizations remain diligent, ensuring this software is updated quickly when new patches are released or otherwise limiting external access to websites leveraging it.

Although the main payload for Apache Struts exploits at the moment appears to be cryptocurrency miners, failure to patch also leaves an organization open to significant risk that goes beyond cryptomining.

Make sure you monitor network traffic going to and from any Apache servers that you host on your network. This is especially true of the servers that can be accessed by external hosts. Also, make sure that your traffic monitoring application is updated with the latest IDS or DNS malware lists so that you can quickly spot problems.

What is SMBv1?

SMB operates as an application-layer network protocol mainly used for providing shared access to files, printers, and serial ports and miscellaneous communications between nodes on a network. Microsoft has implemented three versions of SMB over the years; SMBv2 and SMBv3 are much more secure than SMBv1.

Many Ransomware and Cryptocurrency mining malware variants spread from computer to computer by exploiting critical vulnerabilities in Microsoft’s implementation of SMB version 1. Microsoft recently announced that their security visualization tool (VAST) can report on SMBv1 activity. This is in a response to demand from network and security managers who want to find out if SMBv1 is still active on their networks. However, before you download VAST let’s take a look at the alternatives.

How to root out SMBv1 from your network. Should you download VAST or use an alternative?

There are two primary ways to detect SMBv1 activity on your network. You can either use log files or you can analyze the network traffic going to and from your file servers. Log files will require changes on your file servers, you will need to increase the logging to capture SMBv1 events. Traffic analysis is passive and will not have any performance or storage impact on your servers but you do need to setup a SPAN or mirror port.

Using log files to detect SMBv1

At the end of March 2018 , Microsoft unveiled Project VAST or the Visual Auditing Security Tool (VAST). It uses Windows event logs as a data source and Azure Log Analytics to filter on EventID 3000 for each and every time that a client attempts to access the server using SMB1. You do need to enable auditing on every file server using the command below and this approach does not work for non Windows devices like NAS units.

“$computers = Get-Content “c:\SMB_computers.txt” foreach ($computer in $computers) {Invoke-Command -ComputerName $computer -ScriptBlock {set-smbserverconfiguration -auditsmb1Access $true -Force}}”

The image below shows an example of these events. You could manually check for these events if you only have a single file server but you will be better off to use a separate application to do this job if you have multiple servers.

Using network traffic analysis to detect SMBv1

A more passive approach to detecting SMBv1 involves the use of network traffic analysis. To get a data source you need to monitor network traffic going to and from any file server or network attached storage device. This is easy to setup as all managed switches have a feature called SPAN ports or port mirroring.

The image below shows a typical setup. A copy of the traffic passing through the core switch is sent to the monitoring port. You need to connect your traffic analysis application\device to this port and it checks the file share traffic for SMBv1 activity.

If you host your file servers on virtual platforms such as VMWare ESX you don’t need the SPAN or mirror port, you can monitor the traffic within the virtual environment by setting up a special virtual port group. We have a couple of videos on this page which describe the setup process.

The image below shows a sample report from our LANGuardian system which can be used to detect SMBv1 activity. It also integrates with Active Directory so you can also see the associated username.

Make sure you look at alternatives before you download VAST or similar log analysis tools. Will it be easier to monitor the traffic than make changes on your servers? Do you have any file sharing devices that don’t have logging capabilities?

Using MSP services? Make sure you have independent monitoring in place

A third party such as a managed services provider (MSP) is most often an information technology (IT) services provider that manages and assumes responsibility for providing a defined set of services to its clients either proactively or as the MSP (not the client) determines that services are needed. The main drivers for the adoption of MSPs is the desire to improve operations and cut expenses.

Even years ago before the term MSP was popular, many organizations used external contractors and services to install and configure critical security equipment like firewalls.  Firewalls configurations and rules can be very complex, how do you check them? Make sure they are correct? One option is to look at the traffic and activity inside the firewall.

Recently I worked on an interesting problem with a client who was using a MSP to manage their firewall. They were happy with this arrangement as the MSP did not report any problems and they had nothing independent to highlight any issues.

Case study: Unreported hole in firewall

One thing this client needed outside of the MSP services was a tool to monitor network traffic . They needed a high level view of bandwidth use at their network edge and they contacted us. A trial of our LANGuardian product was deployed, the ability to monitor web traffic and capture associated metadata is one of its many features.

When we started to look at the data captured we noticed something very strange with inbound traffic patterns. We define inbound traffic as a connection were the source IP address is outside the network perimeter (outside the firewall). Over 98% of traffic was associated with LDAP traffic over UDP 389 to one of their domain controllers. Traffic over UDP 389 is typically connection-less LDAP (CLDAP), a variant of LDAP that uses the User Datagram Protocol (UDP) for transport.

Our LANGuardian product has an application recognition engine and so it reported the activity correctly as LDAP. If you are using a tool which uses port numbers (port 80, etc…) to report on activity you may miss things like LDAP.

Drilling down on this traffic we could see connections from China, Russia and many other countries. Our determination was that the domain controller was been used as part of an amplification based DDoS botnet. Infosec attackers are now abusing exposed LDAP servers to amplify DDoS attacks.

We immediately put in a change request to the MSP to block UDP port 389 on the firewall. As you can see from the image below the inbound traffic dropped significantly once the firewall change was implemented.

The big lesson here was the need to have something in place to provide visibility of what was happening on the network. The hole in their firewall was an old NAT rule that was long since outdated. However, their MSP did not pick up on this activity. It needed an independent monitoring tool which could show what was happening on their network.

Finding out what is going in and out of your network with LANGuardian.

LANGuardian comes with a selection of reports which can be customized to filter on certain activity. For this use case we selected the Applications in Use report and we used a specific source and destination IP address filter. You can also use the Report Variables feature to define what subnets are in use inside your network. Follow these steps to get these custom reports setup on your LANGuardian.

1. Create report variables to define what subnets exist on your LAN. If you use private address ranges then you can use the exact same setup as the image below. The only difference between the External and Internal variable is the use of the ! character. This character denotes NOT so any subnet outside of this is not on your LAN.

2. Click on All Reports and select the Applications in Use report. Click the drop down next to Source IP / Subnet on the left and select the External report variable. Click the drop down next to Destination IP / Subnet on the left and select the Internal report variable.

Click on Run Report. You should get an output like the one shown below. In my case I will need to drill down on that SMB activity as I would not expect to see file sharing traffic where the client (source) is outside my network.

3. You can then save this as a custom report by clicking on Actions \ Save As or create a line graph by selecting the Trend Report option.

4. Finally, repeat the steps to show what applications clients are using on the Internet by selecting Internal as a source and External as the destination within the Applications in Use report.

Why do we need to track MAC addresses?

A media access control address (MAC address) of a device is a unique identifier assigned to a network interface controller (NIC) for communications at the data link layer of a network segment. As they are unique, they are used by network devices such as switches to maintain an inventory of what is connected to what switch port.

The concept of a network inventory has been around for a long time, it is one of the fundamentals of networking. Devices cannot exchange data unless they know who to share it with. However, a lot of this inventory information is hidden behind the scenes, buried in MAC tables on switches and distributed across multiple devices.

Many compliance standards such as GDPR now require network managers to maintain a list of what is active on their networks. However, it is good practice to maintain a list of what is connected to your network. If you get hit with something like Ransomware, you will need to act fast and track down what is connected to your network quickly.

Where can you capture MAC address information?

The easiest way to capture MAC addresses is to monitor network traffic via a SPAN, mirror port or TAP. This will give you access to network packets and each packet will contain MAC addresses. You need to be careful about where you capture this information. If you monitor traffic on the wrong side of a routing device like a firewall or network router, you may find that all traffic is associated with the firewall\router MAC address.

An ideal location for capturing MAC addresses is the network core where traffic from clients and servers converges. The image below shows a sample output from our own LANGuardian system which captures metadata like MAC addresses from network traffic.

Server logs and flow data are not good data sources when it comes to capturing data for a MAC address tracker. Logs and flow records focus more on IP addresses which can move from device to device on networks that use DHCP. The image below shows a typical flow record with date, time, IP and port information.

Common use cases for a MAC address tracker

In the past MAC address capturing was typically done using packet analysis tools such as Wireshark. While this is useful for troubleshooting isolated issues, it is not very scalable when it comes to tracking all network device activity.

Recently one of our customers had an issue during a very busy and critical time of the day, the switches were reporting ‘Broadcast storm detected’ and had applied filters as a defense mechanism. This resulted in connectivity issues on their network. As they had an inventory of MAC addresses and associated broadcast traffic, they located the rogue network device quickly. In their case it was a faulty IP phone and normal network operations resumed after it was shutdown.

A use case like the one above shows that the need to track devices on network is important. Common use cases that we come across include:

1. Generating a list of network devices for compliance standards such as GDPR
2. Detect faulty network equipment which may be responsible for broadcast traffic storms
3. Quickly locate problematic devices in the event of a malware outbreak such as Ransomware
4. See the corresponding MAC address associated with copyright violations where clients are using applications like BitTorrent
5. Capture additional metadata for your existing network monitor or SIEM application
6. Track specific application like web traffic by MAC address

The video below shows how you can use a network traffic analysis application to find the host-name or MAC addresses of devices connected to your network.

Most popular LANGuardian reports with links to our demo

Here we have compiled a list of the top 20 LANGuardian based on customer feedback. They are a mix of operational and security reports. If you click on the report name it will link to our online demo and you can check-out the report and output yourself.

1. Traffic & Protocol Analysis : Applications in Use
2. Security : Top Network Events
3. Security : Network Scanners
4. Web : Top Website Domains
5. Windows File Shares : Top File Share Actions
6. Bandwidth : Top Users
7. Encryption Protocols in Use (SSL/TLS)
8. SQL Server : Top MS SQL Statement Type
9. Ethernet : DHCP Lease Assignments
10. Ethernet : Top Broadcasters
11. Services : DNS Servers
12. BitTorrent : Search by Info Hash
13. E-mail : SMTP Emails Sent with Attachments
14. Identity : Directory Logins
15. Traffic Analysis : Countries by Client Location
16. Bandwidth : Inbound TCP Connections
17. Bandwidth : Top AD Departments
18. Ransomware : Top Clients Renaming Files
19. Top Proxy Client IPs
20. Web : Top Website Categories

Detect SMBv1 scanning and active or established connections

Detecting SMBv1 activity is a subject we have covered previously. It has been used as an attack vector for Ransomware and Cryptocurrency Mining. Microsoft has advised all customers to stop using SMBv1. SMBv2 was introduced with Windows Vista in 2006 and the latest version is SMB 3.1.1 which was introduced with Windows 10 and Windows Server 2016. At a minimum, you should make sure that all Windows systems on your network have the MS17-010 patch applied.

One of the easiest ways to detect SMBv1 activity on your network is to monitor network traffic going to and from your file servers. You can do this by setting up a SPAN, mirror port or use a network TAP. This will give you a copy of all activity going to and from the servers.

Once you have your data source which is sometimes referred to as wire data, you can use a network traffic analysis application like our own LANGuardian to extract the file and folder information from the network packets.

SMBv1 scanning vs established connections

There are two types of activity to watch out for when it comes to SMBv1 activity. Clients which are trying to use SMBv1 and clients which are successfully connecting to servers using the SMBv1 protocol. The latter is more serious as you actually have servers on your network supporting and using SMBv1. Microsoft recommends immediately removing this old and vulnerable file sharing protocol from all networks. The recent WannaCry and Petya ransomware attacks for example actually used the same SMBv1 exploit to replicate through networks.

1. SMBv1 connection attempts or SMBv1 scanning. This is where a client sends an SMB request to a server and the version flag is set to v1. The server may or may not accept the connection request.
2. SMBv1 connections. This is where a client and server have established a connection using SMBv1. You need to root out these first. At a minimum make sure the client and server are fully patched.

The video below shows an example of what to look out for once you get network traffic monitoring in place. A trial version of LANGuardian can be used to perform a quick audit if you do not have something in place already.

Video: Detect SMBv1 scanning & established connections

Reporting on traffic between network devices

Recently one of our customers got in contact with this simple query.

“I am looking to find out if it’s possible to get traffic between a certain source IP and destination IP along with the time of the connections.”

They needed a historical report so there was no point in launching a tool like Wireshark as it would not report on the historical activity. As they have LANGuardian installed they have 24/7 visibility throughout their network. By utilizing a SPAN, mirror port or network TAP at strategic locations you can monitor network traffic you can spot abnormal behavioral patterns as they occur. But, critically for this use case, the LANGuardian retains rich network traffic metadata very cost effectively for long periods.

Network traffic reports

The image below shows a sample output from a LANGuardian IP search. Click on the image to access our demo where you can drill down on sample data. The element (1) shows the traffic between a certain source IP and destination IP which is what the customer was looking for. LANGuardian also shows what applications (2) were in use by this network device, suspicious events (3) triggered by the IP. In this case we can see that there was a Malware infection as well as some BitTorrent activity.

Other uses for network traffic analysis

Network traffic analysis was traditionally seen as an operational tool. Something to report bandwidth usage on WAN and Internet links. However, it is an excellent data source for network security use cases including:

• Internal and east-west traffic analysis
• Ransomware detection
• Automated threat hunting
• Passive detection of weak ciphers and vulnerable SSL certificates
• Report on insecure protocol use such as FTP and Telnet
• Root out network devices scanning your internal networks

By monitoring network traffic on your network you can get visibility as to what is happening without the need for agents or log files. Agents can be difficult to deploy and scale and they become one other thing to update and manage. Log files do not always have the answer as they only report about local server issues. Wire data which can be extracted from network traffic, is instant and way more flexible than log data. It can provide high-fidelity user and application evidence to enhance your evolving security operations center (SOC).

Just over 2 weeks ago, we received an inquiry from a large US multinational in the financial sector. They had a very specific requirement, ‘we want to know how much SMBv1 is still in use on our network and start the cleanup’. They had tried just turning it off and waiting for the calls to see who complained but they came and that didn’t work. So basically, they want to get a list of all file share servers accepting SMBV1 connection requests and ‘root it out’.

Makes sense, it is an old vulnerable protocol and recent attacks like Wannacry have demonstrated that it is common sense to ensure it is not in use. It also critical to prep and get as much visibility as possible into the servers still supporting it, and the clients using or depending on it before just disabling it and potentially have a serious impact on the business.

This organisation has a large and complex network, over 50k users and 12 data centres. As they have also acquired several other companies in their space which is not unusual, the network, software and applications are complex and diverse. Making any global change, even a simple upgrade across such a complex network of this size is not a trivial task, and of course, if it is not broken, still supporting the business, why risk it?

We arranged a webex and our demo focussed on this very specific use case. Every device, user and application on the network automatically leaves a trail, a traffic trail. There is no need to turn it ON, to enable logging or install a client. If they are active on the network they leave a trail. LANGuardian ‘sniffs’ this trail, usually via a tap, SPAN or port mirror and using its deep packet inspection engine, extracts application specific metadata for the most critical applications. It also enriches the metadata with usernames extracted using WMI from the logs of the domain controllers. We support a number of ‘critical’ applications, web, SQL, SMTP, BitTorrent, DNS, DHCP and SMB.  With SMB, for example, we extract information such as the client and server IP address, file and folder names and action.

One of the advantages of capturing data ‘off the wire’ is that one has the option or flexibility on selecting the specific details or data to look out for and store and report on demand. The initial SMB client-server negotiation, for example, includes the actual version the client requests and is looking for the server to support and communicate over. So, in the case of SMBV1 the client sends an SMBV1 connection attempt and then if the server supports it, it sends back an SMBV1 connection established. Luckily for us, we supported analysis down to this level, and could instantly show during the demo, all clients on the network initiating a SMBV1 connection request and the servers responding:

Using our report filters to query the database, one can get very specific and list only the servers on any part of the network responding to SMB1 connection requests with success and establishing a SMBV1 connection:

All good so far, this covers the use case required, we have the level of granular detail. The final and most critical step is implementation, critical for such a large network. The system is very easy to use and requires minimum training, so we are good there. LANGuardian can be downloaded and deployed on standard server hardware or VMware. The download and installation, the configuration on the physical or virtual device requires less than 30 minutes, not bad.

The final and crucial step, especially for the network of this size and complexity is sensor placement, how do I see the ‘SMB traffic trail’ or all traffic to and from all file share servers on the network with the minimum number of sensors? Are all the servers in one VLAN and can I just mirror that VLAN for example? Or can I approach it from the client perspective and mirror the point or points in that data centre all clients connect in from? Where are all my file shares? I need to see all traffic to/from all file share servers in order to extract the SMB version information required.

To be investigated….to be continued.

What is Cryptocurrency Mining?

Bitcoin or Cryptocurrency mining is the process by which Cryptocurrency transactions are verified and added to the public ledger, known as the block chain, and also the means through which new bitcoin are released. Anyone with access to the internet and suitable hardware can participate in mining.

The mining process involves compiling recent transactions into blocks and trying to solve a computationally difficult puzzle.  The participant who first solves the puzzle gets to place the next block on the block chain and claim the rewards.  The rewards, which incentivize mining, are both the transaction fees associated with the transactions compiled in the block as well as newly released bitcoin.

Cryptocurrency mining is painstaking, expensive, and only sporadically rewarding. Mining is competitive and today can only be done profitably with the latest ASICs.  When using CPUs, GPUs, or even the older ASICs, the cost of energy consumption is greater than the revenue generated.

Away from using specialized hardware, the most common way to mine cryptocurrency on standard hardware is to install Crypto mining client software and leave it running in the background. Cyber criminals can also use your computer to mine Cryptocurrencies by hosting Cryptocurrency mining hijacker on websites. If you visit the site without adequate virus protection your browser and CPU will be hijacked by the website operators.

Recently a piece of Malware called PowerGhost Malware has been spreading across corporate networks infecting both servers and workstations to illegally mining the crypt-currency and Perform DDoS Attacks.

In this case, attackers using file-less malware techniques to maintain the persistence which is then used to bypass the antivirus detection and leverage the corporate vulnerabilities using known exploits such as Eternalblue.

PowerGhost is unique for two reasons: firstly, it focuses on attacking corporate networks and secondly, it is file-less. This permits the miner to be able to cling to the servers and workstations of victims without being noticed. PowerGhost’s reign of terror has just began, and so far, reports of attacks have been seen Turkey, India, Brazil, and Colombia.

What are the risks associated with Cryptocurrency Mining?

Only those with specialized, high-powered machinery are able to profitably extract bitcoins nowadays. While mining is still technically possible for anyone, those with under-powered setups will find more money is spent on electricity than is generated through mining. If you have clients on your network running crypto mining software then it is costing your business money.

Many cyber criminals now favor anonymous Cryptocurrencies, with Monero being the most prominent. Cryptocurrencies are popular as they are both secure, private and difficult to trace. Servers are often targeted and since many of them are not updated or patched on a regular basis, attackers have a bigger chance of success.

Recently more than 526,000 Windows hosts, mostly Windows servers, have been infected by a Monero miner known as Smominru, according to researchers at Proofpoint. It spreads using the EternalBlue exploit (CVE-2017-0144) which targeted the SMBv1 protocol.

Cryptocurrency mining malware like this covertly mines for coins using the victim’s GPU horsepower without them knowing about it. It has potential for longer-term gains. When a computer is infected many people will fail to notice fans spinning up, or computers under higher load or just plain old not responding. A lot of those people may just pass it off as “one of those things my computer does.”

How to detect Cryptocurrency mining activity on your network

When it comes to detecting Cryptocurrency mining, you need to be looking at multiple data sources.

1. Analysis of all DNS client traffic
2. Use IDS (Intrusion detection software) to detect specific text strings\patterns in network packets
3. Monitor all IRC communications on your network

DNS query logs can be very useful when it comes to detecting suspicious activity or for use in follow up forensics. Searching DNS queries for text strings like bitcoin or crypto can be used to identify clients running crypto mining software. You can get DNS query information from DNS server logs or if you monitor network traffic going to and from your DNS servers.

Intrusion detection software typically uses pattern matching techniques to spot suspicious activity on a network. Applications such as Snort can be used to detect Crypto mining activity. You just need to make sure you install a well maintained IDS signature set such as those provided by EmergingThreats.

Internet Relay Chat (IRC) is an application layer protocol that facilitates communication in the form of text. Some Crypto miners use IRC but can be detected if they try an use IRC on a nonstandard port, IRC typically uses TCP port 6667.

Using LANGuardian to detect Cryptocurrency mining activity

Our own LANGuardian product uses a combination of network traffic analysis and IDS to provide visibility, context and alerts as to what is happening on a network. The following set of screen shots show how LANGuardian can be used to detect Crypto mining activity on a network. The primary data source would be a SPAN or mirror port which is monitoring all traffic going to or from the Internet. It is also advisable to monitor network traffic going to and from your DNS servers as this can also be used to detect Crypto mining activity. The video below shows how to use LANGuardian to detect Cryptocurrency mining on a network.

The follow image shows the output of a LANGuardian Network Events report which shows Crypto mining activity. The first event is associated with a Windows based (W32) Crypto mining client.  The second event is associated with a client visiting a compromised website that is hosting a Cryptocurrency mining hijacker. The third event in the report is reporting that something is using IRC on a non standard port. This may not be associated with Crypto mining but it is worth investigating.

The next image shows what IP addresses are associated with this activity. LANGuardian also includes an Active Directory module so you can drill-down to see what users are associated with this activity. In this example we can see that the Crypto mining is associated with a single client within the network and it is communicating with external systems hosted in the Netherlands and France.

Next we take a look at the DNS activity associated with this client. If we filter on any domains containing the word coin we find that this client is also looking up numerous Bitcoin related sites. You can configure alerts on LANGuardian if you want to be notified about this activity. Alerts can be delivered as an email or as SYSLOG which can be then used to block the client via a firewall or NAC device.

As I mentioned previously, you need to continuously monitor network traffic to have a reliable way to detect Crypto mining activity on your network. You can quickly get a data source in place by setting up a SPAN or mirror port to get a copy of all network traffic going to or from your Internet gateway. Once this is in place you can extend the monitoring to include traffic associated with your DNS servers. The video below goes through the process of getting network traffic monitoring in place.

How to monitor Internet traffic using a SPAN or mirror port

Telnet. One of the oldest network protocols

Telnet is a protocol used on the Internet or local area networks to provide a bidirectional interactive text-oriented communication facility using a virtual terminal connection. Telnet was developed in 1969 and it is still widely used today for configuring network devices.

Why worry about Telnet?

Because Telnet is an unencrypted protocol, session traffic will reveal command line interface (CLI) command sequences appropriate for the make and model of the device. CLI strings may reveal login procedures, presentation of user credentials, commands to display boot or running configuration, copying files and creation or destruction of GRE tunnels, etc…

A recent cyber briefing from the UK based National Cyber Security Centre (NCSC) recommends that you check your network for any devices running unencrypted management protocols such as:

• Telnet
• Hypertext Transport Protocol (HTTP, port 80)
• Simple Network Management Protocol (SNMP, ports 161/162)
• Cisco Smart Install (SMI port 4786)

If these services are in use the NCSC recommends the following:

• Do not allow unencrypted (i.e. plaintext) management protocols (e.g. Telnet) to enter an organisation from the Internet. When encrypted protocols such as SSH, HTTPS, or TLS are not possible, management activities from outside the organisation should be done through an encrypted Virtual Private Network (VPN) where both ends are mutually authenticated.
• Do not allow Internet access to the management interface of any network device. The best practice is to block Internet-sourced access to the device management interface and restrict device management to an internal trusted and whitelisted host or LAN. If access to the management interface cannot be restricted to an internal trusted network, restrict remote management access via encrypted VPN capability where both ends are mutually authenticated. Whitelist the network or host from which the VPN connection is allowed, and deny all others.
• Disable legacy unencrypted protocols such as Telnet and SNMPv1 or v2c. Where possible, use modern encrypted protocols such as SSH and SNMPv3. Harden the encrypted protocols based on current best security practice. The NCSC and Department of Homeland Security (DHS) strongly advise owners and operators to retire and replace legacy devices that cannot be configured to use SNMP V3.
• Immediately change default passwords and enforce a strong password policy. Do not reuse the same password across multiple devices. Each device should have a unique password. Where possible, avoid legacy password-based authentication, and implement two-factor authentication based on public-private keys.

Using network traffic analysis to detect Telnet activity

As I mentioned previously, Telnet normally runs over TCP port 23. However, you can configure Telnet to run over any port and so you cannot just watch out for network traffic running on TCP port 23. You must be able to monitor all traffic and pick out the Telnet traffic by using some form of application detection.

Wireshark is one of the most popular traffic analysis tools and has the capability to detect Telnet traffic as it has access to packet payloads which can be used for application identification. Flow based tools (NetFlow, SFlow) are not suitable for detecting Telnet activity as they are not application aware. Wireshark is fine for low network traffic volumes or if you have a PCAP file that you want to analyze.

If you want to get continous monitoring in place then you need to look at setting up a data source such as a SPAN, mirror port or network TAP. Once you have a data source then you need a commercial network traffic analysis system in place like our own LANGuardian. It has an application recognition engine which can report on any Telnet activity no matter what port it is running over.

Using LANGuardian to detect Telnet activity on your network

LANGuardian uses Content-Based Application Recognition (CBAR) to identify what applications are running on your network. With support for hundreds of the most common applications and protocols, and a unique deep packet inspection algorithm, CBAR delivers greater accuracy and fewer false positives than other approaches to application recognition.

A sample output of this Applications in Use report is shown below. Here we can see that some Telnet activity has been detected.

Drilling down on this Telnet traffic then reveals that Telnet services are active on two seperate ports on a single server as you can see in the image below. LANGuardian can also alert you if a new server port becomes active which is useful for watching out for new activations of Telnet services on your network.

You can download a 30 day trial of LANGuardian from here and use it to detect any device running Telnet services on your network. You do not need any logs or client software. Just setup a SPAN or mirror port and you can passively monitor activity at your network edge and east west traffic moving within your network.

Weak SSL/TLS encryption. Why worry?

A Google search for “GDPR countdown clock” yielded 18,900 results for me this morning so probably the last thing we need to consider is another countdown clock, but here is one for PCI compliance anyway.

The clock highlights 30 June 2018,  an important deadline for online security and network Administrators; a date from which older versions of TLS and all SSL should be confined to history for PCI compliant networks. From 30 June 2018, to be compliant with PCI DSS 3.2, SSL and “early versions” of TLS protocol should be eliminated from use (with some exceptions for POS terminals). This is because PCI requires the use of “strong encryption” and known weakness in all SSL, some TLS versions and some cipher suites mean they fail the ‘strong encryption’ standard.

“Early TLS” is defined as anything before TLS 1.1; however TLS 1.1 is also vulnerable as it allows use of bad ciphers; so TLS 1.2 is a better choice. Along with this version change, the ciphers that are used by SSL/TLS need to be carefully managed too. The ciphers and the SSL/TLS protocol versions are separate, but not completely independent of each other.

Even if you don’t care about PCI compliance, this is important for all networks running SSL/TLS; that includes your own networks, partner or client networks, that interact with your infrastructure. GDPR regulations (article 31) require use of “state of the art” technical and organisational measures to ensure security. While the GDPR language lacks specifics, we can look to PCI 3.2 and NIST guidelines (800-52 Rev 1) which strongly recommend use of TLS1.2 only, to know that SSL, TLS1.0 and TLS1.1 are not state of the art, and so fail the GDPR test. The NIST draft for 800-52 Rev 2 explicitly prohibits use of TLS 1.1.

What’s the problem, SSL provides encryption doesn’t it?

Since the mid 1990’s, SSL/TLS encryption has underpinned much of online security and is the defacto choice for encrypting our web based online shopping and payment transactions. SSL/TLS keeps our transactions private and unaltered. However, researchers and attackers have identified and published weaknesses in the aging versions of the protocols, from SSL2.0, SSL3.0, TLS1.0 and TLS1.1. and in the ciphers that they use. There are three sources of weakness here to be aware of:

1. Some weaknesses are in the protocol implementation itself, for example Heartbleed exploited a read buffer overflow in OpenSSL’s implementation of in the heartbeat extension. This allowed attacking clients to read private key information from the server.
2. Other weaknesses are in the ciphers supported SSL/TLS. For example, increased computation along with the increased volumes of data being transferred, mean that 3DES cipher can be compromised in about 1 hour, using the Sweet 32 attacks. RC4 can also be compromised by brute force attacks. These weaker ciphers are supported by all versions of SSL/TLS up to version 1.2. However, newer. stronger ciphers such as AES are only supported by newer versions of SSL/TLS. So, use new version of TLS to enable use of stronger ciphers.
3. Weakness in the protocol itself

Even if properly implemented, according to the spec, with good ciphers, TLS1.1 is still vulnerable. The PRF (pseudorandom function) is based on broken cryptographic hashes MD5 or SHA1 and its use of ciphers in CBC mode is insecure.

There are no available fixes for these weakness, so the only avenue to remain secure is to use the newer more robust versions.

TLS1.3, the newest, most secure version of TLS resolves the known weakness with the protocol, prohibits use of weak ciphers and has a much shorter setup time. TLS1.3 was in draft form when PCI 3.2 was adopted, so it isn’t mentioned in the PCI 3.2 document (TLS1.3 was formally adopted in March 2018. Mandating use of TLS1.3 at this stage could lead to interoperability problems).

Using Network Monitoring for SSL/TLS analysis

There are various techniques for identifying the SSL/TLS versions and ciphers that servers will support, such as nmap or just running Openssl from the command line. However, this requires that periodic checks are carried, the full inventory is always known, and you have access to scan the network. The PCI Security Standards Council emphasise the important of ensuring adherence to standards at all times and not just once per year to close audit requirements!

Continuous adherence is just good business and security practice and essentially points to continuous monitoring, rather than scheduled pen testing efforts. If you monitor network traffic within your network and perform packet analysis at session startup time, it’s possible to view the SSl/TLS versions and cipher used, as well as the certificates used on encrypted protocols (excluding TLS 1.3) .

You can do this without any access to the servers (i.e you can do it from the client or partner network) and without terminating any of the SSL/TLS sessions (i.e you don’t have to use man in the middle devices). This is possible as the opening salvos in SSL/TLS session establishment happen in the clear. The protocol negotiation, cipher choice and certificate exchange are all readable. Add to this the Server Name Indication (SNI) extension and a packet monitoring application can extract a lot of useful information about the nature of encrypted sessions on the network.

LANGuardian 14.4.1 includes features that are useful for monitoring the status of SSL/TLS on your network.

NetFort LANGuardian is deep-packet inspection software that monitors network and user activity passively via a SPAN\Mirror port or TAP. Here are a couple of use cases which cover how it can be used to detect the use of weak SSL/TLS encryption on your network.

The first is an inventory of SSL/TLS servers. Built from passive traffic analysis, this shows every SSL/TLS server, that has generated traffic on the network. The server can be internal or external (e.g a HTTPS website). The inventory report for each server shows some details of the server certificate, with expiry date and signature algorithm. It also shows the SSL/TLS protocol versions that the server has used to communicate with clients. Issues are highlighted in red, such as expired certificates or weak certificate signature algorithms, such as SHA1. A set of filters help identify conditions, such as use of SHA1 and help identify servers that need configuration or updates.

Filters for reporting on SSL/TLS Sever Inventory

Report on a single SSL server, showing expired certificate, weak protocol used, weak SHA1 algorithm

The other feature is a report on all the SSL/TLS sessions that have occurred on the network. This report (and its drilldowns), identifies all clients and servers that use SSL/TLS encryption, identifying the version of SSL/TLS used and the cipher that is used. Filters can be used to focus on versions of SSL/TLS, identify where SSL3.0 is used for example, or identify where any communication occurs that does not use TLS1.2.

Report showing use of weak SSL/TLS versions

Report drilldown showing cipher used by weak SSL3.0 session

A filter is also provided for the ciphers that are used. Ciphers suites have a specific naming scheme, which identity various attributes of the cipher used, viz:

TLS_KeyExchangeAlg_WITH_EncryptionAlg_MessageAuthenticationAlg.

For example, the cipher TLS_RSA_WITH_AES_128_CBC_SHA

is for use with TLS, using RSA for key exchange, AES 128 bit encryption, with SHA digests.

Report showing use of 3DES cipher

Filter support for SSL/TLS Versions and Ciphers

The list of supported ciphers for various versions of SSL/TLS is extensive (many hundreds) and there’s a balance between security and interoperability to consider when choosing which ciphers should be supported. Recommendations generally are to avoid RC4 and 3DES.

Continuous Network Monitoring is a useful tool for ensuring your network is operating to whatever standards or compliance regulations the you are required to adhere. Without using man in the middle decryption devices, it is possible to learn about the activity on your network.

Video Guide: How to detect weak SSL/TLS encryption on your network

Here are some links for further reading.

https://www.pcisecuritystandards.org/pdfs/PCI_SSC_Migrating_from_SSL_and_Early_TLS_Resource_Guide.pdf

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf

https://tools.ietf.org/html/rfc7540#appendix-A

You can download a 30 day trial of LANGuardian from here and use it to detect the use of weak SSL/TLS encryption on your network. You do not need any logs or client software. Just setup a SPAN or mirror port and you can passively monitor activity at your network edge and horizontal traffic moving within your network.

LANGuardian 14.4.1

NetFort are delighted to announce the availability of the latest major LANGuardian release, V14.4.1. This release introduces some changes and new features to help with compliance monitoring, including a new compliance section presents reports for monitoring technical security compliance with CIS CSC 20 and GDPR. Highlights of this release include:

• SMB fileshare alerts on failed attempts to map network shares, create or read files and folders.
• Encrypted sessions analysis of SSL/TLS/QUIC versions and ciphers used
• Detect new server ports in use on your network
• New Applications in use black/whitelist.
• Allign report names more with compliance standards.

SMB fileshare alerts on failed attempts to map network shares, create or read files and folders

For some time now we have included a file activity monitoring feature in our LANGuardian product. It passively generates an audit trail of file and folder activity using network traffic as a data source. LANGuardian 14.4.1 extends this monitoring to now include the capture of failed access attempts. Many compliance standards require this so that you can detect anomalous activity where a user or device is attempting to access sensitive data.

You can read more about this feature in this blog post which looks at why is it important to monitor for failed access attempts. The screen shot below shows an example of the report output.

Encrypted sessions analysis of SSL/TLS/QUIC versions and ciphers used.

Since the mid 1990’s, SSL/TLS encryption has underpinned much of online security and is the defacto choice for encrypting our web based online shopping and payment transactions. SSL/TLS keeps our transactions private and unaltered. However, researchers and attackers have identified and published weaknesses in the aging versions of the protocols, from SSL2.0, SSL3.0, TLS1.0 and TLS1.1. and in the ciphers that they use.

LANGuardian 14.4.1 includes features that are useful for monitoring the status of SSL/TLS on your network. They include:

• Inventory of SSL/TLS servers
• Report on all the SSL/TLS sessions that have occurred on the network
• A filter is also provided for the ciphers that are used

Learn more in this blog post which looks at how to detect weak SSL/TLS encryption on your network. The sample report below shows how LANGuardian can be used to show use of weak SSL/TLS versions.

Detect new server ports in use on your network

Opening new ports on a server increases that servers attack surface. Keeping the attack surface as small as possible is a basic security measure. New ports become active if you install new software or if you enable a new service on the server. For important servers on your network you should have an inventory of what applications or services are running so that changes can be detected.

If compliance standards such as GDPR are a concern then server monitoring is not just a nice to have, it becomes mandatory. You must maintain an inventory of who is connecting to what if you store sensitive or personal data. LANGuardian 14.4.1 now logs certain information when a port becomes active on a server for the first time. Read more in this blog post which looks at how to detect new server ports in use on your network using LANGuardian. The screen shot below shows an example of the report output.

Applications in use. Build white or black lists

LANGuardian uses an advanced application recognition engine to report on network activity. Instead of matching up port numbers with application names, it analyzes packet payloads to work out what applications are in use. LANGuardian 14.4.1 now includes new report filters which allow you to build lists of white or blacklists. You can then use these lists to detect new applications in critical areas such as your server VLAN.

You can access these new filters in the Applications in Use report. Click on the Protocol dropdown to start to build application lists.

Align report names more with compliance standards.

LANGuardian 14.4.1 includes a new compliance section which groups reports for monitoring technical security compliance with CIS CSC 20 and GDPR standards. Many reports have been renamed so that they are more aligned with compliance standards. For example Top DNS Servers was renamed to DNS Servers. A full list of reports which were renamed can be found within the 14.4.1 release notes.

Video Guide: LANGuardian 14.4.1

Why is it important to monitor for failed access attempts?

For some time now we have included a file activity monitoring feature in our LANGuardian product. It passively generates an audit trail of file and folder activity using network traffic as a data source. All you need to do is monitor network traffic going to and from your file servers and you can easily see who is doing what with your files and folders. The image below shows an output of a sample report.

With the release of LANGuardian 14.4.1 we can now report on successful and failed access attempts to network file shares. The failed access attempts can be viewed in report format or they can also trigger alerts via email or SYSLOG.

For many compliance standards such as GDPR and CIS CSC 20 you also need to monitor for failed access attempts.  This is useful for generating alerts on anomalous activity where a user or device is attempting to access sensitive data. When it comes to GDPR and failed access attempts, this is what you need to focus on and how LANGuardian can help:

A closer look at the LANGuardian failed access reports

The image below shows a sample output. Here can see some failed file open attempts originating from client 192.168.127.237. Drilling down further will show the date and time that this event was triggered and you can also get associated usernames if you have configured the Active Directory integration.

Video Guide: Generating an Audit Trail of Failed Access Attempts to Files or Folders

You can download a 30 day trial of LANGuardian from here and use it to monitor, track file and folder activity on your network. You do not need any logs or client software. Just setup a SPAN or mirror port and you can passively monitor activity to and from your file servers.