Instalacja serwera TeamSpeak 3 – Linux Debian
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)
ufw allow 9987/udpJeś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 ts3Cały proces instalacyjny wykonujemy z poziomu konta ts3, więc zalogujmy się na nie
su ts3Przechodzimy do katalogu domowego
cd /home/ts3/
TS3
Pobierzmy pliki instalacyjne z oficjalnej stronyhttp://www.teamspeak.com/downloadsWchodzimy 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.bz2Wypakowujemy
tar -vxjf teamspeak3-server_linux_amd64-3.0.13.4.tar.bz2Wchodzimy do folderu
cd teamspeak3-server_linux_amd64Nadajemy uprawnienia wykonania dla właściciela
chmod +x ts3server_startscript.shUruchamiamy
./ts3server_startscript.sh startZostały wygenerowane dane dostępowe. Aby zyskać uprawnienia administratora na serwerze należy wprowadzić token przy pierwszym połączeniu z serwerem.
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.
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.localnano /etc/rc.localPrzed 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 0Po restarcie systemu operacyjnego serwer został prawidłowo uruchomiony przez użytkownika ts3.
Porównanie serwerów VPS
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)
- Linux VPS – 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
webh (kvm)
webh (openVZ)
smarthost
hitme
kylos
ovh
tiktalik (pro)
tiktalik (standard_8zł)
tiktalik (standard_36zł)
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)
aruba
kylos
webh (OpenVZ)
smarthost
hitme
ovh
tiktalik (pro)
tiktalik (standard_8zł)
tiktalik (standard_36zł)
Wydajność nginx
- Requests per second [więcej = lepiej]
- Time per request [mniej = lepiej]
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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 (OpenVZ):
hitme:
smarthost:
aruba:
kylos:
ovh:
tiktalik:
Support
webh:
Bezproblemowy, szybki. Odpisywali w środku nocy po chwili. Bardzo miła, fachowa pomoc. 9/10kylos:
Szybki czas aktywacji, profesjonalna obsługa techniczna, bardzo dobry czas oczekiwania na odpowiedź. 7/10hitme:
Dobry czas oczekiwania na odpowiedź (poniżej 24h). Raz nawet zdarzyło się, że dostałem odpowiedź po 10 minutach. 7/10smarthost:
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/10aruba:
Przeciętny. 4/10ovh:
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/10Czas 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.
Dostajemy możliwość zainstalowania aż 21 konfiguracji systemów operacyjnych, ale niestety nie możemy wgrać własnego obrazu ISO. 
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.
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)
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.
[/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
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-enablednano /etc/nginx/sites-enabled/shintestDodajemy następujące linijki
location /.well-known/acme-challenge {
root /var/www/letsencrypt;
}
Przeładowujemy konfigurację
service nginx reloadTworzymy folder
mkdir /var/www/letsencrypt/Instalujemy gita
apt-get install gitKlonujemy 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
Certyfikat został poprawnie wygenerowany.
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/shintestPowinien 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
Przetestujmy domenę skanerem Qualys SSL Labs
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;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.5listen 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_timeoutssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;
OCSP Stapling
Po więcej informacji odsyłam tu i tussl_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 foldermkdir /etc/nginx/sslGenerujemy protokół Diffiego-Hellmana
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096Dodajemy linijkę do naszej konfiguracji
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
A+
Ostatecznie nasza konfiguracja powinna wyglądać takserver {
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
Autoodnawianie
Korzystając z crona zaplanujemy automatyczne odnawianie certyfikatucrontab -eWklejamy 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
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)
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
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)
suWykonujemy niezbędne aktualizacje
apt-get update && apt-get upgrade
nginx
Instalujemy:apt-get install nginxPo instalacji otwieramy przeglądarkę i wchodzimy na adres naszego serwera (używając adresu domeny, bądź IP). Powinna nam się ukazać strona powitalna:
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
nano /etc/nginx/nginx.confW 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 -nworker_connections 65536;nginx -tJeśli tak możemy przeładować konfigurację.
service nginx reloadAby 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-serverZostaniesz poproszony o ustawienie hasła konta root. Warto zmienić kilka niezbyt bezpiecznych ustawień domyślnych.
mysql_secure_installationZostaniemy 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-xmlrpcOtwórz php.ini
nano /etc/php5/fpm/php.iniZnajdź 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=0Resetujemy usługę
service php5-fpm restart
WordPress
Skasujmy domyślne server-blocksrm /etc/nginx/sites-enabled/default /etc/nginx/sites-available/defaultStwórzmy nowy plik w folderze sites-enabled:
nano shintestWklejamy 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
Wszystko gotowe.
Proste, prawda?Strefa zdemilitaryzowana, czyli co to jest DMZ
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:
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.
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.
- do sieci wewnętrznej
- do sieci zewnętrznej
- do danych, które chcemy udostępnić
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.
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
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ć golang i fatih/color.
Teraz zajmijmy się samym frameworkiem.
Wybieramy opcję drugą, następnie wpisujemy adres IP i port, na którym będziemy nasłuchiwać połączenia
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.
Dodatkowe polecenia, które możemy wykonać znajdziemy na stronie twórcy
git clone https://github.com/EgeBalci/ARCANUS cd ARCANUS/SOURCEgo build cd .. chmod 755 ARCANUS ./ARCANUS
Wybieramy opcję drugą, następnie wpisujemy adres IP i port, na którym będziemy nasłuchiwać połączenia
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.
Dodatkowe polecenia, które możemy wykonać znajdziemy na stronie twórcy Testy penetracyjne
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
