Атака на SSH сервер. Как пользоваться fail2ban. Разбор лога.
Я арендую сервер для своих рабочих нужд у компании reg.ru, я им доверяю. Я слежу за безопасностью ПО на сервере, анализирую логи, принимаю определенные меры безопасности. Недавно я посмотрел вывод команды:
и увидел там много веселого! (смотреть скриншот в следующем посте), эти строки показывают сообщения об ошибках, связанных с попытками подключения по SSH к моему серверу (они повторяются много раз). Я думаю будет полезно разобрать данную ситуацию, ибо в последнее время активно атакуются Российские IT компании со стороны США, Украины. Не буду томить, здесь простейший перебор на дурачка, перебираются часто встречающиеся пользователи, пароли, чтобы получить доступ к системе, попытка взломать сервер, как я это понял ? Журнал
Объяснение ошибок:
kex_protocol_error:
Указывает на ошибки в процессе обмена ключами (key exchange) на этапе предварительной аутентификации. Это может быть связано с несовместимостью протоколов или ошибками в передаче данных.
kex_exchange_identification:
Клиент отправил неверный идентификатор протокола. В данном случае клиент попытался подключиться к SSH-серверу, используя запрос HTTP, что является некорректным. Сообщение kex_exchange_identification: banner line contains invalid characters указывает на то, что строка баннера, отправленная клиентом, содержит недопустимые символы.
MaxStartups throttling:
Сервер достиг предела по количеству одновременных незавершенных попыток подключения (MaxStartups). Это механизм защиты от DoS-атак, который ограничивает количество параллельных подключений.
Возможные причины:
- Попытки несанкционированного доступа или автоматизированные сканирования (боты, пытающиеся найти уязвимости).
- Несовместимость протоколов между клиентом и сервером.
- Ошибки конфигурации клиента или сервера SSH.
Рекомендации:
1. Проверка конфигурации:
- Убедитесь, что конфигурация SSH-сервера корректна и соответствует требованиям безопасности.
2. Журналирование и мониторинг:
- Продолжайте мониторинг логов для выявления подозрительной активности.
3. Ограничение доступа:
- Ограничьте доступ к SSH по IP-адресам, если возможно.
- Используйте firewall для блокировки подозрительных IP-адресов.
4. Обновление программного обеспечения:
- Убедитесь, что ваш SSH-сервер и клиент обновлены до последних версий.
5. Использование fail2ban:
- Рассмотрите возможность использования fail2ban или аналогичных инструментов для автоматической блокировки IP адресов, совершающих подозрительные попытки подключения.
Действия:
При конфигурации
Установка fail2ban сервиса:
Добавить конфигурацию для sshd в
Перезапустить:
Можно понаблюдать процесс блокировки левых IP адресов, которые обращаются к серверу по SSH (блокировка осуществляется после 3 неудачных попыток входа):
Если на вашем сервере работают другие службы, рассмотрите возможность настройки fail2ban для их защиты.
#security
Я арендую сервер для своих рабочих нужд у компании reg.ru, я им доверяю. Я слежу за безопасностью ПО на сервере, анализирую логи, принимаю определенные меры безопасности. Недавно я посмотрел вывод команды:
$ journalctl -S today
и увидел там много веселого! (смотреть скриншот в следующем посте), эти строки показывают сообщения об ошибках, связанных с попытками подключения по SSH к моему серверу (они повторяются много раз). Я думаю будет полезно разобрать данную ситуацию, ибо в последнее время активно атакуются Российские IT компании со стороны США, Украины. Не буду томить, здесь простейший перебор на дурачка, перебираются часто встречающиеся пользователи, пароли, чтобы получить доступ к системе, попытка взломать сервер, как я это понял ? Журнал
/var/log/auth.log очень резко стал расти в объеме это раз, во-вторых, в журнале видно, что PAM кричит о неудачных попытках входа по SSH от имени различных пользователей (которых нет у меня на сервере) - это обычный перебор.Объяснение ошибок:
kex_protocol_error:
Указывает на ошибки в процессе обмена ключами (key exchange) на этапе предварительной аутентификации. Это может быть связано с несовместимостью протоколов или ошибками в передаче данных.
kex_exchange_identification:
Клиент отправил неверный идентификатор протокола. В данном случае клиент попытался подключиться к SSH-серверу, используя запрос HTTP, что является некорректным. Сообщение kex_exchange_identification: banner line contains invalid characters указывает на то, что строка баннера, отправленная клиентом, содержит недопустимые символы.
MaxStartups throttling:
Сервер достиг предела по количеству одновременных незавершенных попыток подключения (MaxStartups). Это механизм защиты от DoS-атак, который ограничивает количество параллельных подключений.
Возможные причины:
- Попытки несанкционированного доступа или автоматизированные сканирования (боты, пытающиеся найти уязвимости).
- Несовместимость протоколов между клиентом и сервером.
- Ошибки конфигурации клиента или сервера SSH.
Рекомендации:
1. Проверка конфигурации:
- Убедитесь, что конфигурация SSH-сервера корректна и соответствует требованиям безопасности.
2. Журналирование и мониторинг:
- Продолжайте мониторинг логов для выявления подозрительной активности.
3. Ограничение доступа:
- Ограничьте доступ к SSH по IP-адресам, если возможно.
- Используйте firewall для блокировки подозрительных IP-адресов.
4. Обновление программного обеспечения:
- Убедитесь, что ваш SSH-сервер и клиент обновлены до последних версий.
5. Использование fail2ban:
- Рассмотрите возможность использования fail2ban или аналогичных инструментов для автоматической блокировки IP адресов, совершающих подозрительные попытки подключения.
Действия:
При конфигурации
/etc/ssh/sshd_config я всегда касаюсь одних и тех же строк, ничего нового не придумываю, правило одно - это никаких паролей, вход только по ключам, пароли входа запретить (ибо их можно перебрать), как для пользователей, так и для root, вот основные моменты:...
PermitRootLogin prohibit-password
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ClientAliveInterval 120
...
Установка fail2ban сервиса:
$ apt-get install -y fail2ban
Добавить конфигурацию для sshd в
/etc/fail2ban/jail.local файл:[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 86400
Перезапустить:
$ systemctl restart fail2ban
Можно понаблюдать процесс блокировки левых IP адресов, которые обращаются к серверу по SSH (блокировка осуществляется после 3 неудачных попыток входа):
$ fail2ban-client status sshd
$ tail -f /var/log/fail2ban.log
Если на вашем сервере работают другие службы, рассмотрите возможность настройки fail2ban для их защиты.
#security
Мне все понятно, скрипт-киддикам дали поиграться: https://www.vedomosti.ru/technology/news/2024/03/20/1026915-proukrainskie-hakeri
Заключительный пост к прошлым двум постам:
https://xn--r1a.website/krxnotes/426
https://xn--r1a.website/krxnotes/428
#security
Заключительный пост к прошлым двум постам:
https://xn--r1a.website/krxnotes/426
https://xn--r1a.website/krxnotes/428
#security
Разница между /etc/passwd и /etc/shadow файлами
Этот вопрос часто задают на позицию системного администратора Linux =)
В отличие от
На моей Debian системе:
Когда создаются новые группы и пользователи, файлы
Если в
Если убрать
Раньше хеш-пароля хранился в
#shell #security #theory
Этот вопрос часто задают на позицию системного администратора Linux =)
/etc/passwd хранит информацию о пользователях./etc/shadow хранит информацию, необходимую для аутентификации пользователей при входе в систему.В отличие от
/etc/passwd, файл /etc/shadow доступен только для чтения суперпользователю (root), чтобы обеспечить безопасность хранения паролей.На моей Debian системе:
/etc/passwd -> 0644/-rw-r--r--
/etc/shadow -> 0640/-rw-r-----
Когда создаются новые группы и пользователи, файлы
/etc/passwd, /etc/group, /etc/shadow изменяются. Обычные пользователи начинаются с 1000, а с UID 1-499 или 1-999 это псевдопользователи и они выполняют системные службы (от их лица), у них нет оболочки (nologin). А у обычных пользователей есть (обычно это bash).Если в
/etc/passwd вместо x поставить hash сумму из /etc/shadow пароль подойдет, и все будет работать без ошибок, например:user1:$y$j9T$ICRkTA/TqMwVPxvGJUJ9Y1$A4spI3g11fRL0mqUB34tmzILUCCVSMoagET3cFjcQhD:1002:1002:,,,:/home/user1:/bin/bash
Если убрать
x в /etc/passwd у конкретного пользователя, тогда пользователь будет без пароля (не будет установлен пароль). Это позволяет пользователю user1 входить в систему без ввода пароля, например:user1::/home/user:/bin/bash
Раньше хеш-пароля хранился в
/etc/passwd, но его решили убрать в отдельный файл /etc/shadow, потому что /etc/passwd доступен на чтение всем, а /etc/shadow может читать только root (из соображений безопасности).#shell #security #theory
Immutable files (extended attributes - lsattr, chattr)
Например, необходимо ограничить доступ к файлу (запрет удаления, переименования). Можно добавить биты с помощью chmod и chown, но это не идеальное решение, root все же будет иметь полный доступ к файлу. С помощью chattr можно устанавливать и отключать атрибуты файлов на уровне ФС, независимо от стандартных чтение, запись, выполнение. Такие трюки поддерживают ФС семейства ext (ext2, ext3, ext4), NFS не поддерживает immutable files. Символы '+', '-', '=' - работают аналогично chmod команде.
--------------e------- <file>
Флаг 'e' в выводе команды lsattr показывает, что файл имеет установленный атрибут "extended attributes" (дополнительные атрибуты). Это означает, что можно использовать команду chattr для добавления или изменения дополнительных атрибутов для этого файла.
<file>: Operation not permitted
Можно воспользоваться:
или
Трюк с привилегией CAP_LINUX_IMMUTABLE:
rm: cannot remove '<file>': Operation not permitted
rm: cannot remove '<file>': Operation not permitted
mv: cannot move '<file>' to 'new-name': Operation not permitted
mv: cannot move '<file>' to 'new-name': Operation not permitted
Получился неизменяемый файл.
#theory #security #utils
Например, необходимо ограничить доступ к файлу (запрет удаления, переименования). Можно добавить биты с помощью chmod и chown, но это не идеальное решение, root все же будет иметь полный доступ к файлу. С помощью chattr можно устанавливать и отключать атрибуты файлов на уровне ФС, независимо от стандартных чтение, запись, выполнение. Такие трюки поддерживают ФС семейства ext (ext2, ext3, ext4), NFS не поддерживает immutable files. Символы '+', '-', '=' - работают аналогично chmod команде.
$ touch <file>
$ lsattr <file>
--------------e------- <file>
Флаг 'e' в выводе команды lsattr показывает, что файл имеет установленный атрибут "extended attributes" (дополнительные атрибуты). Это означает, что можно использовать команду chattr для добавления или изменения дополнительных атрибутов для этого файла.
$ chattr =i <file>
<file>: Operation not permitted
Можно воспользоваться:
$ sudo chattr =i <file>
или
Трюк с привилегией CAP_LINUX_IMMUTABLE:
$ sudo setcap cap_linux_immutable+ep /usr/bin/chattr
$ chattr =i <file>
$ rm <file>
rm: cannot remove '<file>': Operation not permitted
$ sudo rm <file>
rm: cannot remove '<file>': Operation not permitted
$ mv <file> new-name
mv: cannot move '<file>' to 'new-name': Operation not permitted
$ sudo mv <file> new-name
mv: cannot move '<file>' to 'new-name': Operation not permitted
$ sudo setcap -r /usr/bin/chattr
Получился неизменяемый файл.
#theory #security #utils
Что такое Secure Boot?
Технология Secure Boot нацелена на предотвращение исполнения недоверенного кода при загрузке операционной системы. Устройства с Secure Boot содержат в энергонезависимой памяти базу данных открытых ключей, которыми проверяются подписи загружаемых UEFI-приложений вроде загрузчиков ОС и драйверов. Приложения, подписанные доверенным ключом и с правильной контрольной суммой, допускаются к загрузке, остальные блокируются. Если подписанное приложение предоставляет возможность недобросовестного использования напрямую или путём загрузки других приложений, оно становится угрозой безопасности всех пользователей, доверяющих этому приложению.
Убедитесь, что ваша система поддерживает Secure Boot. Это можно сделать в настройках UEFI/BIOS.
Пакеты, которые обеспечивают поддержку Secure Boot в Debian:
Более подробно: https://habr.com/ru/articles/308032/
#security #theory
Технология Secure Boot нацелена на предотвращение исполнения недоверенного кода при загрузке операционной системы. Устройства с Secure Boot содержат в энергонезависимой памяти базу данных открытых ключей, которыми проверяются подписи загружаемых UEFI-приложений вроде загрузчиков ОС и драйверов. Приложения, подписанные доверенным ключом и с правильной контрольной суммой, допускаются к загрузке, остальные блокируются. Если подписанное приложение предоставляет возможность недобросовестного использования напрямую или путём загрузки других приложений, оно становится угрозой безопасности всех пользователей, доверяющих этому приложению.
Убедитесь, что ваша система поддерживает Secure Boot. Это можно сделать в настройках UEFI/BIOS.
Пакеты, которые обеспечивают поддержку Secure Boot в Debian:
shim-signed, grub-efi-amd64-signed, и mokutil.Более подробно: https://habr.com/ru/articles/308032/
#security #theory
Что такое Аудит и для чего он нужен?
Нужен для отслеживания критичных с точки зрения безопасности системных событий:
* запуск и завершение работы системы;
* чтение, запись и изменение прав доступа к файлам;
* инициация сетевых соединений;
* попытки неудачной авторизации в системе;
* изменение сетевых настроек;
* изменение информации о пользователях и группах;
* запуск и остановка приложений;
* выполнение системных вызовов;
Ни одно из названных событий не может произойти без использования системных вызовов ядра. Чтобы их отслеживать, достаточно просто перехватывать соответствующие системные вызовы. Именно это и делает подсистема аудита. Когда я работал системным программистом, то часто приходилось взаимодействовать с аудитом (для отладки).
Конфигурация:
После
События 1000 пользователя:
Поиск событий по коду выхода:
Искать события open:
Номера всех системных вызовов:
#kernel #security #utils
Нужен для отслеживания критичных с точки зрения безопасности системных событий:
* запуск и завершение работы системы;
* чтение, запись и изменение прав доступа к файлам;
* инициация сетевых соединений;
* попытки неудачной авторизации в системе;
* изменение сетевых настроек;
* изменение информации о пользователях и группах;
* запуск и остановка приложений;
* выполнение системных вызовов;
Ни одно из названных событий не может произойти без использования системных вызовов ядра. Чтобы их отслеживать, достаточно просто перехватывать соответствующие системные вызовы. Именно это и делает подсистема аудита. Когда я работал системным программистом, то часто приходилось взаимодействовать с аудитом (для отладки).
$ apt-get install -y auditd
$ systemctl status auditd
Конфигурация:
/etc/audit/auditd.conf
Выполнить программу и отследить ее события (работает наподобие strace):$ autrace <path-to-program>
После
autrace:$ ausearch -i -p <pid>
События 1000 пользователя:
$ ausearch -ui 1000
Поиск событий по коду выхода:
$ ausearch -i -e -13
Искать события open:
$ ausearch -ui 1000 -sc open
Номера всех системных вызовов:
$ ausyscall --dump
#kernel #security #utils
——— НАВИГАЦИЯ ———
Git: #git
Жвачка: #fun
Ядро: #kernel
Разное: #misc
ПО: #software
Игры: #games
Книги: #books
Люди: #people
Сборка: #build
Утилиты: #utils
Python: #python
Теория: #theory
Debian: #debian
Новости: #news
Оболочка: #shell
Память: #memory
СПО: #opensource
Терминал: #terminal
Мои мысли: #thoughts
Безопасность: #security
Информация канала: #info
Конфигурационные файлы: #dotfiles
Кто я: https://xn--r1a.website/krxnotes/246
Откуда берется информация: https://xn--r1a.website/krxnotes/500
Поддержать канал:
Git: #git
Жвачка: #fun
Ядро: #kernel
Разное: #misc
ПО: #software
Игры: #games
Книги: #books
Люди: #people
Сборка: #build
Утилиты: #utils
Python: #python
Теория: #theory
Debian: #debian
Новости: #news
Оболочка: #shell
Память: #memory
СПО: #opensource
Терминал: #terminal
Мои мысли: #thoughts
Безопасность: #security
Информация канала: #info
Конфигурационные файлы: #dotfiles
Кто я: https://xn--r1a.website/krxnotes/246
Откуда берется информация: https://xn--r1a.website/krxnotes/500
Поддержать канал:
2202 2036 6907 4603
Блокировка/автовыход из терминала/консоли
Автовыход из терминала (bash): Переменная окружения
Автоблокировка: Для автоблокировки можно использовать утилиту
Заблокировать текущую консоль:
Заблокировать все консоли:
Обе эти настройки помогут повысить безопасность, особенно в многопользовательских системах или в условиях, где доступ к терминалу должен быть ограничен в ваше отсутствие.
#shell #utils #security
Автовыход из терминала (bash): Переменная окружения
TMOUT задает таймаут в секундах для автоматического выхода из сессии bash. Сессия завершится через 60 секунд неактивности:export TMOUT=60
Автоблокировка: Для автоблокировки можно использовать утилиту
vlock. Это утилита, которая блокирует текущую виртуальную консоль, требуя ввода пароля для разблокировки. Это удобно для временной блокировки доступа к терминалу, когда вам необходимо отойти, не выходя из сессии.$ apt-get install -y vlock
Заблокировать текущую консоль:
$ vlock
Заблокировать все консоли:
$ vlock -a
Обе эти настройки помогут повысить безопасность, особенно в многопользовательских системах или в условиях, где доступ к терминалу должен быть ограничен в ваше отсутствие.
#shell #utils #security