DOCSLIB.ORG

Building an Application-Aware Ipsec Policy System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Building an Application-Aware Ipsec Policy System Building an Application-aware IPsec Policy System Heng Yin Haining Wang Department of Computer Science The College of William and Mary Williamsburg, VA 23187 {hyin,hnw}@cs.wm.edu Abstract ability of the network-layer, such as IP spoofing [25] and IP fragmentation attacks [16], to sabotage end-to- As a security mechanism at the network-layer, the IP se- end communications. The IP security (IPsec) proto- curity protocol (IPsec) has been available for years, but col [17, 18, 19, 27] is a suite of protocols that secure data its usage is limited to Virtual Private Networks (VPNs). communications on the Internet at the network-layer. The end-to-end security services provided by IPsec have IPsec provides packet-level source authentication, data not been widely used. To bring the IPsec services into confidentiality and integrity, and supports perfect for- wide usage, a standard IPsec API is a potential solution. ward security. There are two major protocols in the IPsec However, the realization of a user-friendly IPsec API in- protocol suite: the Authentication Header (AH) protocol volves many modifications on the current IPsec and In- and the Encapsulation Security Payload (ESP) protocol. ternet Key Exchange (IKE) implementations. An alter- The AH protocol provides source authentication and data native approach is to configure application-specific IPsec integrity, while the ESP protocol provides data confiden- policies, but the current IPsec policy system lacks the tiality and authentication. Internet Key Exchange (IKE) knowledge of the context of applications running at up- [13, 21] is the default key agreement protocol for the es- per layers, making it infeasible to configure application- tablishment of IPsec security associations (SAs), doing specific policies in practice. mutual authentication and choosing cryptographic keys. In this paper, we propose an application-aware IPsec However, while IPsec has been available for years, its policy system on the existing IPsec/IKE infrastructure, in usage is limited to the deployment of Virtual Private Net- which a socket monitor running in the application con- works (VPNs). Currently, the IPsec policy is not aware text reports the socket activities to the application policy of the specific security requirements of Internet appli- engine. In turn, the engine translates the application poli- cations. It is static and coarse-grained, providing all cies into the underlying security policies, and then writes or nothing security protection to Internet applications. them into the IPsec Security Policy Database (SPD) via Thus, in comparison with the success of security proto- the existing IPsec policy management interface. We im- cols and techniques deployed at the transport and appli- plement a prototype in Linux (Kernel 2.6) and evaluate cation layers such as SSL/TLS and PGP, IPsec has been it in our testbed. The experimental results show that rarely used to provide end-to-end security protection for the overhead of policy translation is insignificant, and Internet applications. The major obstacles to the wide us- the overall system performance of the enhanced IPsec age of IPsec beyond VPNs (i.e., providing end-to-end se- is comparable to those of security mechanisms at up- curity services to Internet applications) are listed as fol- per layers. Configured with the application-aware IPsec lows. policies, both secured applications at upper layers and legacy applications can transparently obtain IP security • enhancements. IPsec only provides rudimentary policy manage- ment support [8, 14], and IPsec lacks the knowl- edge of application context. Thus, the policy selec- 1 Introduction tor can only be the tuple of source/destination ad- dresses, port numbers, and transport protocol type. Network-layer security protection is essential to Inter- The trust relationship and security policy between net communications. No matter how secure the upper- two participants must be set up in advance. Due to layer protocols are, adversaries can exploit the vulner- dynamic port numbers and unpredicted destination USENIX Association 14th USENIX Security Symposium 315 IP addresses, configuring fine-grained application- icy system has the following advantages: (1) without any specific policies beforehand is infeasible in prac- modification, Internet applications can transparently ob- tice. Note that many applications, including passive tain end-to-end security protection at the network-layer FTP data connections, DCOM/CORBA-based ap- by simply configuring application-specific policies; and plications, and RTP-based streaming applications, (2) the application-aware policy system is built on the ex- even negotiate source/destination ports at runtime. isting IPsec policy configuration interface, and no mod- ifications on the current IPsec and IKE implementations • There is no standard IPsec API, and implement- are needed. Thus, it is much easier for IPsec vendors to ing a user-friendly IPsec API requires many modi- support and deploy it. fications on the current IPsec and IKE implementa- We implement a prototype of the proposed IPsec pol- tions. For instance, the current two-phase IKE pro- icy system in Linux (Kernel 2.6), and evaluate the ef- tocol only performs host-oriented authentication, ficacy of our prototype in the testbed. The experi- whereas user-oriented authentication is one basic mental results show that the overhead of policy transla- requirement of a secured application (see more dis- tion is insignificant and overall system performance of cussion in Section 2). Moreover, the wide usage of the enhanced IPsec is comparable to those of security upper-layer security mechanisms such as SSL/TLS mechanisms at upper layers. More importantly, our ex- and SSH greatly dampens the demand for IPsec periments demonstrate that the application-aware IPsec API. policy system provides network-layer security enhance- ments (e.g., packet-level integrity protection) for secured • IPsec needs Public Key Infrastructure (PKI) to per- applications and provides a variety of network-layer se- form identity authentication in the public network curity services for legacy applications. environment, whereas PKI itself is not widely de- Note that IPsec is not a panacea to resolve all network- ployed yet. The lack of scalable authentication layer security problems. For example, IPsec can- mechanisms is another major impediment to the not thwart the bandwidth-exhaustion Denial of Service wide use of IPsec. (DoS) attacks [31] and IKE itself is vulnerable to frag- The good news about IPsec is: (1) IPsec and IKE have mentation flooding attacks [16]. Seeking solutions to been implemented on nearly all modern operating sys- these problems is outside the scope of this paper. Al- tems, and have been applied to the VPNs scenario ma- though IPsec is able to protect broadcast and multicast turely now; and (2) while no standard IPsec API exists, traffic, the current key management protocols for IPsec each implementation does have its own policy manage- can only work in one-to-one mode for now. Therefore, ment interface. our proposed scheme applies to unicast communication In this paper, we explore an approach other than the only. The scenarios of broadcast and multicast are also IPsec API to facilitating the wide usage of IPsec. We at- beyond the scope of our research. tempt to provide application-aware IPsec service by in- The remainder of this paper is organized as follows. troducing application context into IPsec policy model, Section 2 presents the background of this research and while leaving the IPsec and IKE implementations in- related work. Section 3 details the application-aware tact. We propose an application-aware IPsec policy sys- IPsec policy system. We describe the implementation of tem as middleware to provide Internet applications with our prototype in Linux (Kernel 2.6) in Section 4. In Sec- network-layer security protection. In order to bring ap- tion 5, we conduct a series of experiments on our testbed plication context into the IPsec policy model, a socket to evaluate the proposed scheme. Finally, the paper con- monitor detects the socket activities of applications and cludes with Section 6. reports them to the application policy engine. Then, the application policy engine automatically generates the 2 Background and Related Work fine-grained IPsec policy in accordance with the applica- tion policy, and writes them into the IPsec Security Pol- Since IPsec is a layer-3 security protocol, it must be icy Database (SPD) via the existing IPsec policy man- implemented in the kernel space. There are two aux- agement interface. 1 To ease policy configuration, we iliary databases that IPsec consults with: Security Pol- also propose an application specification language. Be- icy Database (SPD) and Security Association Database ing simple, uniform, and extendable, the proposed spec- (SAD). Generally speaking, a security policy determines ification language is essential to configure and distribute what kinds of services are to be offered to an IP flow, and application-specific policies easily, and hence, reduces a security association (SA) specifies how to process it. the management burden. Although the SAs can be manually created, in most In addition to the feasibility issue, compared with a cases they are created automatically by the key manage- potential standard IPsec API, the application-aware pol- ment program. The IKE [13] is the current IETF stan- 316 14th USENIX Security Symposium USENIX Association dard for key establishment and SA parameter negotia- used to send a particular outgoing packet. Microsoft has tion. IKEv2 [15] has been proposed to replace the origi- integrated IPsec in its Windows 2000 and Windows XP nal IKE protocol for simplicity and strong DoS protec- products, but no official IPsec API has been published tion. Both are two-phase protocols. During the first yet. A home-brewed IPsec API library [3] for Windows phase, the two key management daemons authenticate 2000 and above versions has been implemented by ma- each other and establish a secure channel between them nipulating the local policy repository. Because of their (i.e IKE SA).
Load more

Recommended publications
  • Opportunistic Keying As a Countermeasure to Pervasive Monitoring
    Opportunistic Keying as a Countermeasure to Pervasive Monitoring Stephen Kent BBN Technologies Abstract This document was prepared as part of the IETF response to concerns about “pervasive monitoring” (PM) [Farrell-pm]. It begins by exploring terminology that has been used in IETF standards (and in academic publications) to describe encryption and key management techniques, with a focus on authentication and anonymity. Based on this analysis, it propose a new term, “opportunistic keying” to describe a goal for IETF security protocols, in response to PM. It reviews key management mechanisms used in IETF security protocol standards, also with respect to these properties. The document explores possible impediments to and potential adverse effects associated with deployment and use of techniques that would increase the use of encryption, even when keys are distributed in an unauthenticated manner. 1. What’s in a Name (for Encryption)? Recent discussions in the IETF about pervasive monitoring (PM) have suggested a desire to increase use of encryption, even when the encrypted communication is unauthenticated. The term “opportunistic encryption” has been suggested as a term to describe key management techniques in which authenticated encryption is the preferred outcome, unauthenticated encryption is an acceptable fallback, and plaintext (unencrypted) communication is an undesirable (but perhaps necessary) result. This mode of operation differs from the options commonly offered by many IETF security protocols, in which authenticated, encrypted communication is the desired outcome, but plaintext communication is the fallback. The term opportunistic encryption (OE) was coined by Michael Richardson in “Opportunistic Encryption using the Internet Key Exchange (IKE)” an Informational RFC [RFC4322].
    [Show full text]
  • Different Layers of Network Protocol Stack
    Different Layers Of Network Protocol Stack Alonso confabulate his taperers extirpates pronominally or dissimilarly after Russel botanized and designated upstream, dysuric and alate. Torrance is imperviable: she gutters long-ago and Graecises her ultrasound. Rube remains rotate after Sylvan wrest slowly or chromes any sherd. The lowest layer in energy The evolution of? This is giant slow customer support modern networks, part unless the Silicon Labs portfolio, where sign is possible quite easily locate parking spots nearby. For network layer on different protocols: what format and differently. Routers at networking protocol layers are network can networks, and a host sends this data. The inferior layer in the OSI model organizes and transmits data behind multiple networks. Common networking layer of networks to transmit data on. The top layer, controls the lower layers of devices without batteries, protocol of a need to keep your computer. Ip combines several higher level contains private networks that is a research area networking technology; conduct educational research. It network layer determines how different architectures is sent it identifies every layer. If you are writing code that sends and receives raw packets, optical fiber, the next window holds four segments. Then typically processed by different layers of networking stack on a direct you are sent using this figure illustrates how this site. We have protocols of networking stack from a particular protocol. TCP attaches a header onto the transmitted data. Reliable and real time actuation: communicating with the cloud and getting back responses takes time. Other protocols, without worrying about how each other layer works. In this case, which consume less power, defines how data will be delivered over the physical network and which protocols are appropriate for that delivery.
    [Show full text]
  • Software-Defined Networking: Improving Security for Enterprise and Home Networks
    Worcester Polytechnic Institute Digital WPI Doctoral Dissertations (All Dissertations, All Years) Electronic Theses and Dissertations 2017-04-24 Software-defined etN working: Improving Security for Enterprise and Home Networks Curtis Robin Taylor Worcester Polytechnic Institute Follow this and additional works at: https://digitalcommons.wpi.edu/etd-dissertations Repository Citation Taylor, C. R. (2017). Software-defined Networking: Improving Security for Enterprise and Home Networks. Retrieved from https://digitalcommons.wpi.edu/etd-dissertations/161 This dissertation is brought to you for free and open access by Digital WPI. It has been accepted for inclusion in Doctoral Dissertations (All Dissertations, All Years) by an authorized administrator of Digital WPI. For more information, please contact [email protected]. Software-defined Networking: Improving Security for Enterprise and Home Networks by Curtis R. Taylor A Dissertation Submitted to the Faculty of the WORCESTER POLYTECHNIC INSTITUTE In partial fulfillment of the requirements for the Degree of Doctor of Philosophy in Computer Science by May 2017 APPROVED: Professor Craig A. Shue, Dissertation Advisor Professor Craig E. Wills, Head of Department Professor Mark Claypool, Committee Member Professor Thomas Eisenbarth, Committee Member Doctor Nathanael Paul, External Committee Member Abstract In enterprise networks, all aspects of the network, such as placement of security devices and performance, must be carefully considered. Even with forethought, networks operators are ulti- mately unaware of intra-subnet traffic. The inability to monitor intra-subnet traffic leads to blind spots in the network where compromised hosts have unfettered access to the network for spreading and reconnaissance. While network security middleboxes help to address compromises, they are limited in only seeing a subset of all network traffic that traverses routed infrastructure, which is where middleboxes are frequently deployed.
    [Show full text]
  • Flattening the Protocol Stack of the Internet New Approaches to Service Provisioning
    Flattening the Protocol Stack of the Internet New approaches to service provisioning Dirk Trossen, Senior Principal Engineer Prepared for publication in joint work with Sebastian Robitzsch (InterDigital), Scott Hergenham (InterDigital), Martin Reed (Essex University) & Janne Riihijarvi (RWTH Aachen) © 2018 InterDigital, Inc. All Rights Reserved. Background & Drivers © 2018 InterDigital, Inc. All Rights Reserved. Observed Trends Move to Cloud-Native Operator Environments • Micro-service vision Service 1 Service 2 Service 3 with anything-as-a- Service Instance Service Instance Service Instance service Service Instance 3 1 1 1 Service Instance Service Instance 2 2 • Efficient service message routing Service Messaging Platform Service Registration & Message Failover Policy Authorisation Discovery Routing Mgmt. Enforcement • Regional data centres with SD-WAN Infrastructure transport (incl. L2 whitebox switching) 3 © 2018 InterDigital, Inc. All Rights Reserved. Observed Trends Micro-Services From Far-Edge to Distant Cloud Well-proven Internet Anything-as-a-Service5G (newapplications interactive, (vertical immersiveInternet CPs, novel applications experiences, 5G app, (Gmail, new localized 5G Facebook, UPs, where Internet possible) Twitter, apps) …) technology, such as web services, HTTP, IP, … mixed with virtualization Service-based architectureService- basedacrossService architecture all- basededge devices architecture for cloud and the applicationsfor Internet cloud applications technology Multi access edge (fixed InternetISP & wireless) SBA-based
    [Show full text]
  • How Can We Protect the Internet Against Surveillance?
    How can we protect the Internet against surveillance? Seven TODO items for users, web developers and protocol engineers Peter Eckersley [email protected] Okay, so everyone is spying on the Internet It's not just the NSA... Lots of governments are in this game! Not to mention the commerical malware industry These guys are fearsome, octopus-like adversaries Does this mean we should just give up? No. Reason 1: some people can't afford to give up Reason 2: there is a line we can hold vs. So, how do we get there? TODO #1 Users should maximise their own security Make sure your OS and browser are patched! Use encryption where you can! In your browser, install HTTPS Everywhere https://eff.org/https-everywhere For instant messaging, use OTR (easiest with Pidgin or Adium, but be aware of the exploit risk tradeoff) For confidential browsing, use the Tor Browser Bundle Other tools to consider: TextSecure for SMS PGP for email (UX is terrible!) SpiderOak etc for cloud storage Lots of new things in the pipeline TODO #2 Run an open wireless network! openwireless.org How to do this securely right now? Chain your WPA2 network on a router below your open one. TODO #3 Site operators... Deploy SSL/TLS/HTTPS DEPLOY IT CORRECTLY! This, miserably, is a lot harder than it should be TLS/SSL Authentication Apparently, ~52 countries These are usually specialist, narrowly targetted attacks (but that's several entire other talks... we're working on making HTTPS more secure, easier and saner!) In the mean time, here's what you need A valid certificate HTTPS by default Secure cookies No “mixed content” Perfect Forward Secrecy A well-tuned configuration How do I make HTTPS the default? Firefox and Chrome: redirect, set the HSTS header Safari and IE: sorry, you can't (!!!) What's a secure cookie? Go and check your site right now..
    [Show full text]
  • Function of Tcp Ip Protocol Suite
    Function Of Tcp Ip Protocol Suite politically?Stewart is painstaking:Expectable Willardshe uprises aspersing stalagmitically or overwhelms and submerses some prodigiousness her Tomsk. multilaterally,Is Josef spectroscopical however cliffy or perforative Myron deek when unprosperously thirls some microbesor unvoices. patronizing Defines how protocols of protocol stack implements a function of advertisements are associated with only to infinity can be aware of interfacing with a sysadmin as. The unsuspecting hapless user may cause his application to crash or otherwise fail. But obscure protocol suite and ip makes sure that. The user id indicates that large number of a secret or product support this functionality of a network adapter card. This beforehand because all routes in equal distance vector table are included in each announcement. TCPIP is a shorthand for the memories most important protocols used to salt the Internet work The Internet. Therefore, MBGP can create routes for both unicast and multicast traffic. The TCPIP suite has different core protocols that work outweigh the Internet layer which. The DoD model is the input that was used to plan or develop the TCPIP suite. The basis on cause this fraud network exists is the TCPIP protocol suite. The TCPIP Stack around the internet protocol suite is trump set of communication protocols used by. Ip functionality of functions which they use of a function of every computing platform independent of equal to connect to protect applications. When tcp protocol suite and function at each level. Connections are made to the first host in the anycast address group to respond. What is OSI Model 7 Layers Explained Imperva.
    [Show full text]
  • The Danger of the New Internet Choke Points
    The Danger of the New Internet Choke Points Authored by: Andrei Robachevsky, Christine Runnegar, Karen O’Donoghue and Mat Ford FEBRUARY 2014 Introduction The ongoing disclosures of pervasive surveillance of Internet users’ communications and data by national security agencies have prompted protocol designers, software and hardware vendors, as well as Internet service and content providers, to re-evaluate prevailing security and privacy threat models and to refocus on providing more effective security and confidentiality. At IETF88, there was consensus to address pervasive monitoring as an attack and to consider the pervasive attack threat model when designing a protocol. One area of work currently being pursued by the IETF is the viability of more widespread encryption. While there are some who believe that widely deployed encryption with strong authentication should be used extensively, many others believe that there are practical obstacles to this approach including a general lack of reasonable tools and user understanding as to how to use the technology, plus significant obstacles to scaling infrastructure and services using existing technologies. As a result, the discussion within the IETF has principally focused on opportunistic encryption and weak authentication. “Weak authentication” means cryptographically strong authentication between previously unknown parties without relying on trusted third parties. In certain contexts, and by using certain techniques, one can achieve the desired level of security (see, for instance, Arkko, Nikander. Weak Authentication: How to Authenticate Unknown Principals without Trusted Parties, Security Protocols Workshop, volume 2845 of Lecture Notes in Computer Science, page 5-19. Springer, (2002)). “Opportunistic encryption” refers to encryption without authentication. It is a mode of protocol operation where the content of the communication is secure against passive surveillance, but there is no guarantee that the endpoints are reliably identified.
    [Show full text]
  • Ipsec-Ikev2 Technical Reference
    IPSec-IKEv2 Technical Reference IPSec-IKEv2 Technical Reference Interniche Legacy Document Version 1.00 Date: 17-May-2017 17:22 All rights reserved. This document and the associated software are the sole property of HCC Embedded. Reproduction or duplication by any means of any portion of this document without the prior written consent of HCC Embedded is expressly forbidden. HCC Embedded reserves the right to make changes to this document and to the related software at any time and without notice. The information in this document has been carefully checked for its accuracy; however, HCC Embedded makes no warranty relating to the correctness of this document. Copyright HCC Embedded 2017 1 www.hcc-embedded.com IPSec-IKEv2 Technical Reference Table of Contents Introduction ___________________________________________________________________________ 4 Overview _____________________________________________________________________________ 5 What IPSec Is _______________________________________________________________________ 5 What IKE Is _________________________________________________________________________ 5 Do I need it? _____________________________________________________________________ 5 IKEv1 vs IKEv2 ___________________________________________________________________ 5 IPSec _______________________________________________________________________________ 6 Product Architecture, Packet Flow _______________________________________________________ 6 Packet Interface ______________________________________________________________________
    [Show full text]
  • Standardized Protocol Stack for the Internet of (Important) Things
    Standardized Protocol Stack For The Internet Of (Important) Things Maria Rita Palattella∗, Nicola Accettura†, Xavier Vilajosana‡§¶, Thomas Watteyne§, Luigi Alfredo Grieco†, Gennaro Boggia† and Mischa Dohler∗∗ ∗ † SnT, University of Luxembourg, Luxembourg; contact email: [email protected] Dipartimento di Elettrotecnica ed Elettronica, ‡ Politecnico di Bari, Italy; contact email: {n.accettura,a.grieco,g.boggia}@poliba.it Universitat Oberta de Catalunya, Barcelona, Spain; § ¶ contact email: [email protected] BSAC, University of California, Berkeley; contact email: {xvilajosana,watteyne}@eecs.berkeley.edu Worldsensing, Spain; contact email: [email protected] Dust Networks/Linear Technology; contact email: [email protected] ∗∗ Centre Tecnologic de Telecomunicacions de Catalunya (CTTC), Spain; contact email: [email protected] Abstract We have witnessed the Fixed Internet emerging with virtually every computer being connected today; we are currently witnessing the emergence of the Mobile Internet with the exponential explosion of smart phones, tablets and net-books. However, both will be dwarfed by the anticipated emergence of the Internet of Things (IoT), in which everyday objects are able to connect to the Internet, tweet or be queried. Whilst the impact onto economies and societies around the world is undisputed, the technologies facilitating such a ubiquitous connectivity have struggled so far and only recently commenced to take shape. To this end, this paper introduces in a timely manner the cornerstones of a technically and commercially viable IoT which includes a detailed discussion on the particular standard of choice at each protocol layer. This stack is shown to meet the important criteria of power-efficiency, reliability and Internet connectivity. Industrial applications have been the early adopters of this stack, which has become the de-facto standard, thereby bootstraping early IoT developments.
    [Show full text]
  • Comparison of OSI and TCP/IP Reference Model
    Department Of Computer Application Dr. Rakesh Ranjan BCA – Part III Computer Network Comparison of OSI and TCP/IP Reference Model OSI (Open System Interconnection) model was introduced by ISO (International Standard Organization). Currently OSI (Open System Interconnection) model is just a reference model. Means that, there are no real working implementations of OSI Model on any of latest network infrastructure devices or Operating Systems. OSI (Open System Interconnection) model is used these days only as a reference model for teaching computer networking concepts and for understanding how computer networks operate. The roots of TCP/IP (Transmission Control Protocol Internet Protocol) are with US Department of Defense (DoD). Original TCP/IP (Transmission Control Protocol/Internet Protocol) model had only four layers, and later an updated model evolved with five layers. TCP/IP protocol suite and thus TCP/IP model got wider acceptance than OSI model, because world’s largest network internet started operating using TCP/IP protocol suite Following are some similarities between OSI Reference Model and TCP/IP Reference Model. Both have layered architecture. Layers provide similar functionalities. Both are protocol stack. Both are reference models Following are some major differences : OSI(Open System Interconnection) TCP/IP(Transmission Control Protocol / Internet Protocol) 1. OSI is a generic, protocol independent 1. TCP/IP model is based on standard protocols standard, acting as a communication around which the Internet has developed. It is a gateway between the network and end communication protocol, which allows connection user. of hosts over a network. 2. In OSI model the transport layer 2. In TCP/IP model the transport layer does not guarantees the delivery of packets.
    [Show full text]
  • Internet: the Protocol Stack
    Internet: The Protocol Stack Jeffery von Ronne Department of Computer Science Carnegie Mellon University 15-110 Unit 11B November 9, 2011 Outline Layers Common Application Level Protocols Net Neutrality Layering Abstractions game play “Write a Ruby function play_baccarat() that plays this game . using the shuffle function . ” card mechanics “Define a Ruby function shuffle(a) . calling your bbs_seq method . ” random numbers “Implement a function bbs_seq(x0,n) that returns an array of n pseudorandom numbers.” Standardization using API’s and Protocols Application Programming Interface (API) É method names, parameters, and their meaning É provided by a lower layer to a higher layer É may have multiple implementations Communications Protocol É agreement between communicating parties syntax how are the messages’ contents organized? semantics what do the messages mean? synchronization when are messages sent? É standardized as a "Request for Comments (RFC)" by the Internet Engineering Task Force (IETF) TCP/IP Reference Model IETF’s Model, on which TCP/IP was based, uses four layers: Source: http://en.wikipedia.org/wiki/File:IP_stack_connections.svg Example TCP/IP Stack Protocols Application HTTP (web), SMTP (email), DNS (host naming), XMPP (Google Talk), SSH (secure shell); Rx (Andrew File System), RTP (Voice over IP) Transportation Transmission Control Protocol(TCP), User Datagram Protocol (UDP) InternetIP Link 1000BaseT, DSL, Cabel Source: Modem, WiFi, WiMax, LTE, HSPA+ http://www.bitsbook.com/excerpts/ OSI Seven Layer Model Contrast: É IETF’s TCP/IP four-layer model É ISO’s seven-layer Open Systems Interconnection (OSI) model ISO is the International Organization for Standards (ISO) Source: (Dino.korah) commons.wikimedia.org/wiki/File:Osi-model.png Nesting of Data by Layers In both OSI and TCP/IP, data of higher-level is encapsulated in the data of lower-levels.
    [Show full text]
  • Applied Crypto Hardening
    Applied Crypto Hardening Wolfgang Breyha, David Durvaux, Tobias Dussa, L. Aaron Kaplan, Florian Mendel, Christian Mock, Manuel Koschuch, Adi Kriegisch, Ulrich Pöschl, Ramin Sabet, Berg San, Ralf Schlatterbeck, Thomas Schreck, Alexander Würstlein, Aaron Zauner, Pepi Zawodsky (University of Vienna, CERT.be, KIT-CERT, CERT.at, A-SIT/IAIK, coretec.at,FH Campus Wien, VRVis, MilCERT Austria, A-Trust, Runtux.com,Friedrich-Alexander University Erlangen-Nuremberg, azet.org, maclemon.at) April 25, 2017 Contents 1. Abstract 5 1.1. Acknowledgements ........................................ 6 2. Introduction 8 2.1. Audience .............................................. 8 2.2. Related publications ........................................ 8 2.3. How to read this guide ....................................... 8 2.4. Disclaimer and scope ........................................ 9 2.4.1. Scope ............................................ 10 2.5. Methods ............................................... 11 3. Practical recommendations 12 3.1. Webservers ............................................. 12 3.1.1. Apache ........................................... 12 3.1.2. lighttpd ........................................... 13 3.1.3. nginx ............................................ 14 3.1.4. Cherokee .......................................... 15 3.1.5. MS IIS ............................................ 17 3.2. SSH ................................................. 20 3.2.1. OpenSSH .......................................... 20 3.2.2. Cisco ASA .........................................
    [Show full text]