I'm trying to access an internal xRDP terminal server on my LAN from the WAN. I try specifying the use of a non-standard port, but when i try to connect i can't. Looking through my firewall logs it seems that whenever i try to connect over the internet to my server, regardless of whether i specify a port or not, windows RDP keeps trying to use port 443. I can't DNAT port 443 to the server because that port is used by a separate server for file storage and works fine. Anybody have experience with this? Anyone know how to get this to use the port i'm specifying instead of being imbecilic?
Update: I switched it back to the standard port, and i'm able to connect. The thing is i don't want to leave my RDP server open to the world on the standard port, i mine as well unzip my pants and put my schlong in a hotdog bun for the seagulls at the beach. Any time i try a non-standard port though, RDP goes back to stupid mode and starts knocking on port 443 again, no matter what port i specify. What am i missing?
From penetration standpoint. It doesn't matter what service you got where its easy to sniff it out. Unless you filter your ports. Having ports open is not a problem if you can trust the service that is answering the call.
I understand that any open port can be sniffed out, but a random script kiddy in china is less likely to enumerate every non-standard port at a given address than he is to just scan the low hanging fruit (IE, 22 23 80 443 3389 etc) to scan more hosts quickly. It's just a bit of added security through obfuscation that i'd like to have. I just don't understand why my Windows RDP client insists on trying to use 443 instead of the port i'm manually specifying.
did you change your firewall settings too bytheway?
Yes each time i have tried to assign a non-standard port i have changed the firewall rules direct all traffic destined for that port to my RDP virtual server. Regardless the RDP session never hits that rule because it knocks on port 443, not the port i specify. Changing the rule order in my firewall (I'm running IPFire btw.) does nothing to remedy this.
I don't know the specifics on how to do this, but I found a starting point for you that might be useful. The link talks about using iptables to route from xxx.xxx.xxx.xxx:xx to yyy.yyy.yyy.yyy:yy
You must be interpreting the logs wrong. Port 443 is used for SSL encryption. Do not attempt to change the port from one of the well known ports. I.E anything at and below 1000. Instead leave the default ports that RDP uses alone. Ports 3389 and 3390.
If you have a home network that requires a HTTPS connection then you are blocking RDP in your firewall.
You might not wanna have DNS open to the internet though unless you want your ISP to turn off your internet ;)
1 Like
if you want to be a bit safer or avoid port forwarding something like your server you could use a reverse connection where the server would connect to you rather than you connecting to it this way no ports are opened on the server but you need to have a port open on the receiving machine
I don't think RDP supports that.
I know you can do it with rdp not sure with rdp but you can try this :
https://blog.netspi.com/how-to-access-rdp-over-a-reverse-ssh-tunnel/
or use openvpn as a reverse connection and that will give you full access to the servers network
I don't know how i could be interpreting the logs wrong. It has the source IP address/ Destination IP address, then source port (a random port somewhere over 50000) and destination port, which is always 443 unless i leave the RDP client trying to connect to 3389. If i try specifying 3391, it starts knocking on 443 again.
Are you using RD Gateway? It uses 443.
RDP uses ports 3389 & 3390.
do you have another Linux machine to try as a client? (rdesktop, remmina, vinagre.... others) this would at least allow you to verify there isn't a problem with xRDP (port setting should be trivial)
In the Advanced tab on MSTSC, disable stuff there maybe?
Also, SSH tunneling can be good, I don't know if xRDP will be encrypting anything for you (and this could be an issue for MSTSC too)