Network Security Architecture 1 Additional Reading Firewalls and - - PowerPoint PPT Presentation

1

Network Security Architecture

2

Additional Reading

 “Firewalls and Internet Security: Repelling the

Wily Hacker”, Cheswick, Bellovin, and Rubin.

− New second edition

 “Firewall and Internet Security, the Second

Hundred (Internet) Years” http://www.cisco.com/warp/public/759/ipj_2- 2/ipj_2-2_fis1.html

3

Overview

 Network Security Architecture

− Wireless − Security Domains − VPN

 Firewall Technology

− Address Translation − Denial of Service attacks

 Intrusion Detection  Both firewalls and IDS are introductions.

4

802.11 or Wi-Fi

 IEEE standard for wireless communication

− Operates at the physical/data link layer − Operates at the 2.4 or 5 GHz radio bands

 Wireless Access Point is the radio base station

− The access point acts as a gateway to a wired network

e.g., ethernet

− Can advertise Service Set Identifier (SSID) or not

 Doesn't really matter, watcher will learn active

SSIDs

 Laptop with wireless card uses 802.11 to

communicate with the Access Point

5

WEP

 “Wired Equivalency Privacy” -- early technique for

encrypting wireless communication

 Authenticated devices use a key and initialization

vector to seed RC4---a stream cipher

 V (initialization vector) is changed every frame

− Dangers of repeated encryption using the same key stream--

XOR of ciphertexts gives XOR of plaintexts

 And if some of the plaintext is known, the other is recovered

v

6

Frame transmission

 RC4(v,k) is stream generated by long-lived key k and

initialization vector v

 v transmitted in the clear  v is only 24 bits long---since k is long-lived (and used

by all devices)---you are assured of getting repeated key sequences

− And knowing when you have them! Because v is in the

clear…

7

Security Mechanisms

 MAC restrictions at the access point

− “white list” : Protects servers from unexpected clients − Unacceptable in a dynamic environment − No identity integrity. You can reprogram your card to pose as

an “accepted” MAC.

 IPSec

− To access point or some IPSec gateway beyond − Protects clients from wireless sniffers − Used by UIUC wireless networks



802.11i

− Authentication and integrity integral to the 802.11 framework − WEP, WPA, WPA2

8

Network Security Protocols

 SSL/TLS

− Secure sockets layer / Transport layer security − Used mainly to secure Web traffic

 SSH

− Secure Shell − Remote login

 IPsec

− IP-level security suite

8

9

SSL

 Mid ‘90s introduced concerns over credit card

transactions over the Internet

 SSL designed to respond to thse concerns,

develop e-commerce

 Initially designed by Netscape, moved to IETF

standard later

9

10

SSL model



A client and a server



Implements a socket interface

−

Any socket-based application can be made to run on top of SSL



Protect against:

−

Eavesdroppers

−

MITM attacks



Server has X.509 certificate

−

Client may have a certificate, too



Provides encryption, and authentication of server

10

11

SSL Handshake, (1)



Client requests “https” connection with server

−

Passes information to server in message describing available protocols



Key exchange method (e.g., RSA, Diffie-Hellman, DSA)



Cipher (e.g., Triple DES, AES)



Hash (e.g., HMAC-MD5, HMAC-SHA)



Compression algorithms



Client nonce



Server responds with messages that

−

Selects (key xchg, cipher, hash, compression)

−

Provide server’s certificate

−

Server nonce

11

12

SSL Handshake, (2)



Client verifies server cert

−

Likely that cert was signed by a CA whose cert is in the browser already



generates pre_master_secret, encrypts using server’s public key, sends it



Client and server separately compute session key and MAC keys (these from prior random numbers passed)



Client sends MAC of all messages it sent to server in this handshake



Server sends MAC of all messages it sent to client in this exchange

12

13

SSL certificates

13

14

SSL history

 SSLv2 1994  SSLv3 1996

− Fixed security problems

 TLS v1.0 1999  TLS v1.1 2006 14

15

SSL key lengths

 Earlier versions used 40-bit keys for export

reasons

 Later versions switched to 128-bit keys, with

an option to use 40-bit ones with legacy servers/clients

 Rollback attack:

− MITM

15

16

SSL sequence

 Negotiate parameters  Key exchange  Authentication  Session 16

17

SSL negotiation

 Choice of cipher suites, key exchange

algorithms, protocol versions

 E.g. : choice of 40- or 128-bit keys for export

reasons

 Rollback attack: MITM chooses least secure

parameters

17

18

SSL key exchange

 Diffie-Hellman key exchange  RSA-based key exchange

− Encrypt secret s with public key of server

18

19

SSL session

 Use ChangeCipherSpec message to start

encrypting data

 Encryption: RC4, also DES, 3DES, AES, ...  Authentication: HMAC, using MD5 or SHA1 19

20

SSL session…pushing the bits

20

Blocks, sized up to 18K Algorithm agreed-up on in handshake MAC added for authentication Algorithm, key, agreed-up on in handshake Passed on to TCP

21

SSL pitfalls

 Hard to set up

− Expensive certificates − Resource-intensive



Insufficient verification

−

Do people notice the lock icon?

−

Do people check the URL?



Improper use

21

22

IPsec



Designed as part of IPv6 suite

−

One of the key features v6 was supposed to bring



Backported to IPv4



Two options: AH (authentication) and ESP (encapsulated security)



Two modes: transport and tunnel



Readable resource http://www.unixwiz.net/techtips/iguide-ipsec.html

22

23

Transport vs. Tunnel Mode



Grand vision: eventually, all IP packets will be encrypted and authenticated



Transport mode: add headers to IP to do so

May include encryption, authentication, or both



Reality: Most computers don’t support IPsec (more on why later)



Tunnel mode: use IPsec between two gateways to relay IP packets through “untrusted cloud”

23

24

Tunnel Mode

H1 H2 P P P P P P

24

25

AH - Authentication



Simple design: add header with authentication data

−

Security parameters

−

Authentication data : just an HMAC with

shared key to compute Integrity Check Value (ICV)

25

Different of the HMAC architecture picture

26

AH Header

 Next hdr is protocol type of the following header  AH Length gives size of AH header  SPI -- sort of a switch code indicating which set

• f security parameters apply

 Sequence number --- basically a nonce to

prevent replay attacks

 HMAC field

27

AH diagram

27

HMAC applied only to fields in yellow

28

Piggybacking AH on IPv4

 The structure allows IPSec logic to

− peel off the AH header, do verification and/or

decoding,

− Modify “length” and “next protocol” fields to be that of

an AH-free IP packet

− Push the packet up the stack with higher levels none

the wiser that IPSec was present

29

Tunneling in IPSec

 Change the source and destination addresses

to be the tunnel endpoints

 IPSec tunnel endpoints strip off AH header, to

authentication and endcoding

 Original IP packet is part of the payload, just

released into the local network

30

AH in Tunnel Mode

How to detect tunnel mode

30

Original IP header

31

ESP - Encapsulated Security Payload

 Encapsulate data

− Encapsulate datagram rather than add a header − Encrypt & authenticate

Authentication header based only on encapsulation--- not Iaddresses---hold that thought---

31

32

ESP diagram

32

Protocol using TCP is Completely hidden SPI describes encryption Padding and pad len support block encryption

33

Key management



ESP and AH use session keys



Sessions are called Security Associations

−

Indexed by protocol, IP address, SPI



ISAKMP: Internet Security Association Key Management Protocol

−

Authenticates parties

−

Establishes session keys



Authentication

−

Big global PKI (DNSSEC??)

−

Manual configuration

33

34

IPsec redux



Deployment of IPsec limited



Some reasons

−

Global PKI infrastructure hard to set up

−

Fixes a “solved” problem



SSL & SSH work well



IPsec success: VPNs

−

Use tunnel mode of IPsec

34

35

Perimeter Defense

 Is it adequate?

− Locating and securing all perimeter points is quite

difficult

 Less effective for large border

− Inspecting/ensuring that remote connections are

adequately protected is difficult

− Insiders attack is often the most damaging

36

Virtual Private Networks

 A private network that is configured within a

public network

 A VPN “appears” to be dedicated network to

customer

 The customer is actually “sharing” trunks and

• ther physical infrastructure with other

customers

 Security?

− Depends on implementing protocol

37

Multiple VPN Technologies

SSL

• Confidentiality? Yes
• Data integrity? Yes
• User authentication?

Yes

• Network access

control? No

• In addition, limited

traffic

IPSec

• Confidentiality? Yes
• Data Integrity? Yes
• User Authentication?

Yes

• Network access

control? Yes

• Client configuration

required. VLAN – Layer 2 tunnelling technology

• Confidentiality? No
• Data Integrity? No
• User authentication?

Yes

• Network access

control? Yes

• Not viable over non-

VLAN internetworks

38

Security Domains with VPNs

39

“Typical” corporate network

Web Server Mail forwarding Mail server DNS (internal) DNS (DMZ) Internet File Server User machines User machines User machines Web Server Demilitarized Zone (DMZ) Intranet Firewall Firewall

40

VPN using IPSec

40

 ESP does the

encryption

 Difficulty with NAT

means ESP+Auth in tunnel mode

 Requires VPN

gateway---view is a tunnel between two trusted networks

41

VPN using IPSec

42

Firewall Goal

 Insert after the fact security by wrapping or

interposing a filter on network traffic

Inside Outside

43

Application Proxy Firewall

 Firewall software runs in application space on the

firewall

 The traffic source must be aware of the proxy

and add an additional header

 Leverage basic network stack functionality to

sanitize application level traffic

− Block java or active X − Filter out “bad” URLs − Ensure well formed protocols or block suspect aspects

• f protocol

44

Packet Filter Firewall

 Operates at Layer 3 in router or HW firewall  Has access to the Layer 3 header and Layer 4

header

 Can block traffic based on source and destination

address, ports, and protocol

 Does not reconstruct Layer 4 payload, so cannot

do reliable analysis of layer 4 or higher content

45

Stateful Packet Filters



Evolved as packet filters aimed for proxy functionality



In addition to Layer 3 reassembly, it can reconstruct layer 4 traffic



Some application layer analysis exists, e.g., for HTTP, FTP, H.323

− Called context-based access control (CBAC) on IOS − Configured by fixup command on PIX



Some of this analysis is necessary to enable address translation and dynamic access for negotiated data channels



Reconstruction and analysis can be expensive.

− Must be configured on specified traffic streams − At a minimum the user must tell the Firewall what kind of traffic to

expect on a port

− Degree of reconstruction varies per platform, e.g. IOS does not do IP

reassembly

46

Traffic reconstruction

X Y FTP: X to Y GET /etc/passwd GET command causes firewall to dynamically

• pen data channel initiate

from Y to X Might have filter for files to block, like /etc/passwd

47

Access Control Lists (ACLs)

 Used to define traffic streams

− Bind ACL’s to interface and action

 Access Control Entry (ACE) contains

− Source address − Destination Address − Protocol, e.g., IP, TCP, UDP, ICMP, GRE − Source Port − Destination Port

 ACL runtime lookup

− Linear − N-dimensional tree lookup (PIX Turbo ACL) − Object Groups − HW classification assists

48

Ingress and Egress Filtering



Ingress filtering

− Filter out packets from invalid addresses before entering your

network



Egress filtering

− Filter out packets from invalid addresses before leaving your

network

Inside Outside Owns network X Egress Filtering Block outgoing traffic not sourced from network X Ingress Filtering Block incoming traffic from

• ne of the set of invalid

networks

49

Denial of Service

 Example attacks

− Smurf Attack − TCP SYN Attack − Teardrop

 DoS general exploits resource limitations

− Denial by Consumption − Denial by Disruption − Denial by Reservation

50

TCP SYN Attack

 Exploits the three-

way handshake

S D SYNx LISTEN SYNy , ACKx+1 SYN_RECIEVED ACKy+1 CONNECTED

Figure 1. Three-way Handshake

S D Nonexistent (spoofed) SYN LISTEN SYN SYN SYN_RECEIVED SYN+ACK

Figure 2. SYN Flooding Attack

51

TCP SYN Attack Solutions

 Intermediate Firewall/Router

− Limit number of half open connections

 Ingress and egress filtering to reduce spoofed

addresses

− Does not help against DDoS bot networks

 Reactively block attacking addresses

− Generally expensive to acquire technology to do

fast enough

 Fix Protocol - IPv6

52

Teardrop Attack

 Send series of fragments that don't fit together

− Poor stack implementations would crash − Early windows stacks

Offset 0, len 60 Offset 30, len 90 Offset 41, len 173

53

Address Translation



Traditional NAT RFC 3022 Reference RFC



Map real address to alias address

− Real address associated with physical device, generally an

unroutable address

− Alias address generally a routeable associated with the

translation device



Originally motivated by limited access to publicly routable IP addresses

− Folks didn’t want to pay for addresses and/or hassle with

getting official addresses

54

Address Translation



Later folks said this also added security

− By hiding structure of internal network − Obscuring access to internal machines



Adds complexity to firewall technology

− Must dig around in data stream to rewrite references to IP

addresses and ports

− Limits how quickly new protocols can be firewalled

55

Address Hiding (NAPT)

 NAPT = Network Address Port Translation  Many to few dynamic mapping

− Packets from a large pool of private addresses are

mapped to a small pool of public addresses at runtime

 Port remapping makes this sharing more

scalable

− Two real addresses can be rewritten to the same alias

address

− Rewrite the source port to differentiate the streams

 Traffic must be initiated from “inside”, e.g. the

private address

56

NAT example

Enforcing Device 192.168.1.0/24 128.128.1.0/26 10.10.10.0/24 Internet

Hide from inside to outside 192.168.1.0/24 behind 128.274.1.1 Static map from inside to DMZ 192.168.1.5 to 128.274.1.5 inside DMZ

• utside

Src=192.168.1.1 Dst=microsoft.com Src=128.274.1.1 Dst=microsoft.com

57

Static Mapping

 One-to-one fixed mapping

− One real address is mapped to one alias address at

configuration time

− Traffic can be initiated from either side

 Used to statically map out small set of servers

from a network that is otherwise hidden

 Static port remapping is also available

58

NAT example

Enforcing Device 192.168.1.0/24 128.128.1.0/26 10.10.10.0/24 Internet

Hide from inside to outside 192.168.1.0/24 behind 128.274.1.1 Static map from inside to DMZ 192.168.1.5 to 128.274.1.5 inside DMZ

• utside

Src=192.168.1.5 Dst=10.10.10.1 Src=128.274.1.5 Dst=10.10.10.1

192.168.1.5 128.274.15

59

NAT and IPSec AH don’t mix

 Recall the diagram illustrating the fields covered by AH  AH header created at the sender, src/dest IP

addresses changed by NAT

60

FW Runtime Characteristics

 Firewalls track streams of traffic

− TCP streams are obvious − Creates pseudo UDP streams for UCP packets between

the same addresses and ports that arrive near enough to each other

 Processing first packet in stream is more

expensive

− Must evaluate ACLs and calculate address translations − Subsequent packets get session data from a table

61

Multi-legged Firewalls



Historically firewalls have protected inside from outside

− Still true for the most part with personal and home firewalls − No longer sufficient for larger enterprises



PIX security level solution

− Outbound = traffic from low security level interface to high security

level interface

− Inbound = traffic from high security level interface to low security

level interface

− Different requirements for inbound and outbound traffic



IOS divides interfaces into inside and outside groups

− Address translation can only be defined between inside and outside

groups



Routing conflicts with address translation

− Address translation specifies both interfaces − Must be evaluated before the routing, better be consistent

62

Four Legged FW



Static translation from DMZ to Customer

−

10.10.10.10.1 to 128.1.1.1



But routing table wants to route 128.1.1.1 from DMZ to outside interface

−

Static translation interface selection will win

Enforcing Device 192.168.1.1 10.10.10.0/24 Internet

Inside SL=100 DMZ SL=50 Outside SL=0

10.10.20.0/24 10.10.30.0/24

Partner SL=75 Customer SL=25

63

Identity Aware Firewall

 Use TACACS+ or Radius to authenticate,

authorize, account for user with respect to FW

− For administration of FW − For traffic passing through FW

 PIX cut-through proxy allows authentication on one

protocol to cover other protocols from same source

 Authorization for executing commands on the

device

 Download or enable ACL’s  XAuth to integrate AAA with VPN authentication

and other security mechanisms

64

AAA Scenario

X Y

• utside

Inside TACACS or Radius AAA Server Traffic from X must be authenticated via HTTP User Joe should use ACL EngAccess

65

Is the Firewall Dead?

 End-to-end security (encryption) renders firewalls useless

− Tunnels hide information that firewalls would filter or sanitize − With IPSec decrypting and re-encrypting is viable

 Blurring security domain perimeters

− Who are you protecting from whom − Dynamic entities due to DHCP and laptops − More dynamic business arrangements, short term

partnerships, outsourcing

 Total Cost of Ownership (TCO) is too high

− Managing firewalls for a large network is expensive

 Perhaps personal or distributed firewalls are the answer?

− “Implementing a Distributed Firewall”

http://www1.cs.columbia.edu/~angelos/Papers/df.pdf

66

Intrusion Detection

 Holy Grail: Detect and correct “bad” system

behavior

 Detection can be viewed in two parts

− Anomaly detection: Use statistical techniques to

determine unusual behavior

− Mis-use detection: Use signatures to determine

• ccurrence of known attacks

 Detection can be performed on host data (HIDS),

network data (NIDS), or a hybrid of both

67

Intrusion Handling

 Preparation for attack  Identification of the attack  Containment of the attack

− Gather information about the attacker − Honeypots

 Eradication

− Broadly quarantine the system so it can do no more harm − BGP blackholing − Tighten firewalls − Cleanse the corrupted system

 Followup phase

− Gather evidence and take action against the attacker

68

Honey Pots

 Reconnaissance for the good guys  Deploy a fake system

− Observe it being attacked

 Resource management

− Cannot be completely passive

 Must provide enough information to keep attacker

interested

− Must ensure that bait does not run away

 Scale

− Host, network, dark address space

69

IDS Architecture

 Agents run at the lowest level gathering data. Perform

some basic processing.

 Agents send data to a Director that performs more

significant processing of the data. Potentially there is a hierarchy of agents and directors

− Director has information from multiple sources and can

perform a time-based correlation to derive more significant actions

 Directors invoke Notifiers to perform some action in

response to a detected attack

− Popup a window on a screen − Send an email or a page − Send a new syslog message elsewhere. − Adjust a firewall or some other policy to block future action

from the attacker

70

Data Sources

 Direct data

− Network packets − System calls

 Indirect data

− Syslog data, Windows event logs − Events from other intrusion detection systems − Netflow information generated by routers about

network traffic

71

Mis-use/Signature Detection



Fixed signatures are used in most deployed IDS products

− E.g., Cisco, ISS, Snort



Like virus scanners, part of the value of the product is the team of people producing new signatures for newly observed malevolent behavior



The static signature mechanism has obvious problems in that a dedicated attacker can adjust his behaviour to avoid matching the signature.



The volume of signatures can result in many false positives

− Must tune the IDS to match the characteristics of your network − E.g., what might be unusual in a network of Unix systems

might be normal in a network of Windows Systems (or visa versa)

− Can result in IDS tuned too low to miss real events

Can hide real attacks in the mass of false positives

72

Example Signature

 Signature for port sweep

− A set of TCP packets attempting to connect to a

sequence of ports on the same device in a fixed amount of time

 In some environments, the admin might run

nmap periodically to get an inventory of what is

• n the network

− You would not want to activate this signature in that

case

73

Anomaly/statistical detection

 Seems like using statistics will result in a more adaptable

and self-tuning system

− Statistics, neural networks, data mining, etc.

 How do you characterize normal?

− Create training data from observing “good” runs

 E.g., Forrest’s program system call analysis

− Use visualization to rely on your eyes

 How do you adjust to real changes in behaviour?

− Gradual changes can be easily addressed. Gradually adjust

expected changes over time

− Rapid changes can occur. E.g., different behaviour after work

hours or changing to a work on the next project

74

Host Based IDS

 Tripwire – Very basic detection of changes to

installed binaries

 More recent HIDS. Look at patterns of actions

• f system calls, file activity, etc. to permit, deny,
• r query operations

− Cisco Security Agent − Symantec − McAfee Entercept

75

Classical NIDS deployment

NIDS Agent

Outside

Inside

Management Promiscuous Interface

NIDS Director

76

NIDS Remediation Options

 Log the event  Drop the connection  Reset the connection  Change the configuration of a nearby router or

firewall to block future connections

77

Intrusion Protection Systems (IPS)

 Another name for inline NIDS  Latest buzz among the current NIDS vendors  Requires very fast signature handling

− Slow signature handling will not only miss attacks but it

will also cause the delay of valid traffic

− Specialized hardware required for high volume gateways

 When IDS is inline, the intrusion detector can

take direct steps to remediate.

 If you move IDS into the network processing

path, how is this different from really clever firewalling?

78

Summary

 Identification of security domains basis of

perimeter security control

− Firewall is the main enforcer

 Intrusion detection introduces deeper analysis

and potential for more dynamic enforcement

 Intermediate enforcement can handle some

Denial of Service attacks