CS 6250 Test3 – Georgia Tech

6Dec - by qkim0x01 - 0 - In /Classes
9. Software Defined Network
  • Network Management Overview
    • Network Operations and Management
      • Software Defined Networking
      • Traffic Engineering
      • Network Security
    • What is network management?
      • Process of configuring network to achieve a variety of tasks
        • Load balancing
        • Security
        • Business Relationships
      • Mistake can leads to..
        • Oscillation
          • Routers can’t agree to the route to destination
        • Loops
        • Partitions
        • Black hole
          • A packet reach to a router that doesn’t know what to do and drop it
  • Why is configuration hard?
    • Defining correctness is hard
    • Interactions between protocols -> unpredictability
    • Operators make mistakes
      • Each device is configured to the vendor specific
        • Low-level configuration
          • => SDN changes this
    • What operators need (and what SDN provides)
      • Network-wide views
        • Topology
        • Traffic
      • Network-level objectives
        • Load balance
        • Security
      • Direct Control
        • Rather than configuring each device
        • Direct manipulation of data plane
    • Router should..
      • Forward packets
      • Collect measurements
      • (x) Compute routes
        • Can be (logically) centralized and controlled
        • SDN
          • => Remove routing from routers
  • SDN
    • What is an SDN?
      • Today’s network has 2 functions
        • Data plane
          • Forward traffic to destination
        • Control Plane
          • Compute routing table
        • => Data & Control on routers
      • In SDN
        • Control plane runs on logically centralized controller
        • Network-wide control
        • Separation of Data and control
        • Moved from vertically integrated devices, slow innovation => Open interface, fast innovation
          • Control devices by software
    • What are advantages of SDN?
    • Overview
      • History
        • Pre-2004, distributed configuration
          • Router control protocol
          • BGP only
        • 2005, 4D
          • Decision plane
          • Data plane
          • Dissemination / Discovery plane
        • 2008, Openflow
          • Can be practical only when vendors open their api
            • To make switch cheap sets can be controlled from software
            • Allow us to decouple control and data
      • Infrastructures
      • Applications
  • Advantages of SDN
    • Separate control plane
      • Coordination
      • Evolve
      • Reasoning
      • => Allow us to apply all CS techniques
    • Infrastructure
      • Control plane
        • Software program (python, C)
        • Controller affects forwarding state using control command
      • Data plane
        • Programmable hardware
    • Applications
      • This course
        • Data centers
        • Backbone networks
        • Enterprise networks
      • Internet exchange points (IXPs)
      • Home networks
  • Examples of control plane operations
    • Compute state (forwarding path) that satisfies high-level policy
    • Computing a shortest path routing tree
    • Authenticating a user’s device based on MAC address
    • (x) rate-limiting traffic
      • Typically done in data plane
    • (x) Load balancing traffic based on hash of source IP
      • Decision made in forwarding time not by centralized controller
  • Control and Data Planes
    • Control Plane
      • Logic that controls forwarding behavior
      • Examples:
        • Routing protocols
        • Configuration for network middleboxes
    • Data Plane
      • Forward traffic according to control plane logic
      • Examples:
        • Forwarding
        • Switching
    • Routing protocol (control plane)
      • Compute functions
    • => Forwarding table entries (data plane)
    • Why separating data and control a good idea?
      • Independent evolution
      • Control from high-level program
        • Easier debug/check behavior
      • Provide opportunities
        • Data centers
          • Better network management
        • Routing
          • More control over decision logic
        • Enterprise network
          • Security
        • Research
          • Allow virtualize network
            • Coexisture w/ production
      • (x) No single point of failure
      • (x) Ability to scale
  • Example: Data center
    • There are many racks of servers
      • -> over 40000
    • Problem
      • Provisioning/migration in response to varying load
    • Solution
      • Program switch state from a central database
      • If we migrate a VM from a server to another,
        • We must update switch state
        • It is easier to do with central controller (db)
      • Servers are addressed with layer 2 addressing
        • -> Servers can be migrated without requiring new VM to obtain new address
        • -> All it needs to be happen is to update the switch state
  • Challenges
    • Example: Backbone security
      • Goal
        • Filter attack traffic
        • Measurement system detect attacker’s entry point
          • RCP (controller) install null route to ensure no traffic comes from the attacker
    • Scalability
      • One controller responsible for hundreds of switches
    • Consistency
      • Ensure different replicas (controllers) see same view
        • (logically centralized)
    • Security/Robustness
      • Failure or complete?
  • Coping with scalability
    • Eliminate redundant data structure
    • Only perform control-plane operations for a limited # of ops
    • Cache forwarding decisions in switches
    • Run multiple controllers
    • (x) sending all traffic to controller
  • Different SDN controllers
    • NOX
    • RYU
    • Floodlight
    • Pryetic
    • Frenetic
  • NOX
    • First generation openflow controller
      • Open source, stable, widely used
    • Two flavors
      • Classic
        • C++/python
      • New nox
        • C++
        • Fast, clean
    • Components
      • Switches
      • Network-attached servers
    • Abstraction
      • Switch control
    • Control
      • Flow granuality
      • Flow = {srcIP, dstIP, srcPort, …}
    • Operation
      • Flow <header:counter, actions>
        • header : 10 tuples
        • Counter: maintain statistics
        • Actions
          • Should be performed on packets that matches to the flow definitions
          • Forward, drop, seed to controller
      • Update controllers
      • Applies corresponding actions
    • Program Interface
      • Events
        • Controller
          • Know how to process different types of events
          • Keeps track of network view
            • topology
        • Events
          • Switch join/leave, packet received, …
    • NOX characteristics
      • C++
      • Openflow 1.0
      • Model : event based
        • -> event handlers for NOX control
      • (o) performance
      • (x) need to use low-level openflow commands
      • (x) only C++ (slow for dev) (POX for python)
  • When to use POX?
    • Class, University research
    • (x) performance
    • (o) eash (python)
  • Ryu, Floodlight, Nox, Pox
    • Ryu
      • Python
      • OF 1.0~1.3, Nicria
      • Openstack
      • (x) performance
    • Floodlight
      • Java
      • OF 1.0
      • Fork from “beacon”
      • (o) Documentation
      • (o) Integration with REST
      • (o) performance
      • (x) hard to learn
    • Nox
      • C++
      • OF 1.0
      • (o) performance
      • (x) Slow programming
    • Pox
      • Python
      • OF 1.0
      • (x) performance
      • (o) easy to program
  • Customizing Control
    • Review hub/switches
    • Pox controller w/ simple Mininet topology
    • Two types of control
      • Hub
      • Switch
    • Hub
      • Maintains no state
      • Simply forwards the input packet to every output ports
      • In Pox
        • Add listener for a switch connect
        • Use OF flow modification to the switch to flood
    • Switch
      • Maintain switch table
      • Learning switch
      • When a packet arrives from a host using a port, the switch updates table
      • In Pox
        • Update address/port table
          • Controller maintains the table
        • If multicast, flood
        • If no table entry (dst), flood
        • If src == dst, drop
        • Install flow flow table entry
          • Prevents future packet to the flow from being redirected to the controller
            • It can be directly handled by switch
  • Summary
    • OF makes modifying forwarding bahavior easy
      • Switching
        • {*,*, …, DST MAC, *} -> output port
      • Flow switching
        • {switch port, srcMac, … all filled} -> output
      • Firewall
        • {*, srcMac, *, *, …} -> forward/ drop
    • Caching
      • Packets only reach controller if no flow table entry at switch
      • When controller decides an action, installs it in switch
      • Decision/ flow table is cached
        • Until it expires
    • Customizing control is easy
    • Turning switch -> firewall < 40 lines of code
    • Performance benefits of caching rules/decisions

 

9.1 Programming SDNs
10. Traffic Engineering
  • Traffic Engineering Overview
    • Traffic Engineering
      • Process of reconfiguring the network in response to changing traffic loads, to achieve some operational goal
        • Some goals…
          • Peering ratios
          • Relieve congestion
          • Balance load
    • IP networks must be managed
      • “Self-management”
        • TCP
          • Send less during congestion
        • Routing
          • Adopt to topology changes
      • Problem:
        • Does the network run efficiently?
          • How routing should adapt to traffic?
            • Avoid congested links
            • Satisfying application requirements
    • Outline
      • Tuning routing protocol configuration
      • Intra & Interdomain Traffic Engineering
      • Multipath routing
  • Intradomain TE: Tuning link weights
    • Routers flood information to learn topology
    • Operator configures link weights
    • Possible settings:
      • Inversely proportional to capacity
      • Proportional to propagation delay
      • Network-wide optimization
  • Measuring, Modeling, and Controlling traffic
    • 3 steps: Measure, Model, Control
      • Measure topology and traffic
      • Build “what-if” model
      • Change configuration to control network behavior
    • Intradomain TE: Optimization
      • Input: Graph G(R,L) (R: router, L: links), cl: capacity of l
        • Mij: Traffic from router i to router j
      • Output:
        • Set of links weights wl
  • Link utilization Function
    • Objective function
      • Utilization: ul/cl
      • Objective: min f(ul/cl) in the all links
        • -> NP complete
      • Practice:
        • Minimize # of degrees to network
        • Resistance to failure
        • Robust to measurement noise
  • Intra vs Interdomain routing /TE
    • Intradomain:
      • Within a domain (e.g, ISP, campus, datacenter)
    • Interdomain:
      • Between domains
        • eg)
          • Peering between ISPs or university networks
          • Peering at an internet exchange point
  • BGP in interdomain TE
    • Interdomain traffic engineering
      • Allowing congestion on edge links
      • Using new/upgrade edge lineks
      • Changing end-to-end path
      • -> reconfiguration of BGP
  • Goals for Interdomain TE
    • Predictability
      • Try to avoid globally visible changes
        • Or it can make it works (check lecture figures)
    • Limit influence of neighbors
      • Forcing consistent advertisement is difficult but doable
      • Limit AS path influence
    • Reduce overhead of routing changes
      • Group routes that has same path
        • Can move groups of prefixes according to the groups of the prefixes that shares AS paths
  • Multipath routing
    • Operator establish multipath in advance
      • For Interdomain
        • Equal cost multipath (ECMP)
        • Traffic splitting
          • 35% to upper, 65% to lower path
    • How can a source router adjust path?
      • Alternating between forward table entries
        • Have multiple forward table entries for same dst
  • Data center networking
    • Charastertics
      • Multi-tenancy
        • (o) Allow to amortize cost shared infrastructure
        • (x) Security because multiple users
        • (x) Resource isolation
      • Elastic resources
        • Operator can expand or contract resources depends on demand
      • Flexible service management
        • Ability to move workload to other locations inside of datacenter
        • Workload management, migration
          • -> Requires TE
          • Enabler: Virtualization
  • Data Center Network Challenges
    • Challenges
      • Traffic load balance
      • Support for virtual machine migration
      • Power saving
      • Provisioning
      • Security
    • Data center topology (check out lecture figures)
      • Core
        • Historically connected to layer3
        • Modern: all layer-2 topology
          • (o) easier migration
            • Since servers can stay in same layer-2 network
              • -> no need new IP address
          • (o) easier load balance
          • (x) scale
            • Too many servers in a single “flat” topology
        • Problem with this topology
          • (x) potential single point of failure
          • (x) links on top can be oversubscription
      • Aggregation
      • Access
  • Data center topology
    • (x) scale
      • One solution
        • Pods
          • Each pod has address
          • Each server has “pseudo mac” corresponding to pod
            • Switches no longer need to maintain forwarding table for every host
            • Only need to maintain entries for reaching other pods
              • Once it reaches the pod, the switch for the pod has entries for the servers
        • Problem: mapping
          • Pseudo mac -> real mac!
          • Interrupt ARP
            • The switch forward it to fabric manager instead of flooding it
            • Fabric manager responds with the pseudo address
            • The server sends the frame with the destination pseudo address
            • The receiving switch switch pseudo mac -> real mac
        • Achieve hierarchical forwarding in a large layer-2 topology without modifying any host’s software
  • Data center (intradomain) TE
    • Limited server-to-server capacity
      • Links at “top” of fat tree topology are over-subscribed
    • Fragmentation (for resource)
      • Because of migrations
      • May require complicated L2/L3 re-configuration
      • VL2
        • Want: Abstraction of BIG L2 switch
        • Achieve layer-2 semantics across the entire data center topology
          • Done by name, location separation and a resolution that resembles fabric manager
        • Achieve uniform high capacity between servers and balance load across links
          • Flow based random traffic interaction
            • Valiant load balancing
  • Valiant load balancing
    • Goals
      • Spread traffic evenly across servers
        • Access layer randomly select a switch from indirection layer
          • The intermediate switch forward the packet to the dst
      • Location Independence
  • Jellyfish: Networking Data Centers Randomly
    • Goal
      • High throughput
        • Big data
      • Incremental expandability
        • Easy replacement of servers
    • Problem: Structure constrains expansion
      • Hypercube: 2^k switches
      • 3-level fat tree: 5k^2/4 switches
      • Top level switches constrains expansion
  • Jellyfish: Random Regular Graph
    • Random:
      • Each graph is randomly selected from regular graphs
    • Regular graph
      • Each node has same degree
    • Graph
      • Switches are nodes
    • Construction
      • Construct random graph at top of switch layer
      • RRG(N,k,r)
        • ki : total ports
        • ri: to connect to other TopofRack switches
        • Ki-Ri ports to connect to servers
        • With N rackes, the network supports
          • N(Ki-Ri) servers
  • Constructing Jellyfish (check lecture figures)
    • Pick a random (not neighboring) switch pair
    • Join them with a link
    • Repeat until no links can be added
    • High capacity is achieved because of shorter paths
      • Can reach more servers in same number of hop jumps
  • Open questions
    • Topology design
      • How close are random graphs to optimal?
      • What about heterogeneous switches?
    • System design
      • How to physically cable?
      • How to perform routing or congestion control?
11. Network Security
  • Need for Network Security
    • Attacks on:
      • Routing (BGP)
      • Naming (DNS)
        • Reflection (DDos)
          • Generate large amout of traffic targetted at a victim
        • Phishing
          • An attacker expliots the DNS and attempt to trick a customer
  • Internet is Insecure
    • Internet is designed for simplicity
      • Security was not a primary issues
    • On by default
      • When a host is connect to internet, it is reachable any other hosts with public IP by default
    • Hosts are insecure
    • Attacks can look like “normal” traffic
      • Collection of traffics can be a attack
    • Federated design
      • Because there are many individual networks run by different network operators, it is difficult to coordinate a defense
    • (x) IP addresses are easy to guess
  • Resource Exhaustion Attack
    • Packet Switching Network Vulerable: Resource Exhaustion
      • A link can be shared by different senders by statistical multiplexing
        • A large number of senders can overload node or link
          • Phone network doesn’t have this problem (statically dedicated resource)
      •  Attacks a basic component of security (availability)
    • Components of Security
      • Ability
        • Ability to use a resource
      • Confidentially
        • Conceal information (bank, …)
      • Authenticity
        • Assures origin of information
      • Integrity
        • Prevent unauthorized changes
    • Threat: Potentially violate one of the conponents of security
    • Attack: Action that violates the components
  • Attacks on Confidential
    • Eavesdropping
      • Packet sniffing tools
        • Wireshark, tcpdump
        • Set network card in promiscuous mode
      • DNS
        • What website someone is visiting
      • Packet headers
        • What type of app you use
      • Full packet payload
        • See everything you are sending on network
        • Content, messages, …
    • Attack on Authenticity
      • Eve might modify it and reinject to the network
      • Man in the middle
  • Negative impacts of attacks
    • Thief of confidential info
    • Unauthorized use
    • False info
    • Disruption of service
  • Routing Security (BGP)
    • Control plane security (authentication)
      • Determine the veracity of routing advertisement
      • Session
        • Protects point-to-point between routers
      • Path
        • Protects AS paht
      • Origin
        • Guarantee the origin AS that advertises the prefix is the owner of prefix
        • Router hijack
          • Because the advertisement was not from right owner
    • Data plane
      • Data travelling to the intended locations (route)
        • It is hard to verify
  • Route Attacks
    • How?
      • Misconfiged router error
        • unintended attack
      • Routers compromised by attacker
        • Attacker reconfigure the router
      • Unscrupulous ISP
    • Types of attack
      • Config / or change config with sw
      • Tamper with software
      • Tamper with routing data
    • Most common
      • Router hijack
  • Route Hijacking
    • Why hijack matter: DNS masquerade
      • Attacker runs rough DNS server and hijack DNS query or to return false IP
    • MITM
      • Traffic reaches the destination, but the attacker inserts themselves in the path
      • Problem:
        • We need to somehow disrupt the routes to the rest of the internest while leaving the routes between the attacker and the legitimate AS
      • Solution:
        • By AS poisoning
          • insert 10, 20 on AS path MITM
            • 10 and 20 will drop the announcement becasue they think they’ve already heard it and don’t want to form a loop
            • Other ASes will switch path
      • Attacker can hide!
        • Even when sender runs trace route
          • Trace route consists of ICMP time exceeded message
        • Attacker don’t decrease TTL where other hops decrease it
          • Then it won’t generate no time exceeded message
  • Session Authentication
    • The session is TCP connection between routers
      • Use MD5 authentication
        • Send (M (message), MD5(M, k)); k: shared secret
          • Network agree on k at the outside of network
      • TTL hack
        • AS1 send with TTL224, and AS2 drops packets TTL < 224
  • Origin and Path Authentication
    • Guaranteeing Origin & Path Authentication
      • New BGP
        • Secure BGP (BGPSEC)
        • Add signature to route advertisement
        • Origin Authentication (Address Attestation)
          • Certificate binding prefix to owner
            • Certificate must be signed by trusted party
        • Path Attestation
          • Setup signature along AS path
          • ki : secret key of AS i
          • P -> AS1 -> AS2 -> AS3
            • [1]
              • (P, 1) : (prefix, AS path)
              • {2,1}k1 : attestation
            • [2]
              • (P, 2 1)
              • {3, 2, 1} k2
                • Use this to make sure next hop is 2
              • {2,1}k1
                • Check if there’s any other AS inserted by comparing with (P, 2 1)
          • Why have {3,2,1} and {2,1}?
            • If AS1 generate {1}k1, an attacker can steal and replay right away
            • But if AS1 generate {1,2}k1, an attacker cannot make {1}k1 or {4,1}k1 because the attacker doesn’t have k1 key
            • => AS generate signs with its own AS path and next AS along the path
          • Prevents
            • Hijacking
            • Path shortening attack
            • Modification
          • Cannot prevent
            • Suppression
              • If an AS fails to advertise a route or a route withdrawl, there’s no way for the path attestation BGPSEC to prevent that kind of attack
            • Replay
              • Premature re-advertisement of a withdrawn route
            • No way to guarantee the data traffic travels along the advertised AS path
              • Significant weakness of BGP
  • DNS Security
    • DNS architecture
      • MITM
        • Stub -> Caching resolver
          • Read query and it responds
          • -> use DNSSEC protection
        • Cache Resolver
          • Cache poisining
            • Attacker can send reply back to the resolver before real reply comes back
            • -> use 0x20 protection
      • Spoofing
        • Master Authenticative (<- cache resolver)
        • SlaveAuthenticative (<-Master Authenticative)
        • Dynamic update system (-> Master Authenticative)
        • -> use DNSSEC protection
      • Corrupt
        • Zone file (->Master Authenticative)
    • DNS reflection attack
      • DNS can be a “weapon” for DDos
  • Why is DNS vulerable
    • Resolvers trust responses
      • regardless where those comes from
    • Responses can contain info unrelated to query
    • No means for Authentication for responses!!
    • DNS quires are connectionless (UDP)
      • Resolver can’t map response for the query (other than query id)
        • query id can be forged by attacker
  • DNS cache poising
    • Stub resolution (A, google.com) -> Recursive resolver -> (A, google.com) -> SoA (Server of Authority)
    • Attacker -> Recursive resolver
      • Flood with replies with different query id
        • Attacker doesn’t need to see the actual id, it just flood
      • If attack respond reaches faster than the actual response,
        • Cache the bogus response!
    • Defenses
      • query id
        • but it can be guessed
      • Randomized ID (only 16 bits)
        • Rather than having a resolver send quires with sequencly incrementing ID the resolve pick random id
        • It is harder to guess for attacker, but it’s still not too hard
    • Attacker can generate his own DNS quries
      • 1. google.com, 2. google.com, …
      • It will generate new race
        • Eventually, attacker will win one of the races
    • Attacker can respond with NS record not only A
      • Kaminsky attack
        • Create one of these races using an A record query, and responding not only with the A record, but also with the authoritative NS record for the entire zone
        • Attacker can own the entire zone
  • Defense to DNS cache poisoning
    • ID + Randomization
    • Source port randomization
      • Randomize the port which it sends query
      • Adding another 16 bits
      • (x) it can be resource intensive
      • (x) NAT (network address translator) could derandomize the port
    • 0x20 Encoding
      • DNS is case insensitive
      • GoOGle.com == google.com
      • Adding another entropy
      • Only the resolver and the authoritative know exact pattern
      • Add another entropy
  • DNS Amplification Attack
    • Exploits asymmetry in size between queries & responses
    • Attacker send DNS query with victim’s IP as source
      • DNS will response to the victim with large size which causes traffic
      • DDos on victim
    • Defenses:
      • Prevent IP address Spoofing
        • Using appropriate filtering rules
      • Disable open resolver
        • Disable the resolver to resolve queries from arbitrary locations
  • DNSSEC DNS Security
    • DNSSEC
      • Add Authentication to DNS responses
        • By adding signatures
        • Resolver -> (root)
        • Resolver <- (NS.com) (sig(IP + Pk of .com server)) (root)
          • signed by root’s private key
          • Pk: Public key of .com server
          • As long as the resolver have public key corresponding to root, it can check signature, and it knows public key for .com server
        • Resolver <- (NS google.com) (sig(IP + Pk of google.com)) (.com)
          • Resolver can check if the respond is not bogus because it already has .com’s public key
11.1 Internet Worms
  • Types of Viruses and Worm Overview
    • Virus
      • Infection of an existing program that results in modification of behavior
      • Spread typically requires user action
        • Opening an attachment
      • Spread manually
    • Worm
      • Code that propagate/replicate across the network
      • Spread by exploiting flaws
      • Spread automatically
        • By scanning vulerabilities and infect vulerable hosts
    • Types of Viruses
      • 1. Parasitic
        • Infects executable files
      • 2. Memory-resident
        • Infect running programs
      • 3. Boot-sector
        • Spreads when system is booted
      • 4. Polymorphic
        • Encrypt part of virus program using randomly generated key
      • Worm might use any of the techniques to infect before spread
  • Worm Lifecycle
    • 1. Discover
      • Scan for vunlerable hosts
    • 2. Infect vulnerable machines via remote exploit
    • 3. Remain undiscoverable
  • First Worm: “Morris Worm”
    • Robert, 1988
    • No malicious payload
      • but, resrouce exhaustion
      • affected 10% of internet hosts
    • Spread through multiple vectors
      • Remote shell execution/ weak password
        • Targeted trusted hosts by already infected machine
      • Buffer overflow/ remote exploit
      • Debug command in sendmail service
  • Worm Outbreaks In Detail
    • Three major worm outbreaks
      • 1. Code Red 1 (2001)
        • “modern” worm
        • IIS buffer overflow
        • 1th ~ 20th : spread
        • Infects “random” scanning bug
        • Payload
          • DDos on whitehouse.gov
          • But failed because it targetted an IP not the domain
      • 2. Code Red 2
        • Same vulerability, different payload
        • Only spread on Windows 2002
        • Scan preferred nearby addresses
          • Because if there’s 1 vulnerable host, it is likely to be more (maybe because same admin)
        • Payload
          • ISS backdoor
      • 3. Nimda (multi-model)
        • Spread by
          • IIS vulnerablilty
          • Build email
          • Network shares
            • Copied itself to network
          • Installed code in webpage
            • Anyone browser visiting the webpage would be infected
        • Signature based defenses don’t help
          • Because it uses many ways to spread
        • Zero-day attack
          • Email carrying Nimda was untouched
            • Because it had unknown signature, and the scanner couldn’t detect
          • The signature of worm was not extracted
            • Extrremely easy to spread befure any anti-virus catches up
  • Modeling Fast-spreading Worms
    • Random Constant Spread
      • k: initial compromised rate
      • N: vulerable hosts
      • a: fraction of host already compromised
      • Nda (new infected in dt) = (Na) * (k(1-a) (rate of uninfected machines become compromised)) dt
      • a = (e^k(t-T))/(1+e^k(t-T))
        • => we need to have “k” (initial compromised rate) as high as possible
  • Increasing Initial Compromised Rate
    • Hit List
      • Create hit list (list of vulnerable hosts) ahead of time
    • Permutation Scanning
      • Every infected hosts has shared permutation of IP address lists.
      • Start from own IP & work down
        • Different own IP -> make sure to not duplicate
    • Slammer Worm
      • Entire code in one UDP packet!
        • => UDP is connectionless!
      • Damage on ATM, cellphone, …
      • Did not have payload
        • But the bandwidth exhaustion cause resource exhaustion
11.2 Spam
  • Span: Unwanted Commercial Email
    • Most span ends up in your spam folder
    • Problem
      • 1. Filters
        • Someone has to design this
      • 2. Storage
        • Server has to keep the spam until user deletes it
      • 3. Security Problem
        • Phishing
    • Filter
      • Prevent message from reaching inbox
      • How to differentiate Spam from “ham”?
        • 1. Content based (particular words)
          • (x) easy to evade
          • (x) building filter and update it is expensive
        • 2. IP address of sender (blacklist)
          • Sender -> receiver -> DNSBL (blacklist)
          • Receiver can decide to not even receive it
            • Server can save storage
        • 3. Behavior features
          • Filter based on “how” message is sent
            • Particular time or of day or location
            • Sent batch of emails with roughly same size
          • Challenges
            • 1. Understanding network level behavior
            • 2. Building classifiers using network features to execute the filter
  • Surprise: BGP “Agility”
    • 1. Hijack IP prefix (short period of time: 10 min)
    • 2. Send spam
    • 3. Withdraw
    • => Ephemeral IP address
      • IP blacklist is ineffictive
    • Set of Network-level features
      • 1. Single-packet
        • Distance b/w sender & receiver
        • Density of IP space
          • How many email senders are nearby
        • Time of day
        • AS of sender’s IP
      • 2. Single-message
        • # of recipients
        • length of message
      • 3. Aggregate
        • See groups of messages
          • Variation in message length
      • SNARE (Spatio Temperal Netowk Level Automated Reputation Engine)
        • Use Network-level features
        • 70% detection: good enough
11.3 Denial of Service Attacks
  • Denial of Service Overview
    • What is DDos?
      • Attempt to exhaust resources
        • Network bandwidth
        • TCP connections
          • Host might have limited # of TCP connections
        • Server resources
          • Web server might have to do complicate job to render
    • Defenses
      • Ingres Filtering
        • drop if src != 111.111.111/24
        • Works with stub system
          • Stub network has only one IP address
        • (o) fool proof
        • (o) works at edge
        • (x) doesn’t work in core
      • uRPF
        • User routing tables to determine where the packet could feasibly arrived on a particular interface
        • x -> 10.0.1.0/24 -> AS1, x -> 10.0.18.0/24 -> AS2
          • if src (10.0.18.3) from 1 -> x
            • drop it
        • (o) automatic
        • (x) requires symmetric routing
          • routing in internet is often asymmetric
      • Sync Cookies (TCP)
  • TCP 3-way handshake
    • C -> syn -> S
    • S -> syn-ack -> C
    • C -> ack -> S
    • S -> ack -> C
    • Problem
      • Client can send syn to make server to allocate buffer
        • The syn can be spoofed IP
    • Solution : Syn Cookie
      • No buffer allocated on C->syn->S
        • Instead create seq# = f(srcIP, …, random # to prevent reply attack)
      • S -> syn-ack (seq#) -> C
      • C -> ack (seq#) -> S
        • Server checks seq#
      • (x) can be applied in the network “core”
      • (x) Defense against UDP flooding attacks
  • inferring Dos Activity (“Backscatter”)
    • IP address spoofing -> “blackscatter”
    • attacker(y) -> tcp syn(src:x) -> victim
    • victim -> syn-ack -> x (backscatter)
    • If src:x is selected random,
      • we can setup a portion of network Telescope/8 to monitor the backscatter traffic
      • syn-ack goes to this network
      • If src:x is picked uniformly random, the amount of traffic we see as backscatter represents exactly fraction of propotional to the size of overall attack
        • n IP address, m backscatter packets,
          • We expect to see (n/2^32) * m of total backscatter packets == total attack rate
          • Total attack rate (m) = x * (2^32/n)
            • x: observered attack rate
            • n: 2^24 because Telescope/8

Leave a Reply

Your email address will not be published.