Securing the admin account on your Synology — 2FA, password, login protection

A Synology we provision for you has its own public IPv4 — so it’s reachable from the entire internet. That’s a feature, not a bug: you want to access it on the go. But: every DSM instance exposed to the internet gets brute-force attempts on its login from day one. In our experience, the first login attacks show up in the log after about 4 hours.

With the following four measures, all of that is harmless. Without them, things can get unpleasant at some point.

1. Disable the default admin account

Synology ships with a user called admin by default. We disable it during provisioning — brute-force attempts usually target admin specifically, so we take it out of the equation.

That’s why your admin account has a different name (typically admin-<your-customer-number> or one you chose). If you still see the admin user in the user list: disable it.

Control Panel → User & Group → admin → Edit → check “Disable this account”.

2. Strong password

Sounds obvious, but it isn’t. From our logs: 70% of brute-force attempts try the all-time top 100 passwords (123456, qwerty12, synology, admin123, …).

Generated from your password manager: at least 16 characters, mixed, unique. Not used anywhere else. Bitwarden, 1Password, KeePass — doesn’t matter which one, as long as it’s not stored in your head.

Control Panel → User & Group → your account → change password.

3. Two-factor authentication (2FA / TOTP)

This is the single most important measure. Even if someone has your password, they won’t get in without the second factor.

Setup:

1. Install a TOTP app on your smartphone — we recommend 2FAS or Aegis (open source, local backup). Apple users can also use the built-in password manager.
2. In DSM: Personal → Account → 2-Factor Authentication → Enable.
3. Scan the QR code with the app.
4. Enter the 6-digit code from the app — setup complete.

Important: at the end, DSM shows you recovery codes. Print them or store them in your password manager — if your smartphone breaks or gets lost, these codes are the only way back in. From our own experience: printing them and filing them in a binder is the most reliable option.

4. Enable auto block

DSM has built-in brute-force protection that automatically blocks the source IP after X failed logins. By default it’s off — which in our experience is the most common cause of security problems that surface later.

Control Panel → Security → Account → Auto Block:

• Enable auto block: on
• Login attempts: 5
• Within (minutes): 5
• Enable block expiration: on
• Unblock after (days): 7

That blocks any IP that enters wrong credentials 5 times in 5 minutes for a week. From our logs: blocks 99% of brute-force attempts within seconds.

If you ever lock yourself out (typo in the password), you can get back in from a different IP and lift the block yourself in the same panel.

5. (Optional) Change the DSM port

By default, DSM listens on port 5000 (HTTP) and 5001 (HTTPS). Both are very well known on the internet and attract scanners.

You can change the HTTPS port, for example to 15001:

Control Panel → Login Portal → DSM → HTTPS port: 15001.

Your DSM is then reachable at https://...:15001/. Brute-force scanners that only probe 5001 come up empty. Makes the logs quieter, but it’s not real protection — anyone who really wants in scans all ports.

Careful: don’t forget the new port. Otherwise we can only reach DSM via VNC and have to reset the port for you.

6. Permission hygiene for other users

If you give family members or colleagues access: don’t hand out the admin account. Instead:

1. Create a separate user per person.
2. Only share the shared folders they actually need — not all of them.
3. Don’t grant admin rights unless genuinely necessary.
4. A separate password per user (no shared ones).

That way you can disable individual users in an emergency without affecting everyone else.

What we do on our side on top

On the hardware side we run protective measures you don’t have to configure yourself:

• DDoS filtering in front of the data center — massive attack waves are intercepted before they reach your NAS.
• Network monitoring: if a single IP suddenly sends extreme amounts of traffic to your Synology, that alerts us.
• Fail2ban logs: we track brute-force patterns in our aggregation logs.

That doesn’t mean you’re off the hook, though. The DSM login layer is your responsibility.

Frequently asked questions

Do I need a VPN to access DSM? No, with the four measures above (password, 2FA, auto block, optionally a custom port), direct HTTPS is enough. A VPN makes the whole thing even more secure, but it’s operationally inconvenient — you’d have to enable the VPN every time before Drive syncs.

What about running an OpenVPN server on the Synology? Synology ships a VPN server (the “VPN Server” package in Package Center). Feel free to enable it — handy if you want to reach other services on your network too, not just the NAS. But for pure NAS access it’s overkill.

I lost my 2FA device — now what? If you have the recovery codes: use one of them to log in, then set up 2FA again. If not: open a ticket, we reset 2FA via VNC. That only works if you can identify yourself to us (for example via a mail from the email account on file).

Can I downgrade the admin account to a normal user? You need at least one administrator. So if you create a second admin user and make the first one a plain “user”, that’s fine. We recommend, though: one admin account that isn’t used for everyday things, plus a normal user for daily use.

How do I see whether someone tried to break in? Log Center in DSM (its own package, often already installed) → filter “Connection” → there you’ll see failed logins with the source IP. With auto block enabled, you’ll also see the blocked IPs.

What if I want push notifications about failed logins? Control Panel → Notification → Rules — you can set up email or push per event type. “Login failed” is part of our standard recommendation.

What’s next

• Point your own domain at your Synology
• Set up a Let’s Encrypt certificate