* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Security Problems in the TCP/IP Protocol Suite
Survey
Document related concepts
Server Message Block wikipedia , lookup
Network tap wikipedia , lookup
Deep packet inspection wikipedia , lookup
Computer network wikipedia , lookup
Airborne Networking wikipedia , lookup
Remote Desktop Services wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Distributed firewall wikipedia , lookup
Wireless security wikipedia , lookup
TCP congestion control wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Internet protocol suite wikipedia , lookup
Extensible Authentication Protocol wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Routing in delay-tolerant networking wikipedia , lookup
Transcript
Security Problems in the TCP/IP Protocol Suite Presented by: Sandra Daniels, José Nieves, Debbie Rasnick, Gary Tusing Article by: S. M. Bellovin AT&T Bell Laboratories April, 1989 TCP/IP Protocol Suite Widely used Developed under DOD Serious security flaws Topics to be Discussed Problems and defenses Handshake sequence numbers Routing Authentication Service protocols Comprehensive defenses Conclusion TCP Sequence Number TCP Handshake C → S: SYN (ISNc) S → C: SYN (ISNs), ACK (ISNc) C → S: ACK (ISNs) C → S: data And/or S → C: data Mechanism ISNs variable incremented by constant (once per second) and by half that amount each time a connection is initiated. ISNs a number precisely the round-trip between the client and server ISNs predictable, can be guessed by intruder No authentication except IP address Problem ISNs not true random number Easy to calculate or predict Can be used to spoof trusted host Easy and cheap for Intruder Defenses Don’t use netstat protocol Generate ISNs some other way Randomization Use cryptographic algorithm with key Randomize increments instead of basing them on predictable or measurable factor 1 Defenses (cont.) USE DES to generate ISNs Good Logging Alerting mechanisms Routing ISSUES Routing mechanisms can be abused Denial of Service – confusing routing tables Source Routing Reverse the TCP route on a request (if one is used). The attacker may be able to identify an IP address and network in the source domain, the first step gaining control of a host POSSIBLE DEFENSES Hard to defend Possibilities: Local net rejects all external packets claiming to be from the local net (not practical and extreme) Analyze source route and accept it only if trusted gateways are listed (again, hardly practical) RIP Attacks ISSUES RIP – Routing Information Protocol (widely used) Routing information received is often unchallenged Intruder can send bogus routing information and thus re-direct packets to a nontrusted entity, network, or host (impersonating) Hard to authenticate RIP packets Bogus routing information disseminates to other routers POSSIBLE DEFENSES Establishing a “paranoid” gateway One that filters packets based on source or destination address only, not on the route Would have to make RIP more skeptical of the routes that the router is willing to accept EGP ISSUES Protocol for communications between core routers Impersonation of a real gateway when such is down is not hard with this routing protocol Broadcast a route directing others to an offline router, while impersonating that router POSSIBLE DEFENSES Always make exterior gateways be on the core network so that attacker has a harder time impersonating the offline router ICMP ISSUES The Internet Control Message Protocol is used for echo requests from remote hosts (connectivity) POSSIBLE DEFENSES ICMP attacks are difficult because of ICMP packet’s simplicity Yet, ICMP packets can be used to: Redirect routes (such as with RIP) DoS attacks Again, “paranoia” Restrict routing changes to specified connections, not in response to ICMP Redirect messages Check that an ICMP packet is tied up to a particular connection only Authentication Server Used instead of address-based authentication Nothing more than a Trusted Host that will mediate our connections and establish trusted identities Should not rely solely on TCP/IP for authentication; should use some other algorithm Services Within the Suite Finger Email POP PCMAIL DNS FTP SNMP Remote Booting Finger Problem: Gives away too much information to hackers Solution: Disable service POP Problem: Conventional passwords are vulnerable Solution: One-time passwords using cryptographic key PCMAIL Problem: Same as POP, but also supports password-change command with unencrypted passwords Solution? DNS Problem: Sequence number attack leading to spying on traffic/capturing passwords Solution: Run domain servers on highly secure machines and use authentication on domain server responses DNS cont… Problem: Recursive zone transfer requests to download entire database Solution: Employ “refused” error code for any requests from unidentified servers Also, Kerberos tickets can be used to authenticate DNS queries FTP Problem: Use of simple passwords for authentication Solution: One-time passwords Problem: Anonymous FTP Solution: Be careful with sensitive data (such as encrypted passwords) SNMP Problem: In the wrong hands, can divulge too much information Solution: Protect this service (through authentication) Remote Booting Problem: Boot process can be subverted and new kernel with altered protection mechanism can be substituted Solution: Ensure boot machine uses random number for UDP source port and use 4-byte transaction ID Trivial Attacks ARP TFTP Reserved Ports Comprehensive Defenses Authentication Encryption Trusted Systems Authentication One of the overall problems is TCP/IP reliance on IP source address for authentication Too easy to spoof IP address Needs some form of cryptographic authentication Needham-Schroeder algorithm Needham-Schroeder algorithm Relies on each host sharing a key with an authentication server Versions exists for both private-key and public-key cryptosystems Host wanting to communicate request key from authentication server & passes a sealed version along to destination At conclusion of dialog, each side has verified id of other Needham-Schroeder algorithm Allows pre-authenticated connections that are safe DNS provides ideal base for authentication systems Key distribution responses must be authenticated and/or encrypted Encryption Can defend against most problems Disadvantages: Expensive Slow Hard to administer Uncommon in civilian sector Encryption Two types: Link Level including Multi-points link encryption End-to-end encryption Major benefits Implied authentication they provide Provide privacy Link Level Encryption Encrypting each packet as it leaves the host Excellent to protect confidentiality Works well against physical intrusion Weaknesses: Broadcast packets are difficult to secure Implies trust of gateways Blacker Front End (BFE) A multi-point link encryption device for TCP/IP Looks to host as an X.25 DDN interface Sits between host and actual DDN line Receives call with new destination, contacts Access Control Center for permission and Key Distribution Center for cryptographic keys BFE If local host is denied permission to talk to remote host, appropriate diagnostic code is returned Special Emergency Mode when link to KDS or ACC is not working Permission checking can protect against DNS attacks Totally unauthorized host does not receive sensitive data BFE Also translates original “Red” IP address to encrypted “Black” address using a translation table supplied by ACC Foils traffic analysis which are bane of all multi-point link encryption End-to-end encryption Above the TCP level To secure conversations regardless of number of hops Or quality of links Appropriate for centralized network management applications Key distribution/management greater problem (more pairs involved) End-to-end encryption Encryption and decryption done before initiation or after termination of TCP processing, host level software must handle translations resulting in extra overhead for each conversation Vulnerable to denial of service attacks Trusted Systems Hosted and routers rated B2 or higher immune to attacks described here C2 level systems are susceptible B1 are vulnerable to some but not all attacks Conclusions 1. Relying on IP source address for Authentication is dangerous 2. Second broad class of problems deals with sequence number attacks (unpredictable and unseen) 3. Hosts should not be giving away information gratuitously (finger and netstat) 4. Intelligent use of default routes 5. Use verifiable point-to-point routing protocols instead of broadcast-based routing 6. Network control mechanisms must be guarded