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 VMware or Hyper-v. 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.