Who is the best choice?
Web application protection is undoubtedly a hot topic. Because of the maturity of technologies and the increasing expectation of convenience, Web applications have become the mainstream carrier of business systems. The data value contained in the key business systems of "anjia" on the Web has aroused the favor of attackers. The Web vulnerability mining and attack tools circulating on the Internet have lowered the attack threshold, it also makes many attacks blind and random. For example, you can use the GoogleHacking principle to batch find applications with known vulnerabilities, as well as SQL batch injection and Trojan Horse mounting. However, for important Web applications (such as operators or financial institutions), hackers who are always driven by interests are constantly tracking.
If the traditional "Big and comprehensive" security protection products can defend against most attacks generated by tools, targeted attacks will not be sufficient. WAF is a high-end professional security product born on demand, which is also an inevitable trend of market demand refinement. However, since its deployment and functions are similar to those of IPS, some people may wonder why IPS cannot be used, or what are the similarities and differences between WAF and IPS? Who is better suited to protect Web servers?
These questions are actually justified. The difference is that the high-end needs are different, so we need to refine the functions to fit the specific needs and meet the application status of the product, this is also determined by the user requirements with the development of the business itself.
Bodyguard and security guard
To better understand the differences between the two products, we first use this guard (WAF) and security (IPS) to describe.
The building's security guards need to inspect all personnel entering and exiting the building. Once a suspicious person is found, he is prohibited from entering the building. However, if the "seemingly loyal" bad guy is involved in cracking the safe and other destructive activities, building security is powerless.
Private Guard refers to high-level and more "close-fitting" protection. He usually only protects specific people, so he needs to understand the identity, habits, preferences, work schedules, and weaknesses of the protected person in advance, because the work of the protected person needs to face different people, on different occasions, the responsibilities of a bodyguard cannot stop or change his behavior because of danger. Instead, they can only predict possible risks and then customize appropriate protection solutions.
The difference between the two roles is that the security guards protect the entire building, and they do not need to know who is the most important person to be protected. The guard defines the list of protected objects, a deep understanding of the individual characteristics of the protected person is required.
Figure 1.1 bodyguard and security guard
Through the above metaphor, we should understand that the two feel similar because their responsibilities are protected, but the difference lies in their different functional positioning. In terms of technical principles, it will be implemented based on positioning. The similarities and differences between WAF and IPS are analyzed in the following aspects.
Event timeline
There are three time points for the occurrence of Security Events: beforehand, during, and afterwards. Traditional IPS are only valid for attack detection and protection. The other two time points are unique to WAF.
Figure 1.2 event timeline
As shown in, vulnerabilities can be detected by actively scanning and Detecting Web servers before an event occurs, you can take proactive measures such as fixing Web server vulnerabilities or adding protection rules on front-end protection devices to prevent incidents. After the event, the website must be tamper-resistant even if the Web server is attacked, so that attackers cannot destroy website data.
Why cannot I have the 100% protection capability? In fact, we know from the following aspects that we can only achieve relatively optimal protection in the process, but not absolute, because:
1. Software is inherently flawed, including components and function libraries applied to third parties that cannot control their security;
2. The application is being updated, and the business is continuously developing and dynamic. If you do not continuously monitor and adjust security policies, there will also be omissions;
3. attackers are always in the dark. They can track and study the business system, find vulnerabilities and protective defects, and use various deformation techniques to detect and use them for attacks;
4. It is difficult for any protection device to eliminate any defects. Various algorithms and rules minimize the impact of attacks.
Therefore, a closed-loop and cyclical approach is required to reduce potential threats. For such attacks, pre-detection and post-event compensation can be used to form dynamic security protection. In advance, the website is actively inspected by scanning and a new protection rule is formed based on the results to be added to the protection policy in the event, the post-event tamper-proofing ensures that even omissions stop the attack and the website files cannot be further modified or damaged. This is especially important for users with high credibility and integrity.
Figure 1.3 WAF security closed loop
If there is only a difference in the timeline of an event, you can still use other products for assistance. However, the key thing is that there is also a deep difference in protection, now let's talk about the differences in things.
In the event, that is, real-time protection, the difference between the two lies in the aspect and depth. The advantage of IPS lies in its aspect, that is, its monitoring of all traffic in the network. It faces massive data volumes, in the TCP/IP model, network traffic is submitted layer by layer from the physical layer to the application layer. IPS mainly analyzes the data at the transmission and network layers, and then goes up to the complex application layer protocol packets, WAF only provides supervision on all aspects of Web application traffic.
Figure 1.4 Data Structure
At different regulatory levels, IPS can defend against the same attacks, such as SQL injection, but the protection principles are different. IPS relies on static signatures for identification, that is, attack features. This is just a passive security model. The following is an Snort alarm rule:
Alert tcp $ EXTERNAL_NET any-> $ HTTP_SERVERS $ HTTP_PORTS (msg: "SQL Injection-Paranoid"; flow: to_server, established; uricontent: ". asp "; pcre:"/(\ % 27) | (') | (--) | (% 23) | (#)/I "; classtype: web-application-attack; sid: 9099; rev: 5 ;)
Here we mainly check the metacharacters submitted in SQL injection, including single quotes () and dual horizontal (--), to avoid injection attacks such as 1 or 1 = 1, however, we also need to consider converting these metacharacters into Hex values to escape the filtering check. Therefore, we added the corresponding Hex encoded string to the rule.
Of course, there are still many things to consider from the signature features to identify attacks, not only metacharacters but also SQL keywords, including: select insert update, and the case-sensitive deformation and splicing of these keywords, escape filtering by using annotations, as shown in the following example:
Use case-insensitive characters: SeLecT fRom"
Replace the space character with a TAB character or carriage return character: select [TAB] from
Multiple spaces are used between keywords: select from
String Value encoding: 0x414141414141 or 0x41004100410041004100
Insert comment strings ignored by the database: sel/**/ect fr/**/om select/**/from
Use some string conversion functions supported by the database: char (65) or chr (65)
Use String concatenation operations supported by data: sel + ect + fr + om '"," 'sel | ect | fr | om can be imagined, if you want to detect the attack after the deformation characters above, you need to add the corresponding signature features, but more importantly, you need to fully consider the type of conversion encoding, the snort rules in the above example put the suspicious characters and their converted Hex values in the same rule for check. If there are many types of attacks after deformation, this is lagging behind and will cause a bloated signature.
Both of them can defend against relatively superficial attacks, but most IPS on the market cannot perform multiple conversions on message encoding, therefore, attackers only need to construct data packets such as conversion encoding, splicing attack statements, and case-sensitivity conversion to bypass the input check and directly submit the data to the application.
This is exactly the advantage of WAF. It can force Multiple conversions to different encoding methods to restore them to attack plain text, and combine the characters after deformation before analysis. Why can't IPS achieve this level? Also, encryption and decryption for HTTPS are explained in the product architecture in the next section.
Product Architecture
We all know that IPS and WAF are usually deployed on the front-end of Web servers in tandem. They are transparent to servers and clients and do not require any configuration. They all seem to be the same networking mode. In fact, there is a big difference. First, let's take a look at the deployment modes supported by mainstream WAF in the market:
L Bridge Mode
L routing Mode
L reverse proxy
L bypass mode (non-series)
When the two are deployed in tandem at the front-end of the Web server, most IPS on the market adopt the bridge mode, while WAF adopts the reverse proxy mode. IPS need to process all the traffic on the network, WAF only processes Web Application-related protocols, and others forward data, such:
Paranoid "; flow: to_server, established; uricontent:". asp "; pcre:"/(\ % 27) | (') | (--) | (% 23) | (#)/I ";
The difference between the bridge mode and the reverse proxy mode is that the bridge mode is packet forwarding based on the network layer, and there is basically no protocol stack, or only some protocol stacks can be simply simulated, the analysis of network packet traffic is based on a single packet. Therefore, it is not advantageous to handle fragmented packets, data stream reorganization, out-of-order packets, packet retransmission, and packet loss. At the same time, there are many protocol types in network traffic. Each application layer protocol has its own unique protocol characteristics and format requirements, such as Ftp, SSH, Telnet, SMTP, etc, various application traffic cannot be processed on the application layer protocol stack.
The protocol stack embedded in WAF is modified and optimized to fully support Http application protocol processing. This means that Http packets must be processed according to the RFC standard (Internet Requests For Comments, it includes the following major RFC:
L RFC 2616 HTTP syntax definition
L definition of RFC 2396 URL syntax
L how does RFC 2109 Cookie work?
L RFC 1867 how to post http and the format of POST
The request line length, URL length, protocol name length, and header value length of Http in RFC are strictly required, as well as the transmission sequence and application format, for example, Html parameter requirements, Cookie versions and formats, File Upload encoding multipart/form-data encoding, etc, these application layer content can be correctly identified and controlled only when it has a complete application layer protocol stack.