Setki nieudanych logowań ssh

81

Każdej nocy dostaję setki, a czasem tysiące nieudanych logowań ssh na moim serwerze RedHat 4. Ze względów zapory ze stron zdalnych muszę działać na standardowym porcie. Czy powinienem coś zrobić, aby to zablokować? Zauważam, że wiele osób pochodzi z tego samego adresu IP. Czy nie powinno to powstrzymywać ich po chwili?

MattMcKnight
źródło

Odpowiedzi:

67

Możesz użyć iptables, aby ograniczyć nowe połączenia przychodzące do portu SSH. Musiałbym zobaczyć całą konfigurację iptables, aby dać ci rozwiązanie „pod klucz”, ale zasadniczo mówisz o dodawaniu reguł takich jak:

iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 5 --name SSH --rsource -j DROP 
iptables -A INPUT -p tcp --dport 22 -m recent --set --name SSH --rsource -j ACCEPT 

Reguły te zakładają, że akceptujesz USTAWIONE połączenia wcześniej w tabeli (tak, że tylko nowe połączenia trafią w te reguły). Nowe połączenia SSH będą podlegać tym regułom i zostaną oznaczone. W ciągu 60 sekund 5 prób z jednego adresu IP spowoduje odrzucenie nowych połączeń przychodzących z tego adresu IP.

To zadziałało dla mnie dobrze.

Edycja: Wolę tę metodę od „fail2ban”, ponieważ nie ma potrzeby instalowania dodatkowego oprogramowania i dzieje się to całkowicie w trybie jądra. Nie obsługuje parsowania plików dziennika, takich jak „fail2ban”, ale jeśli twój problem dotyczy tylko SSH, nie użyłbym trybu użytkownika wymagającego instalacji oprogramowania i jest bardziej złożony.

Evan Anderson
źródło
1
Podoba mi się to rozwiązanie i planuję je wdrożyć dziś wieczorem, kiedy wyrzucę dzisiejsze pożary.
MattMcKnight
2
Spowalnia ataki i polecam to, ale ponieważ istnieją tam przydzielone botnety skanujące, nie jest to panaceum. Nadal będą występować nieprawidłowe logowanie z botnetów uruchamiających skanowanie rozproszone przeciwko tobie. Naprawdę niewiele można na to poradzić, oprócz pewnego rodzaju „pukania do portu”, aby zdalnie podnieść port SSH, gdy chcesz się dostać.
Evan Anderson
1
+1 za sugestię @ pukania @ Evana. Niektóre informacje: linux.die.net/man/1/knockd . Ale nie rób tego ręcznie (np. Dodając / usuwając reguły iptables), ale zamiast tego użyj -m conditiondopasowania iptables.
pepoluan
2
nie potrzebujesz - port 22 w tych regułach, aby były one stosowane tylko do ruchu ssh?
klimat
2
@clime - Tak. Trudno uwierzyć, że tu już 2 1/2 roku i nikt tego nie zauważył! Dobry chwyt
Evan Anderson
39

fail2ban może w tym pomóc, blokując adresy IP przy zbyt wielu nieudanych próbach logowania.

Kyle Brandt
źródło
11
nie lubię narzędzi / skryptów odczytujących logi i
wydawających
2
@asdmin, tak, szczególnie, gdy mają tak fajną historię ...
maxschlepzig
25

Polecam użycie niestandardowego portu dla SSH, jeśli możesz (tj. Port 10222), ale skoro wspomniałeś, że nie możesz tego zrobić, zaleciłbym użycie czegoś takiego jak DenyHosts.

http://denyhosts.sourceforge.net/

Świetny pakiet, łatwy w instalacji i konfiguracji.

KPWINC
źródło
6
Nie wiem, dlaczego ludzie głosują za tym; SSH znajduje się na standardowym porcie 22. Oznacza to, że gdy jesteś w zagranicznej sieci, nie polegasz na tym, że mają otwarty niestandardowy port przez wychodzącą zaporę. Prawdziwe rozwiązanie tego problemu jest udokumentowane powyżej, albo ogranicz liczbę powtarzających się połączeń za pośrednictwem przychodzącej zapory ogniowej, albo wyłącz logowanie przy użyciu hasła.
Andrew Taylor,
1
OpenSSH 6.7 porzuca obsługę tcpwrappers , z czego korzysta denyhosts.
Zoredache
15

Chociaż może być fajnie móc ssh do twojego systemu z dowolnych lokalizacji w Internecie, istnieją zautomatyzowane systemy ataku hasłem, które zablokują się na otwartym porcie ssh i zastosują różne konta Joe i ataki słownikowe na twój system. Może to być pogarszające, jeśli czytasz w nocnym podsumowaniu dziennika i jest to marnowanie przepustowości.

Jeśli masz serwer sieciowy w tym samym systemie, możesz użyć opakowań php i tcp, aby ograniczyć ruch przychodzący ssh do znanych systemów, a także dać ci klucz back-door, aby umożliwić sobie dostęp z dowolnych systemów w Internecie.

Oto jak to zrobić:

odrzuć wszystkie połączenia ssh w /etc/hosts.deny:

# /etc/hosts.deny fragment
sshd:  all

Zezwalaj znanym systemom przez IP w /etc/hosts.allow, a także dodaj plik do tymczasowego dostępu:

# /etc/hosts.allow fragment
sshd:  10.0.10.2     # some system
sshd:  172.99.99.99  # some other system
sshd:  /etc/hosts.allow.temporary-sshd-access

Utwórz plik php na swoim serwerze internetowym i nadaj mu nieoczywistą nazwę, taką jak my-sshd-access.php:

<?php
function get_ip()
{
    return getenv("REMOTE_ADDR"); 
}

?>

<?php
$out='/etc/hosts.allow.temporary-sshd-access';
$log='/var/log/sshd-access-addition-log';

print "Was:";
readfile($out);
print "<br>";
$ip=get_ip();
$fp=fopen($out,"w");
fputs($fp,$ip);
fclose($fp);

$lfp=fopen($log,"a");
fputs($lfp,$ip);
fputs($lfp,"n");
fclose($lfp);

print "Wrote: ";
readfile($out);
?>

Wybacz kod php - przesunąłem go skądś indziej, aby prawdopodobnie mógł znieść całą grupę. Wystarczy dodać adres IP systemu, który ma do niego dostęp, do pliku /etc/hosts.allow.temporary-sshd-access, który jest odczytywany przez sshd (z powodu włączenia go przez /etc/hosts.allow) w czasie połączenia .

Teraz, gdy jesteś w dowolnym systemie w Internecie i chcesz ssh do tego systemu, najpierw użyj przeglądarki internetowej i naciśnij ten plik (lub użyj wget lub ekwiwalentu):

$ wget http://your.system.name/my-sshd-access.php

Teraz powinieneś mieć możliwość ssh do swojego systemu. Jeśli jest to miejsce, z którego prawdopodobnie będziesz często ssh'ing, byłoby trywialne czytanie zawartości pliku /etc/hosts.allow.temporary-sshd-access i trwałe dodanie adresu IP do / etc / hosts. dopuszczać.

David Mackintosh
źródło
Aby było to bezpieczniejsze, uruchom tę stronę na https.
Robert Munteanu
Jeśli zmienisz skrypt, aby nie wyświetlał zawartości pliku „dozwolonego tymczasowego adresu IP”, potencjalny sniffer nie będzie miał nic do wykrycia. Następnie możesz uruchomić go na http zamiast https.
Barry Brown,
„Dozwolony tymczasowy adres IP” to zawsze adres żądającego (tj. Twojego). Nie sądzę, żeby miało to jakieś znaczenie. Https oznacza, że ​​żądany adres URL jest zaszyfrowany, co oznacza, że ​​nie jest trywialne wąchanie go poza siecią.
David Mackintosh,
To nie zadziała, jeśli jesteś w sieci, która pośredniczy w połączeniach HTTP, ale twoja bezpośrednia droga do Internetu jest inna.
Andrew Taylor
OpenSSH 6.7 porzuca obsługę tcpwrappers , która jest używana w twojej odpowiedzi.
Zoredache
9

Możesz także spojrzeć na denyhosts .

FYI: OpenSSH 6.7 porzuca obsługę tcpwrappers , co oznacza, że ​​denyhosts prawdopodobnie nie jest rozwiązaniem dla nowych instalacji.

Zoredache
źródło
2

innym rozwiązaniem jest po prostu przeniesienie ssh na inny port. te robaki są dość głupie.

disserman
źródło
3
Oryginalny plakat powiedział, że musi biec na standardowym porcie.
kbyrd
1
przepraszam, muszę uważniej przeczytać pytania :)
disserman
1
Muszę się zgodzić ... Mam mój SSH działający na „alternatywnych” portach i to robi ŚWIAT różnicę w logach. Robaki są tak inteligentne jak cegła, więc dobrze działają przeciwko głupim skryptom automatyzacji; nie tak dobrze przeciwko ludzkim napastnikom. Mimo to w dziennikach znajduje się błogosławiony dźwięk ciszy ...
Avery Payne
.. nie chodzi o to, że boty są „głupie”, chodzi o to, że szukają nisko wiszących owoców. Przenoszenie portu SSH jest więc w stylu ... utrzymywania owoców nad ziemią.
elrobis
2

Inną opcją może być wymaganie, aby wszystkie połączenia ssh były weryfikowane przez certyfikat i całkowicie eliminowały hasła.

Zwykle korzystam z Denyhosts, ale okazało się, że łączyłem się regularnie zdalnie z kilku miejsc, więc zablokowałem wszystkie połączenia z portem 22 z wyjątkiem innych miejsc i używam przełączania portów, dzięki czemu mogę połączyć się z dowolnego miejsca za pomocą laptopa, jeśli będę musiał .

Evan
źródło
1

Każde rozwiązanie, które obejmuje automatyczne blokowanie adresów IP po wielu awariach, stwarza ryzyko ataków typu „odmowa usługi”. Tak długo, jak istnieje dobra polityka haseł w celu zmniejszenia skuteczności ataków typu „brute force” lub ataków słownikowych, nie przejmowałbym się nimi zbytnio.

Jeśli ograniczysz użytkowników / grupy tylko do tych, którym należy zezwolić na ssh, i wyłączysz logowanie jako root, powinieneś być bardziej niż wystarczająco bezpieczny. A jeśli to nie wystarczy, zawsze istnieje uwierzytelnianie oparte na kluczach.

goldPseudo
źródło
1

Szczerze mówiąc, jeśli musisz uruchomić SSH (i na porcie 22), nie możesz tego uniknąć. Jeśli musisz zaakceptować hasła, jesteś w jeszcze gorszej formie.

Najlepszym rozwiązaniem jest skonfigurowanie oprogramowania do analizy dzienników, aby wykluczyć dzienniki SSH. Następnie uruchom osobną instancję, aby przeglądać tylko dzienniki SSH, i użyj procmaila, aby odfiltrować nieudane próby. Możesz nawet pisać skrypty sprawdzające pomyślne logowanie z adresów IP przy wielu nieudanych próbach.

Nie ma sposobu, aby powstrzymać ludzi przed sondowaniem twojego serwera SSH. Przykłady Denyhosts, fail2ban i iptables będą działać do pewnego momentu, ale z dodatkowym niebezpieczeństwem przypadkowego zablokowania legalnych użytkowników. Najlepszą metodą jest zassanie go i próba zautomatyzowania procesu analizy logów, aby skrócić czas potrzebny na przemyślenie.


źródło
0

Kiedy mówisz, że nie powiodło się Ch, zaloguj się na swoim serwerze Red Hat, jaki rodzaj zapory sieciowej znajduje się za nim i ile osób musi się do niego włączyć. Sugeruję, że jeśli chcesz, możesz ograniczyć próby zapory ogniowej, zanim dotrą one w pobliże twojego rzeczywistego serwera.

Jeśli możesz ograniczyć zakres adresów IP, które legalnie potrzebują dostępu, powinieneś być w stanie skonfigurować listę dostępu na ścianie przeciwpożarowej. Jeśli możesz ograniczyć ruch w zaporze ogniowej, sugeruję przyjrzeć się systemom włamań do sieci, ponieważ wygląda na to, że coś jest celem twojego serwera.


źródło
0

Większość webhostów używa APF + BFD do blokowania ip nieudanych logowań SSH. Obecnie jest zapora CSF (zapora sieciowa serwera konfiguracji), która zawiera narzędzie o nazwie LFD, które robi to samo, i więcej, w tym blokuje adresy IP z niektórych krajów, w których nie chcesz uzyskiwać dostępu do serwera (np. Korea, Chiny itp., Gdzie 99% moich sond SSH wydają się pochodzić).

gbjbaanb
źródło
0

Jeśli musisz rozwiązać ten problem na więcej niż jednym hoście, możesz sprawdzić OSSEC: http://www.ossec.net/main/ossec-architecture

Umożliwi to skonfigurowanie wielu agentów ze scentralizowanej lokalizacji w celu automatycznego reagowania na ataki siłowe (wraz z każdym innym wzorcem, który można wyodrębnić z dzienników).

Bardzo fajne oprogramowanie :)


źródło