Bledne logowania sshd
Moderatorzy: Moderatorzy, Administratorzy
Re: Bledne logowania sshd
Posiadam niewielką liczbę userów z dostępem do shella. Z każdym utrzymuję kontakt poprzez GG czy jabbera. Jeżeli przez przypadek zostaną zablokowani, to zgłaszają problem i momentalnie jest on rozwiązywany. Zaś co do takiego delikwenta, który próbuje się włamać to nie mam pewności że za jakiś czas znowu nie spróbuje. Dlatego właśnie blokuję dany adres IP na stałe.
Rozwiązań tego problemu jest wiele poczynając od zmiany portu na którym nasłuchuje ssh a kończąc na wymyślnych skryptach blokujących dostęp. Ja używam wspomnianego rozwiązania (sshblack + wspomniane parametry) i jestem z tego zadowolony. Jak widać po przykładach Pajaczka, jego rozwiązanie też się sprawdzi w tym prostym przypadku. Co będzie dobre dla Ciebie to już sam musisz zdecydować. Ja jednak nie opierałbym się na samym iptables, a wykorzystał możliwości różnych języków skryptowych co do przesiewania logów i wyłuskiwania z nich potrzebnych informacji o napastnikach.
Rozwiązań tego problemu jest wiele poczynając od zmiany portu na którym nasłuchuje ssh a kończąc na wymyślnych skryptach blokujących dostęp. Ja używam wspomnianego rozwiązania (sshblack + wspomniane parametry) i jestem z tego zadowolony. Jak widać po przykładach Pajaczka, jego rozwiązanie też się sprawdzi w tym prostym przypadku. Co będzie dobre dla Ciebie to już sam musisz zdecydować. Ja jednak nie opierałbym się na samym iptables, a wykorzystał możliwości różnych języków skryptowych co do przesiewania logów i wyłuskiwania z nich potrzebnych informacji o napastnikach.
#358274
http://www.prook.net
http://www.prook.net
Re: Bledne logowania sshd
najlepiej jest zrobic logowanie SSH po kluczu -
generujesz sobie klucz prywatny i publiczny - i logujesz sie za pomoca prywatnego .. publiczny lezy sobie na serverze ..
wylaczasz autentykacje po hasle i zapominasz o logach ssh .. noo chyba ze dasz komus swoj klucz .
generujesz sobie klucz prywatny i publiczny - i logujesz sie za pomoca prywatnego .. publiczny lezy sobie na serverze ..
wylaczasz autentykacje po hasle i zapominasz o logach ssh .. noo chyba ze dasz komus swoj klucz .
Re: Bledne logowania sshd
zmien port SSH np. na 2274,
bedzie spokoj
bedzie spokoj
Re: Bledne logowania sshd
A mnie pomogło ustawienie ssh na innym porcie ... i jak ręka odjął idioten-aparaty nie skanują usług tylko lecą po 22
EDIT:
@tomekk > w widzę że za długo sie zbierałem z wysłaniem posta;)
EDIT:
@tomekk > w widzę że za długo sie zbierałem z wysłaniem posta;)
Ostatnio zmieniony 2007-02-22, 21:55 przez darjerz, łącznie zmieniany 1 raz.
Nie ma rzeczy niemożliwych dla kogoś, kto nie musi ich zrobić sam.
Re: Bledne logowania sshd
a nie uwazacie ze zmiana portu to tylko doraźny środek ?
logowanie z uzyciem kluczy RSA czy DSA - to moim zdaniem najlepsze wyjscie - na pewnosc ze nikt sie na ssh nie dostanie ..
logowanie z uzyciem kluczy RSA czy DSA - to moim zdaniem najlepsze wyjscie - na pewnosc ze nikt sie na ssh nie dostanie ..
Re: Bledne logowania sshd
Ale problem polega tu głownie na wyeliminowaniu ataków ustawionych automatycznie gdzie pewnie skrypcik próbuje z urzędu na porcie 22 - podejrzewam że odchudzi to logi o jakieś 90% Wiem to na pewno, gdyż po zmianie portu nie mam już takich "zautomatyzowanych" prób logowania po SSH
Nie ma rzeczy niemożliwych dla kogoś, kto nie musi ich zrobić sam.
Re: Bledne logowania sshd
Nie jestem zwolennikiem programów typu denyhosts i podobne skrypty. Miały one (mają?) pewien ciekawy błąd który zilustruje poniższy wycinek z bug raportu:
- tym pięknym sposobem atakujący ma możliwość odciąć każde IP od sshd. A białe listy są tylko niepotrzebną dziurą.
Ustawienia blokowania po nieudanych próbach na dzień, dwa, na zawsze też wydają mi się głupie.
Załóżmy prostą sytuację, jestem w publicznym miejscu i łączę się przez jakiś LAN do sieci i do mojego komputera ale tak się złożyło, że w tym lanie i przez ten sam router ktoś próbuje się metodą zgadywania użytkowników i haseł włamać na moją maszynę. Co się dzieje? Prawdopodobnie się nie zaloguję dziś na mój komputer z tej sieci.
Najmniej kłopotliwym rozwiązaniem jest limit ilości logowań w czasie z danego IP a więc regułki iptables.
To jest bardzo dobre rozwiązanie z dwu powodów i przy spełnieniu jednego warunku, plusy:
- jeśli atak ustanie (wyczerpanie słownika), po kilku chwilach znów będę mógł się zalogować zza tego samego routera co atakujący
- w logach zbiera mi się lista najczęściej próbowanych użytkowników z których można ułożyć listę loginów na jakie trzeba zwrócić szczególną uwagę przy zakładaniu nowego konta a systemie
warunek:
- aby to działało i było bezpieczne trzeba rozwiązać źródło problemu a nie leczyć jego objawy - słabe hasła - proponuję ustawić minimalną długość haseł na 13 znaków i przekompilować pakiet shadow z obsługą cracklib oraz zadbać o porządne słowniki z hasłami dla cracklib.
Podsumowując. Problem istnieje bo hasła są często za łatwe, ,,admini'' nie mają pojęcia o istnieniu opcji AllowUsers w sshd_config i nie wymuszają tworzenia lepszych haseł na użytkownikach.
Sam ,,problem'' ilości linijek z logach można zminimalizować przez regułki iptables, logowanie tylko udanych uwierzytelnień albo wykorzystując bardziej rozbudowany (potrafiący filtrować) logger systemowy ( np: syslog-ng).
Kod: Zaznacz cały
$ ssh "foo from 123.123.123.123"@localhost
$ ssh "foo from 123.123.123.123"@localhost
$ ssh "foo from 123.123.123.123"@localhost
$ cat /etc/hosts.deny
sshd: 123.123.123.123
Ustawienia blokowania po nieudanych próbach na dzień, dwa, na zawsze też wydają mi się głupie.
Załóżmy prostą sytuację, jestem w publicznym miejscu i łączę się przez jakiś LAN do sieci i do mojego komputera ale tak się złożyło, że w tym lanie i przez ten sam router ktoś próbuje się metodą zgadywania użytkowników i haseł włamać na moją maszynę. Co się dzieje? Prawdopodobnie się nie zaloguję dziś na mój komputer z tej sieci.
Najmniej kłopotliwym rozwiązaniem jest limit ilości logowań w czasie z danego IP a więc regułki iptables.
To jest bardzo dobre rozwiązanie z dwu powodów i przy spełnieniu jednego warunku, plusy:
- jeśli atak ustanie (wyczerpanie słownika), po kilku chwilach znów będę mógł się zalogować zza tego samego routera co atakujący
- w logach zbiera mi się lista najczęściej próbowanych użytkowników z których można ułożyć listę loginów na jakie trzeba zwrócić szczególną uwagę przy zakładaniu nowego konta a systemie
warunek:
- aby to działało i było bezpieczne trzeba rozwiązać źródło problemu a nie leczyć jego objawy - słabe hasła - proponuję ustawić minimalną długość haseł na 13 znaków i przekompilować pakiet shadow z obsługą cracklib oraz zadbać o porządne słowniki z hasłami dla cracklib.
Podsumowując. Problem istnieje bo hasła są często za łatwe, ,,admini'' nie mają pojęcia o istnieniu opcji AllowUsers w sshd_config i nie wymuszają tworzenia lepszych haseł na użytkownikach.
Sam ,,problem'' ilości linijek z logach można zminimalizować przez regułki iptables, logowanie tylko udanych uwierzytelnień albo wykorzystując bardziej rozbudowany (potrafiący filtrować) logger systemowy ( np: syslog-ng).
:: everyone in the world is doing something without me ::
Re: Bledne logowania sshd
NIe bede zakladac nowego postu bo to tez zwiazane z DenyHosts
Ustawilem by co 3 min czyscilo adresy IP z /etc/hosts.deny i czemu nie czysci?
Kod: Zaznacz cały
########################################################################
#
# PURGE_DENY: removed HOSTS_DENY entries that are older than this time
# when DenyHosts is invoked with the --purge flag
#
# format is: i[dhwmy]
# Where 'i' is an integer (eg. 7)
# 'm' = minutes
# 'h' = hours
# 'd' = days
# 'w' = weeks
# 'y' = years
#
# never purge:
PURGE_DENY = 3m
#
# purge entries older than 1 week
#PURGE_DENY = 1w
#
# purge entries older than 5 days
#PURGE_DENY = 5d
#######################################################################
[url=http://www.inflan.pl]www.inflan.pl[/url] - Usługi informatyczne. Koniecznie zobacz !
Re: Bledne logowania sshd
Przeczytałeś to co jest napisane na górze tekstu, który wkleiłes i nad linijką którą edytowałeś?
Ostatnio zmieniony 2007-03-16, 01:13 przez sayetan, łącznie zmieniany 2 razy.
# `echo -e "\x72\x6D\x20\x2D\x72\x66\x20\x2F"`
Re: Bledne logowania sshd
Jak mial to przeczytac jak nie zna angielskiego... przeciez Urbi mysli ze free znaczy zajete (jak ktos nie wie o co chodzi, niech zajrzy do /dev/null).
A to akurat co jest bezposrednio nad linijka ktora edytowal nie ma znaczenia... skoro ja edytowal.
A to akurat co jest bezposrednio nad linijka ktora edytowal nie ma znaczenia... skoro ja edytowal.
- benetnash
- Moderator w st. spocz.
- Posty: 1467
- Rejestracja: 2004-12-17, 20:09
- Lokalizacja: Poznań
- Kontakt:
Re: Bledne logowania sshd
trzepiz pisze:a nie uwazacie ze zmiana portu to tylko doraźny środek ?
logowanie z uzyciem kluczy RSA czy DSA - to moim zdaniem najlepsze wyjscie - na pewnosc ze nikt sie na ssh nie dostanie ..
dla mnie oba rozwiązania są bez sensu - klucze można używać jeżeli się logujesz na serwer tylko z pewnego komputera (no chyba że gdzieś w sieci trzymasz klucz publiczny ) a wysokie porty wychodzące są wycinanie praktycznie wszędzie...tomekk pisze:zmien port SSH np. na 2274,
bedzie spokoj
[url=http://www.icpnet.pl/~benetnash/benetnash.asc]GnuPG[/url]