Contact

admin

About Me · Send mail to the author(s) E-mail · Twitter

At GROSSWEBER we practice what we preach. We offer trainings for modern software technologies like Behavior Driven Development, Clean Code and Git. Our staff is fluent in a variety of languages, including English.

Feed Icon

Tags

Open Source Projects

Archives

Blogs of friends

Now playing [?]

Error retrieving information from external service.
Audioscrobbler/Last.fm

ClustrMap

Page 1 of 2 in the Windows category Next Page

ChkDskAll ‒ ChkDsk For All Drives

Posted in .NET | Tools and Software | Windows at Saturday, February 14, 2009 4:41 PM W. Europe Standard Time

The Windows file systems (NTFS and FAT) are able to automatically detect if they are broken. You can even specify when that automatic check should be performed. But sometimes you would want to force a file system check, for example when Windows suddenly behaves strangely for no obvious reason. (For example last year, the day before I went on a month-long vacation, Vista suddenly refused to boot.)

In order to schedule a file system check for the next reboot you will have to

  1. Open an elevated command prompt or log in as an administrator,
  2. Run chkdsk <Drive>: /f,
  3. Rinse and repeat for all installed drives.

This task isn’t easy for inexperienced users, especially given that they might not know about the chkdsk command line tool in the first place. They could use the UI, but would have to repeat the process for each and every drive nonetheless.

Chkdsk UI

To make this task easier, I wrote a little .NET application that automates scheduling file system check for all drives at the next boot. Just double-click ChkDskAll.exe, enter administrative credentials and wait for the goodness to happen.

ChkDskAll In Action

If a drive has already been scheduled for scanning, it won’t be scheduled a second time. To exclude drives from being included in the scan, have a look at ChkdskAll.exe.config. For example, TrueCrypt drives should be excluded if you do not mount them as fixed drives.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <appSettings>
        <!-- The list of excluded drives, e. g. "CDE". -->
        <add key="ExcludeDrives" value="YZ"/>
    </appSettings>
</configuration>

General Considerations For Securing Windows Servers On The Internet (And Anywhere Else)

Posted in IIS | Networking | PowerShell | Security | SQL Server | Windows at Friday, February 08, 2008 5:04 PM W. Europe Standard Time

By now there are a couple of Windows Servers that I actively manage, or, in the case of projects, I touched while moving the project forward. Most of these servers have an Internet connection. Since I've been asked how to make servers more secure and manageable, here are a couple of management rules I applied. Consider it a checklist.

  • Use a firewall and configure it accordingly.
  • Enable automatic Windows Updates and upgrade to Microsoft Update to receive updates of other Microsoft products like SQL Server.

Okay, the two above should have been obvious.

  • Keep the machine clean.
    Don't install any unnecessary software and don't leave any temporary files on the server. I've seen certificate requests lingering on drive C: and "test" folder remnants. A clean system might reveal hacker activity early in case they leave unfamiliar files behind.
  • Leverage the principle of least privilege.
    All users and service accounts should only have the minimum rights they need. Configure the file system such that system services can only access the files and folders they are in charge of. Typical example: Use a dedicated service account for SQL Server. (Setting this up on SQL 2005 is even more simple.)
  • Rename the Administrator account.
    Rename the Administrator account and make it match your preferred user naming scheme (i. e. agross). You might apply this to your whole organization if you use Active Directory. This is another hurdle to guess the Administrator account from a list of user accounts and works good with account lockout enabled (see below).
  • Create a new "Administrator" account
    and give it a very strong throw-away password. I typically use two or three concatenated GUIDs that I immediately forget. Disallow this user to change his password, remove all group memberships and disable the account.
  • Audit the hell out of the machine.
    Windows uses the Security event log to record security-related events. Configure auditing using secpol.msc and enable success and failure logging at least for
    • Account logon events,
    • Logon events and
    • Policy change.
    The last option is for tracking changes to the policy you just set.
  • Enable complexity criteria for passwords and account lockout.
    To be found in the same MMC snap-in as above. For account lockout I often go with the default values of 5 attempts and 30 minutes of threshold and duration.
  • Deactivate file sharing/Microsoft Networking on the WAN connection.
    Because it's most likely unneeded.
  • Secure RDP sessions using a certificate.
    Torsten has a nice write-up on how to leverage SSL to secure the RDP handshaking/authentication phase to overcome man-in-the-middle and ARP spoofing attacks. His article is available in German only so here's two-sentence recap: On the server's RDP security tab, enable SSL and choose the same certificate you use for HTTPS encryption. On the client side, enable server authentication.
  • Extra: Allow RDP sessions only from white-listed workstations.
    For a server that was hacked a while ago using an ARP spoofing attack (see bullet above) I wrote a Powershell script forces RDP session to originate from a list of known workstations. Each RDP user can have multiple allowed workstations. If a logon attempt occurs from another machine that RDP session is killed immediately.
    #
    # Alert.ps1
    #
    # Logon script for users with known RDP client names.
    #
    
    # Array of users with known workstations.
    $userWorkstations = @{
    	"user1" = @("VALIDCOMPUTERNAME1", "VALIDCOMPUTERNAME2")
    	"user2" = @("VALIDCOMPUTERNAME3")
    	}
    
    # Logoff executable.
    $logoffCommand = $Env:SystemRoot + "\system32\logoff.exe"
    
    # Trim the user name.
    $currentUser = $Env:UserName.Trim()
    
    # Cancel if a user that's not contained in $userWorkstations logs on.
    if ($userWorkstations.Keys -inotcontains $currentUser)
    {
    	return
    }
    
    # Send alert e-mail and log off if the user logs on from an unknown workstation.
    if ($userWorkstations[$currentUser] -inotcontains $Env:ClientName.Trim())
    {
    	$subject = $("Unknown RDP client '{0}' for user '{1}'" -f $Env:ClientName.Trim(), $currentUser)
    
    	$message = New-Object System.Net.Mail.MailMessage
    	$message.From = "alerts@example.com"
    	$message.To.Add("admin1@example.com")
    	$message.To.Add("admin2@example.com")
    
    	$message.IsBodyHtml = $false
    	$message.Priority = [System.Net.Mail.MailPriority]::High
    	$message.Subject = $subject
    	$message.Body = $subject
    
    	$smtp = New-Object System.Net.Mail.SmtpClient
    	$smtp.Host = "localhost"
    	$smtp.Send($message)
    
    	# Force logoff.
    	&$logoffCommand
    }
    Set the script as a logon script for your users using the Alert.cmd helper script below.
    rem Alert.cmd - runs the Alert.ps1 Powershell script.
    @powershell.exe -noprofile -command .\Alert.ps1
  • Enable SQL Server integrated authentication.
    I don't see a need for SQL Server Authentication in most scenarios, especially if you're running/hosting .NET applications. However, in some projects I've worked on there seems to be a tendency towards SQL Server Authentication for no special reason.
  • Configure IIS log detail and directories.
    I tend to enable full IIS logs, that is, all information regarding a request should be logged. Also, I like my logs residing in "speaking" folders, so instead of %windir%\system32\LogFiles\W3SVC<Some number> they should be placed in %windir%\system32\LogFiles\IIS <Site name>\W3SVC<Some number>. This makes it easy to find the logs you're interested in.
  • Use SSH to connect remotely.
    There's a little free SSH server out there that should fit most user's needs. Besides a secure shell environment freeSSHd offers SFTP and port tunneling capabilities to tunnel insecure protocols. Authentication works natively against Windows accounts.
  • Deploy a server monitoring tool.
    I like to use the free MRTG tool, of course any other tool allowing you quickly view any uncommon activity to will do.
  • Use a dedicated management network interface, if possible.
    You should configure strict firewall rules for that interface. Allow access only from a known management subnet.

What rules do you apply to make your servers more secure and manageable?

Now Playing [?]: MorcheebaDive DeepEnjoy the ride (feat. Judy Tzuke)

Minimal Debugging Tools for Windows Installation for Symbol Server Support

Posted in Debugging | Windows at Monday, October 09, 2006 6:11 PM W. Europe Daylight Time

Dr. WatsonScott Hanselman recently wrote about the Debugging Tools for Windows and their usefulness in conjunction with Process Explorer. Today I needed the Debugging Tools on a server where an ASP.NET application was running with 100% load on one CPU core with lots of context switches.

When you open Process Explorer's Threads tab for a certain process, Process Explorer will approximate function names and display offsets if the Debugging Tools are not installed. When Process Explorer is configured to use the Debugging Tools and Microsoft Symbol Servers it will display actual function names instead of obscure offsets.

Offsets in Process Explorer Function Names in Process Explorer
Offsets Function Names

Being the kind of guy I am, I opted for a minimal installation of the Debugging Tools, that is just the "Tools" and "Helpful Tools" branches displayed in the installer. This also installs dbghelp.dll which is needed for Symbol Server support. After setting the NT symbol path environment variable and pointing Process Explorer to %ProgramFiles%\Debugging Tools for Windows\dbghelp.dll everything should have worked. So I opened Process Explorer, displayed the properties of some process, opened the Threads tabs …and saw function offsets.

What happened? After some Filemon investigation I found that the symbol path wasn't touched by Process Explorer, no PDBs were downloaded and thus just offsets could be displayed. I got the idea that some Debugging Tools component was missing and installed the full package. Lo and behold, the function names were shown!

After playing around I found that the only component you need install to get Symbol Server support is the "Debuggers" branch. This will also get you WinDbg, a basic yet powerful debugger for Windows with plugin support. Mental note: Try WinDbg.

Aren't these the tools from the basement, Torsten? :-)

Caps Lock

Posted in Windows at Tuesday, August 22, 2006 4:53 PM W. Europe Daylight Time

Caps Lock RemovedThere was an article in a newsletter regarding the Caps Lock key. This key, used to make all letters UPPERCASE, has been bugging me for years. Caps Lock has been used in ancient programming languages like FORTRAN (the name may indicate that uppercase letters were of interest). On internet forums and in chats uppercase statements are considered as "shouting out loud", but some people don't know this little detail. Offending more experienced users is easy.

Do you really need the caps lock key? How often do you type whole sentences in upper case?

To me, the key has been useless the last years, if not disturbing. I've been hitting caps lock accidentally countless times. After realizing that I've written a whole sentence in upper case, I needed to delete the words I've just written and start over again.

For the reasons above the CAPSoff campaign proposes a new keyboard layout where the caps lock key is moved to the top right where the Print Screen, Scroll Lock and Pause keys are located and thereby letting space to other more important keys (more suggestions over here). I'm skeptical that the industry will make that move soon, but you can use your customer voice to finally make it happen by signing the petition.

To relieve you from the Caps Lock pain today, you can physically remove the key (see the image above) but this leaves and ugly crater on the keyboard. A better approach is deactivating the key: Windows uses a keyboard map that translates the keyboard scancodes to internal windows keys (virtual keys). This level of indirection allows applications to respond to the virtual keys instead of dealing with proprietary scancodes issued by keyboards with function keys for e-mail, web search and the like.

To modify the keyboard map I use a tool called KeyTweak. KeyTweak virtually allows you to change the meaning of every key of your keyboard, so be cautious! Also, the mappings apply to all users of the machine.

Besides disabling Caps Lock I've also mapped the Scroll Lock key to the built-in Windows calculator, an applet I did use before.

Vista Cursors

Posted in Design | Windows at Thursday, June 29, 2006 2:01 AM W. Europe Daylight Time

Another post from the Vista customization category. As I read here someone has extracted the Vista mouse cursors from Build 5465 in order to make them available on Windows XP today. The decision to switch to the new cursors after sticking to the 3D cursor set for the last six years (whew) was conceivably an easy one. The direct download is over here.

Aero Cursors

I've used these two animated "busy" cursors in my old cursor set. If you like them, here's the download.

Animated Box Cursor Animated Metallic Cursor

Update: Marci has created two orange-themed cursor sets based upon the Aero cursors above.

Aero Cursors (Orange) Aero Cursors (Orange Sparkle)

Now playing: Lynyrd Skynyrd - Sweet home Alabama

Page 1 of 2 in the Windows category Next Page