Vanbesien

Transcript

Universit´e de La Rochelle KHBO Brugge-Oostende Katholieke Hogesc Oostmeers ww Departement industriële Campus Oostende – Tel. (059) 56 90 ´ Science - Ge ´nie Informatique Faculte 2005–2006 Richtlijnen voo van he Master thesis Implementation of a VPN network. Professors: Student: Koen van Besien Philipe Harrand Johan Calu januari 2005 Master thesis to obtain the degree of Industrieel Ingenieur optie ICT Mededeling ”Deze eindverhandeling was een examen; de tijdens de verdediging vastgestelde fouten werden niet gecorrigeerd. Gebruik als referentie in publicaties is toegelaten na gunstig advies van de KHBO-promotor, vermeld op het titelblad.” Announcement “This thesis was an exam; all errors discovered during the presentation were not corrected. Using it as a reference in publications is allowed only after approvement from the KHBO-supervisor, mentioned on the title page” Acknowledgements I want to dedicate some space here to thanking all the people that helped and supported me during my stay here in La Rochelle, and made it possible for me to finish this project. Firstly, I want to thank my supervisor, Philipe Harrand, who gave me the opportunity to carry out this project, and who was always available to answer my questions. The project would not have been possible without his supervision and strong initiative. Furthermore, I want to thank James Middleton for editing this thesis. It was a hard job but it makes this thesis a little easier to read. I want to say thanks to all the Erasmus students of Maison de la Francophonie who provided a good distraction during this time of hard work. I also want to thank Frederick Vandenbroucke for the never- ending LATEX discussions we had and the support he gave me to complete this thesis. Finally, I want to say thanks to my parents, who gave me the opportunity to have this education, and who have always supported and motivated me to go on, no matter what. Koen van Besien La Rochelle Preface In today’s world, computer and information technology plays a major role in people’s lives. People and companies rely heavily on computer systems for storing and processing vital information. All these technologies must be safe and reliable. Computer networks are a major part of all these technologies; they provide the essential link between them, connecting them into one universal information network. The biggest advantage of networks is the availability of information at any given time and place. However, to keep information secure and to protect the privacy of this information, a proper security system is required. The focus of this thesis is to discuss and implement one of the techniques used to protect data transport in these computer networks, Virtual Private Networks. One of the requirements in this coverage was the use of the open source operating system Linux as a fundamental part of the system. The first part is an extensive overview of Virtual Private Networks and the techniques used to implement them. Firstly, a description and analysis of VPN and its competing technologies is given. Next, a brief overview of all the existing cryptographic methods which are used in VPN networks is provided. Fundamentals about security, for example symmetric and asymmetric algorithms, are explained together with the possible attacks and drawbacks of each method. Finally, an outline is presented of the existing tunneling protocols which are the cornerstone of Virtual Private Networks. The second part covers the design of a VPN network by implementing a Linux based VPN software solution. To begin with, an overview and comparison of the most important open source software solution is given. Secondly, one of the solutions, OpenVPN, is implemented and explained. Master thesis - 4de ing ICT ii van Besien Koen Contents I Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii Table of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii List of figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Virtual Private Networks 1 1 Introduction to VPN 2 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Network infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2.1 Leased lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.2 Permanent Virtual Circuit(PVC) . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.3 Switched Virtual Circuit (SVC) . . . . . . . . . . . . . . . . . . . . . . . . 4 VPN networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.1 What is a VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3.2 Concepts used by a VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.2.1 Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.2.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3.2.3 Encryption and signatures . . . . . . . . . . . . . . . . . . . . . 6 1.3 Master thesis - 4de ing ICT iii van Besien Koen CONTENTS 1.3.3 1.3.4 CONTENTS Common VPN scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.3.1 Site-to-site connection . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.3.2 Client-to-site VPN . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.3.3 Extranet VPN scenario . . . . . . . . . . . . . . . . . . . . . . . 9 Advantages and inconveniences . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3.4.1 Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.3.4.2 Implementation time . . . . . . . . . . . . . . . . . . . . . . . . 10 1.3.4.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.3.4.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.3.4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2 Cryptography 13 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2 Modern encryption methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3 Algorithms and keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4 Symmetric algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5 2.6 2.4.1 Objectives of symmetric algorithms . . . . . . . . . . . . . . . . . . . . . . 15 2.4.2 Implementation and examples . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4.3 Possible attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.3.1 Bruteforce attacks . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.3.2 Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Asymmetric algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5.1 Objectives of asymmetric algorithms . . . . . . . . . . . . . . . . . . . . . 18 2.5.2 Implementation and examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5.3 Possible attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Master thesis - 4de ing ICT iv van Besien Koen CONTENTS 2.7 2.8 Diffie-Hellman exchange scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.7.1 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.7.2 Possible attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Hashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.8.1 2.8.2 2.9 CONTENTS Integrity control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.8.1.1 How it works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.8.1.2 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.8.1.3 Possible attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.8.2.1 Digital signatures . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.8.2.2 HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.9.1 How does it work? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.9.2 Certificates and VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3 VPN Techniques 30 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2 Tunneling protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3 3.2.1 Point-to-point tunneling protocol (PPTP) . . . . . . . . . . . . . . . . . . 31 3.2.2 Layer Two Forwarding protocol (L2F) . . . . . . . . . . . . . . . . . . . . 32 3.2.3 Layer-two Tunneling protocol (L2TP) . . . . . . . . . . . . . . . . . . . . 32 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3.1 3.3.2 Security protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.3.1.1 Authentication header (AH) . . . . . . . . . . . . . . . . . . . . 34 3.3.1.2 Encapsulated security payload (ESP) . . . . . . . . . . . . . . . 35 Modes of communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Master thesis - 4de ing ICT v van Besien Koen CONTENTS 3.3.3 CONTENTS 3.3.2.1 Transport mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.2.2 Tunnel mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Security associations (SA) . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.3.3.1 3.3.4 Key management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3.4.1 3.3.5 3.3.6 3.4 II Example of IPsec traffic treatment . . . . . . . . . . . . . . . . . 38 Internet key exchange (IKE) . . . . . . . . . . . . . . . . . . . . 40 IPsec and Network Address Translation . . . . . . . . . . . . . . . . . . . 41 3.3.5.1 AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.3.5.2 ESP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.4.2 How does it works? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.4.2.1 Handshake protocol . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.4.2.2 Record protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.4.2.3 Alert protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.5 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.6 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Implementation of a Linux based VPN solution 4 Open source VPN software solutions 48 49 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2 Open source software solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2.2 Kernel space solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Master thesis - 4de ing ICT vi van Besien Koen CONTENTS 4.2.3 CONTENTS 4.2.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2.2.2 Advantages and disadvantages . . . . . . . . . . . . . . . . . . . 50 User space solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2.3.1 OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2.3.2 CIPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2.3.3 vTun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.2.3.4 Tinc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.3 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5 OpenVPN implementation 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2 What is OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.3 OpenVPN configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.4 III 57 5.3.1 Network setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.3.2 Firewall rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.3.3 OpenVPN setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.3.1 Static key setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.3.2 PKI setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Final conclusion 65 Annexes 69 A Configuration scripts 69 A.1 Network setup script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Master thesis - 4de ing ICT vii van Besien Koen CONTENTS CONTENTS A.2 Firewall setup script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 A.3 OpenVPN setup script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 A.3.1 Static Key setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 A.3.2 Public key setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 A.3.2.1 TLS-server setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 A.3.2.2 TLS-client setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Master thesis - 4de ing ICT viii van Besien Koen List of Figures 1.1 Difference between a LAN and WAN network . . . . . . . . . . . . . . . . . . . . 3 1.2 Example of leased line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Example of a PVC/SVC network . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Site to site scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.5 client to site scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.6 Comparison about VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 Encryption and decryption of a message. . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Symmetric algorithm with a shared key . . . . . . . . . . . . . . . . . . . . . . . 16 2.3 Block cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.4 Stream cipher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.5 Assymmetric algorithm with a public/private key exchange . . . . . . . . . . . . 19 2.6 Diffie-Hellman exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.7 Concept of hashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.8 Concept of the digital signature . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.9 Concept of a Public Key infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 28 2.10 Chain of trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1 An overview of the components in the IPsec standard . . . . . . . . . . . . . . . 33 Master thesis - 4de ing ICT ix van Besien Koen LIST OF FIGURES LIST OF FIGURES 3.2 A simple representation of the Authentication Header . . . . . . . . . . . . . . . 34 3.3 A simple representation of ESP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.4 AH and ESP in transport mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.5 AH and ESP in tunnel mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.6 Negotiation of inbound traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.7 Treatment of outbound traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.8 AH and NAT problems 3.9 SSL protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.10 SSL handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.11 VPN protocols in the OSI model . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.1 Performed network setup 5.2 Adress network setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Master thesis - 4de ing ICT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 x van Besien Koen Part I Virtual Private Networks Master thesis - 4de ing ICT 1 van Besien Koen Chapter 1 Introduction to VPN 1.1 Introduction One of the most vital elements in a company is the way their internal communication is organized. If a company has only one office, the set up of a good technical network infrastructure is not difficult. The problems start when a company wants to communicate with other offices in another country or city. The employees of one office want to use the networks of other sites without encountering problems. To achieve this the exchange of data or the access to several files has to be the same on all networks. We want to create one big network for the whole company. To accomplish a good connection between several offices, one of the possibilities is to make use of a VPN network (Virtual Private Network). Another important fact is the way employees are working nowadays. A lot of employees want to work at home. They want to have access to all their files and documents at any time and at any place. We call them roadwarriors. It is important to provide the necessary tools to serve the needs of these companies and their employees. We need to look at two important parameters when designing these kind of networks. Security and confidentiality. 1.2 Network infrastructure When we talk about company networks, we can distinguish two types of networks.(In this overview the two most important ones are given) Master thesis - 4de ing ICT 2 van Besien Koen 1.2 Network infrastructure Introduction to VPN LAN network (Local Area Network) This kind of network is a computer network specially designed to set up a network in a building or local office. It covers a small local area. They are most likely based on Ethernet or Wifi. WAN network (Wide Area Network) WAN networks are used to connect networks that are geographically separated. For example, a remote branch office located in city A connecting to the central office in city B. The requirements and choices of WAN technologies are different from LAN networks. The main reason is that WAN networks are usually a service offered by carriers, and they are very costly. WAN also differs from LAN networks in the area of speed. While LAN networks are running at megabits per second, the WANs are usually in kilobits per second. Oostende La Rochelle WAN LAN LAN Figure 1.1: Difference between a LAN and WAN network Next some commonly used WAN techniques will be explained. 1.2.1 Leased lines Leased lines are the most common way of connecting branch offices to the head office. It is a permanent circuit leased from a carrier. It usually runs protocols such as IP and IPX over a point-to-point protocol (PPP). Routers are used to connect leased lines in remote offices to a central office. Due to its cost and the introduction of many other WAN technologies companies have begun to replace leased lines with other technologies like VPN networks. Master thesis - 4de ing ICT 3 van Besien Koen 1.2 Network infrastructure Introduction to VPN Network provider La Rochelle Oostende pop pop LAN LAN Figure 1.2: Example of leased line 1.2.2 Permanent Virtual Circuit(PVC) First I need to introduce the term Virtual Circuit. To initiate a communication path between two computers, one computer calls another and when successfully connected, and data transmission begins. This is called a virtual circuit. A PVC is a predefined path through the network that connects two offices with each other. It is a logical path in the connecting network. PVCs are established for busy networks that always require the service of a virtual circuit. Instead of making repetitive calls, the virtual circuit is made permanent. Examples of PVC are ATM, Frame Relay and MPLS (Multiprotocol Label Switching). All of which are non-broadcasting networks. 1.2.3 Switched Virtual Circuit (SVC) The technology used by a SVC is the same as a PVC. It is set up on demand and is taken down when transmission ends. So it is on demand and not permanent. SVCs are only used when data transfers are not common. Master thesis - 4de ing ICT 4 van Besien Koen 1.3 VPN networks Introduction to VPN Network provider La Rochelle Oostende pop pop LAN LAN Figure 1.3: Example of a PVC/SVC network 1.3 VPN networks 1.3.1 What is a VPN A virtual private network (VPN) is an extension of a company’s private intranet across a public network such as the Internet. It creates a secure private connection through a private tunnel. VPNs securely connect remote users and offices in a corporate network. The objective of a Virtual Private Network is to add a level of security to the exchange of data. Even when a company is using a leased line, they can deploy a VPN network to protect their data. Virtual The deployment of this type of network does not depend on the underlying physical infrastructure. It just adds an extra logical layer to the existing infrastructure. In most cases it also means that the underlying network is not owned by the user. The physical network is a public network shared amongst other users. To achieve this, protocol tunneling techniques are used. Private This refers to the privacy of the data that flows over the VPN. Because VPN traffic flows over shared public networks, there has to be a method to provide security. There are four important requirements in obtaining maximum security: • Confidentiality : Only the person, to whom the message is sent, can read the message. • Integrity : Assuring that the message is not modified during transport. Master thesis - 4de ing ICT 5 van Besien Koen 1.3 VPN networks Introduction to VPN • Authentication : Proving that the message is from the right person and is not modified by an other person. • Non-repudiation : Assuring that once a message is sent, the sender cannot deny having sent the message and the receiver cannot deny having received the message. Network Even though it is virtual, a VPN is an extension of a company’s network infrastructure. This means that it can be made available to the rest of the company’s intranet. 1.3.2 Concepts used by a VPN To achieve the objective of a VPN, we have to make use of some extra technologies and mechanisms. The initial concept of the Internet is not designed for this kind of utilization. 1.3.2.1 Tunneling The exchange of data in a corporate intranet is rarely routable along the Internet. Either the enterprise uses a protocol that differs from the standard Internet protocol (IP) or the internal network address pool is only valid on the intranet. (We call these private addresses). By using tunneling protocols, we can encapsulate a non routable packet into a routable packet and send the data to our receiver along the Internet. By adding some encryption and signature mechanisms we can provide a secure data exchange. Examples of tunnel protocols are GRE, L2TP, PPTP and recently SSL. 1.3.2.2 Authentication The Internet is a widely used network with millions of computers and servers connected. All these entities can connect to the resources of the company. Thus it is highly necessary, when implementing a VPN, to assure the identity of all the users that connect to the companies resources via the VPN. We can obtain this by using proper authentication methods. 1.3.2.3 Encryption and signatures All VPNs rely on the use of a public and most of the time shared network. The confidentiality and integrity of the exchanged data are not assured by this public infrastructure. Master thesis - 4de ing ICT 6 van Besien Koen 1.3 VPN networks Introduction to VPN Virtual private networks make use of several encryption techniques and digital signatures to assure that only the right person can use the exchanged data (confidentiality) and that the data is not changed or modified during transport (integrity). An explanation of these techniques is to be found in section 2.8.2. 1.3.3 Common VPN scenarios We can use VPNs in several different contexts. I will explain the three most common scenarios. • Site-to-site VPN • Client-to-site VPN (Roadwarrior setup) • Extranet VPN 1.3.3.1 Site-to-site connection A Site-to-site connection is used to link branch offices with the company’s headquarters. This scenario securely interconnects trusted intranets within an organization. The security focus is both, protecting the company’s intranet against external intruders and securing the company’s data while it flows over the public Internet. It can totally replace leased lines or PVC networks. It will be less expensive, more secure, and globally accessible. One way to implement this VPN connection between the corporate offices is to purchase Internet access from an ISP (Internet Service Provider). Firewalls and VPN servers can be placed at the boundary of each of the intranets to protect the company’s traffic from intruders. With this scenario, the clients and servers do not need to support VPN technology, since the VPN capabilities, data authentication and encryption, are provided by the VPN servers. With this approach, any confidential information would be hidden from untrusted Internet users, with a firewall denying access to attackers. With this scenario, the company’s offices will be able to communicate securely with each other, whether local or far away. Through VPN technology, each branch office can also extend its existing intranet to incorporate the other branch intranets, building an enterprise-wide corporate network. Master thesis - 4de ing ICT 7 van Besien Koen 1.3 VPN networks 1.3.3.2 Introduction to VPN Client-to-site VPN A remote user (or roadwarrior), whether at home or on the road, wants to be able to communicate securely back to the corporate intranet. For example, an employee is at home or on the road but needs a file on a server within the intranet. By obtaining Internet access the employee can communicate with the server in the company’s intranet and access the required file. Oostende La Rochelle LAN LAN Paris LAN Figure 1.4: Site to site scenario La Rochelle LAN Figure 1.5: client to site scenario Master thesis - 4de ing ICT 8 van Besien Koen 1.3 VPN networks Introduction to VPN One way to realise this scenario is to use a remote access tunneling protocol. Another way is to use a VPN-enabled remote client and a VPN-enabled firewall; ideally, you can combine both solutions, which will provide the best protection. The client accesses the Internet via dial-up or a broadband connection to an ISP, and then establishes an authenticated and encrypted tunnel between himself and the firewall at the intranet boundary. By applying authentication between the remote client and the firewall, you can protect your intranet from unwanted IP packets. And by encrypting traffic that flows between the remote host and the firewall, you can prevent outsiders from sniffing the exchanged information. 1.3.3.3 Extranet VPN scenario A company wants their business partners to be able to access several resources on the corporate intranet. Because the company cannot control the business partners’ networks, the company has to build a secure gateway to provide the necessary information. By using a VPN the company can provide this in a safe and secure way. A VPN can be built between a client in a business partner’s intranet and the server in the company’s intranet. The clients can authenticate themselves to the firewall, directly to the server, or to both. Then a tunnel can be established to encrypt all data from the client, through the Internet, to the server. The big difference between an Extranet VPN and a site-to-site scenario is the fact that the business partner’s intranet is not a trusted network so an extra security level has to be added. 1.3.4 Advantages and inconveniences To compare the solutions, to interconnect branch offices with a headquarters, we can distinguish several parameters. • Costs. • Implementation time. • Performance. • Security. Master thesis - 4de ing ICT 9 van Besien Koen 1.3 VPN networks 1.3.4.1 Introduction to VPN Costs To set up a VPN network, you need only a proper Internet connection, when possible a high bandwidth connection. The cost of a connection nowadays is affordable for any company. The only extra costs are the extra hardware needed to set up your VPN. This is a big advantage over other solutions like leased lines or PVC/SVC’s. For these you have to count in the extra subscription costs that need to be payed to the service carriers. The extra costs are negligible in a VPN setup, when you want to add extra sites or roadwarriors. 1.3.4.2 Implementation time The biggest advantage of a VPN is the fact that it does not depend on a physical infrastructure. When there is an Internet connection present, it takes some weeks to implement everything in a big enterprise environment; but it only takes a couple of days in a normal company environment. Even if you want to add an extra site to an existing VPN it takes only a couple of hours to implement. The implementation of a PVC/SVC is much more complicated because you have to rely on your service carrier who has to implement the extra lines and routes. Leased lines can take some months or even a year, depending on the service provider. 1.3.4.3 Performance In this area, the VPN approach is not the best solution. Because a VPN makes use of a public infrastructure, parameters such as bandwidth, response time and QoS (Quality of service) are difficult to master by the network administrator. The performance of a VPN between two sites depends on the performance of the Internet between these two sites. But nowadays, the ISP networks have developed enough to provide a convenient service on which to implement a VPN. Leased lines or PVC/SVC networks do not suffer these public performance problems. The service carrier guarantees a good performance by using special techniques which are impossible on a public Internet. Master thesis - 4de ing ICT 10 van Besien Koen 1.3 VPN networks 1.3.4.4 Introduction to VPN Security A VPN relies on encryption methods which are very solid and secure. The generation of the encryption keys are handled by the owner of the VPN network. Due to this a VPN guarantees the exchanged data a high level of security. Leased lines are considered as the most secure network connections because it is a private line only used by the company. But the offered level of security depends on the company’s confidence in the service carrier. The service provider can eavesdrop on all the data that flows over the companies network. One solution is to implement the leased lines oneself but being quite impossible, unlikely to result. Another solution is to encrypt all the exchanged data, which brings us back to a VPN network. A VPN is the most vulnerable way to implement a WAN network, because of the public infrastructure used. Because of these problems, integrity and encryption are extensively employed to protect all the data. These techniques are explained in chapter 2. A brief overview of the several parameters is given in figure 1.6. Max leased leased leased VPN PVC/SVC PVC/SVC PVC/SVC Leased VPN VPN VPN PVC/SVC Performance Security Costs Implementation Figure 1.6: Comparison about VPN Master thesis - 4de ing ICT 11 van Besien Koen 1.3 VPN networks 1.3.4.5 Introduction to VPN Summary VPNs securely convey information across the Internet connecting remote users, branch offices, and business partners into an extended corporate network. ISPs offer cost-effective access to the Internet enabling companies to eliminate their current, expensive, leased lines. Advantages of a VPN : • Low costs. • Easy and fast implementation. • Data assured by several encryption methods. • Does not depend on the offered security of the ISP • Easy to convert and very adaptable to new upcoming technologies. • Easy access for roadwarriors. Disadvantages of a VPN : • Extra technical knowledge is necessary. • Performances are not guaranteed. Master thesis - 4de ing ICT 12 van Besien Koen Chapter 2 Cryptography 2.1 Introduction The objective of a VPN is to allow two computers to exchange data in the same way, they do so on a LAN. Because we are working in a corporate environment these data are confidential and thus securing the data is important. By employing a VPN all the data exchanges exist in a public network. Everybody can eavesdrop on the data that two computers are exchanging. The public line does not give any guarantee to secure the data. This is the job of the VPN. It has to offer several services to assure the confidentiality and the integrity of the data : encryption and hashing. Encryption makes it possible to encipher a message, so only the person who is allowed to read the message, can read the message. Hashing guarantees that the message is not modified during the transport of the message. Master thesis - 4de ing ICT 13 van Besien Koen 2.2 Modern encryption methods 2.2 Cryptography Modern encryption methods We can distinguish several cryptographic methods which deal with a VPN: • Symmetric ciphers • Asymmetric ciphers • Message digests • Digital signatures Four important requirements have to be achieved for maximum security: • Confidentiality : Only the person, to whom the message is sent, can read the message. • Integrity : Assuring that the message is not modified during transport. • Authentication : Proving that the message is from the right person and not is modified by an other person. • Non-repudiation: Assuring that once a message is sent, the sender cannot deny having sent the message and the receiver cannot deny having received the message. The non-repudiation of a message is an important requirement. For example in online bank transaction systems; once a transaction is performed, you cannot deny having carried out the transaction. If we want to build a secure VPN, we have to assemble the four cryptographic methods to achieve the four objectives of data security. 2.3 Algorithms and keys A cryptographic algorithm is a mathematical function that is used to encrypt and decrypt a message. An encryption algorithm encrypts plain text into ciphered text. The decryption algorithm decrypts the ciphered text into the plain text again. Master thesis - 4de ing ICT 14 van Besien Koen 2.4 Symmetric algorithms URGENT: Watch out for the new teacher! Cryptography Encrypt Decrypt Sdfdsfdsqf Sqfddsfdsqf sqdfdsfsdfsf URGENT: Watch out for the new teacher! Plaintext Cipher text Plaintext Figure 2.1: Encryption and decryption of a message. In order to explain the different algorithms some symbols need to be defined: plaintext =M ciphertext =C (2.1) encryption algorithm = E(M) decryption algorithm = D(C) All modern algorithms now use a key to encrypt and decrypt all messages. C = Ek (M) (Ciphertext is the encryption of the plaintext) (2.2) M = Dk (C) (The plaintext is the decryption of the ciphertext) The following equation must always be true Dk ((Ek (M )) = M The security of the encrypted data depends on two elements: • The invulnerability of the used algorithm. • The confidentiality of the used key. 2.4 2.4.1 Symmetric algorithms Objectives of symmetric algorithms Symmetric algorithms assure the security of the exchanged data by using several mathematical transformations on the plain text message. All these transformations use the same key for encrypting and decrypting the message. We call this key the shared key. The sender and receiver of the message have to have the same shared key to encrypt and decrypt the message. Master thesis - 4de ing ICT 15 van Besien Koen 2.4 Symmetric algorithms Cryptography Encrypt URGENT: Watch out for the new teacher! Decrypt Sdfdsfdsqf Sqfddsfdsqf sqdfdsfsdfsf URGENT: Watch out for the new teacher! Plaintext Cipher text Plaintext Figure 2.2: Symmetric algorithm with a shared key The key is distributed to the two communicating parties in a secure manner prior to the exchange of the encrypted data. Two of our goals are achieved, the confidentiality and authentication of the message. Confidentiality is assured because only the sender and receiver know the value of the shared key. The authentication is assured because the only one who can posses the key and thus cipher the message, is the sender of the message. 2.4.2 Implementation and examples We can distinguish two types of symmetric algorithms. Block ciphers and stream ciphers. Block ciphers encrypts the message, block by block. We cut the original message into several segments. The size of the blocks depends on the used method. (in general 64 bits). Key XY UI OP po YO Cipher text Plaintext Encryption su vg zr Figure 2.3: Block cipher Some examples of block ciphers are: DES, Triple DES, TwoFish and AES. AES is an algorithm designed by two Belgian researchers. It is adopted as the official standard by NIST. Master thesis - 4de ing ICT 16 van Besien Koen 2.4 Symmetric algorithms Cryptography Block ciphers are used to protect sensitive data. They can be used to send data over the Internet but then the keys have to be sent in another safer way. Block ciphering is also used by IPsec (see section 3.3) as part of its security layer. Stream ciphers encrypt the message in a stream, like a water flow. It carries out a XOR operation on every bit of the message with a stream of bits generated by the algorithm. Key XYZO SRP7 Y Cipher text Plaintext Figure 2.4: Stream cipher The most well known implementation is the SSL/TLS protocol (see section 3.4). This protocol is used a lot to assure the confidentiality and integrity of the exchanged data between a client and webserver. It was invented by Netscape Inc. 2.4.3 2.4.3.1 Possible attacks Bruteforce attacks A brute force attack is simply an attempt to try all possible cipher key combinations in order to find the one that unlocks the ciphertext. This is why this attack is also known as an exhaustive key search. The cracker makes no attempt to actually crack the key, but relies on the ability to try all possible key combinations in a reasonable amount of time. All encryption algorithms are vulnerable to brute force attacks. This method is quite straightforward, we recover the right key to decrypt the ciphertext by trying every possible key combination. For example to crack a DES encrypted message, researchers managed to design a machine that could do it in less than three days. It depends simply on the computer power you have. By augmenting the key size, the algorithms become more robust. AES for example uses a 128 bit key, so it would take trillions of years to crack this key by brute force! We can thus say that AES is brute-force proof. Master thesis - 4de ing ICT 17 van Besien Koen 2.5 Asymmetric algorithms 2.4.3.2 Cryptography Cryptanalysis Cryptanalysis is a science that tries to find flaws in the encryption algorithms in order to reduce the amount of keys that have to be tested. For example if we use an algorithm with an 128 bit key size and we can reduce the amount of possible keys from 2128 to 270 . This weakens the algorithm considerably. To date though, for AES, these flaws are only theoretical. 2.5 Asymmetric algorithms 2.5.1 Objectives of asymmetric algorithms Asymmetric algorithms also called public-key cryptography assures the data exchange by using two different keys which are mathematically related. Both keys can be used to encrypt/decrypt a message. The ciphered text can only be decrypted by the key which is associated with the encryption key. We distinguish two keys : Public key : This key can be distributed to everybody, thus being public. This key is used to cipher a message to send to the owner of the private key. It can also be used to decipher a message from the owner of the private key. Private key : This key is private and has to be kept secret. This key is used to decipher the message that is ciphered with the corresponding public key. It is also used to cipher a message that can be deciphered by the public key. Only the owner of the private key can read the messages encrypted with the related public key. It is imperative to keep the private key secret. The public key can be used to decrypt a message from the owner of the private key, in this way we can be sure that the message is sent by the right person. In figure 2.5 we see an example of a public key exchange. Master thesis - 4de ing ICT 18 van Besien Koen 2.5 Asymmetric algorithms Bob Cryptography Alice Unsecure medium Public key exchange Public Private (1) Public URGENT: Watch out for the new teacher! Kqsmjfdsqf Ldsqkjfmq qlmdskfj (3) Plaintext (2) Encrypt Public Private Kqsmjfdsqf Ldsqkjfmq qlmdskfj Ciphered text (4) Ciphered text Kqsmjfdsqf Ldsqkjfmq qlmdskfj Decrypt Private URGENT: Watch out for the new teacher! Plaintext Ciphered text Figure 2.5: Assymmetric algorithm with a public/private key exchange 1. Alice1 sends her public key to Bob over the unsecure medium 2. Bob uses Alice’s public key to encrypt the message. 3. Bob sends the encrypted message to Alice over the unsecure medium 4. Alice decrypts the message with her private key. 2.5.2 Implementation and examples Only four algorithms, RSA, ElGamal, Schnorr and ECC are suitable for both encryption and digital signatures. Another public-key algorithm that is designed to be used for secure digital signatures is DSA. Important objectives when designing an encryption scheme are the length of the key and the computational work involved in breaking a cipher. 1 By convention, I use Bob and Alice. These names were invented by Ron Rivest Master thesis - 4de ing ICT 19 van Besien Koen 2.6 Comparison Cryptography These algorithms depend on the fact that it is almost impossible 2 to calculate the private key out of the public key. Techniques used for this are huge prime numbers, discrete logarithms or elliptic curves. 2.5.3 Possible attacks When cracking an RSA key, researchers try to find a method to guess the prime numbers needed to calculate the private key out of the public key. The length of the key is important. A key of 512 bits can be factored in 7 months. So a key size of at least 1024 bits is required, to have a secure key. 2.6 Comparison We will now see that both algorithms, symmetric and asymmetric, can be used next to each other. Designers of security systems try to combine the advantages of both to obtain maximum security. The speed of execution of the symmetric algorithms as well as the limited key size, needed to set up a secure communication, makes these algorithms well suited for file encryption. These algorithms are extensively used in securing VPN networks. A drawback is that the key for encryption and decryption is the same. As soon as one of the keys is compromised, you have to use another key, on both sides of the communication channel. To be secure you have to have a different pair of keys for every person you want to communicate with. Managing all these keys involves a lot of organization; the way to negotiate the pair of keys being a weak point in these algorithms. Public-key cryptography became public after Whitefield Diffie and Martin Hellman proposed the concept of an exponential key exchange scheme. The biggest advantage of this method is the way you can spread the public key without compromising your security. Everybody who wants to send an encrypted message to a specific person just uses that person’s public key to cipher the message and only the person with the right private key can read the message. You only need one pair of public/private keys to exchange your data with a lot of people. You can set up a public database where everybody can get the public key of a person. The amount of keys necessary to communicate is much smaller and easier to manage. 2 impossible is a dangerous word to say in cryptography Master thesis - 4de ing ICT 20 van Besien Koen 2.7 Diffie-Hellman exchange scheme Cryptography Another important fact is that the private key is the responsibility of the owner and not of two persons. Public-key cryptography also assures the non-repudiation of the messages. It is impossible to deny having sent the message afterwards. If a message is encrypted with the private key, all parties who have the public key can decrypt the message. In this way it proves that the message is sent by the owner of the private key, the origin of the message is proven. We will combine both methods. For example we use the asymmetric algorithm to encrypt a random shared key and send this to our correspondent. The receiver can use this random shared key to encrypt his data using a symmetric algorithm and start communicating. This method will be explained in the next section 2.7. A short comparison of both methods: Advantages Symmetric Assymmetric Fast execution speed. Keymanagement is easy to handle. Size of the ciphertext is limited. Exchange of the public key is no problem. Disadvantages Keymanagement is exhausting. Slow execution speed because of bigger keysize. 2.7 2.7.1 Exchange of the shared key has Encrypted message is bigger in to be done in a safe way. size than the original plaintext. Diffie-Hellman exchange scheme How it works The Diffie-Hellman exchange scheme is an algorithm to prepare a secure communication. It is not used to cipher a message. It gives the possibility to negotiate a shared key by exchanging only public values. This method takes advantage of the easy computation of exponentials with a prime number p compared with the difficulty of computing discrete logarithms. Before the exchange starts, both sides need to agree upon two values g and p. These values have to be prime numbers and of a reasonable length. Master thesis - 4de ing ICT 21 van Besien Koen 2.7 Diffie-Hellman exchange scheme Bob Cryptography Unsecure medium Alice (3) Pub(B) = gXb mod p (1) Private value : Xb Public value : Pub(B) (2) Xa (4) Pub(A) = g mod p Pub(B) = gXb mod p (1) Private value : Xa Public value : Pub(A) Pub(A) = gXa mod p (2) shared key Sab Figure 2.6: Diffie-Hellman exchange 1. Alice and Bob generate two private random integers. Xa , Xb 2. Bob computes a public value Pub(b) = gXb mod p and send this to Alice. 3. Alice computes a public value Pub(a) = gXa mod p and send this to Bob 4. Alice computes key Sa = (gXb )Xa mod p 5. Bob computes key Sb = (gXa )Xb mod p As you can see, both keys Sa and Sb are the same and thus we have negotiated a shared key Sab over an insecure medium. This key can be used to secure further communication. 2.7.2 Possible attacks This method is vulnerable to a Man-in-the middle attack. The moment both sides want to start the exchange of public key values, an attacker can put himself in the middle of the conversation and intercept all communication. From that moment Bob and Alice are not communicating with each other anymore but with the attacker. Instead of creating one common shared key Sab , Bob creates a key Shb and Alice a key Sha with the attacker. Bob and Alice think they are communicating with each other secretly but in fact they are communicating with the attacker, who reads the data before sending it to the other side. Master thesis - 4de ing ICT 22 van Besien Koen 2.8 Hashing Cryptography A solution for this problem is adding an extra layer of security by using authentication. By this way it is possible to guarantee the origin of the exchanged messages and to notice if something has changed during transport of the messages. We call this method Diffie-Hellman STS or Station-to-station authentication. The way of adding authentication depends on the methods explained in section 2.8.2. 2.8 Hashing Hashing is a special way of encryption. It is irreversible. The hashing algorithm generates a fixed unique hash-message (We call it a message digest) out of the original message. The size of the message does not matter. It is impossible to recover the original message out of the hash-message. The hash message is considered as the digital fingerprint of the original message. It can be used to check if a message has been altered during transport. Because every hash is unique you always can detect if the integrity of the message has been changed. We can also guarantee the origin of the message by using hashing. The advantage of using a hashing algorithm, is the fixed size of the message digest and the speed of execution. 2.8.1 2.8.1.1 Integrity control How it works When we send data over a public network, we do not know what will happen with our data. It can be changed by a pirate or by the equipment our data passes by. The moment we send our message we lose control of it. We can guarantee the integrity of our message by calculating a digital fingerprint of the message. By using hashing the receiver can control if something went wrong during transport. Master thesis - 4de ing ICT 23 van Besien Koen 2.8 Hashing Cryptography Unsecure medium Bob Alice URGENT: Watch out for the new teacher! URGENT: Watch out for the new teacher! (2) (1) Hashing (3) URGENT: Watch out for the new teacher! ---------------------SsqdfeKLSQDKF SDljoiEjlkjielkjoijo URGENT: Watch out for the new teacher! ---------------------SsqdfeKLSQDKF SDljoiEjlkjielkjoijo (4) (4) Hashing URGENT: Watch out for the new teacher! ---------------------SsqdfeKLSQDKF URGENT: SDljoiEjlkjielkjoijo Watch out for the new teacher! ---------------------SsqdfeKLSQDKF SDljoiEjlkjielkjoijo Figure 2.7: Concept of hashing 1. Bob generates a hash of the message he wants to send. 2. Bob sends the message and the hash of that message. 3. Alice receives the message and generates a hash of the received message. 4. Alice checks if both the hashes are the same. If they are the same, the integrity of the message is assured. 2.8.1.2 Algorithms A full explanation of all the hashing methods will not be given but the most important will be indicated, MD5 and SHA-1. MD5 (Message Digest) Created by Robert Rivest, one of the inventors of the RSA algorithm. It is especially designed for 32-bit processors. The algorithm MD5 produces a 128-bit digest. MD5 is faster, but not as secure as SHA-1. SHA-1 (Secure Hash Algorithm) Created by NIST, SHA-1 is part of the U.S. Government’s DSS standard, and works with DES to create digital signatures. SHA-1 produces a 160-bit message digest. Master thesis - 4de ing ICT 24 van Besien Koen 2.8 Hashing Cryptography The message digest produced by SHA-1 is bigger than MD5 and so it is better resistant against brute force attacks. 2.8.1.3 Possible attacks To crack hashing algorithms, there are two possible methods: • Finding collisions in the algorithm. • Interception of the messages. A hashing algorithm creates a unique digital fingerprint of a message. If we find a method that gives us the same fingerprint but calculated out of another message then the algorithm is not resistant to collisions. If we can create the same fingerprint for two different messages, then the security is wholly compromised. Researchers discovered some flaws in the MD5 algorithm. Even by using a simple desktop Pentium computer they managed to produce two identical message digests out of two different messages.[1]. From that time on security experts have advised against using MD5. SHA-1 has a bigger message digest and is less vulnerable to collision attacks. The same group of researcher are trying to find flaws in SHA-1 but to date they have not succeeded. If we are using hashing mechanisms we are sure that the message is not altered during transport. But we are not sure who has sent the message. We cannot be sure about the origin of the message. An attacker can intercept the message and recalculate the message hash, because the hashing algorithms are public. To prevent this we have two options: • Show the hash message on a website and after downloading the message, they can check if the hash message is the same as shown on the website. • Another option is to make use of authentication methods to prevent the altering of the message hash by attackers. 2.8.2 Authentication To assure the origin of a message we need to combine the hashing methods, which take care of the message integrity, and the encryption methods, which assure the confidentiality of the Master thesis - 4de ing ICT 25 van Besien Koen 2.8 Hashing Cryptography message. Two techniques are used in the context of VPN networks. Digital signatures, by using RSA or DSS, and HMAC (Hashed message authentication code). 2.8.2.1 Digital signatures Digital signatures are created by using one of the hashing methods, SHA-1 or MD5. First we produce a message digest out of the message. Later we encrypt this hash message with our private key. The receiver can read the hash message by using the corresponding public key. By comparing the message digest that the receiver calculates he can be sure that the message has been sent by the person from whom he posses the public key. An important remark is the fact that we have to be sure that the public key we have received corresponds to the private key of Alice. If an attacker can intercept or change the public key and send us his public key, he can use his own private key to encrypt the message. By using certificates we can assure that a particular public key is associated with the right private key. I will talk about that in section 2.9. Figure 2.8 is an example of the concept of a digital signature: Bob Unsecure medium URGENT: Watch out for the new teacher! Alice URGENT: Watch out for the new teacher! Public key exchange (5) Hashing (1) URGENT: Watch out for the new teacher! ---------------------SsqdfeKLSQDKF SDljoiEjlkjielkjoijo (2) Hashing URGENT: Watch out for the new teacher! ---------------------SsqdfeKLSQDKF SDljoiEjlkjielkjoijo (4) (3) (6) Public key Alice URGENT: Watch out for the new teacher! ---------------------IouedkhjfozeIRezr kjfEZRQFdsfjflkjff URGENT: Watch out for the new teacher! ---------------------IouedkhjfozeIRezr kjfEZRQFdsfjflkjff Private key Alice (3) URGENT: Watch out for the new teacher! ---------------------IouedkhjfozeIRezr kjfEZRQFdsfjflkjff Figure 2.8: Concept of the digital signature Master thesis - 4de ing ICT 26 van Besien Koen 2.9 PKI Cryptography 1. Alice sends her public key to Bob. 2. Alice produces a hash-message by using MD5 or SHA-1 3. Alice encrypts the hash-message with her private key. 4. Alice sends the message and hash-message to Bob. 5. Bob calculates the hash-message out of the received message. 6. Bob decrypts the hash-message of Alice by using her public key. 7. Bob compares if both hash-messages are the same. 2.8.2.2 HMAC HMAC, short for ”Keyed-Hashing for Message Authentication” is used to assure the authenticity of the message. A HMAC key has to be exchanged before the actual transport of data starts. Before we apply the hashing algorithms to our message we attach the key. This key will get hashed with our message. The hash and the message without the key are sent to the receiver. When the receiver opens the message, he attaches the shared key to the message and compares the calculated hash with the one sent with the message. If an attacker changes our messages and attaches a new hash, he will be unable to reproduce our key and thus the receiver will know the message was altered during transport. By using HMAC we have a way to achieve non-repudiation. Because only our sender knows the key, we can prove that he indeed has sent the message. He can not go back and deny the origin of the message. This is an important feature for e-commerce. 2.9 PKI The public key is used to assure the confidentiality, integrity and authentication of the message. The origin of the public key is really important. When the public key, used to encrypt data or to sign a document, belongs to an attacker and not to the person we trust, the exchange of data cannot be assured. Master thesis - 4de ing ICT 27 van Besien Koen 2.9 PKI Cryptography To make sure that a public key belongs to a specific person, we make use of a PKI, a Public Key Infrastructure. A PKI guarantees a public key is associated with a specific private key by providing certificates. The authentication of the message sent with a certain key can be checked by using the certificate given by the PKI. 2.9.1 How does it work? The PKI distributes no keys, but digital certificates that include the public key. A certificate is a digital document that contains the public key and some information about the identity of the owner of the public key. The owner can be a person or a server, so this information depends on the entity you are dealing with. The PKI provides a secure link between the public key and the owner of the key. Figure 2.9 gives a simple example of a PKI setup: Bob CA Certification request Public Private Identification details (2) (1) Generate key pair Sign certificate Public Certificate Bob’s certificate (4) (3) Generate certificate Figure 2.9: Concept of a Public Key infrastructure 1. Bob generates a public/private key pair. 2. Bob sends his public key to the CA (Certification authority) 3. The CA checks the identity of Bob and generates a certificate with the public key and the identity data. 4. The CA signs the certificate with his private key. 5. Bob uses this certificate to prove the authenticity of the public key. To assure the authenticity of this certificate we need another certificate. We have two certificates. The first one is signed with a private key. This private key is associated with a public key that is included in a second certificate. By using the second certificate everybody can assure the authenticity of the first certificate. Master thesis - 4de ing ICT 28 van Besien Koen 2.9 PKI Cryptography But how can we assure the integrity of the second certificate? For that set up a chain of trust by using Certification Authorities (CA). These CAs take care of the certificates. To assure the trust of the CAs, we set up a hierarchical model. This structure starts with a Root CA that is trusted by everybody in the hierarchical chain. The CAs certify the identity (a unique name) and that identity’s public key. A CA checks this information and is responsible for keeping the user’s name and the associated public key. It certifies public keys, creates certificates, distributes certificates, and generates Certificate Revocation Lists (CRLs). Whenever a person loses his private key, or it gets stolen, the confidentiality/integrity/authentiticity of the communication with this entity can no longer be assured. By adding a certificate to a CRL, the CA knows that there is something wrong with the certificate and it rejects the certificate. Root CA Level 1 CA Level 1 CA Level 2 CA Level 2 CA Figure 2.10: Chain of trust 2.9.2 Certificates and VPN The exchange of certificates plays a major role in the deployment of a VPN. For example when deploying a SSL VPN, certificates are needed for: • The authentification of the server to the client. • The exchange of the symmetric key. • The authentification of the client to the server. The SSL/TLS protocol uses X.509 certificates to do this. Master thesis - 4de ing ICT 29 van Besien Koen Chapter 3 VPN Techniques 3.1 Introduction When implementing a VPN, two important requirements have to be ensured: • Create a tunnel to send the data over the interconnecting networks. • Secure the transmitted data by achieving the four important requirements in cryptography. By using tunneling techniques, we can send data intended for use within a private network, through a public network. The interconnecting routers in the public network are unaware that the transmission is part of a private network communication. Tunneling is done by encapsulating the private network data and protocol information within the public network transmission units. It allows the use of the Internet, which is a public network, to convey data on behalf of a private network. The security of the data is assured by combining several cryptographic methods into one security protocol. For example IPsec or SSL/TLS. 3.2 Tunneling protocols A tunneling protocol is a network protocol which encapsulates one protocol inside another. Tunneling may be used to transport a network protocol through a network which would not otherwise support it. A small overview of the most implemented tunneling protocols in the Master thesis - 4de ing ICT 30 van Besien Koen 3.2 Tunneling protocols VPN Techniques context of VPN networks will follow. All these protocols act on the datalink layer of the OSImodel. These protocols are: • GRE = Generic routing encapsulation. • PPTP = Point-to-point tunneling protocol. • L2F = Layer-two forwarding protocol. • L2TP = Layer-two tunneling protocol. The GRE routing protocol is used in the PPTP protocol. It acts as glue between the encapsulating and the encapsulated protocol. 3.2.1 Point-to-point tunneling protocol (PPTP) This protocol was originally developed by Cisco and licensed to Microsoft. It is used in the Microsoft Windows operating systems. PPTP makes it possible to encapsulate non-IP datagrams like AppleTalk, IPX and NetBios into IP datagrams so it can pass through an IP network like the Internet. The protocol is based on the PPP-protocol to set up the tunnel. PPP is a network protocol that acts on the datalink layer of the OSI-model. PPTP does not change the PPP protocol. PPTP only defines a new way, a tunneled way, of transporting PPP traffic. Most used in a network setup with ordinary telephone lines. A typical PPTP negotiation is as follows: 1. Client connects to a server via PPP. In most cases a server which is connected to the Internet via an ISP. 2. Setup of a control channel between client and PPTP server to negotiate the properties of the tunnel that we want to create. 3. Creation of the tunnel between the client and the PPTP server. The protocol used to encapsulate the PPP data is GRE. 4. From now on there is a direct link between a client and a PPTP server without using a PVC or leased line. Master thesis - 4de ing ICT 31 van Besien Koen 3.2 Tunneling protocols VPN Techniques 5. This is a datalink tunnel which can transport datagrams from one network to the other. Some remarks on this method, the tunnel is initially created by the client and the ISP does not notice anything of this tunnel. The traffic acts as normal network traffic. We call this voluntary mode. PPTP is a tunneling protocol, not a VPN protocol. PPTP relies on the underlying PPPprotocol for its encryption and authentication services. PPTP is currently being replaced by implementations of L2TP and/or IPsec because of security reasons. The weaknesses[2] of the PPTP protocol are specific to the Microsoft implementation. Virtually all other PPTP implementations are written to interoperate with Microsoft’s version, so they share the same weaknesses. . . 3.2.2 Layer Two Forwarding protocol (L2F) L2F creates a virtual tunnel between a client and host through a public network. The difference between PPTP and L2F is that L2F tunneling is not dependent on IP encapsulating; it is able to work with other protocols such as frame relay or ATM. Another important difference is the fact that the tunnel exists between the server of the ISP and the L2F server at the border of the company’s intranet. The client does not notice that there is a tunnel between both servers. We call this compulsory mode, the client does not have any choice in using the tunnel. This protocol never became an official protocol but it served as draft for the L2TP standard. 3.2.3 Layer-two Tunneling protocol (L2TP) L2TP is a combination of L2F and PPTP. L2TP provides techniques to create a tunnel connection that, instead of being terminated at the ISP’s server, is extended to the corporate intranet. The tunnel can be initiated either by the remote host (voluntary mode) or by the ISP’s server (compulsory mode). It is a tunneling protocol which has minimal built-in security. The client and server can authenticate each other during tunnel setup but L2TP depends on the PPP-protocol to protect the user’s data in the tunnel. An important drawback is that for example, once the control Master thesis - 4de ing ICT 32 van Besien Koen 3.3 IPsec VPN Techniques channel between client and server is set up, this channel is unprotected. The attacker can easily disturb the traffic in the tunnel by sending forged messages to the client or server. There is no message authentication in the PPP protocol so there is no protection against replay-attacks. Replay attacksofcan easily be prevented by isadding a sequence each message This process broad communication support only possible throughnumber detailed to standards. IPSec (IPand then Security Protocol) is an ever growing standard for providing encrypted communications over IP. Its authenticating the message. acceptance and robustness has fortified the IPSec as the VPN technology standard for the foreseeable future. There are several RFCs that define IPSec and currently there are over 40 Internet Engineering Another problem andaddress PPP encryption is of that are based on and a shared Task Force (IETF)with RFCL2TP drafts that various aspects the they standard’s flexibility growth.key. Once compromised, all paper previous and future traffic can be read. Because of all these drawbacks, L2TP The goals of this are to: is mostly combined with IPsec and to obtain security. • Introduce the IPSec standard the RFCsmaximum that make up the VPN technology. • Introduce the protocols of the IPSec suite and Key management. • Provide a technical explanation of the IPSec communication technology. 3.3 IPsec Building Blocks of a Standard IPsec a set of security developed by the Internet Engineering Task Force (IETF). TheisIPSec standard is usedprotocols to provide privacy and authentication services at the IP layer. Several RFCs are used to describe this protocol suite, and the interrelationship and organization of the documents are It is an official standard for network security. IPSec was designed for interoperability. When necessary for understanding the development process of the overall standard. correctly implemented, does of not affect networks and hosts that not support it. IPSec is As Figure 1 shows, sevenitgroups documents allow the separate aspects of do the IPSec protocol suite to be developedofindependently a functioning relationship is managed. independent the current while cryptographic algorithms. Itattained works and both with IPv4 and IPv6. Architecture ESP Protocol AH Protocol Encryption Algorithm Authentication Algorithm DOI Key Management Figure 1 Figure 3.1: An overview of the components in the IPsec standard The architecture is the main description document that covers the overall technology concepts and security considerations. It provides the access point for an initial understanding of the IPSec protocol suite. IPsec is designed to achieve the four important requirements in cryptography. Confidentiality, integrity authentication and non-repudiation. (See section 2.2) NetworkCare Whitepaper • 2 IPSec Virtual Private Networks: A Technical Review Master thesis - 4de ing ICT 33 van Besien Koen 3.3 IPsec VPN Techniques There are different types of protection provided by IPsec and there are also different modes for IPsec to operate in. 3.3.1 Security protocols There are two protocols to secure the data transfer. The AH and ESP protocols can be applied alone or in combination, to obtain a maximum level of security. These protocols use encryption mechanisms which are provided by the key management protocol. Both protocols can be implemented in transport or tunnel mode. These modes are explained in section 3.3.2 3.3.1.1 Authentication header (AH) The Authentication header (HA) was designed for integrity, authentication, and replay protection. There is no support for confidentiality! The ESP protocol was designed for this purpose. The AH is useful when the only concern is protection against modification of the data during transport. Processing an AH header is faster then a ESP header because of the lack of encryption. The AH header only authenticates the data and IP header. AH tries to protect all fields of an IP datagram. Only the fields of an IP datagram which changes during transfer are excluded (for example the TTL field in the IP header). The authentication is performed by using hashing mechanisms like HMAC-MD5 or HMAC-SHA1.(See section 2.8.2.2). The methods used are negotiated during the Security Association. Replay protection is provided by using a sequence number within the AH header. There are some important drawbacks when this protocol is used together with NAT (Network Address Translation), explained in section 3.3.5. IP Header AH Header Protected data Authentication Figure 3.2: A simple representation of the Authentication Header IP Header ESP Header Protected data ESP Trailer Confidentiality Master thesis - 4de ing ICT 34 Authentication van Besien Koen 3.3 IPsec 3.3.1.2 VPN Techniques Encapsulated security payload (ESP) The ESP protocol provides data integrity, authentication and confidentiality. The data transmitted is encrypted and authenticated. The difference between AH and ESP is that the ESP IP Header AH Header Protected data offers both, encryption and authentication. However, the authenticating properties are limited compared to the ones of the AH Authentication because the original IP header information is not included during the authentication process. IP Header ESP Header Protected data ESP Trailer Confidentiality Authentication Figure 3.3: A simple representation of ESP 3.3.2 Modes of communication The IPsec standard describes two modes of communication. The transport mode is used to protect upper layer protocols and only influences the data in the IP datagram. Tunnel mode encapsulates the entire IP packet to tunnel the communications in a secured communication. Transport mode is established only for VPN in a server to server or a client to server setup. The tunnel mode is used when there is a connection between two gateways. This is the most common setup. 3.3.2.1 Transport mode In transport mode, the IP datagram contains the security protocol (AH or ESP) located after the original IP header and before the encapsulated protocol such as TCP or UDP. When AH is used as security protocol, the protection is extended to provide integrity of the entire datagram by using the original IP header in the hashing process. The AH header is inserted into the original IP header. When ESP is used as security protocol, the protection, or hash, is only applied to the upper layer protocols contained in the datagram. The IP header information and options are not utilized Master thesis - 4de ing ICT 35 van Besien Koen 3.3 IPsec VPN Techniques in the authentication process. This is a disadvantage, since false packets can be delivered to keep the IPsec server busy. IP Header TCP/UDP Header IP Header AH Header Transported data TCP/UDP Header Transported data Authentication IP Header TCP/UDP Header IP Header ESP Header Transported data TCP/UDP Header Transported data ESP Trailer Authentication Confidentiality Authentication Figure 3.4: AH and ESP in transport mode 3.3.2.2 Tunnel mode Tunnel mode is an IP tunnel which deliversTCP/UDP authentication and/or data encryption. Tunnel mode IP Header Header Transported communications have two sets of IP headers: New IP Header • Inside IP header. AH Header IP Header TCP/UDP Header Transported data Authentication • Outside IP header. When the outside IP header contains the destination IP address of the VPN gateway. The inside IP Header TCP/UDP Header Transported data IP header contains the destination IP address of the final system behind the VPN gateway. The used security protocol appears after the outside IP header and before the inside IP header. New IP Header ESP Header IP Header TCP/UDP Header Transported data ESP Trailer Authentication When AH is used as security protocol, a new IP header has to be created whereafter the AH header and the original IP datagram are inserted. Master thesis - 4de ing ICT 36 Confidentiality Authentication van Besien Koen IP Header ESP Header TCP/UDP Header 3.3 IPsec Transported data ESP Trailer Authentication VPN Techniques Confidentiality When ESP is used as security protocol, the original IP datagram is encapsulated into a new IP Authentication datagram. The ESP header is inserted after the new IP header. The trailer and authentication data is added after the original IP datagram. The advantages of the tunnel mode are total protection of the encapsulated IP datagram and the possibility of using private addresses. New IP Header AH Header IP Header TCP/UDP Header Transported data IP Header TCP/UDP Header Transported data Authentication New IP Header ESP Header IP Header TCP/UDP Header Transported data IP Header TCP/UDP Header Transported data ESP Trailer Authentication Confidentiality Authentication Figure 3.5: AH and ESP in tunnel mode 3.3.3 Security associations (SA) A Security Association (SA) is the most fundamental part of the IPsec standard. An SA is a simplex connection between two IPSec systems which negotiates the necessary parameters of the connection. Each SA can be defined by three components: • Security Parameter Index (SPI) • Destination IP • Security protocol identifier. (AH or ESP) Master thesis - 4de ing ICT 37 van Besien Koen 3.3 IPsec VPN Techniques The SPI is used to identify different SAs with the same destination address and security protocol. The SPI is carried in the header of the security protocol (AH or ESP). To create a connection, we need two SAs to get the job done. One for each direction of the connection. When a connection requires both, authentication and confidentiality, two or more SAs must be created for each direction. We call this a SA Bundle. An important note, the SAs in the bundle do not have to terminate at the same endpoint. For example, a host could use an AH SA between itself and a gateway and an ESP SA that extends the connection to a host behind the gateway. The SA bundles can be used to set up all kinds of VPN scenarios. Each IPsec implementation has two databases which maintain the SAs during the communication setup. These databases are: • Security association database.(SAD) • Security policy database.(SPD) The Security Association Database contains information about the parameters of each SA. Possible parameters are encryption algorithms, sequence numbers, protocol mode or SA lifetime. The Security Policy Database specifies what has to be done with the packets in the IP traffic. The decision is based on parameters such as source, destination, inbound or outbound traffic, etc. It contains an ordered list of rules (policies), separate for inbound and outbound traffic. Entries in this database are similar to firewall rules. 3.3.3.1 Example of IPsec traffic treatment When treating the traffic produced by an IPsec stream, we distinguish to types of traffic that have to be treated. Inbound and outbound traffic. To get this job done, we make use of the two security databases SPD and SAD. For inbound traffic, an IPsec negotation happens as follows: Master thesis - 4de ing ICT 38 van Besien Koen 3.3 IPsec VPN Techniques Transport 4 3 1 SPD Network 2 SAD Figure 3.6: Negotiation of inbound traffic Transport 1 2 1. Incoming traffic. SPD 3 2. Look up the SA ,that belongs to the incoming traffic frames, in the SAD and apply the 4 Network mechanisms described in the corresponding SAD entry. (decryption and authentication SAD methods) Transport 3. Localization of the SAD entry 4 in the SPD database to decide what policy should be used 3 SPD on the incoming frames.1 Network 2 4. If all verification methods pass, the system sends the frames to the upper transport layer. SAD For outbound traffic, the IPsec negotiation happens as follows: Transport 1 4 2 Network SPD 3 SAD Figure 3.7: Treatment of outbound traffic 1. The data from the upper layer enters the IPsec control system. 2. Consult the SPD database to decide what policy should be used on the data. The possible policies are: • Applying the IPsec security methods onto the data. • Transporting the data without adding IPsec security. Master thesis - 4de ing ICT 39 van Besien Koen 3.3 IPsec VPN Techniques • Rejecting the data. 3. When a IPsec application is chosen, we look up the corresponding entry in SAD. The system can perform two actions based on this SAD entry: • If an SA is found, the described parameters and algorithms are applied on the data. • Otherwise the system creates a new SA and performs the negotiated algorithms on the data. 4. The IPsec data are sent over the attached public network. 3.3.4 Key management The security protocols in VPN networks use several algorithms for encryption and authentication. These methods are negotiated via security associations. It is important that all the communicating partners use the same methods during the information exchange. To do this, the IPsec protocol standard uses an automatic key exchange mechanism. The big advantage of this system is when you want to change the keys regularly on all the gateways, clients and servers in the network, as this all goes automatically. Several methods were proposed as standard (SKIP, photuris, SKEME, Oakley or ISAKMP) none of them became the standard. It was the IKE system that won the battle. This system combines all the good properties of the other systems into one hybrid key management system. This is the most important part of the IPsec protocol suite. The secure exchange of keys is the most critical factor in establishing a secure connection. It does not matter how strong the authentication and encryption methods are, they are useless if your keys are compromised. . . 3.3.4.1 Internet key exchange (IKE) The Internet Key Exchange protocol is designed to allow two endpoints to properly set up their Security Associations, including the secret keys. IKE uses a combination of OAKLEY and ISAKMP (Internet Security Association Key Management Protocol) as a framework to establish a compatible security association for both communicating parties. IKE has a lot of configuration options. There is no general well known default case which everybody can implement. If these options are not the same on both sides of the connection, things will not work. The complexity of the system is one of its own biggest drawbacks. Master thesis - 4de ing ICT 40 van Besien Koen 3.3 IPsec VPN Techniques A new version of the IKE protocol, IKEv2 is designed to serve the needs of the users. This version solves the NAT problems of IKEv1 and reduces the amount of messages needed to establish a proper Security Association. 3.3.5 IPsec and Network Address Translation Because IPsec was originally designed for the IPv6 standard, it is not well suited for simultaneous use together with NAT. The problem of NAT is that this mechanism alters the data packets before they leave the network. It changes the IP address and port of an IP datagram. Because of this modification the integrity of the packets is changed and the packets become invalid. An overview of the problems with AH and ESP can be found below. 3.3.5.1 AH The AH performs an integrity control of the IP datagram by calculating a checksum of the whole datagram, including the IP header which posses the IP address and port. Because NAT modifies this IP header, the integrity of the message is altered and thus the message authentication fails. As result, AH, whether in Tunnel or Transport mode, is entirely incompatible with NAT. IP Header TCP/UDP Header IP Header AH Header Transported data TCP/UDP Header Transported data IP Header TCP/UDP Header IP Header ESP Header Authentication NAT IP Header modified AH Header TCP/UDP Header Transported data Authentication failed Figure 3.8: AH and NAT problems Master thesis - 4de ing ICT 41 van Besien Koen TCP 3.4 SSL/TLS 3.3.5.2 VPN Techniques ESP At first sight it could appear that NAT does not produce any problems when we use ESP because the authentication and encryption do not depend on the IP header which is modified by NAT. Nevertheless, NAT gives problems for ESP as well. The NAT gateway has to keep track of all connections that are passing through the gateway. When using TCP or UDP, this is commonly done with port numbers. These port numbers are protected by the used encryption and integrity mechanisms and so, it is impossible to change the port in an ESP packet. 3.3.6 Conclusion It is clear, IPsec and NAT produce a lot of problems; IPsec was not designed to work in cooperation with NAT. Several solutions and RFC are proposed to solve these problems. In future implementations, the problems with NAT and IPsec should disappear, but these solutions are not wide spread yet. When designing a VPN network, NAT is an important aspect to consider! 3.4 3.4.1 SSL/TLS Introduction Secure Sockets Layer (SSL) is a security protocol initially developed by Netscape and later by the IETF but then under the name Transport Layer Security (TLS). There are some differences between SSLv3 and TLSv1, but the protocol remains almost the same. The primary goal of the SSL protocol is to provide a secure data channel which ensures data confidentiality, authentication and integrity on top of the transport layer. SSL achieves these elements of security through the use of cryptography, digital signatures, and certificates. It can add security to any protocol that uses reliable connections (such as TCP, not UDP!). It is widely implemented for secure HTTP connections (HTTPS). SSL can also be used as a tunneling protocol to create a VPN network. Master thesis - 4de ing ICT 42 van Besien Koen 3.4 SSL/TLS 3.4.2 VPN Techniques How does it works? SSL makes use of a server-client communication setup. The client initiates the transaction and the server responds to the client and negotiates which cipher suites are used for encryption. We can distinguish three protocols within SSL : • The Handshake Protocol. • The Record Protocol. • The Alert Protocol. Handshake protocol Record protocol client Alert protocol server Figure 3.9: SSL protocols During the handshake, the client authenticates the server, certificates are exchanged, session keys are generated and encryption algorithms are agreed upon. When the session is initiated and the handshake is complete, the data transfer is encrypted during the Record Protocol phase. If there are any alarms during the session, the alert is attached to the packet and handled according to the Alert Protocol. 3.4.2.1 Handshake protocol Both server and client can authenticate themselves to the other. Mostly it is only the server who authenticates himself to the client. A typical handshake consists of these following steps: Master thesis - 4de ing ICT 43 van Besien Koen 3.4 SSL/TLS VPN Techniques 1. Client sends ClientHello message. 2. Server acknowledges with ServerHello message. 3. Server sends its certificate 4. Optional: server request client’s certificate. 5. Optional: client sends its certificate. 6. Client sends ClientKeyExchange message. 7. Client sends Certificate Verify message. 8. Both send ChangeCipherSpec. 9. Both send Finished messages. Client Hello Server Hello Server certificate Server key echange Request for client certificate Server Hello done Client certificate server client Certificate verification Change Cipher Spec Finished Change Cipher Spec Finished Figure 3.10: SSL handshake During the handshake protocol the encryption algorithms are negotiated and the server is authenticated to the client. SSL uses symmetric cryptography for the data encryption. Asymmetric cryptography is used to negotiate the shared key. Master thesis - 4de ing ICT 44 van Besien Koen 3.5 SSH 3.4.2.2 VPN Techniques Record protocol Once the shared key has been negotiated, the client and server can use it to encrypt the data. The SSL record protocol specifies a format for these messages. In general they include a message digest to ensure that they have not been altered and the whole message is encrypted using a symmetric cipher. 3.4.2.3 Alert protocol If either the server or client detects an error, it sends an alert containing the error. There are three types of alert messages: warning, critical, and fatal. Based on the received alert message, the session can be restricted or terminated. 3.5 SSH SSH can be used to secure connections between systems. It uses TCP/IP as tunneling protocol. It allows application traffic such as Telnet, FTP or POP3 to be both encrypted and compressed. SSH establishes a single TCP/IP connection from the client to the server. The data traffic is encrypted, and optionally compressed. Public/private keys can be used to verify both the user, and the remote system. The encryption cipher used, depends on the SSH version. • SSH 1 : offers Blowfish, DES, 3DES and RC4 • SSH 2 : offers 3DES, RC4 and Twofish SSH is not the best method for implementing VPN networks. It makes use of TCP to set up a connection and using TCP over TCP is not a good idea[3], being fairly ineffective. Long delays and frequent connection interruptions are to be expected. SSH is not designed to manage several tunnels at the same time and has some latency problems. It is well suited for simple and easy connections to a remote system but not for deploying a VPN network required for the setting up of a company. Master thesis - 4de ing ICT 45 van Besien Koen 3.6 Comparison 3.6 VPN Techniques Comparison The following figure gives a small overview about the described VPN protocols and their place in the OSI model. The table is a small comparison of the protocols and their functions. Application IPsec (IKE) SSL/TLS Transport Network IPsec (AH, ESP) NAT Datalink CHAP, MS-CHAP PPTP/L2TP Figure 3.11: VPN protocols in the OSI model Master thesis - 4de ing ICT 46 van Besien Koen Master thesis - 4de ing ICT IP,Frame Relay,ATM Yes GRE Yes Encapsulation protocol Possibility to encapsulate 47 Yes (via PPP) Yes (via PPP) No Yes Yes (via PPP) Yes No Yes Authentication Confidentiality Integrity Nat support packets packets, different from IP L2TP PPTP Yes (With IKEv2) Yes Yes Yes (via IKE) No IP IPsec Transport mode Yes (With IKEv2) Yes Yes Yes (via IKE) No IP IPsec tunnel mode Yes Yes Yes Yes No TCP SSL 3.6 Comparison VPN Techniques van Besien Koen Part II Implementation of a Linux based VPN solution Master thesis - 4de ing ICT 48 van Besien Koen Chapter 4 Open source VPN software solutions 4.1 Introduction Open source VPN solutions have attracted a lot of attention from researchers and developers. The availability of source code and open source licensing allows developers to customize and optimize these products for specific needs. Because Linux is used as the underlying operating system, deployment and installation is quick and easy, there is no need to learn a commercial operating system. Linux is a well know system and with the help of the community via mailinglists and newsgroups free technical support is always available. In this chapter an overview about several open source software solutions will be given. After that follows a comparison of the described solutions and a justification of my choice to use OpenVPN as VPN solution. 4.2 4.2.1 Open source software solutions Introduction There are two general approaches to VPNs, each with their own advantages and disadvantages. • Kernel space solutions • User space solutions Master thesis - 4de ing ICT 49 van Besien Koen 4.2 Open source software solutions 4.2.2 4.2.2.1 Open source VPN software solutions Kernel space solutions Overview Kernel space solutions are solutions which modify the kernel via patches. They are more complex and less portable than user space solutions. Most solutions are implementations of the IPsec security protocol. Either native supported by the kernel or via kernel patches. IPsec support is usually implemented in the kernel with key management carried out in user space. I will give a small overview of the most common solutions: FreeS/WAN The FreeS/WAN project was the first complete and open source implementation of IPsec for Linux. It consists of a kernel IPsec stack called KLIPS, as well as a key management daemon, called pluto, which acts in user space. The FreeS/WAN project was abandoned in 2004. Openswan and strongSwan are continuations of the FreeS/WAN project. Kame The Kame project implemented IPsec support for NetBSD, FreeBSD. Its key management daemon is called racoon. OpenBSD made its own ISAKMP/IKE daemon, simply named isakmpd which is ported to Linux. Netkey This is a kernel IPsec implementation written from scratch for the Linux kernel by Alexey Kuznetsov and David S. Miller. It serves now as the native IPsec implementation in the 2.6 Linux kernel. 4.2.2.2 Advantages and disadvantages Advantages of these solutions are: • Interoperability: Most of the operating systems have a IPsec client. • IPsec is a secure and flexible protocol which offers a lot configuration possibilities. • The IPsec implementation in Linux is very mature. • Mostly used to interconnect entire networks. Master thesis - 4de ing ICT 50 van Besien Koen 4.2 Open source software solutions Open source VPN software solutions Disadvantages are: • Installation and configurations difficulties. • Kernel patches have to be applied. • IPsec and NAT do not cooperate very well. 4.2.3 User space solutions User space solutions act in user space and therefore no special kernel modules or modifications (patches) are necessary. Most of them are easy to set up, quite flexible and portable across several operating systems. User space VPNs use a “virtual tunnel interface”, which takes care of the low-level networking functions, to achieve IP tunneling. Examples are Tinc, CIPE, vTun and OpenVPN. The user space solutions can be grouped based on the security protocol used. • Proprietary protocols that use standard encryption functions provided by OpenSSL. (OpenVPN, vTun,Tinc) • Proprietary protocols with their own implementation of the encryption functions.(cipe, PPTP, L2tpd) 4.2.3.1 OpenVPN http://openvpn.sourceforge.net/ OpenVPN is a SSL VPN solution which uses SSL to secure its control channel. It has two modes of operation. It can function as a simple point-to-point VPN which is very easy to configure. The second mode of operation is as a server with multiple clients. OpenVPN creates a virtual adapter which is assigned a VPN IP address. Once the connection with the server is established, any communication addressed to the VPN address of the server is encrypted. Configuration is simple and straightforward. Advantages of OpenVPN are: • OpenVPN secures all communication between server and client. Master thesis - 4de ing ICT 51 van Besien Koen 4.2 Open source software solutions Open source VPN software solutions • Compression methods are provided by the LZO package which is very fast. • Very detailed logging possible. • Several authentication methods are provided. • Encryption functions are provided by OpenSSL. • Active development. • Support for traffic shaping. • Very well documented. Some drawbacks: • Setup in server-client mode can become complex when using multiple clients. • The use of certification authorities and the generation of certificates can be problematic. 4.2.3.2 CIPE http://sites.inka.de/sites/bigred/devel/cipe.html CIPE is a IP tunneling software developed specifically for Linux. CIPE encapsulates encrypted IP datagrams in UDP. Since CIPE 1.5 it is possible to make use of a public key mechanism which gives a higher level of security. It consists of a custom kernel module and a user space program. The kernel module does the IP packet handling. In stead of using the universal TUN/TAP driver, CIPE uses its own network device. The configuration and the key exchange is performed by the user space program. Advantages of CIPE are: • Very good performance. • Small size. • Tunnels are very robust. Some drawbacks: Master thesis - 4de ing ICT 52 van Besien Koen 4.2 Open source software solutions Open source VPN software solutions • No compression methods. • Need to add an extra module to the Linux Kernel which makes the configuration a little bit more difficult. • Security flaws were found. • Use of its own implementation of the cryptographic algorithms. 4.2.3.3 vTun http://vtun.sourceforge.net VTun provides a method for creating tunnels over TCP/IP networks and allows to shape, compress and encrypt traffic in these tunnels. It is a user space implementation and does not require any modification of the Linux kernel. vTun does not appears to be in active development anymore. The latest stable version is distributed in 2003. This is one of the main reasons to avoid this solution. Security flaws[5] and [6] were found and it does not seems that they have responded to the security flaws found. Advantages of vTun are: • Easy configuration. • Traffic shaping. • Compression. Some drawbacks: • Only one tunnel per running vTun daemon. • development status. • Security flaws were found. • Use of its own implementation of the cryptographic algorithms. Master thesis - 4de ing ICT 53 van Besien Koen 4.3 Comparison 4.2.3.4 Open source VPN software solutions Tinc http://www.tinc-vpn.org/ Tinc is a VPN solutions which support encryption, authentication and compression. OpenSSL is used to encrypt the data and to check the message authentication. The tinc daemon supports multiple tunnels and it is easy to expand a working VPN network. It supports ethernet bridging and runs on several operating systems. It is especially designed for a site-to-site setup. Security flaws were found[5] and [7], but they discussed the flaws found[8] and it does not seem to be a big issue. Advantages of tinc are: • Easy configuration. • Traffic shaping. • Compression. • well suited for site-to-site setup. Some drawbacks: • Security flaws were found. • Documentation and HowTo. 4.3 Comparison The following table combines all the information about the described open source Linux-based VPN solutions. Master thesis - 4de ing ICT 54 van Besien Koen Master thesis - 4de ing ICT 55 key via pktool v1.6 Shared key Shared key / public Authentication Latest Version X.509 certificates + None Data integrity v2.0.7 (April 2006) MD5/SHA1 Blowfish BlowFish v2.6 (Juin 2003) RSA authentication MD5 Blowfish Solaris/MacOS MacOs/PocketPC Confidentiality Linux/FreeBSD UDP/TCP Propietary Linux/Windows/BSD UDP/TCP SSLv3 Linux/Windows UDP Kernel crypto API Operating systems protocol Encapsulating Security protocol algorithms OpenSSL BlowFish Custom Blowfish Encryption zlib (TCP),LZO driver Universal TUN/TAP vTun (UDP/TCP) LZO driver module None Universal TUN/TAP Custom cipe kernel OpenVPN algorithms Compression Kernel interface Cipe v1.0.4 (May 2005) RSA MD5/SHA1 Blowfish MacOs/solaris Linux/Windows/BSD UDP/TCP Propietary OpenSSL (UDP/TCP) zlib (TCP),LZO driver Universal TUN/TAP Tinc April 2004 (obsolete) RSA, Shared key available 3DES Linux UDP IPsec IPsec Available Kernel patch required FreeS/Wan 4.3 Comparison Open source VPN software solutions van Besien Koen 4.4 Conclusion 4.4 Open source VPN software solutions Conclusion The purpose of this thesis was to implement a site-to-site VPN network in Linux. The test computers were provided with Fedora Core 1, with a 2.4 kernel. Kernel modification and compilation were not possible options and would be time consuming, IPsec was thus no option. This leaves a user space VPN solution as the only choice. One of the best choices was OpenVPN. This is a powerful and easy to configure VPN solution which provides almost the same protection and functions as IPSec. SSL/TLS is used as security system, it is a well known and wide spread security protocol. After some research it seems to be one of the most secure and reliable software choices. No big security flaws have been found and it relies on the use of OpenSSL for its encryptions functions. Other solutions as CIPE, tinc and vTUN have or have had some serious security flaws [5]. In the case of CIPE these flaws were solved in version 1.6 by using the crypto api in the Linux 2.6 kernel. Only the 2.4 kernel was available on the test computers and so CIPE was not the most secure solution because I could not use the most recent version. OpenVPN is under active development and is provided with a very clear HOWTO and manual. Because of a lack of time, it was not possible to try other VPN solutions. But OpenVPN was adequate to meet the requirements of the project setup. Master thesis - 4de ing ICT 56 van Besien Koen Chapter 5 OpenVPN implementation 5.1 Overview The purpose of this project was to create a site-to-site VPN network by using an open source Linux software solution. The solution used was OpenVPN. The following picture describes the network setup which has to be performed with OpenVPN. 254 Private network: 192.168.1.0/24 254 TUNNEL Public network: 10.2.10.0/24 Server: 10.2.10.183 254 253 Private network: 192.168.2.0/24 Figure 5.1: Performed network setup Master thesis - 4de ing ICT 57 van Besien Koen 5.2 What is OpenVPN OpenVPN implementation Extra requirements are : • The data exchange between both private networks have to be secured by a VPN tunnel with maximum security. • The clients of both networks have to be able to access a webserver on the public network. • Hosts on the public network can acces the machines on the private networks, only by using a secure SSH tunnel. This is a standard site-to-site scenario which is very easy to perform with OpenVPN. Firstly I explain the OpenVPN software suite secondly I explain the configuration options used to implement this scenario. 5.2 What is OpenVPN OpenVPN is a user space open source VPN solution which creates VPN networks by using the SSL/TLS security protocol. It is based on the OpenSSL library for its encryption functions so it provides all the necessary security algorithms needed for a secure network setup. OpenVPN can create tunnels on both the network and datalink layer of the OSI model. We call it a tunneled or bridged network implementation. Compression of the data is optional and provided by the LZO library. The tunnel is created by using the universal TUN/TAP driver available on most Linux systems. A TUN interface is a virtual network adapter that looks like a point-to-point network adapter but instead of using a wire it sends its data to a program in user space. A user space program can open the TUN device just like a file and read and write IP packets to and from it. A TAP interface is similar, but it emulates an ethernet adapter rather than a point-to-point adapter. We distinguish two modes of execution: bridge mode and tunnel mode. Bridge mode creates one virtual network where all connected machines use the same subnet configuration. This mode uses the TAP interface and supports broadcast messages over the LAN network. This is a useful solution when you want to interconnect Microsoft Windows networks. The file sharing protocol used in Windows, Netbios, relies on broadcast messages. This is a good setup for roadwarriors because no extra routes need to be added. A drawback of this mode is that Master thesis - 4de ing ICT 58 van Besien Koen 5.2 What is OpenVPN OpenVPN implementation efficiency and scalability are limited. Tunnel mode interconnects private networks by setting up routes between them. It is more efficient and easier to scale with big network setups. The configuration is easier but broadcast messages do not traverse the VPN network. A VPN network can be achieved by linking a local TUN/TAP virtual adapter with a remote TUN/TAP virtual adapter. The system treats this adapter as normal ethernet adapters and firewall rules; extra routes can also easily be implemented on these adapters. The IP packets from the TUN/TAP devices are encrypted and encapsulated into a UDP or TCP connection, and sent to a remote host. The remote host decrypts, authenticates, and de-encapsulates the IP packets. Both protocols UDP and TCP are provided but when using TCP as encapsulating protocol, it suffers some serious drawbacks[3]. UDP is an unreliable network protocol which does not suffer these latency problems. TCP is used in situations where firewalls and routers do not allow clients to receive UDP packets from the Internet. For example in Internet caf´es or university campuses. An important remark is that OpenVPN managed to use UDP and SSL/TLS in cooperation with each other. Regardless of the fact that SSL/TLS needs a reliable transport layer which UDP does not provide. The following drawing, taken from the OpenVPN website, gives an overview of this model. SSL/TLS -> Reliability Layer -> \ --tls-auth HMAC \ \ > Multiplexer ----> UDP Transport IP Encrypt and HMAC Tunnel -> using OpenSSL / --> / Packets This model has the benefit that SSL/TLS sees a reliable transport layer while the IP packet forwarder sees an unreliable transport layer. The reliability and authentication layers are completely independent of one another. Master thesis - 4de ing ICT 59 van Besien Koen 5.3 OpenVPN configuration 5.3 5.3.1 OpenVPN implementation OpenVPN configuration Network setup OpenVPN provides a point-to-point mode to create a site-to-site VPN scenario. I make use of the routing mode because it is more efficient and easier to set up. The following figure shows the address setup used. LAN A: 192.168.2.0/24 LAN B: 192.168.3.0/24 10.2.10.7 .254 10.2.10.6 .254 10.2.10.0/24 VPN gateway VPN gateway 192.168.2.1 192.168.3.1 VPN tunnel Tun1 = 10.8.0.1 Tun1 = 10.8.0.2 Figure 5.2: Adress network setup The network configuration of both gateways : Gateway LAN A : Gateway LAN B: Local address eth0 : 192.168.2.254 External address eth1: 10.2.10.7 TUN address : 10.8.0.1 Local address eth0: 192.168.3.254 External address eth1: 10.2.10.6 TUN address : 10.8.0.2 There is no automatic IP configuration with DHCP. All network addresses are fixed and manually provided. The tun devices use addresses which differ from one of the interconnected networks, this to make sure there are no IP address conflicts. Extra routes and IP forwarding are added to both gateways, to let clients of both networks connect to the public network’s webserver. The following script is an example of the network setup on one of the gateways.(See appendix A.1) Master thesis - 4de ing ICT 60 van Besien Koen 5.3 OpenVPN configuration OpenVPN implementation #! /bin/sh # define several parameters # # NETWERK A # LAN = 192.168.3.254 eth0 # INTERNET = 10.2.10.6 eth1 LAN="192.168.2.254" LAN_NET="192.168.2.0/24" INTER="10.2.10.7" INTER_NET="10.2.10.0/24" # flush route table and configure interfaces /sbin/ip route flush all /sbin/ifconfig eth0 $LAN /sbin/ifconfig eth1 $INTER /sbin/route add -net $LAN_NET dev eth0 /sbin/route add -net $INTER_NET dev eth1 # Ip Forwarding on echo 1 > /proc/sys/net/ipv4/ip_forward 5.3.2 Firewall rules Firewall rules were added via a shell-script (see appendix A.2). The firewall used is IPtables this is the standard firewall in the Linux 2.4 kernel. The script provides following security measures: • Prevent external packets from using the loopback address. • Check incoming packets if they have a correct IP address. • Allow Ping, SSH and www. Master thesis - 4de ing ICT 61 van Besien Koen 5.3 OpenVPN configuration OpenVPN implementation • Allow incoming OpenVPN packets. • Allow packets from private subnets. • keep state of connections from local machine and private subnets. • Masquerade local subnet. 5.3.3 OpenVPN setup OpenVPN provides two security modes. • A static key setup • A asymmetric key private/public key exchange 5.3.3.1 Static key setup The static key setup is the easiest setup but it is not the most secure way. The keyfile has to be sent beforehand in a secure way. This method is common in a site-to-site scenario where the shared key is beter protected than in a roadwarrior setup. OpenVPN is executed as a daemon in a shell-script. The shared key can be generated via the openSSL library. The used command to peform this: openvpn --genkey static.key After OpenVPN is executed and a connection is made, extra routes need to be added to route the traffic via the VPN tunnel. Next script is an example of a shared key setup. Master thesis - 4de ing ICT 62 van Besien Koen 5.3 OpenVPN configuration OpenVPN implementation #----------------------Setup of the OpenVPN Tunnel----------------------# #--daemon Become a daemon after all initialization functions are completed. #--dev $DEVICE \ which device tun/tap #--ifconfig $LOCALIP $REMOTEIP \ #--secret $KEYFILE \ set up both end of the tunnels We make use of a shared key #--persist-tun \ # TUN interface would be closed and reopened whenever the tunnel was # interrupted, which would mean losing the routing entries for the tunnel # and dropping all connections. #--keepalive 15 45 #--writepid /var/run/openvpn-${DEVICE}.pid Write OpenVPNs main process ID to file. #--verb 3 the amount of debugmessages shown in the logfile /usr/sbin/openvpn --daemon\ --dev $DEVICE\ --remote $REMOTE\ --ifconfig $LOCALIP $REMOTEIP\ --secret $KEYFILE\ --persist-tun\ --keepalive 15 45\ --writepid /var/run/openvpn-${DEVICE}.pid\ --verb 3 --log-append openvpn #----------------------After TUNNEL is established---------------- # extra route for clients /sbin/route add -net $REMOTE_NET gw $LOCALIP echo $LOCALIP echo "route added via vpn" Master thesis - 4de ing ICT 63 van Besien Koen 5.4 Conclusion 5.3.3.2 OpenVPN implementation PKI setup For this setup, one of the communicating peers has to act as a server the other as a client. this is necessary for the TLS security exchange. The needed keys and certificates can be generated via scripts provided by OpenVPN. This method is almost necessary for a secure roadwarrior setup. These things are clearly explained in the HOWTO. The scripts can be found in appendix A.3.2 5.4 Conclusion The purpose of this project was to create a site-to-site VPN network by using an open source Linux software solution. As mentioned last chapter, the software which was chosen is OpenVPN. It supports a point-to-point mode, needed for this kind of scenario. The final implementation was quite straightforward and performs without any problems. OpenVPN is very feature rich and gives a lot of debugging information when needed. This was very useful to understand how this solutions works and for problem solving. For a complete secure implementation some extra options have to be added: • Downgrade the OpenVPN daemon with user nobody level • Put the work directory of OpenVPN in a chroot jail. Master thesis - 4de ing ICT 64 van Besien Koen Part III Final conclusion Master thesis - 4de ing ICT 65 van Besien Koen Final conclusion Ultimately this thesis was successful. After much research I finally managed to implement the required site-to-site VPN network with an open source software solution in Linux. Thorough research of the possible solutions is performed and OpenVPN is chosen as one of the solutions which meets the requirements stated at the start of this project. Features such as compression and some performance tweaks can additionally be added in future work. OpenVPN is a state of the art security product that relies on the SSL/TLS security protocol. It acts in user space and is available on most modern operating systems. It is flexible and because of its ease of use, it is hard to make it insecure or to implement it incorrectly. Most of my time was spent learning the theory behind VPN networks, and learning the Linux network capabilities. This was not a waste of time but a very interesting period of trial and error. I learned a great deal by making mistakes and then finding out the solutions. A comprehensive understanding of the theory and a good preparation before starting to implement a software solution are the key factors to successfully finishing a project like this. This thesis succeeded in its aim Master thesis - 4de ing ICT 66 van Besien Koen Bibliography Work cited [1] Finding MD5 Collisions – a Toy For a Notebook, http://cryptography.hyperlink.cz , Vlastimil Kl´ıma,(05/05/2005) [2] Security flaws in the Microsoft implementation of PPTP http://www.schneier.com/paper-pptpv2.html, Schneier Bruce, (1998) [3] TCP over TCP is not a good idea http://sites.inka.de/~W1011/devel/tcp-tcp.html, O. Titz [4] IPsec far to complex! http://www.schneier.com/paper-ipsec.html,Schneier Bruce [5] Linux’s answer to MS-PPTP: an extensive security overview, http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt, Guttman Peter,(september 2003) [6] Security flaws in vtun. http://www.off.net/~jme/vtun_secu.html, Jerome Etienne [7] Security flaws in tinc. http://www.off.net/~jme/tinc_secu.html, Jerome Etienne [8] Tinc’s answer to the founded security flaws. http://www.tinc-vpn.org/security.html Master thesis - 4de ing ICT 67 van Besien Koen BIBLIOGRAPHY BIBLIOGRAPHY Bibliography [9] Les VPN, principes, conception et d´eploiement – 2 ´edition, Dunod, Rafael Corvalan, Ernesto Corvalan et Yoann Le Corvic, (2005) [10] Internet Security: Cryptographic principles , algorithms, Wiley, Man Youn Rhee, 2003 [11] IBM redbook: IP Network Design Guide 2nd edition, IBM, Martin W. Murhammer, KokKeong Lee, Payam Motallebi, Paolo Borghi, Karl Wozabal, 1999 [12] IBM redbook: TCP/IP Tutorial and Technical Overview 7th edition, IBM, Adolfo Rodriguez John Gatrell John Karas Roland Peschke, 2001 [13] A Comprehensive Guide to Virtual Private Networks, Volume I: IBM Firewall, Server and Client Solutions, IBM, Martin Murhammer, Tim Bourne, Tamas Gaidosch, Charles Kunzinger, Laura Rademacher, Andreas Weinfurter, 1998 [14] Information security guide: Computer, Internet and Network Systems Security, S.K.PARMAR [15] LATEX COMPANION – 2e ´edition, Paris, Pearson Education France, Frank Mittelbach et Michel Goossens, 2005 [16] l’Essentiel de LATEX et GNU-Emacs - Manuel de r´ealisation de documents scientifiques, Paris, Dunod, Dominique Rodriquez, 2000 Master thesis - 4de ing ICT 68 van Besien Koen Appendix A Configuration scripts A.1 Network setup script #! /bin/sh # define several parameters # # NETWERK A # LAN = 192.168.3.254 eth0 # INTERNET = 10.2.10.6 eth1 DEVICE="tun1" PORT="1194" LOCALIP="10.8.0.1" REMOTEIP="10.8.0.2" KEYFILE="./keys/static.key" LAN="192.168.2.254" LAN NET="192.168.2.0/24" INTER="10.2.10.7" INTER NET="10.2.10.0/24" REMOTE="10.2.10.6" REMOTE NET="192.168.3.0/24" Master thesis - 4de ing ICT 69 van Besien Koen A.2 Firewall setup script Configuration scripts # flush route table and configure interfaces /sbin/ip route flush all /sbin/ifconfig eth0 $LAN /sbin/ifconfig eth1 $INTER /sbin/route add -net $LAN NET dev eth0 /sbin/route add -net $INTER NET dev eth1 # Ip Forwarding on echo 1 > /proc/sys/net/ipv4/ip forward A.2 Firewall setup script #! /bin/sh # NETWoRK A # LAN = 192.168.2.254 eth0 # INTERNET = 10.2.10.7 eth1 DEVICE="tun1" PORT="1194" LOCALIP="10.8.0.1" REMOTEIP="10.8.0.2" LAN="192.168.2.254" LAN NET="192.168.2.0/24" INTER="10.2.10.7" INTER NET="10.2.10.0/24" REMOTE="10.2.10.6" REMOTE NET="192.168.3.0/24" Master thesis - 4de ing ICT 70 van Besien Koen A.2 Firewall setup script Configuration scripts # Loopback address LOOP=127.0.0.1 # Delete old /sbin/iptables rules # and temporarily block all traffic. /sbin/iptables -P OUTPUT DROP /sbin/iptables -P INPUT DROP /sbin/iptables -P FORWARD DROP /sbin/iptables -F # Set default policies /sbin/iptables -P OUTPUT ACCEPT /sbin/iptables -P INPUT DROP /sbin/iptables -P FORWARD DROP # Prevent external packets from using loopback addr /sbin/iptables -A INPUT -i eth1 -s $LOOP -j DROP /sbin/iptables -A FORWARD -i eth1 -s $LOOP -j DROP /sbin/iptables -A INPUT -i eth1 -d $LOOP -j DROP /sbin/iptables -A FORWARD -i eth1 -d $LOOP -j DROP # Anything coming from the Internet should have a real Internet address /sbin/iptables -A FORWARD -i eth1 -s 192.168.0.0/16 -j DROP /sbin/iptables -A FORWARD -i eth1 -s 172.16.0.0/12 -j DROP #/sbin/iptables -A FORWARD -i eth1 -s 10.0.0.0/8 -j DROP /sbin/iptables -A INPUT -i eth1 -s 192.168.0.0/16 -j DROP /sbin/iptables -A INPUT -i eth1 -s 172.16.0.0/12 -j DROP #/sbin/iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP # Block outgoing NetBios (if you have windows machines running # on the private subnet). Master thesis - 4de ing ICT This will not affect any NetBios 71 van Besien Koen A.2 Firewall setup script Configuration scripts # traffic that flows over the VPN tunnel, but it will stop # local windows machines from broadcasting themselves to # the internet. # /sbin/iptables -A FORWARD -p tcp --sport 137:139 -o eth1 -j DROP # /sbin/iptables -A FORWARD -p udp --sport 137:139 -o eth1 -j DROP # /sbin/iptables -A OUTPUT -p tcp --sport 137:139 -o eth1 -j DROP # /sbin/iptables -A OUTPUT -p udp --sport 137:139 -o eth1 -j DROP # Check source address validity on packets going out to internet /sbin/iptables -A FORWARD -s ! $LAN NET -i eth0 -j DROP # Allow local loopback /sbin/iptables -A INPUT -s $LOOP -j ACCEPT /sbin/iptables -A INPUT -d $LOOP -j ACCEPT # Allow incoming pings (can be disabled) /sbin/iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT # Allow services such as www and ssh (can be disabled) /sbin/iptables -A INPUT -p tcp --dport http -j ACCEPT /sbin/iptables -A INPUT -p tcp --dport ssh -j ACCEPT # Allow incoming OpenVPN packets # Duplicate the line below for each # OpenVPN tunnel, changing --dport n # to match the OpenVPN UDP port. # # In OpenVPN, the port number is # controlled by the --port n option. # If you put this option in the config # file, you can remove the leading ’--’ Master thesis - 4de ing ICT 72 van Besien Koen A.2 Firewall setup script Configuration scripts # If you taking the stateful firewall # approach (see the OpenVPN HOWTO), # then comment out the line below. /sbin/iptables -A INPUT -p udp --dport 1194 -j ACCEPT # Allow packets from TUN/TAP devices. # When OpenVPN is run in a secure mode, # it will authenticate packets prior # to their arriving on a tun or tap # interface. Therefore, it is not # necessary to add any filters here, # unless you want to restrict the # type of packets which can flow over # the tunnel. /sbin/iptables -A INPUT -i tun+ -j ACCEPT /sbin/iptables -A FORWARD -i tun+ -j ACCEPT /sbin/iptables -A INPUT -i tap+ -j ACCEPT /sbin/iptables -A FORWARD -i tap+ -j ACCEPT # Allow packets from private subnets /sbin/iptables -A INPUT -i eth0 -j ACCEPT /sbin/iptables -A FORWARD -i eth0 -j ACCEPT # Keep state of connections from local machine and private subnets /sbin/iptables -A OUTPUT -m state --state NEW -o eth1 -j ACCEPT /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT /sbin/iptables -A FORWARD -m state --state NEW -o eth1 -j ACCEPT /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Masquerade local subnet /sbin/iptables -t nat -A POSTROUTING -s $LAN NET -o eth1 -j MASQUERADE Master thesis - 4de ing ICT 73 van Besien Koen A.3 OpenVPN setup script A.3 A.3.1 Configuration scripts OpenVPN setup script Static Key setup #! /bin/sh # NETWORK A # LAN = 192.168.2.254 eth0 # INTERNET = 10.2.10.7 eth1 DEVICE="tun1" PORT="1194" LOCALIP="10.8.0.1" REMOTEIP="10.8.0.2" KEYFILE="/root/scripts/keys/static.key" LAN="192.168.2.254" LAN NET="192.168.2.0/24" INTER="10.2.10.7" INTER NET="10.2.10.0/24" REMOTE="10.2.10.6" REMOTE NET="192.168.3.0/24" # check if openVPN is installed # -x = true if file exists and is executable if [ ! -x /usr/sbin/openvpn ]; then exit 1 fi Master thesis - 4de ing ICT 74 van Besien Koen A.3 OpenVPN setup script Configuration scripts #----------------------Setup of the OpenVPN Tunnel----------------------# #--daemon # Become a daemon after all initialization functions #--dev $DEVICE \ which device tun/tap #--ifconfig $LOCALIP $REMOTEIP \ #--secret $KEYFILE \ set up both end of the tunnels We make use of a shared key #--persist-tun \ # # TUN interface would be closed and reopened whenever the tunnel was # interrupted, which would mean losing the routing entries for the tunnel # and dropping all connections. #--writepid /var/run/openvpn-${DEVICE}.pid Write OpenVPN’s main process to file /usr/sbin/openvpn --daemon\ --dev $DEVICE\ --remote $REMOTE\ --ifconfig $LOCALIP $REMOTEIP\ --secret $KEYFILE\ --persist-tun\ --keepalive 15 45\ --writepid /var/run/openvpn-${DEVICE}.pid\ --verb 3\ --log-append openvpn echo "Tunnel established" #----------------------After TUNNEL is established---------------# extra route toevoegen voor clients /sbin/route add -net $REMOTE NET gw $LOCALIP echo $LOCALIP echo "route added via vpn" Master thesis - 4de ing ICT 75 van Besien Koen A.3 OpenVPN setup script # -e true if file exists Configuration scripts # if file doesn’t exists quit while while true; do # check if the PID file still exists if [ ! -e /var/run/openvpn-${DEVICE}.pid ]; then break else #looking up number of pid PID="‘cat /var/run/openvpn-${DEVICE}.pid‘" fi # probing with ps, returns ”1” if process ID does not exist # -gt = groter dan # /dev/null is een virtual file waar ge naar schrijft ps "$PID">/dev/null 2>/dev/null if [ "$?"-gt 0 ]; then echo "openvpn is not running anymore" break else # now check if the process we found is really running openvpn if [ "‘ps -o comm \"$PID\" |tail -n 1‘"= "openvpn"]; then echo "check running proces openvpn" sleep 60 else break fi fi done # openvpn-server.sh can easily be called using an init entry in # /etc/inittab # Do some cleanup echo "Clean up pid file" rm -f /var/run/openvpn-${DEVICE}.pid Master thesis - 4de ing ICT 76 van Besien Koen A.3 OpenVPN setup script A.3.2 Configuration scripts Public key setup A.3.2.1 TLS-server setup #! /bin/sh # NETWERK A # LAN = 192.168.2.254 eth0 # INTERNET = 10.2.10.7 eth1 DEVICE="tun1" PORT="1194" LOCALIP="10.8.0.1" REMOTEIP="10.8.0.2" LAN="192.168.2.254" LAN NET="192.168.2.0/24" INTER="10.2.10.7" INTER NET="10.2.10.0/24" REMOTE="10.2.10.6" REMOTE NET="192.168.3.0/24" # check if openVPN is installed # -x = true if file exists and is executable if [ ! -x /usr/sbin/openvpn ]; then exit 1 fi #----------------------Setup of the OpenVPN Tunnel----------------------Master thesis - 4de ing ICT 77 van Besien Koen A.3 OpenVPN setup script # Configuration scripts #--daemon # Become a daemon after all initialization functions are completed. #--dev $DEVICE \ which device tun/tap #--ifconfig $LOCALIP $REMOTEIP \ #--secret $KEYFILE \ set up both end of the tunnels We make use of a shared key #--persist-tun \ # TUN interface would be closed and reopened whenever the tunnel was # interrupted, which would mean losing the routing entries for the tunnel # and dropping all connections. #--writepid /var/run/openvpn-${DEVICE}.pid Write OpenVPN’s main process ID to file. /usr/sbin/openvpn --daemon\ --dev $DEVICE\ --remote $REMOTE\ --ifconfig $LOCALIP $REMOTEIP\ --tls-server --dh /root/scripts/keys/dh1024.pem\ --ca /root/scripts/keys/tmp-ca.crt\ --cert /root/scripts/keys/server.crt\ --key /root/scripts/keys/server.key\ --persist-tun\ --keepalive 15 45\ --writepid /var/run/openvpn-${DEVICE}.pid\ --verb 3 --log-append openvpn echo "Tunnel established" #----------------------After TUNNEL is established---------------Master thesis - 4de ing ICT 78 van Besien Koen A.3 OpenVPN setup script # add extra routes for client Configuration scripts /sbin/route add -net $REMOTE NET gw $LOCALIP echo "route added via vpn" # -e true if file exists # if file doesn’t exists quit while while true; do # check if the PID file still exists if [ ! -e /var/run/openvpn-${DEVICE}.pid ]; then break else #looking up number of pid PID="‘cat /var/run/openvpn-${DEVICE}.pid‘" fi # probing with ps, returns ”1” if process ID does not exist # -gt = groter dan # /dev/null is een virtual file waar ge naar schrijft ps "$PID">/dev/null 2>/dev/null if [ "$?"-gt 0 ]; then echo "openvpn is not running anymore" break else # now check if the process we found is really running openvpn if [ "‘ps -o comm \"$PID\" |tail -n 1‘"= "openvpn"]; then echo "check running proces openvpn" sleep 60 else break fi fi done Master thesis - 4de ing ICT 79 van Besien Koen A.3 OpenVPN setup script # openvpn-server.sh can easily be called using an init entry in Configuration scripts # /etc/inittab # Do some cleanup echo "Clean up pid file" rm -f /var/run/openvpn-${DEVICE}.pid A.3.2.2 TLS-client setup #! /bin/sh # NETWERK B # LAN = 192.168.3.254 eth0 # INTERNET = 10.2.10.6 eth1 DEVICE="tun1" PORT="1194" LOCALIP="10.8.0.2" REMOTEIP="10.8.0.1" LAN="192.168.3.254" LAN NET="192.168.3.0/24" INTER="10.2.10.6" INTER NET="10.2.10.0/24" REMOTE="10.2.10.7" REMOTE NET="192.168.2.0/24" # check if openVPN is installed # -x = true if file exists and is executable if [ ! -x /usr/sbin/openvpn ]; then exit 1 fi Master thesis - 4de ing ICT 80 van Besien Koen A.3 OpenVPN setup script Configuration scripts #----------------------Setup of the OpenVPN Tunnel----------------------# #--daemon # Become a daemon after all initialization functions are completed. #--dev $DEVICE \ which device tun/tap #--ifconfig $LOCALIP $REMOTEIP \ set up both end of the tunnels #--persist-tun \ # TUN interface would be closed and reopened whenever the tunnel was # interrupted, which would mean losing the routing entries for the tunnel # and dropping all connections #--writepid /var/run/openvpn-${DEVICE}.pid Write OpenVPN’s process ID to file /usr/sbin/openvpn --daemon --dev $DEVICE\ --remote $REMOTE --ifconfig $LOCALIP $REMOTEIP\ --tls-client\ --ca ./keys/tmp-ca.crt\ --cert ./keys/server.crt\ --key ./keys/server.key\ --persist-tun --keepalive 15 45\ --writepid /var/run/openvpn-${DEVICE}.pid\ --verb 3 --log-append openvpn echo "Tunnel established" #----------------------After TUNNEL is established---------------- # add extra routes for clients /sbin/route add -net $REMOTE NET gw $LOCALIP echo "route added via vpn" Master thesis - 4de ing ICT 81 van Besien Koen A.3 OpenVPN setup script # -e true if file exists Configuration scripts # if file doesn’t exists quit while while true; do # check if the PID file still exists if [ ! -e /var/run/openvpn-${DEVICE}.pid ]; then break else #looking up number of pid PID="‘cat /var/run/openvpn-${DEVICE}.pid‘" fi # probing with ps, returns ”1” if process ID does not exist # -gt = groter dan # /dev/null is een virtual file waar ge naar schrijft ps "$PID">/dev/null 2>/dev/null if [ "$?"-gt 0 ]; then echo "openvpn is not running anymore" break else # now check if the process we found is really running openvpn if [ "‘ps -o comm \"$PID\" |tail -n 1‘"= "openvpn"]; then echo "check running proces openvpn" sleep 60 else break fi fi done # Do some cleanup echo "Clean up pid file" rm -f /var/run/openvpn-${DEVICE}.pid Master thesis - 4de ing ICT 82 van Besien Koen