On Tue, 2005-11-15 at 00:33 -0500, Logan Greenlee wrote: > Hi, > > Some thoughts on moving ports. > > Moving the TS port is for the most part unnecessary, silly and not > "smart". In fact, moving your TS port around might even make you machine > less accessible from some networks depending on the vigilance of network > administrators there by reducing the utility of the service. > > By moving the port you gain some degree of security through obscurity. > Though, no real tangible gains have been made on the safety of the > system. This is in my opinion no security at all - moving the port does > not mitigate a human threat, and it does not mitigate threats from > somewhat intelligent worms. Only in the case of a self propagating > "dumb" worm or program that specifically targets 3389 (and no others) > will one find themselves in trouble. Terminal services has an excellent > (as far as MS is concerned) track record in regards to security and > while this is no degree of insurance it does lead me to believe that it > can be trusted.
This argument, whilst common, isn't necessarily correct - what you should be advising him is that whilst 'security through obscurity' as a *sole* security measure is a bad idea, obscurity actually plays (and historically has played) a very important part in security not just of IT systems. As a few examples, renaming the administrator account, non-obvious forward or reverse DNS, whois sanitisation, and actually even encryption are all security measures which are commonly accepted and have a greater or lesser amount of 'obscurity' involved. The important thing is that you don't rely on them - something which applies just as much to relying on any one vendor's shiny, snakeoil security panacea as it does to policies and reconfigurations like this. Actually, shifting services off standard points has several security benefits, when (as you rightly point out) it isn't more of an inconvenience than it's worth because of locked down firewalls - however, in my experience, comparatively few default-deny firewalls allow outbound RDP because it's a fairly uncommon protocol to use over the internet - as you yourself put it, the "'smart' solution [is provided by] a VPN connection". This aside, any user or group of users routinely accessing a TS box over the internet is likely to either be a support organisation or vendor, or a user. In the former case, I would expect a vendor supporting me to be able to be flexible with regard to how they connected to my systems (I would expect an IT company or company providing IT services to be able to add/change firewall rules with a minimum of hassle). In the latter, any firewall which drops RDP is more likely to drop or break IPSec and/or pptp traffic anyway. The first of those two benefits to me is exemplified by remote access in the linux/unix world - the number of automated password-guessing attempts levied against ssh (port 22) in recent months/years are so voluminous that it's worth moving to a different port (I recommend 443 for maximum firewall penetration - harder to proxy! ;) in order to simplify logs - when your ssh instance is on port 443, 1234, 4321, etc, you /know/ that any failure audits are unlikely to be from a casual/automated attack. The second is that it makes network reconnaissance much harder - portscanning for an RDP port running way up in the 50/60,000s is much, much noisier than running a single probe against port 3389. Every extra packet an attacker wastes trying to find ways into your network is an extra way to detect him, and any competant IDS from the last 4 years will detect a port scan of the type necessary to find a relocated RDP. > The "smart" solution here would involved isolating access to Terminal > Services to authorized users of your network. Access to the terminal > serviced machine should be provided via a VPN connection. If you want to > be really paranoid about it - the VPN connection should not be provided > by your DC (tempting on smaller networks) but instead by another network > device or server. You should also make sure that the device > authenticates with a higher level of credentials than a preshared key > (IPSec comes to mind). I agree - ultimately a VPN provides better security than RDP over the internet. > In my experience TS can stand on it's own. It's a hardy service that has > managed to prove itself through so many catastrophes with other windows > services. Moving the port only has the capacity to restrict your ability > to use the service as intended and does not truly provide any sort of > security. It also adds to the complexity of the network. See above > Changing the administrative login is a good idea though - as it is > nearly impossible to guess in a reasonable amount of time both a user > and a pass for the machine in question. Oh, no! That's "security through obscurity!" :-P > Make sure that your lockout policy is defined such that there is a long > pause between incorrect logins and a lockout for an extended period of > time after no more than 5 failed authentication attempts. Also, if you > do use terminal services you should enable both successful and failed > authentication events. Periodically reviewing the logs is always a good > idea and not just when you think you've been compromised ;-) More sound advice! Just my 2c - kind regards! - James. > Logan > > -----Original Message----- > From: maralisa [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 12, 2005 12:00 PM > To: [email protected]; [EMAIL PROTECTED] > Subject: RE: break in? - terminal services on alternate port > > Paul, > > The smartest and best thing to do if you must open the terminal services > port to the world is to change the port that terminal services runs on. > I do this, and it never gets attacked. You should also change the name > of your administrator account. This is best practice. I've had my > terminal server accessible to the worls for literally year now with no > problems. > > Read this and give it a shot. > http://support.microsoft.com/default.aspx?scid=kb;en-us;q187623 When > you connect using the terminal services client, you put a : and the port > number after the server name, like this, server:6432 > > -steve > > ________________________________ > > From: Paul Greene [mailto:[EMAIL PROTECTED] > Sent: Fri 11/11/2005 9:18 PM > To: [email protected] > Subject: break in? > > > > Hello, > > I have a Win2K domain controller running on my home network that had > Terminal Services enabled through my firewall so that I could access the > box from my office at work. I had configured the firewall to only all TS > access from the IP block of the company where I work. (the firewall is > an openbsd box that also acts as the gateway to my ISP) > > Well, I went out on a road trip and allowed TS access from "any" so that > I could access the DC from my hotel room, and then forgot to restrict > access again when finished. Ooops!! Big mistake. > > I was looking through Event viewer troubleshooting another issue a few > days ago, then noticed a whole bunch of failed administrator logins in > the security logs. Oh, crap what happened now. I ran Symantec AV, Spybot > search and destroy, and Adware and none of them found anything. I ran MS > Update service and realized I was out of date on several patches (going > back about 2 months worth of patches). > > Another ominous sign was that the DC had two printers configured that I > use at the office, but I have never configured a printer for this DC. I > deleted the printers, and they came right back. > > I wanted to see what was going on with the DC, so rather than wipe it > clean and re-install, I locked the firewall down real tight and started > logging everything to see if the DC was going to try to "phone home" > somewhere. I'm only allowing outgoing http access to the MS Update site, > and outgoing DNS queries (UDP port 53) because this is also the dns > server for the network. > > More ominous signs. The server was trying a few times a day to make > connection attempts to some outbound websites and ftp sites. Some of the > IP addresses were located in Rumania and Poland. All connection attempts > were getting blocked and logged. > > Based on these symptoms, can anyone tell me what happened? In > particular, for educations sake, can anyone tell what the specific > exploit that was used in this case, and possibly a reference where I can > go analyze further what happened? > > I don't have anything especially valuable on this server, so I won't > lose much by wiping it and starting over again. I think I've also locked > it down enough now with firewall ACL's that some turkey isn't going to > be stealing my bandwidth for some nefarious purpose either. > > Thanks in advance, > > Paul Greene > > ------------------------------------------------------------------------ > --- > ------------------------------------------------------------------------ > --- > > > > ------------------------------------------------------------------------ > --- > ------------------------------------------------------------------------ > --- > > > --------------------------------------------------------------------------- > --------------------------------------------------------------------------- > --------------------------------------------------------------------------- ---------------------------------------------------------------------------
