Jakiego narzędzia lub techniki używasz, aby zapobiec atakom siłowym na twój port ssh. Zauważyłem w moich dziennikach bezpieczeństwa, że mam miliony prób zalogowania się za pomocą ssh jako różni użytkownicy.
To jest na pudełku FreeBSD, ale wyobrażam sobie, że miałoby to zastosowanie wszędzie.
Odpowiedzi:
Oto dobry post na ten temat autorstwa Rainera Wichmanna.
Wyjaśnia zalety i wady tych metod, aby to zrobić:
Używam fail2ban, który zablokuje IP po kilku nieudanych próbach przez konfigurowalny okres czasu.
Połącz to z testowaniem siły hasła (używając Johna (Rozpruwacza)), aby upewnić się, że ataki siłowe nie powiodą się.
TARPITcelu, jeśli czujesz się źle (z xtables-addons).
Jedyną rzeczą, którą możesz zrobić, to użyć czegoś takiego jak DenyHosts:
http://denyhosts.sourceforge.net/
Wykorzystuje wbudowane hosts.allow / hosts.deny do blokowania nadużyć SSH.
Jednym z najprostszych sposobów uniknięcia tych ataków jest zmiana portu, na którym nasłuchuje sshd
Jak podkreśla Chris, używaj kluczy szyfrujących zamiast haseł.
Dodaj do tego:
Ile osób lub lokalizacji (z ruchomymi publicznymi adresami IP) naprawdę potrzebujesz dostępu do swoich publicznych połączeń ssh?
W zależności od liczby utrzymywanych publicznych hostów ssh i od tego, czy można zawęzić ogólne kryteria połączenia, może być prostsza konfigurowalna konfiguracja, aby ograniczyć dostęp do kilku hostów zewnętrznych.
Jeśli to działa, może naprawdę uprościć narzuty administracyjne.
Oprócz innych dobrych sugestii, jedną naprawdę łatwą rzeczą jest ograniczenie połączeń przychodzących. Ogranicz do 3 połączeń na minutę na IP:
iptables -A INPUT -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP
Użyj opcji „AllowUsers” w sshd_config, aby mieć pewność, że tylko niewielka grupa użytkowników może się w ogóle zalogować. Wszystkie pozostałe zostaną odrzucone, nawet jeśli ich nazwa użytkownika i hasło są prawidłowe.
Można nawet ograniczyć dostęp użytkowników do logowania z danego hosta.
na przykład,
AllowUsers user1 user2@host.example.com
Spowoduje to zmniejszenie przestrzeni wyszukiwania i uniknie tych starych użytkowników, którzy przypadkowo zostali pozostawieni lub zostali włączeni (chociaż ci i tak powinni zostać wyłączeni, jest to łatwy sposób, aby powstrzymać ich przed wykorzystywaniem do wpisu opartego na SSH).
To nie całkowicie powstrzymuje ataki brutalnej siły, ale pomaga zmniejszyć ryzyko.
Użyj czegoś takiego z PF:
tabela <ssh-brute>
trwa blok w szybkim dzienniku z etykiety ssh_brute
przekazać proto $ ext_if proto tcp do ($ ext_if) port ssh modulować stan \
(max-src-conn-rate 3/10, przeciążenie globalne)
Pukanie portów jest dość solidnym sposobem na uniknięcie tego rodzaju problemów. Nieco skrzypiące, czasem irytujące, ale zdecydowanie to rozwiązuje problem.
Kontekst jest ważny, ale poleciłbym coś takiego:
Oprócz sugestii ograniczającej szybkość Sherbanga ważna jest długość opóźnienia. Zwiększając opóźnienie między grupami 3 prób logowania z 2 minut do 20 minut, liczba różnych adresów IP, które spowodowały więcej niż trzy próby logowania, spadła, porównując dwa tygodniowe okresy na jednym komputerze, z 44 prób do 3 Żaden z tych trzech adresów nie próbował przez dłużej niż 11 godzin.
Bardzo niepotwierdzona, ale auth.log stał się dla mnie o wiele bardziej czytelny ...
Po prostu mnie to nie obchodzi. Pozwólcie im odpłynąć do portu, nie będą brutalnie naciskać klucza.
zainstaluj OSSEC. nie tylko monitoruje powtarzające się logowanie, ale również wprowadzi tymczasowy blok z iptables dla niepoprawnego adresu IP. A na koniec wyśle ci raport z podaniem szczegółów. rejestruje wszystko, co jest miłe. Ktoś kiedyś próbował ponad 8000 nazw logowania, aby się zalogować. przeanalizowałem dzienniki i nie znalazłem fajnej listy użytkowników;)