Rules added to firewall as a Test or 'Make Damn Sure'

Currently reading
Rules added to firewall as a Test or 'Make Damn Sure'

DS 718+, 2x-DS 720+
  1. RT2600ac
Operating system
  1. Windows
Mobile operating system
  1. iOS
Last edited:
I've 13 Hikvision Cameras that have the latest firmware in them, but firmware pre-dates Last September's Hikvision Security issues.... I do not have remote access turned on any cameras.. and even went so far as to enter an incorrect gateway....
With all this, the cameras work perfectly, locally via LAN, with their software, or, SS via NAS.. SS access to cams Works fine, local or remote.
Hikvision says the firmware I have is current.... but will not confirm it is still secure. That's what started this!
At the UK user's site, where information if more freely given.... they confirm that firmware I have 'should be' good, as long as remote access is not configured, and confirm that no further firmware version is available....
First Make Damn Sure: Block access of all cameras in Traffic Control....
So, anything else I do would do to improve this -- would have to be done at the Firewall..

So here's what I've done (Last September) as an extra: Make Damn Sure:
1. Cameras are all Static IP's ..
2. Extra DENY Rule in firewall to block camera IP's access to internet -- just to log for hits -- Nothing ever received.... good!
3. Extra DENY Rule in firewall to block camera IP's ICMP (PINGS) from cameras to internet -- just to log for hits -- Nothing ever received.... good!
3. Access list of IP's to Alllow Access to internet in firewall does not include any IP's of cameras... Which logs Lots of (expected) Hits...

With the 2 extra rules added to the firewall (that have yet to log even 1 hit) which is ABOVE the ALLOW INTERNET ACCESS Rule... That is my "Make Damn Sure"..... for the cameras... This was done last September... I think with this I'm OK..... This is something that will be shared by others: dealing with security issues that may show up on gear that the Manufacturer has “Walked away from” !You're Comments....

End of First question....

So today was browsing and saw a conversation on blocking all Pings originating from the internet .... That Sounded interesting.... but would have thought that router would have done that automatically...

So I added a new DENY Rule: ICMP, Internet, ALL, ..., ALL, ALL, ..., DENY

and that is placed at top of firewall list... An hour later, no Hits...

Comments on this.... also....
Last edited by a moderator:
A quick thought re your 2nd point (ICMP). ICMP is intended as a troubleshooting & error-repoting & diagnosis tool for the IP protocol; as such it's a valuable tool for helping diagnose network problems.

I completely understand blocking pings from the internet as a security measure...but in fact pings are only a small part of the ICMP protocol (0, 8 & 11). The ICMP proto also does useful stuff like Path MTU discovery, Destination Unreachable (ICMP type 3) and Quench (type 4) which help your router and other devices in setting packet sizes / transmission rates etc etc. These are particularly useful in the event of network problems.

So I tend to firewall BLOCK particular ICMP types (ie pings from the internet) rather than the whole protocol in order to get the best of both approaches.
-- post merged: --

On the 1st point, I do exactly the same as you! I have a couple of IP cameras (Eufi / Anker) that are fairly recent and still get fw updates. But I still dont fully trust them (how much trust can you ever have in a GBP40 iot device...!), so I put them on a separate isolated Vlan and firewall them so all they can do is reach the internet, nothing else on the LAN.

Belt & braces ;)
I'm not familiar with that router so can't help with the specifics. I use a Mikrotik router running RouterOS and the ICMP firewall rules are like:

/ip firewall filter
    add action=jump chain=forward protocol=icmp jump-target=icmp comment="jump to ICMP filters"

  add chain=icmp protocol=icmp icmp-options=3:0 action=accept \
    comment="net unreachable"
  add chain=icmp protocol=icmp icmp-options=3:1 action=accept \
    comment="host unreachable"
  add chain=icmp protocol=icmp icmp-options=3:4 action=accept \
    comment="host unreachable fragmentation required"
  add chain=icmp protocol=icmp icmp-options=11:0 action=accept \
    comment="allow time exceed"
  add chain=icmp protocol=icmp icmp-options=12:0 action=accept \
    comment="allow parameter bad"
  add chain=icmp action=drop comment="deny all other types"

The 1st line adds a rule to jump to the ICMP chain on receiving any ICMP packet. The rest of the lines create specific ACCEPTS for each ICMP type that I want to allow in.

This relies on RouterOS's inherent understanding of icmp types (the 'icmp-options' parameter in the lines above)... I include it to show the general idea; not sure if a Synology router has an equivalent...?
Maybe someone else can chime in?
So I can add those extra rules in 2600 firewall? I don’t seem to understand how to do that.
These rules I created were to improve isolation of devices (question #1). I think I got a positive answer to that. No ‘hits’ in 13 months is further proof of success.
Question #2 was an attempt to react to a recent interesting post. And that rule is just hours old, so I wanted confirmation it was ok…. Which it may not be from the replies.

Your document is impressive, but I’m not clear how to implement it in 2600 firewall.

‘Hits’ is the only tool I have to confirm a rule is working. So, I’m creating some rules just to test for ‘hits’.

I’m limited to whatever 2600 can do. (Why I posted in 2600 area)
@Jan Janowski If above is not possible on your router, I would create a firewall rule to ALLOW ICMP proto from local LAN IPs; and DROP ICMP from all others.
That way, at least your local devices can ping router / set fragmented bits on packets etc, and the internet will remain unaware of your router's presence.
In the event you have an external networking problem that needs troubleshooting (eg remote VPN access), you can just switch off the ICMP block while you troubleshoot, then re-enable when you're finished.
Firewall rules are run from top to bottom, and will be applied going down the list until a packet matches a given rule.
So, you need 2 rules, somewhere near the top of your firewall rules list:
  • Direction: IN, Proto: ICMP, FROM_IP: (ie your LAN), Action: ACCEPT
  • Direction: IN, Proto: ICMP, FROM_IP:any, Action: DROP

They need to be in the order I've specified above, and before any catch-all 'ACCEPT' rules that may already be in there.

These are pseudo-rules (I dont know your router), but you should be able to work it out based on the above.
Ok: add one more to ALLOW: LAN IP’s ICMP to internet in front of the DENY ICMP from internet. That makes sense. Seeing that I’ve not tried to PING, I have not run afoul of the existing rule, but it does make sense that it’s needed.
But again that is the ‘entire’ ICMP rule, not subset discussed earlier.
ofc you can test the rules when they're setup. Ping from any device to any device within your LAN - ping should get replies and you should see rule 1 getting hits.
Ping your public router IP from outside your LAN (eg from a phone) and it should fail and you should get hits on rule #2.

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.

Old thread notice: There have been no replies in this thread for quite some time. The last reply was on .
The content in this thread may no longer be relevant. It might be better to open a new thread instead.

Similar threads

Just asking again if more in-depth information or rules are available than link posted. I keep creating...
Now I'm not looking on my phone.... The best you can do is to split the single subnet and...
  • Question
@Gerard No port forwarding. No particular need as far as I know.
This is more SRM 1.3.1-1 than RT2600ac specific. Something has been bugging me: I use IPV4 settings here...
I've never been a torrent user but I think that it allows for bits of downloads to be retrieved from...
Firewall rules are checked from top to bottom (first to last). When a matching rule is found for the...
  • Solved
That's what I was after.... The DENY ALL RULE Covers and blocks EVERYTHING not specifically indicated as...

Welcome to! is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Trending threads