RDP issues
-
try making the NAT rule TCP+UDP
RDP requires both.
Is there an associated rule in the Firewall WAN?
This. Just having the port forward defined won't actually allow traffic to pass. You need a complimentary firewall rule on WAN for that.
-
It has been my understanding that UDP is only required for using some of the MS RDP features. But the basic remote desktop connection should work fine with only TCP. It's been awhile since I've messed with that so I could just be making stuff up in my sleep.
-
newer versions of rdp can use UDP.. if your going to forward it then forward both.
Sure looks like you have a link firewall rule there, it should be created by default. My guess is the software firewall running on the host is blocking RDP from connection other than its local network - which would be the default windows firewall setting.
And will state again opening up rdp to the public internet is a VERY bad idea..
Here look at these hits to 3389 on mine just today and today not even over yet.. So if that was open they are going to try brute forcing login, etc. Use VPN to access stuff on your network!!
-
Agreed - opening up RDP from the outside to an internal host is asking for trouble. If you really, really must do it at least set either one or a subset of allowed source addresses. At least that way you prevent anyone from anywhere on the internet have a crack at your server.
-
I added the rule to open port 3389 for RDP traffic but I can't get to my workstation externally.
Create a NAT rule as image shows.
Note : I use port 4321 to enter, not the standard port (this is for my head : I tend to forget 'Microsoft' port numbers ;))
Note : A firewall rule will be created automatically.
Note : The "PowerEdge" label is nothiong else as "192.168.1.4" the IP of my "2008 R2".This should be a clic-and-it-works issue. If still problems, its probably the server that does not accepts connection to rdp, or from LAN, or it doesn't trusts it own LAN, or ….
Try also to connect to this server from a PC on the LAN (same IP range).
-
Worth also pointing out, the workstation/server thats receiving the rdp connection can have its default port number (3389) changed in the registry which can be an issue when taking over from other support companies, but this allows a route from the wan through to the lan for each workstation/server expecting rdp connections and you can have as many port forwards as your like then.
All the user has to do in the windows rdp client is put www.mydomain.co.uk:7777 or www.mydomain.co.uk:8888 where 7777 routes to say the server withe pfsense having port 7777 open and the corresponding allow rules, and 8888 routes to the bosses desktop with port 8888 open on pfsense with the corresponding allow rules, as another example of how to skin the cat, although vpn is still preferred route.
As I've had upto 6 monitors before on my desktop, you can rdp into at least 6 different machines quickly and easily connecting and controlling them, with all of the other perks rdp brings when set up properly.
A quick google will show you the reg setting to change on the machine thats receiving the rdp client connection.
-
Why not just forward port 7777 to HostA:3389 and port 8888 to HostB:3389?
-
Just to show theres more than one way to skin the cat as one of a few other reasons I can think of.
-
there is good and bad ways to skin the cat sure.. Why not just use the different ports on the outside to forward to the standard 3389 would be better way to skin that cat.
But to be honest that doesn't solve the base problem - security through obscurity is not security. Does not matter what port rdp is listening on.. Opening that to the public net is not really a secure option if you ask me.
-
there is good and bad ways to skin the cat sure.. Why not just use the different ports on the outside to forward to the standard 3389 would be better way to skin that cat.
But to be honest that doesn't solve the base problem - security through obscurity is not security. Does not matter what port rdp is listening on.. Opening that to the public net is not really a secure option if you ask me.
I agree
On the point of having the RDP on different ports within a lan setting, how do you prove it wasnt the admin logging in and rdp'ing onto a machine when the audits show it was the admin username and password used and no cctv exists in the office?
-
what would a service listening on a different port prove in that scenario?
-
what would a service listening on a different port prove in that scenario?
Hidden knowledge like a password can also apply to default ports.
As alot of hacking is done from within a company, if you have staff, permies or temps, with some knowledge of systems who like to poke around the network, then changing the default ports for RDP is one way to trip them up, especially if the RDP activity is never done in the main offices.
As admins get called into the main office to do all sorts of things on someone's computers like installing software which cant be pushed to the workstation, or other problems which involves an administrator password to make a change, its easier for passwords to be observed even when requested to look the other way plus theres other measures like the Infrared camera addon or using a special app on someone's phone to detect the sound and vibrations of keys pressed.
http://www.intego.com/mac-security-blog/iphone-case-atm-pins/
http://www.wired.com/2011/10/iphone-keylogger-spying/The 2nd link is a more common hack than you think considering the administrator username is on display which is enough to train some apps to work out the password, made easier if a problem keeps coming up which requires the admin to keep logging into a workstation and thus helps the app improve the probability of guessing the password. An even simpler method is just to have the phone on a stand to one side of the keyboard, appearing to be in sleep mode when its actually recording the keyboard.
Whilst you can audit software installed & other changes, and have trackers to record computer activity, if it shows the admin is logged in, then the admin must of done it, especially if they were on a coffee break or out to lunch or having a smoke. So if RDP activity is always done in the server room/IT dept, thats a bit of hidden knowledge which can be used to trip some internal hackers up, as they would potentially try a default port like 3389 instead of another one, likewise bots that port scan would need to investigate each open port on a network to figure out whats really behind it assuming it doesnt get picked up by network monitoring.
Just like no AV can find 100% of viruses as you can see here https://www.shadowserver.org/wiki/pmwiki.php/AV/VirusDailyStats, where theres a will theres a way. All AV software has a fundamental design flaw which is frequently exploited.
-
Why would users machines even be able to access something they don't have access to via RDP??
Can't "hack" into something with the username/password if they don't have access to even get there.. If rdp is used for admin, then only admin machines should have access. If admin walked away from his desk and did not lock his machine, or guess they know what the admins password is they could just unlock it.
Pretty sure his rdp session WITH odd ball port is saved on his past connections, etc..
So let me guess you think hiding your SSIDs is good security practice too?
-
I think we need to agree to disagree then.
-
Clearly I have no problems in disagreeing with your statements ;)
Changing your standard ports for services to non standard is simple attempt at obscurity, and as we all know security through obscurity is not security.. This is security 101
How does NIST state it – oh yeah "System security should not depend on the secrecy of the implementation or its components."
If your doing it to say keep your logs a bit cleaner from the bots hitting your port on the outside ok.. But it is not a valid security measure. And would seem completely pointless on the inside.. And could even lead to problems.. Hey can you get into that server in that remote DC, billy quit and we have the username and passwords but RDP is not coming up ;)
-
It could be argued that the single, correct AES256 key in use is simply obscure in a sea of 2^256 possibilities but I digress…
-
hehe –- that is a valid point Derelict, valid point ;)
-
Clearly I have no problems in disagreeing with your statements ;)
Changing your standard ports for services to non standard is simple attempt at obscurity, and as we all know security through obscurity is not security.. This is security 101
How does NIST state it – oh yeah "System security should not depend on the secrecy of the implementation or its components."
What gives you the impression it was an attempt at security through obscurity?
-
You are literally obscuring the standard port number for common services by moving it to a different location. It will trick a lot of dumb scans that happen constantly on the Internet but it won't stop a scanner dedicated to finding remote access servers (RDP, SSH, VNC etc) no matter which port they're listening on. It doesn't take a lot of time to parallel-scan huge swathes of port space per IP address when you have many computers at your command.
-
So let me guess you think hiding your SSIDs is good security practice too?
… think hiding your SSIDs is good
securitypractice? Yes.
