The place for nonprofits, charities, and libraries

Discuss remote administration for Windows Server

  • Unix/Linux is traditionally intollerant of hard (power outage) shutdowns

    It just sounded so good you had to repeat it. You're leaving out anything technical that might explain this contention, so I'm looking forward to seeing from you something beyond anecdotal evidence. Something as critical as filesystem integrity needs a proper elucidation - point me to a supporting whitepaper if you haven't the time to explain.

    It happens because *nix caches the disk "directory" in ram and doesn't necessarily write it back to disk except during the shut down process.

    The caching depends on the file system settings. Are you using IDE drives? Are you using soft updates? Are you mounting with sync? Depending on the settings and the hardware, you might have no guarantee of consistency - writes can be done in a completely arbitrary way.

    We have a support request in to both RH and HP on ways to improve this. If you are interested I'll let you know what they suggest (and if it works) when we get it all sorted out.

    Yes please.

    Battery backed controller would be my suggestion, if the expense makes sense for the potential loss of data/time.
  • Hi Obscurant,

    I'm not sure whether you are adressing these questions to myself or Dave - My original comment was a truism known by by most 'nix admins made to highlight the need for another remote admin tool in our arsenal (power-out management cards)... but maybe this is not the thread for a detailed dissection of the 'nix file system.

    If you are interested in starting a new thread on this I will gladly post more info on the problem, and look forward to your suggestions on ways to harden the OS for fluctuating power scenarios.

  • My original comment was a truism known by by most 'nix admins

    You have no interest in providing technical details? I'd take a simpler and generic explanation to avoiding power off. I would suspect that most hardware failures occur when power is either applied or removed - lessening the number of reboots will increase hardware longevity.

    "Don't ever turn the computer off by just pressing the power switch!"

    Perhaps if you didn't listen to whomever told you that you might have tested how the box handled power loss. Power loss isn't anything to fear under unix, or no more so than under other OSes, and is something that should be tested.

  • Another aspect of allowing remote administration is that of intrusion prevention (touched on above with the discussion on admin accounts). Opening a network for remote administration also potentially opens the network for intrusion attacks.

    Intrusion prevention is a management protocol combining surveillance, analysis and control. There are software/hardware tools available to help with each of the three functions, (and tools combining all of these functions), however most important is to develop business processes supportive of a secure computing environment.

    Watch your network traffic (surveilance) for anything untoward and immediately act on any suspicions. This may involve installing a packet sniffer on ports opened for remote access.

    Analyse suspect traffic (maybe all traffic depending on how you do this) and immediately isolate anything suspicious. It's much easier to reconnect a legitimate user accidentally "thrown-off" for suspicious activity, than it is to recover from an illegal network hack attack.

    Implement controls (some discussed above) to prevent unauthorised access and data egress from your network.

    Lastly, don't be afraid to contact and work with law enforcement authorities when an attack or breach occurs. A lot of orgs are reluctant to contact Police over a network breach thinking the org itself may be held responsible if their security is not 'iron-clad'... This is untrue... Penalties exist for people who try to attack your network, not for people trying to prevent network attacks. We will only ever reduce the occurance of these attacks if we provide detailed information to Police and other authorities so they can act against the attackers.

    Rgds, Don
  • This is a very interesting topic for a security or *nix thread, but to wheel things around to the "remote administration for Windows Server" side again, I was wondering if anyone here has any experience with using SSL to remotely connect to admin tools?

    One idea that had hit me back when I worked on Citrix servers frequently was to put up a secure NFuse server that would connect back to a MetaFrame box running common Windows admin tools as published apps. I never implemented it though, due to cost issues. I'd love to hear if anyone has done anything similar, and how it worked (I'm particularly intested because of the increasing use of SSL VPNs).
  • Obs, a couple of years ago while I was in college, we had to demonstrate the ability to install different Server Operating systems. We had identical hardware in our lab for each machine the OS was installed on. The power went out when someone knocked down a utility pole and class was cancelled. When I turned the 2 servers back on a couple of days later, the Windows 2000 server came back up with no problems, but the Linux box did not. The server was corrupt and I had to rebuild as Don has stated. I am far from a "nix admin," but its fairly obvious that the issue isn't hardware, but software.

    Gary Network/Systems Admin Berlin, NH
    Host Non-profit Tech Careers, Security Forums
    Co-Host Networks, Hardware, & Telecommunications Forum

  • On the subject of security, does anyone know how secure/well encrypted the Remote Desktop Protocol is? I'm not guarding military secrets here, but I also know you shouldn't use telnet on the internet if your sending anything important. Judging by this discussion, it is not anything to worry about, but I was wondering what thoughts or information people had.
  • RDP itself isn't very secure... moreso than telnet, less than ssh (although I may regret saying that since SSH does have holes in it's implementation). I personally like ICA over SSL - it's keyboard/video/mouse information only, compressed into the ultra-thin ICA protocol, and wrapped in a cozy SSL blanket for security. Of course, encrypting the file system on the remote and local hosts and securing the connection with an IPSec VPN as well would make things even more secure, but that might be going overboard. :)

    On the serious side, RDP's main flaw is that there is *no* authentication in the protocol prior to reaching the Windows Domain (or server), which means that your first authentication is right into the heart of your network. In most cases this is a serious risk, as many times RDP is enabled by opening a gaping hole in the firewall at port 3399. My comment above on the IPSec VPN is actually semi-serious... preferably an RDP session should only be allowable once an IPSec (or SSL) VPN that auths to a RADIUS or other external authentication implementation has been established.
  • Agree with Joe above (RDP over RSA Secure ID here to wrap RDP in an SSL session and enforce 2-tier authentication).

    If SSL is beyond your means you can minimize the risks outlined by Joe by using a few tricks...

    Restrict the IP's allowed through your firewall on port 3399 (if you are able to allocate and enforce IP's on your remote connecting workstations)

    Setup a 'locked' Win2K3 box in the DMZ that only allows traffic on 3399 and use it as an RDP gateway (this server becomes your RDP authentication server through which you access other servers by running RDP within RDP (a terminal session within a terminal session - RDP is much better at this than VNC or ICA).

    Neither of these methods offer the type of security you would get from SSL, however they do make it tougher for someone to get through your firewall to your server farm (where there are probably a bunch of ports open for different purposes).
  • When I turned the 2 servers back on a couple of days later, the Windows 2000 server came back up with no problems, but the Linux box did not. The server was corrupt and I had to rebuild as Don has stated. I am far from a "nix admin," but its fairly obvious that the issue isn't hardware, but software.

    You're not given much of a choice in filesystem settings under windows, but under linux you are. A novice might not know that having just one large partition as ext2 is a bad idea. For filesystems you have choices, you can choose one that does not do journaling and run it without sync (speedy and unsafe), or use sync (slow and safe), or use a journaling one (not so speedy and safe).

    If you had used a journaling filesystem, you would have just lost whatever metadata didn't get through the transaction.

    With just ext2 you are going through the equivalent of scandisk to check the integrity of your filesystem - chances are it will be fine, but there's always the odd occurrence.
  • RDP to RDP through a pinhole in the DMZ... man that's just wrong on some primeval level. ;)

    I gotta give it a try!
  • No No No!

    This information is NOT correct. You can not hide the admin account from even the most basic hacker.


    You should also realize EVERY Microsoft password can be found in less than 2 seconds thanks to Microsoft’s Jet Database engine unless more than 14 characters are used.

    We are no longer using passwords, we are using passphrases.
  • Hi Dougg,

    I'm not sure who you are replying to, but if its the observation by Eoconlon (and Zac's reply) I think you might be missing the context in which this suggestion was made - it IS good advice for a number of reasons:

    1/ As noted by Zac this is an effective method of making script 'Administrator' attacks less effective

    2/ Not every hack attempt is done by a black-hat wiz-kid. Most unauthorised network accesses occur behind the firewall, and are done by staff or others who might be simply experimenting to see if they can 'get in' as Administrator. Rarely do these people have the skills to crack a password "in less than two seconds", and renaming or removing the administrator-named account certainly reduces the likelihood of success.

    3/ There is no single aspect to total Systems security - everything you do to make it harder to hack your network adds to the whole and reduces the likelihood of a hacker bothering to spend energy breaking tiered security.

    I agree that simply renaming/removing the Administrator account is not a solution in and of itself, but it is one component of a tiered security solution; one more step a hacker has to break to enter your system; one more chance you have of identifying the hacker through logs and other trace-back mechanisms.

    Using a passphrase is excellent advice - until someone sees you type it in (or you write it down on a piece of paper somewhere). Like everything to do with computer security, passphrases are just one tool in the arsenal designed to make your security harder to break.

  • Old thread, new article... don't forget that you can always push Remote Desktop through an SSH tunnel as well. Configure a dumbed down Linux box with public key authentication only and port forward TCP 3389 (UDP not necessary) from your DMZ to your internal network and you have a reasonably secure and encrypted route to your Windows server.
  • Why would you want to add the overhead of SSH when Remote Desktop includes its own encryption?


    Zac Mutrux
    President, Sarai LLC