Ataki na aplikacje

0

Typy ataków na aplikacje

Systemy operacyjne, sieci czy aplikacje są zazwyczaj bezpieczne kiedy są wdrożone zgodnie z zaleceniami twórcy. Ale kiedy zaczynamy zmniejszać poziom bezpieczeństwa na rzecz na przykład kompatybilności z innymi systemami tworzymy luki bezpieczeństwa. Omówię w skrócie popularne typy ataków na aplikacje.

Cross-Site Scripting and Forgery

Jeśli używamy języków skryptowych, takich jak JavaScript dajemy możliwość atakującemu oszukać użytkownika, który odwiedza stronę, aby kod wykonał się lokalnie po jego stronie. Właśnie to nazywamy tak popularnym cross-site scripting (XSS).  W tym ataku sprawca znajduje na stronie interaktywne miejsce, takie jak strona z komentarzami. W polu tekstowym zamieszcza swój kod JS i publikuje komentarz. Następnym razem, kiedy użytkownik odwiedza tę stronę skrypt wykonuje się. Metodą obrony przed XSS jest między innymi filtrowanie danych wejściowych. Cross-Site Request Forgery (XSRF) – czyli tak zwany one-click attack. Polega na wydawaniu nieautoryzowanych poleceń podchodzących od zaufanego użytkownika. Dla przykładu wyobraźmy sobie Anię i Pawła, którzy piszą ze sobą na czacie. Paweł wysyła Ani link ze śmiesznymi kotami. Ania otwiera go, co powoduje kradzież informacji bankowych z otwartej innej karty w przeglądarce. Paweł mógł wykraść te dane, ponieważ Ania jest zaufanym użytkownikiem jej banku. Aby mogło to się udać Ania musiałaby niedawno odwiedzić stronę banku i mieć ciasteczka, które jeszcze nie wygasły.

SQL Injection

SQL (Structured Query Language) jest to język służący do komunikacji z relacyjnymi bazami danych. Atak SQL Injection polega na manipulacji kodem bazy. Wyobraźmy sobie, że interfejs oczekuje, aby użytkownik wprowadził ciąg znaków. Atakujący zamiast tego może wprowadzić linię kodu, która się wykona zamiast zostać zaakceptowaną jako ciąg znaków. Obroną przed tym jest filtrowanie wartości wchodzących.

LDAP Injection

Tak samo jak SQL injection spowodowany jest brakiem filtrowania danych wejściowych. LDAP Injection wykorzystuje słabość w LDAP (Lightweight Directory Access Protocol). W rezultacie może spowodować wykonanie kodu pozwalając atakującemu zmienić, dodać bądź usunąć dane.

XML Injection

Atak podobny do SQL Injection. Polega na wprowadzeniu zapytania XML (znanym jako XPath), które jest exploitem. XPath działa w podobny sposób co SQL, z wyjątkiem tego, że nie ma takich samych poziomów kontroli dostępu.

Zero-Day Exploit

Znajdywana jest luka w oprogramowaniu zanim odkryje ją twórca. Występuje tego samego dnia, w którym została odkryta. Często, jedyną rzeczą, którą może zrobić administrator pomiędzy odkryciem exploitu a wydaniem patcha, jest wyłączyć usługi. Oczywiście jest to często kosztowne.

Ciasteczka

Ciasteczka są to pliki tekstowe, które przeglądarka przechowuje na dysku użytkownika. Ciasteczko zazwyczaj zawiera dane o użytkowniku. Na przykład przechowuje historię klienta. Jeśli sklep, chce wiedzieć jakie zainteresowania ma kupujący i co przeglądał na stronie sklepu może zamieścić te informacje w ciasteczku. Następnym razem, kiedy użytkownik wejdzie na stronę, serwer odczyta zawartość ciasteczka i wyświetli produkty spersonalizowane, które mają większe szanse zainteresować kupującego. Oczywiście ciasteczka są źródłem zagrożenia, ponieważ zawierają informacje osobiste. Typ ciasteczka zwany evercookie zapisuje dane w wielu lokalizacjach, aby uniemożliwić całkowite usunięcie. Jeśli bezpieczeństwo ma najwyższy priorytet powinieneś wyłączyć akceptowanie ciasteczek. Prawie każda przeglądarka oferuje możliwość wyłączenia, bądź włączenia ciasteczek.

Locally Shared Objects

LSO znany jest również jako Flash Cookie i jest to nic innego jak dane przechowywane na komputerze użytkownika przez Adobe Flash. Stwarza podobne ryzyko co wykorzystywanie ciasteczek.

Session Hijacking

Kradzież sesji następuje kiedy sesja autoryzowanego użytkownika, na przykład poprzez kradzież ciasteczka jest używana do ustanowienia sesji z hostem, który myśli, że wciąż komunikuje się z pierwszą osobą. Przejęcia sesji można dokonać na przykład poprzez atak man-in-the-middle.

Buffer Overflow

Występuje wtedy, kiedy aplikacja otrzymuje więcej danych niż jest zaprojektowana, aby akceptować. Taka sytuacja powoduje, że aplikacja zamazuje dane, bądź zapisuje je po zakończeniu przydzielonej przestrzeni. Spowodować to może utratę danych, zawieszenie programu, bądź wykonanie szkodliwego kodu.

Integer Overflow

Tak samo jak Buffer Overflow dotyczy umieszczania zbyt dużej ilości informacji w zbyt małej przestrzeni. W tym przypadku jest to przestrzeń zarezerwowana dla liczb. Na przykład 8 bitów umożliwia nam zapisanie liczby w systemie binarnym (dwójkowym) od 0 do 255. Jeśli ustawione jest tylko 8 bitów, a użytkownik wprowadzi wartość 256, przekracza to co może być przechowywane. Powoduje to przepełnienie pamięci.

Arbitary Code, Remote Code Execution

Programista może stworzyć program, który zdalnie przyjmuje komendy i je wykonuje. Komendy te nie muszą być powiązane ze stworzonym programem, który je obsługuje a z całą maszyną, shellem czy interpreterem komand. Błąd najczęściej wykonywany jest przez przejęcie kontroli nad wskaźnikiem instrukcji programu, który wskazuje następną linie programu do przetworzenia. Poprzez zmianę wskaźnika instrukcji na kod atakującego pozwala to na wykonanie złośliwego kodu. Należy mieć na uwadze, że dużo większym zagrożeniem jest sytuacja, kiedy program uruchomiony jest z wysokimi uprawnieniami, niż z ograniczonymi.

Instalacja serwera TeamSpeak 3 – Linux Debian

4

Wstęp

Kiedy pracujemy nad jakimś projektem, bądź zależy nam na zgraniu drużyny w grze potrzebujemy jakiejś formy komunikacji głosowej. Umożliwi nam to wiele programów, jak na przykład Skype, ale pożera on duże ilości łącza i zasobów komputera. Z pomocą przychodzi nam TeamSpeak, który jest bardzo lekki i praktycznie nie zużywa naszego łącza. W tym poradniku pokażę Ci jak zainstalować i skonfigurować serwer głosowy Team Speak 3 na serwerze z systemem Debian.

Dostosowanie firewalla

Do prawidłowego działania serwera musimy odblokować następujące porty. Jeśli nie potrzebujemy pełnej funkcjonalności wystarczy jedynie odblokować port głosowy.
  • port głosowy (UDP wchodzący): 9987
  • port do przesyłu plików (TCP wchodzący): 30033
  • port serverquery (TCP wchodzący): 10011
  • port tsdns (TCP wchodzący): 41144
  • port weblist  (UDP wychodzący): 2011-2110 (pierwszy dostępny port w zasięgu)
Jeśli korzystamy z ufw port odblokujemy używając następującej komendy (odblokuje ona port głosowy)
ufw allow 9987/udp
Jeśli chcesz odblokować dany zakres portów skorzystaj z tej komendy
ufw allow 2011:2110/udp

Konto

Ze względów bezpieczeństwa należy stworzyć osobne konto, które będzie uruchamiało nasz serwer. Nie powinniśmy przydzielać mu żadnych wysokich uprawnień, a hasło musi być silne.
adduser ts3
Cały proces instalacyjny wykonujemy z poziomu konta ts3, więc zalogujmy się na nie
su ts3
Przechodzimy do katalogu domowego
cd /home/ts3/

TS3

Pobierzmy pliki instalacyjne z oficjalnej strony
http://www.teamspeak.com/downloads
Wchodzimy w zakładkę Server i wybieramy wersję na nasz serwer. Kopiujemy link i ściągamy archiwum.
wget http://dl.4players.de/ts/releases/3.0.13.4/teamspeak3-server_linux_amd64-3.0.13.4.tar.bz2
Wypakowujemy
tar -vxjf teamspeak3-server_linux_amd64-3.0.13.4.tar.bz2
Wchodzimy do folderu
cd teamspeak3-server_linux_amd64
Nadajemy uprawnienia wykonania dla właściciela
chmod +x ts3server_startscript.sh
Uruchamiamy
./ts3server_startscript.sh start
Zostały wygenerowane dane dostępowe. Aby zyskać uprawnienia administratora na serwerze należy wprowadzić token przy pierwszym połączeniu z serwerem. ts3

Klient

Uruchamiamy klienta TeamSpeak 3 i łączymy się z serwerem. Wyświetli nam się komunikat z prośbą o podanie tokena, który został wygenerowany przy pierwszym uruchomieniu serwera. Wprowadzamy go i zatwierdzamy. ts33 Posiadamy teraz pełne uprawnienia administracyjne i możemy zarządzać serwerem z poziomu klienta TS3  

Automatyczny start

Chcemy, aby po restarcie VPS nasz serwer głosowy automatycznie się uruchomił. Aby to zrobić otwórz plik rc.local
nano /etc/rc.local
Przed exit 0 dodajemy linijkę
su ts3 -c '/home/ts3/teamspeak3-server_linux_amd64/ts3server_startscript.sh start'
Należy pamiętać, aby zamiast ts3 wpisać swoją nazwę konta (jeśli podałeś inną) i ścieżkę, w którym znajduje się skrypt uruchamiający serwer. Ostatecznie plik ten powinien wyglądać tak
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
su ts3 -c '/home/ts3/teamspeak3-server_linux_amd64/ts3server_startscript.sh start'
exit 0
Po restarcie systemu operacyjnego serwer został prawidłowo uruchomiony przez użytkownika ts3.

Porównanie serwerów VPS

7

VPS

Virtual Private Server – podział serwera na kilka mniejszych, wirtualnych instancji. Jest on bardzo zbliżony do dedykowanej maszyny. W porównaniu do tradycyjnego hostingu jest on zdecydowanie wydajniejszy. Przewagą serwerów wirtualnych nad dedykowanymi jest możliwość szybkiej reinstalacji serwera, dostęp do konsoli w każdym momencie czy natychmiastowa zmiana parametrów maszyny na życzenie. Jeśli chcemy możemy dowolnie dostosować liczbę CPU, ilość pamięci RAM czy pojemność dysku. Serwery VPS, które testuje różnią się sposobem wirtualizacji.

Wirtualizacja

webh (KVM), smarthost, ovh i kylos korzystają z KVM, webh (OpenVZ) i hitme z OpenVZ, a Aruba z VMware. KVM  (Kernel-based Virtual Machine) jest to pełna wirtualizacja sprzętowa. Przy tym rodzaju wirtualizacji zasoby przydzielone do serwera są bardziej gwarantowane. W przypadku OpenVZ zasoby przydzielane są tylko wtedy, jeśli są wolne. Nie ogranicza nas Linux, możemy zainstalować dowolny system operacyjny. W przeciwieństwie do OpenVZ KVM pozwala na modyfikację kernela. Wspiera on także zaawansowane filtry sieciowe czy konfiguracje zapór ogniowych. Dużym plusem jest możliwość pełnego zaszyfrowania dysku. VMware i XEN tak jak KVM to wirtualizacja sprzętowa. OpenVZ opiera się na wirtualizacji OS-level, czyli VPS uruchamiane są w kontenerach. Oznacza to, że system operacyjny hosta jest dzielony na mniejsze kawałki, które mają przydzielone odpowiednie zasoby. W przypadku OpenVZ mamy dwa rodzaje przydzielonych zasobów, dedykowane (dedicated) i tymczasowe (burst). Dedykowane są gwarantowane dostępne w ramach wykupionego pakietu. Zasoby burst są przydzielane czasowo, jeśli są jakieś wolne. Pozwala to naszemu serwerowi tymczasowo pożyczyć zasoby takie jak RAM z innego VPS. Na serwerze z OpenVZ możemy uruchomić jedynie dystrybucje Linuksa.

Parametry

tiktalik (pro):

  • XEN
  • 1 rdzeń Intel Xeon CPU E3-1230 V2 @ 1000MHz
  • 1 GB pamięci RAM
  • 10 GB powierzchni SSD
  • 2TB / miesięcznie
  • 60,22zł / miesięcznie

tiktalik (standard_8zł):

  • XEN
  • 2 rdzenie Intel Xeon CPU @ 1000vMHz
  • 1 GB pamięci RAM
  • 20 GB powierzchni HDD
  • 2TB / miesięcznie
  • 7,38zł / miesięcznie

tiktalik (standard_36zł):

  • XEN
  • 2 rdzenie Intel Xeon CPU @ 4000vMHz
  • 4 GB pamięci RAM
  • 20 GB powierzchni HDD
  • 2TB / miesięcznie
  • 36,90zł / miesięcznie

webh (KVM):

  • KVM
  • 2 rdzenie Intel Xeon E5 @ 2.6GHz
  • 4 GB pamięci RAM
  • 40 GB powierzchni SSD
  • nielimitowany transfer danych
  • 49 zł / miesięcznie

webh (OpenVZ)

  • Standard
  • OpenVZ
  • 3 rdzenie Intel Xeon E5-2643v2 @ 3.5GHz
  • 4 GB pamięci RAM
  • 20 GB powierzchni SSD
  • nielimitowany transfer danych
  • 34 zł / miesięcznie

hitme:

  • DA-SSD2
  • OpenVZ
  • 2 rdzenie Intel Xeon E5-2670 @ 2.60GHz
  • 2 GB pamięci RAM
  • 60 GB powierzchni SSD
  • nielimitowany transfer danych
  • 89,99 zł / miesięcznie

smarthost:

  • SSD-25
  • KVM
  • 2 rdzenie Intel Xeon X3450  @ 2.67GHz
  • 2 GB pamięci RAM
  • 25 GB powierzchni SSD
  • nielimitowany transfer danych
  • 59 zł / miesięcznie

aruba:

  • VPS Small
  • VMware
  • 1 rdzeń Intel Xeon E5-2650Lv3 @ 1.8GHz
  • 1 GB pamięci RAM
  • 20 GB powierzchni SSD
  • 2TB / miesięcznie
  • 4 zł / miesięcznie

kylos:

  • VPS Silver
  • KVM
  • 1 rdzeń Intel Xeon E3v5 @ 1.7GHz
  • 1 GB pamięci RAM
  • 50 GB powierzchni SSD
  • 3000GB / miesięcznie
  • 79 zł / miesięcznie

ovh

  • VPS SSD 2
  • KVM
  • 1 rdzeń Intel Xeon E5v3 @ 2.4GHz
  • 4 GB pamięci RAM
  • 20 GB powierzchni SSD
  • nielimitowany transfer danych
  • 29,51 zł / miesięcznie

CPU

[mniej = lepiej]
sysbench --test=cpu --cpu-max-prime=20000 --num-threads=1 run
  • kylos: 21.0192s
  • webh (OpenVZ): 24.3710s
  • smarthost: 25.3498s
  • webh (KVM): 26.2768s
  • ovh: 29.0653s
  • hitme: 29.3021s
  • tiktalik (standard_36zł): 30.5099s
  • aruba: 39.9583s
  • tiktalik (pro): 44.1337s
  • tiktalik (standard_8zł): 64.2910s
sysbench --test=cpu --cpu-max-prime=20000 --num-threads=2 run
  • webh (OpenVZ): 12.3077s
  • smarthost: 12.5634s
  • hitme: 14.6648s
  • webh (KVM): 14.9077s
  • tiktalik (standard_36zł): 15.8003s
  • kylos: 21.2054s
  • ovh: 27.4712s
  • aruba:  40.2040s
  • tiktalik (pro): 43.7827s
  • tiktalik (standard_8zł): 68.7461s
dd if=/dev/zero bs=1M count=1024 | md5sum
[więcej = lepiej]
  • kylos: 603 MB/s
  • webh (OpenVZ): 1.90854 s, 563 MB/s
  • ovh: 2.51195 s, 427 MB/s
  • webh (KVM):2.56297 s, 419 MB/s
  • hitme: 2.58041 s, 416 MB/s
  • smarthost: 2,63702 s, 407 MB/s
  • tiktalik (standard_36zł): 3.21451 s, 334 MB/s
  • aruba:  3.56838 s, 301 MB/s
  • tiktalik (pro): 4.3379 s, 248 MB/s
  • tiktalik (standard_8zł):  8.47003 s, 127 MB/s

RAM

[mniej = lepiej]
sysbench --test=memory --memory-total-size=1G run
  • webh (OpenVZ): 0.3276s
  • kylos: 0.3622s
  • hitme: 0.3822s
  • webh (KVM): 0.4467s
  • aruba: 0.5144s
  • ovh: 0.5912s
  • smarthost: 0.6377s
  • tiktalik (standard_36zł): 3.1073s
  • tiktalik (pro): 4.2074s
  • tiktalik (standard_8zł): 6.8215s

Geekbench

[więcej = lepiej]
  • webh (OpenVZ)
    Single-Core Score Multi-Core Score
    3356 7522
  • kylos
    Single-Core Score Multi-Core Score
    4105 3965
  • hitme
    Single-Core Score Multi-Core Score
    2663 4625
  • webh (KVM)
    Single-Core Score Multi-Core Score
    2207 4061
  • aruba
    Single-Core Score Multi-Core Score
    2285 2199
  • smarthost
    Single-Core Score Multi-Core Score
    2232 3499
  • ovh
    Single-Core Score Multi-Core Score
    3204 3019
  • tiktalik (standard_36zł)
    Single-Core Score Multi-Core Score
    1867 3261
  • tiktalik (pro)
    Single-Core Score Multi-Core Score
    2179 1959
  • tiktalik (standard_8zł)
    Single-Core Score Multi-Core Score
    1003 857

Łącze

[więcej= lepiej]

aruba

aruba_speedtest

aruba_lacze

webh (kvm)

webh_speedtest

webh_lacze  

webh (openVZ)

webhopen_speedtest webhopen_lacze  

smarthost

smarthost_laczze smarthost_speedtest

hitme

hitme_speedtest hitme_lacze

kylos

kylos_speedtest kylos_lacze

ovh

ovh_speedtest ovh_lacze

tiktalik (pro)

speedpro

tiktalik (standard_8zł)

speed8

tiktalik (standard_36zł)

speed36 Dysk [więcej= lepiej]
dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync 
  • webh (kvm): 1.0202 s, 1.1 GB/s
  • smarthost: 1,1392 s, 943 MB/s
  • aruba: 1.18678 s, 905 MB/s
  • kylos: 1.33039 s, 807 MB/s
  • webh (openvz): 1.78726 s, 601 MB/s
  • ovh: 2.58483 s, 415 MB/s
  • hitme: 3.30825 s, 325 MB/s
  • tiktalik (pro): 8.43552 s, 127 MB/s
  • tiktalik (standard_36zł): 61.237 s, 17.5 MB/s
  • tiktalik (standard_8zł): 61.913 s, 17.3 MB/s
dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
  • webh (kvm): 0.646442 s, 831 MB/s
  • kylos: 0.662196 s, 811 MB/s
  • aruba: 0.731374 s, 734 MB/s
  • webh (openvz): 0.842019 s, 638 MB/s
  • smarthost: 1,2588 s, 426 MB/s
  • hitme: 1.54114 s, 348 MB/s
  • ovh: 1.59858 s, 336 MB/s
  • tiktalik (pro): 7.73272 s, 69.4 MB/s
  • tiktalik (standard_36zł): 28.415 s, 18.9 MB/s
  • tiktalik (standard_8zł): 30.2917 s, 17.7 MB/s

webh (KVM)

weh_dysk2

aruba

aruba_dysk

kylos

kylos_dysk

webh (OpenVZ)

webhopen_dysk

smarthost

smarthost_dysk

hitme

hitme_dysk

ovh

ovh_dysk

tiktalik (pro)

dyskpro

tiktalik (standard_8zł)

dysk8

tiktalik (standard_36zł)

dysk36

Wydajność nginx

  • Requests per second [więcej = lepiej] 
  • Time per request [mniej = lepiej]
Na serwerach umieściłem 2 pliki, index.html i kot.jpg (2.1 MB) Konfiguracja nginx jest domyślna.
ab -kc 1000 -n 10000 http://serwer/index.html
ab -n 5000 -c 50 http://serwer/kot.jpg

Aruba

Plik html
  • Requests per second: 11185.64 [#/sec] (mean)
  • Time per request: 89.400 [ms] (mean)
Zdjęcie
  • Requests per second: 9.16 [#/sec] (mean)
  • Time per request: 5457.028 [ms] (mean)

Hitme

Plik html
  • Requests per second: 13719.08 [#/sec] (mean)
  • Time per request: 72.891 [ms] (mean)
Zdjęcie
  • Requests per second: 8.10 [#/sec] (mean)
  • Time per request: 6169.858 [ms] (mean)

Kylos

Plik html
  • Requests per second: 26361.23 [#/sec] (mean)
  • Time per request: 37.934 [ms] (mean)
Zdjęcie
  • Requests per second: 5.51 [#/sec] (mean)
  • Time per request: 9081.747 [ms] (mean)

Smarthost

Plik html
  • Requests per second: 17813.72 [#/sec] (mean)
  • Time per request: 56.136 [ms] (mean)
Zdjęcie
  • Requests per second: 40.26 [#/sec] (mean)
  • Time per request: 1241.962 [ms] (mean)

Webh (KVM)

Plik html
  • Requests per second: 7891.55 [#/sec] (mean)
  • Time per request: 126.718 [ms] (mean)
Zdjęcie
  • Requests per second: 230.93 [#/sec] (mean)
  • Time per request: 43.304 [ms] (mean)

Webh (OpenVZ)

Plik html
  • Requests per second: 4836.67 [#/sec] (mean)
  • Time per request: 206.754 [ms] (mean)
Zdjęcie
  • Requests per second: 3.62 [#/sec] (mean)
  • Time per request: 13816.858 [ms] (mean)

OVH

Plik html
  • Requests per second: 3747.40 [#/sec] (mean)
  • Time per request: 266.852 [ms] (mean)
Zdjęcie
  • Requests per second: 5.89 [#/sec] (mean)
  • Time per request: 8491.737 [ms] (mean)

Stabilność

W teście tym chciałem sprawdzić jak serwery radzą sobie pod 100% obciążeniem przez wiele godzin. Oto wykresy dla poszczególnych instancji:

webh (KVM):

webh_cpu

webh (OpenVZ):

webhopen_cpu

hitme:

hitme_cpu

smarthost:

smarthost_cpu

aruba:

aruba_cpu

kylos:

kylos_cpu

ovh:

ovh_stabilnosc

tiktalik:

tiktalik

Support

webh:

Bezproblemowy, szybki. Odpisywali w środku nocy po chwili. Bardzo miła, fachowa pomoc.  9/10

kylos:

Szybki czas aktywacji, profesjonalna obsługa techniczna, bardzo dobry czas oczekiwania na odpowiedź. 7/10

hitme:

Dobry czas oczekiwania na odpowiedź (poniżej 24h). Raz nawet zdarzyło się, że dostałem odpowiedź po 10 minutach. 7/10

smarthost:

Mała wpadka na początku (oczekiwanie na serwer dość długie, około 4 dni), ale wszystko zostało zrekompensowane przez ekspresowy support techniczny. Natychmiastowa odpowiedź i naprawienie problemu. 6/10

aruba:

Przeciętny.  4/10

ovh:

Bardzo długi czas oczekiwania na odpowiedź, powyżej tygodnia. Po aktywacji serwera wystąpiły problemy z kluczem SSH, ale po dwóch dniach otrzymałem szczegółowe informację jak naprawić problem (odpisali w sobotę w środku nocy) 4/10

Czas restartu

[mniej = lepiej] 
  • kylos:  8s
  • ovh: 9s
  • tiktalik (pro): 10s
  • smarthost: 13s
  • hitme: 16s
  • webh (openvz): 17s
  • webh (kvm): 35s
  • tiktalik (standard_36zł): 50s
  • tiktalik (standard_8zł): 1m3s
  • aruba:  3m16s

Panel

Od funkcjonalności panelu zarządzania serwerem zależy wiele. Po otwarciu rozwijalnego tekstu wciśnij poniżej nazwę firmy, aby zobaczyć pełne zdjęcie panelu.

[learn_more caption=”ovh”]

OVH

Zdecydowanie najładniejszy panel, bezproblemowe działanie. Na duży plus zasługuje dostęp do funkcji KVM, z której korzystamy w przypadku gdy nie możemy połączyć się z serwerem poprzez SSH (zablokowany port w firewallu) lub jeśli zajdzie potrzeba poprawienia konfiguracji. ovh_kvm Dostajemy możliwość zainstalowania aż 21 konfiguracji systemów operacyjnych, ale niestety nie możemy wgrać własnego obrazu ISO. ovh_systemy Drugi raz aktywowałem serwer za pomocą panelu Cloud.  [/learn_more] [learn_more caption=”hitme”]

hitme

Podstawowa, wystarczająca funkcjonalność. Konsola dostępna. Ogromna ilość dostępnych konfiguracji systemów operacyjnych.[/learn_more] [learn_more caption=”aruba”]

Aruba

Nie działa. Nic. Chciałem, próbowałem. Reinstalacja systemu operacyjnego kończy się całkowitą awarią. Cokolwiek zaczęło działać… po kilku godzinach. Włączenie konsoli przez panel mija się z celem.[/learn_more] [learn_more caption=”webh”] Przeciętnie wyglądający panel.

webh (kvm)

Do wyboru mamy 9 systemów operacyjnych, które możemy zmodyfikować 7 konfiguracjami. webh_panel_open2                          webh_panel3 Jeśli zdecydujemy się na KVM, będziemy mogli wgrać swój własny obraz systemu, co jest ogromną zaletą i czego nie oferuje nikt inny.

webh (openvz)

webh_panel_open2 W przypadku wersji OpenVZ możemy zainstalować 9 systemów w podstawowej wersji. [/learn_more] [learn_more caption=”kylos”]

Kylos

Bardzo rozbudowany, ładnie wyglądający panel. Dostępna konsola VNC, bardzo duża ilość systemów operacyjnych do wyboru (22). [/learn_more] [learn_more caption=”smarthost”]

smarthost

Mało intuicyjny, słabo wyglądający panel. [/learn_more] [learn_more caption=”tiktalik”]

Tiktalik

Ładny, funkcjonalny panel.  Najmniejszych problemów z obsługą samego panelu, czy też konsoli VNC. Minusem jest mały wybór systemów operacyjnych. systemyy [/learn_more]

Werdykt

Nie będzie go. Moją rolą było przetestowanie każdej z instancji i zaprezentowanie wyników. To Ty drogi czytelniku wybierzesz na jaką usługę się zdecydujesz bazując na danych, jakie tu przedstawiłem. Za wyjątkiem wydajności nginx, stabilności, panelu, łącza i testu geekbench dane zostały przedstawione w rankingu, od najlepszego wyniku do najgorszego.

Kody rabatowe

Specjalnie dla czytelników udostępniam kod rabatowy SHIN2016 uprawniający do zniżki: hitme.pl 30% na 1. płatność na dowolną usługę serwera VPS OpenVZ, Xen lub HVM (bez Windows) oraz na pakiety hostingu www. smarthost.pl pierwszy miesiąc dowolnego serwera VPS z 90% zniżką. webh.pl 50% rabatu na pierwszą dowolną płatność za VPS Linux, KVM (oprócz pakietu mini), Windows. Rabat ten łączy się z rabatem za płatność roczną. Wystarczy wprowadzić kod przy składaniu zamówienia, bądź wpisać go w uwagach.  

Instalacja certyfikatu Let’s Encrypt

0

W poprzednim wpisie skonfigurowaliśmy zestaw oprogramowania LEMP na serwerze. W tym poradniku zainstalujemy bezpłatny certyfikat SSL/TSL Let’s Encrypt i zabezpieczymy serwer www.

Let’s Encrypt

Certyfikat ten jest uznawany przez większość przeglądarek. Ważny jest on 90 dni, po tym okresie należy go odnowić. Certyfikat X.509 szyfruje połączenia pomiędzy serwerem, a klientem, co zapobiega podsłuchiwaniu. Korzystanie z rozwiązania Let’s Encrypt zwiększa bezpieczeństwo danych.  Dodatkowym atutem za wdrożeniem certyfikatu SSL jest lepsze pozycjonowanie w wyszukiwarkach takich jak Google.

Firewall

Jeśli korzystamy z UFW, bądź innego firewalla należy odblokować ruch na porcie 443.
ufw allow 'nginx https'

Certbot

Certbot musi stworzyć tymczasowe pliki, aby uwierzytelnić domenę. Aby mu to umożliwić musimy dodać lokalizację w naszym pliku znajdującym się w sites-enabled
nano /etc/nginx/sites-enabled/shintest
Dodajemy następujące linijki
location /.well-known/acme-challenge {
 root /var/www/letsencrypt;
}
Przeładowujemy konfigurację
service nginx reload
Tworzymy folder
mkdir /var/www/letsencrypt/
Instalujemy gita
apt-get install git
Klonujemy repozytorium
git clone https://github.com/certbot/certbot /opt/certbot
cd /opt/certbot/
Jeśli chcemy, aby certyfikat został wygenerowany dla domeny z www oraz bez www należy pamiętać, aby zawrzeć obie wersje, tak jak poniżej.
./letsencrypt-auto certonly -a webroot --webroot-path=/var/www/letsencrypt/ -d strona.pl -d www.strona.pl

Podajemy adres mail

mail

Akceptujemy warunki agree Certyfikat został poprawnie wygenerowany. congrats Widzimy ścieżkę do certyfikatu, którą należy wpisać później w odpowiednim miejscu w konfiguracji nginx.

Dostosowanie nginx

W poprzednim wpisie skonfigurowaliśmy nginx, aby serwował nam WordPressa. Teraz dostosujemy tamtą konfigurację. Otwórz plik konfiguracyjny znajdujący się w sites-enabled w folderze nginx.
nano /etc/nginx/sites-enabled/shintest
Powinien on wyglądać teraz tak:
server {
 listen 80;
 server_name naszadomena.pl www.naszadomena.pl;
 return 301 https://naszadomena.pl$request_uri;
}

server {
 listen 443;
 server_name naszadomena.pl;
 root /var/www/shintest/public;
 index index.php;
 access_log /var/www/shintest/logs/access.log;
 error_log /var/www/shintest/logs/error.log;

ssl on;
 ssl_certificate /etc/letsencrypt/live/naszadomena.pl/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/naszadomena.pl/privkey.pem;

location /.well-known/acme-challenge {
 root /var/www/letsencrypt;
}
location = /favicon.ico {
 log_not_found off;
 access_log off;
 }

location = /robots.txt {
 allow all;
 log_not_found off;
 access_log off;
 }

location / {
 try_files $uri $uri/ /index.php?$args;
 }

location ~ \.php$ {
 include fastcgi.conf;
 include fastcgi_params;
 fastcgi_pass unix:/var/run/php5-fpm.sock;
 fastcgi_intercept_errors on;
 fastcgi_index index.php;
 }
}
Po wejściu na nasza stronę powinniśmy zobaczyć przedrostek https zamiast http i zieloną kłódeczkę.

WordPress

W ustawieniach ogólnych wordpressa zmień adres URL na przedrostek https wordpress_ssl Przetestujmy domenę skanerem Qualys SSL Labs ssl_scan_2 Wynik nie jest zadowalający. Przeprowadźmy pewne modyfikacje naszej konfiguracji.

SSLv2 i SSLv3

Wyłączmy SSlv2 i SSLv3, ponieważ nie są to bezpieczne protokoły. Dodajemy więc linijkę do server block (plik znajdujący się w sites-enabled)
ssl_protocols TLSv1.2;
Jeśli zależy nam na wsparciu starszych klientów ustawiamy wsparcie dla starszej wersji protokołu TLS
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

HTTP2

Nginx będzie nasłuchiwał połączeń SSL na porcie 443 korzystając z nowego protokołu HTTP/2. Należy pamiętać, że musimy posiadać wersję serwera www co najmniej 1.9.5
listen 443 ssl http2;

Zestaw szyfrów

Nginx będzie korzystał z tych szyfrów zamiast tych, które będą żądane przez klienta.
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;

Cache

Umożliwi to wymianę cache pomiędzy wszystkimi procesami workerów. Jeden megabajt cache przechowuje około 4000 sesji. Domyślny timeout to 5 minut, który możemy zmienić korzystając z dyrektywy ssl_session_timeout
ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 10m;

OCSP Stapling

Po więcej informacji odsyłam tu i tu
ssl_trusted_certificate /etc/letsencrypt/live/naszadomena.pl/chain.pem;
ssl_stapling on;
ssl_stapling_verify on;

Nagłówki

Informuje on przeglądarkę, aby korzystała z HTTPS dla naszej domeny i wszystkich subdomen. UWAGA, należy upewnić się, ze skonfigurowaliśmy poprawnie wszystkie używane subdomeny. Połączenia korzystały będą z HTTPS przez rok, więc jeśli popełnimy błąd nasze strony będą niedostępne.
add_header Strict-Transport-Security "max-age=31557600; includeSubDomains";

Diffie Hellman Groups

Tworzymy folder
mkdir /etc/nginx/ssl
Generujemy protokół Diffiego-Hellmana
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096
Dodajemy linijkę do naszej konfiguracji
ssl_dhparam /etc/nginx/ssl/dhparam.pem;

A+

Ostatecznie nasza konfiguracja powinna wyglądać tak
server {
 listen 80;
 server_name naszadomena.pl www.naszadomena.pl;
 return 301 https://naszadomena.pl$request_uri;
}

server {
 listen 443;
 server_name naszadomena.pl;
 root /var/www/shintest/public;
 index index.php;
 access_log /var/www/shintest/logs/access.log;
 error_log /var/www/shintest/logs/error.log;

 ssl on;
 ssl_certificate /etc/letsencrypt/live/naszastrona.pl/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/naszastrona.pl/privkey.pem;
 ssl_session_timeout 5m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
 ssl_prefer_server_ciphers on;
 ssl_session_cache shared:SSL:10m;
 ssl_dhparam /etc/nginx/ssl/dhparam.pem;
 ssl_trusted_certificate /etc/letsencrypt/live/naszastrona.pl/chain.pem;
 ssl_stapling on;
 ssl_stapling_verify on;

 add_header Strict-Transport-Security "max-age=31557600; includeSubDomains";


location /.well-known/acme-challenge {
 root /var/www/letsencrypt;
}
location = /favicon.ico {
 log_not_found off;
 access_log off;
 }

location = /robots.txt {
 allow all;
 log_not_found off;
 access_log off;
 }

location / {
 try_files $uri $uri/ /index.php?$args;
 }

location ~ \.php$ {
 include fastcgi.conf;
 include fastcgi_params;
 fastcgi_pass unix:/var/run/php5-fpm.sock;
 fastcgi_intercept_errors on;
 fastcgi_index index.php;
 }
}
Oto wynik jaki teraz pokazuje Qualys SSL Labs ssl_scan_3

Autoodnawianie

Korzystając z crona zaplanujemy automatyczne odnawianie certyfikatu
crontab -e
Wklejamy te linijki na samym końcu
30 2 * * 1 /opt/letsencrypt/letsencrypt-auto renew >> /var/log/cert-renew.log
35 2 * * 1 /etc/init.d/nginx reload
 

Instalacja WordPress z LEMP na serwerze

0
LEMP (Linux, Nginx, MySQL, PHP) jest modyfikacją bardzo popularnego LAMP, czyli Linux, Apache, MySQL, PHP. Używany jest do tworzenia aplikacji internetowych. LEMP od LAMP różni się serwerem WWW – wystarczy wymienić Apache na lekki i wydajny nginx.
W tym poradniku zainstalujemy i skonfigurujemy LEMP stack na Debianie 8. Łączymy się przez SSH (używając terminala w linuxie, bądź programu putty w windowsie) z serwerem. Zacznijmy od zalogowania się na konto root (możemy również korzystać z konta, które może używać sudo, wtedy przed każdym poleceniem dodajemy sudo)
 su
Wykonujemy niezbędne aktualizacje
apt-get update && apt-get upgrade
 

nginx

Instalujemy:
apt-get install nginx
Po instalacji otwieramy przeglądarkę i wchodzimy na adres naszego serwera (używając adresu domeny, bądź IP). Powinna nam się ukazać strona powitalna: debian Przejdźmy do podstawowej konfiguracji, otwórz plik nginx.conf w dowolnym edytorze i w linijce worker_processes zmień wartość na liczbę CPU. Aby to sprawdzić w terminalu wpisz
lscpu
Bez tytułu
nano /etc/nginx/nginx.conf
W moim przypadku jest to 2, więc taką wartość wpisuje.
worker_processes 2;
Zmieńmy również wartość worker_connections, która domyślnie ustawiona jest na 768. Mówi ona ile osób jednocześnie może być obsłużonych. Należy pamiętać, że przeglądarki otwierają bardzo często więcej niż jedno połączenie. Dlatego zwiększmy wartość na maksymalną dostępną. Aby sprawdzić, jaką liczbę możemy ustawić w terminalu wpisz:
ulimit -n
W moim przypadku jest to 65536, więc taką wartość ustawiam.
worker_connections 65536;
Wychodzimy poprzez wciśnięcie CTRL + X, następnie Y i ENTER. Sprawdzamy czy wszystko działa.
nginx -t
Jeśli tak możemy przeładować konfigurację.
service nginx reload
Aby włączyć lub wyłączyć usługę wystarczy zamiast reload wpisać start bądź stop.  

MySQL

Po instalacji serwera WWW pora na system zarządzania bazą danych.
apt-get install mysql-server
Zostaniesz poproszony o ustawienie hasła konta root. Warto zmienić kilka niezbyt bezpiecznych ustawień domyślnych.
mysql_secure_installation

Zostaniemy poproszeni o wpisanie hasła, które wcześniej ustaliliśmy. Jeśli chcemy zmienić to hasło, możemy to zrobić. Pozostałe opcje zostawiamy domyślne. Logujemy się.
mysql -u root -p

Tworzymy bazę danych

CREATE DATABASE shintest;

Teraz stwórzmy oddzielne konto użytkownika i nadajmy mu odpowiednie uprawnienia:

GRANT ALL ON shintest.* TO 'testuser'@'localhost' IDENTIFIED BY 'sUp#rs1ln#h@sL0';

Ostatnie polecenie

FLUSH PRIVILEGES;
Wychodzimy
exit;

PHP

Została nam instalacja PHP.
apt-get install php5 php5-fpm php5-mysql php5-curl php5-gd php5-mcrypt php5-xmlrpc
Otwórz php.ini
nano /etc/php5/fpm/php.ini
Znajdź cgi.fix_pathinfo=1, usuń ; na początku linijki i zmień wartość z 1 na 0. Ostatecznie powinno to wyglądać tak:
cgi.fix_pathinfo=0
Resetujemy usługę
service php5-fpm restart

WordPress

Skasujmy domyślne server-blocks
rm /etc/nginx/sites-enabled/default /etc/nginx/sites-available/default
Stwórzmy nowy plik w folderze sites-enabled:
nano shintest
Wklejamy następującą konfigurację zmieniając odpowiednie wartości na swoje
server {
 listen 80;
 server_name naszadomena.pl;
 root /var/www/shintest/public;
 index index.php;
 access_log /var/www/shintest/logs/access.log;
 error_log /var/www/shintest/logs/error.log;


 location = /favicon.ico {
 log_not_found off;
 access_log off;
 }

location = /robots.txt {
 allow all;
 log_not_found off;
 access_log off;
 }

location / {
 try_files $uri $uri/ /index.php?$args;
 }

location ~ \.php$ {
 include fastcgi.conf;
 include fastcgi_params;
 fastcgi_pass unix:/var/run/php5-fpm.sock;
 fastcgi_intercept_errors on;
 fastcgi_index index.php;
 }
}

Jeśli chcemy, aby adres domeny był zarówno z www jak i bez www w linijce server name wpisujemy obie wartości

server_name naszadomena.pl www.naszadomena.pl;

Sprawdzamy konfigurację

nginx -t

Jeśli wszystko jest w porządku restartujemy nginx

service nginx restart

Pobieramy wordpressa

wget https://pl.wordpress.org/wordpress-4.5.3-pl_PL.zip

Wypakowujemy archiwum (może być konieczna instalacja programu unzip, jeśli go nie posiadasz)

apt-get install unzip
unzip wordpress-4.5.3-pl_PL.zip

Przenosimy pliki do folderu, który ustawiliśmy jako główny w konfiguracji nginx

cp -R wordpress/* /var/www/shintest/public/

Wchodzimy do katalogu, do którego skopiowaliśmy pliki wordpressa. Warto teraz przygotować plik konfiguracyjny.

mv wp-config-sample.php wp-config.php

nano wp-config.php

Wpisujemy teraz dane, które ustawiliśmy wcześniej konfigurując MySQL

define('DB_NAME', 'shintest');
define('DB_USER', testuser');
define('DB_PASSWORD', 'sUp#rs1ln#h@sL0');
Ustawiamy również klucze uwierzytelniające i sole. Wchodzimy na ten link i kopiujemy całość, a następnie wklejamy do pliku zastępując domyślne wartości. Zapisujemy i wychodzimy. Zmieniamy właściciela plików na www-data
chown -R www-data:www-data /var/www/shintest/
Wchodzimy teraz na adres naszej domeny, bądź IP i powinniśmy zobaczyć końcowy instalator wp

Wszystko gotowe.

Proste, prawda?

Strefa zdemilitaryzowana, czyli co to jest DMZ

0
Strefa zdemilitaryzowana (DMZ, demilitarized zone) to miejsce, gdzie umieszczamy serwery, do których dostęp będą mieli użytkownicy, którym nie do końca powinniśmy ufać. Poprzez izolację serwera w DMZ, możemy ukryć lub zablokować dostęp do reszty naszej sieci. Możemy wciąż mieć dostęp do serwera poprzez internet, ale nie jesteśmy w stanie uzyskać dostępu do zasobów pozostałych obszarów sieci.  Zapewnia to dodatkową warstwę bezpieczeństwa sieci wewnętrznej, uniemożliwiając dostęp intruzom do prywatnych danych. Każda usługa, która powinna być udostępniona użytkownikom zewnętrznym powinna być umieszczona w DMZ. Najczęściej są to serwery www. Strefa ta powinna zostać zabezpieczona, ponieważ wystawiona jest bezpośrednio na ataki hakerów. Kiedy chcemy oddzielić publiczne informacje od prywatnych DMZ nam to umożliwi. Najprostszym sposobem, aby stworzyć strefę zdemilitaryzowaną jest użyć firewalla, który dane będzie przesyłał w trzech kierunkach:
  1. do sieci wewnętrznej
  2. do sieci zewnętrznej
  3. do danych, które chcemy udostępnić
aFNLH Tutaj powinniśmy zdecydować jaki ruch gdzie trafia, na przykład ruch HTTP powinien zostać przekierowany do DMZ. Należy pamiętać, żeby nie trzymać danych prywatnych (np. dane firmowe) w DMZ. Wszystko o wartości dla nas, czy firmy powinno być trzymane w wydzielonej strefie prywatnej LAN. Firewall-DMZ-IDS Mamy tutaj przykładową infrastrukturę. Zastosowano tutaj wydzielone strefy DMZ i LAN, podwójny firewall, router brzegowy i odpowiednio systemy IDS. Powinniśmy stworzyć reguły dla ruchu pomiędzy DMZ, LAN a Internetem jak na przykład które porty czy usługi powinny być dozwolone. Ciekawa wydaje się opcja zastosowania Stateful Packet Inspection Firewall, który będzie dbał o bezpieczeństwo usług i użytkowników sieci wewnętrznej. Pozwoli on na ruch z sieci zewnętrznej do wewnętrznej tylko pod warunkiem, że będzie to na przykład odpowiedź na żądanie z sieci wewnętrznej.

Arcanus Framework

0
Arcanus jest to generator ładunków (payload generator), który póki co jest niewykrywalny przez prawie wszystkie antywirusy. Jest uniwersalny, działa na każdym systemie, może współpracować z Metasploitem – posiada moduł meterpretera do wykonywania kodów powłoki (shellcodes). Na początku musimy zainstalować golangfatih/color. Teraz zajmijmy się samym frameworkiem.
git clone https://github.com/EgeBalci/ARCANUS
 cd ARCANUS/SOURCE
 go build
 cd ..
 chmod 755 ARCANUS
 ./ARCANUS
arcanus_instalacja Wybieramy opcję drugą, następnie wpisujemy adres IP i port, na którym będziemy nasłuchiwać połączenia arcanus_konfig Po wygenerowaniu ładunku wysyłamy go ofierze. Ja uruchomię go w swojej wirtualnej maszynie z systemem Windows 7. Kiedy ofiara otworzy wysłany przez nas plik zobaczymy otwartą sesję w naszej konsoli. arcanus_udane Dodatkowe polecenia, które możemy wykonać znajdziemy na stronie twórcy

Testy penetracyjne

0
Test penetracyjny – proces pozwalający ocenić bieżący stan zabezpieczeń systemu. Test penetracyjny, popularnie nazywany pentestem, polega na identyfikacji, analizie i oszacowaniu ryzyka związanego z podatnościami i lukami zabezpieczeń. Jest to symulowany atak. Chodzi o to, aby sprawdzić czy luki są rzeczywistym zagrożeniem dla systemu. Dla przykładu wyobraźmy sobie, że po przeprowadzonym audycie aplikacji skan wykazał kilka luk bezpieczeństwa. Test penetracyjny w tym przypadku pozwoli określić czy stanowią one rzeczywisty powód do zmartwień i czy skaner nie wyrzucił zwykłych false positive. Pentest ma na celu przyjąć rolę włamywacza i jego technikami sprawdzić wszystkie błędy, a następnie określić stopień w jakim zagrażają systemowi czy aplikacji. Bardzo ważne jest staranne wyselekcjonowanie możliwych celów ataku, należy przełożyć jakość nad ilość. Sprawdzenie systemu skanerem podatności nie może dać jasnych wyników, odzwierciedlających rzeczywisty stan. Należy pamiętać, że sam fakt wykonania testu penetracyjnego nie oznacza realnego wzrostu bezpieczeństwa. Po przedstawieniu wyników należy wdrożyć zalecenia i rekomendacje, aby załatać błędy. Nie powinno się przeprowadzać pentestu w systemach, które nie posiadają systemów podnoszących bezpieczeństwo, ponieważ nie przyniesie to wymiernych korzyści. Pierw należy zaimplementować odpowiednie zabezpieczenia, a dopiero później je sprawdzić.  Testy penetracyjne powinno się przeprowadzać kiedy osoba odpowiedzialna za system jest przekonana o jego zabezpieczeniach.

Metodologia

Początkowym etapem jest ustalenie zakresu prac i metod przeprowadzania testu penetracyjnego. Wyróżniamy trzy możliwe metody:
  • white-box – osoba przeprowadzająca pentest posiada pełną dokumentację systemu bądź aplikacji. Najczęściej test ten ma na celu sprawdzenie czy system spełnia określone procedury bezpieczeństwa, bądź normy. Metoda ta zajmuje najmniej czasu i jest najtańsza. Przeprowadzany jest on przy pełnej wiedzy zespołu i zarządu.
  • black-box – pentester (osoba przeprowadzająca testy penetracyjne) nie wie nic o systemie, o dostępnych usługach ani infrastrukturze. Jest to najbardziej czasochłonna i kosztowna metoda. Wymaga od pentestera ogromnej wiedzy i umiejętności przełamywania zabezpieczeń. Przeznacza on największy okres czasu na fazę rekonesansu.
  • grey-box – połączenie metod białego pudełka i czarnego. W tym przypadku otrzymujemy część informacji o celu. Nie zawsze jest to pełna dokumentacja, ale często są to bardzo cenne wskazówki.

Fazy

Pre-engagement Interactions

Faza wstępna czyli kontakt ze zleceniodawcą mający na celu ustalenie szczegółów testu penetracyjnego. Na tym etapie ustala się sposób przeprowadzania testów, narzędzia jakich pentester będzie mógł użyć, zakres, które systemy podlegają analizie. Należy ustalić, które systemy nie powinny być testowane ze względu na ich wrażliwość. Ważne jest ustalenie, w którym momencie test się kończy.

Intelligence Gathering

Zbieranie informacji na temat celu ataku. W tej fazie wykorzystujemy biały wywiad, czyli szukamy dostępnych informacji na portalach społecznościowych, korzystamy ze skanerów portów, footprintingu, Gooogle hackingu. Staramy się dowiedzieć jakie usługi są uruchomione, które porty są otwarte. Powinniśmy poznać listę dostępnych hostów, jakie aplikacje są uruchomione itd. Im więcej informacji zbierzmy tym większe szanse na wejście do systemu.

Threat Modeling

W fazie modelowania zagrożeń wykorzystujemy dane, które zgromadziliśmy w poprzedniej fazie. Przyjmujemy pozycję atakującego i staramy się myśleć jak on. Opracowujemy strategię w taki sam sposób, jaki zrobiłby to intruz.

Vulnerability Analysis

Analiza podatności polega na zdefiniowaniu, które ataki są możliwe. Wyszukujemy błędy w usługach, aplikacjach i hostach, które zbadaliśmy wcześniej. Na tym etapie korzystamy ze skanerów podatności. Dobieramy exploity, które mają największe szanse na zadziałanie.

Exploitation

Eksploatacja, czyli realna penetracja systemu. Wykorzystujemy dobrane wcześniej exploity i luki, aby dostać się do systemu. Należy pamiętać, że ślepe przeprowadzanie masowych ataków mija się z celem i może tylko spowodować awarię – takie rozwiązanie niesie niewielkie korzyści dla właściciela.

Post Exploitation

Faza poeksploatacyjna zaczyna się po uzyskaniu dostępu do systemu. Przechodzimy z systemu do systemu i zdobywamy coraz więcej informacji. Pentester może uzyskać trwały dostęp do systemu wykorzystując tylne drzwi (backdoor), spróbować podnieść uprawnienia (privilege escalation). Staramy się złamać zabezpieczenia następnych wewnętrznych systemów, aplikacji, infrastruktur. Należy się dostosować, polegać na własnym rozumie i inteligencji, a nie zautomatyzowanych rozwiązaniach.

Reporting

Test penetracyjny kończymy stworzeniem raportu. Musimy zawrzeć w nim czynności, które przeprowadziliśmy, szczegółową listę luk. Wszystkie informacje, jakie udało nam się zdobyć należy umieścić w dokumentacji. Należy podzielić raport na dwie części – streszczenie dla zarządu i część techniczną. W streszczeniu powinniśmy zawrzeć ogólne zalecenia, ogólne wyniki przeprowadzonych działań i krótki opis każdej z faz testu. W części technicznej należy umieścić szczegółowy opis każdej z faz i oszacować ryzyko związane z każdą podatnością. Pamiętać należy, aby nie oznaczać luk teoretycznych jako krytycznych, jeśli nie stworzono jeszcze odpowiedniego exploitu. Dzięki temu zleceniodawca wie, na których podatnościach powinien się skupić w pierwszej kolejności. W części technicznej ważne jest zamieszczenie rozwiązań, które pomogą wyeliminować ryzyko związane z lukami. Należy pamiętać, aby upewnić się, że luki to naprawdę luki, a nie bazować tylko na wyniku ze skanerów.

IDS, IPS, Firewall, VPN

0

Intrustion Detection System (IDS)

czyli oprogramowanie, które uruchamiane jest na stacjach roboczych, bądź na oddzielnych urządzeniach sieciowych. Służy do monitorowania ruchu w sieci. Nazwa IDS wskazuje na sposób działania, czyli na wykrycie intruza. Możemy rozróżnić kilka trybów działania Analiza heurystyczna – używa algorytmów do analizowania ruchu. Największe prawdopodobieństwo wystąpienia tak zwanych false positive, czyli fałszywych trafień. Analiza heurystyczna ma na celu wykrywanie nowych, nieznanych zagrożeń. Rzeczywiste wykrywanie nowych wirusów jest niskie, a liczba fałszywych alarmów wysoka. Detekcja anomalii – szuka nieprawidłowości, nietypowych działań w systemie, które odbiegają od zwyczajnych działań użytkowników. Zazwyczaj programy uczą się jak wygląda bazowy stan systemu . Bazowy stan systemu (czyli jak powinna wyglądać normalna działalność użytkowników) możemy skonfigurować ręcznie bądź pozwolić programowi samemu nauczyć się typowych wzorców zachowań. Wykrywanie sygnatur – skupia się na wykrywaniu ataków pasujących do określonych sygnatur, czyli do ustalonych reguł. Sygnatury opisują metody ataków na system. Na przykład atak SYN flood polega na ciągłym wysyłaniu bardzo dużej pakietów aż do zablokowania systemu. Pakiety te są specjalnie spreparowane (ustawiona flaga SYN). IDS wiedząc jak wygląda taki atak może podjąć odpowiednie kroki. IDS w przeciwieństwie do firewall stworzony jest aby wykrywać i raportować nieprawidłowości, a nie je blokować.

Network-Based IDS

NIDS zazwyczaj jest osobnym urządzeniem, które za zadanie ma wykrywać intruzów. Najczęściej umieszczany jest w kluczowym punkcie w sieci, aby był w stanie monitorować cały ruch ze wszystkich urządzeń. Systemy NIDS są bardzo popularne ze względu na stosunek kosztów do efektywności. Wystarczy umieścić jedno urządzenie w sieci, zamiast dbać o kupno licencji na każdą stację roboczą.

Host-Based IDS

HIDS działa tylko ona jednej maszynie. Uruchamiany jest jako usługa, bądź proces w tle. Jest to rzadziej spotykane rozwiązanie w porównaniu do NIDS. W obu przypadkach IDS ocenia i monitoruje ruch sieciowy. Po wykryciu anomalii może on zareagować pasywnie, bądź aktywnie.

Reakcja pasywna

Najczęstszy typ reakcji przeciwko większości naruszeń. Polega ona na tworzeniu logów, czyli zapisywaniu wszystkich zdarzeń, które wystąpiły oraz w jakich okolicznościach. Po odczytaniu logów administrator powinien mieś wystarczająco dużo informacji, dzięki którym będzie mógł zrozumieć przebieg ataku. Informacje te wykorzysta później aby zapobiegać podobnym atakom. Drugim sposobem reakcji jest wysłanie administratorowi powiadomienia w momencie wystąpienia zdarzenia. Obejmuje to przekazanie wszelkich istotnych danych, aby osoba, która dostała powiadomienie mogła ocenić zaistniałą sytuację. Czasami odpowiedzią na atak jest brak odpowiedzi. W sieciach pod dużym obciążeniem natężenie ataków jest wysokie. Nie ma więc sensu przejmować się atakami, które nie zadziałają z pewnych powodów.

Reakcja aktywna

Reakcja aktywna podejmuje działania bazując na zagrożeniu. Celem aktywnej odpowiedzi jest zredukować szkodliwe działania. Reakcja aktywna może spowodować zakończenie procesu, bądź sesji. Może także zmienić konfigurację sieciową – na przykład jeśli pewien adres IP powtarza ataki na sieć IDS może wysłać informację do routera, aby ten blokował ruch z tego IP. IDS może także oszukać atakującego, że jego atak się udał przekierowując go do wydzielonego systemu, który imituje prawdziwy (honeypot), a w między czasie monitorować dokładnie jego aktywność. Pozwoli to administratorowi poznać metody ataku i w przyszłości zapobiegać im.

IDS a IPS

Intrusion  Prevention System (IPS) reaguje blokując ruch ze szkodliwego adresu IP i zgłasza wystąpienie zdarzenia. Więc jest to IPS z dodatkową możliwością podejmowania działań, które powstrzymają atak. Można powiedzieć, że jest to firewall i IDS w jednym. System IPS w przypadku błędnej reakcji może spowodować problemy z funkcjonowaniem sieci.

Firewall

Firewall uważany jest za pierwszą linię obrony. Wyróżniamy różne typy firewalli, mogą być one wbudowane w systemy, czy urządzenia sieciowe (np w router), albo osobnymi urządzeniami. Ich zadaniem jest wyizolować sieć wewnętrzną od zewnętrznej. Nie musimy izolować całej sieci, a możemy jedynie jej część.

Stateful Packet Inspection Firewall

Ruch z sieci zewnętrznej do wewnętrznej jest domyślnie zablokowany. Jeśli użytkownik sieci wewnętrznej zainicjuje ruch, firewall na niego pozwoli. Firewall monitoruje ruch wychodzący i przychodzący. Pozwoli on na ruch z sieci zewnętrznej do wewnętrznej tylko pod warunkiem, że będzie to na przykład odpowiedź na żądanie z sieci wewnętrznej. Cały ruch jest zapamiętywany i analizowany.

Packet Filter Firewalls

Firewall nie analizuje danych w pakiecie, decyzje podejmuje bazując tylko na adresacji. Na przykład może być dozwolony ruch tylko na port 80, a gdziekolwiek indziej zablokowany.

Proxy Firewalls

Zapora pośrednicząca najczęściej umieszczana jest pośrodku naszej sieci i innej. Sieci nie mają ze sobą kontaktu, cały ruch jest kopiowany przez serwer proxy i wysyłany z jednej sieci do drugiej poprzez urządzenie pośredniczące. Pozwala to na ukrywanie adresów.

VPN

Virtual Private Network (wirtualna sieć prywatna) – prywatne połączenie, które ustanawiane jest poprzez publiczną sieć. VPN zapewnia prywatność i bezpieczeństwo w przesyłaniu danych przez niezabezpieczony internet. VPN może być używany do łączenia wielu prywatnych sieci (LAN), aby mogły się ze sobą komunikować używając internetu publicznego jako medium. Dzięki temu oba końce mogą być połączone ze sobą jak gdyby były połączone lokalnie. VPN wymaga specjalnych urządzeń (koncentrator VPN), bądź oprogramowania. Wirtualna sieć prywatna stosuje protokoły tunelowania, jak na przykład Layer 2 Tunneling Protocol, Point-to-Point Tunneling Protocol czy IPSec. Najważniejszym elementem zapewniającym bezpieczeństwo jest zastosowanie szyfrowania. Najczęściej używanym systemem szyfrowania jest IPSec. Jak wspomniałem wcześniej VPNy są używane do tworzenia połączeń pomiędzy prywatnymi sieciami poprzez internet. Jeśli nie zastosujemy szyfrowania połączenia nie będą miały zagwarantowanego bezpieczeństwa.