Outline Brief introduction to networking CSci 5271 Introduction to Computer Security Announcements intermission Day 13: Network, etc., security overview Some classic network attacks Stephen McCamant University of Minnesota, Computer Science & Engineering Second half of course The Internet Layered model (OSI) 7. Application (HTTP) A bunch of computer networks voluntarily 6. Presentation (MIME?) interconnected 5. Session (SSL?) Capitalized because there’s really only one 4. Transport (TCP) No centralized network-level management 3. Network (IP) But technical collaboration, DNS, etc. 2. Data-link (PPP) 1. Physical (10BASE-T) Layered model: TCP/IP Packet wrapping IP(v4) addressing IP and ICMP Interfaces (hosts or routers) identified by 32-bit Internet Protocol (IP) forwards individual packets addresses Packets have source and destination addresses, Written as four decimal bytes, e.g. 192.168.10.2 other options First ❦ bits identify network, ✸✷ ✲ ❦ host within Automatic fragmentation (usually avoided) network ICMP (I Control Message P) adds errors, ping Can’t (anymore) tell ❦ from the bits packets, etc. We’ll run out any year now
UDP TCP User Datagram Protocol: thin wrapper around IP Transmission Control Protocol: provides reliable bidirectional stream abstraction Adds source and destination port numbers (each 16-bit) Packets have sequence numbers, acknowledged in order Still connectionless, unreliable OK for some small messages Missed packets resent later Flow and congestion control Routing Where do I send this packet next? Flow control: match speed to slowest link Table from address ranges to next hops “Window” limits number of packets sent but not ACKed Core Internet routers need big tables Congestion control: avoid traffic jams Maintained by complex, insecure, cooperative Lost packets signal congestion protocols Additive increase, multiplicative decrease of rate Internet-level algorithm: BGP (Border Gateway Protocol) Below IP: ARP DNS Address Resolution Protocol maps IP addresses to Domain Name System: map more memorable and lower-level address stable string names to IP addresses E.g., 48-bit Ethernet MAC address Hierarchically administered namespace Based on local-network broadcast packets Like Unix paths, but backwards Complex Ethernets also need their own routing (but ✳❡❞✉ server delegates to ✳✉♠♥✳❡❞✉ server, etc. called switches) DNS caching and reverse DNS Classic application: remote login Killer app of early Internet: access supercomputers To be practical, DNS requires caching at another university Of positive and negative results Telnet: works cross-OS But, cache lifetime limited for freshness Send character stream, run regular login program Also, reverse IP to name mapping rlogin: BSD Unix Based on special top-level domain, IP address written Can authenticate based on trusting computer connection backwards comes from (Also rsh, rcp)
Outline Note to early readers Brief introduction to networking This is the section of the slides most likely to change Announcements intermission in the final version If class has already happened, make sure you have Some classic network attacks the latest slides for announcements Second half of course Outline Packet sniffing Brief introduction to networking Watch other people’s traffic as it goes by on network Announcements intermission Easiest on: Old-style broadcast (thin, “hub”) Ethernet Some classic network attacks Wireless Or if you own the router Second half of course Forging packet sources TCP spoofing Forging source address only lets you talk, not listen Source IP address not involved in routing, often not Old attack: wait until connection established, then checked DoS one participant and send packets in their place Change it to something else! Frustrated by making TCP initial sequence numbers Might already be enough to fool a naive UDP unpredictable protocol But see Oakland’12, WOOT’12 for fancier attacks, keyword “off-path” ARP spoofing rlogin and reverse DNS rlogin uses reverse DNS to see if originating host is on whitelist Impersonate other hosts on local network level How can you attack this mechanism with an honest Typical ARP implementations stateless, don’t mind source IP address? changes Now you get victim’s traffic, can read, modify, resend
rlogin and reverse DNS Outline rlogin uses reverse DNS to see if originating host is Brief introduction to networking on whitelist Announcements intermission How can you attack this mechanism with an honest source IP address? Some classic network attacks Remember, ownership of reverse-DNS is by IP address Second half of course Cryptographic primitives Cryptographic protocols Core mathematical tools Sequence of messages and crypto privileges for, e.g., key exchange Symmetric: block cipher, hash function, MAC A lot can go wrong here, too Public-key: encryption, signature Also other ways security can fail even with a good Some insights on how they work, but concentrating crypto primitive on how to use them correctly Crypto in Internet protocols Web security: server side Web software is privileged and processes untrusted How can we use crypto to secure network protocols data: what could go wrong? E.g., rsh ✦ ssh Shell script injection (Ex. 1) Challenges of getting the right public keys SQL injection Fitting into existing usage ecosystems Cross-site scripting (XSS) and related problems Web security: client side Security middleboxes Firewall: block traffic according to security policy JavaScript security environment even more tricky, NAT box: different original purpose, now de-facto complex firewall More kinds of cross-site scripting IDS (Intrusion Detection System): recognize possible Possibilities for sandboxing attacks
Malware and network DoS Adding back privacy Every Internet packet has source and destination Attacks made possible by the network addresses on it Viruses, trojans, bot nets So how can network traffic be private or Detection? anonymous? Mitigation? Key technique: overlay a new network Distributed denial of service (DDoS) Examples: onion routing (Tor), anonymous remailing Usability of security Electronic money (Bitcoin) Current payment systems have strong centralized trust Prevent people from being the weakest link US Federal Reserve and mint Usability of authentication Banks, PayPal “Secure” web sites, phishing Could they be replaced by a peer-to-peer distributed Making decisions about mobile apps system? Maybe Electronic voting Next time Challenging: hard versions of many hard problems: Trust in software Usability Symmetric crypto primitives Simultaneously public and private Some deployed systems arguably worse than paper Can do better with crypto and systems approaches
Recommend
More recommend