netnerds.net

I'm currently playing with Windows Server 2008 Core and I'm really at a loss trying to figure out why Microsoft seems to go out of its way not to adopt SSH. SSH seems like such an easy and straightforward answer to remote administration. Unix administrators have long used SSH but Windows administrators are given WinRS, a command line tool that requires that you run it each time you need to execute a command on a remote system. So instead of arriving at a remote prompt as you would with SSH and simply typing "ipconfig", you must type "winrs -r:myserver ipconfig"

winrs -r:myserver every time!

I'm hoping things have changed in Windows 2008, but so far, I can't find any way for WinRS to be interactive. A blog post on TechNet back in 2006 suggests that interactivity is going to be a feature at some point:

Currently any commands you execute can't be interactive or prompt for input. WinRS just executes what you specify and returns the results.

Unfortunately, it's nearly a year and a half later and no progress seems obvious. I hope I'm wrong and someone can show me the light or, even better, perhaps we'll see PowerShell+SSH hit the final version of Windows 2008. Many admins already have an SSH client as part of their toolkit and sure, WinRS runs over HTTP(S) and opening just one port is nice but the same goes for SSH. Port 22 or 80, I don't really care. WinRS seems to have its value, but not as a replacement for SSH. Give me SSH or give me both.

I found a pretty good Wordpress Security Whitepaper over at BlogSecurity.net. I followed most of the techniques, especially those that concerned protecting the wp-admin directory, since that's what got me hacked last time.

Also, today, while installing 8 GB of RAM into my virtual server and after more than a decade of taking computers apart, I finally figured out an easy way to keep track of those tiny computer screws. I took a Post-it, turned it upside down and used the glue strip to keep the screws all in one place. Granted I try to stay away from hardware because I tend to catch it on fire, but I can't believe how long it took for me to figure that out.

Hai. I got hacked. brb.

If you've ever dealt with NTFS permissions in VBScript, you will no doubt appreciate just how easy PowerShell now makes it to manage access control lists. Basic examples in PowerShell books and around the 'net look something like this:

In the example above, user "IUSR_CRACKLIN" is given Modify access to the Test directory. Running the code above will not produce any errors but upon checking permission via the GUI, it seems as though the user was added, but no permissions were set.

I thought that perhaps this was an issue with Vista and I tried it on Windows Server 2003. And that's when I noticed that the directory had been given "Special Permissions." When I checked the Advanced permissions, I could see that Modify access had been assigned, but only to "This Folder." Other folders that had the checkboxes checked listed "This Folder, subfolders and files"

Since I wanted the Test directory permissions to match the others, I searched the Google to see which flags would give me "This Folder, subfolders and files." I found Damir Dobric's blog post titled "Directory Security and Access Rules which sported a handy reference table flags that must be set to achieve various scenarios.

So it setting the following should give me what I need:
InheritanceFlags.ContainerInherit, InheritanceFlags.ObjectInherit and PropagationFlags.None.

I then checked the permissions and voila:

Imagine that.. PowerShell can set any number of permissions with about 6 lines of code while VBScript requires over 36 lines JUST to set the constants needed for managing permissions. I'm so excited thinking about the possibilities: PowerShell + Windows Core + SSH is going to be awesome.

When creating a new Active Directory user from the command line in PowerShell, you will likely find yourself using Read-Hosts's asSecureString switch when entering the password.

Next, you'll probably look around the Internets for a few hours or so trying to figure out how to change the password of the newly created user. You will soon discover that the user creation process in PowerShell 1.0 isn't very straightfoward and it even requires a specific order for proper account creation. First, you create the account, then you set some basic properties, next you call SetInfo(), and finally you invoke setPassword using the follwing syntax:

Now you may find yourself with the following exception: Exception calling "Invoke" with "2" argument(s): "Exception has been thrown by the target of an invocation." Originally, this post mentioned using toString() to address the problem but PowerShell team member Lee Holmes wrote to let me know that the password was changed literally to System.Security.SecureString. He also said that "there is no really easy way to convert a secure string to plain text - on purpose. Since a SecureString is supposed to prevent plain text from littering your computer's memory, converting it to plain text defeats the purpose."

My primary reason for using asSecureString is to encode the string into asterisks when typing it at the prompt. So Lee gave me two ways to convert the password to be used while invoking SetPassword. Note that unless you are using a secure LDAP channel, the password will be sent over the network in clear text.

Or, alternatively:

If you continue to see this exception, check to make sure that the password you entered meets your domain's password complexity requirements.

I work for a large company that uses Postini for Enterprise spam filtering and it does a fantastic job. It's actually famous for being one of the very few spam filter capable of blocking UCEs from the "Cajun Spam King" (No, Scelson doesn't sound very Cajun to me...). And in researching for this article, I even found out that Postini will provide spam and anti-virus filtering for Gmail.

To use Postini, you pay them a good amount of money, change your company's MX record to point to their servers and then they filter your email, removing nearly all the spam. From there, the Postini servers forward the scrubbed emails to your own mail gateway, presumably a sendmail or Exchange machine. They may also keep archives of it if you pay them extra. The whole process looks something like the visual seen below:

Last week, I realized that Google Apps can actually do something similar, free of charge. The service, formerly called Google Apps For Your Domain, offers an unlimited amount of email accounts for your domain, each with 2GB of space each, mobile access (including Blackberry access) all for free with the Standard account. The Premier Edition ($50/year per mailbox) offers 10GB of disk space, API stuff, guaranteed uptime, phone support, and e-mail migration tools coming soon.

So I saw that Google was offering e-mail hosting, but didn't really know how it could apply to me. I like having control over my mail - I've been hosting my own for about a decade and it never really crossed my mind to point my MX records to anywhere but my own machines. Exchange's NS-IMF (Not-so-Intelligent Mail Filtering) spam filtering is really weak and inaccurate, however, and overwhelming false positives were becoming a pain. After thinking it out, I realized that I could outsource my spam filtering to Google/Gmail Apps by taking an approach similar to the way that Postini sets up their own customers.

I signed up netnerds.net for an Application account on Google Apps and started the process. I deleted my MX record and in its place, added the 7 or so MX records that Google gave me. Now my records look something like this:

netnerds.net MX preference = 5, mail exchanger = alt2.aspmx.l.google.com
netnerds.net MX preference = 10, mail exchanger = aspmx2.googlemail.com
netnerds.net MX preference = 10, mail exchanger = aspmx3.googlemail.com
netnerds.net MX preference = 10, mail exchanger = aspmx4.googlemail.com
netnerds.net MX preference = 10, mail exchanger = aspmx5.googlemail.com
netnerds.net MX preference = 1, mail exchanger = aspmx.l.google.com
netnerds.net MX preference = 5, mail exchanger = alt1.aspmx.l.google.com

Then I logged in to Google Apps e-Mail (which I've addressed as "Gmail For Your Domain" in the illustration below) and created the two whole user accounts/mailboxes that are valid on netnerds.net. Next, I went and added a new A record for a supersecret subdomain and (one by one), told Gmail to forward all the email to user@supersecrethost.netnerds.net. I then setup Exchange's recipient policy to accept e-mails for supersecrethost.netnerds.net and then ensured each of the two user accounts and their aliases were set as valid recipients. I also disabled IMF at the host level (SMTP -> Default SMTP -> Properties -> General -> Advanced -> Edit -> Uncheck Apply Intellingent Mail Filter) and instructed my other user to disable it at the Outlook level (Actions -> Junk E-mail -> Junk E-mail Options -> Poke around). So here's sorta what it looks like:

Using Google's Admin interface, I also added a subdomain http://gmail.netnerds.net that automatically directs to the Gmail Apps e-mail login page. Now we can use one of three interfaces to check our mail: Outlook Web Access, Exchange/Outlook, or Google. I decided to use Office 2007 as my primary e-mail client but I login to gmail.netnerds.net every couple days to check my spam box for false positives.

    

Because of the manual creation of the email accounts and the subsequent forwarding, this doesn't scale without a huge time investment. Using the Google API's that come with the Premier Edition, however, it would probably be easy to setup something similar on a mass scale. I also considered wildcards forwarding at Google's end (which is supported) then filtering again at my end using Exchange Sinks but my setup is too small to justiy the kind of time I'd spend doing that.

Two final notes: first, by selecting the forwarding option "Forward then Delete" and thus preventing Google Apps from being a Store and Forward, the 2GB storage limit wouldn't pose any sort of restriction for those needing super large mailboxes. The drawback, of course, is if you choose that option, you can no longer use the Gmail interface to check your mail. Second, Google Apps does provide support for additional domains -- I'm currently using it for RealCajunRecipes.com.

Just as I was heading off to bed, I decided to check the TrueCrypt website to see if they added Vista support. I've checked it a few times since March 19th, so I don't know why I didn't notice but version 4.3 now supports Vista. For a moment there, I thought Vista support was going to be vaporwear - they've been promising it since February, 2006.

I donated to the TrueCrypt Foundation back in January because it's some of the greatest software I've used in a long time. The software provides a sense of security -- knowing that my documents/pictures/music are protected in the event that my laptop were to be stolen. To me, knowing someone could be looking at my documents or pictures is an even scarier thought than even having my laptop stolen. So after installing Vista, I was really bummed when I read that the current version would not work.

If you are looking to encrypt an entire disk or portions of a disk, you just may love TrueCrypt too. It works on both Windows and Linux, it's free and it has a ton of functions. ScriptingLife.com has some great suggestions on running a drive with Pstart and mobile versions of applications. DailyCupOfTech.com has good info and quick tutorials on getting started.

Today, as I received an email from CERT, I was reminded of the day in 2004 when it was announced that CERT merged with the US Government. I wondered what would change and even considered the possibility that red tape could turn the highly-respected CERT into something that people just didn't respect anymore.

By the next time a CERT Advsory arrived in my mailbox, the subject had changed from "CERT Advisory" to "US-CERT Technical Cyber Security Alert." And there it was: the presence of the US Government. Who, besides them, still uses "cyber"? And then, not only is it a Cyber Security Alert, it's a Technical Cyber Security Alert as though there's such a thing as Non-technical Cyber Security. I sometimes wonder if the change made the hardcore people at CERT go ":("

A friend asked me what port AIM used and I guessed something along the lines of 5190. I wanted to check to make sure and, after issuing the command netstat -n from the comamnd prompt, I couldn't find any port even close to that in use. But I did see 443 in use.. SSL, eh? I was connected to the IP 205.188.10.248 at port 443. Using Sam Spade, I did an IP Block check and sure enough it was America Online.

UPDATE: Originally, I wrote the following:

This means that all communication between AOL's server and their AIM 6 chat client is very well encrypted -- great news for users who wish to use AIM in an environment where the latest (and most aggressive) version of Websense is running. Even though all of my outbound connections at work are encrypted by default, it's nice knowing that if I even accidently sign on with an insecure connection, my work-related, code-laden chats can't be sniffed (so suck it, Websense!).

After my post, however, two friends suggested that it's possible for AOL to just use port 443, not for SSL, but because it's open on nearlly all firewalls. I then decided to do additional research and after being told that Ethereal and Packetyzer were out-of-style, I downloaded Wireshark, sniffed my packets and found that only the initial login is encrypted. The rest of everything, nick lists, conversations, etc are all sent in clear-text So now back to square one.. make sure your connection is fully encrypted or you use an HTTPS AIM proxy if you want to chat it up on networks that employ Websense and other hardcore tracking software.

Recently, a user trying to login to OWA encountered the following error:

HTTP 403.1 Forbidden: Execute Access Forbidden
You have attempted to execute a CGI, ISAPI, or other executable program from a directory that does not allow programs to be executed.

Another network administrator noticed that the URL was strange too. The user had been directed to:

https://owa.mydomain.com /iisadmpwd/aexp.htr?https:// owa.mydomain.com/exchange/USA/

A quick Googling showed mentions of an expired password but the user was able to login to the domain so we were a bit baffled. As it turns out, we're in the middle of a migration and the user's account on the old domain which still hosts OWA/Exchange was expired but his password on the new domain account was still valid. The user was also not prompted to change his password in OWA because we did not enable that feature. So if you run into something similar, ensure that the user's account does not have "User Must Change Password At Next Logon" checked.