Due to the COVID-19 pandemic and widespread lockdowns in many countries, remote access to workstations via the internet has become the only solution for many companies to continue operations. There are several relatively safe methods for remote work; however, considering the scale of the problem, a method that is easy for any user to connect remotely to the office without requiring additional configurations, explanations, tedious consultations, or lengthy instructions is necessary. One such method favored by many administrators is RDP (Remote Desktop Protocol). Directly connecting to a workstation via RDP perfectly addresses our needs, with one significant drawback—keeping the RDP port open to the internet is very unsafe. Therefore, below I propose a simple yet reliable method of protection.
Since I often encounter small organizations that use Mikrotik devices for internet access, I will demonstrate how to implement this on Mikrotik; however, the Port Knocking protection method can easily be applied to other higher-class devices with similar router and firewall settings.
A Brief Overview of Port KnockingThe ideal external network protection when connected to the internet is to have all resources and ports closed from outside by a firewall. Although a router with such a configured firewall does not react to incoming packets from outside, it does listen to them. Therefore, the router can be configured so that upon receiving a specific (coded) sequence of network packets on different ports, it (the router) grants access to certain resources (ports, protocols, etc.) for the IP address from which the packets originated.
Now to the point. I won't go into detailed descriptions of firewall settings on Mikrotik—there are plenty of quality resources on the internet for that. Ideally, the firewall blocks all incoming packets, but
/ip firewall filter
add action=accept chain=input comment="established and related accept" connection-state=established,relatedIt allows incoming traffic from already established (established, related) connections.
Now let's configure Port Knocking on Mikrotik:
/ip firewall filter
add action=drop chain=input dst-port=19000 protocol=tcp src-address-list="Black_scanners" comment=RemoteRules
add action=drop chain=input dst-port=16000 protocol=tcp src-address-list="Black_scanners" comment=RemoteRules
add action=add-src-to-address-list address-list="remote_port_1" address-list-timeout=1m chain=input dst-port=19000 protocol=tcp comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=19001 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=18999 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=16001 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=15999 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="allow_remote_users" address-list-timeout=1m chain=input dst-port=16000 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
move [/ip firewall filter find comment=RemoteRules] 1
/ip firewall nat
add action=dst-nat chain=dstnat comment="remote_rdp" src-address-list="allow_remote_users" dst-port=33890 in-interface-list=WAN protocol=tcp to-addresses=192.168.1.33 to-ports=3389Let’s go into more detail:
The first two rules
/ip firewall filter
add action=drop chain=input dst-port=19000 protocol=tcp src-address-list="Black_scanners" comment=RemoteRules
add action=drop chain=input dst-port=16000 protocol=tcp src-address-list="Black_scanners" comment=RemoteRulesblock incoming packets from IP addresses that are blacklisted during port scanning;
The third rule:
add action=add-src-to-address-list address-list="remote_port_1" address-list-timeout=1m chain=input dst-port=19000 protocol=tcp comment=RemoteRules adds the IP to the list of hosts that made the correct first knock on the required port (19000);
The following four rules:
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=19001 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=18999 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=16001 protocol=tcp src-address-list="remote_port_1" comment=RemoteRules
add action=add-src-to-address-list address-list="Black_scanners" address-list-timeout=60m chain=input dst-port=15999 protocol=tcp src-address-list="remote_port_1" comment=RemoteRulescreate trap ports for those who want to scan your ports, and upon detecting such attempts, their IPs are blacklisted for 60 minutes, during which the first two rules prevent these hosts from accessing the correct ports;
The following rule:
add action=add-src-to-address-list address-list="allow_remote_users" address-list-timeout=1m chain=input dst-port=16000 protocol=tcp src-address-list="remote_port_1" comment=RemoteRulesplaces the IP in the allowed list for 1 minute (enough to establish a connection), as a second correct hit is made to the desired port (16000);
The next command:
move [\/ip firewall filter find comment=RemoteRules] 1moves our rules up in the firewall processing chain, as we likely already have different blocking rules set that will prevent our newly created ones from functioning. The very first rule in Mikrotik starts from zero, but on my device, zero was occupied by a built-in rule and it was impossible to move it — I moved it to 1. So we look at our settings — where we can move it and specify the desired number.
The next configuration:
/ip firewall nat
add action=dst-nat chain=dstnat comment="remote_rdp_to_33" src-address-list="allow_remote_users" dst-port=33890 in-interface-list=WAN protocol=tcp to-addresses=192.168.1.33 to-ports=3389performs port forwarding from a randomly chosen port 33890 to the standard RDP port 3389 and the IP of the computer or terminal server we need. We create such rules for all necessary internal resources, preferably setting up non-standard (and different) external ports. Naturally, the IPs of internal resources should be either static or assigned by DHCP. server.
Now our Mikrotik is configured and we need a simple user procedure to connect to our internal RDP. Since we mainly have Windows users, we create a simple bat file and name it StartRDP.bat:
1.htm
1.rdprespectively, 1.htm contains the following code:
<img src="http://my_router.sn.mynetname.net:19000/1.jpg">
click refresh to re-enter via RDP
<img src="http://my_router.sn.mynetname.net:16000/2.jpg">This contains two links to fictitious images located at my_router.sn.mynetname.net — we obtain this address from the MikroTik DDNS system by first enabling it in our MikroTik: go to the IP->Cloud menu, check DDNS Enabled, click Apply, and copy the DNS name of our router. This is essential only when the router's external IP is dynamic or when using a configuration with multiple internet providers.
The port in the first link :19000 corresponds to the first port we need to connect to, while the second link corresponds to the second port. Between the links is a short instruction showing what to do if our connection drops due to brief network issues — refresh the page, the RDP port will reopen for us for 1 minute, and our session will be restored. Additionally, the text between the img tags creates a micro-delay for the browser, reducing the likelihood of the first packet reaching the second port (16000) — in two weeks of use (30 people), there have been no such cases.
Next is the file 1.rdp, which we can configure either for everyone or individually for each user (that’s what I did — it's easier to spend an extra 15 minutes than several hours consulting those who couldn't figure it out).
screen mode id:i:2
use multimon:i:1
.....
connection type:i:6
networkautodetect:i:0
.....
disable wallpaper:i:1
.....
full address:s:my_router.sn.mynetname.net:33890
.....
username:s:myuserlogin
domain:s:mydomainOne interesting setting here is use multimon:i:1 — this enables the use of multiple monitors — some users need this, but many wouldn’t think of enabling it themselves.
connection type:i:6 and networkautodetect:i:0 — since most have internet speeds above 10 Mbps, we set the connection type to 6 (local network 10 Mbps and above) and disable networkautodetect, as by default (auto), even a rare minor delay can set a considerably reduced speed for our session, which can create noticeable delays in operation, especially in graphical applications.
disable wallpaper:i:1 — we disable the desktop image.
username:s:myuserlogin — we specify the user's login, as a significant portion of our users do not know their login.
domain:s:mydomain — we specify the domain or computer name.
But if we want to make the connection procedure easier for ourselves, we can also use PowerShell — StartRDP.ps1.
Test-NetConnection -ComputerName my_router.sn.mynetname.net -Port 19000
Test-NetConnection -ComputerName my_router.sn.mynetname.net -Port 16000
mstsc /v:my_router.sn.mynetname.net:33890A bit about the RDP client in Windows: Microsoft has come a long way in optimizing the protocol, both its server and client sides, implementing many useful features — such as working with hardware 3D graphics, optimizing screen resolution for your monitor, multi-screen setups, and more. However, everything is implemented in a backward-compatible mode, meaning that if the client is Windows 7 and the remote PC is Windows 10, RDP will work using protocol version 7.0. Fortunately, it is possible to upgrade RDP versions to newer ones — for example, you can upgrade the protocol from 7.0 (Windows 7) to 8.1. Therefore, for the convenience of clients, it is important to maximize the versions of the server side, as well as provide links for updating to newer versions of the RDP protocol clients.
As a result, we have a simple and relatively secure technology for remote connection to a workstation or terminal server. But for a more secure connection, our Port Knocking method can be complicated for attacks by several orders of magnitude by adding additional ports for verification — using the same logic, you can add ports 3, 4, 5, 6, and in such cases, direct intrusion into your network will be nearly impossible.
.
Source: habr.com
