Ok, you have that shiny new, freshly installed server up and running. You are about ready to deploy it, but you are concerned about security. Judging by today’s political climate, this is a concern that affects many system administrators, now more than ever.
The very first thing you should do, with respect to security, is go to your OS vendor’s website and download all the sevice packs, patches, and newer versions of packages that may be obsolete or insecure. Be sure to review all of the bug and security postings available at the vendor’s site. Now, install all of this software. Yes, this is time consuming. Yes, it is your job as well.
Now that you have all of your software up to date, you are ready to start considering a security policy.
Where do you start? First of all, you will need to have an idea of what it is that you want your server to do. Make a list of all the services that you will want running. What users and groups will have what kind of access to the machine? Where will the server be located? Will it be a web server out in the DMZ, or is it an internal server that is already hidden away behind a firewall or two?
Once you have a rough idea of what it is you hope to accomplish, you are ready to start locking down the server. With most operating systems, you can start out by refusing all connections from outside sources. Once this is accomplished, it is then time to open up ports, configure IP filters, and configure and start services. Microsoft, on the other hand, leaves a *ton* of services open or “on” by default. This includes many services with *huge* security issues (does “Universal Plug and Play” ring a bell…?).
Microsoft does lend a hand, somewhat, with respect to security. There are several default security templates that are a good starting point for a security policy for a local machine or even a Windows 2000 domain controller. These templates can be tailored and even saved, so that you don’t have to reconfigure for multiple machines…. just copy your template to the machine(s) in question and install it as the default security policy. These templates, along with any you may create, are small enough to fit on a floppy disk, so portability is not a problem.
You can even incorporate one of these templates into a group policy object in Active Directory so that your internal Windows 2000 domain controllers are handing out security policies on your network. The nice thing about this is that you do not have to install the security policy on all of the machines on your network, Active Directory will implement it for you.
There are several default security policies available. You can view and modify them by using the Security Templates snap-in for MMC (Microsoft Management Console- type mmc.exe at the run prompt on the start menu). Simply open up a MMC and add the Security Templates snap-in (Console->Add/Remove Snap-in).
This article is more focused on modifying one of the existing security policy templates, however, if you need to, you can very easily create a policy from scratch. With your MMC open, right-click the parent default template folder and select “New Template”. You will be prompted to name your new template. That is it, you are now ready to define the security settings for your custom security policy template.
Before you alter any policies (who knows, you might need that template again later) be sure to back up any policy templates that you may be working with. Simply right-click the template in question and select “save as”. This way, if you do something wrong, you can easily restore the original template. I did mention that you should always try to work with security policies in a lab environment, before deploying to mission critical machines, didn’t I?
Now, the best advice I can offer on configuring your security policy is to read through all of the options in the template and make your decisions based on what you are running and the level of security that you will require. I know this is very open ended, but there are so many different configurations possible, depending on your goals, that there is no way that I could list them all.
Use common sense. If you do not have an FTP server running on this machine, it is reasonably safe to say that you could put the highest restrictions available on any entries governing use of FTP. If you do not know what a service is or does, make a note about which one it is and finish your preliminary security policy without changing policy for these “vague and elusive entries”.
Now, in a lab environment, implement your security policy. Set it up so that you can test all of the services that you will be running on the server in question. Set up several user accounts (that mimic real accounts and privileges that are on the production network) so that you can test group policy. Now make yourself a checklist of all the services each user will have access to utilize. Can you see where I am going with this? Lastly, setup two or three machines that you will use to access the server.
Once your lab environment is set up, start making changes to your security policy based on the list of questionable entries that you made. Every time you make a change, test the results with your checklist for all of the different user accounts that you created. This may be time consuming, but you will be rewarded with a greater knowledge of your system(s) and you can be reasonably sure that short of additional software (anti-virus, firewall, encryption, etc…) or hardware (routers, firewall appliances, etc…) that you have done all that you can to lock down your machine(s).
Once you are comfortable with how you have things set up, download and run a vulnerability scanner against your machine. For Windows networks, I have to recommend LANGuard Network Scanner as your first test scanner. Follow it up with Ethereal, utilizing Ethereal’s less intrusive scans. Both Ethereal and LANGuard will tell you quite a bit about what is visible from the network on your machine(s).
Scanning is what the script-kiddies and the crackers are doing to find out what they can about your machines. Find out what you are letting them know *before* it is too late. Use Event Viewer to check all of your audit logs (you did set up some auditing policies- you know authentication failures, etc…, right?). Use your client machines to test your auditing policies. Make sure that the logs are telling you what you expect them to tell you.
Jay Fougere is the IT manager for the Murdok network. He also writes occasional articles. If you have any IT questions, please direct them to Jay@https://murdok.org.
