PacketFence 1.7 offers client-free open-source NAC

Do you know who connects to your wired and wireless networks, when and where? Do you know who is using applications forbidden by your network usage policy, such as maybe LimeWire or Gnutella? With the ever increasing number of people accessing your network anonymously or generating illegal activities from it, having reliable security tools is now essential.

A well configured firewall and tools such as Snort and Nessus are important steps to secure your network, but you might be looking for a complementary solution that responds automatically to violations of your network usage policy. It’s time to deploy a Network Access Control (NAC) solution on your network.

Almost all switch vendors have their own proprietary NAC which, most of the time, works only with their own hardware. But what if you have a heterogeneous network, or want to customize the solution?

That’s where PacketFence comes in. PacketFence is the open source community’s answer to NAC.

PacketFence is written in Perl and makes use of common open source components such as MySQL and Apache. It does not require a user agent to be installed on computers accessing the network. Its deployment is non-intrusive, and every interaction with users goes through a captive portal which can be accessed by every web browser.

PacketFence provides an impressive list of features. Among them are:

• Registration of new network devices
• Detection of abnormal network activities (computer virus, worms, spyware, etc.) using alerts from Snort sensors
• Registration-based and scheduled Nessus scans
• Isolation of problematic devices

• Remediation through a captive portal

• VLAN isolation with VoIP support (even in heterogeneous environments) for multiple switch vendors such as Cisco, Edge-Core, HP, Linksys and Nortel

• Support for 802.1X through a FreeRADIUS module
• Wireless integration with FreeRADIUS
• DHCP fingerprinting

 Figure 1: the relations between PacketFence standard features.

PacketFence currently supports ARP, DHCP/DNS and VLAN isolation techniques. Choosing the right isolation method depends on the size of your network and the networking equipment you possess.

In this article, we’ll cover VLAN isolation.

What is VLAN isolation ?

The purpose of VLAN isolation is to assign any device connected to the network, an appropriate VLAN based on its MAC, its registration and violation status.

 Figure 2: How PacketFence reacts to SNMP traps

When a device connects to a switch port, the switch sends PacketFence an SNMP trap. This trap is received by the snmptrapd daemon and written to a log file. The pfsetvlan daemon tails this log file and upon reception of a trap, determines the appropriate VLAN for the MAC and then communicates with the switch (mostly using SNMP) to assign the switch port to the determined VLAN. In addition to assigning an appropriate VLAN to devices when they connect to the network, PacketFence can also isolate devices already connected to the network when they violate the network usage policy.

PacketFence can work with different SNMP trap types such as linkup/linkdown, MAC notification, and port security traps. If available on your switches, we highly encourage the usage of port security traps since it is a very efficient mechanism: PacketFence will only receive traps when equipment is newly connected to or moving on your network. The second best option is the combined usage of linkup/linkdown and MAC notification traps. The disadvantage is that PacketFence might receive a high number of traps at periodic intervals due to your switches expiring their learned MAC addresses at fixed intervals and spanning tree recalculations. If your switches only support linkup/linkdown traps, PacketFence can also work solely based on these traps. This implies that upon reception of a linkup trap PacketFence will have to query the switch for some time to determine the MAC address on the switch port (which might take some time).

Considerations before installing PacketFence

Are all your switches supported? In order for VLAN isolation to work, you must use manageable switches. In particular, the switches must provide a means to remotely determine and change a port’s VLAN and must be able to send Simple Network Management Protocol (SNMP) traps to PacketFence. SNMP traps include the switch IP address, the port number and, depending on the trap type, they could include the port status, the MAC address of the equipment, and so on. The complete list of currently supported network hardware is available at https://www.packetfence.org/dokuwiki/doku.php?id=config_1.7.0#other_switches.

PacketFence is also designed to ease the addition of support for new switches. All supported switches are represented through Perl objects with an extensive use of inheritance. Adding support for a new product comes down to extending the pf::SNMP class and can be done in a matter of hours !

Are you using hubs? PacketFence is currently designed to support one MAC address per managed switch port. PacketFence therefore can’t manage ports to which several computers are connected at the same time and these ports should be defined as ‘uplink’ in the switches.conf configuration file.

Can you span two new VLANs throughout your network? PacketFence uses two dedicated VLANs: a registration VLAN and an isolation VLAN. The easiest setup is when you can span these VLANs over your whole network and give the PacketFence server direct access to them. If this is not possible in your infrastructure, you’ll have to create the appropriate VLANs in your access switches and then route the traffic to PacketFence. If the isolation and registration VLANs are not routed to your regular VLANs, PacketFence fully isolates new equipment, and equipment which violates network policy, from the regular network. Consequently, it efficiently prevents illegal access, attacks and virus propagation.

What’s the correct VLAN for a given MAC address? PacketFence assigns the switch ports VLAN based on the MAC address connected to the port. By default, PacketFence uses a very simple scenario: when the MAC has open violations in the database, it is assigned to the violation VLAN; when the MAC is not registered, it is assigned to the registration VLAN; otherwise, it is assigned to the VLAN specified in the vlan column of its database entry. This simple setup implies that you can assign, during registration, a specific VLAN to each MAC and that this VLAN is available on all switches the MAC might connect to.

Of course, real networks are a bit more complicated, and PacketFence has been successfully deployed in more complicated setups where computers are assigned to different company departments and the department VLANs change from one building (or switch) to another. For example you might want to distinguish computers in the customer support department from computers in human ressources and your customer support department is spread out over several branch offices with different VLANs!

How can you relate IPs to MAC addresses? When a computers connects to PacketFences captive portal, PacketFence must show the correct message based on its MAC. The IP to MAC resolution is easy if the PacketFence server can send ARP queries (i.e. has direct access to the isolation and registration VLANs). If your isolation and registration VLANs are routed, this is not possible any more and PacketFence must find another way to obtain this information. Most of the time, this is done through a copy of the DHCP traffic of your network. PacketFence includes a DHCP listener daemon which records the MAC-IP associations to its database … and which, at the same time, is used to OS fingerprint the devices. Using these fingerprints, it even becomes possible to automatically register some devices, such as printers, while denying access to some others, such as game consoles.

The copy of the DHCP traffic is also very important when you use an IDS such as Snort. The Snort alerts sent to PacketFence contain the IP of the offending device, not its MAC address. PacketFence, on the other hand, saves the violations for a given MAC, so again, PacketFence must be able to relate the IP to a MAC address.

PacketFence installation walkthrough

Here are the instructions to install PacketFence on CentOS 5 (depending on your linux distribution, there may be some differences)

• Install MySQL and start it.

• Disable SELinux.

• Configure your package manager to use Dag Wieers repository (https://dag.wieers.com/rpm/).

• Download the PacketFence package for CentOS5 from https://www.packetfence.org and install it with Yum (Yum will satisfy all dependencies for you)

• Install the IPTables::IPv4 perl module using CPAN:

  perl -MCPAN -e 'install IPTables::IPv4
  

• Set the timezone in /etc/php.ini. For example:

  date.timezone="America/Montreal"
  

• Execute the PacketFence installer /usr/local/pf/installer.pl and follow the instructions.

• Execute the PacketFence configurator /usr/local/pf/configurator.pl and follow the instructions

• It is recommended that you create your own SSL certificate to replace the example certificate in /usr/local/pf/conf/ssl.

VLAN isolation setup and initial testings

Configuring VLAN isolation requires a certain amount of changes and tests:

Create the registration and isolation VLANs on your network. Span these VLANs throughout your network or make sure their traffic is correctly routed to the PacketFence server. Make sure, also, that these VLANs are not routed to any other regular VLANs on your network. Now, configure the PacketFence server NICs so that PacketFence will be able to answer HTTP requests in both of these VLANs. Test that any device in the registration/isolation VLAN can communicate with PF through its registration/isolation VLAN IP and that it cannot communicate with any device in any other VLAN.

Configure a DHCP and DNS server to take care of the requests in the registration and isolation VLANs. The DNS server must resolve all requests to PacketFences IP address. Now, configure a switch port first in the registration VLAN, then the isolation VLAN, and test that a machine connected to that switch port obtains an appropriate IP address using DHCP in both VLANs and that all DNS requests return PacketFences IP.

**Update the PacketFence configuration files, located in /usr/local/pf/conf

switches.conf must contain the read/write SNMP communities of your switches, the database connection parameters, the list of VLANs and of all switches managed by PacketFence. For example a Cisco Catalyst 2960 switch could be defined as follows:

[192.168.1.101]
    ip = 192.168.1.101
    type = Cisco::Catalyst_2960
    mode = production
    uplink = 10025

Execute the supplied test/connect_and_read.pl script to make sure that PacketFence can correctly communicate with the switches you have defined.

The previously executed configurator.pl script already took care of configuring most sections of the pf.conf file. Review this file and add the necessary interface sections for all your NIC. Here’s an example for an isolation interface

[interface eth0.3]
    mask=255.255.255.0
    type=internal,isolation
    gateway=192.168.3.1
    ip=192.168.3.1

PacketFence replaces upon startup all regular iptables rules with its own rules. If you want to open specific ports on your PacketFence server, you’ll have to add them to the iptables.pre file. For example to open UDP port 162 (SNMP traps), add the following lines in to iptables.pre:

*filter
    :INPUT ACCEPT [0:0]
    -A INPUT -p udp -m udp --dport 162 -i eth0 -j ACCEPT
    COMMIT

Now, start the packetfence service and make sure you don’t receive any warnings or error messages.

As the last step, configure your switches to send the appropriate SNMP traps to PacketFence. Plug a device into a configured switch port and tail the files /usr/local/pf/logs/snmptrapd.log and /usr/local/pf/logs/pfsetvlan.log. You should see the reception of the trap and the action pfsetvlan takes to flip the ports VLAN.

Adapting PacketFence to your needs

VLAN assignment: During registration, by default, PacketFence puts the normalVlan configuration setting (defined in switches.conf) in the nodes database entry. You can change this behavior by modifying the following lines in /usr/local/pf/cgi-bin/register.cgi

#determine default VLAN if VLAN isolation is enabled
    #and the vlan has not been set yet 
    if (isenabled($Config{'network'}{'vlan'})) {
      if (! defined($info{'vlan'})) {
        my %ConfigVlan;
        tie %ConfigVlan, 'Config::IniFiles', (-file => '/usr/local/pf/conf/switches.conf');
        $info{'vlan'}=$ConfigVlan{'default'}{'normalVlan'};                    
      }
    }

As we already mentioned, the pfsetvlan daemon assigns by default a MAC to the VLAN which is saved in its database entry. This can be adjusted by modifying the custom_getCorrectVlan function in /usr/local/pf/conf/pfsetvlan.pm

sub custom_getCorrectVlan {
      my ($switch_ip, $ifIndex, $mac, $status, $vlan, $pid) = @_;
      #$switch_ip is the ip of the switch the computer is connected to
      #$ifIndex is the ifIndex of the port the computer is connected to
      #$mac is the MAC connected
      #$status is the node's status in the database
      #$vlan is the vlan set for this node in the database
      #$pid is the owner of this node in the database
      my $logger = Log::Log4perl->get_logger();
      Log::Log4perl::MDC->put('tid', threads->self->tid());
      return $vlan;
    }

Note that the function already receives several parameters (such as the switch and the owner of the computer) which allows you to return the VLAN in a way that matches exactly your needs !

Registration pages: Since version 1.7 of PacketFence, the registration pages use Template Toolkit (https://template-toolkit.org/) and gettext (https://www.gnu.org/software/gettext/) for internationalization. The template files are located in /usr/local/pf/html/user/content/templates with the translations being saved in /usr/local/pf/conf/locale. The main registration template is /usr/local/pf/html/user/content/templates/register.html and you can freely edit the HTML code in it. If you want to customize it beyond the HTML template, you’ll need to look into the /usr/local/pf/lib/pf/web.pm Perl module.

Violations and isolation: Another very important customization is to define what you actually consider a violation of your network usage policy and how PacketFence should react upon detection of such a violation. All violations are defined in /usr/local/pf/conf/violations.conf. The origin of a given violation is defined with the trigger parameter. PacketFence currently supports three different violation origins:

* internally defined violations: These violations are detected by mechanisms internal to PacketFence, such as, for example, violations based on the DHCP (OS) fingerprint or a node. The keyword for fingerprint violations is OS and it is followed by the fingerprint ID (defined in `/usr/local/pf/conf/dhcp_fingerprints.conf`).  For example to define a violation for all fingerprints in class 16 (which contains OS/2 Warp and BeOS), use

    trigger=OS::16

to define a violation for Windows 95, use

trigger=OS::104

* Snort alerts: These violations are based on alerts PacketFence receives from one or several Snort sensors. The keyword for these violations is `Detect` and it is followed by the Snort violation ID. For example, to define a violation for Gnutella, use

    trigger=Detect::2001664,Detect::2002760,Detect::2002761

* Nessus scans: These violations are based on Nessus scan results. The keyword in this case is `Scan` and is followed by the Nessus Scan ID. It is very important to note that for each violation, you control the action PacketFence takes through the `action` parameter. Depending how severe you judge a given violation, you can for example only send an email to an administrator or immediately flip the computers VLAN to the isolation VLAN. You can also specify if the user can regain network access by itself (and how many times) by using the `max_enable` parameter. The remediation page shown to the user during the isolation is specified through the `url` parameter. In its default configuration, PacketFence uses PHP templates located in `/usr/local/pf/html/user/content/violations/`

Conclusion

As you can see, PacketFence is a very powerful NAC solution. Being an open source application, it can be easily configured and extended to perfectly fit your network design and security needs. Last but not least, PacketFence supports the usage of VoIP phones and has 802.1X support both on wired and wireless networks. Using PacketFence, you can efficiently secure both your wired and wireless networks, your way.