Home => A firewall rule can help block ransomware
August 29, 2021
In the good old days, ransomware simply referred to bad guys encrypting data files to make them inaccessible without a password (key). But, apparently enough companies were not paying the ransom, so the bad guys got meaner.
Now, encrypted files are only half the story, bad guys are also stealing the data files. Victims that don't pay up, will have some of their sensitive data leaked to the public.
In the August 2021 breach of T-Mobile, it was reported that over 100 gigabytes of data was taken by the attackers. In the previous high profile attack, on the Colonial Pipeline, it was also reported that the bad guys stole close to 100 gigabytes of data (in less than 2 hours). That's a lot of data.
On the one hand, I have wonder how the exfiltration of so much data goes undetected?
But, this blog is to offer a new defense, not to trash these companies (even if they deserve it). The data theft might have, maybe, been prevented, or at least mitigated, with a simple firewall rule. At zero cost.
DO YOU QUALIFY?
Like many, I store much of my data on a Network Attached Storage device (NAS). My NAS is from Synology, other big players in the field are QNAP and Western Digital. These devices have often been targeted by bad guys and they have their fair share of bugs, like any server. My Defensive Computing Checklist website offers some suggestions and links to improve the security of a NAS.
What's there, however, is the equivalent of rounding up the usual suspects. A firewall rule, on the other hand, is off the beaten path. Rather than prevent the hacking, the firewall rule can (hopefully) mitigate it by blocking all or some of your data from being stolen. A firewall rule does not prevent bad guys from encrypting your files and holding them for ransom, just from stealing the files.
However, this requires a router that supports outbound firewall rules. So, many people reading this should just stop here. Consumer routers, as a rule, do not offer customizable outbound firewall rules. Neither do routers or gateways (combination modem/router) supplied by an ISP. The default operation of consumer routers and gateways is to let any device on your home network send anything it wants out to the Internet, at any time. For me, that won't do.
The type of router that probably (I have not tested all of these) supports outbound firewall rules is pfSense, OPNsense, Ubiquiti UniFi (not AmpliFi), DrayTek and Untangle. No doubt there are many other options too. Personally, I use Peplink routers and the example firewall rule below is from a $200 Peplink router.
THE MAIN RULE
For the most part, my NAS communicates with the devices in my home. But, once a day, it sends some files out to an off-site storage provider for safe keeping. This backup happens between 9 and 9:30PM. So, the obvious choice for me was to only let my NAS communicate with the Internet for those 30 minutes. The other 23.5 hours in a day, it can only communicate within my home.
Below is the firewall rule that implements this.
This is not rocket science.
On the source line, you see an IP address of 192.168.23.23 which is my NAS. For the firewall rule to work, the NAS has to have this same IP address every day ("static" is the official term). This can be done by either the NAS itself or by the router. The Destination line says "Any address" which means any computer on the Internet. Outbound firewall rules apply from my home out to the Internet, they do not apply between the devices in my home. On the Action line you see that communication is Denied, and on the Event Logging line you see that I don't bother logging every time the rules blocks the NAS. Anyone who does log this activity will probably find their NAS is quite chatty.
The Enable line is doing two things. The checkbox means the rule is enabled and the box next to that is the name of a schedule. Peplink routers support schedules that can be assigned to assorted things such as WiFi networks (SSIDs) and Firewall rules. The schedule name can be anything, but Off-9PM-on-9.30PM is as descriptive as I could get. It means the firewall rule goes off at 9PM and back on at 9:30PM. The blockade is dropped for 30 minutes.
Below you see the definition of this schedule in the router. Each green boxes indicates 30 minutes when the schedule is active. Gray boxes are when the schedule is not active.
If my NAS gets hacked, the bad guys can only upload files for 30 minutes a day. Hopefully, they give up before they discover the open window.
The enemy of security will always be convenience. By blocking Internet access, the NAS can no longer detect and/or install updates to the operating system or any of the apps it runs.
Perhaps I could set an alarm, log in to the NAS during the open 30 minutes window and manually have it check for updates. Or, I could disable the firewall rule at any time and then have it check for software updates. Synology lets customers download new versions of the NAS operating system (DSM) at any time, so I could do that on my computer and manually install the update over the LAN, without the NAS ever communicating with the outside world.
We all have to decide how much inconvenience we can tolerate for improved security.
For the NAS to run my file backup at 9PM, it needs to know what time it is. To that end, the device makes outgoing Network Time Protocol (NTP) requests fairly often. To allow these requests, I created another firewall rule, one that is checked before the rule above. The NTP requests from the NAS show up in the router as a UDP request from port 123 on IP address 192.168.23.23 (the NAS) to port 123. The rule is shown below.
Like many devices, the NAS phones home to assorted NTP servers, to insure that one will always be available. This is why the destination in the rule is "Any Address". I could dial up the security by configuring the NAS to use only one NTP server and then allowing only the one IP address in the firewall rule. But, enough is enough :-)
|@defensivecomput||TOP||Home => A firewall rule can help block ransomware|
|michael--at--michaelhorowitz.com||Last Updated: August 29, 2021 10PM UTC|