@themamuthWłasny domowy serwer — zabezpieczenia SSH

Własny domowy serwer — zabezpieczenia SSH

27 sierpnia 2016, 17:12

[image=tytul]

Ogromna liczba urządzeń IoT, popularność platformy Raspberry Pi powoduje, że duże grono pasjonatów zaczyna bawić się w instalację przeróżnej maści dystrybucji Linux na urządzeniach. Udostępniając w sieci świadomie lub nie sesje SSH często na domyślnych ustawieniach z domyślnym hasłem. Nawet gdy je zmienimy często dla łatwości ustawiamy je na funia czy inny tofik. Przygotowany prze zemnie wpis ułatwi często zaniedbywaną kwestię bezpieczeństwa.

Bezpieczeństwa systemów informacyjnych nie należy traktować jako jednorazowe przedsięwzięcie, ale jako proces, który powinien być modyfikowany wraz z pojawiającymi się zmianami w otoczeniu wewnętrznym i zewnętrznym organizacji.

- Ryszard Borowiecki, Mirosław Kwieciński (red.), Monitorowanie otoczenia : przepływ i bezpieczeństwo informacji. w stronę inteligencji przedsiębiorstwa, Zakamycze, Kraków 2003, ISBN: 83‑7333-246-4

Zabawę zacząć czas

Protokół SSH jest jednym z tzw. protokołów zdalnej sesji. Oznacza to, że program korzystający z tego protokołu umożliwia komunikację ze zdalnym komputerem. Przy pomocy SSH można więc poprzez sieć Internet zalogować się na się na odległym serwerze i pracować na nim tak, jak przy pomocy fizycznie podłączonego doń terminala. Protokół SSH zapewnia szyfrowanie całej transmisji. Protokół ten udostępniony początkowo w wersji 1 szybko ewoluował i aktualnie częściej używana jest jego 2‑ga wersja.

Zasada działania protokołu SSH opiera się na kryptograficznej technologii RSA i jest następująca: każdy z komputerów, na którym zainstalowane jest oprogramowanie SSH posiada parę kluczy: tzw. klucz prywatny dostępny tylko dla administratora komputera oraz klucza publicznego dostępnego dla wszystkich użytkowników sieci. Klucze te są tak zbudowane, że informację zaszyfrowaną kluczem prywatnym można rozszyfrować tylko przy pomocy klucza publicznego i odwrotnie informację zaszyfrowaną kluczem publicznym można rozszyfrować wyłącznie przy pomocy klucza prywatnego. Klucze są więc ze sobą powiązane, ale żadnego z nich nie można odtworzyć na podstawie znajomości drugiego. Połączenie SSH inicjowane jest po stronie programu - klienta SSH. Klient łączy się z serwerem i otrzymuje od niego jego klucz publiczny. Klucz ten porównywany jest z zachowanym w wewnętrznej bazie danych klienta, z poprzednich połączeń. W przypadku wykrycia niezgodności kluczy wyświetlane jest specjalne ostrzeżenie umożliwiające przerwanie połączenia. Następnie, klient przekazuje serwerowi swój klucz publiczny, generuje losową bitową liczbę, szyfruje ją przy pomocy swojego klucza prywatnego oraz klucza publicznego serwera. Serwer po otrzymaniu tak zakodowanej liczby rozszyfrowuje ją przy pomocy swojego klucza prywatnego i klucza publicznego klienta. Tak otrzymana liczba jest losowa a ponadto znana tylko klientowi i serwerowi. Jest ona używana jako klucz do kodowania podczas dalszej komunikacji.

Zabawę z SSH, jeżeli jeszcze go nie zainstalowałeś lub nie wiesz czy jest on aktywny na twoim serwerze zaczniemy od sprawdzenia statusu usługi poleceniem:


pi@raspberrypi:~ $ ps -aux | grep ssh


pi@raspberrypi:~ $ service ssh status


pi@raspberrypi:~ $ /etc/init.d/ssh status

oraz nasłuch


pi@raspberrypi:~ $ netstat -plant | grep :22

Może to też zrobić ktoś za nas prostym poleceniem wykorzystując do tego nmap:


pi@raspberrypi:~ $ nmap -p22 <adres_naszego_komputera>

lub jeszcze prostszy skrypt


if nmap -p22 <adres_ip_naszego_komputera> -oG - | grep -q 22/open; then
     echo "OK"
else
     echo "NOK"
fi

Jeżeli sprawdzenie statusu procesu nie zwróci Ci informacji o tym że SSH działa oraz skrypt zwróci Ci "NOK", to jesteś w zupełności bezpieczny. Prawdopodobnie usługa SSH nie jest zainstalowana. Dopóki nie wydasz polecenia instalacji serwera SSH, poniższy wpis nie jest dla Ciebie, jeżeli jednak Cię zaciekawiłem to zapraszam do zabawy.

Instalacja SSH

SSH zainstalować możemy poleceniem:


#Debian/Ubuntu
pi@raspberrypi:~ $ sudo apt-get install openssh-server

W CentOS będziemy potrzebować pobrać EPEL repository ponieważ fail2ban nie jest dostępne dla CentOS - przykłąd polecenia zależnego od wersji CentOS jest pokazany poniżej (dla wersji 6).


rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm


#Fedora/CentOS
sudo yum install openssh-server

Gdyby przy ponownym uruchomieniu serwera okazało by się, że serwer SSH nie uruchamia się automatycznie z serwerem, to poniższym poleceniem możemy dodać go do uruchamianych procesów na start:


#Debian/Ubuntu
pi@raspberrypi:~ $ sudo update-rc.d ssh defaults


#Fedora/CentOS
sudo systemctl enable sshd.service

Przed wykonaniem dalszych czynności wykonaj polecenie usunięcie obecnych kluczy hosta i wygenerowanie nowych.

Przenosimy/Usuwamy


pi@raspberrypi:~ $ cd /etc/ssh/
pi@raspberrypi:~ $ sudo mkdir oldoriginal_default_keys && sudo mv ssh_host_* oldoriginal_default_keys/


pi@raspberrypi:~ $ sudo rm /etc/ssh/ssh_host_*

Generujemy nowe


pi@raspberrypi:~ $ sudo dpkg-reconfigure openssh-server && sudo /etc/init.d/ssh restart

Gdyby pojawiły się problemy przy wywołaniu skryptu dpkg-reconfigure wygeneruj klucze ręcznie:


pi@raspberrypi:~ $ sudo ssh-keygen -t dsa -N "" -f /etc/ssh/ssh_host_dsa_key
pi@raspberrypi:~ $ sudo ssh-keygen -t rsa -N "" -f /etc/ssh/ssh_host_rsa_key
pi@raspberrypi:~ $ sudo ssh-keygen -t ecdsa -N "" -f /etc/ssh/ssh_host_ecdsa_key

The reason for this is because every Linux and Unix system uses similar keys. An Attacker could potentially guess or crack your SSH keys and exploit your system using Man‑in-the-Middle techniques.

-Aamir Lakhani (known as Dr. Chaos)

Może pokazać Ci się poniższy komunikat

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
 Someone could be eavesdropping on you right now (man-in-the-middle attack)!
 It is also possible that the RSA host key has just been changed.
 The fingerprint for the RSA key sent by the remote host is
 26:65:52:75:81:71:a8:c5:4c:ad:b6:81:78:58:18:af.
 Please contact your system administrator.
 Add correct host key in /root/.ssh/known_hosts to get rid of this message.
 Offending key in /root/.ssh/known_hosts:1
 RSA host key for localhost has changed and you have requested strict checking.
 Host key verification failed.

Powyższy komunikat pokaże Ci się tylko w przypadku gdy połączysz się ponownie po SSH ze swojego komputera.

Wtedy usuń ręcznie wpis w pliku np ~/.ssh/known_hosts odnoszący się do serwera, z którym się łączyłeś.

Można też wykonać to poleceniem:


pi@raspberrypi:~ $ ssh-keygen -R <nazwa_serwera_zdalnego>

Instalacja Fail2Ban

Fail2Ban monitoruje usługi i sprawdza w logach czy były jakieś nie udane próby logowania. Jeżeli oprogramowanie wykryje znacznie zwiększoną liczbę nieudanych prób logowania z danego adresu IP. Wskazującą na próbę ataku typu Bruteforce. Stworzy ono regułę w iptables lub TCP Wrappers (/etc/host.deny) o blokadzie możliwości połączenia do Twojego serwera, do konkretnej usługi z konkretnego adresu IP, który dokonuje ataku.

Oprogramowanie Fail2Ban napisane jest w języku Python, możesz zainstalować je za pomocą polecenia:


pi@raspberrypi:~ $ sudo apt-get install fail2ban

Po instalacji zostaną utworzone kolejno pliki:


/etc/fail2ban/fail2ban.conf (zawiera podstawowe ustawienia.)
/etc/fain2ban/jail.conf (ustawienia monitora programu.)
katalog /etc/fail2ban/action.d/ (zawiera akcje banowania podejrzanych IP)
katalog /etc/fain2ban/filter.d/ (zawiera reguły dzięki, którym fail2ban identyfikuje zagrożenia).

Przejdźmy jednak do konfiguracji, skopiujmy plik /etc/fail2ban/jail.conf:


pi@raspberrypi:~ $ sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

W sekcji [DEFAULT]

ignoreip - Wszystkie wpisy tu będą stanowić białą listę, z których nie będzie analizowany ruch. Wpis może mieć postać adresu IP i CIDR maski podsieci oraz adres DNS hosta.

Jeżeli chcemy być bardziej dokładni i zezwolić tylko dla konkretnej usługi (JAILS) ustawić biała listę pomijając inne wydajemy polecanie.


fail2ban-client set <JAIL> addignoreip <IP>

gdzie <JAIL> to nazwa usługi a <IP> to twój zaufany adres IP.

maxretry - Tu podajemy liczbę nieudanych prób po, których fail2ban zablokuje hosta.

bantime - Tu informujemy na ile sekund ma być zbanowany host.

banaction - Do wyboru dwie opcje iptables-multiport lub hostsdeny. Pierwsza opcja tworzy wpisy w iptables blokujące adresy podejrzane o atak. Druga opcja blokuje adresy w tcp‑wrappers /etc/hosts.deny.

action - Zmiana wpisu na %(action_mwl)s spowoduje że oprócz informacji w logu o zablokowaniu adresu IP lub hosta zostaniemy poinformowani o tym e‑mailem.

Domyślna action_ akcja blokuje tylko użytkownika, akcja action_mw banuje i wysyła informację, akcja action_mwl banuje użytkownika wysyła e‑mail z bełną informacja o logach i podjętych działaniach.

destemail - Tu wpisujemy adres na który ma zostać wysłane e‑mail.

findtime - Tu określamy czas w jakim mają się powtórzyć podejrzane próby ataku.

Pełna dokumentację oraz opis można znaleźć w manualu usługi.

Sekcja JAIL [SSH]

enable - Opcja true działa reguła / false nie działa.

port - określenie portu lub nazwy usługi.

filter - okreslenie reguły w ramach której bedzie analizowany log i wdrażane drop w iptables lub tcp wrapper

logpath - log usługi z zapisani nieudanych prób logowania.

maxretry - Po ilu próbach zostanie zablokowany host. Gdy w [DEFLAUT] jest od komentowana sekcja maxretry obowiązuje jej wpis.

W Fail2Ban są dostępne też inne reguły, w moim wpisie nie będziemy z nich korzystać więc ustawiamy w pozostałych sekcjach [<nazwa sekcji>] enable=true na enable=false lub po prostu tworzymy pusty plik /etc/fail2ban/jail.local i edytujemy go:


[DEFAULT]
ignoreip  = 127.0.0.1 82.192.71.9 95.211.46.207
bantime   = 86400
destemail = you@your-email.com
banaction = iptables-multiport
action    = %(action_mwl)s


#Debian/Ubuntu
# JAILS
[ssh]
enabled   = true
maxretry  = 3


#Fedora/centOS
#JAILS
[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
                 sendmail-whois[name=SSH, dest=root, sender=fail2ban@example.com]
logpath  = /var/log/secure
maxretry = 5

Restartujemy usługę i sprawdzamy czy działa


#Debian/Ubuntu
pi@raspberrypi:~ $ sudo /etc/init.d/fail2ban restart && /etc/init.d/fail2ban status


#Fedora/CentOSsudo 
sudo service fail2ban restart && service fail2ban status

W iptables powinien też pojawić się wpis:


fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh

Sprawdzamy to poleceniem:


pi@raspberrypi:~ $ sudo iptables -L

Przeprowadź test i spróbuj błędnie zalogować się po SSH z lokalnego hosta. Log Fail2Ban znajdziemy tutaj /var/log/fail2ban.log


pi@raspberrypi:~ $ cat /var/log/fail2ban.log

Zablokowany adres IP usuwamy po czym restartujemy usługę


pi@raspberrypi:~ $ sudo iptables -D fail2ban-ssh 1 && sudo /etc/init.d/fail2ban restart

Na problemy sierżant zawada

Przy problemach z fail2ban po awarii (crash) systemu lub awarii zasilania należy usunąć plik /var/run/fail2ban/fail2ban.sock


pi@raspberrypi:~ $ sudo rm /var/run/fail2ban/fail2ban.sock

Aby temu zaradzić należy w pliku /etc/default/fail2ban poprawić/dodac linijkę


FAIL2BAN_OPTS="-x"

W systemach o bardzo skomplikowanych strukturalnych iptables może wystąpić błąd podczas tworzenia łańcuchów przez fail2ban. Jest na to rada w postaci dodania do /usr/bin/fail2ban-client polecenia time.sleep(0.1) w linii 145


def __processCmd(self, cmd, showRet = True):
			beautifier = Beautifier()
			for c in cmd:
					time.sleep(0.1)
					beautifier.setInputCmd(c)

Powiadomienia e‑mail a w zasadzie szablon można edytować w pliku /etc/fail2ban/action.d/sendmail-whois-lines.conf.

Przydatne polecenia:


Logs: tail /var/log/fail2ban.log
Check status: fail2ban-client status
Check status of certain service: fail2ban-client status ssh
Check regex results: fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

Fail2ban zapewnia dodatkowe komendy fail2ban-client, które mogą być używane do kontrolowania i administracją Fail2ban. Przydatne komendy:

fail2ban-client COMMAND
start: Startuje Fail2ban i wszystkie ustawienia JAIL.
reload: Przeładowuje wszystkie ustawienia.
reload JAIL: Za słowo JAIL wpisz nazwę usługi spowoduje to przeładowania ustawień konkretnej usługi w fail2ban.
stop: Zatrzymuje usługę.
status: Pokazuje status usługi fail2ban oraz zastosowane JAIL.
status JAIL: Pokazuje status usługi JAIL oraz zablokowane adresy IP dla tej usługi JAIL.

Dodatkowe informacje fail2ban-client commands, można znaleźć na Fail2ban wiki.

Konfiguracja ustawień SSH

Plik konfiguracyjny znajdziesz w /etc/ssh/sshd_config Aby go edytować będzie konieczne wydanie polecenia:


pi@raspberrypi:~ $ sudo nano /etc/ssh/sshd_config

Pamiętaj

Pamiętaj, że serwer SSH zbędny jest na stacjach roboczych i laptopach. Jeżeli komputer jest włączony tylko wtedy kiedy z niego korzystasz pamiętaj o tym by wyłączyć serwer SSH. Tak wiem, wiem można przesyłać pliki jednak to nie usprawiedliwia tego że masz nie zabezpieczone SSH - zmień to!

Jeżeli jest zbędne odinstaluj go

Odinstalować serwer SSH można podając polecenie:


#
Fedora/CentOS
sudo chkconfig sshd off && sudo yum erase openssh-server


#Debian/Ubuntu
pi@raspberrypi:~ $ apt-get remove openssh-server

Nie usunie to klienta nadal będzie można łączyć się do innych komputerów.

Aktualizuj

Zawsze staraj się posiadać najnowsze oprogramowanie i wersje wydane dla twojego systemu. Zrobisz to poleceniem:


#Fedora/CentOS
sudo yum update


#Debian/Ubuntu
pi@raspberrypi:~ $ sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade

Używaj silnych haseł

Możesz zabezpieczyć super SSH ale nic to nie da jeżeli twoje hasła będą proste i łatwe do zapamiętania, złamania, zgadnięcia. Pamiętaj proste hasło dla Ciebie to proste hasło dla włamywacza.

[list] [item]Używaj generatorów haseł takich jak pwgen

Poleceniem:

 pi@raspberrypi:~ $ pwgen 12

Wygenerujesz tym polecenie losowe hasło o długości 12 znaków.[/item] lub funkcji urandom dodając do ~/.bashrc własną funkcję, która w każdej chwili gdy tylko będziesz tego potrzebował wygeneruje Ci hasło

skrypt


genpasswd() {
       local l=$1
                 [ "$l" == "" ] && l=20
                 tr -dc A-Za-z0-9_ < /dev/urandom | head -c ${l} | xargs
}

[item]Nie używaj tego samego hasła do uwierzytelniania się na rożnych serwerach, portalach, usługach online itp. Jeżeli nie potrafisz zapamiętać haseł zapisz je. Jest większe prawdopodobieństwo, że zostanie ono wykradzione z portali i użyte na innych gdzie używasz tego samego niż ktoś odnajdzie Twoją karteczkę z zapisanymi hasłami. Jeżeli nie wierzysz mi uwierz guru bezpieczeństwa Bruce Shneier. [/item][item]Zmień hasła dla standardowych kont w dystrybucjach typu Rasbpian, OSMC, itp gdzie użytkownik to "pi" a hasło dla niego to "raspberry"[/item][/list]

Używaj tylko SSH Protocol 2

Protokół SSH w wersji pierwszej jest podatny na ataki typu man‑in-the-middle i ma problemy z zabezpieczeniami. Unikaj go jak ognia. Jeżeli twój serwer SSH korzysta z protokołu w wersji 1 zmień to na wpis:


Protocol 2

Ogranicz możliwość logowania

Ogranicz logowanie użytkowników tylko do wybranych. Nie jest potrzebne by każdy użytkownik stworzony na serwerze mógł korzystać z SSH. Ograniczysz to dodając wpis w pliku konfiguracyjnym:

AllowUsers <nazwa_twojego_uzytkownika>

Możesz dodać kilku oddzielając wpisy przecinkiem lub spacją

Zabroń logowania się po SSH dla użytkownika root. Zawsze możesz się na niego zalogować po zalogowaniu się do SSH na zwykłego użytkownika polecaniem su -

Wpis ograniczający w pliku konfiguracynym ma postać:

DenyUsers root

Stwórz specjalnego uzytkownika z ograniczonymi uprawnieniami na którego bedziesz logowała się po SSH. Zrobisz to poleceniem:

#Fedora/CentOS
sudo useradd <nazwa_nowego_uzytkownika> && sudo passwd <nazwa_nowego_uzytkownika>

#Debian/Ubuntu
pi@raspberrypi:~ $ sudo adduser <nazwa_nowego_uzytkownika>

Nie dodawaj go do sudo. Pamiętaj, że logując się do ssh zawsze możesz się potem prze logować na użytkownika z uprawnieniami sudo.

Ogranicz też grupę która może logowac sie do SSH. Wykorzystyjąc do tego wpisy w pliku konfiguracyjnym ssh:

AllowGroups <nazwa_twojej_gupy>

Utwórz grupę i dodaj użytkownika do tej grupy:

 pi@raspberrypi:~ $ sudo groupadd <nazwa_twojej_grupy> && sudo usermod -a -G <nazwa_twojej_grupy><nazwa_usera_ssh>

Skonfiguruj Log Out Timeout Interval

Skonfiguruj po jakim czasie od bezczynności użytkownik ma zostać automatycznie wyrzucony z sesji SSH. Wpis w pliku konfigurujący wygląda następująco:

ClentAliveInterval 300
ClientAliveCountMax 0

Wyłącz pliki .rhosts

Nie używaj plików ~/.rhosts i ~/shosts uzytkowników. Wpis w sshd_config powinien wyglądać tak:

IgnoreRhosts yes

Wyłącz Host-Based Authentication

Wpis w sshd_config powinien wyglądać tak:

HostbaseAuthentication no

Wyłącz logowanie użytkownika root po SSH

Wpis w sshd_config powinien wyglądać tak:

PermitRootLogin no

Włącz baner ostrzegawczy

Wpis w sshd_config powinien wyglądać tak:

Banner /etc/issue

Zmień port SSH i ogranicz adresy z których można się łączyć

Wpis w sshd_config powinien wyglądać tak:

Port 3023

ListenAddress 192.168.0.1 ListenAddress 88.89.90.91

Używaj TCP Wrappers

Po prostu edytuj plik /etc/hosts.allow (zawierający listę dozwolonych adresów IP) i dodaj wpis:

sshd : 192.168.0.1 88.89.90.91

Wykorzystaj też plik /etc/hosts.deny (zawierający listę nie dozwolonych adresów IP) i dodaj do niego wpis

sshd : ALL

Wyłącz Empty Passwords

Wpis w sshd_config powinien wyglądać tak: PermitEmptyPasswords no

Wyłacz IPv6

Jeżeli nie wykorzystujesz adresacji IPv6 to wyłącz korzystanie z adresów IPv6 w sieci lokalnej. Po pierwsze sprawdź polecenie ifconfig czy jest aktywne IPv6 u Ciebie.

Żeby wyłączyć IPv6 wydaj polecenie:

sudo nano /etc/sysctl.conf

Dodaj poniższy wpis

net.ipv6.conf.all.disable_ipv6 = 1

Aby zastosować regółę bez restartu serwera wydaj polecenie:

pi@raspberrypi:~ $ sudo sysctl -p

Zweryfikuj ustawienia poleceniem ifconfig.

Jeżeli chcesz z powrotem przywrócić IPv6 wystarczy wartośc 1 zmienić na 0. Pamietaj również o przełądowaniu ustawień.

sudo sysctl -p

sudo ifconfig eth0 down && sudo ifconfig eth0 up

Jeżeli wykonywałeś to polecenie podłączony przez SSH to zostaniesz wyrzucony. Połączyć będziesz mógł się po chwili po przeładowaniu ustawień.

Używaj Public Key Authentication

W trakcie prac nad protokołem SSH opracowano liczne jego udoskonalenia i rozszerzenia. Jednym z nich jest możliwość autoryzacji użytkowników przy pomocy pary kluczy RSA Jest to znacznie bezpieczniejszy sposób logowania się na serwerze niż przy pomocy tradycyjnych haseł. Aby używać autoryzację RSA należy wygenerować parę kluczy - swój klucz prywatny i klucz publiczny. W systemach Unixowych do tego celu służy program ssh‑keygen. Jego opis możemy obejrzeć wydając komendę:

man ssh-keygen

Wygenerowany klucz publiczny należy umieścić w pliku identity.pub w podkatalogu .ssh swojego katalogu domowego. Klucz prywatny należy przenieść w bezpieczne miejsce, np. na swój prywatny komputer lub na noszoną ze sobą dyskietkę/klucz USB. Dla zwiększenia bezpieczeństwa można podczas tworzenia pary kluczy RSA zażądać dodatkowego zaszyfrowania klucza prywatnego wymyślonym przez siebie hasłem. W takim przypadku, przed każdym wykorzystaniem swojego klucza prywatnego do uzyskania połączenia z serwerem konieczne jest podanie hasła rozkodowującego klucz. Wiele programów - klientów SSH umożliwia wykorzystanie autoryzacji RSA zamiast wprowadzania tradycyjnych haseł.

Pewnie zdarzyło Ci się pomylić przy wpisywaniu hasła. Może to spowodować zablokowanie twojego hostu i uniemożliwić Ci zalogowanie się do serwera SSH. Rozwiązaniem jest używanie PublicKeyAutentication. W pliku konfiguracyjnym edytujemy linię:

PublickeyAuthentication yes

Jak wygenerować parę kluczy pod windows w putty pisałem już w jednym z moich artykułów - Jak trwoga to do boga cz. 2

Jednak można to też zrobić w konsoli naszego klienckiego komputera z systemem linux z którego będziemy chcieli się łączyć do naszego serwera. Służy do tego polecenie:

ssh-keygen -t rsa -b 3072 -f ssh_serwer

A potem przenieść go na serwer poleceniem:

ssh-copy-id -i ~/.ssh/id_rsa.pub remote_user@remote_host

Możemy to też zrobić na Windows po instalacji CyGwin.

Firewall lub/i iptables

Ograniczenie połaczeń z jednego adresu IP

iptables  -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 3 -j REJECT

Ograniczenie połaczeń do czterach w przeciagu 60 secund

iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set

iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update \

 --seconds 60 --hitcount 4 -j REJECT

Reguły iptables są ustalane i edytowane z wiersza polecenia komendą iptables dla IPv4 i ip6tables dla IPv6.

Dla IPv4 mogą one zostać zapisane w pliku komendą iptables-save.

#Debian/Ubuntu
iptables-save > /etc/iptables/rules.v4

#Fedora/CentOS
iptables-save > /etc/sysconfig/iptables

Ten plik może później zostać załadowany komendą iptables-restore.

#Debian/Ubuntu
iptables-restore < /etc/iptables/rules.v4

#Fedora/CentOS
iptables-restore < /etc/sysconfig/iptables

Jeżeli są wykorzystywane reguły IPv6 to mogą one również zostać zapisane.

#Debian/Ubuntu
ip6tables-save > /etc/iptables/rules.v6

#Fedora/CentOS
ip6tables-save > /etc/sysconfig/ip6tables

Używaj Keychain Based Authentication

http://www.cyberciti.biz/faq/ssh-passwordless-login-with-keychain-for-...

Chroot SSHD

Zainstaluj rssh

sudo apt-get install rssh

Więcej o konfiguracji

Używaj Port Knocking

https://debian-administration.org/article/268/Multiple-port_knocking_N...

Dodatkowe ustawienia

Dodatkowe ustawienia, które zwiększają bezpieczeństwo.


IgnoreRhosts yes
RhostsRSAAuthentication no
UsePam yes
ServerKeyBits 2048 lub więcej
UserPrivilegeSeparation yes
Strictmode yes
VerifyReverseMapping yes
AllowTcpForwarding no
X11Forwarding no

Bądź zawsze czujny

Bezpieczeństwa systemów informacyjnych nie należy traktować jako jednorazowe przedsięwzięcie, ale jako proces, który powinien być modyfikowany wraz z pojawiającymi się zmianami w otoczeniu wewnętrznym i zewnętrznym organizacji.

Niniejszy wpis proszę traktować jako wskazówki do prawidłowego zabezpieczenia serwera SSH. Bezpieczeństwo IT nie jest jednorazowym produktem a nieustannie wdrażanym i kontrolowanym procesem. PAMIĘTAJ O TYM!

Przydatne linki:

I jeszcze mogłbym tak wymieniać ale każdy ma googla :) Pozdrawiam

P.S. Czekam na wasze opinie, komentarze, hejty, hejpy.