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).