Google ostrzega przed Państwa stroną, odwiedzający trafiają na obce strony albo dostawca hostingu zablokował konto? Izolujemy stronę, zamykamy lukę i usuwamy złośliwy kod w ciągu 24 godzin od uzyskania dostępu, także w weekend. Potem otrzymują Państwo pisemny raport.
Bezpieczeństwo aplikacji webowych przed pentestem i po ataku
Zbliża się test penetracyjny, raport wskazuje luki albo Państwa strona została zhakowana? Sprawdzamy aplikację i serwer przed testem, usuwamy podatności wskazane w raporcie, a po ataku pomagamy w ciągu 24 godzin od uzyskania dostępu, także w weekend.
- Full stack i DevOps od 2012 r.
- PHP i WordPress od 2012 r., do tego Craft CMS
- Wsparcie i awarie całą dobę (24/7)
Co robimy dla bezpieczeństwa Państwa aplikacji
Typowe powody są takie:
- Klient, bank lub przetarg wymaga testu penetracyjnego, a termin jest już ustalony.
- Raport z testu penetracyjnego wskazuje luki, a w firmie nikt nie ma czasu ani wiedzy, żeby je zamknąć.
- Państwa strona została zhakowana, a pierwsi zauważyli to odwiedzający lub Google.
- Strona na Craft CMS lub WordPressie działa od lat i nikt nie pilnuje aktualizacji ani dostępów.
Aplikację i serwer zawsze traktujemy razem: kod, konfigurację, dostępy, serwer WWW i system Linux pod spodem. Nasi inżynierowie pracują od 2012 r. jako inżynierowie full stack i DevOps, z PHP, ColdFusion i Lucee. Dzięki tej wiedzy znajdujemy i zamykamy luki bez przepisywania aplikacji od nowa.
Przygotowanie do testu penetracyjnego: zanim przyjdzie audytor
Jeśli test penetracyjny znajduje głównie przestarzałe biblioteki, otwarte dostępy administracyjne i dane diagnostyczne, na trudne pytania zostaje mało czasu. Dlatego przed terminem sprawdzamy:
- aplikację: dane wejściowe, logowanie i sesje, uprawnienia, przesyłanie plików i biblioteki
- serwer: otwarte usługi, dostępy administracyjne, TLS, nagłówki bezpieczeństwa i aktualizacje
- konfigurację: komunikaty o błędach, dane diagnostyczne i konta z domyślnymi hasłami
Otrzymują Państwo ustalenia według ryzyka, z nakładem pracy dla każdego z nich. Szybkie poprawki wykonujemy jeszcze przed testem; które, uzgadniamy z Państwem po przeglądzie. Przygotowanie nie zastępuje testu penetracyjnego. Dzięki niemu test zajmuje się trudnymi pytaniami, a nie oczywistymi lukami.
Usuwanie podatności z raportu z testu penetracyjnego
Raport jest gotowy, a lista długa? Porządkujemy ustalenia według ryzyka i usuwamy podatności w kodzie i konfiguracji, na przykład cross-site scripting, SQL injection, niezabezpieczone sesje lub niesprawdzane przesyłanie plików. Każdą poprawkę sprawdzamy, a na potrzeby ponownego testu otrzymują Państwo listę tego, co i gdzie zostało zmienione. Dotyczy to także starszych aplikacji w PHP, ColdFusion lub Lucee, których autora już nie ma.
Jeśli luki w kodzie nie da się zamknąć od razu, zabezpieczamy ją tymczasowo. Strefy sieciowe, dostęp administracyjny przez VPN i WAF z regułami dla Państwa aplikacji opisuje część o architekturze bezpieczeństwa na stronie Administracja Linux i infrastruktura. Jeśli przyczyną jest wersja bez aktualizacji bezpieczeństwa, aktualizację planujemy jako osobny krok w ramach usługi Migracja i modernizacja.
Pierwsza pomoc, gdy Państwa strona została zhakowana
Google ostrzega przed Państwa stroną, odwiedzający trafiają na obce strony albo dostawca hostingu zablokował konto? W ciągu 24 godzin od uzyskania dostępu, także w weekend, izolujemy stronę, ustalamy drogę włamania, zamykamy lukę i oczyszczamy stronę. Zmieniamy hasła i dostępy, a jeśli Google oznaczył stronę jako niebezpieczną, składamy wniosek o ponowną weryfikację.
Najczęściej dotyczy to stron na WordPressie. Pomagamy także przy Craft CMS i innych aplikacjach w PHP lub CFML. Jak przebiegają te 24 godziny i czego lepiej nie robić przed rozpoczęciem naszej pracy, opisuje strona Strona zhakowana?
Zabezpieczenie stron na Craft CMS i WordPressie
Strona oparta na systemie zarządzania treścią pozostaje bezpieczna tylko wtedy, gdy ktoś dba o CMS, wtyczki i serwer. Przy stronach na Craft CMS i WordPressie postępujemy tak:
- inwentarz wtyczek i motywów: co jest rozwijane, a co porzucone
- aktualizacje CMS, wtyczek i PHP, najpierw sprawdzane w środowisku testowym
- wymiana lub usunięcie porzuconych wtyczek
- logowanie dwuskładnikowe do panelu administracyjnego, właściwe uprawnienia do plików i WAF na serwerze
- kopie zapasowe z testem odtworzenia i monitoring
Pierwszym krokiem jest Przegląd CMS. Pokazuje, w jakim stanie jest Państwa strona, i kończy się planem przejęcia i opieki.
Testy penetracyjne: współpracujemy z każdą firmą, która je wykonuje
Test penetracyjny przeprowadza wyspecjalizowana firma. Współpracujemy z każdą firmą wykonującą testy penetracyjne, którą wybiorą Państwo lub Państwa klient: przygotowujemy aplikację i serwer do testu, odpowiadamy na pytania audytorów, a potem usuwamy wskazane podatności. Jeśli nie mają Państwo jeszcze wykonawcy, w razie potrzeby dobierzemy odpowiedniego partnera, aby uszczelnić Państwa aplikację.
Technologie, które zabezpieczamy
Dwie typowe sytuacje wyjściowe opisane szczegółowo
-
-
Państwa stary system działa i zawiera reguły, których nikt nie chce pisać od nowa. Udostępniamy jego logikę jako usługę webową i jednorazowo zamykamy znane luki. Testy porównawcze sprawdzają, czy działanie pozostaje takie samo, a nowe funkcje powstają obok, w nowym stosie technologicznym.
Dwa produkty wejściowe w stałej cenie: przed testem i po ataku
Przygotowanie do testu penetracyjnego
Dla firm, przed którymi jest test penetracyjny wymagany przez klienta, audytora lub przetarg, a które chcą wcześniej wiedzieć, gdzie ich aplikacja i serwer są podatne na atak.
- Aplikacja: dane wejściowe, logowanie i sesje, uprawnienia, przesyłanie plików, przestarzałe biblioteki
- Serwer: otwarte usługi, dostępy administracyjne, TLS, nagłówki bezpieczeństwa, aktualizacje
- Konfiguracja: komunikaty o błędach, dane diagnostyczne, konta z domyślnymi hasłami
- Lista ustaleń według ryzyka, z nakładem pracy dla każdego ustalenia
- Szybkie poprawki przed terminem testu, w zakresie uzgodnionym z Państwem po przeglądzie
Sprawdzamy jedną aplikację wraz z jej serwerami. W systemie produkcyjnym zmieniamy to, co Państwo zlecą. Przygotowanie nie zastępuje testu penetracyjnego: dzięki niemu test zajmuje się trudnymi pytaniami, a nie oczywistymi lukami.
Co zawiera wynik
Pisemna lista ustaleń według ryzyka z konkretnymi poprawkami, stan wykonanych poprawek i plan do terminu testu. Lista należy do Państwa. Po teście na życzenie usuwamy podatności wskazane w raporcie.
Pierwsza pomoc po włamaniu na stronę
Dla firm, których strona internetowa została zhakowana: Google ostrzega przed nią, odwiedzający trafiają na obce strony, w wynikach wyszukiwania pojawia się spam albo dostawca hostingu zablokował stronę.
- Odizolowanie strony i zabezpieczenie jej stanu, zanim cokolwiek zostanie usunięte
- Ustalenie drogi włamania: wtyczka, dane dostępowe, serwer lub kod
- Zamknięcie luki albo jej tymczasowe zabezpieczenie
- Oczyszczenie strony, w miarę możliwości z kopii zapasowej sprzed ataku
- Zmiana haseł, kluczy i dostępów
- Wniosek o ponowną weryfikację w Google, jeśli strona jest oznaczona jako niebezpieczna
24 godziny liczymy od uzyskania dostępu, także w weekend. Nie zawsze da się z pewnością ustalić, czy dane wyciekły; to, co ustalimy, opisujemy w raporcie. O tym, kiedy ostrzeżenie zniknie, decyduje Google. Dalsze prace po pierwszych 24 godzinach zaczynamy dopiero po Państwa zgodzie.
Co zawiera wynik
W ciągu 24 godzin od uzyskania dostępu odizolowana i oczyszczona strona oraz pisemny raport z technicznym przebiegiem zdarzenia i kolejnymi krokami zabezpieczenia. Raport należy do Państwa.
od 1 500 € netto
Zamów pierwszą pomocZ naszych projektów
-
Sklep zalewany przez boty, które udawały klientów
Sklep na WooCommerce z 52 produktami ładował się bardzo długo albo wcale. Przyczyną była opłacana sieć botów, która wysyłała dziesiątki tysięcy żądań na godzinę, każde z innego domowego adresu, a każdy bot z osobna zachowywał się wzorowo. Nasi inżynierowie zatrzymali ten ruch na brzegu sieci, a gdy miesiąc później boty zmieniły taktykę, druga reguła zdjęła obciążenie w dwie minuty.
Pytania o bezpieczeństwo aplikacji i stron
Czy wykonują Państwo także test penetracyjny?
Samego testu nie wykonujemy. Współpracujemy z każdą firmą wykonującą testy penetracyjne, którą wybiorą Państwo lub Państwa klient, a w razie potrzeby dobierzemy odpowiedniego partnera. Przygotowujemy aplikację i serwer do testu, a po nim na życzenie usuwamy podatności wskazane w raporcie.
Dzięki temu test pozostaje niezależny od tych, którzy rozwijają system i się nim opiekują.
Czy po przygotowaniu nasza aplikacja przejdzie test penetracyjny?
Tego nikt nie może zagwarantować. Przygotowanie usuwa oczywiste słabe punkty, na przykład przestarzałe biblioteki, otwarte dostępy administracyjne lub widoczne dane diagnostyczne. Znajdujemy zwłaszcza wstydliwe podatności, które łatwo przeoczyć w codziennej pracy, a które wyglądają na oczywiste, gdy wyjdą dopiero w teście penetracyjnym. Na życzenie wykonamy też z partnerem technologicznym próbny test penetracyjny przed właściwym audytem. Test może się wtedy skupić na trudnych pytaniach.
To, co test znajdzie mimo to, na życzenie usuwamy, a każdą poprawkę dokumentujemy na potrzeby ponownego testu.
Czy mogą Państwo usunąć podatności z istniejącego raportu z testu penetracyjnego?
Tak. Porządkujemy ustalenia według ryzyka, usuwamy podatności w kodzie i konfiguracji, na przykład cross-site scripting lub SQL injection, i sprawdzamy każdą poprawkę. Na potrzeby ponownego testu otrzymują Państwo listę tego, co i gdzie zostało zmienione.
Jeśli luki w kodzie nie da się zamknąć od razu, zabezpieczamy ją tymczasowo, na przykład regułą w WAF. Dotyczy to także starszych aplikacji w PHP, ColdFusion lub Lucee.
Czy WAF wystarczy?
Samodzielnie nie. WAF, czyli zapora aplikacji internetowych, filtruje typowe ataki przed aplikacją i daje czas, ale nie zamyka luki w kodzie. Dlatego łączymy go z usuwaniem znanych podatności, segmentacją sieci i dostępem administracyjnym wyłącznie przez VPN.
WAF z regułami dopasowanymi do Państwa aplikacji wywołuje mniej fałszywych alarmów i zwykle chroni skuteczniej niż konfiguracja domyślna. Jeśli kodu nie da się szybko zmienić, WAF z izolacją systemu jest rozwiązaniem pomostowym do czasu aktualizacji. Ryzyko maleje wtedy, ale nie znika.
Czy nie wystarczy po prostu przywrócić ostatniej kopii zapasowej?
Samo przywrócenie zwykle nie wystarcza. Luka, przez którą wszedł atakujący, jest także w kopii, a jeśli atak zaczął się wcześniej, niż się wydaje, kopia zawiera już złośliwy kod. Wtedy strona po krótkim czasie znów jest zainfekowana.
Dlatego najpierw ustalamy drogę włamania, potem przywracamy kopię sprzed ataku i zamykamy lukę, zanim strona znów będzie dostępna. Jeśli czystej kopii nie ma, oczyszczamy stronę bezpośrednio.
Czy czasem pełnią Państwo dyżury w weekendy?
Tak. Wsparcie i awarie obsługujemy całą dobę (24/7), także w weekendy. Prace planowane na weekend, na przykład przełączenie w oknie serwisowym, wykonujemy po uzgodnieniu. W pozostałych sprawach jesteśmy dostępni od poniedziałku do piątku od 9:00 do 17:00 czasu środkowoeuropejskiego, a na zapytania odpowiadamy w ciągu jednego dnia roboczego.
W 20 minut ustalimy, jaki pierwszy krok pasuje do Państwa systemu
Państwo opisują cel i obecny stan, my mówimy otwarcie, czy i jak możemy pomóc. Odpowiedź w ciągu jednego dnia roboczego, bez zobowiązań.
Telefon (niemiecki, polski, angielski)
+48 501 250 220
E-mail
E-mail
Dostępni: poniedziałek–piątek, 9:00–17:00 (czas środkowoeuropejski); wsparcie i awarie całą dobę (24/7)