Network Security Essentials

Virtual Private Networks

• stunnel and native capabilities are fine for per-service

security, but what if we want to secure all
communications between clients and servers?
– Not everyone will remember https://

• What if we need to provide secure remote access to a

lot of different applications?

• Best answer: a “Virtual Private Network” (VPN)

Module Code and Module Title Title of Slides

 VPNs
• VPNs can be used as building blocks to construct
anything from a small secure telecommuting solution
to a large-scale secure WAN.
• VPNs tie together concepts from cryptography,
networking, and firewalls.
• VPNs still have a long way to evolve before they are
as easy-to-configure as other networking subsystems,
such as IP.
• We use VPNs to look at elements of operating
systems architecture
– You don’t have to configure one unless you want to

Module Code and Module Title Title of Slides

 Tunneling, Encapsulation
• Tunneling is the process of placing an entire packet within another
packet before it's transported over the Internet. That outer packet
protects the contents from public view and ensures that the packet
moves within a virtual tunnel.
• This layering of packets is called encapsulation. Computers or other
network devices at both ends of the tunnel, called tunnel interfaces,
can encapsulate outgoing packets and reopen incoming packets. IP
routers along the way do not parse the payload (the inner packet);
they only parse the outer IP packet as they forward it towards the
tunnel endpoint. Upon reaching the tunnel endpoint, encapsulation
is removed and the payload is forwarded along to its ultimate
destination.
• Applications using a VPN find them indistinguishable from a wide
area network implemented with dedicated circuits.

Module Code and Module Title Title of Slides

 Protocols

• Generic Routing Encapsulation (GRE), defined by RFC 2784, is a

simple protocol developed as a tunneling tool meant to carry any
OSI Layer 3 protocol over an IP network.
• Variants of Point-to-point Protocol (PPP) like L2F, PPTP, or L2TP
are also commonly used.
– These are not considered a proper VPN though: in a proper
VPN, the computers at each end of the tunnel encrypt the data
entering the tunnel and decrypt it when it arrives.
• There are VPNs that provide remote access through a browser-
based session using SSL. Many of these SSL VPNs, which have
been built around Web-based applications, install a Java or
ActiveX-based agent on the remote asset.

Module Code and Module Title Title of Slides

 IPSec - Brief history

When the original IP (Internet Protocol) specification was created, it

didn't really include much of a security mechanism to protect it from
potential hackers. There were 2 reasons for this:
1.Back then (35-40 years ago) most people thought that users and
administrators would continue to behave fairly well and not make any
serious attempts to compromise other people's traffic.
2.The cryptographic technology needed to provide adequate security
wasn't widely available - and in some cases not even invented!
IPSec was the first major effort to develop an IETF standard for secure
networking: first version in 1995.
Since then, alternatives have been developed, but IPSec is still very
important.

http://www.firewall.cx/networking-topics/protocols/127-ip-security-protocol.html

Module Code and Module Title Title of Slides

 IPSec – Secure IP
• IPSec can be configured to operate in Tunnel mode or
Transport mode
– Tunnel mode is the default: the entire original IP packet is
protected by adding a new IP header in front of the packet
• Meant for use between sites across public Internet, where
routers act as IPSec gateways to local networks
– Transport mode puts a copy of the original IP header with a new
protocol ID in front of the packet rather than a new IP header.
• Meant for use with another tunneling protocol like GRE
• Two IPSec security protocols are used, Encapsulating
Security Payload (ESP) and Authentication Header (AH)
– Either one can be used with Tunnel and Transport mode

Module Code and Module Title Title of Slides

 IPSec Tunnel
mode with ESP

IPSec Transport
mode with ESP

IPSec Tunnel
mode with AH

IPSec Transport
mode with AH

http://www.firewall.cx/networking-topics/protocols/870-ipsec-modes.html
 AH and ESP
Authentication Header (AH)
uses a hash algorithm on the packet header to help hide certain
information (like the sender's identity) until it gets to its destination.
•Provides source authentication
– Protects against source spoofing
•Provides data integrity
•Protects against replay attacks
•Protects against denial of service attacks

Encapsulating Security Payload (ESP)

•Provides all that AH offers, and provides data confidentiality
– the application data and ESP trailer is signed as one unit (like
AH), then encrypted, then signed again.
– the data being transported (payload) is encrypted with a
symmetric key algorithm
Module Code and Module Title Title of Slides
 Internet Security Agreement/Key
Management Protocol (ISAKMP)

ISAKMP provides a way to agree on security settings and exchange

a security key. ISAKMP is a two step process. First, the two
computers must agree on:
1) The encryption algorithm to be used for key exchange
2) Which algorithm they'll use for verifying message integrity
3) How connections will be authenticated: using public-key
certificate, a shared secret key or Kerberos.
Once all that has been sorted out, they start another round of
negotiations which cover:
a) Whether AH will be used, and the authentication protocol
b) Whether ESP will be used, and the encryption algorithm

Module Code and Module Title Title of Slides

 IPsec/IKE* Acronyms

• Security Association (SA)

– Collection of attribute associated with a connection
– Is asymmetric!
• One SA for inbound traffic, another SA for outbound traffic
• Security Policy Database (SPD)
– Store policies used to establish SAs
• Security Association Database (SADB)
– A database of Sas
• Security Parameter Index (SPI)
– A unique index for each entry in the SADB
– Identifies the SA associated with a packet

* IKE = Internet Key Exchange, short for ISAKMP

Module Code and Module Title Title of Slides
 IPSec in a nutshell

• IPSec is a complex modification to the IP stack itself.

• IPSec examines packets coming out of an IP interface,
determines if a security association exists with the
destination, and then tries to automatically encrypt
packets at one end and decrypt them at the other.
• Because IPSec considered the source and destination
addresses to be part of the secured payload, it broke
interoperability with NAT.
– Workarounds have been developed, but they are complicated.

Module Code and Module Title Title of Slides

 openvpn-2.0.9

• OpenVPN is a full-featured SSL VPN which can

accomodate a wide range of configurations, including
remote access, site-to-site VPNs, WiFi security, and
remote access with load balancing, failover, and fine-
grained access-controls.
• OpenVPN requires the bridge-utils package, which for
us is part of the core.

http://openvpn.net/index.php/open-source/documentation.html
• Be sure to see the "General" section of the FAQ:
• http://openvpn.net/index.php/open-source/faq

Module Code and Module Title Title of Slides

 What is a tun/tap interface?

• A tun interface is a device driver that that looks like point-

to-point network hardware to the operating system
• A tap interface is similar, but it emulates ethernet rather
than point-to-point.
• Rather being connected to a wire, the driver connects to
“user space”, where a program can open the device just
like a file and read and write packets from and to it.
(more on this concept later today)
• The modern, portable, easy-to-configure, user-space VPN
essentially links a local tun or tap device with a remote one
of the same type.

Module Code and Module Title Title of Slides

 openVPN and UDP

• IP packets from tun or tap virtual network adapters are

encrypted and encapsulated in UDP, and sent through a
tun or tap device to a remote host over the internet.
• The remote host receives, decrypts, authenticates, and
de-encapsulates the packets, pumping the UDP payload
into a tun or tap device at the other end.
• You can apply firewall rules to tun and tap interfaces in
the same way that you can apply them to ethernet
interfaces.
• You can apply routes and NAT to tun interfaces just like
you can apply them normally.

Module Code and Module Title Title of Slides

 VPN Configuration
The modern user-space VPN presents virtual tun and tap
interfaces as VPN endpoints.
So, as we might expect, the two major techniques for VPN
networking are routing (tun) and bridging (tap).
•Bridging is a technique for creating a virtual, wide-area
ethernet LAN, running on a single subnet.
•Routing solves the problem of a wide area VPN by using
separate subnets and setting up routes between them.

Module Code and Module Title Title of Slides

 Bridging

• Broadcasts traverse the VPN -- this allows software that

depends on LAN broadcasts such as Windows NetBIOS
file sharing and printer sharing to work.
• No route statements to configure.
• Works with any protocol that can function over ethernet,
including IPv4, IPv6, Netware IPX, AppleTalk, etc.
• Relatively easy-to-configure solution for road warriors.
• Less efficient than routing (all that broadcast traffic)
• Does not scale well.

Module Code and Module Title Title of Slides

 Routing

• Better scalability
• Allows better tuning of MTU for efficiency.
• Routes must be set up linking each subnet.
• Software that depends on broadcasts will not "see"
machines on the other side of the VPN.
• Works with IPv4 in general, and IPv6 only in some
special cases.

Module Code and Module Title Title of Slides

 The nuts and bolts of Bridging

• First generate a bunch of persistent tap devices on your

VPN server
• Then use the brctl tool to bridge them together with your
real ethernet adapter.
 When clients connect to the server, the tap interface at
their end can be assigned an IP address from the subnet
of the physical ethernet LAN connected to the server.
• So I could have a subnet 192.168.70.0/24 which is a
bridged ethernet.
• 192.168.70.5 could be a machine in Moscow, Idaho, and
192.168.70.6 could be a machine in Moscow, Russia.

Module Code and Module Title Title of Slides

 The nuts and bolts of Routing

• First generate a tun device on your VPN server

• Make sure port 1194 is open
• Configure routes as usual with route add or whatever
 When clients connect to the server, the tun interface at
their end must be assigned an IP address from a different
subnet than the physical LAN connected to the server.
• Remember that routing and firewall rules work for routing
between tun interfaces too!

Module Code and Module Title Title of Slides

 VPNs and firewalling

• One of the more troublesome security issues of VPNs

is the way that they create trusted relationships
between different networks.
– This can be bad, as in the case where a worm or virus infects
someone’s home machine, then jumps across the VPN to
corporate headquarters.
• Firewall rules applied to the VPN can create a trust
relationship between two networks that is more than
untrusted but less than fully trusted.

Module Code and Module Title Title of Slides

 OpenVPN

• Tun and tap devices can be interconnected to create a

complex routing topology.
 People have created multi-node WAN networks over tap devices
and actually run DHCP over the VPN so that clients can log into
the virtual ethernet and request an IP address.
• They sky is the limit as far as the complexity of network
you can build, but the basic building block is a VPN
daemon such as OpenVPN connecting tun or tap
devices on two different machines.

Module Code and Module Title Title of Slides

 openVPN v. IPSec

IPSec is done in “kernel OpenVPN runs in “user

space”, which means the space”, so it only needs the
IPSec (AH, ESP, IPCOMP) tun/tap driver module in the
and cryptography modules kernel
need to be in the kernel

The only additional package OpenVPN requires tun/tap

IPSec requires is one to devices to be created (as
manage the security policy appropriate), the bridge-utils
and security associations package, and something to
databases (ipsec-tools) manage certificates.

Module Code and Module Title Title of Slides

 SO …

• Where do tun/tap devices come from?

• How do I know what modules are loaded
into the kernel?

We need to understand
– device drivers
– modprobe, lsmod
– udev, /dev/ and /sys/

Module Code and Module Title Title of Slides

 Kernel modules and
Device Drivers
• Every device in the system is represented by a file - even
to read from memory is to read from a file.
• In kernel space, the virtual file system (VFS) decodes the
file type and transfers the file operations to the appropriate
channel, like a filesystem module in case of a regular file
or directory, or a device driver in case of a device file.
• All of the functions used to access a specific device are
jointly referred to as the device driver.
• Device drivers must be statically compiled into the kernel
or stored on disk as a dynamically loadable module.

Module Code and Module Title Title of Slides

 Device Nodes

• Device files (also called device nodes) are located in

the /dev/ directory.
• A device node is a file with type c (for "character"
devices, devices that bypass the buffer cache) or b (for
"block" devices, which go through the buffer cache).
• Each device file is assigned a major number and a minor
number.
• Traditionally, each device driver has a major device
number, and all device files for devices controlled by that
driver have the same major number.

Module Code and Module Title Title of Slides

 Device Files and udev

# ls -l /dev/sda
brw-rw---- 1 root disk 8, 0 March 9 07:56 /dev/sda
Shows type (b=block) and permissions (rw-rw----),
owner (root), group (disk),
major device number (8), minor device number (0),
date (March 9), hour (07:56) and device name (guess :-)
Modern Linux kernels allow multiple drivers to share major
numbers, but most devices that you will see are still
organized on the one-major-one-driver principle.
The kernel will assign a major/minor number pair when it
detects a hardware device.

Module Code and Module Title Title of Slides

 The kernel and udev

• The udev daemon listens to the netlink socket that the

kernel uses for communicating with user space
applications.
• For every detected device, the kernel creates an internal
device structure (in “kernel space”) and the driver core
sends an event to udev (in “user space”)
• If a device driver needs to be loaded, udev calls
modprobe with parameters provided by the kernel

Module Code and Module Title Title of Slides

 /dev/ and /sys/

• Once the proper device driver is loaded, udev processes

the event (see next) and creates the device node in /dev/
• Then, for every device the kernel has detected and
initialized, a directory with the device name is created
that contains files with device specific properties in /sys/

Module Code and Module Title Title of Slides

 udev rules

• Every event is matched against the set of rules provided

in /etc/udev/rules.d/*.rules.
• These rules can add or change event environment keys,
request a specific name for the device node to be
created, add symlinks pointing to the node or add
programs to be run after the device node is created.
• udev rules can match on any property the kernel exports
in /sys/ or adds to the event, and the rule may also
request additional information from external programs

Module Code and Module Title Title of Slides

 udev

• From the user space perspective, there is no difference

between a device coldplug sequence and device
discovery during runtime (hotplug).
• All devices that are plugged in or removed will cause an
uevent to be sent to the udev daemon, which runs an
event process to match against udev rules,
create/remove the device node and symlinks as
required, and possibly run specified programs to set
up/clean up after the device.

Module Code and Module Title Title of Slides

 modprobe

• modprobe is used to load and unload kernel modules

• lsmod is used to list currently loaded modules
• If you don’t know why a module is needed, use
modinfo to find information about it

There is a fuller explanation of in the class notes

Module Code and Module Title Title of Slides

 • Understanding VPN IPSec Tunnel Mode and IPSec Transport Mode. Written by
Administrator, 06 May 2012
http://www.firewall.cx/networking-topics/protocols/870-ipsec-modes.html
• IPSec - Internet Protocol Security. Written by Administrator, 25 April 2011
http://www.firewall.cx/networking-topics/protocols/127-ip-security-protocol.html
• ipsec.ppt - Somesh Jha, University of Wisconsin, 2006
http://pages.cs.wisc.edu/~jha/course-archive/642-spring-2006/SLIDES/IPsec.ppt
• BLUG talk - James Yonan 2003
http://openvpn.net/papers/BLUG-talk/BLUG-talk.ppt

Module Code and Module Title Title of Slides