Notatnik » ssh

nie weszłeś… ;)

krolik — Fri, 18 Sep 2009 08:42:22 +0000

Sep 17 18:35:25 shell sshd[59982]: Invalid user deutch from 217.133.97.38
Sep 17 18:35:31 shell sshd[59984]: Invalid user german from 217.133.97.38
Sep 17 18:35:34 shell sshd[59986]: Invalid user hitler from 217.133.97.38
Sep 17 18:35:41 shell sshd[59993]: Invalid user deutchland from 217.133.97.38
Sep 17 18:35:41 shell sshguard[80272]: Blocking 217.133.97.38: 4 failures over 16 seconds.

hitler, nie wszedł

sshguard

krolik — Fri, 30 Jan 2009 08:04:54 +0000

Jeśli ktoś musi (chce) mieć wystawiony port 22 dla całego internetu musi liczyć się z tym, że po niedługim czasie w logach serwera zacznie się pojawiać lawina nieudanych prób zalogwania na całkiem przypadkowe konta.

Na szczęście jest na to sposób. Jakiś miesiąc temu natknąłem się przypadkowo (szukając zupełnie czegoś innego ) na program o nazwie sshguard. W systemie FreeBSD skrypty instalacyjne podpinają go do syslog.conf w ten sposób:

auth.info;authpriv.info |exec /usr/local/sbin/sshguard

W domyślnej konfiguracji cztery próby w ciągu dwóch sekund zakończone niepowodzeniem są identyfikowane jako działanie bota i adres IP z którego były nawiązywane połączenia jest blokowany. U mnie odbywa się to za pomocą tcpwrappers (wpis do hosts.allow).

Ze strony projektu można się dowiedzieć, że isnieje możliwość zintegrowania sshguarda z różnego rodzaju firewallami. Np. pf, ipfw, iptables. Poza sshd, potrafi analizować też logi proftpd, pure-ftpd, ftpd (FreeBSD), dovecota, UWimap.

Zanim napisałem tego posta, zerknąłem na auth.loga z ostatniego miesiąca i stwierdzam, że ostatnia aktywność botów ssh, była 12-go stycznia b.r. To dosyć dawno jak na publicznie otwarty port 22. Więc albo ludzie pokasowali wirusy i pozaciągali Windows Update, albo sshguard odstraszył botnety i trafiłem na jakieś ich ignore-listy lub coś w tym stylu

chwile grozy

krolik — Mon, 29 Sep 2008 18:21:10 +0000

Właśnie jestem świeżo po instalacji Kubuntu na swoim laptopie. Tak, już nie mam FreeBSD W trakcie działania instalatora, na etapie instalacji nowych plików (formatowanie partycji już było zakończone) zdałem sobie sprawę z jednej zajebiście istotnej rzeczy….
Zapomniałem o skopiowaniu swoich kluczy ssh. Z początku nie wydawało mi się to aż tak straszne. Jednak w chwili kiedy zdałem sobie sprawę, że hasła na konto root do serwera z freebsd właściwie nie pamiętam… miałem całą pieluchę. Tak to jest… od zawsze używałem swoich kluczy do dostawania się na ten serwer, także nie przywiązywałem uwagi do tego, że nie znam hasła. Gdyby nie to, że dodałem jakiś czas temu drugi swój klucz, który wygenerowałem na służbowym PC, już bym miał ciepło… Obecna konfiguracja systemu Uniemożliwia całkowicie zdalną interwencję ekip mojego usługodawcy.
Jak to się mówi: „Więcej szczęścia, niż rozumu”. Wniosek jaki płynie z tej lekcji: Warto zawsze zrobić sobie alternatywną konfigurację.

ssh-askpass

krolik — Sun, 01 Apr 2007 17:11:56 +0000

Bardzo przydatnym i szeroko wykorzystywanym narzędziem u mnie w firmie jest ssh-add. Poniżej zamieszczam krótki skrypt który na pewno przyda się użytkownikom FreeBSD. Spowoduje on ustawienie dla całej sesji KDE informacji o kluczu ssh oraz uruchomienie w trybie graficznym prompta do wpisania hasła do klucza. Wymaga dosinstalowania pakietu OpenSSH-askpass. Skrypt należy umieścić w katalogu: ~/.kde/Autostart

#!/bin/tcsh
eval `/usr/bin/ssh-agent`
setenv SSH_ASKPASS ‘/usr/X11R6/bin/ssh-askpass’
dcop klauncher klauncher setLaunchEnv SSH_AGENT_PID „$SSH_AGENT_PID”
dcop klauncher klauncher setLaunchEnv SSH_AUTH_SOCK „$SSH_AUTH_SOCK”
ssh-add
Prompt do wpisania hasła ładniej wygląda po przypisaniu zmiennej SSH_ASKPASS wartości /usr/local/bin/ssh-askpass-fullscreen. Program ten pochodzi z pakietu: ssh_askpass_gtk2