Today I’m evaluating ZeroShell 1.0 beta 12. This is a linux based firewall that will run from a CD, compact flash, hard disk and I’m testing it as a virtual machine running on VMWare. The console give us only minimal access to the system, most of the configuration is done from the web interface. Note: You can click on any of the screenshots to open a new window with a full size screenshot.
The console allows:
- <A> Activate Profile
- <D> Deactivate profile
- <S> Shell prompt
- <R> Reboot
- <H> sHutdown
- <B> create a Bridge
- <W> Wifi manager
- <P> change admin Password
- <T> show routing Table
- <F> show Firewall rules
- <N> show Network interface
- <Z> fail-safe mode
- <I> Ip manager
After setting up some basic configuration options from the console, we use the web interface for everything else. I examined the console options, and the <B> create a Bridge option basically said, use this only if the web interface doesn’t work for you. Much like other commercial firewalls such as SonicWall, ZeroShell is designed to be configured through a web interface. The difference is that this one is Linux based, Licensed under GPLv2 and free for download.
Although I couldn’t locate any documentation on the Profiles tab, I did walk through the configuration screen. It appears to me that what this allows is different configurations on the same firewall. for different purposes, and only one configuration can be active at any one time.
The Network tab of course, lets us configure network options. ZeroShell has more network options than I think I’ve seen in any other firewall distribution. Not only can we configure a static or dynamic gateway, but we can configure Lan-to-Lan VPNs, PPPoE for DSL and Cable connections, 3G Modem for cellular modems. It’s possible to create VLANs on interfaces, once they are set up. Zero Shell has basically two operating modes, either transparent bridge mode or router mode. It can be configured to do Quality of Service and Traffic Shaping. Also available are LAN-to-LAN OpenVPN Virtual Private Networks, using either X.509 or pre-shared key authentication.
Setting up ZeroShell to act as a gateway to the internet isn’t as transparent as I would expect. It isn’t obvious that, once we have our internet interface configured that we need to create a bridge interface to move data between the LAN interface and WAN interface. I found excellent documentation on LinuxPlanet for configuring ZeroShell as an Internet Gateway.
The Time tab pops up a new window and allows us to configure the current time, the time zone that the firewall will operate in. whether it will act as a client or server and the time servers it should sync with.
The https tab pops up a configuration dialog that will allow us to restrict where we can connect to the firewall web interface. We can choose one or all interfaces (I would only use the LAN) one host or an entire network, and we can configure X.509 authentication using either the local Certificate Authority or a certificate imported from another Certificate Authority.
The SSH pop up let’s us enable and set IP addresses or subnets from where SSH access can be allowed. So far I don’t see any reason to allow this, so I probably would leave the default setting, which is disabled.
The Startup/Cron tab exposes a pop-up that gives a lot of options to customize the firewall with scripts. There are pre-configured options for Captive Portal Authentication, Captive Portal Gateway, Firewall Chain, NAT and Virtual Servers, Post Boot, Pre Boot, QoS, Test and Wireless. There are is little information, but I presume it’s the bash shell that executes the scripts. There is a test script but it doesn’t contain the typical bangpath #! that most shell scripts have. A tour through the filesystem from the console didn’t shed any light on the topic. There is also a GUI interface to cron , where we can schedule repetitive jobs.
The logging setup screen contains options for remote logging. We can allow logging from remote systems, log compression and log export. I can’t think of any other log options we would need on a firewall. I would probably set the firewall to log to a remote logging server. In that way if the firewall were compromised, I would have logs somewhere else to examine forensically.
The Utilities page has tabs for IP Check which consists of ARP Check, Ping, Tracepath, and a DNS Lookup tab. All are there to support network troubleshooting using a web interface. Over time, as this distribution matures, I expect other tools might get added. There’s both an up and down sides to adding more sophisticated tools. They can give the administrator more to use, but some network tools have a history of being used as attack vectors and compromise.
The Users page allows the administrator to List, View Add, Edit, Delete users. We can also manage users’ X509 certificates and Kerberos 5 authentication through this page.
There’s only one group “nobody” so unless we want our users to all be members of that group, we need to create the group first. For testing purposes I created the group users with the GID of 500. Then I created user bclown, a.k.a. Bozo Clown. The system automatically created an X509 certificate for bclown as shown in the logs:
These services are disabled by default in the web interface view. However, I went to the console and got a shell and did some digging. LDAP is in fact running on the system. However, slapd is configured to only allow access through the loopback interface. So I presume that enabling ldap in the web interface will allow access from other systems.
This isn’t something I would use on a firewall that’s connected to the internet. Everything I know about ldap tells me it’s not secure and shouldn’t be run on an unprotected network. I prefer the least number of services running on my firewall, since there are fewer to track and I believe it reduces chances something will be compromised, leading to compromise of my firewall. There is essentially no built-in security, for ldap. Maybe if it were only a departmental firewall, I might consider enabling it.
The ZeroShell firewall can be the Radius server, or we can configure the firewall to proxy for a Radius server on one of our networks. Again, keeping with my philosophy of least services on the firewall, I would use the proxy configuration if I wanted to use Radius authentication for my wireless access points.
When we click on the Access Points we are presented with a screen where we can configure individual access points. Our options are Access Point Name, IP or Subnet and Shared Secret. When I configure this I would use some kind of random sequence generator to create the shared secret and a random string of at least 24 characters. I found some password generators will do this for us. Once we set up the access points then we can move on to setting up Captive Portal.
Captive Portal will allow us to control access to the public of network resources through a web page. In it’s most simple form it is a list of clients and some attributes of those clients, like IP and MAC addresses. Authentication can be local, or remote. Access can be configured to rely upon some identification and a password, a shared key, or an X509 certificate. We can configure Captive Portal as either bridged or routed and which interface to activate it on. If we want authenticated users to access your LAN then bridged is probably a good choice. If however we use of Captive Portal is simply to access the internet, we might want to use the routed configuration. Everything depends upon our network topology and the purpose of the ZeroShell system. I can see many uses throughout the network, not just as an edge router.
The HOSTS page helps us to set up and manage X.509 certificates and ldap entries for hosts that the ZeroShell server will interact with. We can List, View, Add, Edit, Delete create and manage X509 certificates and Kerberos 5 authentication information on the HOSTS page. Everything in this page is similar to the interface for users. The use of X509 certificates is designed to maximize security. The generated certificates can be used for both server and client SSL. OpenVPN uses SSL certificates. It can be used in just about any situation where you need secure host to host authentication.
If we’re going to us ZeroShell as a gateway box, we want to configure it to do routing. We may want to add static routes other than our default route. If we want to run RIPv2, this is the page to configure it. The NAT tab allows us to choose which interfaces will be doing PNAT or masquerading for hosts in our LAN. We can also configure 1:1 NAT through the Virtual Server tab. This will set up port forwarding for specified ports to specified hosts. This is handy if we have a DMZ network and servers in that network. We can port forward specific ports to those hosts. If we create an ethernet alias by adding another IP to then interface in Network section of SETUP we can then provide access to services running in the DMZ network.
If we’re running multiple networks, for example a DMZ, LAN, WAN we may need to run DNS so hosts can find each other on the different network segments. We may be connected to a ISP that only uses dynamic addresses, and our IP changes occasionally. So we need a way to advertise our address and keep up with the changes. All of these things would be set up in the DNS page. There is a configuration tab for Dynamic DNS Updater where you can configure your dynamic DNS provider, so when your IP address changes ZeroShell notifies you provider of the change.
Unfortunately it looks to be difficult to set up split zones through the GUI interface. So I would probably do what I currently do for my network. I would run an authoritative DNS server inside the DMZ, and not configure anything but local addresses in the gateway. I would also edit the default configuration through the console so it only binds to the internal interfaces.
This is the weakness of GUI interfaces, you can only configure what the interface provides. Fortunately in the case of Zero Shell, you still have access to the command line and can configure through the console. I’m not sure how well these command line configurations are protected. Sometimes GUI interfaces stomp on command line configurations.
If we want to manage all of our internal networks from the gateway, ZeroShell provides us with an interface to DHCP . It’s not obvious in the GUI interface if you can set up multiple networks and configure DHCP to hand out a different set of addresses on each interface, something I like to do on my firewall. Because I have a dhcp server running in the network where I’m testing ZeroShell, I’m relunctant to enable this service, to test it. It’s never a good idea to have two dhcp servers running on the same network.
We have multiple options when setting up a host-to-lan vpn with ZeroShell server. We can user OpenVPN, with Only Password, Only X.509 Certificate, or X.509 Certificate + Password.
If we prefer, we can set up host-to-lan VPN with IPSEC. You need the Radius Server configured for IPSEC.
This type of VPN is a combination of two protocols: Layer Two Tunneling Protocol (L2TP) incapsulated into IPsec working in transport mode. IPsec authentication uses the IKE (Internet Key Exanchange) with X.509 certificates. This means that both VPN server and client hosts need a certificate with the related private key to provide mutual authentication. L2TP authentication occurs through MSCHAPv2 protocol that authenticate the users with the same usernames and passwords used with Kerberos 5.
We can also create a LAN-to-LAN VPN
Zeroshell uses OpenVPN to encapsulate Ethernet datagrams in TLS tunnels authenticated via X.509 certificates on both endpoints as a solution to the site-to-site VPNs. This non-standardized solution requires the use of a Zeroshell box in both LANs or another system using the OpenVPN. This type of LAN-to-LAN VPN has been chosen because it has the following advantages:
* By creating an Ethernet (Layer 2) connection between the two LANs, in addition to routing, bridging of the networks is made possible guaranteeing the passage of any layer 3 protocol (IP, IPX, Apple Talk);
* The 802.1Q VLAN protocol is supported. This means that if a network is broken into Virtual LANs, the latter can also be transported on the peer network with a single VPN tunnel;
* Bonding of two or more VPNs is supported in load balancing or fault tolerance configuration. This means, for example, that if there are two or more ADSL connections, a VPN can be created for each connection and they can be combined increasing the bandwidth or reliability
* Thanks to the LZO real-time compression algorithm, data is compressed in an adaptive manner. In other words, compression only occurs when the data on the VPN really can be compressed;
* The use of TLS tunnels on TCP or UDP ports makes it possible to transit the router where the NAT is enabled without problems.
While all these seem like great advantages, it does however mean that we will have to use Zero Shell boxes on all gateways that will participate in our LAN-to-LAN VPN. To my knowledge this is the only firewall software that uses this configuration. It may well be secure, but it will not interoperate with any commercial firewall. This will be a show stopper for some companies, that don’t control both ends of their VPN perhaps because they need to work with a business partner.
Quality Of Service (QOS) is a handy feature if we need to reserve application bandwidth through our gateway. As more applications run in network over IP this feature will be used more. Applications could be Voice Over IP traffic or traffic to a cloud application. When we apply QOS to an interface it only applies to outgoing traffic on that interface. There is no control over incoming traffic. We control incoming traffic by applying QOS rules to the opposite interface, for example apply QOS to the WAN interface to control incoming traffic on the LAN interface. There is pretty good documentation on QOS on the ZeroShell website.
When we click on the Wireless link in the Web interface to ZeroShell this error message pops up. Must be on the todo list. There is some documentation on the ZeroShell web site about setting up a wireless access point.. I prefer stand alone access points instead of APs built into the system. If something goes wrong with an external access point, you can restart it without having to interrupt other traffic through your firewall. If the wireless card is built into the gateway hardware, then you might have to restart the whole gateway router, to fix a problem with the wireless card.
The Net Balancer is capable of two modes, Failover and Load Balancing or just Failoever. The Failover and Load Balancing mode can effectively increase available bandwidth for multiple users on a busy network. Different weight values for connections in the Failover and Load Balancing mode determine how traffic is routed and which connections get the most traffic. In Failover mode, the weight value determines the order that the different connections fail over. The highest weight value is active, lower values are spares that become active when the active connection fails. I don’t have multiple connections to use for testing, but the Zero Shell web site documentation is pretty understandable. If we need to set up this configuration, we will definitely refer to this site.
Since I’m not that versed on Kerberos I’m going to depend upon the excellent documentation to help us understand the how-and-why of this part of the ZeroShell interface. Below is a the first page of the documentation for Kerberos 5. Not too difficult to read and understand. I’ll highlight a few things below.
“The name of a realm is case sensitive, i.e. there is a difference between upper and lower case letters, but normally realms always appear in upper case letters. It is also good practice, in an organization, to make the realm name the same as the DNS domain (in upper case letters though). Following these tips when selecting the realm name significantly simplifies the configuration of Kerberos clients, above all when it is desired to establish trust relationships with subdomains. By way of example, if an organization belongs to the DNS domain example.com, it is appropriate that the related Kerberos realm is EXAMPLE.COM. ……..”
EXAMPLE.COM is the default domain configured on ZeroShell. Since it’s not routeable, that should save the novice administrator from making some mistakes bringing up a new installation of ZeroShell. All the default IP addresses are likewise non-routeable. Good defaults, I like it.
“A principal is the name used to refer to the entries in the authentication server database. A principal is associated with each user, host or service of a given realm. …..”
“A ticket is something a client presents to an application server to demonstrate the authenticity of its identity. Tickets are issued by the authentication server and are encrypted using the secret key of the service they are intended for. Since this key is a secret shared only between the authentication server and the server providing the service, not even the client which requested the ticket can know it or change its contents. ……………”
” …………. Version 5 of Kerberos, however, does not predetermine the number or type of encryption methodologies supported. It is the task of each specific implementation to support and best negotiate the various types of encryption. However, this flexibility and expandability of the protocol has accentuated interoperability problems between the various implementations of Kerberos 5. In order for clients and application and authentication servers using different implementations to interoperate, they must have at least one encryption type in common. The difficulty related to the interoperability between Unix implementations of Kerberos 5 and the one present in the Active Directory of Windows is a classic example of this. Indeed, Windows Active Directory supports a limited number of encryptions and only had DES at 56 bits in common with Unix. This required keeping the latter enabled, despite the risks being well known, if interoperability had to be guaranteed. The problem was subsequently solved with version 1.3 of MIT Kerberos 5. This version introduced RC4-HMAC support, which is also present in Windows and is more secure than DES. …………….”
The version of ZeroShell I am reviewing has
- DES cbc mode with CRC-32, no salt
- DES cbc mocde with CRC-32, Version 4
- DES cbc mode with CRC-32, AFS version 3
- Triple DES cbc mode with HMAC/sha1, no salt
- ArcFour with HMAC/md5, no salt
- AES-128 CTS nmode with 96-bit SHA-1 HMAC, no salt
- AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
We can see an example of configuring these attributes in the following screen.
If we have equipment that needs to share tickets with, we should check for compatibility with this system. I probably would choose to run the Key Distribution Center (KDC) somewhere other than the gateway to the network. Previous version of kerberos have had serious bugs. Perhaps a virtual machine configured to act as a KDC would be a more secure design. Something to think about when deploying any gateway.
I chose to take only a few definitions from the Kerberos Tutorial page. It’s well written and good for getting you up to speed.
The firewall page allows us to build custom firewall rules using iptables. There are a set of L7 Filter rules that can be called by clicking on a pull down menu. These are premade rules for allowing applications to work across the gateway. There are rules for games. There are rules for protocols and rules for providers. We could add custom rules here to create rules automatically to block certain kinds of attacks patterns.
You can start with a new chain and then build rules to apply to that chain. In this screen shot we’re just adding some rules to the Foreward chain.
X.509 CA is the interface to manage our Certificate Authority. I would again choose to run this on a separate server, perhaps another virtual machine, instead of running it on the gateway. The tool is great, I just prefer not to use it on a gateway.
The first step is to set up the basic Certificate of Authority configuration in the setup screen. If we were going to run the CA on the Zero Shell system, we would want to change all the information in the screen below to what is appropriate for our domain.
Then we to generate new CA Certificate and Private Key, or if we are going to generate our keys somewhere else, we can then import them from this external Certificate of Authority. We want to generate keys for all hosts and users that will interact with the ZeroShell. They’re used for authenticating to the built in methods on Zero Shell. It’s recommended that every system that will be participating in host-to-LAN Virtual Private Networks will use certificates for authentication.
If you already have a Certificate Authority configured inside your network, you can add it to the list of trusted CAs and continue using it as your primary CA. You can transfer certificates from the CA to Zero Shell system.
ZeroShell relies upon havp HTTP Anti Virus Proxy to protect client traffic passing through. The http proxy is configured to run as a transparent proxy in either bridge or router mode. There is an iptables redirect rule that is added when you add capture rules to an interface. This makes it simpler to deploy for the system administrator, since we don’t need to configure clients to use the proxy, it’s automatic. You can create exclusions for the proxy. For example you might have a web server inside one of your networks and don’t want to proxy connections to it. HAVP can be configured to log Only URLs containing Virus, or you can configure it to log all connections.
“The HAVP proxy configured in Zero Shell, by default scans images using the ClamAV antivirus program. Nevertheless, on slow hardware, the scanning of images could delay the opening of web pages with many images. In this case it possible to disable the scanning of files containing images, by setting the [Check Images (jpg, gif, png)] option from “Enabled” to “Disabled””
There is also an option to maintain Blacklist and Whitelist containing one URL per line. There are some hints that Dans Guardian may be able to be integrated with the havp daemon. However it is not distributed with ZeroShell. because of questions about the compatibility of licenses. I want to point to the excellent documentation for this feature on the ZeroShell website
I want to thank Fulvio Ricciardi for producing such a nice system. The amount of work done shows in the interface and the thoughtful way the system is put together. I even like the error messages for future features. The documentation is uneven, however what is there is excellent. I think it’s well written and easy to understand. I only found one or two things that I would need further research to understand. ZeroShell is an impressive firewall and I could see several places where it would be useful in addition to the primary rolls as edge router or filtering bridge. The fact that it run on single board computers is a plus. I personally like the low failure rates for these small systems.
If you are looking for a Linux powered firewall, without too much extra baggage, ZeroShell deserves a close evaluation. I’ve evaluated many Linux “firewalls” and many have too many applications for my liking. ZeroShell does everything I would like, few things I don’t and boasts first class security with both Kerberos 5 and X.509 Certificate Authority. For anyone wanting to increase the security of their network, ZeroShell could be a good place to start.