vermin.eu.org

Dzieje się tak czasem, że wygląd historii został zaburzony przez pewne fakty, zakłócając obraz do tego stopnia, iż nie potrafimy skupić się na niczym innym. Potrafi się to stać (i dzieje się) także dla MRTG. Ponieważ skaluje on tworzone obrazki dynamicznie nagłe zakłócenie danych oscylujących na pewnym okreslonym poziomie olbrzymim w stosunku do nich pikiem, powoduje zakłócenie radości z oglądania owych fluktuacji. Można sobie zadać pytanie - skoro monitorujemy, to przecież chcemy wiedzieć co się dzieje?

Tak - to prawda, niemniej czasem, ze względu chociażby na możliwość czasowego wyłączenia agenta SNMP odczytującego wewnętrzne rejestry maszyny jego nagłe włączenie potrafi podać olbrzymią daną (agent SNMPd podaje dane różnicowo - jeśli nie wie jaka była poprzednia wartość zwróci aktualną wartość rejestru… która może być zaskakująca). Dzieje się to chociażby przy restarcie maszyny. Oczywiście można zapobiec takim sytuacjom podając zmieniając ciut konfigurację agenta, my niemniej zejdziemy do poziomu pliku logów i poprawimy jego zachowanie.

MRTG wykorzystuje do gromadzenia danych RRD. Jest to taka specyficzna baza danych, która z upływem czasu bardzo nie rośnie, a jedynie zmienia się jej zawartość/rozdzielczość w czasie. Wynika to z faktu, iż jest ona tworzona w oparciu o szczegółowe interwały czasowe (tu: dzień/tydzień/miesiąc/rok), ze szczegółową dokładnością (odpowiednio 5 minut/30 minut/godzina/dzień), które wraz ze starzeniem się, przesuwają się w dół, tracąc nadmiarowe, nie potrzebne na danym poziomie szczegółowości dane.

Wystarczy w związku z tym popatrzeć na nasze zaburzone wykresy, zapamiętac kiedy wystąpiło zaburzenie, otworzyć plik log powiązany z daną/interfejsem, który monitorujemy i… ujrzeć stado cyfr.
Pierwsza linijka pliku RRD zawiera informacje o tym kiedy była wykonana na nim ostatnia operacja i (dla interfejsu) ilość danych wchodzących i wychodzących:
1172975401 828445773 1460749062
Czas podany jest w sekundach od 01-01-1970. Można to przełożyć na nasze za pomocą np. funkcji Excela

Kolejne linijki mają zbliżony format, różnią się jedynie pozostałymi czterema kolumnami - są to odpowiednio średni ruch wchodzący/interwał, średni ruch wychodzący/interwał, maksymalny ruch wchodzący w odcinku czasu, maksymalny ruch wychodzący/interwał.
1172527200 119 4209 718 25418

My jednak jesteśmy w innej sytuacji - znamy mniej więcej moment wystąpienia złej danej - trzeba go wyszukać i zneutralizować.
Zamieniamy szukaną datę (zaokrągloną do pełnej godziny lub północy szukanego dnia) na odpowiednią liczbę sekund - znów przychodzi z pomocą Excel, zakładając, że datę mamy wpisaną w komórce A1:

Teraz tylko otworzyć plik logów, znaleźć inkryminowany czas, wyliczyć średnią z otaczających pól, żeby jakaś wartość jednak była w tym miejscu i koniec. Po chwili równej interwało odświeżania danych pliki wykresów poprawią się. Oczywiście jeśli jest to na wykresie rocznym/miesięcznym to ta chwila może być dłuższa, warto więc skasować pliki *.png i poczekać, aż skrypt je odtworzy.

Źródło: MRTG-logfile

Od kawałka czasu padłem ofiarą spam botów, które śmiecą mi w logach swoimi adresami oraz wysycają moje biedne (SDI rulez!) łącze. Pokazuje to przyjemnie i slimstat, jak i kilka obrabiających logi apache demonów. Cóż - temat stary jak świat (pierwsze posty na ten temat jakie czytałem pochodziły z 2002 roku), a rozwiązanie banalne. Wystarczy w zasadzie poblokować w .htaccess słowa kluczowe (i niestety aktualizować je co jakiś czas) prostą regułą:

Dzięki temu spamerzy zostaną przekierowani do siebie samych. Minusem tego rozwiązania jest zakaz używania powyższych słów tytułach własnych postów (jeśli mamy włączone permlinki), ale to chyba nie będzie miało u mnie miejsca.

Jak sprawdzić, że blokada działa? Prosto - używamy narzędzia wget (jest także pod Windows!)

i ściągamy nie naszą-super-witrynę.com ale właśnie spamerskie dmost.

Rozszerzeniem tej idei jest blokowanie adresów IP spamera, na przykład za pomocą przekierowania na plik PHP i wywołania

, ale po pierwsze - zablokujemy jakieś tam adresy ze spam-netu, iptables wymaga niewirtualnego hostingu, i po ostatnie - jeśli ktoś może uruchomić iptables z uprawnieniami roota z konta na którym działa apache to gratuluję… odwagi? głupoty?

P.S. Chociaż może tego nie widac na podstawie tego bloga - ale ja naprawdę czytam także inne rzeczy niż logi

Typowy scenariusz - mamy serwerek FTP, oczywiście chrootujemy użytkowników do katalogów domowych. Nagle okazuje się, że jeden z nich musi mieć dostęp do dodatkowych danych, np. utrzymać stronę WWW, którą do tej pory zajmował się inny użytkownik. Symlinki oczywiscie nie wchodzą w grę, ale jest kilka opcji:

• można dać mu kolejny login i hasło, (które zgubi, zapomni), co jest proste dla admina, ale niewygodne dla usera
• można przekopiować dane do jego katalogu, zmienić uprawnienia, zmienić konfigurację apache, co jest trudne, długie, wymaga restartu usługi, no i jak ten user odejdzie, to trzeba operację powtórzyć
• można też zastosować rzecz wygodną i dla admina i dla usera - czyli mount

W zasadzie wydanie komendy

załatwia nam sprawę (jak to jest na czas powyżej średniego uptime maszyny to warto to dodać do /etc/fstab). Proste, czyste, przyjemne

Źródło: MDLog:/sysadmin

Sobota, godziny popołudniowe, szybki look w logi i co widzę? Gdzieś w środku nocy, jakiś dzieciak zza oceanu wybrał sobie jeden z moich serwerków w celu przetestowania swoich narzędzi. Bardzo to niefajne, bo szybkie łącze pozwoliło mu na dosłownie zalanie serwera requestami o autoryzację - do DOSa nie doszło - niemniej jest to trochę wkurzające…

O ile SSH się w miarę łatwo zabezpiecza przed zbyt duża ilością wpisów, to już serwery FTP zabezpieczyć trudniej. Z pomocą przychodzą dwa narzędzia - pierwsze z nich to znane z pakietu *sentry Logsentry, zaś drugie, nad którym się skupię - fail2ban. Obydwa działają tak samo - monitorują logi i na tej zasadzie podejmują odpowiednie działania. Obydwa mają zbliżone zalety i tą samą wadę - regexpy¹. Obydwa używają /etc/deny.hosts lub iptables. Obydwu nie ma w stable

Fail2ban niestety nie znajduje się w stable - jest za to w testing i unstable, więc można go ściągnąć stamtąd lub bezpośrednio ze stron projektu Debian. Z wymogów instalacyjnych trzeba wspomnieć o pythonie i lsb-base, które na szczęście są w stable i to w odpowiednich wersjach. Po instalacji fail2ban od razu rozpoczyna działanie - niemniej dobrego admina to nie zadawala i od razu rusza do /etc/fail2ban.conf, żeby poprawić konfigurację.

Co warto zmienić? Na pewno warto dodać listę adresów, które nie będą blokowane (bo w końcu każdy może wysłać stworzone przez siebie pakiety wskazujące na dowolne IP) - opcja ignoreip. Kolejną opcją, którą warto zmienić, to czas blokady (bantime) - domyślne 10 minut to za mało - warto dać więcej, a mając fizyczny dostęp do maszyny nawet -1 (for ever). Jeśli ktoś lubi, to warto włączyć opcję powiadamiania emailem o zablokowaniu konkretnego IP (jeśli dostajemy wiadomości w stylu in-your-face, to trudniej zapomnieć, że taki niskopoziomowy mechanizm gdzieś tam sobie działa i można szybciej zdiagnozować problem). Pozostaje włączenie odpowiednich demonów, czyli zmiana enabled na true w odpowiednich sekcjach pliku konfiguracyjnego.
Domyślnie skrypt ma wpisane kilka typowych demonów - SSH (włączone domyślnie), SASL, Apache, ApacheAttacks, VSFTPD, PROFTPD, ale bazując na wyrażeniach regularnych¹ można dodać dowolne inne, co jest duuużym plusem. Kolejnym plusem jest przyjemna konfiguracja iptables, którą wykonuje program - tworzy własne łańcuchy opisujące przez jaką regułę dany IP został zablokowany, co pozwala łatwiej przejrzeć logi w razie narzekań userów czy innych adminów.

¹regexpy to mieszane błogosławieństwo - pozwalają na wspaniałe dostosowanie programu pod de facto dowolnego demona, niemniej pozwalają także na przemycenie, przez użycie zbyt szerokiego zakresu wyrażenia, błędów, pozwalających w tym wypadku na DOS maszyny…

Warto poczytać dodatkowo: Debian Administration

Na SBSie po instalacji standardowo stoją conajmniej dwie instancje SQL Server - jedną z nich jest SBSMONITORING, drugą SHAREPOINT. Jesli mamy ISA Server to dodatkowo jest jeszcze MSFW. Jest tego od groma, a jak można się zorientować na mojej małej stronce o SBSie, z instancjami (pseudo) SQL Servera na SBS są zazwyczaj problemy - po pierwsze na pewno jakieś są zainstalowane, po drugie działają i zabierają pamięć, po trzecie - co to jest kurcze blade? I to pytanie wcale nie jest takie bezpodstawne, bo postawienie dodatkowo SQL Servera z płytki Premium, WSUSa powoduje, że spokojnie mamy conajmniej 3 różne silniki… Więc który z nich obsługuje co?

Przystępujemy do pracy:
Najpierw sprawdzamy co właściwie u nas działa: task manager pokazuje, że procesy SQL istnieją (sqlservr.exe). Każda instancja (SBS Monitoring, Sharepoint, etc.) ma swój proces w ramach którego istnieje - jak sprawdzić, która to która?
Konsola: tasklist /svc i już widzimy który proces (numer PID jest tu wyróżnikiem) obsługuje jaką bazę. Teraz spokojnie możemy zobaczyć co sprawia problemy, (która instancja).

Teraz warto sprawdzić w zasadzie co jest obsługiwane przez co - czy wszystko przez SQL Server, czy może przez MSDE, a może przez (W)MSDE (a na pewno instancja MSSQL$SBSMONITORING nie powinna być na SQL Server). Znowuż - jak to zrobić?
Wchodzimy tam gdzie są logi (albo c:\program files\Microsoft SQL Server\nazwa$instancji\LOG albo tam gdzie są logi). Otwieramy plik z logami i jeśli mamy Desktop Engine on Windows NT 5.2, to NA TEJ INSTANCJI jest MSDE, jeśli Desktop Engine (Windows) on Windows NT 5.2 to WMSDE, jeśli Standard Edition on Windows NT 5.2, to mamy faktycznie SQL Server.

Dzięki temu będzie nam łatwiej rozwiązywać standardowy problem z pamięcią na odpowiedniej instancji

Pierwsza część artykułu przeprowadziła nas przez prostą konfigurację postfixa, zapobiegającą przerobieniu naszego serwera na open-relay przy pomocy autoryzacji poprzez pop-before-smtp. Dziś czas na część drugą, czyli jak szybko włączyć autoryzację, tls i mieć to z głowy.

Pierwszą rzeczą jaką trzeba sprawdzić, to czy mamy zainstalowane potrzebne pakiety:

• postfix-tls
• sasl2-bin
• libsasl2
• openssl
• libsasl2-modules

Ruszamy - naszym celem są następujące pliki:

• /etc/postfix/main.cf, czyli plik zawierający opcje postfixa
• /etc/postfix/sasl/smtpd.conf, sposoby autentykacji sasl
• /etc/postfix/smtpd.key, klucz, którym będzie autoryzowany postfix
• /etc/default/saslauthd, konfiguracja demona SASL, który będzie dokonywał autentykacji
• /etc/fstab, nawet tu będziemy musieli dokonać zmiany, jeśli chcemy, żeby sasl działał poprawnie

Na pierwszy ogień idzie konfiguracja postfixa - otwieramy /etc/postfix/main.cf i dodajemy linie:

• smtpd_sasl_auth_enable = yes, odpowiada za włączenie mechanizmu autoryzacji
• broken_sasl_auth_clients = yes, pozwala na autoryzację klientom takim jak OE. Nazwa opcji jest swoją drogą jednoznaczna…
• smtpd_use_tls = yes, pozwalana włączenie szyfrowania transmisji
• smtpd_tls_cert_file = /etc/postfix/smtpd.cert, informuje gdzie znajduje się klucz publiczny serwera
• smtpd_tls_key_file = /etc/postfix/smtpd.key, dla odmiany wskazuje lokalizację klucza prywatnego
• do linijki smtpd_recipient_restrictions = dodajemy opcję permit_sasl_authenticated. Należy ją dodać przed jakimkolwiek zakazem typu reject.

Postfix już skonfigurowany - teraz pozostaje mu tylko dostarczyć dane, które obiecaliśmy. Na pierwszy ogień idzie autentykacja. Przede wszystkim otwieramy plik /etc/default/saslauthd i ustawiamy opcje

(lub “pam” lub “pam shadow”). Szybciutko restartujemy demona (/etc/init.d/saslauthd restart).
Nie jest to wszystko - drugi plik, którym musimy się zająć (a wręcz stworzyć ), to /etc/postfix/sasl/smtpd.conf. Opisuje on jakim mechanizmem posłużymy się do autentykacji - możemy użyć baz danych lub też w opisywanym przypadku, skonfigurowanego przed chwilą demona odwołującego się do kont systemowych. W naszej sytuacji wystarczy do tego pliku dodać linie

W perfekcyjnym świecie to byłoby wszystko, w tym mniej doskonałym okazuje się, że dostaniemy komunikat

Dzieje się tak, ponieważ domyślnie sasl tworzy swój socket w /var/run/saslauthd/ a postfix, działający w chrootowanym środowisku szuka plików w (domyślnie) /var/spool/postfix/var/run/saslauthd/. Tworzenie katalogu (mkdir -p /var/spool/postfix/var/run/saslauthd) a potem tworzenie softlinka (ln -s) jest tu oczywiście opcję, niemniej nie rozwiązującą sytuacji. Dużo lepszym rozwiązaniem (i dość permanentym), jest zamontowanie tego katalogu poprzez dowiązanie. Na stałe rozwiązuje to odpowiednia linijka w /etc/fstab:

.
I już jest prawie dobrze gdyby nie to, że przy próbie autentykacji okazuje się że coś jest nie tak z uprawnieniami (warning: SASL authentication
failure: cannot connect to saslauthd server: Permission denied; warning: SASL authentication
failure: Password verification failed; SASL PLAIN authentication failed). Żeby poprawić sytuację wystarczy dodać postfixa do grupy sasl komendą usermod -G sasl postfix i już po sprawie.

Po restarcie autentykacja już działa. Możemy sprawdzić to telnetując się na port 25. Po komendzie ehlo wyświeli nam się linijka z wspieranymi rodzajami autentykacji. My wydamy następną komendę - AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q=. Jeśli mamy użytkownika o loginie test i haśle test to autoryzacja przebiegnie pomyślnie. A tak przy okazji - jeśli nie mamy, to ciąg znaków za metodą PLAIN możemy łatwo uzyskać za pomocą następujące komendy:

jeśli mamy oczywiście zainstalowanego albo perla z modułem MIME::Base64 albo xemacs21-bin

Pozostała nam kwestia bezpieczeństwa. Musimy utworzyć parę kluczy, tak aby można było hasło przesyłać bezpiecznie. W tym zakresie wystarczy wykonać polecenie

. Wpisanie danych daje nam ważny rok, podpisany samemu przez siebie certyfikat. Jeśli mamy certyfikat kwalifikowany, to wystarczy go dograć w to właśnie miejsce.

Voila - cel osiągnięty. Teraz pozostaje dodać spamassassina oraz clamav’a i mamy prosty, funkcjonalny serwer pocztowy, ale o tym w następnych odcinkach.

Logi w systemie Windows to temat straszliwie zagmatwany. System ten potrafi i ma możliwości, (oczywiście z pogwałceniem wydajności), logowania praktycznie chyba wszystkiego. Możliwość ustawienia performace meters, (dzienniki wydajności), pozwala śledzić problemy sprzętowe a sam Event Viewer (Podgląd zdarzeń) przechowuje zdarzenia aplikacyjne i sprzętowe, domyślnie podzielone na aplikacje, system i zabezpieczenia (na stacji roboczej, w serwerze dochodzą jeszcze Serwer
DNS, Usługa katalogowa i Usługa replikacji plików). Oczywiście kategorii tych może być więcej, np. IE7b2 stworzył sobie swoją, podobnie zresztą sterowniki ATI (ACEEventLog).

pozornie niska szczegółowość
Problemem jednak jest fakt, iż zazwyczaj wiele różnych kategorii zdarzeń zapisywanych jest do tych raptem 3 głównych. Jest to niemiłe jeśli prowadzimy jakiś audyt dostępu do obiektów czy też audyt użycia uprawnień. Event Viewer nie spełenia niestety swojej roli zbyt dobrze - ma niby możliwości filtrowania zdarzeń, ale kiepskie to i dalekie od fleksyjności PERLa, który niestety na nic tu nam, gdyż same logi są zapisane w formacie binarnym. Ponieważ zazwyczaj niestety IT w polskim sektorze MiŚP nie jest zbyt dofinansowane a budżet skończył sie w momencie zakupienia redundantnego zasilania do serwera, musimy sobie jakoś radzić.

kilka komputerów to nie problem!
Chcąc ściągnąć logi z kilku maszyn polecam narzędzie o nic nie mówiącej nazwie EventCombMT. Pozwala ono ściągnąć na jedną maszynę logi z kliku, co już ułatwi adminowi koniecznośc przelogowywania się, odpalania Remote Desktop (czy innego rdesktop’a pod linuxem - przypominam tylko, że linux potrzebuje wredne licencje dostępowe CAL…). Samo narzędzie swoją droga jest częścią pakietu Account Lockout and Management Tools, który pozwala na sprawdzenie czemu ktoś akurat nie może się zalogować do maszyny, domeny, etc.

ulepszone przeglądanie, czyli czy jest coś lepszego niż PERL
OK - mamy logi z kilku maszyn, niemniej jesteśmy w tej samej głupiej sytuacji. Jak z tego całego tatałajstwa wyciągnąć pożądane przez nas informacje? Z pomocą przyjdzie nam inne przemiłe i darmowe narzędzie LogParser. Nie wiedzieć czemu stanowi on część pakietu Internet Information Services (IIS) 6.0 Resource Kit Tools, niemniej nie umniejsza to jego wspaniałej roli w wyciaganiu potrzebnych nam zdarzeń. Opierając się na składni zbliżonej do SQL pozwala on na wyciągnięcie naprawdę ciekawych szczegółów. Co lepsze - pozwala na wybranie odpowiadającego nam sposobu prezentacji -zarówno czysto tekstowej, HTML jak i wykresów! Nie jestem zwolennikiem IIS jako web serwera, niemniej zamiast webalizera taka zabawka spełniłaby się na pewno
Przykładowo

pozwoli na przejrzenie historii logowań. Inne przykłady znaleźć można na http://www.logparser.com/, czytając ciekawy artykulik ze skrypty ;-), czy też polskie opracowanie na WSS.

No ale co z tego wynika?
Analiza logów niestety też nie jest zbyt wdzięcznym zajęciem. Tu zazwyczaj niestety albo eventid.net albo google i dokładny zapis komunikatu błędu. I tu niestety kłania się polskim adminom jakość tłumaczeń - ciężko czasem wpaść jako to właściwie brzmi po angielsku i jak niektóre pojęcia się mapują pomiędzy językami. Bez tego niestety zazwyczaj admin wpadnie po uszy - większość artów w KB jest w języku angielskim. Cóż - przy zakupie nowych serwerów polecam wersje EN (dla odmiany zdecydowanie nie przy SBSie, z którym przy mieszaniu wersjami sharepointa i windowsa wychodzą czasem niemiłe sytuacje). W zasadzie nie znalazłem poza wzmiankowanymi witrynami żadnych innych darmowych narzędzi pozwalających na szybki troubleshooting Little help, anyone?

W poprzednim artykule o ssh pisałem o opcji logowania się za pomocą kluczy. Ponieważ z różnych ważnych powodów musiał zostać podniesiony poziom zabezpieczeń (ot choćby żeby pokazać, jak to sie człowiek stara ), zaimplementowałem w końcu ten przemiły sposób logowania. Polega on w skrócie na tym, iż potrzebna jest para kluczy - klucz publiczny, umieszczany na serwerze, oraz klucz prywatny, znajdujące się w posiadaniu użytkownika. Literatura mówi, iż klucz prywatny jest nieodtwarzalny z klucza publicznego, ale klucz publiczny z prywatnego już tak. Ponadto rzeczy zakodowane kluczem publicznym odczytywane są tylko za pomoca komplementarnego klucza prywatnego i vice versa, rzeczy zakodowane przy pomocy klucza prywatnego odczytywane są tylko przy pomocy klucza publicznego. To pierwsze przydaje się do szyfrowania, to drugie do autentykacji. Tyle teorii, przejdźmy do rzeczy.
Przede wszystkim musiałem ustawić ssh - /etc/sshd_config przeszło następujące zmiany:

• PasswordAuthentication no - w połaczeniu z ChallengeResponseAuthentication no pozwoliło na zablokowanie logowania za pomocą haseł. Samo wyłączenie autetykacji za pomocą haseł nie chce działać. Literatura sieciowa sugeruje jeszcze wyłączenie PAM, ale mimo wszystko nie wydaje mi sie to konieczne, a nawet wręcz przeciwnie.
• AuthorizedKeysFile %h/.ssh/authorized_keys włączyło (domyślne) położenie pliku zawierajacego klucze publiczne,
• W moim szczególnym przypadku użyłem opcji AllowUsers i DenyUsers żeby wyspecyfikować grupy użytkowników mogące się logować oraz tych, którzy w żaden sposób niepowinni. Działają tu tylko nazwy użytkowników, nie ich id, można używać znaków * oraz ?.

Po tej przymiarce, ZANIM zrestartujemy sshd, musimy wygenerować nasz klucz (żeby w razie zerwania sesji móc się wbić ponownie na serwer. Ogólnie to ten krok warto zrobić najpierw :-)…
Generowanie zestawu kluczy jest dość banalne - albo użyjemy ssh-keygen -t rsa a on interaktywnie przeprowadzi nas przez tworzenie klucza albo skorzystamy z pakieciku putty i jego składowego programiku keygen. Którejkolwiek opcji byśmy nie używali warto wpisać hasło (passphrase) którym zabezpiecznym klucz. Zdecydowanie podnosi to bezpieczeństwo wg paradygmatu: coś co się zna (login, hasło) oraz coś co się ma (klucz). Bez klucza nikt się nie zaloguje, przechwytując klucz prywatny, bez hasła też nie (chociaż tu wracamy do ataku typu bruteforce).
Wygenerowany klucz prywatny (domyślnie id_rsa) zapisujemy w bezpiecznym miejscu zaś klucz publiczny przenosimy na serwer do pliku wyszczególnionego w zmiennej konfiguracyjnej AuthorizedKeysFile - zazwyczaj ~/.ssh/authorized_keys.
Sprawa jest już prawie zakończona - jednak jak się logować? W wypadku korzystania do połączeń z putty, można dodać klucz do pageanta, albo w konfiguracji połaczenia wskazać na plik zawierający klucz. W wypadku łaczenia się z pod linuxa, do komendy ssh oprócz standardowych parametrów, takich jak chociażby ?C (kompresja) należy dodać ?i nazwa_pliku_zawierającego_klucz prywatny. Co do używania pageanta, to warto pamiętać o tym, co piszą o nim sami autorzy odpowiadając an pytanie czemu pageant nie działa jako serwis systemowy. W trakcie działania programu klucz jest przechowywany na maszynie w pamięci niezabezpieczony - łatwo (teoretycznie) go stamtąd wyjąć i używać nie korzystając z hasła którym ten klucz zabezpieczyliśmy.
Bezpiecznego logowania!

Mnóstwo skryptów powstało w celu ataku na niezabezpieczone demony ssh. Standardowy atak polega na przeczesaniu zakresu adresów IP w celu odnalezienia otwartych portów 22 (enumeration) a następnie atak na działającego tam demona.
Jest kilka metod mogących zabezpieczyć przed tego typu aktywnością:

• blokada na poziomie sshd_config:
  • opcja PermitRootLogin powinna być ustawiona na no, co automatycznie zabezpieczy przed wejściem z zewnątrz na konto root (pozostaje droga zwykłe konto -> su/sudo),
  • opcja MaxStartups pozwoli na uruchomienie tylko odpowiedniej ilości watków nasłuchujących i podtrzymujących przez LoginGraceTime otwarte połączenie a stanie niezautoryzowanym - dodatkowo podanie listy trzech parametrów, np, 10:30:60 powoduje uruchomienie ssh w trybie pozwalającym maksymalnie na 10 połaczeń anonimowych, z czego co trzecia próba połączenia będzie odrzucanoa (30%), która to liczba będzie rosła wraz z nasileniem ataku aż do 60% odrzuconych połączeń,
  • opcj PermitEmptyPasswords powinna być ustalona na nie - w ten sposób zabezpieczymy się przed ustawieniem pustego hasła i możliwością zalogowania na taie konto - oczywiście nie broni nas to przed atakaiem na konto test/test, dupa/dupa czy inną ambitną kombinacją,
  • w skrajnej sytuacji możemy zabronić logowania ssh bez posiadania klucza prywatnego powiązanego z danym loginem - co niestety powoduje konieczność posiadania takiego klucza przy sobie w celu wykonywania zadań administracyjnych - przydatna tu będzie opcja PasswordAuthentication
• blokada na poziomie iptables - możliwe są dwa warianty tej blokady. Jednym z nich jest totalne zablokowanie danego IP przez demona pilnującego logów, takiego jak napisany w pythonie fail2log (zasada działania zbliżona do portsentry), wsparta dodatkowo wpisaniem złego hosta do hosts.deny - czyli wykorzystanie warstwy tcpwrappers chorniącej przy okazji inne usługi mające wkompilowane korzystanie z tego rodzaju zabezpieczeń. Minusem takiego rozwiązania jest możliwy atak typu Denial Of Service, który spowoduje wyblokowanie pewnych klas IP, co może być minusem w wypadku serwera z którego korzystają sieci publiczne typu uzytkownicy neostrady. Drugim jest ograniczenie ilości połaczeń napływających do serwera za pomocą modułów iptables. Przykładowe polecenia wyglądają następująco:
  /sbin/iptables -I INPUT -p tcp –dport 22 -i $EXTERNAL_INTERFACE -m state –state NEW -m recent –set
  /sbin/iptables -I INPUT -p tcp –dport 22 -i $EXTERNAL_INTERFACE -m state –state NEW -m recent –update –seconds 60 –hitcount 3 -j DROP
  Pierwsza z tych linijek spowoduje zaznaczenie, że połączenia z łączego się z portem 22 adresu IP mają wejść w pulę testowaną, druga zaś określa, iż jesli w przeciągu 60 sekund z danego adresu liczba połączeń przekroczy 2, to wszystkie następne są dropowane. Powinno to zdecydowanie zmniejszyć liczbę wpisów w logach. Oczywiście tu także minusem może być tymczasowa odmowa połączenia z naszym hostem - ale jej prawdopodbieństwo jest dużo niższe… i na dodatek zmienne w czasie (60 sekund).

Nie są to oczywiście wszystkie możliwe sposoby - więcej na temat można znaleźć w artykule autorstwa Ryana Twomey opublikowanym na linux.com do którego lektury zapraszam.