Transcript Network Management

Network Security
Today’s Universities Campus
Perimeter Security
Anti-virus system
100 %
Firewalls
Remote access VPN,
using IPSEC
96.2 %
78.8 %
78.8 %
Access control
55.8 %
Content filtering
57.7 %
Intrusion Detection System
Remote access VPN
using SSL
Other *
Anti-virus system
Firewalls
Remote access VPN, using IPSEC
Access control
Content filtering
Intrusion Detection System
Remote access VPN using SSL
Other
25 %
11.5 %
* Other includes packet shapers,
proxy servers and smart-card
authentication.
Security challenges for remote offices
53.8 %
Lack of personnel/expertise
Complexity
Management costs are too high
Solution costs are too high
Lack of one-stop shopping from vendors
51.9 %
42.3 %
36.5 %
21.2 %
Agenda
NAT – the most common and quite effective
zero-mainetnance firewall
 PacketFilters and RealFirewalls
 SSL/TLS: transport layer security

– Easy to use
– CA infrastructure
– SSH

IPSec: network layer security (VPN)
– Difficult to deploy
– Transport or Tunnel mode
Use of Private Addresses

Routers in the public Internet will not route
packets whose destination are private
addresses
– 10.0.0.0/8,
– 172.16.0.0/12,
– 192.168.0.0/16

However, it is possible for routers in a private
network to route packets with private
addresses
 The same private addresses can be reused in
different private networks
Network Address Port Translation
(NAPT or Masquerading)
Network Address Translation
NAT is a major problem for media
communications!
 NAT:

Types of NAT
1.
2.
3.
4.
Full Cone
Restricted Cone
Port Restricted Cone
Symmetric
Full Cone

Any computer can send back data to an
open port.
Restricted Cone

Any computer can send back data to an
open port AFTER we send data to their IP.
Port Restricted Cone

Same as restricted cone but we need to
first send data to their IP AND the port
that will be allowed to send back.
Symmetric
Typical Call Setup
The Location Service is
being queries to check that
the destination IP address
represents a valid registered
device, and for its IP Address
DNS Server
DNS Query for
the IP Address of
the SIP Proxy of
the Destination
Domain
2
Location Service
The INVITE is
forwarded
4
3
A request is sent
(SIP INVITE) to
ESTABLISH a
session
1
SIP IP Phone
SIP Proxy
5
The request is forwarded to
the End-Device
SIP Proxy
SIP IP Phone
6
Media Transport
Destination device returns
its IP Address to the
originating device and a
media connection is opened
SIP Signaling and NAT
SIP itself is usually not the problem.
 The UAC/proxy/etc just send back SIP
packets based on the “rport“ tag (the
received data)
 SIP signaling intervals need to be
shorter than NAT timeout time.

Simple NAT Scenario
(Bob sending data)
Private address space
Alice
NSIS
NAT
Application-level signaling
NSIS signaling (Reserve Mode)
Data
NSIS signaling (Create Mode)
Public Internet
Bob
STUN Tests

4 tests needed.
RTP-gateway
NAT Limitations

Applications with IP-address content
– Need AGL (Application Level Gateway)
Applications with inter-dependent
control and and data sessions
 Translation of fragmented FTP control
packets
 NAT device can be a target for attacks

Packet Filtering

Packet filtering
– Access Control Lists
•
•
•
•

source/destination IP address
source/destination TCP/UDP port
protocol (TCP, UDP, ICMP, GRE,...)
IP/TCP header bits (fragmentation, QoS, Established)
Session filtering
–
–
–
–
Dynamic Packet Filtering
Stateful Inspection
Smart packet filtering
Context Based Access Control
SSL/TLS and IPSec
IPSec
Security at the network layer
 Can hide data and destination ports
 Don’t have to rewrite applications
 Using security gateways in tunnel mode,
can be done without reconfiguring hosts.

IPSec Architecture
Tunnel and Transport Mode

Authentication Header (AH)
– Authenticates the sender

Encapsulating Security Payload (ESP)
– Data encryption
– Can be done in two ways:
• Transport mode: only the transport layer segment is
encrypted
• Tunnel mode
– encrypt the entire IP datagram
– put it inside another IP datagram
Tunnel Mode
SSL and TLS
SSL designed by Netscape
 TLS IETF standard

– compromise between SSL and a Microsoft
protocol

SSL and TLS provide applications:
– Encryption
– Server authentication
– (Optional) client authentication

SSL programming libraries are pretty easy to
use
SSL Data Processing
SSL Record Format
SSL Handshake

Pretty complicated
– why HTTPS websites seem sooooooo slow.

Server (and client) authentication
 Negotiation of:
– Encryption algorithm
– MAC algorithm
– Encryption key

Must be done before any data transmission
SSL/TLS Overview

SSL = Secure Sockets Layer.
– unreleased v1, flawed but useful v2, good v3.

TLS = Transport Layer Security.
– TLS1.0 = SSL3.0 with minor tweaks (see later).
– Defined in RFC 2246.
– Open-source implementation at
http://www.openssl.org/.

SSL/TLS provides security ‘at TCP layer’.
– Uses TCP to provide reliable, end-to-end
transport.
– Applications need some modification.
– In fact, usually a thin layer between TCP and
SSL/TLS Basic Features

SSL/TLS widely used in Web browsers and
servers to support ‘secure e-commerce’ over
HTTP.
– Built into Microsoft IE, Netscape, Mozilla, Apache,
IIS,…
– The (in)famous browser lock.

SSL architecture provides two layers:
– SSL Record Protocol
• Provides secure, reliable channel to upper layer.
– Upper layer carrying:
• SSL Handshake Protocol, Change Cipher Spec.
Protocol, Alert Protocol, HTTP, any other application
protocols.
SSL Protocol Architecture
SSL
Handshake
Protocol
SSL
Change
Cipher
Spec
Protocol
SSL Alert
HTTP, other
Protocol
apps
SSL Record
Protocol
TCP
TLS: Transport Layer Security

formerly known as
SSL: Secure Sockets Layer
 Addresses issues of privacy, integrity
and authentication
– What is it?
– How does it address the issues?
– How is it used
What is TLS?
Protocol layer
 Requires reliable transport layer (e.g.
TCP)
 Supports any application protocols

HTTP
Telnet
TLS
TCP
IP
FTP
LDAP
TLS: Privacy
Encrypt message so it cannot be read
 Use conventional cryptography with
shared key

– DES, 3DES
– RC2, RC4
– IDEA
A
Message
$%&#!@
B
Message
TLS:Key Exchange
Need secure method to exchange
secret key
 Use public key encryption for this

– “key pair” is used - either one can encrypt
and then the other can decrypt
– slower than conventional cryptography
– share one key, keep the other private

Choices are RSA or Diffie-Hellman
TLS: Integrity

Compute fixed-length Message
Authentication Code (MAC)
– Includes hash of message
– Includes a shared secret
– Include sequence number

Transmit MAC with message
TLS: Integrity

Receiver creates new MAC
– should match transmitted MAC

TLS allows MD5, SHA-1
A
Message
MAC
B
Message’
MAC’
MAC
=?
TLS: Authentication
Verify identities of participants
 Client authentication is optional
 Certificate is used to associate identity
with public key and other attributes

A
Certificate
B
Certificate
TLS: Overview

Establish a session
– Agree on algorithms
– Share secrets
– Perform authentication

Transfer application data
– Ensure privacy and integrity
TLS: Architecture
TLS defines Record Protocol to transfer
application and TLS information
 A session is established using a
Handshake Protocol

Handshake
Protocol
Change
Cipher Spec
Alert
Protocol
TLS Record Protocol
TLS: Record Protocol
TLS: Handshake

Negotiate Cipher-Suite Algorithms
– Symmetric cipher to use
– Key exchange method
– Message digest function
Establish and share master secret
 Optionally authenticate server and/or
client

Handshake Phases
Hello messages
 Certificate and Key Exchange
messages
 Change CipherSpec and Finished
messages

X.509 Certificate Issues

Certificate Administration is complex
– Hierarchy of Certification Authorities
– Mechanisms for requesting, issuing,
revoking certificates
X.500 names are complicated
 Description formats are cumbersome
(ASN.1)

X.509 Alternative: SDSI
– SDSI: Simple Distributed Security
Infrastructure (Rivest, Lampson)
• Merging with IETF SPKI: Simple Public-Key
Infrastructure in SDSI 2.0
• Eliminate X.500 names - use DNS and text
• Everyone is their own CA
• Instead of ASN.1 use “S-expressions” and
simple syntax
• Name and Authorization certificates
TLS “Alternatives”
S-HTTP: secure HTTP protocol, shttp://
 IPSec: secure IP
 SET: Secure Electronic Transaction

– Protocol and infrastructure for bank card
payments

SASL: Simple Authentication and
Security Layer (RFC 2222)
6.2 SSH
SSH overview
 SSH architecture
 SSH security
 Port forwarding with SSH
 SSH applications

SSH Overview

SSH = Secure Shell.
– Initially designed to replace insecure rsh, telnet
utilities.
– Secure remote administration (mostly of Unix
systems).
– Extended to support secure file transfer and e-mail.
– Latterly, provide a general secure channel for network
applications.
– SSH-1 flawed, SSH-2 better security (and different
architecture).

SSH provides security at Application layer.
– Only covers traffic explicitly protected.
– Applications need modification, but port-forwarding
eases some of this (see later).
SSH Overview

SSH Communications Security (SCS).
– www.ssh.com.
– Founded by Tatu Ylonen, writer of SSH-1.
– SSH is a trademark of SCS.

Open source version from OpenSSH.
 IETF Secure Shell (SECSH) working group.
– Standard for SSH in preparation.
– www.ietf.org/html.charters/secsh-charter.html.

Long-running confusion and dispute over
naming.
SSH-2 Architecture
SSH-2 adopts a three layer architecture:
 SSH Transport Layer Protocol.
– Initial connection.
– Server authentication (almost always).
– Sets up secure channel between client and server.

SSH Authentication Protocol
– Client authentication over secure transport layer
channel.

SSH Connection Protocol
– Supports multiple connections over a single
transport layer protocol secure channel.
– Efficiency (session re-use).
SSH-2 Architecture
Applications
SSH Connection Protocol
SSH Authentication Protocol
SSH Transport Layer Protocol
TCP
SSH-2 Security Goals

Server (nearly) always authenticated in transport
layer protocol.
 Client (nearly) always authenticated in
authentication protocol.
– By public key (DSS, RSA, SPKI, OpenPGP).
– Or simple password for particular application over
secure channel.

Establishment of a fresh, shared secret.
– Shared secret used to derive further keys, similar to
SSL/IPSec.
– For confidentiality and authentication in SSH transport
layer protocol.

Secure ciphersuite negotiation.
SSH-2 Algorithms

Key establishment through Diffie-Hellman key
exchange.
– Variety of groups supported.





Server authentication via RSA or DSS
signatures on nonces (and other fields).
HMAC-SHA1 or HMAC-MD5 for MAC algorithm.
3DES, RC4, or AES finalists (Rijndael/Serpent).
Pseudo-random function for key derivation.
Small number of ‘official’ algorithms with simple
DNS-based naming of ‘private’ methods.
SSH-1 versus SSH-2

Many vulnerabilities have been found in SSH1.
– SSH-1 Insertion attack exploiting weak integrity
mechanism (CRC-32) and unprotected packet
length field.
– SSHv1.5 session key retrieval attack (theoretical).
– Man-in-the-middle attacks (using e.g. dsniff).
– DoS attacks.
• Overload server with connection requests.
• Buffer overflows.

But SSH-1 widely deployed.
 And SSH-1 supports:
SSH Port Forwarding
Without SSH or port forwarding.
LS Login
server
UM User’s
machine
Src: UM Dest: LS Port: 23
Src: UM Dest: MI Port: 113
Src: UM Dest: MO Port: 25
MI Mail in
server
MO Mail out
server
SSH Port Forwarding
Recall: TCP port number ‘identifies’
application.
 SSH on local machine:

– Intercepts traffic bound for server.
– Translates standard TCP port numbers.
• E.g. port 113  port 5113.
– Sends packets to SSH-enabled server through
SSH secure channel.

SSH-enabled server:
– Receives traffic.
– Re-translates port numbers.
• E.g. port 5113  port 113.
SSH Port Forwarding
With SSH and port forwarding.
MI Mail in
server
UM User’s
machine
Src: UM Dest: LS Port: 23
LS
SSH-enabled
login
server
MO Mail out
server
Src: UM Dest: MO Port: 25
Src: UM Dest: MI Port: 113
Src: UM Dest: LS Port: 5113 Src: UM Dest: LS Port: 5025
Src: LS Dest: MI Port: 113 Src: LS Dest: MO Port: 25

SSH Applications
Anonymous ftp for software updates, patches...
– No client authentication needed, but clients want to be
sure of origin and integrity of software.

Secure ftp.
– E.g.upload of webpages to webserver using sftp.
– Server now needs to authenticate clients.
– Username and password may be sufficient, transmitted
over secure SSH transport layer protocol.

Secure remote administration.
– SysAdmin (client) sets up terminal on remote machine.
– SysAdmin password protected by SSH transport layer
protocol.
– SysAdmin commands protected by SSH connection
protocol.
6.3 Comparing IPSec, SSL/TLS,
SSH

All three have initial (authenticated) key
establishment then key derivation.
– IKE in IPSec
– Handshake Protocol in SSL/TLS (can be
unauthenticated!)
– Authentication Protocol in SSH

All protect ciphersuite negotiation.
 All three use keys established to build a
‘secure channel’.
Comparing IPSec, SSL/TLS,
SSH

Operate at different network layers.
– This brings pros and cons for each protocol suite.
– Recall `Where shall we put security?’ discussion.
– Naturally support different application types, can
all be used to build VPNs.

All practical, but not simple.
– Complexity leads to vulnerabilities.
– Complexity makes configuration and management
harder.
– Complexity can create computational bottlenecks.
– Complexity necessary to give both flexibility and
security.
Comparing IPSec, SSL/TLS,
SSH
Security of all three undermined by:
 Implementation weaknesses.
 Weak server platform security.
– Worms, malicious code, rootkits,…

Weak user platform security.
– Keystroke loggers, malware,…

Limited deployment of certificates and
infrastructure to support them.
– Especially client certificates.

Lack of user awareness and education.
– Users click-through on certificate warnings.
Secure Protocols – Last Words
A (mis)quote from Eugene Spafford:
“Using encryption on the Internet is the
equivalent of arranging an armored car
to deliver credit-card information from
someone living in a cardboard box to
someone living on a park bench.”
What is a VPN
Public networks are used to move information between trusted network segments using
shared facilities like frame relay or atm
A VIRTUAL Private Network replaces all of the above utilizing the public
Internet Performance and availability depend on your ISP and the Internet
VPN Implementations
VPN as your Intranet
VPN Components
Technologies
Application Layer: SSL
Tunnel vs Transport

Transport
– Implemented by the end point systems
– Real address to real address
– Cannot ‘go through’ other networks

Tunnel
– Encapsulation of the original IP packet in another
packet
– Can ‘go through’ other networks
– End systems need not support this
– Often PC to a box on the ‘inside’
PPTP: Free from Microsoft
PPTP: Security
Outgoing PPTP Client Through NAT
a
Internet
10.0.0.2
NAT
b
c
10.0.0.3
10.0.0.4
10.0.0.1
204.x.1.10
web server
VPN Comparisons
So why have a private network:
QOS not fully cooked

Very dependent on your ISP
 Real hard to do across ISPs
 So no guarantee of performance