Tag Archives: Networking

Home / Networking
4 Posts

In August 2014 all Synology DiskStations where under attack of ransom ware: SynoLocker. It encrypts the files, disabled some services and showed a message that states your files are encrypted. The only way to get the files back is to pay the ransom of 0.6 Bitcoin to receive the decryption keys. (If you are lucky…) SynoLocker is well designed by professional criminals. If you are infected there is no way around the encryption besides paying and hope for the best. At the moment this post is written, it turns out that only DiskStations that are not patched accurately are vulnerable to SynoLocker. It uses a vulnerability that has been fixed by Synology in December 2013.

SynoLocker created huge fuzz worldwide. Luckily I wasn’t affected by SynoLocker, but it triggered me to look critical to the security measures I took and what I could do more to raise the security of my DiskStation. This post is the result of the steps to take besides those I already took to be able to use the DSM desktop from the internet in a previous post. I’ll mention some of those here again. If you want to implement those specific measures, you’ll have to peek in the post Securing the DSM desktop when accessed from the internet. Oh, for those who think they are secure because they don’t own a Synology the following is recommended to read: Network Attached Shell: N.A.S.ty Systems that Store Network Accessible Shells

First (after the disclaimer) there will be an explanation from the components that are involved and what they (can) do to raise the security of your local network. At the end there will be a description of several options to raise your level of protection. This post isn’t a recipe that tells you step by step what to do and where. It’s meant as an eye-opener and points you in directions to find your own solutions. Synology has an active and competent community in different languages. It’s a good plan to start there when you have a specific question. Keep in mind that the communities are not owned by Synology. (Except the English one.) They are crowded by other Synology enthusiasts who are NOT employed by Synology.

Disclaimer

When a NAS comes into the house, it adds a whole lot of new services to the local network. Most of the time a NAS also will be attached to the router as just another local network device. The other devices on the local network can communicate freely with the NAS and everything seems to be fine. The complexity begins when services from the NAS also have to be available from the internet. The appropriate port(s) will be opened and passed through to the NAS. And that is just that where vulnerability starts.

There are a lot better solutions thinkable to minimize the risks of being attacked from the internet, but they also require more sophisticated equipment and come in most cases with the need of having the knowledge of an IT professional. When a generic modem/router was enough for companies to protect themselves from intrusions from the internet, they wouldn’t invest huge amounts of money as they do now to protect themselves. And even then they haven’t guarantees they are absolute save. They just took a calculated risk. Bear in mind that absolute secure does NOT exist. All the measures you take are based on the risks you are willing to take and what is the price you are willing to pay.

When you are about to open a service to the internet, it is accessible to everybody. Ask yourself how many risks you are willing to take  losing your (sensitive) files or abusing your NAS and what measures are you willing (can/afford) to implement to avoid that. There is always someone looking for opportunities to abuse your service or stealing your data. Keep this in mind when you are exposing your sources to the public internet. In the last part of this post there will be some suggestions that require more equipment or external services, but helps dramatically reducing risks. The main part of this post is to help increasing security on common home configuration as shown in the picture above.

The amount of text of this post does not imply that everything about the subject hardening and being prepared or disasters is completely covered. The intention is to make you think what you can do to increase your security and give you some directions to look into and hopefully some hints you’ve never thought of. If you have anything to add, feel free to let me know.

No liability is taken for your actions that compromise your data or security. All the mentioned items are intended to give you suggestions to increase security in a simple home network just to make it less insecure. If your data is really precious to you and you don’t have the knowledge to implement complex security measures, you should consult an IT-professional or refrain from opening services from your local network to the internet. All the actions you take as an immediate cause of this post are at your own risk!

Threats

Your data is permanent in danger. You should be aware of that. One threat is more likely to happen than others, but even unlikely threats do happen. There is no way to eliminate all risks, so you have to be prepared when a certain threat occurs.

As soon as you make your DiskStation accessible from the internet, you are vulnerable to all sorts of threats. The internet is a blessing when it comes to making things possible. However making things possible can also being used to abuse or threatening these possibilities. Internet is made possible by using specific software on computers that uses a network to communicate. The network is made possible by using hardware components like routers and switches. These components are also computers with software (firmware) with a specific task; traffic regulation of the network traffic.

Passwords are meant to identify users and assign certain resources to them. However to access the ‘entry point’ of a resource the ‘entry point’ has to be accessible for everybody if you don’t know where your user is when he accesses your resource. When an unauthorized user finds this ‘entry point’ he is urged to enter his username and password to authorize. When the user is not a legitimate user but just a fortune seeker, he can try entering usernames and passwords randomly. You aren’t able to avoid that, but you can implement mechanisms to harden this.

Software flaws

In a perfect world all software is error less. But we aren’t living in a perfect world, so software has errors. It does not matter if the errors are known or unknown. An unknown error will become sooner or later a known error, because the software reaches a condition that triggers this error. What happens next depends on how the software is designed. In many cases errors will be caught and handled by the software. This occurs when the error is more or less expected by the programmer of the software. Unexpected errors aren’t handled and the outcome of what happens next when software runs in these kinds of errors is uncertain. Sometimes it leaves the computer in a state that can compromise the integrity of the whole computer.

There are people who try to find these kinds of errors to let the software crash and gain control over the computer. What happens next depends on the attacker. Sometimes it is being used to attack other computers without your knowledge, sometimes it kidnaps your files and forces you to pay a fee to get your own files back.

This all happens because there is an error in some part of software. Software is still created by people and people make mistakes. You have to deal with the fact that there is no software without errors. No matter if it is your word processor, operating system of your computer, your web server software or the software in your Modem/Router. When you made your computer accessible from the internet it gets even worse. There is somewhere out here looking for your service trying to find the error he needs to attack your service too. The internet is a hostile environment.

Scary, Huh? In the case of software you have to depend on others to release a bug fixed version of the software. The only thing you can do is update your software that is being used to facilitate your internet presence. Fortunately, often there is a bug fixed version available shortly after a bug has been discovered. If you think you are safe because you implemented a complex password policy, you are terribly wrong. Software flaws often bypass the password mechanism. So, don’t rely on that. Complex passwords are used to protect against other threats.

There is only one thing you can do, just to reduce the risk of being attacked: Update your software as soon as an update is available. This is one of the lessons learned from the previous mentioned SynoLocker attack which abuses a software error that has been fixed by Synology eight months before this thread occurs. Eight months is a very long time. You should have to update immediately. You may want to investigate the impact of the update or wait a couple of days to see what issues other users ran into when they applied the new update. However you shouldn’t wait too long. Accordingly to the experiences of other users you may want to apply an update in a couple of days. Certainly not months!

If you still haven’t updated your software in this time span, you only can blame yourself when this happens to you. Even if there will be no more updates for your software, you have to blame yourself. You simply shouldn’t use the component anymore for being accessed by anyone. You should get yourself a device that can be updated. The old device only can be used internally for testing purposes. Due to the age you shouldn’t even use it for production environments. (Not even your car last forever. One day it’s too expensive to maintain it any longer or you are willing to pay for the extended lifetime for the car with expensive workshop bills.)

Keep in mind that all devices that realizes your internet connectivity rely on software. So, don’t forget to update regularly the software from the modems, routers, and switches too. Not only the software on your DiskStation and other computers.

Another software threat can be the use of software that came from less reliable sources. You can use all kinds of packages that add functionality to your DiskStation. However the quality of these applications may vary. The programmer may not have tested it extensively as he should be. This increases the risk of software flaws and even malware. It is likely software that came from a company that can held reliable for damages, is better tested than the software from an obscure source. This does not guarantee that this software is working flawlessly, but it’s probably better maintained and will be updated as soon as a fix is available for a certain flaw. On the other hand, there are magnificent sources to add functionality to your DiskStation that are reliable too from dedicated programmers. If you want to add software, be sure you tested it before installing it on your DiskStation. (I.e. installing a virtual DiskStation in VirtualBox if you don’t have a spare DiskStation.)

Another way to add software is ‘Bootstrapping’. This allows you to add software to your DiskStation without the need of a special created package. With bootstrapping you have more or less the same risks as installing software from a third party source. You can jeopardize the stability of your DiskStation. Due to software errors, the DiskStation may not be able to come up after a reboot because there are errors in start-up scripts of an application. If you want to add extra software to your DiskStation, try to find more information about it in forums or elsewhere on the internet. Test it and make sure you update the software regularly as you should do with your other software.

Passwords and accounts

Using passwords is the most common method to grant access to a computer system. It is therefore one of the most attacked mechanisms. Most of the time it’s not the password itself that creates a problem, but the user who has to use it. As an administrator you can force a certain complexity, but the downside is that the user has to remember it. There is something that speaks for the user: he has to remember a zillion passwords of all kinds of services. He can’t remember them all anymore and when the password becomes too complex, the user will write it down. You have to find a balance between complexity and usability for your users. You also have to make sure the user has access to resources he really needs and nothing more. You also might want to consider two-factor authentication. Fortunately your DiskStation is ready to start using this. Unfortunately the user has to activate this and cannot be forced yet.

For an administrator account you have to use two-factor authentication and real complex passwords. There is another issue with the default admin account on your DiskStation: You can’t change the username. For attackers it’s easier to attack your DiskStation. They haven’t had to guess the account name, because the default is known to the public: Admin. The best thing you can do is to create a new administrative account with two-factor authentication and a complex password to use this account for administrative task only on your DiskStation. The default ‘Admin’ account must be disabled. Before that, give the default ‘Admin’-account a real complex password too. Print this on a piece of paper and store this somewhere (offsite) safely. You can still use the ‘root’ account that has the same password as the default ‘Admin’ account. The newly created admin account does not have root privileges as the default Admin account has on file system level.

There is another account that may seem to be interesting to enable, but shouldn’t be enabled: the ‘Guest’ account. You always want to know who is on your system and ‘guest’ is not one of them. This account has some access rights to your DiskStations file system. If you want your users having access to the file system, assign them an own account.

You might have to discipline yourself using your DiskStation. Many people use like a regular user their DiskStation with an administrative account. This can be a huge risk for your data. It is convenient to have an account that can be used for all tasks. This comes with a price: you can accidentally delete files and folders on locations you wouldn’t like to do that. (I.e. ruin your WordPress or whatever else CMS you use.)

Another risk is that every time you use this account you have to enter your credentials. Even in locations you strongly advised not to do so. Public places like airports, hotels and restaurants must be considered as insecure, because of the risk of being eavesdropped while you log on to your DiskStation. Using your administrative account may be catastrophic. You even have to think twice if you are willing to use your regular user account here. By disciplining yourself using a user account when using the DiskStation and an administrative account when you administer it, you increase your security of your data.

Passwords are interesting to attackers. Once they found a log-on page, they can try with dictionary lists or brute force to find a valid password. A DSM desktop is easy to find. It might be yours. Just Google inurl:/webman/index.cgi and see for your self what happens. There is nothing you can do if you are opening services to the internet that requires a username and password. Any other service log on page can be found like demonstrated above. You can’t hide yourself not even if you use a nonstandard port for a service.

Make sure you limit the amount of tries a user authenticates. Your DiskStation contains an Auto block mechanism for Synology services. Use this to lockout any user that has to try more than x times in a time span of y. The Amount of tries and the time span depends on your needs. Three times within 1440 minutes is very strict, but also very protective and useful when you are the only user. This lockout fortune seeker very quick and the majority of attacks are done by fortune seekers.

Authentication is a process that relies on the quality of the software. When the software contains flaws regarding authentication, an attacker doesn’t need a password to be able to hack himself into your system. The biggest error you can make is to use complex passwords and think you are secured. This is not true. A password doesn’t protect you against software flaws.

Hardware failures

After some time your hardware may start to malfunction. Especially disks are vulnerable to failures after a while. Depending on the device you may have already taken precautions for this. However what if you have only one disk for redundancy and two disks will fail shortly after each other? Redundancy does not replace the need of backing up your data. No matter how expensive your NAS is. You should realize that someday even your DiskStation may fail.

Physical threats

Threats that often are forgotten are threats to your data when something physical happen to your DiskStation. What happens when a burglar visits your place and steals your DiskStation? And what if they also took the attached USB disk you installed for backup purposes? Or what is remaining of your data when your apartment burns down? As stated before, you can’t avoid these risks but you can be prepared.

You probably will get the hardware replaced from the insurance company, but your data is priceless and unique. No insurance company can replace that for you. Both cases have a similarity: your data is missing. To be prepared for that you have to develop a backup strategy that includes offsite backups. You can consider storing your data at a friend’s NAS remotely. Depending on the friendship, this can be a good start. However consider what happens with your data when suddenly your friend isn’t your friend any longer. (Don’t think these things don’t happen. They do!) You might want to consider a cloud solution.

In case of a burglary, you might take another precaution. You have to make sure that the data is inaccessible to an unauthorized person who has physical access to your DiskStation. For this threat you can use encryption on a shared folder. Don’t forget to encrypt the backup disk too and store your secret keys on a really safe place. (Not on your DiskStation, that is like putting the key of your vault in your vault.) It’s a good idea to print the encryption key on a piece of paper and store it somewhere (offsite) safe. Encryption of shares is available in your DiskStation.

Components

When you are using a DiskStation, many of the required components to protect it, are already available. You only have to activate and configure them. To understand what components are involved and what role the components have, will be explained shortly hereafter.

Without the firewall, you’ll see a typically home user’s network with a NAS. Most of the time people have multiple devices in their home network. Computers, laptops, tablets and smartphones are connected to the modem/router directly. Some are connected wired and some wireless. The Modem/Router handles the local network traffic and keeps unsolicited network traffic outside the local network and all devices are protected against unsolicited traffic that comes from the internet.

Home

Modem/Router

A Modem/Router is most of the time delivered to you by your Internet Service Provider. This device resides on the edge of your local network and the internet. Nowadays these devices fulfill a lot of functions. It provides the connectivity with the internet, it keeps unsolicited traffic from the internet from your local network, it is your Wi-Fi access point for your wireless devices, it enables communication between your devices in your local network, it gives each device in your network an unique address to be able to communicate and it is the yellow pages for your network to find services your devices are asking for. (Among other things.)

When a device on your local network is using a service from the internet, your router will replace the private return address of the traffic with your current public address. (And keeps track of it when the reply traffic comes in.) This process is called Network Address Translation or NAT. The addresses used on your local network aren’t suitable to communicate directly on the internet. (This is by design. With this mechanism, you can use the same address ranges as your neighbor. It is not possible to have the same address being used by multiple devices at the same time in one network.) You also have to deal with NAT when you are going to expose services from your NAS with only a private address.

A port represents a service. Many ports are standardized (80, 443, etc.), many other ports aren’t. For each service you want to publish, you have to find out its port(s). Some services use just one port some use multiple ports. You have to open all the ports for the services to function.  Besides that, there are also settings to be made related to a service (port) that tells something of the type of traffic that can be expected. The most common two are TCP and UDP.

As soon as you open a port on the internet to access services from your local network, your Modem/Router will block all incoming unsolicited traffic except the traffic on the port(s) you just opened. Once the specific traffic is arrived in your Modem/Router it needs to know witch device the traffic should be routed to and what port(s) on the device it should use. The device handles the traffic and replies trough the Modem/Router to the client somewhere on the internet. (When the public available service on your NAS has a flaw and is vulnerable to abuse, it can be used to compromise your NAS directly from the internet. A good password will not protect you against these types of attacks. Just updates.)

It is possible to change the port number during the NAT process in your router. When a request arrives at your Modem/Router on port x the Modem/Router can change that to port y to the internal device. This is called port translation and often is incorporated in NAT. It’s referred to as Network Address and Port Translation; NAPT for short. Many standardized ports will have to pass 1:1 through your router. It makes no sense to translate the standard port (80) to access a web browser. A user has to enter the port number explicitly in the address bar and needs to know the port number. And there is no reason to change the port for the internal users. Changing this kind of known ports makes the service useless, because users will go elsewhere. Therefore most of the time these ports are passed through the router to the internal device to handle the request. The possibility that the web server software has a flaw that can be abused is a calculated risk that is hardly to avoid. The only alternative is NOT opening the port from the internet.

Ports that are not official standardized, necessary and being used by a selected group of users are candidates to translate during the NAPT process. Another purpose can be putting services behind ports that are allowed from another local network, but normally using a port that is not allowed from the same network. (You shouldn’t but you can…) It is perfectly possible to host a standard service on a nonstandard port. You just have to add the port number to the address. This mechanism also can be used to use different ports for standard known Synology ports.

When you change a different port than default set by Synology, you can mask the service a little when you give this a higher (unused) port number (<65535). The higher the better. This won’t protect against anything. When someone scans all your ports he will find this port. The next step is to find out the service behind the port and start trying to attack the service. There is a reason you still should do this when you can: scanning all your 65k ports takes a whole lot of time. Most of the time an attacker will not spend that amount of time to all its potential targets. It is more likely the attacker will ‘drive by’ and tests the default port for a specific service set by the manufacturer for the service and goes on when nothing is found. It won’t protect you against an attack where you are a specific target (or where the attacker found the specific port number elsewhere), but it helps a lot against the most attacks from fortune seekers.

A potential port to translate on your Synology is port 5001. This port is used to access the Synology console with a web browser on a secure http (https) connection. If you want, for whatever reason, to be able to access this from the internet, you should choose a high port number to access from the internet. (i.e. 54931). NAPT can translate this to 5001 on the inside and passes it through to your DiskStation. With this construction you don’t have to modify anything on your DiskStations configuration. On your local network you have to access the DiskStation on port 5001.

Security is all about combining measures to make sure the combination will give you a higher level of protection. In the specific case of opening a port to access the Synology Desktop, you have to take additional precautions to make this more save. See for the details another post about this specific subject here.

There is one thing your Modem/Router probably can’t do: Allowing or blocking traffic that comes from certain addresses. This can be helpful to narrow the access to opened ports based on the source form the traffic. (Reducing risks.) It would be nice if you have a mechanism that allows you to set access rules for specific source addresses you entered explicitly. All other traffic will be declined. This job can be done by a firewall.

Firewall

A firewall will test the traffic before it reaches the requested service. There are not much home users that are using a firewall. (NAPT is not a firewall.) Most of the time they trust on the capabilities of their Modem/Router. This is sufficient as long as there are no ports opened from the internet to the inside local network. Your Synology is provided with a firewall you can use to help to narrow the allowance of the traffics origin. It’s not optimal but can contribute to raise your level of protection. (Using a protection mechanism on the same machine as it protects, can become useless as soon as the machine becomes compromised.) However, if you aren’t compromised yet and haven’t other options available to install a separated firewall, you can use the one on your DiskStation.

Using geographical restrictions can make you a whole lot safer. If you opened a port for your own purposes only and you live in the southern of Germany, then it is likely that most of the time you’ll stay in Germany. It is very unlikely that you need access to that port from Nigeria, China, Russia, Ukraine, United States of America, Norway, Sweden or whatever other country you can think of. It is a good idea to limit the access to this specific port to Germany. (You might want to consider Austria and Switzerland, because you stay there frequently.) Just doing this lowers the risks dramatically. (You can still be attacked from the countries you allowed. It is even possible that an attacker from a not allowed country can attack you through a proxy in one of the by you selected countries. But this takes extra efforts of the attacker and there is much easier pray for them.)  Ports to accommodate CloudStation or the DSM desktop are good candidates to limit by geographical location. The firewall in your DiskStation (DSM version 5.0-4482 or higher) allows you to make firewall rules based on geographical location.

Adding a firewall to your DiskStation makes managing your local network and the port forwarding on your Modem/Router a bit more complicated. Even if the topology is as simple as shown in the picture above, at the beginning of this paragraph. However it’s is worth the effort. After all it’s all about your precious data. Most of the time it’s the troubleshooting part that causes headaches. You have two places to take care of the right settings before a port forwarding will work: the Modem/Router and the firewall.

A firewall is basically a set of rules that will be applied, starting at the top of the rules list. When the firewall finds a rule that applies, it’ll execute the rule and exits the process of applying rules. It does not matter if the rule states that the traffic should be allowed or denied. A matching rule stops the process of rules testing an executes the rule. Keep this in mind when you create your own rules.

WARNING: Before you start designing your own rules there is a warning: Setting the wrong sequence in rules with the wrong settings may lock you out of your DiskStation. It is inaccessible and may require a reset of your DiskStation. Synology tests during the saving of the rules set if you are about to lock yourself out, but it’s nasty when you find out the hard way that this didn’t work well for you.

Take precautions before you start editing firewall rules. If you have a DiskStation with multiple NIC’s then you get the IP-address of one of the other NIC’s where you aren’t applying the firewall to. Make sure it is a static IP-address and write it down. (You can give your computer another static IP-address in the same range to let you access your DiskStation again if you are locked out.) If you have only one NIC, then you’ll have to make sure that the first rule you create is a rule that allows your local network to communicate on all ports with all protocols.

In the picture below, you’ll see an example of a set if firewall rules. Each line will be explained individually.

Firewall

Before starting creating rules there are two settings you have to look into before you start. First, make sure you apply the rules to the correct NIC. In the picture above it’s the upper red arrow that points to a roll-down menu to select a NIC. In this case: LAN 1. The other setting is pointed out with the lower red arrow: If no rules matched (Item 10). This sets the action what to do if no rule matches. By default it is set to Allow access. Leaving this setting so makes no sense. You may have a long list of rules with Deny-actions and still aren’t sure if you comply with all the situations you want to block. It’s smarter to set this to Deny Access if no rule matches and set the allowance explicitly. If a rule that should be set is forgotten, access is simply denied and does not harm your security. Don’t click the save button yet. You might lock yourself out, because you haven’t defined any rules and the setting for no matching rules is set to Deny access. At least you have to set a rule that allows all traffic from your local network. (Item 2).

In the picture above, about the firewall rules, all rules are numbered. All ports are shown by their explicit number. It is possible to select an application during the creation of the rule to let the wizard select the accordingly ports. The drawback of this is that you can’t see in the list what port numbers are selected and often there might be more ports opened than really is necessary. By setting the port with its number, it’s much clearer what you have set. The rules will be explained by their number below:

  1. I run a DHCP server on my DiskStation. (My Modem/Routers DHCP doesn’t support the use of PXE on my network. My DiskStation does.) Because of the fact that a workstation initially has no IP address witch it should obtain from the DHCP server, traffic to just do that should be allowed. So any Source IP should be allowed to communicate with the UDP ports 67 and 68.
  2. This is the rule that should be in top of your rules list of your firewall. This rule defines that all protocols on all ports with a Source IP coming from your local network is allowed to communicate with your DiskStation. Setting this rule on top of your list basically makes that anything that comes from your local network isn’t obstructed by the firewall. (While this is a match, the processing of the rules is exited and no other rules will be applied. That is the reason why it should be in top of your rules list. You may swap #1 and #2, if you want to.) You can define a single IP address, a subnet or an address range as Source IP. It’s likely you will choose a subnet or an address range here. In the example above is a subnet used: 192.168.10.0/255.255.255.0. A subnet IP address always ends with a 0 and must have a subnet. All the devices in that subnet are allowed. Defining an address range is a little easier. Just enter the lowest and highest IP address you want to allow access for: 192.168.10.1 – 192.168.10.254. Make sure you include the IP address of your Modem/Router. At this point you may click the save button. You are always able to reach your DiskStation from any device in your local network on any port.
  3. The rule defined here is one that has to allow access to your web server on your DiskStation when you are using the default ports (80, 443. Both TCP). You can’t know where from the world you will be accessed by users to see your website hosted on your DiskStation. If you want your website open for everybody, than you have to allow access from any Source IP. Your web server can be attacked when there are vulnerabilities in it. There is nothing you can do against that. (To minimize the potential damage it is wise to run the web server with credentials that are as limited as possible. This is the reason why Synology recently changed this from the ‘root’ user to a new user called ‘http’.) You can see an extra port defined: 8484. You can transport http traffic over nonstandard ports and because it is listed with the standard ports, it is clearer that this port is related to any web server related services. You can create a new rule to achieve the same thing. It’s just easier to recognize it for the administrator.
  4. This port is a mail server port. As mentioned in #3 for a web server, a mail server is also being accessed from all over the world if you run your own domain. You can’t know who wants to send you or one of your users an e-mail. But it has to be delivered at port 25 on your mail server. So you have to allow any Source IP if your run your own mail server. If you use batched SMTP and use your ISP’s mail relay, you can limit the Source IP to those of your ISP’s mail servers.
  5. TCP Port 6690 is being used by Synology’s CloudStation. In this example it’s worldwide accessible. Depending on your (or your users) need you might want to limit access to certain geographical locations.
  6. The UDP ports defined here are assigned to a VPN protocol named L2TP. (For other VPN protocols, you have to define other ports.) It is also worldwide accessible. This might become your ‘backdoor’ if you want to use services that are geographically or otherwise restricted and you are out of the bounds of those restrictions. Through a VPN connection you still be able to gain access to those sources. (See also the VPN paragraph below.)
  7. This port is the Synology Default for the https connection to the DSM desktop. It is arbitrary if you want to make this accessible directly on the internet. It might be a surface to attacks, but so are other opened ports. The idea that this is the ‘desktop’ to administer your DiskStation can make you nervous. However for a regular user it can be a desktop to consume functionality allowed for the user to use, like VideoStation, AudioStation and FileSation. Due to the drag and drop capabilities in the browser of DSM it also can be used to transport data form a local machine to the DiskStation over https without the need of a FTP-Server. It is up to you how many risks you may want to take. You still can use this remotely when you connect with a VPN if you decide not to open the port to the DSM desktop. In this example it is only accessible from any IP-address in The Netherlands.
  8. This is an example of the usage of a port from that is being used by a SVN service (source code version control). This port is restricted to three geographical locations: Germany, Austria and The Netherlands. You can do this in cases you are working with multiple people on a project where the people are located in different countries or travel a lot to those countries.
  9. These are the default ports for FTP. In this case it is restricted to access just from within The Netherlands.
  10. This is the rule that defines the default behavior if none of the rules matches. In this case: Access denied.

Where the Modem/Router meets the firewall

All the ports used in the example above are the ports that services have by default. However if you combine the firewall with the Modem/Router, it is possible that you use other ports for certain services on the internet side of your Modem/Router. NAPT takes care of the port translation and makes it possible to keep the default ports internally. This makes that the firewall has to act after the Modem/Router has translated the ports and must deal with the ports assigned internally. Three example cases to clarify:

  1. A user wants to visit your website witch is hosted on your DiskStation. The user enters either the public IP address of your Modem/Router or enters a public host name you have obtained for your public IP address. As soon as he presses ‘Enter’ his browser will try to look your host name up in the DNS to obtain an IP address to use or the given IP address is used to connect to your Router/Modem. Because the traffic is http traffic (TCP port 80) and your router opened port 80 (TCP) to pass through to your DiskStation at port 80 (TCP), your DiskStation will reply to the request of the user and starts showing your website.
  2. A user of yours uses CloudStation. But for security reasons you have opened port 16690 (TCP) in your Modem/Router and ordered requests to this port to be translated to port 6690 on the private side (local network) of your Modem/Router. The client on the device of the user connects to the public IP address (or host name) of your Modem/Router with the addition of ‘:16690’ to the IP address to tell to connect to the nonstandard port for this service. Your Modem/Router allows this request, because you have opened port 16690 (TCP) on the public side of Your Modem/Router. The request will be redirected to port 6690 (TCP) and send to your DiskStation, because you told the Modem/Router it handles the traffic for this port.
  3. A user, living in Norway, wants to use your FTP server. The FTP server is available but only for traffic that is originated in The Netherlands. When the user starts a FTP session and tries to connect to your FTP server. Your Modem/Router allows the FTP traffic on port 20 and 21 (TCP) and passes the request to your FTP server hosted by your DiskStation. The firewall on the DiskStation however finds out that the traffic came from a not allowed origin and will deny the access.

The examples above are trying to make clear the interaction between the Modem/Router and the firewall of your DiskStation. This interaction is projected with a red line with arrows in the first picture of this post.

You shouldn’t get sloppy opening ports on the internet side of your Modem/Router and rely on your Modem/Router and firewall to let foreign traffic on your local network. Even a firewall contains software. Always ask yourself if you really need to have to open a port. And don’t forget to close it when not needed anymore. Reduce open ports to the bare minimum of your needs. It’s always better to have an unreachable port than a firewalled port. The service behind that port can have a flaw that can be attacked. There is no firewall or Modem/Router to prevent that.

Virtual Private Networking

Virtual Private Netwoking (VPN) gives you the ability to be a physical part of your local network while you are on a remote location. When you have a VPN connection with your network, you have all the access to the network components as if you were working locally. Your local network will be stretched over the internet to your device as soon as you have started the VPN connection. It’s a relative save way to make connection to the local resources of your DiskStation.

VPN installed on the DiskStation comes in multiple flavors with each their own characteristics. PPTP is relatively simple to setup, but is considered less secure. L2TP is secure and supported out of the box by many operating systems, but gives some trouble when using Windows. (You have to set a registry key in Windows to let the L2TP implementation work behind NAT Modem/Routers.) OpenVPN lets you goof with certificates and you have to install a client on each device you want to use the OpenVPN connection. Depending on the VPN type you choose, you have to open some ports to access the VPN server.

A big advantage of using a VPN connection is that you can refrain from publishing ports on the internet for services like the DSM desktop. Through a VPN connection you still can access the DSM desktop remotely, but an attacker has to hack himself into your VPN first before he can start attacking your DSM desktop. There also maybe some other services only used by you, you might want to make accessible through VPN only.

You can use the VPN server that can be installed on your DiskStation. You may want to consider using another device that functions as VPN server. When your DiskStation may become compromised, you can’t trust the VPN connection any longer. It might be rerouted without you even noticing it. Some Modem/Routers have VPN functionality built in. Check the manual of your Modem/Router.

Measures

So? You are still here? Then you are highly motivated to find out what measures you can take to minimize the risks of attaching your DiskStation to the internet to provide services. In the following summary there will be a list of options you should implement to ensure you did the maximum to protect your data and you have the mechanisms in place to kick in when something goes wrong.

Update, update, update

The only defense you have against software flaws is updating your software as soon as there is an update version of the software. You may take some time to test the software or to find out if someone else reports problems, but you should install updates as soon as possible. (After an update release the bad guy also knows the flaws exists. From then on the clock starts ticking.) All the software in the chain of publishing a service to the internet must be kept up to date. That includes the software (firmware) of your Modem/Router, web service and DiskStation. (And all the others in your specific situation. Make a list and verify each component regularly.) Use automatic update features when available or let it send at least a mail to you when an update is available. Add yourself to mailing lists from manufacturers. When there is a vulnerability and there will be no update released for your specific service or device, you should take it offline and replace it with a new component.

Accounts and passwords

Use your administrators account to administer and use an user account to use your DiskStation. Create a new administrator account and disable the default ‘Admin’. Provide your administrator accounts with complex passwords and two-factor authentication. Use complex passwords that can be remembered by your users but are complex enough to protect the accounts. Disable the ‘Guest’ account and don’t forget to set the ‘IP Autoblock’ feature of your DiskStation. Clean up user accounts that are not used anymore.

More information:

Connectivity

If you only connect your DiskStation to the internet to have an internet presence with a website or mail server, then you are much better off with a commercial internet hosting provider. For a little amount of money you can have your website including your own domain and unlimited e-mail addresses. You don’t need to have the hassle of running a web server and a mail server when this is the only reason to open your DiskStation for the internet.

If you are still eager to do this all by yourself, then you must take some precautions. Open only the ports on your Modem/Router that are required by the services you are going to provide. If you stop the service, close the ports immediately. How to do this depends on your Modem/Router. You have to look into your Modem/Routers manual how to do this. Don’t get lazy and let UPNP let this do for you. If you do so, you are out of control. Disable UPNP as soon as possible in your Modem/Router. (See manual.)

If you have to open a port that is not an internet default port (being used by users with unknown origin) you have to use other ports on the internet than the default for the specific service. Use the NAPT to translate the port internally. Because you use a random port for the service the attacker has to find out what port you are using for what services. For fortune seekers this takes too much time. The just want to try the default and will go one when they find nothing. (It won’t protect you from an aimed attack on your public IP address.)

Enable the firewall on your DiskStation and configure it to only allow traffic that you want to have. Decline all other. You might want to fine tune it by requiring specific Source IP addresses or countries. (See earlier in this post.)

Only allow encrypted connections to your DiskStation to eliminate eavesdropping. Your DiskStation already has a certificate installed to be able to encrypt traffic. However this certificate isn’t ‘trusted’ by your web browser. However it is your own machine to trust, you can import it to trust it in the future or consider buying a commercial certificate. (For public websites with https, you should do this. Your customers might not find you trustworthy if you don’t.)

For gaining remote access to delicate services you should use VPN instead of directly opening ports to the services from the internet. Choose a secure VPN flavor that suites your needs and keep in mind what the reason is for authenticating twice if you want to access your DSM desktop remotely. (One for authenticating the VPN connection and one to authenticate to the DSM desktop.)

More information:

Protecting the data

Your really sensitive data should be protected with share encryption. This only protects against physical unauthorized access. (Theft of the device. Don’t forget to encrypt your backup too.) Once an attacker is in your DiskStation, encryption is not going to help.

Backup is another aspect of protecting your data. There are a lot of scenarios to deal with to make the right choice. There is one option your don’t have: No backups. Having any form of redundancy in your drives, does not mean you can do without any form of backup. One too many disks or the raid controller may fail and your data gets inaccessible forever.

The most common type of data loss is a user that inadvertently deletes a file. Your DiskStation has a function for this: Enable Recycle Bin. This can be found on the shred folder and is set per shared folder. You might consider setting the Hide folders and files from users without permissions option also. Only the administrator then can restore a file from the recycle bin and avoids confusion for the user. The deleted files and folders will be stored in the #recycled folder on the share. (The #recycled folder should not be included in a backup cycle to an external medium as backup.)

If data can’t be retrieved from the #recycled folder, you should be able to restore it from a backup you create periodically. The frequency of creating a backup of data depends on the nature of the data. If data changes frequently, you should make a backup frequently to. Some of it (documents) may be backed up on a day by day basis. Some other may be backed up less frequent. (Your vacation photos. You probably will not have vacation every day of the year.) If you are a photographer you consider your photos as documents and you might want to backup them on a daily basis. Create multiple backup jobs that comply with your needs. You can assign them a different interval of backing up. If you automate this and you think you need an extra backup cycle of a set, you always can start the backup job manually.

You have to decide where to store your backup. That depends on the risks you want to cover. If you just want to retrieve a file from a backup every now and then, then a relatively cheap local USB disk will be enough. You might want to consider an extra NAS in your local network for backup purposes. (This could be an outdated NAS that does not get updates anymore of the firmware and is unsafe to use for public appearance on the internet. In a home use or small office use this can be done. In large organizations you have to consider the threats coming from your local network too.)

If you want data protection against physical theft or fire, you have to look further. You need an offsite location to store your backup. This can be online and offline. You can store your backup on the NAS of a friend and your friend can store his’ in return on yours. You have to be aware that it can happen that one day your friend isn’t your friend anymore and ask yourself what will happen with your data. (Always encrypt!). Another aspect is your maximum upstream speed. It might take a while before your backup job is ready. (are the both NAS devices up and running the whole day or do you need to negotiate a time slot with your friend to complete your backup.)

Alternatively you can use commercial cloud storage. Like the issue with backing up to a friend’s NAS, your upstream may cause some limitations. Most of the time a limited amount of space is free; the rest has to be paid for. Depending on your needs you probably run out of free space soon. There are different clients for DiskStation to facilitate cloud synchronization that can be found in your Package Center. There is one that can be paid with your own storage: SymForm. You might to consider this if you don’t want to pay and still have the need of an offsite backup facility.

Another option is to take care of the offsite backup yourself. To be absolutely safe, you need two extra backup devices. One is offsite while the other is being used to be backing up to. When the backup is done, you transport the backup to the external location and you might pick up the first one immediately or pick it up later when you need it to backup to. Call it paranoia, but Murphy will always strikes when you expected it the least: What if your backup is done, but is still onsite waiting for transportation to the external location and a burglar visits your house stealing all your computer equipment? Then you still are left behind with no backup at all.

You also might need an offline backup. This kind of backup should protect you against tampered data that has been encrypted by some ransom ware. When you automated your backup jobs totally then you are risking that your files, encrypted by the ransom ware, will be backed up. If you choose to backup and replacing files with the newer versions of those files, your files in your backup will be encrypted too. Then you are still having no usable backup of your files. To protect you against these kinds of threats, you can backup manually after you ensured yourself that the files are not compromised. (You can define a job for this, but you have to start it manually. After the job is done, you have to detach the device from your NAS and store it somewhere safe.) This requires a high level of discipline and dedication of the administrator. He has to do a lot manually and repeat this every time it’s needed to create a new offline backup.

Finally you have to decide what kind of backup is needed to achieve your goals. How many versions of a backup should be kept, should the backup always contain all files or do you want a full backup weekly and a day by day incremental or differential until the next full weekly backup? This has all to do with your capacity needs of the data you want to backup and how many space you are willing to invest. It’s common that files that are backed up are written over the previous version of that file during backup. (For home office use this might seems enough, however if you are doing this professionally you should consider what if the current backup job ruins this backup? You might end up with having no backup at all.)

So, backup is easy? It’s not. For most users it is enough having a backup at all and for those who wants to protect themselves against fire or theft, they should take actions to make sure they have an offsite backup as well. And for those who wants to protect themselves against ransom ware also needs to have an offline backup. It’s possible that not all these jobs can be done in one run. You must create jobs that suites your needs. Some can be executed automatically, some must be executed manually. Be aware of where your data is and under witch circumstances. (Who can control it?) To have a good backup strategy requires a good plan that starts with the threats you want you to protect against. The strategies you have to pick must fulfill the protection of these threats.

Backup comes at a cost. Cost can be in time to backup or size of the files to be backed up. Be picky in what has to be backed up and what can be restored otherwise. Self-created documents or holiday photos and videos can’t be recreated otherwise than restoring from a backup. You can’t do the vacation over again when the photos are lost. However your downloaded collection of shareware or freeware can be downloaded again and must not be backed up.

It’s always a good idea to create backups of the DiskStations configuration too. This includes server configuration, users, groups and shared folders information. Include also the MariaDB database server data files and configuration. This can speed up the process of rebuilding your DiskStation when you have to recreate it after a disaster. This backup does not backup configuration settings of 3th party applications installed later on your DiskStation. You can create a shell script that copies configuration files to a certain folder to be included in the backup. This shell script can be run automatically as cronjob or task in your DiskStations task scheduler.

The most important about backups is saved for the last: TEST YOUR BACKUPS. Make sure the data that should be in the backup is in the backup and can be restored! (Don’t just look into the files set, also do an actual restore.) Backing up makes no sense if you are unable to restore it. Don’t rely on a success message in the log. Backing up 0 files will also result in a success. You will not be the first who discovered at the moment the backups were needed the most, there is nothing to restore.

More information:

Advanced Measure

If you need a more secure environment to fulfill your needs, then you should consider splitting things up. This increases the complexity of the complete infrastructure, but also increases the security of your data. This paragraph will describe additional suggestions to achieve that.

Separation of functionality spreads the impact of vulnerabilities that might occur. A server with no documents that becomes hacked contains still no documents after the hack. There are also some network measures that can be taken to make sure that when a service is being hacked, there still will be a barrier before a more delicate server is reachable. These measures will cost money mostly and requires high skills of knowledge to implement. Consult an IT professional to help you with this if this goes beyond your own knowledge.

Implementing a DMZ creates a network before the local network containing public services exposed to the internet. Hosts in the DMZ are very limited to have contact with specific hosts in the local network. They are also limited in their connection to the internet. This allows DMZ hosts to communicate with both the internet and the local network. One firewall controls the traffic between the internal network clients and the DMZ, and another firewall protects the hosts in the DMZ from the internet. Traffic to reach your web server will never travel over your local network, just into your DMZ. Web servers, mail servers FTP servers and VPN Servers are candidates to put into your DMZ.

With your public services in the DMZ, you can leave your file server and other internal services in your local network on another DiskStation. This DiskStation can’t be reached from the internet anymore to be attacked.

A firewall should be hosted on other devices than the hosts they protect. You might have to invest in one or two extra routers with firewall capabilities. (Depending if you are building a DMZ or not.) Depending on the capabilities you need from the firewall, you might need more than a simple Soho-router.

Like firewalls, VPN servers shouldn’t be hosted on the host with other services. If you created a DMZ and put a DiskStation in it, you can use this device to host the VPN server. Otherwise your Modem/Router or another separated device should host the VPN server. When your only DiskStation gets compromised and it is directly connected to the internet, you might not be able to start a VPN connection to your network if you are offsite and must interfere immediately. If you host your VPN server on a DiskStation in your DMZ and this machine gets compromised, you can’t access your network either.

Services like CloudStation that should be accessible from the internet, should use a steppingstone in the DMZ. You can pass it through directly to you DiskStation in your local network containing your files, but is seems a better idea to make these files for a user accessible through the DMZ. You can do an extra security checks (virus scanning) before the files reaching your local network. The other alternative is to allow CloudStation synchronization only when the client is connected to the local network. (Directly or via VPN.) This construction removes the necessity of opening a port for CloudStation to the internet. You can build a steppingstone facility on your internal network to do some extra security checks when the files are coming in.

I am playing with the idea of using the PXE capabilities of my DiskStation for a while now. I postponed many times the moments that I want to start with it. It has some implications for my network infrastructure and I couldn’t find the time to do this. I decided to do it in several stages to come to the situation that I’m able to use the PXE server. This post will describe what I did to start using PXE with all kind of network boot functionality. It must be able to start installations of operating systems (Windows and Ubuntu), Anti virus scanners and other maintaining tools.

1. Prerequisites

Before you can use the PXE server you have to fulfill some prerequisites. You have to enable PXE capabilities on your current DHCP server, or use the DHCP capabilities of your DiskStation. I decided to use the DHCP of the DiskStation, because my router’s DHCP does not support these features. Many times these kind of features are not supported by the router you get from your ISP. This also allows me to start using the DNS server capabilities of my DiskStation. I have the feeling this DNS is much faster than the DNS of my router and, because I’m able to define the DNS-server to use, I took the opportunity to switch my DNS-server too.

Another prerequisite is the availability of a shared folder to serve the PXE from. You can use an existing one, but I’ll advise you to create a new one.

1.1 Enable DHCP

I’ll start with a warning: you do NOT want to have more than one DHCP on your local home network. It is also a good idea to write down your current IP-address, subnet mask an gateway address. You might need this when the configuration of the DHCP service of the DiskStation is faulty and the current DHCP-service is disabled. (You can make the IP configuration of your workstation static with this information and enables you to gain network access again.)

This means when you start using the DHCP service of your DiskStation, you have to disable your current DHCP service. This is most of the time provided by your modem/router. On each modem/router this service can be managed, only the way how to do this differs. Check the manual of your modem how to do this.

To make the switch more smoothly for me, I use the same address pool range as was using on my modem/router. To enable the DHCP on the DiskStation open in DSM the ‘Control Panel‘ and select ‘Network‘. Click on the ‘Network Interface‘-tab. Select the ‘Lan’ you want to enable the DHCP service for. Click the ‘DHCP server‘ button.

In the ‘General‘ tab you have to tick the ‘Enable DHCP Server‘ checkbox. You have to define minimal one DNS-Server. The ‘Primary DNS’ has to be filled with the IP-address of the DNS-server to use. If you remain using your modem/router as DNS-server, then you have to enter the IP-address of your modem/router here. If you use another DNS-server then you enter this IP-address accordingly. (How to use the DiskStation DNS is not a part of this post. You have to find this information elsewhere, or keep using the DNS of your modem/router. This will make no difference for the PXE capabilities.)

You also have to define an address pool for the DHCP service. Click on the ‘Add‘ button and enter the start address and end address of the pool and enter a subnet mask and gateway address. (The start address and end address can be found in the modem/router settings. To find the subnet mask and the gateway address, you can use ‘ipconfig /all‘ in a Windows DOS-box. The gateway address will probably the IP-address of your modem/router.) Make sure the address pool is marked as ‘enabled‘.

Now click on the ‘Apply‘ button to start and enable the DHCP server of the DiskStation. Now it is the time to disable the DHCP-service on your modem/router. This completes the DHCP part.

1.2 Creating shared folder

This is a default functionality of your DiskStation. In ‘Control Panel‘ Click ‘Shared Folder‘. Click on the ‘Create‘ button. Give it an appropriate name (I choose tftproot) and ‘Location‘ and tick the boxes ‘hide this shared folder in ‘My Network Places‘ and ‘Hide folders and files for users without permissions’. Click the ‘OK‘ button to create the shared folder.

Select the just created shared folder and open the ‘Privileges‘ menu. Select the ‘Privileges Setup‘ item and give the ‘administrators group‘ read and write access. I also added NFS read rights for my complete network. This can be done with the ‘NFS privileges‘ in the ‘Privileges‘ menu. I struggled a while with the NFS privileges, but I have a working configuration now. You have to enter three values, the ‘IP address’ (or network) that has access to the NFS share, the ‘Privilege’ and the ‘Root squash’. I used 192.168.1.0/24 (Network), Read only and Map to admin.

With the above prerequisites fulfilled you are good to go to start using the PXE services of your DiskStation.

2. Setup the DiskStations PXE service

The prerequisites must function well before it makes any sense to continue. So make sure your DHCP server works well.

The following step is to setup de PXE service. Before you can do that, you need some files to actually boot from the network. I used PxeLinux witch is a part of SysLinux. you have to pick some files from several locations of the zip: chain.c32, mboot.c32, memdisk, menu.c32, pxelinux.0 and vesamenu.c32. For your convenience I made a zip-file containing these files. You can download the zip from here.

Extract or copy these files to the root of the shared folder you have created for your PXE service. (i.e. tftproot). Use a program like WinSCP (If you are using Windows). The location of the shared folder will be /volumeX/tftproot where X is the volume number on witch you created the shared folder. After you have done that, create a folder named pxelinux.cfg and a folder named images in the tftproot folder.

The next thing to do is to create a text file named default in the pxelinux.cfg folder. Use an appropriate text editor. The one in WinSCP will do. (Windows default Notepad doesn’t!). put the following text in the default file:

default menu.c32
prompt 0

MENU TITLE PXE Boot Main Menu
MENU INCLUDE pxelinux.cfg/graphics.conf
MENU AUTOBOOT Starting Local System in # seconds

LABEL local
    MENU LABEL Boot local hard drive
    MENU default
    LOCALBOOT 0
    TIMEOUT 300
    TOTALTIMEOUT 9000

Create another text file in the pxelinux.cfg folder with the name graphics.conf. This file contains some color and other layout settings for the PXE boot menu and is included in the default file. Put the following text in the graphics.conf file:

    menu color tabmsg 37;40          #80ffffff #00000000
    menu color hotsel 30;47          #40000000 #20ffffff
    menu color sel 30;47             #40000000 #20ffffff
    menu color scrollbar 30;47       #40000000 #20ffffff
    MENU MASTER PASSWD yourpassword
    MENU WIDTH 80
    MENU MARGIN 22
    MENU PASSWORDMARGIN 26
    MENU ROWS 6
    MENU TABMSGROW 15
    MENU CMDLINEROW 15
    MENU ENDROW 24
    MENU PASSWORDROW 12
    MENU TIMEOUTROW 13
    MENU VSHIFT 6
    MENU PASSPROMPT Enter Password:
    NOESCAPE 1
    ALLOWOPTIONS 0

Save the files and switch to the DSM desktop of your DiskStation.

Open the ‘Control Panel‘ and tick the FTP feature. Select the ‘TFTP/PXE‘ tab. Enable the ‘Enable TFTP service‘ feature and select the ‘TFTP root folder‘ you have created earlier. (i.e. tftproot).

Click the ‘Advanced Settings‘ button and make the ‘FTP Client Permissions‘ set to ‘Read only‘. You also have to limit the ‘Allowed Clients‘ to the address range of your local network. (The start address and end address of your DHCP address pool will do.) Click the ‘OK‘ button to confirm these advanced settings.

Now also enable the ‘Enable PXE service‘. The next thing to do is to select the ‘Boot loader‘. Click the button and pick: pxelinux.0. Next select the LAN interface you enabled DHCP earlier on. (i.e. LAN 1). The only thing left to do is to configure the DHCP. Use the same information you used earlier to configure your DHCP service. (DNS server address, start address, end address, subnet mask an gateway address) Click the ‘Apply‘ button to save the information and start the TFTP and PXE service.

If everything went well so far, you now must be able to do a network boot with a client computer and can select the option to ‘Boot the local hard drive’. I know this isn’t much, but it is the bare minimum to make sure PXE booting works. The following chapter will describe how to add more to the PXE boot menu. (Keep in mind I would like to create a rich boot menu with all kind of different options. This takes time to figure out.) You may want to go from here by yourself or you see what the next chapter will bring.

3. Filling the PXE boot menu

As I mentioned before I would like to have many different tools and services from the PXE service. To make sure this stays accessible in the future, I need a menu structure with sub menu’s to organize all this. I’ll start to explain how to make these menu’s in the PXE boot menu. After that the filling of the submenu’s will be explained.

3.1 Adding a sub menu

To add a sub menu, create a new text file with an appropriate name in the pxelinux.cfg folder. For this example create a file with the name ‘rescue.menu‘ to accommodate all the functionality that the PXE service supplies to ‘rescue’ a computer. This can be a virus scanner or a recovery disk to try to recover data from a computer that can’t boot by it self.

For now the sub menu will not have any content (Beside an entry to return to the main menu). That will be handled later. First create the sub menu’s. Create a text file rescue.menu and put the following in it:

default menu.c32
prompt 0

MENU TITLE Rescue Menu
MENU INCLUDE pxelinux.cfg/graphics.conf

LABEL Main
    MENU LABEL ^Return to Main Menu
    KERNEL menu.c32
    APPEND pxelinux.cfg/default

Save the file. This file will be called from the default menu. To achieve this, the default text file must be extended with the following lines:

LABEL Rescue
	MENU LABEL ^Rescue Menu...
	KERNEL menu.c32 
	APPEND pxelinux.cfg/rescue.menu

This snippet creates a menu item in the PXE boot menu. So for any sub menu you need, you can use this structure. Just change the MENU LABEL, and the APPEND accordingly. The position in the text file of a snippet is also the position the item has in the boot menu. The new default now looks like this:

default menu.c32
prompt 0

MENU TITLE PXE Boot Main Menu
MENU INCLUDE pxelinux.cfg/graphics.conf
MENU AUTOBOOT Starting Local System in # seconds

LABEL Rescue
	MENU LABEL ^Rescue Menu...
	KERNEL menu.c32 
	APPEND pxelinux.cfg/rescue.menu

You are now able to add items to the PXE menu’s. No matter is this is the default menu or any submenu. The idea is the same: just add a snippet to the file you want to extend with the functionality. Beyond this I only show the snippets that makes a PXE boot menu item, not a complete text file.

3.2 Booting an ISO image with PXE

The first idea that came up to me was to start with a bootable ISO-image. I choose the Hirens Boot CD that can be downloaded from http://www.hirensbootcd.org. Download the zip (590M) and extract the ISO-file from the zip-archive. copy Hiren’s.BootCD.15.2.iso to the images folder you created in the tftproot folder. (It is a good idea to create a structure that makes sure that you find your way in the future here, when this folder becomes more crowded.) For this example I simply drop the ISO in the images-folder.

The following snippet makes a menu entry that let you boot Hirens boot cd from the network:

LABEL hirensbootcd
	MENU LABEL ^Hirens boot CD
	kernel memdisk
	append iso initrd=images/Hiren's.BootCD.15.2.iso raw

When you add this snippet to the previously created rescue.menu file, you’ll find the Hirens boot cd in the rescue menu of the PXE boot menu.

I found out that not all the ISO images let them start so easily. In the next chapter I start collecting all kind of snippets to start all kind of functionality from the PXE server. An example that causes me troubles were the Kaspersky Rescue disk and the F-Secure rescue disk. I will keep trying and publish as soon as I’ve found a way to start these successfully.

3.3 Booting from an NFS share

This took me a while to figure out how this works. This has to do with how NFS works in the first place. After I sorted that out, I decided to setup a PXE from the ‘Trinity Rescue Kit’ (TRK). I downloaded the ISO image from TRK and extracted the ISO. (I know there are other archives.) You can download TRK from http://trinityhome.org/ (151M).

Copy the folder with it’s content of the extracted ISO as subfolder to ‘/TftpRoot/images/’. I presume that this subfolder name is ‘trk‘, so Trinity Rescue Kit is saved in /TftpRoot/images/trk/ on your DiskStations shared folder for PXE. The only thing left to do is enter the TRK as a menu entry in the PXE boot menu:

LABEL trk3
      menu label ^Trinity Rescue Kit
      kernel images/trk/kernel.trk
      append initrd=images/trk/initrd.trk ramdisk_size=65535 root=/dev/ram0 vga=0 trknfs={IP_DISKSTATION}:/volume1/TftpRoot/images/trk/ ro ip=::::::dhcp splash=verbose

Make sure you entered the correct IP address (IP_DISKSTATION) and volume in the append line of the menu entry above.

4. PXE Boot menu snippets

This chapter contains some examples of snippets to extend the PXE boot menu. The given file destinations are default located in the images folder that is located in the shared folder assigned to the PXE services. (i.e. tftproot)

4.1 Bootable ISO’s

This section contains a snippet that let the accordingly ISO image boot with the PXE server.

4.1.1 Hirens Boot CD
Source: http://www.hirensbootcd.org/download/
File(s): Hiren’s.BootCD.15.2.iso
File(s) destination: images/
Snippet:

LABEL hirensbootcd
	MENU LABEL ^Hirens boot CD
	kernel memdisk
	append iso initrd=images/Hiren's.BootCD.15.2.iso raw

4.2 Boot live systems

This section contains snippets that let you boot a live system from the network.

4.2.1 Trinity Rescue Disk
Source: http://trinityhome.org/Home/index.php?content=TRINITY_RESCUE_KIT_DOWNLOAD
File(s): ISO image extract in a subfolder named ‘trk’
File(s) destination: images/trk/
Snippet:

LABEL trk3
      menu label ^Trinity Rescue Kit
      kernel images/trk/kernel.trk
      append initrd=images/trk/initrd.trk ramdisk_size=65535 root=/dev/ram0 vga=0 
		trknfs={IP_DISKSTATION}:/volume1/TftpRoot/images/trk/ ro ip=::::::dhcp splash=verbose

(The ‘append’ line in the snippet above is ONE line.)

4.2 Other

For those who can read German, there is an extensive Wiki about PXE on Synology with many more examples to add items to your PXE bootmenu. Please visit the deutschen SynologyWiki. (They have a lot of other interesting Wiki’s too!)

Your FritZ!Box may have the ability to generate package traces of your network traffic. If you own a Fritz, click either of the two links below and authenticate yourself on the Fritz.
Select the interface you want to trace by clicking on the corresponding start button. Doing so starts a streaming download in your browser. DO NOT stop this. If you want to stop the trace select the corresponding stop button. After that select the option in your download window to save the trace. Then you can open it to analyze with WireShark (http://www.wireshark.org/).

Start trace 1
Start trace 2 (Does not work anymore on FRITZ!OS 05.51 Firmware version: 99.05.51.)

There is a very annoying problem when you install VMware (or VirtualBox) on Vista (and Windows Server 2008 and above). When you install VMware it adds a few virtual network adapters. For various reasons, these adapters are listed in the Network Sharing Center as being on an “Unidentified network (Public network)” and all of the features under Sharing and Discovery are turned off .

Here is the best fix I’ve found in the VMware forum:

  1. Run regedit
  2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}
  3. Underneath you should see several keys labeled 0000, 0001, 0002 etc… Look through these and find the VMware adapters. They will probably be near the end of the list if you just installed VMware.
  4. For each of the VWware adapters, add a new DWORD value named “*NdisDeviceType” and set it to 1 (make sure you get the * at the beginning of the name, I missed that the first time).
  5. Disable and Enable each of the network adapters.

That should take care of the problem. Setting *NdisDeviceType to 1 causes Windows to ignore the device when it does network identification.

It turns out that the same issue occurs when using other hypervisors (i.e. VirtualBox). The strategy is the same. Find the adapters created by the used hypervisor in the registry key mentioned above and add the *NdisDeviceType DWORD with a value of 1.

Source: Rob Boek