Mój serwer jest ciągle atakowany [zamknięty]

Jestem dość nowy w świecie administracji systemem. Ostatnio pracuję nad aplikacją i kiedy sprawdzam logi serwera aplikacji, ciągle otrzymuję różne adresy IP próbujące ssh na mój serwer brutalną siłą. Oto przykład mojego dziennika serwera:

Feb 14 04:07:20 foodwiz3 sshd[1264]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 14 04:07:21 foodwiz3 sshd[1264]: reverse mapping checking getaddrinfo for coenamor.columbiansabbatical.com [23.249.167.223] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb 14 04:07:21 foodwiz3 sshd[1264]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=23.249.167.223  user=root
Feb 14 04:07:23 foodwiz3 sshd[1264]: Failed password for root from 23.249.167.223 port 32997 ssh2
Feb 14 04:07:23 foodwiz3 sshd[1264]: Received disconnect from 23.249.167.223: 11: Bye Bye [preauth]
Feb 14 04:13:04 foodwiz3 sshd[1289]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Feb 14 04:13:05 foodwiz3 sshd[1289]: reverse mapping checking getaddrinfo for coenamor.columbiansabbatical.com [23.249.167.223] failed - POSSIBLE BREAK-IN ATTEMPT!
Feb 14 04:13:05 foodwiz3 sshd[1289]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=23.249.167.223  user=root
Feb 14 04:13:07 foodwiz3 sshd[1289]: Failed password for root from 23.249.167.223 port 41562 ssh2

Czy jest to coś dość normalnego, czy powinienem się martwić / coś z tym zrobić?

Witamy w cudownym świecie Internetu ... Czy:

• umieścić serwer za zaporą sprzętową?
• aktywował zaporę programową ? (na wypadek usterki zapory sprzętowej)
• stwardniały swój serwer?
• zainstalowany rkhunter przed wprowadzeniem go do sieci?
• aktywowane automatyczne codzienne aktualizacje bezpieczeństwa ?
• zmieniono domyślny port ssh ?
• ...

Ale prawdziwa odpowiedź brzmi: tak, to jest normalne : BotNet Maffia może zawsze korzystać z kilku dodatkowych źle chronionych serwerów ...

To dość normalne, aby mieć wystarczającą liczbę prób logowania, aby utworzyć dziennik powodzi.

Zmiana portów SSH jest bardziej rozwiązaniem typu „bezpieczeństwo przez zaciemnienie”, ale pomaga w powodzi. Podkreślam, że nie jest zbyt elegancki; z jakiegoś powodu istnieją de facto porty dla usług.

Powinien być domyślnie włączony, ale upewnij się, że nie możesz SSH na serwerze jako root. Jest to nazwa użytkownika, która jest dość spójna między serwerami, a zatem głównym celem prób logowania przy użyciu siły brute force. Wymuszaj ustawienie za pomocą następującego wiersza w sshd_config:

PermitRootLogin no

Zobacz także, fail2banczy monitoruje dzienniki sshd pod kątem powtarzających się wykroczeń. Na przykład 5 nieudanych prób logowania w ciągu 3 minut od określonego adresu IP spowoduje zablokowanie tego adresu IP na 10 minut. Wydłużyłem ten czas banowania do 24 godzin, aby jeszcze bardziej zmniejszyć spam w logach. :)

Proponuję ci zrobić kilka rzeczy:

1. Zmień port, na którym nasłuchuje ssh (na coś znacznie powyżej 1024) i upewnij się, że nie używasz wersji 1 protokołu:

/ etc / ssh / sshd_config

# What ports, IPs and protocols we listen for
Port 50022
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

2. Instal fail2ban- monitoruje pliki dziennika i tymczasowo lub trwale blokuje podatne na awarie adresy poprzez aktualizację istniejących reguł zapory ( iptables).

3. Upewnij się, że umieściłeś na białej liście zaufane lokalizacje.

Tak, martw się . Możesz nigdy się nie poparzyć, ale powinieneś stosować się do najlepszych praktyk IT. Lepiej dmuchać na zimne.

Jestem administratorem sieci w szpitalu. Zawsze jest źlePodłączanie skrzynki bezpośrednio do Internetu pomysłem. To, co widzisz, to tysiące automatycznych skanerów, które skanują w poszukiwaniu luk w Internecie. Widzę te i wiele innych rzeczy (skanowanie portów, różne znane testy podatności) na wszelkiego rodzaju oprogramowanie (ssh, telnet, ftp itp.) Pojawiające się na naszym polu identyfikatora. Twoja maszyna powinna znajdować się za zaporą sieciową / NAT i powinieneś tylko przekieruj wymagane porty do Internetu (80, 443 itp.). Jest to stosunkowo łatwe do zrobienia. Posiadanie czegoś, co można wykorzystać do zarządzania (telnet SSH), to zły pomysł, aby mieć dostęp do Internetu, ponieważ jeśli - z jakiegokolwiek powodu - wystąpi błąd w oprogramowaniu SSH / telnet na tym serwerze, automatyczny bot będzie wykryj to w mgnieniu oka, a będziesz pieprzony. Błędy w oprogramowaniu zdarzają się cały czas i może upłynąć trochę czasu, zanim łatka zostanie wydana lub pamiętaj, aby ją załatać.

Jeśli chcesz zdalnie zarządzać, zajrzyj do skonfigurowania czegoś takiego jak rozwiązanie VPN lub jeśli korzystasz z systemu Windows, skonfiguruj bramę usług terminalowych dla pulpitu zdalnego. Wiem, że możesz użyć osobnego komputera z systemem Linux lub Windows z 2 kartami sieciowymi, aby skonfigurować routing i dostęp zdalny dla VPN i NAT, jeśli jesteś tylko małym sklepem. W przeciwnym razie dostawcy tacy jak Cisco mają sprzętową zaporę ogniową / rozwiązania NAT (Cisco ASA).

Podsumowując, umieść swój komputer za NAT. Przekaż tylko porty wymagane do uruchomienia usługi. Nie przesyłaj dalej usług używanych do zarządzania do Internetu, zamiast tego zajrzyj do VPN w celu zdalnego zarządzania.

PS Zmiana portów SSH może pomóc w woluminie dziennika, ale tak naprawdę nie uniemożliwia dostępu do SSH. Dowolny z tysięcy automatycznych wyszukiwarek luk może i będzie skanować porty, aby sprawdzić, które porty nasłuchują dla jakich usług. Możesz to zrobić samodzielnie za pomocą narzędzia o nazwie nmap .

Możesz skonfigurować wewnętrzną zaporę jądra przez iptables . Aby tylko kilka komputerów mogło ssh na twój serwer i pozwolić, aby inne pakiety IP spadły. Zobacz man iptableswięcej informacji.

Na przykład, jeśli 192.168.1.67 jest hostem, z którego ssh, to na typie serwera:

sudo iptables -A INPUT -p tcp --dport ssh -s 192.168.1.67 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport ssh -j DROP
sudo iptables-save

Czy naprawdę potrzebujesz swojego serwera w Internecie? Jeśli naprawdę chcesz mieć go w Internecie, upewnij się, że jest bezpieczny, zanim go tam umieścisz.

Zmiana portu to tylko bezpieczeństwo poprzez zaciemnienie. Jeśli twój atakujący jest bardziej wyrafinowany niż uruchamianie skryptów, nie pomoże.

Kilka już wspomnianych rzeczy, które polecam również:

1. Zgadzam się z Fail2Ban, a odpowiednio skonfigurowane utrzyma skrypty i najbardziej wyrafinowanych hakerów na dystans.
2. Ustawienie PermitRootLogin na no jest koniecznością.
3. Skonfiguruj zaporę ogniową. Zwykle po prostu edytuję reguły iptables, ale coś takiego jak UFW lub firehol również będzie działać.

Właśnie dołączyłem do tej społeczności, ponieważ są dwie rzeczy, które moim zdaniem nie zostały odpowiednio rozwiązane.

• W konfiguracji zapory blokuj / wyłącz absolutnie wszystko, co nie jest całkowicie konieczne. Zanim otworzysz porty, zadaj sobie pytanie: „Czy naprawdę potrzebuję tej usługi z Internetu?” Każdy port / usługa, którą otworzysz, staje się kolejnym potencjalnym wektorem, który ktoś może wykorzystać. Jeśli w tej usłudze jest błąd, który pozwala im uzyskać dostęp do serwera root, mogą mieć dostęp do wszystkiego na nim. Twoje bezpieczeństwo jest tak silne, jak najsłabsze ogniwo.
• Teraz ostatnia rzecz i prawdopodobnie najważniejsza. Skrypty, które widziałeś podczas próby uzyskania dostępu do ssh, mogą z czasem odgadnąć twoje hasło. Fail2Ban bardzo je spowolni, ale wciąż mogą to odgadnąć. Jeśli tak, potrzebujesz uwierzytelnienia dwuskładnikowego w dostępnych usługach. W tym celu polecam bezpłatne konto w Duo Security. https://www.duosecurity.com/docs/duounix

Kolejny przykład odpowiedzi @ cff, jeśli zamierzasz zakazać kolejnych prób na swoim serwerze SSH:

sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --update --seconds 600 --hitcount 4 --name DEFAULT --mask 255.255.255.255 --rsource -j DROP
sudo iptables -A INPUT -p tcp -m tcp --dport ssh -m state --state NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
sudo iptables-save

To „taguje” próby połączenia, a jeśli więcej niż 4 zdarzy się w 600s (10 mln), to źródło jest „zbanowane”. Użyj tego zamiast rozwiązania @ cff, ponieważ jest bardziej bezpieczne (jeśli się zablokujesz, poczekaj 10 minut i spróbuj ponownie).