Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Własny domowy serwer — zabezpieczenia SSH

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.

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

  • 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 }

  • 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.
  • Zmień hasła dla standardowych kont w dystrybucjach typu Rasbpian, OSMC, itp gdzie użytkownik to "pi" a hasło dla niego to "raspberry"

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 3023ListenAddress 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 wpissshd : 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 -psudo ifconfig eth0 down && sudo ifconfig eth0 upJeż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 IPiptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 3 -j REJECTOgraniczenie połaczeń do czterach w przeciagu 60 secundiptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --setiptables -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/iptablesTen 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/iptablesJeż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

Chroot SSHD

Zainstaluj rsshsudo apt-get install rsshWięcej o konfiguracji

Używaj Port Knocking

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

linux bezpieczeństwo serwery

Komentarze

0 nowych
DjLeo MODERATOR BLOGA  17 #1 27.08.2016 15:17

Muszę pohejtować Twój wpis, a więc jest bardzo dobry. W sumie to jednak nie hejt :) Dobra robota ;)

  #2 27.08.2016 15:23

pi@raspberrypi:~ $ servic ssh status
czy
pi@raspberrypi:~ $ service ssh status

GBM MODERATOR BLOGA  19 #3 27.08.2016 15:43

Bardzo dobry wpis, dodam od siebie, że w (tak jak autor napisał) bardzo ważna jest częsta aktualizacja naszego serwera SSH. Ten protokół ze względu na swoją obecność w praktycznie każdym serwerze opartym na Linuxie, ma bardzo duże grono "fanów" szukających w nim podatności ;)

Dodatkowo lepsze niż hasło, jest uwierzytelnianie za pośrednictwem kluczy. Warto też podkreślić, że z pomocą Google Authenticator można zaimplementować (w dosyć łatwy sposób) uwierzytelnianie dwuetapowe w SSH ;)

PS. Usunąłbym termin "domowy" z tytułu. Generalnie rady tu zawarte w pewnym zakresie można zastosować także w warunkach produkcyjnych ;)

Autor edytował komentarz w dniu: 27.08.2016 15:44
makmk   5 #4 27.08.2016 16:14

Ogólnie dobry wpis, ale jest trochę błędów:
"Klucze są więc ze sobą powiązane, ale żadnego z nich nie można odtworzyć na podstawie znajomości drugiego."

http://askubuntu.com/questions/53553/how-do-i-retrieve-the-public-key-from-a-ssh...

"Klucz ten porównywany jest z zachowanym w wewnętrznej bazie danych klienta, z poprzednich połączeń."

Nie jest to baza danych a plik known_hosts - zazwyczaj ~/.ssh/known_hosts

"W przypadku wykrycia niezgodności kluczy wyświetlane jest specjalne ostrzeżenie umożliwiające przerwanie połączenia"
Nie jest to ostrzeżenie, tylko połączenie jest zwyczajnie przerywane.

"...od sprawdzenia statusu usługi poleceniem:" - tutaj dodałbym systemctl status sshd dla systemd

No i pośród tych wszystkich opcji brakuje mi chyba najważniejszej czyli pam, oraz dostępnych modułów -> http://www.linux-pam.org/Linux-PAM-html/sag-module-reference.html

muska96   8 #5 27.08.2016 16:14

Bardzo dobry wpis, jednak jest kilka literówek typu "Do puki...", ale mniejsza z tym. W sieci domowej mamy router, który nie pozwoli się połączyć do naszego ssh spoza sieci domowej, więc nie ma konieczności tak rozbudowanej ochrony, póki nie włączymy przekierowania portu SSH. Mam też drobne wątpliwości, jeśli chodzi o polecenia dla raspberry pi - najnowszy Raspbian pracuje już na systemd, więc znaczna część poleceń będzie taka sama jak dla Fedory/CentOSa.
Poza tym mam wrażenie, że wymienione sposoby są chaotycznie poukładane - spróbuj podzielić je na jakieś kategorie typu: Ustawienia w Iptables, Ustawienia w konfiguracji SSH, Przydatne programy do ochrony SSH itp.
Wpis na pewno się przyda. Bardzo obszernie i dobrze wytłumaczone.

Czarny Romek   5 #6 27.08.2016 16:32

Co mi przeszkadza niezabezpieczony serwer ssh dostępny tylko po LAN-ie?

kwpolska   5 #7 27.08.2016 17:10

> pi@raspberrypi:~ $ servic ssh status

literówka: service ssh status

lepiej z systemd: systemctl status ssh
albo nawet spróbować się połączyć: ssh localhost

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

Nie jest, jeśli mamy więcej niż jedną stację roboczą.

> Tak wiem, wiem można przesyłać pliki jednak to nie usprawiedliwia tego że masz nie zabezpieczone SSH - zmień to!

A co jak mam zabezpieczone?

themamuth   5 #8 27.08.2016 17:23

@makmk: Dziękuję za uwagi. Jednak mam dwie uwagi. Jak na to rozmówca zareaguje? Chciałbym poznać opinię?

http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap15s... odnosnie

" IgnoreUserKnownHosts yes

The option IgnoreUserKnownHosts specifies whether the ssh daemon should ignore the user's $HOME/.ssh/known_hosts during RhostsRSAAuthentication."

Jak plik ~/.ssh/know_hosts będzie miał kilka wpisów nie będzie wtedy bazą?
To nie związane z SSH ale... http://webmade.org/porady/baza-danych-oparta-na-plikach-php.php

themamuth   5 #9 27.08.2016 17:29

@muska96: Nie tylko gdy udostępniamy SSH na zewnątrz przydaje się zabezpieczenia. Kolega ustawił sobie na RPi OSMC. Jakie było jego zdziwienie gdy po mojej wizycie codziennie o 19:35 włączało się odtwarzanie z filmami z katalogu xXx. - często zapominamy w takich domowych projektach o bezpieczeństwie.

P.S dziękuje za uwagi błędy wychwycone poprawione :)

themamuth   5 #10 27.08.2016 17:32

@Czarny Romek: Mój komentarz do komentarza muska96. Dostęp do SSH nie zabezpieczonego często równa się dostępowi do root z domyślnym hasłem lub zmianie tego hasła po zalogowaniu się na sudo usera.

Dziękuję za opinie.

  #11 27.08.2016 17:34

I uważasz, że po tym artykule każdy sobie sam postawi serwer na linuxie? Dla większości osób problemem już będzie gdzie klepać komendy. Pisząc taki artykuł trzeba się zastanowić do kogo jest skierowany. Ktoś kto wiedzę gdzie to wszystko w klepać, nie potrzebuje tego artykułu. Słodzenie kolegów linuxowców, jaki to artykuł świetny jest oczywiście bezpodstawne.

ps. Nadal uważacie, ze linux jest prosty i dla każdego?

pat.wasiewicz   5 #12 27.08.2016 19:14

A ja tak nietechniczne: "Na problemy sierżant zawada" - obstawiłbym raczej "komisarz zawada" :D

grapeli23   5 #13 27.08.2016 19:18

Wpis typowy na dp - przedstaw zagadnienie (o tematyce około linuksowej) w formie najmniej przejrzystej, możliwie najbardziej zagmatwanej oraz dopraw to wiedzą trącącą myszką już 10 lat temu.

Czarny Romek   5 #14 27.08.2016 19:35

Ja szczególnie nie zabezpieczam dostępu ssh do mojego serwera. Hasło na roota mam 123abc, port domyślny - da się zalogować na roota tym hasłem. Problem tylko w tym, że do ssh można dostać się tylko wtedy, gdy zalogujemy się do mojej sieci OpenVPN, z odpowiednim certyfikatem i hasłem. W takiej konfiguracji nie boję się niczego. Poczta jest też tylko przez www.

To jest najlepsze zabezpieczenie - nie wystawiamy na zewnątrz żadnych usług, oprócz absolutnego minimum. U mnie to jest poczta i www. Reszta tylko za vpn-em, a mam jeszcze oprócz ssh gita, svn i masę innych usług.

Autor edytował komentarz w dniu: 27.08.2016 19:36
NieGooglujMnie   6 #15 27.08.2016 19:38

ok, themamuth został(eś) moim ulubionym blogerem na tym portalu ;)

wartość merytoryczna wpisów przerasta o lata świetlne pozostałych blogerów "linuxowych".

wpis można ładnie rozszerzyć też o coś z webmin ;)

np. jak najlepiej zabezpieczyć SSH przez webmina:
http://www.webmin.com/

Autor edytował komentarz w dniu: 27.08.2016 19:51
  #16 27.08.2016 20:24

Porada ograniczenia dostępu dla wybranego IP ma sens, jak ktoś ma niezmienne IP (co dotyczy raczej tylko garstki szczęśliwców z łączem domowym). W tej sytuacji lepsze jest blokowanie po kraju na bazie GeoIP, które opisałem na swoim blogu: http://monter.techlog.pl/blokada-dostepu-do-ssh-na-podstawie-bazy-geoip/

  #17 27.08.2016 20:52

Wielkie brawa za ten artykul. Oby wiecej bylo takich.

makmk   5 #18 27.08.2016 22:33

@themamuth: Co do 1 punktu to cytat z mana ssh:
"If a host's identification ever changes, ssh warns about this and disables password authentication to prevent server spoofing or man-in-the-middle attacks, which could otherwise be used to circumvent the encryption."
Natomiast IgnoreUserKnownHosts ma zastosowanie "during RhostsRSAAuthentication" czyli to szczególny przypadek.

Co do 2 to wg Wikipedii "A database is an organized collection of data.[1] It is the collection of schemas, tables, queries, reports, views, and other objects." czy plik z wrzuconymi kluczami jest taki "organized" ? Oczywiście kwestia punktu widzenia ale z mojego raczej nie.

  #19 27.08.2016 23:18

Natrudzisz się człeku, a później wystarczy, że połączysz się gdzieś spoza zaufanej strefy/sieci ... i cały misterny plan w PiSdoo :D Problemem może być bezproblemowe przechwycenie sesji ssh, o czym autor chyba nie wspomniał, bo zapuścił poradnik jakich w sieci całe multum (przez co nie chciało mi się tego czytać kolejny któryś tam raz). Poza tym, kiepski wpis, bo nawet nie wyjaśnił po co i na co wyłączyć opcje, które zaserwował na końcu. Bezmyślne wyłączenie czasem niesie bardziej opłakane skutki, niż ich pozostawienie...

themamuth   5 #20 27.08.2016 23:22

@makmk: dziękuję. Czekałem na Twoją ocenę, opinię . Tylko tyle :)

SpaceM7c5   6 #21 28.08.2016 00:04

Dobry artykuł na weekend :) Dzięki :)

  #22 28.08.2016 09:00

Widzę, że nie macie w zwyczaju publikowania nieprzychylnych, choć obiektywnych komentarzy. Wazelinujcie więc sobie nadal. Świetny artykuł. Zrozumiały dla wszystkich. Super. Czekam na więcej.

MacGregor   7 #23 28.08.2016 09:25

@grapeli23: Moja skromna rada: Jeżeli nie masz żadnego pojęcia o temacie i zagadnieniach poruszonych we wpisie, to go nie komentuj. To że ty nie masz żadnej wiedzy o tym i nic nie rozumiesz, nie znaczy że wpis jest zły. Tylko robisz z siebie bezmyślnego hejtera.

edmun   12 #24 28.08.2016 10:18

pozwoliłem już sobie to skopiować i zrobić to do pdf'a. Jak znajdę odrobinę czasu w pracy to na spokojnie sobie przeczytam i zaaplikuje co poniektóre rady

  #25 28.08.2016 10:27

Zdaje sie ze autor troche poszalal z kluczami publicznym i prywatnym. Zdaje sie, ze zgodnie ze specydikacja transmisja zawsze szyfrowana jest publicznym a deszyfrowana prywatnym. Nie slyszalem jeszcze o technice szyfrowania prywatnym aby deszyfrowac publicznym. Zreszta co to mialoby na celu? Szyfrwac nieznanym kluczem aby kazdy mogl deszyfrowc. Do tego zdaje sie jest podpis cyfrowy, ten faktycznie tak dziala, ale na pewno nie rsa ani nic pokrewnego.

enkidu   2 #26 28.08.2016 10:31

Dobry wpis - tutorial właściwie :) Nie bardzo rozumiem jednak jak wyłączenie adresacji ipv6 w sieci lokalnej miałoby zwiększyć bezpieczeństwo?

__Tux__   12 #27 28.08.2016 10:44

Wszystko fajnie. Nie żebym się czepiał, ale mam pytanie: "Bezpieczeństwa systemów informacyjnych..." - co właściwie ludzie mają na myśli pod hasłem "system informatyczny"? Według definicji z wiki, pod to hasło można podpiąć wszystko, nawet Internet.
A ten obrazek z Ubuntu, nie wiem jaki ma związek kobieta dłubiąca w nosie :-) .

Shiroi   6 #28 28.08.2016 10:45

Właśnie takie wpisy uwielbiam czytać! Co prawda, dodałbym kilka drobiazgów, bo chyba nastąpiły drobne skoki myślowe, ale oceniam to na 9.9/10 pkt :D

Drogi Panie autorze, @themamuth czekam na kolejną odsłonę Pana bloga :D

Pozdrawiam :D

themamuth   5 #29 28.08.2016 11:22

@enkidu: Zabezpieczenia, które robisz na ruterze w sieci na urządzeniach odnoszą się albo do adresaci IPv6 lub do IPv4. Dla przykładu Fail2ban nie wspiera IPv6 więc jeżeli masz aktywny ten protokół to ataki BF można przeprowadzić po IPv6 nawet gdy masz zabezpieczone IPv4. Tak samo wpisy do iptables robisz osobno dla IPv6 i IPv4. Ja jestem zdania, że jeżeli czegoś nie wykorzystujesz to wyłącz to. A jeżeli jest Ci potrzebne to zabezpiecz to.

themamuth   5 #30 28.08.2016 11:29

@__Tux__: Trzeba to rozumieć bardzo ogólnie. Jeżeli ty w domu masz własny serwer VPN to staraj się go zabezpieczyć i monitoruj go cały czas po przez aktualizacje, reakcje na exploity czy inne zagrożenia do protokołów używanych przez ta usługę. Tak samo w pracy jak zarządzasz siecią czy baza danych itp.

To jest palec przytkany do ust wyłaniającej się z cienia kobiety. Czyli coś jak włamywacz, który bokiem omija nasze zabezpieczenia.

Bardzo lubię wszelkie odmiany Debiana.

themamuth   5 #31 28.08.2016 11:32

@Shiroi: Nie chciałem by wpis stał się "how to" jak krok po kroku zabezpieczać swoje środowisko SSH. Ale by pobudził myślenie i przy czytaniu zachęcić czytelnika do szukania wszelkich sposobów na zabezpieczenie.

Czekam na wszelkie uwagi konstruktywne i te mniej :) na wszystko co pomoże pisać jeszcze lepsze wpisy.

themamuth   5 #32 28.08.2016 11:39

@kwpolska: Jeżeli jest potrzebne Ci SSH na stacjach roboczych to zabezpiecz je. Jeżeli masz zabezpieczone to super. Pamiętaj tylko że musisz monitorować te zabezpieczenia czasami nawet 24 godziny na dobę.

clubber84   4 #33 28.08.2016 12:03

@__Tux__: Ta kobieta przykłada palec do ust wypowiadając: "ciii..."
Czyli bądź anonimowy w sieci dla "crackerów" i "hakerów", poprzez zabezpieczanie zewnętrznego dostępu do swoich usług dla niepowołanych osób.

NieGooglujMnie   6 #34 28.08.2016 12:47

co do bezpieczeństwa, to jak ktoś się kisi w LAN/Virtualbox to zupełnie nie to samo. Fakt jest taki, że w sieci trwa wojna, wojna botnetów (coś jak e-cyborgi z terminatora).

jak wypuszczamy dowolną usługę na świat i otwieramy jakikolwiek port w firewallu, to do 30 minut przyjdzie bot i zacznie skanować.
np. u mnie wyciąg logów z maja 1 :
no więc adres IP "125.91.13.2" to są takie ładne Chiny ( Guangdong) . No i bocik z tego adresu próbował wejść na SSH na różnych portach, np. na użytkownikach: syslog, icnanker, nano, shadmin...

log:

May 1 12:59:44 tiptup sshd[6776]: Received disconnect from 125.91.13.2 port 47293:11: Bye Bye [preauth]
May 1 12:59:44 tiptup sshd[6776]: Disconnected from 125.91.13.2 port 47293 [preauth]
May 1 12:59:47 tiptup sshd[6778]: Received disconnect from 125.91.13.2 port 48332:11: Bye Bye [preauth]
May 1 12:59:47 tiptup sshd[6778]: Disconnected from 125.91.13.2 port 48332 [preauth]
May 1 12:59:49 tiptup sshd[6784]: Invalid user shadmin from 125.91.13.2
May 1 12:59:49 tiptup sshd[6784]: input_userauth_request: invalid user shadmin [preauth]
May 1 12:59:49 tiptup sshd[6784]: Received disconnect from 125.91.13.2 port 49355:11: Bye Bye [preauth]
May 1 12:59:49 tiptup sshd[6784]: Disconnected from 125.91.13.2 port 49355 [preauth]
May 1 12:59:51 tiptup sshd[6786]: Invalid user icnanker from 125.91.13.2
May 1 12:59:51 tiptup sshd[6786]: input_userauth_request: invalid user icnanker [preauth]
May 1 12:59:52 tiptup sshd[6786]: Received disconnect from 125.91.13.2 port 50381:11: Bye Bye [preauth]
May 1 12:59:52 tiptup sshd[6786]: Disconnected from 125.91.13.2 port 50381 [preauth]
May 1 12:59:54 tiptup sshd[6794]: Invalid user nano from 125.91.13.2
May 1 12:59:54 tiptup sshd[6794]: input_userauth_request: invalid user nano [preauth]
May 1 12:59:54 tiptup sshd[6794]: Received disconnect from 125.91.13.2 port 51303:11: Bye Bye [preauth]
May 1 12:59:54 tiptup sshd[6794]: Disconnected from 125.91.13.2 port 51303 [preauth]
May 1 12:59:57 tiptup sshd[6796]: Received disconnect from 125.91.13.2 port 52360:11: Bye Bye [preauth]
May 1 12:59:57 tiptup sshd[6796]: Disconnected from 125.91.13.2 port 52360 [preauth]
May 1 12:59:59 tiptup sshd[6801]: Received disconnect from 125.91.13.2 port 53291:11: Bye Bye [preauth]
May 1 12:59:59 tiptup sshd[6801]: Disconnected from 125.91.13.2 port 53291 [preauth]
May 1 13:00:02 tiptup sshd[6803]: Received disconnect from 125.91.13.2 port 54295:11: Bye Bye [preauth]
May 1 13:00:02 tiptup sshd[6803]: Disconnected from 125.91.13.2 port 54295 [preauth]
May 1 13:00:04 tiptup sshd[6806]: Invalid user syslog from 125.91.13.2

Oczywiście proste zgadywanie hasła to pikuś. Generalnie w ciągu godziny mając rozwinięte serwery/usługi można spodziewać się kilkunastu-dziesięciu-setek ataków ze strony botnetu (skanowanie, próba exploitów). Takie są realia, bo w internecie trwa wojna.
Hacker siada za sterami najczęściej jak botnet coś zrobił, czyli dopiero w 2giej kolejności pojawia się żywy człowiek.

Autor edytował komentarz w dniu: 28.08.2016 13:03
bart86   9 #35 28.08.2016 13:52

Super wpis :)

pocolog   11 #36 28.08.2016 14:19

Fajny wpis. Dawno nic nie było o SSH.

bart86   9 #37 28.08.2016 16:00

zmieniłem port ssh i u mnie żadne boty nie próbują się wbić, na port 80 też nic

tarantul   3 #38 29.08.2016 09:21

@Czarny Romek: O włamaniu (celowym, lub przypadkowym) na Twój serwer:

Uczeni wyliczyli, że jest tylko jedna szansa na milion, by zaistniało coś tak całkowicie absurdalnego. Jednak magowie obliczyli, że szanse jedna na milion sprawdzają się w dziewięciu przypadkach na dziesięć.
Terry Pratchett (z książki Równoumagicznienie)

  #39 29.08.2016 16:42

widzę ze się uczycie podstaw hakerki korzystając z Pythona i nmapa. Polecam czytnikom kali.org tam znajdziecie więcej dziwnych programow

  #40 29.08.2016 16:57

jedno pytanie, w jaki sposob dodać inne szyfrowanie do obecnego?
powiedzmy chcę zwykłe symetryczne szyfrowanie, co jakiś czas po prostu bede je zmieniał. Powiedzmy 16 znaków co 1M danych.
Hasełka moge sobie wygenerować lub mogę mieć plik. Nie ważne, jak DODAC jeszze jedno szyfrowanie do już istniejacego?

Shiroi   6 #41 29.08.2016 19:01

@themamuth: No wiesz, ja to rozumiem, bo nie ma nic gorszego niż bezmyślne ctrl+c oraz crtl+v a potem pretensje typu *kilka wyzwisk* + " zrobiłem tak jak pokazałeś, a mi się źle stało". How to, jest fajne, jeśli ktoś wie co robi.

Czy mogę Cię pomęczyć troszkę na PW na temat SSH i innych rzeczy związanych z tematem?

themamuth   5 #42 29.08.2016 21:11

@Shiroi: Pewnie pisz :)

  #43 29.08.2016 22:46

Nie z przymiotnikami razem, czyli "nieudane", a nie "nie udane".

Shiroi   6 #44 31.08.2016 20:55

@themamuth: z miłą chęcią to zrobię. Jak tylko wyczaję jak :P

  #45 05.09.2016 02:09

@Anonim (niezalogowany): "ps. Nadal uważacie, ze linux jest prosty i dla każdego?"

ale zabawa w serwery nie jest dla każdego to i artykuł nie jest kierowany do każdego. Stawianie serwera na windowsie to jest dopiero atrakcja, cała dokumentacja tego korporacyjnego sztiftu to jakaś kpina..

@themamuth no ładnie wyczerpałeś temat :)
osobiście nie dzierżę fail2bana, zbędny, bezużyteczny gadżet, wystawka ssh na pięciocyfrowy port praktycznie udaremnia 99% ataków, które są przeważnie jakimiś chińskich skanerami, a ten jeden procent hipotetycznych ataków wymierzonych celowo na naszą maszynę z pewnością skutecznie udaremni kontrola dostępu w host.deny/hosts.allow i logowanie kluczem na konto z ograniczeniami.

  #46 05.09.2016 02:28
  #47 05.09.2016 02:31

@bart86: to są ataki na konkretne łącza a nie jakieś małe vpsy hostowane w pierdziszewie

bart86   9 #48 06.09.2016 06:22

@Anonim (niezalogowany): na port 22 boty z Chin lecą cały czas i to wszędzie

  #49 07.09.2016 23:15

@NieGooglujMnie: no niby taki zawodowiec a nie potrafi przypiąć spam filtera nosz kurwa! jak to tak?

  #50 07.09.2016 23:19

@bart86: na te boty z chin i na cały zbadany botnet grasujący w sieci są aktywne listy SBL, trza se przypiąć do netfiltera to oczywiste...

  #51 07.09.2016 23:25

themamuth, bardzo dobry art, może uświadomi niektórych idiotów wystawiających ssh na pastwę losu, pal sześć ich cyrk ale zazwyczaj na dzierżawionym vpsie po przejęciu konta takiego lamera pada całe łącze i dostają po dupie klienci...

themamuth   5 #52 08.09.2016 14:18

@dźejson (niezalogowany): Rozbraja mnie czasami myślenie ludzi, którzy twierdzą, że znają się na informatyce, albo jak to mówią ich syn chodzi własnie do liceum informatycznego i według jego opinii... (jest to smutne ale to real) ...takie zabezpieczenia są wystarczające.

Wtedy rzucam przykładem, że jest to wystawianie gołej dupy za okno... Często leci riposta "...to moja dupa i niech sobie na nią patrzą..."
A ja po prostu dalej kończę ... za okno, w które rzucają gwoździami i żyletkami.

Niestety czasami na reakcję jest już za późno i często trzeba stawiać środowisko od nowa... Tak jak ostatnio z życia wzięte ... kolega wywyższający się, że wie lepiej wystawił publicznie nie zabezpieczoną Joomle do testów, a co gorsza na serwerze pod, które IP jest podpiętą domena i poczta. Po paru miesiącach działania dostał bana na pocztę/domenę/IP za słanie spamu... FacePalm

Johnathan   4 #53 12.09.2016 11:49

@Czarny Romek: Cześć, stawiam sobie serwer domowy i myślałem właśnie, żeby puścić SSH przez OpenVPN. Masz może jakiś link do dobrego poradnika jak to zrobić? Będę wdzieczny za wszelkie rady ;) Lubie się uczyć od bardziej doświadczonych kolegów.

themamuth   5 #54 12.09.2016 13:47

@Anonim (niezalogowany): Uważam że jest dla każdego... Tylko nie dla każdego są oferowane przez niego usługi.

themamuth   5 #55 13.09.2016 14:34

@pat.wasiewicz: Hej to było świadome posunięcie :) ...

themamuth   5 #56 14.09.2016 10:14

@Czarny Romek: Często jak nie zwracamy uwagi na takie szczegóły jak zabezpieczyć SSH w lokalnej (lub ogólnie zabezpieczenia w sieci lokalnej) sieci też nie zauważymy luk w jak to powiedziałeś w masie innych usług.

Czym skorupka za młodu nasiąknie tym na starościc trąca... jakie proste słowa a jakie mądre.