This is a topic as much as it is an open ended statement. What does it mean to be secure? There are a lot of methods for securing your data all the way from network implementations down to physical implementations such as door locks. Security is really the sheer act of trying to obfuscate or protect information from unauthorized access – to hide or to control. Its always assumed that security will only ever do good however sometimes even when implemented properly can hinder functionality and require new solutions. Ultimately it is due to the complexities of implementation that even experienced users and businesses often overlook the basics and assume that their solutions are “good enough”, and this is what the bad guys are hoping.
Lets get something straight, this series is not aimed to make you a security professional, its not going to teach you everything, and it might even overlook a concept or too, its goal is to break down the complexities and lead you in your own direction while providing you with new tips and tools for the future to help protect yourself and your systems. For the first series I wanted to start with a basic concept;
Baselines via Local Security Policies.
A baseline is a good thing to have, it gives you a starting off point, its the line in the sand and it keeps your systems security consistent. If any of your machines security rely solely on the securities enforced by an out of the box install then you should really keep reading this article. Don’t ask me since when but at least since XP windows has employed the concept of Security Policies in two manners, Local Security Policies and Group Policies, we will focus on the former in this article.
Utilizing a Local Security Policy you can set various options and tune the level of access that users have when connected to the system as well as set specific security, audit, and logging options. Lets start walking through how you can modify your own local policy and then we will take a gander at Security Templates that allow you to export this information or even import a security policy which can be very helpful especially if you have multiple machines or plan to scale.
The Local Security Policy Editor
Lets go ahead and open up the local policy editor which will allow us to review our current configuration settings as well as make changes to any of those settings.
- Start > All Programs > Administrative Tools > Local Security Policy
The policy editor appears, on the left there is a large list of setting sections and clicking one will expand the available options in the pane on the right. Lets cut to the chase here and start diving in.
Account Policies contain settings which will allow you to define requirements for user accounts and passwords. In this working example you will define a set of rules that will aid in thwarting bots from brute force attacks on your system.
- Expand Account Policies > Password Policies
In this specific section you can see that there are various settings that you can set and they all relate to – you guessed it – passwords. Remember we are talking security here and baselines and how we can protect our systems. A very common style of attack is known as a brute force attack and the concept is simple, guess a username and try the password over and over again based on a dictionary of words. This sounds like a very unreliable method for a hacker and while the odds are not great this style of attack can get results especially in a multiuser environment with weak security where a user can reuse the password “Password1234” as many times as they can. So, lets stop that so that Junior, or Junior Admin does not get us pwned.
- Double click “Enforce password History”, set it to remember the last 5 passwords.
- This will ensure that a user has to use a fresh password each time. (Note: you can read the Explain tab for more information for each setting)
- Double click “Password must meet complexity requirements” and set to Enabled.
- Now your password must be complex and meet the rules provided in the explain tab. (Very important, if you are not using an existing complex password and set this then logout you will never get back in with that user and have to unlock it, set a complex password first before applying this setting)
Now brute force attacks are not a thing of the past, but they will be a lot harder now, however our next step should thwart a bot relatively quickly even if they have a very good dictionary of complex passwords further preventing this style of attack.
Account Lockout Policy
- Expand Account Policies > Account Lockout Policy
Enable the following settings.
- Account Lockout Threshold > 5 Invalid attempts
- Account Lockout Duration > 15 minutes
- Reset Lockout counter > 15 minutes
Brute force attempts are almost always done by bots on open services such as FTP, Remote Desktop, etc, and you’re normally not the only target. The settings applied will cause an account to be locked out after 5 bad password attempts for 15 minutes so they cannot login. The bot will notice its not getting any responses and move onto greener pastures in most cases, unfortunately though if its a true user they will need an admin to unlock their account or wait 15 minutes as well but its better than the alternative.
This section, Local Policies, contains even more settings than Account Policies and really offers what I like to call “the hidden control panel”. In this example we will change some settings to enable more complete logging and make sure a user cant shut down your system without appropriate permissions.
The first section covers Audit Logging and for the most part Windows logs the jest of what you need to know by default in the Event Viewer however it never hurts to have more detail and in here you can essentially enable “Full Logging”. Depending on what you want to log you could fine tune these here, or all of them.
- Audit account logon events, Success, Failure
- Audit account management, Success, Failure
- Audit logon events, Success, Failure
- Audit policy change, Success, Failure
Enabling the above settings should give you a pretty good idea of who is accessing the system and when, also it will let you know when someone is making important changes to the system which otherwise you would not be able to tell from standard event logging.
User Rights Assignments
The User Rights Assignments contains a list of Users and Groups for each setting that allow you to further define what a user or group can do.
A very important thing to note about this section is that User Accounts and Groups all have a unique SID in Windows that is tied to a specific installation instance. Since we are creating a Baseline that we want to reuse we really only want to work with “Well Known SID’s” which are SIDS that are essentially default to all versions of Windows Operating Systems. If you for instance add the user “SaltyDog” to a setting on one machine the SID for SaltyDog will not be present on another even if you have created the account on the other system. When creating a baseline template to use on other systems stick to Well-Known SID’s and modify each machine individually thereafter.
One thing that could quickly aggravate an Administrator of a system is an accidental Shutdown of a system especially if that system is only available via remote access or has a specific uptime SLA . One way we can prevent a user from accidentally performing this is by modifying the following setting;
- Shut down the system
- Select “Users” group and select Remove
- Press OK
While reviewing the setting click the “Users” group and select Remove. Since all accounts are part of the Users group now only those that are in the Administrators Group, or Backup Operators can Shutdown the system.
The Security options section is the last on the list and has a whole host of settings that can be applied. We will make various changes to this section that to modify some account settings and to obfuscate some information that would be available otherwise to a Local or Remote Desktop user. There is much more we could enable here but for brevity only make the following changes
- Accounts: Rename administrator Account
- Set to something that you will remember but that is not as obvious like “superuser0”
- Accounts: Guest account status
- Disabled, (its very uncommon that this will be needed)
- Interactive logon: Do note display last user name
The first two changes should be rather obvious as to what they do. When presented with a login screen either locally, or remotely, Windows has a default behavior of suggesting the last user that has logged in and in Vista and higher will show you blocks of various user accounts accessible. The final setting prevents an attacker from learning of these accounts so they can not try to brute force them to gain entry and requires them to specify a user account and password.
Converting into a Security Template for re-use
Now that we have configured our Local Security Policy we can go ahead and export it, If you still have the Local Security Policy editor open perform the following.
- Right click “Security Settings” and select “Export Policy”
- Save the file to your computer
This Security Template can then be imported onto another machine without having to go through this process again and making sure that our future servers employ at least these basic securities. To import your policy we will open up a new tool to do this. If you have another server you wish to do this on copy your .inf that you saved to it otherwise you could just follow along on the same server and just import the settings over top of the existing.
Open up the Security Configuration and Analysis Wizard which will do all this work for us.
- Start > Run (or search) > mmc
- In the MMC, File > Add/Remove Snap-In
- Scroll down the left pane and Select “Security Configuration and Analysis” and press the Add button, then press OK
We will now use the SCA snap-in to create a new database to temporarily store our settings before we configure the system. This process will not make any changes to your system.
- Right Click “Security Configuration and Analysis” and select “Open Database”
- Browse to a location where you want this file temporarily placed, specify a filename and press OK
- On the next browse window locate your .inf that you saved previously and press Open
- Right click “Security Configuration and Analysis” and select “Analyze Computer Now”
Now you can review the individual settings, those with a Red X are not currently in place in your systems Local Policy and would be changed. Those with a green check are currently in effect. You can make changes from this section as well to update your current database and those settings will be pushed instead of those found in the Security Template. When you are ready to Configure your computer perform the following;
- Right Click “Security Configuration and Analysis” and select “Configure Computer now”.
Once this has completed your computer now has the new settings in place and meets your Baseline template.
Hopefully this guide taught you a thing or two about how you can further modify securities on your server or workstation and create from that a Security Template that you can deploy onto various systems to provide you with a baseline for your future systems. This is just the tip of the iceberg and as well the building blocks of understanding how to create “Group Policy Objects” for controlling systems on a domain which is another topic all together. I strongly encourage you to dig a bit deeper into Security Policies and best practices, I think you will find this a beneficial and standard practice for your Windows Systems in the future.