Answer the question
In order to leave comments, you need to log in
Hide the RDP server... but how?
Actually, paranoia knows no limits... I fell under the paranoia of my colleague... He wants the following:
There is an office in which there are bare monoblocks and a modem. Accordingly, we need to have nothing on the office computers themselves, from the word at all, except for the RDP client that is in any Windows.
Somewhere in a certain data center in the Russian Federation, a terminal server is standing and spinning, to which workers connect.
Of course, they connect via IP, which belongs to the data center, that is, the IP is scorched, where the server is - it's not a problem to find out.
A friend wants to implement the following:
Rent a server in Europe, which will act as a kind of proxy or something like that for an RDP server that is in Russia. That is, as I understand it, we need to somehow forward ports on a server in Europe so that when connecting to it, the RDP connection goes directly to the Russian Federation.
That is, in this way we hide the real server.
Is it even possible? How? 3proxy? ProxyMapper? Socks4/5???
PS: I found a secure RDP service on Google, they offer to rent such a service. But we don’t want to rent, we need our own pancake ...
Answer the question
In order to leave comments, you need to log in
What's so difficult? Enough 2 rules in iptables. Of course, there is a minus - the client IP will not be visible, everyone will sit on the terminal server from the IP VPS server (WAN_IP).
RDP_IP='192.43.76.78'
WAN_IP='54.23.45.43'
WAN_INTERFACE=ens33
SRC_PORT_FORWARD=3389
DST_PORT_FORWARD=3389
echo 1 > /proc/sys/net/ipv4/ip_forward
sudo iptables -t nat -A PREROUTING -i $WAN_INTERFACE -p tcp --dport $SRC_PORT_FORWARD -j DNAT --to-destination $RDP_IP
sudo iptables -t nat -A POSTROUTING -d $RDP_IP -p tcp --dport $DST_PORT_FORWARD -j SNAT --to-source $WAN_IP
Forward VPN to your terminal server - and go ...
You can forward the VPN on a server in Europe to the terminal server, and throw RDP out
I have been doing similar work for accounting departments for 5 years already and I can say that you are doing a lot of things wrong
. any obep or department can easily bend your hoster. The server must be in Europe. Moreover, some types of hetzners also cooperate with ours and can simply close your access.
2) most likely your server is sitting on the Internet, which is called a bare op (the rdp port is open). And even if you change the rdp port, it will still be scanned by bots and you will constantly be guessing passwords. As a temporary solution, you can get a permanent ip from the provider at work and configure the server firewall to connect via rdp from this ip. But this will cancel the ability to connect from different places... Best practices is to use variant machines on the server that will sit behind a virtual router. Next, an encrypted tunnel is made between the router in your office and the virtual router, and people connect via RDP already inside this tunnel at gray ip addresses. I prefer to use mikrotik equipment. Virtual machines are also convenient in that they can be easily backed up, as well as transferred to other servers in case of expansion.
Rent a server in Europe, which will act as a kind of proxy or something like that for an RDP server that is in Russia.
Server in Europe - an intermediate VPN server, to which the VPN from the office will go (openvpn\wiregurd from each monoblock or a general VPN at the exit from the office), from which the VPN will go to the final server. No NAT, only routes, and the RDP connection will have a server address from the gray subnet.
And yes - there will be jamming.
Before you stir it up, you need to clearly understand who is hiding what and why, what you or your friend will get from this, etc.
Please note that with the help of a thermo-rectal decoder, all passwords are easily opened, a server in Europe is also searched, and the Terminal in Russia, and even the Kennedy assassin is located.
As an option. Restrict entry by IP, raise pritunl. Add its IP to the allowed ones, through pritunl we make routes to the rdp server.
At the exit, we can control vpn users through the web interface (if we quit, we delete it and it will not connect anymore). Access to the server is only through a vpn gateway, the Internet through a regular gateway.
There is no way to get to the server except with a connected vpn, since there is a restriction on ip, if there is an ad, you can purchase the enterprise version of pritunl and synchronize with ad. No need to manually create users in pritunl.
I think that if you are paranoid, then to the fullest, or rather, you need to protect yourself in all areas of the connection. But also that the decision was not too tricky and without glitches.
I suggest the following:
on a rented server, we put mikrotik chr, or a simple linux and port knocking, we configure it there by analogy with the article about port knocking , then we forward it preferably a non-standard rdp port to ip in your data center, and in the network settings in the data center we specify to accept connections only from the ip of the leased server to the port we have chosen and forward it to our RDP server.
the final schema looks like this:
A client from the office knocks on port knocking on the rented server, a certain port for RDP is opened for him, then this port is forwarded to your server in the data center, a connection is established, the client works quietly, and the port on the rented server is closed (except for established connections).
if they want, they will find it and vpn will not help
, it is most logical to connect via rdp to a server physically located in another country
You can get free vps from google. On firstvds 55 rubles a month, 1 core, 512 mb
Step by step.
1. Any vps in Europe. For the test, free Google or Amazon.
2. We put any Linux.
3. We put pritunl on it. Select a subnet for vpn. Important: by default, pritunl wraps all traffic from clients into itself. Therefore, in pritunl we change the mask 0.0.0.0 to the mask of our invented subnet. Allow connections between clients.
4. We make an account for the server in the tunnel. We nail its IP with nails (for example, 10.0.10.250) We take the .ovpn config
5. We put the OpenVPN client on the server as a service. Uploading the config. We edit the service to run the default config.
6. We start on the server ovpn. We check that after the reboot, the ovpn works.
7. We create clients in the tunnel and send them configs. And we inform you that the rdp server is now 10.0.10.250
Well, like a cherry in a data center where the server is denied all incoming. Well, almost everything.
Just a task, like a horse in a vacuum.
After setting up port forwarding on an intermediate server, I highly recommend installing the ipban program on the rdp server. By doing this, you will save yourself from brute force attacks (enumeration of logins and passwords), of which, believe me, there will be a lot (but this only works for servers starting from 2012).
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question