Krystek

Co prawda o jakości oferty wypowiedzieć się nie mogę, bo nie korzystam z usług webh.pl, ale mogę stwierdzić, że jeśli nie jesteś ich klientem (i nie chcesz zostać) to olewają korespondencję kierowaną do nich (nawet jeśli zgłaszasz przypadek ataku z serwerów, które są przez nich hostowane). A było tak: system IPS WordPressa zablokował próbę włamu brute force z pewnego IP. Jako, że zgłaszam wszystkie próby włamów do serwisu AbuseIPDB to przy okazji wyszło, ze zgłaszane IP jest obsługiwane przez operatora z Polski. Postanowiłem więc, że zgłoszę bezpośrednio do firmy zarządzającej klasą adresową IP. Jako, że korespondowanie z działami abuse operatorów klas adresowych IP typu Amazon (AWS), czy inne Google nie ma większego sensu to myślałem, że chociaż tutaj ktoś zareaguje. Przesłałem szczegóły dotyczące incydentu, logi, wszystkie informacje, które byłem w stanie zebrać i udostępnić. To było w piątek. Przez weekend z ciekawości zerkałem na raporty z AbuseIPDB dla tego zgłaszanego IP i cały czas były raportowane z różnych krajów ataki na instalacje WordPress. Po weekendzie przypomniałem się firmie, do której przesłałem zgłoszenie. Odpisano mi, że tak, to ich klasa adresowa z tym IP, ale najlepiej, żebym zgłaszał bezpośrednio do firmy, która podnajmuje od nich adresy IP, bo oni sami nie mogą tego zrobić i zareagować, jeśli ktoś nie prześle zgłoszenia do ich klienta. Dodam, że serwis AbuseIPDB pokazuje zarządzającego klasą adresową, a nie dane końcowego klienta, który korzysta z tej klasy. Podesłali mi link do rekordu bazy RIPE z wpisem firmy, która korzysta z ich adresów IP, czyli Ultrahost - właściciel marki webh.pl No to wysłałem do nich całe zgłoszenie, które wysłałem poprzednio z danymi. Tutaj już odpowiedzi się nie doczekałem. Nadal z ciekawości zerkałem na te wpisy w AbuseIPDB i jeszcze przez tydzień ludzie zgłaszali ataki z tego zgłaszanego adresu. Konkluzje / konstatacje, które mi się nasunęły: dziwi mnie, że operatorowi klasy adresów IP nie zależy na reputacji adresów. Gdyby zależało to by sam podesłał firmie, która podnajmuje od nich adresy zgłoszenie ode mnie, a nie twierdził, że nie może. Może dla niego lepiej żeby IP gniły w filtrach i innych RBL-ach. Wszak dzisiaj IP wynajmuje firma A, jutro może te IP wynajmować firma B. Tylko współczuć jeśli się trafi na trefną klasę do prowadzenia biznesu. Smuci brak odpowiedzi na zgłoszenie. Wystarczyłaby odpowiedź: „Dziękujemy za zgłoszenie. Przyjrzymy się sprawie”. I tyle. Nie wymagam, by firma informowała mnie krok po kroku o tym, co robi w tej sprawie, ale chociaż krótka odpowiedź na zgłoszenie. Chociaż patrząc na to, że w Polsce cały czas słowa „proszę”, „dziękuję”, „przepraszam” nie są popularne to może nie powinno mnie to dziwić. Za to nie dziwi mnie, że gdy ludzie chcący zgłosić np. jakąś lukę w oprogramowaniu / systemie (nie mam na myśli tutaj tej sytuacji) zostają olani przez firmę to publikują szczegóły dotyczące tej luki. Bo gdyby firma była zainteresowana to by świadczyło, że jej produkt nie jest taki super i łał. Dobra. Pożaliłem się. Proszę potraktować ten wpis jako rozważania natury ogólnej

Dzięki, @psz Pewnie podeślę dostawcy. Może ktoś będzie chciał się tym zająć i podepnie ruch pod CF. A co do samego problemu z łącznością z CF to śledząc różne fora i grupy nie tylko ja miałem taki problem, ale też inni ludzie z PL, a także z zagranicy. tak, czy siak. Każdemu może się zdarzyć. Dobrze, że to nie jakaś globalna awaria.

Ano. Pewnie to był ten przypadek. Sprawdziłem AS-y mojego dostawcy Internetu i faktycznie wymienia ruch z THINX-em. Rozumiem, że to problem po jego stronie, w sensie na sztywno ma ustawiony ruch z THINX do CF i nie może przeroutować przez inny AS.

Dzisiaj, tj. 23.06.2021 w godzinach popołudniowych domeny obsługiwane przez DNS-y CloudFlare nie odpowiadały. Forum RootNode również leżało (nie mówiąc o paru większych serwisach). Czy jest jakiś sposób - po stronie użytkownika / właściciela serwsiu, by zabezpieczyć się przed tego typu awariami?

Dzisiaj znowu serwer DNS dostał czkawki, bo dostałem powiadomienie z serwisu monitorującego domenę, że domena nie odpowiada. Chyba faktycznie trzeba będzie przenieść się z zarządzaniem domeną w inne miejsce. Akurat ja tam za wiele zarzucić serwisowi FreeDNS.42.pl, bo korzystam z niego do obsługi niekrytycznych systemów. Jedyne, czego brakuje (i o co można mieć żal) to to, że administrator nie wysyła mailem powiadomień do wszystkich o zaistniałem sytuacji. Wcześniej wysyłał powiadomienia o różnych sprawach związanych z serwisem, ale od dawna już tego nie robi. I tego właśnie brakuje.

I nie zapomnieć, żeby treści na stronie linkowane były do adresów z HTTPS, inaczej przeglądarka może wyświetlić komunikat, że strona nie jest w pełni bezpieczna, bo zawiera odnośniki do niezabezpieczonych stron ("mixed content") i wtedy kłódka nie zaświeci się na zielono.

Jako ciekawostkę dodam - bo oczywiście w starym panelu tego nie było - że gdy chcemy usunąć całkowicie (skasować) z panelu strefę DNS dla konkretnej domeny to by to zrobić OVH wysyła mailem formularz, który należy wypełnić i zatwierdzić, by operacja została zatwierdzona a strefa skasowana. W panelu OVH były rekordy DNS dla domen, które nie zostały przedłużone (to, że nie skasowali stref dla takich domen to akurat nie jest złe, bo można sobie przypomnieć wpisy - np. SPF, jeśli się deleguje NS-y na inny serwer, ale jeśli miało się sporo domen, które nie zostały opłacone i przedłużone to już się robi mętlik) i żeby je całkowicie usunąć z panelu OVH należy wypełnić i zatwierdzić formularz.

Ten nowy panel to tragedia. Wszystko działa kilka razy wolniej w porównaniu ze starym. Może nawet i ładnie wygląda (kwestia gustu), ale co z tego...

Abstrahując od tych wszystkich rzeczy, które to wymieniłeś. A jak sprawdzisz (tj. udowodnisz) poziom SLA? Że jest 99,8 a nie 99,78%?

Może nie przedłużyli abonamentu na Pingdomie. Swoją drogą to ceny usług SolarWinds są kosmiczne i nakierowane na wielkie korpo.

A kto bogatemu zabroni?

A, OK

Ceny hostingu Wam się chyba poprzestawiały, @sohost Na stronie - https://sohost.com/cart.php?gid=1 pakiet o pojemności 10GB jest droższy, od tego 20GB.

Blokadę przez plik .htaccess robi i serwer - dodając reguły z cPanelu, i wtyczka All in One WP Security. Dodaje np. reguły próbujące wyeliminować boty, proxy, ataki na konkretne pliki konfiguracyjne WordPressa, listowanie folderów, przekierowania z podejrzanych stron i ataki na popularne moduły, pliki, katalogi. Tu jest nieco opisane - https://www.tipsandtricks-hq.com/wordpress-security-and-firewall-plugin | https://www.tipsandtricks-hq.com/adding-firewalls-to-your-wordpress-site-6974 Nie mogę już zatwierdzić edycji poprzedniego komentarza, więc dodaję kolejny: dodałem w załączniku do tego postu z komentarzem plik .htaccess wygenerowany przez wtyczkę All in One WP Security. W niej są wstawione prawie wszystkie reguły, które zostały dodane przez włączenie odpowiednich opcji w panelu administracyjnym wtyczki w WP adminie. Prawie wszystkie opcje bezpieczeństwa powłączałem dla strony, z której pochodzi ten plik .htaccess. WP_All_in_One_Security-htaccess.txt

Ale ilu masz tam użytkowników tego Subiekta? Jakiej wielkości jest baza danych? Baza danych na SSD to dobra opcja pod warunkiem, że robisz co jakiś czas jej kopię na zwykły, talerzowy HDD. Na jakiej wersji bazy danych MS SQL to pracuje? Windows 7 Pro nie jest wcale zły do takich rzeczy, ale wszystko zależy od parametrów komputera i liczby jednoczesnych użytkowników, którzy korzystają jednocześnie z programu. Może na początek wystarczyłoby zmienić dysk systemowy i z bazą danych na SSD i mieć kopię na HDD.

Gdybyś miał router ASUS, na który można wgrać alternatywne oprogramowanie to wgrywając DD-WRT miałbyś cały wachlarz możliwości podłączenia się do sieci za routerem korzystając z szyfrowanego tunelu: przez VPN, PPTP i WireGuard, ktory nie spowalnia tak połączeń, jak transmisja przez VPN. W DD-WRT przy okazji nie trzeba bawić się mocno w całą skryptologię, jak w innych alternatywnych dystrybucjach softu na routery. Prawie wszystko można wyklikać w panelu routera.

Nie dodaję do blokady adresów typu Neostrada. Dodaję albo klasy albo powtarzające się adresy, które najpierw sprawdzam pod kątem zjadliwości w serwisie AbuseIPDB, czyli głównie hostingownie z atakującymi maszynami (Hetzner, OVH, Digital Ocean, Microsoft i kilka innych, które się często przewijają).

No, to nie moje pluginy Miałem posprzątać po włamaniu. Też obstawiam dziury w dodatkach, bo Immunify360 część plików instalacji WP naprawił (wykasował złośliwy kod), a część podrzuconych plików zapisał na liście do usunięcia. Te wgrane pliki pousuwałem. WordPressy zaktualizowałem i włączyłem automatyczną aktualizację dodatków. Ale zauważyłem też jedną rzecz związaną z cPanelem i blokowaniem po IP w Blokerze IP cPanelu: w logach cPanlu sprawdzam wpisy w sekcji Logi błędów. Tam mam odwołania z IP do nieistniejących zasobów i mogę sprawdzić, czy z danego adresu nie było wejść na różne domeny na tym serwerze. Wtedy wiem, że takie IP jest podejrzane, bo wie o różnych innych domenach. Takie IP dodaję w Blokerze IP i najczęściej jest tak, że przy kolejnej próbie sondowania strony taki adres dostaje 403 od serwera. Ale wydaje mi się, że było kilka adresów, które dodałem w Blokerze IP cPanelu, a nie zostały zablokowane przez serwer. Bo sprawdzałem potem czy te adresy były wpisane na listę blokowanych i były. Tak, jakby taa blokada razł działała, a innym razem nie. Możliwe to?

Jeśli tylko dla domeny z www i bez www w adresie to za 29 zł brutto PositiveSSL od Comodo w HitMe.pl - https://hitme.pl/certyfikaty-ssl/

Wszystko zależy od tego, na jakim łączu pracujesz. Jaki jest upload na nim i tak dalej.

Dzięki. No to tak, jak myślałem. FTP-a nie da się zablokować. A szkoda, bo po klasach IP, które brużdzą - czyli hostingownie - bym poblokował to i owo, żeby odbijali się od serwera w ogóle. Co do WordPressa to na każdej jego instalacji jest jeszcze zaintalowany dodatek All In One WP Security & Firewall [link], który przede wszystkim blokuje 90% szkodliwego ruchu. Mam w nim ustawione, że po 3-ch próbach logowania na panel admina WP z błędnym loginem i/lub hasłem, adres IP z którego była taka próba jest blokowany na 48h. Mailem dostaję powiadomienia o próbie logowania z adresem IP oraz nazwą loginu admina, której próbowano użyć do zalogowania. Poza tym jest tam w tym dodatku włączona opcja sprawdzania wywołań 404 dla strony WP w domenie, więc m ożna prześledzić jakie IP próbują wywoływać nieistniejące skrypty albo odwołują się do katalogów, do których nie powinny. Je też można dodać do blacklisty - automatycznie lub ręcznie. Powtarzające się adresy albo takie, które atakują kilka razy z rzędu dodaję do listy blokowanych. Jest tam wiele jeszcze innych opcji, które pomagają walczyć z próbami włamań (np. firewall, który blokuje fałszywe boty, dodawanie captacha na stronie logowania, zmiana adresu strony logowania). Ale akurat w tym przypadku próbuję ustalić, czy to atak na jednego WordPressa rozlał się po całym serwerze, czy może wyciekło hasło dostępowe FTP do folderu głównego domeny. Dla dostępu przez FTP/SSH będę generował klucz SSL, by logować z autoryzacją poprzez certyfikat, więc może to wyeliminuje wykradanie haseł przez malware (o ile u kogoś - korzystających z tego serwera i dostępu FTP do niego - wyciekło).

Chyba nie było? Certyfikaty SSL wydawane będą tylko na rok. Po 31 sierpnia 2020 nie będzie można przedłużyć na 2 lata certyfikatów, które były wydane na taki okres przed tą datą. Zostaną przedłużone jedynie na rok z kawałkiem. Więcej informacji o przyczynach takiego stanu rzeczy w artykule - https://certyfikatyssl.pl/news/certyfikaty-ssl-tylko-na-rok.html

Znajomemu, który ma konto na hostingu i kilka zainstalowanych domen z WordPressami, ktoś włamał się na te WordPressy i zainstalował w nich szkodliwe skrypty. Poprosił mnie, bym pomógł mu popsrzątać po włamywaczach. Administratorzy hostingu powiadomili o włamie i zablokowali dostęp do zarażonych plików, a ich lista była dostępna w wynikach skanera Immunify360. Pousuwałem ręcznie wskazane pliki, zaktualizowałem WordPressy, wtyczki i szablony, włączyłem automatyczną aktualizację wtyczek (WordPress od najnowszej wersji 5.5 pozwala na ustawienie zautomatyzowanych aktualizacji dodatków). Poblokowałem również w Blokerze IP adresy IP, z których w dniu ataku pochodził największy ruch. Były to głównie adresy zagranicznych serwerowni, które wyciąłem bez żalu, bo to zwykły użytkownik ma zaglądać na stronę, a nie host w serwerowni. Jako, że tam są WordPressy, które mają pliki.htaccess to po dodaniu blokowanego IP w Blokerze IP cPanelu taki adres pojawia się w sekcji deny wpisów pliku .htaccess. Pytanie, czy jest możliwość - dysponując cPanelem - zablokować ruch do stron z konkretnych IP nie tylko na poziomie plików .htaccess? Bo w logach FTP dla konta jednej z podpiętych domen był ruch z farmy botów. Wyciąłem ten adres blokerem cPanelu, ale po FTP nadal można się z tego adresu dobijać do serwera? Hasło do tego konta oczywiście zmieniłem, chociaż nie ja to konto zakładałem - w ogóle nie miałem go skonfigurowanego w żadnym programie FTP. Czy na koncie hostingowych nie da się wyciąć ruchu z IP? Czy już trzeba do tego VPS-a? I ostatnie pytanie w kwestii bezpieczeństwa stron na hostingu to tam jest folder domowy /home/nazwakontahostingowego folder /public_html oraz foldery poszczególnych domen, na których są WordPressy. Czyli tak: /home/nazwakontahostingowego/public_html/domena.1/ /home/nazwakontahostingowego/public_html/domena.2/ /home/nazwakontahostingowego/public_html/domena.3/ itd. Czy jest możliwe, że jeśli ktoś włamie się na WordPressa w folderze /domena1 to jest w stanie dostać się poziom wyżej, do folderu /public_html/ i atakować inne strony na serwerze? Bo w wyniku włamu ucierpiały takze strony, na których nie ma WP - są tylko folderu z index.php albo index.html. I jeszcze jedno. Wśród tych stron na WordPressie są takie, które już nie będą w przyszłości aktualizowane o nowe materiały (teksty, zdjęcia, pliki). Czy jeśli zablokuję dodatkowo dostęp do folderu /wp-admin/ za pomocą .htpasswd i zastosuję regułkę z tej strony, by działał poprawnie panel admina to czy to nie zepsuje automatycznych aktualizacji WP?

GSC?

Dziękuję za wszelkie sugestie, szczególnie dla @nnd.newbie i @mrViperoo za polecenie ciekawych serwisów storage. W trakcie poszukiwań znalazłem jeszcze takie serwisy, które oferują transfer plików większych, niż 5GB. Oto one: https://www.swisstransfer.com/en https://www.grosfichiers.com/en https://forumfiles.com/ https://framadrop.org/ Przy czym próbowałem wysłać plik o rozmiarze ok. 5,7GB za pośrednictwem tego pierwszego serwisu z listy - https://www.swisstransfer.com/en ale transfer zatrzymał się na 97% (być może dlatego, że wybrałem opcję założenia hasła do pobrania pliku po załadowaniu) i ostatecznie mi się nie udało. Innych już nie testowałem, bo właśnie wgrywam FTP-em na serwer hostingu. A ten drugi serwis z listy ma trochę słaby upload 300 MB na godzinę https://www.grosfichiers.com/en/FAQ.html