One significant challenge many IT administrators face today is safeguarding their networks from intruders. This applies to the intruders who are the unknown hackers “out there”, or to merely the sheer magnitude of unwanted SPAM, spyware, and the overwhelming availability of Internet sites offering everything from innocent (and time-wasting) computer games to gambling and pornography.
Before the advent of the Internet, organizations with computer networks didn’t have to worry too much about the wild, wild cyberworld out there. Local area networks (LANs) sprouted up to allow computers within a single building or a campus to communicate with each other, and then wide area networks (WANs) were created to connect these multiple LANs in a typically (somewhat) private, closed system. LAN protocols were not highly routable (if at all), keeping network communications “within the walls”.
Thus, there was (comparatively) little concern about what some “black hat” hackers in another part of the world might be cooking up to potentially attack your network and computers, and possibly steal your organization’s information or hijack your network services. The greatest concern in this realm usually centered around the ubiquitous floppy disks (remember those?), as the chief medium for the spread of computer viruses.
Today, just as computer networks replaced the “sneaker net” of transporting data between computers via floppies, and as high-speed, permanent (“always-on”) Internet connections replaced the venerable (but sluggish) dial-up Internet connection, so the risks of computer insecurity have also advanced in terms of both speed and prevalence. Some users have reported instances of their computers being compromised (“hacked”) within minutes – yes, minutes – of first connecting them to the Internet, after a fresh installation of the operating system.
Combating the “bad guys” today requires a multi-level approach, with the constant vigilance of a good antivirus system, plus applying the continuous plethora of operating system security patches (see “Patch Management Made Easy”), and implementing prudent network security solutions as well.
The most obvious and essential network security element today is the firewall. Once esoteric and prohibitively expensive, firewall technology is now a standard part of any organization’s network security architecture – almost as ubiquitous as networks themselves – and indeed, it is hard to imagine an interconnected network without one. Even for the humble home user today who subscribes to high-speed Internet service (cable or DSL), often a basic personal firewall/router device comes bundled with the package. Software firewall services are also now integrated into the desktop operating systems, to add yet another layer of protection.
Firewall technology, introduced in the early 1990s, began with simple packet-filtering, and then advanced to more sophisticated firewalls capable of examining multiple “layers” of network activity and content. The early firewalls were essentially merely routers containing packet-filtering capability.
Although this basic packet-filtering is still a core function for the firewall, additional firewall services, such as “stateful inspection”, were needed, and so were added, to combat more sophisticated hacking techniques. In addition, to combat attacks on certain application systems such as email or Web services, specialized application proxy gateways were also introduced.
Thus, we could deploy multiple types of firewalls and proxies on a single network to deal with the various ways that cyber-attackers might seek to do their mischief. We could use a boundary packet-filter firewall at the network perimeter, combined with a stateful inspection firewall for advanced protection. And then to protect the email system from transmitting viruses and SPAM, we could employ an application-proxy gateway (or SMTP gateway, in this case).
But with this multiplicity of security systems also comes the increased complexity of implementing and maintaining them. Advances in firewall technologies have led to a great degree of “hybridization” of these various security functions, so that modern “firewalls” perform many different network security functions simultaneously – packet filtering, stateful inspection, application proxy, content filtering, and others as well. This model of multiple security services running on a single device is often referred to as Unified Threat Management (UTM).
One such hybrid firewall system is the Astaro Security Gateway, which is sold both as a pre-installed network hardware device, and alternatively as software only, to be installed on standard computer hardware. Either way, the Astaro solution utilizes the (now typical) hardened Linux kernel, upon which run all of the security services. For ease of management, all of the security management functions are performed via a Web interface (BTW – Astaro has earned the SC Magazine “Product of the Year” award for both 2005 and 2006).
Novell has partnered with Astaro to provide Novell Security Manager, powered by Astaro. This is essentially the same Astaro Security Gateway software, which is easily installed on any modern PC or server-class computer. This software offers security at six different levels: Firewall, Virtual private network, Intrusion protection, Virus protection, Spam protection and URL filtering.
Of course, Novell/Astaro isn’t the only game in town. Many vendors now offer UTM devices and software, all of them promising to make your network more secure. So one problem facing many network administrators today is not the lack of choices, but the burden of choosing and implementing the security solution that they can live with.
It has to have all of the advanced security capabilities – in case we find that we need them – but it also has to be reasonably easy to implement and maintain. We don’t have time to run out and get a PhD in firewall technology.
So, predictably, we start out by reading up on the various security products that are available (you’re reading this, aren’t you?), and then we’d like to take the next step. Before we commit to any particular product or solution, prudence tells us that we should take it out for the proverbial “test drive”. We would like to “try before we buy”, and first gain a little familiarity with this product, prior to investing the time and money required to jump into the actual implementation.
There is one challenge with performing our own proof-of-concept testing with network security systems: how do we test them without disrupting the production network? I know of one colleague who had changed his UTM firewall on his production network six times in the past year. Essentially, he was making his end users the live “guinea pigs” while he tested this product and that, until he found his desired balance of features and ease-of-use. Well, most of us wouldn’t retain our jobs too long if we tried that approach.
Fortunately, many software vendors allow you to download their software to test it for a limited period, before attempting to deploy the software into production. The Novell Security Manager / Astaro is no exception. It can be downloaded at: http://download.novell.com (keyword: Novell Security Manager).
In an ideal IT world, we would all have adequate proof-of-concept labs, replete with all of the PC, server and network hardware we would need to test out our IT solutions before we deploy them in the production environment, including a separate Internet router and firewall. But don’t feel too bad: most network admins I know don’t have that either. However, in theory, this would allow us to test out our solutions before inflicting them on the end user population.
In this article, I would like to describe how to get started with testing Novell Security Manager and get some of the basic security features running, so we can “learn the ropes” on this product before even thinking about having to perform any real deployments on our production networks.
At this point I should say that I am by no means an expert on firewalls, but like many of you, I am a learner. Because of our “learner” status, it is all the more important that we try out our network solutions in a safe environment, to both learn the ropes about firewall deployment and understand the features and capabilities of the particular solution that we are testing. In this article I merely wish to share what I am learning with you, the reader.
The 30-day evaluation download of Novell Security Manager is in the form of an .ISO file, so of course the first step is to download the disc image and write it to a CD-R or CD-RW disc. Again, of course, you need to have adequate hardware on which to install the software. The minimum hardware requirements are pretty modest: Processor: at least a Pentium II or compatible (hey, do those still exist?), 256 MB RAM, 8 GB IDE or SCSI hard drive, bootable IDE or SCSI CD-ROM drive, and 2 or more PCI Ethernet network cards.
Once you have downloaded the .ISO file and written it to a CD, you should be able to boot the computer to the bootable CD. (Note: This may require configuring the boot options in the computer BIOS.)
Let’s say that we don’t have a dedicated computer lab network that we wish we had, but we still need to perform some testing of the NSM software, even within the existing production network. This doesn’t need to be a show-stopper, if we proceed carefully. We can place the NSM computer on a different logical network (IP subnet), even though it may be connected to the same physical network as the production environment.
One way to deploy the secondary firewall is to run the new firewall and the existing firewall side by side. This means inserting an Ethernet switch between the Internet router (internal NIC) and the existing firewall (external NIC), and then also attaching the new testbed firewall (external NIC) to the switch.
Here’s a scenario: let’s say we currently have a production network with an IP subnet address of 10.1.1.0, the subnet mask of 255.255.255.0, and gateway of 10.1.1.1 – which points to the existing firewall (internal NIC). We want to install the NSM computer alongside this framework. We can insert the switch between the Internet router and firewall (as above) and attach the new test firewall to this switch. Note: This action will result in a brief outage of network services while the LAN cables are disconnected and reconnected, so it is best performed during non-production hours.
Let’s assume that the external network (the segment between the Internet router and the firewalls) has an IP subnet address of 10.0.0.0 /24, and we create a third IP subnet for the lab network as 10.2.2.0 /24. See the diagram below for a visual representation of this.
Note: These fictional IP subnet addresses are for example only. On a real network, you may have a routable (public) IP address on the Internet router (internal NIC) and on the existing firewall (external NIC). If so, then you would also need a corresponding routable IP address for the external NIC of the new testbed firewall.
Figure 1 – Production and test-lab network environment
This is just a “quick and dirty” way to set up a testing environment, without a significant capital outlay. Most of us have a spare switch or two available, or else can afford to acquire them. This provides two logically separate networks, which we can use to test our NSM firewall configurations and capabilities.
Note: If you intend to run any type of services in the lab environment to be available from the outside (Internet), such as Web or email services, then you may have to configure the appropriate NAT addressing at the router, static routes, DNS entries, etc. However, for our purposes I will try to keep this as simple as possible.
The actual NSM software installation could hardly be easier. Once you have booted to the installation CD, you are notified that you are about to install the product, and all the contents of the computer’s disk will be erased (of course). You then are prompted to select your desired language, time zone, and TCP/IP address, etc. – just follow the prompts, and then the system is imaged with the software, and you are finally prompted to remove the CD and power cycle the computer.
Note: During installation, only one network interface (typically the internal NIC, used for administration) will be configured. For the internal NIC, no gateway will be specified, since the firewall will route all external traffic to its external interface. The rest of the networking will be configured from the firewall’s Web management portal after the initial installation.
After the Astaro/NSM software is installed, there is practically no need for the firewall to have KVM (keyboard, video monitor, and mouse). All administration can now be accomplished through the Web Management portal, which is accessed by directing your Web browser to https://<ipaddress> from a management PC connected to the internal NIC of the new firewall. Note: If you do intend to remove the KVM on the firewall computer, be sure that the BIOS settings allow the machine to boot without halting on keyboard or mouse disconnection errors.
Upon the software installation and reboot, and opening of the firewall’s Web management portal, you must immediately set the passwords for the WebAdmin user, the shell login user and the shell admin user called “root.” These passwords have to be strong passwords (8 characters minimum, including uppercase, lowercase, numerical and special characters). As soon as the passwords are set, you are then prompted to login as the WebAdmin user (admin), supplying the password that you just set.
Figure 2 – WebAdmin user login
At this point, with only the internal network interface configured, we do not yet have a firewall. One of the very first tasks to configure the firewall is to configure the external network interface and configure packet filter rules between the two interfaces.
To configure the external firewall interface,
1. From the main screen of the Web portal menu, select Network | Interfaces.
Under “Current Interface Status”, you should see the (internal) interface which you specified during the software installation (such as, “eth0”). This is the NIC through which you are now communicating with the firewall.
2. To add a second NIC definition, click New and enter a name for the new interface, such as “External”.
3. Select the hardware (such as, “eth1”), and the type of “Standard Ethernet Interface”.
This opens new fields, where you need to specify the IP address, subnet mask, and gateway address. In our example above, this address would be on the 10.0.0.0 subnet, with the gateway being the internal interface of the Internet router.
4. Click “Add” to add this interface definition.
The interface is not active (the administrative status is ‘Down’) until you choose to activate it.
5. Under “Current Interface Status”, in the “Admin” column, click the first (gray) box next to the new interface, to change it to the green ‘Up’ Admin status.
Note that the operational status may still be ‘Down’ (as when the Ethernet cable is unplugged), when the Admin status is change to ‘Up’ – but an Admin status of ‘Down’ also changes the operational status to ‘Down’ (the interface is disabled).
Note: Due to security settings in the Web administration portal, do not use the browser’s refresh button to refresh information in the portal. This will only prompt you to log in again and re-establish your session. Instead, use the Web portal’s internal refresh button. For example, when you are in the Network | Interfaces page, at the top of the page there is a refresh button just to the right of “Network >> Interfaces”.
To verify external network communications, you can use Network | Ping Check from the Web administration portal to ping internal and external network addresses. If you need to use DNS names to ping, you must first configure at least one DNS proxy under Proxies | DNS.
At this point we may have a firewall installed, but the default behavior is to allow no traffic through the firewall. So we are totally secure, but we are also totally unable to communicate with the “outside world”. To allow network traffic to pass through this newly installed firewall, we need to first set up policies or packet filter rules.
Before we start opening up the gates, we should understand a little about what the packet filter is doing. Normally, different network services which use the TCP/IP protocol use different “ports” that are specified within the protocol to accomplish the various types of communication. For example, FTP (File Transfer Protocol) typically uses port 21 for file transfer, and SMTP (Simple Mail Transfer Protocol) uses port 25 to transmit email. Typically, we use these ports to define the type of network service.
Standard network services are pre-configured in the Astaro/NSM firewall, and additional services can be added, if required, by going to Definitions | Services in the Web administration portal.
To configure packet filter rules,
1. Select Packet Filter | Rules from the Web administration portal menu. No rules are defined by default – this means, by default, the firewall allows no traffic either in or out.
Some firewalls, for ease-of-use purposes, start out with everything “open”, and then rely upon you to begin to set up some policies to start locking down communications for your own security reasons. The Astaro/NSM firewall starts from the other perspective – everything is locked down by default, until you specifically start opening up communications based upon your needs.
Usually, the first thing we wish to do on any firewall is to open up some communication from the inside (trusted network) to the outside (untrusted network). Typically, this means we want to look out and access the Internet, but the Internet cannot look in and access our network.
The quickest way to open up “inside to outside” communications is to setup the basic “any” rule.
2. In the Web administration portal menu, select Packet Filter | Rules and click New Rule.
3. From the Source field select “Internal (Network)”, and from the Destination field select “External (Network)”. (We defined this earlier when we defined and enabled the firewall’s external interface.)
4. From the Service field select “Any” (the default), and from the Action field select “Allow” (default).
5. Add a Comment if you like, such as “Allow all traffic from Internal to External”, and click Add Definition.
You will notice that the new rule appears in the list. But just like when we created the network interface definition, the new rule is not activated until you purposefully activate it. You’ll notice the red square in the fourth column of the rule list, signifying that the rule in inactive.
6. Click the gray square next to the red square, and you’ll see that it turns green – now the rule is activated.
Since this basic rule allows all network traffic originating from the internal network to traverse to the external network, this should allow all internal computers to see “out”, but not allow external computers to see “in”, because there is no rule specified to allow any traffic from the external network to traverse to the internal network.
If you wish to further restrict this type of traffic, and specify that only Web (HTTP) traffic can traverse to the outside, for example, you can change the Service from “Any” to “HTTP”. From there we launch on to the complexities of what to allow and what to disallow in the packet filter rules, according to your specific network requirements. For more in-depth description of the packet filter rules, see the NSM user guide (http://www.novell.com/documentation/nsma6/pdfdoc/security_manager_astaro_v6/security_manager_astaro_v6.pdf).
For the built-in intrusion protection features of Astaro/Novell Security Manager, all you really need to do is turn it on. This is easily accomplished in the Web management portal by selecting Intrusion Protection | Settings from the menu, and clicking Enable.
The NSM has over 6900 pre-configured rules that protect against all kinds of known intrusion techniques. There is no need to manually configure or modify any of these rules, unless you are an advanced firewall administrator and really know what you’re doing.
Besides the basic firewall and intrusion protection features, what many are seeking in a Unified Threat Management (UTM) solution is the ability to provide proxy services for network services such as Web (HTTP) and e-mail (SMTP). The HTTP proxy not only provides content caching, to speed up the loading of often-used Web pages, but also provides content filtering, to limit the type of Web sites that users may open.
For the NSM, the HTTP proxy is enabled by default, as a transparent proxy (since all traffic from the internal network passes through the NSM anyway), and caching is also enabled. In Transparent mode, there is no need to configure proxy settings in the Web browsers of every PC on the network. The proxy will handle all traffic passing through the firewall on port 80 (HTTP).
Note: The HTTP proxy will not handle FTP or HTTPS requests. To allow those, you must specify packet-filter rules to open the respective ports (21 and 443). Select Packet Filter | Rules from the Web administration portal menu to configure the desired rules.
One of the features within the HTTP proxy service is Content Filtering. Like the IPS feature, this is a set of pre-configured rules that block specific Internet sites based upon content that is categorized using a database maintained by
Cobion Security Technologies. The local database is updated daily by default, using the NSM’s Up2Date feature. Also called Surf Protection, it offers 60 subcategories that are grouped into 18 main categories.
To enable the content filter within the HTTP proxy page,
1. Click Enable, under Content Filter.
At this point, the content filtering service is enabled, but nothing is configured for filtering. A default profile exists, and new profiles can be created, if needed, to be assigned to specific groups of users.
2. Click Show/Hide to the right of the Surf Protection Categories to display the pre-defined Web site categories and subcategories.
3. To block a specific category under a profile, click in the Block SP Categories column for that profile, and select the category you wish to block (control-click to select multiple categories). For example, to block computer game and gambling sites, select the “Games-Gambles” category.
Note: Web content filtering services, from any vendor, cannot guarantee that any undesirable sites will absolutely be blocked. Internet Web sites are changing all the time, and most content filtering services are a “best effort” to categorize the majority of Web sites. The NSM content filter also allows you to manually “blacklist” sites that you decide should be blocked, and “whitelist” sites that you decide should not be blocked.
If users attempt to visit a Web sites that is in a category that is blocked, they would receive a denial message such as the following in their Web browser:
Figure 3 – “Content Blocked” warning
Another important feature is the ability of NSM to filter out SPAM and viruses that often barrage networks via e-mail. The SMTP proxy can be used to shield your internal mail server from attacks – acting as a “relay” for both incoming and outgoing messages. In addition, emails can be scanned for harmful virus content. The anti-spam measures are designed to block unsolicited email messages. To activate the SMTP proxy, select Proxies | SMTP from the NSM Web administration portal menu, and click Enable.
As with the other services, enabling the SMTP Proxy service is not effective until you configure the service according to your own network requirements. First you must add your SMTP domain (MX record) in the Hostname field, and for error reporting, enter a valid Postmaster email address, to specify where email alerts will be sent.
In a production environment, typically the MX record, defined in the authoritative DNS record for your Internet domain, will point to the external IP address of your firewall, allowing it to accept and route SMTP traffic to the internal e-mail server. If you are configuring this in a test environment, you may have to establish a test Internet domain with its own MX record, in order to effectively test the SMTP filtering features.
The “Allow relay from” field should only point to the internal email server, as well as any hosts that legitimately require SMTP relaying. It is imperative NOT to select “Any” on the “Allow relay from” field, as this will result in an “open relay” allowing any IP address to send messages through. Spammers are quick to discover open relays, and you could find your email domain suddenly listed in 3rd-party spam blacklists.
“Transparent mode” allows the SMTP proxy to operate without modifying any of the clients or server.
You can specify your email domains in the Domain Groups section, and then specify the internal email server in the Profiles and domain group assignment section.
Note that you will need to define the e-mail server address first in the Definitions menu, before it is available to be listed as the Route Target.
1. Select Definitions | Networks from the Web administration portal menu.
2. Click New Definition and add the Name, Type (Host), and IP address of the email server. Then it will be available on the Proxies | SMTP page.
3. From that page, you can select it as the Route Target.
Click “Enable” on the Spam Protection section to enable that service. The anti-spam engine uses heuristic and statistical checks, text, HTML, and URL syntax analysis as well as both header and body validation, and the anti-spam patterns are updated at regular intervals by the Up2Date service.
But just as we said about the Web Content Filtering, this is not an exact science. The anti-spam engine and pattern definitions are a “best effort” to attempt to reduce – not eliminate – the incidence of spam emails, while not blocking out legitimate emails that may resemble spam. Of course, one man’s spam is another man’s meat and potatoes, since there really can be no accurate, scientific definition of what is – and isn’t – “spam”.
To help you tune the anti-spam service, the Astaro/NSM allows you to set the thresholds – a scale of 1 to 15, with 1 being “fanatical” and 15 being “let it all come in” (my own definitions). The default thresholds for anti-spam are:
Threshold one: When Spam Level exceeds: 05 (reasonable) do this: Quarantine Threshold two: When Spam Level exceeds: 08 (conservative) do this: Reject
These settings probably work for most of the population. But if you find that you are getting too much spam with these settings, or if legitimate emails are being blocked as spam, you might have to tweak the settings one way or the other.
At this point, you might be impressed with how much there is to configure on the NSM – well, we’ve barely scratched the surface. As you become familiar with each of the features that NSM offers, and begin adjusting settings for Firewall, Intrusion protection, Virus protection, Spam protection and Web Filtering, you quickly realize that you could never remember all the settings that you’ve configured.
Hopefully, part of our network administration includes carefully documenting all of our security settings – at least, we hope to someday get around to that. But even if we did, and if because of some type of failure we needed to restore all of these settings on a new computer, we certainly wouldn’t want to have to manually reset all of them.
The Astaro/NSM allows you to quickly capture all of your current configuration settings to a file:
1. Choose System | Backup in the Web administration portal menu.
2. Click Start in the Create a Backup section to save the configuration file to the local computer.
3. To schedule the NSM to regularly e-mail the configuration file to any email address, click Enable (by the Send Backups by E-Mail option in the Advanced section), and supply a valid e-mail address.
If you need to completely restore the settings on the NSM, whether you’ve installed it on a new computer (for either a hardware upgrade or a replacement after a failure), or on the same computer, you can use the “Upload Backup File” option in the Restore a Backup section. This returns the NSM settings to exactly what they were from the time of the backup. This is extremely beneficial for recovery purposes – whether due to hardware failure, or if you’ve just really “screwed up” the settings and want to return to a previous, working state.
Implementing, replacing or upgrading a firewall, and especially a Unified Threat Management (UTM) device can be a daunting task. Most of us aren’t security experts, yet we might be tasked with network security responsibilities, just the same. Having the rich feature set as we see in the Astaro/NSM product can certainly be a great benefit, but having all of those options and settings can also present its own challenges.
There is definitely a benefit in having a lab network in which to test out our proposed solutions before we ever try to “go live” with them on the production network. This also gives us the chance to “learn the ropes” a bit, and take those theoretical ideas that we read about in the product manuals a little closer to reality – at least as close as we can get, in the lab environment.
In whatever product or solution that I would recommend to my colleagues or to my customers, I always want to take the “try before you buy” stance. Real IT solutions are rarely “off-the-shelf”, “plug-and-play” affairs – usually there’s quite a bit of customization and configuration that has to be done to suit the particular computing environment.
It is my hope that this article will help network administrators who need to implement network security solutions to get a start on testing and evaluating both their security needs and some security solutions. If you’ve read through to this point, then maybe it’s time you started to Test Drive Your Firewall Solution.
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.