Ubuntu логи подключений по ssh
Обновлено: 06.07.2024
Я хотел бы узнать, пытался ли кто-нибудь войти в систему с помощью грубой силы на моем сервере Ubuntu 12.04 через SSH. Как я могу узнать, проводились ли такие мероприятия?
Все попытки входа в систему регистрируются на /var/log/auth.log .
1. Фильтр для брутфорс интерактивных SSH логинов
Откройте терминал и введите ниже; если она длиннее 1 страницы, вы сможете прокручивать ее вверх и вниз; введите q для выхода:
Вот реальный пример одного из моих VPS:
2. Проверьте наличие неудачных подключений (т. Е. Не было попытки входа в систему, может быть сканер портов и т. Д.):
Используйте эту команду:
Как уменьшить количество неудачных попыток входа в систему
- Попробуйте переключить ваш SSH на нестандартный порт из стандартного 22
- Или установите скрипт автоматического запрета, такой как fail2ban .
Я бы сказал, что мониторинг журналов является слабым решением, особенно если у вас есть слабый пароль для учетной записи. Грубые попытки часто пробуют как минимум сотни ключей в минуту. Даже если у вас есть задание cron по электронной почте о грубых попытках, может пройти несколько часов, прежде чем вы попадете на свой сервер.
Если у вас есть общедоступный SSH-сервер, вам нужно решение, которое срабатывает задолго до того, как вас могут взломать.
Я настоятельно рекомендую fail2ban . Их вики говорят, что это делает лучше, чем я.
Fail2ban сканирует файлы журналов (например /var/log/apache/error_log ) и блокирует IP-адреса, которые показывают вредоносные признаки - слишком много сбоев паролей, поиск эксплойтов и т. Д. Обычно Fail2Ban затем используется для обновления правил брандмауэра, чтобы отклонять IP-адреса в течение заданного периода времени, хотя любой Произвольные другие действия (например, отправка электронной почты или извлечение лотка CD-ROM) также могут быть настроены. Из коробки Fail2Ban поставляется с фильтрами для различных сервисов (apache, curier, ssh и т. Д.).
Получить защиту от него так же просто, как sudo apt-get install fail2ban .
По умолчанию, как только у кого-то есть три неудачные попытки, его IP получает пятиминутный бан. Такая задержка, по сути, останавливает попытку перебора SSH, но это не разрушит ваш день, если вы забудете свой пароль (но вы все равно должны использовать ключи!)
Основные log файлы Ubuntu
Лог загрузки
Начнем с самого начала. В момент загрузки системы записывается вся основная информация, имеющая к ней отношение. Если у вас будут какие-то ошибки во время старта сервера, вы сможете их увидеть в этом логе. Посмотреть лог загрузки Ubuntu можно следующим образом.
У вас получится очень длинный вывод всего того, что происходило с системой на старте. Если ищите что-то конкретное, то можете сделать фильтрацию вывода с помощью grep. Допустим, вам надо узнать информацию только о диске.
Вы увидите лог загрузки системы ubuntu, содержащий информацию только о диске sda. Аналогичным образом можно фильтровать вывод по другим темам. Например, посмотреть все ошибки, которые были во время загрузки.
И так далее. Информация, которую выводит команда dmesg, хранится в log файле /var/log/dmesg .
Логи авторизации, в том числе ssh
Для того, чтобы узнать, кто и когда проходил авторизацию на сервере ubuntu, можно воспользоваться логами из файла /var/log/auth.log . Авторизация по ssh там будет выглядеть следующим образом.
Не забудьте перезапустить службу sshd для принятия изменений:
После этого логирование подключений по ssh будет более подробное.
Лог локального входа в ubuntu тоже хранится в файле auth.log . Информация о подключении через консоль выглядит следующим образом.
Устройство /dev/tty1 говорит о том, что вход локальный.
Вы можете быстро посмотреть информацию о последних входах в систему с помощью команды last. Эта информация хранится в бинарном логе /var/log/lastlog .
Примерно то же самое можно увидеть с помощью utmpdump.
Логи ошибок в Ubuntu
Рассмотрим теперь вопрос с расположением лога ошибок в Ubuntu. Как такового отдельного error log в традиционных linux системах нет. И Убунта тут не исключение. Ошибки придется искать по системным и программным логам выборкой ключевых слов. Обычно используют следующие фразы:
- error или err
- critical или crit
- debug
- warn
А теперь проверим ошибки в системном логе.
Видим некоторые ошибки в службе systemd-resolved.
Cron logs
Часто хочется проверить лог запуска периодических заданий cron. В Ubuntu, как мне кажется, сделали не удобно. По умолчанию, cron logs не выделены в отдельный файл. Искать их стоит в общем системном логе syslog. Например, в Centos существует отдельный лог-файл /var/log/cron, где собрана вся информация о запущенных заданиях. Предлагаю сделать так же в Ubuntu.
Для этого открываем конфигурационный файл /etc/rsyslog.d/50-default.conf и добавляем туда следующую информацию.
Я добавил в нее cron.none, чтобы логи cron не писались больше в системный лог syslog. После этого перезапустите службы rsyslog и cron и проверяйте изменения.
Теперь у нас все логи Cron в Ubuntu будут в отдельном файле.
Лог действий пользователя
Мне часто задают вопросы, как посмотреть лог действий пользователя в системе или как узнать, какие программы он запускал. По умолчанию, такие действия не логируются в ubuntu. Для этого нужно устанавливать какое-то дополнительное программное обеспечение. Я даже не знаю, кто умеет это делать. Обычно если надо фиксировать действия пользователя, включается лог работы sudo.
Для того, чтобы включить логирование действий пользователя через sudo, редактируем файл /etc/sudoers . Добавляем туда строку.
Теперь выполните какую-нибудь команду через sudo.
Выполненная команда пользователя сохранена в логе sudo.log. Теперь никто не сможет выполнить незаметно административные действия на сервере. Конечно, человек с полными правами сможет изменить любой лог файл, удалив свои действия при желании. Для этого важные логи нужно отправлять куда-то в другое место, но это уже тема отдельной статьи.
На сегодня по логам в Ubuntu у меня все. Желаю вам логов без ошибок и вечного аптайма (шутка, надо ставить обновы и перезагружаться).
В случае если сервер на Linux был взломан, возникает необходимость собрать информацию, например, получить время и IP адреса последних SSH сессий. Это может помочь не только установить источник опасности, но и, например, ответить на вопрос: был ли подобран пароль (или скомпрометирован сертификат) SSH либо злоумышленник воспользовался уязвимостью программного обеспечения.
К счастью, в дистрибутивах Linux хранятся журналы входа в систему, как по сети, так и для пользователей, который непосредственно сидят перед компьютером.
IP адрес предыдущего подключения по SSH
При каждом подключении по SSH выводится строка с IP, с которого было сделано предыдущее подключение, также показывается дата и время этого подключения:
История IP адресов SSH подключений
Кроме последней сессии, в системе хранится информация обо всех успешных входах за последние месяцы. Эта информация содержится в файле utmp / wtmp. На самом деле, файл utmp могут использовать различные программы (не только SSH), которые хотят сохранить информацию о входе пользователя.
Во многих дистрибутивах имеется файл /var/log/wtmp, куда программы записывают входы в систему. Проверить последние записи можно командой:
Все записи, в которых встречаются IP адреса — были сделаны по SSH подключению.
Записи без IP адресов — это входы пользователей, находящихся непосредственно перед компьютером.
Дополнительно вы можете проверить другие файлы журналов: /var/log/secure (на дистрибутивах на основе RH) или /var/log/auth.log (на дистрибутивах на основе Debian). В этих файлах служба sshd обычно хранит следы сделанных подключений, даже если они не стали результатом успешных входов (как это делают utmp/wtmp, которые сохраняют только информацию об успешных входах).
Служба sshd на IIRC Solaris (которая необязательно является sshd службой OpenSSH) хранит эту информацию в /var/adm/messages.
При этом необходимо помнить, что если атакующий получил доступ с правами суперпользователя, то есть скомпрометирован аккаунт root или другого пользователя с повышенными привилегиями, то все записи в файлах /var/log/wtmp или /var/adm/messages могут быть изменены атакующим. Для защиты от этого необходимо регулярно выгружать журналы в безопасное хранилище.
Как узнать, кто в настоящий момент подключён по SSH
Чтобы увидеть пользователей, вошедших в систему, используйте любую из следующих команд:
Следующие команды также покажут активные SSH сессии — у каждой из них различается набор выводимой информации, поэтому вы можете выбрать ту из них, которая вам больше всего подходит:
I have Ubuntu 9.10 installed with sshd and I can successfully connect to it using login and password. I have configured an RSA key login and now have "Server refused our key" as expected. Ok, now I want to check sshd log in order to figure out a problem. I have examined /etc/ssh/sshd_config and it have
Ok. I'm looking at /var/log/auth.log and. it's empty O_O. Changing Loglevel to VERBOSE helps nothing - auth.log is still empty. Any hints how I can check sshd log?
7 Answers 7
If no one else is using the system at the moment you could do what i've done in such cases:
- stop sshd service (at least i've been able to do this while logged in via ssh)
- start sshd manually and add some -d options to get more verbose debug output. Unless you have something funky going on it should use the same keys and config it does when started properly
Creating an answer based on the comments above, credit to @Prof. Moriarty and @Eye of Hell
SSH auth failures are logged here /var/log/auth.log
The following should give you only ssh related log lines
grep 'sshd' /var/log/auth.log
To be on the safe side, get the last few hundred lines and then search (because if the log file is too large, grep on the whole file would consume more system resources, not to mention will take longer to run)
Читайте также: