Info Security and your DSM setup
- Thread starter jeyare
- Start date
- Latest activity Latest activity:
- Replies 84
- Views 18,352
Currently reading
Info Security and your DSM setup
thx
when you are sure about your NAS security, you can open next round - DNS security.
First really easy step for everyone is use:
For an exact check of possible leaking of unencrypted DNS traffic you can use more low-level tool: tcpdump in your router.
1. you need find your WAN interface from the interfaces list:
or
and the possible result is e.g: eth0 …. for my Unifi USG-Pro
2. then you need capture traffic on standard DNS port: 53
ofc is better to use include the option (-w) to save the output to file:
a) text file …. the you can add this option: ‘-w <path of the file>
b) file for Wireshark analysis:
- you need add an option ‘-s 65535’ to get a full length of the every packet
- file needs to be written in binary format, you need use ‘.pcap’ file extension
… ofc for advanced user, there is an option to do it directly from the Wireshark.
3. you will get details about source - destination traffic dump of every packets in ASCI format, what can get your “friends” from a darknet side, when they will try catch you. Ofc, with this powerful attitude you can find hidden traffic from your network environment to internet. No need more explain for advanced tools like Wireshark. Prepare some heavy drink shots. It will open your eyes.
So it’s a time to hardening unencrypted DNS communication by DNSSEC.
I will prepare a guide for great solution based on dnscrypt-proxy, running on my all USG sites with Cloudflare’s DNS over HTTPS.
when you are sure about your NAS security, you can open next round - DNS security.
First really easy step for everyone is use:
ofc, use the extended test. It’s safe.DNS leak test
dnsleaktest.com
For an exact check of possible leaking of unencrypted DNS traffic you can use more low-level tool: tcpdump in your router.
1. you need find your WAN interface from the interfaces list:
Bash:
ip l
Bash:
tcpdump -Dand the possible result is e.g: eth0 …. for my Unifi USG-Pro
2. then you need capture traffic on standard DNS port: 53
Bash:
tcpdump -i eth0 dst port 53 or src port 53 -n -x -X -vofc is better to use include the option (-w) to save the output to file:
a) text file …. the you can add this option: ‘-w <path of the file>
b) file for Wireshark analysis:
- you need add an option ‘-s 65535’ to get a full length of the every packet
- file needs to be written in binary format, you need use ‘.pcap’ file extension
… ofc for advanced user, there is an option to do it directly from the Wireshark.
3. you will get details about source - destination traffic dump of every packets in ASCI format, what can get your “friends” from a darknet side, when they will try catch you. Ofc, with this powerful attitude you can find hidden traffic from your network environment to internet. No need more explain for advanced tools like Wireshark. Prepare some heavy drink shots. It will open your eyes.
So it’s a time to hardening unencrypted DNS communication by DNSSEC.
I will prepare a guide for great solution based on dnscrypt-proxy, running on my all USG sites with Cloudflare’s DNS over HTTPS.
Gents,
last week I completed my deep dive data research based on data from Shodan.
I analyzed the data related to the country in which I live only. My previous consideration - that maybe only 20% of all Syno NASes exposed in this source are vulnerable, has been underestimated. There are more than 58% of them. Those things are a lot worse. Based on the data, it is easy to find a domain behind it. This is just a step towards analyzing whether it can be a random device or a series of devices used for IP addresses registered for a specific domain. I found almost 400 devices exposed from an academic environment.
Protect your data!
Btw. I sent my entire report to Synology to understand what the situation is like. Because 1.5 months have passed since the introductory information was sent to the Synology PSIR team, and no one from Synology has contacted me yet.
This is just a single screenshot from my analysis. What you will see is just the tip of the iceberg. I will not publish the rest for understandable reasons.
Notes:
- Syno model number is known just from UPnP exposed NASes (7% from total).
- DS or RS is applied only for the UPnP filter
- DSM/SRM version, some data doesn't contain this value, then "Blank" is exposed to the chart
- Most used Ports - no need more explanation. Maybe just for the 5353 as the third most exposed port, what is a fixed port for Bonjur in SRM/DSM and reused by AudioStation pckg.
- exposed vulnerable versions of Apache servers (well known from CVE sources).
PS: I contacted some of the companies from the research outcome directly. Silence.
How can we make the Internet healthier when this civilization fails in difficult situations?
last week I completed my deep dive data research based on data from Shodan.
I analyzed the data related to the country in which I live only. My previous consideration - that maybe only 20% of all Syno NASes exposed in this source are vulnerable, has been underestimated. There are more than 58% of them. Those things are a lot worse. Based on the data, it is easy to find a domain behind it. This is just a step towards analyzing whether it can be a random device or a series of devices used for IP addresses registered for a specific domain. I found almost 400 devices exposed from an academic environment.
Protect your data!
Btw. I sent my entire report to Synology to understand what the situation is like. Because 1.5 months have passed since the introductory information was sent to the Synology PSIR team, and no one from Synology has contacted me yet.
This is just a single screenshot from my analysis. What you will see is just the tip of the iceberg. I will not publish the rest for understandable reasons.
Notes:
- Syno model number is known just from UPnP exposed NASes (7% from total).
- DS or RS is applied only for the UPnP filter
- DSM/SRM version, some data doesn't contain this value, then "Blank" is exposed to the chart
- Most used Ports - no need more explanation. Maybe just for the 5353 as the third most exposed port, what is a fixed port for Bonjur in SRM/DSM and reused by AudioStation pckg.
- exposed vulnerable versions of Apache servers (well known from CVE sources).
PS: I contacted some of the companies from the research outcome directly. Silence.
How can we make the Internet healthier when this civilization fails in difficult situations?
What do you mean when you say vulnerable? Are these DS that you have managed to log into? Or is it just because you can see they have open port(s) (like any web-facing server would do) ? Surely this needs to be combined with an attack of some kind to see if they are actually vulnerable?
This is coming from someone who is obviously a lot less technically minded than you!!
First
I never tried to connect to a foreign system to test its security unless its owner asked me to. It is valid also for the devices mentioned in this thread.
Back to basics
Every IP address in the world is subject to scanning by various 3rdP services. ( @Telos - just unplug will cover your security).
Any port opened to the internet is a problem. Any.
Just because someone has port 443 opened only it doesn't mean he/she is on the safe side.
However, the problem is when someone has ten ports open and doesn't idea that they are opened. This is the core of the problem. Honestly, most Synology NASes users have no idea what is going on in that black box (some are also white) and how much of a problem it is = what is the reason for the 5353 'Bonjour' exposed to WAN(also called 'mDNS' ... what is similar to UPnP). When your mDNS service is exposed to the WAN, it would allow hackers to grab information about your environment (MAC addresses, services running on the device) that could be used to prepare an attack. To be sure you can check it by:
better from an external environment (not from LAN).
More is here:
Any system exposed to communication via the HTTP port is in principle vulnerable because it allows you to intercept traffic on this port. It has been seen on NASes with exposed ports 5000 (HTTP DSM default) or 80, 8080. The fact that someone has x-ports available means that they do not use a Reverse proxy. Reverse proxy alone is not a guarantee of security. But it helps increase infrastructure security. E.g. with strict HSTS enabled, certificate defined for services/port, ...
And the fun starts when you see ports like 22 (SSH) or 3389 (RDP). It is a call for big troubles.
This is just a part of the system/environment vulnerabilities explained.
Any information about the target's vulnerability is useful to dark-net entities.
Btw:
There is a big difference between packets on the firewall side dropped or rejected. For example, the problem with Firewall settings in DSM is that it only allows Accept or Drop for packets (weak IPTABLES implementation into DSM GUI due to the idea of a single GUI for all). No Reject there, which is useful for the LAN hardening in case of the problem discovering.
Therefore, it is essential to have more effective (complementary) protection based on an integrated Router/Firewall/IPS-IDS or a separate Firewall/IPS-IDS.
Even if you have IPS-IDS as part of your router, you are not 100% sure that everything will work properly.
Syno is using their own IPS engine (really??) in SRM, as I know they left Suricata Open IPS/IDS in 2019/2020.
I never tried to connect to a foreign system to test its security unless its owner asked me to. It is valid also for the devices mentioned in this thread.
Back to basics
Every IP address in the world is subject to scanning by various 3rdP services. ( @Telos - just unplug will cover your security).
Any port opened to the internet is a problem. Any.
Just because someone has port 443 opened only it doesn't mean he/she is on the safe side.
However, the problem is when someone has ten ports open and doesn't idea that they are opened. This is the core of the problem. Honestly, most Synology NASes users have no idea what is going on in that black box (some are also white) and how much of a problem it is = what is the reason for the 5353 'Bonjour' exposed to WAN(also called 'mDNS' ... what is similar to UPnP). When your mDNS service is exposed to the WAN, it would allow hackers to grab information about your environment (MAC addresses, services running on the device) that could be used to prepare an attack. To be sure you can check it by:
Bash:
nmap -Pn -sU -p5353 --script=dns-service-discovery <Your-public-IP>More is here:
Any system exposed to communication via the HTTP port is in principle vulnerable because it allows you to intercept traffic on this port. It has been seen on NASes with exposed ports 5000 (HTTP DSM default) or 80, 8080. The fact that someone has x-ports available means that they do not use a Reverse proxy. Reverse proxy alone is not a guarantee of security. But it helps increase infrastructure security. E.g. with strict HSTS enabled, certificate defined for services/port, ...
And the fun starts when you see ports like 22 (SSH) or 3389 (RDP). It is a call for big troubles.
This is just a part of the system/environment vulnerabilities explained.
Any information about the target's vulnerability is useful to dark-net entities.
Btw:
There is a big difference between packets on the firewall side dropped or rejected. For example, the problem with Firewall settings in DSM is that it only allows Accept or Drop for packets (weak IPTABLES implementation into DSM GUI due to the idea of a single GUI for all). No Reject there, which is useful for the LAN hardening in case of the problem discovering.
Therefore, it is essential to have more effective (complementary) protection based on an integrated Router/Firewall/IPS-IDS or a separate Firewall/IPS-IDS.
Even if you have IPS-IDS as part of your router, you are not 100% sure that everything will work properly.
Syno is using their own IPS engine (really??) in SRM, as I know they left Suricata Open IPS/IDS in 2019/2020.
when you need check basic quality of your domain security or when you aren’t sure, that your DNSSEC is working right, you can use this useful Cloudflare link:
where “yourdomain” is your registered domain, e.g. “facebook.com”
when your DNSSEC is working, then you will get:
where “yourdomain” is your registered domain, e.g. “facebook.com”
when your DNSSEC is working, then you will get:
for those who run Pihole and need to understand if their DNSSEC really works, here is an article that explains this very nicely:
Never fully understood the reasoning with shifting port numbers around. Scanning ports seems trivial for an attacker and the idea of a firewall is to keep things from getting in via these ports when they are uninvited.
Unless people are leaving ports wide-open and rely on the (brief) obfuscation?
️
Unless people are leaving ports wide-open and rely on the (brief) obfuscation?
️
Selectively scanning well-known ports and a lot of IPs will likely harvest a better crop of vulnerable devices. That's the reason to shift your services to less likely ports... if you are vulnerable then you will be more likely to be overlooked. But limiting exposed services to the minimum is a good idea.
Some services weren't designed to be exposed to malicious connections, so checking that they aren't accessible is useful.
Plus most home security features aren't as robust as enterprise grade. A firewall hasn't been the be-all-and-end-all for quite some time. Next-gen firewalls have been around for many years and they still need additions to built-in IDPS, such as WAF and [D]DOS, to protect internal servers. Then there are dynamically defining LAN based on zero-trust. All out of reach for the home market. So doing anything is better than nothing ... but yeah, HTTPS on TCP 443 is something you'll have to accept if you're trying to connect home from any office location that restricts employee access outbound.
Never fully understood the reasoning with shifting port numbers around. Scanning ports seems trivial for an attacker and the idea of a firewall is to keep things from getting in via these ports when they are uninvited.
Unless people are leaving ports wide-open and rely on the (brief) obfuscation?
based on Shodan db darknet forces don't need to create a brute force. They will use just open highways
ofc, shifting of the ports will not save mental health - when someone is able to open your gates
I never trust that my firewall is enough no matter what I do.
I make sure I have backups of my important files to avoid ransomware attacks, which are getting so common and hitting home users as well as commercial sites. I also run regular malware scans (Malwarebytes) and have Windows ransomware protection (FWIW) turned on for my laptops. I rarely connect to any public Wi-Fi (can't actually remember the last time I did), and if I do I always use my VPN (WireGuard). I even use it at my Mom's house, just in case. I use my phone hotspot for connecting my laptop if I need to do that.
Others can give you better advice than I on firming up your firewall. But the best advice I ever got was "Back up your shi_t, or you WILL cry later." Either due to equipment failure or to virus/bot/ransomware attack.
I make sure I have backups of my important files to avoid ransomware attacks, which are getting so common and hitting home users as well as commercial sites. I also run regular malware scans (Malwarebytes) and have Windows ransomware protection (FWIW) turned on for my laptops. I rarely connect to any public Wi-Fi (can't actually remember the last time I did), and if I do I always use my VPN (WireGuard). I even use it at my Mom's house, just in case. I use my phone hotspot for connecting my laptop if I need to do that.
Others can give you better advice than I on firming up your firewall. But the best advice I ever got was "Back up your shi_t, or you WILL cry later." Either due to equipment failure or to virus/bot/ransomware attack.
This is out of your FW:
- when you use Cloudflare with DNSSEC to them ….simple it is a secure authentication protocol between the DNS and your site
it prevents DNS spoofing, MiTM,
Used, satisfied.
- with dnscrypt e.g. over the Cloudflare DNS you can hide/encrypt comm between DNS client and resolver
it prevents an eavesdropping for attackers or ISP
Used, satisfied. Running directly in my USG Pro4.
Proxied by Cloudflare, then my fixed IPs aren’t flying everywhere
- when you use Cloudflare with DNSSEC to them ….simple it is a secure authentication protocol between the DNS and your site
it prevents DNS spoofing, MiTM,
Used, satisfied.
- with dnscrypt e.g. over the Cloudflare DNS you can hide/encrypt comm between DNS client and resolver
it prevents an eavesdropping for attackers or ISP
Used, satisfied. Running directly in my USG Pro4.
Proxied by Cloudflare, then my fixed IPs aren’t flying everywhere
there isn’t relation between compromised public hotspot + your device safety, when you are running VPN.
It can protect VPN communication, but rest of the communication isn’t in the safe boundaries. Just strict security policies list defined in your device (include firewall) can provide more safety.
Last edited:
Of course there is no way to be completely safe using public Wi-Fi, which is why I don't use it and as I said cannot remember the last time I used it. However, if you must use public Wi-Fi, using a personal VPN while on it is better than not as at least your data is encrypted and IP hidden. Still vulnerabilities will exisit (e.g., MitM, etc.). 
Prompted by this thread I had my SOHO network looked at by a fresh set of eyes. Very rough and sanitised version of the observations below - specific to me but no doubt others will be similar.
The Good:
The Bad:
I think I understood nearly all of it, at least when it was being explained. The formal document is much more wordy!
I have some screenshots of the open source web tools used for the 'gross error' checks, if anyone is interested. Not sure of their value.
[edit] I should add that I did enable DNSSEC just before this, with this thread being the final prompt to sort it out.
️
The Good:
Code:
- Capable IPv4/IPv6 firewall with ‘reasonable’ settings and a well-understood and managed configuration
- No basic form of UPnP used - service deleted in toto
- WAN via PPPoE tunnel with hardline direct to backhaul / ISP router
- ISP selected for privacy / security
- ISP provides IP ‘machine name’ linked to them alone
- All ports in 'stealth' mode
- No DNS leaks
- Good L2 / L3 management
- Capable and fully mapped wifi system, robust settings, guest and IoT VLAN segregation
- Monitored full-home SDN, reserved IPs by MAC, very limited use of DHCP IPs
- Very limited exposure to IoT systems and all using HomeKit and/or Thread
- Only using Apple TVs for streaming services
- Only 2 x 24/7 servers - macOS and Synology
- Main Synology NAS only exposed to external access (eg DDNS) when specifically required for a task
- Secondary servers are LAN only and only powered during specific tasks (eg weekly backups)
- Only use macOS, iOS and Linux to avoid issues provided by the Windows and ‘droid attack surfaces
- Internal DNS, DNS cache / forwarder with DNSSEC to 2 external ‘trusted’ providers
- Internal Stratum 1 NTP server, available to LAN clients, secondary NTP server and via DHCP Option 42
- No use of ‘services’ that deliberately bypass security settings (eg Google Chrome, some cloud services, Microsoft etc)
- Full use of Apple tracking prevention
- Own domain points at US provider only, rather than my own static IP
- Small and trusted UK company used for web and email hosting, using my own domain
- Firmware and software up-to-date with managed upgrades
- Accurate database of all networked equipment and relevant security policies
- All obsolete or depreciated protocols disabled
- No use of Facebook, WhatsApp, whatever, where the commodity traded is the user
- Password management system
- Digital hygiene on personal informationThe Bad:
Code:
- Modem maintained ‘blind’ by a 3rd party (Openreach) (but mitigated somewhat by PPPoE tunnel)
- WAN provided over G.fast that went into limited support faster than it was rolled-out and finally halted
- Router has UPnP2 enabled (albeit monitored and configured in Secure Mode only)
- Using own static IP for day to day use
- No Secure SNI (??)
- Single Windows server (rarely powered-up and cleansed of all bloat & telemetry) but Windows is a security issue in its own right
- No full DNS encryption (either DoT or the horrid DoH)
- No use of Synology NAS’s internal firewall
- One device that bypasses some internal security (SkyHD box) but constrained to an untrusted VLAN
- One device that seems to be becoming less trustworthy (2019 LG OLED), needing further constraint
- One device (client) with RJ45 capability connected via wifi instead (hey, that’s just 1 single client!)
- Plex server available for remote access 24/7 via somewhat randomised UPnP2 secured ports
- WoL enabled on servers that are typically switched-off 24/7
- No ACLs or locks enabled on switchports (does anyone do that?)
- No full disk encryption on NASes (Synology…)
- Servers without dedicated management interfaces (Synology…)
- Have a daughterI think I understood nearly all of it, at least when it was being explained. The formal document is much more wordy!
I have some screenshots of the open source web tools used for the 'gross error' checks, if anyone is interested. Not sure of their value.
[edit] I should add that I did enable DNSSEC just before this, with this thread being the final prompt to sort it out.
️How did you find the person who did the review for you? Small business or independent? I've thought about doing this myself, but one of those "things I should do" that I haven't gotten around to yet.
The report didn't mention, but I assume your TVs are on your IoT VLAN (that's how I set things up in my house) so that they are separated from your personal devices (NAS, phones, laptops, etc.).
I am also not using encryption on my NAS devices. Another "I probably should do that" that I haven't.
The report didn't mention, but I assume your TVs are on your IoT VLAN (that's how I set things up in my house) so that they are separated from your personal devices (NAS, phones, laptops, etc.).
I am also not using encryption on my NAS devices. Another "I probably should do that" that I haven't.
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
Try adding them one-at-a-time, saving, logging out, restarting* your computer, then logging back in until...
I receive the reports monthly, just actually got them on 2/1 and verified for some reason this is still...
It took a while to get iOS Syno Drive Client to reset and ask for my 2FA to log back in. It was set up...
Understood, thanks for clarifying.
My auto-block was always set to block after multiple attempts. Since this login stuff was happening once...
- Question
Synology answered my ticket, will be fixed in DSM 7.2.1.
Welcome to SynoForum.com!
SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.
Registration is free, easy and fast!
Trending threads
-
-
-
-
NAS Compares Synology NAS Complete Multimedia Setup Tutorial (2024 SETUP GUIDE #4)- Started by NAS Compares
- Replies: 0
-
-
NAS Compares Synology DS224+ vs DS723+ NAS – Which 2-Bay is Best?
- Started by NAS Compares
- Replies: 0