Network Access Control Guide

Network access control Learning Guide SearchSecurity.com and SearchWindowsSecurity.com From PDAs to insecure wireless modems, users have myriad options for connecting to -and infecting -- the network. Created in partnership with our sister site SearchWindowsSecurity.com, this guide offers tips and expert advice on network access control. Learn how unauthorized users gain network access, how to block and secure untrusted endpoints, and get Windows-specific and universal access control policies and procedures. TABLE OF CONTENTS

Securing remote access points……………………………………….. 4 Book chapter: Remote access as an attack vector PDF: IPsec and SSL VPNs: Solving remote access problems Product review: 2006 Remote access Products of the Year Technical tip: A five-point strategy for secure remote access Technical tip: Remote user security checklist Technical tip: Five steps to controlling network access Technical tip: Secure data transmission methods Technical tip: How to stop a rogue user from circumventing network security Technical tip: Guarding against malware infection from remote users Technical tip: Remote network access from privately-owned machines Technical tip: Ten tips for safe computing on a public LAN

Endpoint security tactics………………………………………………21 PDF: Five best strategies for endpoint security PDF: Layered access control: Six top defenses that work Product review: Hot Pick: Fireball KeyPoint Product review: End of the line Product review: Hark! Who goes there? Technical tip: Effective endpoint security without a significant investment Technical tip: Painful patching: How to lock down networked devices Technical tip: The key to locking out mobile threats Technical tip: Tips for securing iPods in the enterprise

Network architecture controls………………………………………..35 Glossary definition: DMZ (SearchSecurity.com) Glossary definition: VLAN (SearchSecurity.com) Book chapter: Secure LAN switching (SearchSecurity.com) Expert advice: How to protect a LAN from unauthorized access (SearchSecurity.com) Expert advice: Designing DMZs with various levels of access (SearchSecurity.com) Technical tip: Using 802.1X to control physical access to LANs (SearchSecurity.com) Technical tip: Life at the edge: Securing the network perimeter, Part 2 (SearchSecurity.com) Technical tip: VLAN security (SearchSecurity.com) Technical tip: Popular VLAN attacks and how to avoid them SearchSecurity.com Copyright TechTarget 2006

Firewalls………………………………………………………………46 Product review: 2006 Network Firewall Products of the Year Technical tip: How to choose a firewall Technical tip: Choosing the right firewall topology Technical tip: Placing systems in a firewall topology Technical tip: Auditing firewall activity Technical tip: Activating an XP firewall on a LAN Technical tip: Traffic flow considerations for the Cisco PIX Firewall Technical tip: Firewall security tips Technical tip: Firewall redundancy: Deployment scenarios and benefits

VPNs…………………………………………………………………...61 Glossary definition: SSL Glossary definition: IPsec Book chapter: Crypto basics: VPNs Product review: SSL VPN: AEP SureWare A-Gate AG-600 Product review: Corrent VPN 'connects' with Check Point software Quiz: SSL vs. IPsec VPNs Technical tip: Letting telecommuters in – Your VPN alternatives Technical tip: The inherent capabilities of IPsec selectors and their use in remoteaccess VPNs Technical tip: VPN fast facts: True or false? Technical tip: Client-side security considerations for SSL VPNs

Windows-specific network access control procedures……………...76 Book chapter: Access control entries Book chapter: Six steps for deploying Network Access Quarantine Control Checklist: Hardening Windows School: Advanced checklist on network access quarantining Checklist: Harden access control settings Expert advice: Security risks associated with granting permissions in Windows XP Expert advice: How to deny access when connecting to a share on a Windows 2003 Server Expert advice: How to detect when non-domain laptops are plugged in to Windows Server 2003 Expert advice: How to set up dual administrative controls for tighter security in Windows 2000 Expert advice: How to remove specific permissions from an account operator in Windows 2000 Expert advice: How to check which permissions are assigned to a user or group in Windows 2000 Expert advice: How to set NTFS permissions on Windows 2000 Terminal Services Expert advice: Limiting user and admin access Opinion: Network admins needs Microsoft-Cisco unity SearchSecurity.com Copyright TechTarget 2006

2

Step-by-Step guide: Network Access Quarantine Control Technical tip: Lock down user access and privileges Technical tip: Permissions basics for Windows 2000 Technical tip: NTFS default permissions for Windows 2000 Technical tip: How to implement permissions in Windows 2000/NT

Network access control policies………………………………………124 Expert advice: Distinguishing a remote access policy from a portable computing protection policy Technical tip: Policies for reducing mobile risk Technical tip: Laptop security policy: Key to avoiding infection Technical tip: Work with users to secure new technologies in the enterprise Technical tip: The benefits of writing a policy before a new system deployment Technical tip: Managing network policy Technical tip: Top 10 network security tips

SearchSecurity.com Copyright TechTarget 2006

3

Securing remote access points Book chapter: Remote access as an attack vector 16 Jun 2005 | Larstan Publishing In this excerpt of Chapter 7 from "The Black Book on Corporate Security," authors Howard Schmidt and Tony Alagna analyze how "unmanaged" remote access can serve as an attack vector. There are many different types of remote access solutions for mobile employees. There is SSL VPN, which is a Web-based VPN device. There are also different types of Webmail as well as Outlook Web Access. Also, some bigger companies like Citrix have secure gateways. Classic IPsec VPNs, as well as different types of portals and intranets and extranets, can also be used for mobile computing. The quality that all remote access has in common, regardless of the method used, is that it is an endpoint machine and is as vulnerable as any other system on the Internet. In some cases, they are managed machines — a corporate issued asset that is managed by the corporate IT that has all of the corporate security provisioned security programs. Corporate resources can now be accessed from anywhere, with most places far from trustworthy. The danger here is extreme, because mobile computing environments plug into random places and in unmanaged systems. Vendors are aware of this security threat, and they're increasingly recommending the deployment of different types of security and scanning technologies. The problem is that most security technologies are not readily deployable. Antivirus is a very large application, so it is not practical to have anyone who is logging-in remotely to download this software and then scan the hard drive for half an hour before they can access email. Antivirus-type technologies in the "unmanaged space" must be behavioral, small, fast and transactional. Some are emerging in the marketplace. However, the vulnerability in this mobile communication model is obvious. Besides the general threat of malicious code, these machines have no physical access restrictions. Anybody can load whatever they want on it (the risk of a keystroke-logger, regardless of whether it has network connectivity, is huge). A person can walk up five minutes before it was used and five minutes after it was used and capture everything that was done on that machine between those two time points. Insider Notes: Corporate resources can now be accessed from anywhere, with most places far from trustworthy. The danger here is extreme, because mobile computing environments plug into random places and in unmanaged systems. Vendors are aware of this security threat and they're increasingly recommending the deployment of different types of security and scanning technologies. The threat of malicious code is even greater in this unmanaged machine space. Sometimes the people using IPsec VPNs feel safe because this technology prevents splitSearchSecurity.com Copyright TechTarget 2006

4

tunneling (the ability for two or more applications to be communicating simultaneously while the VPN connection is going). Preventing split-tunneling only creates an illusion of safety. A reverse-connecting Trojan functions in the same way in this environment as it does in a corporate environment, by initiating its connection sequence inside out. So, if users can see the Internet, then so can the malicious code. Even without Internet access, malicious code can be scripted to steal or perform actions whenever it comes back online. Malicious code is basically winning in every environment regardless of the situational defenses. All situational defenses can do is minimize the types of attacks; it cannot stop attacks. 2006 Remote access Products of the Year 02.01.2006 | SearchSecurity.com VPN 3000 Series Concentrators Cisco Systems, www.cisco.com With the proliferation of laptops, PDAs and other mobile devices requiring access to the corporate network, a VPN purchase is no longer an impulse -- it's an imperative. The offerings have mushroomed, particularly SSL VPN products, forcing IPsec-dependent market leaders to broaden their scope. Included in this wave are Cisco Systems' VPN 3000 Series Concentrators -- a smart move judging by the number of readers who raved about its endpoint security and ease of use. For this reason, the Concentrators were awarded the gold medal in remote access. "Concentrators have proven to be the most compatible and secure, and provide the best ease-of-use out of all the remote access devices I have encountered," wrote one enthusiastic user. Others who helped make the series' six models collectively tops were especially pleased with the Concentrators' security, including their firewall capabilities through stateless packet filtering and granular access control. The majority also gave their thumbs-up approval to the wide range of features, documentation and vendor support. "An excellent tool," said one user. Scalability is a strong driver. Cisco VPN 3005 and 3015 are designed for small- to mid-sized enterprises, promising between 100 and 200 simultaneous IPsec sessions, or 50 and 75 WebVPN sessions. The 3020 and higher are geared more toward larger companies, supporting up to 10,000 IPsec, or 500 clientless sessions running concurrently in the 3080 model. A big plus, according to users, is the VPN series' versatility. Recognizing that SSL VPN providers were gaining market share, Cisco made sure its 3000 series offered both IPsecand SSL-based connectivity on a single platform. This allows almost any device within SearchSecurity.com Copyright TechTarget 2006

5

the corporate network to establish an end-to-end secure connection using public networks. In addition, customers like how easily the Concentrators can be managed through their simple Web-based interface to configure mobile devices and monitor all remote-access users. That includes pushing policies and updates through the VPN to users and then scanning for continued compliance before a machine is allowed on to a network. Some respondents were glad to discover that the VPN 3000 Concentrators work well with other applications. "[We] rarely have problems with these devices," one user wrote. Another summed it up this way: "[Concentrators are] just plain easy." VPN-1 Check Point Software Technologies, www.checkpoint.com This is the other half of the medal-winning Check Point package (with FireWall-1). One user calls it "the most compatible, secure remote access device." It wins high praise for security, performance and overall quality. VPN Gateway Nortel Networks, www.nortel.com "Stable, reliable, robust. Just keeps working." VPN Gateway users particularly like its performance and give it consistent "excellent" ratings for security. A five-point strategy for secure remote access 25 July 2005 | George Wrenn | SearchSecurity.com Managing secure remote access is a tough job. Because remote systems may directly connect to the Internet rather than through the corporate firewall, they pose an increased risk to your network environment. Virus and spyware protection, and a general VPN network policy isn't enough to keep these systems -- and the network they connect to -safe. Here are five best practices for providing secure remote access. 1. Software controls policy Create a policy that defines the exact security software controls that must exist on systems with remote access. For example, you may need to spell out that antivirus, antispyware and desktop firewalls must be installed and configured in a specific manner with the latest signatures, along with which vendors are acceptable. The best practice is to distribute the policy along with the connection setup or similar instructions for end users. Often a zero-tolerance policy is best for endpoint security. End users should meet a set of guidelines before connecting to the network. No AV, antispyware and desktop firewall? No remote access allowed. The policy should also spell out what ports and services may be exposed on the system. SearchSecurity.com Copyright TechTarget 2006

6

2. Endpoint security management Choose a vendor that offers comprehensive endpoint security management and policy enforcement as part of their VPN or remote access solution. It is best to mandate that all remote users use the enterprise sponsored VPN client. That's the only way you are going to get true policy compliance and assurance of endpoint security posture. Your chosen remote access solution should be able to refuse connections for endpoint systems that do not meet the policy compliance checks. Ideally, the solution should tell end users which items are out of compliance so they can remediate the situation prior to attempting to reconnect. This cuts down on help desk calls. 3. Enforce corporate policy compliance Inform end users that corporate security policy extends to their remote desktop when connected to the enterprise network. For example, no file sharing and other disallowed use while connected to the corporate network. 4. Reporting features Reporting on end user compliance is critical. Most of the solutions mentioned above offer reporting capabilities to keep admins updated on the status of the connecting endpoints. Depending on the number of users you have to manage, it may be wise to set up alarms that email admins when a machine that is significantly out of compliance tries to connect. In some cases administrative intervention may be warranted -- especially when other access methods to the network may exist. 5. Periodically review policy and reports Every couple of months, review policies and reports to identify trends and patterns in access violations. This is important to ensure that the policy and technical controls are addressing your remote access security needs. If you find trends in access violations, add or modify policies accordingly. About the Author: George Wrenn, CISSP, ISSEP, is a technical editor for our sister publication Information Security magazine and a security director at a financial services firm. He's also a graduate fellow at the Massachusetts Institute of Technology. Remote user security checklist 22 Nov 2005 | Kevin Beaver | SearchWindowsSecurity.com At some point in time, odds are you've had remote users connecting to your network. Telecommuting has several proven productivity and environmental benefits, but it doesn't come without its drawbacks -- mostly in the form of information security risks. What happens if your remote users' computers have viruses or they transmit sensitive emails and instant messages over an unsecured wireless link? How about when systems that aren't properly protected can connect directly to your network -- thus offering a direct inbound link to anyone wanting to get inside and poke around maliciously.

SearchSecurity.com Copyright TechTarget 2006

7

Arguably, many bad things can happen. Unauthorized information access can take place, information leakage can occur, and there's always a possibility that malware can seep in through your otherwise hardened network border. Before you create any new policies or lock down your remote systems, it's very beneficial to determine which remote access vulnerabilities currently exist in your environment. Doing that not only finds missing patches, but it also digs in deeper to find misconfigurations, unnecessary shares, null session connections and other exploitable vulnerabilities you would not otherwise be able to dig up easily. I suggest you use a vulnerability assessment tool such as Tenable Network Security's NeWT, GFI Software Ltd.'s LANguard Network Security Scanner, Qualys Inc.'s QualysGuard. Use one (or more) of these tools on your internally supported images for laptops and desktops and, if it makes sense, test remote systems owned by your users as well. If the latter is not an option for political or resource limitation reasons, you could easily document instructions for your remote users to do it themselves. Consider having them install and run the Microsoft Baseline Security Analyzer (MBSA) on their systems and sharing the reports with you. You could even automate this via login scripts and/or Group Policy in Windows. Remember, there are reasons your organization's assets must be protected. Once you've determined where your weaknesses exist and have addressed the issues, use the following checklist of common and not-so-common security safeguards to be sure you've got your remote systems locked down: 1. Ensure that personal firewall software is installed (Windows Firewall in XP SP2+, BlackICE and so on) and at least provides inbound protection -- outbound application protection is nice, especially if you can configure it so your users aren't hindered by the constant outbound connection requests. 2. Require malware protection (antivirus and antispyware) on every system and ensure that updates are being applied in real-time if possible to prevent unnecessary infections. 3. Enable strong file and share permissions on remote hard drives and other storage devices -- especially on Windows 2000 and NT systems that allow everyone full access by default. 4. Have a written policy and documented procedures in place for managing patches. For example, enable real-time Automatic Updates or roll out patches using an existing patch management system. 5. Disable null session connections to prevent the unauthorized gleaning of user names, security policy information and more from remote systems. 6. Implement a VPN (the free Windows-based PPTP is a decent option) or make sure you're running a secure alternative connection such as Windows Remote Desktop or Citrix. SearchSecurity.com Copyright TechTarget 2006

8

7. Remember to include remote users, computers and applications in your security incident response plan and disaster recovery plans. Those are common oversights that can rattle your nerves if they catch you off guard. 8. Your users will likely download and install IM, P2P and other applications that you can't support or otherwise make you nervous, so be prepared to prevent it in the first place via accounts with minimal privileges (think Windows Vista new feature) and periodic scans of systems looking for such software. Or, standardize on a small number of applications you can manage comfortably. They're going to do it anyway, so the latter option might be the easiest. For systems configured to use 802.11-based wireless (or ones that may be used as such in the future), don't forget the following safeguards: 1. Enable WEP at a minimum since it's a lot better than nothing, but ideally have users enable WPA2-PSK with strong (20+ random characters) pass-phrases. 2. Require your users to use directional antennae instead of the omni-directional ones that come stock on practically all APs. 3. Enable MAC address controls, which help keep non-techies from snooping or accessing your network (techies know how to spoof their MAC addresses to get around this). 4. If possible, require a specific vendor/model of AP and wireless NIC to ensure they're hardened consistently according to your standards and so you can stay abreast of any major security alerts and necessary firmware or software updates. 5. Remember that users may connect to your network via public hotspots, so make sure you and they understand the security implications and have the proper safeguards in place. 6. Enable secure messaging if a VPN or other hotspot protection is not available via POP3s, SMTPs, Webmail via HTTPS and other built-in controls. 7. Disable Bluetooth if it's not needed. Otherwise, it's too risky by default so lock it down. These relatively simple and mostly free remote access safeguards, combined with a reasonable information security awareness program, will go a long way toward securing your offsite computers and protecting those things you cannot afford to lose. About the Author: Kevin Beaver is an independent information security consultant, author and speaker with Atlanta-based Principle Logic LLC. He has more than 17 years of experience in IT and specializes in performing information security assessments. Beaver has written five books, including Hacking for Dummies (Wiley), Hacking Wireless Networks for Dummies and The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach).

SearchSecurity.com Copyright TechTarget 2006

9

Five steps to controlling network access 16 Nov 2004 | Wes Noonan | SearchWindowsSecurity.com Wes Noonan, author of Hardening Network Infrastructures, reviews steps you can take from both a Windows and network perspective to protect your data regardless of what is occurring at the network perimeter. One common security mistake is to treat the network and applications as separate entities that never interact. You may have separate people maintaining them, separate security policies, separate procedures and so on. Hardening Windows servers will go a long way toward protecting the integrity of the data on those servers, but you must also harden the network infrastructure itself. Start by taking the following five steps. 1. Implement access control lists (ACLs) If someone can get inside your network, they can gain access to your Windows systems. You need to implement strict ACLs on your network equipment and grant access only to those users that require it. For example, do users in Houston ever need access to systems in New York? If not, chances are the traffic passing between those systems isn't essential to the business. 2. Implement network-based access control (NBAC) Connecting systems to the network used to be a hassle: You had to build the network drivers, assign addresses and physically connect systems to get them to talk. Although this made it difficult for unauthorized systems to easily connect to the network, it created excessive administrative overhead. Then technologies like star-wired networks and Dynamic Host Configuration Protocol (DHCP) made it exceedingly simple to connect systems to the network. At first I rejoiced! But now I realize anyone can connect to the network. In fact, approximately 90% of the customers I visit have live network jacks that I can easily plug into to gain network access even if they have some written policy that states unauthorized connections are not permitted. NBAC seeks to provide an enforcement mechanism to support those written policies. With NBAC, you want to define what is an authorized user and ensure connected systems are running the appropriate patches and software versions. If they aren't, they are placed in quarantine until the system is patched or updated. 3. Restrict remote connections Implementing a VPN can be a risky endeavor. It permits network access for both users and viruses. Instead of allowing VPN access to your entire network, implement network ACLs that restrict remote users only to the servers and resources they need. For instance, using a VPN to connect Citrix or Terminal Server farms ensures that the only traffic allowed through the VPN is the Citrix traffic to the Citrix servers; if a remote client's system is infected, it will not infect your network. SearchSecurity.com Copyright TechTarget 2006

10

4. Restrict and secure wireless connections If implemented behind your firewall, wireless LAN connections create a particularly large, gaping hole in your network perimeter. As a result, your wireless LAN connections should be treated like any other remote connection: Terminate them outside your firewall and require a VPN connection to gain access to internal and protected resources. 5. Implement IPsec Implementing IPsec on your network is a great way to protect data in transit from being compromised. But it's no panacea. For example, if a machine is infected with Slammer, IPsec will only ensure the Slammer traffic is encrypted before it is transmitted. When used in conjunction with the other hardening methods, however, IPsec can serve as an effective method for protecting your internal traffic from prying eyes. Due to network de-perimeterization, you can no longer rely exclusively on the network perimeter to protect systems and data. Removing the perimeter entirely is not the solution, nor is hardening the perimeter alone. You must also harden your Windows systems and network infrastructures to protect data in the event that the network perimeter fails or is circumvented. About the Author: Wesley J. Noonan has been working in the computer industry for over 12 years, specializing in Windows-based networks and network infrastructure security design and implementation. He is a senior network consultant for Collective Technologies, LLC (www.colltech.com). Wes recently authored the book Hardening Network Infrastructures for Osborne/McGraw-Hill and previously authored a chapter on network security and design for The CISSP Training Guide by QUE Publishing. Secure data transmission methods 17 Jan 2006 | Chris Apgar | SearchSecurity.com A significant issue facing security professionals, especially in healthcare organizations, is the secure transmission of confidential and proprietary information, and protected health information (PHI). When many organizations think of secure transmission, the conversation generally turns to encryption and encrypted email. While this tip touches on email security, you can find more in-depth information in Email Security School. The main purpose of this tip is to explore secure data transmission options that are available to help meet regulatory and legal requirements. The HIPAA Security Rule, references secure transmission and the use of encryption. Although the Rule does not require the use of encryption, it's included as an "addressable" implementation specification. In other words, a healthcare organization covered under HIPAA has three choices: implement the specification as it appears in the Rule, implement an alternative that is equivalent to the specification or document why the specification is not applicable and therefore is not implemented. SearchSecurity.com Copyright TechTarget 2006

11

Given the availability and affordability of encryption technology today, it is difficult for a healthcare organization to justify not using some form of it when transmitting PHI. A number of vendors offer a variety of reasonably priced encryption hardware and software, as well as outsourcing options. Now we'll review the options in more detail. Email encryption A number of vendors offer products that encrypt email messages, are easy to use and provide the ability to send private data, including email attachments, securely. The recipient can respond using the same encryption method. Many of these products are Web-based. They work by sending a link to the recipient, who then clicks on it and logs on to a secure email server, which the organization either owns or outsources to an appropriate vendor. The recipient is then able to read the email and any attachments securely, and send a secure response including attachments if needed. There is also non-Web-based technology that allows transportation of secure messages from one person or organization to another, the most common of which is public key infrastructure (PKI). PKI requires an exchange of keys used to unlock the encrypted file. For example, Bob wants to send a secure email to Sue, so he gives her a copy of his public key to open his encrypted message. Bob retains the private key he used to encrypt the message or file, which he can also use, especially with a digital signature, to authenticate himself as the sender. A digital signature is a small electronic file that is unique to each sender and specifically authenticates his or her identity. In many states, a digital signature can be used and is enforceable to the same extent as an original signature on a contract or other legal document. There haven't been any large PKI deployments as of yet, mainly due to it being cumbersome, and the difficultly of administering and managing keys. However, PKI has been successful with small deployments and is frequently used for sending large files between organizations such as health plans and healthcare clearinghouses. One method of secure data transmission often used in conjunction with PKI to encrypt and authenticate large data files, is secure file transfer protocol (FTP). However, it is not used for transmission between individuals. The technology is readily available and recommended for organizations transmitting large amounts of data, such as claims transactions and electronic remittance advices through clearinghouses. Web site encryption Organizations that use the Web to collect and transmit sensitive data to customers or other organizations need to secure their Web site. The general standard is the use of secure socket layers (SSL), which encrypts data transmitted via a Web site. Upon opening an Internet browser, an open or closed lock appears in the lower right hand corner of the Web site. If the lock is closed, it means the data transmitted over the Web site is secure, generally by SSL. This allows the transmission and collection of private data over a Web site, without worrying about a hacker accessing it. There is no such thing as security without risks, but the use of SSL and secure Web sites when transmitting data significantly reduces the risk of it being inappropriately intercepted. Secure Web sites can SearchSecurity.com Copyright TechTarget 2006

12

be established by using internal Web analysts/programmers or working with a vendor who has expertise in creating an appealing and secure Web presence. Application encryption Some organizations transmit data between applications, such as an electronic health record. It is wise to view such transmissions, if the data travels outside an organization, as any message sent over the Internet, meaning it's subject to interception and, unless properly protected, misuse. When transmitting sensitive data between applications, it is sound and good security practice to evaluate the encryption capabilities of the application(s) and implement an encryption solution beforehand. An organization can obtain this technology from the vendor that manufactures the application or a customprogrammed product that accommodates application functionality while protecting the data as it travels from one point to another. Remote user communication Remote users present an additional security risk, because they are often communicating between their home and an organization. This means they not only need to be aware of secure data transmission requirements, but also other information security risks associated with remote access to confidential information. To secure communication with remote users, install a virtual private network (VPN), which encrypts all the data sent between its users. This technology is readily available on the market, and it is advisable that organizations with remote users install it. If a VPN is not established and a modem is not in use (which is generally not an efficient method of accessing a company network), all data transmitted over the Internet is subject to interception and inappropriate use. Laptops and PDAs These portable devices can be easily lost or stolen. Therefore, it is wise for organizations using these devices to transport confidential information to encrypt the data stored on those devices. This protects the organization against inappropriate data disclosure if the portable device is lost or stolen. Encryption programs are available for portable devices and the cost of such software is reasonable and affordable, even for smaller organizations. Wireless networks Wireless threats are on the rise and unsecured wireless networks are significant points of vulnerability and open up organizations to easy hacker access. Therefore, it's becoming increasingly important, to prevent access by anyone not authorized to access the network. Also, encrypt all data transmitted between wireless devices to prevent inappropriate disclosure of confidential information. Laptops connected to wireless networks are becoming more common, especially in hospital emergency rooms where medical and health insurance information is collected. These laptops communicate with the organization's wireless server and update applications, health records, etc. This data is generally sensitive and needs the extra layer of protection that encryption provides. About the Author: Chris Apgar, CISSP, is president of Apgar & Associates, LLC and former HIPAA Compliance officer for Providence Health Plans in Oregon and SW SearchSecurity.com Copyright TechTarget 2006

13

Washington. He is a nationally recognized data security, privacy, transaction and code sets, regulatory and HIPAA expert. He is a member of the HIPAA Compliance Insider Advisory Board, the Security Compliance Insider Advisory Board, the URAC Privacy Advisory Committee, and chairs the Oregon and SW Washington Healthcare, Privacy & Security Forum and the Forum's Transaction & Code Set Workgroup. Mr. Apgar now operates an independent consulting firm specializing in security, privacy, HIPAA, global and detailed business process review, information systems project development, and lobbyist activity. How to stop a rogue user from circumventing network security 15 Nov 2005 | ITKnowledge Exchange | SearchSecurity.com The following question and answer thread is excerpted from ITKnowledge Exchange. A user identified as Mouse 3333 posed this question: We have a rogue user who knows more than she should. She can grant herself and others the authority to access secure files. How can we monitor her activity to review what she has done? We believe she is using several different user IDs. We have come across a couple and have changed those passwords. Is there anything else we can do to stop her? A user identified as Layer 9 advised: There are some products that allow you to restrict users internally, but you really have to know what you are doing to use them. In order to stop this power user from circumventing your network's security, you will need to bring in a security consultant, because it is clear that this user knows more than you do about network security. Other than hiring a consultant, there are some technical steps you can take as well. Assuming your Layer 2 network is a Cisco or other SPAN-compliant vendor, doing the following will likely reveal what she is doing: 1. Trace back from the desktop to the actual switch port her workstation is connected to. If you don't have a current wiring diagram or a coding system, you can use a cheap toner to trace back to the switch. Then trace back your own desktop to the switch as well. I am assuming they are plugged into the same switch, if not you'll want to plug a laptop in from inside the wiring closet. 2. Once you have the port number on the switch, log on to it, enable SPAN and set the port you are plugged into as the Monitor Port. Then set the port that the suspect's system is plugged into as the Monitored Port. 3. At this point, download Ethereal, (you can also use Sniffer or Etherpeek if you have it) and install it on the desktop. Set a filter in your protocol analyzer to filter to all other systems on her MAC or IP. Examine what the packet captures about the activity between the suspect and the logon servers – particularly, with the system or systems where the accessed files are stored. These packet captures will show you what she is doing to get in or at least point you in the right direction.

SearchSecurity.com Copyright TechTarget 2006

14

If you don't have a switch that supports SPAN, it's time to upgrade the network. If what I suggest sounds foreign, then you should consider hiring a consultant. A user identified as Solutions1 advised: First, make sure your procedural and policy ducks are in a row and carefully adhere to those guidelines. Second, evaluate your priorities. If you suspect that that one end user acquired "super user" access, then perhaps your priority should be to rebuild your access control structure, because one "known" violation suggests that there could be others. Third, get management support at an appropriate level before you proceed with your capture and detection measures. A user identified as Bobkberg advised: Here are some other steps you can take to mitigate this risk: •

If you are in a Windows environment, list out all of the members of the administrators group and check their login history. Turn on security auditing for logins and for system/file/folder access for likely machines -- then check regularly.

•

If you are in a Unix/Linux environment, check all user and group IDs for root equivalence or root group membership. If you learn more about the initial situation, regularly check for login time/date as well as where it occurred. If you are using Network Information Service, check all user IDs there also.

Here is the bottom line -- if you don't receive management's support, email them about the matter clearly and keep their response. It will be your "Pearl Harbor" file. A user identified as ChinaBJ advised: I suggest you use a combination of IT rules and technical methods to prevent this from happening again. Seek help from top management personnel to establish and implement IT rules. As far as technical methods are concerned, you can install a remote control client on the suspect's computer from the server and log her actions. If you have Windows 98 sharing, stop it. It is also necessary to stop Windows 2000 server's support for previous Windows authentication. Third, you should implement IPsec to encrypt the communications that take place on your server. A user identified as This213 advised: I agree with Layer9, you should consider hiring a security consultant. I also think she may have gotten her hands on someone's password. While you have received some sound advice, I find it interesting that there has been no mention of the authentication mechanism in use or what OSes and other resources are involved. There may be options available to you that would not require approval from anyone (depending on your role and your company's policies). Once you know what resources have been accessed -- whether they are files in a file system or user changes in Active Directory -- you should be able to trace those who have accessed them. If you're not logging accesses to resources, I strongly encourage you to. If SearchSecurity.com Copyright TechTarget 2006

15

you're in a Windows environment, there are tools for this. If you're in a Unix/Linux environment, the tools are most likely already in place. I suggest you have your network penetration tested, both externally and internally, even if it does turn out to be just a corrupted password. You never know how strong something is until you try to break it. Plenty of companies out there do this. Also, make sure you document everything. Create a situation file, collect hard copies of all the logs about the affected systems, and place them in the file. Then, document your actions to remedy the situation and put that in the file. Send emails to your superiors and detail the situation as best as you can. Inform them of the file and its location, and explain how they can view a *copy* of its contents. Place the emails that discuss the situation into the file as well. Note that I said a *copy* of the file, always follow the maxim: CYA. Finally, make sure that anyone (management, auditors, etc.) can access the file, so they can read about the entire situation themselves -- as Bobkberg said, it's your "Pearl Harbor" file. A user identified as SidZilla advised: Don't overlook the non-technical solutions. I would make sure HR is on board with the fact that circumventing security is a fire-able offense, then take the offending employee to HR and ask her what she is doing, how she is doing it and most importantly, why she is doing it. If she doesn't answer all three and agree to stop, fire her on the spot. Guarding against malware infection from remote users 2 Sept 2004 | Ed Skoudis, CISSP | SearchSecurity.com So, you think you've got your malware defenses up to snuff, right? Antivirus tools on the mail gateway? Check. AV deployment on all company-owned desktops and laptops? Check. Firewalls blocking all services except those with a defined business need? Check. Thorough malware defenses against infected telecommuters using the VPN from their laptops, home desktops and even handheld devices? Um … well, … Sadly, many organizations today haven't adequately addressed the potential for malicious code infection via telecommuters. Often, a home user gets infected by some pathogen on the Internet and then sets up a VPN connection to the corporate network. Once connected, the infected home system acts like the Typhoid Mary on the internal network - spreading the malicious code and bypassing your perimeter defenses, including Internet firewalls. How can you stop this plague in your environment? The solution requires both policy and technology. Make sure to define policies that require home users to keep up-to-date AV tools installed on their systems, regardless of whether the machine is owned by the user or the company. In today's new-worm-every-day world, require that the AV tool be configured to automatically download new signatures each day and define specific penalties for disabling the AV tool and its update capabilities. SearchSecurity.com Copyright TechTarget 2006

16

Also, specify in your policy that the corporation reserves the right to search the computers of any VPN users across the network, again, regardless of whether the system is owned by the employee or the corporation. Employ a warning banner to launch during the VPN login that requires users to click "OK", acknowledging that their personal systems could be searched remotely when an incident occurs. Enlisting permission from the system owner -- the employee, allows your incident-response team to legally conduct the analysis required to address the problem. Without this policy and warning banner, you have no business searching an employee-owned machine. Alternatively, you can create a policy that limits VPN access to only corporate-owned computers. Of course, your company will need to purchase machines for all telecommuters, so make sure the budget can adequately afford you going that route. Fortunately, many VPN gateways now offer the capacity to interrogate the client to ensure the host system is running an active AV tool with up-to-date signatures and a personal firewall. Activate these capabilities if your infrastructure supports them; Users wanting access to the corporate playground, first must prove they won't infect the other kiddies. Also, make sure your VPN gateway passes all traffic through a firewall that performs comprehensive filtering -- only allowing access to absolutely required services and only to those servers that each remote user needs. Furthermore, consider deploying network-monitoring tools, including network-based intrusion-detection and intrusionprevention systems, on network segments associated with the VPN and filtering devices - this will enable you to detect and thwart attacks early. About the Author: Ed Skoudis, CISSP, is cofounder of Intelguardians Network Intelligence, a security consulting firm, and author of Malware: Fighting Malicious Code (Prentice Hall, 2003). Remote network access from privately-owned machines 25 Aug 2004 | Mark Mellis | SearchSecurity.com IT managers are under increased pressure to provide broad remote-access capabilities. User communities range from casual "day extenders," who only need access to their email and the corporate Web portal from their family PC, to full-time telecommuters who use core applications and IP telephony. Because they depend upon remote access for all their work, companies usually don't have too much trouble justifying high-end solutions for the full-time telecommuter by providing them with a company-owned computer, firewall and 24x7 help desk access. But how can we effectively (and affordably) support the low-end needs of other users? The upside of allowing users access from their own computers and network connections is attractive. Often, remote users don't even want a company laptop -- too much to lug around. Besides, the family system is likely faster (designed for the kids to blast alien spacecraft with). However, it's the downside that we need to consider.

SearchSecurity.com Copyright TechTarget 2006

17

Risks are proportionate to access provided Users who have full network access to internal enterprise LANs can inflict much more damage than those who can only use webmail. So, the first step in your strategy entails providing tiered access, appropriate to the needs of each user. Many companies can get by with two or three tiers, with webmail at the low end, file and Web application access in the middle, and full VPN connectivity at the top. Training End user security education is essential for successful remote-access programs. It should play a prominent part in your ongoing security education program. You can use online programs on the company intranet. Make sure that you track completion and require periodic refresher training. Try awarding a gift certificate to someone selected from those who took the course to give users a positive incentive for completing their mandatory training. The curriculum should include information on the hazards of active content, including viruses, worms and spyware. Make the point that this instruction will help them protect their own data as well as that of the company. Also include information on password hygiene and what to do in the event that they suspect an incident might be in progress. Don't forget to include requirements for access to company information. Authentication You have to know who someone is before you allow them access to any service, including webmail. Typically, we use user names and passwords to provide authentication, which are vulnerable to interception and compromise. Educating users about password hygiene and protecting passwords in transit with encryption used to be adequate, but with today's spyware and keystroke sniffers, two-factor authentication with hardware tokens is practically mandatory for all remote users, even those with low-end privileges. If you choose to stay with usernames and passwords, make sure that you don't set yourself up for a denial-of-service attack. Do you use your internal domain authentication source for remote access and automatically lock out accounts after a certain number of failed login attempts? If manual intervention by an administrator is required to restore an automatically locked-out account, your systems are vulnerable. It's a simple matter for a disgruntled employee sitting at a cyber cafe to go down the company directory typing three bad passwords for every username on the list and lock out the whole company, internal as well as external. It's much better to use separate authentication sources for external services or to only lock out accounts for a short period of time. Even lockouts as short as five minutes will protect you from dictionary attacks. Authorization Appropriate access to internal resources is key. If you have an existing data inventory and authorization model, it will pay off. If not, you need to identify your information assets and how they are classified. The best SSL VPN and gateway products have rich accesscontrol models, but they won't do you any good if you don't know which users should have access to which data and where the data is stored. If you haven't classified your data, this could provide the motivation to start. SearchSecurity.com Copyright TechTarget 2006

18

Active content control Viruses are the scourge of the decade and like all effective security programs, virus control should be layered, starting at the edge of the network. Of course every computer should have antivirus software installed and maintained. Here's another place where you can provide an incentive for good security practices: consider providing antivirus software to your end users for free or at a discount. You may not want to use the corporate edition that you deploy internally, since that would increase your support burden, but you can still provide the consumer editions to your day extenders. Of course you will want to ensure that users renew their subscriptions each year, so consider including the renewals in your program. Don't forget to protect the systems used by the full-time telecommuters as well. Personal firewalls Personal firewalls are very common in full VPN environments, and can be useful even for day extenders using webmail, because they can help block spyware back channels. You may elect to subsidize their use in a manner similar to that discussed for antivirus software. Information leaks Every time a browser loads a clear text Web page, a copy of the page is made in the browser's cache. Likewise, pathnames and other parameters can be captured by the browser's history feature. And end users often download email messages and attachments, as well as files to which they might have access. Obviously this can be a serious problem. All is not lost, however. Browsers do not normally cache data downloaded over SSL connections. Further, some SSL VPN remote access products have special features to clean up after sloppy software and forgetful users. If the risk of information leakage is important for your company, you will want to investigate these features. If you can't control, monitor You won't necessarily have the resources to implement technical controls to compensate for every threat. That's the bottom line. However, you shouldn't give up. If you can't control, often you can monitor instead. Monitoring techniques can include network- and host-based intrusion detection, system auditing and log analysis -- powerful techniques for stopping problems in their tracks. Your company can allow employees to use their home computers. It won't be free, and it likely won't encompass all the services that some users will want, but it can be done safely for many services. About the Author: Mark Mellis, ISACA/CISM, is a consultant with SystemExperts Corporation, specializing in network security. Ten tips for safe computing on a public LAN 22 Sept 2003 | Ed Yakabovicz | SearchSecurity.com SearchSecurity.com Copyright TechTarget 2006

19

There may be times when your remote users need to connect to a public LAN. Here is a checklist of ten basic tips for ensuring the security of their systems, as recommended by SearchSecurity.com expert Ed Yakabovicz. These are also handy tips to distribute to end users for keeping home PCs secure. 1. Keep the system's OS patches up to date. 2. Use a personal firewall (software; some are free) and keep track of who is trying to access your machine. 3. Using the personal firewall, allow no one to connect through Windows to your machine. Do not share drives. 4. Use antivirus software to protect your system from any virus or malicious code. Never, never shut it off – for any reason. 5. Conduct a full scan for viruses weekly. Update the antivirus signature file daily. 6. Use a hardware firewall if you can. These can run $40 to $100, but they save much time and hassle. 7. Ensure the user ID guest is disabled. 8. Ensure passwords are hard to guess, and do not use administrator unless necessary. 9. Run some type of third party cleaner that will check for malicious code and hidden files that could be Trojans. 10. Run defrag once a week.

SearchSecurity.com Copyright TechTarget 2006

20

Endpoint security tactics Hot Pick: Fireball KeyPoint 13 Oct 2004 | Tom Bowers, CISSP | SearchSecurity.com Fireball KeyPoint RedCannon, www.redcannon.com Technically, RedCannon's Fireball KeyPoint is an endpoint security solution conveniently packaged in a portable USB token. In reality, it's a basic, secure mobile computer that uses host machines as conduits for I/O devices, connectivity to the Internet and corporate networks. When the Fireball KeyPoint is plugged into a USB port, it connects to the RedCannon Web site or your enterprise's management server for policy and software updates. Updates are loaded before it scans the host PC and grants secure access to network-based applications. The token also alerts users to the presence of spyware or malware on the host PC, but doesn't remove it. Fireball KeyPoint assesses and authenticates the host machine's compliance with enterprise security policies, granting full access to compliant machines, limited access to moderately risky machines, or no access to machines that represent a high security risk. For example, hosts with a low-level adware threat could still be granted email access. However, if a more dangerous keystroke logger is detected, Fireball KeyPoint won't permit a connection and will advise the user to try another host. The connection to the corporate network is secured with an IPsec VPN tunnel. An area of concern is RedCannon's suggested distribution of policy updates via shared drives -- an open invitation to disaster, since worms like Blaster and My-Doom could use the open shares to propagate on the LAN. Fortunately, this isn't a requirement; we discovered during testing that using a Web session secured with SSL or SSH will close this hole. In light of this review, RedCannon has changed its recommended architecture. RedCannon's Fireball KeyPoint provides token-based endpoint security, secure Web browsing, storage and email, and spyware protection. Enterprises can configure Fireball KeyPoint to securely run common applications (such as Web browsers and email) and avoid untrusted applications on host machines. RedCannon's proprietary email is adequate; it has the same basic features and capabilities as free or inexpensive email apps like Calypso, Eudora and Thunderbird. The only difference with Red-Cannon's secure email is that almost everything runs from the token, and what little runs from the host PC is hashed/encrypted, erasing all traces of the session. Email messages are stored and encrypted in a token-based vault. SearchSecurity.com Copyright TechTarget 2006

21

Although RedCannon claims Fireball KeyPoint leaves no residual data on the host computer, our testing found traces of visited Web pages in the Documents and Settings temp directory after the token was removed. This is disappointing, since the whole point of this device is to securely browse the Web and access email via an untrusted computer. RedCannon says the bug will be fixed in the next release. Fireball KeyPoint comes in two sizes -- 256 MB and 512 MB -- but don't let the numbers fool you. Its auto-recovery app takes up approximately 50 MB. The Encrypted Vault secure storage provides drag-and-drop capability through Windows Explorer. And, just as the scanner limits or blocks access to the corporate network, it will also lock down the vault if the host machine presents an unacceptable risk. The tedious process of integrating Fireball KeyPoint's Fireball Manager into Active Directory -- the only supported directory service -- must be completed before license, key and policy distribution. Each token must be plugged into a USB port on either the system hosting the management server or with network share to receive licenses, policies and configurations. Wizard-based installation for the Fireball Manager and authentication to a secure Web site/sharepoint for policies/licenses would be on our wish list for the next version. A thin Quick Start Guide and poor documentation complicated the Fireball Manager's installation and configuration. The guide was lacking in nearly every subject, and completely missing was a diagram showing the entire architecture, which would have prevented serious roadblocks during setup and testing. Despite a number of first-release shortcomings, the Fireball KeyPoint is an endpoint security product with potential. Whether you're using an Internet cafe or a home computer, the device lessens the most common remote access security concerns. We expect future versions only to improve upon this strong foundation. About the Author: Tom Bowers has worked with computers since the early 80s. He is currently the Manager of Information Security Operations for Wyeth Pharmaceuticals, where he leads a team conducting pen testing globally. He also owns Net4NZIX, a small consulting firm specializing in pen testing and computer forensics. Tom holds the CISSP, PMP and Certified Ethical Hacker certifications. He can be reached at [email protected]. Product Review: End of the line 1 June 2004 | Curtis Dalton, CISSP | SearchSecurity.com Endpoint devices -- laptops, SOHO desktops, public terminals, etc. -- are your biggest security headache. Traveling employees log in without updated AV signatures or the latest OS patches. Home workers may have no AV or firewall protection. And who knows what unauthorized software and spyware are on connecting PCs? SearchSecurity.com Copyright TechTarget 2006

22

Users jacked into your LAN may not be much better off. Even the most up-to-date patching will lag behind the spread of worms and viruses. According to Gartner, 90 % of cyber-attacks through 2005 will involve known vulnerabilities for which a patch or remedy already exists. Policy notwithstanding, internal employees and contractors disable AV scanners, fiddle with registry settings and run Kazaa and Quake on your network. IT security staffers are often skeleton crews that can't keep up with basic patching, much less play cop with noncompliant employees and machines. The secure master build installed on each computer before it's released is often rendered obsolete by the latest vulnerability and exploit. No wonder the number of endpoint security solutions is growing. These products ensure that each device complies with policy before it's allowed on your network. Endpoint police How do you determine whether a particular host should or shouldn't be allowed to access the network? A solution should cover these compliance criteria: • • • • • •

Authorized OS version and hardware platform. Required OS patches and registry settings. Functioning AV software with latest signatures. Firewall and VPN client with approved policy. Required company software. Absence of IM, P2P, spyware or other rogue programs.

Most endpoint solutions attempt to cover these criteria, but in different ways. Most check compliance through direct login to the endpoint client and/or remote scanning. Typically, solutions use either a resident agent or thin client. Solutions can work for remote and/or LAN-based clients, and most require manual remediation. Direct Login What if you could validate virtually all client systems, including public kiosks and SOHO computers? This is the big advantage to the direct login approach. A gateway device will intercept the endpoint's authentication request and use native cached account credentials to validate compliance, checking for active processes, registry settings, OS revision, patches, etc. The downside: Because of the credential caching, this type of endpoint security gateway is an important -- and additional -- user information store that must be stringently protected. Also, the gateway must be inline with your authentication servers, which could introduce additional points of failure and must be compatible with your authentication protocol (LDAP, Active Directory, NT Domain, etc.). SearchSecurity.com Copyright TechTarget 2006

23

One example of this type of gateway is StillSecure's SafeAccess, an agentless solution. The SafeAccess server is a Layer 2 bridge based on Red Hat Linux with Apache for Web-based management. It's installed on a dedicated server that sits between the VPN gateway and firewall. Since it operates at Layer 2, it requires no IP addresses for devices in your DMZ. If a remote device is connecting to the corporate LAN for the first time, SafeAccess assigns a unique identifier so it can recognize it in subsequent connection attempts. If a remote host isn't a member of the corporate domain, the user is directed to a Web logon page, allowing the Safe-Access server to log in to the computer (through Windows support only) and perform the checks. The login sequence is achieved via the Windows RPC service from within the VPN tunnel (all IPSec VPN vendors are supported) between the remote host and the corporate VPN gateway. SafeAccess checks for missing patches, software updates, up-to-date AV signatures, policy settings and required or prohibited programs. Noncompliant devices are quarantined using ACLs defined on the SafeAccess server. Remote Scanning/Agent Queries Many solutions use vulnerability scanning technology to check the remote client or query client-side agents (or a combination of both) to determine if required security programs (firewall, AV, VPN with split tunneling disabled, etc.) are running. These products eliminate the need to cache user names and passwords on the gateway device. However, client-side software of some kind is required -- a preinstalled agent, ActiveX thin client or browser plug-in. Check Point Software Technologies' Zone Labs Integrity Clientless Security integrates with popular SSL VPNs. Its ActiveX thin client uses a combination of signatures and heuristics to detect, quarantine and block systems containing spyware, keystroke loggers, viruses, Trojans, worms, third-party cookies and hacker tools. Clients can be routed to a customizable URL for remediation. Citadel Security Software's ConnectGuard uses a host-based agent to draw policies and remediation instructions from Citadel's Hercules patch and configuration server. The agent monitors all outbound traffic and blocks any connections that violate the corporate security policy. The first version of this product is fairly elementary; it offers no quarantining and only works in conjunction with Hercules. ENDFORCE's ENDFORCE Enterprise uses a resident agent to check host OS, applications (such as AV, VPN and personal firewall), patches and applicable app or file signatures. ENDFORCE works in conjunction with most AV solutions, VPNs and personal firewalls. If a remote device fails the checks, ENDFORCE provides instructions or automated remediation steps.

SearchSecurity.com Copyright TechTarget 2006

24

InfoExpress' CyberGatekeeper suite offers appliance-based solutions using a resident agent executable or ActiveX thin client. CyberGatekeeper LAN protects the internal LAN and integrates closely with Cisco switches to quarantine noncompliant hosts. The resident agent executable (Windows and Linux supported) checks running processes, registry settings, OS revision and patches, and enforces OS security compliance. Noncompliant hosts are automatically assigned to a segregated VLAN, allowing limited access until updates and configuration changes are made. CyberGatekeeper Remote functions much like the LAN product but uses an ActiveX thin client, which is loaded onto the host via the browser. Iomart Group's NetIntelligence relies on a host-based agent, which checks for IM, P2P, malware and pornographic files via digital fingerprinting and provides Web content blocking and copyright theft detection. It can be used to monitor specific apps and removable devices, such as USB flash memory sticks. NetIntelligence provides integrated Kaspersky Labs AV protection, but no integrated VPN support. Policies are defined by user and group and are pushed down from a central console on a scheduled or ad hoc basis. Policy enforcement is accomplished via client-side access controls applied to the firewall policy. Remediation can be implemented through a central console, which can apply changes individually or by group. Sygate's Secure Enterprise (SSE) employs a resident agent to enforce policy and verify that Sygate's firewall, IDS and AV (all popular solutions are supported) are current and operational. SSE verifies OS version, patches, registry settings and files requirements. Noncompliant devices can be monitored and automatically remediated through usergenerated scripts, or blocked entirely via VLAN manipulation. Sygate plans to release Sygate On-Demand, which can use an ActiveX or Java thin clients instead of agents, and Magellan, a clientless direct login solution. Symantec's Client Security checks compliance for LAN-based and remote clients. Its resident agent detects unauthorized activity, attempts to disinfect afflicted devices and prevents access to system or network resources via real-time AV protection, personal firewall and IDS--all controlled via the management console. Built-in location awareness capabilities ensure that the appropriate security policy is applied. For example, the policy for accessing company headquarters may be different than logging in to a branch office. This solution is best deployed with Symantec VPN Sentry, which assures up-to-date Client Security is running. Noncompliant endpoints can be blocked or granted limited access. Whole Security's ConfidenceOnline solution is completely transparent and requires no signatures. It uses an ActiveX thin client or Netscape plug-in to check for eavesdropping SearchSecurity.com Copyright TechTarget 2006

25

software and verifies that required processes and applications are running and conform to policy. Config-urable heuristics are also used to identify and disconnect remote clients that display infection symptoms. Weighing the choices It's tempting to steer clear of solutions that require client-side software and all the administrative pain that it entails. On the other hand, clientless solutions require that you either trust the proprietary behavioral traffic analysis or entrust third-party security devices with automated domain administrator login access on your networks. Since domain administrator credentials are stored somewhere in these boxes, you should be concerned with their hardening processes and understand what services are active. For example, are stored domain passwords encrypted or hashed, and what hash or cryptography is used? Is your endpoint security solution utilizing Apache 2.0.37, which has a few known vulnerabilities, or does it have an unused, vulnerable version of H.323, which is susceptible to buffer overflows and DoS attacks? From a management standpoint, look for solutions that offer global policy controls and granular ACLs based on location, user ID, group and role. Endpoint security solutions should also allow you to quickly tweak policy across client base, such as in response to new threats. Be sure to check under the hood before you buy. About the Author: Curtis Dalton, CISSP, CISM ([email protected]), is the founder of Principal Security Group, an information security consulting firm. He has authored numerous magazine articles and co-authored Security Architecture: Design, Deployment & Operations (Osborne McGraw-Hill, 2001). Hark! Who goes there? -- Network device compliance 6 Apr 2004 | Ben Rothke, CISSP | SearchSecurity.com Traditional network security has long been about protecting the network perimeter via the "crunchy on the outside, chewy on the inside" method. But that method does nothing to stop viruses and worms from originating inside the network. Examine a corporate campus and count the consultants, service providers and temporary workers accessing the network. How can their access be controlled, ensuring they don't introduce viruses and worms to the network? Today, many corporate networks are more open than all-night convenience stores. With that openness comes lost productivity, industrial espionage, insider abuse and much more. Even with layers of firewalls and IDSes, viruses and worms are still the curse of today's IT environments. Even for the organization that has an antivirus appliance at their gateway, end-node security is crucial since so many devices (PDAs, laptops, etc.) are now bypassing that first-level gateway of protection. A network card and DHCP is all SearchSecurity.com Copyright TechTarget 2006

26

that is needed to access many networks. This is atrocious given the risks that arise from a lack of effective end-node security. Effective end-node security is all about verifying the security compliance of any device that connects to the network. Seeing the importance of end-node security, many vendors are getting into the game. While the company hasn't announced anything directly, Microsoft is working on a trust model of analysis and the quarantining of end points. Two announcements, by Symantec Corp. and StillSecure, were made early this week. Symantec Corp. announced the release of Symantec Client Security 2.0, which includes VPN Compliancy Check, and StillSecure announced its agentless end-node security solution, StillSecure Safe Access. Others vendor offerings include Infoexpress's CyberGatekeeper and Sygate's Adaptive Protection, but they don't have the level of infrastructure to leverage as Cisco's Network Admission Control (NAC). NAC isn't a product per se but Cisco's collaborative effort to ensure network devices can't enter a network until they are compliant with the level of enforcement required. Noncompliant devices can be isolated and denied network access until they are appropriately patched. This host isolation is the greatest benefit of NAC. Typhoid Mary showed what one infected person can do to facilitate the spread of disease -- so too with a single infected host. Until it is isolated, there is little that can be done to stop its lingering effect on the rest of the network. NAC's goal is simple: Ensure hosts can't harm the network. It's the equivalent of showing one's credentials before admission and having a level of enforcement after admittance. An example of NAC credentials would be the most recent antivirus definitions and operating system patches. Cisco defined NAC's architecture and the specifications for NAC technology to be integrated into third-party products. Any developer that wants to integrate NAC into their solution licenses the NAC SDK. It is Cisco's hope that NAC will ultimately be ubiquitous at the desktop in the form of the Cisco Trust Agent (CTA) software. CTA will be the interface between the desktop and NAC, and will be freely available to end-users, much like the Adobe Acrobat reader. The function of any desktop agent is to collect security state information from the desktop device and to report that information to the connected network where access control decisions are made and enforced. If the host is compliant, access is granted. If not, the device is placed in a quarantined area where the required patches are downloaded. If an agent isn't loaded, default access policies are enforced according to the level of security desired. The beauty of such an architecture is that there is compulsory enforcement. Hosts that aren't compliant are denied network access. End-node security fills the credo of trust but verify. With laptops, cell phones and wireless PDAs easily connecting to the corporate network, the security risks with this SearchSecurity.com Copyright TechTarget 2006

27

level of network ease of use can be utterly dreadful. It will be a while before the various end-node security initiatives are complete and fully deployed. But as a start, it shows that the best information security defense is a strong offense. About the Author: Ben Rothke, CISSP, is a New-York based security consultant with ThruPoint, Inc. McGraw-Hill recently published his book Computer Security: 20 Things Every Employee Should Know. He can be reached at [email protected]. Effective endpoint security without a significant investment 2 May 2005 | Ben Rothke, CISSP | SearchSecurity.com Vendors are touting new products to manage endpoint security, but organizations can save money by effectively managing three technologies they already employ – firewall, antivirus and patch management. The endpoint security market grows as more attention is given to the challenges of securing a dynamic digital perimeter. Organizations willing to pay a hefty price can choose from a variety of products that ensure that endpoint devices comply with policy before connecting to the network. However, effective endpoint security doesn't have to require a significant investment in new software or hardware. Most organizations already employ three effective endpoint security controls: firewall, antivirus and patch management. Where is your endpoint? The function of perimeter or endpoint security is to ensure that the infrastructure is protected against external threats. Before you can secure your endpoint, you need to define it. In the pre-Internet days of the mainframe, endpoint security was simple; things were either inside or outside of the data center. Despite the fact that more and more is being spent on information systems security, systems are becoming increasingly complex, and complex systems are much harder to protect. Even the physical perimeter is not simple to define. The potential endpoints are many. Some of them include: • • • • •

Internet access Business Partner access External partnership access Internal employee access And more

Know your endpoint The banking industry has a federal requirement known as Know Your Customer (KYC), which is part of the USA Patriot Act of 2001. The purpose of KYC requirements is to catch those laundering money or attempting tax evasion. Banks are required to determine SearchSecurity.com Copyright TechTarget 2006

28

the source of customer deposits, classify them according to pre-determined profiles and monitor their banking activity to detect deviations. Those in information security can take a similar approach to securing the network perimeter. If you know your endpoint, and are able to detect and respond to anomalous activities, much can be achieved. Effective endpoint security requires an understanding of the infrastructure and a significant commitment to get the job done. Those who have management support and are willing to put in the time to get to know their endpoint have a real chance to create a highly effective information security infrastructure. Technical controls Firewall A firewall is often the first line of network defense, ensuring that only allowed traffic traverses the network. Firewalls are often pristine when initially configured, but after time, allow far too much traffic and too many protocols through. In addition, management often puts too much confidence in firewalls. How do you obviate such a predicament? Make sure you have an effective and current set of firewall policies. A firewall can't be effective unless it's deployed in the context of working policies that govern its use and administration. Antivirus Viruses, worms, Trojan horses, spyware and more are a huge risk to information security. By deploying antivirus technology at the endpoint, organizations can ensure that malware does not infect the infrastructure. But when it comes to antivirus software, organizations are only as good as their virus definition files. To ensure maximum protection, organizations must make certain that gateway devices and workstations have updated antivirus signatures on each device. Patch management Until recently, patch management was something a system administrator did when he had time; now it is an elemental part of information security. Patch management is a strategic process where it must be decided: • • • • •

which patches to install the benefits and implications of implementing the recommended changes the business benefit of installing a patch the regulatory requirements the operational requirements

The year 2005 is no longer your mother's patch environment, where one can leisurely decide whether or not to patch. Microsoft's Patch Tuesday can easily turn into a Black Wednesday if not handled correctly.

SearchSecurity.com Copyright TechTarget 2006

29

Times are changing and information security must change with them. Endpoint security comes down to knowing what your perimeter is, knowing what your risks are and defending against them. When managed effectively, your firewall, antivirus and patch management products will help you do that. About the Author: Ben Rothke, CISSP is a New-York based security consultant with ThruPoint Inc. and the author of Computer Security: 20 Things Every Employee Should Know. He can be reached at [email protected]. Painful patching: How to lock down networked devices 26 Apr 2005 | Brien M. Posey | SearchWindowsSecurity.com What you will learn from this tip: Options for patching endpoints in heterogeneous environments. Given the fact that almost all networks are connected to the Internet nowadays, your one hope of staying secure is to constantly patch all machines on the network with the latest vulnerability fixes. This may not be a big deal in environments consisting only of Windows 2003 servers and Windows XP workstations, for which you can simply use Microsoft's Software Update Services (SUS), System Management Server (SMS) or any number of third-party tools for patch updates. However, if your computers are running non-Microsoft operating systems or non-PC devices, or if your VPN allows connections by computers not controlled by your company, keeping everything up-to-date on your network becomes much more complex -- although not impossible. Comprehensive patch management for heterogeneous environments is considerably more difficult and more expensive than homogenous environments, but there are ways to manage patches in such environments. In the sections below, I discuss some of your options in difficult patch management situations. Patching networked devices Many people don't realize it, but networked non-PC devices, such as personal digital assistants (PDAs), can pose a significant threat to your network's security. Of all the PDAs you see people using in your company, how many of those PDAs does your company own and maintain? People often bring PDAs into the workplace running an outof-the-box configuration and attach them to the network. Although PDA-based exploits aren't as common as PC-based exploits, there are documented cases, nevertheless, where Trojans were found running on PDAs. Unless you control PDA usage in your company, you could be exposing your network and the data it contains to exploits. The best way I know to counter such threats is to establish a policy mandating that only PDAs issued by the company are allowed to be connected to the corporate network or to computers belonging to the company. Once you control all of the PDAs used throughout the company, you can focus on patch management. SearchSecurity.com Copyright TechTarget 2006

30

An easy way to patch your mobile devices is to make sure they are running Windows CE 4.2 or higher or Windows Mobile 2003 or higher. You can then use the SMS 2003 Device Management Feature Pack to manage mobile devices exactly as you would computers on your network. SMS can discover mobile devices and automatically deploy patches to them. Patching heterogeneous operating systems Keeping heterogeneous operating systems patched is more difficult than keeping a purely Windows environment patched. Doing so requires third-party software. There are lots of patch-management solutions out there, but the best choice for your organization will depend greatly on the operating systems being used and on your budget. For organizations running only Windows and Linux operating systems, I like GFI Software Limited's LANguard Network Security Scanner because it's reasonably priced, it does a good job, and it's easy to use. If you require a more comprehensive patch-management solution, check out Citadel Security Software Inc.'s Hercules. I have never actually used this product, so I can't tell you how good it is, but it exemplifies a tool that can patch Windows, AIX, HP-UX, Solaris, Linux and Mac OSX. Patching remote computers not controlled by your company Unpatched computers passing through corporate VPNs have proved particularly troublesome for sometime now. There is a solution built into Windows Server 2003, but it can be extremely difficult to use. The solution is called Network Access Quarantine Control, which places a machine in a quarantined environment when it connects to your network. At that point, you run a query to make sure the operating system has all of the latest patches and the remote system is running an approved antivirus program with upto-date virus definitions. If everything checks out, the PC is allowed to connect to the network. If the machine does not meet all of the requirements set forth by the corporate security policy, the patches are either applied on the spot or the connection is severed (your choice). As I mentioned, though, the big problem with quarantine mode is that you practically need a doctorate in computer science to configure it -- it is script intensive. However, rumor has it that Microsoft will greatly simplify quarantine mode in Windows Server 2003 R2, to be released later this year. The company also plans to change the name to Network Access Protection (NAP). About the Author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies.

SearchSecurity.com Copyright TechTarget 2006

31

The key to locking out mobile threats 4 Apr 2005 | Brien M. Posey | SearchWindowsSecurity.com Mobile devices today are so commonplace that few people pay much mind to them, but mobile devices can pose threats to your network that must not be ignored. Here I'll explain how they can harm your network and what you can do to prevent exploits. New storage features call for greater precautions Mobile devices can threaten your network by allowing hackers to haul away sensitive data or letting malicious freeloaders into your space. Let me explain. PDAs have a much greater storage capacity now than they previously had, in a sense acting as portable hard drives. For instance, an unhappy user or unknown intruder who connects a PDA to an office PC could potentially copy sensitive files from the network to the PDA and walk right out the door with them. He could also use a PDA to bring in virus-infected files, whether it be intentional or accidental, or to copy and install a small application on an office workstation. The fact that many people do not think of mobile devices as security concerns is a major issue. These days, viruses and Trojans are specifically designed to attack mobile devices. This becomes a problem when a device is used to connect to a corporate network over a VPN, Wi-Fi or dial-up link. If a mobile device is infected with a keystroke logger, access credentials to the network can be stolen and transmitted to a server on the Internet, compromising a user's authentication credentials for potential hack attempts. Locking down mobile devices To protect your Windows network from mobile threats, create a corporate policy that bans the use of privately-owned mobile devices. If anyone in the company has a legitimate need for a mobile device, it will be the company's responsibility to provide that device. This will cost the company some money up front, but I believe the benefits outweigh the cost. The first benefit is that you know exactly who is authorized to use mobile devices, and you can take steps to prevent anyone else from attaching a mobile device to the network. Since many mobile devices attach to PCs through a Universal Serial Bus (USB) or Firewire port, try a product like GFI Software Ltd.'s Portable Storage Control to prevent users from attaching mobile devices or any other portable storage device to their PCs. Company ownership of mobile devices also enables you to dictate what must be running on the devices, insuring the devices are used properly. Insist that the mobile device is running all of the latest patches and the latest antivirus definitions (yes, there are antivirus programs for mobile devices). Following those steps should greatly increase mobile device security in your organization, but I also recommend occasionally performing random device audits. Check for unauthorized mobile applications, such as hacker tools, and anything else that might compromise security. People tend to have a personal attachment to their mobile SearchSecurity.com Copyright TechTarget 2006

32

devices and might be reluctant to allow the IT department to inspect them. Remember though that the device is company property, and you have the right to inspect it anytime you feel like it. Mobile devices pose one additional risk, which is what could happen if the device were lost or stolen. If a user has passwords cached within the device, whoever finds it can instantly access your network using that information. Insist that mobile device users have power-on passwords (if supported), and prevent them from caching passwords for connecting to your network, the Internet or anything else. Some users have been known to create text files of passwords, ATM PINs and other highly sensitive information. Make it clear to your users that such files are a very bad idea. As you can see, mobile devices can easily threaten the integrity and security of your network unless they are properly secured. About the Author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. Tips for securing iPods in the enterprise 28 Dec 2005 | Joel Dubin | SearchSecurity.com Any external storage device connected to a desktop can be a security risk. This includes USB keys, flash drives, zip drives – you name it. If it can be attached to a USB port, it can hold and move data. iPods fit neatly into this category and in most cases should be prohibited in the enterprise. iPods can hold up to 30 GB of photos, music, MP3s, videos and movies, as well as any other ordinary data or file type. While they can take -- or steal -- date from the network, they can also introduce spyware and malware into the network. Generally speaking, iPods have no business purpose and shouldn't be allowed to be connected to your employees' desktops. But, there are some exceptions. An innovative business use for iPods was recently developed at a hospital in Geneva. A professor developed software that allows doctors to store and view medical images on their iPods. Using Apple iChat, several doctors in far flung departments on the same case can look at the images remotely from their iPods and compare notes simultaneously. The system has saved the hospital the cost of more expensive equipment for medical imaging and storage. So, despite the security risks, a company may want to consider using podcasts for disseminating information to its employees. A project manager may want to use iPods to distribute diagrams too large to send as email attachments to team members. How do you SearchSecurity.com Copyright TechTarget 2006

33

balance the potential security risk with the potential convenience of iPods and podcasts? Here are some suggestions. •

Restrict the use of iPods to specific projects. Their use should be approved in writing by the information security department for each employee requiring them. Exemptions should only be made on a per-project basis and not entitle the employee to unlimited use of their iPod or to connect to the network after the project is complete.

•

iPods must be scanned by antivirus and antispyware software before connecting to the network. This should be written into your information security policy.

•

Dedicated file servers should host podcasts or other data to be shared by iPods. Access should be logged and monitored for unauthorized or malicious use. Only employees working on the project with a specific need should be granted access. iPods should also be hardened with unneeded services turned off.

•

Only software pre-approved and reviewed by information security should be allowed for use on iPods. As they become more sophisticated, more software becomes available for them. Apple iTunes is an example of another repository for iPod enthusiasts. iTunes must be downloaded to the desktop that will be connecting to the iPod. Most sane information security policies prohibit employees from downloading software willy-nilly directly off the Web. For this reason alone, iTunes wouldn't be allowed on most corporate desktops. Apple this year also released a patch for a flaw in iTunes that allowed a hacker to remotely gain control of a user's desktop. By itself, iTunes is a harmless music store, but is it necessary in the office?

•

USB ports should be shut off for those users who do not need to connect to the network. This can be done at the BIOS level, or on Windows machines through the Device Manager, the Group Policy editor or through registry key settings locked down on the enterprise build of the desktop distributed to your employees.

About the Author: Joel Dubin, CISSP, is an independent computer security consultant based in Chicago. He specializes in Web and application security and is the author of The Little Black Book of Computer Security available on Amazon.

SearchSecurity.com Copyright TechTarget 2006

34

DMZs, LANS and VLANs Glossary Definition: DMZ SearchSecurity.com In computer networks, a DMZ (demilitarized zone) is a computer host or small network inserted as a "neutral zone" between a company's private network and the outside public network. It prevents outside users from getting direct access to a server that has company data. (The term comes from the geographic buffer zone that was set up between North Korea and South Korea following the UN "police action" in the early 1950s.) A DMZ is an optional and more secure approach to a firewall and effectively acts as a proxy server as well. In a typical DMZ configuration for a small company, a separate computer (or host in network terms) receives requests from users within the private network for access to Web sites or other companies accessible on the public network. The DMZ host then initiates sessions for these requests on the public network. However, the DMZ host is not able to initiate a session back into the private network. It can only forward packets that have already been requested. Users of the public network outside the company can access only the DMZ host. The DMZ may typically also have the company's Web pages so these could be served to the outside world. However, the DMZ provides access to no other company data. In the event that an outside user penetrated the DMZ host's security, the Web pages might be corrupted but no other company information would be exposed. Cisco, the leading maker of router s, is one company that sells products designed for setting up a DMZ. Glossary definition: VLAN SearchSecurity.com A virtual (or logical) LAN is a local area network with a definition that maps workstations on some other basis than geographic location (for example, by department, type of user, or primary application). The virtual LAN controller can change or add workstations and manage loadbalancing and bandwidth allocation more easily than with a physical picture of the LAN. Network management software keeps track of relating the virtual picture of the local area network with the actual physical picture. VLANs are considered likely to be used with campus environment networks. Among companies likely to provide products with VLAN support are Cisco, Bay Networks, and 3Com. There is a proposed VLAN standard, Institute of Electrical and Electronics Engineers 802.10. SearchSecurity.com Copyright TechTarget 2006

35

Book chapter: Secure LAN switching Saadat Malik | Cisco Press | SearchSecurity.com This excerpt is from Chapter 5, Secure LAN Switching, of "Network Security Principles & Practices," written by Saadat Malik and published by Cisco Press. In order to provide comprehensive security on a network, it is important to take the concept of security to the last step and ensure that the Layer 2 devices such as the switches that manage the LANs are also operating in a secure manner. This chapter focuses on the Cisco Catalyst 5000/5500 series switches. We will discuss private VLANs in the context of the 6000 series switches. Generally, similar concepts can be implemented in other types of switches (such as the 1900, 2900, 3000 and 4000 series switches) as well. Security on the LAN is important because some security threats can be initiated on Layer 2 rather than at Layer 3 and above. An example of one such attack is one in which a compromised server on a DMZ LAN is used to connect to another server on the same segment despite access control lists on the firewall connected on the DMZ. Because the connection occurs at Layer 2, without suitable measures to restrict traffic on this layer, this type of access attempt cannot be blocked. General switch and layer 2 security Some of the basic rules to keep in mind when setting up a secure Layer 2 switching environment are as follows: •

VLANs should be set up in ways that clearly separate the network's various logical components from each other. VLANs lend themselves to providing segregation between logical workgroups. This is a first step toward segregating portions of the network needing more security from portions needing lesser security. It is important to have a good understanding of what VLANs are. VLANs are a logical grouping of devices that might or might not be physically located close to each other.

•

If some ports are not being used, it is prudent to turn them off as well as place them in a special VLAN used to collect unused ports. This VLAN should have no Layer 3 access.

•

Although devices on a particular VLAN cannot access devices on another VLAN unless specific mechanisms for doing so (such as trunking or a device routing between the VLANs) are set up, VLANs should not be used as the sole mechanism for providing security to a particular group of devices on a VLAN. VLAN protocols are not constructed with security as the primary motivator behind them. The protocols that are used to establish VLANs can be compromised rather easily from a security perspective and allow loopholes into the network. As such, other mechanisms such as those discussed next should be used to secure them. SearchSecurity.com 36 Copyright TechTarget 2006

•

Because VLANs are not a security feature, devices at different security levels should be isolated on separate Layer 2 devices. For example, having the same switch chassis on both the inside and outside of a firewall is not recommended. Two separate switches should be used for the secure and insecure sides of the firewall.

•

Unless it is critical, Layer 3 connectivity such as Telnets and HTTP connections to a Layer 2 switch should be restricted and very limited.

•

It is important to make sure that trunking does not become a security risk in the switching environment. Trunks should not use port numbers that belong to a VLAN that is in use anywhere on the switched network. This can erroneously allow packets from the trunk port to reach other ports located in the same VLAN. Ports that do not require trunking should have trunking disabled. An attacker can use trunking to hop from one VLAN to another. The attacker can do this by pretending to be another switch with ISL or 802.1q signaling along with Dynamic Trunking Protocol (DTP). This allows the attacker's machine to become a part of all the VLANs on the switch being attacked. It is generally a good idea to set DTP on all ports not being used for trunking. It's also a good idea to use dedicated VLAN IDs for all trunks rather than using VLAN IDs that are also being used for nontrunking ports. This can allow an attacker to make itself part of a trunking VLAN rather easily and then use trunking to hop onto other VLANs as well.

Generally, it is difficult to protect against attacks launched from hosts sitting on a LAN. These hosts are often considered trusted entities. As such, if one of these hosts is used to launch an attack, it becomes difficult to stop it. Therefore, it is important to make sure that access to the LAN is secured and is provided only to trusted people. Some of the features we will discuss in the upcoming sections show you ways to further secure the switching environment. The discussion in this chapter revolves around the use of Catalyst 5xxx and 6xxx switches. The same principles can be applied to setting up security on other types of switches. How to protect a LAN from unauthorized access What steps should I take to use filters to protect a LAN from unauthorized access? QUESTION POSED ON: 04 November 2005 QUESTION ANSWERED BY: Joel Dubin, SearchSecurity.com The first, and easiest, way to protect a LAN is to put it in a separate subnet behind its own gateway router or firewall. This segregates the LAN from other networks and makes it easier to tune any gateways into it through hubs, switches or routers.

SearchSecurity.com Copyright TechTarget 2006

37

The next simplest step, at least for a Windows network, is to simply shut off port 139 on the gateway router. This prevents a malicious user from trying to map a drive to the LAN. Similarly, turn off NetBIOS over TCP/IP on the workstations within the LAN. This prevents some bad guy from trying to directly map a drive to the workstations inside the LAN by using the NetBIOS name of the computer over a TCP/IP connection from outside the LAN. Each workstation can also be configured to only accept traffic from specific IP addresses. Every LAN has a range of internal IP addresses assigned by whoever set up the LAN. The IP filtering feature can be set to only accept traffic from those IP addresses. But might that block Internet access? Not necessarily. If the LAN accesses the Internet through the gateway, whose IP is in the network's range of accepted IP addresses, then the LAN will still be able to connect to the Internet. But it will do so securely since it's only accepting the traffic from the accepted gateway and not the Internet directly. And, of course, tune your firewalls, both at the gateway and on the individual hosts, to only accept needed TCP protocols. If FTP or Telnet isn't needed, filter them out. About the Author: Joel Dubin, CISSP, is an independent computer security consultant based in Chicago. He specializes in Web and application security and is the author of The Little Black Book of Computer Security available on Amazon. Designing DMZs with various levels of access I need some information on designing DMZs for my local users, customers, partners and application servers with different levels of access. I have more than 1,100 workstations on my LAN, and I want to define different levels of access for local users, too. I appreciate any guidance. QUESTION POSED ON: 08 January 2004 QUESTION ANSWERED BY: Ed Yakabovicz, SearchSecurity.com Typically the DMZ is designed as the first stop into any company that is connected to the Internet. Do not place any email, databases or any other data that is critical to your company in this zone. Place servers that you connect for authentication. Now when these devices connect back through the DMZ to say a database zone, create a network subnet with only those devices. This separates other internal systems from the external and provides a layered approach. Now, anyone needing to access say email or other data (shares, files, etc) put them in another network off the DMZ. I always recommend firewalls at both sides of the DMZ and IDS systems external -- one in the DMZ, one in the Database zone and others more or less in all zones. Security must be addressed as a layered approach. The first step is to filter all traffic before it enters the DMZ. So a router only letting in say port 80, 443 to the DMZ. Then SearchSecurity.com Copyright TechTarget 2006

38

the DMZ will only allow traffic such as any application in the DMZ email, SMTP. Please no FTP, because it's too insecure. The DMZ should only allow valid traffic to the devices behind it. Using 802.1X to control physical access to LANs 29 Dec 2005 | Michael Cobb | SearchSecurity.com Network security would be so much easier if you could control which physical computers were allowed to join your network. It would mean a hacker would have to gain physical access to a particular computer before they could even start to attack your network. One technology used to control admission of computers into a network is 802.1X, a portbased access control. It is mainly used on wireless networks but is increasing in popularity as an access control method on wired networks too. 802.1X features MAC address filtering. Any machine whose MAC address on the network adapter does not match an entry in the account database is not permitted access to the network. Unfortunately, like IP addresses, MAC addresses can be spoofed. This creates the possibility of a man-in-the-middle attack, albeit a sophisticated one. To prevent this type of attack, 802.1X should be combined with the Extensible Authentication Protocol (EAP) to authenticate the client to the network and the network to the client. 802.1X is one way of preventing entry to your network, but once it authenticates the connection it assumes all traffic over the connection is legitimate. To really solve the problem of rogue machines, each computer needs to protect itself from the other computers on the network. So, 802.1X should also be used in conjunction with IPSec, which provides end-to-end authentication and encryption between hosts on a network. Looking ahead to the release of Microsoft Windows Vista/Longhorn, it's understood that they will include Network Access Protection (NAP). This feature will allow you to protect your network from unhealthy computers by enforcing compliance with network health policies. This is similar to Cisco's Network Admission Control (NAC), which isolates and denies network access to non-compliant devices. While NAP and NAC play a different role from 802.1X in controlling network connections, it will certainly go a long way to ensuring trusted computers on the network stay that way. About the Author: Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for SearchSecurity's Web Security School and, as a SearchSecurity.com site expert, answers user questions on application and platform security.

SearchSecurity.com Copyright TechTarget 2006

39

Life at the edge: Securing the network perimeter, Part 2 5 Jun 2005 | Michael Cobb | SearchSecurity.com Divide and conquer -- DMZs A network DMZ separates and isolates a trusted network from an untrusted network by creating screened subnets. By dividing the system into segments and creating DMZs where only intermediate levels of trust exist, the system has a much greater resistance to successive compromise, thereby protecting the key resources even if other components fail. DMZs work because network traffic cannot travel between two network subnets without being routed. Your Web servers, FTP servers, mail servers and external DNS servers should be placed in this DMZ, or "perimeter network," along with additional network defenses, such as an IDS. By putting these public services in the DMZ, you put them on a different subnet to your internal network. Your internal network is where your back-end systems such as database servers should be located. Any machine placed in the DMZ is still at risk, but if an intruder compromises the DMZ, he does not automatically have access to the internal network. Each access point into the DMZ blocks and filters network traffic to only allow activity to or from certain network addresses, over certain ports, to pass through. Great care should be taken so that interactions with the DMZ do not expose the internal network. The barriers between each segment are controlled and screened by firewalls and routers, and protected by access control lists, strong authentication and encryption. For the ultimate in DMZ security, place each service on its own DMZ segment, configuring firewall policies to meet the needs of each server. Network layouts There are two DMZ network layouts we'll look at. The first, called a triple-homed perimeter network, is suitable for low-budget Web sites that do not connect to a critical internal network. The second is a back-to-back perimeter network, which is required for e-commerce and other mission-critical Web sites. Triple-homed perimeter network This topology uses a single firewall to separate the Internet, the perimeter network and the corporate intranet. It is also known as a single-screened subnet because the DMZ is bounded by only a single firewall with three network cards: one connected to the Internet, one to the DMZ and one to the corporate intranet (see figure 1 below). The disadvantage of this network layout is that there is a single point of failure. When ports are opened through a perimeter guarded by a single firewall, the perimeter security is unavoidably weakened. If an intruder compromises the firewall in this topology, he has access to both the server in the DMZ and the corporate intranet.

SearchSecurity.com Copyright TechTarget 2006

40

Figure 1: Triple-homed perimeter network. Note that this topology specifies the use of a secured router between the Internet and the DMZ. Ports on this router should be locked down. Examples of ports that you would typically need open to ensure correct Web server functionality would be port 80 for HTTP and port 443 for HTTPS. Back-to-back perimeter network The back-to-back perimeter network topology shown in figure 2 is widely regarded as one of the most secure. The perimeter network is separated from the Internet on one side and from the internal network on the other side by using two firewalls. Each firewall has two network adapters. The external firewall has one network adapter connected to the Internet and the other connected to the perimeter network, while the internal firewall has one network adapter connected to the perimeter network and the other connected to the internal network (see figure 2 below). This provides an added layer of protection. If an intruder from the Internet compromises the perimeter network, he does not automatically gain access to resources in the internal network, as there is another barrier between the intruder and the rest of the network.

Figure 2: A dual screened subnet or back-to-back perimeter network using two firewalls. Note that there is another secured router separating the network segments that compose the perimeter network. Although locking down this router is not as important as locking SearchSecurity.com 41 Copyright TechTarget 2006

down the router connected to the Internet, ensuring that non-essential ports are closed can give additional security. The outside firewall protects against external attacks and manages all Internet access to the DMZ. The inside firewall manages DMZ access to the internal network. This firewall should have different rules than the firewall facing the Internet, allowing only inbound application-specific service calls to reach specified systems and preventing unsolicited inbound port 80 Web traffic into the internal network. In other words, the firewall should only pass inbound traffic from a server in the DMZ that needs to communicate with one of the internal systems. For example, if a Web server communicates with a database via SQL, open TCP ports in the firewall to pass the SQL queries and responses, and block everything else. Security is further enhanced when different makes of firewalls are used on each side of the DMZ. A hacker is less likely to be able to use the same exploit to defeat both systems. When segmenting a network for security purposes, always choose physical segmentation. A virtual LAN (VLAN) is a network segment that is logically defined and controlled by a switch that can assign its ports to two or more VLAN segments rather than have all its ports belong to the same physical segment. Although this reduces the cost of purchasing multiple switches, the segmentation is virtual. It can be removed and the security the switch provides can be easily bypassed. About the Author: Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a consultancy that offers IT training and support in data security and analysis. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Mike is the guest instructor for SearchSecurity's Web Security School and, as a SearchSecurity.com site expert, answers user questions on application and platform security. VLAN security 29 Mar 2004 | Tom Lancaster | SearchSecurity.com This week, I wanted to address VLAN security, which like Ethernet, is a mystery to most people. That may sound like a strange statement, since I'm sure everyone reading this has been using Ethernet for years, but seriously, how many network engineers do you know who could explain Manchester bit encoding or how Fast Link Pulses work? Not very many, of course, and why should they? After all, Ethernet is one of those protocols that "just works." Network administrators don't understand it for the very simple reason that they never have to troubleshoot it. VLANs are pretty much the same way. Sure, the configuration of a few more advanced topics like VTP and VLAN pruning can give you a mental workout, and of course, nobody likes Spanning-Tree Protocol, but really, when was the last time you really needed to know how your switches implemented VLANs? For the most part, you define a SearchSecurity.com Copyright TechTarget 2006

42

VLAN, and assign ports to it, and define trunk ports and configure which VLANs can cross it... and it just works... simple as that. But it's precisely this simplicity that can lull you into leaving open a raft of security vulnerabilities. So as I was checking a few quick facts for this tip, I ran across an @Stake white paper so concise and illuminating, despite being 2 years old, that I decided to just link you to it and offer a quick summary. (http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a 008013159f.shtml) The reason I like this article is because it explains at a high level, several ways your network can be attacked at Layer 2. Many of these aren't nearly as intuitively obvious as the higher-level attacks we witness daily, so many administrators think that it's impossible to attack VLANs, which is of course, absurd. So here are a few key points to remember when configuring your network: VLAN 1 (on Catalyst switches) is the default for both ports and the "Native" VLAN on 802.1Q trunks, which is precisely why you should NEVER use it. Don't allow dynamic protocols to talk to untrusted devices. Many administrators don't realize there are a lot of these operating around Layer 2, such as VTP, PAgP, CDP, DTP, UDLD and of course STP. If at all possible, authenticate all hosts and/or limit their connectivity. Port Security, 802.1x and Dynamic VLANs are three methods mentioned in this article you can use. About the Author: Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years experience in the networking industry, and co-author of several books on networking, most recently, CCSPTM: Secure PIX and Secure VPN Study Guide published by Sybex. Popular VLAN attacks and how to avoid them 23 May 2005 | Chris Partsenidis | SearchSecurity.com Configuring three or more switches to support a VLAN and partition a network is a fairly simple and straight-forward process; however, ensuring a VLAN can withstand an attack is a different story! In order to secure a VLAN, you need to know what to protect it from. Here are a few of the most popular attacks against VLANs, ways you can fight them, and in some cases, minimize their effect. VLAN hopping attacks SearchSecurity.com Copyright TechTarget 2006

43

The basic VLAN hopping attack is based on the Dynamic Trunking Protocol and, in some cases, the trunking encapsulation protocol (802.1q or ISL). The Dynamic Trunking Protocol is used for negotiating trunking on a link between two switches or devices and the type of trunking encapsulation to be used. Trunk negotiation can be enabled on a switch interface by entering the following command at the interface level: Switch(config-if)#switchport mode dynamic While this feature might ease the process of configuring switches, it hides a serious weakness for your VLAN. A station can easily spoof itself as a switch using the 802.1q encapsulation, thereby creating a trunk link and becoming a member of all VLANs. Thankfully, this vulnerability has been fixed in Cisco's newer IOSes. To avoid possible VLAN hopping attacks, do not use 'dynamic modes' at the interface level and configure the link as a trunk or access type. Address Resolution Protocol attacks The Address Resolution Protocol (ARP) attack is popular in the underground world. Available tools can bypass the switch security feature that creates a virtual communication channel between two nodes and prohibits the rest from 'listening' to their conversation. With ARP attacks, the intruder obtains IP addresses and other statistics about the network he plans to attack, and then uses that information to issue the attack. The intruder floods the network switches with ARP broadcasts, telling the network switches that all, or a range, of IP addresses belong to him, thereby forcing all data packets and conversations to pass through him while he sniffs the data. You can avoid this problem by using the 'port-security' command available to most highend Catalyst switches such as the 4000, 4500, 5000 and 6500 series. Once the port-security feature is enabled on a port, you are able to specify the number of MAC addresses or the specific MAC address allowed to connect through the port. The command required to enable this security feature is: Switch(config)#set port security port enable Static ARP should be used for critical routers or hosts such as servers. Lastly, intrusion-detection systems can track and report multiple ARP broadcasts resulting from such attacks. VLAN Trunking Protocol attack The VLAN Trunking Protocol (VTP) is a proprietary Cisco protocol designed to make life easy by automatically propagating VLAN information throughout network switches. Its setup involves a VTP server, effectively a switch, in charge of propagating all VLAN information. All switches, minus the VTP server switch, are configured as client switches SearchSecurity.com Copyright TechTarget 2006

44

that are responsible for listening for announcements regarding any VLAN changes made from the VTP server. The VTP attack involves a station sending VTP messages through the network, advertising that there are no VLANs on the network. Thus, all client VTP switches erase their valid VLAN information databases. This may also occur if a switch is plugged into the network that is configured as a VTP server and contains a VTP configuration version higher than the existing VTP server. In this case, all switches overwrite their valid information with that obtained by the 'new' VTP server. Thankfully, there are ways to protect a VLAN from this situation. Either disable VTP all together (not advised for a large network with more than five switches) or use MD5 Authentication for all VTP messages to ensure no VTP message is processed by the client switches if the password contained in the message is not correct. The commands used to set the VTP password for your VTP Domain are: Switch#vlan database Switch(vlan)# vtp domain password Switch(vlan)#apply Switch(vlan)#exit About the Author: Chris Partsenidis is the founder and senior editor of www.Firewall.cx, a Web site dedicated to network security and protocol analysis. If you wish to read up more on VLAN technologies and their associated protocols, you can refer to www.Firewall.cx where the topic is extensively covered. Chris has a bachelor's degree in Electrical Technology and holds the following IT certifications: Cisco CCNA, Novell CNA (3,4,5), Linux LCP, D-Link Engineer, Microsoft MCP, CompTIA A+ & Network+. You can contact Chris via www.Firewall.cx.

SearchSecurity.com Copyright TechTarget 2006

45

Firewalls 2006 Network Firewall Products of the Year SearchSecurity.com NetScreen-5GT and -5XT Juniper Networks, www.juniper.net Juniper Networks clearly knew what it was doing when it acquired NetScreen in 2004. Its NetScreen-5GT and -5XT firewall appliances earned consistent "excellent" and "good" responses across the board, earning the gold medal in the network firewall category for two years running. This family of network security solutions is ideal for locking down enterprises' remote offices, retail outlets and broadband telecommuter environments. Its integrated security applications, routing protocols and policy-based management features have earned it the top spot among surveyed readers. The NetScreen-5GT's and -5XT's stateful packet inspection and signature-based deep inspection threat detection, and DDoS protection capabilities, stop network- and application-layer attacks. Their Web filtering options (available from third-party vendor Websense) prevent users from leaking sensitive corporate information, whether deliberately or through spyware/phishing attacks. The firewalls offer up to 25 concurrent VPN tunnels, an unlimited number of trusted IP addresses and up to 4,000 concurrent sessions. Specifically, the 5GT has embedded network-based AV that scans for viruses in email, Web and file-transfer protocols. Its embedded Trend Micro antivirus engine scans IMAP, SMTP, FTP, POP3 and HTTP mail protocols, and checks against an encyclopedia of more than 80,000 signatures. (It is important to note that the NetScreen-5XT does not support this embedded antivirus gateway scanning.) The 5GT's and 5XT's embedded IPsec VPN provides Web-based and XAUTH authentication, with third-party support for RADIUS, LDAP and RSA SecurID. "We originally selected Juniper because we knew the performance was greater than our previous solution. We had no idea we'd be seeing so many other benefits," says Matthew Gruett, Internet systems specialist for TDS Telecom. Both the 5GT and 5XT support key routing protocols -- including BGP, OSPF and ECMP -- and integrate into the network with ease. Dial-backup and dual Ethernet ports support business-critical systems and provide redundancy. Restricted security zones protect corporate activity and offer a clear separation between authorized and unauthorized business use. The zones also offer delineation between home and office users, allowing employees to access the corporate network though a secure VPN SearchSecurity.com Copyright TechTarget 2006

46

connection (work zone) and maintain their access to the Internet (home zone) through normal connectivity. In addition, the 5GT Wireless appliance also offers support for a wide set of wireless authentication and privacy protocols for 802.11b/g networks. Cisco PIX 500 Series Security Appliances Cisco Systems, www.cisco.com Firewall and PIX are synonymous, says one user. "It's what I trust between me and the Internet." FireWall-1 Check Point Software Technologies, www.checkpoint.com It is no surprise that this granddaddy of firewalls continues to draw great user support, getting especially strong ratings for security. How to choose a firewall 17 Oct 2005 | Mike Chapple | SearchSecurity.com There are dozens of firewalls on the market today. Choosing one for your organization can be a daunting task – especially in an industry filled with buzzwords and proprietary trademarks. Let's take a look at the basics of firewall technology and five questions you should ask when choosing a firewall for your organization. 1. Why are you implementing a firewall? Sure, this sounds like a simple question. You're probably thinking to yourself, "Because we need one!" But it's important that you take the time to define the technical objectives that you have for implementing a firewall. These objectives will drive the selection process. You don't want to choose an expensive, feature-rich firewall that's complicated to administer when your technical requirements could be met by a simpler product. 2. How will the firewall fit into your network topology? Will this firewall sit at the perimeter of your corporate network and be directly connected to the Internet, or will it serve to segment a sensitive LAN from the remainder of the organization? How much traffic will it process? How many interfaces will it need to segment your traffic? Performance requirements such as these contribute a significant amount to the total cost of new firewall implementations, making it easy to under- or over-purchase. 3. What type of traffic inspection do you need to perform? This is where the buzzwords start to come into play. Every vendor out there has a different trademark for their traffic-inspection technology, but there are essentially three different options (listed in order of increasing complexity and cost): •

Packet-filtering firewalls use simple rules to evaluate each packet they encounter on its own merits. They maintain no history from packet to packet, and they perform basic packet header inspection. The simplicity of this SearchSecurity.com 47 Copyright TechTarget 2006

inspection makes them speed demons. They're the most inexpensive option, but they are also the least flexible and vulnerable. There's a good chance you already own equipment capable of performing packet filtering – your routers! •

Stateful-inspection firewalls go a step further. They track the three-way TCP handshake to ensure that packets claiming to belong to an established session (i.e., the SYN flag is not set) correspond to previous activity seen by the firewall. Requests to open the initial connection are subject to the statefulinspection firewall rulebase.

•

Application-proxy firewalls contain the highest level of intelligence. In addition to stateful inspection, they broker the connection between client and server. The client connects to the firewall, which analyzes the request (including application-layer inspection of packet contents). If the firewall rules indicate that the communication should be allowed, the firewall then establishes a connection with the server and continues to act as an intermediary in the communication. When combined with Network Address Translation, both hosts may not even be aware that the other exists – they both believe they are communicating directly with the firewall.

4. Is your organization better suited for an appliance or a software solution? Appliances are typically much easier to install. You normally just plug in the appropriate Ethernet cables, perform basic network configuration and you're ready to configure your firewall rules. Software firewalls, on the other hand, can be tricky to install and require tweaking. They also lack the security that's often built into the hardened operating systems of firewall appliances. What's the tradeoff? You guessed it! Appliances are more expensive. 5. What operating system is best suited for your requirements? Even appliances run an OS and, chances are, you'll need to work with it at some point in your firewall administration career. If you're a Linux jockey, you probably don't want to choose a Windows-based firewall. On the other hand, if you don't know ⁄dev⁄null from ⁄var⁄log, you probably want to steer clear of Unix-based solutions. While I can't recommend a specific firewall to you without knowing your needs, the process of answering these questions can help you solidify your thoughts and put you in the right direction. With these answers in hand, you should be able to intelligently evaluate the cost/benefit tradeoff for the various products available on the market today. About the Author: Mike Chapple, CISSP is an IT Security Professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles including the CISSP Prep Guide and Information Security Illuminated.

SearchSecurity.com Copyright TechTarget 2006

48

Choosing the right firewall topology 17 Oct 2005 | Mike Chapple | SearchSecurity.com When developing a perimeter protection strategy for an organization, one of the most common questions is "Where should I place firewalls for maximum effectiveness?" In this tip, we'll take a look at the three basic options and analyze the scenarios best suited for each case. Before we get started, please note that this tip deals with firewall placement only. Anyone building a perimeter protection strategy should plan to implement a defense-in-depth approach that utilizes multiple security devices including firewalls, border routers with packet filtering and intrusion-detection systems. Option 1: Bastion host The first and most basic option is the use of a bastion host. In this scenario (shown in figure 1 below), the firewall is placed between the Internet and the protected network. It filters all traffic entering or leaving the network.

Figure 1: Bastion host The bastion host toplogy is well suited for relatively simple networks (e.g. those that don't offer any public Internet services.) The key factor to keep in mind is that it offers only a single boundary. Once someone manages to penetrate that boundary, they've gained unrestricted (at least from a perimeter protection perspective) access to the protected network. This may be acceptable if you're merely using the firewall to protect a corporate network that is used mainly for surfing the Internet, but is probably not sufficient if you host a Web site or email server. Option 2: Screened subnet The second option, the use of a screened subnet, offers additional advantages over the bastion host approach. This architecture uses a single firewall with three network cards (commonly referred to as a triple homed firewall). An example of this topology is shown in figure 2 below.

SearchSecurity.com Copyright TechTarget 2006

49

Figure 2: Screened subnet The screened subnet provides a solution that allows organizations to offer services securely to Internet users. Any servers that host public services are placed in the Demilitarized Zone (DMZ), which is separated from both the Internet and the trusted network by the firewall. Therefore, if a malicious user does manage to compromise the firewall, he or she does not have access to the Intranet (providing that the firewall is properly configured). Option 3: Dual firewalls The most secure (and most expensive) option is to implement a screened subnet using two firewalls. In this case, the DMZ is placed between the two firewalls, as shown in figure 3 below.

Figure 3: Dual firewalls The use of two firewalls still allows the organization to offer services to Internet users through the use of a DMZ, but provides an added layer of protection. It's very common for security architects to implement this scheme using firewall technology from two different vendors. This provides an added level of security in the event a malicious individual discovers a software-specific exploitable vulnerability. Higher-end firewalls allow for some variations on these themes as well. While basic firewall models often have a three-interface limit, higher-end firewalls allow a large number of physical and virtual interfaces. For example, the Sidewinder G2 firewall from SearchSecurity.com Copyright TechTarget 2006

50

Secure Computing allows up to 20 physical interfaces. Additional virtual interfaces may be added through the use of VLAN tagging on the physical interfaces. What does this mean to you? With a greater number of interfaces, you can implement many different security zones on your network. For example, you might have the following interface configuration: • Zone 1: Internet • Zone 2: Restricted workstations • Zone 3: General workstations • Zone 4: Public DMZ • Zone 5: Internal DMZ • Zone 6: Core servers This type of architecture allows you to take any of the three topologies described above and add a tremendous degree of flexibility. That's a brief primer on firewall architectures. Now that you're familiar with the basic concepts, you should be able to help select an appropriate architecture for use in various situations. About the Author: Mike Chapple, CISSP is an IT Security Professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles including the CISSP Prep Guide and Information Security Illuminated. Placing systems in a firewall topology 17 Oct 2005 | Mike Chapple | SearchSecurity.com In the previous tip we explored the basics of choosing a firewall topology. We covered the differences between bastion hosts, screened subnets and combining multiple firewalls for maximum security. Once you have decided which topology best suits your IT infrastructure, you need to decide where to place individual systems within the chosen topology. As we discuss this topic, we'll use the concept of security zones to further define our requirements. For our purposes, consider a security zone to be all of the systems connected to a single interface of a firewall – either directly or through network devices other than firewalls. Bastion host First, let's look at the simplest case: the bastion host. In this scenario, all traffic entering or leaving the network passes through the firewall and it has only two interfaces: a public interface directly connected to the Internet and a private interface connected to the intranet. This leaves us with two security zones, making it fairly easy to place systems. We simply put all systems that we would like protected in the private zone! SearchSecurity.com Copyright TechTarget 2006

51

In the case of a bastion host topology, we're assuming that you are not planning to offer any public services to the Internet. If you do need to offer public services (such as DNS, SMTP or HTTP), you should seriously consider the use of an alternate topology. If that is not possible, you have a difficult decision to face: should you place your public servers in the public or private zone? If you place them in the public zone, they don't gain any protection from the firewall and are more vulnerable to attack. On the other hand, placing them in the private zone raises the possibility that other, more sensitive systems, may be compromised if the public server falls victim to an attack. You need to carefully weigh the risks and benefits when making this decision.

Figure 1: Bastion host Screened subnet The screened subnet scenario, the most commonly deployed firewall topology, is also somewhat straightforward. We add an additional zone -- the screened subnet (or DMZ) -that contains all hosts offering public services. In this case, the public zone is directly connected to the Internet and contains no hosts controlled by the organization. The private zone contains systems that Internet users have no business accessing, such as user workstations, internal file servers and other nonpublic applications. The DMZ contains all systems that are intended to provide services to the Internet. This zone contains your public Web server, SMTP server, DNS servers and other similar systems. Your IMAP/POP server may or may not reside in this zone, depending upon your security policy.

Figure 2: Screened subnet Multi-homed firewall The final scenario, a multi-homed firewall with more than three interfaces, poses the most interesting challenge. In this case, you have more than three zones, so you have the luxury of further subdividing systems. You'll need to make these subdivisions based upon the specific security objectives of your organization. One division you might want to SearchSecurity.com Copyright TechTarget 2006

52

make is to place workstations into different zones to provide isolation for sensitive systems. For example, you might place all systems belonging to accounting into one zone, executive workstations in another zone and other workstations in yet a third zone. You also may wish to subdivide systems offering services to the Internet. For example, systems that provide services to the general public (such as a company Web site) may be placed in a different zone than systems that offer services only to authenticated users (such as a Web mail server).

Figure 3: Multi-homed firewall In the end, the choices are yours to make. Now that you've read this tip, you should have plenty of ideas running through your mind. Sit down and commit them to paper, discuss the options with your colleagues and develop a system placement strategy suitable for your organization. About the Author: Mike Chapple, CISSP is an IT Security Professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of several information security titles including the CISSP Prep Guide and Information Security Illuminated.

Auditing firewall activity 17 Oct 2005 | Mike Chapple | SearchSecurity.com In the first three parts of this series, we explored choosing a firewall platform, choosing an appropriate topology, and placing systems within that topology. Once you've made it through the challenging phases of firewall selection and architecture design, you're finished setting up a DMZ, right? Your rulebase should remain stable and you'll never have a need to make configuration changes. We can only dream! In the real world of firewall management, we're faced with balancing a continuous stream of change requests and vendor patches against the operational management of our firewalls. SearchSecurity.com Copyright TechTarget 2006

53

Configurations change quickly and often, making it difficult to keep on top of routine maintenance tasks. In this tip, we explore some ways to leverage the logging capabilities of your firewall to help keep things in order. Let's take a look at four practical areas where some basic log analysis can provide valuable firewall management data: 1. Monitor rule activity System administrators tend to be quick on the trigger to ask for new rules, but not quite so eager to let you know when a rule is no longer necessary. Monitoring rule activity can provide some valuable insight to assist you with managing the rulebase. If a rule that was once heavily used suddenly goes quiet, you should investigate whether the rule is still needed. If it's no longer necessary, trim it from your rulebase. Legacy rules have a way of piling up and adding unnecessary complexity. Over the years, I've had a chance to analyze the rulebases of many production firewalls, and I estimate that at least 20% of the average firewall's rulebase is unnecessary. I've seen systems where this ratio is as high as 60%. 2. Traffic flows Also monitor logs for abnormal traffic patterns. If servers that normally receive a low volume of traffic are suddenly responsible for a significant portion of traffic passing through the firewall (either in total connections or bytes passed), then you have a situation worthy of further investigation. While "flash crowds" are to be expected in some situations (such as a Web server during a period of unusual interest), they are also often signs of misconfigured systems or attacks in progress. 3. Rule violations Looking at traffic denied by your firewall may lead to interesting findings. This is especially true for traffic that originates from inside your network. The most common cause of this activity is a misconfigured system or a user who isn't aware of traffic restrictions, but analysis of rule violations may also uncover attempts at passing malicious traffic through the device. 4. Denied probes If you've ever analyzed the log of a firewall that's connected to the Internet, you know that it's futile to investigate probes directed at your network from the Internet. They're far too frequent and often represent dead ends. However, you may not have considered analyzing logs for probes originating from inside the trusted network. These are extremely interesting, as they most likely represent either a compromised internal system seeking to scan Internet hosts or an internal user running a scanning tool – both scenarios that merit attention. Your firewall audit logs are a veritable goldmine of network security intelligence. Use them to your advantage! About the Author: Mike Chapple, CISSP is an IT Security Professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to SearchSecurity, a technical editor for Information Security magazine and the author of SearchSecurity.com Copyright TechTarget 2006

54

several information security titles including the CISSP Prep Guide and Information Security Illuminated. Activating an XP firewall on a LAN 10 Oct 2005 | ITKnowledge Exchange | SearchSecurity.com The following question and answer thread was excerpted from ITKnowledge Exchange. A user identified as stanslad posted the following question: "We would like to activate an XP firewall in our corporate LAN. However, I've been advised not to do so because activating such a firewall causes complications for LANbased users, applications and services. What should we do?" A user identified as hedgehog advised: "I would enable it first on a small test bed of controlled clients and see how it goes. Keep in mind that, as with most personal firewalls, the WinXP firewall will have some connectivity problems, especially with client-server apps or with those that need to 'ping' the machines to work. You will need to determine which ports/services are in use and open them in the firewalls. If you allow laptops into your corporate LAN, a personal firewall should be mandatory on those machines. While having a personal firewall on a desktop is not as critical, they also contribute to your overall security." A user identified as csmric advised: "When I initially deployed SP2 throughout our organization, I enabled an XP firewall and created 'holes' in it as necessary. However, as we proceeded, I found more and more LAN-related problems. The Terminal Server users, the various antispyware and antivirus solutions we employ became too much to keep up with as I opened more and more holes. Since we use a hardware (PIX) firewall and an ISA Server, I decided to disable the XP firewall on all computers. We have used this configuration for 6 months now and haven't experienced any adverse reactions. I would also recommend configuring the laptops so they use the XP firewall. This protects the laptops when the user is not on your LAN." A user identified as gstornelli advised: "On small, well-protected networks, I have used group policy to disable the firewall while the workstation is on the network, and enable the firewall while the workstation is off the network. That way you don't have to deal with apps that are only run while in the office, while protecting the notebook users when they're on the road." A user identified as poppaman2 advised: "While I agree that a desktop firewall is a good idea, I disagree that the XPSP2 firewall should be deployed. It is an ingress-only firewall and leaves outgoing data untouched. I suggest, depending upon how much security is needed, something a bit more robust, such as Sygate, Tiny, Black Ice or Zone Alarm."

SearchSecurity.com Copyright TechTarget 2006

55

A user identified as amigus advised: "I disagree with the notion that an ingress-only firewall is not useful or adequate. Egress filtering usually comes with a significant maintenance burden. While egress filtering is very useful (and often recommended) on network firewalls it's not that useful on workstations. In my opinion, there are only two reasons you would want to use egress filtering: 1. You want to limit the communications of user-installed applications. 2. You have spyware problems. With respect to limiting application network exposure, it's rather difficult because (most of the time) if they can install applications, they can also pass through the firewall using the same privilege they used to install it. With respect to spyware, again, the user probably has too much privilege. With that said, I believe egress filtering is more trouble than it's worth and for what it's worth, it seems Microsoft agrees. If you're serious about security, spend your time making your network work with unprivileged user accounts, rather than wasting your helpdesk resources configuring cranky firewalls. If you really want egress filtering, implement it on your network firewall. And, if you really want to limit the scope of workstation communication, use IPSec." Traffic flow considerations for the Cisco PIX Firewall 17 Mar 2005 | Tom Lancaster | SearchSecurity.com In most small environments, firewalls are deployed in simple, common schemes, such as a firewall with three "legs": one for the Internet, one for the intranet and one for a DMZ. Another common scheme is two firewalls in series, where you have the intranet, a firewall, the DMZ, another firewall and finally the Internet. But as time goes by, things seem to become more complex. Some designs can get fairly contorted, putting firewalls in awkward positions that can compromise your security if you're not careful. In any event, you need to pay attention to how traffic flows through your firewall. And this is particularly true of the Cisco PIX Firewall. While it's one of the most highly regarded firewalls, it does have some quirks that may not be obvious to the casual observer. Primarily, you should make sure that the security levels on the interfaces reflect the realities of the traffic that flows through your network. This is because of the way the Adaptive Security Algorithm works. For starters, the ASA sets the default permissions. By default traffic is allowed to pass from an interface with a "higher" security level to a "lower" security level (such as from the Inside (100) to Outside (0) interfaces) but not from lower to higher. However, you may be tempted to override those with accesscontrol lists, because, for example, another administrator wants to place a server in a zone where it really doesn't belong, and expects you to secure it anyway. Or maybe you want traffic to go in and out of a zone through the same interface. SearchSecurity.com Copyright TechTarget 2006

56

So, you can configure the PIX in this manner, and it will block traffic like you configure, but what you need to realize is that you may not be getting the benefit of all the PIX's stateful features, again because of the way the ASA works. Specifically, features like the inspection engines and HTTP(S) and FTP filtering only work in one direction. For example, SMTP inspection is only from lower to higher interfaces, while NetBIOS inspection only applies from higher to lower interfaces. Filtering is only from higher to lower. Thus, you may be paying for and expecting the robust protection of a top-shelf firewall, but designing yourself into a level of protection not much better than ACLs on a regular router. So as a general rule of thumb, don't put any security device into an unconventional situation without some due diligence. One last caveat: The details of the behavior of these features may change as new versions of the PIX OS are released, so don't rely on my examples above to guide your design; check it yourself on CCO. About the Author: Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years experience in the networking industry, and co-author of several books on networking, most recently, CCSPTM: Secure PIX and Secure VPN Study Guide published by Sybex. Firewall security tips 28 Oct 2004 | Shelley Bard | SearchSecurity.com When When vulnerabilities are identified that apply to your system and whenever patches and upgrades are applied. Examine your guidance policies at least annually. Why When your organization's networks are connected to the Internet without adequate security measures, you are vulnerable to attack. Strategy In the limited space available here, I cannot possibly address how to secure a firewall. Instead, I'll note the considerations that go into doing so and point you to some useful resources. CNSS Instruction No. 4009, revised May 2003, National Information Assurance (IA) Glossary defines a firewall as a "system designed to defend against unauthorized access to or from a private network." I prefer CERT's definition: "A combination of hardware and software used to implement a security policy governing the network traffic between two or more networks, some of which may be under your administrative control (e.g., your organization's networks) and some of which may be out of your control (e.g., the Internet)."

SearchSecurity.com Copyright TechTarget 2006

57

A DMZ (Demilitarized Zone) is a combination of firewalls -- a perimeter network segment logically between internal and external networks. Also called a "screened subnet," its purpose is to enforce the internal network's IA policy for external information exchange and to provide external, untrusted sources with restricted access to releasable information while shielding internal networks from outside attacks. In some circles the DMZ is considered a part of the firewall, while other circles consider the DMZ the land of the sacrificial hosts. One way to think of a DMZ is as a group of hosts that are guided by a unique security policy. This policy balances some of the strictest controls against public access and availability requirements. When putting in a firewall, CERT recommends a four-part approach: prepare, configure, test and deploy. To prepare, design the firewall system and have a written firewall security policy for each one that identifies who is allowed to log in to it, configure and update it. It should also outline the logging and management practices. The next step is critical: configure. Here you will acquire the firewall hardware and software; acquire the documentation, training and support; install the firewall hardware and software; configure IP routing, packet filtering, and logging and alert mechanisms. DISA's Network Infrastructure Security Checklist, Version 5 release 2.2, is a combination of minimum security requirements and best practices designed to ensure a system is locked down as much as possible while still being useful. The Checklist requires, for example, that firewalls placed in the network infrastructure are only those having a Common Criteria (CC) Protection Profile evaluation of EAL4 or greater. Check out the CC Protection Profile evaluation product ratings. The Network Infrastructure Security Checklist discusses, among other things, which features of Cisco's IOS and Juniper's JUNOS systems should be present or absent for a more secure network setup. Next, test the firewall and deploy the system into operation. Considerations to fold into your planning and configuration include proxies, stateful inspection or dynamic packet filtering, network address translation, virtual private networks, IPv6 or other non-IP v4 protocols, network and host intrusion detection and prevention technologies, routing and route management, switching and virtual local area networks, and encryption technologies More information Helpful checklists can be found at the NIST Web page. A nifty feature of this page is a sign-up for email notifications when a checklist or implementation guide has been updated. And William R Cheswick & Steven M Bellovin's "Firewalls and Internet Security" will help you appreciate how far we've come and yet how little we've accomplished in firewall technology and practices in 10 years. About the Author: Shelley Bard, CISSP, CISM, is a senior security network engineer with Verizon Federal Network Systems (FNS). An information security professional for 17 years, Bard has briefed and written infosecurity assessments and technical reports for the White House and Department of Defense, special interest groups, industry and academia.

SearchSecurity.com Copyright TechTarget 2006

58

Opinions expressed in this column are those of Shelley Bard and don't necessarily reflect those of Verizon FNS. Firewall redundancy: Deployment scenarios and benefits 20 Apr 2004 | Mike Chapple | SearchSecurity.com Many network administrators have considered implementing dual firewalls. It is an expensive option, and the administrator who proposes the idea is likely to encounter a response like "$5,000 for a firewall? Don't we have one of those already?" There are, however, several good reasons to deploy multiple firewalls in your organization. Let's take a look at a few scenarios. Fault tolerance and load balancing Many organizations choose to implement dual firewalls in a parallel fashion, as shown in the figure below. When the router is properly configured, this provides the added benefits of fault tolerance and load balancing. Both firewalls should be configured to "fail-safe," that is, in the event of a failure, they should automatically block all traffic. When configured in this fashion, the firewalls provide fault tolerance; when one fails, the other is able to carry the network traffic and keep the failure transparent to users.

The second benefit to this strategy, load balancing, is a performance benefit. The router may be configured to divide traffic between the two firewalls, either on a priority basis or on a fair-share basis. Spreading the traffic out among multiple firewalls in this fashion helps prevent the bottleneck problems that plague many networks. Enhanced perimeter protection It's also possible to deploy the two firewalls in a series circuit, as shown in the illustration below. When configured in this fashion, all traffic passing into or out of the network must pass through both firewalls. This setup is sometimes deployed in high-security environments to protect against firewall-specific vulnerabilities. In this case, the two firewalls are from different vendors and may even run on different operating systems.

SearchSecurity.com Copyright TechTarget 2006

59

Protected subnets The final scenario we'll discuss is shown in the figure below. In this case, secondary firewall(s) are used to protect subnets of the internal network that have greater security requirements than the network as a whole. This type of scenario may be used, for example, to provide an accounting department added protection for sensitive financial data they wish to protect from other internal users.

Overall, the deployment of multiple firewalls offers a variety of benefits, ranging from greater performance to enhanced security. If your security environment warrants this type of scenario and your wallet is big enough, it's definitely an option worth considering. About the Author: Mike Chapple, CISSP, currently serves as Chief Information Officer of the Brand Institute, a Miami-based marketing consultancy. He previously worked as an information security researcher for the U.S. National Security Agency. His publishing credits include the TICSA Training Guide from Que Publishing, the CISSP Study Guide from Sybex and the upcoming SANS GSEC Prep Guide from John Wiley. He's also the author of About.com Guide to Databases.

SearchSecurity.com Copyright TechTarget 2006

60

VPNs Glossary definition: SSL SearchSecurity.com Secure Sockets Layer The Secure Sockets Layer (SSL) is a commonly-used protocol for managing the security of a message transmission on the Internet. SSL has recently been succeeded by Transport Layer Security (TLS), which is based on SSL. SSL uses a program layer located between the Internet's Hypertext Transfer Protocol (HTTP) and Transport Control Protocol (TCP) layers. SSL is included as part of both the Microsoft and Netscape browsers and most Web server products. Developed by Netscape, SSL also gained the support of Microsoft and other Internet client/server developers as well and became the de facto standard until evolving into Transport Layer Security. The "sockets" part of the term refers to the sockets method of passing data back and forth between a client and a server program in a network or between program layers in the same computer. SSL uses the public-andprivate key encryption system from RSA, which also includes the use of a digital certificate. TLS and SSL are an integral part of most Web browsers (clients) and Web servers. If a Web site is on a server that supports SSL, SSL can be enabled and specific Web pages can be identified as requiring SSL access. Any Web server can be enabled by using Netscape's SSLRef program library which can be downloaded for noncommercial use or licensed for commercial use. TLS and SSL are not interoperable. However, a message sent with TLS can be handled by a client that handles SSL but not TLS. Glossary definition: IPsec SearchSecurity.com IPsec IPsec (Internet Protocol Security) is a framework for a set of protocols for security at the network or packet processing layer of network communication. Earlier security approaches have inserted security at the application layer of the communications model. IPsec is said to be especially useful for implementing virtual private networks and for remote user access through dial-up connection to private networks. A big advantage of IPsec is that security arrangements can be handled without requiring changes to individual user computers. Cisco has been a leader in proposing IPsec as a standard (or combination of standards and technologies) and has included support for it in its network routers. IPsec provides two choices of security service: Authentication Header (AH), which essentially allows authentication of the sender of data, and Encapsulating Security SearchSecurity.com Copyright TechTarget 2006

61

Payload (ESP), which supports both authentication of the sender and encryption of data as well. The specific information associated with each of these services is inserted into the packet in a header that follows the IP packet header. Separate key protocols can be selected, such as the ISAKMP/Oakley protocol. Officially spelled IPsec by the IETF, the term often appears as IPSec and IPSEC. Book chapter: Crypto basics: VPNs Chey Cobb | John Wiley & Sons | SearchSecurity.com In this excerpt of Chapter 3 from "Cryptography for Dummies," author Chey Cobb explains how virtual private networks (VPNs) use encryption to secure data in transit. When businesses communicate over the Internet, there is no protection promised or implied. Everything is done out in the open and can be seen, captured, destroyed or copied by anyone who cares to try. It's like cities, towns and villages connected by roads. You transport whatever is on those roads at your own risk. Businesses began to see the need for a safer alternative as they did business with remote partners and employees in remote locations. Thus, the Virtual Private Network (VPN) was invented. VPNs use encryption to protect the traffic between any two points. It's like building a tunnel with special access controls between those cities, towns and villages. The tunnels aren't available to everyone, and to the people up above, they are invisible. Before you can enter the tunnel, you must prove your identity, your packages must be of certain types and the delivery address must be verifiable. If that isn't secure enough for you, a VPN also has the ability to disguise the packages through encryption. That way, if someone manages to gain unauthorized access by fooling the access guards or by digging another tunnel that intersects with your tunnel, the intruder won't know which packages to steal because he can't tell one from another. VPNs have been around for enough years now to consider them a standard security mechanism. On the other hand, the way vendors create their VPN hardware and software is not necessarily interoperable. If you are communicating with someone who doesn't have the same sort of setup, it may take a few days or weeks of juggling cables and commands to get it working correctly. In general, VPNs are considered fairly reliable as far as security mechanisms go. Sure, there are hacks, but you really don't hear about too many of them. Either they are not happening often, or companies are just not telling. VPNs are capable of encrypting two different ways: transport and tunneling. The transport encryption sets up a secure, encrypted link across the Internet wires, and it encrypts the data (payload) you are sending to the other end. This is the equivalent of the delivery truck carrying a package via the underground passageway. (I'm not using the word tunnel here because I don't want to confuse you!) The encryption is invisible to the user — other than passwords, passphrases, or a special card to plug into the computer, the user doesn't have to press a button that says "encrypt" or "decrypt." All the data in transit SearchSecurity.com Copyright TechTarget 2006

62

is protected from sight. The only drawback to transport encryption is the fact that the headers on the data are sent in the clear. In effect, that's like disguising the package and then putting a label on it that says what's inside. Maybe not the smartest thing to do considering that intruders may occasionally gain access. The other form of VPN encryption, tunneling, not only sets up a secure, encrypted link between two points, but it also encrypts the headers of the data packets. That's better. Not only do you have a disguised package, but the address and the contents listed on the package's label are in code so they're not easily recognizable. As I mention earlier, the VPN standards aren't necessarily standard, so you'll have to see what protocols the vendor is using. The vendor will have tons of transfer protocols to choose from, but the tunneling protocols are fairly limited. Just to give you an introduction, here are the tunneling protocols: • • • • •

GRE = Generic Routing Encapsulation IPsec = Secure Internet Protocol L2F = Layer 2 Forwarding PPTP = Point To Point Tunneling Protocol L2TP = Layer 2 Tunneling Protocol (PPTP + L2F)

If you set up a VPN for your customers, business partners and employees, they can gain some comfort in the fact that their data isn't traveling in the clear. One point to remember, though: Many road warriors have automated the process of logging in to their VPN and have a shortcut on the desktop. On top of that, a laptop is not properly protected with proper access controls -- turn it on and it's yours. In this instance, a stolen laptop can easily be used to log on to a VPN, and you'll never know it unless the employee alerts you. In addition to access controls for laptops, you may also want to consider disk encryption to protect the data stored on the laptop. Just something to keep in mind. VPNs are relatively easy to set up now, and you can usually find experienced staff to install and manage them. As I mention earlier, sometimes it takes a little effort to get two different VPNs talking to one another, but that doesn't last forever. Many vendors are including VPN capabilities in their routers so the system is practically plug and play. Just remember to change the default settings such as the administrator password. VPNs are great at protecting the data in transport, but they do not encrypt the data on your drives -that data is still in the clear. SSL VPN: AEP SureWare A-Gate AG-600 23 Aug 2005 | George Wrenn | SearchSecurity.com AEP SureWare A-Gate AG-600 AEP Systems, www.aepnetworks.com Price: $8,995/400 users

SearchSecurity.com Copyright TechTarget 2006

63

AEP Systems SureWare A-Gate AG-600 provides SSL VPN remote access for connecting external users to internal systems. The appliance provides clientless access to HTTP and Windows Terminal Server apps and full access to client-server apps from Windows XP/2000 clients. It has four Ethernet interfaces, features high availability and session-level failover and handles 400 simultaneous connections. Enterprises will appreciate its capacity to cluster up to 16 boxes for supporting thousands of users. AEP packs strong security in the AG-600, which runs a hardened version of Linux. Booting the box over a serial connection initially blocks access to system resources. You'll need to set a password and options for Web-based administration, remote root logins to the network, SSH, syslog and SNMP to unlock configuration. This is a radical departure from security hardware that, once connected, and without so much as a password, allows anyone to configure network and device settings. We launched a browser, authenticated and proceeded to solve the obfuscated text riddle, or 'completely automated public Turing test to tell computers and humans apart' (CAPTCHA) utility. CAPTCHA is an image with slightly skewed characters and numbers, designed for enhancing authentication and preventing automated attacks. You decipher and type a displayed code and enter a user name and password. Configuration is a comprehensive process using GUI setup tabs, although the interface conspicuously lacks a help menu. We methodically assigned IP addresses to Ethernet interfaces and configured the LAN/WAN interfaces, DNS server, incoming access to port 443 (SSL) and external gateway to route traffic to the Internet. Setting up digital certificates for authenticating users is a breeze. Clicking on the site security tab allows you to create a certificate signing request (CSR). We pasted our CSR into a VeriSign form to access a trial certificate, and, with our new SSL-site identity, we configured the remote access policy. AG-600 supports two Windows authentication options: LDAP for AD domains, and the Windows Server Message Block file sharing protocol (SMB) for old-school domain services. A-Gate also integrates with Sun LDAP and Novell NDS servers. Its RADIUS support hooks into other authentication methods, including CASQUE, Crypt-Card and SecurID. Our configuration using the internal database and Windows SMB domain authentication worked flawlessly. AG-600 provides two modes of VPN access: A-Gate Anywhere can proxy application traffic via a Java applet, for instance, to Windows Terminal Services; the A-Gate Central is a thin-client SSL VPN that enables access to TCP/UDP applications. Users launch the client by clicking the link on the user A-Gate portal page, which is customizable to reflect user's branding. Establishing WAN access to these services was an easy configuration of A-Gate's host MYSQL database, server names and IP addresses. But, adding the Anywhere Web servers to the remote access configuration, and again in the portal page, was bothersome; an automated mechanism would be easier. SearchSecurity.com Copyright TechTarget 2006

64

Policy configuration was a challenge. While we easily defined a HTTP global access policy for authenticated users, the GUI made it tough to configure more granular access control rules. It's confusing to decipher how menu branches relate to others in the tree. A more intuitive grid or matrix for defining devices, URL strings as services and authorized users/groups would be simpler. While AG-600's granular policy and portal elements could use some tweaking, this hardcore appliance provides enviable security defaults and convenient access to sensitive applications. About the Author: George Wrenn, CISSP ([email protected]), is a technical editor for Information Security and a security director at a financial services firm. He's also a fellow at the Massachusetts Institute of Technology. Corrent VPN 'connects' with Check Point software 7 Jul 2005 | Mike Chapple | SearchSecurity.com Corrent's SR110 SSL VPN Web Security Gateway with Check Point Connectra 2.0 Corrent, www.corrent.com Price: Starts at $11,700 for hardware and software license Corrent's SR110 SSL VPN Web Security Gateway, an appliance running Check Point Software Technologies' Connectra 2.0 SSL VPN software, offers easy administration, an intuitive client experience and strong security. However, the SR110 is priced in the upper tier of VPN appliances. The Connectra software provides point-and-click administration through a well-designed Web interface. User authentication may be managed through the internal Connectra user database, but enterprises will prefer to integrate with LDAP, RADIUS and SecurID systems for authentication and authorization. We used Connec- tra's LDAP interface to perform authentication against Active Directory. The Web-based process for adding applications is straightforward. For example, to add a Web application, we simply specified the name and location of the application and the desired protection level (a combination of allowable authentication techniques and caching status). The SSL Network Extender ActiveX control, a Connectra Web plug-in, allows the use of any network-based Windows application. It tunnels endpoint traffic over SSL. We used the SR110 to access a Windows Server 2003 file server, an Exchange 2000 Web Outlook server, an IMAP server (using the Connectra integrated client) and several Web-enabled apps. Clients are presented with the Connectra portal, which provides a consolidated view of authorized apps.

SearchSecurity.com Copyright TechTarget 2006

65

Connectra leverages Check Point's experience in perimeter security by integrating the Smart-Defense network and application security controls. Network security controls include protection against DoS attacks (such as Teardrop and LAND), TCP/IP protocolbased attacks and network probes; application controls include inspection of HTTP and FTP traffic. The controls stopped several of our URL-based attacks, as well as a SQL injection attack against a Web-based form. The wizard-based installation was smooth, taking about an hour from opening the box to establishing client connections. The installation guide provides detailed instructions for a variety of network configurations, including template firewall rules necessary for installing the appliance in a DMZ. The SR110 has six Ethernet ports, two of which support Gigabit Ethernet. We were disappointed with Connectra's lack of Fire-fox client browser support, but Web portal access is available through IE, Mozilla, Netscape and Safari. SSL Network Extender functionality is limited to IE on Windows 2000/XP. The SR110's steep price may discourage some enterprises. The $3,700 cost of Corrent's appliance combined with the $8,000 cost of a 50-user Connectra license from Check Point (which increases to $30,000 for 250 users) makes the price tag soar far above some established competitive products. For example, a Cisco VPN 3005 concentrator (which supports 50 SSL VPN sessions) lists at $2,995, and $35,000 will purchase a Cisco VPN 3060, which supports 500 clientless Web sessions. Price notwithstanding, an appliance that incorporates ease of use for admins and users and strong security offered by Connectra merits consideration for secure access to enterprise applications. About the Author: Mike Chapple, CISSP, currently serves as Chief Information Officer of the Brand Institute, a Miami-based marketing consultancy. He previously worked as an information security researcher for the U.S. National Security Agency. His publishing credits include the TICSA Training Guide from Que Publishing, the CISSP Study Guide from Sybex and the upcoming SANS GSEC Prep Guide from John Wiley. He's also the author of About.com Guide to Databases. Quiz: SSL vs. IPsec VPNs SearchSecurity.com Test your knowledge of IPsec and SSL VPNs with this quiz to help you determine which technology best suits your organization's needs. 1.) Which type of VPN encryption sets up a secure, encrypted link between two points, but does not encrypt the headers of the data packets? a. Transport encryption b. Tunneling encryption SearchSecurity.com Copyright TechTarget 2006

66

2.) Which of the following is a basic requirement of an SSL VPN? a. Proxy access and protocol conversion b. Remote-access orientation c. Extranet support d. Highly granular access controls e. All of the above 3.) In which scenario is an IPsec VPN generally considered a better solution than an SSL VPN for remote access? a. Telecommuters coming from fixed sites, using managed corporate devices and terminating in a secure, private network on either side. b. Telecommuters without fixed access who want to come in from a variety of sites. 4.) Which layer of the network does an IPsec VPN operate on? a. Layer 3 b. Layer 4 c. Layers 4 though 7 d. None of the above 5.) Which of the following operational modes is the simplest and most usable, as well as the most supported by SSL VPNs? a. Application translation b. Port forwarding c. Proxy d. Network extension 6.) Which of the following describes an IPsec VPN? a. Requires host-based clients and hardware at a central location. Users have full office functionality, but there's very little granularity in access control. b. Does not require a client download. Remote connections made via a Web browser or a downloadable Java or ActiveX agent. Role-based access can be assigned for each user, and application and client administration is eliminated. 7.) True or False: SSL VPNs are inherently less secure than IPsec VPNs. a. True b. False 8.) Encapsulating Security Payload (ESP) allows for... a. Authentication of the sender of data b. Encryption of the data c. Both authentication of the sender and encryption of the data d. None of the above 9.) Which of the following features of SSL VPNs help avoid the risk of leaving sensitive information on public PCs used to access a corporate network? a. Secure logout SearchSecurity.com Copyright TechTarget 2006

67

b. Credential scrubbing c. Auto forms completion disabling d. All of the above 10.) What is the transmission of data through a public network in such a way that the routing nodes in the public network are unaware that the transmission is part of a private network? a. Tunneling b. Virtual private network c. Output feedback d. Promiscuous mode Answer Key: 1. a. Transport encryption 2. e. All of the above 3. a. Telecommuters coming from fixed sites, using managed corporate devices and terminating in a secure, private network on either side. 4. a. Layer 3 5. c. Proxy 6. a. Requires host-based clients and hardware at a central location. Users have full office functionality, but there's very little granularity in access control. 7. b. False 8. c. Both authentication of the sender and encryption of the data 9. d. All of the above 10. a. Tunneling Letting telecommuters in -- Your VPN alternatives 1 Oct 2005 | Rebecca Rohan | SearchSecurity.com There are other options to give telecommuters access to your network and its applications than a traditional VPN. According to this article from Informit, if you weigh your access and security requirements against the cost and complexity needed you might find other options to a traditional VPN. What are the best ways to let telecommuters into your network? The answer that helps administrators sleep most securely is a fixed Virtual Private Network (VPN). A VPN uses end-to-end encryption to carve out a private tunnel over the public network. The most secure VPN is the traditional arrangement with the telecommuter coming from a fixed site, ideally using a managed, corporate device and terminating in a secure, private network on either side. Quite a bit of effort can go into setting up this arrangement; you need to see that hardware, software and settings, as well as SearchSecurity.com Copyright TechTarget 2006

68

authentication, are set up perfectly and maintained on both ends, despite user changes to software, firmware and hardware, but the security can be worth the trouble. Let's throw out some protocols -- literally. There are three or four at this end of the pool. Only one from this group is secure enough to take seriously: IPSec, especially in conjunction with L2TP. IPSec is the standard to buy; it encrypts at the packet level. PPTP has weak encryption keys, weak password hashing and unauthenticated control traffic. L2TP traffic can be read by network sniffers. However, when combined with IPSec for encryption, L2TP becomes unreadable and offers IPSec authenticated access for multiple protocols. Just be sure the device you buy supports the combined IPSec and L2TP standard. SSL Maybe you have mobile employees without fixed access who want to come in from a variety of sites. Salespeople are the typical example, as they may need to connect to your network from a hotel room or a customer site. Things may actually be easier for them, depending on how much trust they request from your network. In recent years, Secure Sockets Layer (SSL) VPN appliances, such as those sold by Aventail and Juniper, have sprung onto the planet and ask nothing of the visitor except an SSL-enabled browser -- no software installation, no matching hardware. Remote users can come into the VPN from anyplace that has an SSL browser or kiosk. The administrator manages access rights and authentication rites in advance, setting up different rules based on who the user is, how secure a "neighborhood" he's calling from and so on. If he phones into the office from an airport kiosk, the user may not see those medical records he would get if he were calling from an approved device at home -- at least not if the administrator set things up correctly. You don't want the good doctor looking at your record from the airport, because he can forget to log out. "Hey, look at this, man." "Is this thing on?" Talk about letting in the rabble. And therein lies the first of the security concerns with SSL VPNs. Another concern with SSL VPNs is the recent discovery that local desktop search engines cache and index SSL VPN sessions, even though the VPNs have tools to wipe their own caches. Some SSL VPN vendor tools are available to combat this new threat. Microsoft Terminal Services Microsoft Terminal Services lets users work on applications in thin client fashion from a remote location. Terminal Services, part of Windows' NT Server 4.0 Terminal Services Edition, Windows 2000 and .NET Server, is a time-honored institution at many shops with ID badges and telecommuters who sport authentication token fobs. They get a new password number each 30 seconds and type it, along with their login, whenever they need to get in. (That's just one way to authenticate, of course.)

SearchSecurity.com Copyright TechTarget 2006

69

When initially released, "Term Server," like its parent Citrix WinFrame from Citrix Systems Inc., became an enticing way for many shops to let employees access applications remotely, and it remains so to this day. With the addition of Citrix' Secure ICA Services' 128-bit, end-to-end encryption, (not included) Term Server traffic becomes more secure. You have to think about what happens after that secure log-in. Remote Control Perhaps the easiest to set up, lowest-budget solution for telecommuter access is remote control software, such as Symantec's PC Anywhere. These packages allow the remote user to literally control the machine back at the office. VNC is an open source selection that runs on Windows, Mac, Linux and other platforms; it can be more trouble and additional skills are required, but you only pay if it works. Some remote control software, such as Netopia's Timbuktu Version 7, use non-standard encryption when sending copies of your screen over the Internet. Currently, Timbuktu uses a proprietary method to scramble bits and randomize parts of the screen. Experts advise against using home-grown encryption, as even well-known methods often fail to pass muster once put under scrutiny and, with a proprietary cipher, you're getting what Gramma called "a pig in a poke." (Netopia says it plans to employ an as-yet unannounced form of standard encryption in its next version of Timbuktu.) Meanwhile, Altiris Inc.'s Carbon Copy uses 128-bit MD5 encryption during authentication only, and the MD5 collision weakness that came to light in 2004 shouldn't be a problem for Carbon Copy. However, Carbon Copy's data stream is guarded by a 64bit proprietary encryption key for each packet sent. Users may define any key for authentication of the data stream -- presumably if they provide the key. Symantec Corporation just announced PC Anywhere 11.5 with AES encryption (up to 256-bit cipher strength) for both authentication and the data stream. The new version of pcAnywhere also offers host address blocking, 13 different methods of authentication (including RSA SecurID authentication), the ability to specify TCP/IP addresses and subnets that are allowed to connect, and the option to hide pcAnywhere hosts from TCP/IP browse lists. Check security specs before you buy, because these things change. Go to BugTraq (http://www.securityfocus.com/archive/1) and check the product name (in date order) for security reports. Also, make sure you can blank the screen in the office so telecommuters don't have an audience watching what they're doing from home.

SearchSecurity.com Copyright TechTarget 2006

70

The inherent capabilities of IPSec selectors and their use in remote-access VPNs 31 Mar 2004 | Lisa Phifer, VP, Core Competence, Inc. | SearchSecurity.com In a SearchSecurity webcast, speaker Lisa Phifer, vice president and owner of consulting firm Core Competence, addressed technological developments in virtual private networks. Here Lisa answers a user-submitted question that she didn't have time to answer during the broadcast. If you missed our webcast, New Directions in VPNs, or would like to review it, you may listen to the recorded webcast on-demand. You mentioned during the webcast that IPsec can access the entire network behind the firewall whereas SSL can access only the assigned server. But I noticed that you set that in IPsec by setting the subnet address range rather than the entire network. Am I missing something here? Good catch. I didn't elaborate on this in the webcast, but there's a difference between the capabilities inherent in IPsec selectors (traffic filters) and the way in which most companies use them. IPsec selectors can be based on entire IP subnets, partial subnets, individual destinations, protocol types and source/destination ports. That means that it's possible to create an IPsec selector that permits encrypted access to just one server and just one application (port) on that server (depending upon product support). But in practice, most remote-access VPNs are configured with fairly coarse IPsec selectors, allowing access either to an entire subnetwork or (more often) to all destinations (0.0.0.0/0.0.0.0). The latter is very common; to avoid split tunneling, all outbound traffic is sent via the IPsec tunnel. Once the traffic reaches the VPN gateway, it is decrypted and forwarded along to the final destination, whether that's inside the private Intranet or somewhere on the public Internet. This configuration lets the company monitor, log and filter all user traffic, no matter what the destination -- for example, stripping a malicious attachment at the VPN gateway that the user might otherwise pick up while downloading shareware from a public Web site. SSL VPNs that act as circuit-layer proxies can be configured in a similar fashion to forward all outbound application traffic across the SSL VPN tunnel. However, many SSL VPN products are configured in a more granular fashion to ignore or drop traffic that lies outside the VPN policy and relay only that application traffic covered by the VPN's policy. SSL VPN products do tend to allow more granularity in filter configuration than even the most granular IPsec selectors -- for example, filtering on individual URLs, Web objects or even application commands. Using this kind of fine granularity can require more complex policy maintenance and so is usually done with group-level policies that apply the same complex filters to a set of users, rather than to individual users. In short, product capabilities vary, but it's more important to decide the level of policy granularity your business requires, and then make sure the product you pick can support than level of granularity without a lot of administrative overhead.

SearchSecurity.com Copyright TechTarget 2006

71

About the Author: As owner of consulting firm Core Competence, Lisa Phifer advises companies regarding security needs, product assessment and the use of emerging technologies and best practices. She has been involved in the design, implementation and evaluation of security and network management products for more than 20 years. VPN fast facts: True or false? 1 Aug 03 | Lisa Phifer, VP, Core Competence | SearchSecurity.com SSL VPNs are inherently less secure than IPSec VPNs. False. While they differ architecturally, both VPNs can be deployed securely -- or poorly. Security builds upon standards and products that implement them, but ultimately depends upon appropriate deployment and sound policy definition. SSL VPNs can be used anywhere that IPSec VPNs can be used. False. IPSec is generally considered a better solution for site-to-site VPNs, where it better satisfies broad application needs and performance demands. SSL is better suited in scenarios where VPN administrators have no control over client software installation, such as extranet collaboratives or nonwork computers (kiosks and homes). SSL VPNs are suitable for enterprise-class deployment. True. Some SSL VPN gateways are designed for large-scale deployment. They support high user volume, encryption via hardware acceleration and redundancy through failover and load balancing. Many argue that SSL VPNs are more suitable for large populations because they reduce the cost of software distribution. To meet the needs of different constituencies, many companies will likely end up with both. IPSec VPNs offer more extensible infrastructure. True. IPSec was designed to secure any IP traffic and is configurable to support any IP application. SSL was designed to secure HTTP and has been successfully extended to secure many other applications. However, extensibility ultimately depends on how an SSL VPN product is designed and performs in production environments. About the Author: As owner of consulting firm Core Competence, Lisa Phifer advises companies regarding security needs, product assessment and the use of emerging technologies and best practices. She has been involved in the design, implementation and evaluation of security and network management products for more than 20 years. Client-side security considerations for SSL VPNs 23 Mar 2004 | Lisa Phifer, VP, Core Competence, Inc. | SearchSecurity.com Companies tired of VPN client software installation and configuration are being increasingly drawn to "clientless" solutions like SSL VPNs. However, using a browserbased VPN to go "clientless" still requires client-side vulnerability analysis and mitigation. SearchSecurity.com Copyright TechTarget 2006

72

The lure of SSL VPNs According to Frost and Sullivan, the SSL VPN market exploded in 2002, growing at a compound annual rate of 49% through 2010. The big draw? SSL VPNs leverage browsers present on nearly every desktop and handheld to avoid adding software. Security policy can be largely dictated by the VPN gateway, reducing remote configuration. Circumventing these IT pain points should cut the cost of remote access. What's more, browser-based VPNs enable remote access from more locations. Travelers can use public PCs at business centers and Internet cafes. Teleworkers can use home PCs without IT oversight. Business partners can use PCs administered by other companies. Permitting remote access from these venues increases convenience, availability and productivity. But, there's a catch: loss of IT control over the hosts used for remote access. Leave nothing behind Most public PCs contain traces of past user activity: Outlook inboxes filled with private email, browser caches containing Webmail text and password-laced cookies, and file attachments saved to temp directories. Leaving this sensitive data behind on public PCs poses considerable risk, but relying on users to clean up after themselves is a very bad idea. Many have no idea what they leave behind; even those who know how to wipe their tracks clean make mistakes. To address this risk, most SSL VPNs take steps to automatically clean up after each remote access session, no matter who owns the remote PC. Features to look for when considering SSL VPN products include: •

Secure logout -- Forced session disconnection and browser window close, typically based on centrally defined inactivity or duration timeouts.

•

Credential scrubbing -- Deleting cached credentials at session end or preventing them from being cached on the client in the first place.

•

Temp file clean up -- Deleting files created during the session or blocking their creation, including cached pages, offline content and downloaded programs.

•

Cookie blocking -- Removing cookies at session end, or better yet, no personally identifiable or reusable information written to cookies during sessions.

•

Auto forms completion disabling -- Avoiding client storage of data entered in private Web page forms that might otherwise be visible to subsequent users.

•

Personal information profile disabling -- Preventing access to, and use of, user data commonly integrated with browsers, like Outlook Address Book entries.

•

Browser history removal -- Stopping VPN URLs from being used as a launch point for common Web server attacks (e.g., password-guessing, DoS floods, script injection).

Prevent tunnel compromise Post-session clean up is essential, but it doesn't go far enough. PCs available for public use in cafes, airports and conference centers are readily accessible to strangers 24/7, SearchSecurity.com Copyright TechTarget 2006

73

greatly increasing the risk of compromise. Attackers can install packet-capture tools, keystroke loggers and even desktop session recorders to obtain usernames, passwords and private data. Spyware, remote access Trojans and denial-of-service zombies can be implanted to probe or attack corporate resources during active VPN sessions. To prevent IPsec/L2TP/PPTP VPN tunnel compromise on company laptops, most companies mandate client-side personal firewalls, antivirus software and up-to-date security patches. These measures are typically part of the "remote access bundle" that IT installs and configures on every host, either directly or by supplying software and instructions to employees. For "clientless" access, this may not be practical or possible. Some argue that SSL VPNs pose less risk because network VPNs use secure tunnels to connect remote hosts to private networks, while SSL VPNs typically connect individual client applications to private servers. A narrower window of opportunity can eliminate some vulnerabilities -- for example, preventing Trojan access to other systems and ports. However, this really depends upon the product and policy granularity. To implement more granular policies, look for products that can define access rights based not just on application, but also on individual commands (e.g., permit read but not write or delete) and user/group-specific URLs and objects (e.g., folders, accounts). Granularity is a double-edged sword: Look for incremental or hierarchical grouping features, and design your policies with both maintenance and performance in mind. Stop problems before they start A smaller window of opportunity helps, but is that enough? Depending upon your business risk, additional measures may be appropriate to secure your VPN. •

To adjust permissions to reflect threat level, look for products that support policies that differentiate between company-administered hosts and all others. For example, Nokia's Secure Access System can restrict access to applications and features, depending upon the system from which a VPN session is initiated.

•

To defeat password compromise by keystroke loggers and session recorders, use one-time passwords or two-factor authentication. Options are more limited on public PCs -- for example, USB tokens or biometric devices require client software -- but other mobile methods are widely supported (e.g., RSA SecurID, S/Key).

•

To defeat session data capture and client-side malware, look for VPN products that integrate client-side security checks into access policies. A growing number of VPN products now offer scan-on-connect. Examples include Microsoft Windows Server 2003 Quarantine, CheckPoint's VPN-1 SecureClient (integrated with PestPatrol and others), Cisco's VPN Client (integrated with ZoneLabs' Integrity), Aventail's End Point Control (integrated with Bluefire and others), and Neoteris (integrated with WholeSecurity and others). Scan-on-connect may ensure that desktop security measures are active and up-to-date and can sometimes detect the presence of malware, preventing VPN session establishment by compromised hosts. Although many do require installed client software, some SearchSecurity.com 74 Copyright TechTarget 2006

are "clientless" -- for example, Zone Labs' download-on-demand host integrity checker. These are just some of the steps you can take to address client-side security concerns for network-level and browser-based VPNs. Keep in mind that all VPNs pose some risk; effective VPN deployment requires understanding and managing inherent vulnerabilities. Going "clientless" with an SSL VPN may avoid new client-side software, but it still requires client-side vulnerability analysis and mitigation. About the Author: As owner of consulting firm Core Competence, Lisa Phifer advises companies regarding security needs, product assessment and the use of emerging technologies and best practices. She has been involved in the design, implementation and evaluation of security and network management products for more than 20 years.

SearchSecurity.com Copyright TechTarget 2006

75

Windows-specific network access control procedures Book chapter: Access control entries Paul Cooke | Realtimepublishers.com | SearchWindowsSecurity.com Access control entries While the ACL is the overall structure for providing permissions in Windows 2000, it's really the ACEs that carry all the real access control information. Although there are different types of ACE structures, as I mentioned earlier, all ACEs include a SID, an access mask, flags to determine inheritance of the ACE, and the ACE type. All ACEs are somewhat similar, but Windows 2000 supports six ACE types, as shown in Table 5.4. Of these six ACE types, three are generic and can be used in ACLs for any securable object. The other three are object-specific and can be used only in ACLs for AD objects. ACE

Type

Description

Accessdenied

Generic

Denies access to an object in a DACL.

Accessdenied

Objectspecific

Denies access in a DACL to a property or property set or to limit inheritance to a specified type of child object.

Accessallowed

Generic

Allows access to an object in a DACL.

Accessallowed

Objectspecific

Allows access in a DACL to a property or property set or to limit inheritance to a specified type of child object.

Systemaudit

Generic

Logs attempts to access an object in a DACL.

SystemObjectLogs attempts in a SACL to access a property or property set or audit specific to limit inheritance to a specified type of child object. Table 5.4: The six types of ACEs. While generic and object-specific ACEs are extremely similar, there are a couple of differences between them. The differences can be categorized primarily by the granularity of access control that they provide for ACE inheritance and object access. Generic ACEs can distinguish between container and non-container objects only when they're inherited, and they can only apply to an entire object. Object-specific ACEs can distinguish between which child objects can inherit them and can be used on a single attribute, or a set of attributes, of an object. Whether ACEs are generic or object-specific isn't something that you need to concern yourself with every day. Whenever you modify an ACL, Windows 2000 automatically SearchSecurity.com Copyright TechTarget 2006

76

constructs the appropriate ACE and takes care of all the implementation details. However, knowing a little bit about what is going on under the hood is useful. Book chapter: Six steps for deploying Network Access Quarantine Control Jonathan Hassell | Apress | SearchWindowsSecurity.com In this section, you'll look at the actual deployment of NAQC on your network. There are six steps, each outlined in separate subsections ahead. Creating quarantined resources The first step is to create resources that you can actually access while the quarantine packet filters are in place for a remote client. Examples of such resources include DNS servers and DHCP servers, so you can retrieve IP address and connection information and file servers that will download the appropriate software to update out-of-compliance machines. In addition, you can retrieve Web servers that may describe the quarantining process or allow a remote user to contact IT support via email if any problems occur. There are two ways you can specify and use a quarantined resource. The first is to identify certain servers on your network because these quarantine resources without regard to their physical or network location. This allows you to use existing machines to host the quarantined resources, but you also have to create individual packet filters for quarantined sessions for each of these existing machines. For performance and overhead reasons, it's best to limit the number of individual packet filters for a session. If you decide to go this route, you'll need to enable the packet filters shown in Table 7-1. Table 7-1. Packet filters for distributed quarantine resources Traffic Source Destination Alternatives type port port Notifier

n/a

TCP 7250

None.

DHCP

UDP 68

UDP 67

None.

DNS

n/a

UDP 53

You can also specify the IP address of any DNS server.

WINS

n/a

UDP 137

You can also specify the IP address of any WINS server.

HTTP

n/a

TCP 80

You can also specify the IP address of any Web server.

NetBIOS

n/a

TCP 139

You can also specify the IP address of any file server.

Direct hosting

n/a

TCP 445

You can also specify the IP address of any file server.

SearchSecurity.com Copyright TechTarget 2006

77

You can also configure any other packet filters peculiar to your organization. The other approach is to limit your quarantined resources to a particular IP subnet. This way, you just need one packet filter to quarantine traffic to a remote user, but you have to readdress machines and, in most cases, take them out of their existing service or buy new ones. When you use this method, the packet filter requirements are much simpler. You simply need to open one for notifier traffic on destination TCP port 7250, and one for DHCP traffic on source UDP port 68 and destination IDP port 67. For all other traffic, you should open the address range of the dedicated quarantine resource subnet. And again, you can also configure any other packet filters peculiar to your organization. Writing the baseline script The next step is to actually write a baseline script that will be run on the client. This is really independent to your organization, but all scripts must run RQC.EXE if the baseline compliance check was successful and they should include the following parameters: The switches and arguments are explained in the following list: •

The ConnName argument is the name of the connectoid on the remote machine, which is most often inherited from the dial-in profile variable %DialRasEntry%.

•

The TunnelConnName argument is the name of the tunnel connectoid on the remote machine, which is most often inherited from the dial-in profile variable %TunnelRasEntry%.

•

The TCPPort argument is, obviously, the port used by the notifier to send a success message. This default is 7250.

•

The Domain argument is the Windows security domain name of the remote user, which is most often inherited from the dial-in profile variable %Domain%.

•

The Username argument is, as you might guess, the username of the remote user, which is most often inherited from the dial-in profile %UserName%.

•

The ScriptVersion argument is a text string that contains the script version that will be matched on the RRAS server. You can use any keyboard characters except /0 in a consecutive sequence.

Here is a sample batch file script: @echo off echo Your remote connection is %1 echo Your tunnel connection is %2 echo Your Windows domain is %3 echo Your username is %4 set MYSTATUS= SearchSecurity.com Copyright TechTarget 2006

78

REM Baselining checks begin here REM Verify Internet Connection Firewall is live. REM Set CHECKFIRE to 1-pass, 2-fail. REM Verify virus checker installed and sig file up. REM CHECKVIRUS is 1-pass, 2-fail. [insert various commands to verify the presence of AV software and sig file] REM Pass results to notifier or fail out with message to user. if "%CHECKFIRE%" == "2" goto :NONCOMPLIANT if "%CHECKVIRUS%" == "2" goto :NONCOMPLIANT rqc.exe %1 %2 7250 %3 %4 Version1-0 REM These variables correspond to arguments and switches for RQC.EXE REM %1 = %DialRasEntry% REM %2 = %TunnelRasEntry% REM RQS on backend listens on port 7250 REM %3 = %Domain% REM %4 = %UserName% REM The version of the baselining script is "Version1-0" REM Print out the status if "%ERRORLEVEL%" == "0" ( set ERRORMSG=Successful baseline check. ) else if "%ERRORLEVEL%" == "1" ( set ERRORMSG=Can't contact the RRAS server at the corporate network. Contact a system administrator. ) else if "%ERRORLEVEL%" == "2" ( set ERRORMSG=Access is denied. Please install the Connection Manager profile from http://location and attempt a connection again. ) else ( set ERRORMSG=Unknown failure. You will remain in quarantine mode until the session timeout is reached. ) echo %ERRORMSG% goto :EOF :NONCOMPLIANT echo echo Your computer has failed a baseline check for updates on echo your machine. It is against corporate policy to allow out of SearchSecurity.com Copyright TechTarget 2006

79

echo date machines to access the network remotely. Currently echo you must have Internet Connection Firewall enabled and echo an updated virus scanning software package with the echo latest virus signature files. For information about how to echo install or configure these components, surf to echo http://location. Echo You will be permitted to access only that location until Echo your computer passes the baselining check. Of course, the batch file is simple. You can make it as complex as you like; you can even compile a special program, because the postconnect script option in CMAK allows you to run an .exe file. Installing the listening components The Remote Access Quarantine Agent service, known otherwise as RQS.EXE, must be installed on the Server 2003 machines that are accepting incoming calls using RRAS. RQS is found in the Windows Server 2003 Resource Kit Tools download, which you can find on the Microsoft Web site. Once you've run the installer for the tools, select the Command Shell option from the program group on the Start menu, and run RQS_SETUP /INSTALL from that shell. This batch file will copy the appropriate binaries to the WindowsRootSystem32RAS folder on your system and modify the service and Registry settings so that the listener starts automatically when the server boots up. NOTE: To remove RQS.EXE, type RQS_SETUP/REMOVE at a command prompt. There's a bit of manual intervention required, however. You need to specify the version string for the baseline script. The listener service will match the version reported by the remote computer to the value stored on the RRAS computer so you can make sure that the client is using the latest acceptable version of a script. To make this change manually after you've run RQS_SETUP from the Tools download, do the following: 1. Open the Registry Editor. 2. Navigate to the HKEY_LOCAL_MACHINESystemCurrentControlSetServicesRqs key. 3. Right-click in the right pane, and select New String. 4. Name the string AllowedValue. 5. Double-click the new entry, and enter the string that refers to an acceptable version of the script. Alternatively, you can modify the RQS_SETUP batch file, so this step can be automated for future deployments. Do the following: 1. Open the RQS_SETUP.BAT file in Notepad. 2. Select Find from the Edit menu. 3. In Find What, enter Version10, and click OK. The text cursor should be on a line that SearchSecurity.com 80 Copyright TechTarget 2006

says: REM REG ADD %ServicePath% /v AllowedSet / t REG_MULTI_SZ /d Version10Version1a0Test. 4. To add just one acceptable version, delete "REM" from the beginning of the line. 5. Now, replace the text "Version10Version1a0Test" with the script version string you want to be passed by RQC.EXE. 6. If you want to add more than one acceptable version, replace the text "Version10Version1a0Test" with the acceptable version strings, each separated by the "0" line. 7. Save the file, and then exit Notepad. RQS is set as a dependency of RRAS. However, when RRAS is restarted, RQS doesn't automatically restart, so you'll need to manually restart it if you ever stop RRAS manually. NOTE By default, RQS.EXE listens on TCP port 7250. To change the default TCP port, navigate to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesrqs key, create a new REG_DWORD value called Port, and set it to the desired port. Analyzing creating a quarantined connection profile The next step is to create a quarantined Connection Manager profile, which happens to be a plain-vanilla profile with a few modifications. For one, you need to add a postconnect action so that your baseline script will run and return a success or failure message to the RRAS machine. You also need to add the notifier to the profile. In this section, I'll assume you're familiar with creating custom connectoids with the Connection Manager Administration Kit (CMAK) wizard, because the whole process is beyond the scope of this chapter and this book. The process begins to differ at the Custom Actions screen (shown in Figure 7-1), so I'll begin this procedural outline there: 1. Navigate to the Custom Actions screen, and fill in subsequent screens as appropriate.

SearchSecurity.com Copyright TechTarget 2006

81

Figure 7-1. The Custom Actions screen of the CMAK wizard 2. Select Post-Connect from the Action type drop-down list, and then click the New button to add an action. 3. The New Custom Action dialog box is displayed, as shown in Figure 7-2. 4. Type a descriptive title for the postconnection action in the Description box. In Program to Run, enter the name of your baseline script. You can also use the Browse button to look for it. Type the command-line switches and their arguments in the Parameters box. Finally, check the two bottom boxes, Include the Custom Action Program with This Service Profile and Program Interacts with the User. 5. Click OK, and you should return to the Custom Actions screen. Click Next. 6. Continue filling in the wizard screens as appropriate, until you come to the Additional Files screen, as depicted in Figure 7-3.

SearchSecurity.com Copyright TechTarget 2006

82

Figure 7-2. The New Custom Action dialog box

Figure 7-3. The CMAK wizard Additional Files screen 7. Click Add, and then enter RQC.EXE in the dialog box. You can use the Browse button to search for it graphically. Once you're finished, click OK. 8. You'll be returned to the Additional Files screen, where you'll see RQC.EXE listed. Click Next. 9. Complete the remainder of the wizard as appropriate. Distributing the profile to remote users The profile you created earlier is made into an executable file that can be distributed to your remote users and run on their systems automatically. This creates a profile without any intervention after that. There are several options for actually getting that executable file to your users. SearchSecurity.com Copyright TechTarget 2006

83

You could transmit the executable file as an attachment to an email message, or better yet, make a link to the executable file hosted on a Web server somewhere. In the email message, you could include instructions to run the file and use those new connectoids for all future remote access. You could also have the executable run as part of a logon or logoff script, but to do that, you'd need to either have your users log on through a dial-up connection, or wait until the mobile users returned to the home network and connected at the corporate campus to the network. Regardless of which method you choose, if you want to initially transmit the profile installer to your users, then you should always place the latest version of the profile installer on a quarantined resource somewhere, so that client computers that don't pass your baseline script's compliancy checks can surf to a Web site and download the latest version without compromising the integrity of your network further. Configuring the quarantine policy The final step in this process is to configure the actual quarantine policy within RRAS. In this section, I'll create a quarantine policy within RRAS that assumes you've posted the profile installer on a Web server that is functioning as a quarantined resource. NOTE If RRAS is configured to use the Windows authentication provider, then RRAS uses Active Directory or an NT 4 domain (remember, the RRAS machine needs only to be running Server 2003; it doesn't need to belong to an Active Directory-based domain) to authenticate users and look at their account properties. If RRAS is configured to use RADIUS, then the RADIUS server must be a Server 2003 machine running Internet Authentication Service (IAS). Incidentally, IAS also uses Active Directory, which is an NT domain to authenticate users and look at their account properties. 1. Open the RRAS Manager. 2. In the left pane, right-click Remote Access Policies, and then select New Remote Access Policy from the context menu. Click Next through the introductory pages. 3. The Policy Configuration Method page appears. Enter Quarantined VPN remote access connections for the name of this policy, as shown in Figure 7-4. Click Next when you've finished.

SearchSecurity.com Copyright TechTarget 2006

84

Figure 7-4. The Policy Configuration Method screen 4. The Access Method screen appears. Select VPN, and then click Next. 5. On the User or Group Access screen, select Group, and then click Add. 6. Type in the group names that should be allowed to VPN into your network. If all domain users have this ability, enter Everyone or Authenticated Users. I'll assume there's a group called VPNUsers on this domain that should have access to VPN capabilities. Click OK. 7. You'll be returned to the User or Group Access page, and you'll see the group name you added appear in the list box, as shown in Figure 7-5. Click Next if it looks accurate.

Figure 7-5. The User or Group Access screen SearchSecurity.com Copyright TechTarget 2006

85

8. The Authentication Methods screen appears. To keep this example simple, use the MSCHAP v2 authentication protocol, which is selected by default. Click Next. 9. On the Policy Encryption Level screen, make sure the Strongest Encryption setting is the only option checked, as shown in Figure 7-6. Then click Next.

Figure 7-6. The Policy Encryption Level screen 10. Finish out the wizard by clicking Finish. 11. Back in RRAS Manager, right-click the new Quarantined VPN remote-access connections policy, and select Properties from the context menu. 12. Navigate to the Advanced tab, and click Add to include another attribute in the list. 13. The Add Attribute dialog box is displayed, as depicted in Figure 7-7.

Figure 7-7: The Add Attribute dialog box SearchSecurity.com Copyright TechTarget 2006

86

14. Click MS-Quarantine-Session-Timeout, and then click Add. 15. In the Attribute Information dialog box, type the quarantine session time in the Attribute Value field. Use a sample value of 60, which will be measured in seconds, for this demonstration. Click OK, and then OK again to return to the Advanced tab. 16. Click Add. In the Attribute list, click MS-Quarantine-IPFilter, and then click Add again. You'll see the IP Filter Attribute Information screen, as shown in Figure 7-8.

Figure 7-8. The IP Filter Attribute Information dialog box 17. Click the Input Filters button, which displays the Inbound Filters dialog box. 18. Click New to add the first filter. The Add IP Filter dialog box is displayed. In the Protocol field, select TCP. In the Destination port field, enter 7250. Click OK. 19. Now, go back to the Inbound Filters screen, and select the Permit Only the Packets Listed Below option. Your screen should look like Figure 7-9.

Figure 7-9. The completed Inbound Filters screen SearchSecurity.com Copyright TechTarget 2006

87

20. Click New and add the input filter for DHCP traffic, and repeat the previous steps. Make sure to include the appropriate port number and type as described earlier in this chapter. 21. Click New and add the input filter for DNS traffic, and repeat the previous steps. Make sure to include the appropriate port number and type as described earlier in this chapter. 22. Click New and add the input filter for WINS traffic, and repeat the previous steps. Make sure to include the appropriate port number and type as described earlier in this chapter. 23. Click New and add an input filter for a quarantine resource, such as a Web server, where your profile installer is located. Specify the appropriate IP address for the resource in the Destination Network part of the Add IP Filter screen, as shown in Figure 7-10.

Figure 7-10. The Add IP Filter box, where you add a quarantined Web resource 24. Finally, click OK on the Inbound Filters dialog box to save the filter list. 25. On the Edit Dial-in Profile dialog box, click OK to save the changes to the profile settings. 26. Then, to save the changes to the policy, click OK once more. Creating exceptions to the rule Although it's certainly advantageous to have all users connected through a quarantined session until you can verify their configurations, you may find some logistical or political problems within your organization that mitigate this requirement. If so, the simplest way to excuse a user or group of users from participating in the quarantine is to create an exception security group with Active Directory. The members of this group should be the ones that need not participate in the quarantining procedure. Using that group, you should create another policy that applies to the exceptions group, which is configured with the same settings as the quarantine remote-access policy you SearchSecurity.com Copyright TechTarget 2006

88

created earlier in the chapter. This time, though, don't add or configure either the MSQuarantine-IPFilter or the MS-Quarantine- Session-Timeout attributes. Once you've created the policy, move the policy that applies to the exceptions group so that it's evaluated before the policy that quarantines everyone else. Checklist: Hardening Windows School: Advanced checklist on network access quarantining 14 Jun 2005 | Jonathan Hassell | SearchWindowsSecurity.com One of the easiest and arguably most prevalent ways for nefarious software or Internet users to creep into your network is not through firewall holes or brute-force attacks -- nor is it any means that might occur at your campus or corporate headquarters. It's through mobile users trying to connect to your business network while on the road. Consider why that is the case: Most remote users are authenticated only on the basis of their identities, and no effort is made to verify that their hardware and software meets certain baseline requirements. It is not uncommon for remote users to fail any or all of the following guidelines: • • • •

The latest service pack and security hotfixes must be installed; The company-standard antivirus software must be installed and running with the latest signature files; Internet or network routing must be disabled; Windows XP Internet Connection Firewall (ICF) (now named Windows Firewall) or any other approved firewall must be installed, enabled and actively protecting ports on the computer.

You would expect business desktops to follow policy, but mobile users have traditionally been forgotten or grudgingly accepted as exceptions to the rule. Therefore, they become an active port for malware to enter and infect your network. That's why I'm going to explain why you need to use a security feature introduced in Windows Server 2003, Network Access Quarantine Control (NAQC), which gives you a chance to vet computers trying to access your network remotely, effectively closing ports. Sound like a decent idea? Browse through the checklist below to learn more about quarantining. Hardening Windows School Checklist: Know your network access quarantine options Understand how Network Access Quarantine Control (NAQC) works Here's basically how NAQC works: Under NAQC, when a client establishes a connection to a remote network's endpoint -- a machine running the Routing and Remote Access Service (RRAS) -- the destination Dynamic Host Configuration Protocol (DHCP) server gives the remote, connecting computer an IP address, but an SearchSecurity.com Copyright TechTarget 2006

89

Internet Authentication Service (IAS) server establishes a "quarantine mode." In quarantine mode, a set of packet filters restricts the traffic sent to and received from a remote access client, and a session timer limits the duration of a remote client's connection in quarantine mode before being terminated. Once the remote computer is in quarantine mode, the client computer automatically executes the baseline script. Windows runs the script and, if satisfied with the result, contacts the listening service running on the Windows Server 2003 back-end machine to report it. Quarantine mode is then removed and normal network access is restored. If Windows is not satisfied with the result, the client is eventually disconnected when the session timer reaches the configured limit as described above. Decide on your preferred criteria for allowing regular access to your network What would you like to check when remote users try to connect? Here are some ideas: • The latest approved operating system service packs installed • Antivirus software installed, working and updated with the latest signature files • Firewall protections enabled • Internet routing disabled Begin planning your resource areas for users in quarantine mode Under NAQC, you can establish a limited set of resources within the quarantine area where users can download information and software to help them rectify any issues that prevent them from accessing the unrestricted network. Consider posting a Web page explaining the quarantine process. Include information on how to get help from the help desk. You might also include a link to the latest service pack, a copy of your corporate antivirus software and individual links to hotfixes that you require. Give your users the power to self-correct their problems while still enhancing security on your network. Explore the Routing and Remote Access Service (RRAS) policy functionality A great guide to RRAS can be found at ServerWatch.com, and Chapter 11 of my book Learning Windows Server 2003 explains how to set up RRAS, and teaches you how to use policies and quarantining. About the Author: Jonathan Hassell is an author, consultant and speaker residing in Charlotte, North Carolina. Jonathan's books include RADIUS and Learning Windows Server 2003 for O'Reilly Media and Hardening Windows for Apress. His work is seen regularly in popular periodicals such as Windows IT Pro magazine, SecurityFocus, PC Pro and Microsoft TechNet magazine. He speaks around the world on topics including networking, security and Windows administration.

SearchSecurity.com Copyright TechTarget 2006

90

Checklist: Harden access control settings 12 Jul 2005 | Roberta Bragg | SearchWindowsSecurity.com Whether you're protecting sensitive data from malicious outsiders or preventing internal users from accessing systems not assigned to them, you have your work cut out for you when it comes to access control. This collection of checklists written by Roberta Bragg will help you along your way. She details specific steps to take in locking down default Windows access control settings and offers access control best practices. Checklist 1: Three security mandates for any Windows environment Disable or rename the Administrator account It's important to prevent or restrict access to the local Administrator account. Attackers are well aware of it and its all-powerful presence on the computer. Malicious software is often written to use this account. While the attacker would still have to know or deduce the account's password to use it, he won't have the chance to try if the account is disabled. Security Option: Use "Accounts: Administrator account status" to disable the Administrator account on Windows XP and Windows Server 2003 computers. On Windows 2000 computers this option is not available. Instead you can thwart attacks by renaming the Administrator account. If an attack involves the use of an account named "Administrator" and no such account exists, then the attack will not work. Security Option: Use "Accounts: Rename Administrator Account" to rename this account in Windows 2000. However, please keep in mind that internally Windows computers use a unique security ID (SID) -- not a name. If the attacker knows the Administrator account SID, simply renaming the account does nothing. This SID is composed of a unique number and a standard relative ID (RID). An attacker or wellcrafted malicious program can easily determine the Administrator account SID, unless you change that as well. (A future checklist will tell you how to protect Windows from such attacks.) Even on computers where you can disable the Administrator account you should rename the account. Another account with administrative privileges can always be used to re-enable the Administrator account. So what are the problems with disabling or renaming the Administrator account? First, many people will complain that this is security through obscurity. An attacker might be able to deduce the account name or SID, so disabling or renaming the account is not a sure preventative. Second, some people are under the false impression that they must use the Administrator account to administer the computer. If it's disabled, they say, how can they administer the computer? Preventing the use of the Administrator account does not mean you or others can't have administrative rights on the computer. Each user requiring such access can have an account with SearchSecurity.com Copyright TechTarget 2006

91

membership in the Administrators group. Disabling and renaming the account does not prevent administrative access, it just makes it harder for would-be attackers to get in. Disable or rename the Guest account While the Guest account has few privileges, it is included in the Everyone group when permissions are being evaluated -- and the Everyone group can access many systems. The Guest should be disabled by default. You just have to make sure it stays that way or rename it. Disabling and renaming this account may only remove low access rights, but this is a step that can be done quickly and easily, and doing so will typically cause no problems. Security Option: Use "Accounts: Rename Guest Account" to rename the account. Hide logon names By default the last account used to logon is displayed on the logon screen after the user has logged off. This allows anyone in close proximity to the machine to read the name, giving him half of the information he needs to access the computer and perhaps the network. He still has to know or deduce the password, but his job is easier than if he had to obtain both the account name and its password. Security Option: Use the "Interactive: Do not display last user name" option to ensure the previously used logon name is removed from the logon screen. Once again, some people will say these measures are security by obscurity and offer little value. They'll ask who cares if someone knows Joe User's logon name. They'll also maintain that it's a nuisance for users to enter their account names each time they logon. Baloney! A few keystrokes are all it takes. Requiring users to enter their information each time also ensures that they know their account names. Remember that not every user has limited access. You really don't want others to know the logon account names for administrators or other highly privileged users. Hiding the logon name can help you guard that information. How to find and set the above Security Options On a workgroup server or desktop (computers that are not joined in a domain) 1. Start/Administrative Tools/Local Security Policy 2. Navigate to Local Policies/Security Options 3. Scroll down to the appropriate setting. 4. Make the recommended change. In a domain environment The first step in making any change to Group Policy in a domain environment is to ensure that the change does not violate official organization security policy. Make sure you clear changes appropriately. In a domain environment, Group Policy management should be assigned to a limited number of administrators. Technical controls should also be in place to enforce this. Use the following steps to stay in compliance: SearchSecurity.com Copyright TechTarget 2006

92

1. Create or open the Group Policy Object that will apply to computers you want to manage. 2. Navigate to Windows Settings/Security Settings/Local Policies/Security Options. 3. Scroll to the appropriate setting. 4. Make the recommended change. Checklist 2: Block anonymous access To deduce the SID of the Administrator account, the attacker obtains the account list, translates the account into a SID, retrieves the computer part of the SID, adds the known Administrator account portion and then uses the deduced SID in a logon attack or to figure out the new name of the Administrator account. To foil this process, use the security options below, which block anonymous access and other types of attacks that use anonymous access. Disable the option "Network Access: Allow anonymous SID/name translation." This option, once disabled, prevents anonymous SID/name translation. Combine this option with the one below to keep an attacker from using an anonymous connection to deduce account names. Enable the option "Network Access: Do not allow anonymous enumeration of SAM accounts." When enabled, this option prevents the enumeration of the user account list via an anonymous connection. When both this and the above security options are used, you can keep the changed name of the Administrator account hidden from an attacker using an anonymous connection. Enable the option "Network Access: Do not allow anonymous enumeration of SAM accounts/shares." When enabled, this option also prevents anonymous enumeration of shares. Shares offer opportunities for system connections and data theft. If shares are properly protected by permissions, then anonymous access won't matter. If share permissions are not correct, or when they inadvertently offer access to an anonymous connection, you need to block anonymous connection to stop data theft. This option comes in handy on systems like Windows 2000, which include the anonymous SID in the Everyone group, where the group is given access permissions. Disable the option "Network Access: Let Everyone permissions apply to anonymous users." On Windows XP and Windows Server 2003 systems, anonymous users are excluded from the Everyone group and cannot gain access to resources given to that group. Keep this option disabled to prevent access. Enter the names of named pipes if necessary in option "Network Access: Named Pipes that can be accessed anonymously." SearchSecurity.com Copyright TechTarget 2006

93

Named pipes are another way network connections can be made by client/server programs. In this scenario, one part of a program runs on one computer and another part on another computer. Some legacy programs require anonymous access over these named pipes. If anonymous access is blocked, use this option to allow it where required. Enter the name of shares if necessary in the option "Network Access: Shares that can be accessed anonymously." Here again, some legacy applications may require anonymous access to shares. Instead of allowing anonymous access to all shares, enter the names of shares that require anonymous access. Checklist 3: How to properly set account lockout options It seems some true and tested security recommendations are backfiring. Specifically, let's take for example the usual advice to set account lockout options in a Windows domain. If you do set account lockout and someone tries to logon to an account using the wrong password, the account will automatically lock after the specified number of tries -- and no one can logon using it. Setting this option is supposed to provide two advantages: 1. A would-be attacker can't use the account unless he's capable of guessing the password within the number of tries you set. 2. If you have enabled auditing, configured it to record these events and reviewed your logs, you may discover these attempts at compromise. On the other hand, setting this option may also bring two disadvantages: 1. Legitimate users may fumble-finger attempts at logon and lock themselves out. Does this seem far-fetched? I once did so in front of an audience of 500 people. 2. Automated attacks on accounts can trigger whole-scale lockout of multiple accounts. The password cracking attempt becomes a denial-of-service attack (and some say that may have been the goal). Still, I believe that properly-implemented account lockout options can work to your advantage. Account lockout settings should be set in a Group Policy Object linked to the domain. You'll find them at Windows Settings/Security Settings/Account Policies/Account Lockout Policy. Here's how to use them. Set account lockout threshold to 25 invalid logon attempts After 25 tries the account will be locked out. (Even I don't think I'd enter an incorrect password 25 times!) This should keep the authorized user from locking themselves out just because they are having a brain hiccup. It does give the attacker a little more time to get the password, but unless the password is simple, 25 tries is hardly enough to compromise the account. SearchSecurity.com Copyright TechTarget 2006

94

Set account lockout duration to 30 minutes For Windows Server 2003, this is the default if the threshold is set. The account lockout duration is the length of time that the account will remain locked out before it is reset. It's a good idea to set this feature. The alternative is to require administrators to reset accounts, a time-consuming venture in a large environment -- a real showstopper should you get massive account lockout due to an automated attack. Yes, you will increase the risk that an attack can succeed. All the attacker has to do is wait out the lockout time and try again. On second thought, make your account lockout duration something other than 30 minutes. Let's foil the would-be attacker reading this document. Set the "reset account lockout counter after ..." option to 30 minutes Windows keeps track of the number of bad password attempts in a lockout counter. This setting returns that total to zero after the number of minutes you prescribe. By providing a time here, the counter won't continue to increase if the time limit is reached. That can also keep the help desk calls down. It also allows an attacker to program around your defense. All she has to do is fly in under your radar (so to speak), sending, for example, 24 tries in 30 minutes, then none for a couple of minutes, then continue the cycle until she succeeds. But she'd have to know your settings, and if you're doing a good job of reviewing your audit logs, you should notice this pattern pretty quickly. Set auditing for logon events and monitor logs Account lockout locks out accounts. That should let you know that something is amiss. However, if you aren't auditing logon events, you're missing many other more subtle attempts at compromise. It may be the only way to nip such an attack in the bud or prevent it from occurring again by helping you discover the source of the attack. Protect accounts from automated attacks originating from the Internet Where would such attacks come from? Intuition says from the Internet. You shouldn't be able to logon from the Internet without some remote-access service such as a VPN. Unless an attacker can establish such an authenticated, authorized connection, he can't run an automated attack from the Internet. Block NetBIOS ports from Internet access and require the use of VPNs, SSL or other secure remote-access processes. Protect accounts from automated attacks originating from external users Protect accounts from automated attacks originating from partners, customers and others whom you may allow access to your networks. Isolate resources you make available to these users. They shouldn't have free access to your entire network. Protect accounts from insider attacks This is the really rough one. Your legitimate users have to be able to authenticate to the domain. How can you protect yourselves from their abuse of this privilege? Every SearchSecurity.com Copyright TechTarget 2006

95

practice that you adopt that limits users' ability to install and run unauthorized software helps you to mitigate this risk. Checklist 4: Restrict access to prevent insider hacks Insiders are often to blame for more computer compromises than outsiders. That means your employees and fellow workers create more havoc for your network than all the malicious people on the Internet. Limit your losses by preventing users from accessing sensitive systems and logging on to machines other than those assigned to them. WARNING: You can seriously hamper user ability to log on by setting the wrong user rights. Please do the following steps in a test environment. Step 1: Keep users out of systems that don't concern them. You'll want to set file permissions, but before you do, quarantine users so they can only access and log on to a limited number of computers. To do so, open their account property pages in Active Directory Users and Computers, select Account tab and click the Log On To button. Next click "The following computer" button, enter the name of a computer the user is allowed to access and click the Add button. If users must have access to multiple desktop computers and laptops, simply add those computer names. This works well when multiple people need to use any one of several computers in a lab or department. If you want to keep an account from logging on at any computer, just enter the name of a non-existent computer. Setting log-on-to computers does not restrict users from accessing data on other computers across the network. To limit network access, configure user rights. User rights specify what a user can do on a computer. Set them in the default domain controller Group Policy Object (GPO) to limit access on domain controllers, and in GPOs linked to organizational units when you want to impact a subsection of computers joined in the domain. User rights are located in the GPO under Windows Settings --> Security Settings --> Local Policy --> User Rights Assignment. Step 2: Restrict rights that directly impact computer access. User rights configuration is similar to file permission settings; if the right is not granted, the user does not have it. The following rights directly impact access to computers and should be limited. • Access this computer from the network This right only allows identified user groups access to the computer. By default, the Everyone group has this right, and may not want that. To restrict this right, add groups that should have the right to access the computer, and then remove the Everyone group. Be careful not to lock out service accounts. • Deny access to this computer from the network Remember, by default, if a user does not have the right to access the computer, he is denied access implicitly. Use this right sparingly to define SearchSecurity.com Copyright TechTarget 2006

96

those accounts that should never, under any circumstances, access the computer from the network. By default, Windows Server 2003 locks out the support_388945a0 account. You could use this right to prevent the local administrator account from being used on the network. Step 3: Harden log on and deny logon rights. Be careful handling log on and deny logon rights. Each right has an associated counterpart -- a deny user right. Use deny rights sparingly, usually only to manage those accounts that should never have the right. Follow the table below for recommendations. User right

Meaning

Recommendation

If a user has this Allow log right, he can sit at on locally the console and log on.

Restrict access to all servers by adding groups that represent those authorized to configure or manage the server. Then remove the users group. Be cautious here. If the machine is a terminal server, locking up local log on is not the choice to make. The SUPPORT_388945a0 account is denied this right.

Allow log If this machine is a on through Restrict terminal services to those users who are terminal server, terminal actually authorized to use the servers. users need this right. services Batch jobs are jobs that run in the Log on as a background. They batch job are often scheduled with the task scheduler.

Limit this right only to accounts that might be used to run these types of jobs -- and then only if the accounts need it. Accounts used for SUPPORT_388945a0, local service and Internet Information Services-related (IUSR, IWAM and IIS) WPG (Microsoft Word for Windows vector graphics) are given this right. Don't remove these groups unless the tasks they perform are no longer necessary on these computers.

Log on as a Services also run in service the background.

Limit this right to services that may need it (by default the network service account is given this right). Ordinary users do not need it.

Checklist 5: Set account options to limit systems access Password policies aren't the only way to control access to your Windows systems. An account that grants access to your computer systems is a privilege not a right. Not everyone should have an account, nor should employees with accounts have unrestricted access to your systems. You don't make everyone an administrator, right? So why not restrict access using all the tools at your disposal? I don't mean you should invest in chains, whips or restrictive leather gear -- just use native Windows tools like account options to limit system access, as you'll learn in the checklist below. Following the SearchSecurity.com Copyright TechTarget 2006

97

checklist, you'll find steps for actually locating and changing account options in Active Directory. Set logon hours This is the span of time users are authorized to logon. Restricting logon to normal work hours prevents users, or anyone who learns their account and password information, from accessing your network at off hours when few people are around to discover the unauthorized access. Setting logon hours can also hamper unauthorized use of remote access during those hours. Set log-on-to machines Being able to logon from any computer in the domain is a nice convenience, but it's a bit too risqué for me. Selecting specific computers to use for logon may help prevent unauthorized actions that could result in data theft or damage. It is especially important to limit guests, temporary workers, students and contractors. Set "Smart card is required for interactive logon" where smart cards are used If you don't require smart cards for interactive logon, users may forgo their smart card and use a password instead. You don't want this to happen. Smart card technology helps you escape the many weaknesses of password use. If users can choose whether or not to use their smart cards, you've lost that advantage. Also, users won't have to report a lost smart card in order to get a new one; if the wrong person finds an envelope with a smart card inside and the PIN number written on it -- game over. As a general rule, users should never store PIN numbers with their smart cards, but there is no way to guarantee they won't. If a user reports a missing smart card and must receive a new one to logon, revoke the certificate assigned to the smart card to prevent the use of the lost card. Set "Account is sensitive and cannot be delegated," at least for administrator accounts Account delegation is a useful tool for multi-tiered applications. It enables you to delegate authority for access, and gain tighter control and accountability of that access. However, delegating administrator accounts is not a good idea. Prevent that from happening by checking the "Account is sensitive and cannot be delegated" box. Set an account expiration date Many of you hire part-time help, contractors and other temporary workers. When they (or any regular employees) leave their jobs, are you immediately made aware of the change so you can disable and eventually delete their accounts? Leaving excess accounts enabled on your systems is not a good security move. The compromise and use of these accounts might go unnoticed for a very long time. If all accounts have expiration dates set, temporary workers will need to have it extended in order to work past their length of service. If they leave early, at least the account will be expired. If setting account expiration dates for all employees is difficult to manage, at least set expiration dates for temporary workers. SearchSecurity.com Copyright TechTarget 2006

98

How to locate and change account options in an Active Directory domain Open Active Directory Users and Computers, navigate to the container where user accounts are stored (either the Users container or possibly several organizational units depending on your Active Directory design) and double click on the user account. To make changes, click on the check boxes or manipulate other controls. User details on a standalone Windows 2000, Windows XP or Windows Server 2003 computer can be found in the Computer Management\Local Users and Groups\Users container. However, many of the account details described above are not accessible there. To use those that make sense, you'll have to use the Net User command. Net User is also helpful in a domain. Use it to change account options for multiple accounts at one time. Alternatively write a script. Information on doing both can be found at Microsoft's support site and Microsoft TechNet. Checklist 6: Tighten default settings to prevent unauthorized access Many people say information security is a journey: No action you take to secure Windows will make much difference if you don't keep doing more and stay one-step ahead of your nemesis. Even if you spend lots of money, hire the best people, know security backward and forward, implement Fort-Knox-like physical security and antilogic bomb bunker technologies, you're still going to lose. Someone will be one step ahead of you. Hogfeathers! This kind of attitude will leave you open to attack. Sure as letting a bull loose in a glass shop, it will result in damaged goods -- your network and your computers will be penetrated. Instead of bemoaning what you don't know, what you can't do and what the enemy knows, get a grip and start hardening systems. Truth be told, doing so, like eating good food and not standing on a hill during a lightening storm, can protect you from an extraordinary percentage of common attacks. You have to modify Windows system defaults. Defaults are established to help the most people get the most use out of their systems. You should address this issue from the standpoint of what you want your users to be able to do with their systems. If you reduce their possibilities, you also reduce risk. Start by disabling unnecessary network connections. These network connections are enabled by default. The key word here is not 'disable' -- it's 'unnecessary.' You may need these connections on some systems but you should have a security policy that defines how and when to use these connections and how they may be secured. Meanwhile, take the attitude that all things should be locked down, and loosened only after need versus risk has been evaluated. Disable 802.11 wireless network connections SearchSecurity.com Copyright TechTarget 2006

99

If enabled, 802.11 wireless cards can serve as connection points for attackers even if users don't know that they have wireless capabilities. Even administrators and trained technical users may indivertibly expose their systems to risk by leaving wireless unprotected. If secure wireless networks are implemented and security practices extend to the workstation, then and only then should you enable them. Before disabling, open the 802.11 network connection property page and use the advanced tab to firewall the connection. This protects the connection when it is enabled. Disable Bluetooth connections Bluetooth connections are used for short-range wireless synch or to communicate with a range of wireless devices, such as phones and printers. However, many systems do not need this capability, and your security policy may deny it to others. If you have to rely on Bluetooth, you're taking a risk, which each organization must weigh for itself. But by all means, turn off Bluetooth unless you know you absolutely need it for wireless devices to work. Disable infrared connections Infrared technologies allow wireless connectivity primarily for synching with handheld systems, but they may also be used for printing or file transfer. When another infrared system is in range, and its owner wants to transfer a file to your system, a popup asks you if you want the file. It will not distinguish between malware or important files -- that's your job. Files are stored using your privileges. Unchecking the Allow others to send files to your computer using infrared communications box in the Wireless Link Control Panel applet prevents accidental transfer. Disable FireWire FireWire -- a fast, short-range network connection often used for connecting audio and video devices -- may be used to network computers together and can be bridged with an Ethernet connection that enables a system with only Firewire access to access your network. Firewire is configured using the 1394 network connection viewable in Network Connections. It is enabled by default. Firewall the connection, and then disable this device. About the Author: Roberta Bragg is author of Hardening Windows Systems and a SearchWindowsSecurity.com resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker.

SearchSecurity.com Copyright TechTarget 2006

100

Security risks associated with granting permissions in Windows XP I am in the process of a desktop lockdown review for a Windows XP deployment. We need to define the security risks associated with granting permissions to select directories and registry settings for the average user (member of local users). These permissions are required to allow applications to function. I have found white papers from Microsoft and CIS that recommend certain permissions, but none explain the impact of not granting those permissions. QUESTION POSED ON: 05 August 2003 QUESTION ANSWERED BY: Roberta Bragg | SearchWindowsSecurity.com The reason for granting permissions on registry keys and so forth is to allow custom groups the ability to run applications. The reason permissions are necessary is that some applications insist on making changes or opening files and keys as if to make changes -permission usually granted only to administrators. Therefore, many companies have found that they need to make users members of administrative groups just so they can run certain applications. There is far less risk granting selected users permission on selected keys, files, etc., than there is in giving them administrative privileges, and therefore access to many more keys and files, as well as elevated privileges. On the other hand, if you are not using applications that require this level of access, then you should not be granting permissions. You may want to review the situation by using test groups, then try granting and not granting permissions while running applications to determine if there are some you can eliminate. The free utilities regmon and filemon available from Sysinternals can help you determine exactly which items are being accessed. About the Author: Roberta Bragg is author of Hardening Windows Systems and a SearchWindowsSecurity.com resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker. How to deny access when connecting to a share on a Windows 2003 Server I have a Windows XP Professional workstation that is trying to connect to a share on a Windows 2003 Server in a workgroup environment. When I try to connect to the share on the server, I get an access denied message. I checked sharing and security permissions for this user, and they are set to full control. Is there anything else I can check to give this user access? QUESTION POSED ON: 19 July 2004 QUESTION ANSWERED BY: Roberta Bragg | SearchWindowsSecurity.com Share permissions can be complicated. It sounds like you have checked the first obvious thing. Both the permissions on the share and the security permissions on the folder must be considered before access is granted. The next issue is the user ID. In a Windows workgroup, you must be either using the same user ID and password on both machines, or when configuring the share, do so as another user by entering a password and user ID in the "Connect using a different user name." Here is a list of things to check: SearchSecurity.com Copyright TechTarget 2006

101

1. Share permissions. 2. Security permissions on the folder that is shared (and permission on any files and subfolders you want to access). 3. Are you using an account and password for the server? 4. Check the local security policy of the server -- user rights. Make sure the user name you are using has the right to connect to the server remotely and is not denied the right to logon to this machine. 5. Check the local security policy of the server -- security options. Accounts limit local account use of blank passwords to console. (Don't change this. If you do, make all accounts use passwords) 6. Check to see if any changes have been made to security policy. 7. Make sure the local user account on the server is enabled, and not locked out. About the Author: Roberta Bragg is author of Hardening Windows Systems and a SearchWindowsSecurity.com resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker. How to detect when non-domain laptops are plugged in to Windows Server 2003 We are trying to stop users from plugging in laptops that are not part of the domain for security reasons. Every once in a while we see a crazy workgroup name on the network. My question: Is there any way I can set up some type of alert so when this does happen I will be notified? Thanks. QUESTION POSED ON: 13 September 2004 QUESTION ANSWERED BY: Roberta Bragg | SearchWindowsSecurity.com Some network management products may have this facility. There are also some new technologies that might help. They are based on either requiring every computer to be scanned and pass a security review before being able to connect to the network or requiring a set of access control lists on switches and other network devices. Or they are based on preventing unauthenticated computers from accessing network resources. In the first case, the security review can look for things like computer identity and refuse access to those not authorized. This is similar to the Network Quarantine control process available with Microsoft Windows Server 2003, but for the LAN. The user might plug the computer into a jack, but cannot access anything since the computer cannot pass the security test. This is a new technology that Microsoft is working on. Cisco has a product Secure Access Control Server for Windows that can configure access control lists on firewalls, routers, switches and so on to control access.

SearchSecurity.com Copyright TechTarget 2006

102

In the second case, IPSec policies are used on domain resource computers and require any computer to have its own certificate and authenticate before accessing resources. The user may be able to plug his computer into the network, but any attempt at accessing a network resource will be "access denied" since the computer cannot pass the security test. Desktop systems owned by your company will need appropriate certificates provided, as will servers. Microsoft has a document on how they implemented this solution which is called Domain isolation. About the Author: Roberta Bragg is author of Hardening Windows Systems and a SearchWindowsSecurity.com resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker. How to set up dual administrative controls for tighter security in Windows 2000 I work in a large corporation as a liaison between finance and IT. We have Active Directory in place worldwide. Corporate documentation on AD consists of mountains of intranet documents on the rollout and objectives, but they never talk about anything other than monitoring performance, replication and otherwise making sure it works from an IT perspective. What I want is a little finance/business-relevant functionality. We have an application used to conduct very sensitive transactions. It can be set up to use Windows authentication to grant access, assuming that users have been made members of the appropriate global groups that have access to the network/database resources (group membership is controlled exclusively by a group manager within finance in this case). Using the features of Windows authentication is good because it reduces finance's need to know IT and maintain an IT infrastructure. Instead, we can piggyback on IT's engineered solution rather than having to support our own, for which we don't have either the expertise or the budget. But there is one critical issue for us following our corporate security standards implemented through AD -- a single helpline person has the authority to reset passwords for user IDs. In the worst case, a malicious, knowledgeable helpline person could reset a user's password and then enter our sensitive finance system, posing as an authorized user. Finance can't tolerate a single administrative authority outside our organization with the ability to control access to our system in this manner (our back door). On the other hand, finance is at risk if that authority resides completely within finance, too, because that person would probably possess much more knowledge about our sensitive system and how to violate it. What we want is dual administrative activities to take place when a user requests their password to be reset -- allow the helpline to reset the user password as per our corporate standard, but require a second, unrelated person to confirm the validity of the action from within finance for users of this particular system. The question is how. If somehow, a network agent were able to monitor members of the global SearchSecurity.com Copyright TechTarget 2006

103

group that grants access to our application and then, if a password change was made to any member, they'd be automatically removed from the global group, which only finance can administer (i.e., add them back to the group), that would be ideal. In that case, a password reset by the helpline would also require finance to restore membership to the group with access to the application (dual administrative control when a password reset takes place). Is there any way that AD could be configured such that a password reset could trigger removal from certain sensitive network groups that the AD administrator would NOT have control over? This would allow for dual administration and less risk of an internal hacker accessing sensitive network resources. Is there another way that dual administration could be implemented when resetting a user's password? Would group policies help? Should we monitor event logs and send alerts that would run VB scripts to remove the member? QUESTION POSED ON: 05 June 2003 QUESTION ANSWERED BY: Roberta Bragg | SearchWindowsSecurity.com Yes, the administrator could reset the user's password. I know of no way to take out-ofthe-box AD and make it remove this privilege for the administrator. (There may be some deep and dirty AD config in the ACLS, however, but an admin could change them back.) However, if the administrator does not know the user's password, and uses the reset function, he cannot reset the password back to what the user used. So the user, when she tries to log on next, will not be able to, and will have to contact the help desk to have her password reset. This activity, of course, should be investigated. Yes, users do forget their passwords; but, couple this with a strong audit policy in the event log, and event 627 "A user's password was changed" will be recorded. You can match these with user requests. In addition, you can set up EFS so that an administrator would have to access the files from the user's workstation in order to decrypt them. When the reset password privilege is delegated to a help desk, even more interesting issues abound. We tend to hire and vet administrators and expect a little more of them, and pay them well. We believe they know the rules, and we watch these privileged persons a little more closely. Help desk personnel are often not paid well, have less education and turnover is rampant. Even if you solve all those issues for the help desk person in your case, you still should work on getting some monitoring (see the audit route above). And, yes, your solution might work. You could script removal from a group after password reset. You could also make that a requirement, write a password reset script that first removes the user from a group, then resets the password. The help desk uses this instead of Active Directory Users and Computers. I like the concept, too. It separates duties; that is, the help desk can reset a password if they remove a user from group. Finance can put a user in group. Neither can do both. There would have to be collaboration for a malicious act. SearchSecurity.com Copyright TechTarget 2006

104

Still, a rogue admin or a help desk person (if the privileges aren't worked out correctly) can access the normal password reset functionality in Active Directory Users and Computers. A number of things can go wrong. Ideally, if files are that sensitive and the risk cannot be tolerated, you need to adapt some other method of authentication like a smart card or biometrics. With Windows 2000, certificate services come free. You would have to purchase the cards and/or readers, but the software is there. You would have to securely implement them; and, no -- once done, you do not have to make every user use a smart card, you can just use it for the finance group and you can require that the smart card, not the password, is used. If a smart card is lost or damaged, a new one can be issued. This can be done in a way in which only the user sees the PIN. Even if the card is lost, it cannot be used without the PIN. After a small number of PIN "guesses," the card self-destructs. Let me know what you do, and how it works for you. Developing sound and secure business practices from mounds of technical information is not always easy. About the Author: Roberta Bragg is author of Hardening Windows Systems and a SearchWindowsSecurity.com resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker. How to remove specific permissions from an account operator in Windows 2000 How can I remove the permissions to delete a user account from the account operator in Windows 2000? QUESTION POSED ON: 02 April 2003 QUESTION ANSWERED BY: Roberta Bragg | SearchWindowsSecurity.com There are two ways to approach this problem. 1. To allow account operators to do everything to manage accounts except delete user accounts, you can deny account operators the "Delete all child objects" permission on the users container in Active Directory users and computers. If all user accounts do not reside in this container, you will have to make the same change to all user account containing organizational units (OUs). 2. The second option is to create a custom security group and only give it the permissions over user accounts that you desire. After creating the group, use the delegation of control wizard. When you are done, add members to this group that you wish. Delegation of administrative authority to security groups may be of help. About the Author: Roberta Bragg is author of Hardening Windows Systems and a SearchWindowsSecurity.com resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker. How to check which permissions are assigned to a user or group in Windows 2000 SearchSecurity.com 105 Copyright TechTarget 2006

I'm using Windows 2000 server and NTFS file system. There have been a lot of permission changes for certain folders and files, so I have lost control of where and which permissions have been changed. It's easy to open folder or file properties and find which permissions are applied to whom, but I would like to get another view; I would like to take a user or group and see where and which permissions on the file system level they have. How do I get that, because tons of files are stored on the server and I cannot check every file properties step-by-step. Thanks, Roberta. QUESTION POSED ON: 21 May 2003 QUESTION ANSWERED BY: Roberta Bragg | SearchWindowsSecurity.com Use the SomarSoft Utility DumpSec, a free utility; see also Hyena, a product by the folks that provide the free one. About the Author: Roberta Bragg is author of Hardening Windows Systems and a SearchWindowsSecurity.com resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker. How to set NTFS permissions on Windows 2000 Terminal Services What is the guideline for setting NTFS permissions on a Windows 2000 Server Terminal Services with Citrix MetaFrame 1.8? I have been told by Microsoft technical support NOT to mess with the group "Everyone," to leave permissions at default and create a new group and restrict NTFS permissions to that group. Does that sound correct? I have been told you cannot set the permissions like you could in NT 4.0 Terminal Server Edition. Is that correct? QUESTION POSED ON: 23 September 2002 QUESTION ANSWERED BY: Roberta Bragg | SearchWindowsSecurity.com There appears to be more than one issue here: 1. Since you say you were told to create a new group and restrict NTFS permissions to that group, I'm assuming you want to restrict access by setting deny permissions. If this is so, then yes, create the group and set "deny permissions" for it. You cannot deny access to the Everyone group; if you do so, you will do just that, deny access to everyone. Since deny access is usually applied first, no amount of "allow access" will override this. Instead, grant "allow access" to those who need access. Those without access will be denied by default. The "deny access" permissions help with more granular access restrictions, but Windows 2000, like NT, does not grant access to anyone implicitly. 2. What access do you wish to adjust? System access? Data file access? As you know, in some areas, the group Everyone is explicitly given access. In many cases you can remove this access, but you must make sure to replace it by giving the SearchSecurity.com 106 Copyright TechTarget 2006

SYSTEM and appropriate users access explicitly. You should always use caution when doing this, and do so on test systems. I am unable to find out if Citrix Metaframe also requires explicit access to areas, where it is getting that access because of default group "everyone." If this is so, then if you could determine where that is necessary, then you can make the appropriate adjustments. I suggest you work with your Citrix support to determine if this is possible. 3. Windows 2000 is different than Windows NT 4.0 Terminal Server edition, and that may be the cause of some problems. Permissions set on the system files are not the same. This could be the answer here. You cannot merely set permissions in Windows 2000, as you may have in Windows NT. 4. It's always easier to just leave the defaults. I know of no explicit reason why you cannot make some adjustments to file permissions, but there is no easy answer here. As always, you must determine what access is required before you blithely change access. Depending on where you wish to change permissions, you may need to know the access required by Windows, Citrix Metaframe and user accounts. About the Author: Roberta Bragg is author of Hardening Windows Systems and a SearchWindowsSecurity.com resident expert. She is an MCSE, CISSP and Microsoft MVP, and a well-known information systems security consultant, columnist and speaker. Limiting user and admin access 03.09.2006 | Wes Noonan | SearchWindowsSecurity.com Allowing granular access to the many objects on your Windows network to various users can present some problems. In this set of questions and answers, Windows network security expert Wes Noonan shares how to selectively limit object access from users and admins alike. Q: How can I prevent a domain user or computer from accessing all servers on the network? I only want them to be able to access one server. A: One effective method of doing this would be to add the user to a group that you create (for example Server A Users) and then remove them from the domain users group. Next, make the group that you created a member of the appropriate local groups on the server to grant them the level of access you desire. For example, if you want them to be just a regular user, you can add the global group to the local "Users" group. Q: How can I prevent certain users who are domain administrators from logging onto domain controllers? A: That depends on the kind of user they are. If they are a member of a group that grants them rights on domain controllers (for example, Domain Admins) there really isn't a way to do that. If your domain is small enough, you could specify the list of computers they SearchSecurity.com 107 Copyright TechTarget 2006

are allowed to login to, excluding the domain controllers, but I think this would rapidly become unmanageable (every time you add a computer, potentially you need to update the list of computers they can login to) as well as being rendered ineffective if the users in question are domain admins (they can always come in behind you and undo it). Now, assuming that this is not a domain admin, the ability to logon to a domain controller is defined in the Default Domain Controllers Group Policy. You can view this by right clicking on the Domain Controllers OU in Active Directory Users and Computers and selecting "Properties". Click on the "Group Policy" tab, select the policy and click "Edit". Navigate using the Group Policy Object Editor to the following branch: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment In the right hand window, look for either "Log on locally" or "Allow Logon Locally" (it differs depending on which version of Windows you are using). Double click on the policy and add/remove users from that list accordingly and check the box next to "Define these policy settings:" to define who will be allowed to logon locally. By default, the following accounts/groups can logon locally to domain controllers: 1. Account Operators 2. Administrators 3. Backup Operators 4. Print Operators 5. Server Operators 6. Corresponding Internet Users (IUSR_) As always, rather than directly editing the Default Domain Controllers Group Policy, you should create a new group policy object with the settings you want. Also, be advised that changing the default settings can cause unexpected and potentially damaging results to your systems. Q: If you have two domains on your network that are located at the same physical site and you want to implement an account policy that requires passwords of at least eight characters and should meet complexity requirements -- do you apply the account policy setting at the site? What account policies should you use? A: You would need to apply the account policy separately on each domain. Even though the group policy MMC snap-ins will display the "Password Policy" branch for OU's and sites, you can only define the password policy at the domain level. This is because there can only be a single password policy in a given Active Directory, which effectively means that you can only define it at the domain level. Also, just as a note regarding best practices, rather than modifying the default domain policy, you should go ahead and create an additional group policy object with the password policy settings that you want to apply. SearchSecurity.com Copyright TechTarget 2006

108

Q: I have an NTFS folder on Windows 2000 Advanced Server. I want to set rights to this folder so that users are not able delete files or folders, while at the same time they are able to save and make changes in that folder. How can I do this? A: This can be done by editing the advanced security properties of the folder and files. To do this, right click on the folder in question and select "Properties." Select the Security tab and click "Advanced." Add or edit the appropriate users and specify the following permissions: Traverse Folder/Execute Data List Folder/Read Data Read Attributes Read Extended Attributes Create Files/Write Data Create Folders/Append Data Write Attributes Write Extended Attributes Read Permissions Change Permissions You may or may not need all of the above permissions for your specific requirements. The key is to remember to NOT grant the "Delete Subfolders and Files" and "Delete" permissions. Keep in mind that you may need to remove inheritance to allow you to make the necessary changes. About the Author: Wesley J. Noonan has been working in the computer industry for over 12 years specializing in Windows-based networks and network infrastructure security design and implementation. Opinion: Network admins needs Microsoft-Cisco unity 30 Jul 2004 | Laura E. Hunter | SearchWindowsSecurity.com You were at the coming out party for Windows Server 2003 in April of 2003, admit it. But did you notice that neat little feature standing alone in the corner because nobody was asking her to dance? Her name was Network Access Quarantine Control, and as new features go, it was amazing how little attention she garnered. This little toy could look at your incoming remote access clients, check their patch levels, antivirus signatures and other pertinent security details, and then grant or deny access to your internal network based on the client's overall "fitness" level. This was huge, people! OK, so maybe it wasn't all that easy to deploy. All right, I admit it, it was a bear. But it was still a major leap forward in perimeter security for Microsoft products. SearchSecurity.com Copyright TechTarget 2006

109

The next major advance will arrive in the next release of 2003 -- R2 -- scheduled for release in mid-2005. Currently dubbed "Network Access Protection," this tool improves on NAQC in two significant ways: •

It creates simpler, GUI-based administration and implementation, rather than the extensive scripting needed for NAQC. In addition, Microsoft has promised interoperability with a number of third-party products, including antivirus and existing remote-access technologies.

•

It extends the functionality of the protection to all types of connections, both remote access and LAN-based. This part is key because the pervasiveness of "always-on" Internet connectivity, wireless hotspots and smaller Internet-capable devices like cell phones and PDAs has greatly blurred the distinction between what is a locally connected versus a remote-access client. In many ways, the idea of the network perimeter has ceased to be a physical entity like a border router, and has become a much more logical concept.

However, Microsoft's entry into this market seems likely to place it in competition with existing network perimeter security software, most notably Cisco's Network Access Control. Now, I'm a big bad capitalist, and am of the opinion that competition is good for any industry, especially the software business. Competition for customer dollars almost inevitably leads to better products for the money, as different vendors develop more desirable features to "get the contract." But when security is at stake, interoperability must trump the desire to turn a profit. At the risk of sounding utopian, the idea of a "greater good" needs to extend to the Internet and Internet-connected machines, since their security and well-being affect us all. At the moment, the Microsoft and Cisco perimeter security products are gearing up to not quite speak to one another. NAP is slated to use PEAP (Protected Extensible Access Protocol), whereas Cisco's NAC is only meant to run on Cisco equipment. Given the prominence of both vendors' products in the enterprise network, this could prove problematic. If the two offerings don't end up working and playing well together, network administrators who rely on both vendors' products will be forced to jury-rig a solution, either by building their own or using a product from a third-party vendor to create interoperability. I don't know about you, but I get nervous whenever I'm forced to use the word "jury-rig" in connection with network security. Granted, this may be putting the cart before the horse somewhat, since there isn't much in the way of clearly defined standards for secure network access. But a significant positive indicator for the future is Microsoft's support for 802.1x authentication, both in Windows Server 2003 and Longhorn. If current or future iterations of the Microsoft and Cisco perimeter security offerings can be built according to industry standards -- either 802.1x or some future model -- the security of all those who rely on Microsoft and Cisco technology will certainly benefit. SearchSecurity.com Copyright TechTarget 2006

110

Step-by-Step guide: Network Access Quarantine Control 5 Jan 2006 | Jonathan Hassell | SearchWindowsSecurity.com One of the easiest and arguably most prevalent ways for nefarious software or Internet users to creep onto your network is not through holes in your firewall, or brute-force password attacks, or anything else that might occur at your corporate headquarters or campus. It's through your mobile users, when they try to connect to your business network while on the road. You would expect your business desktops to follow policy, but in the past, mobile users have traditionally been forgotten or grudgingly accepted as exceptions to the rule. However, Windows Server 2003 includes a new feature in its Resource Kit, called Network Access Quarantine Control (NAQC), which allows you to prevent remote users from connecting to your network with machines that aren't up-todate and secure. NAQC provides a different sort of security and addresses a different, but equally important, sector of communications than VPN or IPSec. Step 1: Learn how it works NAQC prevents unhindered, free access to a network from a remote location until after the destination computer has verified that the remote computer's configuration meets certain requirements and standards, as outlined in a script. To use NAQC, your remote access clients must be running Windows 98 Second Edition, Windows Millennium Edition, Windows 2000, or Windows XP Home or Professional. These versions of Windows support a connectoid, which is simply a dial-up or VPN connection profile located in the Network Connections element in the user interface, containing three essential elements: •

Connection information, such as the remote server IP address, encryption requirements and so on.

•

The baselining script, which is a simple batch file or program used to assess the suitability of the client computer (more on this in a bit).

•

A notifier component, which talks to the destination network's backend machine and negotiates a lift of the client's quarantine.

These elements are united into one profile using the Connection Manager (CM) Administration Kit (CMAK) in Windows Server 2003. Additionally, you'll need at least one Windows Server 2003 machine on the back end running an approved listening component; for the purposes of this guide, I'll assume you're running the Remote Access Quarantine Agent service (called rqs.exe) from the Windows Server 2003 Resource Kit, because that is the only agent available at press time. Finally, you'll need a NAQCcompliant RADIUS server, such as the Internet Authentication Service in Windows Server 2003, so that network access can be restricted using specific RADIUS attributes assigned during the connection process. Here is a detailed outline of how the connection and quarantining process works, assuming you're using rqc.exe on the client end from the CMAK and rqs.exe on the back end from the Resource Kit: SearchSecurity.com Copyright TechTarget 2006

111

1. The remote user connects his computer, using the quarantine CM connectoid to the quarantine-enabled connection point, which is a machine running RRAS. 2. The remote user authenticates. 3. RRAS sends a RADIUS Access-Request message to the RADIUS server -- in this case, a Windows Server 2003 machine running IAS. 4. The IAS server verifies the remote user's credentials successfully and checks its remote access policies. The connection attempt matches the configured quarantine policy. 5. The connection is accepted, but with quarantine restrictions in place. The IAS server sends a RADIUS Access-Accept message, including the MS-QuarantineIPFilter and MS-Quarantine-Session-Timeout attributes, to RRAS. 6. The remote user completes the remote access connection with the RRAS server, which includes leasing an IP address and establishing other network settings. 7. RRAS configures the MS-Quarantine-IPFilter and MS-Quarantine-SessionTimeout settings for the connection, now in quarantine mode. At this point, the remote user can only send traffic that matches the quarantine filters -- all other traffic is filtered -- and can only remain connected for the value, in seconds, of the MS-Quarantine-Session-Timeout attribute before the quarantine baselining script must be run and the result reported back to RRAS. 8. The CMAK profile runs the quarantine script, currently defined as the "postconnect action." 9. The quarantine script runs and verifies that the remote access client computer's configuration meets a baseline. If so, the script runs rqc.exe with its commandline parameters, including a text string representing the version of the quarantine script being used. 10. rqc.exe sends a notification to RRAS, indicating that the script ended successfully. 11. The notification is received by rqs.exe on the back end. 12. The listener component on the RRAS server verifies the script version string in the notification message with those configured in the registry of the RRAS and returns a message indicating that the script version was either valid or invalid. 13. If the script version was acceptable, the rqs.exe calls the MprAdminConnectionRemoveQuarantine API, which indicates to RRAS that it's time to remove the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout settings from the connection and reconfigure the session for normal network access. 14. Once this is done, the remote user has normal access to the resources on the network. 15. rqs.exe creates an event describing the quarantined connection in the System event log. SearchSecurity.com Copyright TechTarget 2006

112

Step 2: Create quarantined resources You need to create resources that actually can be accessed while the quarantine packet filters are in place for a remote client. Examples of such resources include DNS servers and DHCP servers, so that IP address and other connection information such as suffix addresses, DNS server addresses, and the like can be retrieved; fileservers to download appropriate software to update out-of-compliance machines; and Web servers that can describe the quarantining process or allow a remote user to contact IT support via email if any problems occur. You can specify and use a quarantined resource in two ways. The first is to identify certain servers, which can be spread across your network, as these quarantine resources. This allows you to use an existing machine to host the quarantined resources, but you also have to create individual packet filters for quarantined sessions for each existing machine. For performance and overhead reasons, it's best to limit the number of individual packet filters for a session. If you decide to go this route, you'll need to enable the packet filters shown in the following table: Table 1. Packet filters for distributed quarantine resources Source Destination Alternatives (instead of specifying port Traffic Type Port Port information) Quarantine Notifier

None

TCP 7250

None

DHCP

UDP 68

UDP 67

None

DNS

None

UDP 53

You also can specify the IP address of any DNS server.

WINS

None

UDP 137

You also can specify the IP address of any WINS server.

HTTP

None

TCP 80

You also can specify the IP address of any web server.

NetBIOS

None

TCP 139

You also can specify the IP address of any file server.

Direct Hosting None

TCP 445

You also can specify the IP address of any file server.

You also can configure any other packet filters that are particular to your organization. The other approach is to limit your quarantined resources to a particular IP subnet. This way, you need just one packet filter to quarantine traffic to a remote user, but you might need to readdress machines and, in most cases, take them out of their existing service or buy new ones.

SearchSecurity.com Copyright TechTarget 2006

113

Using this method, the packet filter requirements are much simpler. You just need to open one for notifier traffic on destination TCP port 7250, one for DHCP traffic on source UDP port 68 and destination IDP port 67, and for all other traffic, the address range of the dedicated quarantine resource subnet. And again, you can configure any other packet filters that are particular to your organization. Step 3: Write the baselining script The next step is to write a baselining script that will be run on the client. You can write this script in any scripting environment supported by your Windows clients, or even as a compiled EXE program. This script can check whatever you want -- there is no standard level of baseline, as it's only what you feel comfortable with letting onto your network. You also can use any sort of interaction with any program that your scripting environment will allow. The baseline script is very flexible and can use whatever software resources you have available. Here is an example batch file script: @echo off echo Your remote connection is %1 echo Your tunnel connection %2 echo Your Windows domain is %3 echo Your username is %4 set MYSTATUS= REM Baselining checks begin here REM Verify Internet Connection Firewall is enabled. Set CHECKFIRE to 1-pass, 2-fail. REM Verify virus checker installed and sig file up. CHECKVIRUS is 1-pass, 2-fail. REM Pass results to notifier or fail out with message to user. if "%CHECKFIRE%" = = "2" goto :NONCOMPLIANT if "%CHECKVIRUS%" = = "2" goto :NONCOMPLIANT rqc.exe %1 %2 7250 %3 %4 Version1-0 REM These variables correspond to arguments and switches for RQC.EXE REM %1 = %DialRasEntry% REM %2 = %TunnelRasEntry% REM RQS on backend listens on port 7250 REM %3 = %Domain% REM %4 = %UserName% REM The version of the baselining script is "Version1-0" REM Print out the status if "%ERRORLEVEL%" = = "0" ( set ERRORMSG=Successful baseline check. ) else if "%ERRORLEVEL%" = = "1" ( set ERRORMSG=Can't contact the RRAS server at the corporate network. Contact a system administration. SearchSecurity.com Copyright TechTarget 2006

114

) else if "%ERRORLEVEL%" = = "2" ( set ERRORMSG=Access is denied. Please install the Connection Manager profile from http://location and attempt a connection again. ) else ( set ERRORMSG=Unknown failure. You will remain in quarantine mode until the session timeout is reached. ) echo %ERRORMSG% goto :EOF :NONCOMPLIANT echo echo Your computer has failed a baseline check for updates on echo your machine. It is against corporate policy to allow out of echo date machines to access the network remotely. Currently echo you must have Internet Connection Firewall enabled and echo an updated virus scanning software package with the echo latest virus signature files. For information about how to echo install or configure these components, surf to echo http://location. Echo You will be permitted to access only that location until Echo your computer passes the baselining check. :EOF Of course, this batch file is simple. I've added the necessary comments throughout the script so that you can follow the action. It's important to keep in mind that you can make the script as complex as you want; you even can compile a special program because the post-connect script option in CMAK allows an .exe file to be run. The one requirement of every baseline script is that it must run rqc.exe if the baselining compliance check was successful and included the following parameters: rqc ConnName TunnelConnName TCPPort Domain Username ScriptVersion The switches and arguments are explained in the following list: •

The ConnName argument is the name of the connectoid on the remote machine, most often inherited from the dial-in profile variable %DialRasEntry%.

•

The TunnelConnName argument is the name of the tunnel connectoid on the remote machine, most often inherited from the dial-in profile variable %TunnelRasEntry%.

•

The TCPPort argument is, obviously, the port used by the notifier to send a success message. This default is 7250.

•

The Domain argument is the Windows security domain name of the remote user, most often inherited from the dial-in profile variable %Domain%.

•

The Username argument is, as you might guess, the username of the remote user, most often inherited from the dial-in profile %UserName%. SearchSecurity.com Copyright TechTarget 2006

115

The ScriptVersion argument is a text string that contains the script version that will be matched on the RRAS server. You can use any keyboard characters except /0 in a consecutive sequence. Step 4: Install the listening components The Remote Access Quarantine Agent service, known otherwise as rqs.exe, must be installed on the Windows Server 2003 machines accepting incoming calls using RRAS. RQS is found in the Windows Server 2003 Resource Kit Tools download, which you can find on the Microsoft Web site at http://www.microsoft.com/windowsserver. Once you've run the installer for the tools, select the Command Shell option from the program group on the Start menu, and run RQS_SETUP /INSTALL from that shell. This batch file will copy the appropriate binaries to the %SystemRoot%System32RAS folder on your system and modify service and registry settings so that the listener starts automatically when the server boots up. A bit of manual intervention is required, however, to finish the installation: you need to specify the version string for the baselining script. The listener service will match the version reported by the remote computer to the value stored on the RRAS computer to make sure the client is using the latest acceptable version of a script. This is a great way to enforce changes you make to your baseline scripts: if a user isn't using the latest version of the scripts (and therefore isn't making the latest analysis of the system based on your needs), he won't be released from the quarantine mode. To make this change manually after you've run RQS_SETUP from the Tools download, follow these steps: 1. Open the Registry Editor. 2. Navigate to the HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Rqs key. 3. Right-click in the right pane, and select New String. 4. Name the string AllowedValue. 5. Then, double-click the new entry, and enter the string that refers to an acceptable version of the script. Step 5: Creating a quarantined connection profile The next step is to create a quarantined Connection Manager profile, which happens to be a normal profile you might create for any standard dial-up or VPN connection, with only a few modifications. For one, you need to add a post-connect action so that your baselining script will run and return a success or failure message to the RRAS machine. You also need to add the notifier to the profile. Let's look at using the CMAK to create a custom connectoid including the necessary NAQC components. 1. Open the CMAK from the Administrative Tools menu, and then click Next off the introductory screen. SearchSecurity.com Copyright TechTarget 2006

116

2. Select Create a new service profile, and then click Next. 3. In the Service name box, type a name that you want to use for the connection. This should be something familiar to users, such as "Connect to Corpnet" or something similar. 4. In the File name box, type a name that you want to use for the service profile. This name is used for the files that CMAK creates while building the service profile. Do not use any of the following characters in the filename: < SPACE > ! , ; * = / : ? ' " < > 5. Click Next. 6. I'll assume here that you do not have an existing CM profile to merge, so simply click Next to bypass the screen that appears that asks you to merge profile information. 7. If you want to add a line of support information to the logon dialog box, type it in the Support information box -- for example, "For customer support, email [email protected]." This is optional. Click Next when you've finished. 8. Specify whether the service requires a realm name, and then click Next. 9. If you want to configure custom Dial-Up Networking entries, click Add. In the Phone-book Dial-Up Networking entry dialog box, type the phonebook Dial-Up Networking entry that you want. Click Next. 10. Specify whether you want to assign specific DNS or WINS server addresses or a Dial-Up Networking script, and then click OK. Click Next. 11. If you want to add VPN support to the service profile, click to select the This service profile checkbox, and then click Next. Specify the server in the Server address box, specify whether you want to assign specific DNS or WINS server addresses and whether to use the same user credentials that are used for a dial-up connection, and then click OK. Click Next. 12. (Here is where the quarantine steps begin.) The Custom Actions screen appears. 13. Select Post-Connect from the Action type drop-down box and then click the New button to add an action. The New Custom Action dialog box is displayed. 14. Type a descriptive title for the post-connection action in the Description box. In Program to run, enter the name of your baselining script. You also can use the Browse button to look for it. Type the command-line switches and their arguments in the Parameters box. Finally, check the two bottom boxes, Include the custom action program with this service profile and Program interacts with the user. 15. Click OK, and you should return to the Custom Actions screen. Click Next. 16. Continue filling in the wizard screens as appropriate, until you come to the Additional Files screen.

SearchSecurity.com Copyright TechTarget 2006

117

17. Click Add, and then enter rqc.exe in the dialog presented next. You can use the Browse button to search for it graphically. Once you're finished, click OK. 18. You'll be returned to the Additional Files screen, where you'll see rqc.exe listed. Click Next. 19. Complete the remainder of the wizard as appropriate. Step 6: Distribute the profile to remote users The profile you just created is made into an executable file that you can distribute to your remote users so that they can run it on their systems automatically, creating a profile without any intervention after that. You have several options for actually getting that executable file to your users. You can transmit the executable file as an attachment to an email message, or better yet, as a link to the executable file hosted on a web server somewhere. In the email message, you can include instructions to run the file and use the new connectoids for all future remote access. You also can have the executable run as part of a logon or logoff script, but to do that, you need to either have your users log on through a dial-up connection, or wait until the mobile users return to the home network and are connected at the corporate campus to the network. Regardless of which method you choose to initially transmit the profile installer to your users, you always should place the latest version of the profile installer on a quarantined resource somewhere, so client computers that don't pass your baselining script's compliancy checks can surf to a web site and download the latest version without compromising further the integrity of your network. Step 7: Configuring the quarantine policy The final step in this process is to configure the actual quarantine policy within RRAS. In this section, I'll create a quarantine policy within RRAS that assumes you've posted the profile installer on a web server that is functioning as a quarantined resource. 1. Open the RRAS Manager. 2. In the left-pane, right-click Remote Access Policies, and then select New Remote Access Policy from the context menu. Click Next through the introductory pages. 3. The Policy Configuration Method page appears. Enter Quarantined VPN remote access connections for the name of this policy. Click Next when you're finished. 4. The Access Method page appears next. Select VPN, and click Next. 5. On the User or Group Access page, select Group, and click Add. 6. Type in the group names that should be allowed to VPN into your network. If all domain users have this ability, enter Everyone or Authenticated Users. I'll assume this domain has a group called VPNUsers that has access to VPN capabilities. Click OK.

SearchSecurity.com Copyright TechTarget 2006

118

7. You'll be returned to the User or Group Access page, and you'll see the group name you added appear in the list box. Click Next if it looks accurate. 8. The Authentication Methods page appears. To keep this example simple, use the MS-CHAP v2 authentication protocol, which is selected by default. Click Next. 9. On the Policy Encryption Level page, make sure the Strongest Encryption setting is the only option checked. Then, click Next. 10. Finish out the wizard by clicking Finish. 11. Back in RRAS Manager, right-click the new Quarantined VPN remote access connections policy, and select Properties from the context menu. 12. Navigate to the Advanced tab, and click Add to include another attribute in the list. 13. The Add Attribute dialog box is displayed. 14. Click MS-Quarantine-Session-Timeout, and then click Add. 15. In the Attribute Information dialog box, type the quarantine session time in the Attribute value box. Use a sample value of 60, which will be measured in seconds, for the purposes of this demonstration. Click OK, and then OK again to return to the Advanced tab. 16. Click Add. In the Attribute list, click MS-Quarantine-IPFilter, and then click Add again. You'll see the IP Filter Attribute Information screen. 17. Click the Input Filters button, which displays the Inbound Filters dialog box. 18. Click New to add the first filter. The Add IP Filter dialog box is displayed. In the Protocol field, select TCP. In the Destination port field, enter 7250. Click OK. 19. Now, back on the Inbound Filters screen, select the Permit only the packets listed below radio button. 20. Click New and add the input filter for DHCP traffic, repeating the preceding steps and including the appropriate port number and type as described earlier. Follow the same directions to allow DNS and WINS traffic. 21. Click New and add an input filter for a quarantine resource, such as a web server, where your profile installer is located. Specify the appropriate IP address for the resource in the Destination network part of the Add IP Filter screen. 22. Finally, click OK on the Inbound Filters dialog box to save the filter list. 23. On the Edit Dial-in Profile dialog box, click OK to save the changes to the profile settings. 24. Then, to save the changes to the policy, click OK once more. About the Author: Jonathan Hassell is author of Hardening Windows (Apress LP) and is a SearchWindowsSecurity.com site expert. Hassell is a systems administrator and IT consultant residing in Raleigh, N.C., who has extensive experience in networking technologies and Internet connectivity. He runs his own Web-hosting business, Enable SearchSecurity.com 119 Copyright TechTarget 2006

Hosting. His previous book, RADIUS (O'Reilly & Associates), is a guide to implementing the RADIUS authentication protocol and overall network security.

Lock down user access and privileges 16 Jun 2005 | SearchWindowsSecurity.com Users should not be Administrators. Malware tends to execute with the privileges of the currently logged-in user. If the user did not have access to key system files and was not authorized to install software, the malware would be stopped dead in its tracks. Unfortunately, in most cases users do have Administrator privileges on their own machines; which means that malware executed under their privileges has carte blanche on the system as well. Many users, particularly those in the executive suites, jump and holler when talk begins of removing or restricting their access to their own machines. For the sake of security, general access should be limited, but that is a tough, uphill battle which requires the support of senior leadership to have any chance of success. Permissions basics for Windows 2000 09.18.2002 | Adesh Rampat | SearchWindowsSecurity.com Plan before you assign permissions All Windows 2000 administrators want to allow the right people access to the right information. To do that, you must understand the most basic form of security -permissions. Most network administrators are already familiar with the setting up of permissions to files/folders, so this article looks at the major concepts you should consider when applying permissions to files/folders. You need to do proper planning before you actually assign permissions. One of the benefits of using Windows 2000 over Windows 98 or Me, for workstations as well as servers, is the ability to use file and folder permissions. To enable file and folder permissions, you need to use NTFS: they are not available on FAT. So when you upgrade to Windows 2000, if you are concerned about file/folder security, you must convert that FAT partition to NTFS. This is normally done during the upgrade process. Use caution when applying the deny permission, because the deny permission takes precedence over any allow permission. All other permission is cumulative or additive. For example, if a user has been assigned the "Read" permission to a file, but is also a member of a group that has been assigned the "Write" permission, the user's effective permission to the file is "Write." If, on the other hand, a user has been assigned the "Deny SearchSecurity.com Copyright TechTarget 2006

120

Write" permission, then that user will not be able to write to the file or folder, even if he/she also belongs to a group that has been assigned Full Control. To properly assign permissions: 1. Calculate what permissions you are going to use for files/folders. Permissions for files/folders are "least restrictive." For example, Paul is a user that has been assigned Read permission to a file. He also is a member of the shipping group that was assigned Full Control to the same file. The result is that Paul's permission for the file will be Full Control, because the "least restrictive" permission will apply to users, and Full Control is less restrictive than Read. 2. Then perform separate calculations for shares using the "least restrictive" rule. For example, the shipping folder is now shared. Paul is assigned change permission. The shipping group (of which Paul is a member) has been assigned Read Only permission. Based on the "least restrictive" rule this user now has Change permission to the shared folder. Permission for files and shares are always additive or least restrictive. What would Paul's effective permission be? It is the combined permission for Paul when he accesses files and folders within the shared folder. This is calculated using the most restrictive rule. So because Paul is accessing the file (for which he has Full Control) through the shared folder (for which he has Change permission), then his effective permission (combined permission) would be Change since this is the most restrictive between the shared folder (Change) and the file permission (Full Control). Paul has Full Control for the file and Change permission for the share folder. Therefore Paul's effective permission is Change. About the Author: Adesh Rampat has 10 years experience with network and IT administration. He is a member of the Association of Internet Professionals, the Institute for Network Professionals, and the International Webmasters Association. He has also lectured extensively on a variety of topics. NTFS default permissions for Windows 2000 11 Feb 2003 | Adesh Rampat | SearchWindowsSecurity.com We all know, or should, that using NTFS as the file system in Windows 2000 for the workstations in your company is the better security decision to make, although there may be a slight performance hit when using this file system. When you upgrade to Windows 2000, of course, you get the option of installing NTFS or using the FAT system. The former requires a "clean install," which means you must wipe out the computer's drive and restore all the data in some way. Still, it's worth it for the security available. But when you do this, there are some default permissions the installer grants, and you need to know what they are and where they're applied. SearchSecurity.com Copyright TechTarget 2006

121

The NTFS filing system has been around since the introduction of Windows NT. As we know this filing system offers much more enhanced security features than the standard FAT system. Administrators should, however, be aware of the various permissions that are used, especially when sharing a drive, so that they can, if necessary, change some of the default settings. Since the list of permissions is lengthy I have included the following link, which should be used as a guide for administrators and anyone one else who might be interested in the various permission that are available when sharing a resource. http://support.microsoft.com/default.aspx%3Fscid=kb%3BEN%2DUS%3Bq244600 This link will take you to the Microsoft TechNet page. Simply type Q244600 (the knowledge based article) then click the go button. (If you're upgrading to Windows XP, you have the option to convert to NTFS after installation, by starting a command window and then executing the CONVERT command. For permissions in XP, click this link: http://support.microsoft.com/default.aspx?scid=kb;en-us;290403.) About the Author: Adesh Rampat has 10 years experience with network and IT administration. He is a member of the Association of Internet Professionals, the Institute for Network Professionals, and the International Webmasters Association. He has also lectured extensively on a variety of topics. How to implement permissions in Windows 2000/NT 20 Mar 2002 | Adesh Rampat | SearchWindowsSecurity.com When implementing permissions in Windows NT/2000 the network administrator should ensure that NTFS volumes are being used and not FAT volumes. A good idea when deciding to implement permissions to folders is that the network administrator can group users who require various forms of permissions and then apply the assigned permissions to the folder. Assigning individual user permission can create some manageability problems especially for larger networks. For all new folders that are created the default permissions assigned to the "Everyone" group is Full Control. You may want to change the Everyone group's permission for a folder to read access, and then any new subdirectories created after that will get the new permission settings. You should perform periodic checks to ensure that the permissions assigned to the current group are appropriate.

SearchSecurity.com Copyright TechTarget 2006

122

File-level permission checks should also be conducted periodically to ensure that the group of users, or in some cases a single user, has the appropriate rights assigned. The network administrator should place program and data files in separate locations. Assigning write access to data files requires special attention. By assigning write access users can copy files from the server to their local hard drive and vice versa. If the user access rights are set up properly on a Windows 2000 workstation, then users should not be able to copy files from the network server to their local drives. It's also a good idea to set Audit options, especially where you've granted write access to a folder There may be instances where users need access to certain sensitive folders in an application but some users within the group will not require access to that particular folder. In that case, share the folders that contain the sensitive information with a dollar sign ($) to hide them from unauthorized persons. As your Windows help system will tell you, such folders are not visible from My Computer, but can be viewed using the Shared Folders snap-in. About the Author: Adesh Rampat has 10 years experience with network and IT administration. He is a member of the Association of Internet Professionals, the Institute for Network Professionals, and the International Webmasters Association. He has also lectured extensively on a variety of topics.

SearchSecurity.com Copyright TechTarget 2006

123

Network access control policies Distinguishing a remote access policy from a portable computing protection policy What is the best way to distinguish a remote access policy from a portable computing protection policy? QUESTION POSED ON: 4 November 2005 QUESTION ANSWERED BY: Shon Harris | SearchSecurity.com These two policies have very distinct focuses. A remote access policy should address the following items and concepts: Standardize remote connectivity for: • Any system type, whether it is company owned or personally owned computers, PDAs, smart phones, laptops, Blackberries, etc. • User type (employee, vendor, contractors, partners, etc.) • Connectivity type, as in dial-in modems, frame relay, ISDN, DSL, VPN, SSH, and cable modems, etc. Remote access should only be allowed to carry out company-related functions Reduce potential unauthorized use of company resources Connectivity and encryption requirements: • VPN, SSL, SSH and encryption needs for sensitive data Employee is responsible for ensuring: • Family members do not violate any company policies • Antivirus signatures, hot fixes and patches are up to date • Personal firewall is installed and properly configured • Authentication credentials are not shared • System is not connected to another network that is not owned by the company or employee • No use of non-company email accounts are used • Non-approved hardware configurations are not used Authentication type that is allowed • Passwords, passphrases, one-time passwords, private key, etc. Enforcement • Disciplinary actions, termination, prosecution While a portable computing protection policy should address the following items and concepts: Standardize connectivity and configurations for: SearchSecurity.com Copyright TechTarget 2006

124

•

Notebook computers, Tablet PCs, Palm Pilots, Microsoft Pocket PCs using Windows CE, text pagers, smart phones, FireWire devices, USB drives, etc. • User type (employee, vendor, contractors, partners, etc.) • Connectivity type, as in remote, LAN, WAN, wireless, etc. Allowable usage • Smart phones with cameras may be banned in sensitive areas for example Classified data needs to be encrypted during transfer or synchronization steps Roles that are allowed to use certain portable devices: • Only executives may be able to use and connect Blackberry devices to the network Specific types of security software may be required for specific types of devices • Additional security software may need to be installed and properly configured Asset management • Company owned portable devices must be properly tagged and documented • User must register device with company before attempting to connect it to the network Portable devices should not be left unattended in public areas Public network may be setup to allow only Internet accessibility for portable devices Prior to transfer of ownership or disposal of portable device, all sensitive data must be properly destroyed Access should only be allowed to carry out company related functions Reduce potential unauthorized use of company resources Connectivity and encryption requirements: • VPN, SSL, SSH and encryption needs for sensitive data Employee is responsible for ensuring: • Antivirus signatures, hot fixes and patches are up to date if applicable • Personal firewall is installed and properly configured if applicable • Authentication credentials are not shared • System is not connected to another network that is not owned by the company or employee • No use of non-company email accounts are used • Non-approved hardware configurations are not used Authentication type that is allowed: • Passwords, passphrases, one-time passwords, private key, etc. Enforcement • Disciplinary actions, termination, prosecution About the Author: Shon Harris is a CISSP, MCSE and President of Logical Security, a firm specializing in security educational and training tools. Shon is a former engineer in the Air Force's Information Warfare unit, a security consultant and an author. She has authored two best selling CISSP books, including CISSP All-in-One Exam Guide, and was a contributing author to the book Hacker's Challenge. Shon is also the co-author of Gray Hat Hacking: The Ethical Hacker's Handbook.

SearchSecurity.com Copyright TechTarget 2006

125

Policies for reducing mobile risk 25 Apr 2006 | Lisa Phifer | SearchSecurity.com Today, many workers are carrying PDAs, smartphones and other mobile computing devices containing at least some business data, such as contact lists, account passwords, confidential emails and file attachments. A 2005 Nokia study found that 21% of US employees carry PDAs and 63% carry mobile phones used for business. While these devices are increasingly well-connected, they are largely unsecured and can pose a significant risk to business networks and data. Reducing that risk starts with establishing an information security policy that deals with both employee-purchased and companyowned mobile devices. Risky business When a mobile device is lost or stolen, any business data it contains is jeopardized. Laws, such as California SB1386 (and similar laws introduced in 35 states last year), require companies to notify individuals whose private information may have been compromised. And businesses that violate industry mandates like HIPAA and GLBA face hefty fines or even jail time. But many companies cannot even enumerate the data carried by lost or stolen mobile devices. A growing number of workers are using PDAs and smartphones to access business networks and applications. In the Nokia study, commonly-used mobile applications included email, instant messaging, corporate database access, sales force automation, field service, CRM and ERP/supply chain applications. Companies without mobilespecific applications may still face mobile exposure through traditional applications. For example, many employees synchronize company email onto PDAs or forward messages to smartphones. Therefore, if lost or stolen, these devices can be used to gain unauthorized access to an otherwise private network and applications therein. Additionally, many mobile devices now support multiple wireless interfaces, creating new attack vectors. Mobile phones with Bluetooth can be "BlueBugged" (used by an attacker to place calls) or "BlueSnarfed" (accessed to retrieve contacts and calendars). Cradled PDAs can become Wi-Fi bridges into corporate networks. When used correctly, wireless interfaces can aid productivity, but safeguards are needed to prevent misuse or attack. Security policy To manage these risks, companies need to define which mobile devices are allowed and under what conditions. They should place limits on network and application access, and on business data storage and transfer. Security measures and practices should be required, and processes defined to monitor and enforce compliance. These decisions should be documented in a mobile device security policy -- a formal statement of the rules by which mobile devices must abide when accessing business systems and data. Such policies may include the following sections: SearchSecurity.com Copyright TechTarget 2006

126

1. Objective: Identify the company, organizational unit and business purpose of the policy. For example, the intent of the policy may be to prevent disclosure of company-confidential data when transferred to or stored on PDAs and mobile phones, no matter who owns those devices. 2. Ownership and authority: Identify those responsible for policy creation and maintenance (development team), those responsible for policy monitoring and enforcement (compliance team), and those responsible for policy approval and management oversight (the policy's owners). 3. Scope: Identify the users/groups and devices that must adhere to this policy when accessing business networks, services and data. Enumerate the mobile device models and minimum OS versions allowed to access or store business data. Identify the organizational units that are (or are not) permitted to do so. For example, you may forbid business data storage on unapproved devices, or you may require users to register personal devices before using them for business. 4. Risk assessment: Identify the business data and communication covered by this policy -- your company assets that may be placed at risk by mobile devices. For each asset, identify threats and business impacts, taking into consideration both probability and cost. For example, when a mobile device is lost, hardware replacement is probably just a small fraction of the impact. If your risk assessment determines that data carried by a mobile device is more valuable than the device itself, this may lead you to focus on data backup and confidentiality as your top priority. 5. Security measures: Identify recommended and required mobile security measures and practices, including: • • • • • • •

Power-on authentication to control lost/stolen device use File/folder encryption to prevent unauthorized data disclosure Backup and restore to protect against business data loss or corruption Secure communication to stop eavesdropping and backdoor network access Mobile firewalls to inhibit wireless-borne attacks against devices Mobile antivirus and IDS to detect and prevent device compromise Application and interface authorization to control program installation, network use, synchronization and data transfer to/from removable storage

For example, your policy may mandate authentication, specifying the minimum length and complexity for passwords and any applications that are excluded from authentication (e.g., accepting incoming phone calls without entering a password). Your policy may also define a process for mobile password reset that is convenient yet safe for users who cannot easily return to the office. 6. Acceptable usage: Define what users must do to comply with this policy, including procedures required for device registration, security software download and installation, and policy configuration and update. Enumerate best practices SearchSecurity.com Copyright TechTarget 2006

127

that users are required to follow, including banned activities. If users understand what they can and cannot do and why, they will be less frustrated and more likely to comply with stated policy. For example, you may implement a mobile security system that automatically detects any PDA cradled to a corporate desktop. That system may prompt the user for self-registration and then push security software and policy onto the PDA. Your policy might explain this procedure and require that users cradle any purchased PDA to their office desktop before using it to store business data. It might also describe unauthorized use that will be blocked, like beaming business data over Bluetooth or copying data to removable storage. 7. Deployment process: Define how you plan to implement and verify your mobile security policy. It is a good idea to begin with a trial, taking both your mobile security software and defined procedures out for a test drive with a small group of users. Many security policies fail because they prove impractical to deploy or use. Working out these kinks before requiring everyone to follow your policy will increase voluntary compliance and overall effectiveness. Don't forget to include training for administrators and users in your deployment process. 8. Auditing and enforcement: Voluntary compliance is nice, but insufficient for truly managing business risk. Effective policies ensure compliance through monitoring and enforcement. For example, you may adopt a mobile security system that checks for a correctly-configured security agent whenever a PDA or phone is synchronized over-the-air or cradled. Be sure to consider all points of network entry (e.g., email server, VPN gateway, Wi-Fi AP, desktop PC cradle), and define a business process to deal with non-compliance and intrusion. Some mobile security systems can hard-reset devices that have been stolen or appear to be under attack, but your policy should clearly define the conditions under which this potentially destructive step will be invoked. About the Author: Lisa Phifer is vice president of Core Competence Inc., a consulting firm specializing in network security and management technology. Phifer has been involved in the design, implementation, and evaluation of data communications, internetworking, security, and network management products for nearly 20 years. She teaches about wireless LANs and virtual private networking at industry conferences and has written extensively about network infrastructure and security technologies for numerous publications. She is also the guest instructor for SearchSecurity.com's Wireless Security Lunchtime Learning. Laptop security policy: Key to avoiding infection 16 Sept 2003 | Ed Tittel | SearchSecurity.com

SearchSecurity.com Copyright TechTarget 2006

128

I'm taking a short emergency break from my ongoing series on security policy document library elements to sound a note of caution regarding the handling of traveling employee laptops. In the wake of recent discussions with several Fortune 500 companies whose internal networks were safe from the onslaught of Blaster, Welchia, SoBig and others, but some or all of whose traveling sales or technical staff got infected by same, I've started to recognize that security policy for laptops is pretty darn important. Although these companies were able to withstand big impacts from these worms, others weren't so lucky. Entire groups or departments of salespeople or technical staff found themselves essentially disconnected from e-mail and network access for anywhere from a full day to as long as a week, depending on how soon they could get their machines repaired and recovered. In light of this situation, I can't stress enough how important it is to develop and implement security policy for laptops, and to keep remote and roving workers as safe as those behind corporate firewalls and other infrastructure elements. To that end, I'm going to refer to a recent posting by Microsoft (yes, that paragon of security itself) that actually makes a great starting point for laptop security policy, then add a few additional recommendations. At www.microsoft.com/security/protect you'll find the following admonitions. "3 steps to ensure your PC is protected: • Use an Internet firewall • Get computer updates • Use up-to-date antivirus software" If followed, this simple prescription would have protected all of the people whose machines were essentially taken out of service by these worms. The missing details, of course, require some expansion of this simple but effective list: •

Choosing the right Internet firewall depends on other corporate policies, vendor selection and so forth. In passing, let me mention that an out-of-the box default install of Norton Internet Security in August produced a machine that showed no vulnerabilities whatsoever (zero!) to security scans from Steve Gibson Research, SecuritySpace.com and even Norton's own more exhaustive Web-based scan.

•

Getting updates is not the issue; installing them is what really counts. Companies should either impose the policy of enforced access to automatic update services from vendors, or provide regular image delivery or patching services of some kind to employees to make sure they're running the latest, greatest, and safest OS and application images.

•

Picking and using antivirus software likewise depends on other policies and vendor selections and again should be combined with automatic updates and email warnings to download signature files when automatic update intervals don't suffice to maintain proper levels of protection. SearchSecurity.com Copyright TechTarget 2006

129

•

Other elements of security policy, such as remote access mechanisms, VPN use, access controls and privileges, and so forth also need to be consistently enforced to prevent unauthorized access to internal systems and resources.

•

Some type of entire drive or directory-based encryption is strongly advised to protect information.

With these simple policy elements in force, laptops needn't pose any more of a threat to security than other systems in use. About the Author: Ed Tittel is Vice President of Content Services at iLearning, a CapStar company based in Austin, Texas. As creator and series editor for Exam Cram 2, Ed's worked on numerous titles on Microsoft, Novell, CompTIA and security certifications, including Security+, CISSP and TICSA. Work with users to secure new technologies in the enterprise 18 Nov 2005 | Al Berg | SearchSecurity.com New technologies make my head hurt. My geeky side loves to play with the latest toys and see what they can do. My Infosec Director side (the side that pays the bills) reacts to new technologies like Dracula to a nice garlic sandwich. How can I keep my organization safe without limiting my users to outdated technologies? Here are a few tips and techniques I find helpful. Stop and take a deep breath Some security practitioners react to new technologies with panic and the issuance of stern edicts against using USB drives/PDAs/EVDO cards/wireless LANs, etc. Stop and take a deep breath. In most cases, users have a legitimate need to fill. It is your job to find a way for them to fill that need safely, not to keep them from being efficient. Besides, issuing stern edicts typically serves only to increase awareness of the "forbidden" (and thus much more interesting) technology and tends to drive users underground, making your job more difficult and adversarial. Work with your users, not against them Make sure that your users feel comfortable talking to you about new technologies. You want them to come and tell you about the neat new gizmo or software they just bought (or better yet, are thinking of buying). They will not do this if they perceive that you are going to arbitrarily stop them from using anything new. A better approach is to sit down with the user, understand what they are trying to accomplish with the new technology, and try and get them to raise the security questions themselves. For example, when smartphones came on the scene, users fell in love with the ability to stuff their cellphone/PDA with all the important information they need while working outside the office. These little gems quickly became nightmares for security people. By sitting down with users, acknowledging all of the good things about smartphones and maneuvering them into asking about how their customer lists, passwords and other SearchSecurity.com Copyright TechTarget 2006

130

confidential information could be protected, I was able to get them to drive the process of setting security standards for the new devices. The resulting standards combine encryption, password protection and the prompt reporting of device loss and subsequent remote self destruct of data, allowing us all to sleep at night. Because the users felt included in the process of analyzing the problem and coming up with the policies, they were willing to accept the addition of some security measures that create a little bit of inconvenience. Compare new technologies to old Another way to deal with new technologies is to compare them with existing technologies. In many cases, from a security point of view, the new gizmo is a lot like some older gizmo, except faster, cheaper and with prettier blinking lights. This makes it easier to explain the security issues to users and can cut down on the need for more and more policies. For example, we are starting to see laptops with built in broadband class Internet connections over wireless public networks (like EVDO or WiMax) being offered for sale. Plugging one of these into a corporate network provides an attacker with a "back door," bypassing all of your expensive firewalls. If you think about it, we've had this problem before with dial up modems. By explaining this new technology to users in comparison to modems, it is easy to make them understand the risks. No new policies are needed to deal with this issue as most companies' modem policies are broad enough to deal with this new form of connectivity. You can allow the use of these connections with the proper firewall measures – just not while connected to the corporate LAN. Educate users New technologies should be part of your awareness efforts. If your users are clamoring for the ability to use those cute little USB thumb drives to carry documents and data, you can either disable USB ports and explain why, or you can show your users how to use an encrypted thumb drive to protect data while in transit. Either option may be a legitimate strategy for your organization, or even for a subset of your organization. It depends on what your company does and how sensitive the information is. The point here is that no matter which choice you make, explaining the logic to users is going to be key in getting them to accept and comply with new policies and standards. Know what's on the horizon Infosec departments should be looking ahead to find out what new technologies are most likely to pop up in their organizations. Every company seems to have a few early adopters who can be counted on to buy and try every new gadget that hits the market. Make these people your buddies and keep tabs on what new technologies they are looking at and how they are using them. Remember: your mission here is to gather information, not to stamp out new and better ways of doing things. Become a business enabler There are going to be times when saying no to a new technology is the right answer. However, if that is the route you are going to take, make sure that you have analyzed the risks and rewards of the new technology thoroughly and that your users understand why SearchSecurity.com Copyright TechTarget 2006

131

they can't use the latest gadget. Offer some alternatives to help users get the functionality they are seeking – safely. As a group, information security has a bad reputation as being the department that says, "No." We need to work on this and change our role from business obstacles to safebusiness enablers. Working with users to introduce new technologies is one way to do this. About the Author: Al Berg, CISSP, CISM is the Director of Information Security for Liquidnet (www.liquidnet.com). Liquidnet is the leading electronic venue for institutional block equities trading. According to INC. magazine in 2004, Liquidnet was the fastest growing privately held financial services company in the US and the 4th fastest growing privately held company in the US across all industries. The benefits of writing a policy before a new system deployment 15 Sept 2004 | Charles Cresson Wood | SearchSecurity.com Consider this scenario: A multi-national company is revamping its network defenses on a worldwide basis. It locates the relevant internal information systems specialists around the world and engages them in a dialog on how to increase the organization's network security. The enhanced security they seek includes content filtering, intrusion detection and other capabilities not yet deployed. The budget for the project does not include sufficient resources to handle organizational issues, such as the establishment of a single manager in charge of network security across the organization. Instead, technical staff specifies, selects and deploys hardware and software, thinking that through these system components information security will be achieved. Staff training, documentation, organizational communications channels and other non-technical factors are postponed until the end of the project, and some are then dropped entirely in order to make a deadline and keep resource consumption down. Although certain managers receive their bonus for bringing in the project on-time and onbudget, the actual level of security delivered is, as a result, significantly lower than it should be. This is due to a lack of effort to integrate business needs with new security functionality and because the organization's ability to effectively manage these new systems is questionable. When organizations decide to write a policy after a security system is deployed, they are missing an opportunity to use the policy-writing process as a way to get consensus amongst a variety of different managers about the functionality of these security systems. The very act of writing a policy begs questions such as the impact on the business, the interfaces with related systems, the degree to which there must be end-user involvement and training, as well as the technical capabilities that must be available in order to properly manage the security systems. SearchSecurity.com Copyright TechTarget 2006

132

When a policy is written before deployment, the policy can direct staff to select hardware and software that genuinely meets collectively-determined business needs. Also, political issues and disagreements about what should be done will be immediately highlighted, and hopefully resolved, all before any money is spent on the involved system. This can help prevent the organization from committing itself to purchasing, leasing, renting or outsourcing certain security capabilities only later to find that these same capabilities are in some way objectionable and inappropriate for the organization in question. As an example, consider a content management system that can, among other things, examine and log the nature of the Internet material being sent and received by specific workers. If a particular worker is distributing unauthorized copies of copyrighted software, the content management system will note this. At first this sounds good, but the functionality may be a problem for existing privacy policies and laws, depending on the organization and country involved. Before technical staff proceeds to acquire and install such a system, it is important that privacy policies and laws be examined, and that approval is obtained. Then a draft policy about a content management system can be prepared. In terms of keeping costs down and project timelines short when deploying a significantly modified or new security system, it is best to write policies early. Here are the benefits of doing so: •

Policies help to define the scope of a system, help to clarify the objectives of a system and help to get alignment from all those concerned with the involved system.

•

Writing policies prior to deployment forces people to look at issues such as necessary changes in business operations.

•

This approach also forces people to communicate their ideas in concrete and explicit terms, particularly when it comes to the business and operational impacts of a new or significantly modified system.

•

Writing policies before deployment may also make it clear that project budgets are insufficient, that desired project timelines are overly-optimistic, and/or that technical staff plans are at odds with business reality.

These days most people wouldn't think of building a house without a blueprint and other plans like a permit from a local government authority, but many people still continue to build information systems (which by the way are even more complex) without the benefit of planning documents such as policies. When you're developing a project plan for the next major security system upgrade, or perhaps the deployment of an entirely new system, be sure to include sufficient time in the early stages of the project to develop policies. Architectures, procedures and configuration standards come later, in part because they are a function of the hardware and software selected. But policies should be vendor neutral and technology agnostic. Policies should talk about necessary control capabilities, affected business processes and required worker interactions with the involved systems. Thus, the overview that policies SearchSecurity.com Copyright TechTarget 2006

133

provide should be one of several early planning tools in every major information security project. About the Author: Charles Cresson Wood, CISSP, CISA, CISM, is an independent information security consultant based in Sausalito, Calif. He specializes in the development of information security documents including policies, standards, procedures and job descriptions. He is also the author of the book and CD-ROM entitled Information Security Policies Made Easy. Managing network policy 22 Jul 2004 | Pete Lindstrom | SearchSecurity.com Managing the complexities of large, distributed networks is a daunting task, with hundreds, even thousands, of mixed-vendor bridges, switches, routers and gateways. Managing the security settings on these devices from a central console sounds wildly impractical -- the requirements are complex, and there are too many fast-moving parts. But, the demands of global business and regulatory compliance are forcing enterprises to consider management consoles that push granular policy updates to heterogeneous devices. There are several environments in which this functionality is critical: •

Multinational enterprises, which may want to segment their networks to comply with the regulatory requirements of the host nation.

•

Manufacturing environments, in which headquarters may need an administrative connection to the plant but the company doesn't want anyone or anything touching the computers running the assembly line.

•

HR and finance departments, which share a lot of sensitive information among themselves and little with other employees and customers.

•

Business partner connections or newly acquired enterprises, where the "other end" of the network is unknown.

•

Enterprises carving out logical networks for users, Web server farms, management backbones, etc., with specific risk thresholds and security requirements.

Managing each set of devices based on particular needs is imperative, but how? Custom scripts can help, and most network vendors have some sort of console; but, for the most part, these devices are operated independently. Network security provisioning solutions provide centralized management of heterogeneous network devices -- routers, switches and even VPNs and firewalls. Aside from stronger configuration control, the solutions also offer SSO for network devices, central logging and, in most cases, network configuration management. Here are a few: •

Gold Wire Technology's Formulator manages ACLs and other configuration parameters and provides infrastructure integrity to network devices, popular firewalls and Linux and Solaris OSes. SearchSecurity.com Copyright TechTarget 2006

134

•

Voyence's VoyenceControl! is a Java application that provides lifecycle change management services. It features support for templates, rollback and workflow.

•

Rendition Networks' TrueControl is a Windows 2000 application that manages many network devices, including wireless access points and VPN concentrators.

•

Intelliden's R-Series software is a Java application that performs device modeling along with its core network configuration features.

•

Solsoft's Policy Server models a network and provides "point-and-click" security design, automatically calculating the ACLs required to allow access from a source endpoint to a server. It pushes out these changes and keeps track of them.

Today's enterprises and their distributed environments are too complex and their requirements too diverse to manage efficiently, but manage them you must. Network security provisioning solutions offer an option that makes sense. About the Author: Pete Lindstrom, CISSP, is research director at Spire Security. Top 10 network security tips 22 Nov 2002 | Mark Edmead | SearchSecurity.com I was asked by a client to develop a "best practices" guide for securing Microsoft IIS 5.0. In my search for supporting reference material, I came across a very informative document called The 60 Minute Network Security Guide on the National Security Agency Web site (www.nsa.gov). The document is only about 40 pages long, but it's packed with valuable pearls of wisdom on how to secure your network enterprise, including specific information for Windows and Unix systems. The document is what is known as a "best practices" guideline for network security. Here's a summary: 1. Make sure you have a security policy in place -- The security policy is the formal statement of rules on how security will be implemented in your organization. A security policy should define the level of security and the roles and responsibilities of users, administrators and managers. 2. Make sure all of your operating systems and applications are patched with the latest service packs and hotfixes -- Keeping your systems patched will close vulnerabilities that can be exploited by hackers. 3. Keep an inventory of your network devices -- Develop and maintain a list of all hardware/software components, and understand which default software installations provide weak security configurations. 4. Scan TCP/UDP services -- Turn off or remove unnecessary services. Unneeded services can be the entry point attackers use to gain control of your system. 5. Establish a strong password policy -- Weak passwords could mean a compromised user account. 6. Don't trust code from non-trusted sources. SearchSecurity.com Copyright TechTarget 2006

135

7. Block certain e-mail attachment types -- This list includes .bas, .bat, .exe and .vbs. 8. Don't provide more rights to system resources than necessary -- Implement the concept of "least privilege". 9. Perform your own network security testing -- Find the holes before the attackers do! 10. Implement "defense-in-depth" -- Don't rely on just one control or system to provide all the security you need. I recommend downloading this document and reading it from cover to cover. It's packed with excellent tips and techniques to help secure your network environment. About the Author: Mark Edmead, CISSP, SSCP, TICSA, is president of MTE Software, Inc. (www.mtesoft.com), and has more than 25 years' experience in software development, product development and network systems security.

SearchSecurity.com Copyright TechTarget 2006

136