Inter-machine communication • Datagram sockets: Unreliable message delivery - User Datagram Protocol (UDP/IP) - Send atomic messages, which may be reordered or lost • Stream sockets: Bi-directional pipes - Transmission Control Protocol (TCP/IP) - Bytes written on one end read on the other Socket naming • Every Internet host has a unique 32-bit IP address - Often written in “dotted-quad” notation: 204.168.181.201 - DNS protocol maps names (www.nyu.edu) to IP addresses - Network routes packets based on IP address • 16-bit port number demultiplexes TCP traffic - Well-known services “listen” on standard ports: finger—79, HTTP—80, mail—25, ssh—22 - Clients connect from arbitrary ports to well known ports - A connection consists of five components: Protocol (TCP), local IP, local port, remote IP, remote port IP header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 vers hdr len TOS Total Length DM Identification 0 F F Fragment offset TTL Protocol hdr checksum Source IP address Destination IP address Options Padding IP header details • Routed to destination address specified • TTL (time to live) decremented at each hop (avoids loops) • Fragmentation used for large packets - Fragmented in network if links crossed with smaller MTU - MF bit means more fragments for this IP packet - DF bit says “don’t fragment” (returns error to sender) TCP header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 source port destination port sequence number acknowledgment number UA P R S F data reserved R C S S Y I Window offset G KH T NN checksum urgent pointer options padding data TCP fields • Ports • Seq no. – segment position in byte stream • Ack no. – seq no. sender expects to receive next • Data offset – # of 4-byte header & option words • Window – willing to receive (flow control) • Checksum • Urgent pointer TCP Flags • URG – urgent data present • ACK – ack no. valid (all but first segment) • PSH – push data up to application immediately • RST – reset connection • SYN – “synchronize” establishes connection • FIN – close connection A TCP Connection (no data) orchard.48150 > essex.discard: S 1871560457:1871560457(0) win 16384 essex.discard > orchard.48150: S 3249357518:3249357518(0) ack 1871560458 win 17376 orchard.48150 > essex.discard: . ack 1 win 17376 orchard.48150 > essex.discard: F 1:1(0) ack 1 win 17376 essex.discard > orchard.48150: . ack 2 win 17376 essex.discard > orchard.48150: F 1:1(0) ack 2 win 17376 orchard.48150 > essex.discard: . ack 2 win 17375 Connection establishment • Three-way handshake: - C ! S: SYN, seq SC - S ! C: SYN, seq SS, ack SC + 1 - C ! S: ack SS + 1 • If no program listening: server sends RST • If server backlog exceeded: ignore SYN • If no SYN-ACK received: retry, timeout Connection termination • FIN bit says no more data to send - Caused by close or shutdown on sending end - Both sides must send FIN to close a connection • Typical close: - A ! B: FIN, seq SA, ack SB - B ! A: ack SA + 1 - B ! A: FIN, seq SB, ack SA + 1 - A ! B: ack SB + 1 • Can also have simultaneous close • After last message, can A and B forget about closed socket? TIME WAIT • Problems with closed socket - What if final ack is lost in the network? - What if the same port pair is immediately reused for a new connection? (Old packets might still be floating around.) • Solution: “active” closer goes into TIME WAIT - Active close is sending FIN before receiving one - After receiving ACK and FIN, keep socket around for 2MSL (twice the “maximum segment lifetime”) Sending data • Data sent in MSS-sized segments - Chosen to avoid fragmentation (e.g., 1460 on ethernet LAN) - Write of 8K might use 6 segments—PSH set on last one - PSH avoids unnecessary context switches on receiver • Sender's OS can delay sends to get full segments - Nagle algorithm: Only one unacknowledged short segment - TCP NODELAY option avoids this behavior • Segments may arrive out of order - Sequence number used to reassemble in order • Window achieves flow control - If window 0 and sender's buffer full, write will block or return EAGAIN A TCP connection (3 byte echo) orchard.38497 > essex.echo: S 1968414760:1968414760(0) win 16384 essex.echo > orchard.38497: S 3349542637:3349542637(0) ack 1968414761 win 17376 orchard.38497 > essex.echo: . ack 1 win 17376 orchard.38497 > essex.echo: P 1:4(3) ack 1 win 17376 essex.echo > orchard.38497: . ack 4 win 17376 essex.echo > orchard.38497: P 1:4(3) ack 4 win 17376 orchard.38497 > essex.echo: . ack 4 win 17376 orchard.38497 > essex.echo: F 4:4(0) ack 4 win 17376 essex.echo > orchard.38497: . ack 5 win 17376 essex.echo > orchard.38497: F 4:4(0) ack 5 win 17376 orchard.38497 > essex.echo: . ack 5 win 17375 Retransmission • TCP dynamically estimates round trip time • If segment goes unacknowledged, must retransmit • Use exponential backoff (in case loss from congestion) • After ∼10 minutes, give up and reset connection Bro: Detecting network intruders • Many security holes exploited over the network - Buffer overruns in servers - Servers with bad implementations (“login -froot”, telnet w. LD LIBRARY PATH) • Goal: Detect people exploiting such bugs • Detect activities performed by people who've penetrated server - Setting up IRC bot - Running particular commands, etc. Bro model • Attach machine running Bro to “DMZ” - Demilitarized zone – area betw. firewall & outside world • Sniff all packets in and out of the network • Process packets to identify possible intruders - Secret, per-network rules identify possible attacks - Is it a good idea to keep rules secret? • React to any threats - Alert administrators of problems in real time - Switch on logging to enable later analysis of potential attack - Take action against attackers – E.g., filter all packets from host that seems to be attacking Goals of system • Keep up with high-speed network - No packet drops • Real-time notification • Separate mechanism from policy - Avoid easy mistakes in policy specification - So different sites can specify “secret” policies easily • Extensibility • Resilience to attack Challenges • Have to keep up with fast packet rate • System has to be easy to program - Every site needs different, secret rules - Don't want system administrators making mistakes • Overload attacks • Crash attacks • Subterfuge attacks Bro architecture • Layered architecture: - bpf/libpcap, Event Engine, Policy Script Interpreter • Lowest level bpf filter in kernel - Match interesting ports or SYN/FIN/RST packets - Match IP fragments - Other packets do not get forwarded to higher levels • Event engine, written in C++ - Knows how to parse particular network protocols - Has per-protocol notion of events • Policy Script Interpreter - Bro language designed to avoid easy errors Overload and Crash attacks • Overload goal: prevent monitor from keeping up w. data stream - Leave exact thresholds secret - Shed load (e.g., HTTP packets) • Crash goal: put monitor out of commission - E.g., run it out of space (too much state) - Watchdog timer kills & restarts stuck monitor - Also starts tcpdump log, so same crash attack, if repeated, can be analyzed Questions • Why is FTP more complicated? How to handle? • How to deal with type-ahead in telnet/rlogin connections? • What are network scans? Port scans? How to detect these? • How convinced are we of effectiveness? Subterfuge attacks • IP fragments too small to see TCP header • Retransmitted IP fragments w. different data • Retransmitted TCP packets w. different data • TTL/MTU monkeying can hide packets from destination - Compare TCP packet to retransmitted copy - Assume one of two endpoints is honest (exploit ACKs) - Bifurcating analysis State and checkpointing • Need to keep a lot of session state - Open TCP connections, UDP request-response, IP fragments - No timers to garbage collect state • Checkpointing the system - Start new copy of monitoring process - Kill old copy when new copy has come up to speed - Is this ideal? Stretch break Much read-only data improperly trusted • People install/upgrade software over the Internet - No guarantee you are talking to the right host - No guarantee server has not been compromised - No guarantee you can trust a mirror site's owner • Central servers configure/upgrade machines - sup, anonymous rsync, AFS read-only—all insecure • People base financial decisions on public data - Stock quotes, financial news Why people avoid security • Performance - Public-key cryptography can cripple throughput (e.g. SSL) • Scalability and reliability - Widespread replication essential for popular data - The more replicas, the less they can be trusted • Convenience - Most users will skip optional verification steps - Often hard to understand precise security guarantees Example: PGP-sign data off-line • Advantages: - Compromising server does not circumvent PGP security - Data can be replicated on untrusted servers • Not general purpose • Most users will ignore signatures • Requires continued attention of user - Was file signed by authoritative key? - Is a signed file the latest version? - Does signed contents of file match file name? - Were two separately signed files published together? Solution: SFS read-only file system • Convenience: Use the file system interface - Publish any data - Access it from any application • Scalability: Separate publishing from distribution - Off-line publisher produces signed database - On-line servers/replicas completely untrusted • Intrinsic security: Nothing for user to do - Every file system has a public key (specified in name) - Client automatically verifies integrity of files SFSRO Architecture