DSM firewall and trusted proxies, am I doing something wrong?

[leriak]

Hi everyone, this is my first post on the forum although I've been passive reader for a while now.

I posted a doubt yesterday on the synology subreddit but it doesn't seem to have attracted much feedback, so I though maybe you people would have some insight. I'm copying below what I wrote there, sorry for the spam if you've been there and already seen this.



I'm trying to set some kind of external access to my NAS using Cloudflare and there's some behavior with the firewall I don't understand, possibly I'm doing something wrong...

I have the cloudflare ip ranges in the "trusted proxies" section, which as per the very VERY short description in the documentation DSM should work with the origin ip instead of the cloudflare one:

DiskStation Manager - Knowledge Base | Synology Inc.

This seems to work, I connect through cloudflare and on "connected users" the ip that appears is the origin ip instead of the cloudflare one (before adding the cloudflare ip ranges to trusted proxies I'd get the cloudflare ip).

I've tried to fail to log too many times and auto-block correctly blocks the origin ip and enforces the protection.

Now I try to block the origin IP on the firewall as my plan is to allow access only to certain IP ranges and I want to check that IPs not in that range are blocked.

To test this I'm outside of the LAN, but I also have VPN access through a different server on the LAN:

• I put a rule at the top of the firewall rules with my ip address, all ports and deny as action and...
• Well, I still have access!, on "connected users" there I am with the very IP that I just added to deny access on the firewall.
• I actually thought that I would not even be able to set the rule as I undertand that the firewall rules are not saved if DSM detects that you cannot connect after making the change. But the rule is saved and there... I've even tried setting the rule while connected through the VPN with the same result.

What am I doing wrong, do I not understand how the firewall works? Or is this behavior a bug (feature)?

 

[Robbie]

DSM has little if any rules that prevent you locking yourself out with firewall rules, so be careful on that front.

The firewall rules are actioned from top to bottom, so to be active as a firewall the very last rule (ie after all the rules that allow the access you need) has to be a deny all.

 

[leriak]

Yes, thanks for the heads up, I have rules on the firewall to allow acces to the services (ports) I use and all work as expected, and I also have a deny all rule at the bottom too.

I'm being very careful not to lock myself out, but I know it could happen anyway. I have backups of the DSM settings and the small amount of test data I have copied on the NAS. I won't put more data until I'm satisfied with the setup in case I have to reset everything.

Right now I don't see where the configuration could be wrong... so I've put this approach on ice until I find additional info (if I find it).

I've removed the cloudflare ips from the trusted proxies and put them on an access control profile on the reverse proxy together with the LAN segment and a deny all rule at the bottom. Applying this profile to all reverse proxy rules works mostly as I intend: when traffic does not come from cloudflare a synology error page appears, which I don't like because I'd prefer no response at all... baby steps.

 

[WST16]

To test this I'm outside of the LAN, but I also have VPN access through a different server on the LAN

How are you doing the testing? Are you accessing DSM over VPN for testing?

 

[leriak]

How are you doing the testing? Are you accessing DSM over VPN for testing?

VPN is my "main" access, but for this testing I'm not using it.

To test the behavior when connecting from outside but not through cloudflare I disable the cloudflare proxy (gray cloud) and use a computer which is not in the LAN. It's a little slow because I have to wait a few minutes every time I enable/disable the proxy, and restart the browsers and flush the cached dns.

On cloudflare I have a few firewall rules to allow only access from certain ip ranges and other filters for bots, etc... The end goal, is to try to ensure that when someone connects from outside the traffic comes from cloudflare to enforce those filters.

I think this would be way simpler if "authenticated origin pulls" could be configured on DSM, but I haven't found a way to do it, or at least not a robust non hacky way...

 

[WST16]

Sorry, I don’t know how Cloud Flair proxies work so I can’t visualize the problem.

But if you’re saying that the origin IP address is shown by DSM when connected, then you should be able to act upon that with the firewall rules. Unless the connections coming through the trusted proxies are exempted from the firewall check, which is unlikely, because there should be a clear warning indicating that instead of just a single line explaining what is trusted proxies. Not even sure if what I’m saying makes any sense within the context of your problem.

If you wish, post a screenshot of the rules (blur what’s sensitive), maybe someone can spot something.

 

[fredbert]

It's not at all clear what the network topology is in this situation. AFAIK Cloudflare is used by most as a free Internet-based DNS but they do have a range of business services. Do they have a web access/content service that people can subscribe to? Or are we talking about a cloud-based reverse proxy service to funnel Internet requests to the [hosted?] NAS?

The trusted proxy feature sounds like it treats all traffic from that IP as good. But then it sounds that the NAS is then able to inspect the XFF headers for the 'real' client IP. My assumption would be that the NAS firewall acts on the reverse proxy's IP address and not additional XFF IP address.

The NAS firewall is stateful, so layer 4, but that's not to say that it's application aware to unpack web traffic. I'd expect, at least, that the trusted proxy would then allow the trusted client feature to work.

 

[WST16]

@fredbert presented a possible explanation (although I hope it’s not what’s happening). What happens if you put a rule to block the IP address of the proxy server in exactly the same place where you said your current rule is not blocking the origin IP address (while the “trusted proxy” is enabled of course). Not sure if this will prove anything, but I’m curious.

If I were you, I'd raise a ticket with Synology and ask about what @fredbert mentioned. Just keep it simple and direct, otherwise they’ll be confused. I hope they won't say give us remote access

 

[leriak]

Sorry, I don’t know how Cloud Flair proxies work so I can’t visualize the problem.

Cloudflare proxy does something like this
browser/client <----> cloudflare server ip A <-> cloudflare firewall/ddos protection etc <-> cloudflare server ip B <--> origin server ip (NAS)

The short story is: the client connects to cloudflare and cloudflare then to the server, so the client never sees the server ip, only cloudflare's. In the intermediate cloudflare offers ddos protection, a WAF, https redirect, a CDN, and many other services
Good:
- server ip is masked
- services offered are high value in my opinion (and free)
Bad:
- you need to trust Cloudflare: it needs to decrypt the traffic (SSL) and then reencrypt to perform its function so all data is in plain text on their servers even if only for an instant.


Anyway after some thinking I believe I know what's my original problem. I'm no linux expert but this is what I'm thinking:

• Trusted proxies work at application level (web server?): it has to as in order to pass the real ip downstream it needs to read headers in the http request
• Synology firewall (iptables?) not sure but probably works at OSI level 3/4 (TCP/IP): when traffic reaches the firewall it only knows the ip client that connects to it. packets are probably still encrypted, so it knows nothing about what's inside

So, if this is true the firewall can never block proxied traffic based on origin ip, to do that it would have to be a WAF which I don't think it is...

I can't test it right now, but when I have some time I'll test this hypothesis by:

• removing everything I've done (access profiles, trusted proxies...)
• add rules to synology firewall to allow cloudflare ips and lan ips, block the rest
• if it works (block connections not through cloudflare)
  • re-add trusted proxies, see if it keeps working but reporting the origin ips
• if it does not work
  • keep thinking

EDIT: typos

 

[fredbert]

So, if this is true the firewall can never block proxied traffic based on origin ip, to do that it would have to be a WAF which I don't think it is...

That was pretty much what i was getting at.

A similar situation would be that you're expecting the NAS firewall to act on IP addresses in VPN tunnel payload when really all it can do it act on the VPN tunnel packet IP addresses. Once at the VPN server then the IP addresses in the payload can be seen and acted on.

The addition of XFF and other HTTP headers isn't mandatory and checking them takes processing power, plus time. Using XFF is normally a way for web services to server location aware content to the client, and addresses some of the issues with centralised/regional forward proxies.

 

[leriak]

That was pretty much what i was getting at.

Thanks fredbert, you replied while I was writing my last post and I didn't see it. Yes, the situation is the same with a VPN connection.

I've tested what I said I'd test on my last post and i does indeed work: the firewall does allow cloudflare ips and blocks non cloudflare ips even if trusted proxies is configured and the origin ip is being logged in the system.

And auto-block blocks the origin ip and not the cloudflare ip.

Hmmm....

This means that "auto-block" is an application level block, not through firewall... obvious in retrospective as the login page appears even if my ip is blocked.
This design is understandable but not what I "expect" when I think of blocking... allowing connections from an ip that is suspected to be malicious is less than ideal.
Even if the attacker's is blocked permanently it can just take note of the presence of a syno and if/when a vulnerability is discovered quickly come back to exploit it.

Am I being TOO paranoid??

 

[fredbert]

What you're doing here is moving your security perimeter to Cloudflare. Does Cloudflare have security settings to block suspect IP addresses and subnets, plus geographic areas? If it does then you should use them.

However, should you have another domain (e.g. Synology DDNS) or QuickConnect that enables direct access to you Internet connection then this will not be protected by Cloudflare. You still need to have suitable local security policies to manage these connections.

On my RT2600ac Internet router I've got Threat Prevention enabled and moved all the rules for low reputation sources from Alert to Drop. Plus any rule that relates to scanning is set to Drop. I see scans precede other events from the same source. I may then configure SRM firewalls rules to do one of the following:

• block the /24 or, if other IPs are particularly noisy, /16 subnet for a while
• check where the IP is registered and add its country to my block rules

Paranoid is good

If you look at most of the DSM/package security vulnerabilities they require authenticated user access. That's not to say unauthenticated won't happen but it is much rarer, so far.

Be careful in enabling guest, public access in any services. Also, you are more exposed to other devices on you LAN so limit them and remember that things that are 'easy to use [out of the box]'/'make you life easier' usually are so at the expense of security.

 

[leriak]

What you're doing here is moving your security perimeter to Cloudflare. Does Cloudflare have security settings to block suspect IP addresses and subnets, plus geographic areas? If it does then you should use them.

Cloudflare firewall is configured to allow only ips in the range of the ISPs that need to have it (using AS number). No geographic areas, just allow certain ISPs, and then also block by thread score and known bots.

The firewall also blocks /admin subdirectories on any subdomains and other subdirectories I've identified where DSM leaks (/sspd and /dar, I'll add more if I find them)

I know I'm moving (part of) the perimeter to Cloudflare, I'm putting trust in them that they'll do a better job than the combination me+synology... let's hope the trust is well put...

However, should you have another domain (e.g. Synology DDNS) or QuickConnect that enables direct access to you Internet connection then this will not be protected by Cloudflare. You still need to have suitable local security policies to manage these connections.

Yes, I have a duckdns independent from the cloudflare domain for accessing the VPN server. DSM firewall also only allows ports that are needed even on LAN ips.

On my RT2600ac Internet router I've got Threat Prevention enabled and moved all the rules for low reputation sources from Alert to Drop. Plus any rule that relates to scanning is set to Drop. I see scans precede other events from the same source. I may then configure SRM firewalls rules to do one of the following:

• block the /24 or, if other IPs are particularly noisy, /16 subnet for a while
• check where the IP is registered and add its country to my block rules

I don't have a router/firewall capable of any of this sadly... that's part of why I'm using cloudflare. I'm also trying to maintain networking gear as thin as possible for 2 reasons:

1. spouse approval
2. mo' things -> mo' maintenance

in that order.

Be careful in enabling guest, public access in any services. Also, you are more exposed to other devices on you LAN so limit them and remember that things that are 'easy to use [out of the box]'/'make you life easier' usually are so at the expense of security.

There's no guest access anywhere, and only a very few people may need connection.
But it's a very good point, now I need to look into the firewall of the VPN server...

Thanks for your insight!

 

[fredbert]

I don't have a router/firewall capable of any of this sadly... that's part of why I'm using cloudflare. I'm also trying to maintain networking gear as thin as possible for 2 reasons:

1. spouse approval
2. mo' things -> mo' maintenance

in that order.

Been there. As documented elsewhere on here I used a well-crafted business case with my CFO pitching ABB and backing up the offspirngs' PCs, the need for more storage etc, as reason to upgrade DS218+ to DS1520+.

There're only so many stern, reproachful looks I can take so getting pre-purchase approval is better on the nerves. But whenever the 'how much?' question starts I always begin with rounding down: £230 will be around £200.

 

[Rusty]

I used a well-crafted business case with my CFO

Luckily I'm the CFO for the HW part of our household. Usually, I get the "do we need that?" question, and ofc I always say "yes we do!". No objection after that, but I do have to get some additional new HW to please the CEO. So if I want a 10G switch, she gets a new Macbook... you know the small stuff. But in the end, it's all good , everybody happy.

 

[fredbert]

All the C-level positions are held by one person here, and that includes Chief of TV remotes.

 

[Robbie]

I get the remote but she tells me when it should be used. I'm like a more reliable Siri.