Saturday, January 6, 2007

Intranet Security 101

This text is just a simple viewpoint on securing an internal network for today's increasingly hostile digital world.

We will cover simulated levels of an internal network from the following hierarchy (lowest to highest):

* Desktop PCs
* Mobile Devices (Laptops)
* Internal Servers
* DMZ Servers
* Gateways

Desktop PCs

Desktop PCs or simply PCs are usually the least secure computers lying around the internal network. They are not mission critical computers in a corporation; yet they usually hold important, private data which are personal to the members of the corporation. It would be horrendous to know that the 300-page proposal due in an hour's time got chomped up by a virus infection. Or your private and confidential report getting sent to all your address book entries by bad ol' Sircam who randomly picked your report for mass mailing. It's a bang-your-head-on-the-wall situation. In more exaggerated scenarios, crackers might be able to use PC's as a launchpad for Distributed Denial Of Service attacks.

Let's take a look at solutions we currently have at the PC level. Desktop anti-virus is a must in every corporation. Administrators must ensure that all PCs are installed with the latest anti-virus pattern on their anti-virus solution. The best practice method of disseminating virus pattern files across a large network of PCs is to have a central anti-virus server, push the pattern files to the PCs. With this method, administrators do not have to worry about lackadaisical users who do not update their pattern files in time. Viruses from mails, floppy disks or even CDs will be scanned upon entry to the desktop PC with the latest pattern files.

As for PC's turning into DDoS zombies, there is currently no popular solution to apprehend this problem at the desktop level. This is because it is very rare to hear PCs being zombified for DDoS activities. However, one cannot forego that possibility from happening in the near future due to controversial reports on raw sockets on desktop PCs. A new concept of incorporating IDS solutions on PCs might be the next generation of IDS solutions at the host-level (Host Intrusion Detection Systems).

An adequately secure PC of the future would be to have anti-virus software installed on it, a personal Firewall / IDS to monitor activities on the PC and an Emergency Response plugin to disconnect malicious activities.

As the bottom-most layer of an internal network's hierarchy, PCs are the last layer of defence before it hits end-users. It is therefore important to also deploy adequate security measures at this last line of defence.


Mobile Devices (Laptops)


Mobile devices include laptops, PDA's and cellular phones. The most common mobile device that gets plugged into an internal network is the laptop. Laptops are usually brought out away from the protection of the corporation's secured environment. This means that they are capable of bringing in "other life forms" into the internal network without getting filtered at the gateway level. Laptops also suffer the same problems PCs have; and the PC security solution discussed above must also be applied to laptops.

The extra security feature here that can be implemented with current technologies is to employ a Virtual Private Network (VPN) solution for these laptops. We must configure VPN client software at the laptops so that when they are out of the internal network's secure environment, they have to login to the corporation's gateway in order to be able to access the Internet. The VPN client can be installed in such a way that the laptop user can only connect to the Internet through the VPN gateway at the user's office, no matter where he or she is. This will restrict his access only through the secure environment his corporate network can provide; thus limiting his access to the allowed rules of his corporate network. To further enhance remote access to internal systems, authentication mechanisms can be used to add an extra layer of defence over the VPN scheme.

Like any security solution, there is always the yin and yang. On one hand, by restricting Internet access of the laptops to the corporate gateway, the laptops are adequately secured by the corporate's security infrastructure (firewalls, IDSs, anti-virus, etc..). On the other hand, it opens up an opportunity for crackers to backdoor their way to the internal network through a careless VPN client laptop user; and it has happened before.

One possible solution is to isolate an entire segment for VPN services away from the deeper, mission-critical network segments. Restrict VPN access for only explicitly defined services. Apply the same security solutions for a desktop PC as highlighted earlier in this text (eg. Desktop anti-virus, personal firewall / IDS, etc..). Another issue would be the application and bandwidth performance of a VPN client; where multiple layers of authentication, filtering, scanning, encryption and decryption will slow down the entire process of employing this solution.

Internal Servers

These are the mission-critical servers that hold the entire digital backbone of your company. Common servers in this category include application servers, database servers and other back-end servers. These servers are usually protected behind a firewall and are only accessible through legitimate system traffic from other servers and internal networks.

A typical example would be an e-commerce system where the web server at the DMZ will communicate with the internal application and database servers on specific ports for transferring data. Mail relays at the DMZ will talk to the internal mail servers for communication and vice versa. Proxy servers will be accessed by internal users to go out to the Internet and system developers would constantly need to access the web, application, database and other back-end servers for maintenance purposes. These cross-interaction between many network segments from the DMZ to the internal network and vice versa can create minute opportunities for intruders to access the internal network, if they manage to break into the DMZ segment.

Current solutions for this issue include fine-tuning and extreme tightening of firewall rulebases to ensure only truly legitimate traffic are being passed around from the DMZ to the internal servers. IDSs (host and network) will be strategically placed to monitor malicious activity. As most security-concious administrators already know, it involves a lot of work to monitor an IDS; let alone a firewall due to overwhelming logfiles. Therefore, a proper log management system must be employed to ensure a higher level of manageability to sipher legitimate and hostile logs. There are software currently that specifically handle log file management.

A newer twist would be a revolutionised way of storing log data; and enabling a practical method of accurately digesting the data into meaningful information using Artificial Intelligence. Anti-virus solutions for servers are currently available in the market; but the effectiveness of these products on various application servers are still debatable. For instace, anti-virus software consumes a reasonable amount or processing power and memory; and this puts a considerable amount of burden on heavy-running application servers.

One viable solution would be to configure and fine tune the anti-virus software to do periodic scaning instead of real-time scans; or if real-time scan is prefered, scan only objects and extensions that are most likely to contain viruses and not every single type of file. These approaches have trade-offs that the administrator must consider : security or speed?

For the more adventurous security freaks, decoy servers can be set up in the internal network to distract would-be crackers from damaging the original servers first. These decoy servers must be relatively easy to hack, so it would be more enticing to attack a vulnerable server than a secure one. I can safely say (in my humble opinion again) that 50% of all hacks will be at vulnerable servers first (these are from the amature script kiddies), and that leaves the other 50% for crackers who likes more challenging targets. However, these decoy tactics must be planned properly; or it will itself be a huge hole in your internal network. I have read about honeynets / honeypots being hacked into and further hacks being launched into the internal networks from the honeynets / honeypots. Unless you are a super administrator, don't try this in your network!

Security updates which include hotfixes, patches, service packs or whatever they call them must always be applied on these internal servers. These apply to updates at the OS level and ALL other software that run on the server. It is advisable to read the instructions for these updates first before applying them on your production servers. Sometimes, even when you follow the instructions faithfully, your server coughs up core dumps after applying the update. Some administrators will test the patch on a mirror production server first before applying it on the real server. Sometimes, the update will not work for your servers because it would crash the system. A dilemma here! A security hole but you cannot patch it! One article I read overcame this problem by creating an attack signature to block the particular hack at the IDS level. This way, the server do not have to be patched but the IDS will do the dirty job of blocking the hack. Another adventurous way I would suggest is to study and understand the nature of the hack; and then mannually configure and modify the offending vulnerability. If you can do this, give yourself a pat on the back and go ask for a half day off.

A strong point to note is to check for security updates everyday! Some software vendors have automated update checkers to check on servers which are not patched with the latest updates. These are useful tools which administrators can apply to ensure all their servers are not left behind the security trend.

The physical location of your internal servers must also be equally secure. No point securing it electronically but leaving it wide open for strangers to meddle. Be it a server farm, data center or Harry's store room, your critical servers must be secured by smart card doors, biometric devices and fireproof rooms / casings. If it is Harry's storeroom, get a strong padlock and chains; at least!

DMZ Servers

These servers are placed in the network segment that is accessible by the public / Internet. These are usually HTTP / web servers, FTP servers and Mail Relays that are the best points of intrusions because they are legitimate traffic in the firewall's eyes.

In other words, these are the most vulnerable servers to your network and must be protected at all costs! Even a simple web defacement without any penetration to your internal network will cost a bomb to thoroughly investigate and rebuild your image and credibility on the internet. Standard practices include tightening your firewall rules to make sure only legal traffic is allowed into the internal network servers, patching security holes and all the security guidelines listed for the internal servers above.

I suggest the minimalist methodology in configuring DMZ servers. If it is a web server, remove all other unnecessary services unrelated to web service. Specify also whichever functions, modules or plug-ins that are explicitly needed for the web server so that you do not have "extra" features installed unknowingly. This is especially true for a certain commercial web server that has as many holes as a swiss cheese. This methodology should apply for other DMZ servers as well. Less services equal more manageability and less headache.

I will now use web servers as an example for DMZ servers because web servers usually cause the most commotions when it gets hacked, compared to other DMZ servers. A host-based IDS should be installed on a web server to monitor suspicious activity and to react accordingly when an illegal modification is made in the server. For instance, if a web page is modified illegally, the IDS will detect and restore the original copy of the page in a matter of seconds. User defined reactions or events are an important part of an IDS and should be used as much as possible in designing a superior IDS solution. This concept can be used in other DMZ servers too.

All in all, DMZ servers must be properly secured, and a minimalist approach must be applied in its installation, configuration and deployment in the DMZ network segment.

Gateways

Gateways are usually placed right behind the router to route internal traffic in the internal network. Gateways usually are also firewalls that filter and defend the internal network from the internet and across its internal segments.

As the premier line of defence in the internal network, firewalls are always regarded as the "must-have" security component in every important network. Firewalls are also the first ones to encounter the raw and wild internet traffic being plundered at them. This is why the firewall must be hardened and secured to its maximum; or it will be the biggest hole in your network because of its ability to access every network segment of your internal network (in a standard firewalled network configuration). Therefore, the firewall must only do ONE thing; and that is to be a firewall. No other hanky-panky services should be allowed in the firewall box; and all non-related applications, services and programs should not be running in the background. The OS housing the firewall should be installed with the most basic system files and nothing else. These are the most fundamental rules in installing a firewall.

The firewall rules that are configured should be as concise, explicit and as direct as possible. A firewall policy must be properly enforced so that only legitimate personnel may alter the rules and not Harry who loaned you his storeroom. Rules should be the "deny all except those permitted explicitly" type of configuration. By properly regulating the firewall and not simply opening ports for conveniences will save your network from unforseen problems.

Bonus Text

Network traffic analysis is a good way of monitoring and understanding the normal flow of legitimate traffic. By collecting statistical data of the network traffic in an organisation, we can summarize a normal pattern flow of an average day's network traffic. The data collected can be translated into graphs or charts, and the results can be a good benchmark to compare extraodinary traffic, should an outbreak occur. During the recent Code Red outbreak, a security administrator who regularly analyzes his network traffic was stunned when his network graph became viciously abnormal. A sudden surge in HTTP activity within his network prompted him to check for the offending machines and he subsequently managed to cut them off the wire before things got any worse. And mind you, this happened way before any official report was out on Code Red. It was due to the security administrator's initiative to monitor his network activity that saved him from lots of dirty work. Network traffic monitoring and analysis is a good way of determining awkward network behaviour that are new; and especially on denial of service attacks.