CSE 524: Lecture 17

1

CSE 524: Lecture 17

Network security issues

2

Administrative

• Programming assignment due Monday 12/1– Arrange with TA

• Final project due 12/10

3

Optional material

• Hacking the stack: Network protocol attacks– Hacking TCP– Hacking routing– Hacking ICMP– Hacking DNS– Reflector attacks

• Analyzing attacks– Estimating DoS activity

• Tracing the source of attacks– Traceback via traffic injection– Traceback via packet marking– Traceback via logging

• Intrusion detection and response– Network IDS– Attacking the detectors

4

Hacking the stack: Network protocol attacks

• C. Schuba, I. Krsul, M. Kuhn, E. Spafford, A. Sundaram, D. Zamboni, "Analysis of a Denial of Service Attack on TCP"

• S. Bellovin, "Security Problems in the TCP/IP Protocol Suite" • S. Bellovin, "Defending against sequence number attacks"• S. Bellovin, "Packets Found on an Internet"• R. Morris, "A Weakness in the 4.2BSD Unix TCP/IP Software“• B. Cheswick, S. Bellovin, “A DNS Filter and Switch for Packet-

filtering Gateways”.• S. Savage, N. Cardwell, D. Wetherall, T. Anderson, “TCP

Congestion Control with a Misbehaving Receiver”.

5

Hacking TCP: SYN Flooding

• Attacker sends many connection requests w/ spoofed source addresses to victim– Victim allocates resources for each request

• Finite # half-open connection requests supported• Connection requests exist for TIMEOUT period

– Once resources exhausted, all other requests rejected

Normal connection est. Syn Flooding attack

6

Hacking TCP: SYN Flooding Defenses

• System Configuration Improvements– Reduce timeout period– Increase length of backlog queue to support more connections– Disable non-essential services to make a smaller target

• Router Configuration Improvements– Configure router external interfaces to block packets with source

addresses from internal network– Configure router internal interfaces to block packets to outside that have

source addresses from outside the internal network

• TCP SYN cookies– Make handshake stateless on server end– Server makes ISN a function of a secret nonce it keeps and pieces of the

SYN connection ID– Only create TCB and establish connection upon verifying client’s ACK

7


• Firewall as a Relay– Firewall answers on behalf of

Destination

– Once connection established, firewall predicts seq # and establishes 2nd connection to Destination

– Disadvantage: Adds delay for every packet

8


• Firewall as a Semi-transparent Gateway– Forges the 3rd handshake (ack) from the client to the destination

– This moves connection out of backlog queue, freeing resources

– If this is attack, no “real” ack will happen

• Destination will send RST packet terminating connection

– If this is actual connection request the eventual ack will be ignored as a duplicate

– Disadvantages:

• Large # illegitimate open connections if system under attack

• Must very carefully choose timeout periods

9


Attack w/ semi-transparent gateway

Legit connection w/ semi-transparent gateway

10


• Active Monitor– Program that promiscuously monitors and injects network

traffic to/from machines it is protecting

– Monitors net for SYN packets not acknowledged after a certain period of time

– If it detects problems with a half-open connection it can• Send RST packets to the sender to release destination resources

• Complete the TCP connections by sending the ACK message

– Similar to Semi-Transparent gateways

11

Hacking TCP: Congestion control tricks

• ACK Division– Receiver can acknowledge segments multiple times (up to #bytes acks)

– Leads Sender to grow cwnd faster than normal.

• Solution to ACK Division– Modify congestion control to guarantee segment-level granularity

– Only increment MSS when a valid ACK arrives for the entire segment.

Bunch of acks

Burst 1 RTT later

12


• Duplicate Ack Spoofing– Receiver sends multiple acks/sequence #

• no way to tell what segment is being acked

– Causes sender to enter fast-recovery mode and inflate cwnd

• Solution to Duplicate Ack Spoofing– Add new fields to TCP headers.

• “nonce & nonce-reply” – random values sent with segments and replies• Only increment cwnd for ACKs with previously unseen nonces

Burst of dup acks

Sender enters Fast Recovery and bursts 1 RTT later

13


• Optimistic ACKing– Send acks for segments not yet received

– Decrease perceived RTT, affecting CW growth.

Segment acks

Segs arrive

14


• Solution to optimistic acking: Cumulative Nonce – Sender sends random number

(nonce) with each packet

– Segment size slightly randomized

– Receiver sends cumulative sum of nonces

– if receiver detects loss, it sends back the last nonce it received

– Why cumulative?

– Requires modifications to stack

15

Hacking routing: RIP attacks

• Attack– Intruder sends bogus routing information to a target and

each of the gateways along the route• Impersonates an unused host

– Diverts traffic for that host to the intruder’s machine

• Impersonates a used host– All traffic to that host routed to the intruder’s machine

– Intruder inspects packets & resends to host w/ source routing

– Allows capturing of unencrypted passwords, data, etc

16

Hacking routing: RIP attacks

• Defenses– Paranoid gateway

• Filters packets based on source and/or destination addresses

– Don’t accept new routes to local networks• Messes with fault-tolerance but detects intrusion attempts

– Authenticate RIP packets• Difficult in a broadcast protocol

• Only allows for authentication of prior sender and doesn’t address information from a deceived gateway upstream

17

Hacking ICMP

• Attack– Targeted Denial of Service (DoS)

• Attacker sends ICMP Redirect message to give a bogus route• Attacker sends Destination Unreachable or TTL exceeded messages

to reset existing connections• Attacker sends fraudulent Subnet Mask Reply messages

– Blocks communication with target

• Defenses– Verify ICMP packet contains a plausible sequence #– Don’t modify Global Route Table due to ICMP Redirect

messages– Disallow ICMP Redirects?– Check to see if multiple ICMPs from a host agree

18

Hacking DNS

• DNS : Domain Name System• BSD r*

– rlogin, rcp, rsh use address based authentication (reverse lookup)

• The problem– No authentication– Responses can contain entries that should not be trusted but are– Responses are cached

• Attacks– Inject bogus DNS responses– Attach additional bogus entries in valid DNS responses (especially for internal

names)

ApplicationRemote Name Server

(?)Local Name Server

(Trusted)Resolver

*Firewall

19

Hacking DNS

• Solution: DNS Proxy– Filter

• Drop malformed packets

– Verify• Does the answer, really answer the query made?

• Was the answer received from the appropriate server?

– Proxy performs checks on the answers from outside DNS servers

• Located within the firewall on a trusted host

• Intercepts DNS queries, filters, modifies and forwards in appropriate direction

20

Hacking the stack: Reflector attacks

• A reflector is any IP host that will return a packet or more if sent a packet.– Reflector cannot easily locate the slave because of IP spoofing.

• Examples:– Web servers: return SYN ACKS or RSTs in response to SYN or other

TCP packets.

– DNS servers: return query replies in response to query requests.

– Routers: return ICMP Time Exceeded or Host Unreachable messages in response to particular IP packets.

22

Hacking the stack: ICMP reflectors

• ICMP echo, timestamp, address mask, router solicitation, information request/reply.– ICMP echo is widely used.

– Smurf attacks

• ICMP source quench, unreachable, time exceeded, parameter problem, and redirect.– Important ICMP messages:

• Host unreachable.

• Time exceeded.

• Need fragmentation.

23

Hacking the stack: TCP reflectors

• TCP stack can be made to reflect via…– SYN ACK by sending an initial SYN.

• Filtering leads to no-remote access.

– RST by sending a FIN.• Filtering RST results in clogging of stale connections state

24

Hacking the stack: TCP reflectors

• Predictable TCP sequence numbers– If reflector stack has guessable TCP sequence numbers, it’s

a DISASTER for the victim.

– Attacker can drive the Reflector TCP state machine, making it send ACKs, data segments.

– Attack can be amplified by transmitting large items and exploiting “ACK splitting” techniques.

25

Hacking the stack: TCP for Transactions (T/TCP) reflectors

• Spoof initial SYN packet with acceptable seq. no.– Make an expensive request.

• Factors that limit the T/TCP attack– T/TCP server will begin in slow start.

• Unless the server’s stack has predictable seq. no.

– Amenable to stateless packet filtering.

– T/TCP is not widely deployed.

26

Hacking the stack: UDP reflectors

• UDP– Application-specific

• Quake Qstat

• Counter-strike clients

• DNS

27

Hacking the stack: DNS reflectors

• DNS– Reflector sending DNS reply in response to a spoofed DNS request.

• Victim can configure its local DNS servers so as to filter out unknown DNS server responses.

– If the victim is a name server• Attacker can query a large number of DNS servers which in turn recursively

query the Victim.

• Victim server gets bombarded due to multiple queries.

• DNS queries needn’t even be spoofed.– Send valid queries to a large set of known DNS servers

• Arbitrary names not just the ones responsible for

• Caching at the reflector server doesn’t help.

• Solution: Provide filtering in name servers so as to serve recursive queries from local addresses, coupled with ingress filtering.

28

Hacking the stack: SNMP reflectors

• SNMP (UDP-based request/reply)– Sites that fail to block off-site access to SNMP provide a

large number of reflectors.

– SNMP attack is sourced at port 161.

– Filtering out the external SNMP messages leads to major problem for service providers.

• Configure the filter to receive SNMP messages from interested hosts.

29

Hacking the stack: HTTP reflectors

• HTTP proxies– HTTP proxy caches provide a way that an HTTP client can manipulate a

proxy server into initiating a connection to a victim web server.– HTTP proxy servers act as reflectors for the DDOS attacks.

• HTTP - Limitations– Proxies can be configured to serve a restricted set of clients.– There are not enough proxy caches to constitute a large pool of possible

reflectors.– Connection between slave and the reflector cannot be spoofed unless the

reflecting proxy has predictable sequence numbers. Logging helps in identifying the slave’s location.

• Definitely a major threat if servers running on stacks with predictable sequence numbers are widely deployed.

30

Hacking the stack: FTP reflectors

• See previous lecture on server-to-server transfers

31

Hacking the stack: Gnutella

• Gnutella attack– Provides a “push” facility that instructs the server to connect to a given

IP address and port in order to deliver the Gnutella item.

– Gnutella connection to the IP host is separated from the initial client making it impossible to trace back to the slave.

• Fix– Modify the protocol to include path information with “push” directives

• Gnutella could be a major problem for DDOS reflector attacks.

33

Analyzing attacks

• D. Moore, G. Voelker, S. Savage “Inferring Internet Denial-of-Service Activity”

34

Analyzing attacks: Backscatter

• Attackers spoof source address randomly– Small frequent packets. (packet/sec bottleneck)

– e.g. TCP SYN -> victim allocate data structure for arriving packets (for unmatched to existing connections)

• Victims, in turn, respond to attack packets– Remotely controlled “Zombies” for DDoS

• Unsolicited responses (backscatter) equally distributed across IP space– Received backscatter is evidence of an attacker elsewhere

35

From caida page

36

From caida page

37

Analyzing attacks: Backscatter

• Backscatter analysis provides quantitative data for a global view on DoS activity using local monitoring

• Videos• Traffic Characterisation (How Data Gathered)

– http://www.caida.org/outreach/resources/animations/passive_monitoring/traffic_char.mpg (1min12s)

• TCP Port Analysis – http://www.caida.org/outreach/resources/animations/passive_monitorin

g/tcp_port_analysis.mpg (2min15s)

• Backscatter– http://www.caida.org/outreach/resources/animations/passive_monitorin

g/backscatter.mpg (1min26)

http://www.caida.org/outreach/resources/animations/passive_monitoring/traffic_char.mpg

http://www.caida.org/outreach/resources/animations/passive_monitoring/traffic_char.mpg

http://www.caida.org/outreach/resources/animations/passive_monitoring/tcp_port_analysis.mpg

http://www.caida.org/outreach/resources/animations/passive_monitoring/tcp_port_analysis.mpg

http://www.caida.org/outreach/resources/animations/passive_monitoring/backscatter.mpg

http://www.caida.org/outreach/resources/animations/passive_monitoring/backscatter.mpg

38

Analyzing attacks: Assumptions

• Address Uniformity• Reliable delivery

– Backscatter not lost

• Backscatter hypothesis– Unsolicited packets represent backscatter

• In fact any server can send

– Reflector attack may not be detected• Not random IP-forgery

– Some attacks (e.g. TCP-RST) doesn’t produce backscatter.

40

Analyzing attacks: Backscatter platform

41

Analyzing attacks: Results

• 13000 attacks in 3 weeks• 5000 victim IP addresses on 2000 domains• 200 million backscatter packets

– *256 < Real attack packets

• Most attacks short, some longer persistent ones• Mostly TCP (90-94%)

– Some large ICMP storms (43% of all packets)– Attacks cover most ports, but HTTP and IRC singled out

• How serious is this?– 500 packets enough to overwhelm server

• 38-46 % of attacks (unif.-all)

– 14000 packets enough to overwhelm firewall• 0.3-2.4 % of attacks (unif.-all)

42

Analyzing attacks: Victim characterization

• Entire spectrum of sites and businesses– Yahoo!, Amazon, CNN, etc.

• Small attacks from personal vendettas– 10-20% targeted towards home machines

• Attacks on infrastructure– 5% directed towards routers and root DNS servers

43

Traceback

• H. Burch, B. Cheswick, "Tracing Anonymous Packets to Their Approximate Source“

• S. Bellovin, M. Leech, T. Taylor, "ICMP Traceback Messages"

• A. Mankin, D. Massey, C. Wu, S. Wu, L. Zhang, "On Design and Evaluation of "Intention-Driven" ICMP Traceback“

• A. Snoeren, C. Partridge, L. Sanchez, C. Jones, F. Tchakountio, S. Kent and W. Strayer, “Hash-Based IP Traceback”

44

Traceback: Motivation

• DoS attacks– IP spoofing

• No one checks source IP address to drop spoofed packets

• TCP SYN floods, Smurf (ICMP echo to broadcast addresses)

– Difficult to get the help of upstream ISP• Lack skill

• Lack resources (might be 6pm on Friday)

• In a different country (speak different language, etc)

– Require automatic way of identifying where the traffic is coming from without human intervention

45

Traceback: Problem

• Goal– Given set of packets– Determine path

• Assumptions– Most routers remain

uncompromised– Attacker sends many

packets – Route from attacker to

victim remains relatively stable

R6 R7 R8

A4 A5A1 A2 A3

R9 R10

R12

V

46

Traceback: schemes

• Record Route• Traffic injection• ICMP Trace (ITRACE)• Probabilistic packet marking• Logging and query

– Source Path Isolation Engine (SPIE)

• Reverse ITRACE• Subverting Traceback schemes

47

Traceback: Record Route

• Record path– Each router adds IP address to packet

– Victim reads path from packet

• Problem– Requires space in packet

• Path can be long

• No extra fields in current IP format– Changes to packet format are not practical

48

Traceback: Traffic injection

• Create a map of routes from victim to every network– Burst TCP/UDP packets to each and see if you are affected

• TCP/UDP chargen service• Generates continuous data to anyone who connects to service

– If DoS stream perturbed, you have a candidate

• Problems– Finding open chargen service– Asymmetric routing– Must generate sufficient load to perturb stream especially when there are

multiple attacking hosts– Easy to thwart

• Vary source of attack by altering frequency of packets• Attack from many sources• Still can’t turn attacker’s off…Must notify upstream ISP to stop

49

Traceback: Leverage volume of attack (Part 1)

• Many packets– DDoS involves many

packets on same path

• Have routers periodically send message to victim– Each router sends message

to Victim for every X packets it forwards to victim

R6 R7 R8

A4 A5A1 A2 A3

R9 R10

R12

V

50

Traceback: ICMP trace

• ICMP traceback messages– Routers periodically issue traceback ICMP messages to destination

• Send 1 message for every 20000 packets forwarded to destination– 0.1% overhead

• Similar to RouteRecord, collects intermediate hops along the way to destination

• Over time, leaves a trail of where packets are being sourced from

– Problems• Skilled attacker spoofing traceback messages to conceal the real source of

attack– Requires some signature and trust management

• Skilled attacker uses zombies to flood each other along with victim to reduce the amount of traceback messages sent

– “Background noise”

• Only want traceback messages from far away

51

Traceback: Leverage volume of attack (Part 2)

• Many packets– DDoS involves many

packets on same path

• Store one link in each packet– Probabilistically store your

own address or edge in packet using unused IP header fields (IP identifier)

• < 0.25% of traffic fragmented

– Fixed space regardless of path length

R6 R7 R8

A4 A5A1 A2 A3

R9 R10

R12

V

52

Traceback: IP traceback w/ edge sampling

• Data fields– Edge: start and end IP addresses

– Distance: number of hops since edge stored

• Marking procedure for router R with probability p

write R into start address

write 0 into distance field

else

if distance ==0 write R into end field

increment distance field

53


• Packet received– R1 receives packet from source or another router

– Packet contains space for start, end, distance

R1 R2 R3

packet s e d

54


• Begin writing edge– R1 chooses to write start of edge

– Sets distance to 0

R1 R2 R3

packet R1 0

55


• Finish writing edge– R2 chooses not to overwrite edge

– Distance is 0 • Write end of edge, increment distance to 1

packet R1 R2 1

R1 R2 R3

56


packet R1 R2 2

R1 R2 R3

• Increment distance– R3 chooses not to overwrite edge

– Distance >0 • Increment distance to 2

57

Traceback: IP traceback w/ edge sampling Path reconstruction

• Extract identifiers from attack packets• Build graph rooted at victim

– Each (start,end,distance) tuple is an edge

– Eliminate edges with inconsistent distance

– Traverse edges from root to find attack paths

• # packets needed to reconstruct path

E(X) <

where p is marking probability, d is length of path

ln(d) p(1-p)d-1

Optimal p is 1/d … can vary probability by distance

58

Traceback: IP traceback w/ node sampling

• Less data than edge sampling– Each router writes own address with probability p

• Infer order by number of packets– Router at distance d has probability p(1-p)d of showing up in

marked packet

R

p 1-p 1-p 1-p

V

d• Problems

– Need many packets to infer path order– Does not work well if many paths

59

Traceback: Reduce Space Requirement

• IP identifier is 16 bits– Distance, node addresses, larger

– Solution• Break into chunks

• XOR edge IP addresses

– Store edge as start + end

– Work backwards to get path:

(start + end) + end = start

• Sample attack patha + b b + c c + d d

a b c d V

60

Traceback: Where to store the info?

• Identification field– Used for fragmentation– Fragmentation is rare– 16 bits

• Store edge in 16 bits?– Break into chunks– Store start + end

Version Header LengthType of Service

Total LengthIdentification

Flags

Time to LiveProtocol

Header Checksum

Source Address of Originating Host

Destination Address of Target Host

Options

Padding

IP Data

Fragment OffsetIdentification

offsetdistance edge chunk

0 2 3 7 8 15

61

Traceback: IP traceback convergence time

62


• Benefits– Practical algorithm for tracing anonymous attacks

– Can reduce per-packet space overhead (at a cost)

– Potential encoding into current IP packet header

• Weaknesses– Path validation/authentication

– Robustness in highly distributed attacks• Both addressed nicely in [Song&Perrig00]

– Compatibility issues (IPsec AH, IPv6)

– Origin laundering (reflectors, tunnels, etc)

63

Traceback: Hash-based logging

V

R

R1 R2

R3

RR

RR

R4

A R

RR7

R6R5

64

Traceback: Logging

• Each forwarding decision is recorded– Traceback request queries upstream routers to ask if the

router forwarded a particular packet

• Difficulties– Attack path reconstruction is difficult

• Packet may be transformed as it moves through the network

– Full packet storage is problematic• Memory requirements are prohibitive at high line speeds (OC-192 is

~10Mpkt/sec)

– Extensive packet logs are a privacy risk• Traffic repositories may aid eavesdroppers

65

Traceback: Logging

• Compute “packet digest”– Compute hash(p)

• Invariant fields of p only

• 28 bytes hash input, 0.00092% WAN collision rate

• Fixed sized hash output, n-bits

• Store in Bloom filter (more later)– Compute k independent digests

• Increased robustness

• Reduced collisions, reduced false positive rate

– Flush filter every time interval, t

66

Traceback: Hash-based loggingHash-input (Invariant Content)

Total Length

Identification

Checksum

Ver TOSHLen

TTL Protocol

Source Address

Destination Address

Fragment OffsetMF

DF

Options

Remainder of Payload

First 8 bytes of Payload

28bytes

67

Traceback: Bloom filterhL-1h1

Flow insertion

1

1

1

Check entry0

0

h0

0

1

2

N-1

NL virtual bins out of L*N actual bins

68

Traceback: Reverse ITRACE

• R-ITRACE routers send ICMP messages to the source of the just-processed packet rather than its destination (unlike ITRACE).

• Routers on the path between slave and the reflector will send ICMP messages to Victim to enable trace back to the slaves.

• Efficacy does not depend on Nr but only on Ns.

69

Traceback: Subversion via reflectors…

• Major advantage to attackers– Protection from trace back mechanisms.

– Traceback mechanisms fail since they cannot trace back directly to slave

• Reflector operator must be involved

• Administratively cumbersome.

– Source Path Isolation Engine (SPIE) helps.

– Note: reflectors need not serve as amplifiers.

– Non-spoofed reflector attacks will expose the slave to quick traceback.

70

Traceback: Defense against Reflectors

• Prevent spoofing source address by ubiquitous deployment of ingress filtering.– Application level reflectors such as recursive DNS queries

or HTTP proxy requests can still be used.

– Disadvantage: Not feasible.

• Heavy-duty filtering at victim or at reflector– Disadvantage: Requires widespread deployment of filtering.

71

Traceback: Defense against Reflectors …

• Deploy traceback mechanisms that incorporate the reflector end-host software itself in the scheme, allowing traceback through the reflector back to the slave.– Disadvantage: Enormous deployment difficulties.

• Intrusion Detection Systems (IDS) monitor a site’s network for active slaves.– Disadvantage: Requires widespread deployment of security technology.

72

Traceback: Other solutions

• Ingress filtering– Block outgoing packets without appropriate source address

• Backbone filtering– Use knowledge of BGP to guess if packet’s source address

could have possibly originated from a particular direction• Routing instability makes this hard

• Lack of resources at routers makes this hard

73

Intrusion Detection Systems

• T. Ptacek, T. Newsham, “Insertion, Evasion and Denial of Service: Eluding Network Intrusion Detection” (Jan ‘98)

• B. Sanford, “IP Fragmentation and fragrouter” (Dec ‘00)• S. Patton, W. Yurcik, D. Doss, “An Achilles’ Heel in Signature-

based IDS: Squealing False Positives in SNORT” (‘01)• G. Malan, D. Watson, F. Jahanian, P. Howell, "Transport and

Application Protocol Scrubbing" • M. Handley, V. Paxson, C. Kreibich, “Network Intrusion

Detection: Evasion, Traffic Normalization and End - End semantics” (‘01)

74

IDS

• Introduction to IDS– Some popular IDSs

• Problems with IDSs– Insertion, evasion, denial-of-service

– IP Fragmentation & fragrouter

– “Squealing” in SNORT

• Counter-measures– Protocol scrubbing

– Traffic normalization

75

IDS: What do they do?

• Detect intrusion attempt or a threat: potential possibility of a deliberate unauthorized attempt to access/manipulate information, or render a system unreliable or unusable.

• Types of IDS– Host-based

– Network IDS

• Example IDSs– ISS RealSecure, WheelGroup NetRanger, Network Flight

Recorder, Snort

76

IDS: Principles

• Passive monitoring• Signature Analysis• Need for reliable ID

– accuracy: false positives and false negatives

– “fail-open”: if an attacker disables the IDS, entire network is still accessible

– forensic value of information

77

IDS: Fundamental problems

• Deployed on a different box and/or different network– Protocol implementation ambiguities

• Different protocol stacks have different behavior

– NIDS could see a different stream of packets than host

• Inaccuracies– False positives

• incorrectly identify an intrusion when none has occurred

– False negatives• incorrectly fail to identify an intrusion that has actually occurred

78

IDS: Attacks

• Insertion– IDS thinks packets are valid; end system rejects these

• Evasion– end system accepts packets that IDS rejects

• Denial of Service– resource exhaustion

• Examples

79

IDS: Popular problems/attacks

• TCP/IP Options fields• TCB Creation/Teardown• TCP Stream Reassembly• IP Fragmentation

– overlapping fragments

80

IDS: IP Fragmentation

• Allows IP traffic over different network media with different max packet sizes

• IP stacks do not handle reassembly well– can lead to DOS (teardrop, jolt2)

• Fragrouter– NIDS testing tool

– accepts IP packets routed from another system

– fragments these packets according to various schemes

81

IDS: Popular problems/attacks

• Resource Exhaustion– CPU, Memory, Network Bandwidth

• Abusing reactive IDS– attack to generate false positives

– IDS shuts down valid connections, blocks valid traffic etc.

– Results in IDS triggering a DOS

82

IDS: False positives

• Abuse by generating loads of false positives– Squealing: Noise made by pigs during periods of

distemperment

– Boy cried wolf too many times• additionally, boy may not recognize the wolf when it actually

appears!

• Example using Snort– open-source, free, lightweight NIDS

83

IDS: Attacking Snort

• Limitation is not in correctly identifying attacks, but in the ability to suppress false positives

• PCP– Tool for generating false positives

– packet writing and argument parsing

84

IDS: Squeal attack types

• Noise-masked attacks– diverts attention from a covert attack

• Attack misdirection– source of attack is spoofed

• Evidence Reputability• Target Conditioning• Statistical Poisoning

– when training an IDS

85

IDS: Counter-measures

• Adaption– changing the signature-matching algorithms rapidly

• State awareness– make IDS have a “context” which checking packets

86

IDS: Counter-measures

• Problem– IDSs are vulnerable to attacks

– fundamental problems:• IDS sees different streams than target host

• protocol implementation ambiguities

• Solutions– Transport and application layer protocol scrubbing

– Generalized traffic “normalizer”

– Modify packets to erase ambiguity

87

IDS: Normalizer

88

IDS: Normalizer

• Sits directly in path of traffic into a site• Patch up or normalize the packet stream• Result: same traffic and unambiguous behavior for

NIDS and host• Differs from a firewall• Other approaches

– host-based IDS, details of intranet, bifurcating analysis

89

IDS: Normalization Tradeoffs

• Protection– not meant to but can act as a firewall

• Need to preserve End-End Semantics• Impacts end-end performance• Stateholding attack

– create excess state than Normalizer can handle

• Inbound vs Outbound traffic

90

IDS: Other Considerations with Normalizer

• Cold Start– is a “real world” requirement

– what happens to existing connections?

– Initiate state for connections from trusted network

• Attacking the normalizer itself

CSE 524: Lecture 17

Documents

Transcript of CSE 524: Lecture 17