Thumbnails generation on the Synology NAS can be a useless waste of resources, making your CPU run at 100% for hours or days. This behavior takes place whenever you upload any images without using the proper software released by Synology (i.e. Photo Station Uploader), for example when you upload your holiday pictures through SMB straight onto the Synology shared folder.
Please note that thumbnails are generated even though the Synology Photo Station software is disabled.

In order to avoid this behaviour, you should disable the service responsible for the thumbnails creation, that is /usr/syno/etc/rc.d/S77synomkthumbd.sh.

You can stop it: /usr/syno/etc/rc.d/S77synomkthumbd.sh stop but unless you want it up and running again after any reboot, you can disable it from executing:chmod -x /usr/syno/etc/rc.d/S77synomkthumbd.sh

Please note that there are many others services running, most of which can be useless to you. Some of them are listed below.

During vulnerability assessment activities I frequently run across the advisory that suggests to disable the RC4 cipher suites on the web server of the day. The reasons behind this are explained here: link.

On windows system, I came across to that vulnerability applied to the Remote Desktop service. I also read about some people having troubles trying to disable those ciphers, meaning the remediations they used didn’t really work. I personally followed this security advisory and it solved the problem.So basically I just added the following registry key:

In my previous posts, I described how to backup the Synology NAS to an ubuntu-based rsync server. I found out that rsync server doesn’t automatically set a log rotation when installed, thus my logs went quite large.
Here is how you can manage the problem.
Create the file /etc/logrotate.d/rsynclog as follows:/var/log/rsync.log {
rotate 5
mail yourmail@domain.com
size=5+
copytruncate
compress
missingok
notifempty
}

When your logs get 5MB they will be compressed and rotated for a maximum of 5 times. Some notification will be sent to your email.

For a complete list of commands of the logrotation google welcomes you.

In my previous article I described how to exploit a covert channel such as dns tunneling using iodine in conjunction with a dns server we are controlling.

Here I describe how to set up a dns tunnel without the need of a controlled dns server of our own.
That is, dns tunneling is made directly through iodine client and iodined server: this is a technically easier scenario to exploit compared with the one in the previous article.

Let’s assume we are phisically connected to a target network. In order to exploit a dns tunneling we have to verify that we can run dns queries to an arbitrary dns server, that is a dns server not included in the default network configurations of the target network (e.g open dns server, 208.67.222.222).

We use nslookup to verify this. Just set up >server 208.67.222.222 and run a query. If the query is successful, than we could exploit a dns tunnel.

What we need is a server with public IP (e.g 11.11.11.11) that we can reach. On that server, install iodine server (i.e iodined), than run:

iodined -fP mypassword 10.100.100.1 myexample.com

than enable port forwading on the kernel:

echo 1 > /proc/sys/net/ipv4/ip_forward

and enable iptables rules:

iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -o eth0 -j MASQUERADE

Now you should turn your server into a SOCK proxy server. You can do it by typing: