Being Practical yet Secure! MikroTik Port Nocking and Starlink Dynamic IP
- MoLuke Inc
- Aug 18
- 4 min read
Remote Desktop Protocol (RDP) is one of the most common entry points for attackers. Recently, while working with a client to improve their network security, I discovered a subtle yet serious vulnerability in how they managed RDP access.
The Initial Setup
The client had implemented what looked like a reasonable approach:
Whitelist of employees’ semi-static home IPs for RDP access.
Firewall rule allowing only these whitelisted IPs to reach the RDP servers.
Non-default RDP port (security by obscurity).
At first glance, this seemed fine. But when I reviewed the firewall rules carefully, I realized something important: although there was an “allow access” rule for employees, there was no explicit deny rule preventing others from connecting to the RDP servers. In practice, anyone could still reach the service.
Why Not Just Block It?
The knee-jerk reaction might be to block everything outright. But that’s risky: business continuity is just as important as security. Pulling the plug without a backup plan could lock out the entire company and disrupt operations.
So instead, I took a more careful and incremental approach.
Step 1: Observe First, Block Later
That night, I added a logging rule on the MikroTik router to monitor access to the “obscured” RDP port. The logs quickly revealed what I expected:
attackers had already found the port and were running brute-force attempts.
As a quick stopgap, I began blocking the attackers’ IP addresses. This was low-hanging fruit until I could properly address the issue the next morning.
Step 2: Communication First
The next day, I contacted the supervisor and explained the risk. I asked them to warn employees that access changes were coming and to report any problems. With communication in place, I moved forward.
Step 3: Controlled Lockdown — and the Starlink Surprise
I then blocked public access to the RDP port, leaving only whitelisted addresses. As expected, a few employees reported problems because their IPs weren’t yet in the whitelist.
The first three reports came quickly, and I added their IPs to the list without issue. This was part of my plan — I knew there might be unlisted employees who hadn’t been accounted for. Within minutes, those three were back online.
About an hour later, however, I received another complaint: one employee was still locked out. When I checked the logs, I saw something strange — her IP had already been whitelisted, yet the connection attempts were coming from a completely different IP.
After a closer look, I realized she was using Starlink. Unlike typical ISPs that keep customer IPs relatively stable, Starlink frequently reassigns new IPs — sometimes multiple times in a single day. In fact, her IP had already changed twice that morning. Static whitelisting was clearly not going to work in this case.
This posed a new challenge:
I couldn’t simply open up RDP to the entire internet.
Whitelisting Starlink’s whole IP range would defeat the purpose.
Rolling back to “open access” was not an option.
I needed a solution that could work immediately, without onboarding a new VPN or ZTNA solution overnight.
Step 4: Port Knocking to the Rescue
The best long-term solution is a VPN or Zero Trust Network Access (ZTNA). These approaches eliminate the risks of exposing RDP to the internet altogether.
Now, MikroTik actually makes it possible to spin up an OpenVPN server within minutes — and I’ve done it many times. The RouterOS feature set is impressive, and technically I could have had a VPN tunnel up and running before the employee finished her coffee.
But here’s the reality: the real challenge isn’t how fast the server can be set up — it’s how fast you can onboard employees. Installing a client, distributing configuration files, and walking a non-technical user through the setup over the phone takes time. In the middle of a workday, that can mean hours of lost productivity.
That’s why, for this particular case, I reached for a different MikroTik facility: Port Knocking. It gave me a way to secure the RDP access immediately while still keeping things seamless for the employee.
The idea is simple: employees “knock” on three predefined ports in sequence. If they do it correctly within a short time window, their IP is dynamically added to the whitelist.
For the Starlink employee, I provided three URLs like:
http://<IP>:<PORT1>
http://<IP>:<PORT2>
http://<IP>:<PORT3>
When she clicked them in order (within 10 seconds), her current IP was whitelisted for 4 hours. Problem solved — and no downtime.
NOTE: This is not a complete secure solution!
While this worked well for a particular customer with specific situation, it is highly advised to evaluate your own case and context and then implement your tailored security measures!
MikroTik Firewall Rules for Port Knocking
Here’s the exact implementation:
1. Create Address Lists
/ip firewall address-list
add list=Employee
add list=Employee_pre1
add list=Employee_pre2
2. Port Knocking Rules
/ip firewall mangle
# First knock - add to Employee_pre1 for 20s
add chain=prerouting protocol=tcp dst-port=<PORT1> tcp-flags=syn \\
action=add-src-to-address-list address-list=Employee_pre1 \\
address-list-timeout=20s
# Second knock - only from Employee_pre1, add to Employee_pre2 for 20s
add chain=prerouting protocol=tcp dst-port=<PORT2> tcp-flags=syn \\
src-address-list=Employee_pre1 action=add-src-to-address-list \\
address-list=Employee_pre2 address-list-timeout=20s
# Third knock - only from Employee_pre2, add to Employee for 4h
add chain=prerouting protocol=tcp dst-port=<PORT3> tcp-flags=syn \\
src-address-list=Employee_pre2 action=add-src-to-address-list \\
address-list=Employee address-list-timeout=4h
3. Secure RDP Access Rule
/ip firewall filter
# Allow RDP only from Employee list
add chain=input protocol=tcp dst-port=<RDP_PORT> \\
src-address-list=Employee action=accept
# Drop everything else to RDP
add chain=input protocol=tcp dst-port=<RDP_PORT> action=drop
With this, attackers could no longer brute-force RDP, and employees could still connect — even with dynamic IPs.
Extra Thoughts
Instead of whitelisting for hours, you could block only new TCP SYN packets. This way, once the RDP session is established, the connection continues even if the IP is removed.
Use stateful firewall rules to allow established and related connections. This reduces the need for long whitelist timeouts.
Final Takeaway
Security is always a balance between business continuity and risk management. In this case, Port Knocking provided a quick and practical middle ground until the client could roll out a VPN or ZTNA solution.
And this is where MikroTik shines: it offers the flexibility to roll out a VPN in minutes if needed, while also providing creative options like Port Knocking to bridge the gap when user onboarding is the bottleneck.
Comments