News

Layer 7 DDoS attack on our Web Host servers

Layer 7 DDoS attack

This weekend, more exactly yesterday (2017/02/05) we have experienced a Layer 7 DDoS attack that affected for a short period the majority of the websites we host. Targeted websites were the Gaming hosting range.

We had previous attacks as well, but none of them managed to affect us, until yesterday. The attackers used bots that made many concurrent connections per IP; this should have not affected us in any way, but the requests were taken as legit human requests, the only difference and their mistake was the “referrer”.

The highest peak was at 18:56 ( UK Time ) which reached over 7500 concurrent connections. We immediately had taken action, and manually banned the majority of the attacking IP addresses.

The upon further investigation, we found these interresting logs (xxx.xxx.xxx.xx:yyyy means hidden from public):

2017/02/05 18:56:41 [crit] 249794#249794: *9699055 connect() to xxx.xxx.xxx.xx:yyyy failed (99: Cannot assign requested address) while connecting to upstream, client: 37.76.217.0, server: localhost, request: "GET / HTTP/1.0", upstream: "xxx.xxx.xxx.xx:yyyy", host: "xxx.xxx.xxx.xx", referrer: "1n0tecvo3j.net"
2017/02/05 18:56:41 [crit] 249792#249792: *9703927 connect() to xxx.xxx.xxx.xx:yyyy failed (99: Cannot assign requested address) while connecting to upstream, client: 193.107.97.197, server: localhost, request: "GET / HTTP/1.0", upstream: "xxx.xxx.xxx.xx:yyyy", host: "xxx.xxx.xxx.xx", referrer: "20af7nwfxo.me"
2017/02/05 18:56:41 [crit] 249792#249792: *9703937 connect() to xxx.xxx.xxx.xx:yyyy failed (99: Cannot assign requested address) while connecting to upstream, client: 193.107.97.197, server: localhost, request: "GET / HTTP/1.0", upstream: "xxx.xxx.xxx.xx:yyyy", host: "xxx.xxx.xxx.xx", referrer: "rmbgmibjlb.info"
2017/02/05 18:56:41 [crit] 249793#249793: *9699170 connect() to xxx.xxx.xxx.xx:yyyy failed (99: Cannot assign requested address) while connecting to upstream, client: 37.76.217.0, server: localhost, request: "GET / HTTP/1.0", upstream: "xxx.xxx.xxx.xx:yyyy", host: "xxx.xxx.xxx.xx", referrer: "juxior7qep.ru"

So what does this mean? Basically because of the too many requests, the backend server could not serve anymore, thus triggering the “502 Bad Gateway” which you may have seen yesterday.

These requests also triggered a particular mod_security rule:

[Sun Feb 05 18:56:33.317898 2017] [:error] [pid 561854] [client 202.179.23.96] ModSecurity: Warning. Match of "pm AppleWebKit Android" against "REQUEST_HEADERS:User-Agent" required. [file "/usr/local/apache/conf/modsec_vendor_configs/OWASP/rules/REQUEST-20-PROTOCOL-ENFORCEMENT.conf"] [line "299"] [id "960015"] [rev "3"] [msg "Request Missing an Accept Header"] [severity "NOTICE"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "8"] [tag "Host: xxx.xxx.xxx.xx"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/MISSING_HEADER_ACCEPT"] [tag "WASCTC/WASC-21"] [tag "OWASP_TOP_10/A7"] [tag "PCI/6.5.10"] [hostname "xxx.xxx.xxx.xx"] [uri "/"] [unique_id "[email protected]"]

So the attackers were smart, but not smart enough. Our expert technicians have resolved this issue under 10 minutes.

After making some extra tweaking, our web servers are now able to automatically detect and throttle ( ban ) these IP`s that will make such requests.

We do apologise for all those that were affected by this attack, and we can ensure you that your business will always be up with us.

Thank you for reading, and have a nice day!