RE: RE: break in? - terminal services on alternate port

From: Logan Greenlee (lgreenlee_at_digitalresultsgroup.com)
Date: 11/15/05

  • Next message: Barrie Dempster: "RE: What server hardening are you doing these days?"
    Date: Tue, 15 Nov 2005 00:33:53 -0500
    To: "maralisa" <maralisa@villatiburon.com>, <techlists@comcast.net>
    
    

    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.

    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).

    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.

    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.

    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 ;-)

    Logan

    -----Original Message-----
    From: maralisa [mailto:maralisa@villatiburon.com]
    Sent: Saturday, November 12, 2005 12:00 PM
    To: focus-ms@securityfocus.com; techlists@comcast.net
    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:techlists@comcast.net]
    Sent: Fri 11/11/2005 9:18 PM
    To: focus-ms@securityfocus.com
    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

    ------------------------------------------------------------------------

    ---
    ------------------------------------------------------------------------
    ---
    ------------------------------------------------------------------------
    ---
    ------------------------------------------------------------------------
    ---
    ---------------------------------------------------------------------------
    ---------------------------------------------------------------------------
    

  • Next message: Barrie Dempster: "RE: What server hardening are you doing these days?"

    Relevant Pages

    • Re: RE: break in? - terminal services on alternate port
      ... Not changing the default RDP port immediately identifies a potential ... "Network vigilance" would be based on defining what services are needed, ... Terminal services has an excellent ... >serviced machine should be provided via a VPN connection. ...
      (Focus-Microsoft)
    • Re: Remote desktop connection error
      ... Does the computer have more than one network adapter?? ... msconfig to troubleshoot.Check that the Terminal Services service and the ... > firewall or the app that uses/opens the port. ...
      (microsoft.public.windowsxp.network_web)
    • RE: break in? - terminal services on alternate port
      ... 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. ... terminal server accessible to the worls for literally year now with no ... I had configured the firewall to only all TS ...
      (Focus-Microsoft)
    • Re: Restricting access to a web server by IP
      ... > remote control clients (terminal services, telnet, etc), etc - we remotely ... > for all ports except port 80 ideally. ... > The argue for is that it secures us from hackers who specially target the ...
      (comp.security.misc)
    • Re: Restricting access to a web server by IP
      ... > remote control clients (terminal services, telnet, etc), etc - we remotely ... > for all ports except port 80 ideally. ... > The argue for is that it secures us from hackers who specially target the ...
      (comp.security.firewalls)