PacketFence Coming Soon!

In my last post, I voiced my discontent with Zeroshell as my security appliance solution for testing with my lab. My hat is off to Zeroshell developers, because it would make a great SOHO device if it were more stable, but I have been itching to give Linux based PacketFence a test drive for over a year now.

Last Saturday (8/31/13) I ordered a Supermicro server from ebay with dual Intel Xeons, 8GB RAM, and a 500GB HDD for about $200 (not bad) to use as a NAC appliance via PacketFence. 

 

From my understanding PacketFence has NAC, RADIUS, Captive Portal, DHCP, DNS, and many more capabilities. I will attempt to deploy PacketFence in VLAN mode first, which means the device is not inline and instead is out-of-band but still actively managing network access. VLAN mode does require compatible layer 2 hardware (switches, APs, etc.). Essentially PacketFence can filter network access requests by moving suspicious clients to a quarantined VLAN or SSID. 

My only other consideration to take before my PacketFence server arrives is how I will configure the server. PacketFence can be deployed by either installing and configuring CentOS or RHEL (Red Hat Enterprise Linux) first, then installing the PacketFence application, or you can use the preconfigured zero touch LIVE USB install. I'm not sure of which is more advantageous versus the other, but off the bat, configuring CentOS would be good experience. I have played with CentOS before and even configured it to support a DNS server using BIND9. Either way, I hope to deploy PacketFence in my lab atleast by next week!

After PacketFence, I plan to upgrade my wireless network (nothing too amazing) and will probably end my lab purchases for the year. After that, everything will be study and labs with existing equipment.

AAA Security and Zeroshell Appliance

In the interim before my CCNP studies, I am still picking up some security training. My latest project has been experimenting with AAA(Triple-A). As some may or may not know, AAA stands for Authentication, Authorization, & Accounting. AAA is how administrators of large networks secure access and privileges of IT infrastructure (network equipment, servers, appliances, etc.) and keep record of access in layman's terms. 

Authentication - Secure user access usually base on TACACS+ or RADIUS server database
Authorization - Level of privileges based on secured user or group login ID.
Accounting - Record or log of user or group access as well as changes made.

I decided to start from scratch and completely wipe all of my network configuration and essentially rebuild my network. When starting, I had three goals in mind:

(1. Set up RADIUS Server to store user database and accounting log.
(2. Configure all Cisco equipment login to check against RADIUS server database.
(3. Set up Captive Portal using same RADIUS server and database to protect WLAN access.

To set up my RADIUS server, I downloaded and installed the latest Zeroshell image. Zeroshell is an all around Linux security appliance distribution with a very small footprint and very low hardware requirements. As a matter of fact, the device I set Zeroshell up on is my in-law's old computer which is an old HP Pavilion a1424n with a Pentium 4, 1GB of RAM, and no HDD. The OS basically runs off of an 8GB flash drive. I installed two add-on NICs which made for three NICs if you include the onboard. Please make note, I (you) only need two NICs minimum(one for the LAN and the other for WAN). 



Due to hardware limitations, the Zeroshell appliance is an inline device. In case you do not know, inline essentially means that traffic has to flow through the Zeroshell appliance before it gets out to the LAN (in a bridge like configuration). Personally, I don't care much for inline appliances. They are very archaic in design, they don't scale well at all in larger networks, and if they don't have fail-to-wire capability (meaning if the appliance fails, traffic can still be passed through a virtual wire created by the internal and external interface) they essentially can bring down whatever segment of your network that they are designed to serve. Below is my topology:

 

As you can see, for my home wireless network, Zeroshell sits bridged between my Vyatta internet router and my wireless bridge (Linksys EA2700). 

In order to get access to anything on the wireless network, outside the wireless network, or the internet, traffic must be authenticated by the Zeroshell captive portal for which I have created a user/password database on Zeroshell.

 



  

As you can see, the captive portal isn't the most aesthetically pleasing and customization is limited unless you know HTML (not since college, for me). Clients are pretty much contained unless they can authenticate at this Captive Portal. You pretty much can't even print to a printer on the same network. The main reason I wanted this feature was to thwart would be free-loaders from accessing my wireless even though it is protected (WPA2/PSK) and to limit access time for my little sisters who spend a little too much time on the internet. 

The captive portal has all kinds of customizable features as far as access is concerned including setting access times, exceptions, the ability to de-authenticate, and set re-direct pages from an administrative perspective. 

After authenticating, traffic is free to traverse the network. Zeroshell acts as a router and passes traffic from the bridged LAN interface (supporting the wireless) to be routed over the WAN interface to all other networks. This is where RADIUS comes in for my network.

Whenever I access any of my Cisco equipment, I have configured all equipment to check logins against a RADIUS server database as opposed to the default practice of using the local user database which a good hacker could easily break. Below is a simple diagram of how the RADIUS server works.





Essentially, when a client attempts to open an SSH or Telnet session with any of my Cisco equipment, let's say a router; that router, requests login credentials as normal. After those credentials are supplied, instead of checking the local database, the router contacts the RADIUS server and checks the RADIUS server user database. If the the supplied credentials are a match to credentials in the RADIUS database, the router opens the session with the appropriate authorization level. If not, after so many retries, it disconnects the session UNLESS you have a fall-back sequence as I do. 

I configured a fall-back sequence in case the RADIUS server is inaccessible for any reason so that my router will fail-over to the local database. This is best when setting up RADIUS because one false move can easily lock you out of your equipment. Below is an abridged configuration of RADIUS from one of my router. 
 
aaa new-model

aaa authentication banner ^C

Authenticating session with local RADIUS server...

aaa authentication password-prompt Secret:
aaa authentication username-prompt Identification:
aaa authentication login TRIPLE-A-LIST group radius local enable
aaa authentication login FALLBACK local enable none

radius-server host 192.168.3.1 auth-port 1812 acct-port 1813 key <I removed my encrypted key for security purposes>

 line con 0
 logging synchronous
 login authentication FALLBACK
line aux 0
line vty 0 4
 password <removed for security purposes>
 logging synchronous
 login authentication TRIPLE-A-LIST
 transport input telnet ssh
line vty 5 15
 password <removed for security purposes>
 logging synchronous
 login authentication TRIPLE-A-LIST
 transport input telnet ssh
!

 Configuring RADIUS is simple when you understand the steps:

1. Enable AAA authentication (aaa new-model)
2. Set an AAA banner (optional)
3. Set  prompts (aaa authentication login username-prompt, etc.) (optional)
4. Tell the router to check RADIUS for authentication (TRIPLE-A-LIST) and configure   fallback sequence (local, enable)
5. Configure sequence for Console (FALLBACK, local, enable, none)
6. Configure vty and console ports (similar to ACL) for authentication sequence
7. Tell the router where the RADIUS server is and what ports to use
1. NOTE: Zeroshell uses UDP 1812 (authentication) and 1813 (accounting) by default
2. NOTE: Original default ports were UDP 1645 and 1646. Cisco and some other vendors still use these for backwards compatibility but they have changed to 1812 and 1813 in recent years. 

Why is the console port not AS secure?

One individual that really helps me to make common sense out of networking is Jeremy Cioara. From watching the CBT Nuggets CCNA Security videos, I understand the the Console port is more of an emergency access port after initial use. It should not be locked down so tightly that you can't access it later, because in the event of emergency, it could be your last hope to access a router or switch and having to do a password reset because you can't access the console port would waste a TREMENDOUS amount of time. 

Also, to throw in my two cents, intruders can attack vty ports from a lot of different remote directions. But console ports must be attacked physically, meaning the intruder must have physical access to your equipment. Though these attacks happen, they are more rare than remote attacks. If an intruder gets to your console port, most likely, your problem is physical security which is a whole new animal. I digress.
 
RADIUS looks like this when logging into a Cisco router:







All of the banners were my own aesthetic touches including the "Authenticating session with local RADIUS server..." bit. It makes the login look more serious. 

Why use RADIUS?
 
Because RADIUS secures logins and also records them which are invaluable tools in an enterprise setting. RADIUS is mainly useful, in my opinion, if you have multiple administrators who are accessing terminal consoles of sensitive equipment. 

RADIUS vs TACACS+

My understanding is that TACACS+ is a propriety Cisco protocol. TACACS+ is much more granular than RADIUS, but it's granularity is much easier to configure if that makes sense. RADIUS can be simple, but for more complex accounting and privilege functions can require some serious configuration overhead. 

TACACS+ can easily manage logins as well as login privileges in a Cisco environment. To shorten an already long story, use TACACS+ for granular AAA deployments and purely Cisco networks. Cisco has devices for these in the form of a software and hardware Cisco ACS (Access Control Server) appliance. Use RADIUS for simpler AAA deployments and more vendor agnostic networks.

My Review of Zeroshell

PROS

• Easy to configure and deploy (An hour or less)
• Simple user interface
• Extremely small footprint and low hardware requirements
• Multiple features
• Captive Portal
• RADIUS and other AAA Functions
• Router (Static only)
• DNS and DHCP server
• Firewall
• 802.1x Support
• Net Balancer
• QoS
• VPN

CONS

• Not an extremely advanced appliance (simplicity has it's drawbacks)
• Lack of design and implementation options
• Customization is highly lacking or not readily apparent for a Linux appliance
• Dependability is questionable
• Captive Portal service has failed numerous times allowing unauthorized access (myself) with no exceptions in place
• HTTP redirect service has failed causing disruption of internet browsing
• RADIUS service has experienced several failures, relating to the actual Linux daemon (when it is running, it works well)

My conclusion about Zeroshell is that I will probably be migrating to a more proven, flexible appliance for my security needs (IPS, Captive Portal, RADIUS, etc) in the coming weeks; Packetfence!  Zeroshell is good when it works, but I wouldn't dare launch this in an enterprise environment and even question it in a SOHO network.

Conclusion

In conclusion, my security studies are progressing along well. I have been learning plenty of ways to secure my network equipment while avoiding rendering it useless. One of the most important lessons I'm learning right now about security is that administrators and engineers are challenged to find a balance between effective security and usability that does not hinder the end-users that the network serves.