Czy normalne jest wykonywanie setek prób włamań dziennie?

Właśnie sprawdziłem serwer /var/log/auth.logi stwierdziłem, że codziennie otrzymuję ponad 500 nieudanych powiadomień o haśle / próbie włamania! Moja witryna jest niewielka, a jej adres URL jest niejasny. Czy to normalne? Czy powinienem podjąć jakieś środki?

Niestety w dzisiejszym Internecie jest to całkiem normalne. Istnieją hordy botnetów próbujących zalogować się do każdego serwera, który znajdą w całych sieciach IP. Zazwyczaj używają prostych ataków słownikowych na dobrze znane konta (takie jak konta root lub niektóre aplikacje).

Celów ataku nie można znaleźć za pomocą wpisów Google ani DNS, ale osoby atakujące po prostu próbują każdego adresu IP w określonej podsieci (np. Znanych firm hostingowych serwerów głównych). Więc nie ma znaczenia, że ​​twój adres URL (stąd wpis DNS) jest raczej niejasny.

Dlatego tak ważne jest:

• nie zezwalaj na rootowanie w SSH ( howto )
• wszędzie używaj silnych haseł (także w aplikacjach internetowych)
• w przypadku SSH użyj uwierzytelnienia kluczem publicznym, jeśli to możliwe, i całkowicie wyłącz uwierzytelnianie hasła ( howto )

Dodatkowo możesz zainstalować fail2ban, który skanuje authloga, a jeśli wykryje pewną liczbę nieudanych prób logowania z adresu IP, będzie kontynuował dodawanie tego adresu IP do /etc/hosts.denylub iptables / netfilter w celu zablokowania atakującego na kilka minut.

Oprócz ataków SSH często zdarza się również, że skanujesz swój serwer sieciowy w poszukiwaniu wrażliwych aplikacji internetowych (niektóre aplikacje blogowe, CMS, phpmyadmin itp.). Upewnij się więc, że są aktualne i bezpiecznie skonfigurowane!

Kilka 100 jest w porządku ... W zeszłym miesiącu odkryłem, że jeden z moich serwerów miał 40 000 nieudanych prób. Przeszedłem przez kłopot z ich wykreśleniem: Mapa

Gdy zmieniłem port ssh i wdrożyłem Port Knocking, liczba spadła do 0 :-)

Ja na przykład używam „tarpit” oprócz zezwalania tylko na uwierzytelnianie za pomocą klucza publicznego i nie zezwalanie na rootowanie.

W netfilteristnieje recentmoduł, który można używać z ( INPUTłańcuch):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

To oznacza, że ​​każda próba połączenia z portem 22 jest wymieniona przez recentmoduł z adresem IP i innymi rzeczami pod nazwą „tarpit” (jeśli jesteś ciekawy, spójrz /proc/net/xt_recent/tarpit). Oczywiście możesz używać innych nazw.

Aby wyświetlić lub usunąć adresy IP, użyj:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Ta szybkość ogranicza próby do 5 w 300 sekund. Należy pamiętać, że użytkownicy z istniejącym połączeniem nie przejmują się tym limitem, ponieważ mają już ustanowione połączenie i mogą tworzyć więcej (nawet powyżej limitu prędkości).

Dostosuj reguły do ​​swoich upodobań, ale upewnij się, że zostaną dodane w tej kolejności (tzn. Dodając, użyj ich w tej kolejności, wstawiając następnie w odwrotnej kolejności).

To ogromnie zmniejsza hałas. Zapewnia również faktyczne bezpieczeństwo (przed brutalnym wymuszaniem) w przeciwieństwie do postrzeganego bezpieczeństwa zmiany portu. Jednak nadal zalecam zmianę portu, jeśli jest to wykonalne w twoim środowisku. To również znacznie obniży poziom hałasu ...

Nadal możesz połączyć to z fail2ban, chociaż działałem dobrze bez niego i tylko z powyższymi zasadami.

EDYTOWAĆ:

Możliwe jest zablokowanie się w ten sposób, dzięki czemu możesz dodać coś takiego, co pozwoli ci usunąć ban poprzez pukanie do określonego portu:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

Możesz zaimplementować fail2ban lub podobne metody, takie jak blokowanie SSH do twojego adresu IP. Niestety boty cały czas próbują brutalnie wymuszać dostęp, więc jest to całkiem normalne, musisz upewnić się, że masz dobre hasło.

Tak . W dzisiejszych czasach jest to całkiem normalne.

Jeśli to możliwe, używaj tylko uwierzytelniania klucza publicznego do celów administracyjnych. Wygeneruj klucz prywatny na swojej stacji roboczej:

$ ssh-keygen -t dsa

Skopiuj zawartość ~ / .ssh / id_dsa.pub do swoich serwerów ~ / .ssh / Author_keys (i /root/.ssh/authorized_keys, jeśli potrzebujesz bezpośredniego logowania roota).

Skonfiguruj swoje serwery / etc / ssh / sshd_config, aby akceptować tylko uwierzytelnianie za pomocą klucza publicznego:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

Jeśli masz zbyt wiele serwerów, możesz użyć Puppet do uruchamiania na nich kluczy publicznych i konfiguracji.

Zajrzyj do Denyhosts i fail2ban, aby zablokować powtarzające się próby logowania SSH i zobacz Snort, jeśli potrzebujesz pełnego IDS / IPS.

użyj http://denyhosts.sourceforge.net/

i tak, należy użyć uwierzytelniania z kluczem publicznym i wyłączyć uwierzytelnianie hasła.

Próby są zmechanizowane, więc liczby wydają się OK (tak, są wysokie w porównaniu do niektórych witryn i niskie w porównaniu do innych). Powinieneś podjąć kroki, które zwykle musisz: Uważasz swoje witryny za cele ataku każdego dnia, nawet jeśli nie wykryjesz ataku; nie wykrycie ataku, nie oznacza, że ​​nie istnieje .

Powiedziałbym, że zdobycie tylko 500 jest trochę niskie.

U poprzedniego pracodawcy jeden z badaczy bezpieczeństwa komputerowego nazwał ciągły strumień prób włamania „internetowym odpowiednikiem szumu kosmicznego ”. Opisał to jako normalny, ciągły przepływ złośliwego ruchu, który szukał systemów w Internecie i automatycznie wykorzystuje skrypty do próby przejęcia systemu. Bot-sieci i inne złośliwe systemy nieustannie skanowałyby i ponownie skanowały Internet w poszukiwaniu wrażliwych systemów, takich jak SETI.

Tak,

jest to powszechne, ale to nie znaczy, że nie powinieneś walczyć w dobrej walce. Oto kilka kroków, w jaki sposób możesz zwiększyć bezpieczeństwo swojego serwera.

Unikaj adresów IP powiązanych z DNS

Możesz znacznie zmniejszyć tę liczbę w środowiskach współdzielonych lub kolokacyjnych, wyłączając dostęp SSH na dowolnych adresach IP powiązanych z nazwami domen. Niepubliczne adresy IP nienależące do domeny będą otrzymywać mniej tego rodzaju ruchu, więc kup niepubliczne adresy IP i używaj tego adresu IP tylko w celu uzyskania dostępu SSH.

Użyj VPN dla całego dostępu SSH

Jeśli znajdujesz się w środowisku, w którym możesz zaimplementować IPsec / VPN do sieci prywatnej w środowisku serwera, jest to idealne rozwiązanie. Wyłącz dostęp do Internetu SSH, upewnij się, że masz zintegrowane rozwiązanie wyłączania oświetlenia. Skonfiguruj VPN i zezwalaj na dostęp SSH tylko z VPN.

Wdrożenie reguł adresów IP dla dostępu SSH

Jeśli sieć VLAN nie jest opcją, skonfiguruj router lub reguły zapory, aby zezwalać tylko na połączenia SSH ze znanego zakresu adresów IP.

Jeśli wykonasz te kroki, będziesz spać znacznie łatwiej w nocy, wiedząc, że ktoś będzie musiał naruszyć sieć firm hostingowych, aby uzyskać dostęp do serwera przez SSH.

Całkiem normalne, aby zobaczyć setki nieudanych połączeń SSH.

Jeśli masz taką opcję, po prostu zmieniam mój port SSH na coś niestandardowego. Niekoniecznie sprawia, że ​​serwer jest bardziej bezpieczny, ale z pewnością czyści dzienniki (i pozwala zobaczyć, jak ktoś celowo próbuje się włamać!)

Oprócz korzystania z automatycznego mechanizmu blokowania, takiego jak fail2ban, masz jeszcze jedną opcję: w rzeczywistości skontaktuj się z adresem ISP atakującego. Może się to wydawać całkowicie bezcelowe, ale w przypadku skrypciarza ich dostawca usług internetowych jest bardziej niż chętny do podjęcia działań w stosunku do nich.

Aby znaleźć adres do nadużyć, zacznij od arin.net i wyszukaj adres IP za pomocą whois. Możesz zostać przekierowany do innego rejestru regionalnego, ale w końcu możesz znaleźć odpowiedzialnego usługodawcę internetowego dla bloku IP zawierającego adres. Poszukaj adresu @ nadużycia lub po prostu napisz kontakt techniczny.

Wyślij im uprzejmą wiadomość z odpowiednimi wpisami pliku dziennika (pamiętaj, aby usunąć wszelkie prywatne informacje) i poproś ich o podjęcie działań przeciwko przestępcy.

Odradzam korzystanie z fail2ban, ale uruchamianie SSH (i innych) na niestandardowym porcie. Nie wierzę w bezpieczeństwo przez zaciemnienie, ale uważam, że jest to doskonały sposób na zmniejszenie hałasu w dziennikach.

Nieudane logowanie na niestandardowych portach będzie nieliczne i może oznaczać również bardziej ukierunkowane ataki.

Możesz nawet pójść o krok dalej i zainstalować honeypot SSH, taki jak Kippo, aby „wpuścić” bruteforcerów i zobaczyć, co zrobiliby, mając szansę.

Tak, to normalne. Co mówię klientom w twojej sytuacji z małymi stronami internetowymi.

Zawsze bądź przygotowany na włamanie.

Posiadaj kopię swojej strony na serwerze deweloperskim. Może to być pulpit systemu Windows za pomocą XAMPP, który można uzyskać za darmo.

ZAWSZE wprowadzaj zmiany na serwerze deweloperskim, a następnie przesyłaj je na swoją stronę internetową. Jeśli jest to CMS, taki jak Wordpress, umieść swoje posty na serwerze deweloperskim, a następnie skopiuj i wklej je na serwerze na żywo.

NIGDY nie pobieraj niczego z witryny na żywo na serwer programisty.

Regularnie monitoruj strony internetowe pod kątem wszelkich zmian, których nie wprowadziłeś. W szczególności ukryte linki do narkotyków lub produktów „ulepszających”. Możesz znaleźć wiele dodatków do przeglądarki i programów, które zrobią to za Ciebie.

Jeśli jesteś zagrożony. Powiadom hosta, usuń wszystko, zmień wszystkie hasła i prześlij swój czysty serwer programistów na pusty serwer. Współpracuj z gospodarzem, aby zapobiec ponownemu wystąpieniu.

W przypadku małej witryny nie powinieneś potrzebować zespołu bezpieczeństwa. To właśnie powinien zapewnić Twój host. Jeśli nie, zdobądź inny host, co jest o wiele łatwiejsze, gdy masz serwer deweloperski niż próbować przenieść serwer na żywo.

Mam nadzieję że to pomoże.

Inny sposób na zatrzymanie go (ponieważ osobiście nie lubię przenosić portu SSH): zdecyduj, czy możesz wyświetlić listę wszystkich sieci, z których kiedykolwiek będziesz chciał się zalogować, a następnie zezwól tylko tym na dostęp do twojego portu SSH.

Wpisy WHOIS lokalnych dostawców usług internetowych pomogły mi zredukować ataki do 1-2 prób logowania na miesiąc (wtedy było to około 1 000 dziennie). Wykryłem je, wciąż używając denyhosts .

Oprócz innych doskonałych sugestii, które już otrzymałeś, lubię również stosować dyrektywę AllowUsers, jeśli jest to odpowiednie dla danego serwera. Pozwala to tylko określonym użytkownikom na logowanie za pośrednictwem SSH, co znacznie zmniejsza możliwość uzyskania dostępu za pośrednictwem niepewnie skonfigurowanego konta gościa / usługi / systemu.

Przykład:

AllowUsers admin jsmith jdoe

Opcja AllowUsers określa i kontroluje, którzy użytkownicy mogą uzyskać dostęp do usług ssh. Można określić wielu użytkowników, oddzielonych spacjami.

Tak, to normalne. Możesz :

• Zmniejsz szansę na atak za pomocą fwknop

Fwknop jest jedną z lepszych implementacji knock portowych, ponieważ nie jest sfałszowany i faktycznie uwierzytelnia się, a nie tylko autoryzuje połączenie.

• Możesz zmienić port używany przez openssh, ale tak naprawdę nie poprawiasz bezpieczeństwa.

• Wzmocnij uwierzytelnianie ssh za pomocą Google -hententator lub wikid

Chroni to ataki oparte na hasłach oraz możliwość zdecydowanego ataku / ataku ukierunkowanego, który naruszy twój komputer administracyjny i wykradnie kombinację klucza i hasła ssh.

Wystarczy spojrzeć na najnowszą wersję pwn2own, aby przekonać się, jak łatwo jest wyszkolonemu napastnikowi skompromitować w pełni załataną skrzynkę administracyjną.

Niestety jest to całkiem normalne. Powinieneś rozważyć dodanie do systemu czegoś takiego jak fail2ban , aby automatycznie wykrywać i blokować atakujących. Jeśli jeszcze tego nie zrobiłeś, powinieneś rozważyć użycie tylko ssh z kluczami publicznymi i nie zezwalaj na logowanie roota przez ssh. Jeśli używasz ftp do przesyłania plików do systemu, rozważ użycie scp / sftp.

Zaimplementowałem pukanie portów i mam kilka sond dziennie. Nie dostają połączenia, więc odchodzą. Rejestruję i zgłaszam cały dostęp do danych portów.

Uruchomiłem również fail2ban z Shorewall jako zaporę, aby tymczasowo umieścić na czarnej liście upartych napastników.

Jeśli nie potrzebujesz dostępu do Internetu do SSH, wyłącz go. Jeśli masz kilka znanych adresów wymagających zdalnego dostępu, ogranicz dostęp do tych adresów.

Pomocne może być również ograniczenie dostępu do autoryzowanych kluczy.

Używam pam_abldo tymczasowego umieszczania na czarnej liście brutalnych siłowników i działa to świetnie. Myślę, że lepiej jest mieć autoryzację w PAM przy użyciu własnej bazy danych niż polegać na hosts.denylub iptables.

Kolejnym plusem jest to, że pam_ablnie zależy od skanowania plików dziennika.

Obecnie jest to całkowicie normalne.
Możesz ustawić limit „burst” na zaporze ogniowej dla nowych połączeń przychodzących na porcie SSH
lub zainstalować jeden z wielu parserów dziennika a'la fail2ban lub zmienić port SSH;).

Ostatni jest najłatwiejszy. Na maszynach o dużym obciążeniu takie próby włamania mogą mieć bardzo zły wpływ na cały system.

-
Pozdrawiam,
Robert

Tak, to normalne.

Właśnie zmieniłem port ssh z dala od standardowego 22. Mój serwer, moje zasady :) po prostu edytuj / etc / ssh / sshd_config, zmień port i zrestartuj usługę. Jedynym minusem jest to, że musisz pamiętać, aby dodać ten port do konfiguracji do każdego używanego klienta ssh.

• Wyłącz logowanie roota (w każdym systemie root istnieje użytkownik root, więc boty mogą łatwo odgadnąć nazwę użytkownika). Po zalogowaniu się jako zwykły użytkownik możesz przełączyć się na rootowanie przez su lub sudo.

• zmień domyślny port z 22

• Zezwalaj na dostęp ssh tylko ze znanych adresów IP

• Użyj silnego hasła alfanumerycznego dla użytkownika z dostępem ssh