τεχνοσοφια

Here’s a list of all the free software I’m running on my Windows XP workstation, or least the subset that I deem noteworthy. Rather than annotate the list, which would be far too helpful, I will merely provide links.

Foundstone Vision 1.0 (system util)
Process Explorer 9.25 (system util)
Microsoft PowerToys XP (OS pimpage)
Notepad++ 3.3 (text editor)
Cygwin 1.5.18-1 (X server / *nix tools)
FileZilla 2.2.17 (FTP client)
FileZilla Server 0.9.11b (FTP server)
Mozilla Firefox 1.5 (WWW browser)
Mozilla Thunderbird 1.5 (mail client)
Trillian Basic 3.1 (multi-network chat client)
PuTTY 0.57 (SSH client)
Semagic 1.5.5.6U (blog client)
iTunes 6.0.1.3 (aural pleasure)

P.S. I do have Firefox installed but I don’t use it. Internet Explorer is the only way to browse.

What do you do when you’ve got a server to install and you’re too lazy to burn a CD with all the latest service packs and hotfixes? I suppose you could attach the server to the Internet and head over to Microsoft’s Windows Update website. But then you would be committing a grievous faux pas among systems people. Only connect an unpatched machine to the Internet if you wish to have it 0wN3d in seconds flat.

One strategy for patching up your server is to install on your local network a server running Windows Software Update Services, and configure IPSec on your new server to allow connections only to the local WSUS server. For the sake of convenience, I have also allowed outgoing DNS requests. If you know the IP address of the WSUS server, these are probably unnecessary, but otherwise shouldn’t pose much of a risk.

Here’s an IPSec script, which I called newServerLockdown.txt, that you may use to accomplish this task.

# IPSec Configurations to Lock Down a New Server
#
# WHAT IS THE POINT?
# Well, good security practices dictate keeping servers off the network until they have been
# fully patched, which is rarely achievable from system CDs. Thus, before a server is conn-
# ected to the network, we use IPSec to restrict traffic such that no host may initiate an
# incoming connection, and only the local Windows Software Update Server may be contacted.
#
# HOW TO RUN THIS SCRIPT
# netsh -f newServerLockdown.txt
#
# THEN WHAT?
# Once the server is fully patched, hotfixed, and service packed, these IPSec rules may be
# blown away with two commands, or so it is believed by the author:
# netsh ipsec dynamic delete all
# netsh ipsec static delete all
#
# NOTE
# Originally tested on November 23, 2005
# Inspiration from:
# http://www.unisanet.unisa.edu.au/staff/davidgardiner/ipsec/netsh-script.txt
# and
# http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=41571

############# Set IPSec mode to dynamic ############

pushd ipsec dynamic

# Dump packet drops to the Event Log
set config property=ipsecdiagnostics value=7

# Allow as few exemptions as possible
set config property=ipsecexempt value=3

# During boot sequence, allow only stateful connections initiated by the server
set config property=bootmode value=stateful

popd

############ Set IPSec mode back to dynamic ############

pushd ipsec static
set store location=local

# Clean the slate and remember these settings
# DO NOT DO THIS IF YOU DO NOT WANT YOUR STATIC CONFIGS ZAPPED!
delete all

# Create a new policy
add policy name="Restrict to WSUS" activatedefaultrule=NO

# Create actions for filters to use
add filteraction name="PERMIT" action=PERMIT
add filteraction name="BLOCK" action=BLOCK

# Default policy - block everything
add filterlist name="All incoming traffic"
add filter filterlist="All incoming traffic" protocol=ANY srcaddr=ANY dstaddr=ANY description="Block all incoming traffic"
add rule name="Default incoming block" policy="Restrict to WSUS" filterlist="All incoming traffic" filteraction="BLOCK"

# Allow outgoing DNS requests
add filterlist name="DNS resolution"
add filter filterlist="DNS resolution" protocol=TCP srcaddr=ME srcport=0 dstaddr=DNS dstport=53 mirrored=YES
add filter filterlist="DNS resolution" protocol=UDP srcaddr=ME srcport=0 dstaddr=DNS dstport=53 mirrored=YES
add rule name="Allow DNS resolution" policy="Restrict to WSUS" filterlist="DNS resolution" filteraction="PERMIT"

# Allow outgoing HTTP connections to WSUS
add filterlist name="HTTP" description="Allow outbound HTTP connections to WSUS"
add filter filterlist="HTTP" protocol=TCP srcaddr=ME srcport=0 dstaddr=YOUR.WSUS.HOST.NAME dstport=80 mirrored=YES
add filter filterlist="HTTP" protocol=TCP srcaddr=ME srcport=0 dstaddr=YOUR.WSUS.HOST.NAME dstport=443 mirrored=YES
add rule name="Allow HTTP traffic to WSUS" policy="Restrict to WSUS" filterlist="HTTP" filteraction="PERMIT"

# Activate policy
set policy name="Restrict to WSUS" assign=YES

popd
exit

One of the first tasks that has been assigned to me is the installation and configuration of a pair of network load-balanced Terminal Servers running Windows Server 2003. The department has already cobbled together documentation on how to build servers within the locally developed and recognized best practices, and I am loath to deviate from these in my first month of employment. I got up to the point of joining the first TS node (”TS1″) to the AD domain pretty smoothly. When I attempted to move TS1 out of its workgroup and into the domain, I was prompted for a password (which is a good thing, and is to be expected). When I attempted to use my domain admin account in the form “DOMAIN\account”, I was rudely greeted with an “unknown username or bad password” error. When I tried to provide my credentials in the form of “account@domain.university.edu”, I received the unfamiliar “Element not found” message.

After poking around for a few hours, I came up with the following fix:

1. The administrative account being used to join the server to the domain must be allowed logon rights on the server being added. This must be done on the domain controller.
2. NTLM v2 authentication must be enabled in the Local Security Policy of the new server. Go to Administrative Tools / Local Security Policy and navigate to Security Settings / Local Policies / Security Options. In the right-hand pane, locate the policy named Network security : LAN Manager authentication level and change its value to Send NTLMv2 response only. (Note: I am unsure what other repercussions might be caused by changing this setting.)

These steps might not work for you, as they were likely necessary in my environment due to networking and domain configuration particulars.

Here’s a simple one. But first, some backstory.

I’d been using the tcsh shell on my Linux servers for years, but I am now working in an environment where bash is the preferred shell. I view it as an opportunity to poke around in a shell that’s relatively unfamiliar to me as a dyed-in-the-wool tcsh user[1]. I’d also been used to connecting to my Linux servers with the SSH Communications Security version of the Secure Shell client. Unfortunately, the newest version of this client, which is available to me, will not connect to our department’s boxes due to the version (or configuration) of the OpenSSH libraries that have been installed. I’m new to this job, so I’m accepting this more or less on the authority of comments made by coworkers; I haven’t independently verified this, though I can confirm that I can’t connect with the SSH client. I switched to the PuTTY SSH client, since it’s free, widely used, and supported by my colleagues. And, oh yeah, it connects to our Linux boxes.

One of the neat features of the SSH Communications Security client is the ability map keys to certain other keys. For instance, I used to map the Home and End keys to <Ctrl-a> and <Ctrl-e> for ease of navigation on the command-line; sometimes the command strings I have to type are, to put it technically, really frickin’ long and it’s nice to be able to make edits to the beginning and end of these command strings without holding down the left and right arrow keys for an hour. PuTTY does not have a key-mapping feature, so I was wondering how to get my Home and End keys to do more than just generate the ‘~’ character. (Though such a feature is on PuTTY’s wish-list.)

It turns out there’s a simple fix: just set the environment variable, TERM, to the value of “linux” in ~/.bash_profile (or .bashrc).

export TERM=linux

should do the trick. Make sure you logout and login again, or just source your bash config files. It’s possible that other TERM values do the trick as well, but “linux” has worked for me. Prior to that, the TERM variable was set to the value “xterm”.

For some more shell-based key mapping geared toward the Backspace and Delete keys, see the Consistent BackSpace and Delete Configuration page.

1. While I’ve used tcsh as my default shell for years, I do acknowledge the argument that csh programming is considered harmful. I use the Bourne shell and Perl for scripting, though primarily the latter.