Artykuły dotyczące tematu: serwer

dodany: 01.01.2013 | tagi: , , ,

Jak chronić się przed malware – poradnik dla użytkowników systemów Windows – cz. 5. Ochrona serwerów

1

Krok 4: Ochrona serwerów

 

W poprzednim rozdziale opisaliśmy zagadnienia obrony warstwy komputera klienckiego. Kolejny etap, to ochrona serwera. Strategia umocnień dla serwerów w organizacji ma wiele wspólnego z obroną zwykłych komputerów. Podstawową różnicą jest znacznie wyższy poziom oczekiwań jaki musi spełnić zarówno sam serwer, jak i jego obrona w zakresie niezawodności oraz wydajności.

Dodatkowo, serwery mogą odgrywać wyspecjalizowane role w infrastrukturze organizacji, co prowadzi często do szczególnych rozwiązań obronnych.

Informacje zawarte w tym rozdziale koncentrują się na podstawowych różnicach między obroną serwera, a omawianej wcześniej strategii ochrony komputerów klienckich. Etap ten obejmuje następujące zadania:

1. Utwardzanie serwerów.

2. Instalacja oprogramowania antymalware dla serwerów.

3. Realizacja konkretnych konfiguracji w zależności od specyfiki wykorzystywanych w firmie aplikacji albo roli pełnionej przez serwer.

 

Zadanie 1: Utwardzanie serwerów

Proces minimalizacji możliwości ataku na serwer jest często określany mianem utwardzania (z ang. hardening). Można w tym celu wykorzystać narzędzie Compliance Manager Microsoft Security, zapewniające możliwość scentralizowanego zarządzania oraz dostosowania systemu operacyjnego serwera do pełnionych przez niego ról.

Cztery podstawowe kroki ku obronie serwerów przed malware są identyczne jak w przypadku komputerów klienckich:

1. Ograniczenie możliwości ataku. W celu zminimalizowania możliwości ataku należy usunąć z serwera wszelkie niepotrzebne usługi i aplikacje.

2. Aktualizacja zabezpieczeń. Zapewnienie na wszystkich serwerach możliwości systematycznych, bieżących aktualizacji oprogramowania. Należy wykonać testy sprawdzające czy aktualizacje nie będą miały negatywnego wpływu na działanie krytycznych serwerów.

3. Ustawienie firewalla. Windows Server 2008 zawiera firewall, który może być stosowany również dla obrony serwerów organizacji.

4. Testowanie podatności na ataki. Można skorzystać z Microsoft Baseline Security Analyzer (w skr. MBSA) w systemie Windows Server 2003, który pomaga w identyfikacji potencjalnych luk w konfiguracji serwera. Aby zapewnić jak najsolidniejszą konfigurację, najlepiej użyć kilku różnych, specjalistycznych skanerów.

 

Zadanie 2: Instalacja oprogramowania AV dla serwerów

Podstawową różnicą między aplikacjami przeznaczonymi dla komputerów klienckich oraz tych dla serwerów jest poziom integracji między skanerem opartym o serwer a wszelkimi usługami serwerowymi, takimi jak powiadamianie czy obsługiwanie bazy danych. Inne, znaczące zalety oprogramowania antymalware dla serwerów obejmują specjalistyczną ochronę poszczególnych ról lub usług, solidniejsze zabezpieczenia, mogące sprostać zapotrzebowaniu na jednoczesną obsługę wielu siników skanujących oraz scentralizowaną administrację. Wiele serwerowych programów AV pozwala na zdalne zarządzanie, co wpływa na zminimalizowanie potrzeby fizycznej konsoli serwera.

Inne ważne kwestie, które należy wziąć pod uwagę przy ocenie przydatności specjalnego, serwerowego oprogramowania antymalware, to:

Moc procesora (w skr. CPU) serwera, który będzie odpowiedzialny za skanowanie. Przepustowość procesora jest krytycznym elementem zdolności serwera do wykonywania jego podstawowej roli w organizacji.

Niezawodność aplikacji. Awaria systemu na serwerze ważnym dla centrum danych ma znacznie większe skutki niż awaria jednej stacji roboczej. Dlatego, by upewnić się o niezawodności systemu, ważne jest dokładne przetestowanie wszystkich serwerów, na których działa oprogramowanie antymalware.

Zarządzanie ogólne. Umiejętne stosowanie oprogramowania AV może pomóc w redukcji administracyjnych kosztów zarządzania serwerami w organizacji.

Współdziałanie aplikacji. Należy przetestować działanie aplikacji AV oraz usług serwera, by wyeliminować ewentualne problemy interoperacyjne.

Narzędziem pomocnym do konfiguracji oprogramowania serwerowego może być Microsoft Forefront. Zawiera ono zestaw rozwiązań, dostosowanych do konkretnych produktów Microsoftu, w tym Exchange Server, Microsoft Lync i SharePoint. Na przykład, Forefront Protection 2010 for Exchange Server przeznaczony jest do ochrony informacji przekazywanych przez pocztę elektroniczną, a Forefront Endpoint Protection 2010 chroni systemy operacyjne hostów.

 

Zadanie 3: Realizacja konkretnych konfiguracji w zależności od specyfiki wykorzystywanych w firmie aplikacji albo roli pełnionej przez serwer

Istnieje szereg możliwych konfiguracji, narzędzi i aplikacji, które można dostosować do określonych ról pełnionych przez serwer. Przykładowe role serwera, do których dopasować można wyspecjalizowane oprogramowanie AV:

Active Directory Domain Services (w skr. AD DS) – usługa katalogowa (hierarchiczna baza danych) dla systemów Windows.

Protokół Dynamicznego Konfigurowania Węzłów (z ang. Dynamic Host Configuration Protocol, w skr. DHCP Services) – protokół komunikacyjny umożliwiający komputerom uzyskanie od serwera danych konfiguracyjnych, np. adresu IP hosta, adresu IP bramy sieciowej, adresu serwera DNS, maski podsieci.

System Nazw Domenowych (z ang. Domain Name System, w skr. DNS Services) – protokół komunikacyjny oraz usługa zapewniająca zamianę adresów znanych użytkownikom Internetu na adresy zrozumiałe dla urządzeń tworzących sieć komputerową.

Obsługa plików.

Obsługa drukarek.

Active Directory Certificate Services (w skr. AD CS) – technologia bezpiecznego zrządzania certyfikatami kluczy publicznych.

Obsługa sieci (z ang. Network Policy and Access Services, w skr. NPAS) – kontrola uprawnień dostępu etc.

Remote Desktop Services – protokół pozwalający na komunikację z usługą Terminala Graficznego w Microsoft Windows (z ang. Terminal Services).

Obsługa sieci.

Hipernadzorca (z ang. hypervisior) narzędzie niezbędne w procesie wirtualizacji – kontroli działania systemu. W systemie Windows Server 2008 R2 już jako wbudowane narzędzie Hyper-V.

Istnieje także wiele specjalistycznych rozwiązań dla różnorodnych aplikacji serwerowych, np.:

Messaging Servers – w Windowsie jako Microsoft Exchange 2010 i Microsoft Lync – aplikacje umożliwiające komunikację pomiędzy programami.

Serwery Baz Danych – umożliwia Microsoft SQL Server 2008 R2.

Serwery Pracy Grupowej – umożliwia Microsoft SharePoint 2010.

Specjalistyczne rozwiązania zapewniają lepsza ochronę przed malware oraz większą wydajność. Poniżej bardziej szczegółowe omówienie ról serwerów wraz z odpowiednimi zaleceniami konfiguracyjnymi, narzędziami czy aplikacjami.

 

Serwery WWW

We wszystkich typach organizacji serwery WWW od dawna stanowią cel ataków. Czy są to ataki malware, czy hakerskie próby podmiany witryny, ważne jest, żeby możliwie maksymalnie kompleksowo skonfigurować wszelkie zabezpieczenia.

Istnieje kilka darmowych narzędzi, które można wykorzystać do szeregu konfiguracji zabezpieczeń na Internet Information Services (w skr. IIS), takich jak IIS Lockdown. Narzędzie to służy do konfiguracji serwera WWW tak, aby zapewnić mu ochronę tych usług, które przypisane są jego roli.

UrlScan jest kolejnym narzędziem bezpieczeństwa, ograniczającym typy żądań HTTP używanych przez usługi IIS. UrlScan pomaga serwerowi uniknąć potencjalnie szkodliwych żądań poprzez blokowanie określonych żądań HTTP.

 

Messaging Servers

Przy projektowaniu skutecznej obrony przed malware dla serwerów poczty elektronicznej i komunikatorów należy pamiętać o dwóch, podstawowych celach. Pierwszym celem jest ochrona samych serwerów. Drugim celem jest uniemożliwienie złośliwemu oprogramowaniu przebicia się do skrzynek pocztowych pracowników organizacji przez e-maile lub komunikatory internetowe (z ang. Instant Messenger, w skr. IM). Ważne jest, aby nasze rozwiązanie spełniło te oba cele.

Ogólnie, standardowe skanowanie plików w celu wychwycenia malware nie jest w stanie zapobiec przychodzeniu złośliwego oprogramowania na serwer w postaci załącznika wiadomości. Wszystkie aplikacje, z wyjątkiem najbardziej prostych klientów poczty elektronicznej, przechowują pliki w bazie danych (zwanej magazynem wiadomości). Typowy skaner antymalware nie może uzyskać dostępu do zawartości takiej bazy danych.

Ważne jest więc dopasowanie oprogramowania AV do naszego rozwiązania serwerowego. Wielu producentów takiego oprogramowania zapewnia dedykowane wersje dla określonych serwerów pocztowych, przeznaczone do skanowania poczty e-mail.

Dostępne są trzy podstawowe typy rozwiązań antymalware dla serwerów poczty elektronicznej:

Rozwiązanie hostowe. Rozwiązanie to jest częścią pakietu, który oferuje także, m.in., usługi antyspamowe i antyphishingowe. Ochrona odbywa się za pomocą hosta pośredniczącego. Przysłane do nas wiadomości docierają najpierw na host dostawcy usługi, tam zostają „przebadane”, a następnie trafiają w miejsce przeznaczenia, czyli do nas. Tym samym szkodliwe oprogramowanie zostaje wyeliminowane jeszcze zanim dotrze do naszego systemu. Takim narzędziem jest np. Forefront Online Protection for Exchange, które zapewnia również szereg innych usług możliwych do dostosowania do własnych potrzeb. W Internecie znaleźć można wiele podobnych usług.

Bramowe skanery SMTP (ang. Simple Mail Transfer Protocol, w skr. SMTP) – rozwiązania oparte na skanowaniu poczty, określane są zazwyczaj jako „brama”. Mają one tę zaletę, że działają z wszystkimi usługami poczty SMTP, a nie są związane z konkretnym serwerem e-mail. Jednak rozwiązania te ograniczone są w niektórych bardziej zaawansowanych funkcjach, ze względu na ich uzależnienie od protokołu SMTP.

Zintegrowane skanery serwera. To wyspecjalizowane aplikacje, pracujące bezpośrednio z konkretnymi produktami serwerów e-mail. Aplikacje te dają wiele korzyści. Na przykład, można je zintegrować bezpośrednio z zaawansowanymi funkcjami serwera i są przeznaczone do stosowania na tym samym sprzęcie, co serwer pocztowy. Np. Forefront Protection 2010 for Exchange Server jest z założenia zintegrowanym rozwiązaniem, które zapewnia skanowanie poczty elektronicznej.

Microsoft Exchange posiada specjalny antywirusowy interfejs programowania aplikacji (w skr. API) o nazwie Virus API (w skr. VAPI), który jest również określany jako Antivirus API (w skr. AVAPI) czy Virus Scanning API (w skr. VSAPI). Interfejs ten używany jest przez wyspecjalizowane aplikacje Exchange Server w celu zapewnienia pełnej, bezpiecznej oraz niezawodnej ochrony wiadomości na serwerach Exchange e-mail.

Istnieje również wiele zintegrowanych rozwiązań dla serwerów czatu. Np. Forefront Security for Office Communications Server zapewnia skanowanie w czasie rzeczywistym zawartości IM oraz transferowanych plików zanim dotrą one do odbiorcy. Używa do tego wielu silników skanowania od różnych dostawców.

 

Serwery Baz Danych

Dla Serwerów Baz Danych wyznaczyć można cztery główne elementy ochrony przed szkodliwym oprogramowaniem:

Host. Serwer lub serwery z systemem baz danych.

Usługi bazodanowe. Poszczególne aplikacje uruchomione na hoście, dostarczające usług bazy danych przez sieć.

Przechowywanie danych. Dane przechowywane w bazie danych.

Dane komunikacji. Połączenia i protokoły, które wykorzystywane są w komunikacji między hostem bazy danych a innymi hostami w sieci.

Ponieważ dane przechowywane wewnątrz bazy nie są bezpośrednio wykonywalne, uważa się, że bazy nie wymagają skanowania. Obecnie nie istnieją aplikacje przeznaczone specjalnie dla baz danych. Jednak przy konfiguracji oprogramowania AV nie można zapominać ani o bazach, ani o danych komunikacji.

Zagrożenia atakiem malware należy uwzględnić także podczas lokowania i konfiguracji hosta. Zgodnie z ogólną zasadą nie zaleca się umieszczania serwerów baz danych w sieci obwodowej organizacji zwłaszcza, jeśli na serwerach przechowywane są dane poufne. Jednakże, jeżeli serwer bazy danych musi znajdować się w sieci obwodowej, należy upewnić się, że jest on skonfigurowany tak, aby ryzyko infekcji złośliwym oprogramowaniem zostało zminimalizowane. Na stornie Microsoftu można znaleźć wytyczne na temat konfiguracji systemu dla SQL Server.

 

Serwery Pracy Grupowej

Już sama natura serwerów pracy grupowej, takich jak SharePoint 2010, czyni je podatnymi na malware. Gdy użytkownik kopiuje pliki z oraz na serwer, może wystawić serwery innych użytkowników na atak złośliwego oprogramowania. Zaleca się ochronę współpracujących w środowisku organizacji serwerów za pomocą aplikacji skanujących wszystkie pliki przychodzące i wychodzące z naszej bazy. Aby uzyskać więcej informacji, zobacz Forefront Protection 2010 dla Microsoft SharePoint.

 

Pytania końcowe

Aby upewnić się, że odpowiednio zidentyfikowaliśmy opisane w powyższym rozdziale potencjalne zagrożenia dla serwerów, należy odpowiedzieć na następujące pytania:

Jakie produkty ochrony serwerów przed malware polecają istotni dostawcy takiego oprogramowania? Niektóre programy serwerowe przeznaczone są do pracy na zwykłym serwerze, podczas gdy inne wymagają specjalnych rozwiązań.

Czy rozmieszczenie serwera i bazy danych jest zgodne z prawami i wymogami bezpieczeństwa? Organizacje mogą mieć potrzebę przechowywania niektórych typów danych i aplikacji w firmowej bazie danych.

Czy zostały uwzględnione wszystkie geopolityczne problemy? Na przykład, jeśli firma posiada odrębne działy IT może zajść konieczność odrębnego zorganizowania ich pracy.

Czy nie należy odizolować serwerów pełniących różne role? Korporacyjne zasady lub regulacje rządowe mogą wymagać wyodrębnienia osobnych serwerów do przechowywania niektórych rodzajów danych lub dla niektórych części organizacji.

Czy pracownicy organizacji posiadają odpowiednią wiedzę, niezbędną do obsługi oprogramowania AV? Większe oddziały mają tendencję do zatrudniania wyspecjalizowanych pracowników, natomiast w mniejszych środowiskach często takich osób brakuje.

Czy posiadany sprzęt spełni warunki wymagane do instalacji oprogramowania AV?

Czy sprzęt serwera, po uruchomieniu oprogramowania AV, zapewni odpowiednią ochronę bez utraty wydajności? Niektóre oprogramowanie antymalware może mieć różne wymagania co do systemu operacyjnego dla serwerów lub do podjęcia współpracy z innym oprogramowaniem AV.

Jaki harmonogram aktualizacji da najlepszą ochronę serwerów? Harmonogram należy dopasować do oczekiwań i możliwości biznesowych organizacji.

 

Wszystkie części poradnika:

Cz. 1. Jak chronić się przed malware – poradnik dla użytkowników systemów Windows

Cz. 2. Identyfikacja potencjalnych zagrożeń

Cz. 3. Ochrona sieci

Cz .4. Ochrona komputerów klienckich

Cz .5. Ochrona serwerów

Cz .6. Zagrożenia fizyczne

Cz .7. Edukacja i plan reakcji

dodany: 27.11.2012 | tagi: , ,

Pierwsze kroki z własnym serwerem – część 1

5

W życiu młodego adepta sztuki administracyjnej przychodzi taki czas, kiedy postanawia on wziąć na swe barki pełną odpowiedzialność za maszynę fizyczną lub wirtualną. Do jego obowiązków należy nie tylko instalacja i konfiguracja systemu i usług, ale także zabezpieczenie całości przed zagrożeniami wszelkiego rodzaju.

Żadna książka, żaden tutorial wideo nie zastąpią pracy na żywym organizmie. Oczywiście nie musi to być środowisko produkcyjne (a nawet nie powinno)… Cudowna niemalże technologia, jaką jest wirtualizacja, pozwala nam na uruchomienie świeżego systemu operacyjnego wewnątrz drugiego, już działającego. Rozwiązań wirtualizacyjnych jest wiele i jako że nie są one przedmiotem tego artykułu, to nie uzasadnimy polecenia konkretnego rozwiązania. Do najpopularniejszych rozwiązań zaliczamy VirtualBox, Hyper-V oraz XEN. Na początek polecamy korzystanie z VirtualBox (w wersji otwartoźródłowej lub dostarczanej przez firmę Oracle). Oprogramowanie pozwalające na wirtualizację systemów nazywamy hypervisorem, maszynę na której uruchomiony jest hypervisor nazwiemy sobie hostem, zaś maszyny wirtualne nazwiemy gośćmi. Hypervisor VirtualBox jest prosty w instalacji i obsłudze.

W pierwszej części niniejszego przewodnika* system operacyjny hosta oraz rodzaj hypervisora nie grają dla nas roli. Poruszymy podstawy zabezpieczania świeżo zainstalowanego systemu operacyjnego naszego serwera. Na system operacyjny dla naszego wirtualnego serwera wybraliśmy jedną z najpopularniejszych dystrybucji systemu Linux, używanej na serwerach na całym świecie: Debian GNU/Linux w 6 wersji stabilnej („Squeeze”). Jest to wersja już nieco leciwa i prawdopodobnie na początku lutego, podczas konferencji FOSDEM 2013, będzie miała miejsce premiera nowej, 7 stabilnej wersji o nazwie kodowej „Wheezy”. Świeżość jądra systemu i pakietów, które tworzą dystrybucję nie ma jednak dla nas również znaczenia – podstawy, które będziemy omawiać, dotyczą niemalże każdej dystrybucji i każdej wersji.

Zakładamy zatem, że system Debian GNU/Linux 6 jest już zainstalowany i uruchomiony. Zalecamy instalację czystego systemu, bez żadnych (poza serwerem SSH) dodatkowych usług, takich jak serwer www, serwer wydruku czy serwer plików. Z racji tego, że system-gość został zainstalowany na maszynie do której mamy osobisty dostęp (fizyczny, RDP lub przez konsolę), widzimy prawdopodobnie ekran zachęty do zalogowania:

W zależności od użytego hypervisora i nazwy serwera, na ekranie zachęty logowania mogą występować drobne różnice. Przede wszystkim różna będzie nazwa serwera (w naszym przypadku jest to s1).

Aby wykonywać czynności administracyjne, konieczne jest zalogowanie się na konto superużytkownika (administratora), czyli root. Podajemy zatem login root, zatwierdzamy i podajemy hasło ustalone podczas instalacji.

Po zalogowaniu konsola użytkownika root jest gotowa do użytku:

Zanim zabierzemy się do hakowania plików konfiguracyjnych, należy zastanowić się, co będziemy zabezpieczać oraz przed czym i przed kim chcemy się chronić. Dopiero kolejnym krokiem będzie odpowiedzieć na pytanie – „jak?”.

Idąc od zagrożeń najbardziej ogólnych do najbardziej szczegółowych, musimy sobie stworzyć pewną listę, która pomoże nam się zabezpieczyć na początkowym etapie konfiguracji serwera.

  1. Dostęp do portów – firewall.
  2. Dostęp do SSH – zapobieganie nieautoryzowanemu dostępowi, zapobieganie atakom, ograniczenie dostępu.
  3. Wykrywanie rootkitów – zapobieganie instalacji i uruchamiania niebezpiecznego kodu.

Firewall

Polecanym dla systemów z rodziny Linux firewallem jest na ogół IPTables. Dla początkujących potrafi on być jednak trudny w zrozumieniu i konfiguracji. Na szczęście dystrybucja Debian i jej pochodne, mają w swoich repozytoriach dostępną aplikację, która w prosty i intuicyjny sposób pozwala konfigurować IPTables. UFW – bo o nim mowa – to skrót od angielskiego Uncomplicated Firewall. Za pomocą prostych komend możemy określać reguły zapory i tryb jej działania.

Najpierw instalujemy UFW:

Po instalacji UFW jest nieaktywny. Zasada działania UFW jest bardzo prosta.  Domyślnie zapora blokuje cały ruch przychodzący (poza pewnymi wyjątkami, które mają ułatwiać życie początkującym administratorom i domowym użytkownikom).

Zanim uruchomimy zaporę, musimy zadbać o to, żeby port na którym działać ma usługa SSH, był dostępny po uruchomieniu zapory. Gdybyśmy tego nie zrobili, a łączylibyśmy się z serwerem zdalnie za pomocą SSH, okazałoby się, że straciliśmy dostęp do własnej maszyny…

Domyślny port SSH, to 22. Jednakże zaleca się, aby port domyślny zmienić na inny (ale nie taki, który koliduje z popularnymi usługami). Doświadczeni administratorzy mogą powiedzieć, że nie jest to specjalnie mocne zabezpieczenie, gdyż zdalny serwer można zeskanować w poszukiwaniu portów otwartych dla poszczególnych usług, ale zawsze jest to pewne zabezpieczenie przed mniej doświadczonymi atakującymi. W kolejnym punkcie będziemy rekonfigurować usługę SSH i określimy port, na jakim ma ona działać. Ja wybiorę port 22000.

Musimy zatem przygotować regułę zapory, która otworzy port 22000. Zasada tworzenia reguł w UFW jest następująca:

– jeśli chcemy otworzyć określony port

– jeżeli chcemy zamknąć port

– jeżeli chcemy usunąć regułę

– poza możliwością otwierania i zamykania samego portu, mamy także możliwość określenia protokołu; jeśli chcemy otworzyć port 22000 na protokole TCP

Ja otwieram port 22000 zarówno dla połączeń TCP, jak i UDP, tak więc wybieram pierwszą opcję.

Dodatkowo, trzymając się zasady „Security by obscurity” (bezpieczeństwo przez ukrywanie), chciałbym wyłączyć możliwość sprawdzania dostępności serwera przez ICMP (ping). W tym celu należy edytować plik /etc/ufw/before.rules (np. przy pomocy edytora vi).

– w pliku tym zmieniamy:

na (zamieniamy ACCEPT na DROP)

– na razie nie uruchamiamy zapory. Musimy bowiem zająć się konfiguracją SSH.

Secure Shell (SSH)

Pierwsza zasada bezpieczeństwa SSH mówi: nigdy nie loguj się jako root (chyba, że wiesz, jakie to może mieć konsekwencje i podejmujesz to ryzyko na własną odpowiedzialność).

My nie podejmujemy ryzyka. Będziemy logować się przez SSH jako użytkownik z ograniczonymi uprawnieniami. Tylko najpierw trzeba go stworzyć…

Użyjemy do tego adduser. W poniższym przykładzie websec to nazwa użytkownika, którego tworzymy. Nazwa ta jest oczywiście dowolna.

Podajemy istotne informacje (w tym hasło użytkownika) i nowy użytkownik systemu gotowy:

Zasada numer dwa bezpieczeństwa SSH mówi: hasło to za mało!

Uwierzytelnianie za pomocą hasła, to słaba metoda zabezpieczania się przed nieautoryzowanym dostępem do serwera. Na szczęście mamy możliwość skorzystania z  kluczy dostępu. Oznacza to, że zamiast podawać przy logowaniu hasło, będziemy musieli posiadać klucz prywatny dostępu do serwera. Na serwerze umieszczony zostanie klucz publiczny, który posłuży do uwierzytelnienia nas przy próbie dostępu do serwera. Dzięki temu dostęp do serwera będą miały tylko osoby posiadające klucze uwierzytelniające, których klucze publiczne dodane zostaną do kont użytkowników na serwerze. Dodatkowo klucz wzmocnić można hasłem, co sprawi, że otrzymamy uwierzytelnianie dwuetapowe.

Jeśli korzystacie z systemów z rodziny Windows, to niestety nie uświadczycie narzędzia zdolnego do generowania kluczy SSH wbudowanego w system operacyjny. Nie ma się jednak czym martwić. Z pomocą przychodzi chyba najpopularniejszy klient SSH dla użytkowników systemów Windows: PuTTY. Na stronie projektu znajdziemy generator kluczy: PuTTYgen. Program po prostu pobieramy i uruchamiamy.

Opcje zaznaczone domyślnie w pełni nas satysfakcjonują. Generujemy zatem parę kluczy:

W celu dodatkowego zabezpieczenia dostępu do SSH, podajemy frazę zabezpieczającą klucz (Key passphrase). Ewentualnie możemy także napisać komentarz do klucza (Key comment) – pozwoli to w łatwiejszy sposób identyfikować klucz.

Następnie zapisujemy parę kluczy (Save public key oraz Save private key) w bezpiecznym miejscu.

Do konfiguracji dostępu do naszego serwera potrzebna nam będzie zawartość pola wyświetlającego klucz publiczny w formacie przeznaczonym dla OpenSSH. W naszym przykładzie jest to:

Kopiujemy klucz wraz z komentarzem na jego końcu.

W terminalu logujemy się na konto utworzonego wcześniej użytkownika. Przy przelogowaniu administrator nie musi podawać hasła dla konta użytkownika (w poniższej komendzie zastępujemy websec swoją nazwą użytkownika):

Następnie przechodzimy do katalogu domowego użytkownika:

Kolejnym krokiem jest utworzenie ukrytego katalogu, który zawierać będzie pliki związane z użytkowaniem i konfiguracją usługi SSH dla tego użytkownika. Nazwa katalogu musi być identyczna z poniższym przykładem. Kolejne kroki to zmiana uprawnień innych użytkowników do katalogu, wejście do nowoutworzonego katalogu, stworzenie pliku z kluczami, które autoryzujemy do dostępu i wreszcie zmiana uprawnień innych użytkowników do tego pliku.

Ostatnim krokiem w konfiguracji dwuetapowego, bezpiecznego uwierzytelniania naszego użytkownika, jest wklejenie klucza publicznego do pliku ~/.ssh/authorized_keys. Możemy zrobić to przy pomocy dowolnego edytora. Pamiętajmy, by zapisać zmiany w pliku.

Przechodzimy do konfiguracji serwera SSH. Jedyny plik konfiguracyjny, który będziemy zmieniać w celu zabezpieczenia usługi SSH, to /etc/ssh/sshd_config. Otwieramy ten plik w ulubionym edytorze i wyszukujemy następujące parametry:

Port 22

Zmieniamy na:

Port 22000

Upewniamy się, czy poniższe parametry mają wartość yes. Jeśli jest inna (no), wtedy zmieniamy:

RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
StrictModes yes

Następnie upewniamy się, czy poniższe parametry mają wartość no. Jeśli jest inna (yes), wtedy zmieniamy:

PermitRootLogin no
PermitEmptyPasswords no

Jeżeli którykolwiek z powyższych parametrów rozpoczyna się od # (czyli jest zakomentowany), to usuwamy znak # z początku wiersza.

Zapisujemy zmiany w pliku i zamykamy edytor, a następnie restartujemy serwer SSH następującą komendą:

Teraz należy sprawdzić, czy nasze uwierzytelnianie działa. Użyjemy klienta SSH PuTTY:

Uzupełniamy dane sesji logowania według konfiguracji swojego serwera, a następnie w kategorii SSH/Auth podajemy klucz prywatny do logowania i nawiązujemy połączenie:

Podczas logowania zostaniemy poproszeni o frazę do klucza SSH. Uwierzytelnienie następuje na podstawie sprawdzenia frazy odblokowującej klucz i samego klucza. Powinniśmy zalogować się na naszym serwerze za pomocą SSH jako użytkownik, którego tworzyliśmy wcześniej. Aby zalogować się na konto administratora (root), wydajemy komendę:

i podajemy hasło administratora.

Firewall – uruchomienie

Komenda uruchamiającą firewall, to (jako root):

Ochrona przed rootkitami, backdoorami i exploitami lokalnymi

Oprogramowanie, czy skrypty, których używamy na serwerze, nie zawsze pochodzą z oficjalnych repozytoriów. To, co nie zostało sprawdzone przez osoby odpowiedzialne za repozytoria i przez społeczność zgromadzoną wokół nich, jest potencjalnym zagrożeniem. Musimy zatem uzbroić nasz serwer w narzędzie, które pomoże nam sprawdzić, czy nasz system nie jest zainfekowany przez jakiś rootkit czy backdoor oraz czy nie jest podatny na ataki za sprawą jakiejś luki w lokalnie zainstalowanych usługach. Narzędzie, które nam to wszystko umożliwi, dostępne jest w repozytoriach systemu Debian GNU/Linux i nazywa się rkhunter (rootkit hunter). Instalujemy:

Skanowanie systemu przez rkhuntera wywołujemy komendą:

Wynik skanowania systemu powinien być podobny do tego raportu. W raporcie mogą wystąpić jakieś ostrzeżenia (warning), ale należy spokojnie przeanalizować ostrzeżenie i nie wpadać w panikę. Ostrzeżenie nie musi oznaczać problemu.

* Jest to pierwsza część poradnika, który ma na celu wskazać dobre praktyki przy konfiguracji własnego serwera. W kolejnych częściach zajmiemy się innymi usługami i budowaniem polityki bezpieczeństwa.