Fun sharing: using JavaScript against DDOS attacks

Fun sharing: using JavaScript against DDOS attacks

Continue to share interesting things.

Last time I talked about university attacks with a network cable. Today I will talk about it later.

But this is the opposite-not attack, but defense. A wonderful firewall development experience.

In the second semester, everyone had a computer, so they could use a higher-end method to disconnect the network. However, if the device is advanced, it does not feel like GEEK. So I decided to do something more meaningful.

One day, a few friends spoke, and their game servers were broken down. Then they began to discuss various protection solutions.

In the past, when I heard about the firewall software, I felt useless. As a result of huge traffic, bandwidth is blocked, and what is the use of software.

However, we still have high hopes for it. There are also many manufacturers doing this. It seems that the effect is always a little bit.

The discussion is inevitable. Otherwise, make a firewall and make a different idea!

Of course, this is not the first attempt.

When I was a beginner, I wanted to build a large program every time I saw a small demo. For example, when I saw DirectX, I had the urge to play games, but I couldn't do it in a few days.

For a while, I was interested in the driver and figured out the demo in Windows DDK. When I saw this thing about NDIS middleware, I suddenly got started. Isn't this the underlying package filter used for firewall? The performance is naturally excellent.

As a result, the simplest IP address filtering firewall was transformed according to the samples. In order to highlight the high performance, I read the data structure and wrote a hash table for faster query.

However, it's just a toy.

In reality, firewalls cannot be such a simple logic. More advanced protocol analysis, complex policy judgment, and massive data accumulation are required... Of course, there are still countless blue screen debugging times.

With this in mind, I will not continue.

However, this time, I decided not to tangle the technical layer, but to be an "alternative"-using the simplest technology, coupled with clever ideas, and some unique technical skills to achieve unexpected results.

Considering that traditional developers are already familiar with systems and networks, they have no advantage in competing with them.

At that time, I was filled with a skill unrelated to security-webpage script effects and a bunch of "front-end black magic ".

But... This .. And network defense... What is the relationship?

No half link ~~ Think too much. Think about it.

The first thing that comes to mind is to transform the server.

After all, this is "Open-source" and will certainly be able to enhance the fragile network system by modifying programs.

However, when you see the dense code, a language you have never used, and a completely unfamiliar debugger, you are not interested.

If you are not interested, you have no idea and give up.

In this case, try it from the client.

This time, with the feeling of exploration, open the program and try again.

Just as there was no clue, there was a sudden sound of cordial speech-how can we let go of sensitive nerves? Isn't this the exclusive voice of ie.

This makes me realize that embedded in the browser is not just a big web page!

If you have a webpage, you cannot run the script!

I never imagined that I had the idea of this embedded box ~~ But I finally pulled the script together.

The more you want, the more excited you are. The existing firewalls are almost all purely server-side data analysis, which can involve clients. It should be rare.

"As long as a script is introduced in the browser's webpage, you can ..."

You can accept it.

With the script, you can make full use of it.

We must allow users to run scripts to connect to the game server. IP addresses that have not run scripts will be blocked.

So I started to design and organize:

When the script is running, send a request to the "Authorization server"

After the "authorized server" parameter is verified, the user IP address is notified to the firewall on the "game server" and added to the White List.

"Game server" only allows IP addresses in the whitelist to pass ("authorized server" is on the whitelist by default)

This does not affect normal users, but the attacker does not execute scripts and cannot enter the whitelist-no matter what packets are sent, they will be intercepted.

In this way, the firewall policy becomes extremely simple: only judge whether the IP address of the data packet is in the whitelist.

So the previous simple demo driver was turned over again. Because of its single function, stability and high performance are ensured.

At this point, a prototype of the network firewall involving JavaScript was born!

Maybe you will say that this is just a transfer of risk. Transfer the risks of the game server to the website. If the website is broken down, it cannot enter the game.

Indeed. However, compared with common network programs, the Web has more mature defense solutions, and even can be mitigated by using ready-made CDN.

Therefore, the general C/S network defense is linked to a more stable B/S, and there is no need to recreate the wheel, saving a lot of costs.

Of course, this is just a basic prototype. There are still many things to consider in practical application.

For example, the whitelist cannot be added infinitely and has to have an expiration time. The client script cannot only run once and must be periodically activated.

....

However, the development is smooth because there is no need to consider compatibility issues. The servers are all Win2003, and the Web pages run in the WebBrowser control are all ie67 kernels.

A few days later. Then we made a simple interface program, packed the solution, and started to try it out.

After going online, the effect is very good! Any traffic unrelated to players is intercepted. Easily resist various CC attacks!

However, attackers will never stop.

Besides, everything on the front end is open, and this secret will be discovered early or late.

Vs v1

After several months of calm, a huge wave of botnets came again.

Logs show that a large number of IP addresses are added to the whitelist in a short period of time, which is not a normal user.

Apparently, someone has discovered this secret!

In fact, the first version is very simple and even confusing.

They transplanted the script logic to the attacker. In this way, you can become a legal user if you do not access the webpage.

As for how they discovered it, there is no way to know. However, the mood after brain makeup detection must be like this: the slot, originally here, is actually so cool ~~~~

 

Of course, this is expected.

The new version is already ready, and the "Black Front-end magic" is also eager to try and decide to fight back.

This time, the script is encrypted.

No, it is not the encryption that is circulated on the Internet, but a special structure. Although it looks similar: the entire program is embedded in an eval.

Anyone who knows about JS knows how to replace eval with console. log and so on, and the code will be ready. I believe 99% of people will do this.

Therefore, we use this mentality to bury a trap in the Code: If only decryption is performed without eval, unexpected consequences will occur.

eval(    (function() {        ...        T = setTimeout(die, 1)        ...        code += 'clearTimeout(T)'        ...        return code    })())

During the decryption process, a timer is secretly enabled: 1 millisecond later, and enters the suicide mode-apply for an endless loop memory!

Under normal circumstances, this will not be triggered-because the timer will be removed in the subsequent eval code; but if the eval is changed to another one, it will not be able to be lifted-the bomb is triggered!

At that time, the mainstream memory was 1 ~ 2G, this will be swallowed up instantly, stuck to the hard disk.

To satisfy curiosity, I want to see how many people are planted. Therefore, the log reporting function is added before the endless loop.

During that time, I was thinking about an SMS interface. Therefore, this log becomes the test content.

Whenever someone tries to crack the script, the phone immediately receives a message and experiences the feeling of "under control :)

Of course, is that the end?

No, it's still early.