Skocz do zawartości

psz

Użytkownicy
  • Ilość treści

    19
  • Rejestracja

  • Ostatnio

  • Wygrane dni

    1

psz wygrał w ostatnim dniu 20 Luty

psz ma najbardziej lubianą zawartość!

Reputacja

7 Neutral

Informacie firmowe

  • Firma/marka
    Cloudflare

Ostatnio na profilu byli

Blok z ostatnio odwiedzającymi jest wyłączony i nie jest wyświetlany innym użytkownikom.

  1. Czy mogę poprosić, żeby firma @Gnum.pl spamowała swoimi ofertami we własnym wątku w dziale Ogłoszenia? thx.
  2. A planuje? Skąd masz takie informacje?
  3. Robiłem kilka razy migrację poczty między serwerami przy pomocy programu imapsync, i sobie bardzo chwaliłem. Wrzucenie tego do crona nie powinno być większym problemem. Nie jest on jednak napisany w PHP.
  4. psz

    Nowe tld

    Część domen nTLD się przyjmuje i są relatywnie popularne (tutaj ranking ). Dużym minusem dla których nTLD nigdy w Polsce nie będą popularne jest bardziej prozaiczny. Prawie wszystkie są w języku angielskim, więc jeśli firma/osoba nie celuje w odbiorcę globalnego, to nigdy u nas nie będzie nimi zainteresowania.
  5. @Gnum.pl Brak obsługi DNSSEC, brak delegacji na adres IPv6. W 2019 roku... Z czym do ludzi...
  6. psz

    Podział poczty

    Ja dodam jeszcze, że oprócz subdomeny, jak wspomniał @theqkash, można też zrobić aliasy w domenie xyz.pl, które by przekierowywały tylko wybrane adresy do firmy outsourcingowej.
  7. psz

    Hosting na start

    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
  8. https://www.projectlibre.com/product/projectlibre-open-source
  9. 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.
  10. Polecam lekturę: https://support.cloudflare.com/hc/en-us/articles/200170196-I-am-under-DDoS-attack-what-do-I-do-
  11. 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.
  12. 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.
  13. 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").
  14. psz

    Serwer poczty

    https://www.zoho.eu/mail/
×
×
  • Utwórz nowe...

Ważne informacje

Korzystając z forum, wyrażasz zgodę na: Warunki korzystania z serwisu, Regulamin, Polityka prywatności.