SENSS Security Service for the Internet Jelena Mirkovic

SENSS Security Service for the Internet Jelena Mirkovic (USC/ISI) Minlan Yu (Harvard) Ying Zhang (Facebook) Rajat Tandon (USC) Sivaram Ramanathan (USC)

DDo. S Attacks: Large and Powerful • DDo. S attacks are increasing in volume and frequency (new record 1. 3 Tbps) • Disproportionate power in hands of attacker – Attacks that bring down large, well provisioned victims often wielded by a single person or small group (Spamhouse, Dyn, OVH and Krebs) – No special experience or circumstance – Cheap for attacker, very expensive for the victim • Enabled by large, distributed botnets – No single entity (centralized or distributed) can withstand this, distributed defenses a must 2

Our solution: SENSS • Enables any ISP to offer automated services for DDo. S diagnosis and mitigation – Naturally distributed and victim-driven – Secure, robust to misbehavior – Works with existing ISP infrastructure • Victim queries its own ISP or remote ISPs about: – Its inbound traffic, routes to its prefixes – This helps detect best points for mitigation • Victim asks select ISPs to: – Filter some of its inbound traffic (victim specifies header signature) – Demote a route that may contain a bottleneck 3

SENSS Modules • Detect an attack, provide signature: – Detector • Securely request and implement actions that mitigate the attack via automated victim-ISP communication: – Client – Server – Proxy (if Client is unable to communicate) • Prevent attacks: – Blacklist Aggregator 4

SENSS Modules server Five independent modules blacklist aggregator proxy detector server client detector server 5

SENSS Modules Detector (AMON-SENSS) Detects the attack and devises signature for filtering blacklist aggregator proxy Interfaces with the client server client attack signature detector 6

SENSS Modules Client Talks to servers in victim’s name, collects reports, decides on actions Possibly mult. comm. rounds with multiple servers blacklist aggregator proxy server query msg filter msg client detector 7 7

SENSS Modules Server Receives and authenticates client requests. Performs monitoring and filtering requested by the client. Sends back traffic and route reports blacklist aggregator proxy server Volume of matching traffic per POP client detector 8 8

SENSS Modules Proxy Victim sets up the proxy as a backup, delegates credentials. Proxy probes the victim, and takes over if the victim is unresponsive. Client can trigger the proxy w one-way msg. blacklist aggregator Comm. w proxy server as SENSS client server client detector 9 9

SENSS Modules Blacklist aggregator (BLAG) Produces a master blacklist A public service, which produces a timely, accurate, aggregate blacklist from many feeds. SENSS servers could offer preventative filtering using this list. blacklist aggregator proxy server client detector 1 10 10

Integrating SENSS with Victim/Proxy • Simple Python application – – No specific requirements for integration Lightweight messaging and data processing 11

Integrating SENSS With ISPs • SENSS is a Web application, which can be ran on any Web server within an ISP: – – – • Admin account requires 2 -factor authentication Use RPKI or set up DB for proof of authority for a prefix Supply IP addresses of switches and any credentials SENSS needs traffic/route observation and filtering: – – – For traffic observation: SDN or Netflow For traffic filtering: SDN or Flowspec or ACLs For route observation/filtering: interact with router software (Quagga) 12

SENSS APIs at ISPs • Exposed as Web services – • Leverage existing functionalities for robustness (replication), security (HTTPS), charging (e-commerce) Type Fields Action/Reply Traffic query Flow, dir, obs_time List of <tag, dir, volume> Traffic filter/allow Flow, dir, tag, duration Deploy filter/allow actions Route query Prefix List of best paths to prefix Route demote Prefix, segment, duration Demote routes with given segment Message authentication: Proof of authority for a prefix – E. g. , RPKI, a DB of known customers, prefixes and public keys • TLS for communication security 13

SENSS Client Programs Using APIs Flood w signature Flood w/o signature 14

SENSS Client Programs Using APIs Reflector Crossfire and blackholing hijack 15

SENSS Client Programs Using APIs Interception BGP hijack 16

Select Results Flood w signature Very effective at 1% top-AS deployment Flood w/o signature Crossfire 17

Select Results Flood w signature At 1% top-AS deployment - Outperforms clouds in DDo. S def. - Outperforms clouds in route correction - Does not make AS path longer while clouds do Blackholing 18

Benefits • Deployable with current ISP infrastructure: – Victim or ISP can diagnose an attack or drive the entire defense • Secure – Victim can only control its own traffic/routes • Motivates deployment at ISPs – Increases portfolio of services • Aligns control of traffic/routes with ownership – End-network fully in charge of its own defense • Excellent performance in simulation (effective in sparse deployment) and emulation (fast, low overhead) 19

Competition • Research solutions – Source-destination collaboration – Effective only in very large deployment – Often require router changes – not deployable • Operational solutions – End-network filters– don’t work against high volume – ISP solutions (RTBH) – often inflict large collateral damage – Cloud defenses – withstand some attacks but not all, expensive and with finite resources, signature-based • SENSS complements operational solutions – Enables collaborative, scalable defense on demand 20

Technology Transition • Public prototype released on Github • Underwent code revision to make it user-friendly • Talks at NANOG 64 and 67 • Repeated talks with CENIC, Los Nettos and ESNet – Slow because no operational experience and demand for human operator time • Planned pilot at three ISPs under extended contract • Exploring transition to end networks – E. g. , campuses, libraries, K-12 institutions 21

Lessons Learned • Hard to do tech transition in parallel with development • ISPs value human time much more than money • Prefer cloud-based solutions, however imperfect, because they require no human time investment • In the past three years Internet 2 has chosen a cloud solution, CENIC has piloted one and UC is planning to use one • These solutions have low price, but also low bandwidth to the victim and no way to measure accuracy • ISPs are scared of letting customers control their network – Some are even scared of SDN in general and prefer manual control – Even though distribution brings the best outcome technically, realistically we should start with edge deployment • Deployment requires long trust-building – Smaller organizations may be more ready to adopt new solutions 22

Thank You! Jelena Mirkovic Minlan Yu Ying Zhang Rajat Tandon Sivaram Ramanathan