Are you ready to start writing your logical security configurations? If you are like most security professionals, this is what we like to do. While we all understand plan- ning is a critical process for success, it is the actual configurations and implementa- tions we like to spend our time working on. Since firewall and VPN solutions provide different capabilities, we have divided this section into two parts.The first part covers Firewall logical security configurations, and the second part covers VPN logical security configuration. Both parts will use a lot of information we gathered in previous sections, such as security areas.
Logical Security Configuration: Firewall
As discussed in the introduction, the Firewall Logical Security Configuration is a document that correlates security policy information into common security feature and functionality. Again, it is important to reiterate this process is not trying to write a device-specific configuration file. While there are many methodologies and process you could follow during this phase, we are going to take a simple, yet effective approach to building your first configurations. We will further divide this section into two components: general security and access policies.
60 Chapter 2 • Using Your Policies to Create Firewall and VPN Configurations
General Security for Firewall Configurations
Anything that relates to the secure deployment of your firewall devices should be documented in this section. We recommend using a spreadsheet similar to the example following. It will allow you to convert your policies requirements into log- ical configurations in an easy way. While this might seem obvious, converting your security policies into these specific details will help in deployment and auditing of your devices. For our example, we have broken the spreadsheet into four columns.
■ AREA and ITEM General and specific categories used to help organize and sort the spreadsheet.
■ DESCRIPTION Statements found in our security policies that need to be configured or supported.
■ REQUIREMENT Specific information that will be used to configure the devices during implementation.
While the description and requirement might both be defined in your security policy, it is important to break them out in your logical security configurations. In some cases, the requirements are loosely defined in security policies, and this exercise (see Table 2.6). will help articulate a specific requirement for a given area and item.
Table 2.6General Security: Articulation of a Specific Requirement for a Given Area and Item
Area Item Description Requirement
Management Access Control All remote man- Each firewall will be agement must be required to support a limited to side- dedicated network band, dedicated interface on the
management 10.10.10.0/24 network.
interfaces.
Management Protocol Support All remote man- Secure shell access will agement must be be limited to SSHv2, secure and and secure Web access encrypted. will be limited to SSL.
Continued
Table 2.6General Security: Articulation of a Specific Requirement for a Given Area and Item
Area Item Description Requirement
Behavior Default Access If a rule or policy Implied access policy Policy does not grant or will be to drop all
restrict access, the connection attempts default access and log.
policy should be deny. In addition, only IP traffic is allowed to traverse between segments.
Logging Default Level All connection Internet to Trusted Logging attempts origin- Security Areas—
ating from the Logging = True Internet must be
logged.
Access From Internet All connections Source=Internet Zone originating from Destination=Any
untrusted sources, Access=Drop such as the Logging=True Internet, should be
dropped and logged.
Access To DMZ All connections Source=Internet Security Area from an untrusted Destination=DMZ
security zone, Access=HTTP/HTTPS/
such as the SMTP
Internet, with a Logging=True destination to the
DMZ will be limited to HTTP, HTTPS, and SMTP.
Policy Access All connections Source=DMZ
originating from a Destination=Internal security area with Access=Drop
a risk greater than Logging=True the destination
must be dropped and logged.
62 Chapter 2 • Using Your Policies to Create Firewall and VPN Configurations
Access Policies for Firewall Configurations
Access policies are more specific and include a lot of information we developed ear- lier in the chapter.This includes things such as security areas and security area risk ratings (see Table 2.7).
Table 2.7Security Areas and Security Area Risk Ratings
Source Destination Access Protocols Logging Notes User-Network, DMZ-1 Allowed HTTP, HTTPS Enabled Internal
VPN-Network user
access to DMZ servers Internet DMZ-1 Allowed HTTP, HTTPS, Enabled Internet
SMTP access to
DMZ servers User-Network Internet Allowed HTTP, HTTPS Disabled Internet
Conference- access
Network, VPN-Network
User-Network IT-Network Allowed CIFS, HTTP, Disabled Internal
HTTPS, DNS server
access VPN-Network IT-Network Allowed- CIFS, HTTP, Disabled Internal
Authen- HTTPS, DNS server
ticated access
IT-Network Internet Allowed- HTTP, HTTPS, Disabled Internal
Authen- DNS server
ticated Internet
access
DMZ-1 Internet Allowed DNS Disabled
DMZ-1 Internet Allowed- HTTP, HTTPS Enabled Allows
Authen- Internet
ticated access
after authenti- cation
Logical Security Configuration: VPN
Virtual private networks, commonly referred to as VPNs, are deployed in most com- panies today. While there are many types and uses for VPNs, many are deployed to provide secure, remote access to the companies’ network resources to remote employees. In today’s distributed environments, field sales teams, home-office based employees, and consultants are all great examples and users of VPN solutions. As VPNs provide the necessary communication links between these users and resources, they also bring new challenges to security professionals.They are common targets for attackers and are considered one of the weakest points in the overall security posture of an organization.
VPNs are also used when an organization wants to connect remote sites together or with a central site.These deployments might use one of many types, but often are found using the Internet as their transport. Using the Internet as a transport has many advantages.They often are more cost effective, easily deployed, and use stan- dardized protocols such as IPSec.The more common VPN solutions include:
■ Gateway-to-gateway IPSec
■ Gateway-to-gateway PPTP
■ Gateway-to-gateway L2TP
■ Gateway-to-gateway IPSec
■ Gateway-to-gateway SSL
Best Security Practices for VPN Configurations
Your first goal is to ensure your VPN solution can be configured to enforce the requirements defined in your security policies. However, there are many common, best security practices we recommend for all VPN deployments.These include:
■ Deploy VPN termination devices on dedicated network segments.
■ Require secure access control for all VPN traffic.
■ Use dedicated devices for VPN termination.
■ Limit management access to side-band/out-of-band interfaces.
■ Require additional or complementary authentication to standard username and passwords.
■ Enable auditing, providing detailed audit trail for access, authentication, and use.
64 Chapter 2 • Using Your Policies to Create Firewall and VPN Configurations
■ Limit rules or configurations to specific users and, instead, design around groups.
■ Use recent software versions.
■ Audit logs and authentication records on a daily basis.
It is imperative to evaluate and integrate best security practices when deploying your VPNs. VPNs are one of the weakest areas of your network and can lead to breaches in your network security. An old cliché in security is, “security is only as strong as the weakest link.” Keep in mind, no system or device is 100-percent pro- tected and secure from attacks or vulnerabilities. If someone wants access, he or she will gain it. Many times, your configurations and security policies only need to be as strong as the information they are protecting. As security professionals, you have learned security is a trade-off of risk versus reward. Keeping this in mind is useful when creating your VPN logical security configurations.
Once a host authenticates, it is common to authorize the specific user. While host authentication is recommended, it does not ensure the person using that host is who you believe him to be. A common best practice is to deploy a strong, two- factor user authentication system such as RSA SecurID tokens and Aladdin Knowledge Systems’ eToken solutions. Other solutions include biometric systems, smart cards, USB tokens, and random one-time-password token systems. When deploying VPN access for remote users, it is recommended one of these systems be used versus a standard username- and password-based system.
Who Needs Remote Access?
Determining who needs to use your VPNs is not an easy task that can be done in just minutes. It is not uncommon for almost every employee to need some form of VPN access at one point or another.This introduces many challenges from user management to the auditing of your systems and individual access logs.This is an area in which your user groups and centralized user management systems will play an important role. It will help ensure your access rights are secure and granted to only those individuals or groups that need access. As you implement a remote access VPN solution, keep your access controls simple and easy to audit. Long term, this will help you maintain a strong security posture with your remote access solutions.
Many organizations deploy their remote access solutions granting their users unrestricted access to all internal network resources.This is probably one of the most critical mistakes you can make as a security professional. Access controls should be specific and related to the requirements defined by your written security policies.
Some additional best practice recommendations for remote VPN users include:
■ Grant access to user groups and not individual users.
■ Implement access control, granting access only to those resources that are required.
■ Require a strong authentication system, based on a user and not a device.
■ Enable strong audit capabilities.
■ Require password changes twice as often as policy requirements or internal systems for remote VPN users.
Access Policies for VPN Configurations
VPN access policies are more specific and include a lot of information we developed earlier in the chapter.This includes things such as security areas and security area risk ratings.Table 2.8 is an example remote access VPN logical configuration policy for our example company.
Table 2.8Remote Access VPN Logical Configuration Policy
Source Destination Access Protocols Logging Notes
VPN- DMZ-1 Allowed- HTTP, HTTPS Enabled Remote user
Remote Authenti- access to
Employees cated DMZ servers
VPN- Contractors
VPN-Users- Internet Allowed HTTP, HTTPS Disabled Internet
ALL with URL access
Filtering
VPN- IT-Network Allowed- CIFS, HTTP, Disabled Internal
Remote- Authenti- HTTPS, DNS server access
Employees cated
VPN- IT-Network Allowed- CIFS, HTTP, Enabled Internal
Contractors Authenti- HTTPS, DNS server access
cated
The most important concept to remember is you should only grant access to remote users based on their requirements. Granting unrestricted access might be easier to manage, but creates a security risk that will likely lead to an attack or secu- rity incident.
66 Chapter 2 • Using Your Policies to Create Firewall and VPN Configurations
Summary
Creating logical security configurations for firewalls and VPN devices is not a trivial task. It takes time and patience to create a strong security posture for any organiza- tion. Since these devices are common targets for attack and exploitation, they are the areas that require a lot of attention. With practice and over time, the process to effec- tively convert your written policies into logical security configurations will become easier. As discussed early in the chapter, our primary goal is to create a roadmap that is abstracted from specific vendors’ devices or product feature set.This very impor- tant step will help create an overall more secure environment.This process helps security administrators implement secure configurations that reflect the business goals of the organization. While it is not important to rank each step as it relates to another, it is easy to understand how focusing time and effort to each can help achieve success during implementation, and to maintain it through the entire man- agement lifecycle.
Solutions Fast Track
Logical Security Configurations
Logical security configurations are documents that interpret written security policy requirements and define configuration requirements for a specific type of enforcement device, like a firewall or VPN product.
Unlike a device configuration for a specific vendor’s product or version, logical security configurations are written to common feature sets found in the target enforcement devices.
Logical security configurations are developed for a type or group of enforcement devices versus one for each device in your environment.
A specific written policy requirement or item is commonly used by many logical security configuration documents across the enterprise.
Planning Logical Security Configurations
Identification of network assets is a critical requirement in the overall security posture of an organization.
Networks evolve and constantly change and as a result, a method to capture, organize, edit, and audit this information is recommended.
Network asset profiling is an exercise to capture and validate information specific to each device. A combination of automated tools and interviews is commonly used by security professionals.
Security areais a term used to group together network assets based on common attributes of those devices.
Security area risk rating is a numerical value assigned to each area that helps a security professional understand the relationship between those two areas. As traffic passes from one area to another area, this rating helps understand the policy that should be enforced for that traffic.
Users and user groups are a key element in security policy development.
Most access is granted to user groups versus individual users.
Writing Logical Security Configurations
Logical security configurations are written for each type of device that will be used to enforce an organization’s written security policies.
VPN remote access to your company’s resources is considered high risk, and as a result, additional user authentication and access restrictions are recommended to reduce the chance of a security breach.
Logical security configurations, once written, should be audited and reviewed against actual configurations on a regular basis.
It is a best practice to separate the responsibilities for writing security policies, logical configurations, and implementation guides.
68 Chapter 2 • Using Your Policies to Create Firewall and VPN Configurations
Q. Since we have already standardized on a specific vendor’s firewall and VPN solu- tion, should we still create a logical security policy?
A. It is recommended you go through the process to develop your logical security policies even if you have already bought a vendor’s product or solution. Doing so will help you understand your security policy in more detail and ensure you have the right product and features to enforce your organization’s requirements.
In many cases, this exercise will help discover other features in your products that might not enabled or could be configured that result in an overall, better security posture for your organization.
Q. I don’t understand the concept of a security area risk rating and how it relates to the logical security configuration.
A. A security area risk rating is numerical value you assign to each security area, and as a result, allows you to understand the relationship of risk between those two areas.This will be helpful when evaluating traffic that traverses between two security areas and applying a specific enforcement policy to the traffic.
Q. Why is it recommended to implement VPN termination devices on a dedicated, separate network?
A. Terminating remote access on a dedicated segment provides many security bene- fits, including auditing, management, and security policy enforcement.This is a best-practice design and not a requirement.
Q. With new remote access solutions such as SSL clientless VPNs, how do they compare from a security perspective to traditional IPSec VPN solutions?
A. The main difference between using an SSL and an IPSec-based solution has more to do with the management of remote clients than with the security of the system.The overall security effectiveness is in the strength and implementation of the encryption algorithms.
Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutionsand click on the “Ask the Author”form.
Q. In our DMZ, we allow access to internal resources for the system administrators and developers. Reading this chapter, you recommend not allowing access to internal systems. Why?
A. DMZs are traditional security areas that host servers and services that are more subjective to external attacks. As a result, compromised systems on your DMZ will have a high likelihood of becoming a launch system. By limiting access to other internal security areas, a system compromised could be contained and limit the attacker’s ability to gain additional access to other areas of your network.
Q. Our authentication for remote access users currently uses the built-in features. Is our solution secure?
A. While this is not insecure per se, it is not a strong solution.You should make it a priority to implement a strong authentication system to replace the built-in con- trols you are using today. In addition, it is recommended you audit your access logs often and educate your users about ensuring they maintain strong passwords that are not easily guessed.
Q. Our network design limits our ability to control specific access for our remote users, and as a result, we grant unrestricted access. Are we secure?
A. Again, while not insecure, this is an area that would be considered high risk and likely to lead to a security incident. A network design in which security has been an afterthought is challenging and difficult to secure. In these cases, it is recom- mended you gain executive support to create a project that will address all the security concerns of your organization. Remember the old saying, “security is only as strong as the weakest link in the system.”
Part II