Przepuść boty CoreDash przez CDN lub firewall

Przepuść oba boty CoreDash przez CDN lub firewall

CoreDash wysyła na twoją stronę dwa boty: audyt cRUM i sprawdzanie uptime'u. Aby w pełni korzystać z CoreDash, CDN lub firewall musi przepuszczać oba. Czasami któreś z ustawień je blokuje. Ta strona pokazuje, jak rozwiązać ten problem w Cloudflare i AWS WAF za pomocą jednej reguły dla obu botów.

Co robią oba boty:

• Audyt cRUM. Gdy wybierzesz stronę w sekcji cRUM (beta) w menu CoreDash, CoreDash otwiera ją w Chrome na swoim serwerze audytowym – tak jak zwykły odwiedzający – i pokazuje, co ją spowalnia. Jego user agent to CoreDash/1.0 (audit; +https://www.coredash.app/bot).
• Sprawdzanie uptime'u. Co 30 minut CoreDash odpytuje monitorowane witryny ze swoich serwerów i informuje cię, gdy któraś przestanie działać. Wysyła CoreDash/1.0 (uptime; +https://www.coredash.app/bot).

User agent to nazwa wysyłana z każdym żądaniem przez przeglądarkę lub bota, by określić, czym jest. W obu botach CoreDash zaczyna się ona od CoreDash/ – i właśnie tego będzie szukać twoja reguła.

Jak wygląda zablokowany audyt lub sprawdzanie uptime'u

Firewall lub CDN widzi ruch z centrum danych, którego user agent nie jest przeglądarką. Uznaje go za niezaufanego bota i zwraca kod błędu lub stronę challenge. Każdy bot pokazuje to inaczej.

Zablokowany audyt cRUM zatrzymuje się z komunikatem „Audit failed” i informacją o błędzie poniżej. Może też wykonać się na samej stronie blokady: Page load filmstrip zamiast twojej witryny pokazuje wtedy stronę challenge lub stronę błędu, a wszystkie liczby w audycie dotyczą tej strony.

Monitor uptime'u wyświetla status Blocked, a powiadomienie „A firewall blocks the checker” podaje kod statusu otrzymany podczas sprawdzania oraz informację, od kiedy to trwa. CoreDash nie wlicza zablokowanych testów do downtime'u, więc blokada nie obniża wskaźnika uptime. Dopóki jednak każde sprawdzenie jest blokowane, żadne nie dociera do serwera – monitor nie może więc powiadomić cię o awarii strony.

Strona monitora dla example-shop.com, gdy Cloudflare na każde sprawdzenie uptime'u odpowiada kodem 403.

Jak firewall rozpoznaje CoreDash

W firewallu lub CDN konfigurujesz jeden wyjątek dla CoreDash. Najczęściej ustawia się go na podstawie user agenta: jedna reguła dopasowująca CoreDash/ przepuszcza audyt i sprawdzanie uptime'u. Token bota projektu pozwala stworzyć bardziej rygorystyczną regułę, bo wysyłają go wyłącznie boty z twojego projektu. Adresy IP CoreDash to rozwiązanie ostateczne, gdy nic innego nie działa. Zmieniają się one, gdy CoreDash dodaje lub przenosi serwer, więc regułę z adresami IP trzeba aktualizować samodzielnie.

To, które ustawienie wymaga wyjątku, sprawdzisz w logach firewalla. Logi Cloudflare omawiamy w kolejnej sekcji. W przypadku AWS WAF przejdź niżej do sekcji „Zezwól na CoreDash w AWS WAF powyżej Bot Control”.

Sprawdź, co zablokowało CoreDash w Cloudflare

Otwórz swoją domenę w Cloudflare i przejdź do Security › Analytics, zakładka Events. W sekcji Sampled logs znajdź żądanie z user agentem CoreDash. Przy dużym ruchu kliknij Filter, jako pole wybierz User agent i wklej pełną wartość: CoreDash/1.0 (uptime; +https://www.coredash.app/bot) dla sprawdzania uptime'u lub CoreDash/1.0 (audit; +https://www.coredash.app/bot) dla audytu.

Kliknij żądanie, aby je otworzyć. W wierszu Service znajdziesz funkcję Cloudflare, która je zablokowała.

Mechanizm Browser Integrity Check zablokował to sprawdzenie uptime'u na example-shop.com.

Wartość w wierszu Service decyduje o sposobie naprawy:

• Bot fight mode: to ochrona przed botami w planie Cloudflare Free – reguły użytkownika nie mogą utworzyć dla niej wyjątku. Przejdź niżej do sekcji poświęconej Bot Fight Mode.
• Wszystko inne, jak Browser integrity check na zrzucie ekranu, reguła zarządzana lub Super Bot Fight Mode: utwórz opisaną niżej regułę Skip.

Przepuść CoreDash przez Cloudflare za pomocą reguły Skip

Reguła Skip instruuje Cloudflare, aby nie stosować wybranych zabezpieczeń wobec żądań z user agentem CoreDash. Działa jednocześnie dla audytu i sprawdzania uptime'u, a skonfigurujesz ją w każdym planie Cloudflare.

1. Przejdź do Security › Security rules. W sekcji Custom rules kliknij Create rule.

Security rules dla example-shop.com przed utworzeniem pierwszej reguły niestandardowej.

2. Nazwij regułę CoreDash. W sekcji „When incoming requests match” kliknij „Edit expression” i wklej poniższy wiersz w otwartym polu tekstowym.

   http.user_agent contains "CoreDash/"

Nazwa i wyrażenie reguły po kliknięciu „Edit expression”. Ukośnik po CoreDash jest wymagany.

3. W sekcji „Then take action” wybierz Skip i wskaż mechanizmy, które Cloudflare ma pominąć dla CoreDash. W „WAF components to skip” zaznacz „All managed rules” oraz „All Super Bot Fight Mode Rules”. Kliknij „More components to skip”, aby rozwinąć listę, i zaznacz również „Browser Integrity Check”. Pozostaw włączoną opcję „Log matching requests”, aby w Events było później widać działanie reguły.

Akcja Skip z trzema zaznaczonymi opcjami.

4. Kliknij Deploy. Jeśli twoja domena ma już inne reguły niestandardowe, Cloudflare zapyta o kolejność: umieść tę regułę na samej górze.

Bez innych reguł niestandardowych kolejność nie ma znaczenia – kliknięcie Deploy to ostatni krok.

5. Sprawdź, czy CoreDash przechodzi przez zaporę. Gdy nadejdzie kolejny audyt lub sprawdzenie uptime'u, w sekcji Events w Cloudflare pojawi się wpis z akcją Skip. W CoreDash sprawdź bota, z którego korzystasz (lub oba).

W przypadku audytu cRUM wybierz ponownie stronę w sekcji cRUM (beta) lub odśwież kartę przeglądarki, w której jest otwarta – audyt uruchomi się na nowo. Gdy ruch zostanie przepuszczony, Page load filmstrip pokaże klatka po klatce ładowanie twojej strony w Chrome.

Ukończony audyt ze wskaźnikami TTFB, FCP, LCP i CLS oznaczonymi na klatkach.

Sprawdzanie uptime'u nie wymaga żadnego klikania: CoreDash sprawdza stronę o pełnej godzinie i w pół do, więc w ciągu 30 minut monitor zmieni stan na Up, a nowe słupki będą zielone.

example-shop.com ma znów status Up: 38 sprawdzeń otrzymało kod 403, a każde kolejne po dodaniu reguły – kod 200.

Bezpieczniejsza reguła Cloudflare z tokenem bota CoreDash

Każdy może wysłać żądanie z user agentem zaczynającym się od CoreDash/, więc złośliwy bot podszywający się pod CoreDash również przeszedłby przez regułę Skip. Token bota projektu jest poufny: każdy audyt i sprawdzenie uptime'u przesyła go w nagłówku X-CoreDash-Bot. Reguła weryfikująca ten token przepuszcza wyłącznie boty z twojego projektu.

Aby go pobrać, otwórz Project settings w CoreDash i przejdź do zakładki „CoreDash bot token”. Dostęp do niej ma wyłącznie właściciel projektu. Gdy monitor ma status Blocked, przejdziesz tam również za pomocą linku „View your CoreDash bot token” w powiadomieniu. Kliknij „Copy Cloudflare rule”, aby skopiować pełne wyrażenie z wstawionym tokenem.

Opcja „Copy Cloudflare rule” kopiuje do schowka wyrażenie z twoim tokenem.

Jeśli masz już utworzoną regułę Skip, przejdź do Security › Security rules i otwórz regułę CoreDash. W jej wyrażeniu zastąp wiersz z user agentem skopiowanym tekstem i zapisz regułę. Akcja oraz zaznaczone opcje pozostają bez zmian. Jeśli jeszcze nie masz tej reguły, wykonaj powyższe kroki dla reguły Skip, wklejając wiersz z tokenem w kroku 2.

Token jest wysyłany wyłącznie do witryny twojego projektu i jej subdomen. Monitor lub audyt strony w innej domenie nie wysyła tokena, więc taka domena pozostaje przy regule opartej na user agencie. A jeśli token kiedykolwiek wycieknie, kliknij „Make a new token”. Stary token przestaje działać natychmiast, więc od razu wklej nowy do reguły w Cloudflare.

Bot Fight Mode w darmowym planie Cloudflare

Ta część dotyczy sytuacji, w której wiersz Service w Events wskazywał Bot fight mode.

Sprawdzenie uptime'u CoreDash z akcją Managed Challenge i usługą Bot fight mode.

Bot Fight Mode weryfikuje proste boty działające na serwerach chmurowych – a dla Cloudflare oba boty CoreDash są właśnie takimi botami. Dokumentacja Cloudflare podaje, że reguły Skip i Allow na niego nie wpływają. Musisz go więc wyłączyć albo pozostawić włączony i przepuścić adresy IP CoreDash.

Wyłącz Bot Fight Mode

Przejdź do Security › Settings i przefiltruj widok według Bot traffic. Znajdź wiersz „Bot fight mode” i przestaw przełącznik na pozycję wyłączoną. Cloudflare przestanie wtedy weryfikować proste boty w całej witrynie. Jeśli wolisz zachować taką ochronę, w planie Pro dostępny jest Super Bot Fight Mode, który respektuje regułę Skip. Po wyłączeniu przełącznika utwórz również opisaną wyżej regułę Skip, aby Browser Integrity Check lub reguła zarządzana nie zablokowały CoreDash w następnej kolejności.

Przełącznik Bot fight mode znajduje się w kolumnie Status. Na tym zrzucie ekranu jest już wyłączony.

Zostaw Bot Fight Mode włączony i zezwól na adresy IP CoreDash

Zanim zaczniesz: te adresy nie są stałe. Twoje reguły IP access rules pozostają dokładnie takie, jak je wpiszesz, natomiast aktualna lista znajduje się zawsze pod adresem app.coredash.app/bot/ips.json. Jeśli CoreDash zostanie kiedyś ponownie zablokowany, najpierw porównaj swoje reguły z tą listą.

Reguła IP access rule przepuszcza dany adres IP przez reguły firewalla, a Bot Fight Mode ignoruje żądanie, jeśli pasuje ono do takiej reguły. Przejdź do Security › Security rules i w sekcji IP access rules kliknij Create rule. Jeśli Cloudflare zaproponuje utworzenie jej jako custom rule, wybierz „No, go to IP access rules”. Wpisz 51.195.222.219, wybierz Allow oraz „This website” i kliknij Create. Utwórz po jednej regule dla każdego adresu: 51.195.222.219 i 51.195.222.220 dla sprawdzania uptime'u oraz 135.125.202.210 dla audytu cRUM.

Po jednej regule IP access rule dla każdego adresu CoreDash z akcją Allow dla tej witryny.

Po zastosowaniu dowolnego z tych rozwiązań sprawdź, czy CoreDash przechodzi przez zaporę – dokładnie tak jak w kroku 5 dla reguły Skip.

Zezwól na CoreDash w AWS WAF powyżej Bot Control

W AWS WAF za blokowanie CoreDash odpowiada zazwyczaj Bot Control – oferowana przez AWS grupa reguł zarządzanych chroniąca przed botami. Rozwiązaniem jest reguła Allow dla user agenta CoreDash, umieszczona powyżej Bot Control. Ta jedna reguła przepuści audyt i sprawdzanie uptime'u. Poniższe zrzuty ekranu z AWS pochodzą ze środowiska demonstracyjnego acme-aws.com, przygotowanego na potrzeby tej strony.

1. W konsoli AWS WAF otwórz web ACL swojej witryny (zestaw reguł chroniący stronę) i przejdź do zakładki Sampled requests. Kliknij URI żądania, aby wyświetlić jego nagłówki: żądania od CoreDash mają user agenta zaczynającego się od CoreDash/. W kolumnie „Rule inside rule group” podana jest reguła, która je zablokowała.

Reguła SignalNonBrowserUserAgent w Bot Control blokuje sprawdzanie uptime'u CoreDash na acme-aws.com.

2. W widoku web ACL kliknij Add rules › „Add my own rules and rule groups”, aby otworzyć Rule builder (w nowej konsoli AWS nazywa się to Custom rule). Wypełnij formularz tak jak na zrzucie ekranu: zwykła reguła o nazwie CoreDash, która sprawdza nagłówek user-agent i zezwala na każde żądanie, w którym zaczyna się on od CoreDash/. Następnie przewiń w dół i kliknij „Add rule”.

Reguła CoreDash: Single header user-agent, Starts with string CoreDash/, akcja Allow.

3. AWS otworzy ekran „Set rule priority”. Zaznacz CoreDash, klikaj „Move up”, aż znajdzie się na samej górze, i kliknij Save. AWS przetwarza reguły od góry do dołu, a żądanie pasujące do reguły Allow nie jest dalej sprawdzane – Bot Control nigdy więc nie zobaczy żądań z CoreDash.

CoreDash na samej górze, powyżej grupy reguł Bot Control.

4. Sprawdź, czy CoreDash przechodzi przez firewall. W Sampled requests najnowsze żądania CoreDash powinny teraz wskazywać regułę CoreDash z akcją Allow.

Najnowsze sprawdzenia CoreDash na acme-aws.com pasują do reguły CoreDash i zostają przepuszczone.

W CoreDash zweryfikuj działanie bota, z którego korzystasz – tak samo jak w kroku 5 dla reguły Skip w Cloudflare: nowy audyt pokaże twoją stronę w Page load filmstrip, a monitor zmieni stan na Up po kolejnym sprawdzeniu uptime'u.

Podobnie jak w Cloudflare, token bota projektu zwiększa bezpieczeństwo tej reguły. Informacje o tym, dlaczego warto go użyć i które strony go otrzymują, znajdują się wyżej w sekcji o tokenie w Cloudflare. Aby przełączyć regułę AWS na token:

1. W CoreDash otwórz Project settings, przejdź do zakładki „CoreDash bot token” i kliknij „Copy token”.
2. W AWS WAF ponownie otwórz regułę CoreDash w swoim web ACL (formularz znany ze zrzutu ekranu z Rule builder powyżej).
3. Zmień nazwę pola nagłówka z user-agent na x-coredash-bot. AWS nie rozróżnia wielkości liter w nazwach nagłówków, więc odpowiada to nagłówkowi X-CoreDash-Bot.
4. Ustaw pole Match type na „Exactly matches string”, wklej token jako ciąg znaków do dopasowania i zapisz regułę.

Sprawdzanie serwera źródłowego kończy się timeoutem za CDN

Ta część dotyczy wyłącznie sprawdzania uptime'u i tylko sytuacji, gdy podczas konfiguracji monitora w sekcji Advanced podano Origin IP. CoreDash sprawdza wtedy serwer także bezpośrednio, z pominięciem CDN. Niektóre serwery akceptują wyłącznie żądania z adresów samego CDN. Monitor przechodzi wtedy w stan Down z komunikatem „The origin check fails: Connect timeout”, podczas gdy odwiedzający nadal normalnie otwierają strony z CDN.

CDN wciąż serwuje strony z cache, a sprawdzenie samego serwera kończy się timeoutem.

Reguła sprawdzająca user agenta lub token tutaj nie pomoże: taki serwer odrzuca połączenie ze względu na źródłowy adres IP, zanim w ogóle odczyta nagłówki. Musi więc rozpoznawać CoreDash po adresach IP. Dodaj dwa adresy sprawdzania uptime'u (51.195.222.219 i 51.195.222.220) do dozwolonych w firewallu serwera lub poproś o to hostingodawcę. Jeśli w przyszłości sprawdzanie serwera znów zacznie kończyć się timeoutem, sprawdź najpierw aktualną listę – adresy mogły ulec zmianie.

CoreDash jest nadal blokowany

Jeśli monitor nadal ma status Blocked lub audyt nadal kończy się błędem, otwórz ponownie logi i kliknij najnowsze żądanie CoreDash: Events w Cloudflare lub Sampled requests w AWS. Zobaczysz tam mechanizm, który obecnie blokuje CoreDash. Najczęstsze przyczyny:

• Inna funkcja niż wcześniej – np. Browser integrity check po wyłączeniu Bot Fight Mode. Skonfiguruj również regułę Skip.
• Reguła nie jest aktywna lub w AWS nie znajduje się na samej górze. W Cloudflare reguła CoreDash w sekcji Custom rules powinna mieć status Active. AWS wymaga jej na pierwszym miejscu listy w „Set rule priority”.
• Reguła różni się od opisu w instrukcji. Cloudflare wymaga operatora contains oraz wartości CoreDash/ z ukośnikiem; AWS wymaga nagłówka user-agent i warunku „Starts with string”.
• Jedna z twoich własnych reguł w Cloudflare, na przykład blokada krajów. Reguła Skip nie wyłącza pozostałych reguł niestandardowych, więc musisz zmodyfikować tamtą regułę, by pominęła CoreDash. W Events sprawdzisz, z jakiego kraju pochodziło żądanie.
• Tryb Under Attack Mode. Weryfikuje on każdego odwiedzającego, w tym CoreDash, dopóki go nie wyłączysz.
• Żądanie przeszło pomyślnie lub w logach w ogóle nie ma żądań CoreDash. Oznacza to, że przed Cloudflare/AWS lub za nimi działa inny firewall – na przykład u dostawcy hostingu lub bezpośrednio na serwerze. Tam również musisz zezwolić na user agenta CoreDash/.

Nadal masz problem? Skontaktuj się z CoreDash – podaj adres URL monitora lub audytowanej strony oraz czas wystąpienia blokady.

Informacje o tym, co i dlaczego wysyłają oba boty, znajdziesz na stronie bota CoreDash. Więcej o monitorach: monitoring uptime'u, a dla skryptów – Uptime API.