Setki nieudanych logowań ssh

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?

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.

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

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.

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ć.

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.

Zrób sobie przysługę i wyłącz hasło logowania. Używaj wyłącznie kluczy uwierzytelniających (na przykład Google ssh-keygen - Przykład: http://www.puddingonline.com/~dave/publications/SSH-with-Keys-HOWTO/document/html/SSH-with-Keys-HOWTO-4 .html ) Twój serwer będzie bezpieczniejszy, połączysz się z nim wygodniej (sprawdź ssh-agent, ssh-add, keychain) i nie będziesz więcej ofiarą ataków ssh brute force.

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

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ł .

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.

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.

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.

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ć).

Korzystam z fail2ban i bardzo mi to pomaga.

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 :)

Inną opcją podobną do DenyHosts jest sshutout http://www.techfinesse.com/sshutout/sshutout.html