Firewall Rules: Allowed IPs and Threat Prevention?

Currently reading
Firewall Rules: Allowed IPs and Threat Prevention?

Quick question, but probably one that betrays how little I actually understand Threat Prevention at the moment.

If I create a firewall rule that allows traffic from a range of IPs, will threat prevention just ignore those?

I use a particular remote desktop streaming service that's generating a metric ton of High Threat alerts and blocks. TP is identifying that traffic as shell code execution, and I don't just want to blanket tell it to "do nothing" for all shell code execution. I also don't want to keep creating TP rules for each specific random IP I end up connected to at the cloud service.

The firewall, on the other hand, lets me define rules for a range of IP addresses, unlike the TP package. If I allow a range, will TP just ignore those?

I'm not running any world-facing servers at the moment (except for the WAN-accessible SRM control to enable the Let's Encrypt cert to automatically update). Is it even worthwhile to have Threat Protection turned on if I have the firewall enabled? As much fun as it is to tinker with, it's a pain to have to keep tinkering with it to figure out how to get it to stop generating false positives. (Like, why has Synology not figured out a way to get it to stop flagging legit STUN traffic?)
 
Short answer

No, I don't think so. TP rules are applied to all traffic that the FW thinks is OK (definitely for inbound and probably for outbound too, otherwise TP processes all outbound traffic before FW [not tested it]).

TP rules can be added that only need to match a source or destination IP while leaving the other blank.

Use AbuseIPDB - IP address abuse reports - Making the Internet safer, one IP at a time to check the reported IP to determine if the traffic is OK or not: some STUN is done by DDNS agents but it can be clients opening back ports for Internet services.

You can also decide on the type and frequency of notifications you get. If you are using email then you might be able to set inbox rules to move and mark as read to another mail folder. Then set some time aside to review the alerts.

One thing is that you're probably now getting alerts for activity, and stopping some, when before if was all happening without your knowledge.

Keep TP on and tune the policies. You could also assign DHCP client IP reservations so LAN clients always get the same IP and this will make your TP custom rules more accurate.

TL/DR
From my usage of combining FW and TP:
  1. For blocking Internet scanning: TP alerting and blocking when no FW rule specifically blocks the source IP changes to no TP alert when a FW rule blocks the source IP/subnet. That implies inbound connections are filtered first by the FW and only then by TP.
  2. Normally allowed inbound NAT + FW traffic to NAS: Any of the NAT (port foward) rules has an associated FW rule. I still get TP alerts on these permitted connections.
This all implies that the two protection mechanisms are separate and FW rules and TP are not aware of each other. And this is a good thing!

Why is having FW and TP separated and applying two policies vs a merged policy?
  • In a merged policy which rules will take precedence?
  • The mechanisms are not applying the same type of control:
    • FW: considers the packet header information and decides if this connection instance meets any acceptance criteria and then either allows the connection or not. In the stateful FW it then tracks the protocol and service to ensure packet follow the expected pattern.
    • TP: considers the behavioural patterns of the traffic. It can inspect the payload data as well as associating other connections' characteristics (source, destination, ports, payloads) and will then determine if there's a pattern that matches a risk.
You should setup the FW to filter out the unwanted traffic, after which you are left with the acceptable traffic. But just because it meets the FW rules it doesn't mean that it is not malicious. The TP mechanism is now working on approved traffic but checking for anomalous behaviour (which may be malignant, or not). If you were to accept that the FW's 'OK' traffic doesn't need to go through TP (and all FW traffic will have to have matched an accept or deny rule) then there's no point in having TP ... for inbound connections.

As for outbound connections then it depends where TP is applied in the processing flow. For discrete appliances that do FW and TP (IDS/IPS) then the usual approach is FW first from the the Internet and IPS behind it: meaning that outbound traffic hits the IPS box first and then FW box. But for all-in-one appliances it can be different and it could be that it always applies the same functional processing from any interface: FW first and then IPS (TP). And is where it gets interesting because different vendors have historically applied routing and NAT processing at different places in this stack, both in relation to each and to FW filtering ... you had to know how to write the rules for FW processing: was it before or after NAT had been done and which interface it's heading towards.
 
Thanks, @fredbert . This is awesome, and I'm going to study it carefully before I try messing with TP again.

Right now, I've left Safe Access and the Firewall on, and turned TP off again.
Until I get a better handle on how to actually properly tune the firewall, I can't keep trying to tinker with it every day. I need to have a better grip on what I'm doing and an actual plan for tuning it, and try to do that all at once.

I ran into two issues, one annoying and one showstopper.
  1. My cloud gaming service kept getting dropped for attempting to execute shellcode. This is not important at all, except to show me that I do not yet understand how to most efficiently blanket allow a service that uses a bunch of ports and several (dozen? more?) IPs.
  2. TP was dropping/blocking dozens/hundreds of STUN related traffic events a day. This was a huge problem as it actually seemed to be making my work VoIP connection less stable. My iPhone (everyone's iPhone, here) uses WiFi Calling to help compensate for the crap cell reception in my building, and at one point it was so confused it wouldn't even dial out even after I restarted it.
I"m not actually 100 percent sure (2) is completely the fault of the router, but every dropped STUN traffic event I checked was attached to a legit VoIP service. All the problems also cleared up after I turned off TP, so...

Again, I need to get much better at tuning the TP rules before I turn this back on. I can't have it impacting my work--most of which I do by phone/internet.

The good news is when TP was on, it didn't impact my maximum network throughput at all (using a hardwired PC to do speedest). Synology's implementation is fanastic.
 
When deploying a business IDS/IPS it is normal to have a period of tuning (aka baselining) over a few weeks or more. This would be analysed to establish what is normal and the policy would be set to minimise false alerts. Over the operational life of the service there would be re-tuning to ensure the policy remains efficient.

With TP you could just identify the rules that are causing the problem and without assigning source or destination IP just set them to alert or do nothing.

The role of security mechanisms is to mitigate risks and ultimately there is a trade-off between the cost of the mitigation vs the impact of the risk being realised. In the end you have to be pragmatic: it's like the joke about the two guys that confront a bear, one guy puts on his running shoes and the other says 'you can't out run a bear' to which he replies 'so long as I'm faster than you' ... security can sometimes be a bit like that :)

BTW I'm not sure if it's applicable but there's a SIP pass-through setting in Network Center. My work uses Cisco Jabber VOIP and I don't have any issues with this passing through SRM.

As for gaming: yep I see loads of alerts and drops when my son is online gaming but since he hasn't complained since the WiFi signal improved (Apple Airport to RT2600ac) I'm guessing it doesn't adversely affect it. Though I have added accept rules for Microsoft authentications and other known cloud services.

A thought for TP: you can opt to disable TP on a per device basis so you could disable TP for iPhones but leave it on for general purpose OS devices (which are more likely to store business data)
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

Just asking again if more in-depth information or rules are available than link posted. I keep creating...
Replies
1
Views
1,227
Now I'm not looking on my phone.... The best you can do is to split the single 192.168.1.0/24 subnet and...
Replies
6
Views
2,056
ofc you can test the rules when they're setup. Ping from any device to any device within your LAN - ping...
Replies
11
Views
1,309
Deleted member 5784
D
  • Question
@Gerard No port forwarding. No particular need as far as I know.
Replies
3
Views
1,704
This is more SRM 1.3.1-1 than RT2600ac specific. Something has been bugging me: I use IPV4 settings here...
Replies
0
Views
1,354
I've never been a torrent user but I think that it allows for bits of downloads to be retrieved from...
Replies
5
Views
1,720
Firewall rules are checked from top to bottom (first to last). When a matching rule is found for the...
Replies
1
Views
2,478

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top