Blog (17)
Komentarze (121)
Recenzje (0)

Własny domowy serwer — zabezpieczenia SSH

Strona główna@themamuthWłasny domowy serwer — zabezpieczenia SSH
27.08.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.
bDUqtzvX

- *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.

bDUqtzwd

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
bDUqtzwe

oraz nasłuch

pi@raspberrypi:~ $ netstat -plant | grep :22
Sprawdzenie statusu procesu ssh
Sprawdzenie statusu procesu ssh

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

bDUqtzwf
pi@raspberrypi:~ $ nmap -p22 

lub jeszcze prostszy skrypt

if nmap -p22  -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:

bDUqtzwg
#Debian/Ubuntupi@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/CentOSsudo 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/Ubuntupi@raspberrypi:~ $ sudo update-rc.d ssh defaults
#Fedora/CentOSsudo 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_keypi@raspberrypi:~ $ sudo ssh-keygen -t rsa -N "" -f /etc/ssh/ssh_host_rsa_keypi@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/knownhosts odnoszący się do serwera, z którym się łączyłeś.

Można też wykonać to poleceniem:

pi@raspberrypi:~ $ ssh-keygen -R 

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  addignoreip 

gdzie  to nazwa usługi a  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 %(actionmwl)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 actionmw banuje i wysyła informację, akcja actionmwl 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 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.207bantime   = 86400destemail = you@your-email.combanaction = iptables-multiportaction    = %(action_mwl)s
#Debian/Ubuntu# JAILS[ssh]enabled   = truemaxretry  = 3
#Fedora/centOS#JAILS[ssh-iptables]enabled  = truefilter   = sshdaction   = iptables[name=SSH, port=ssh, protocol=tcp]                 sendmail-whois[name=SSH, dest=root, sender=fail2ban@example.com]logpath  = /var/log/securemaxretry = 5

Restartujemy usługę i sprawdzamy czy działa

#Debian/Ubuntupi@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
ssh002
ssh002

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.logCheck status: fail2ban-client statusCheck status of certain service: fail2ban-client status sshCheck 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 COMMANDstart: 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.

ssh003
ssh003

Konfiguracja ustawień SSH

Plik konfiguracyjny znajdziesz w /etc/ssh/sshdconfig 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/CentOSsudo chkconfig sshd off && sudo yum erase openssh-server
#Debian/Ubuntupi@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/CentOSsudo yum update
#Debian/Ubuntupi@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 itemUż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}
ssh004
ssh004

itemNie 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. /itemitemZmień 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 

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/CentOSsudo useradd  && sudo passwd 
#Debian/Ubuntupi@raspberrypi:~ $ sudo adduser 

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 

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

 pi@raspberrypi:~ $ sudo groupadd  && sudo usermod -a -G 

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 300ClientAliveCountMax 0

Wyłącz pliki .rhosts

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

IgnoreRhosts yes

Wyłącz Host-Based Authentication

Wpis w sshdconfig powinien wyglądać tak:

HostbaseAuthentication no

Wyłącz logowanie użytkownika root po SSH

Wpis w sshdconfig powinien wyglądać tak:

PermitRootLogin no

Włącz baner ostrzegawczy

Wpis w sshdconfig powinien wyglądać tak:

Banner /etc/issue

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

Wpis w sshdconfig 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 sshdconfig 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/Ubuntuiptables-save > /etc/iptables/rules.v4
#Fedora/CentOSiptables-save > /etc/sysconfig/iptables

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

#Debian/Ubuntuiptables-restore < /etc/iptables/rules.v4
#Fedora/CentOSiptables-restore < /etc/sysconfig/iptables

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

#Debian/Ubuntuip6tables-save > /etc/iptables/rules.v6
#Fedora/CentOSip6tables-save > /etc/sysconfig/ip6tables

Używaj Keychain Based Authentication

Chroot SSHD

Zainstaluj rssh

sudo apt-get install rssh

Więcej o konfiguracji

Używaj Port Knocking

Dodatkowe ustawienia

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

IgnoreRhosts yesRhostsRSAAuthentication noUsePam yesServerKeyBits 2048 lub więcejUserPrivilegeSeparation yesStrictmode yesVerifyReverseMapping yesAllowTcpForwarding noX11Forwarding 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.

- *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*

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.

bDUqtzwT