NOOOO!!!!

Found this article today on Bruce Schneier's blog and wanted to share it:
-----------------------------------------------------------------------------

ireland.com - Breaking News - My goodness, thief drives off with 450 kegs

http://www.ireland.com/newspaper/breaking/2007/1129/breaking41.htm

-----------------------------------------------------------------------------
Sounds easy doesn't it? I wonder how many other breweries have such lax security standards...

To my dismay...

None of the spare Linksys units I have at home are supported with OpenWRT. After a bit of browsing I found the units I have are really REALLY old and the CPU is an ARM S3C4510 (manufactured by Samsung). Oh well, guess I'll have to by some WRT54G's! Hope the wife understands... :)

Time off

Well, after some time off (got married, had honeymoon) I'm slowly getting back into the swing of things. Work has been busy too, and end of year is typically crazy. This year is no different.

I hope to start hacking away at some old Linksys devices I found lying around my apartment. OpenWRT is a great choice for loading up on embedded devices. The guys from the PaulDotCom podcast recently wrote a book regarding hacking such devices and I plan to pick up a copy and get moving.

No postings of late

Obviously there's been no postings from me in a while...my firm has just opened a new office in the UK so I've been there a couple of times, plus I'm getting married in a few weeks so its been a rather crazy time of late. I'm going to try making some short posts more frequently, and hopefully I'll get back on track with my vision of how my blog should be.

Social Networking sites

I wanted to make a quick Blog posting based on something I took notice of recently. I read an interesting post from Martin McKeay on the Network Security Blog a few weeks back and wanted to offer my two cents. I agree wholeheartedly with Martin's posting. For a while now I've had friends use the words MySpace and Facebook as nouns and verbs. Just as Google has been used in the last 7 or 8 years, phrases like "I have her Facebook", or "He MySpace'd me yesterday" have become the norm. Let's face it, email as a social communication medium is dieing (if not already dead) when speaking in terms of the youth of today.

While these social networking sites are incredibly popular and can serve as a valuable resource to people, if you choose to create an account for one of these sites always take care when signing up and posting information about yourself online. Posting to publicly accessible websites means exactly that; its public.

There are also inevitable technical problems with these systems. Recently Facebook's source code was leaked. Leaked source code means bad guys find vulnerabilities with the website and exploit them to steal enormous amounts of information. Your personal information.

So I encourage anyone who wishes to sign up for these social networking sites to err on the side of caution, and thoroughly query every step you take.

SMB shares and DNS CNAME aliases

Every corporate Active Directory (or dare I say NT...) network, even most home networks, have Microsoft Windows SMB shares lurking somewhere. SMB (Server Message Block), re branded as CIFS (Common Internet File System), is the application level protocol used primarily with file shares, but also used for print shares.

Recently I was required to move an SMB share to another server, but needed to keep the original server name the same. Seems pretty straightforward, right?

1. Create and permission the share on the new server
2. Migrate the data
3. Shutdown the old server
4. Remove the DNS host record for the old server
5. Remove (or disable) the old server object from Active Directory
7. Create a DNS CNAME alias for the old server to point to the new server
8. Test the share

After performing these steps I tried connecting to the share, and received the following obscure message:

System error 52 has occurred
A duplicate name exists on the network

Weird. I triple checked DNS records, looked for IP conflicts, file share permissions, but everything checked out. What next? Time to ask Google...

After about 15 minutes or so of research, the issue was apparent. Windows Server 2003 Service Pack 1 removed the ability to access SMB/CIFS shares via DNS CNAME aliases. By adding this 'feature', the LanmanServer service does not answer requests other then those to its NetBIOS name. So any SMB requests to its CNAME alias will be ignored and the user will receive the error message above. Microsoft have, however, made available a workaround to enable SMB/CIFS access via CNAME aliases. The following registry key must be added:

HKLM\SYSTEM\CurrentControlSet
\Services\LanmanServer\Parameters

Value name: DisableStrictNameChecking
Data type: REG_DWORD
Base: Decimal
Value data: 1

Once I applied this registry key I was able to successfully attach to the share and access the data.

I've not really found out why Microsoft introduced this with SP1 as I can't find any obvious security implications with it. If anyone has an ideas on this then please comment on this post or email me directly. Good practice, however, is to make sure your share permissions are tight. By default the Everyone group has Read access to shares as they are created, so I recommend removing this and explicitly adding the group(s) who will be accessing the share.

For more information on this, read the following Microsoft knowledgebase article:

http://support.microsoft.com/kb/281308

***NOTE: I accept no responsibility for your systems upon making any changes ***

Virtual machines in WSUS

With it being patch Tuesday, I thought I'd post about a problem we dealt with recently regarding virtual machines and WSUS.

Microsoft Windows Server Updates Service (WSUS) is a Microsoft patch management tool which allows SysAdmin's to distribute security updates to Windows servers, clients, and various Microsoft applications. Our shop uses the web based 2.0 version as we've not yet scheduled the testing of its successor, 3.0, which apparently has a richer administrative interface (it's MMC based).

Recently we've been pushing to migrate Windows based applications running on legacy hardware into virtual machines, using VMware as the hosting environment. These servers, of course, need to be monitored for Microsoft updates. VMware allows the use of Templates to deploy Windows servers in a very efficient manner. A Template is essentially an image of a server you have customized to your specifications (patch level, service packs, security policies, etc) from which you can deploy multiple servers as needed (licensing permitting, of course). The deployed servers are uniquely configured using Sysprep. This eliminates the need to perform server installations from scratch. I'll get into that in a later posting.

I came across an issue recently when deploying Windows servers from one of our Templates. When a new virtual server gets deployed it is added to a WSUS management group and subsequently inherits any patch approvals. However, what I noticed was that each time a server was deployed, the server which was deployed before it vanished from WSUS! Initially I thought maybe something had gone awry when the servers were joined to the domain, however having checked Active Directory all the new server deployments seemed fine. Each new server had an associated object in the domain tree and was assuming a DHCP address before being assigned a static address. What I discovered was that the Windows Update client (which comes by default with a Windows Server installation) obtains a unique SUSClient ID for the server, when under WSUS management. Unfortunately, when each server was deployed from our pre-configured VMware Template, although they successfully joined the domain (using Sysprep) and obtained their own domain SID, the SUSClient ID remained the same. This ID is maintained in the registry key:

HKLM\Software\Microsoft\Windows\
CurrentVersion\WindowsUpdate\SusClientId

(this text has been wrapped due to formatting constraints)

In order to remedy this, I had to use the following procedure for each server:

1. Stop the Automatic Updates Service
2. Browse to the registery key above and delete it
3. Start the Automatic Updates Service
4. Click Start, Run, and enter 'wuauclt /resetauthorization /detectnow'

Each virtual server then showed up individually in the WSUS management console. I'll be working on remedying this in our Templates in the near future.

Happy patching!