Shulou(Shulou.com)06/01 Report--

1) Everything is based on accurate monitoring (Prometheus)

Before talking about safety protection and ***, all preconditions are subject to accurate monitoring, and the acquisition accuracy is 1s.

Whether it is the monitoring and early warning of the enterprise, or the stress test simulation for the rainy day, there must be a detailed reference.

Here to recommend a powerful open source monitoring tool, Prometheus Prometheus

It is an open-source, mathematical command-line and time-series database based precision monitoring tool

The theoretical value of its acquisition accuracy can reach one acquisition per second. Combined with the expression form of floating point number, it is very suitable for analysis/monitoring/and alarm of instantaneous sudden conditions.

Next, let's briefly demonstrate how prometheus actually operates (currently built on a production teaching platform).

Actual operation:

No pressure + rapid fluctuation of pressure test curve

Prometheus is so powerful, but it is not popular in China for three main reasons.

The first one requires a certain mathematical foundation, and the mathematical command line is difficult to use.

The second requirement is to have a certain understanding of the underlying working principles of Linux systems, otherwise you cannot accurately add monitoring

The third question in English (there is very little information in Chinese, and almost no complete Chinese tutorial) most of the details should be taken from the official website

Understanding of CPU time slice distribution, accumulation of time slice occupancy

Understanding of COUNTER Type Data

Differential + dichotomy yields the rate per unit time, which is proportional to CPU usage (understand the mathematical function provided by prometheus)

2) Talk about server resources from the perspective of operation and maintenance

What is the essence of ***? In fact, in the final analysis, it is a strong blow to the existing resources of the server or consumption

So from the perspective of our operation and maintenance architecture, what are the classifications of server resources in the enterprise?

Category 1: Resources at the server physical level

This is the best understanding, nothing more than CPU /memory/hard disk/, these are limited resources as a computer physical level

Category 2: OS-level resources

We're going to benchmark it against Linux, the core OS of operations.

So the operating system resources are simply a few examples, number of ports, number of connections, number of TCP queues, number of file handles, process scheduling/priority, etc.

Category 3: Network Resources

This mainly refers to network bandwidth, which is a very precious resource, and will be explained in detail later.

The three types of resources mentioned above are all limited resources as a cluster architecture *** The essence is actually the consumption of resources

The exhaustion of resources will eventually cause the server to be unable to respond to user requests, which is what we often call Dos denial of service ***

In addition, the three categories of resources mentioned above are not independent of each other, but actually have a lot of relationships between them.

Now is the era of Internet applications, everything goes through the network, so the consumption of network resources is naturally self-evident.

Even if we temporarily ignore the IP packet routing process, even if it directly reaches our service cluster

There are also a number of series of consumption associated with other resources occurring in our cluster

As shown in Figure (01), for example, after an HTTP request arrives, it will be connected in series from the physical layer to the application layer according to the framework of the standard seven-layer protocol.

The NIC will reassemble IP packets, TCP/UDP will establish connections at the transport layer, and the establishment of connections must continue to consume CPU/RAM/IO , ports, connections, queues, file handles, and so on.

Any bottleneck in one resource will hold back other resources.

3) Talk about the changes in the defensive side and the defensive side over time

From the square, gradually from the difficult level of 4, gradually changed to a fool of 7

For example: the system vulnerability based on layer 4 to be discussed later (mainly refers to TCP/IP layer 3 and layer 4 protocols)

This kind of requester should not only be proficient in TCP/IP protocol, but also master the underlying knowledge of the system and the foundation of the code.

From Dos with very small traffic requirements to Ddos (Distributed Dental of Service) with large concurrency

Originally, when the operating system (mainly Linux) kernel is low, when the server performance is low, a small amount can cause system paralysis.

As OS and server upgrades, traffic demands are increasing.

From the early physical layer system layer, it caused the consumption of the first and second types of resources, and gradually exceeded the consumption of network bandwidth.

In addition, there is the issue of expenses. In fact, the expenses of both attacking and defending sides have been increasing all the time.

4) Talk about the old-fashioned four-layer *** and simple simulation experiments (known as Death Ping and SYN Flood)

OSI seven-layer model (02)

The classic OSI seven-layer model, which I refer to in my teaching as the seven-layer model of the U-shaped structure

Because the flow of data goes from right to left, top to bottom, bottom to top, packaging to unpacking.

We will introduce several types later, mainly concentrated in the third layer, the fourth layer (unified called the fourth layer), the seventh layer (5 6 7 can be merged into a layer unified as the application layer ***)

Distributed Dos

PING*** Rationale

Can a ping command be initiated? It feels a little incredible, but in fact, this is not unusual in the early days (the early Sino-US war mainly used this method)

We usually use ping just to check whether the network is connected or not. In fact, after PING reaches the bottom layer, there are many details that we just don't see.

According to the IP protocol, IP packets will be packetized when they are sent out, and the routers passing through will also packetize, but the packet reassembly needs to be completed by the receiving end.

IP protocol packet header has a limit on IP packet size (65535 TL field, packet header + data entity), packet reassembly needs to be completed with the help of Linux kernel

Early kernels assumed that IP packet size would not exceed the TL maximum limit, and when a *** sent an IP packet that exceeded the TL maximum limit, the system allocated a fixed amount of memory for packet reassembly during fragmentation.

And only after all packets are reassembled can their entire size be identified, so each packet looks normal midway through the reassembly process (fragmented packets have their own headers, only the size of the fragment is marked)

Once the maximum allocation is exceeded, the system can only temporarily write the extra fragments to other normal areas of memory. This is the so-called ** of memory overflow mode. This overflow is not borrowing but a pathological occupation.

It will grind out the data in the normal area. If it is critical data, there is a high possibility that it will cause the system to collapse.

However, with the continuous update of the Linux kernel, this fatal vulnerability has been filled, and now if you want to launch such a ** simply through the PING command or a program based on the IP/ICMP protocol, it is difficult to break through the kernel protection.

In addition: some friends have asked me such a question, you said IP packets exceed the maximum limit will have problems, then usually we send a file is often hundreds of megabytes on G, also did not see a problem ah?

That's a good question. Look at the second picture above.

Actual operation:

[root@server01 ~]# ping server02 -A -s 65550

SYN semi-connection ***

TCP three-way handshake, which we are all familiar with, the so-called SYN semi-connection ***

That is, after the receiver acknowledges the ACK in one direction (the receiver is ready for data transmission), the initiator does not send the last acknowledgement, so that the receiver cannot continue the handshake process.

If the receiver fails to receive the last acknowledgement, it will retry and wait. In addition, if the *** party adds IP spoofing, the receiver connection will be blocked.

In fact, whether it is the receiver's retry/wait/block, these are not actually the essence of the Dos denial of service

what really causes a denial of service is the queuing limit on the number of SYN connections the receiver can initiate

On Linux systems that have not been kernel tuned, the default maximum number of SYN connections that can be opened is 256

Once this limit is exceeded, SYN is difficult to open, and normal user HTTP requests (or other layer 4 requests) must be established within connections that begin with SYN

Then at this time, the *** person's goal is achieved. A large number of requests from normal users cannot be allocated SYN, resulting in denial of service.

Actual operation: (SYN is easily filled after the denial of service will not occur)

5) Talk about today's seven-story *** Ddos

As we said before, the four layers of high-difficulty system loopholes are becoming less and less effective, because the opponents themselves have very high requirements.

As a result, a fool-like DDos approach emerged, which is based on seven layers (application layer) of Ddos, which is now the CC***

CC is actually a branch of DDos, its principle is not complicated, by sending a large number of simulated normal user requests (most HTTP requests)*** Receiver resources

Bandwidth resources are severely consumed, websites are paralyzed, CPU and memory utilization rates soar, hosts are paralyzed, and rapid response is impossible.

In addition, we also know that for the initiator, there are also high resource requirements, including host configuration, network bandwidth, system optimization, and so on.

These are all money, so if Fang establishes his own cluster to launch ***, he will lose money and earn money.

Therefore, today's CC Ddos are more about finding various host machines. After invading, they use them as their springboard to launch attacks on targets.

This is also commonly known as chicken

6) From the perspective of operation and maintenance architects, propose a buried seven-layer handshake to try to defend DDOS for free ***

Let's start with the online architecture.

As shown in the figure above, this is a more classic online five-tier architecture, although not all Internet companies are built in a 100% way.

But the basic online framework cannot escape this layout at this stage

Whether it is a normal request or a *** request, it is entered from left to right.

The more to the right of the figure, the more the cost of each resource, the more the association, and vice versa

Therefore, we need to prevent *** traffic from hitting the right as much as possible, and control the range of the first and second layers.

This is the left-push optimization scheme (same applies to safety protection)

The Importance of Reverse Proxy

Many friends know the concept of reverse proxy, but they are not very clear about its substantive role.

We will explain the environment based on LNMP. After the HTTP request comes, we need to process the HTTP protocol and static content through nginx first.

If there is dynamic content in the request, the reverse proxy goes to PHP (code layer) for processing

And that's where the key lies.

Nginx can do seven-layer Load Balancer. In fact, the basic function of Load Balancer is also attributed to reverse proxy.

The resource consumption of reverse proxy is much smaller than that of PHP code layer (Nginx high concurrency processing, resource overhead is very small)

So, what we want is that when *** requests come in, we can control them at most until they are in the reverse proxy, so that they are not associated with the PHP code layer.

Cut that link as much as possible.

But this kind of disconnection requires determining the authenticity of the request, which is a difficult problem.

How to identify CC Ddos*** is worth considering

First of all, CC Ddos*** is a simulated real user request.

It is impossible to think of a simple method, such as adding an IP blacklist with a firewall.

IP number is large, and dynamic change or IP camouflage

Since CC*** is located on the seventh floor, then our response plan also needs to be found on the seventh floor.

One of the screening methods I share here is called seven-layer hand burial.

What does that mean?

Please refer to the following picture

We customize specific URL parameters on a seven-layer basis (i.e. HTTP) to defend against ***

URL parameters are generated on the client side, and the user is actually unaware

Client-side developers and server-side operation and maintenance developers first discuss several parameters and obtain an md5 value by calculating among several parameters.

This md5 value is appended to the URL and verified on the server side

In addition, parameters need to change in real time, and you cannot always use a dead fixed value (otherwise, once intercepted by ***, it will be invalid).

In addition, you can also add an additional "hidden button" parameter to the URL parameter. This parameter will not appear directly in the URL, but will be added to the final md5 value calculation.

This "hidden button" client developer and operation and maintenance development can be discussed in advance and placed in their own code

Some optimizations, polling values to accommodate a large number of API parameter positions also prevent *** people from guessing parameters

Cons: The more LUA code you have, the more it costs.

So today's network security sharing is here ^_^

For more, please pay attention to Rice's blog follow-up. Oh, thank you.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.