MIT course "Computer Systems Security". Lecture 12: "Network Security", part 1

Massachusetts Institute of Technology. Lecture course # 6.858. "Security of computer systems". Nikolai Zeldovich, James Mykens. year 2014

Computer Systems Security is a course on the development and implementation of secure computer systems. Lectures cover threat models, attacks that compromise security, and security methods based on the latest scientific work. Topics include operating system (OS) security, capabilities, information flow control, language security, network protocols, hardware protection and security in web applications.

Lecture 1: "Introduction: threat models" Part 1 / Part 2 / Part 3
Lecture 2: "Control of hacker attacks" Part 1 / Part 2 / Part 3
Lecture 3: "Buffer overflow: exploits and protection" Part 1 / Part 2 / Part 3
Lecture 4: "Separation of privileges" Part 1 / Part 2 / Part 3
Lecture 5: "Where Security Errors Come From" Part 1 / Part 2
Lecture 6: "Opportunities" Part 1 / Part 2 / Part 3
Lecture 7: "Sandbox Native Client" Part 1 / Part 2 / Part 3
Lecture 8: "Model of network security" Part 1 / Part 2 / Part 3
Lecture 9: "Web Application Security" Part 1 / Part 2 / Part 3
Lecture 10: "Symbolic execution" Part 1 / Part 2 / Part 3
Lecture 11: "Ur / Web programming language" Part 1 / Part 2 / Part 3
Lecture 12: "Network Security" Part 1 / Part 2 / Part 3

Today we will talk about network security, in particular, we will discuss Stephen Bellovin’s article titled “Looking into the past:“ A Look Back at Security Issues in the TCP / IP Protocol Suite ”). This guy used to work at AT & T, and now he works in Colombia. In this work, it is interesting that it is relatively old - it is more than 10 years old, and in fact, these are comments on an article that came out a decade earlier in 1989.
')
Many of you guys ask why we study this if many of the problems described there have been resolved in today's versions of the TCP protocol?



This is true, some of the problems described by Stephen have since been resolved, and some of them still remain problems. Given this, we will sort them out and see what happens. You may wonder why people did not solve all these problems in the first place when designing TCP? What were they just thinking about?

And this is really not clear. What do you think? Why didn’t TCP have the necessary security considering all these considerations? Any thoughts?

Student: at the time, the Internet was a much more trusting place.

Professor: yes, it was literally a quote from this guy's article. Yes, at that time in general ... a set of Internet protocols was developed, I think, about 40 years ago. The requirements were completely different. It was necessary to simply connect to the common network a bunch of relatively trusting sites that knew each other by name.

I think this often happens in any system that becomes successful - it needs changes. Previously, it was a protocol for a small number of sites, now this protocol covers the whole world. And you no longer know by name of all people connected to the Internet. You cannot call them on the phone if they do something bad, and so on.

Therefore, I think this story is the same for many protocols that we are considering. And many of you guys are wondering, like: “what the hell were these guys thinking? This is so flawed "! But in reality, they designed a completely different system, it was simply adapted for modern needs.

The same and the Internet, as we have seen over the last couple of weeks, was designed for a very different purpose. But it has expanded, and we have new concerns about how to adapt this protocol to modern requirements.

There is one more thing that happened somewhat suddenly, that people had to overestimate the severity of the security problem. It used to be that you really didn’t understand all the things you should worry about, because you didn’t know what the attacker could do with your system.



I think partly for this reason it will be interesting to see what happened to TCP security, what went wrong, how we can fix it, and so on. As a result, we need to figure out which kinds of problems need to be avoided when developing our own protocols, as well as what constitutes the right thinking about attacks of this kind. How do you know what an attacker is capable of doing in your own protocol, when you are only developing it, in order to then avoid such pitfalls?

Okay, let's leave the preamble aside and talk about this article.

So how should we think about network security? I think we could start with the first principle and try to figure out what our threat model is. So, what can an attacker do in our network?

He probably has the ability to intercept packets, and perhaps he is able to modify them. Thus, if you send a packet over the network, it is reasonable to assume that some bad guy will see your package and be able to change it before it reaches its destination. He may also be able to drop it and use the ability to inject custom packets with arbitrary content that you have never sent.



But the possibility of bad guys interfering with your protocols is more dangerous. The attacker has his own computer, which he fully controls. Even if all the computers you trust are behaving properly, a bad guy who has a computer can interfere with your protocol or system operation.

So if you have a routing protocol that involves a lot of people talking to each other, and some scaling would probably be impractical to keep the bad guys outside. If a routing protocol is being executed with 10 participants, then maybe you can just call all of them and then say, "well, yes, guys, I know all of you."

But on the scale of the Internet today it is impossible to directly find out who the other members of the network are using this protocol. So, probably, some bad guy is going to participate in your protocols or distributed systems. Therefore, it is important to design distributed systems, which, however, can do something reasonable with this.

Well, so what are the consequences of all this? I think we will go through the list. Capturing packets is generally easy to understand, you cannot send any important data over the network if you expect the bad guy to intercept them, or at least not send them in clear text. Perhaps you should encrypt your data.



This seems relatively easy to understand, although you still need to keep this in mind when developing protocols. Deploying or injecting packages leads to a wider range of interesting problems that are discussed in this article. In particular, attackers can enter packets that can impersonate packets from any other sender. Since the data transfer path is based on IP, the packet itself has a header that indicates the source IP of the packet and the destination IP. In this case, no one checks that the source is necessarily correct. Nowadays there is some filtering, but it is not perfect and it is difficult to rely on it.

So, as a first approximation, an attacker can insert inside any IP address as a source and send it to the correct destination. It is interesting to find out what an attacker can do with the ability to send arbitrary packets.

In the weeks before, we looked at buffer overflow issues from a web security perspective. We looked at how an attacker could use an implementation error such as a buffer overflow. Interestingly, the author of this article is not really interested in implementation errors, he is more interested in protocol errors.

So what's so special about it? Why did he not pay attention to implementation errors, although we spent several weeks on their consideration? Why does it matter?

Student: because we have to eliminate these errors when writing a protocol.

Professor: yes, this is a really big failure due to an error in the design of the protocol, because it is difficult to change. So if you have an implementation error and you have a memcpy or print-out that did not check the memory range, it’s impossible to notice this error. But if you have a range check and it still works, then a buffer overflow can be avoided, so this is great.

But if you have some kind of error in the protocol specification, how the protocol should work, then correcting such an error will require correcting the entire protocol, which means a potential impact on all systems that speak this protocol. So if we find some problem in the TCP protocol, potentially it will be rather destructive. Because every machine that uses TCP will have to make changes, because it is potentially very difficult to make the modified protocol compatible with the old machine.

The errors of the TCP protocol that have so bothered Stephen are fundamental, so he decided to talk about them. In the first example, it examines how the TCP SN sequence numbers work.

Student: it's a bit off topic, but I'm just curious. Suppose you find an error in TCP. How do you make changes to it? How do you tell all the computers in the world to change this?

Professor : yes, I think this is a huge problem. What if you find a bug in TCP? Well, it is not clear what to do. I think the author is struggling with this here. If you could do a TCP redesign, then many of these errors are relatively easy to fix if you know in advance what to look for.

But since TCP is rather difficult to correct or change, eventually the following happens: developers try to find backward compatible settings that either allow old implementations to be used in conjunction with the new implementation, or add some additional field that makes the connection somewhat more secure.



But this is a big problem. If this is some kind of security problem that is deeply rooted in TCP, then it will become a huge problem for everyone, because it is very difficult to even simply upgrade to the TCP version, suppose n plus 1.

IPv6 can be seen as an example of the fact that this does not happen, and we know that this problem will arise for another 15 years or 20 years. IPv6 has been around for more than 10 years, but it's hard to convince people to move away from IPv4. IPv4 is enough for them, it seems to work, and they think that switching to a new Internet protocol will be too expensive. They think: “no one else speaks IPv6, so why should I start talking on this strange protocol that I have no one to talk to?”. In any case, this is a kind of forward movement, but I think it will take a lot of time. There really will be some motivation for migration, and backward compatibility helps a lot in this case.

IPv6 has many backward compatibility features; for example, you can talk to an IPv4 host using IPv6. Therefore, developers are trying to design all this support, but it is still difficult to convince people to upgrade.

So, considering the TCP sequence numbers, we are actually going to look at two issues that are related to how the TCP handshake works. So let's spend some time looking at how a TCP connection is initially established.

Three packets are sent to establish a new TCP connection. Our client generates a packet to connect to the server, which says that here is my client IP address, I send it to the server. At the same time there is a packet header structure consisting of different areas, but we will be interested in the sequence number area. Here we will have a SYN flag saying, “I want to synchronize the state and establish a new connection,” and it includes the serial number of the SNc client.



Then, when the server receives this packet, it says: “the client wants to connect with me, so I will send the packet back to this address, no matter who says that he is trying to contact me.” Thus, the server will send a packet to the client, which includes its own SNs server synchronization sequence number and ACK client acknowledgment number (SNc). Finally, with the third packet, the client responds to the server, confirming the synchronization and sending the server an ACK confirmation number (SNs) to the server. Now the client can start sending data.

Thus, in order to send data, at the beginning of the connection, the client must include some data in the packet and attach the sequence number of the client SNc to indicate that this is actually legal customer data. It indicates, for example, that this is not some data from later messages that just come in now, because the server has missed some initial pieces of data.



Thus, as a rule, all these sequence numbers are intended to ensure the delivery of packages. If the client sends two packets, the one that has the initial sequence number is the first data fragment, the next sequence number is the next data fragment. It is also useful for providing some security requirements.

Before that, I gave an example that these requirements are changing. Therefore, initially no one thought that TCP should provide any security features. But then TCP started using applications, and they seemed to rely on these TCP connections, believing that they could not be broken by an attacker or that the attacker could not enter malicious data into an existing TCP connection. As if all of a sudden, this mechanism, which was originally intended only for ordering packages, began to guarantee some kind of security for these compounds.

Therefore, in this case, I assume that the problem is related to what the server could have assumed regarding this TCP connection. As a rule, the server assumes - implicitly, as you can imagine - that this connection is established with the correct client at this IP address C, and it is natural for him to assume that. But is there any reason for such an assumption? If the server receives a message with some data about this client-server connection, and it has the sequence number C, why does the server conclude that this data was sent by the real client?

Student: because the sequence number is difficult to guess.
Professor: correct, so this is a kind of implicit thing, implying that there must be a valid SNc sequence number here. And in order for this connection to be established, the client must have a confirmed SNs server sequence number, and the server's sequence number is sent by the server only to the client's IP address.

Student: How many bits are available for the sequence number?

Professor: TCP has a sequence number of 32 bits, and although it is not a completely random number, it is not easy to guess, it would take a lot of bandwidth.

Student: Is the sequence number higher than the initial sequence number?

Professor: yes, in principle, these things are increasing. Therefore, each time you send a SYN, this is considered to be 1 byte more than your sequence number. That is, if in the first line we had an argument (SNc), then in the fourth one it would be (SNc + 1), and then the numbering continues from here. Thus, if you send 5 bytes, then the next one will be (SNc) +6. It simply counts the bytes that you send, with each SYN counting as 1 byte. In the TCP specification, it is recommended to select these sequence numbers so that their increment occurs at some roughly fixed rate. The initial RFC working papers suggested that you increase these things by about 250,000 units plus 250,000 per second.



The reason that this was not completely random is that these sequence numbers are actually used to prevent the intervention of failed packets or to mix packets from previous connections with new connections. Every time you establish a new connection, you choose a completely random sequence number. At the same time, there is some chance that if you install a series of connections over and over, a certain packet from the previous connection will have a sequence number rather similar to the sequence number of your new connection and therefore will be accepted by the server as a valid part of the new connection data.

So this is what TCP developers were very worried about — these unordered packets or delayed packets. As a result, they really wanted these sequence numbers to be a fairly monotonous sequence in time, even between connections.

If I open one connection, it can have the same source and destination, port numbers, IP addresses, and so on. But since I established this connection now, and not earlier, packets from previously sent messages, I hope, will not match the sequence numbers that I have for my new connection. So this was a mechanism to prevent confusion between recurring connections.

Student: if you don’t know exactly what the step of the sequence of packages will be, how do you know that the package you receive is the next package, and not the part of the previous one that you ...

Professor: As a rule, you remember the last packet received. And the next sequence number is exactly the next packet in the sequence. So, for example, the server knows that I saw exactly the data portion of date (SNc +1), then the next one will be the SYN packet (SNc +1), because the previous packet at the beginning of the connection was SYN (SNc).

Student: so, you say that when you set a sequence number, even after that you ...

Professor: well, of course, these sequence numbers, initially, when you install them, are selected according to some plan. We will talk about this plan. You may think that they are random, but over time they should be some kind of consistent flow of changes in the initial sequence numbers for the connection.

But within one connection, everything ends as soon as it is established - the sequence numbers are fixed. And they just mark this connection as data is sent over it.

There were plans that offered to manage these sequence numbers. , . , , , .

, - , 250000. , , , 64k 128k, . , – , SYN .

, 64 . , .

, . , , , , IP-.
, , , , , . , , .

, ? , , , — SNc. , , - , , , .

, . ACK (SNs).

- .



SNs , , , IP- C.

, . , : , , , data (SNc +1).



(SNs). ?

: , ?

: . , , , , . , , , , .

: , , ?

: . , ?

, . , , 32 , , .

, .

: , , , . …

: , TCP .

: , .

: , .

: , , .

: , , , . , , 1000 , 2 32 .

, - , , . . , .



: - , ?

: , . , , IP-, ?

: ?

: — ? , . ?

: , , , , - .

: , , , , , . IP-, TCP , , , .

TCP , - , , , C RST (SN…), , .



- , , C , .

, C , . , S , : «, , , ».

, , , , , C .

, «» C , . , «» C , . , TCP.

: , . , SYN , .

: , , . , , , , NAT, . , NAT RST , . , , , , , Comcast , RST .

: ?

: , , TCP. , . , , , . /, .

, data (SNc +1). , IP- , : « », , S.



SYN (SNs) (SNs) , . — , IP-, . , SNS SNS .

25:50

MIT course "Computer Systems Security". 12: « », 2


Full version of the course is available here .

Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps until December for free if you pay for a period of six months, you can order here .

Dell R730xd 2 times cheaper? Only we have 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV from $ 249 in the Netherlands and the USA! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?