Next Generation Router- SecurityConcept or a Virtual Reality

Denise Mangold Department of Electrical and Computer Engineering

Villanova University College of EngineeringVillanova PA 19085

Abstract—The computer industry must always evolve in the areas of infrastructure and security. There is a growing need for virtualization in the point of presence and datacenters. The desire to reduce capital, environmental and operational cost by purchasing fewer chassis and less power consumption has led to a growing push toward virtualization, while this push makes economical sense security must also be priority in decision making. The Halon security router is a network operating system and software distribution based on Open BSB, which provides a UNIX root shell. Halon claims to be secure by design because of the Open Source sandbox user interfaces with backend API as the sole area of exposure. [1] Traditional routers have been hardware based Halon can be hardware based but also offers a virtual security router. I investigated the ease of use, security, performance and features available from Halon in a Virtual machine, Oracle’s Virtual box was used to install Halon.

I. INTRODUCTION

The next generation of routers is increasingly becoming virtual appliances. A number of vendors already have virtual appliances on the market, Cisco has the Cisco Cloud Services Router, and Palo Alto has a PAN-OS both companies offer an impressive suite of tools such as malware blocking, virus protection, spyware protection, data filtering, deep packet inspection and promises of vulnerability detection. To fully get an understanding of the functionality, security and performance of a virtual appliance I built a virtual router from a vendor that allowed a fully functional trial/Personal evaluation.

The Halon security router (SR) is a network and software distribution based off the OpenBSD Operating system. The SR uses a single revision managed, clear-text configuration file uses atomic commits meaning there is never a need for a reboot even for rollbacks of changes [1] this is important for production environments due to the cost of downtime. The SR also has built in clustering meaning if one system fails there is no downtime; this is if clustering is configured. Clustering was not tested in the VM due to the fact reliable results could not be obtained at this time. The SR also has a fully featured load balancer (up to layer 7, with SSL acceleration) I have a matrix of what constitutes a reboot/reset for soft commits and how changes are applied to the system on figure 1.

Figure:1

II. SetupThe main operational requirement for deploying a virtual

router is that router functionality should not deteriorate as a result of implementing a virtualized solution this includes performance as well as security.

The system being evaluated as a virtual secure router is a mix of open system scripts, patches, and closed backend source code. The software can be installed on a number of platforms such as Mac OS X, Linux/BSD, Microsoft Windows, and virtual machines such as VMware and Oracle’s Virtual box. The version that was used for my evaluation and summary was halon-vsr-i386.vmdk installed within Oracle’s virtual box version 4.3.12 r3733 on a Mac OS X version 10.9.5. The system deployed itself with ease. The Virtual box settings were as follows: System base memory 4gb, video memory of 16mb, and storage of 20gb. One virtual CPU was allocated to the VM. The configuration was straight forward a web address was given by the install to log into for further configuration via a web UI. For the evaluation I wanted to focus more on vulnerability detection and prevention in a virtualized router situation. I did set up 3 virtual machines to test various functions of the router capabilities. IP addresses for my three virtual machines were 192.168.1.9, 192.168.1.12, 192.168.1.11 the .9 and .12 with the 192.168.1.9 having the virtual cluster setup.

Figure 2: Virtual machine setup

FiOS Router configuration of DHCP addresses assigned to the virtual machines built for evaluating the HALON Security router. As shown there are 4 addresses used for the virtual machines. 192.168.1.9 – 12. The .11 address was used by the Kali Linux machine for penetration testing of the router configuration. The FiOS router is an Actiontec Model MI424WR-GEN3I firmware version 40.21.18 with a broadband connection type of DHCP.

Figure 3:

Getting the virtual machines on the same network as the Verizon FiOS router required setting up the VirtualBox network device as a bridged network. VirtualBox provides up to eight virtual PCI Ethernet cards for each virtual machine. With bridged networking, VirtualBox uses the device driver of the host system in this setup it is Intel PRO/1000 MT Desktop, as this setup was done using an iMac, that filters data from the

physical network adapter. This setup allows the VirtualBox to intercept data from the physical network and inject data into it, effectively creating a new network interface in software. Even though technically, everything that can be done using internal networking can also be done using a bridged networking, there are security advantages with internal networking.

In a bridged network mode, all traffic goes through a physical interface of the host system. It is possible to attach a packet sniffer such as wireshark to the host interface and log all traffic going through it. If the goal is for the virtual machines to communicate privately, hiding the data from both host system and user, a bridged networking configuration is not an option. I would not recommend this setup for a production environment, but it served as a research testbed perfectly, giving me the ability to really evaluate and analyze the traffic.

Figure 4: Bridged adapter allowing network connectivity

After the initial install a static IP addresses was assigned to allow for web access, the file changed was /var/www/logs/resolv.conf and the wanted IP address was added to allow for website login and configuration. The gateway was set to the home network router from Verizon of 192.168.1.1 the Verizon router assigned DHCP addresses to the virtual machines, the DHCP IP addresses given by the Verizon router were set as static IP addresses from within the Halon router configuration.

Figure 5: Initial Web login:

The free/personal version of Halon SR does allow the installation of a functioning firewall router. The router is IPv6 ready and is supported in the virtualized environment. The router does add automatic clustering, revision based configuration, real time graphs, and logging facilities, integrated centralized management for clusters. The SR also supports AES acceleration when used with supported hardware. The personal/free version has restrictions on functions such as maximum of ten firewall rules, one IPsec tunnel and no load balancing, VPN users or the ability to VLAN the network. All of the above mentioned configurations could be done using the WEB GUI.

Figure 6: Welcome screen with real time graphing (.12 was used)

III. OPERATING SYSTEM SECURITY - EVAULATION

The operating system allows for root access. A root account was created, as well as other user accounts those users were added to the sudoers file via visudo. The system does allow for direct root login if root is enabled.

A. OS Good Security Practices Observations:

The top-level file systems are not writable, example mkdir dmangold within the /home directory produced the output Read-only file system. The passwords are salted, there is no /etc/shadow file the passwords are kept in a db file that is encrypted. The logging is verbose and each login is recorded in the log files. There is a limited use of shells the only shells available to the OS are sh, csh and ksh, this is critical due to the recent shell shock vulnerability. I tried deleting the

/etc/passwd file and was able to do so, however, the system self healed and I was able to log back into the machine with no issues after deleting critical system files. Also, the top-level directories are read-only, meaning I could not create files or directories within the system, this is critical in protecting against rootkit type of Trojans.

Figure 7:

B. OS Security Concerns observations during initial evaluation;

The /etc/sudoers file allowed vi editing directly to the file and I was able to save the file. Adding users to the sudoers file should always be done via visudo. The /etc/passwd file also allows for direct editing. This is very bad in the fact a corrupted passwd file could render the system unusable, however, the halon does self heal from /etc/passwd deletions and bad edits. The web interface is Apache and the httpd.conf file can be edited, the default address was changed to another address to listen on via #vi /var/www/conf/httpd.conf. The /sbin directory is available to root and the ability to change files within that directory, meaning rootkits could theoretically compromise these files and hide their activity. Library files can be manipulated theoretically, however after testing those files are also self healing, meaning deleting or modifying them does NOT leave the system unusable. Log files can be manipulated, once again these are also kept as backup in the database so in the event they were manipulated they can be recovered for proper forensic analysis.

The IP address if public facing is subjected ssh brute force attacks if using default port of 22. Figure: 3 shows ssh brute force attacks on Halon’s public Web UI demo software. The ssh port on the web gui if possible should be changed, my system was closed off to the public so if changing the port for ssh via the /etc/ssh/sshd_config was possible, I could not test to see if the configuration was viable out in the wild.

Figure 8Oct 15 01:00:08 sr last message repeated 2 times Oct 15 01:00:08 sr sshd[12971]: Disconnecting: Too many authentication failures for root [preauth] Oct 15 01:00:09 sr sshd[9101]: Failed password for root from 61.174.51.224 port 38444 ssh2 Oct 15 01:00:11 sr sshd[9101]: Failed password for root from 61.174.51.224 port 38444 ssh2 Oct 15 01:00:12 sr sshd[28514]: Failed password for root from

61.174.51.224 port 30879 ssh2 Oct 15 01:00:14 sr sshd[9101]: Failed password for root from 61.174.51.224 port 38444 ssh2 Oct 15 01:00:15 sr sshd[9101]: Failed password for root from 61.174.51.224 port 38444 ssh2 Oct 15 01:00:15 sr sshd[9101]: Disconnecting: Too many authentication failures for root [preauth] Oct 15 01:00:19 sr sshd[17927]: Failed

IV. ConfigurationOne of the most attractive features of the halon router is the

configuration feature. The Configuration is stored in a revision-managed database.Every new configuration is saved, it is committed to the database. The running configuration is shown by checking out the latest configuration (like a feature MS word or excel has) the latest configuration is called the HEAD, each revision is associated with a revision number. Each revision is incremented, by increasing numbers. When a user commits a configuration, it is first applied (meaning it’s made effective) if it is successful it is saved in the database.

New configuration events are transformed into event keys, which have an ID and values. Whenever new keys are generated they are compared to the running configuration keys, which contain an event list. If a user commits a configuration that contains no differences in keys an error is given.

When the system boots the latest revision is checked out and compared to the last list of keys, which should be empty, meaning every change needed to bring the system to the state requested by the configuration is done.

V. WEB UI SECURITY

The web interface for the Halon SR was reviewed for security flaws using two web vulnerability scanners for scanning the public facing demo site. Kali Linux was used for scanning the Web UI for vulnerabilities. The first scan was done using OWASP Zap; there were no high alerts, however Vega listed one finding as a high risk. The initial evaluation was done scanning the public facing demo site. Kali Linux was used for scanning the Web UI for vulnerabilities. The first scan was done using OWASP Zap; there were no high alerts, however Vega listed one finding as a high risk. Session Cookie without Secure flag, the impact is that cookies can be exposed to network eavesdroppers. Session cookies are authentication credentials; attackers who obtain them can get unauthorized access.

Figure 10:

A. Web UI User experience

The user experience and ease of use is important to the operation of any software system. The Web UI is intuitive, it allows for a straightforward configuration of the system.

Other features that are easily accessible are setting up a clustered environment, hardware information, system health and system as well as other various system administration tasks, such as user management. The UI allows for those who are not native router/network administrators to configure a network, and set up firewall rules without having to fully know or understand the CLI, which would result in lower administrative costs as the more technical knowledge the more expensive. All of the vendors promise an intuitive interface, from the evaluation of Halon, the user interface truly is intuitive and does not require a lot of technical knowledge to set up a functional network.

I was able to set up basic firewall rules banning telnet and ftp access through the router.

I was also able to setup IPsec tunnel, although it was from host to host on the same physical machine. I used the non-clustered Halon router to tunnel to one of the clustered Halon SR routers in my VM setup. This was mainly done to determine the ease of setup and verify that I could set up the one promised IPsec tunnel.

Figure 9:

I was also able to set up a faux type clustering, I call it faux because this setup was run on an iMac through virtualbox using the same physical Ethernet card. I was not able to get a “TRUE” cluster being that I had only one machine to setup the cluster of VMs running on the same iMAC. The setup was more of a virtual cluster.

Figure 11:

The ability to set up IPsec was also very intuitive in the fact that with just a few searches one can come up with usable settings for setting up IPsec for their personal network. IPsec is very important especially in today’s climate of constant

network breaches. The internet protocol (IP) does not provide protection to transferred data. It does not guarantee that the sender is who you think they are. IPsec attempts to solve the problem of securing IP traffic. The CIA triad of confidentiality, integrity and availability is at the heart of information security. IPsec supports them in a uniform matter, such as confidentiality: You do not want anyone to see your passwords when logging into a remote system over the internet. Integrity guarantee that data being transmitted is not altered while in transit. Authenticity, signing the data so that others know that it is really you that sent it. Halon supports one IPsec tunnel for the personal/free version of their Security router. I was able to set up one tunnel (albeit it was from one VM to another)

The configuration of the IPsec within Halon can be done from within the GUI or from the CLI. The configuration was for configuring IPsec (not VPN) When configuring IPsec in Halon you can select wither automatic keying (IKE) or Manual Keying. IKE is the most common method of setting up IPsec because it automatically rotates the keys, in order to ensure the encryption is not compromised. The disadvantage of implementing IKE is that it is relatively complicated to implement for someone who is not an advanced user, this can result in unstable tunnels and in events of minor misconfiguration can cause incompatibility with

VI. VIRTUALIZATION SECURITY CONSIDERATIONS

Although vendors promise smarter routing/network capabilities such as malware detection, file blocking, date filtering, virus protection as well as vulnerability protection a key question that must be asked is how secure is a virtual environment? From a technical point of view wouldn’t the

sharing of resources present a security risk? A user could exploit resources and reduce service quality, which would place all overlay technologies in question. Typically a virtual machine is connected to the network via a bridged connection.

To use the VM as a router or firewall means that all the traffic would come into the physical computer, the packets are filtered and sent back to the physical computer. Since the physical computer can take unfiltered packets it’s actually responsible for distributing packets to the rest of the network, this could be exploitable.

ACKNOWLEDGMENT

I was able to evaluate in real time a fully functional virtual router/firewall. I’d like to thank Halon for giving me information and support free of any charge!

I’d also like to thank the network team at Villanova University for directing me to good documentation for the Palo Alto virtual appliance and giving me a crash course on setting up network appliances.

REFERENCES

[1] "Security Router | Halon Security." Halon Security Security Router Comments. N.p., n.d. Web. 17 Oct. 2014.

[2] "Cisco Cloud Services Router 1000V 3.11 Series Data Sheet." Cisco. N.p., n.d. Web. 17 Oct. 2014.

[3] Virtual Box "Chapter 13. Security Guide." Chapter 13. Security Guide. N.p., n.d. Web. 17 Oct. 2014.

[4] Wilmsmeier, Gordon. "Determinants of Liner Shipping Network Configuration: A Two-region Comparison." GeoJournal 76.3 (2011): 213-28. Web.