Zabezpiecz się przed atakami hakerów / włamań na serwery [zamknięte]

Niedawno skonfigurowałem serwer Confluence w moim domu i używam CCProxy do kierowania zewnętrznego portu 80 do wewnętrznego portu 8090, z którego korzysta serwer Confluence. Ale widzę, że co jakiś czas w dzienniku CCProxy pojawiają się nieznane adresy IP. Wydaje mi się, że wynika to z roboty skanującej losowe adresy IP w poszukiwaniu dostępnych portów w celu wykrycia luk w zabezpieczeniach.

To samo widziałem, kiedy otworzyłem port 22 na moim serwerze NAS, aby włączyć SFTP. Nagle mój NAS wysłał mi e-maila o zablokowaniu tego i tego adresu IP, który próbował uzyskać dostęp przez SSH (który również korzysta z portu 22). W tym przypadku właśnie zmieniłem port SFTP na jakiś losowy port w obszarze tysięcy.

Ale co mogę zrobić, aby się przed tym zabezpieczyć? Co można zrobić, aby chronić otwarte porty? Czy mogę po prostu się położyć i mieć pewność, że nazwa użytkownika / hasło wystarczą, aby odeprzeć próby włamania?

Masz rację, są to boty, które skanują w poszukiwaniu otwartych portów i zwykle wykonują atak słownikowy przy użyciu znanych kombinacji adresu e-mail i hasła.

Biorąc pod uwagę, że skanują tylko na niektórych portach, możesz zmienić numer portu na coś innego niż port 80 i dodać ten port w adresie URL, na przykład: mojadomena.com:8090, aby to działało.

Ale jeśli ustawisz, że po 5 błędnych próbach logowania adres IP zostanie trwale zablokowany, to również jesteś bezpieczny. W dzienniku pojawi się wiele takich ataków, a jeśli dziennik jest wystarczająco szczegółowy, najprawdopodobniej nadal będzie pojawiać się ta sama nazwa hosta lub wzorzec z innego adresu IP. Nawet nie rozważaj ograniczenia temp.

Jest na to wiele sposobów.

Sugeruję utworzenie VPN i wymaganie dostępu przez VPN przed uzyskaniem dostępu do Confluence.

Następną rzeczą byłoby użycie HTTPS. Jeśli umieścisz go za serwerem proxy, możesz nawet wymagać certyfikatów klienta.

Używanie czegoś takiego jak fail2ban i przyzwoite hasła powstrzymają brutalne ataki Force, ale nie wykorzystają podatnego kodu w Confluence, jeśli taki istnieje (i przypuszczam, że może). Całkowite zapobieganie dostępowi do aplikacji do czasu przeprowadzenia innej weryfikacji musi być lepsze.