外文翻译--回顾“tcpip协议套件安全问题”(编辑修改稿)

外文翻译--回顾“tcpip协议套件安全问题”(编辑修改稿)内容摘要：

to grab password files from various Research machines。 a number of us had installed detectors for exactly that sort of activity, and noticed the unusual behavior. At that, we were lucky—most of the connectivity within ATamp。 T was via the proprietary Datakit work, which he didn’t know how to exploit. By the time of the Inter worm of 1988, this paper was already in substantially its current form. The result was an analysis (to the best of my ability。 I was relatively new to security at the time) of protocollevel problems in TCP/IP. The original paper was criticized in [54]. Some of the criticisms were valid。 some, in my opinion, were not. At the time, I chose not to publish a detailed rebuttal。 I will not do so here. I have, where appropriate, noted where my analysis was especially incorrect. I did and do feel that my conclusions were substantially correct. The TCP/IP protocol suite [41, 21] which is very widely used today, was developed under the sponsorship of the Department of Defense. Despite that, there are a number of serious security flaws inherent in the protocols. Some of these flaws exist because hosts rely on IP source address for authentication。 the Berkeley “rutilities” [22] are a notable example. Others exist because work control mechanisms, and in particular routing protocols, have minimal or nonexistent authentication. When describing such attacks, our basic assumption is that the attacker has more or less plete control over some machine connected to the Inter. This may be due to flaws in that machine’s own protection mechanisms, or it may be because that machine is a microputer, and inherently unprotected. Indeed, the attacker may even be a rogue system administrator. . Exclusions We are not concerned with flaws in particular implementations of the protocols, such as those used by the Inter “worm” [95, 90, 38] Rather, we discuss generic problems with the protocols themselves. As will be seen, careful implementation techniques can alleviate or prevent some of these problems. Some of the protocols we discuss are derived from Berkeley’s version of the UNIX system。 others are generic Inter protocols. We are also not concerned with classic work attacks, such as physical eavesdropping, or altered or injected messages. We discuss such problems only in so far as they are facilitated or possible because of protocol problems. For the most part, there is no discussion here of vendorspecific protocols. We do discuss some problems with Berkeley’s protocols, since these have bee de facto standards for many vendors, and not just for UNIX systems. One of the criticisms in [54]) was that I had lumped Berkeleyspecific protocols together with standardized protocols described in RFCs. It’s quite clear from the preceeding paragraph that I understood the difference. However, the use of addressbased authentication—a major flaw that I criticize throughout the paper—was peculiar to Berkeley’s software。 I did not make that distinction clear. It is indeed a bad way to do authentication, but it was not blessed by any official standard. 2. TCP Sequence Number Prediction One of the more fascinating security holes was first described byMorris [70]. Briefly, he used TCP sequence number prediction to construct a TCP packet sequence without ever receiving any responses from the server. This allowed him to spoof a trusted host on a local work. The normal TCP connection establishment sequence involves a 3way handshake. The client selects and transmits an initial sequence number ISNC, the server acknowledges it and sends its own sequence number ISNS, and the client acknowledges that. Following those three messages, data transmission may take place. The exchange may be shown schematically as follows: C ! S : SYN(ISNC) S ! C : SYN(ISNS), ACK(ISNC) C ! S : ACK(ISNS) C ! S : data and/or S ! C : data That is, for a conversation to take place, C must first hear ISNS, a more or less random number. Suppose, though, that there was a way for an intruder X to predict ISNS. In that case, it could send the following sequence to impersonate trusted host T: X ! S : SYN(ISNX), SRC = T S ! T : SYN(ISNS), ACK(ISNX) X ! S : ACK(ISNS), SRC = T X ! S : ACK(ISNS), SRC = T, nasty − data Even though the message S ! T does not go to X, X was able to know its contents, and hence could send data. If X were to perform this attack on a connection that allows mand execution (., the Berkeley rsh server), malicious mands could be executed. How, then, to predict the random ISN? In Berkeley systems, the initial sequence number variable is incremented by a constant amount once per second, and by half that amount each time a connection is initiated. Thus, if one initiates a legitimate connection and observes the ISNS used, one can calculate, with a high degree of confidence, ISN′ S used on the next connection attempt. Morris points out that the reply message S ! T : SYN(ISNS), ACK(ISNX) does not in fact vanish down a black hole。 rather, the real host T will receive it and attempt to reset the connection. This is not a serious obstacle. Morris found that by impersonating a server port on T, and by flooding that port with apparent connection requests, he could generate queue overflows that would make it likely that the S ! T message would be lost. Alternatively, one could wait until T was down for routine maintenance or a reboot. I mischaracterized Morris’ paper on this point. While flooding can work—without explicitly stating it, I anticipated the denial of service attacks that started occurring in 1996—Morris in fact exploited an implementation error in the Berkeley kernel to acplish his goal with many fewer packets. That flaw (d。