psz
-
Postów
231 -
Dołączył
-
Wygrane w rankingu
33
Typ zawartości
Profile
Forum
Wydarzenia
Odpowiedzi opublikowane przez psz
- Poprzednia
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- Dalej
- Strona 9 z 10
-
-
Jest jeszcze https://dmarcian.com/, ale przestałem używać, bo darmowa wersja jest zbyt ograniczona. Firmy jednak to lubią. Może dlatego, że było jednym z pierwszych.
-
https://www.dmarcanalyzer.com/ - do 25k maili/miesiąc za darmo
https://report-uri.com/ - do 10k raportów (nie maili; w raporcie może być np. informacja zbiorcza za cały dzień, chyba gmail tak robi) / miesiąc za darmo
-
Bawiłem się kiedyś, i działa gdziekolwiek się ustawi odpowiedni adres IP (213.186.33.5). Magnes na abuse, tylko czekać aż OVH to zlikwiduje.
Ale jeśli używasz Cloudflare, to dużo lepszym rozwiązaniem jest ustawienie przekierowania w Page Rules (bo przekierowanie jest generowane lokalnie na serwerach w 194 miastach na świecie, a nie na jednym serwerze we Francji, co znacząco zmniejsza opóźnienia).
-
1
-
-
2 godziny temu, rafii napisał:
@psz dziękuję za informacje. Nie do końca rozumiem jak to działa. Te rekordy interpretują i stosują tylko serwery OVH czy jest światowy standard? Poproszę o przykład wytłumaczony łopatologicznie
Nie, to autorska usługa OVH.
2 godziny temu, rafii napisał:Właśnie przed chwilą natknąłem się na taki oto rekord jednej z firm, który ma jeszcze dodatkowe wpisy:
nazwadomeny.pl. 299 IN TXT "v=BIMI1; l=https://nazwadomeny.pl/images/logo.svg; a=;"
Co ten rekord robi?
Jakiś nowy standard o nazwie Brand Indicators for Message Identification. Tu jest trochę opisu: https://help.returnpath.com/hc/en-us/articles/360029690591-What-is-the-correct-syntax-for-a-Brand-Indicators-for-Message-Identification-BIMI-record-in-the-Domain-Name-System-DNS-
-
To jest darmowy redirector, który OVH oferuje na domenach hostowanych u nich. Działa na zasadzie, że serwer przekierowujący (213.186.33.5) czyta rekordy TXT z domeny i robi przekierowanie. W panelu jest możliwość łatwego edytowania tych wpisów.
Nie znalazłem konfiguracji, ale chwila reverse-engineeringu doprowadziła mnie do takiej obserwacji:
www TXT "1|domena.pl" - przekierowanie z kodem HTTP 301 www TXT "2|domena.pl" - "przekierowanie" z ramką iframe www TXT "t|title" - tytuł ramki www TXT "k|keywords" - słowa kluczowe ramki www TXT "d|desc" - opis ramki www TXT "3|welcome" - strona "strona w przygotowaniu" www TXT "l|pl" - język strony powitalnej www TXT "4|domena.pl" - przekierowanie z kodem HTTP 302
Można użyć gołą domenę, albo pełny URL. Co ciekawe, redirector działa nawet jeśli ręcznie się ustawi gdzieś we własnej domenie niehostowanej w OVH.
Taka mała ciekawostka, która się może kiedyś przydać.
-
Szybkie szukanie w Google naprowadziło mnie na RFC 7151 (polecenie HOST w FTP). Będziesz więc potrzebował serwera oraz klienta z jego obsługą, ale podejrzewam, że najpopularniejsze będą to miały.
Niestety, nie słyszałem nigdy o obsłudze rekordów SRV w FTP. Będziesz więc musiał ustawić dwa osobne rekordy DNS, albo przekierować jedną z usług np. przy pomocy DNAT w iptables.
-
Nie polecam implementować FTP do niczego.
Potrzebujesz wysyłać pliki? Użyj SFTP
Potrzebujesz tylko pobierać pliki? Użyj HTTPS
-
Dnia 23.10.2019 o 14:40, Krystek napisał:
W logach domeny portalu wykryliśmy atak SQL injection, który ktoś cały czas ktoś próbuje uskutecznić z jednego, konkretnego IP. ... ale nadal ktoś bombarduje serwer HTTP - mimo otrzymywania 403 i generuje obciążenie. ... Nota bene w tych logach widać, że atakujący (atak trwa już 3-ci dzień) zwiększa wykorzystanie zasobów maszyny i przyznanego limitu, a administratorzy Kei odpisali, że nie wytną go na firewallu, bo wycięliby ruch z tego IP dla całej maszyny. Swoją drogą to niezłą cierpliwość ma atakujący - zapuścił automat i od kilku dni bombarduje domenę zapytaniami, dostaje 403 ale to go nie zraża. Może polecicie jakieś oferty?
Darmowy Cloudflare powinien z łatwością Tobie pomóc na durne ataki, jak ten (dostępne: blokowanie po IP, rate limiting, proste regułki firewalla, wymuszenie cache'owania, itp.). A jeśli atakujący nagle zmądrzeje, to dokupujesz WAF za $20/mieś.
-
Zazwyczaj oznacza to organy ścigania albo coś podobnego. Na pewno nie szary człowiek. Innymi słowy, od wprowadzenia GDPR/RODO publiczny whois stał się bezużyteczny, więc dodatkowa ochrona (a tym bardziej płatna, choć niektórzy rejestratorzy oferowali to za darmo) jest zbędna. Chyba, że obawiasz się organów ścigania, wtedy usługi typu "whois privacy" nieznacznie ich tylko spowolnią (będą musieli się zapytać jednej firmy więcej). Czy jest sens za to płacić, pozostawiam Tobie do zdecydowania.
-
-
Częsty problem z nieresolvowaniem się domen może wynikać z błędnej konfiguracji DNSSEC. Przetestuj tutaj: http://dnsviz.net/
-
Dnia 30.07.2019 o 19:12, darekm napisał:
jeśli NASK nie podniesie to u nas dalej 59 brutto bedzie
A planuje? Skąd masz takie informacje?
-
-
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.
-
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.
-
@Gnum.pl Brak obsługi DNSSEC, brak delegacji na adres IPv6. W 2019 roku... Z czym do ludzi...
-
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.
-
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
-
1
-
1
-
-
-
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.
-
-
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.
-
1
-
-
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.
-
1
-
-
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.
23 godziny temu, mariaczi napisał:Hmm, mi wygląda na to, że jest w porządku.
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").
-
3
-
- Poprzednia
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- Dalej
- Strona 9 z 10
VPS od AWS po music bota
w Offtopic
Opublikowano
Amazon Lightsail, takie małe Amazonowe oszustwo na lojalnych użytkownikach AWS.
VPSy EC2 w pakiecie z dyskiem i transferem za stałą cenę. Poczynając od 1 TB.
https://aws.amazon.com/lightsail/pricing/