The perils of running an unsecured FTP server

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last week I got hacked.

I’d opened up my previously stealthed firewall to:

  • Access my home network when I’m at work;
  • Allow one of my friends to post some large files to my FTP server.

The trouble is that I hadn’t been carrying out the best practices that I would advocate for my enterprise clients. Despite last month’s post on securing IIS, I had just opened up the standard ports to a standard IIS server which wasn’t even in a demilitarized zone (DMZ).

I didn’t think I’d be a target for a hacker but within a few days some guys in Italy and Belgium had started abusing my FTP server to dump their files (this article from ZD Net leads me to believe that it’s a common practice). I don’t know what the contents were. I deleted them quickly to be safe and shut down the firewall until I could implement something more secure.

Thankfully, I got off lightly (this time). I checked the logs last night and my new security measures are keeping the intruders out. If you do need to provide an FTP service, you might like to read the windowsecurity.com article with 10 steps to secure an FTP server.

Should you run the Windows Firewall, a third party firewall, or both?

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

“Which firewall should I use?” – it’s an interesting question. Microsoft are positioning the Windows Firewall (part of Windows XP service pack 2) as a major leap forward in terms of network protection, and it is; but there are many good third-party firewall products out there. Should you use the Windows Firewall? Should you use your third-party product? Should you use both?

According to the Windows IT Pro magazine network (formerly the Windows and .NET magazine network) Windows Tips and Tricks Update, Microsoft issued the following statement in response to such questions from their customer base:

“We strongly recommend that users run only one host firewall on their system. Yes, the XP SP2 Windows Firewall can coexist with third-party firewalls, but multiple firewalls don’t make you safer. Running multiple firewalls just means you have to configure the settings in multiple places (e.g., opening ports for each firewall you run). For anyone who wants to keep using a third-party firewall after installing XP SP2 – for example, because they like some of the extra features – we suggest they turn off the Windows Firewall. We have already advised third-party firewall vendors to programmatically turn off the Windows Firewall in their future releases, so this will eventually be automatic.

We don’t have any specific guidance as to whether people should use the built-in XP SP2 Windows Firewall or use a third-party product. We absolutely believe that people who don’t already have host firewalls should run the Windows Firewall in XP SP2. Almost all firewalls on the market (including the Windows Firewall) provide good security; it then boils down to what features and capabilities people want. The Windows Firewall, for example, doesn’t do any alerting or intrusion detection. Neither does it offer outbound filtering capabilities. The Windows Firewall focuses on preventing attacks from successfully penetrating a system, but it doesn’t do anything to protect systems once bad software is locally installed. Some other products also have better diagnostics and centralized reporting than the Windows Firewall (which has no reporting whatsoever). I don’t believe people are “safer” running third-party firewalls, but there may be some features in these products that they would like to have.”

Whatever the answer, in today’s climate, and in line with the security principle of defence in depth, we should all seriously consider the use of a firewall on all PCs, and the Windows Firewall is a good starting point.

Script to disable password expiry for local Windows accounts

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

One of the shortcomings of the net user command in Windows is the inability to set the password never expires flag on an account (account expiry options can be set, but not password expiry and the full syntax is described in Microsoft knowledge base article 251394).

There are 13 flags on an NT SAM/Active Directory user account which may be manipulated using VBScript (for further details of the 13 flags, see Microsoft’s sample scripts or there is some useful information about the object model at the Motobit Software website).

This script can be used to set the password never expires flag on a specified account. I’ve tested it against the local SAM database on a Windows XP PC, but in theory it should work on all versions of Windows NT (2000, XP, 2003 Server, etc.) and also against Active Directory accounts if you run it on a domain controller.

Securing IIS

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Whilst researching some IIS issues, I came across a useful checklist for securing IIS courtesy of the University of Washington.

Allowing potentially dangerous attachments in Outlook

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve come up against this one before, but as its something I’ve had to look up on a few occasions, I thought I’d post it up here. You know the problem – someone e-mails you a useful script and Outlook blocks access to it; and rightly so as we have no real way of telling if the attachment could be malicious.

If you trust the sender and are sure you need to access the attachment, there is a quick registry hack you can employ:

  1. Navigate to HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Security\ (for Outlook 2003 – change 11.0 to 10.0 for Outlook 2002 or 9.0 for Outlook 2000).
  2. Add a new String Value called Level1Remove and add a semicolon-delimited list of file extensions to be allowed, e.g. .bat;.cmd;.com;.exe;.vbs.
  3. Restart Outlook and the offending attachments will be accessible.

Remember that this is disabling a security feature, so only enable potentially dangerous attachment types as an emergency workaround and remove the Level1Remove value once complete.

More details may be found in Microsoft knowledge base article 829982.

Microsoft Windows XP Security Guide

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Microsoft have just published the updated Windows XP Security Guide, which provides several levels of security guidance for customers interested in hardening deployments of Windows XP for desktop and laptop clients in their environment.

This guide includes settings for Windows XP clients deployed in a Microsoft Windows 2000 or Windows Server 2003 Active Directory domain. The document also includes guidance for an environment requiring an extremely high level of security in which application compatibility or usability may be constrained. Finally, it discusses procedures for implementing Windows XP security settings in stand-alone clients.

Manually configuring Windows Firewall in Windows XP SP2

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

There is an interesting article on the Microsoft website describing the settings for the Windows Firewall introduced in Windows XP Service Pack 2.

Preventing denial of service attacks on an ADSL router

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Since about April 2004, I’ve been having problems with my ADSL router at home (a Solwise SAR 110). As the hardware was just over 12 months old (and hence just out of warranty), the cynical side of me was resigned to the fact that it had just “broken”. Not wanting to lose my configuration settings through a firmware upgrade, I got used to resetting the router each day (sometimes several times a day) when it seemed to just drop off the network. Because I couldn’t access the box, I couldn’t check any logs and find out what was happening.

This all changed when I spotted a posting on my ISP’s support forum, directing me to Chris Marsh’s excellent SAR 110 and 130 Guide. Using Chris’ advice I have been able to stealth my router (as tested using the GRC Shields UP! port prober). The SAR Guide website also included interesting information on other configuration items that were not always clear from the Solwise manuals and help text.

Now that my router is no longer visible on the Internet, it seems to stay up as it did for the first year I was on ADSL (just under 13 days and counting as I write this). I can only assume that the problem was a denial of service (DoS) attack, that has now been prevented through the stealthing of the router.

Obviously, there are many types of router out there, but by following the same steps, it should be possible to stealth most ADSL routers, even if the user interface is slightly different.

Why physical access to a PC is so useful for a hacker

This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

This week, I’ve been attending a (Microsoft-sponsored) training course, looking at Windows security. Now, what happens when you get a bunch of techies together in a room and talk about security? Exactly! We all start to think of ways around things. Like the classroom PCs with locked-down configurations…

…the guy sitting next to me (who will remain anonymous, as will the training provider) had a Winternals ERD Commander 2003 boot CD.

Using this, we were quickly able to reboot, launch the Locksmith utility and reset the administrator password to one of our choice, following which we had unrestricted access to the PC.

It was all just a bit of harmless fun within a classroom environment, but it goes to show why physical access is such an important part of a defence in depth strategy.

Scripting changes to resource permissions in Windows

This content is 21 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Earlier today, I needed to include some registry permissions changes within a command line script that I was writing. Microsoft knowledge base article 245031 discusses a method using the regini.exe resource kit tool for Windows NT 4.0; however, for Windows 2000, XP and Server 2003 there is the SubInACL utility (subinacl.exe) which is far more powerful and much easier to use, enabling administrators to obtain security information about files, registry keys, and services, and transfer this information from user to user, from local or global group to group, and from domain to domain.