A Developer’s Brief Introduction To Network Administration (part 3)

In Part 2 Dave McMahon looked at the network building blocks, in the third and final part of this series he moves on to look at matters of security.

Anti-Virus Software
You must have Anti-Virus software for your network. I'll say that again. You must have Anti-Virus software for your network! There is so much garbage floating around out there that you need to protect yourself from this 'malware'. Microsoft do not do their own AV software as such, although one-care is available in Beta at the time of this article. They do now do Windows Defender which is an Anti-Spyware solution which I also thoroughly recommend you have, but an AV solution is still very much in the arena of Third Party products. Ridgian use Symantec's Corporate Edition, but Trend, MacAfee and others all do great solutions. Trend actually do a quick internet–based Virus Scanner which is nice (see http://housecall.trendmicro.com/) but no good for a corporate network solution. You need to be able to get automatic updates of virus signatures, schedule scans from a central server and force laptops etc to do scans on or prior to network reconnection. You can use Group Policy (see below) to deny machines connecting to the network if they don't have suitable AV software installed.

Firewall and Web Proxy
What next? Well I would advise you setting up and installing a firewall. What actually does a firewall do? Essentially it blocks any network traffic that you do not specifically allow through it, thus 'limiting the attackers options'. You can then monitor the permitted traffic for any other 'bad stuff'. There are many types of firewalls out there both hardware and software, take your pick. Internet Security and Acceleration Server (ISA Server) is Microsoft's software combined proxy/firewall solution, which we use at Ridgian.

ISA Server 2004 is very easy to use and is wizard driven in almost all of its functionality. Take some time to read the descriptions of network layouts and overview of ISA Server. It can appear to be a mysterious beast, but it is actually pretty straightforward to use.

The main thing about configuring ISA Server is knowing that you must configure the internal network or Local Address table (LAT) as ISA Server sees it. Not as you see it. This is a 'gotcha', as you may be tempted to simply put in the range of addresses you defined for your DHCP. Say for example you had defined your internal DHCP server to issue IPs in the range 10.0.0.1 to 10.0.0.255 and your internal network subnet mask is 255.255.255.0 then your ACTUAL internal network range as seen by ISA Server is 10.0.0.0 to 10.0.0.255. If you don't set the internal network to what ISA server believes it is you will get intermittent network connectivity and an Event Log full of errors! A great article on this is at: http://www.isaserver.org/articles/2004netinnet.html

One last thing, if you require more than one external network to be routed through ISA Server (for instance you have 2 separate network cards each with distinct IP addresses on different subnets), you may have to play around with setting up static routes in the Windows Routing table. A better solution would probably be to get an external hardware/software router.

ISA Server is also a Proxy Server. OK so what is a Proxy Server? It's basically a server that is on your internal network that pretends to be the Internet! Why would you want to do this? A number of reasons, a single entry point to the Internet allows better security measures to be put in place. The Firewall can block unwanted ports and also you can get Anti-Virus Software to scan traffic at the Proxy Server. Also the Proxy Server caches regularly accessed resources and serves them up rather than individual users constantly accessing the Internet. This saves on bandwidth and can speed up the fetching of web pages and other resources.

So we have AD, DNS, DHCP, AV, Firewall and Proxy Services . Now let's look at turning our network into something useful.

Security Control of Users and Computers
Active Directory stores information about the Users and Computers on your domain. You want to think about how you want to organise your users and computers. It is often easier and generally a 'Best Practice' to put your users into Groups. A single user can be in many groups and a group obviously can contain many different users. There are basically 2 types of groups Security and Distribution. The latter are only used by your email server to control the distribution of emails, the former is used to apply security permissions to a number of users to ease administration. It is often better to assign permissions to a group and then place users in a group, as users often change but groups rarely do. I describe a real-life example of this below in the Group Policy Section. You create, edit and delete Users and Computers and Groups through the Active Directory Users and Computers console. IT Pros often refer to permissions as Access Control Lists (ACLs)

In Windows 2000 based domains and later Security Groups can contain other Security Groups which is great for building up hierarchies in the domain. For example at Ridgian we have a Security Group called Management and one called Senior Management. The latter is a Security Group within the former, so specific permissions can be granted to the Senior Management whilst they still have all the permissions of the Management group.

Organising Users and Computers – Organisational Units and Group Policy
I mentioned earlier about Security Groups and how they can be used to organise Users and make the creation and assigning of ACLs much easier. I also mentioned about Group Policy and how it can be used to further control how Users and Computers interact with the domain.

We have made the assumption here that you will be working on a single domain, The following sections applies equally to a forest of domains. Active Directory supports the idea of Containers, Organisational Units and Group Policies. These are extremely useful objects and work in the following way: A container is just that: a bucket for grouping together objects. By default, new users are created in the Users Container and Computers are added into the Computers Container. Containers however cannot have Group Policy applied to them.

What is Group Policy? Simply speaking Group Policy is a range of attributes or settings that apply to a group of objects. So for example, if you want all users to use a specific Proxy Server, you can specify it in a Group Policy. How do you apply the Group Policy? Through the mechanism of the Organisational Unit (OU). By default two Group Policies exist when the domain is created one is the Default Domain Policy and one is the Default Domain Controller Policy. Opinion is divided, but I would recommend leaving these well alone, as if all goes wrong, you can always delete your own custom Group Policies and you are back to where you started.

To manage Group Policy I recommend you use the Group Policy Management console from http://www.microsoft.com/downloads/details.aspx?familyid=0A6D4C24-8CBD-4B35-9272-DD3CBFC81887&displaylang=en. Not only does it make Group Policy easy to manage, it actually shows it in a way that is almost self-explanatory.

Let's examine Group Policy by means of a real-life example. In our network, we wanted some but not all users to be able to log on to our member servers. By default Local Policy (Policy applied to individual machines) on member servers precludes domain users from logging on. However, we didn't want to grant administrator privileges or power user privileges just to log on. SO we carried out the following steps:

• From Active Directory Users and Computers inside our Users OU we created a Security Group called Server Logons.
• From the Servers OU Properties Group Policy Tab we opened the Group Policy Management Console.
• We created a new Group Policy called Ridgian Servers and in this Group Policy, we enabled the 'Log on Locally' for all members of the Server Logons security group.
• Using the Group Policy Management Console we linked the Group Policy to the Servers OU.
• We then and put all of our member servers into this OU using the Active Directory Users and Computers Console.
• Finally we added the users we wanted into the Server Logons Security Group.

By using Active Directory Users and Computers we could easily add or remove users from the Server Logons Security Group, thereby allowing or denying users the ability to log on to member servers.

Group Policy updates can take a while to propagate around the network, you can force the issue with the gpupdate command line utility. The equivalent functionality on Windows 2000 is provided by secedit. See the reference: http://technet2.microsoft.com/WindowsServer/en/Library/b846f817-e308-442c-bcde-daa4a99c1ecf1033.mspx?mfr=true

Installing Something Useful – Exchange Server
Users will probably want access to email. You don't need to install an email server, if you Internet Service Provider (ISP) has a POP3 and SMTP server which you can access, however, having you own Email Server allows you greater control over your corporate email which these days is the backbone of inter-company communication. If we are sticking to the Microsoft suite, then Exchange Server is the mail server which you will be installing. Exchange 2000 for some inexplicable reason uses an image type drive known as the M:\ drive. For unsuspecting developers like myself, when I first installed this I just took the defaults as you do right? It didn't actually dawn on me that the M drive actually took a large chunk of the C: drive which when you have a busy email server soon fills up. Then you have to move it to another drive and whilst its not a huge deal, you can certainly do without the stress of moving a 13Gb email database that contains all of the company email from the last 3 years …

Thankfully Exchange 2003 has done away with this anachronism and just uses standard edb files which you can easily choose to put wherever you like. Another huge couple of gotcha's about Exchange is backups. Firstly you can't do differential backups of Exchange databases if you then want to recover fully from a failure. Secondly, you must use some backup software which clears up the Exchange Logs after the backup has been done. If you don't you will find you discs filling up again. The native backup utility ntbackup does this and this is what we use at Ridgian, however I fully accept that this utility falls well short of easy to use and reliable software, and you may well want to invest in a third party product.

Setting up Exchange Server involves only a couple of configuration points, you have to decide how you want to organise your Exchange databases and you need to configure your SMTP Connector to point at your ISP Mail Server. There is plenty of help on Exchange on the Internet and TechNet, but to be honest, I personally have had no real problems with either Exchange 2000 or Exchange 2003, apart from the issues with the M Drive and backups described above.

Once you have installed Exchange Server 2003 however, I recommend you running the Exchange Best Practice Analyzer Tool which you can get from http://www.microsoft.com/downloads/details.aspx?familyid=dbab201f-4bee-4943-ac22-e2ddbd258df3&displaylang=en

It is a simple but effective tool which analyses the exchange server and makes some recommendations based on 'Best Practice' to ensure that it is as secure and effective as possible. If like me you don't have time to learn all the nuances of Exchange management, this tool will see you right, most of the time.

Virtual Private Networking (VPN)
VPNs allow users to access the network whilst they are remote from it, e.g working at home or on a business trip. The beauty of the VPN is that it gives the user the feel that they are actually still in the office. VPN access can be set up quite easily using windows Routing and Remote Access (RRAS) Services. In Windows 2003 it is a trivial affair of running the 'Configure Your Server' wizard,and/or running the wizard in ISA Server.

You can use DCHP to issue out IP addresses to VPN clients (those machines which have used a VPN connection to link to the network) and to configure the client machine's Default Gateway and DNS Servers.

Web Servers
On Windows 2000 IIS 5.0 is the Microsoft standard web server and on Windows 2003 it is IIS 6.0. IIS 6.0. By default IIS6.0 is NOT installed on the operating system except for the Web Server edition. You have to assign the Application Server role to the server in order to install IIS and ASP.NET (Well you could do that manually, but the Role Wizard is so easy to use). As a developer especially if you are a web developer this is probably more familiar territory and I will not dwell too much on this service. From a network administration point of view, I would recommend you run the IIS Lockdown Tool http://www.microsoft.com/downloads/details.aspx?FamilyID=dde9efc0-bb30-47eb-9a61-fd755d23cdec&DisplayLang=en provided by Microsoft. This ensures that the bare minimum 'surface area' of IIS is available and that unnecessary script folders and things like access to parent paths are removed. It also disables services such as SMTP Mail and FTP unless you explicitly tell the tool that you need these services to run.

Database Services
This is home territory for me. SQL Server is Microsoft's main database server and the recent release sees SQL Server 2005 take its functionality and reach go further than ever before. This means as Network Admins you have a responsibility to properly and securely administer the database serves in your network. Databases normally contain information you would rather not loose, so remember to implement a backup routine. Using the Database Maintenance Plan wizard makes this a trivial exercise. In terms of security it is best to get people to connect with their windows credentials and not to use SQL Server Security. However many people (including us) use the SQL Server security and if that's the case, use strong passwords (see below). If you are on a Windows 2000 domain with SQL Server never let the sa password be blank.

SQL 2005 comes with a 'Surface Area Configuration' tool. This is a great tool for a one-stop lock-down of SQL Server. From here you can switch-on/switch-off services and functionality to suit your needs. By default virtually everything is switched off, including remote connectivity.

A couple of other tips about SQL Server. To get best performance out of a SQL Server, put the database log files on a separate physical disc (preferably with a separate disk controller) to the data files, and also limit the amount of memory available to SQL Server. That may sound a bit odd, but by doing so, you leave enough room for the host operating system to continue to function effectively, otherwise SQL tends to hog it all.

Security Considerations
I haven't left this section until last because it's less important. I've left it until last because I want it to stick on your mind after you have finished.

Now I'm not a security guru, but I've picked up a few things along the way, people such as Chris Seary, Keith Brown and Dinis Cruz have all opened my eyes to many security issues. Being a developer and having to work somewhat in the IT Pro space, I am fully aware of how carefree an attitude many developers, even senior ones have towards security. Many developers are interested often only in the functionality of applications and still have the attitude that unless they are developing a high profile government or banking application, somehow security is not that important, as 'hackers won't be very interested in us'.

I am sorry, but you have to assume that somebody will try to hack your network. As soon as a curious person sees that logon screen or the NT login credentials box on your web site, it is often a red rag to a bull. I bet that even you reading this application have at one point tried to break into a web site to get to a download, or have used software which 'cracks' an application. If you, a law abiding citizen can have a go ('it's harmless right?') don't you think others too might have a go?

Best advice? Design your network to be as secure as can be.

However, whilst you will find that's it's almost totally secure, the corollary is that it will be almost unusable. You can gradually release resources to users though, as and when they need it. This approach is eminently preferable to designing a highly functional network and then trying to apply security afterwards. If you start with a watertight container and then poke holes in it at least you know where the holes are. If you start with a sieve it's difficult to plug all the holes …

How do you design for security? It almost sounds like a cliché, however you only realise how important this is usually when it's too late. The best advice I ever heard was to identify your assets and then decide how you are going to protect them. After all, I presume you are running a network in order to run a business and most businesses have assets that are stored in electronic for these days. What do I mean by assets? I mean your financial records, your source code, your training material, your images, styles etc.

Even if nobody ever steals them, somebody might accidentally delete them or the disc might fail. Security doesn't just mean protecting yourself from the bad guys, it means protecting yourself from anything that could jeopardise your business, including yourself!

You could do a risk assessment, it doesn't even have to be a formal one, and even just thinking about it is preferable to ignoring it. There are books and books on this subject, but my initial advice is simply to follow the guidelines of:

• Grant Least Privilege
• Defend In Depth
• Limit Your Attackers Options

Grant Least Privilege. This is both a boon and a curse. It's a boon if you get it right, but how many Network Administrators do? This is definitely the one that can cause you the most headaches with the users of the network. This is the one they all hate you for. But this is the one that can save your company thousands or even millions of pounds. This is essentially your last line of defence. When somebody manages to hack his/her way into areas of the network they shouldn't go, the mere fact that they do not have privileges to run/access files may cause them to give up. It may not, if that is the case, there is probably little you can do, but Least Privilege causes headaches for the hacker, which can only be a good thing.

This is also sometimes the only defence against accidental damage to the network, people unwittingly deleting, moving files that shouldn't be deleted or moved. It pays to learn about Access Control Lists (ACLs), Security Groups and, although not strictly a security feature (thank you to Dinis Cruz for pointing that out), Group Policies. By doing so you will gain an understanding of how to limit users access without having to limit the usefulness of the network.

Defend In Depth. This has been a principle down the ages in all sorts of security, from defending castles to entire countries. Basically, just put enough obstacles in the enemies way and he/she just may give up. You can defend in depth with Network Firewalls, Workstation Firewalls, Server Firewalls, Anti-Virus Software and ACLs, beyond that User Certificates or SSL and data encryption can all help to defend information and systems. The only problem is, if your network is small enough whereby you are only a part-time administrator, you can have too much security whereby you cease to be productive in your 'real' job. The trick is here is to get enough defence in depth to be reasonably safe.

Limit Your Attackers Options. One thing which the Duke of Wellington was fantastic at and why he never suffered a defeat is that he forced the enemy to do battle on his terms. Therefore, he never fought a battle he wasn't ready for. Adopting his principle is also a good thing for network security. Limit the ways hackers can get into your systems. "Well, I've got a firewall, and Anti-virus" you say, but what about the Floppy Drives, CD-ROM drives, USB Connections Ports. You may have shored up the outer defences, but is mal-ware getting onto your system by other means, that 'useful' utility Bob downloaded last night and has brought in for all of you today? You may wish to implement a 'quarantine' machine which scans all 'external' software prior to it going onto the network. Or even more draconian, limit the sites to which users can browse, and deny them the ability to download anything, and all downloads again go to a quarantine machine. Finally, remember the dangers of social engineering, the method of attack, whereby hackers eavesdrop on conversations or worm their way into positions of trust with one or more key individuals.

When creating user accounts, here's a pattern you may want to use in a smaller organisation when you don't have the time to administer everybody's machine and control everything.

Create the users accounts but don't give them anymore privileges than a normal user. Next for those users whom you trust give them a local administrator account with the same password as their domain account. Set this local administrator account, so they have to change it at first logon. This way they are running with lowered privileges normally and can elevate themselves to administrator when installing software, stopping starting services etc. For those of you who baulked at the word 'trust' please remember that the whole internet runs on trust. We trust Verisign certificates because its Verisign and they have a reputation, how many of us have ever been to Verisign? This pattern only works well in smaller organisations, but then again that is the target of this article.

Always try to log on to a machine with your normal account then use the 'Run As …' option to run a specific process under administrator privileges if necessary. This comes back to reducing the attack vectors. If only a small number of processes are running with administrator privileges, it makes it harder to hijack a useful process.

Think also about the password policy you want to impose. Windows 2003 domains, by default have a complex password policy which initially seems great, but practical use of can drive you a bit nuts. I've finally settled on a password policy I like and can use. That is the use of 'pass-phrases' (Thanks to Steve Lamb of Microsoft for this) So, rather than having a password like 'peaches' or more securely 'Pe4che5', a pass-phrase would be say 'ilikepeachesilikecream'. Notice the lack of odd characters. It is the length of the password that provides the robustness not the fiddly and clever characters.

Finally in this section, I highly recommend as a network administrator that you download, install and run on every machine the Microsoft Baseline Security Analyzer (MBSA). This is a great tool for analyzing the security profile of any machine in your network. It produces a report highlighting areas of concern regarding security issues. You can then choose to implement the recommendations or not. If you choose not to, that is OK, but at least you are aware of the potential risks.

In Summary
We have looked at the basics behind TCP/IP the ubiquitous protocol of networks. We have also examined some network options and installing AD, DNS, DHCP, Firewall and Web Proxy, AV, VPN Access and configuring Exchange Server, Web Servers and Database Servers. We also took a good look at how to approach security when running a network.

This is by no means a comprehensive document. We haven't looked at any of Certificate Services, FTP, Update Services, Microsoft Operations Manager or a host of other things. Neither have we looked at hardware routers, hubs, switches … there I leave it and flee gratefully back to my developer workstation.

It's been a bit of a lightening trip around the IT Pro world, but maybe it has been of some use to those of you who developers who have taken on the mantle of network administration and are still trying to get to grips with it all. Hopefully too, I've given you a few pointers to help you get started in the key specific areas. Don't forget TechNet it IS a great resource as is the Internet with its newsgroups and user groups.