Designing an Embedded Firewall/VPN Gateway
Contents
1. VPN Node Branch Office LAN VPN Firewall oy f Node N e Public Network E eG d Eo d 5 m f VPN lt Node VPN Node MD T lt a Branch Office LAN M T aT Branch Office LAN Figure 6 The VPN nodes link remote locations to the central office over a public network The many to many links allow the VPN to be resilient to failures of individual nodes and in the case where there is significant traffic between the remote nodes there is better utilization of the VPN resources as all packets go through at most one IPsec tunnel to their destination Another system that offers similar function ality to the one we have presented here is the Moat from the AT amp T Labs Denk99 Like our system the Moat also utilizes small single board computers running a lightweight version of Linux and create VPNs allowing AT amp T research per sonnel to telecommute The Moat follows the one to many VPN layout probably because it is not envisaged that there will be significant traffic between employees working at home Remote stations with floating IP addresses as is the case2. Prev99 In the previous project a number of VPN stations were deployed within the University of Piraeus in Greece as part of a network of monitoring sta tions The purpose of these Secure Network Sta tions SNS was to allow the creation of a secure network that allows administrators to manage and troubleshoot network elements such as routers hubs and switches deployed throughout the Uni versity campus The SNS system has been in op eration for more than three years The SNS nodes have different configurations from the VPN nodes discussed in this paper be cause they serve different roles For example SNS nodes need to forward SNMP traffic from the network elements and allow connections from inside the secure network to reach network ele ments located outside the SNS perimeter Moreover the system uses static IPsec configu ration which necessitates the production and distribution of updated configurations on a regu lar basis Nevertheless the experience gained from their use helped in refining the requirements for the systems described in this paper One notable decision that was directly influenced by the pre vious design was to have a fully connected mesh of IPsec tunnels linking every node to all the oth ers Most VPN solutions tend to link a central office with a number of remote locations with the IPsec tunnels arranged in a star see Figure 6 ee Main Office LAN
3. of most dial up Internet connections are treated by dynamically rewriting the IPsec configuration files This requires that a central cite is always operational so that the VPN nodes can get the information they need to create their configura tion files In our system the use of certificates allows any two stations to negotiate SAs and cre ate IPsec tunnels Additionally the use of built in facilities such as the isakmpd daemon make the system easier to maintain and port across Oper ating System releases As part of our future plans we intend to im prove the automatic configuration of our system The goal is a system that explores the network it is connected to discovering default routers dhcp servers and so on and configures itself accord ingly References Bosc00 Boscia Nichole K and Derek G Shaw Wireless Firewall Gateway White Paper NASA Advanced Su percomputing Division Moffett Field CA 94035 Cheswick William and Steven Bel lovin Firewalls amp Internet Security Repelling the Wily Hacker Addi son Wesley Professional Computing Series 1994 Denker John S Steven M Bel lovin Hugh Daniel Nancy L Mintz Tom Killian and Mark A Plotnick Moat A Virtual Private Network Appliance and Services Platform LISA 99 13th Systems Administra tion Conference Washington No vember 1999 Ioannidis S A D Keromytis S M Bellovin and J M Smith Imple menting a Distributed Firew
4. or a solid state disk e g Com pact Flash In our prototype system we are us Pi kernfs mfs msdos nfs procfs df newfs umount Filesystem The root of the runtime file system together floppy root kernel i Ramdisk root were e configuration F g etc stand var ing Compact Flash as the boot medium so in the following paragraphs we use the term CF A P AN In order to produce a RAM based system mfs rc executables we adopted the techniques used by the PICOBSD project which is a collection of FreeBSD con figurations that can be accommodated within a single boot floppy http vww freebsd org picobsd The PICOBSD project provides con figurations for a dial up router dial in router ISP access server general purpose router and firewall The PICOBSD technique links the code of all the executables that we wish to be available at runtime in a single executable using the crunchgen utility Silv98 The single executable alters its behavior depending on the name under which it is run argv 0 By linking this ex ecutable to the names of the individual utilities we can create a fully functional bin directory where all the system commands are accessible as apparently distinct files The aggregation of the system executables in a single file and the compression of the entire kernel allows a large number of facilities to be made available despite the small size of the boot medium For example in th
5. to the application code e Like other free UNIX clones a large number of programs such as tcpdump snmpd ssh etc are either supported in the base release or are available through the ports system e Good security The designers of OpenBSD have paid a lot of attention to the security profile of the system creating a robust envi ronment 3 3 IPsec IPsec is a suite of protocols RFC1825 that pro vide encryption authentication and integrity checking at the network layer Sieve employs IPsec in tunnel mode with encryption ESP RFC1827 Figure 3 Tunneling consists of encrypting and encapsulating a normal IP packet within an IPsec packet Since both the header and payload of the original packet are encrypted the internal structure of the private network is con cealed from intruders Shah97 The use of tunnel mode also allows us to use the Sieve nodes as routers sending packets from the remote home LANs to the main corporate network Scot98 Under this scenario addresses from the internal corporate network may be allo cated to workstations at the employees homes Another configuration layer 2 VPN utilizes bridging Kero00 rather than routing so that the remote node appears to be directly connected to the corporate network This approach also allows the use of non IP protocols such as LAN Manager and Novel IPX SPX Two sets of IPsec connections are main tained for each Sieve node One carries the VPN data while t
6. Designing an Embedded Firewall VPN Gateway Vassilis Prevelakis vp drexel edu Drexel University Angelos Keromytis angelos cs columbia edu Columbia University Abstract The widespread use of mobile computing and telecommuting has increased the need for effective protection of computing platforms Traditional schemes that involve strength ening the security of individual systems or the use of firewalls at network entry points have difficulty accommodating the special requirements of remote and mobile users We propose the use of a special purpose drop in firewall VPN gateway called Sieve that can be inserted between the mobile workstation and the network to provide individualized se curity services for that particular station Sieve is meant to be used like an external mo dem the user only needs to plug it in Its existence is transparent to the user requiring no modification to the workstation configuration To function in this role Sieve has been de signed to be compact low cost requiring little administration or maintenance In this pa per we discuss the features and advantages of our system We demonstrate how Sieve was used in various application areas home university environment etc and describe our future plans 1 Introduction The recent advances in networking have created a situation where computers are practically al D 7 son ase ways connected to the Internet Cable modems 3 and DSL lines for the SOHO env
7. OD P0001 tives and most Unix and Unix like systems al ready provide security features that can be used to implement firewall functionality on every ma chine The difficulty of securing general purpose Operating systems has impeded the widespread use of this approach Moreover it is difficult to ensure that a secured system remains secure after the user has had the opportunity to install soft ware and perform reconfigurations and upgrades Recognizing the futility of attempting to se cure the user machines themselves we propose the use of a portable shrink wrapped firewall which we have called Sieve This is a separate machine running an embedded system that in cludes firewall capabilities and is normally placed between the general purpose computer and the network Figure 2 The problem of se curing the firewall becomes much simpler as the platform is a special purpose one with a highly controlled architecture Jee storage server gt LJ user workstation mall server eft computation server Figure 2 Sieve provides firewall services and creates secure links to other servers in the net work establishing a secure overlay network that is inaccessible by third parties attacker To avoid the need for labor intensive recon figurations and to provide flexibility we allow the security policy of this embedded platform to be downloaded from the network For a shrink wra
8. all Pro ceedings of Computer and Commu nications Security CCS 2000 pp 190 199 Keromytis Angelos D Jason L Wright Transparent Network Secu rity Policy Enforcement USENIX Annual 2000 Technical Conference Freenix Refereed Track San Diego California June 18 23 2000 Prevelakis Vassilis A Secure Sta tion for Network Monitoring and Control The 8th USENIX Security Symposium Washington D C USA August 1999 Atkinson R Security Architecture for the Internet Protocol Internet Engineering Task Force August 1995 Atkinson R IP Encapsulating Se curity Payload ESP Internet En gineering Task Force August 1995 Ches94 Denk99 Ioan00 Kero00 Prev99 RFC1825 RFC1827 Scot98 Shah97 Silv98 Stub02 Scott Charlie Paul Wolfe and Mike Erwin Virtual Private Networks O Reilly amp Associates Inc 1998 Shah Deval and Helen Holzbaur Virtual Private Networks Security With an Uncommon Touch Data Communications Sept 97 da Silva James Cruchgen Open BSD User Manual 1998 Stubblefield Adam John Ioannidis and Aviel D Rubin Using the Flu hrer Mantin and Shamir Attack to Break WEP To appear at the NDSS 02 Conference
9. e Sieve distribution we include the following commands Commands cat chgrp chmod chown cp echo kill ln Ils mkdir more pwd rm telnet test w date dmesg hostname passwd ps reboot vmstat dev_mkdb mknod pwd_mkdb swapctl swapon sysctl Category Shell Commands Korn Shell Administration System Configu ration getty snmpd dhcpd inetd init login syslogd telnetd stty update Figure 4 The organization of the Sieve distribution with the executable and associated links are placed in a ramdisk that is stored within the ker nel binary The kernel is then compressed using gzip and placed on a bootable CF This CF also contains the etc directory of the running system in uncompressed form to allow easy configura tion of the runtime parameters Figure 4 At boot time the kernel is copied from the CF disk to main memory and is uncompressed and executed The file system root is then located in the ramdisk The CF boot partition is mounted and the etc directory copied to the ramdisk At this point the CF partition is unmounted and may be removed The system is running entirely off the ramdisk and goes through the regular initiali zation process Once the boot process is com plete user logins from the console or the network may occur The CF is usually write protected so changes in the system configuration do not sur vive reboots If however the CF is not write protected there e
10. e ex changed between the VPN nodes themselves This kind of communication is mainly for management and node administration Gen erally no restrictions are placed to this type of traffic Given that we are enforcing no access re strictions within the VPN we were extremely concerned about allowing access to the Sieve from the user workstation When considering security mechanisms there is always a need to strike a balance between security and conven ience Making life difficult for the end users would only mean that they would avoid using the VPN or find ways to disable or bypass various security mechanisms thus compromising the security posture of the entire network At the same time we did not wish to allow unsophisti cated users access to the Sieve nodes In the end we decided that users may access their local Sieve node only from their own inside network In this way only users suitably authorized would be able to access the configu ration of their own Sieve nodes 3 6 RAM based system In order to produce a simple and reliable system we decided to dispense with the hard disk The reason behind this decision was twofold reliabil ity and support Although disk drives tend to be reliable they would have to operate continuously throughout the life of the Sieve nodes In both home and mobile environments equipment tend to be subject to all kinds of abuse knocked about powered down without shutting down the system
11. for the customer In the same way one of the endpoints A of a VPN tunnel presents a certificate that is signed by a certification authority CA acceptable to the other side B There is no need for B to have previous knowledge of A since the certification authority vouches for the authenticity of the cer tificate presented by A Security Association is the set of parameters for one way communication between two nodes cryptographic keys choice of algorithm etc There are two differences from the credit card example The first is that there is no on line communication with the CA during the negotia tion Endpoint B has the public key of the CA and can thus verify any certificate presented by A The second difference is that A does not trust B and so B must also present a certificate to A The second certificate must be signed by a CA acceptable to A In our system all certificates are signed by the same CA but this need not always be the case A serious issue with certificates is revoca tion i e what happens if for example a Sieve node is lost or stolen There are two mechanisms that can prevent compromised nodes from linking to the VPN 1 certificates have limited lifetimes and so unless renewed become worthless after a specified interval 2 by changing the policy file we can prevent nodes from accepting connections from blacklisted nodes 3 5 Firewall Sieve nodes must be able to allow traffic from the
12. gh the company network This is not entirely without merit be cause it means that the home computers are shielded behind the company firewall However there may be cases where we wish to have access to sites or services that are blocked by the com pany firewall In such cases the Sieve can be configured to allow only certain PCs or network segments to be part of the VPN while the rest work as if they were directly connected to the ISP In this scenario the Sieve can also perform the task of a NAT router allowing the user to share a single ISP provided IP address among multiple workstations 4 4 Hardware Platform The VPN software runs on standard PC hard ware While most of the development was carried out on decommissioned PCs the size power re quirements and most importantly the noise from the power supply fan make such machines totally unsuitable for deployment in the field Single board computers SBCs allow the creation of small factor convection cooled sys tems These designs are mostly compatible with the PC motherboards and cards so that there is no need for software porting Moreover solid state storage in the form of Flash RAM may be added Compared to ordinary hard drives this offers improved reliability After examining a number of products we chose the NetCARD system see Figure 5 This single board computer is about 14cm by 10cm and combines on board Ethernet interface Com pact Flash and 2 PC CARD slots a
13. he other is used for the management of the Sieve node itself By using separate IPsec connections we ensure that users cannot access the management information or be in a position to contact other nodes through the VPN 3 4 Key Management Using IPsec with statically defined Security As sociations SAs as we did in Prev99 is equivalent to running the Internet with static routing tables The resulting VPN is inflexible and keys are not changed as often as prudent cryptographic practice suggests because of the effort and disruption to service Moreover since SAs contain source and destination IP addresses they have to be changed each time the IP address of one of the endpoints changes Users that con nect to the Internet via dial up connections or even permanently connected users that are as signed IP addresses via dhcp cannot use statically assigned SAs Workarounds to these problems exist and are discussed in detail in Prev99 However these solutions lack elegance and are not suitable for large scale VPNs Purchases via credit cards provide a good analogy to the problem of setting up flexible SAs When purchasing an item the customer presents a credit card to the merchant The mer chant does not need to keep a record of all the people that have a VISA card in order to com plete the transaction Instead the merchant con tacts the credit card company and receives an authorization In essence the credit card company vouches
14. igi nal roll out will be difficult e A non standard platform such as Sieve will have to be easy to master otherwise new staff will not be able to support it e Sieve is intended for production use thus the administrators must have confidence in the platform 3 2 Operating System From the very beginning we wanted a platform that could accommodate tools for remote moni toring and management The requirement that the station should operate in residential environ ments without a monitor keyboard or mouse effectively disqualified all Windows platforms From the available UNIX or UNIX like systems we eventually chose OpenBSD 2 9 for the fol lowing reasons e Built in support for the transport layer secu P N 4 Public gt Network V Sieve Encrypted Tunnel Application Servers Remote Network Figure 3 The IPsec tunnel provides a secure connec tion between the two local area networks over the public Internet rity protocols IPsec that offer secure com munication channels between stations Since these channels are created by the networking code in the kernel the encryption is trans parent to applications Thus programs such as rlogin 1 that have no encryption fa cilities can take advantage of the built in se curity offered by IPsec without any modifi cations
15. interior network to flow through the VPN to the other internal networks while at the same time they should allow only a very restricted set of incoming connections On the other hand con nections from other Sieve nodes must be ac cepted The VPN may be viewed as a transit network located between the end user workstation and the internal network In the Sieve design we have used the packet filtering functionality of the OpenBSD kernel with a configuration that imposed three classes of restrictions e Public Internet This refers to packets coming in from the interface that is connected to the public net work These packets are generally blocked except IPsec packets since IPsec has its own security mechanisms Moreover we also al low ICMP echo and reply messages for net work troubleshooting but we block other ICMP messages e Transit packets flowing through the VPN Packets received from the interface con nected to the local protected network and destined for the remote end of the VPN con nection fall within this category of restric tions While allowing the packets to be routed through the VPN we generally do not allow connections to the Sieve nodes them selves Exceptions to this rule include serv ices such as dhcp that are required for the operation of the node We also allow certain types of ICMP packets for network trouble shooting e Traffic between the VPN nodes In this category we have packets that ar
16. ironment and user mailserver wireless networking for laptop and handheld workstation computers ensure that the resources of the Inter net are always accessible Against the conven computation server Figure 1 By accessing network resources the user workstation runs the risk of having its com ience of always on connections we must bal ance increased exposure to attacks munications intercepted or being attacked by malicious third parties attacker Traditional approaches for countering threats involve the use of firewalls Ches94 Unfortu nately firewalls are better suited to organizations that can afford to pay for the configuration and maintenance of such systems Moreover fire walls provide a hard shell protecting the soft core of the internal networks This architecture does modified operating systems and applications which for the time being is not feasible on a large scale basis On the other hand existing systems such as Windows NT and its deriva not protect against internal threats nor does it protect mobile users telecommuters or users of wireless connections see Figure 1 Ioannidis et al Ioan00 propose the use of a distributed firewall i e the integration of fire wall functionality in every machine in the net work However this approach requires that all computers in the network run appropriately This work was supported by DARPA under Contract F39502 99 1 0512 M
17. long with the usual PC style interfaces floppy IDE disk etc We used this system both with a floppy boot me dium and with a Compact Flash The on board Ethernet interface was used to connect the VPN node to the network access device while an Eth ernet PC CARD provided the inside network connection A wireless Ethernet card may be at tached to the system eliminating the need for fixed wiring 4 2 Operation As soon as power is applied and the power on tests are complete the PC BIOS loads the system from the boot medium and hands control over to the OpenBSD kernel In order for the outside interface to be configured the VPN node must find out the IP address provided by the ISP If the IP address is always the same then it can be in cluded in the static configuration that is read off the boot medium Otherwise the system uses dhcp to configure its interface The inside Eth ernet interface uses a pre assigned address from the private Internet range RFC1918 The sys tem also runs dhcpd on the inside interface so that workstations on the private network can be auto configured The system then runs the isakmpd daemon that creates the IPsec tunnels The packet filtering software ensures that the VPN is isolated from the outside world The node may be powered down without the need for a shutdown procedure e g sync 5 Conclusions Future Plans The work presented in this paper is a continua tion of the work described in
18. pped firewall to be effec tive the following prerequisites must be satisfied e Low cost in terms of hardware software configuration and maintenance e While it may restrict some services it must be totally transparent to authorized services e Offer secure connections to servers and other network assets thus protecting the commu nications between the protected system and other resources e Be flexible it should be able to accommo date various security policies and different types of network attachments serial Ether net wireless e Be resistant to tampering Furthermore in cases where there are indications that a sta tion has been compromised it must be easy to restore its original configuration e To simplify centralized management and troubleshooting it must offer a standard plat form for the execution of common network management and monitoring tools Worksta tion users should not have access to the management information e Finally regardless of the profile of the end user the shrink wrapped firewall must be able to be deployed with minimal overhead Existing commercial solutions do not offer the right mix of open standards and low price In fact many solutions have a per node pricing model that is based on the assumption that re mote locations are company branches Thus they have pricing structures that deal with tens or hundreds of nodes Scaling them to networks with thousands of nodes produce
19. relocated while in operation etc Hard disks produce a fair amount of heat and noise and are also more prone to failure in these conditions The second and more important reason is related to the way that these machines are in tended to be used For our purposes hard disks are already huge in terms of capacity and are getting bigger all the time This free space can cause all kinds of trouble for example it may be tempting to fill it with data that should not be stored in the Sieve node in the first place This means that stations can no longer be redeployed easily because this information must be backed up or processed Secondly if a station is com Commands ifconfig ipf ipnat cadm netstat ping traceroute isakmpd trol dhclient mount cd9660 fdesc ffs Category Networking promised the intruders will be able to use this space as a bridgehead transferring and installing tools that will enable them to attack other net work assets On the other hand diskless machines bring ipse route wicon with them a whole collection of problems and administrative headaches They are also basically incompatible with our objective of using standa lone machines with encrypted tunnels for all communications over the public Internet Instead we use a RAM based system where the software is loaded once during boot and then the system runs entirely on the system main memory RAM The boot medium may be disk ette CDROM
20. s outrageous prices Thus we decided to investigate an Open Source solution The advantage of this approach is that it offers enormous potential for customi zation coupled with a low cost per node Another benefit of using Open Source software is that unlike proprietary solutions the code can be freely audited thus providing security through openness 3 System Architecture Creating a system in house has many pitfalls mainly related to the fact that the platform de sign implementation and support all have hidden costs that must be brought out into the open and accounted for Just because a piece of software is free does not mean that its deployment in a pro duction environment is without cost A lot of attention has to be given to the integra tion large scale production and maintenance of the nodes in order that a usable system be achieved within the project s budget constraints The prime considerations in the design of Sieve have been simplicity and security In this section we will elaborate on these two issues and examine their impact on the design of the oper ating environment We will also present the ma jor components of the Sieve platform and discuss the various design decisions 3 1 Simplicity Reliability There are several good reasons to maintain low platform complexity e A complex design is difficult to verify and control This implies that maintaining the se curity posture of the platform after its or
21. ularly vulnerable to in trusion attacks A popular hacker pastime is to cruise around town with a laptop trying to con nect to wireless networks Wireless networks gt gt lt p 33 Pentium Class lt Processor p 4 io ed 64Mb RAM 10 100 WaveLAN Ethernet PC Card Figure 5 Wireless configuration should be considered unsafe and thus always linked to the internal network via a firewall In Bosc00 the authors describe the diffi culties in managing a wireless network handing out addresses opening connections through the firewall etc They also include a number of solutions but they admit that these solutions have weaknesses and thus they use them to provide access only to non critical hosts in their network Normally the system is used in bridging mode although there were cases where the sys tem administrators want to know which machines are on the wireless segment The main difference with the desktop configuration is that in the wireless configuration all communication is car ried over secure links We use IPsec in tunnel mode Figure 3 to link the workstation to the internal network In this case the public network of Figure 3 is the wireless network 4 3 Home Network Gateway Internet connections at home are seldom used by only one person or for only one task e g work By placing a Sieve between the home network and the ISP connection we have the option of forcing everybody to go throu
22. xists a utility that can copy the contents of the ramdisk etc directory to the CF boot partition thus making the running configu ration permanent This organization places the files that are unlikely to change between Sieve nodes in the kernel where they are compressed while leaving the configuration files in the etc directory on the CF Thus these files can be easily accessed and modified Moreover a single image may be pro duced and the configuration of each station ap plied to it just before it is copied to the CF 4 Prototype In this section we describe the Sieve prototype and three examples of its use office desktop wireless and home gateway 4 1 Office Desktop Contrary to popular belief internal networks in most organizations are not safe Although pro tected by firewalls these networks are vulnerable to internal attacks e g by coworkers worms and viruses from other infected machines etc Our approach is to install Sieve stations between each sensitive desktop and the internal network As it has been noted in Prev99 the ability to manage these stations via a centralized Network Management System creates a safe and predict able platform from which user network problems can be diagnosed remotely We use the Sieve in bridge mode so that the desktop appears to be directly connected to the local area network 4 2 Wireless network Wireless networks even with encryption acti vated Stub02 are partic
Download Pdf Manuals
Related Search