Authenticated access ensures that a user has to provide credentials to get access to the corporate LAN. But that doesn't guarantee that the user's computer will behave well on the network once it is there. It doesn't ensure that the computer is not hideously compromised, owned by some botnet or riddled with malware.
So, authentication controls are supplemented in some places by fuller-featured health checks, usually referred to as network access control (NAC). NAC systems go beyond verifying that users or machines are known, to signing off on the system's initial good health. NAC checks, among other things, to be sure that there is an antivirus program running, that the system has passed a scan and that its operating system has been brought up to date. The more current systems incorporate ongoing behavioral analysis, which watches what a system does once on the Net and takes remedial action if it goes astray.
LAN edge switch security functions and NAC
Defense-in-depth requires that networking teams use edge switches as part of the security infrastructure. ACLs, VLANs and authentication form the base of edge security; NAC sits atop this base to further mitigate risks. It is usually driven by intelligence in the data center or network core, such as policies defined and propagated from a central management point or directories of users that are allowed to use the network.
However, some vendors, such as ConSentry, Napera and Fortinet, put all the intelligence as well as the enforcement in edge devices, making deployment in theory simpler, especially in smaller networks. But NAC requires at least the participation of edge switches if it is really going to protect the network. Authentication for edge access is the first and most important hurdle that systems must clear in most NAC installations. Beyond that, failure to pass tests requires use of edge device VLANs or port-disablement as controls on "bad" systems.
Whether NAC is edge-driven or simply edge-enforced, initial health checks require a tamper-resistant agent on the endpoint that can verify that some software is running (e.g., an antivirus) and other software is not (e.g., various kinds of spyware). In the Windows world, several NAC solutions use Microsoft's Network Access Protection client for health checks. Others supply their own agent.
Implementing health checks at the LAN edge
The specifics of implementing health checks vary dramatically from system to system (more than ACLs or even authentication configurations). In spirit, they resemble ACLs:
Vlan-hosts fail antivirus-check isolate
Vlan-guests fail antivirus-check allow remediate-vlan
Wlan fail OS-check allow remediate-vlan
Adding health checks can bring down the incidence of compromised machines being used on the LAN. ACLs and VLANs can protect edge devices from one another and can limit the range of attacks possible against data center targets, but they can't see that more subtle attacks are under way. Adding behavioral analysis can make even subtle attacks visible if they entail doing anything over the network that a user wouldn't normally do.
So, on networks with significant numbers of transient users (as in a company making extensive use of contractors, or in a university) or where IT control of desktops is minimal, NAC may be an excellent precaution. NAC will be most useful on wireless LANs and other segments with temporary users or lots of laptops that leave the LAN regularly. In a smaller organization with a more static user population, it is nearly always overkill. Before undertaking a NAC deployment involving added gear, all organizations should exploit whatever edge switch security they have available; and if they are Windows users, they should look at NAP.
Tuesday, May 18, 2010
Configuring LAN edge switches for network access authentication
Edge switches are an important part of in-depth network defense, essential to protecting edge nodes from each other and able to decrease the low-end workload on security devices deeper in the network so they can focus on higher-level threats.
Of all the unused security features lying dormant on intelligent edge switches in LAN data closets, perhaps the single most important one for improving LAN security is authenticated network access.
In the data center, IT has complete control over who can plug something into the network and who can have physical access to a device on the network. Outside the data center, that's not the case. In the LAN, that's where authenticated network access comes in. It ensures that users provide credentials at the switch in order to talk to anything beyond on the network.
How switch-based network access authentication works
The IEEE 802.1X standard governs the authenticated access, and both wired and wireless networks can require 802.1X authentication before providing access. The standard defines traffic among three entities: the supplicant, the authenticator, and the authentication server.
The supplicant is the computer (or other device) trying to connect through the authenticator -- the switch or access point. They communicate using the Extensible Access Protocol (EAP). The switch or access point uses the Remote Authentication Dial-In User Service (RADIUS) protocol to send credentials to the authentication server (AS), which checks them and sends back either a success or a failure, accepting or denying the supplicant.
Choosing the right RADIUS servers and readying them for 802.1X and EAP
For authenticated network access to work, the network needs a RADIUS server that supports EAP. Enabling the Network Policy Server on a Windows server (Internet Authentication Service, prior to Windows 2008) provides the service in a Windows domain. Lots of other RADIUS servers are available from network vendors, including Alcatel-Lucent, Cisco and Juniper. Freeware is also available. The key to long-term manageability is making sure your RADIUS service is connected to your domain authentication service (be it Active Directory, Lightweight Directory Access Protocol, or something else) and that it doesn't maintain a separate set of credentials.
To make the RADIUS server 802.1X-ready, an admin must set up a key and get a digital certificate. (This may have been done in support of some other security appliance, such as a VPN concentrator.) Any OpenSSL client or Windows IIS server can request a certificate with the right attributes in place. The most secure systems use EAP-TTLS or PEAP, which require certificates on client machines too, but this is optional. This is not required with EAP-TTLS.
Also, supplicants must support EAP and gracefully handle the transition from the un-trusted state (black hole VLAN and address) to the trusted state (usable IP address and VLAN). Some older desktop operating systems did not do well with this, but even Windows XP (post service pack 1) is sufficient.
Enabling LAN switch security
The next step is to enable security on the switches. Methods vary by switch vendor but should look something like this (with actual IP addresses substituted):
radius server host 192.168.001.001 key RadiusServersEncryptionKey
aaa authentication dot1x default radius
dot1x system-auth-control
interface Ethernet g2-g48 dot1x port-control auto
That is:
interface Ethernet g2-g48 dot1x port-control auto unauth-vlan 13
Specifying network access authentication for specified user groups
The choice of whether to require network authentication, and what to do with unauthenticated access attempts, has to be driven by careful consideration of user populations and can be sanctioned for specific user groups or scenarios. An organization may want to grant mobile, temporary Internet access without credentials to user populations such as consultants or professional services staff while not wanting to grant data center access. That same organization might want to require authentication for any access by a user plugging into a regular office's network jack on the assumption that only company staff should be using those for access.
Of all the unused security features lying dormant on intelligent edge switches in LAN data closets, perhaps the single most important one for improving LAN security is authenticated network access.
In the data center, IT has complete control over who can plug something into the network and who can have physical access to a device on the network. Outside the data center, that's not the case. In the LAN, that's where authenticated network access comes in. It ensures that users provide credentials at the switch in order to talk to anything beyond on the network.
How switch-based network access authentication works
The IEEE 802.1X standard governs the authenticated access, and both wired and wireless networks can require 802.1X authentication before providing access. The standard defines traffic among three entities: the supplicant, the authenticator, and the authentication server.
The supplicant is the computer (or other device) trying to connect through the authenticator -- the switch or access point. They communicate using the Extensible Access Protocol (EAP). The switch or access point uses the Remote Authentication Dial-In User Service (RADIUS) protocol to send credentials to the authentication server (AS), which checks them and sends back either a success or a failure, accepting or denying the supplicant.
Choosing the right RADIUS servers and readying them for 802.1X and EAP
For authenticated network access to work, the network needs a RADIUS server that supports EAP. Enabling the Network Policy Server on a Windows server (Internet Authentication Service, prior to Windows 2008) provides the service in a Windows domain. Lots of other RADIUS servers are available from network vendors, including Alcatel-Lucent, Cisco and Juniper. Freeware is also available. The key to long-term manageability is making sure your RADIUS service is connected to your domain authentication service (be it Active Directory, Lightweight Directory Access Protocol, or something else) and that it doesn't maintain a separate set of credentials.
To make the RADIUS server 802.1X-ready, an admin must set up a key and get a digital certificate. (This may have been done in support of some other security appliance, such as a VPN concentrator.) Any OpenSSL client or Windows IIS server can request a certificate with the right attributes in place. The most secure systems use EAP-TTLS or PEAP, which require certificates on client machines too, but this is optional. This is not required with EAP-TTLS.
Also, supplicants must support EAP and gracefully handle the transition from the un-trusted state (black hole VLAN and address) to the trusted state (usable IP address and VLAN). Some older desktop operating systems did not do well with this, but even Windows XP (post service pack 1) is sufficient.
Enabling LAN switch security
The next step is to enable security on the switches. Methods vary by switch vendor but should look something like this (with actual IP addresses substituted):
radius server host 192.168.001.001 key RadiusServersEncryptionKey
aaa authentication dot1x default radius
dot1x system-auth-control
interface Ethernet g2-g48 dot1x port-control auto
That is:
- Tell the switch what RADIUS server to talk to.
- Tell it to use RADIUS authentication with 802.1X.
- Tell it to turn on 802.1X.
- Tell it to require 802.1X on ports g2 through g48.
interface Ethernet g2-g48 dot1x port-control auto unauth-vlan 13
Specifying network access authentication for specified user groups
The choice of whether to require network authentication, and what to do with unauthenticated access attempts, has to be driven by careful consideration of user populations and can be sanctioned for specific user groups or scenarios. An organization may want to grant mobile, temporary Internet access without credentials to user populations such as consultants or professional services staff while not wanting to grant data center access. That same organization might want to require authentication for any access by a user plugging into a regular office's network jack on the assumption that only company staff should be using those for access.
LAN edge switch security functions: Switch ACLs; filtering port traffic
Organizations large and small spend a lot of money buying intelligent edge switches that can do a lot more than provide base connectivity, but then they use these switches for little more than the basics. Among the functions often overlooked are LAN edge switch security features, including port-level security and switch-level access control lists (ACLs).
LAN edge switch ACLs can be an important part of in-depth defense. Just like ACLs on routers and firewalls, switch-level ACLs can filter traffic, permitting or denying access through the port. But pushing that function to the edge spreads the work out, potentially decreasing the number of rules required in other locations and the amount of traffic processed there, thus improving performance. Also, LAN edge switch ACLs can do something ACLs elsewhere can't: help protect edge devices from one another.
How LAN edge switch ACLs work
ACLs work in a straightforward way: They can be used to identify an action, which kind of traffic will be affected (the object of the action), and the sources and destinations involved.
Note the melding of information from layers 2 (MAC address), 3 (IP address) and 4 (TCP/UDP ports) in ACLs. This ability to pay attention to and act on multiple layers of traffic is part of what makes intelligent switches intelligent.
ACLs are processed sequentially: Traffic is compared to each rule in turn, from top to bottom, until it hits a rule that applies to it, and then that action is taken.So, for example, to make ports on a switch useful only as thin clients running against a Citrix XenApp/XenDesktop farm, one might apply an ACL similar to this (assuming the data center net is on 192.168.100.000, mask 000.000.000.255):
Ports 1494 and 2598 are the primary ports used by ICA, Citrix's thin client protocol. Traffic bound to the data center from any IP node attached to the switch, or from the data center to any node attached to the switch, and traveling across the specified TCP ports will be permitted to pass through the switch to the edge ports or to the uplink port.
Intelligent edge switch security features: Supporting VLANs; port management
ACLs are not the only intelligent edge switch security feature. Any smart switch supports VLANs. Where ACLs are great for managing access to specific addresses or applications, VLANs are a more robust way of handling groupings of ports and controlling traffic among these groups. Also, many other security settings are available (varying by vendor and line) to perform such functions as controlling broadcast storms and limiting the MAC addresses a port will talk to.
Suppose, for example, that in your offices there is no business reason for PCs (or Macs) to talk directly to one another because, for instance, services are all provided out of the data center. To help prevent rapid spread of viruses from machine to machine, you might configure the edge switches to prevent ports from talking to one another. There are several ways to do so:
Managing ACLs manually (like the rest of the security settings on your switches) is easy enough if you have only a few switches. The more you have, the more important it becomes to maintain a standard "golden" configuration and use automated configuration tools to maintain and audit configuration.
LAN edge switch ACLs can be an important part of in-depth defense. Just like ACLs on routers and firewalls, switch-level ACLs can filter traffic, permitting or denying access through the port. But pushing that function to the edge spreads the work out, potentially decreasing the number of rules required in other locations and the amount of traffic processed there, thus improving performance. Also, LAN edge switch ACLs can do something ACLs elsewhere can't: help protect edge devices from one another.
How LAN edge switch ACLs work
ACLs work in a straightforward way: They can be used to identify an action, which kind of traffic will be affected (the object of the action), and the sources and destinations involved.
- Action: Options are usually limited to forwarding packets ("permit"), or blocking them from passing ("deny").
- Object: If a switch has ACLs, it usually has at least three possibilities: all IP traffic, all TCP traffic, and all UDP traffic. Many switches offer per-port filtering for TCP and UDP as well, so that you can, for example, permit SSL traffic but block NFS.
- Source and destination: These can always be specified with IP addresses, or ranges of IP addresses (as with an address base and mask). You may also be able to use MAC addresses and the EtherType data.
Note the melding of information from layers 2 (MAC address), 3 (IP address) and 4 (TCP/UDP ports) in ACLs. This ability to pay attention to and act on multiple layers of traffic is part of what makes intelligent switches intelligent.
ACLs are processed sequentially: Traffic is compared to each rule in turn, from top to bottom, until it hits a rule that applies to it, and then that action is taken.So, for example, to make ports on a switch useful only as thin clients running against a Citrix XenApp/XenDesktop farm, one might apply an ACL similar to this (assuming the data center net is on 192.168.100.000, mask 000.000.000.255):
- Permit TCP any 192.168.100.000 000.000.000.255 port 1494
- Permit TCP 192.168.100.000 000.000.000.255 any port 2598
- Permit TCP any 192.168.100.000 000.000.000.255 port 1494
- Permit TCP 192.168.100.000 000.000.000.255 any port 2598
- Deny any any
Ports 1494 and 2598 are the primary ports used by ICA, Citrix's thin client protocol. Traffic bound to the data center from any IP node attached to the switch, or from the data center to any node attached to the switch, and traveling across the specified TCP ports will be permitted to pass through the switch to the edge ports or to the uplink port.
Intelligent edge switch security features: Supporting VLANs; port management
ACLs are not the only intelligent edge switch security feature. Any smart switch supports VLANs. Where ACLs are great for managing access to specific addresses or applications, VLANs are a more robust way of handling groupings of ports and controlling traffic among these groups. Also, many other security settings are available (varying by vendor and line) to perform such functions as controlling broadcast storms and limiting the MAC addresses a port will talk to.
Suppose, for example, that in your offices there is no business reason for PCs (or Macs) to talk directly to one another because, for instance, services are all provided out of the data center. To help prevent rapid spread of viruses from machine to machine, you might configure the edge switches to prevent ports from talking to one another. There are several ways to do so:
- You can manage it with ACLs:
- Permit IP Any 192.168.100.000 000.000.000.255
- Permit IP 192.168.100.000 000.000.000.255 Any
- Deny IP Any 192.168.000.000 000.000.255.255
- Deny IP 192.168.000.000 000.000.255.255 Any
- Permit IP Any any
- You can manage it with VLANs by putting every port on a unique VLAN and not propagating VLANs off the switch.
- You can also manage it with other settings, such as making all the edge ports on a Cisco switch "protected" or using the "port-isolation" function on HP ProCurve switches.
Managing ACLs manually (like the rest of the security settings on your switches) is easy enough if you have only a few switches. The more you have, the more important it becomes to maintain a standard "golden" configuration and use automated configuration tools to maintain and audit configuration.
Wednesday, May 12, 2010
Cisco Nexus 1000v Virtual Network Switch - The Eyes Returns 8-)
Today I want to talk a little bit about the importance of knowing what's going on in the virtual network environment. Nowadays it is a common practice for companies to move to a virtual server environment after realizing the real advantages of doing so. I don't want to talk about the advantages of a virtual environment, since in my opinion, pretty much everyone interested on this topic will already understand its importance, from an economic and environmental perspective; but I would like to talk about the virtual network environment in which this virtual servers infrastructure relies.
Traditionally, network groups have managed the physical network connection of a server from the switch all the way to the NIC. Virtualization changes that by extending the network into the server, snatching control out of the network administrator's hands. This poses a host of new problems that include a lack of visibility within the server and a lack of manageability of virtual network switches.
Virtual network switches effectively extend the physical network from the NIC in a VMware ESX host to a virtual switch that is managed by the ESX server, as well as a virtual NIC that connects a virtual machine (VM) to the virtual switch. This virtual switch is usually managed by virtualization administrators and not network administrators, which can cause some concern and friction between the two groups because the network admins can no longer control and manage part of the network that is inside a virtual host.
The role of virtual network switches.
Virtual switches are the core networking component on an ESX and ESXi host. A virtual switch is built and contained in the RAM of a host and connects the physical NICs (referred to as uplinks) in the host server to the virtual NICs in virtual machines. Virtual switches (vSwitches) emulate many of the traits of traditional Ethernet switches and can perform many of the same functions, such as forwarding frames at the data link layer and VLAN segmentation, and they also support copying packets to a mirror port for use with a sniffer or IDS system. In VMware VI3, there was only one type of vSwitch; in vSphere, there are now three different types that you can use: the standard vSwitch, the new distributed vSwitch, and third-party vSwitches (Cisco Nexus 1000v). With the exception of the Nexus 1000v, you can have multiple vSwitches configured on a single host, but a single physical NIC can only be assigned to a single vSwitch.
Challenges of virtual networking:Blind spots and lack of control
One of the challenges with vSwitches is that much of the traffic between VMs on the same host never leaves the host, so it does not go over the physical network. As a result, it cannot be monitored or managed by the network devices on the physical network, such as IDS/IPS systems. To summarize, this occurs when VMs are connected to the same vSwitch and the same port group on that vSwitch. What happens is that all network traffic between those VMs stays within the host's memory subsystem as both the vNICs and vSwitch are contained in a host's memory. This can be desirable from a performance standpoint, as transferring data in a host's memory is much faster than sending it over the network. But it is not desirable from a network standpoint because the data cannot be seen by the physical network and, consequently, by network firewalls, QoS, ACLs and IDS/IPS systems that are designed to protect servers at the network layer.
Another challenge with virtual switches is that both the standard and distributed vSwitch do not have many features and are basically dumb, unmanaged switches. As a result, there is very little control over what happens on a vSwitch and no integration between vSwitches and physical switches.
One last challenge with virtual switches is with adding devices to the network. Most network admins like to control what is plugged into their network. Admins will typically disable ports that are not in use and set port security on all ports so that if a different NIC is plugged in, they are alerted to it and the port is disabled. With a vSwitch, they lose this control as they only have control of the uplink ports from the physical NICs in the host and not the many virtual machine ports that exist on a vSwitch.
New tools address virtual networking management
These challenges all lead to reduced visibility and control of network traffic, which results in a less secure environment, incomplete network traffic analysis and unhappy network admins. One way to address this is to use network management products that are designed to work in virtual environments.
These typically allow you to secure, monitor and control all the virtual networking traffic on a host. These products typically deploy as virtual appliances on a host and either sit inline between VMs in a protected vSwitch or use the new VMsafe technologies in vSphere, which can protect VMs without being inline. Some examples of these types of products include Reflex System's Virtual Management Center, Altor Networks Virtual Firewall, and Catbird's vSecurity. Another important product among this family, is the Cisco Nexus 1000v virtual network switch, which gives network administrators visibility and control of virtual networking and the one we will be reviewing on this post.
Cisco Nexus 1000v virtual network switch: Virtual network management
While virtualization networking management tools are helpful for monitoring, securing and managing virtual networks, they don't give control of the virtual network back to network administrators. One solution to this problem lies in implementing the Cisco Nexus 1000v distributed virtual switch (vSwitch).
The Cisco Nexus 1000v distributed virtual switch shifts virtual network management inside a virtual host back to network administrators and helps to make peace between server and network teams. In addition to solving the political problem of administration, it also adds many advanced features and better security to virtualization networking inside a host. The Nexus 1000v provides features not found in the VMware-provided vSwitches, including QoS, support for Switch Port Analyzer (SPAN), Encapsulated Remote SPAN (ERSPAN), NetFlow, RADIUS and TACACS, access control lists, packet capture/analysis, DHCP/IGMPv3 snooping and much more.
How the Nexus 1000v distributed virtual switch works
The Cisco Nexus 1000v distributed virtual switch consists of two components: a Virtual Supervisor Module (VSM) and a Virtual Ethernet Module (VEM). The VSM manages one or more VEMs as one logical switch and supports up to 64 VEMs. All the configuration of the VEMs is done using the VSM with the NX-OS command line interface, which is pushed to all the VEMs.
The VSM uses port profiles that are configured for each VEM and then appear as port groups in the vCenter Server. The VSM is integrated with the vCenter Server so all network configuration involving the VEMs is synchronized between them. The VSM is packaged as a virtual appliance and is deployed on an ESX or ESXi host using the vSphere Client. Once deployed and powered on, the VSM is managed using a command line interface (my favorite ;)). The VEM is installed on each ESX and ESXi host, and only one VEM can exist on a single host. The VEM executes as part of the VMKernel and uses an API to interface with the vCenter Server and virtual machines. The VEM gets all of its configuration information from the VSMs, and if it loses connectivity to the VSM, it will continue to switch traffic based on the last known configuration.
The Cisco Nexus 1000v distributed virtual switch can be used with any physical switch, regardless of the manufacturer. This allows anyone who uses non-Cisco physical network gear to take advantage of the 1000v to handle virtual network management.
Preparing the network team for virtual network management
The Cisco Nexus 1000v distributed virtual switch hands virtual network management back to network administrators so they once again have total control of the entire network environment. It ends the feud between server administrators and network administrators that often occurs when deploying virtualization. However, just giving control of the virtual network back to network administrators is often not enough. Many network administrators are accustomed to dealing only with the physical world, and virtualization may be new to them. They are commonly leery of virtualization and put up resistance. Educating everyone involved in the virtualization project is the best way to combat this problem.Educational steps for network administrators include:
Traditionally, network groups have managed the physical network connection of a server from the switch all the way to the NIC. Virtualization changes that by extending the network into the server, snatching control out of the network administrator's hands. This poses a host of new problems that include a lack of visibility within the server and a lack of manageability of virtual network switches.
Virtual network switches effectively extend the physical network from the NIC in a VMware ESX host to a virtual switch that is managed by the ESX server, as well as a virtual NIC that connects a virtual machine (VM) to the virtual switch. This virtual switch is usually managed by virtualization administrators and not network administrators, which can cause some concern and friction between the two groups because the network admins can no longer control and manage part of the network that is inside a virtual host.
The role of virtual network switches.
Virtual switches are the core networking component on an ESX and ESXi host. A virtual switch is built and contained in the RAM of a host and connects the physical NICs (referred to as uplinks) in the host server to the virtual NICs in virtual machines. Virtual switches (vSwitches) emulate many of the traits of traditional Ethernet switches and can perform many of the same functions, such as forwarding frames at the data link layer and VLAN segmentation, and they also support copying packets to a mirror port for use with a sniffer or IDS system. In VMware VI3, there was only one type of vSwitch; in vSphere, there are now three different types that you can use: the standard vSwitch, the new distributed vSwitch, and third-party vSwitches (Cisco Nexus 1000v). With the exception of the Nexus 1000v, you can have multiple vSwitches configured on a single host, but a single physical NIC can only be assigned to a single vSwitch.
Challenges of virtual networking:Blind spots and lack of control
One of the challenges with vSwitches is that much of the traffic between VMs on the same host never leaves the host, so it does not go over the physical network. As a result, it cannot be monitored or managed by the network devices on the physical network, such as IDS/IPS systems. To summarize, this occurs when VMs are connected to the same vSwitch and the same port group on that vSwitch. What happens is that all network traffic between those VMs stays within the host's memory subsystem as both the vNICs and vSwitch are contained in a host's memory. This can be desirable from a performance standpoint, as transferring data in a host's memory is much faster than sending it over the network. But it is not desirable from a network standpoint because the data cannot be seen by the physical network and, consequently, by network firewalls, QoS, ACLs and IDS/IPS systems that are designed to protect servers at the network layer.
Another challenge with virtual switches is that both the standard and distributed vSwitch do not have many features and are basically dumb, unmanaged switches. As a result, there is very little control over what happens on a vSwitch and no integration between vSwitches and physical switches.
One last challenge with virtual switches is with adding devices to the network. Most network admins like to control what is plugged into their network. Admins will typically disable ports that are not in use and set port security on all ports so that if a different NIC is plugged in, they are alerted to it and the port is disabled. With a vSwitch, they lose this control as they only have control of the uplink ports from the physical NICs in the host and not the many virtual machine ports that exist on a vSwitch.
New tools address virtual networking management
These challenges all lead to reduced visibility and control of network traffic, which results in a less secure environment, incomplete network traffic analysis and unhappy network admins. One way to address this is to use network management products that are designed to work in virtual environments.
These typically allow you to secure, monitor and control all the virtual networking traffic on a host. These products typically deploy as virtual appliances on a host and either sit inline between VMs in a protected vSwitch or use the new VMsafe technologies in vSphere, which can protect VMs without being inline. Some examples of these types of products include Reflex System's Virtual Management Center, Altor Networks Virtual Firewall, and Catbird's vSecurity. Another important product among this family, is the Cisco Nexus 1000v virtual network switch, which gives network administrators visibility and control of virtual networking and the one we will be reviewing on this post.
Cisco Nexus 1000v virtual network switch: Virtual network management
While virtualization networking management tools are helpful for monitoring, securing and managing virtual networks, they don't give control of the virtual network back to network administrators. One solution to this problem lies in implementing the Cisco Nexus 1000v distributed virtual switch (vSwitch).
The Cisco Nexus 1000v distributed virtual switch shifts virtual network management inside a virtual host back to network administrators and helps to make peace between server and network teams. In addition to solving the political problem of administration, it also adds many advanced features and better security to virtualization networking inside a host. The Nexus 1000v provides features not found in the VMware-provided vSwitches, including QoS, support for Switch Port Analyzer (SPAN), Encapsulated Remote SPAN (ERSPAN), NetFlow, RADIUS and TACACS, access control lists, packet capture/analysis, DHCP/IGMPv3 snooping and much more.
How the Nexus 1000v distributed virtual switch works
The Cisco Nexus 1000v distributed virtual switch consists of two components: a Virtual Supervisor Module (VSM) and a Virtual Ethernet Module (VEM). The VSM manages one or more VEMs as one logical switch and supports up to 64 VEMs. All the configuration of the VEMs is done using the VSM with the NX-OS command line interface, which is pushed to all the VEMs.
The VSM uses port profiles that are configured for each VEM and then appear as port groups in the vCenter Server. The VSM is integrated with the vCenter Server so all network configuration involving the VEMs is synchronized between them. The VSM is packaged as a virtual appliance and is deployed on an ESX or ESXi host using the vSphere Client. Once deployed and powered on, the VSM is managed using a command line interface (my favorite ;)). The VEM is installed on each ESX and ESXi host, and only one VEM can exist on a single host. The VEM executes as part of the VMKernel and uses an API to interface with the vCenter Server and virtual machines. The VEM gets all of its configuration information from the VSMs, and if it loses connectivity to the VSM, it will continue to switch traffic based on the last known configuration.
The Cisco Nexus 1000v distributed virtual switch can be used with any physical switch, regardless of the manufacturer. This allows anyone who uses non-Cisco physical network gear to take advantage of the 1000v to handle virtual network management.
Preparing the network team for virtual network management
The Cisco Nexus 1000v distributed virtual switch hands virtual network management back to network administrators so they once again have total control of the entire network environment. It ends the feud between server administrators and network administrators that often occurs when deploying virtualization. However, just giving control of the virtual network back to network administrators is often not enough. Many network administrators are accustomed to dealing only with the physical world, and virtualization may be new to them. They are commonly leery of virtualization and put up resistance. Educating everyone involved in the virtualization project is the best way to combat this problem.Educational steps for network administrators include:
- Explaining the concept of virtual switches and virtual NICs and how they interact with physical switches and physical NICs.
- Demonstrating setup and configuration of a virtual switch, how to install a virtual NIC in a VM, and how to connect the virtual NIC to a virtual switch.
- Explaining how ESX uses trunked network ports and how 802.1Q VLAN tagging works in a virtual networking environment.
- Explaining virtual network security principles and how virtual switches are isolated from one another so traffic can't leak between them.
- Demonstrating NIC teaming and failover in a virtual switch.
Friday, May 7, 2010
gwping2 - A Python Script for Dual WAN Redundancy and Load Balancing in Linux
Sometime ago I was faced with the task of finding the way to make a Linux box, use two different WAN connections to two different Internet Service Providers (ISP), in this case Telus and Shaw, in some special way. The challenge was to do a sort of load balancing while both link were up and running, by having some services as http, https, smtp on one of the links and the VoIP system, running through the second WAN link. Then, any time one of this links went down, the services should be automatically moved from the broken link to the link still running, for keeping the company services online. In this case there was no server involved behind the Linux box acting as a firewall, but only clients connecting to the Internet and their Phones, connecting to the VoIP server located at the company headquarters, through a VPN Tunnel.
This was the network layout I was working with for this task. I believe this will help you understand every step from now on.
So I started by browsing on the Internet, for some one that had previously done something similar to this and after some days of investigation, I found the right idea that would allow me to develop the final python script. Click here to see the post with the original idea.
The main idea behind the post, was very simple. It used the Linux ping application, to monitor the availability of each gateway, given that the ping application for Linux , allows you to send the ping with any source IP address you want. By using this feature of the ping application for Linux and the ip rules suite for Linux, it was possible to develop something as simple and at the same time useful as this script named gwping.
To me, this script was not enough, given the specifics of the project, but I felt the idea behind was correct, so I started working on my own version of the script that I decided to name gwping2. The gwping script was developed using bash, but for my version I decided to go with python, which is one of my favorite and, in my opinion, the most powerful programming language today and the one I know the most, and also because Python is installed by default in every Linux installations, just as Bash is.
So I started by recreating the network infrastructure in the Lab and the fun begun. The requirements were the followings:
As you can see there are a few section in this file that, at first sight, don't relate directly to the nature of the script; for example: the iptables, dhcp and openvpn sections. The reason why the iptables section was included, was because the Linux box acting as a firewall, is running iptables to protect the internal network, and for changing the services from one link to another, several changes has to be made in the iptables rule set to allow the services to run smoothly on what ever link they were moved to. You will see this later when we get to the gwping2 script. A similar reason provoked the addition of a dhcp section. The main problem with de DHCP was due to the fact that, the conections to the ISPs used, were residential class connections to save some money. This means that, every time one of the link goes down , you will probably end up with a different IP address assigned to the interface, once it comes back, because the IP address for residential services, are assigned by using the ISP dhcp service. The openvpn section was included because the VoIP system is running over a VPN connection to the headquarters and every time one of the links goes down, the openvpn connection has to be reestablished using the available link, to allow the phones to reconnect to to the VoIP server.
Now it is time for the main dish: the gwping2.py python script that will tight all this together. Keep in mind that for python the indenting is critical, if you decide to copy and paste this script. I would like to suggest you use notepad++ or any other Advanced Text Editor to make any modification to the gwping2 script.Click here to download the gwping2.py script.
You would want to place the gwping.conf file under /etc on your Linux box. This is the only file you will need to change to make any modifications to the setup explained in here. As you can see , you only need a few general details to make this work, for example:
testip=192.5.5.241 --> This will be ip you will use to test the links. It needs to be a host that is always responsive and in this case , we are using a DNS Root Server IP Address.
teleworker=X.X.X.X --> This is the ip of the VoIP server to which the phones of the clients connect.
You will need to setup the variables listed under the [network] section to match you particular environment. The same applies to the [email] and [iptables] section. Everything else should be OK.
After modifying gwping.conf to you particular environment, you would like to place gwping2.py under /usr/sbin/ , so you can execute this script anytime once it is in the system's path.
This is pretty much it, with regard to the installation of the software. Now it will take care of the routing on your Linux box, as well as the modification of the iptables rules anytime a link goes down or up, according to the requirements above. It will also take care of the opnvpn tunnels restarting processes, every time it notices a link state change on any of the links. This little script will also alert you any time a link state change takes place, by sending an email to the specified email address, by using the smtp relay server also specified.
I hope some of you find this helpful and, at the same time, save some time by not having to program all this on your own. Please let me know if you run into some problems when trying to use my script, by posting your thoughts below. Feel free to modify anything you need on any of the files provided.
This was the network layout I was working with for this task. I believe this will help you understand every step from now on.
So I started by browsing on the Internet, for some one that had previously done something similar to this and after some days of investigation, I found the right idea that would allow me to develop the final python script. Click here to see the post with the original idea.
The main idea behind the post, was very simple. It used the Linux ping application, to monitor the availability of each gateway, given that the ping application for Linux , allows you to send the ping with any source IP address you want. By using this feature of the ping application for Linux and the ip rules suite for Linux, it was possible to develop something as simple and at the same time useful as this script named gwping.
To me, this script was not enough, given the specifics of the project, but I felt the idea behind was correct, so I started working on my own version of the script that I decided to name gwping2. The gwping script was developed using bash, but for my version I decided to go with python, which is one of my favorite and, in my opinion, the most powerful programming language today and the one I know the most, and also because Python is installed by default in every Linux installations, just as Bash is.
So I started by recreating the network infrastructure in the Lab and the fun begun. The requirements were the followings:
- Dual WAN Connection to the Internet through two different providers on the Linux Box.
- Whiles both links were up, the Internet services will be running on the TELUS (ISP1) link and the VoIP services on the SHAW (ISP2) link.
- If the TELUS link went down, all the services will be automatically moved to the SHAW link to keep the company services online.
- If the connection to TELUS was reestablished, all the internet services will be automatically moved back to the TELUS link, keeping the VoIP services running over the SHAW Link.
- If the SHAW link went down, the VoIP services will be automatically moved to the TELUS link to keep the company services online.
- If the connection to SHAW was reestablished , the internet services will be moved to the SHAW link and the VoIP services will be kept running over the TELUS link. Then after 8 p.m. everything would be reset back to its normal operation state. This difference in the approach when the SHAW link goes down and then UP is because , every time the VoIP service is moved it caused all the phones to reconnect to the VoIP server causing 1-3 minutes of phones downtime.
As you can see there are a few section in this file that, at first sight, don't relate directly to the nature of the script; for example: the iptables, dhcp and openvpn sections. The reason why the iptables section was included, was because the Linux box acting as a firewall, is running iptables to protect the internal network, and for changing the services from one link to another, several changes has to be made in the iptables rule set to allow the services to run smoothly on what ever link they were moved to. You will see this later when we get to the gwping2 script. A similar reason provoked the addition of a dhcp section. The main problem with de DHCP was due to the fact that, the conections to the ISPs used, were residential class connections to save some money. This means that, every time one of the link goes down , you will probably end up with a different IP address assigned to the interface, once it comes back, because the IP address for residential services, are assigned by using the ISP dhcp service. The openvpn section was included because the VoIP system is running over a VPN connection to the headquarters and every time one of the links goes down, the openvpn connection has to be reestablished using the available link, to allow the phones to reconnect to to the VoIP server.
Now it is time for the main dish: the gwping2.py python script that will tight all this together. Keep in mind that for python the indenting is critical, if you decide to copy and paste this script. I would like to suggest you use notepad++ or any other Advanced Text Editor to make any modification to the gwping2 script.Click here to download the gwping2.py script.
You would want to place the gwping.conf file under /etc on your Linux box. This is the only file you will need to change to make any modifications to the setup explained in here. As you can see , you only need a few general details to make this work, for example:
testip=192.5.5.241 --> This will be ip you will use to test the links. It needs to be a host that is always responsive and in this case , we are using a DNS Root Server IP Address.
teleworker=X.X.X.X --> This is the ip of the VoIP server to which the phones of the clients connect.
You will need to setup the variables listed under the [network] section to match you particular environment. The same applies to the [email] and [iptables] section. Everything else should be OK.
After modifying gwping.conf to you particular environment, you would like to place gwping2.py under /usr/sbin/ , so you can execute this script anytime once it is in the system's path.
This is pretty much it, with regard to the installation of the software. Now it will take care of the routing on your Linux box, as well as the modification of the iptables rules anytime a link goes down or up, according to the requirements above. It will also take care of the opnvpn tunnels restarting processes, every time it notices a link state change on any of the links. This little script will also alert you any time a link state change takes place, by sending an email to the specified email address, by using the smtp relay server also specified.
I hope some of you find this helpful and, at the same time, save some time by not having to program all this on your own. Please let me know if you run into some problems when trying to use my script, by posting your thoughts below. Feel free to modify anything you need on any of the files provided.
Thursday, May 6, 2010
ipt_netflow-1.6 - Netflow Based Monitoring Solution for Linux and iptables
After several days of investigation for the right solution for the network monitoring needs of my small company, I found a very powerful tool that helped me solve the problem and today I want to share it with you. Its name is ipt_netflow and it is an iptables module that can be used to understand what's going on in your network.
The company was needing "Eyes" on the network infrastructure, mainly on its firewalls to see what was going trough them and to understand the flow of the information inside of the corporate structure. Because it is a small company , we are using open source software everywhere including iptables for the firewalls and it made sense, then, to use open source software for the monitoring solution as well.
I have created an installation guide for ipt_netflow-1.6 under CentOS 5.4 that I would like to share with those interested on this subject and here it goes...Next post will be covering the same installation under Ubuntu 9.10.
First we will need to make sure our system complies with some basic packages needed to compile the ipt_netflow module.
Under CentOS 5.4 , and as root, install:
yum install iptables-devel.i386
yum install gcc.i386
yum install kernel-devel.i686
yum install kernel.i686
yum install gcc gcc-c++ kernel-devel
Then download ipt_netflow from:
http://sourceforge.net/projects/ipt-netflow/files/ipt-netflow/1.6/ipt_netflow-1.6.tgz/download
or execute the following command on your Linux box:
wget http://downloads.sourceforge.net/project/ipt-netflow/ipt-netflow/1.6/ipt_netflow-1.6.tgz
Unpack ipt_netflow-1.6.tgz:
tar -xzvf ipt_netflow-1.6.tgz
Move into the ipt_netflow folder :
cd ipt_netflow-1.6.tgz
Because CentOS normally goes a little behind with its package selection we need to edit one of the files provided within the ipt_netflow-1.6.tgz for this to work under CentOS 5.4. So let's edit the libipt_NETFLOW.c file:
vi libipt_NETFLOW.c
Search for "void _init(void)" and Replace the line:
void _init(void)
For the following line:
void __attribute((constructor)) my_init(void)
After this, save changes and exit.
Now we are ready to compile the module so execute:
./configure
and if it returns no errors then execute:
make all install; depmod
If the compilation returns no errors then the installation is done and now you need to load the module and setup the corresponding iptables rules.
First copy the ipt_NETFLOW.ko (wherever it was placed on your system) into the kernel modules folder (if the right kernel was installed it should be there already and this step is not needed):
cp /lib/modules/2.6.18-164.11.1.el5.centos.plus/extra/ipt_NETFLOW.ko /lib/modules/2.6.18-164.11.1.el5/extra/
Second load the module using modprobe:
modprobe ipt_NETFLOW destination=netflowserverip:port
Third add rules to the iptables at the top of the list:
iptables -A INPUT -j NETFLOW
iptables -A OUTPUT -j NETFLOW
iptables -A FORWARD -j NETFLOW
Now you only need to restart iptables for the flows to start being exported to your netflow server. In my case I'm using ManageEngine Netflow Analizer Free Edition which allows me to monitor a maximum of to interfaces for free. I strongly recommend you use the same application for this purpose since it is unbelievably good.
Before finishing the setup we need to tune up a little bit the ipt_netflow module. For this I like to set up the active_timeout to 10 because it is 1800 by default and this cause a delay in the flow reporting. To do this execute:
sysctl -w net.netflow.active_timeout=10
or if you want to make this permanent you would like to edit the /etc/sysctl.conf file and add this line to it:
net.netflow.active_timeout=10
It is also a good idea to load the ipt_netflow module automatically every time you restart your Linux box, for this you need to add the following line to the /etc/rc.local file:
modprobe ipt_NETFLOW destination=netflowserverip:port
and, of course, change the "netflowserverip:port" for the corresponding Server IP Address and Port.
You can take a look at some of the stats by issuing the following command in your Linux box:
cat /proc/net/stat/ipt_netflow
and you can also use tcpdump to check if the flows are being exported properly.
You will also need to add an extra rule to you iptables rule set, that allows the flows to get out of the Linux box and go to the Netflow Server. Something like the following line, but of course, changing the Interface, IP and Port shown, for the ones corresponding with your infrastructure:
iptables -A OUTPUT -o eth0 -p udp -d 192.168.0.70 --dport 9996 -j ACCEPT
Please let me know if you run into some problem while following this guide. I will be more than pleased to help any of you out there.
Enjoy.
P.D. - There is also an RPM for this but I couldn't make it work properly (http://centos.alt.ru/?p=306). Please let me know if anyone have made this work.
Here you are a couple of interesting links regarding ipt_netflow-1.6 module:
http://centos.alt.ru/?s=ipt_netflow
The company was needing "Eyes" on the network infrastructure, mainly on its firewalls to see what was going trough them and to understand the flow of the information inside of the corporate structure. Because it is a small company , we are using open source software everywhere including iptables for the firewalls and it made sense, then, to use open source software for the monitoring solution as well.
I have created an installation guide for ipt_netflow-1.6 under CentOS 5.4 that I would like to share with those interested on this subject and here it goes...Next post will be covering the same installation under Ubuntu 9.10.
First we will need to make sure our system complies with some basic packages needed to compile the ipt_netflow module.
Under CentOS 5.4 , and as root, install:
yum install iptables-devel.i386
yum install gcc.i386
yum install kernel-devel.i686
yum install kernel.i686
yum install gcc gcc-c++ kernel-devel
Then download ipt_netflow from:
http://sourceforge.net/projects/ipt-netflow/files/ipt-netflow/1.6/ipt_netflow-1.6.tgz/download
or execute the following command on your Linux box:
wget http://downloads.sourceforge.net/project/ipt-netflow/ipt-netflow/1.6/ipt_netflow-1.6.tgz
Unpack ipt_netflow-1.6.tgz:
tar -xzvf ipt_netflow-1.6.tgz
Move into the ipt_netflow folder :
cd ipt_netflow-1.6.tgz
Because CentOS normally goes a little behind with its package selection we need to edit one of the files provided within the ipt_netflow-1.6.tgz for this to work under CentOS 5.4. So let's edit the libipt_NETFLOW.c file:
vi libipt_NETFLOW.c
Search for "void _init(void)" and Replace the line:
void _init(void)
For the following line:
void __attribute((constructor)) my_init(void)
After this, save changes and exit.
Now we are ready to compile the module so execute:
./configure
and if it returns no errors then execute:
make all install; depmod
If the compilation returns no errors then the installation is done and now you need to load the module and setup the corresponding iptables rules.
First copy the ipt_NETFLOW.ko (wherever it was placed on your system) into the kernel modules folder (if the right kernel was installed it should be there already and this step is not needed):
cp /lib/modules/2.6.18-164.11.1.el5.centos.plus/extra/ipt_NETFLOW.ko /lib/modules/2.6.18-164.11.1.el5/extra/
Second load the module using modprobe:
modprobe ipt_NETFLOW destination=netflowserverip:port
Third add rules to the iptables at the top of the list:
iptables -A INPUT -j NETFLOW
iptables -A OUTPUT -j NETFLOW
iptables -A FORWARD -j NETFLOW
Now you only need to restart iptables for the flows to start being exported to your netflow server. In my case I'm using ManageEngine Netflow Analizer Free Edition which allows me to monitor a maximum of to interfaces for free. I strongly recommend you use the same application for this purpose since it is unbelievably good.
Before finishing the setup we need to tune up a little bit the ipt_netflow module. For this I like to set up the active_timeout to 10 because it is 1800 by default and this cause a delay in the flow reporting. To do this execute:
sysctl -w net.netflow.active_timeout=10
or if you want to make this permanent you would like to edit the /etc/sysctl.conf file and add this line to it:
net.netflow.active_timeout=10
It is also a good idea to load the ipt_netflow module automatically every time you restart your Linux box, for this you need to add the following line to the /etc/rc.local file:
modprobe ipt_NETFLOW destination=netflowserverip:port
and, of course, change the "netflowserverip:port" for the corresponding Server IP Address and Port.
You can take a look at some of the stats by issuing the following command in your Linux box:
cat /proc/net/stat/ipt_netflow
and you can also use tcpdump to check if the flows are being exported properly.
You will also need to add an extra rule to you iptables rule set, that allows the flows to get out of the Linux box and go to the Netflow Server. Something like the following line, but of course, changing the Interface, IP and Port shown, for the ones corresponding with your infrastructure:
iptables -A OUTPUT -o eth0 -p udp -d 192.168.0.70 --dport 9996 -j ACCEPT
Please let me know if you run into some problem while following this guide. I will be more than pleased to help any of you out there.
Enjoy.
P.D. - There is also an RPM for this but I couldn't make it work properly (http://centos.alt.ru/?p=306). Please let me know if anyone have made this work.
Here you are a couple of interesting links regarding ipt_netflow-1.6 module:
http://centos.alt.ru/?s=ipt_netflow
Subscribe to:
Posts (Atom)