Due to the covid-19 virus pandemic and general quarantine in many countries, the only way for many companies to continue working is remote access to workplaces via the Internet. There are many relatively safe methods for remote work - but given the scale of the problem, a simple method for any user to remotely connect to the office is needed and without the need for additional settings, explanations, tedious consultations and long instructions. This method is beloved by many admins RDP (Remote Desktop Protocol). Connecting directly to the workplace via RDP ideally solves our problem, except for one big fly in the ointment - keeping the RDP port open for the Internet is very unsafe. Therefore, below I propose a simple but reliable method of protection.
Since I often come across small organizations where Mikrotik devices are used as Internet access, it will be shown below how to implement this on Mikrotik, but the Port Knocking protection method is easily implemented on other higher-class devices with similar input router settings and firewall.
Briefly about Port Knocking. The ideal external protection of a network connected to the Internet is when all resources and ports are closed from the outside by a firewall. And although a router with such a configured firewall does not react in any way to packets coming from outside, it listens to them. Therefore, you can configure the router so that when a certain (code) sequence of network packets is received on different ports, it (the router) for the IP from where the packets came from cuts off access to certain resources (ports, protocols, etc.).
Now to business. I will not do a detailed description of the firewall settings on Mikrotik - the Internet is full of high-quality sources for this. Ideally, the firewall blocks all incoming packets, but
/ip firewall filter
add action=accept chain=input comment="established and related accept" connection-state=established,relatedAllows incoming traffic from established, related connections.
Now we set up 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=3389Now in more detail:
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=RemoteRulesprohibit incoming packets from IP addresses that are blacklisted during port scanning;
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 ip to the list of hosts that made the correct first knock on the correct port (19000);
The next four rules are:
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 if such attempts are detected, blacklist their ip for 60 minutes, during which the first two rules will not give such hosts the opportunity to knock on the correct ports;
Next 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=RemoteRulesputs ip in the allowed list for 1 minute (enough to establish a connection), since the second correct knock was made on the desired port (16000);
Next command:
move [/ip firewall filter find comment=RemoteRules] 1moves our rules up the firewall processing chain, since most likely we will already have different deny rules configured that will prevent our newly created ones from working. 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. Therefore, we look at our settings - where you can move it and indicate the desired number.
Next setting:
/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=3389forwards an arbitrarily selected port 33890 to the usual 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 non-standard (and different) external ports. Naturally, the ip of internal resources must be either static or fixed on the DHCP server.
Now our Mikrotik is configured and we need a simple procedure for the user 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">
Π½Π°ΠΆΠΌΠΈΡΠ΅ ΠΎΠ±Π½ΠΎΠ²ΠΈΡΡ ΡΡΡΠ°Π½ΠΈΡΡ Π΄Π»Ρ ΠΏΠΎΠ²ΡΠΎΡΠ½ΠΎΠ³ΠΎ Π·Π°Ρ
ΠΎΠ΄Π° ΠΏΠΎ RDP
<img src="http://my_router.sn.mynetname.net:16000/2.jpg">it contains two links to imaginary pictures that are located at my_router.sn.mynetname.net - we take this address from the Mikrotik DDNS system after enabling it in our Mikrotik: go to the IP-> Cloud menu - check the DDNS Enabled checkbox, click Apply and copy the dns name of our router. But this is only necessary when the external ip of the router is dynamic or a configuration with several Internet providers is used.
The port in the first link: 19000 corresponds to the first port on which you need to knock, in the second, respectively, to the second. Between the links there is a short instruction that shows what to do if suddenly our connection is interrupted due to short network problems - we refresh the page, the RDP port reopens for us for 1 minute and our session is restored. Also, the text between the img tags forms a micro-delay for the browser, which reduces the likelihood of the first packet being delivered to the second port (16000) - so far there have been no such cases in two weeks of use (30 people).
Next comes the 1.rdp file, which we can configure one for all or separately for each user (I did this - it's easier to spend an extra 15 minutes than a few hours consulting those who could not 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:mydomainof the interesting settings here is use multimon: i: 1 - this includes the use of multiple monitors - some need this, but they themselves will not think of turning it on.
connection type: i: 6 and networkautodetect: i: 0 - since the majority of the Internet is above 10 Mbps, then turn on connection type 6 (local network 10 Mbps and above) and turn off networkautodetect, because if by default (auto), then even a rare small network latency automatically sets our session to a slow speed for a long time, which can create noticeable delays in work, especially in graphics programs.
disable wallpaper: i: 1 - disable the desktop picture
username:s:myuserlogin - we specify the user login, since a significant part of our users do not know their login
domain:s:mydomain - specify the domain or computer name
But if we want to simplify our task of creating a connection procedure, then 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:33890Also a little about the RDP client in Windows: MS has come a long way in optimizing the protocol and its server and client parts, has implemented many useful features - such as working with hardware 3D, optimizing the screen resolution for your monitor, multiscreen, and so on. But of course, everything is implemented in backward compatibility mode, and if the client is Windows 7, and the remote PC is Windows 10, then RDP will work using protocol version 7.0. But the benefit is that you can update RDP versions to more recent versions - for example, you can upgrade the protocol version from 7.0 (Windows 7) to 8.1. Therefore, for the convenience of clients, it is necessary to increase the versions of the server part as much as possible, as well as drop links to upgrade to new versions of RDP protocol clients.
As a result, we have a simple and relatively secure technology for remote connection to a working PC or terminal server. But for a more secure connection, our Port Knocking method can be made more difficult to attack by several orders of magnitude, by adding ports to check - you can add 3,4,5,6 ... a port according to the same logic, and in this case a direct intrusion into your network will be almost impossible .
.
Source: habr.com