Bad advice prevalent?

Looking at this article here:

http://www.lokbox.net/SecureXP/

It seems that a lot of Windows "Security advice" is pretty rubbish to me. Some of the things mentioned in the article are common sense, but others are nonsense:

Quote:

---

1.) Verify that Automatic Updates are set to install automatically.

---

Remember that this is an article about securing WEB SERVERS. No sane sysadmin would have automatic updates on a production web server. Several reasons:

1. If the networking is configured correctly, automatic updates would fail anyway because egress would not be permitted from the DMZ that the web servers reside in.
2. No sane sysadmin wants updates applied to production servers without first being tested.

Quote:

---

2.) Disable and Audit the following files: ftp.exe, tftp.exe, command.com, cmd.exe, telnet.exe, wscript.exe, and cscript.exe.

---

Total tripe. Deactivating system commands is asking for trouble. Many installers and other programs rely on these to operate correctly. Worse still, if an attacker did gain access, they could do so without these programs, or upload their own copies.

It's a measure which if taken literally, will almost certainly break a lot of applications, and do little to enhance security.

Quote:

---

3.) Rename the Administrator account and disable the Guest account.

---

The latter is sensible (and in fact is done by default anyway on NT4 +). But I feel that renaming the Administrator account is just "Security by obscurity".

Brute-force attacks should not be successful anyway, and should be prevented by other means. Anyone who gains enough access to do naughty things like obtain password hashes, will also be able to trivially determine the true administrator account name.

Quote:

---

When installing ANY software on your machine, it is very important that you not choose the default installation directory.

---

Utter rubbish. Again, you're just encouraging security by obscurity. When a new sysadmin joins the company, they will be utterly confused with the nonstandard filesystem layout. Legitimate software will have to be reconfigured, increasing support costs and the likelihood of a mistake by an administrator or developer.

Quote:

---

17.) Remove Remote Access capability to your Windows XP computer.

---

More sensibly, create firewall rules to block it from untrusted networks. Create sensible audit policies. You should not disable remote admin capability on a production web server - it would be highly inefficient to have to physically walk to the console for every tiny configuration change which needs to be applied.

Whoever wrote this article is an idiot; they seem to be recycling material from OS as old as WinNT, with little understanding of how it affects newer MS OS.

Many of the steps are just implementations of "security by obscurity", increasing system complexity and likely to cause applications to fail without a clear security benefit.

I think the clue to the idiot is in the title "Securing a Windows XP IIS 5.1 Webserver" - we know that in fact, Windows XP is not a server OS, and that running IIS on it has severe restrictions imposed by Microsoft to boost sales of its server operating systems.

So the same principles apply to Windows2003, but it should be noted that IIS is considerably different, particularly with respect to security, it has extra layers to try to prevent some of the exploits of the type that have historically plagued IIS.

Slarty

Slarty: Nice synopsis.... Whats sadder yet is the long list of letters behind these two's names. "by Greg Thatcher, MCSD, MCDBA, MCSE and Niall Brady, CNA"...... All that work they put in and they seem to miss some of the most basic mitigatory, (new word??), issues.

Hmm and I had just seen a 'tutorial' that was a mere copy/paste job, using the same 'advice'. Seems as though the person took it down quickly... ahh so little imagination.

Quote:

---

We at LokBox understand that configuring your system may be a daunting task. We have over 12 years of experience configuring Microsoft Operating Systems, and are available on a consulting basis to help you through this process. For more information, contact us at [email protected]

---

Now if there is two of them that must mean they have about 6 years experience each, not so much if you look at it that way :D

Experience is the operative word here. It sounds like they have been theorizing for 12 years but not actually practicing in a real world environment. Book/Cert folks tend to spew the same crap. I see it all the time yet when you present these intellects with a simple real world business case, their knowledge/benefit dissapears faster than a pizza at a weight watchers convention. Once again, another reason why I become very suspicious of people applying for positions with an entire alphabet next to their name. This has become almost a dead give away that the person has spent zero time practicing and will more than likely be useless in a production environment.

Quote:

---

When installing ANY software on your machine, it is very important that you not choose the default installation directory.

---

This one is the only one that I feel *may* have some merit. What I mean is I can see having applications installed on another partition (using the same path, just on another partition such as the E drive for example) to keep the system partition clean and separate from apps/data. However, you have to use a lot of imagination to take this away from the statement they made.

Quote:

---

Originally posted here by hypronix
Hmm and I had just seen a 'tutorial' that was a mere copy/paste job, using the same 'advice'. Seems as though the person took it down quickly... ahh so little imagination.

---

Yes, I also saw that plagiarised tutorial, I wanted to respond to it but it got taken down... so I created this thread instead.

Not only did the copy/paster ript off an "original" tutorial, it was a rubbish one too

Slarty

Hey Slarty. :)

I agree with your opinions except for ....... numbers 3 and 4.

Since many automated attacks and viruses target the Administrator account on web servers, changing the name of the Administrator account (and using a strong password) is a basic defense.

Also in this same vein is not using the default installation path for programs on your web server. Attackers often target particular file names, and if the attacker does not know where a file resides, this makes it more difficult to affect a compromise of the web server.

I agree that these are "security by obsecurity" measures, and should never be solely replied upon for security. However, these easy to implement measure, have often given me advance warnings of attacks that could have potentially succeded in compromising the system with no one the wiser. Until something went very wrong that is.

As for new Admins coming on board, this is an issue that is readily made moot by proper documentation.

Quote:

---

Since many automated attacks and viruses target the Administrator account on web servers, changing the name of the Administrator account (and using a strong password) is a basic defense.

---

I wouldn't consider it a defense but rather an early warning system or "honeypot trap" (if you will -- maybe an activity trap is a better term). Since the account has the same default SID you can find it. The problem with this isn't that it can fool the kiddies but rather that many admins believe it to be the perfect solution to "hiding" the admin account. Heck, I recently taught this to my students and whoever taught them windows made them believe that no one would find the account.

IMHO, the only reason why I would want to rename the Admin account would be for logging and auditing purposes. What I generally do is rename the Admin account and then rename (and ensure it's disabled/locked) the Guest account to Administrator. Then I turn on auditing for successful and failed logins and check it regularly to see who's attempting it.

Security through obscurity is not meant to be total security and shouldn't be relied on for that.

Now, on to the original tutorial. He must have removed it fairly quickly after I posted the source underneath. One of the things about any advice given is that it is based on the person's experience. And if they have limited experience they can only provide what they know (hopefully). There are some that will make some stuff up (I've heard weird things about other profs and what they teach). Does this justify it?

No. Even our Windows profs here (and myself as a *nix prof) spend time creating networks and experimenting with "what if" kind of situations. I tend to "play" with my students in class to ensure that I have more than just "book knowledge" (an unfortunate side effect to being a prof is not getting enough time in "Real life" as it were and spending an enormous amount of time reviewing books for courses as well as updating courses). The point of this ramble is that even if you don't have full "real life" experience it doesn't mean you cannot simulate some of it.

My 2 1/2 cents worth.

Quote:

---

2.) Disable and Audit the following files: ftp.exe, tftp.exe, command.com, cmd.exe, telnet.exe, wscript.exe, and cscript.exe.

---

Put that way, I agree, it's a bad idea. However, setting deny persmissions to IUSER, IWAM and other services only accounts on these can be a pretty good idea.

Quote:

---

When installing ANY software on your machine, it is very important that you not choose the default installation directory.

---

Again, "when installing any software" just implies security through obscurity. However, in the case of IIS, moving the web root to it's own drive helps in the case of "../" directory traversal attacks (and its variants) because it doesn't allow the attacker to access other drives than the one the web root is in.

...


Ammo

I have to agree with most of the recommendations made in the original article.. The problems that you are raising only become issues in a production environment if you do not document everything that you do. What does it matter where you put the files, if you have a step by step guide that details how to install any software on the system? The fact that you are not around should cause no problems for the next admin if you do your job correctly. It is security through obscurity, but that doesn't mean the system is obscure for the administrators. These are super simple things that will keep script kiddies out, but any proficient attacker will find other means around these measures. But isn't security about layers?

Also changing the admin account away from administrator will not cause you any problems at all. There is not even a need to change the guest account name to administrator as you can see what user names are being given to ntlogin in the event log entry, even if the user account doesn't exist.

As for disabling system commands. Again, I see no problem with doing this. If you do what you say, and test/document any new installs, then you will know ahead of time that turning off a certain command broke an install. I would also be really suspect of any software install that used CLI commands. You can do just about anything using windows installer and the installer APIs. Any software that installs using things like cmd or ftp, are bad install routines.. These would also be things that are tested and insured to work before going into production.

The only bad advice I see if auto installing patches... Totally agree on the testing and documenting of any new changes. The article does take the draconian route of just turning off services to get secure. Your comments are correct that you can secure the services they are talking about through other means. But to those who don't usually make any changes because of security concerns, these are some good basic steps. Every article can not be at everybodies technical level.

I sympathise with your point of view mohaugn, but I have made my opinions clear :)

Quote:

---

Originally posted here by mohaughn
[B]As for disabling system commands. Again, I see no problem with doing this. If you do what you say, and test/document any new installs, then you will know ahead of time that turning off a certain command broke an install. I would also be really suspect of any software install that used CLI commands. You can do just about anything using windows installer and the installer APIs. Any software that installs using things like cmd or ftp, are bad install routines.. These would also be things that are tested and insured to work before going into production.

---

It depends which system commands you're referring to... I find it highly unlikely that many programs rely on telnet or ftp, but cmd.exe, cscript.exe and wscript.exe are basic Windows components these days and are relied on by MANY installers for a lot of products including Microsoft software.

IIS in fact ships with several configuration scripts which should be run with cscript.exe (If you choose to use them).

The Windows installer has APIs for a few things but a lot of configuration of real software is done by cmd.exe scripts or vbs scripts.

Granted, if you test absolutely everything and can guarantee that no software will require them, you can safely disable them. The problem is that a future version of existing applications may use them - even things like patches may use them. That's why I'm deeply suspicious of removing these core components.

Slarty