psz

Taki atak jest prosty do odparcia. Polecam na początek: - ograniczyć dostęp do adresów Cloudflare (żeby atakujący nie mógł pominąć), lista adresów https://www.cloudflare.com/ips/ - stworzyć Page Rule typu Cache Everything na atakowanym adresie https://dash.cloudflare.com/?zone=page-rules - dodać powtarzające się User-Agenty do 'User Agent Blocking' https://dash.cloudflare.com/?zone=firewall/tools - utworzyć regułę rate-limiting na stronę główną blokującą po np. 10 requestach na minutę https://dash.cloudflare.com/?zone=firewall/tools - (opcjonalnie) zmienić IP serwera

https://www.projectlibre.com/product/projectlibre-open-source

Zgadzam się, że jest różnica między L4 (ochrona przed którym powinna być w standardzie każdego porządnego hostingu). Natomiast co do L7 to CF ma szereg rozwiązań: - rate limiting (1 darmowa reguła) - Blokowanie po User-Agent (10 darmowych reguł), co ciekawe, skuteczne na głupie boty - IP Access Rules, można sobie np. Chiny czy Ukraińskie hostingi przyblokować - Firewall Rules (5 reguł za darmo), blokowanie po składni przypominającej Wireshark/tcpdump - Cloudflare Access (5 userów za darmo), można sobie ustawić np. /wp-admin za logowaniem - WAF (płatne) Dostępnych rozwiązań jest cała masa. Jedynym warunkiem jest, żeby atakujący nie znał adresu IP serwera, więc rotacja w hostingu wskazana.

Polecam lekturę: https://support.cloudflare.com/hc/en-us/articles/200170196-I-am-under-DDoS-attack-what-do-I-do-

Tak, myślę, że jest to przyczyna. Google DNS ma dosyć słabą konfigurację cache, szczególnie dla mało popularnych domen. Nie dzieli stanu cache pomiędzy serwerami wewnątrz PoP'u przez to bardzo często musi pytać nameserverów dla domeny, a to bardzo cierpi przy stratach pakietów.

Dla przykładu, dostaję losowe timeouty gdy odpalam takie komendy: dig a fizyda.com @ns1.fizyda.com dig ns fizyda.com @ns1.fizyda.com $ ping fizyda.com PING fizyda.com (87.98.236.85): 56 data bytes 64 bytes from 87.98.236.85: icmp_seq=0 ttl=49 time=16.907 ms 64 bytes from 87.98.236.85: icmp_seq=1 ttl=49 time=114.178 ms 64 bytes from 87.98.236.85: icmp_seq=2 ttl=49 time=136.342 ms 64 bytes from 87.98.236.85: icmp_seq=3 ttl=49 time=174.192 ms Request timeout for icmp_seq 4 Request timeout for icmp_seq 5 64 bytes from 87.98.236.85: icmp_seq=6 ttl=49 time=16.450 ms Request timeout for icmp_seq 7 64 bytes from 87.98.236.85: icmp_seq=8 ttl=49 time=23.186 ms 64 bytes from 87.98.236.85: icmp_seq=9 ttl=49 time=17.876 ms Request timeout for icmp_seq 10 Request timeout for icmp_seq 11 Request timeout for icmp_seq 12 ^C --- fizyda.com ping statistics --- 14 packets transmitted, 7 packets received, 50.0% packet loss round-trip min/avg/max/stddev = 16.450/71.304/174.192/63.010 ms Teraz widzę, że masz bardzo duże straty pakietów, tu bym poszukał przyczyny problemów. Może serwer jest przeciążony, albo wadliwy (jeśli dedyk). Polecam zapytać supportu OVH.

Pojawiające się co chwilę kody błędu "SERVFAIL" (co bardziej, pokazują to różni usługodawcy) sugerują problem po stronie serwera DNS dla domeny. Jako, że używasz własnego VPS, podejrzewam, że masz ustawienia firewalla, które albo blokują TCP/UDP port 53, albo jakiś rate-limiting. Patrząc na szybko są problemy z różnymi rekordami, nic specyficznego dla CNAME. Jeśli nie masz jakiegoś wyraźnego powodu dlaczego nie chcesz używać zewnętrznych serwerów DNS, to polecałbym Cloudflare (najszybszy DNS na świecie wg https://www.dnsperf.com/). Disclaimer: Pracuję dla Cloudflare, ale tutaj odpowiadam prywatnie. Czasy odpowiedzi > 1000 ms to z pewnością nic w porządku. Wyraźnie widać, że serwery Google w ogóle odpowiadają, ponieważ próbują po kilka razy. Odpowiedzi z TTL = 0 to prawdopodobnie tzw. stale cache, co samo w sobie jest ciekawym pomysłem (w skrócie: "wiem, że mój cache wygasł, ale serwer ma problem, więc odpowiem tym, co wiem").

https://www.zoho.eu/mail/

Jeśli nie ma na stronie żadnych interaktywnych elementów, nawet zwykły hosting + Cloudflare będzie w sam raz. Lektura: https://support.cloudflare.com/hc/en-us/articles/202775670-How-Do-I-Tell-Cloudflare-What-to-Cache- https://support.cloudflare.com/hc/en-us/articles/200172366-How-do-I-cache-everything-on-a-URL-

Oczywiście, to było uproszczenie. Chodzi o najbliższy z punktu widzenia BGP, ale do celów wyjaśnienia wystarczy.

Tu masz w prosty sposób przedstawiony temat czym Anycast jest: https://www.cloudflare.com/learning/cdn/glossary/anycast-network/ W skrócie: Anycast to technologia, która umożliwia świadczenie tej samej usługi w wielu miejscach na świecie, natomiast protokoły trasujące (te, które decydują jak wysłać pakiety z punktu A do punktu B, najczęściej BGP) kierują Twój ruch do najbliższego pod względem geograficznym miejsca. Np. między Paryżem a Tokyo jest opóźnienie 230 ms, ale już między Paryżem a Londynem tylko 5 ms. Prędkości światła nie zmienisz, ale możesz zmniejszyć odległość Tutaj masz przykład globalnej sieci firmy Cloudflare (które nota bene można używać za darmo dla własnej domeny/www): https://www.cloudflare.com/network/

Regulamin: