|
| Framework specifications/FCMDPF layers | OB layer | STBOA layer | FAEB layer | Remarks |
|
| (1) The framework should provide a protection against high rate DDoS (HR-DDoS) and flash crowd (FC) attacks, as well. It should be able to differentiate between them clearly to block the former immediately and block the latter gradually. | ✗ | ✗ | ✓ | The FAEB scheme of the FCMDPF framework is quite able to differentiate between HR-DDoS and FC attacks precisely. Hence, it is able to provide the protection for web applications against them properly through the FAEB algorithm, flash crowd attack entropy algorithm, and high rate attack entropy algorithm, as are described previously. The mod_antiddos module subsystem, which is developed based on FAEB scheme, detected and prevented all high rate HTTP-based DoS/DDoS (HR-DDoS) attacks. As well, it detected and prevented 369726 out of 420000 flash crowd (FC) attacks. |
|
| (2) The framework should provide a protection against low rate DDoS (LR-DDoS) attacks. | ✗ | ✗ | ✓ | Despite the FAEB scheme of the FCMDPF framework and therefore the mod_antiddos module subsystem, being able to protect web applications from LR-DDoS attacks, this protection is excluded intentionally in this research. It is excluded because the protection from LR-DDoS attacks is provided in all recent web servers by default. |
|
| (3) The framework should provide a mechanism to verify the validity of the incoming requests. As well, it should provide a mechanism to find out the true attacking IP source. Besides that, it should not be designed in a way that annoys the requesters by performing extra tasks, such as CAPTCHA. | ✓ | ✓ | ✗ | (i) The STBOA scheme of the FCMDPF framework and therefore STBOA_Shield subsystem, which is developed based on STBOA scheme, is quite able to verify the validity of an incoming request. The STBOA scheme verifies it through the STBOA algorithm to identify if it is legitimate or illegitimate and, therefore, subsequently to pass the former and block the latter. As well, it provides a mechanism that is quite able to trace back and find out the true attacking IP source in a way that does not burden or annoy the requester. In particular, the second phase of the STBOA scheme utilizes web services to send back a puzzle to the requester. In case the requester is a human using a real web browser (not a bot), he will answer this puzzle automatically by the browser itself without human interaction. Then, he will send back the answer to the web application. After that, the web application verifies (examines) the answer, and if it is correct, it passes it to the next layer or otherwise it blocks it immediately and updates the OB scheme blacklist database table with this attacking IP source.
(ii) The STBOA_Shield subsystem, which is developed based on STBOA scheme, succeeded to validate and trace back 369726 out of 420000 incoming requests.
(iii) The OB scheme then collaborates to block those updated attacking IP sources in upcoming incoming requests. |
|
| (4) The framework should provide a mechanism to block the attacking IP sources at the edge router near to the attacking source. | ✓ | ✗ | ✗ | (i) The outer blocking (OB) scheme of the FCMDPF framework is quite able to block the attacking IP source that neither passes the STBOA scheme’s tests, nor passes the FAEB scheme’s tests, at the Edge Router (Network Entrance).
(ii) The OB_Shield subsystem succeeded to detect and prevent all of those attacking IP sources, which were 420000 IP sources, at the edge router. |
|
| (5) The framework should be designed in a way that supports the separation of duties concept. | ✓ | ✓ | ✓ | (i) The FCMDPF framework is a collaborative, multilayer, DDoS prevention framework because it protects web applications against HTTP DoS/DDoS attacks at the different collaborative points through which the incoming requests have gone.
(ii) Each point at different framework layers collaborates to protect web applications from HTTP DoS/DDoS attacks by performing its special tests. Then, it forwards the request to the next framework’s layer if it succeeds, or otherwise it will be dropped immediately.
(iii) In the same manner, the next framework’s layer performs its special tests, and then it forwards the packet to the next point if it succeeds, until it reaches the target. Otherwise, it will be dropped immediately. |
|
| (6) The framework should be compatible with the existing protocols. | ✓ | ✓ | ✓ | (i) The entire FCMDPF framework’s layers, the OB layer, the STBOA layer, and the FAEB layer are compatible with existing protocols.
(ii) Indeed, the OB layer is compatible with the IP, TCP, and UDP protocols. The OB layer merely uses the IP protocol to pass or block IP source the incoming request based on its blacklist database table.
(iii) As well, the STBOA and FAEB layers are compatible with the HTTP protocol.
(iv) The STBOA layer checks HTTP protocol headers and then generates a mathematical puzzle in order to verify the validity of the requester. After that, it passes it to the next layer if it is legitimate, or it blocks it immediately if it is illegitimate.
(v) The FAEB layer uses the HTTP protocol’s relevant information in order to detect HR-DDoS and FC attacks and to block the former immediately, while it blocks the latter gradually. |
|
| (7) The framework should be deigned explicitly for processing web application layer; HTTP protocol, rather than only network layer; IP and ICMP protocols, or transport layer; TCP and UDP protocols. | ✓ | ✓ | ✓ | The FCMDPF framework mainly concentrates on protecting the HTTP protocol from all sorts of DoS/DDoS attacks, such as HR-DDoS, LR-DDoS, and FC attacks. In addition, it traces back and finds out the true attacking IP sources. |
|
| (8) The framework should be easy to implement and does not cause huge processing and bandwidth overheads. | ✓ | ✓ | ✓ | (i) In reality, the FCMDPF framework is simple to implement through collaborative multilayer; each layer is distributed and deployed at different point.
(ii) The FCMDPF framework generates very low processing and bandwidth overheads, compared to those schemes and frameworks that use packet marking [25]. |
|
| (9) The framework should be able to adopt and update itself dynamically, once needed. | ✗ | ✓ | ✓ | The FCMDPF framework can adapt and update itself once needed. In particular, when a new stealthy bot’s feature is discovered, the relevant feature’s pattern can be easily added to the STBOA scheme. As well, when a new or a different profile is in need, the relevant information such as HR-DDoS and FC threshold’s values can be easily added to the FAEB scheme. |
|
| (10) The framework should provide support to the hybrid scheme. | ✓ | ✓ | ✓ | In fact, the FCMDPF framework is designed in a way that supports the hybrid scheme that consists of proactive and reactive schemes. In particular, the OB and STBOA layers of the FCMDPF framework represent a proactive scheme, while the FAEB layer of the FCMDPF framework represents a reactive scheme. |
|
| (11) The framework should consume low storage memory. | ✓ | ✓ | ✓ | In general, the FCMDPF framework’s layers, the OB layer, STBOA layer, and FAEB layer, consume very low memory storage. In particular, the OB layer of the FCMDPF framework consumes very low memory to store its blacklist database table, while the STBOA layer of the FCMDPF framework does not consume any storage memory, since all of its transactions are done in the real time. As well, the FAEB layer of the FCMDPF framework consumes little memory to store the relevant information about web pages. |
|
| (12) The framework should be resistant to IP source spoofing attacks, especially during finding out the true attacking IP sources. | ✗ | ✓ | ✗ | In fact, the FCMDPF framework is resistant to IP source spoofing attacks, since the STBOA scheme verifies whether the requester is legitimate or illegitimate by examining incoming request’s headers and puzzle’s answer. If the requester failed to satisfy these two tests, the requester is considered an attacker. Therefore, it will be blocked immediately. |
|
