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”.
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.
Komentarze
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.
albo nie wyłączać i maskowafirewalld, tylko go użyć.
Można, ale opis dotyczył użycia iptables. Do firewalld trzebaby xmla robić, który wpuściłby niestandardowy port ssh.
a może po prostu nauczyć się komend zamiast kombinować z xml’em ?
Nie trzeba.
firewall-cmd –permanent –add-port=5000/tcp
(w miejsce – wstaw dwa – – minusy, bo WordPress.)
yum-cron po zainstalowaniu wstaje automatycznie po restarcie, nie trzeba jej dodatkowo aktywować w systemctl
Nie byłem pewien, a nie miałem jak i gdzie sprawdzić, czy usługa startuje domyślnie po instalacji.
@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.
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.
@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.
Od tego jest tzw. cron lub inna usługa oraz umiejętność pisania skryptów w baszu.
A czy przypadkiem nie trzeba jeszcze odblokować tcp 80 na inpucie w iptables żeby aktualizacje systemu mogły się pobierać? oraz DNS udp 53?
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.
Ale ze mc ??
Tak, 4 PLN za miesiąc , zapraszamy do zapoznania się z ofertą :)
https://www.arubacloud.pl/vps/oferta-virtual-private-server.aspx
a co jest zlego w mc?
Jest błąd we wpisie gdzie podajecie katalog, w który należy wejść po zainstalowaniu fail2ban
ssh-add z centos7 nie łapie kluczy z ed25519, nie bez kombinowania w każdym razie.
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.
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
Zamieniam sie w sluch czemu CentOS ma takie, a nie inne pakiety i czemu sa one opoznione w rozwoju.
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)
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.
A co jest problematyczne, jak masz jakis skrypt to dodajesz zmienna dla innego portu, jak robisz to recznie to musisz poprostu pamietac.
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.
„może to być później problematyczne”
Nie problematyczne, po prostu upierdliwe. Nie poprawia bezpieczeństwa, natomiast niepotrzebnie marnotrawi czas.
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
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
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.
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.
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.
popieram :)
Ja mam ubuntu i nic nie rozumiem, ale wszystko działa! :)
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
Przy zmianie portu SELINUX potrafi zablokować działanie sshd. Należy zmienić port w SELINUX albo wyłączyć go.
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.
A to może lepiej jakieś Raspberry. Pobiera kilka Wat przy pełnym obciążeniu wszystkcih core’ów.
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 ;-)
Mam pytanie czy ten Ed25519 jest bezpieczniejszy od rsa 4096 bit?
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.
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ę.
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.
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.
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?
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.
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?
> 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.
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.
Jaką pełną kontrolę? Wystarczy dostęp do dowolnego usera, albo nawet dziurawy skrypt www z dostępem do exec i podobnych.
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…
Wyjaśnisz fragment gdzie mówisz „nie ma prawa działać” skoro działa?
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ź.
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,
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”?
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.
To wyślij do Aruby pytanie, ale nie sądzę, by to był dla kogoś problem który trzeba pilnie rozwiązać…
Vpn na udp? Chyba powinnien byc port tcp?
No esli ktos ma adaptive ze tc udp leci na tym samym porcie to ok
W poprzednim artykule ustawialiśmy VPNa na UDP
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.
A możesz wyjaśnić, dlaczego nie jest optymalnym?
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.
Czy ruch z VPNów w Polsce jest monitorowany przez rząd?
Tak, premier nie śpi bo słucha torrentów.
Chyba trochę niezasadna ta złośliwość.
Czy nadal czeka się 2 miesiące na voucher?
Ceny fajne i oferta tez, szkoda ze ani nie przyjmuja platnosci BTC ani nie planuja w „niedalekiej przyszlosci”.
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 :)
http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
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.