In our initial PacketFence article in the April 2007 issue of LJ, we introduced the great network access control (NAC) solution that rivals the best ones on the market. On that occasion, we covered ARP-based isolation, which works relatively well for small networks.
Unfortunately, ARP-based isolation can't really scale to many thousands of nodes and is relatively easy to bypass with a simple static ARP table. Thus, we, at Inverse, decided to improve PacketFence by adding a VLAN-based isolation mode. This addition, combined with other enhancements, makes the solution suitable for large-scale networks.
The purpose of PacketFence's VLAN isolation is to assign any device connected to the network to an appropriate VLAN based on its MAC, registration and violation status. A simple scenario would be that every new device belongs to a registration VLAN, a registered and violation-free device belongs to a “normal” VLAN and a device with open violations belongs to an isolation VLAN. If the isolation and registration VLANs are not routed to the “normal” VLAN, PacketFence fully isolates the new device, and any device that violates network policy, from the regular network, efficiently preventing any attack or virus propagation. Of course, real networks are a bit more complicated, and VoIP phones may not end up in the same VLAN as regular computers or servers. But, whatever your network's VLAN design, PacketFence is up to the task.
In order for the VLAN isolation code to work properly, you must use manageable switches. In particular, the switches must provide a means to change a port's VLAN remotely and must be able to send SNMP (Simple Network Management Protocol) traps to PacketFence. SNMP traps include the switch's IP address; the port number and, depending on the trap type, could include the port status (for example, “up” when a device has been connected and “down” when disconnected); the MAC address of the device (mostly for MAC notification and security violation traps); the number of MACs connected to the switch port and so on.
When a switch sends an SNMP trap to PacketFence, the snmptrapd dæmon receives it and writes it to the log file /usr/local/pf/contrib/log/snmptrapd.log. PacketFence's setVlanOnTrapd dæmon continuously reads this log file and, for every new trap, determines whether it needs to change a port's VLAN. If this is the case, it sends the appropriate SNMP commands to the switch.
A crucial part of VLAN isolation is knowing when a device connects to or disconnects from the network. In early 2006, we started the development of the VLAN isolation code by supporting two very basic SNMP traps: linkup and linkdown traps. The vast majority of switch vendors support these two traps, which made our implementation immediately usable on a wide variety of networking hardware. Unfortunately, simply relying on linkup and linkdown traps has its downsides, from both a performance and a functional perspective, including:
Because a switch needs to see some network traffic on a port to determine the MAC address of the connecting device, linkup traps cannot include any MAC address. PacketFence's setVlanOnTrapd must, therefore, repeatedly query the switch after every linkup trap in order to determine the MAC address of the newly connected device, which introduces some overhead.
Most VoIP phones contain a built-in switch to connect a PC. The switch sends the linkup trap when you connect the phone; when you connect the PC to the phone, the switch won't send a second linkup trap. Therefore, in this deployment scenario, relying solely on linkup and linkdown traps does not provide enough information to setVlanOnTrapd to work correctly.
One possible solution to address these issues is MAC notification traps. Every time a switch learns a MAC address on a port, it sends a “MAC learned” trap that includes the MAC address. And, of course, PacketFence now also supports MAC notification traps.
In addition to assigning an appropriate VLAN to devices when they connect to the network, PacketFence also isolates devices already connected to the network when they violate the network policy. Two different options are available:
PacketFence can briefly disconnect a device from the network by administratively shutting down the switch port and re-opening it soon after. In this case, the switch sends a linkdown, followed by a linkup trap. When PacketFence receives the linkup trap, it determines that the device has an open violation and switches the port to the isolation VLAN. On the computer side, the network adapter notices that the network link went down and automatically renews its IP address—this time in the isolation VLAN. PacketFence's captive portal then informs the user that he or she has been isolated.
Administratively shutting down a switch port can be problematic when using VoIP phones, as doing so might end a call. If PacketFence has access to the isolation VLAN, you don't actually need to shut down the port. Changing the port's VLAN and doing some ARP spoofing generally are sufficient to make the captive portal available to the user.
So far, we've mentioned only the registration and isolation VLANs, but PacketFence uses a third VLAN, the MAC detection VLAN. This VLAN, which is the default one of every port, must not contain access to any DHCP server and could be seen as an “empty” VLAN. It exists to allow the switch to learn the MAC address of a newly connected device before it obtains an answer from a DHCP server.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open