on 21-Apr-2020 13:55
In the F5 SIRT and F5 Support, we are often asked how F5 products can be used to defend against threats like ransomware, malware and rootkits.
Threats like these can enter a target network through a multitude of vectors specific to the target endpoints – email spam campaigns, phishing and spear-phishing attacks, drive-by download vulnerabilities – but they can also enter the network through direct compromise of internet facing hosts.
It’s tempting to look at F5 products and think they aren’t designed to detect a malicious binary being injected into your network, and while (with the exception of ICAP virus scanning of files uploaded to a webserver) that might be true, it is definitely not true to think that F5 products can’t be used as part of a defence-in-depth strategy to protect yourself from both compromise and post compromise exploitation.
So let’s talk about a few ways you can bolster your network security using F5 products…
The first step is to understand that the BIG-IP is usually found sitting at the border of your network, therefore it is crucially important to protect the BIG-IP from compromise. If the BIG-IP is compromised then it doesn’t matter how good your Advanced WAF policies are or your AFM rulesets, the attacker has a neat jump-box which they can use to pivot into the rest of your network.
Fortunately, protecting yourself against exploit here is as simple as following a few basic principles:
If you absolutely must expose the management interface to the internet, be sure to set appropriate ACLs to restrict access to specific IP ranges.
All of which is documented in our Ask F5 article K13092
Now that you’ve got the BIG-IP sorted, you can turn your attention to how the BIG-IP(s) in your infrastructure can help protect your internal assets.
As we discussed earlier malware can enter your network in a number of different ways, and a BIG-IP can help secure a number of those:
Of course, it is true to say that BIG-IP products are not best placed to stop a user from clicking on a malicious link in an email, but the points above at least help close some of the vectors that malware can enter your network!
But, don’t stop there. I’m sure that as part of your day to day, you are on the look-out for IOCs to watch for that might indicate a problem within your network?
If you are inspecting your outbound traffic (with BIG-IP AFM or SSLO) then it’s a snap to add rules to those products that will alert you and/or block outbound C2 communication attempts from compromised clients!
Cloud Snooper first appeared in the news in February 2020 billed as “malware that sneaks into your Linux servers”. Reading the Sophos white-paper (links to a non-F5 resource) it becomes clear that the researchers aren’t sure what the original infection vector is here; they know that the key marker is a specific rootkit present on the hosts, but not how that rootkit got there in the first place.
Since there isn’t a specific initial infection vector, like most malware, we know that we need to think about everything from the previous two sections:
The white-paper tells us that the rootkit dropped initially is a local command-and-control system rather than the ultimate exploit; its job is to receive incoming C2 messages and arbitrate between those and malware subsequently installed.
It does that by sniffing all of the network traffic arriving at the compromised host and inspecting the TCP source port of every incoming packet. If the source port of the packet matches one of the ‘magic’ numbers hard-coded in the rootkit then it is treated as a command, otherwise it is simply ignored, and the host processes it as normal. So we've a third item to add to our list above:
Good news! With even the default configuration in place there’s a good chance that the BIG-IP won’t preserve the TCP source port between the client side and the server side, especially on a system passing a reasonable amount of traffic. But you can go one step further – simply change the “Source Port” option on the Virtual Server from “Preserve” to “Change” and the BIG-IP will always try to change the source port! The C2 messages might arrive at the Virtual Server, but by the time they leave and head to the pool member they’ll be on a new port and the rootkit will completely ignore them.
Want to go one step further and ensure that C2 traffic never reaches the server at all? BIG-IP AFM has you covered; just create a Network Firewall rule to deny all traffic with a source port of 1010, 2020, 6060, 7070, 8080 or 9999, assign the rule to a Rule List, assign the Rule List to a Network Firewall Policy and then assign that Network Firewall policy to any Virtual Servers you’re concerned about or even to all traffic passing through the BIG-IP. As the original white-paper notes, regular clients don’t normally use source ports below 32768 so legitimate traffic shouldn’t be affected – but simply by assigning a logging profile with Network Firewall logging enabled will let you see what’s being denied by the rule.
See the following chapters in the manual (BIG-IP Network Firewall: Policies and Implementations) for your version for more information:
Configuring BIG-IP Network Firewall Policies
Local Logging with the Network Firewall
If you don’t have AFM, we’ve still got you covered. A simple iRule attached to a Virtual Server provides a simple way to block incoming Cloud Snooper C2 communications:
when CLIENT_ACCEPTED { switch -- [TCP::client_port] { 1010 - 2020 - 6060 - 7070 - 8080 - 9999 { # Uncomment the following to log locally, which should be used for debugging purposes only # log local0. "Reject possible Cloud Snooper C2 message from [IP::client_addr] with source port [TCP::client_port]" reject } default { # Not a Cloud Snooper C2 connection, continue as normal } } }
Of course, an iRule doesn’t come with the many advantages of AFM's Network Firewall Policies – it’s more computationally expensive, there isn’t simple access to remote logging compatible with leading SIEM systems, and it isn’t as easily administered if needs change. But, still, it’s there and it’s an excellent option – the F5 SIRT makes regular use of iRules in order to stop the bleeding and get customers back up and running in a pinch!
In brief, to protect against Cloud Snooper:
The Maze ransomware has been in the news regularly since January 2020 and shares a lot of traits with previously identified ransomware – infection is likely to be through vectors such as phishing, brute force access to network infrastructure like RDP or compromising internet-facing hosts.
One thing that is new (but not unique) with Maze is what it does with the data once it’s in; it doesn’t just encrypt files, it syphons them off, so the target is not only being coerced into paying to regain access to their data, but also to avoid their data being exposed on the internet.
So, everything we discussed in the previous sections applies equally well to Maze as Cloud Snooper or any other malware infection, with the only difference being we aren't looking for inbound C2 messages but rather outbound data exfiltration:
It’s currently thought that Maze exfiltrates this data en-masse via outbound FTP connections, so protecting against that threat using F5 products is as simple as passing your outbound traffic through a Virtual Server and using Network Firewall policies or iRules to block all outbound FTP or to block or alert on outbound traffic destined to one of the published IOC IP addresses for Maze.
In brief, to protect against Maze:
Admit it, you skipped right down to this section, didn’t you? It’s OK – we are all busy people, I understand!
Here’s my five-bullet BIG-IP takeaway:
And, finally, my general advice five-bullet takeaway – things that apply equally to F5 products and general-purpose computing:
Those ten things, the first five of which are covered in more detail in the article above, will go a long way to ensuring the security of your network and your assets. Of course, the BIG-IP and good security practices can't obviate the need for good endpoint security, MFA for your users and so on, but you'll at least have squashed a significant amount of attack surface.