Jak zbudować solidne środki bezpieczeństwa, aby chronić swoje serwery

Wprowadzenie

Podczas pracy nad infrastrukturą chmurową Twoim głównym celem jest upewnienie się, że aplikacje są w pełni operacyjne. Jednym z ważnych elementów procesu konfiguracji i wdrożenia jest wbudowanie skutecznych, dokładnych i solidnych środków bezpieczeństwa w aplikacje lub systemy, zanim zostaną one udostępnione publicznie. Zamiast wdrażać środki bezpieczeństwa wstecznie po wdrożeniu, ważne jest zapewnienie, aby w infrastrukturze była wbudowana bezpieczna konfiguracja bazowa.

Ten poradnik pomoże Ci w tym zakresie. Przedstawi on pewne praktyczne środki bezpieczeństwa, które można wdrożyć podczas konfiguracji i instalacji infrastruktury serwera. Choć nie jest to wyczerpująca lista protokołów bezpieczeństwa serwera, stanowi ona pomocny punkt wyjścia. W miarę pracy i lepszego zrozumienia specyficznych potrzeb swojego środowiska i aplikacji, możesz opracować dodatkowe środki bezpieczeństwa, aby rozbudować swoją bazę.

Klucze SSH (Secure Shell)

Podczas pracy z serwerem większość czasu spędzisz na pracy w połączeniu SSH z serwerem w sesji terminala. Klucze SSH (Secure Shell) zapewniają bezpieczniejszą metodę logowania do serwera niż logowanie oparte na hasłach. Do celów uwierzytelniania, przy użyciu kluczy SSH, przygotowywane są dwa klucze dostępu. Pierwszy to klucz tajny (prywatny), a drugi to publiczny klucz, który można udostępniać.

Uwierzytelnianie za pomocą klucza SSH musi zostać najpierw skonfigurowane. Odbywa się to poprzez umieszczenie klucza publicznego SSH w odpowiednim katalogu na serwerze. Gdy Twój klient połączy się początkowo z serwerem, zostaniesz poproszony o dowód posiadania klucza prywatnego. Odbywa się to poprzez wygenerowanie losowej wartości, która zostanie następnie wysłana do Twojego klienta SSH. Klient SSH z kolei użyje klucza prywatnego do zaszyfrowania odpowiedzi. Odpowiedź ta zostanie wysłana do serwera. Następnie serwer odszyfruje wiadomość od klienta za pomocą Twojego klucza publicznego. Jeśli losowa wartość zostanie odszyfrowana przez serwer, oznacza to, że klient posiada klucz prywatny. W takim przypadku uwierzytelnienie zostaje potwierdzone i można nawiązać połączenie z serwerem bez użycia hasła.

Zwiększanie bezpieczeństwa za pomocą kluczy SSH

Choć autoryzacja hasłem lub jakiekolwiek uwierzytelnianie za pomocą SSH jest całkowicie zaszyfrowane, złośliwi użytkownicy mogą próbować uzyskać dostęp do serwera. Szczególnie jeśli weszli w posiadanie publicznego adresu IP serwera. Poprzez wypróbowywanie każdej możliwej kombinacji klawiszy, współczesne komputery umożliwiają logowanie oparte na hasłach, co jest często próbą podejmowaną przez złośliwych użytkowników. Jeśli ktoś zautomatyzowałby te próby dostępu, możliwe jest systematyczne wypróbowywanie różnych kombinacji, aby w końcu trafić na poprawne hasło.

Dzięki wykorzystaniu szyfrowanego uwierzytelniania SSH nie ma potrzeby włączania haseł do logowania. Klucze SSH zazwyczaj zawierają ogromną liczbę kombinacji, które napastnik musiałby sprawdzić. Zmiejszona podatność wynika z faktu, że zwiększona liczba bitów zwielokrotnia potencjał różnych kombinacji potrzebnych do złamania szyfrowania. Przejście przez wszystkie możliwe kombinacje algorytmu klucza SSH byłoby zatem niezwykle czasochłonne. W związku z tym staje się to przedsięwzięciem niewartym czasu złośliwego napastnika. Dlatego szyfrowanie SSH jest zazwyczaj uważane za „nie do złamania”.

Wdrażanie kluczy SSH

Logowanie do dowolnego zdalnego serwera Linux powinno odbywać się przy użyciu kluczy SSH. Klucz można wygenerować na lokalnej maszynie, a klucz publiczny przesłać na serwer w ciągu kilku minut. Dzięki temu poradnikowi dowiesz się, jak używać SSH do łączenia się ze zdalnym serwerem w Ubuntu. Możesz również skorzystać z naszego szczegółowego poradnika, jak skonfigurować serwer Linux do korzystania z uwierzytelniania opartego na kluczach SSH.

Ogólnie rzecz biorąc, uniemożliwienie użytkownikowi root bezpośredniego logowania przez SSH jest powszechnie stosowaną dobrą praktyką, podczas gdy logowanie się jako użytkownik nieuprzywilejowany i korzystanie z narzędzia takiego jak sudo w celu podniesienia uprawnień w razie potrzeby jest zalecane. Jest to znane jako zasada najmniejszych uprawnień: metoda ograniczania uprawnień dostępu. Po zweryfikowaniu logowania na konto nieuprzywilejowane za pomocą SSH, logowanie roota można wyłączyć, ustawiając dyrektywę PermitRootLogin no w pliku /etc/ssh/sshd_config na serwerze. Następnie serwer można zrestartować za pomocą polecenia procesu SSH sudo systemctl restart sshd.

Zapory sieciowe

Oprogramowanie (lub urządzenie sprzętowe), które reguluje udostępnianie usług w sieci, znane jest jako zapora sieciowa. Optymalnie skonfigurowana zapora sieciowa zapewnia, że tylko dozwolone usługi są dostępne publicznie oraz dopuszczone do ruchu przychodzącego i wychodzącego z danego serwera.

Domyślnie na serwerze może działać kilka usług, które można podzielić na następujące grupy:

• Usługi wewnętrzne: Dostęp do nich powinien być możliwy wyłącznie wewnętrznie z samego serwera. Zapobiega to wystawieniu usług na publiczny dostęp z Internetu (np. baza danych dostępna tylko poprzez połączenia lokalne).
• Usługi publiczne: Usługi, do których dostęp może uzyskać każdy, często anonimowo, w Internecie. Obejmują one serwery WWW, które umożliwiają odwiedzającym dostęp do Twojej witryny.
• Usługi prywatne: Tylko autoryzowane konta z wyłącznego zestawu lokalizacji mogą uzyskać dostęp do tych usług (np. panel kontrolny bazy danych phpMyAdmin).

Podczas gdy usługi publiczne mogą pozostać dostępne z Internetu, usługi prywatne mogą być ograniczone na podstawie parametrów dostępu (takich jak typy połączeń), a usługi wewnętrzne są całkowicie odcięte od jakiegokolwiek dostępu internetowego. Dostęp do tych usług, wraz ze szczegółowością, z jaką jest dozwolony, jest w pełni kontrolowany przez zaporę sieciową. Nieużywane porty są zwykle konfigurowane tak, aby całkowicie blokować do nich dostęp.

Zwiększenie bezpieczeństwa dzięki zastosowaniu zapory sieciowej

Zapora sieciowa stanowi podstawę ochrony serwera. Służy do ograniczania połączeń do i z usług, zanim aplikacja obsłuży ruch. Oczywiście możesz wdrożyć dodatkowe funkcje bezpieczeństwa dla swoich usług i ograniczyć je do pożądanych interfejsów.

Tylko te usługi, które zdecydujesz się pozostawić otwarte, nie będą ograniczane przez odpowiednio skonfigurowaną zaporę sieciową. Ogranicza to elementy podatne na ataki, ponieważ dostępne oprogramowanie jest znacznie bardziej ograniczone, a co za tym idzie, mniej narażone na atak.

Wdrażanie zapór sieciowych

Dla systemów Linux dostępnych jest wiele zapór sieciowych. Niektóre z nich są dość skomplikowane. Jednak typowa konfiguracja zapory sieciowej powinna być wykonywana tylko podczas wstępnej konfiguracji serwera, gdy wdrażane są zmiany w usługach serwera. Powinno to zająć tylko kilka minut. Poniżej przedstawiono kilka opcji do rozważenia w celu skonfigurowania i aktywowania zapory sieciowej:

• W przypadku systemu CentOS możesz postępować zgodnie z naszym przewodnikiem Konfiguracja zapory sieciowej za pomocą FirewallD w systemie CentOS 7.
• Nasz przewodnik po Iptables może przeprowadzić Cię przez proces wyświetlania i usuwania reguł zapory Iptables.

Co najważniejsze, niezależnie od samouczka, musisz upewnić się, że wybrana zapora sieciowa blokuje nieznany ruch do Twoich serwerów, aby zapobiec niezamierzonemu wystawieniu nowo udostępnionych usług w Internecie. Konieczność jawnego autoryzowania dostępu zmusi Cię do pełnej oceny sposobu uzyskiwania dostępu do usługi, jej uruchamiania oraz tego, kto ma do niej dostęp.

Sieci Virtual Private Cloud (VPC)

Zasoby Twojej infrastruktury’ muszą działać wewnątrz sieci prywatnej znanej jako VPC. Sieci te są bezpieczniejsze, ponieważ uniemożliwiają dostęp z innych sieci VPC opartych na chmurze. Tym samym sprawiają, że interfejsy sieciowe są niedostępne z publicznego Internetu.

Zwiększanie bezpieczeństwa dzięki sieciom VPC

Sieci prywatne są preferowane w stosunku do ich publicznych odpowiedników sieciowych w przypadku komunikacji wewnętrznej. VPC pozwala na izolację grup zasobów w określonych sieciach prywatnych. Ponieważ sieci VPC komunikują się wyłącznie za pośrednictwem połączeń prywatnych, ruch w sieci jest chroniony przed ujawnieniem w publicznym internecie, gdzie informacje te mogłyby być podatne na przechwycenie lub ujawnienie. Sieci VPC mogą być również używane do izolowania środowisk wykonawczych, a także dzierżawców. Bramy internetowe mogą być również skonfigurowane jako pojedynczy punkt dostępu między publicznym internetem a zasobami w sieci VPC.

Ponadto duża część bezpieczeństwa wiąże się z analizowaniem naszych systemów i zabezpieczaniem wszystkich komponentów najlepiej jak potrafimy. Audyt usług pozwala nam poznać akceptowalne protokoły systemów, uruchomione usługi oraz porty wykorzystywane do komunikacji. Znajomość tych informacji może pomóc w podejmowaniu najlepszych decyzji dotyczących konfiguracji. Decyzje te mogą dotyczyć ustawień zapory sieciowej, monitorowania systemu i alertów oraz tego, które usługi powinny być dostępne publicznie.

Wykorzystanie audytu do zwiększenia bezpieczeństwa

Każda usługa może być wykorzystywana do obsługi klientów zewnętrznych lub do celów wewnętrznych. Niezależnie od intencji, wszystkie te usługi stanowią punkty podatności dla złośliwych użytkowników. Wraz ze wzrostem liczby uruchomionych usług rośnie również potencjał wykorzystania podatności.

Możesz rozpocząć analizę usług, gdy tylko dobrze zrozumiesz, jakie usługi są uruchomione na maszynie. Podczas przeprowadzania audytu usług warto zadać następujące pytania:

• Czy dana usługa powinna być aktywnie uruchomiona?
• Czy działa na optymalnych interfejsach sieciowych?
• Czy usługa jest najlepiej dostosowana do publicznego, czy prywatnego interfejsu sieciowego?
• Czy reguły zapory sieciowej są poprawnie skonfigurowane, aby zezwalać na uprawniony ruch do tej usługi?
• Czy nieuprawniony ruch jest blokowany przez moje reguły zapory sieciowej?
• Czy włączony jest system alertów o lukach w zabezpieczeniach?

Podczas dodawania nowego serwera do infrastruktury powyższe kwestie powinny być standardowymi praktykami w procesie jego konfiguracji. Dodatkową korzyścią z audytów usług jest to, że pozwalają one zidentyfikować wszelkie konfiguracje, które uległy niezamierzonej zmianie.

Przeprowadzanie audytów usług

Aby przeprowadzić audyt uruchomionych usług, użyj polecenia ss, aby wyświetlić listę wszystkich portów UDP i TCP aktywnie używanych na serwerze. Oto przykład użycia polecenia ss z nazwą programu PID, sprawdzającego nasłuchujące porty TCP i UDP:

Zostanie zwrócone coś podobnego do poniższego:

Powinieneś skupić się głównie na kolumnach Netid, Local Address:Port oraz Process:

• Jeśli wartość Local Address:Port to 0.0.0.0, oznacza to, że usługa aktywnie akceptuje wszystkie połączenia na wszystkich interfejsach sieciowych IPv4. Jeśli adres to [::], wówczas wszystkie połączenia IPv6 akceptują ruch.
• W powyższym przykładzie zarówno Nginx, jak i SSH nasłuchują na wszystkich interfejsach publicznych w obu stosach sieciowych (IPv4 i IPv6).

W oparciu o powyższy przykład możesz zdecydować, czy chcesz zezwolić SSH i Nginx na nasłuchiwanie na obu interfejsach, czy tylko na jednym z nich. Ogólnie rzecz biorąc, warto wyłączyć wszelkie nieużywane usługi, aby zapobiec ich uruchamianiu. Na przykład, jeśli Twoja witryna powinna być dostępna tylko przez IPv4, pomocne byłoby wyłączenie interfejsów IPv6, aby ograniczyć ekspozycję.

Utrzymywanie aktualności dzięki aktualizacjom bez nadzoru

Aktualizacje bez nadzoru zmniejszają nakład pracy wymagany do utrzymania bezpieczeństwa serwerów i pomagają skrócić czas, w którym pozostają one narażone na znane błędy. Im dłużej zwlekasz z uruchomieniem aktualizacji na serwerze, tym dłużej pozostaje on narażony na znane podatności. Aktualizacje bez nadzoru zapewnią, że gdy tylko pojawią się pakiety poprawek, zostaną one automatycznie zainstalowane na serwerze, aby ograniczyć czas podatności na zagrożenia.

Oprócz audytu serwerów, aktualizacje bez nadzoru mogą znacznie zmniejszyć narażenie na ataki. Pozwolą one również znacznie skrócić czas spędzany na konserwacji serwerów.

Jak aktywowane są aktualizacje nienadzorowane

Aktualizacje nienadzorowane są obecnie opcjonalną funkcją w większości dystrybucji serwerowych. Na przykład w systemie Ubuntu administrator może uruchomić następujące polecenie:

Aby uzyskać dodatkowe informacje na temat wdrażania aktualizacji nienadzorowanych, zapoznaj się z sekcją Aktualizacje automatyczne tutaj. Dla systemu Fedora instrukcje można znaleźć tutaj. Należy pamiętać, że automatyczne aktualizacje zainstalują tylko to oprogramowanie, które zostało pierwotnie zainstalowane za pośrednictwem systemowego menedżera pakietów. Wszelkie dodatkowe aplikacje, np. aplikacje internetowe, będą musiały być sprawdzane pod kątem aktualizacji ręcznie lub indywidualnie skonfigurowane do automatycznych aktualizacji.

Indeksowanie katalogów

Gdy w katalogu brakuje pliku indeksu, większość serwerów jest domyślnie skonfigurowana tak, aby wyświetlać zawartość katalogu. Innymi słowy, jeśli na serwerze WWW zostanie utworzony katalog o nazwie „downloads”, każdy, kto go przegląda, będzie mógł zobaczyć wszystkie znajdujące się w nim pliki. Choć nie zawsze stanowi to zagrożenie dla bezpieczeństwa, sprawia, że poufne informacje stają się widoczne dla osób nieupoważnionych. Jako przykład rozważmy sytuację, w której serwer WWW może zawierać plik z danymi dostępowymi do strony głównej witryny oraz plik z całą konfiguracją bazy danych zaplecza witryny. Jeśli indeksowanie katalogów nie zostanie wyłączone, pliki te będą widoczne dla każdego, kto przegląda ten katalog.

Zwiększanie bezpieczeństwa poprzez wyłączenie indeksowania katalogów

Mimo że indeksowanie katalogów jest przydatne, może prowadzić do niezamierzonego ujawnienia plików. Aby ograniczyć takie niezamierzone ujawnienie i wszelkie powiązane z nim ryzyka, indeksowanie katalogów na serwerze powinno być domyślnie wyłączone. Choć odwiedzający nadal mogą uzyskać dostęp do plików, ryzyko niezamierzonego przeglądania danych jest znacznie ograniczone.

Wyłączanie indeksowania katalogów

W większości przypadków dodanie tylko jednej linii do konfiguracji serwera WWW wystarczy, aby wyłączyć indeksowanie katalogów.

• Postępuj zgodnie z tymi krokami, aby wyłączyć listowanie katalogów na Apache Wiki. Upewnij się, że opcja Options -Indexes znajduje się w blokach konfiguracyjnych Apache Directory.
• W serwerze Nginx indeksowanie jest domyślnie wyłączone, co nie wymaga żadnych dalszych działań w tym zakresie.

Częste kopie zapasowe

Choć kopie zapasowe nie są środkiem bezpieczeństwa, są one niezbędne do ochrony danych i całych systemów w przypadku naruszenia bezpieczeństwa systemu. Pomagają również przeanalizować, w jaki sposób system mógł zostać zaatakowany. Rozważmy niefortunny scenariusz, w którym Twój system zostaje zaatakowany przez oprogramowanie ransomware (wirus lub złośliwe oprogramowanie, które szyfruje pliki w systemie i odszyfrowuje je tylko wtedy, gdy zapłacisz hakerowi pieniądze). Jeśli nie ma kopii zapasowych danych, jedynym wyborem jest zapłacenie pieniędzy, aby odzyskać dostęp do swoich danych. Jeśli dane są bezpiecznie zapisane w kopii zapasowej, nadal będziesz mieć do nich dostęp i będziesz w stanie je odzyskać bez konieczności uzyskiwania dostępu do zainfekowanego systemu.

Zwiększenie bezpieczeństwa dzięki częstym kopiom zapasowym

Częste kopie zapasowe pomagają odzyskać informacje w przypadku ataku, uszkodzenia lub nawet niezamierzonej utraty (usunięcia). Bez względu na to, jaki rodzaj negatywnych zdarzeń prowadzi do utraty danych, ryzyko jest zmniejszane dzięki przechowywaniu kopii danych serwera.

Oprócz ataków ransomware, częste kopie zapasowe mogą pomóc w wymiernym badaniu długotrwałych ataków na system. Jeśli nie przechowujesz bezpiecznie swoich danych w formie kopii zapasowej, ustalenie źródła ataku oraz tego, które dane zostały naruszone, może być trudne lub wręcz niemożliwe.

Wdrażanie częstych kopii zapasowych

Nadrzędnym celem podczas tworzenia kopii zapasowych systemów powinno być traktowanie weryfikowalnego odzyskiwania uszkodzonych, naruszonych lub usuniętych danych jako priorytetu. Aby to najlepiej zobrazować, zastanów się, jakie działania wymagałyby najmniejszego nakładu pracy, aby przywrócić system do działania, gdyby Twój serwer zniknął jutro.

Oto kilka innych kwestii, które należy wziąć pod uwagę, myśląc o planie awaryjnym (disaster recovery):

• Jeśli pracujesz na dynamicznie zmieniających się danych, Twoje kopie zapasowe prawdopodobnie będą musiały być wykonywane częściej. W przypadku utraty danych, jeśli ostatnia kopia zapasowa została wykonana zbyt dawno temu, możesz być zmuszony do powrotu do nieaktualnych danych.
• Pomyśl o rzeczywistym procesie przywracania kopii zapasowej. Czy konieczne będzie dodanie nowego serwera, czy też można przywrócić istniejący?
• Jaki jest najdłuższy okres czasu, w którym serwer może być nieaktywny?
• Czy kopia zapasowa offsite jest koniecznym rozwiązaniem?

Aby dowiedzieć się więcej o rozwiązaniach Disaster Recovery od CloudSigma, zapoznaj się z naszym wpisem na blogu szczegółowo opisującym dlaczego nasza usługa Disaster-Recovery-as-a-Service jest idealnym dopełnieniem chmury. A tutaj możesz dowiedzieć się więcej o funkcjach bezpieczeństwa & ciągłości działania CloudSigma. Mamy również szczegółowy przewodnik na temat tego, jak łatwo skonfigurować funkcję kopii zapasowej CloudSigma.

Prywatne sieci i VPN

Sieć prywatna to sieć, która jest dostępna i używana wyłącznie przez określonych użytkowników lub serwery. Bezpieczne połączenie między zdalnymi urządzeniami, które umożliwia działanie połączenia tak, jakby znajdowało się w sieci prywatnej, to VPN (wirtualna sieć prywatna). Zapewnia ona możliwość zabezpieczenia połączeń w sieci prywatnej oraz łączenia zdalnych serwerów.

Jak sieci prywatne zwiększają bezpieczeństwo?

Gdy istnieje wybór między użyciem sieci publicznej a prywatnej do komunikacji wewnętrznej, ta druga jest zawsze preferowaną opcją. Należy jednak pamiętać, że inni użytkownicy z tego samego centrum danych nadal mogą mieć dostęp do tej samej sieci. Oznacza to, że nadal należy stosować dodatkowe środki bezpieczeństwa, aby zapewnić bezpieczną komunikację między serwerami.

W zasadzie korzystanie z VPN to sposób na określenie, co mogą widzieć pracownicy Twojej organizacji. Korespondencja będzie całkowicie bezpieczna i prywatna. Konfiguracje aplikacji pozwalałyby na przesyłanie ruchu z interfejsu wirtualnego przez VPN. Dzięki temu tylko te usługi, które są przeznaczone do interakcji z klientem przez Internet, będą mogły być wystawione na działanie sieci publicznej.

Jak trudne jest wdrożenie VPN?

Wykorzystanie sieci prywatnych w centrum danych jest tak samo proste, jak skonfigurowanie aplikacji i zapory sieciowej do korzystania z sieci prywatnej oraz włączenie VPN podczas tworzenia serwera. Ważne jest, aby pamiętać, że inne serwery współdzielą tę samą przestrzeń sieciową, co sieci prywatne obejmujące całe centrum.

Początkowa konfiguracja VPN jest nieco bardziej skomplikowana. Jednak dodatkowe bezpieczeństwo, jakie to zapewnia, jest opłacalne w większości przypadków użycia. Dane konfiguracyjne i wspólne zabezpieczenia muszą zostać zainstalowane i skonfigurowane na każdym serwerze w sieci. Aby uzyskać bardziej szczegółowe informacje na temat tego, jak działa VPN oraz omówienie konfiguracji OpenVPN na Ubuntu, skorzystaj z tego przewodnika. Możesz również skorzystać z tego samouczka, który przeprowadzi Cię przez kroki mające na celu połączenie sieci VPN z infrastrukturą CloudSigma.

Szyfrowanie SSL/TLS i infrastruktura klucza publicznego

Generowanie, zarządzanie i walidacja certyfikatów w celu identyfikacji osób oraz szyfrowanie komunikacji są określane jako infrastruktura klucza publicznego (PKI). Różne podmioty mogą uwierzytelniać się nawzajem za pomocą certyfikatów SSL lub TLS certyfikatów. Następnie mogą być one również używane do ustanawiania szyfrowanej komunikacji.

Jak certyfikaty zwiększają bezpieczeństwo

Aby szyfrować ruch i weryfikować tożsamość członków na serwerze, kluczowe jest ustanowienie urzędu certyfikacji (CA) i możliwość wglądu we wszystkie certyfikaty sieciowe. Może to pomóc w zapobieganiu atakom typu „man-in-the-middle”, w których serwer jest imitowany przez hakera, a ruch jest przekierowywany.

Konfigurację każdego serwera można ustawić tak, aby ufał scentralizowanemu CA. Wszelkie kolejne podpisy certyfikatów mogą być wtedy domyślnie zaufane. Jeśli szyfrowanie SSL/TLS jest obsługiwane przez protokoły i aplikacje używane przez Twój serwer, możesz zabezpieczyć swój system bez narzutu związanego z tunelem VPN. Aby uzyskać więcej informacji, zapoznaj się z naszym samouczkiem dotyczącym automatyzacji odnawiania certyfikatów SSL LetsEncrypt dla Nginx.

Trudność wdrożenia

Skonfigurowanie urzędu certyfikacji, a następnie skonfigurowanie pozostałej części PKI może wymagać dużego początkowego nakładu pracy. Ponadto, gdy zachodzi potrzeba utworzenia, unieważnienia lub podpisania nowych certyfikatów, wymagany będzie dodatkowy nakład pracy administracyjnej.

Ponieważ większość infrastruktur musi się rozwijać, wdrożenie pełnoprawnego PKO jest najrozsądniejszym podejściem. Dopóki nie osiągniesz punktu, w którym PKI będzie warte dodatkowych kosztów administracyjnych, korzystanie z VPN do zabezpieczenia komponentów systemu może służyć jako odpowiedni środek tymczasowy.

Wykrywanie włamań do systemu i korzystanie z audytu plików

Audyt plików to proces służący do porównywania plików i ich atrybutów w systemie będącym w pełni bezpiecznym, dobrym stanie z plikami aktualnie znajdującymi się w systemie. Jest to dobra metoda na znalezienie i odizolowanie nieautoryzowanych zmian w systemie.

System IDS, system wykrywania włamań, odnosi się do oprogramowania monitorującego, które śledzi wszelkie nieautoryzowane działania w systemie. Zazwyczaj wykorzystuje ono metody audytu plików w celu wyszukiwania nieoczekiwanych zmian w systemie.

Zwiększenie bezpieczeństwa dzięki IDS/audytowi plików

Oprócz audytu na poziomie usług, przeprowadzanie audytów na poziomie plików jest niezbędne do zapewnienia bezpieczeństwa systemu. Może to być wykonywane za pomocą zautomatyzowanego procesu IDS lub okresowo przez administratora systemu.

Audyty plików i IDS to jedyne rzeczywiste procesy pozwalające upewnić się, że w systemie nie doszło do żadnych nieoczekiwanych zmian. Większość intruzów chce eksploatować serwery, na które się włamią, przez dłuższy czas, a aby to zrobić, muszą zachować możliwość ukrywania swoich działań. Mogą oni zastąpić pliki binarne wersjami podatnymi na zagrożenia lub uszkodzonymi. Wszelkie pliki, które zostały zmodyfikowane w systemie, zostaną wykryte podczas audytu systemu plików. Daje to komfort szybkiego dowiedzenia się, czy integralność systemu została naruszona.

Poziom trudności wdrożenia

Wdrożenie IDS i audytu plików może być bardzo intensywnym procesem. Na początku system musi zostać skonfigurowany w celu zdefiniowania ścieżek do wykluczenia i ustalenia niestandardowych zmian, które zostały wprowadzone w systemie, aby stworzyć odczyt bazowy systemu.

Codzienne operacje stają się również bardziej uciążliwe, ponieważ procedury będą wymagały ponownego sprawdzenia systemu przed uruchomieniem jakichkolwiek aktualizacji. Stan bazowy pomiarów systemu będzie musiał również zostać odtworzony lub ponownie ustalony, aby uwzględnić zmiany wersji oprogramowania jako część nowego stanu bazowego systemu. Raporty z audytu będą również musiały zostać przeniesione do innej lokalizacji. Wynika to z faktu, że należy zapobiec modyfikowaniu audytu przez intruza w celu ukrycia swoich śladów.

Choć z pewnością zwiększa to obciążenie administracyjne systemu, jest to jeden z niewielu pewnych sposobów na upewnienie się, że żaden z plików nie został zmodyfikowany bez Twojej wiedzy. Jednymi z najpopularniejszych systemów wykrywania włamań i audytu plików są Aide oraz Tripwire.

Izolowane środowiska

Każda metoda, w której poszczególne komponenty są uruchamiane we własnej, dedykowanej przestrzeni, jest określana jako izolowane środowisko wykonawcze.

Może to oznaczać, że poszczególne komponenty aplikacji będą umieszczone na ich własnych, dedykowanych serwerach lub że usługi mogą być skonfigurowane do działania w środowiskach chroot (lub kontenerach). To, jak bardzo odizolowane jest środowisko, zależy głównie od realiów Twojej infrastruktury oraz wymagań aplikacji.

Zwiększanie bezpieczeństwa dzięki izolowanym środowiskom

Izolując procesy w poszczególnych środowiskach, izolujesz również te procesy, na które mogą wpłynąć luki w zabezpieczeniach. Podobnie jak przedziały i grodzie pomagają powstrzymać przecieki kadłuba na statkach, gdy rozdzielisz poszczególne części i komponenty systemu, jeśli intruz uzyska dostęp do jednego z nich, nie będzie w stanie przedostać się do całego połączonego systemu sieciowego.

Trudność wdrożenia

Złożoność izolacji aplikacji różni się w zależności od typów konteneryzacji, na które się zdecydujesz. Docker nie uważa izolacji za funkcję bezpieczeństwa. Jednak gdy komponenty są podzielone między różne kontenery, izolację osiąga się znacznie łatwiej. Możesz skorzystać z tego poradnika, aby zainstalować Docker na naszej infrastrukturze.

Gdy skonfigurowane są środowiska chroot, zapewniony jest również pewien stopień izolacji. Nie jest to jednak metoda całkowicie nie do przebicia, ponieważ istnieją sposoby na wyjście z takiego środowiska. Dedykowane maszyny dla różnych komponentów są zazwyczaj najlepszym i najprostszym sposobem na osiągnięcie izolacji. Jest to jednak bardziej kosztowne ze względu na konieczność posiadania dodatkowych maszyn.

Przemyślenia końcowe

Przedstawione strategie to tylko niektóre z kroków, które można podjąć w celu zwiększenia bezpieczeństwa systemu. Warto zauważyć, że im dłużej zwlekasz z wdrożeniem funkcji bezpieczeństwa, tym mniejsza staje się ich skuteczność. Mając to na uwadze, ważne jest, aby upewnić się, że z bezpieczeństwem nie należy czekać. Zamiast tego powinno ono zostać wdrożone jako jeden z pierwszych elementów budowy infrastruktury. Gdy system jest już wystarczająco bezpieczny dzięki podstawowym zabezpieczeniom, można zacząć aktywować usługi i dodawać aplikacje, wiedząc, że domyślnie działają one w bezpiecznym środowisku.

Bezpieczeństwo nie jest jednak procesem statycznym, lecz płynnym. Musi być stale utrzymywane i udoskonalane. Należy do niego podchodzić z nastawieniem na ciągłą świadomość i nieustanną czujność. Zawsze zadawaj sobie pytanie, jakie są konsekwencje dla bezpieczeństwa związane z jakąkolwiek zmianą w systemie. Upewnij się, że środowiska operacyjne i domyślne konfiguracje zawsze optymalizują bezpieczeństwo i współpracują z wystarczająco defensywnym oprogramowaniem.

Miłego korzystania z komputera!