Firewalls and VLANs

Chia sẻ: Tuan Bui Nghia | Ngày: | Loại File: PDF | Số trang:4

Thêm vào BST

Báo xấu

97
lượt xem 15
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

One of the most common questions with regard to designing a firewall implementation is how VLANs and firewalls interact with each other

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Firewalls and VLANs

Firewalls and VLANs One of the most common questions with regard to designing a firewall implementation is how VLANs and firewalls interact with each other. Historically, firewalls and VLANs went together like oil and water. Physical separation of resources for the purposes of security was a sacred cow. It was an untouchable fact in network security. This was reinforced by exploits and security issues that allowed traffic to traverse between VLANs without going through a firewall or router, effectively bypassing any security that was in place. A few things have contributed to a change in thinking regarding firewalls and VLANs. First, people became very comfortable with VLANs on their internal networks and started using them to segment resources logically throughout their internal network. Second, people started to realize that if they used multiple DMZs to house resources of differing types, they could further segment and secure their perimeter resources by placing resources with common access rules in different DMZ segments, instead of just tossing everything into a single DMZ segment. The problem with creating so many DMZ segments is that doing so required an incredible expenditure in network infrastructure equipment such as switches and firewalls. After all, physically separate DMZ segments required a dedicated switch and firewall interface on each DMZ segment, at a minimum, which frequently made the solution cost prohibitive. To address the cost issues, VLANs were looked at as a viable solution. Finally, switch vendors began securing their software to help prevent the circumstances (typically buffer overflows) that would allow traffic to traverse VLAN segments without going through the firewall or router. Separate DMZ segments are fundamentally no different than separate subnets on an internal network. On the internal network, VLANs are used to logically separate subnets in lieu of physical separation. The benefits of this are well understood. It is cheaper to implement because you do not need physically distinct switches or routers for each subnet, and it is easier to manage the overall environment because moving resources from subnet to subnet merely requires a change in the VLAN configuration (and, of course, a change of the IP address of the system being moved). This same logic was applied to the network perimeter, which resulted in using VLANs to create distinct DMZ segments. Although using VLANs addressed the cost issue completely, the use of VLANs creates a couple of important issues for folks to consider. First, whereas logical separation of resources on a trusted network was generally considered an adequate security risk, it is not as secure as physical separation of resources. At the end of the day, a logically separated subnet is still physically connected to other subnets in the same switch fabric. Normally for traffic to go from one VLAN to another, it must go through a router (or firewall and thus can be filtered accordingly);
because there is no actual physical separation between the VLANs, however, it is possible for traffic on one VLAN to inadvertently be delivered to another VLAN without using a router or firewall. The most common exploit to take advantage of this logical separation is to create a situation that causes the switch to forward packets across VLANs without going through the corresponding router or firewall. On a trusted network, this might not be a big deal. If the only separation between your internal network and the Internet is a VLAN, however, the risk becomes much more substantial. Traffic from the Internet could wind up on your internal network, completely bypassing the firewall. It's important not to overstate this risk. It is not really a trivial task to accomplish, and when switches have been found to be vulnerable to such an attack the vendors tend to fix the switch software relatively quickly, but the risk does exist. Note For more information about VLAN security, check out the following white papers: http://www.sans.org/rr/whitepapers/networkdevs/1090.php http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking_solutions_whi te_paper09186a008014870f.shtml The second issue to consider when using VLANs is that because there is no physical separation of resources, a server on one DMZ segment may be plugged into the same switch right next to a server in another DMZ segment. This setup can make it very easy to inadvertently plug a server into the wrong VLAN, and thus the wrong DMZ segment (which may create an inadvertent security risk). Although you can mitigate this by paying careful attention to detail and having well-documented and well-followed procedures and policies, the bottom line is that the best technical controls out there cannot prevent every instance of human error. Some examples of good practices to mitigate this problem are as follows: • Set trunking to off on all access ports. • Enable port fast on all access ports. • Implement port security on all access ports. • Limit the use of VLAN 1. • Configure dedicated native VLANs on trunk ports. • Manually configure allowed VLANs on trunk ports. • Shut down all unused ports and place them in an unused VLAN. Although you can use VLANs in the network perimeter, it is important not to use them to separate resources that have distinctly different security levels. For example, the Internet and the internal network should always be physically separated from every other network or DMZ segment with a firewall physically sitting between the segments and controlling
the flow of traffic. Additionally, if you are going to use VLANs, you should implement an IDS/IPS solution that can notify you of traffic that has an incorrect source or destination IP address, indicating that traffic from one VLAN may be incorrectly on a different VLAN or that a server from one VLAN may have been inadvertently plugged into the wrong VLAN. You should also plan on implementing VLAN access control lists (VACLs) to provide a means of filtering traffic at Layer 2, and thus within the VLAN, to further protect resources. Virtual Firewalls Virtual firewalls build upon the practice of using VLANs. After all, if you can logically separate a switch into multiple subnets, why not have the ability to use a single interface on a firewall (or a logical interface on a firewall blade in a switch chassis) to filter between those logical subnets. The benefit of this approach is that you further reduce the cost of implementation by removing the need for each VLAN to connect to a physically distinct interface. Virtual firewalls are most commonly implemented by separating a single firewall into multiple logical firewalls, sometimes referred to as security contexts. Virtual firewalls are also frequently implemented on network devices that support firewall hardware or software as a component of the network device. For example, a Cisco Catalyst 6500 with a Firewall Services Module (FWSM) allows you to create up to 100 virtual firewalls within the switch. The virtual firewall can then be associated with corresponding VLANs, providing the same functionality that would exist if a physical firewall had been used to segment the VLANs from the rest of the network. Because virtual firewalls can so easily be integrated into many switches, they are a good way to segment and secure internal resources. Virtual firewalls are also commonly used to segment DMZ segments that use VLANs as the segmentation method. This allows multiple VLANs to be secured by multiple virtual firewalls using a single firewall interface. A big disadvantage of virtual firewalls is the fact that many folks have a hard time conceptualizing virtual devices and objects. This can make it difficult to troubleshoot or diagnose problems. Additionally, each virtual firewall is typically treated as an individually managed and maintained resource, in addition to the system context (or physical device itself), which increases management costs. Finally, not all virtual firewalls can function exactly as if there were a physical firewall. For example, in certain configurations, virtual firewalls may not be able to support technologies such as dynamic routing protocols (such as when using Cisco FWSM and transparent mode configuration).