Hiding from DDOS for NAT provider

UPD The idea is not entirely obvious, detailed explanations in the comments.

Not so long ago, the last block of ipv4 addresses was printed. Providers are less likely to provide a free external ip address to regular customers, offering to connect it as a separate service. At the same time, users are tempted by the ability to remotely connect to their computer, the best work of torrents, the ability to host games and even raise their web server ... And the only advantage of gray ip is your security, i.e., inaccessibility from the outside without your desire.

The article describes how to take advantage of this opportunity, which, moreover, is provided completely free of charge, and reliably protect your server from attacks, while retaining its functionality.
')
What we can get in the ideal:
- Fully operational client-server application;
- Free DDOS protection capable of absorbing flood traffic, comparable in volume to the width of the provider's main channel;
- Software implementation, without the need for changes in the network infrastructure.



So, you are behind a NAT provider and you have a gray IP. Your computer does not receive external IP. In principle, this is enough to ensure that your server is protected from DDOS.

But you ask: what about respectable users will connect to my server? It is also unavailable from the outside ... Indeed, establishing a connection on the initiative of the client will fail. But here the fun begins.

We will consider a situation where you have not just a web server, but a server application that clients interact with, also written by you. In this case, you completely determine the logic of how the server and clients work. The basic idea is to let the server know that a client is going to connect to it. Then the server will establish a TCP connection to the address provided to it, and from that moment it will be possible to fully communicate with the client and the server. It will continue until the server disconnects. Thus, the network interaction is completely under the control of the server, which avoids any unwanted traffic, including the usual udp-flood.

But how does the server know that they want to connect to it?

It offers a wide scope for fantasy, based mostly on free solutions. The fact is that the Logon server (let's call it that way) is in essence a very simple application (in terms of the logic of operation). He just needs to get the IP address from the client to which he needs to connect and transfer it to the main server. The rest of the logic, including IP filtering, can be implemented already on it. Just for such simple tasks there is a huge free infrastructure.

Here is an example:
- Mail servers;
- Google Apps;
- FTP server;
- Free hosting (including static);
- Any service that provides an API and through which you can exchange information.

I repeat: we just need to transfer a small text fragment (containing an IP address and, possibly, other information) from the client to the server via the third service in a reasonable time (a few seconds). And do it only once, when the client connects.

So, what we have achieved.

We can accept connections from authorized clients and completely ignore intruder traffic. After all, the main problem was precisely that it was almost impossible to fight with UDP flood (except for channel expansion). And now at our disposal virtually the entire main channel of the provider, and until it is clogged, our service works great. The provider has no complaints to us: doser is not connected with us in any way, the packets go to the NAT provider’s address and are destroyed there.

What are the disadvantages of the proposed method?
- The method is suitable only for full-fledged client-server applications;
- The method is suitable for small projects;
- Be sure to be behind a NAT provider;
- Clients with a gray IP will not be able to connect.

In conclusion, I want to say that the idea described belongs to me personally. And I have a great desire to discuss it with habravchanami :) Ready to answer your questions ...