Now let's discuss those SYN flood challenges that we briefly discussed already. How can we challenge clients or more specifically the attacker in order to protect your environment, while not blocking the legitimate users. In this lecture, we will start from where we left off last time. Now we're response challenge methods will consist of using two different things. The first one is sync cookie. And the second one is using proxies and firewalls, more specifically proxies.

Now, I think the second item is obvious. Using proxies by proxy, I mean using a proxy between the client and the server you want to protect, basically, sync cookie. Now what I mean by that, what I mean by sync cookie is basically choosing specific TCP sequence numbers in order to find out whether actually, the client is following this three way handshake structure. Or not. In other words, suppose we have a client here, and we have the server here. When the client sends the Send request, while we are answering it with a SYN ack, it is not going to be a standard SYN ack, we choose a specially crafted SYN ack, which has a temporary TCP sequence number, so that we expect a client to send an ACK with an appropriate sequence number in accordance with our SYN ack.

Again, if the client fails to send an ACK request here, which is not suitable to our SYN ack that we sent. In other words, if the sequence numbers are not matching up, then it is almost certain that this is not a client, it's actually an attacker. In all these challenges that I have defined here, we will be using both of these things, meaning both SYN cookie and proxy between our protected server and the quote. Now there are three different methodologies for challenging against sin. plots. The first one is proxy fight.

The second one is the reset aspect. And the third one is reset sent. So let's start with the first one. In the proxy fight structure, we first use the proxy before actually letting the traffic pass through our protected server. In other words, as you can see here, our proxy on behalf of the server replies with a special syntax requests the cookie here, this cookie is nothing but again, a temporary TCP sequence number. So when a real user receives this temporary SYN ack request, it should also respond with an appropriate sequence number.

And only after that, we actually forward this request from real user to our server. In other words, this SYN request, only after this authentication is transmitted to the server and then our server answers with SYN ack and only then the act is also transmitted. This is the first methodology. Now let's discuss the pros and cons of this methodology. Well, the pros, as you can see, it involves using a proxy on that nothing else. And additionally protects against empty connection floats, which we will also discuss later on in this course.

And actually, we haven't gotten to the upper TCP IP layers yet. But as a heads up, it also applies to HTTP, HTTPS, and rtsp. Here, I can tell you that the most important thing is it protects against both HTTP and HTTPS. Cons. It requires a fully symmetric environment in your network. If you don't know what the symmetric environment means in the network.

I recommend you to go back and refresh your knowledge on that. And the second one, which is kind of obvious later on Adding and sequence acknowledge number modification can impact performance. As you might remember, proxy first authenticates all the requests before reaching to the server. Let me show you here, first of the proxy, and then we forward everything to the server. So this kind of two step connection establishment can impact the performance of the server and therefore the clients. The second method is reset expect here we intentionally sand the bad synack to the SYN request of the client.

In other words, in reset expect, we are actually not using exactly the same cookies, but we are sending an out of band SYN ack sequence number. And according to TCP rules, when a client receives such a bad SYN ack request, it must replace it with a reset once we received the reset after a certain amount of time If we receive a SYN request again, then we verify that this is actually a real client. In other words, if you don't receive a reset, instead, if you keep receiving sins all the time from the client to your proxy, according to TCP rules again, it means that this is a legitimate traffic. Therefore, it's most likely an attacker only after this authentication, the proxy lets the traffic pass through to the server. The only difference in this methodology is in reset expect, as opposed to the proxy fight approach.

Once we authenticate the client, we don't care about the rest of the traffic. In other words, all the rest of the traffic will directly reach to the server. There won't be a middleman sitting here as opposed to proxy fight because in proxy fight all the traffic was forwarded by proxy even after Client authentication. Now let's discuss pros and cons. The first Pro is it works in that symmetric Ingress only. If you don't know what it means, please go back and check your networking knowledge on that.

And the second one is not late binding in this approach. Since once the authentication of the client is complete, the proxy doesn't play any role anymore in the traffic from that moment on. In other words, once it's authenticated, the client can directly communicate with the server as we discussed, cons, it doesn't work in a symmetric mesh deployments. Some firewalls may look to reset packets to be expected. Because basically, it's an unusual situation in three way handshake. So some firewalls on the client site may block it, and therefore the client might have to need to tune this firewall accordingly.

Just to be able to connect to your server. And with a proxy, once one legitimate user authenticates itself. In cases behind the net, anyone behind the same net will be authenticated. And this actually can be a big issue, because let us check it again. Suppose that this user is authenticated. And proxy doesn't play any role anymore, as we discussed.

In other words, from that moment on, the traffic between the client and the server will be direct. So what if this is actually an attacker? What if at the beginning, it pretends to be a normal client and authenticates himself? Or what if one single legitimate user behind the net or proxy authenticates the client IP, but there are actually attackers behind the same IP, then actually, this methodology becomes useful. In fact, let me demonstrate the issue with a graph. As you can see here, when the see request comes in, the server replies with an ACK request with an invalid sequence number.

And then the server waits for a reset packet. And if the server receives that reset, the server waits for some time, which you should define, depending on your network and performance expectation. So if within this period of time the server receives a SYN transmit, then we know that this SYN sender is authenticated. And the IP is to be added to the content table that you will have to create in this methodology to check the legitimate sin Sanders in order to lock the traffic pass through in the future. And after that, this is proxied. By the way, after that authentication, all upcoming sins will be directly forwarded.

To the protected server, and all traffic from that point on is going to be direct. And that will leave the server unprotected against the SYN floods, which might come from the same IP client. The final methodology that we are going to discuss is the reset sent. Let me this time start directly with the graph. This is again, the proxy in this methodology. Instead of expecting a reset, that we actually send the reset to the client.

In other words, we in this methodology use again cookies, we reply with cookies. And then we again expect an acknowledged packet with an appropriate cookie. And at that point, we again authenticate the client. However, this time, we treat this as the only first step of our authentication. So after this three way handshake, successful three way handshake, we suddenly send the reset packets. So the difference between a reset sent and reset expect is in recent sense, we use SYN cookies, and we complete the three way handshake.

But there's a second stage, we reset the connection. And then, within a predefined period of time, we expect the client to send the new SYN request, again with the cookie that we defined in the previous methodology in the reset expect, we were actually expecting the client to send a reset. Now let's discuss its pros and cons as well. The first Pro is it works again in a symmetric Ingress only. And there's also no delayed binding because as you could see, after the authentication, and after waiting for some specific time, a proxy basically allows the traffic to pass through directly to the server. And the columns here, the support is only for HTTP, HTTPS, and smtp.

In other words, other application layer protocols does not work with this methodology. It doesn't work in a symmetric mesh actually depends on the application to respond to the reset. And this is actually something that can vary depending on the application. Since there is no common guideline, common rules for that. And again, in relation to that, depending on the application, the client will need to refresh page or take similar action in order to pass this authentication and the same code as before, as reset expect a place here with a proxy. And by the way, this proxy is the proxy on the client side.

In other words, we are talking about kind of a NAT here, the proxies to which multiple clients Connect So again, once this connection is authenticated, all the clients using the same client proxy will be authenticated as well. So just because one client is authenticated, we cannot make sure that, you know, all the people who use this proxy or the nut, if this is a company are legitimate users actually saw again, just like in the previous methodology reset expect with a proxy. One legitimate user request can authenticate the attackers. Finally, let me just show you the comparison of these methodologies. As you can see, Prague certified works in a symmetric environment. In a symmetric Ingress only doesn't work in a symmetric mesh.

And there is late binding because in proxy fight, as the name suggests, is Brock's fights. So all the traffic is sort of checked by the proxy all the time. Reset expect and resets and when it comes to environment and delay, they are pretty much the same actually. So when you are going to decide on what methodology you use, you need to consider all these parameters.