-15% na nową książkę sekuraka: Wprowadzenie do bezpieczeństwa IT. Przy zamówieniu podaj kod: 10000

Kilka pomysłów na bezpieczny serwer linuksowy

15 września 2017, 15:15 | Aktualności, Teksty | komentarzy 29

Materiał pochodzi z Linux Magazine 3 2016 (145).

Konfigurując nowy serwer linuksowy, warto podjąć kilka dodatkowych kroków, aby mieć pewność naprawdę bezpiecznego systemu.

Niedawno zrezygnowałem z fizycznego serwera na rzecz systemu opartego na chmurze. Proces rejestracji przebiegł bezboleśnie – może poza koniecznością podania danych karty kredytowej – i po chwili mogłem się cieszyć nowym serwerem z Debianem 8.1 Jessie ze statycznym adresem IPv4.

Niezwykle rzadko zdarza mi się ręcznie budować serwery od podstaw. Ponieważ jednak opisywany w przykładzie system ma służyć jako serwer roboczy, warto przyjrzeć się czynnościom, jakie wykonałem, aby go zabezpieczyć. Przedstawione kroki w dużej mierze wynikają z osobistych upodobań, ale stanowią dobry punkt wyjścia przy budowie własnego systemu bezpieczeństwa. Lista z pewnością nie wyczerpuje wszystkich możliwości (jest ich po prostu zbyt dużo, aby dokładnie je omówić), ale może zasugerować nam rozwiązania niebrane wcześniej pod uwagę.

Opisane w artykule instrukcje pokazują, jak skonfigurować od podstaw serwer z Debianem Jessie. Jak zawsze chodzi o zminimalizowanie liczby pakietów, aby zredukować potencjalne luki w zabezpieczeniach i ograniczyć ilość aktualizacji. Przykład pokazuje, jak wzmocnić zabezpieczenia pojedynczego serwera z Debianem – zapewnienie ochrony całej sieci wymaga wielu dodatkowych czynności, w tym zadbania o bezpieczeństwo routerów, zapór sieciowych, systemów zapobiegania włamaniom i wielu innych.

Usługi

Do uzyskania zdalnego dostępu do serwerów zwykle sprawdzają się klucze SSH. Po zmianie adresu DNS na statyczny IP oferowany przez dostawcę chmury, logujemy się do systemu przez SSH i od razu zmieniamy hasło root na takie, które spełnia nasze wymagania (i nie jest przesyłane drogą mailową). Warto sugerować dostawcom chmur, by dostarczali hasła root za pośrednictwem interfejsu webowego (używającego HTTPS); e-mail jest niezwykle niebezpieczny, a przecież chodzi o nową instalację serwerową, która ma być godna zaufania przez długi czas. Zaleta polega na tym, że dostawca przynajmniej zachęca do utworzenia klucza SSH.

Zalogowawszy się przez SSH jako root, przystępujemy do pracy. Pod żadnym pozorem nie powinniśmy logować się przez SSH jako superużytkownik, jeśli wcześniej nie utworzyliśmy użytkownika z mniejszymi uprawnieniami, który w razie potrzeby wpuści nas do systemu.

Wzmacnianie zabezpieczeń maszyny zaczynamy od wyłączenia wszystkich usług otwierających porty z wyjątkiem serwera SSH, uruchamiając polecenie:

# lsof -i | grep LISTEN

Wynik wyświetla dwie kolumny: w lewej są nazwy usług (przeważnie związane z nazwami plików start/stop z katalogu /etc/init.d), a w prawej – otwarte przez nie porty sieciowe widniejące zwykle na liście jako nazwy usług przetłumaczone z liczb przez plik /etc/services.

Uwagę przykuwają w przykładzie dwie niepożądane usługi mogące zagrażać bezpieczeństwu. Za uruchomienie pierwszej odpowiada pewnie /etc/init.d/rpcbind; szybko ją wyłączamy:

# systemctl stop rpcbind

dodając polecenie zakazujące rpcbind ponownego uruchamiania się po restarcie:

# systemctl disable rpcbind

Kolejny otwarty port sugeruje w końcu, że winna jest uruchamiana podczas startu usługa Systemd o nazwie nfs-common. Wyłączamy ją jak poprzednio, zastępując rpcbind jej nazwą.

W razie kłopotów (jeśli nie używamy wersji polecenia lsof z Debiana Jessie, ale z innej dystrybucji) możemy spróbować zmodyfikować polecenie:

lsof -i | grep LISTEN | awk '{print $1,$3}'

rpcbind rpc
master root
sshd root
httpd root
httpd apache

Działa ono w przykładzie z Debianem Jessie. Wyszukuje wszystkie nasłuchujące usługi i wyświetla ich nazwy wraz z kontami użytkowników odpowiedzialnymi za jej uruchomienie. Polecenie lsof z wyjątkiem wyłączania usług może służyć do eksperymentów z przenoszeniem usług do bezpieczniejszych kont użytkowników. Metodą prób i błędów możemy skutecznie przełączyć niektóre usługi na inne konta, podnosząc bezpieczeństwo.

Ssshhhh

Kolejny krok polega na przeniesieniu demona SSH sshd ze zbyt przewidywalnego portu 22 na inny. W tym celu ostrożnie edytujemy plik /etc/ssh/sshd_config, odkomentowując początkowy wiersz (Rysunek 2) i zmieniając 22 na wybrany numer portu – na przykład 2222, co zapobiega zautomatyzowanym atakom na port 22.

Rysunek 2: Na początku pliku sshd_config zmieniamy istniejący port na 2222 lub inny, odkomentowując wiersz poprzez usunięcie znaku #.

Dodatkowo blokujemy logowanie użytkownika root parametrem PermitRootLogin z wartością no:

PermitRootLogin no

Przechodzimy do utworzenia mniej uprzywilejowanego użytkownika. Wcześniej jednak upewniamy się, że logować się zdalnie mogą tylko wybrani użytkownicy – dodajemy do pliku konfiguracyjnego SSH (na początku, by pamiętać o zmianach przy następnym otwarciu pliku) polecenie:

AllowUsers lionel, luis, neymar

Teraz przez SSH mogą się logować tylko trzej użytkownicy – tworzymy ich konta, zanim się wylogujemy lub zrestartujemy serwer OpenSSH; inaczej ryzykujemy utratę dostępu do systemu:

# adduser lionel

Dalsze zabezpieczanie pliku SSH to temat na osobny artykuł; zdecydowanie jednak warto je wykonać i zrozumieć wprowadzane zmiany. Aby zatwierdzić zmiany, restartujemy sshd:

# systemctl restart ssh

Możemy przeprowadzić szybki test, aby się upewnić, że SSH nadal pozwala nam się logować, i otworzyć dziennik systemowy (w tym wypadku plik /var/log/messages). Wciąż powinniśmy zapoznać się z błędami Systemd, ale nie widać w pliku nic powiązanego z wprowadzonymi zmianami, więc na razie nie ma powodu do zmartwień.

Otwieramy plik /etc/hosts.allow, by usunąć wszystko, co niewykomentowane, i dodać swój adres IP:

sshd: 11.22.33.44, 123.123.123.123, 9.8.7.6

Od teraz przez SSH mogą się logować tylko trzy adresy IP, a nazwa użytkownika powinna być jedną z wcześniej utworzonych – na przykład lionel. Dodajemy wiersz do hosts:deny:

sshd: ALL

I gotowe. Pamiętajmy, aby nie zamykać okna logowania, nie przetestowawszy logowania się przez SSH.

Historia poleceń

Przewijanie historii poleceń znacznie przyspiesza użycie klawiszy [PageUp] i [PageDown]. Wprawdzie nie jest to związane z bezpieczeństwem, ale pozwala nam sprawniej się poruszać po wierszu poleceń.

Na Rysunku 3 znajdują się dwa wiersze pliku /etc/inputrc, które odkomentowujemy. Zmiany zostają wprowadzone przy kolejnym rozruchu.

Rysunek 3: Pisanie w wierszu poleceń możemy przyspieszyć, używając przycisków [PageUp] i [PageDown].

Home, sweet home

Nie wszystkie dystrybucje domyślnie zaostrzają ograniczenia w dostępie do katalogów domowych. Zakładamy, że nasza nazwa użytkownika to lionel, luis i neymar mają nie widzieć plików z naszego katalogu domowego. Aby zablokować innym użytkownikom dostęp do katalogu domowego, możemy uruchomić z uprawieniami root polecenie:

# chmod -R 750 /home/lionel

Chcąc z kolei zablokować dostęp do wszystkich katalogów domowych, wystarczy użyć symbolu gwiazdki zamiast nazwy użytkownika.

Hej, panie listonoszu!

Następny krok to instalacja i skonfigurowanie narzędzia Logwatch [1], abyśmy codziennie otrzymywali podsumowanie najważniejszych zdarzeń. Wykonanie tych kilku prostych czynności da nam również w pełni funkcjonalny serwer SMTP. Oczywiście, z powodu ram artykułu, polecenia omówione są w dużym skrócie; jeśli jednak nie mamy pewności, co robić, lepiej, przyjrzeć im się bliżej.

Instalujemy Postfiksa:

# apt-get install postfix

Podczas procesu konfiguracji wybieramy Internet Site i dodajemy pełną nazwę hosta (w tym FQDN). Możemy wprowadzić szybką zmianę w pliku /etc/aliases, aby na prywatny adres e-mail otrzymywać wiadomości wysyłane do użytkownika root – edytujemy plik aliases i dodajemy adres zewnętrzny:

# pico -w /etc/aliases

Upewniamy się, że wiersz zaczynający się od root: wygląda analogicznie:

root: chris@binnie.tld

Aktualizujemy plik aliasów, wywołując polecenie newaliases:

# newaliases

Na koniec instalujemy pakiet Logwatch:

# apt-get install logwatch

Logwatcha najłatwiej wywołać, tworząc zadanie crona uruchamiane codziennie o tej samej porze (cron.daily); czas możemy określić w pliku /etc/crontab. Alternatywnie możemy przenieść plik /etc/cron.daily/00logwatch w inne miejsce i uruchomić go w innym czasie ustawionym pliku /etc/crontab.

Uruchamiamy Logwatcha i sprawdzamy skrzynkę:

# /etc/cron.daily/00logwatch

Wyniki są bardzo przydatne. Więcej na temat monitorowania plików dziennika przy użyciu Logwatcha [2].

Logwatch dostarcza użyteczne informacje na temat systemu (w tym wykorzystania miejsca na dysku, logowania się przez SSH, nowych użytkowników i grup, restartowanych usług i podejrzanych wpisów w plikach dziennika). Dodatkowo tworzy listę pakietów zainstalowanych od instalacji minimalnej, dzieląc je w praktyczny sposób na Zainstalowane, Zaktualizowane i Usunięte. Listy archiwizowane w skrzynce e-mail z tematem wiadomości Logwatch dla <nazwa_hosta> (Linux) to doskonały punkt odniesienia na przyszłość. W razie rozbieżności między dwoma serwerami spowodowanymi różnymi wersjami pakietów lub funkcjami sprawdzenie, w jaki sposób są skompilowane, zajmuje najwyżej dwie minuty.

Nie chcąc, aby użytkownik root bezpośrednio otrzymywał pocztę za pośrednictwem naszego pliku aliases, w pliku konfiguracyjnym /etc/logwatch/conf/logwatch.conf możemy dodać MailTo = adres e-mail. Jeżeli plik nie istnieje, tworzymy go.

Warto przy okazji wspomnieć, jak zabezpieczyć nowy serwer SMTP. Nawet gdy domyślnie włączone jest przekazywanie (ang. relaying), wciąż powinniśmy podjąć pewne kroki, aby zapewnić bezpieczeństwo serwera poczty. Interesujący post znajduje się na stronie Ask Ubuntu [3].

Hasła

Jeśli na serwer mają się logować inni użytkownicy, powinniśmy zadbać o bezpieczeństwo haseł. Jeżeli mieliśmy styczność z listą najpopularniejszych haseł, wiemy, dlaczego administratorzy tak bardzo obawiają się dopuszczać do systemów serwerowych zwykłych użytkowników [4].

Skala stosowania słabych haseł nie wróży dobrze, zwłaszcza jeśli dostępu do serwera nie blokujemy po adresach IP lub przy użyciu innej metody. Gdy użytkownicy mogą się logować przez SSH z dowolnego adresu, a nie zablokowaliśmy serwera lub nie wprowadziliśmy zasad tworzenia haseł, istnieje ryzyko zautomatyzowanych ataków słownikowych. Na szczęście Linux pozwala wzmocnić reguły haseł przy użyciu zaawansowanego pakietu libpam-cracklib.

Konfiguracja sprawdza się na systemie Debian Wheezy. Instalujemy libpam-cracklib:

# apt-get install libpam-cracklib

Edytujemy plik:

# pico -w /etc/pam.d/common-password

Zmieniamy wiersz:

password requisite pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=2 ocredit=2

przy użyciu wymaganych ustawień (lepiej go odkomentować, zamiast usuwać, aby w razie potrzeby móc go przywrócić). Konfiguracja ogranicza do dwóch liczbę prób zalogowania się i wymaga hasła złożonego z przynajmniej dziesięciu znaków. Ustawienie difok=6 (denerwujące kolegów) umożliwia ponowne wykorzystanie w bieżącym haśle tylko sześciu znaków występujących w poprzednim, dwa ostatnie powinny być przynajmniej dwoma cyframi i dwoma symbolami (lub znakami specjalnymi).

Aby włączyć te ustawienia (na Wheezy), piszemy:

# pam-auth-update

Teraz możemy wypróbować kilka testów – ostrożnie, abyśmy mogli zalogować się na konto z powrotem. W razie problemów możemy sprawdzić, czy plik /etc/ssh/sshd_config zawiera UsePAM yes. Po zmianie konfiguracji uruchamiamy ponownie serwer OpenSSH poleceniem systemctl restart ssh.

Tabela 1 zawiera podsumowanie opcji wymuszających stosowanie silniejszych haseł zaczerpnięte z instrukcji pam_cracklib. Możemy eksperymentować z ustawieniami do woli.

Tabela 1: Opcje wymuszania haseł Crackliba
Opcja Opis
retry=N Informuje użytkownika najwyżej N razy przed zwróceniem błędu. Wartość domyślna N wynosi 1.
difok=N Liczba znaków, które muszą być zmienione w stosunku do poprzedniego hasła (domyślnie 5).
minlen=N  Minimalna akceptowalna długość nowego hasła; więcej informacji zawiera instrukcja.
 dcredit=N   (N0) Maksymalna liczba punktów za użycie cyfr w nowym haśle. Jeśli hasło ma N lub mniej znaków, każdy znak to +1 punkt do bieżącej wartości minlen. Domyślna wartość dcredit wynosi 1; zalecana wartość minlen – mniej niż 10. (N < 0) Minimalna liczba cyfr w nowym haśle.
 ucredit=N  (N0) Maksymalna liczba punktów za użycie w nowym haśle wielkich liter. Jeśli hasło zawiera N lub mniej wielkich liter, każdy znak to +1 punkt do bieżącej wartości minlen. Domyślna wartość ucredit to 1 – zalecana przy minlen mniej niż 10. (N < 0) Minimalna liczba wielkich liter w nowym haśle.
 lcredit=N  (N0) Maksymalna liczba punktów za użycie małych liter w nowym haśle. Jeśli w haśle jest N lub mniej małych liter, każda litera to +1 punkt do wartości minlen. Domyślna wartość lcredit to 1, zalecana wartość minlen – mniej niż 10. (N < 0) Minimalna liczba małych liter w nowym haśle.
 ocredit=N  (N0) Maksymalna liczba punktów za użycie w nowym haśle innych znaków. Jeśli hasło ma N lub mniej innych znaków, każdy znak to +1 punkt do bieżącej wartości minlen. Domyślna wartość ocredit to 1, zalecana przy minlen mniej niż 10. (N < 0) Minimalna liczba innych znaków w nowym haśle.
minclass=N  Minimalna liczba wymaganych klas znaków dla nowego hasła, domyślnie 0. Są cztery rodzaje klas: cyfry, duże i małe litery oraz inne znaki.
 maxrepeat=N  Odrzuca hasła zawierające więcej niż N jednakowych występujących po sobie znaków, domyślnie 0 (wyłączony test).
 maxsequence=N  Odrzuca hasła z monotonicznymi sekwencjami znaków (na przykład 12345 lub fedcb) dłuższymi niż N, domyślnie 0 (czyli test jest wyłączony).
 maxclassrepeat=N Odrzuca hasła zawierające więcej niż N występujących po sobie znaków tej samej klasy, domyślnie 0 (czyli test jest wyłączony).
 reject_username  Odrzuca hasło, które zawiera nazwę użytkownika w zwykłej lub odwróconej kolejności.
 gecoscheck  Odrzuca hasło, które zawiera ciągi z pola GECOS (zwykle pełna nazwa użytkownika) dłuższe niż 3 znaki w zwykłej lub odwróconej kolejności.
enforce_for_root  Komunikat o błędzie lub nieudanej próbie testu uniemożliwia użytkownikowi root zmianę hasła. Opcja domyślnie wyłączona: komunikat o nieudanej próbie przeprowadzenia testu jest generowany, ale root i tak może zmienić hasło.
 authtok  Argument zakazuje modułowi prosić użytkownika o nowe hasło, by użyć hasła dostarczonego przez wcześniejszy moduł haseł.

Chcąc pójść krok dalej, możemy wprowadzić własne słowniki dla Crackliba. W Sieci znajdziemy dość stary, ale dobrze napisany artykuł na temat używania Crackliba w połączeniu z Django [5].

Inne pomysły

Dalsze kroki mogą obejmować monitorowanie systemu plików. Dla najważniejszych plików możemy utworzyć sumy kontrolne MD5, z którymi będziemy porównywać pliki w razie podejrzenia ataku. Możemy też zainstalować narzędzie sprawdzające integralność systemu plików – na przykład AIDE (ang. Advanced Intrusion Detection Environment), by monitorowało za nas zmiany.

Do wykrywania niepożądanych usług możemy też skonfigurować IPTables sprawdzające, czy na systemie są uruchomione usługi wyzwolone na skutek ataku lub błędnej konfiguracji.

Bronić się przed atakami pozwala również pukanie w porty (ang. Port Knocking) [6]

  • technika umożliwiająca zablokowanie portu serwera SSH dla świata zewnętrznego
  • wyłącza pingi, czyniąc serwer całkowicie niewidocznym; jedynym sposobem obudzenia serwera SSH jest połączenie się z określoną sekwencją portów.

Jeśli użytkownicy mają zdalny dostęp przez sFTP, możemy im go ograniczyć poprzez zmuszenie ich do pracy wewnątrz katalogu domowego i zablokowanie możliwości wykonywania innych poleceń systemowych. W tym celu wystarczy skonfigurować środowisko sFTP chroot [7].

Możemy też skorzystać z narzędzia, które automatycznie analizuje i blokuje system, raportując o problemach związanych z bezpieczeństwem, jak rozwiązania do audytu bezpieczeństwa pokroju Bastille Linuksa czy Lynisa.

Zaleta narzędzi takich, jak Bastille Linux i Lynis, polega na tym, że przyspieszają proces wzmacniania zabezpieczeń i nie wymagają szczegółowej wiedzy na ten temat. Z drugiej jednak strony sprawia to, że administratorzy tracą zainteresowanie bezpieczeństwem systemu, a tym samym korzyści samodzielnego wzmacniania bezpieczeństwa systemu, pomijając już, jak łatwo wpisać Y i przypadkowo uczynić system bezużytecznym, nie rozumiejąc, o co pyta nas aplikacja.

Niekończąca się historia

Bezpieczeństwo zależy nie tylko od konfiguracji serwera. Naszej uwagi wymagają również inne komponenty sieci. Na przykład powinniśmy sprawdzić obecność na systemie niebezpiecznych plików z uprawnieniami SETUID, z pewnością chcąc ograniczyć ich liczbę.

Jeśli mamy obawy, możemy poeksperymentować z poleceniem:

find / -xdev \( -perm -4000 \) -type f -print0 | xargs -0 ls -hal

Nieprzyjemne niespodzianki z bitem s możemy usunąć:

# chmod -s /home/chrisbinnie/nasty_file

Aby jeszcze bardziej wzmocnić bezpieczeństwo systemu plików, możemy rozważyć instalację SELinuksa. Warto też rzucić okiem na zalecenia amerykańskiej Narodowej Agencji Bezpieczeństwa [10].

Instalując na serwerze Apacheʼa, możemy zacząć od ukrycia katalogu cgi-bin i zmiany ustawień ServerTokens na Prod. Świetny artykuł na temat podnoszenia bezpieczeństwa Apacheʼa znajduje się na stronie Geekflare [11].

Testowanie zabezpieczeń to niekończąca się historia. Jeśli chcemy dowiedzieć się więcej, możemy poczytać na temat stworzonego przez National Institute of Standards and Technology skanera OpenSCAP [12], którego działanie polega na „automatycznej weryfikacji obecności łatek, sprawdzaniu konfiguracji zabezpieczeń i analizowaniu systemów pod kątem występowania śladów włamań”.

Oby artykuł zachęcał do dalszego eksplorowania tematu bezpieczeństwa systemu. Warto budować i konfigurować systemy serwerowe, mając na uwadze bezpieczeństwo, szczególnie jeśli – wracając do nich później – chcemy je zastać działające tak samo w chwili pozostawienia.

Linki

  1. Logwatch: http://www.logwatch.org/ 
  2. Chris Binnie, Logwatch, „Admin Magazine” 25/2015: http://www.admin-magazine.com/Archive/2015/25/Lean-on-Logwatch/%28language%29/eng-US
  3. Zabezpieczanie Postfiksa na serwerze Ubuntu: http://askubuntu.com/questions/418340/how-to-secure-postfix-on-ubuntu-server
  4. 5 najczęstszych haseł ujawnionych: http://news.sky.com/story/1412124/revealed-the-top-25-most-common-passwords
  5. Wymuszanie silniejszych haseł przy użyciu Crackliba: http://thegarywilson.com/blog/2006/using-cracklib-to-require-stronger-passwords/
  6. Chris Binnie, Ochrona sieci przy użyciu Port Knockingu, „Admin Magazine” 23/2014: http://www.admin-magazine.com/Archive/2014/23/Port-Knocking
  7. Ograniczanie dostępu za pomocą więzień SFTP na Debianie i Ubuntu: https://www.linode.com/docs/tools-reference/tools/limiting-access-with-sftp-jails-on-debian-and-ubuntu
  8. Bastille Linux: http://bastille-linux.sourceforge.net/
  9. Lynis: https://cisofy.com/lynis/
  10.  Wytyczne NSA dotyczące bezpiecznej konfiguracji systemu operacyjnego: https://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/operating_systems.shtml
  11. Wzmacnianie zabezpieczeń serwera Apache: http://geekflare.com/apache-web-server-hardening-security/
  12. Portal OpenSCAP: http://www.open-scap.org/page/Main_Page 

Chris Binnie

Wydanie Linux Magazine jest na Allegro w wersji drukowanej (z dystrybucją Kali Linux na DVD) i elektronicznej.

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Pyth0n

    Warto dodać, że restart serwera SSH nie zmienia bieżącej sesji. Także testy czy można się zalogować po zmianach konfiguracji SSH robi się z drugiego okna, nie wylogowując się na pierwszym. Jeżeli jest coś nie tak, to poprawiamy konfigurację do skutku. Ergo – nie robimy tego przez łącze, które może „spaść”.

    PZDR

    Odpowiedz
    • ahahahhaah

      To się ustawia dwa porty. Wtedy restart lub zerwane połączenie nie mają znaczenia.

      Odpowiedz
      • asdf

        robi sie IaC a nie jakies reczne zmiany

        Odpowiedz
  2. MatM

    Wiem, że każdy admin ma swój sposób na konfigurację ale wydaje mi się, że dużo lepiej jest zablokować w SSH możliwość logowania przy pomocy haseł (PasswordAuthentication no) i używać wyłącznie kluczy (oczywiście zabezpieczonych hasłem). Przy takiej konfiguracji nie trzeba zmieniać domyślnego portu.

    Odpowiedz
    • q

      Ja akurat preferuje kerberosa.

      Odpowiedz
    • p

      Rozwiązanie z wyłączeniem uwierzytelniania na hasło byłoby najlepsze gdyby nie czynnik ludzki. Czasami potrzeba dać dostęp do shella lub sftp komuś, kto kompletnie nie rozumie kryptografii asymetrycznej i nie zamierza tego zrozumieć.

      Odpowiedz
      • ahahahhaah

        Jeśli użyszkodnik ma keyloggera lub innego wirusa podglądającego jego działalność to nie ma znaczenia czy używa kluczy, czy haseł.
        Banki wprowadziły papierowe kody jednorazowe do robienia przelewów. Nastepnie smsy. Niektóre tokeny.
        Najprostszym sposobem dla klientów jest live cd/usb i nie trzeba męczyć się z serwerami i jego zabezpieczeniami.

        Odpowiedz
  3. Z

    Jakiś łamaniec z tym lsof, wystarczy netstat -pln

    Odpowiedz
    • gosc

      No powinni rozbić na kilka artykułów.

      Taki przykład
      ========================================================
      # netstat -ntulp
      Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
      tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 9997/sshd
      tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 555/rpcbind
      ========================================================

      Ale czy napewno jest taki pakiet w systemie, jak to usunąć ?

      Sprawdzamy
      ============================
      # ps aux | grep rpcbind
      root 555 0.0 0.0 37080 2652 ? Ss Apr23 0:00 /sbin/rpcbind -w
      ============================

      ========================
      # dpkg -S /sbin/rpcbind
      rpcbind: /sbin/rpcbind
      ========================

      A jednak należy do pakietu rpcbind, no to usuwamy
      ===================
      apt-get remove rpcbind
      ===================
      albo lerpiej tak bo zostaną pliki konfiguracyjne niepotrzebnie
      ===================
      apt-get –purge remove nazwa
      ===================
      wtedy sprawdzic
      ============================
      dpkg -l | grep -E ^rc
      ============================

      Co jeszcze sprawdzić ?
      Załadowane moduły:
      ==================================================
      # systemctl list-units | grep -iE 'failed|not-found’
      ==================================================

      Odpowiedz
  4. Jacek

    Zmiana portu na inny niz 22 to żart :)
    To prawie tak jak mowienie ze sam NAT to taki firewall

    Odpowiedz
    • gosc

      Nie dokońca, zrób statystyki, może okazać się że 22 jest o wiele częściej przez boty sprawdzany.
      A najlepiej zrobić to co on, udostępnić ssh określnonym IP,
      albo zmusić system by do zapory sam dodawał zweryfikowane IP.

      Odpowiedz
    • @Jacek,
      autor słusznie zauważa że port zmieniamy z 22 na wyższy w celu zmniejszenia ilość *automatycznych* skanowań i logować przez automaty, których zadaniem jest logowanie do usługi SSH.
      Czy to jest zabezpieczenie same w sobie? NIE.
      Czy to jest dobra praktyka? TAK.

      Odpowiedz
    • ahahahhaah

      Zmiana portu to tylko zabezpieczenie przed skanerami.
      Za to zyskujesz czyste logi, bo automaty nie sprawdzają nietypowych portów.

      Odpowiedz
    • zibi

      W praktyce oznacza spadek liczby skanów prawie do zera.

      Odpowiedz
    • czesław

      Ja nie zmieniam portu tylko instaluje fail2ban, który dynamicznie tworzy regułkę w iptables po 3 nieudanych zalogowaniach.

      Odpowiedz
    • vanitas

      @Jacek – to nie żart. Zabezpiecza przed 98% skanerów usiłujących logować się na ssh…

      Odpowiedz
    • Paweł
      Odpowiedz
      • gosc

        „nie uda się w ten sposób ukryć SSH przed defaultowym skanem nmapem”
        To zalezy od umiejętności admina, a dokładniej Firewalla.
        Dlatego czekam na kolejne artykuły z serii
        ” Jak postawić bezpieczny serwer linuksowy ” . ;-)

        Odpowiedz
    • dx

      ssh na 22, bantime=tydzień
      fail2ban-client status sshd | grep banned
      |- Currently banned: 1535
      |- Total banned: 1536

      ssh na 70, bantime=tydzień
      fail2ban-client status sshd | grep banned
      |- Currently banned: 0
      |- Total banned: 3

      Odpowiedz
      • ahahahhaah

        Obadaj i po czasie pokaż statystyki:
        https://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html#comment-19302
        ###iptables -A INPUT -p tcp –dport 22 -j ACCEPT ### comment this line
        iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –name tcp22 –set
        iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –name tcp22 –update –seconds 5 –hitcount 2 -j DROP
        iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –name tcp22 –update –seconds 180 –hitcount 3 -j ACCEPT

        Głupie 5 sekund na wstrzymanie i boty padają.

        Odpowiedz
  5. rr

    @Z, lsofem łatwiej zaimponować laskom.

    Odpowiedz
  6. gosc

    ” Error: Time limit is exhausted. Please enter CAPTCHA value again. Click the BACK button on your browser, and try again. ”
    Uff można cofnąć stronę :-)

    Odpowiedz
  7. Tomasz21

    Witam;Bardzo interesujący materiał dla początkującego ,takiego jak ja.Można się dużo dowiedzieć na ciekawe tematy .Komentarze też dużo wnoszą do tematu.Bardzo potrzebny i przydatny materiał.Pozdrawiam.

    Odpowiedz
  8. Wujek Pawel
    Odpowiedz
  9. zero one

    Chmury’ bywają przepiękne. Kiedy śmigają nad naszymi głowami.
    Taka tam moja subiektywna opinia. ;-)
    Pozdrawiam.

    Odpowiedz
  10. dx

    Jeżeli serwer wystawia typowe usługi na typowych portach, które jakoś okresowo monitorujemy i jesteśmy w stanie określić wolumen ruchu, to warto wrzucić w iptables podstawowe regułki zabezpieczające przed SYN-floodem – zmora ostatnimi czasy…

    Odpowiedz
  11. omnomomo

    Super art, dzięki

    Odpowiedz
  12. draft

    Garnek miodu na TCP/22?

    Odpowiedz
  13. Fajne pomysły. Wypróbuję ;)

    Odpowiedz

Odpowiedz na Wujek Pawel