I recently made the decision to ditch my old Sonicwall TZ 205 in favor of the new Synology RT 1900ac. As a security guy, this seems like an odd decision, but since I was not paying for any of the advanced Sonicwall services, it really just came down to convenience and support. I run a Synology 1815+ at home and love everything about it, so I wanted to give their brand new router/firewall a shot. Unfortunately, I’ve run into some very strange firewall behavior that I’ve been trying to work through with their support team.
Now, to understand the problem it is import to know some basic things about how firewalls work:
First, the rules are read by the firewall in a “top-down” manner. This means order matters when creating and organizing your rules. Placing a rule at the end of the list may not have the same effect as placing it at the beginning.
Second, the moment a rule is matched, the firewall stops evaluating that traffic. That means if you have conflicting rules, the firewall will enforce the top most matching rule and ignore all others.
And third, an important part of all firewalls is a (usually implicit) Deny-All rule at the end of the list. This rule tells the firewall that if the traffic it is evaluating does not match any of the rules in the list, do not allow it through.
So if I have a rule on line 1 (the top of the list) that allows FTP traffic, then a rule on line 5 (fifth down the list) that denies FTP traffic, it will result in the FTP traffic being allowed (because line 1 is above line 5 and matched first). If I have no rule at all, the traffic will be denied, because no allow rule has been matched.
So, with that understanding, here is my current setup: Internet > Synology Router/Firewall> DMZ (with FTP Server) > Internal network. Obviously, very simplified for brevity, but there you have it. To enable my FTP server to be reached from the outside world, I have a Firewall rule that reads as “Allow TCP traffic on port 21 from any IP within the United States” (this is ignoring NAT, port forwarding and all that jazz, as it is inconsequential to this post).
Synology also gives you the option of specifying whether unmatched traffic should be allowed or denied. In 99% of cases, you want to deny unmatched traffic, but it is nice they give you the option. So, with my rule in place to allow FTP traffic from the US, and deny any other traffic, I carry on with my life assuming I’m perfectly well protected (see screenshot below).
A few weeks after setting this all up, I receive an alert from my FTP server informing me that it has automatically blocked the IP address 188.8.131.52 for attempting to hack the server. This seemed a little strange to me, as I don’t recognize the 184.108.40.206/24 address range. A quick search shows me it originates from Vietnam:
Now this seems strange – I *know* I configured my firewall to only allow IPs from inside the United States. I’m not overly concerned though, automated attacks are a part of life and my FTP server handled it just fine. But it raises questions about the firewall so I contact Synology support. The response I received is that the database they use to determine IP locations is not 100% complete and that IP range was not in it. This seems pretty reasonable to me, so I let the matter drop.
17 days later I get another alert from my server, this time informing me that it blocked the IP address 220.127.116.11. This time it is an IP from China. Alright, fine. Maybe they are missing that IP as well. I guess that is understandable – new product and all. But sure enough 8 days later I get yet another alert. This time the IP is 18.104.22.168. Now once or twice I can understand, but 3 missing address ranges all from different countries starts to seem like a problem.
So, I contact support once again. They initially seem to have no idea what is going on. After a bunch of back and forth the engineers determined that there is a bug in SRM 1.0 causing this behavior. They say a fix is upcoming in SRM 1.1, but suggested in the meantime I create an explicit deny rule to disallow FTP traffic and place it below the allow rule. This would cause any traffic not matching the allow rule to be explicitly denied before even reaching the implicit rule at the end (see screenshot below again).
However, once I created and enabled this rule, all access to FTP was severed. I could no longer connect from any external IP address (US or otherwise). This was more troubling to me than anything that had happened up until this point because it seemed to defy all three of the basic rules of firewall operation.
If the Deny FTP rule was stopping FTP traffic it means:
1) The firewall is continuing to assess rules after finding the first match OR
2) The firewall is assessing the rules out of order AND
3) The Implicit Deny rule show at the bottom of the list is not functioning correctly
I have tested this with multiple services and multiple rules so far. As far as I can tell, the Implicit Deny rule is definitely not functioning correctly. I believe this has to do with only allowing traffic from certain regions (rather than by specific IP), but I cannot be positive. Additionally, there is definitely an issue with the way in which the firewall is assessing the rules. I can’t tell if it is continuing to assess until it hits a deny, or if it is just assessing out of order, but either one is a huge problem.
I have another ticket in with the Synology Support team and will update this post as I get more information. For now, however, if you are considering investing in an RT 1900ac I would strongly suggest holding off.
UPDATE: Synology informed me that this was a problem with the behavior of their Implicit Deny rule and that it would be addressed in the next SRM update. SRM 1.1 has since dropped and they did make a significant change to the way these rules function.