Chris Sanders

The fine folks over at GFI were kind enough to send me a copy of the latest release of their LANguard product which is currently at version 9.0. As a disclaimer, GFI does advertise on my site, but this is not a paid advertisement, and our business relationship is has no influence on my review of the product.

I’ve used various GFI products for several years and remember using LANguard many years ago while working for the Department of Education. As I have taken on a more security-focused role in my new position with EWA GSI I have found myself using LANguard again and am enjoying the newest version of the product just as much as I did the older versions.

The big three features LANguard boasts are vulnerability management, patch management, and network auditing. I’ll address each of those individually.

Vulnerability Management

My primary use of LANguard has always been in this category. Some of my earliest learning experiences with network security were centered on LANguard security scans and in my current security role I’m making use of it right where I left off.

The scanning engine boasts over 15,000 scanning signatures and does seem to be quite thorough. I compared GFI LG scans side by side with Nessus scans on the same hosts and found the reporting from the LG scans were picking up quite a few more items of interest when it came to Windows hosts. The scanning options are quite robust and the reporting and remediation interface couldn’t be much better. 

Patch Management

I’ve previously always used WSUS for patch management. However, if you’ve used WSUS you know that it can sometimes be unreliable and the reporting and troubleshooting features associated with it are still greatly lacking. I’m no longer directly managing a network so I evaluated the patch management features of LG on my home network and was pleasantly surprised.

I ran several scans against the devices on my networks and some of the virtual machines in my test networks that I had purposely halted automatic updates on. LG reported the missing updates on these machines and I was able to efficiently deploy those updates to the machines. I’ve always thought OS updates should be something that “just works” and LG fit the bill on this.

Network Auditing

There is a LOT of competition in this area but I was really impressed with what LG could offer here. I think a network auditing solutions biggest weak point is usually the reporting interface, and just as with the other areas of LG, the reporting is pristine. Not only can you perform on the spot audits, but you can also check for things such as illegal software installations by running comparisons against baseline audits.

Pricing

GFI has released a full-featured FREE version of LANguard to be used for up to 5 IPs. After that, pricing is done on a per-IP basis with prices starting from around $32USD per IP for a 10-24 IP block.

Conclusion

I’ve always thought GFI was a great company with some really great products and LANguard 9.0 only helps to reinforce this opinion. I will continue to use the product alongside Nessus for my security scanning needs and would fully recommend it for network management and auditing.

You can check out LANguard and other GFI products at http://www.gfi.com.

Derek Melber wrote a great little article about the top ten security settings to make directly after installing Active Directory. I’d recommend all of these. Our server guys here actually have a very similar procedure they follow when creating a new network.

Read the full article here.

 I write a lot about WSUS because I think it is a necessity for any network with Windows servers or clients. It is typically pretty easy to setup but occasionally you will run into some issues. Out of all of the WSUS issues I hear about and directly experience (and trust me, I manage a LOT of WSUS servers) the most common problem I hear is when the computers in a network simply don’t connect to the WSUS server.

Here are a few items which are the most typical causes to this problem:

Lack of Patience

This is the number one overall issue I see. WSUS is built upon a technology that is by no means instant. It takes some time for updates to download, it takes some time for Group Policy Objects to apply, and it takes some time for computer to report in to WSUS in general. That being the case, if you have just installed WSUS and are looking at this article two hours later because computers aren’t reporting in, then you most likely haven’t waited long enough. I generally tell people to wait as long as two days after installing WSUS to start looking into why individual clients aren’t reporting.

Group Policy Issues

One of the simpler problems is that either the Group Policy Object for configuring the automatic update service is not being applied or it is misconfigured. At a minimum, your GPO should be configured so that it points the automatic update service to download from the WSUS server. Make sure you don’t have any typos in this path.

You can make sure that your GPO is being applied to the computer in question by typing GPRESULT into a command prompt on one of the machines in question. Remember, the Group Policy setting for configuring automatic updates is to be applied to computer objects, not users.

Client Requirements

WSUS clients must be Windows 2000 SP3, Windows XP, or Windows Server 2003 in order to take advantage of WSUS. I’ve seen lots of cases where someone would tell me a bunch of their workstations weren’t reporting in and updating only to find out they were Windows 2000 SP2 or something like that.

Imaged/Cloned Computers

In some network most if not all of the workstations were deployed with system images via Acronis, Ghost, or some similar program. If that’s the case, there is a good chance that the WSUS ID, a unique identifier found in the registry of every computer on your network, was not regenerated. These WSUS IDs are generated based upon the SID of a computer. If you configured your image so that it would generate a new SID upon pasting then you likely won’t have this problem, but this step is commonly forgotten. The WSUS ID is stored in these three registry keys:

HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAccountDomainSid
HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdatePingID
HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateSusClientId

In order to generate a new WSUS ID, you will need to delete these keys on the client machine in question. After doing this, restart the Automatic Update service and run the command “wuauclt.exe /resetauthorization /detectnow. You should see the computer in the WSUS console shortly after that.

This process may seem a bit too manual when you have to perform it on multiple computers, so there is a VB script that can automate this a bit. You can download this script here: http://www.vbshf.com/vbshf/forum/forums/thread-view.asp?tid=199&start=1. You can simply download this script and perform the aforementioned steps remotely by just entering the computer name.

This covers a few of the most common reasons clients don’t report in. Obviously, there is no way to cover every possibly avenue, but hopefully this will eliminate some of the more common possibilities. As always, I respond to direct WSUS questions via e-mail. Also, the WSUS forums over at http://www.wsus.info/ are a great community driven resource for figuring out issues like this.

Dan Nerenberg over at TheLazyAdmin.com has just published a guest post from me about WSUS. If you have never heard of this site, then I’d highly recommend adding it to your daily reads. Originally started by former MVP and current Microsoft employee Rodney Buike, it contains a great deal of informative content.

The post is a detailed WSUS FAQ. If you are considering deploying WSUS but have some questions, then chances are that this FAQ will answer at least a couple of them. Check it out here.

Most people have heard horror stories about employees who are fired and then proceed to go on a violent rampages through an office as they exit. It is for this reason that most organizations have policies in place that require terminated employees to be escorted of the building by a security officer or member of upper level administration.

This same policy can be applied to network administration. I have heard countless tales of network uses whose last act before leaving the building after being fired is to romp across any server they have access to deleting files as they go. In all honesty, if a disgruntled former employee ONLY deletes data then you are getting off easy. How about if the employee has access to business critical informationa nd takes a copy with them when they live to sell off to the highest bidder? What if it is a member of the IT staff who has just been fired and he/she decides to change all of the domain administrative passwords or delete the NTLDR file on the domain controller? Even worse, what if the employee has access to sensitive financial information about employees including account numbers and social security numbers?

What I am getting at here is that every organization needs to have a policy in place for limiting the technical resources of a user after they have been terminated. This includes disabling their user account, changing and departmental or administrative passwords they have access to, disabling corporate e-mail access, and locking down access to their personal workstation. In most cases you won’t want to immediatly delete all of their account information, but disabling it and/or resetting passwords is the perfect option until you get the go-ahead from management to trash it all. This can be done manually by a particular member of IT staff or can be setup in an automated fasion through the use of a script.

I have just had a full length article published on WindowsDevCenter.com entitled “Five Things You Need to Know about Virtual Server”. It is a great introductory article about Virtual Server and the benefits it provides, as well as how to install it and do some basics things with it. You can view the article on the front page of WindowsDevCenter.com or directly by clicking here.

If you have tried running the Windows Server 2003 Management Tools on Windows Vista then you have more than likely run into a problem or two. Microsoft has a KB article on how to fix a majority of these problems. See KB930056 here.

Every single service or device on your network has at least one point of failure. That is, any point on a network that when in a failure state can cause a service to no longer function. Thinking small, a PC has several points of a failure…the power supply, the motherboard, the hard drive, each one is a point of failure for that PC. Thinking on a larger scale, a service on a WAN might have dozens of points of failure…the router on either end of the WAN link, an internal switch, a network cable.

The goal is to have as few points of failure as possible for any service. A lot of this is achieved by making sure the layout of your network is conducive to having only a few points of failure. The other primary method of ensuring this is through redundancy. A two-node server cluster will eliminate the point of failure should one server crash. Don’t let that false sense of security trick you though, if you have two redundant servers sitting in the same rack, a spilled cup of coffee and ensure that rack as another failure point

The point of this is that you should always be aware of the points of failure on your network for its mission critical services. This will result in fewer disasters, and quicker disaster recovery should there be one.

As the conclusion to my series on the various Intellimirror technologies, WindowsDevCenter has just released an article on using offline files. Co-written by myself and Mitch Tulloch, this explains the ins and outs of offline files and includes a quick Q & A about the technology. Check it out on the front page of http://www.windowsdevcenter.com or directly by clicking here.

I have co-written another article with Mitch Tulloch for WindowsDevCenter on the topic of installing software with group policy. You can currently access this article on the front page of http://www.windowsdevcenter.com or directly by clicking here.

If your organization relies on technology to any reasonable extent then the chances are that you have servers responsible for several different services and roles. These roles and services can vary from database, to file, to web, to application services. These services all require some form of network communication and use a port to do so. The more services on a computer, the more ports open on that computer.

Nothing looks more juicy to a possible intruder than a machine sitting somewhere with forty-two different ports open on it. It is basically a big red flag saying “Hey! Exploit Me!” This being the case, service isolation can really deter a possible intrustion attempt. If a hacker sees several boxes each with only one or two ports open then they are a lot less likely to even bother with scanning the machines.

There are several ways you can go about service isolation. One of the most effecient ways is to leverage the use of Microsoft Virtual Server (or VMWare server if that is your cup of tea). Doing this you can still achieve a lot of the goals of server consolidation while maintaining a better security baseline. Even though all of these services are still running on the same physical server, them running on different virtual machines makes it appear as if they are all running on seperate machines to those looking in from the outside.

That’s right ladies and gentlemen! My first book has been released in E-Book form by the great people at O’Reilly! It is an absolutely fantastic look into Virtual Server and how it can save you and your organization time and money. The current selling price is $7.99 which is an absolute steal for the amount of content it has to offer!

Check it out here:

http://www.oreilly.com/catalog/saving/?CMP=ILC-2RQ…

If you like it, don’t forgot about my second book coming out IN PRINT from No Starch Press early next year!

Would you allow somebody to bring a laptop into your corporate headquarters and plug it directly into an Ethernet port? Then why would you allow someone easy access to your network via its wireless infrastructure? That is exactly what you are doing when you do not invest in the security of your wireless network.

It is so common to talk to a Network Admin and listen to them tout the security of their WEP or WPA enabled wireless network. WEP, WPA, and similar technologies are very easily surpassed by even the most novice of hackers. It is for this reason that I refer to securing a wireless network as “investing” in its security. That is because relying on just the individual wireless access points security is not enough.

If your wireless infrastructure is of any reasonable size then it is a safe bet to say that you should look into spending some extra money in securing it. How do you do this? There are a variety of different ways you can go about implenting server based wireless security. The most common (and secure) is RADIUS based security with the enchancements of certificate based authentication. This ensures thats only the wireless clients listed in a RADIUS database on a physical server and holding a certificate pushed out by group policy will be able to authenticate to the network. If someone wishes to compromise the security of your wireless network then they must also compromise the RADIUS and certificate servers. There are several other ways to secure your wireless network beyond WEP/WPA, and I highly reccomend looking into them.

Remember, you can never destroy all of the paths a hacker can take to compromising a device or service. You can however put plenty of hurdles in the way of those paths ot make the process a lot harder.

The administrator account is perhaps one of the most sacred things there is on your network. I am not talking about the Domain Administrator account however, I am referring to the local administrator account. Obviously the domain administrator account has the most power out of any account in your network, but the fact of that matter is that you shouldn’t be logging in with this account anywhere anyways, and it is something that should be nearly impossible to crack from a hackers standpoint.

The local administrator account is where it all begins. If someone is going to break into your network the first thing they will need is to gain administrative priveleges on a machine. If you can protect this account successfully then you are doing a good job of stopping internal attacks at the front line.

This being the case, how do you protect this account? Obviously, the first thing you will want to do is use a strong password. People should not be logging in to computers with this account so it is okay to make it something insanely long that nobody would really want to type. Be sure to use uppercase letters, lowercase letters, numbers, and even a few symbols when setting these passwords. In larger environments you will also want to make sure that the administrator accounts on all your computers vary by location. It is not too pratical to make a different password for every single computer, however you can make multiple passwords for various departments, locations, subnets, etc. These passwords should be changed frequently, as in monthly. If you want to get really creative you can do some scripting paired with group policy to make this task a lot easier.

One more thing you can do is to to completely disable the administrator account all together. This will make sure nobody is logging into it. However, this isn’t always feasible in some cases. Another solution I have often heard is renaming the administrator account. If you rename your administrator account to something other than “admin” or “root” that adds a completely new step of enumeration an attacker has to go through before beginning to try and compromise a system. A lot of the times you can deter an attacker just by making them jump through some extra hoops along the way.

I got to looking at my calendar and noticed I had scheduled a User and Group permissions audit for today. I try to do these at least once every quarter and I am very glad I do. In an environment where you have multiple people who exercise their ability to assign permissions to various resources you can very quickly get people who aren’t on the same page assigning permissions that they shouldn’t be.

Completing this type of task may seem daunting once you start counting up the various network resources you have (printers, shared storage, etc) but if you get an organized system going it really flies by quickly. I typically make an excel spreadsheet where I have a heading for every network resource and a row for every group or user that has permissions assigned to it. From there I make a columns for the type of access assigned (read, write, modify, etc) and place an “X” in the ones that apply to the user or group.

As an added bonus, if you do your audit via the spreadsheet method I mentioned above, you can easily transfer this to a mobile device such as a laptop or PDA in order to have a quickly accessible reference to resource permissions when you are away from the network.

If you have never done a permissions audit on your network I highly recommend scheduling a few spread out across a year. I can guarantee that you will be surprised at some of the things you find.