HARD CORE SECURITY LAB

Przyszła dziś pora na odrobinę praktyki. Zastanówmy się, w jaki sposób można sobie skutecznie poradzić z ruchem związanym z atakami typu brute force wymierzonymi w publicznie widoczne konsole SSH?

Otóż tak się składa, że jeśli interfejsy zarządzania serwerami lub urządzeniami sieciowymi za pomocą protokołu SSH są widoczne z całego Internetu, to prędzej czy później przyciągną one nieproszony ruch związany z atakami typu brute force. Tego rodzaju udostępniania SSH dla całego świata najlepiej w ogóle unikać. Czasem jednak jest to konieczne – przykładowo administrator musi mieć dostęp do swych firmowych urządzeń również z domu.

Rozwiązaniem jakie się od razu nasuwa jest stworzenie listy ACL (ang. Access Control List) dopuszczającej tylko zaufane źródłowe adresy IP (czyli np. domowe adresy IP wszystkich administratorów danej usługi). Tego rodzaju rozwiązanie można bez problemu w praktyce skonfigurować w przypadku popularnych urządzeń sieciowych, jak i serwerowych systemów operacyjnych. Znacznie większy problem pojawia się jednak wtedy, gdy administrator danej usługi będzie korzystał z łącza o zmiennym publicznym adresie IP (jest tak przykładowo w przypadku popularnej Neostrady). W takim przypadku stworzenie statycznej listy ACL jest w praktyce niemożliwe... warto jednak wtedy skorzystać z dobrodziejstw projektu SSH blacklist.

SSH blacklist publikuje aktualizowaną co godzinę listę adresów IP, z których pochodzą ataki brute force na usługę SSH udostępnioną na kilku maszynach testowych utrzymywanych przez organizatorów tego interesującego projektu. Warto więc utworzyć (i co jakiś czas aktualizować) listę ACL w oparciu o listę publikowaną przez sshbl.org. Jak się bowiem w praktyce okazuje, zawiera ona ogromną większość aktywnych w danej chwili intruzów polujących na konsole SSH, dzięki czemu znacznie zredukujemy lub nawet zupełnie wykluczymy tego rodzaju ruch skierowany do naszych urządzeń.