10.10.2016 | 07:15

Adam Haertle

Naucz się jak zabezpieczyć swój serwer, cześć 1: podstawy

W ostatnich miesiącach namawialiśmy Was do postawienia swoich własnych serwerów pełniących rolę usługi kopii bezpieczeństwa lub VPN. Przedstawione przez nas konfiguracje były bezpieczne, ale nadszedł czas, by je jeszcze trochę ulepszyć.

We współpracy z firmą ArubaCloud pokazaliśmy Wam, jak postawić swój serwer backupów, jak skonfigurować własny serwer VPN i podłączyć do niego komputer, telefony komórkowe oraz domowy ruter a także jak schować się przed cenzurą sieci. Dzisiaj zaczynamy cykl artykułów, w których pokażemy Wam, jak podnieść bezpieczeństwo Waszych serwerów w Arubie. Zaczniemy od podstaw, a w kolejnych odcinkach dodamy kolejne elementy zabezpieczeń.

Jeśli nie macie jeszcze swojego własnego serwera, to jest to dobra okazja by się w taki wyposażyć. Aruba oferuje dwa miesiące korzystania ze swojego podstawowego serwera gratis – a po zakończeniu promocji będzie on Was kosztował zaledwie 4 złote miesięcznie. Instrukcję jak krok po kroku skorzystać z promocji i uruchomić swój serwer znajdziecie w tym artykule. Jeśli macie już swój serwer – to zapraszamy do lektury kolejnych akapitów.

SSH bezpieczniej

Wszystkie poniższe instrukcje powinny działać na systemie CentOS7, który wykorzystywaliśmy przy poprzednich instrukcjach. Ćwiczenie zaczniemy od poprawy bezpieczeństwa usługi SSH. Co prawda jeśli wybraliście silne hasło roota to Wasz serwer raczej jest w większości przypadków bezpieczny, ale bez dodatkowej konfiguracji daleko mu do modelowego wdrożenia. Trochę go zatem podrasujemy.

Jeśli nie zmienialiście naszej domyślnej konfiguracji, to logujecie się za pomocą swojego hasła bezpośrednio na konto roota na porcie 22. Wszystkie elementy tej układanki poskładamy od nowa. Po pierwsze stworzymy nowego użytkownika, by nie logować się bezpośrednio zdalnie na roota. Dużo bezpieczniej jest konta roota używać tylko do czynności które go naprawdę wymagają, na co dzień korzystając z konta o niższych uprawnieniach. Dodamy zatem w naszym systemie nowego użytkownika i ustawimy mu nowe hasło.

useradd adam
passwd adam

Dodamy też użytkownika do grupy WHEEL by w razie potrzeby mógł wykonywać polecenia jako root.

usermod -aG wheel adam

Mamy teraz nowego użytkownika – możemy od razu się na jego konto zalogować. Gdy się zalogujemy (nowa sesja w PuTTy), to od razu utworzymy mu klucz SSH. I to klucz bardzo bezpieczny, używający kryptografii krzywych eliptycznych – a konkretnie lubianej i szanowanej krzywej Ed25519. Użyjemy także zabezpieczenia przed atakami typu bruteforce na hasło naszego klucza – na wypadek gdyby ktoś go nam ukradł i próbował nasze hasło do niego złamać. Wykorzystamy w tym celu funkcję bcrypt i na przykład 100 rund, by zniechęcić potencjalnego atakującego.

[adam@serwer ~]$ ssh-keygen -o -a 100 -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/adam/.ssh/id_ed25519):
Created directory '/home/adam/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/adam/.ssh/id_ed25519.
Your public key has been saved in /home/adam/.ssh/id_ed25519.pub.

Pobierzemy klucz na nasz komputer, by zalogować się nim zdalnie zanim wyłączymy możliwość logowania się hasłem.

[adam@serwer ~]$ cd .ssh
[adam@serwer .ssh]$ cat id_ed25519
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNsaC1rZXltdjEAAAAACmFlczI1Ni1jYmMAAAAGYmNyeXB0AAAAGAAAABCpbVco+k
SRaMh/ndLs15daAAAAZAAAAAEAAAAzAAAAC3NzaC4lZDI1NTE5AAAAIBlV2rHO4axH8Otm
7lU7yTveIWWlt8Yy0vKGQnEhzwJ4AAAAoN5YkWL55KoygRRXFEkqG1Jho0VFYRKvC8npY+
q5oSRuTZvsk6t77mxvUJWatljIN70Zhtn5UxqoH3+RQ1sVvLUwhvafvGaXCkawylUUoKkO
je1QiI31Fj3wt2pMehyjFtVPsYMA5DYIOW0CVhLlehADFyxtw0Z61r+zU5VIl4UgI7KZme
/UMC+6UNR/dzDj1JgvT1pMS7RDYqhBDuuI1v0=
-----END OPENSSH PRIVATE KEY-----

Zwartość klucza prywatnego możemy skopiować z ekranu PuTTy i wkleić do pliku tekstowego który zapiszemy w bezpiecznym miejscu na naszym dysku. Aby użyć nowego formatu klucza potrzebujemy jednak nowej wersji PuTTy oraz narzędzia PuTTygen. Na stronie PuTTy znajdujemy sekcję „The latest development snapshot” (różowe tło) i pobieramy PuTTy.exe oraz PuTTygen.exe. Uruchamiamy nowe PuTTygen.exe i wybieramy menu „Conversions” oraz „Import key” a następnie wskazujemy zapisany przed chwilą klucz prywatny. Podajemy hasło klucza i gdy po chwili zostanie prawidłowo zaimportowany wybieramy „Save private key” i zapisujemy plik z rozszerzeniem .PPK w bezpiecznej lokalizacji. Pozostaje nam już tylko na serwerze skopiować nasz klucz publiczny do pliku o odpowiedniej nazwie:

cd .ssh
cp id_ed25519.pub authorized_keys

a w PuTTy w sekcji „Connection” w menu „Data” wypełnić pole „Auto-login username” oraz w menu SSH/Auth wskazać plik .PPK (i zapisać ustawienia by nie musieć powtarzać całej operacji). Po udanym logowaniu za pomocą klucza możemy wrócić do dalszego zabezpieczenia usługi SSH na serwerze.

Aby móc edytować konfigurację serwera SSH najpierw nadamy sobie moc roota poprzez polecenie

su

a następnie podanie hasła roota. Dla wygody możemy teraz uruchomić Midnight Commandera

mc

i poszukać pliku

/etc/ssh/sshd_config

W nim około wiersza 17 zmienimy numer portu na np. 5000

Port 5000

W wierszu 23 wymusimy korzystanie z najnowszej wersji protokołu:

Protocol 2

W wierszu 44 ustawimy dokładniejsze logowanie informacji, na przykład odcisków kluczy używanych do logowania:

LogLevel VERBOSE

W okolicy wiersza 49 zablokujemy możliwość logowania się bezpośrednio na konto roota:

PermitRootLogin no

a około wiersza 79 wyłączymy możliwość logowania się za pomocą hasła:

PasswordAuthentication no

Zmodyfikowany plik zapiszemy (F2) i zrestartujemy usługę:

systemctl reload sshd.service

Nie zamykając okienka w którym pracowaliśmy (na wszelki wypadek, by w razie katastrofy móc jeszcze wprowadzić poprawki) możemy przetestować logowanie z osobnej sesji PuTTy (nie zapomnijcie zmienić numeru portu na nowy). Jeśli wszystko działa to możemy przejść do kolejnych zadań, czyli blokowania adresów, które dobijają się do naszej usługi.

fail2ban

Aby zabezpieczyć serwer przed uporczywymi próbami odgadywania haseł wdrożymy tez blokowanie niegrzecznych użytkowników po adresie IP. W tym celu użyjemy narzędzia fail2ban. Najpierw musimy je zainstalować:

yum install fail2ban fail2ban-systemd

Następnie stworzymy odpowiednią konfigurację – będziemy blokować adres IP na dobę za 3 nieudane próby logowania. W edytorze Midnight Commander (sudo mc) wchodzimy do katalogu

/etc/fail2ban/jail.d/

tworzymy plik (Shift+F4) o treści:

[sshd]
enabled = true
port = 5000
logpath = %(sshd_log)s
maxretry = 3
bantime = 86400

i zapisujemy go (F2) pod nazwą sshd.local. Wystarczy już tylko uruchomić usługę i zapewnić jej uruchamianie przy każdym restarcie:

systemctl enable fail2ban
systemctl start fail2ban

iptables

Jako ostatni z podstawowych kroków konfiguracji bezpieczeństwa serwera włączymy firewalla. Co prawda udostępniamy naprawdę niewiele usług, ale dobrze skonfigurowany firewall jeszcze nikomu nie zaszkodził, a tu konfiguracja będzie dość prosta. Jako narzędzia do określenia zasad przepuszczania i blokowania ruchu użyjemy polecenia iptables.

Zaczniemy od zatrzymania usługi firewalld oraz maskujemy ją aby nie uruchamiała się podczas uruchomienia systemu:

systemctl stop firewalld
systemctl mask firewalld

Następnie instalujemy pakiet iptables-services:

yum install iptables-services

Ustawiamy automatyczne uruchamianie usługi iptables podczas startu systemu:

systemctl enable iptables

Następnie usuwamy przypadkowe lub stare reguły:

iptables -F

Zaakceptujemy połączenia na interfejsie lokalnym:

iptables -A INPUT -i lo -j ACCEPT

Wpuścimy ruch do naszego serwera SSH (na porcie 5000) oraz serwera VPN (na porcie 11194)

iptables -A INPUT -p tcp -m tcp --dport 5000 -j ACCEPT
iptables -A INPUT -p udp --dport 11194 -j ACCEPT

Pozwolimy na ruch wychodzący z serwera (np. pobieranie aktualizacji)

iptables -P OUTPUT ACCEPT
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

A całą resztę ruchu zablokujemy

iptables -P INPUT DROP

Możemy teraz sprawdzić czy o czymś nie zapomnieliśmy

iptables -L -n

Następnie zapisujemy konfigurację

iptables-save > /etc/sysconfig/iptables

i restartujemy usługę

systemctl restart iptables

Automatyczne aktualizacje

Jeśli w poprzednich artykułach ominęliście konfigurację automatycznych aktualizacji bezpieczeństwa, to najwyższy czas je uruchomić na serwerze. Instalujemy pakiet yum-cron:

yum install yum-cron

W pliku /etc/yum/yum-cron.conf zmieniamy w wierszu 8

update_cmd = default

na

update_cmd = security

a w wierszu 19

apply_updates = no

na

apply_updates = yes

Pozostaje uruchomić usługę:

systemctl start yum-cron.service

Dzięki temu nie będziecie musieli co parę dni aktualizować ręcznie pakietów oprogramowania w obawie przed nowymi błędami – aktualizacje bezpieczeństwa zainstalują się same.

Odzyskiwanie dostępu do serwera

W trakcie eksperymentów z podnoszeniem poziomu bezpieczeństwa może się zdarzyć, że zabezpieczenia okażą się zbyt skuteczne nawet dla właściciela serwera i zostaniecie odcięci od swojej maszyny (szczególnie zdarza się przy zabawach z iptables). Na szczęście ArubaCloud dysponuje rozwiązaniem awaryjnym, które pozwoli w łatwy sposób do serwera wrócić. Wystarczy, że zalogujecie się na swoje konto, na liście serwerów wybierzecie obok nazwy swojej maszyny opcję „Zaloguj się” a następnie w prawym dolnym rogu wybierzecie opcję „Uruchom proces startowania konsoli”.

aruba01

Traficie wtedy do ekranu logowania gdzie wystarczy że podacie login roota oraz hasło by dostać się do swojej maszyny. Metoda ta pozwoli Wam np. poprawić reguły iptables lub błędnie skonfigurowany dostęp SSH i przywrócić dostęp do serwera.

Podsumowanie

Powyżej przedstawiliśmy jedynie kilka podstawowych kroków mających podnieść poziom bezpieczeństwa usługi SSH oraz samego serwera. Staraliśmy się nie popadać w paranoję i wybrać metody, które pozwalają bezpieczeństwo poprawić, nie zabijając użyteczności. To oczywiście dopiero wstęp do tematu, który będziemy rozwijać w kolejnych odcinkach. Zapraszamy też do zgłaszania uwag i pomysłów – poradnik może dzięki Wam stać się dużo lepszy w kolejnej edycji.

Poradnik oraz swoje własne pomysły możecie testować na serwerach ArubaCloud przez dwa miesiące za darmo, a potem za zaledwie 4 PLN miesięcznie. Zapraszamy do zabawy :)

Dla pełnej przejrzystości – za przygotowanie oraz opublikowanie powyższego artykułu otrzymujemy wynagrodzenie.

Powrót

Komentarze

  • 2016.10.10 07:52 jdoe

    Zabrakło kilku rzeczy. 1. Domyślnie w CentOS 7 iptables są zarządzane przez firewalld. Konfiguracja zniknie po restarcie. Trzeba wyłączyć i zamaskować firewalld oraz włączyć (unmask/enable/start) usługę iptables. 2. Dla yum-cron brakuje enable usługi (ktoś może sprawdzić,czy domyślnie jest enabled po instalacji). Usługa może nie wstać po restarcie.

    Odpowiedz
    • 2016.10.10 08:25 lejzab

      albo nie wyłączać i maskowafirewalld, tylko go użyć.

      Odpowiedz
      • 2016.10.10 10:06 jdoe

        Można, ale opis dotyczył użycia iptables. Do firewalld trzebaby xmla robić, który wpuściłby niestandardowy port ssh.

        Odpowiedz
        • 2016.10.10 12:05 tomek

          a może po prostu nauczyć się komend zamiast kombinować z xml’em ?

          Odpowiedz
        • 2016.10.10 20:25 Chris Warrick

          Nie trzeba.

          firewall-cmd –permanent –add-port=5000/tcp

          Odpowiedz
          • 2016.10.10 20:26 Chris Warrick

            (w miejsce – wstaw dwa – – minusy, bo WordPress.)

    • 2016.10.10 08:41 K

      yum-cron po zainstalowaniu wstaje automatycznie po restarcie, nie trzeba jej dodatkowo aktywować w systemctl

      Odpowiedz
      • 2016.10.10 10:07 jdoe

        Nie byłem pewien, a nie miałem jak i gdzie sprawdzić, czy usługa startuje domyślnie po instalacji.

        Odpowiedz
    • 2016.10.10 10:06 Q

      @jdoe Czepiasz się detali, a jest jeden naprawdę poważny błąd merytoryczny w artykule. Klucza prywatnego nie generuje się na serwerze, z wiadomych względów.

      Odpowiedz
      • 2016.10.10 11:15 jdoe

        Wyszedłem z założenia, że artykuł jest dla początkującego i może się zdziwić, że coś mu po restarcie nie działa. I że taka osoba nie ma pod ręką linuxa, na którym mogłaby klucz Ed25519 wygenerować (PuttyGen raczej tego nie potrafi). A że domyślnie klucz jest szyfrowany, to jego wygenerowanie/pozostawienie na serwerze nie stwarza aż tak dużego ryzyka, o ile jest zabezpieczony mocnym hasłem.

        Odpowiedz
        • 2016.10.10 16:22 Q

          @jdoe no tak, najlepiej robić wodę z mózgu ludziom już na samym początku i uczyć ich złych nawyków. No i puttygen wspiera ed25519 pod ponad roku.

          Odpowiedz
    • 2016.10.10 11:18 systemctl stop

      Od tego jest tzw. cron lub inna usługa oraz umiejętność pisania skryptów w baszu.

      Odpowiedz
  • 2016.10.10 07:57 Gość

    A czy przypadkiem nie trzeba jeszcze odblokować tcp 80 na inpucie w iptables żeby aktualizacje systemu mogły się pobierać? oraz DNS udp 53?

    Odpowiedz
    • 2016.10.10 08:44 K

      Jak już to output na 53 i 80. W powyższej konfiguracji output jest na Allow.
      Gdybyś świadczył usługi na świat (np. miał własnego Apache2) to wtedy musiałbyś zrobić w Input allow na 80.

      Odpowiedz
  • 2016.10.10 08:03 Hmm

    Ale ze mc ??

    Odpowiedz
  • 2016.10.10 08:40 Piter

    Jest błąd we wpisie gdzie podajecie katalog, w który należy wejść po zainstalowaniu fail2ban

    Odpowiedz
  • 2016.10.10 09:14 lejzab

    ssh-add z centos7 nie łapie kluczy z ed25519, nie bez kombinowania w każdym razie.

    Odpowiedz
    • 2016.10.10 10:43 Trolecki Jan

      CentOS to jest w ogole taki DOS 6.22 wsrod Linuksow. Wiecznie opozniony w rozwoju, zeby to jakos dzialalo to trzeba pododawac dodatkowe repozytoria (np z Fedory). Dobre jak musisz cos zrobic na Redhacie, ale nie z jakiegos powodu nie chcesz/nie mozesz go kupic.

      Odpowiedz
      • 2016.10.11 03:28 adrb

        Jak chcesz używać pakietów Fedory, to zainstaluj Fedore. A jak nie wiesz czemu Centos ma takie a nie inne pakiety to… lepiej zamilcz zamiast pisać bzdury

        Odpowiedz
        • 2016.10.11 12:53 Trolecki Jan

          Zamieniam sie w sluch czemu CentOS ma takie, a nie inne pakiety i czemu sa one opoznione w rozwoju.

          Odpowiedz
          • 2016.10.18 10:20 hind

            CentOS ma opóźnienie w pakietach ponieważ utrzymuje tą samą wersję pakietów od momentu wydania wersji dystrybucji aż do końca jej wsparcia, dodając tylko łatki bezpieczeństwa (Spójne API, coś co zewnętrzni dostawcy lubio)

  • 2016.10.10 09:32 Invidian

    Ciekawy artykuł dla początkujących. Ja osobiście staram się unikać zmiany portu SSH, ze względu, że może to być później problematyczne przy używaniu rsync’a, SFTP etc. (nie zawsze konfiguracja portu jest trywialna). Dodatkowo mogę polecić port multiplexer na port 443, za którym można ukryć SSH, serwer www z HTTPS i OpenVPN’a.

    Odpowiedz
    • 2016.10.10 10:41 Trolecki Jan

      A co jest problematyczne, jak masz jakis skrypt to dodajesz zmienna dla innego portu, jak robisz to recznie to musisz poprostu pamietac.

      Odpowiedz
      • 2017.03.15 10:43 Kamil

        Wydaje mi się, żę w ~/.ssh/config można wpisać niestandardowy port SSH dla danego hosta. Wtedy rsync-e i scp-y powinny działać w sposób przezroczysty.

        Odpowiedz
    • 2016.10.11 03:38 adrb

      „może to być później problematyczne”

      Nie problematyczne, po prostu upierdliwe. Nie poprawia bezpieczeństwa, natomiast niepotrzebnie marnotrawi czas.

      Odpowiedz
  • 2016.10.10 10:34 Trolecki Jan

    Ja bym jescze dodal lekki hardening samego SSH:

    Wywalenie mozliwosci logowania z kluczami dsa, albo pozostawienie mozliwosci tylko dla ed25519:

    HostKey /etc/ssh/ssh_host_rsa_key
    #HostKey /etc/ssh/ssh_host_dsa_key
    HostKey /etc/ssh/ssh_host_ecdsa_key
    HostKey /etc/ssh/ssh_host_ed25519_key

    + do tego oczywiscie funkcje haszujace:
    KexAlgorithms [email protected],ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
    Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
    MACs [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected]

    + blokada port forwardingu w przypadku gdybysmy dawali doestep jeszcze komus a ten ktos chcialby sobie zrobic socks proxy:
    AllowTcpForwarding no
    X11Forwarding no

    + pozwolenie na zalogowanie tylko dla wybranych uzytkownikow:
    AllowUsers xyz

    + W Debianie i pochodnych:
    DebianBanner no

    + jeszcze kilka przydatnych opcji:
    UsePrivilegeSeparation yes
    StrictModes yes
    VerifyReverseMapping yes

    Oprocz tego co zostalo juz napisane na temat fail2ban, po przeniesieniu SSH na inny egzotyczny port proponuje jeszce dodanie modulu xtables – psd, ktory skutecznie spowolni boty atakujace port 22.

    iptables -A INPUT -m psd –psd-weight-threshold 15 –psd-hi-ports-weight 3 -j DROP

    iptables -A INPUT -p tcp –dport 22 -j TARPIT

    Oczywiscie mozna dodac jeszcze inne standardowe porty, na ktorych nie mamy zadnych uslug:

    iptables -A INPUT -p tcp –dport 21 -j TARPIT
    iptables -A INPUT -p tcp –dport 23 -j TARPIT
    iptables -A INPUT -p tcp –dport 80 -j TARPIT
    iptables -A INPUT -p tcp –dport 110 -j TARPIT
    iptables -A INPUT -p tcp –dport 113 -j TARPIT
    iptables -A INPUT -p tcp –dport 143 -j TARPIT
    iptables -A INPUT -p tcp –dport 993 -j TARPIT
    iptables -A INPUT -p tcp –dport 995 -j TARPIT
    iptables -A INPUT -p tcp –dport 1024 -j TARPIT
    iptables -A INPUT -p tcp –dport 1194 -j TARPIT
    iptables -A INPUT -p tcp –dport 5060 -j TARPIT
    iptables -A INPUT -p tcp –dport 8080 -j TARPIT

    Odpowiedz
    • 2017.04.28 14:20 Wojciech

      Odnośnie hardeningu SSH trzeba wystrzegać się krzywych od NIST (zgodnie np. z https://stribika.github.io/2015/01/04/secure-secure-shell.html i zamieszaniem związanym z NIST). Więc oprócz wywalenia możliwości logowania z kluczami DSA, warto wywalić również ECDSA:

      HostKey /etc/ssh/ssh_host_rsa_key
      #HostKey /etc/ssh/ssh_host_dsa_key
      #HostKey /etc/ssh/ssh_host_ecdsa_key
      HostKey /etc/ssh/ssh_host_ed25519_key

      Podobnie algorytmy wymiany klucza (to nie to samo co funkcje haszujące) dobrze wykastrować o te korzystające z krzywych NIST (ecdh-sha2-nistp521, ecdh-sha2-nistp384 oraz ecdh-sha2-nistp256) co daje:
      KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256

      I jeszcze odnośnie MACs (Message authentication codes), dlaczego wyrzuciłeś algorytmy [email protected] oraz hmac-ripemd160? Z tego co czytam żadne skuteczne ataki nie są znane

      Odpowiedz
    • 2017.04.28 14:33 Wojciech

      Odnośnie hardeningu SSH warto chyba wystrzegać się krzywych od NIST (zgodnie np. z https://stribika.github.io/2015/01/04/secure-secure-shell.html i ogólnym zamieszaniem związanym z NIST). Więc oprócz wywalenia możliwości logowania z kluczami DSA, warto wywalić również ECDSA:

      HostKey /etc/ssh/ssh_host_rsa_key
      #HostKey /etc/ssh/ssh_host_dsa_key
      #HostKey /etc/ssh/ssh_host_ecdsa_key
      HostKey /etc/ssh/ssh_host_ed25519_key

      Podobnie algorytmy wymiany klucza (to nie to samo co funkcje haszujące) dobrze wykastrować o te korzystające z krzywych NIST (ecdh-sha2-nistp521, ecdh-sha2-nistp384 oraz ecdh-sha2-nistp256) co daje jedynie dwie możliwości:
      KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256

      I jeszcze odnośnie MACs (Message authentication codes), dlaczego wyrzuciłeś algorytmy [email protected] oraz hmac-ripemd160? Z tego co czytam żadne skuteczne ataki nie są znane (https://en.wikipedia.org/wiki/Hash_function_security_summary). Już prędzej wyrzuciłbym umac-128 (160 bitów vs 128).

      I jeszcze drobna uwaga ogólna odnośnie generowania klucza, dla ed25519 przełącznik -o jest niepotrzebny, w tym przypadku klucze prywatne zawsze zapisywane są w nowym formacie OpenSSH.

      Odpowiedz
  • 2016.10.10 13:16 Ninja

    Wydaje mi się, że skoro jest to reklama o podstawach zabezpieczenia serwera, to oprócz pisania „zrób to”, „zrób tamto”, przydałoby się też krótkie wyjaśnienie co dana instrukcja spowoduje i dlaczego została użyta. Np. dlaczego połączenia na interfejsie lokalnym mają być dopuszczone w iptables albo jaka jest różnica pomiędzy firewalld, a iptables. Ale to tylko zaawansowana reklama, dlatego tych rzeczy brakuje.

    Nubom polecam, żeby nie przepisywali na ślepo wszystkich komend, tylko sprawdzili co one powodują, zanim zastosują u siebie.

    Odpowiedz
    • 2016.10.10 15:13 Trolecki Jan

      Przeciez ten caly firewalld to jest nic innego jak taki defaultowy firewall napisany przy uzyciu iptables. Nie ma tam nic czego bys jeszcze nie widzial albo o czym nie slyszal.

      Odpowiedz
    • 2016.10.10 20:04 maslan

      popieram :)

      Odpowiedz
  • 2016.10.10 13:53 User

    Ja mam ubuntu i nic nie rozumiem, ale wszystko działa! :)

    Odpowiedz
  • 2016.10.10 14:54 pwd

    Nikt nie wspomniał o selinuksie, który jest domyślnie włączony po instalacji centosa. Żeby zmiana domyślnego portu dla sshd zadziałała trzeba skonfigurować selinuksa za pomocą polecenia:
    semanage port -m -t ssh_port_t -p tcp 5000

    Odpowiedz
  • 2016.10.10 16:31 Tomasz

    Przy zmianie portu SELINUX potrafi zablokować działanie sshd. Należy zmienić port w SELINUX albo wyłączyć go.

    Odpowiedz
  • 2016.10.10 19:45 Krzysiu

    Jako pole treningowe polecam jakiegoś starego laptopa. Odłączyć niepotrzebny sprzęt, w tym ekran i wifi, jeśli wentylator jest na 12V to podpiąć go na 5V (a czasem można i całkowicie wyłączyć) – cicho i tanio. Nie wiem dokładnie ile mój zabierał, ale maksymalnie mógł ok. 70 W brać – z wifi, ekranem, dodatkowymi urządzeniami USB. Stąd pewnie jakieś 30-40 W będzie.

    Odpowiedz
    • 2017.03.15 10:51 Kamil

      A to może lepiej jakieś Raspberry. Pobiera kilka Wat przy pełnym obciążeniu wszystkcih core’ów.

      Odpowiedz
  • 2016.10.10 20:35 ssh_man

    Cześć :-)
    Logując się zdalnie z obcych komputerów musimy mieć nośnik z kluczem SSH. Płytka CD-R (bo jest read-only) da radę, ale napędy CD spotyka się już coraz rzadziej (nie, nie, pendrive’y odpadają). No to logowanie tylko na podstawie czegoś co wiem, ale nie samym hasłem! Dla Linuxów dostępny jest Google Authenticator, który jest tokenem software’owym na telefony z Androidem albo iOS. Instalacja jest banalna, ładnie działa a przez SSH można sobie puścić w tunelu RDP do swojego Windowsa w domu ;-)

    Odpowiedz
  • 2016.10.10 22:26 Wacek

    Mam pytanie czy ten Ed25519 jest bezpieczniejszy od rsa 4096 bit?

    Odpowiedz
    • 2016.10.12 12:05 jsdfhj

      Są podobne. Curve ECC 25519 jest szybsze.
      RSA >= 2048 jest wystarczający do zastosowań produkcyjnych i zaleca się, w wielu przypadkach, dodać również ten szyfr asymetryczny dla kompatybilności wstecznej.

      Odpowiedz
  • 2016.10.11 09:27 Bartosz

    Hmm… To trochę nie dla mnie, ja mam serwer z OVH (tańszy) i na Debianie. Zabezpieczałem go według poradnika „Securing & Hardening Linux v1.0” autorstwa Charalambous Glafkos. Coś mi się wydaje, że znacie ten poradnik, bo to właśnie tutaj jest opisana metoda na grupę wheel. Nie skorzystałem z tego. Ja na serwerze mam zainstalowany panel WWW, który sam zainstalował takie pakiety jak iptables i fail2ban, a także są zarządzane z poziomu strony administracyjnej (w takim lepiej nie kasować reguł, bo np. ftp lub baza przestanie działać). Z kilku rzeczy z waszego poradnika chętnie bym skorzystał. Np. nie mam zmienionego portu, niektórzy mówią, by tego portu SSH nie zmieniać, inni mówią, by zmienić. Ciężko stwierdzić, kto ma rację.

    Odpowiedz
    • 2016.10.11 12:58 Trolecki Jan

      Jesli zmienisz, to w przypadku gdy pojawi sie jakas dziura typu remote/dos, a ty z jakiegos powodu nie zaktualizujesz openssh to bedizsz latwiej podatny.
      Jesli przesuniesz SSH na inny port, to nadal bedziesz podatny ale wszystkie boty beda go szukaly na porcie 22. Oczywiscie nowy port wyjdzie przy skanowaniu, o ile nie nie bedziesz z automatu banowal IP ktore cie skanuja.

      Odpowiedz
      • 2016.10.11 16:22 rob006

        Przesunięcie portu na 5000 to średnio rozsądne wyjście – usługę nasłuchującą na tym porcie może uruchomić dowolny user, wystarczy włam na dowolne konto lub usługę i przy odrobinie szczęścia można postawić fałszywe ssh czyhające na nieostrożnych użytkowników.

        Odpowiedz
        • 2016.10.11 21:05 Adam

          Możesz wyjaśnić co kryje się pod pojęciem „odrobiny szczęścia”? Poza tym nawet jeśli spełni się ten mało realistyczny scenariusz, to co podsłuchasz?

          Odpowiedz
          • 2016.10.11 22:36 rob006

            Odrobina szczęścia, która sprawi że demon ssh padnie i zwolni port. A to może być wszystko: restart, aktualizacja, błąd albo efekt ataku. A podsłuchać można wszystko, co użytkownik poda do takiego podstawionego ssh.
            Ostateczny efekt całej porady ze zmianą portu na 5000 jest taki, że zamieniasz realne zabezpieczenie (gwarancja że usługa nie jest postawiona przez dowolnego usera) na security by obscurity.

          • 2016.10.12 08:11 Adam

            A próbowałeś taki atak przeprowadzić w świecie rzeczywistym? I jakie jest prawdopodobieństwo, że się uda? Plus że administrator nie zauważy? A nawet jeśli, to jak zalogujesz się na cudze konto dzięki niemu?

          • 2016.10.12 10:00 rob006

            > I jakie jest prawdopodobieństwo, że się uda?

            Podejrzewam że większe niż to, że akurat zmiana domyślnego portu uchroni cię przed włamem – jeśli masz sensowne hasło (o kluczach nie wspominając) to żaden bot i tak ci nie wejdzie na serwer, a w ukierunkowanym ataku zmiana portu nic nie daje, otwiera za to inne możliwości ataku.
            W ogóle takie udziwnienia konfiguracji są zmorą na dłuższą metę i wyrządzają więcej szkody niż pożytku. Taki sam kaliber jak „autorskie rozwiązanie kryptograficzne” tworzone przez domorosłych programistów.

        • 2016.10.12 10:36 Trolecki Jan

          A co chcesz podsluchac skoro w tej stuacji juz masz pelna kontrole nad serwerem? Po za tym, ja osobiscie SSH trzymam na portach pieco cyfrowych, a usera mozna przyciac do uzywania portow z zakresu powiedzmy 1500-2500, albo w ogole pozbawic go tej mozliwosci.

          Odpowiedz
          • 2016.10.12 11:10 rob006

            Jaką pełną kontrolę? Wystarczy dostęp do dowolnego usera, albo nawet dziurawy skrypt www z dostępem do exec i podobnych.

  • 2016.10.11 20:05 kszh

    Masakra! Część o generowaniu kluczy jest zupełnie bez sensu i nie ma prawa działać. Klucze należy wygenerować _na pececie_ (kliencie), np za pomocą PuTTygen. Publiczny (.pub z peceta) skopiować na server do ~/.ssh/authorized_keys nowo utworzonego użyszkodnika. Jeszcze chmod 600 ~/.ssh/authorized_keys na wszelki wypadek. Voila!

    Generowanie klucza na serwerze i importowanie go do PuTTy jest bez sensu. Chyba zabrakło merytorycznej weryfikacji…

    Odpowiedz
    • 2016.10.11 21:03 Adam

      Wyjaśnisz fragment gdzie mówisz „nie ma prawa działać” skoro działa?

      Odpowiedz
      • 2017.05.05 12:02 Marcin

        Witam, sorry za pytanie nooba, ale mi to nie działa.

        1. Z jakim rozszerzeniem ma być zapisany klucz prywatny? *.pem?
        2. Nie mogę zaimportować klucza, dostaję komunikat: „couldn’t load private key (new-style openssh magic number missing)”. Coś robię źle?

        Z góry dziękuję za podpowiedź.

        Odpowiedz
  • 2016.10.11 21:00 borys

    Info do autora:

    1. Czemu zamieniasz firewalld na iptables? Tak mi się wydaje że za dużo przeczytałeś poradników na internecie, gdzie każdy od każdego przepisuje nic nie sprawdzając! Są wady i zalety obu rozwiązań ale przy podstawowej konfiguracji nie ma znaczenia co wybierzesz, oba da się skonfigurować w ten sam sposób.

    2. Pakiety z repo base i update w CentOS 7 nie mają informacji, o tym czy są security update czy nie, więc ustawienie automatycznych aktualizacji na poziomie 'security’ jest bez zasadne, aktualizacja się nie wykona. <- zachęcam do sprawdzenia :)

    3. Testowałem waszą usługę i dostałem przeinstalowane fail2ban na waszym VPS-e, to jakiś błąd czy nawet nie wiem co macie w obrazach?

    Pozdrawiam,

    Odpowiedz
    • 2016.10.11 21:11 Adam

      1. Bo jak się uczyłem iptables to nie było firewalld i tak mi zostało a też działa.
      2. Sprawdzę, dzięki,
      3. Co to znaczy „przeinstalowane”?

      Odpowiedz
      • 2016.10.11 22:07 borys

        Odnośnie punktu 3, miało być 'preinstalowane’ czyli dostałem obraz VPS-a wraz zainstalowaną paczką fail2ban, tyle że paczka fail2ban nie była włączona i skonfigurowana. Więc nie wiem czy to jest sens, bo jak ktoś nie zna fail2ban to i tak go nie włączy, a jak ktoś zna to sobie zainstaluje i skonfiguruje.

        Odpowiedz
        • 2016.10.12 08:11 Adam

          To wyślij do Aruby pytanie, ale nie sądzę, by to był dla kogoś problem który trzeba pilnie rozwiązać…

          Odpowiedz
  • 2016.10.11 21:35 Imiennik

    Vpn na udp? Chyba powinnien byc port tcp?

    No esli ktos ma adaptive ze tc udp leci na tym samym porcie to ok

    Odpowiedz
    • 2016.10.11 21:53 Adam

      W poprzednim artykule ustawialiśmy VPNa na UDP

      Odpowiedz
  • 2016.10.12 08:03 raw_iptables_master

    Fail2ban nie jest optymalnym rozwiązaniem z punktu widzenia wydajności. Samym iptables i ipset można to załatwić, by banować skanowanie portów.

    Odpowiedz
    • 2016.10.12 08:04 Adam

      A możesz wyjaśnić, dlaczego nie jest optymalnym?

      Odpowiedz
    • 2016.10.12 10:40 Trolecki Jan

      Ale fail2ban to wlasnie iptables+python. Nie widze potrzeby aby tracic czas na rzezbienie wydumanych skryptow FW, zeby osiagnac to samo co daje F2B. Chyba, ze masz duzo czasu na to i robisz to dla samej sztuki.

      Odpowiedz
  • 2016.10.12 17:31 Gregory

    Czy ruch z VPNów w Polsce jest monitorowany przez rząd?

    Odpowiedz
    • 2016.10.12 17:35 Adam

      Tak, premier nie śpi bo słucha torrentów.

      Odpowiedz
      • 2016.10.13 14:15 Filip

        Chyba trochę niezasadna ta złośliwość.

        Odpowiedz
  • 2016.10.14 15:18 Majkel

    Czy nadal czeka się 2 miesiące na voucher?

    Odpowiedz
  • 2016.10.17 15:48 j

    Ceny fajne i oferta tez, szkoda ze ani nie przyjmuja platnosci BTC ani nie planuja w „niedalekiej przyszlosci”.

    Odpowiedz
  • 2016.10.25 08:19 Therion7777

    Odnośnie „yum install yum-cron” i „update_cmd = security”: żeby była jasność — w CentOS-ie nie będzie działało, bo w oficjalnych repo Centka nie ma info o metadanych. Więc sry, ale tylko AFAIR epel to wspiera.
    Bo nagle się okaże, że wszyscy są tacy secure, ale patche jednak nie są ssane :)

    Odpowiedz
  • 2019.08.21 14:44 Marian

    Witam, mam na Arubie server Debian 9 i zainstalowany openvpn. Chciałem wg Waszego poradnika stworzyć klucz ssh ale się zablokowałem przy importowaniu przez Puttygen.exe. Używam Ubuntu w domu i nie używam tego programu dlatego proszę o pomoc co zrobić dalej.
    1. Na serwerze zrobiłem:
    ssh-keygen -o -a 100 -t ed25519
    2. Na domowym lapku stworzyłem plik klucz.ppk i wkleiłem to co wyszło.

    Odpowiedz

Zostaw odpowiedź

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

Naucz się jak zabezpieczyć swój serwer, cześć 1: podstawy

Komentarze