You can take it a step further by adding Snort alerts to your PacketFence installation. Let's assume that using BitTorrent clients is prohibited in your environment and you want to configure PacketFence to enforce this policy. Edit /usr/local/pf/conf/violations.conf so that the section containing BitTorrent reads as follows:
 desc=P2P (BitTorrent) priority=8 url=/content/index.php?template=p2p disable=N max_enable=1 actions=trap,email,log trigger=Detect::2000334,Detect::2000357, ↪Detect::2000369
This tells PacketFence that:
The BitTorrent violation can be generated by the Snort alerts 2000334, 2000357 and 2000369 (the trigger parameter).
The system has to act upon this violation by isolating the user, sending an e-mail alert to the administrator and logging the violation to /var/log/messages (the actions parameter).
The user is allowed to re-enable network access once (the max_enable parameter).
Finally, you need to activate Snort from inside PacketFence by incorporating the following into conf/pf.conf:
[trapping] detection=enabled [interface eth0] type=internal, managed,monitor
and restarting the PacketFence service. Note that if you are using switches, you have to redirect a copy of your network traffic to eth0 (the PacketFence monitor—that is, the interface Snort listens to for packets).
Generating a violation in PacketFence is now as simple as launching your favorite BitTorrent client, such as Azureus. Do so, and open a torrent file to start a download. Once a couple of packets are exchanged on the network, Snort should catch some and match them with the 2000334, 2000357 or 2000369 rules. Those rules, which come from the Bleeding Edge Threats rulesets, correspond to BitTorrent peer sync, traffic and announce, respectively. Once Snort logs such unusual activity, PacketFence reacts by creating a violation.
As an administrator, you can see the list of violations with:
/usr/local/pf/bin/pfcmd violation view all
As a user, on your computer, launch your favorite Web browser and try to open any outside Web site. You'll be redirected to the PacketFence system automatically, which will display the peer-to-peer template, as shown in Figure 2.
Stopping the BitTorrent client lets you regain network access. Now, try to use BitTorrent a second time. As before, an alert is generated, and your browser is redirected to the PacketFence portal. But this time, however, you won't get another chance to re-enable your access. In real life, offending users would have to call their network administrator to re-enable network access.
To activate the Nessus scanning of hosts trying to register with PacketFence, add the following section to /usr/local/pf/conf/pf.conf:
[scan] ssl=enabled pass=<nessus_passwd> user=<nessus_user> port=1241 host=127.0.0.1 registration=enabled
and restart the PacketFence service. Trying to add a computer running an unpatched version of Microsoft Windows now generates an immediate violation. You also can use the administrative Web GUI (the Scan tab) to define that complete Nessus scans should be executed every night.
Deploying PacketFence in your network with ARP-based isolation is simple. Although this isolation technique is easy to deploy, it doesn't necessarily scale well and could be bypassed by wise users with static ARP-cache entries.
Other isolation techniques exist in PacketFence, such as DHCP/DNS, which scales well. At Inverse, we also added VLAN-based isolation to PacketFence, which makes this solution more secure and appealing for large networks. PacketFence is an ideal solution for securing campus networks or even a part of your network (a VLAN or subnet). Finally, a high-quality NAC solution has emerged from the FOSS community, and the evolution of PacketFence is promising.
Ludovic Marcotte (email@example.com) holds a Bachelor's degree in Computer Science from the University of Montréal. He is currently a senior systems architect for Inverse, Inc., an IT consulting company located in downtown Montréal that specializes in the deployment of infrastructures based on free and open-source components.
Dominik Gehl (firstname.lastname@example.org) holds a Master's degree in Computer Science from the University of Montréal. He is currently a systems architect for Inverse, Inc., an IT consulting company located in downtown Montréal that specializes in the deployment of infrastructures based on free and open-source components.
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!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- SourceClear Open