So a few days ago I was killing time by listening to a webinar on our website webinar: https://www.kaseya.com/resources/best-practices/ransomware-and-your-msp - and it made me think about a few things surrounding the topics.
It doesn't surprise me that 4 out of 5 MSPs have had to deal with ransomware attacks of their clients, what does surprise me is that most businesses seem to be in reactive mode, rather than proactive.
Additionally, what is your business doing to ensure who doesn't have to be lumped into this group? The webinar suggests a Layered Security approach, but I want to hear your thoughts.
Layered proactive security:
- remove local admin rights
- spam filter emails
- group policy software restrictions - no launching executables from temp folder; ban use of command line tools used by crypto programs (e.g. use cryptoprevent)
- monitor for violations -> audit event logs to detect blocked actions hence users that are failing to recognize scams; understand "what got through" and retrain user.
- ensure 'previous versions' turned on for rapid file recovery
- thorough test of backups; ensure backup location not accessible by users - hence not able to be damaged by crypto
- strong patch update policy; close those known security holes
- decent antivirus/antimalware installed & maintained
- TRAIN USERS to recognize and delete phishing emails & have strong security practices
- subscribe to relevant security news feeds, mailing lists etc. to remain informed and understand new attacks as they emerge.
Also, audit security permissions - remove access where not necessary; this reduces the targets that can be attacked, hence less work to do in restoring if you are compromised.
Also, have a precovery policy .eg. identify source, clean/wipe source machine, restore files from backup/shadow copy, scan to ensure infection removed, identify attack vector & re-train user.
Also, password policy. Many attacks are now due simply to weak passwords + public facing RDP, VPN, etc. We sometimes white hat client password databases to identify weak passwords e.g. Password1, Welcome, etc. that rainbow tables can easily crack.
We have also removed 'administrator' and used a non-obvious admin name, hence removing one half of the hackers known login credentials.
We are also looking at 'fail2ban' type technology to block internet facing IP's that try to brute force logins. Where possible be geo-block Ip ranges e.g. russia, china etc. as we don't have users located there.
Moved away from KES or KAV .... !!!
Great points Craig! What I think may be the simplest, and most obvious, way to prevent this from happneing really is just training employees to be as vigilant as possible and keep a strict password policy for all those involved.
Combined with the other techncical aspects you listed it creates the best position you can be in for a Layered Security approach.
Anyone else have any thoughts on the matter?
Things we do:
-No Open RDP from the public Internet ---ever---
-SonicWALL Comprehensive Gateway Security Suite (gatewayAV, spyware, intrustion prevention, botnet detection features enabled)
-Sonicwall Geo-IP filter on all inbound rules
-OpenDNS or like service (we use Appriver's SecureSurf)
-hosted spam/virus filter (we use Appriver Securetide, even with O365)
-MBAM, Webroot, Cryptoprevent on desktops and select servers)
-Restrict Windows "Administrators" LocalGroup to only select accounts (no "FOO\Domain Users" ever!)
-Maintain Patches is a given! (Especially Adobe Flash)
-most importantly: End-User Security Training!!! (i.e. knowbe4.com)
-VSS snapshots, especially on Servers
-Backup Shares (NAS) are restricted for access to only one select account
What we want:
-NetFlow Reporting & Alerts
Ransomware is a virus that encrypts the files on your PC and then spreads to the data on the server. Ransomware has been taking the virtual world for a ride with versions derived in different forms.
Invest in security
Update the software regularly
Go for effective password management and access control
Take the Backups
Regularly do system vulnerability test
Whitelisting technology. It doesn’t matter what method you select, but something is better than nothing. For example. AppLocker is great, but is hampered significantly by vendors using ClickOnce installations, which are still a supported technology. Even filtering based on executable name alone will block essentially all common malware.
Then don’t be dumb! Allowing SMB access over the internet will get you hacked. RDP access is equally an issue – in fact, there are few services that shouldn’t be accessible only over a VPN, or without specific IP restrictions.
Standard security practices:
• Principle of least privilege
• Patching of OS within 48 hours of patch release
• Patching of applications within 48 hours of patch release
• Application whitelisting
Ransomware runs in context of a user. The access rights of a user obviously mitigate what the malware can do, however for users to do their job they will present the malware with an attack surface. This is especially the case in small businesses, where it is generally a business requirement to have all users granted full access to 95% of data.
User training is the best available mitigation for initial compromise, however we need to recognise it is the failing of the overarching IT systems that are at fault. Without entering into a tautological argument, consider iOS as a comparison to all desktop systems. Yes, it has less configurability, but there are unarguably less security issues over the past decade with iOS. Which is to say, user training is great, but things will get past users, no matter their experience or training – some social engineering is undeniably great! The answer to this doesn’t exist today, but it will lie with replacement technologies (perhaps even Windows Apps)
Reactive security practices
• Shadow copies of all data
• Good backups, running every hour or so at the most, for those cases where shadow copy is no longer useful (malware could fill disk space to delete past VSS, and advanced (or administrative context) malware could simply delete the shadow copies)
o Must not be accessible to any security context that has write access to data – otherwise it is to be assumed to be compromised at the time of infection
• Procedures for recognising an attack is in progress, AND immediate mitigation strategies. For example, accessing more than 200 files in a couple of minutes may be odd in a given environment, and that being the case, making the share read-only completely mitigates any continued destruction
Just some notes!
Oh, Craig - just a matter of opinion, but Fail2Ban is a risky option. It essentially is giving root privilege to a process that is possible to abuse. How long until a persistent attacker works out how to have you block 0.0.0.0/0 through spoofing and you are locked out of your own devices to remotely fix?
Just my two cents...
eyeTSystems I said 'fail2ban' type technologies - not naming a specific product. however, in any case these products block only a single public IP address (the subnet mask is always 255.255.255.255 and this is hardcoded) and simply can't be fooled the way you imply. blocks are time-based also; after a period the timeout resets, meaning any lockout is temporary. This may be a form of DoS but it's not fatal, as you imply.
As you say however, any "block" type tech is an increased risk - in the same way that having an account lockout policy increases support workload when the user typos their password a bunch of times and can't log in.
I'd still rather just drop all traffic from an IP for an hour, than allow the hacker to flood my bandwidth 100% for an hour as an unlimited number of user/pass combination attempts are thrown at our systems.
To each his own - but lets not spread FUD unnecessarily.
Speaking of FUD, a moment to look at VPN. VPN isn't some magic security system that "fixes all" or offers "perfect" security.
If I have a user with a username of 'user' password of 'Welcome' and RDP or SSH open, he is probably going to be hacked pretty quickly.
How is the same user more secure with 'only' VPN public-facing? Answer- he isn't. Only the protocol has changed, not the security itself.
Therefore' just screaming "use a VPN" is no solution.
(Hopefully this is all being taken as a spirited discussion over a coffee rather than rage on a blog hiding behind pseudo-anonymity)
I missed the fail2ban type part, and used the IPv4 range as an example. I guess what I’m trying to say is that it is a risk analysis (not FUD), as long as an informed decision is made, it can’t be wrong.
I’m also not saying that a VPN is a magic security system – but I do maintain that using a VPN for access is more secure than not using a VPN. Poorly chosen, implemented and located VPNs offer marginal security benefits. Done properly, a VPN offers a major security increase – some thoughts are below.
A VPN is an encrypted tunnel. A properly selected and configured VPN should be invulnerable to eavesdroppers, and withstand retrospective attack even with knowledge of encryption keys. Therefore, simply using a VPN to connect to another service is more secure in terms of a potential attack against the underlying protocol. In the example of RDP, if there is in the future a method of decrypting captured communications, passwords would no doubt be exposed. If the RDP communication was encapsulated within a VPN, there is no reasonable assertion that the RDP traffic would ever be exposed, unless we are then supposing a compromise of the VPN technology before the RDP weakness is to be exploited.
A VPN is likely replacing more than one open port. This being the case, attack surface is reduced (and in any case, isn’t being increased), and complexity increased for an attacker. It is NOT a panacea, but it sure helps. This is why we are all told to layer our protections – to use defence in depth.
Granted, VPN is a service itself, and is potentially vulnerable to code exploits, and poor configuration like all other exposed services. I would argue that even a poorly configured additional layer of security is better than none. Even if the VPN server is compromised, it doesn’t leave the internal network in a less secure state than if the services were directly exposed.
It also depends on the choice of VPN technology. A PPTP connection with weak credentials is not going to withstand attack. A PKI based VPN with forward secrecy is unlikely to be compromised through a weakness in the protocol, and without a shared key is computationally infeasible to attack.
Finally, the placement of a VPN server on the network is a differentiating factor. If you have RDP exposed to the internet, the attacker is already sending packets inside your network to attempt a logon. With a VPN server, no data from the outside should ever get to the inside of your network. Even assuming a compromised VPN server, there should be less implicit rights than connecting directly to a machine. More specifically, an RDP server is likely domain joined (i.e. SSO), and vulnerable to various attacks, and you would already have authenticated. A VPN compromise would gain you physical network access, but still no access to the RDP server.
I would go one step further and specify a *properly configured* VPN can definitely be a big help. To directly address Craig Hart 's last statement for example. There is more to a properly defined VPN than *just* a username and password. For example we are a sonicwall shop and often make the use of their Global VPN clients for case uses such as what is being defined here. In a case like that there are actually two different pieces of information that any attacker would have to have in order to connect via that VPN.
1.) They would first need the actual IPSec Key that is in use for the VPN configuration. Without the IPSEC key knowing the user's credential's does nothing for you.
2.) The user's credentials, which may or may *not* actually be the same as their network username and password. In our case we actually utilize AuthAnvil with their Radius plugin, and have the VPN appliance using Radius to authenticate the user. So have to utilize their username, PIN and the AuthAnvil token to log in (yes we still use the old onprem setup).
Overall the best answer for *all* scenarios is can be simply described with two words.
There is no one shot fix for everything. In that respect I agree with Craig about VPN's not being the be all, end all solution. But it is one piece of the pie.
To make a few points in rebuttal (and yes this is a friendly chat over coffee!). an IPSEC VPN with a key, is actually implementing 2FA. So, the additional security actually comes in fact from implementing 2FA, and not VPN itself. To make a point, if I could implement RDP with 2FA, then I'd be just as secure.
Also, in terms of encryption, RDP uses the same encryption as SSL (go look it up). Granted, other open ports using legacy protocols (e.g FTP) don't offer encryption, so generically speaking VPN can add to security by adding an encryption layer to an unencrypted protocol, however RDP is not vulnerable here.
It is a point well-made that "some" VPNs are actually less secure e.g. PPTP - which is why the likes of Apple have dropped IOS support for PPTP. Implementing VPN poorly, leads to a false sense of security. And guess which VPN is the default type and easiest to configure in windows server [Shout out to SBS Server] :)
In terms of public-facing open ports - automated port scanners have existed for 20+ years. reducing the attack surface is really moot - just one open port is enough to gather the hackers attention, and the hackers will check VPN ports just as much as any other. I do agree however (see above) it can make your security job easier if you don't have to independently ensure security on a bunch of different public facing protocols, and instead just secure one protocol -- however that belies the layered approach; strictly speaking if the protocols aren't secure to begin with, why are they in use?
Having said that, moving something like RDP to a nonstandard port does cut down a fair % of the 'noise' generated by automated attack scripts. It's more about just avoiding this 'script kiddie' type traffic, than adding security however.
Finally, lets talk about what compromising or 'hacking' actually means. two points here - one is gaining a valid login via a weak password (hardly hacking); the other is actually exploiting the VPN server itself. There's a clear distinction there.
If I 'hack' RDP by discovering valid credentials, i'm logged onto the box (probably as a standard user). what I can access then depends on windows security; e.g. i'd have to try to escalate privilege to do much further damage (or, launch some ransomware, perhaps).
If I hack VPN the same way, i'm now a trusted host on the LAN. I'd argue that's a lot worse - I can now scan your whole network, discover hosts and internal systems, sniff and inject packets, etc. and most likely do so with impunity (VPN implementation-specific, of course). I'm not sure which you'd consider worse, but I suspect that both are equally bad, with VPN being potentially a lot worse in my book.
If however, I exploit the VPN server itself, then anything could by on the cards - depending if the VPN box is part of the firewall, a windows service or linux daemon on an internal box, etc. so there's a lot to think about.
As others have said, it's a complex beast and there is no one simple solution. So to those that simply say "VPN" as a one-word answer to security - well that's just wrong.
There's really a few things to take away from this discussion:
1. Remove anything insecure from public facing - that means no plain FTP etc. that don't offer encryption. A strong VPN may be a way to achieve this. Replacing with secure protocols e.g. SFTP, IPSEC may be another option.
2. Everything is [by default] only as secure as the passwords chosen. So use strong passwords and audit their use.
3. Implement 2FA where possible.
4. Keep up with vendor patches.
5. Layered security. Ask yourself what might happen if your first level of defense was compromised - what if bob makes his pasword "password" and a hacker does connect to your VPN or RDP box? what then?
6. Backups. Have them. Make sure they work. They're your last line of defense.
7. Don't be the 'low hanging fruit' - RDP on 3389 , SSH on 22, etc. is just asking the hackers to come and try their luck, but also understand putting RDP on 3390 and SSH on 222 isn't some genius security fix that absolves you of any further effort.