Wednesday, December 3, 2008

Network Access Protection Using 802.1x VLAN’s or Port ACLs

Given that the NAC (Network Access Control)market is one of the hottest segments in the industry (I think virtualization has that distinction at the moment) it is fitting to take a look at the variety of options available from Microsoft's Network Access Protection (NAP). NAP supports a variety of what we call enforcement methods. In the NAP space, and enforcement method is simply a term that defines the way a machine connects to a network. In NAP, these are DHCP, 802.1x (wired or wireless), VPN, IPsec, or via a Terminal Services Gateway.

The most common method of the list is 802.1x for a variety of reasons. First, the industry has been selling 802.1x network authentication for the last 10 years. 1x gained tremendous popularity as wireless networking became prevalent in the late 90's and early 2000's and has been proven to be a viable solution to identifying assets and users on your network. For customers that have invested in 802.1x capable switches and access points, NAP can very easily be implemented to complement what is already in place. The Network Policy Server (NPS) role Windows Server 2008 has been dramatically improved to make 802.1x policy creation much simpler to do, however, what many people don't realize is that there really are 2 rather distinct ways to deploy 802.1x based NAP, and this is what we will be discussing today. These 2 methods are commonly referred to as the use of VLAN's or Port ACL's.

VLAN

Since we are talking about this in the context of NAP, this would be a good time to introduce the fact that taking the VLAN approach essentially requires that you involve the folks that own your switching infrastructure in your NAP plans. Why you ask, because you will now be asking them to touch all the switches and AP's on the network to create the VLAN structure that you will need for your NAP deployment. At a minimum, you would want to create 3 different VLAN's. One for 'healthy' or compliant computers, one for 'unhealthy' or non-compliant computers, and a third VLAN for guests, or unknown devices that cannot pass the ports requirement to do 802.1x authentication.

In the VLAN scenario, on your RADIUS server (i.e. our NPS server) you would create a policy that had a set of attributes with values that matched the VLAN you have created on the switch. The most common attributes used are Tunnel-Private-Group-ID, Tunnel-Tag and Filter-ID. The values for these attributes usually would match the VLAN name, or number you created on the switch.

As an example, let's say on your switch VLAN 100 is the compliant VLAN and VLAN 200 is the non-compliant VLAN.

To make this work when you walk through the wizard in NPS to create 802.1x policies you will create a compliant and non-compliant policy. When prompted to insert values for these attributes you will enter "100" for your compliant policy (i.e. Tunnel-Private-Group-ID = 100) and "200" for the non-compliant policy. Our wizard based configuration makes this very easy.

Once completed, when a machine comes onto your network and meets the criteria of one of the policies you created, the NPS will send back this tunnel information to the switch to instruct the switch to put that machine in the proper VLAN. Pretty simple and straight forward.

Port ACLs

There are 2 approaches here.

  1. You send the switch a 'reference' to an ACL you have already created on the switch
  2. You send the switch vendor specific attributes with values that tell the switch how to ACL the port


In scenario 1, you would do the heavy configuration on the switch by creating the ACLs you would want for compliant and non-compliant machines. Most likely those ACL's would restrict protocols and ports and access to only certain IP addresses. For this example let's say you have named your ACL's "compliant" and "non-compliant".

In your RADIUS server you would use something like the Filter-ID attribute (this is the most commonly supported attribute) with a string value of "compliant" or "non-compliant". When received the switch will then know what ACL to apply to that port.

In scenario 2, instead of configuring and sending the Filter-ID attribute, you would create Vendor Specific Attributes (VSAs) (this is a common concept in the RADIUS protocol) that tell the switch explicitly what ACL's to apply to that port. For example, the HP ProCurve line of switches will accept the following Vendor Specific Attribute (VSA)

permit in udp from any to 10.10.10.2 53

This essentially says 'allow any DNS traffic on this port to IP address 10.10.10.2'. The assumption is that 10.10.10.2 is your DNS server.

The pros and cons of the 2 port ACL approaches are fairly similar as well.

  1. Pros, simplified RADIUS server configuration, less prone to mistakes in the RADIUS server configuration; Cons, required to touch your entire switching infrastructure, ACL configuration isn't centralized
  2. Pros, doesn't require you to touch your entire switching infrastructure, configuration can be centralized on your RADIUS servers; Cons, more complex RADIUS server configuration, prone to mistakes in ACL configuration on the RADIUS server


Comparing the 2 approaches


Now that everyone understands what is required for each approach, let's take a look at some of the pro's and con's of each.

VLAN


+ The concept of VLAN's is one that is easy to explain that even a manager can figure out!

+ Doesn't require extensive knowledge of the RADIUS protocol to set up and anyone who's anyone at a switch CLI could get this set up pretty easily

+ Makes helpdesk troubleshooting a bit simpler by being able to quickly find out why a machine can't connect to (insert your answer here). It would go something like "Oh, you can't get to your mail because you're in VLAN 200!"


- The user experience can be very poor if the machine is being dynamically moved from VLAN to VLAN (which is what NAP does essentially). The reason why is because when a machine changes VLAN's the interface on the machine is torn down and essentially does an ipconfig /release /renew

- If not properly designed, this can be a real helpdesk nightmare. A common mistake here is to ACL down the non-compliant VLAN to not have any corporate access, which is a mistake since that machine may need to re-authenticate itself with the network after NAP has remediated it

- Requires you to touch all of your switches and AP's to do the VLAN creation and management.

- For NAP, your AP's and switches will need to support the ability to do dynamic VLAN assignment and not all switches and AP's support this concept. In fact, not all firmware versions from the same manufacturer support this, so an upgrade may be required.


Port ACL


+ Can possibly be implemented without having to touch all your switches and AP's since the configuration would reside on the NPS Server. This can also be seen as a political positive as well since infrastructure folks and server folks are commonly separate teams with separate objectives that rarely overlap.

+ The actual enforcement of the ACL is done at the switch or AP and thus offers the user a more pleasant experience since even if the machine is moving from a compliant to a non-compliant state (or vice versa) it is handled at the switch and not on the client machine (no ipconfig /release /renew)

+ The attributes and values required in your NPS policy to make this scenario work are commonly supported and have been for some time, so the chance of having to do a hardware upgrade in this scenario are less likely


- To really make this work effectively in an enterprise you really need to know the ins and outs of your switches and what is and is not supported, not to mention you must be a pretty good RADIUS geek as well to get this working (we are a dying breed these days… J)

- Troubleshooting and helpdesk support in this scenario is a bit more complicated since your NPS policy for this could have multiple ACL's in it that look like this (permit in udp from any to 10.10.10.2 53). It would not be uncommon to have 10-12 lines like this in your policy and trying to figure out why a machine can't connect to a resource on the network

- Finding accurate documentation on exactly what attributes and values are supported for your device(s) can be a challenge

In conclusion

Hopefully now you have a better understanding of what 802.1x authentication support in NAP can offer you. 1x is a very powerful means of maintaining and safe and healthy network, but it's not the ultimate solution by any means. Network security and health is an ongoing exercise that may require multiple solutions to achieve your business goals (like using 1x and IPsec together for instance).


Tuesday, December 2, 2008

Network HUBs

Hubs and switches function as a common connection point for the workstations, printers, file servers and other devices that make up a network. The main difference between hubs and switches is the way in which they communicate with the network.

What is a Hub?

A hub functions as the central connection point of a network. It joins together the workstations, printers, and servers on a network, so they can communicate with each other. Each hub has a number of ports that connect it to the other devices via a network cable.

How does a Hub work?

A hub is an inexpensive way to connect devices on a network. Data travels around a network in 'packets' and a hub forwards these data packets out to all the devices connected to its ports.

As a hub distributes packets to every device on the network, when a packet is destined for only one device, every other device connected to the hub receives that packet. Because all the devices connected to the hub are contending for transmission of data the individual members of a shared network will only get a percentage of the available network bandwidth. This process can slow down a busy network.

A 10Base-T hub Ethernet Hub provides a total of 10 Mbit/sec of bandwidth, which all users share. If one person on the network is downloading a very large file, for example, little or no bandwidth is available for other users. These users will experience very slow network performance.

What is a Switch?

A switch is more sophisticated than a hub, giving you more options for network management, as well as greater potential to expand. A switch filters the data packets, and only sends the packet to the port which is connected to the destination address of that packet. It does this by keeping a table of each destination address and its port. When the switch receives a packet, it reads the destination address and then establishes a connection between the source port and the destination port. After the packet is sent, the connection is terminated.

What are the advantages of a Switch?

A switch provides higher total throughput than a hub because it can support multiple simultaneous conversations. For example, when a 100Mbit/sec hub has five workstations, each receives only 20Mbit/sec of the available bandwidth. When a 10/100Mbit/sec switch is used every port on the switch represents a dedicated 100Mbit/sec path, so each workstation receives 100Mbit/sec of bandwidth.

Switches also run in full duplex mode, which allows data to be sent and received across the network at the same time. Switches can effectively double the speed of the network when compared to a hub which only supports half duplex mode.

Why choose one of our Switches?

Switches improve the performance and efficiency of a network and should be used when you:

  • Need to make best use of the available bandwidth
  • Have multiple file servers
  • Require improved performance from file servers, web servers or workstations
  • Use high speed multi-media applications
  • Are adding a high speed workgroup to a 10Mbit/sec LAN
  • Plan to upgrade from 10 to 100Mbit/sec or Gigabit network

The standard features on all N-Way switches are:

  • 10/100Mbit/sec Auto-Negotiation on all ports, the switch automatically senses the speed of the attached device and configures the port for the proper speed. This simplifies deployment in mixed Ethernet and Fast Ethernet environments
  • Auto MDI/MDI-X auto-detects whether the connected cable type is normal or cross-over
  • Full or Half Duplex operation

Which Switch do I need?

If you are setting up a home or small office network an ideal solution is to use a switch with 5 to 8 ports. Switches can be linked together as your network expands.

For a good entry level switch to meet this requirement we recommend the 5 Port 10/100Base-TX Ethernet N-Way Switch (Part No. 32981) or the 8 Port 10/100Base-TX Fast Ethernet N-Way Switch (Part No. 32982)

The compact 8 Port 10/100Base-TX Fast Ethernet Switch features Auto MDI/MDI-X on all ports, 10/100Mbit/sec Auto-Negotiation, and full and half-duplex modes and can be desktop or wall mounted.

If you require a larger switch with rackmount capability choose the 16 Port 10/100 Base-TX Fast Ethernet N-Way Switch (Part No. 25020) or 24 Port 10/100 Base-TX Fast Ethernet N-Way Switch (Part No. 25021).

These 19" rackmount switches are the perfect solution for expanding a 10/100 network.

Gigabit Ethernet Switches

Our GIGA N-Way Switches provide cost effective scalability of the network by utilising the existing copper CAT5e cabling environment. Connectivity is not sacrificed because the same cabling is used for Ethernet, Fast Ethernet and Gigabit Ethernet.

These switches also incorporate VLAN technology. This feature is accessed from a console port on the switch and provides network administrators advanced configuration options and the ability to set up “virtual” LANs which function as separate, secure network segments.

The LINDY 24 Port 10/100Base-TX + 2 Port 1000Base-T GIGA N-Way Switch (Part No. 25000) is ideal for linking backbone connections between servers and network switches.

24 Port 10/100Base-TX Switch with two 10/100/1000Base-T Gigabit Ethernet Ports with VLAN technology.

Managed Switches

A managed switch allows the ports on the switch to be configured, monitored, enabled and disabled. Switch management can also gather information on a variety of network parameters, such as:

  • The number of packets that pass through each of its ports
  • What types of packets they are
  • Whether the packets contain errors
  • The number of collisions that have occurred

You should look for the following features on a managed switch:

  • Gigabit Ethernet support
  • SNMP management and remote control capabilities
  • A management interface that can be accessed through an internet browser
  • Auto-negotiation support which auto-senses the speed and duplex capabilities of connected devices
  • Built-in expansion capability

The Fully Managed SNMP 24 Port 10/100Base-TX + GIGA Expansion N-Way Switch (Part No. 25030) is a high performance web-managed Layer 2 Switch that provides 24 Fast Ethernet 10/100Mbps ports. The built-in expansion slot can accommodate a number of different modules. Optional Gigabit/Fast Ethernet modules can be copper or fibre based and support 10/100/1000Base-T, 100Base-FX, and 1000Base-SX. This switch is ideal for organisations wishing to create a new, or upgrade their existing network infrastructure.

The switch features advanced SNMP (Simple Network Management Protocol) management and remote control capabilities, and supports an easy to use Layer 2 management interface that can be accessed through an internet browser.

Fully managed SNMP 24 Port Fast Ethernet and full Gigabit backbone support with remote management.

Using a managed switch can reduce hidden costs by using –

  • Switch and traffic monitoring to help head off problems before they occur, reducing user downtime
  • Management tools that offer an intuitive graphical user interface (GUI) that simplifies configuration and monitoring tasks
  • Management functions can be performed remotely using a web browser or directly via a console connected to the switch

Virtual Network Components

Virtual Network Components

The key virtual networking components in a VMware Infrastructure are virtual Ethernet adapters and virtual switches. A virtual machine can be configured with one or more virtual Ethernet adapter. Virtual switches allow virtual machines on the same VMware ESX host to communicate with each other using the same protocols that would be used over physical switches, without the need for additional hardware. They also support VLANS that are compatible with standard VLAN implementations from other vendors, such as Cisco.

Connecting Virtual Machines to your Network

VMware technology lets you link local virtual machines to each other and to the external enterprise network through the virtual switch. The virtual switch emulates a traditional physical Ethernet network switch to the extent that it forwards frames at the data link layer. VMware ESX may contain multiple virtual switches, each providing more than 1,000 internal virtual ports for virtual machine use.

The virtual switch connects to the enterprise network through outbound Ethernet adapters. A maximum of eight Gigabit Ethernet ports or ten 10/100 Ethernet ports can be used by the virtual switch for external connectivity. The virtual switch is capable of binding multiple VMNICs together, in a manner much like NIC teaming on a traditional server, offering greater availability and bandwidth to the virtual machines using the virtual switch.

Virtual Ethernet Adapters

There are three types of adapters available for virtual machines in VMware infrastrucure 3:

  1. vmxnet is a paravirtualized device that works only if VMware Tools is installed on the Operating System. This adapter is optimized for virtual environments and designed for high performance.
  2. vlance emulates the AMD Lance PCNet32 Ethernet adapter. It is compatible with most 32-bit guest operating systems and can be used without VMware Tools.
  3. e1000 emulates the Intel E1000 Ethernet adapter and is used in either 64-bit or 32-bit virtual machines.

There are two other virtual adapters that are available through VMware technology. Vswif is a paravirtualized device similar to vmxnet that is used by the VMware ESX service console. Vmknic is a device in the VMkernal that is used by the TCP/IP stack to serve NFS and software iSCSI clients.

Virtual Switches

VMware technology includes virtual switches that you can build on demand at run-time to provide different functions, including:

  1. Layer 2 forwarding.
  2. VLAN tagging, stripping and filtering.
  3. Layer 2 security, checksum and segmentation offloading.

This modular approach reduces complexity and maximizes system performance, VMware virtualization technology loads only those components it needs to support the specific physical and virtual Ethernet adapter types used in the configuration. Additionally, the modular design enables VMware and third-party developers to incorporate new modules to enhance the system in the future. Up to 248 virtual switches can be created on each VMware ESX host. Following are important features of virtual switches:

  • Virtual ports: The ports on a virtual switch provide logical connection points among virtual devices and between virtual and physical devices. Each virtual switch can have up to 1,016 virtual ports, with a limit of 4,096 ports on all virtual switches on a host. The virtual ports provide a rich control channel for communication with the virtual Ethernet adapters attached to them.
  • Uplink ports: Uplink ports are associated with physical adapters, providing a connection between the virtual network and the physical networks. They connect to physical adapters when they are initialized by a device driver or when the teaming policies for virtual switches are reconfigured. Virtual Ethernet adapters connect to virtual ports when you power on the virtual machine, when you take an action to connect the device or when you migrate a virtual machine using VMware Vmotion. A virtual Ethernet adapter updates the virtual switch port with MAC filtering information when it is initialized or when it changes.
  • Port groups: Port groups make it possible to specify that a given virtual machine should have a particular type of connectivity on every host, and they contain enough configuration information to provide persistent and consistent network access for virtual Ethernet adapters. Some of the information contained in a port group includes virtual switch name, VLANIDs and policies for tagging and filtering, the teaming policy and traffic shaping parameters. This is all the information needed for a switch port.
  • Uplinks: With VMware technology, uplinks are the physical Ethernet adapters that serve as bridges between the virtual and physical network. The virtual ports connected to them are called uplink ports. A host may have up to 32 uplinks.

Other things to consider:

  • Virtual switches do not learn from the network to populate their forward tables. This helps to minimize denial of service attacks.
  • Virtual switches make private copies of frame data used to make forwarding or filtering decisions. This ensures the guest operating systems cannot access sensitive data once the frame is passed onto the virtual switch.
  • VMware technology ensures that frames are contained within the appropriate VLAN on a virtual switch 1) by carrying the data outside the frame as it passes through the virtual switch, and 2) because there is no dynamic trunking support that could open up isolation leaks, making the data vulnerable to attack.

Virtual Switches vs. Physical Switches

Virtual switches are similar to modern physical Ethernet switches in many ways. Like a physical switch, it maintains a MAC:port forward table and performs frame destination lookup and frame forwarding. It also supports VLAN segmentation at the port level, so that each port can be configured as an access or trunk port, providing access to either single or multiple VLANs.

However, unlike physical switches, virtual switches do not require a spanning tree protocol, because VMware Infrastructure 3 enforces a single-tier networking topology. There’s no way to interconnect multiple virtual switches. Also, network traffic cannot flow directly form one virtual switch to another within the same host. Virtual switches provide all the ports you need in one switch. You don’t need to cascade virtual switches or prevent bad virtual switch connections, and because they don’t share physical Ethernet adapters, leaks between switches do not occur. Each virtual switch is isolated and has its own forwarding table, so every destination the switch looks up can match only ports on the same virtual switch where the frame originated. This feature improves security, making it difficult for hackers to break virtual switch isolation.