Проверка безопасности :классификация журнала ssh -попыток

Краткий ответ от 1 до 3

Я считаю, что last -iи lastb -iнеобходимы для менее загроможденного анализа.

• Обозначение preauthуказывает, что попытка входа не удалась.

• Обозначение Спасибо за игру — это немного админского юмора.

• Все неудачные попытки регистрируются.

• «Врата», как вы выразились, открыты для Интернета... так что каждый хост в мире «достиг ворот», если только вы не настроите стук портов.

В общем, если открытый ключ является единственным методом аутентификации для ssh, ваша конфигурация практически неуязвима для скриптовых ботов. Однако можно ожидать несколько тысяч попыток в месяц, а то и больше.

Если вас беспокоят такие попытки, вы можете установить и настроить fail2ban .

Более длинный ответ и Добро пожаловать в Матрицу

Боты и низко висящие фрукты

Большинство менее опытных администраторов, которые начинают просматривать лог-файлы, вероятно, впадают в панику. Я знаю, когда у меня был свой, я начал задавать многие из тех же вопросов, что и вы. Это обычный ответ на, казалось бы, бесконечный поток попыток взлома вашего крошечного уголка Интернета.

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

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

Вот почему вы увидите целую серию из сотни или около того имен, таких как:Фред, Салли, Джордж... и т. д... Вы даже можете увидеть свое имя,или что-то в этом роде. То же самое верно и для других служб, которые вы можете использовать, таких как электронная почта. Если вы посмотрите в файл /var/log/mail.log, вы увидите такие же попытки взлома комбинации имени пользователя и пароля.

Все эти атаки осуществляются ботами. Если вы настроили разумные меры безопасности на своем сервере, вы вряд ли подвергнетесь риску sshпопытки взлома.

SSH-ключи

Пары ключей SSH имеют открытый и закрытый компоненты. Частный компонент никогда не должен распространяться. Публичный компонент должен быть помещен в файл ~/.ssh/authorized_keysцелевого сервера.

Во время аутентификации с открытым ключом по соединению не передаются ни закрытый ключ, ни парольная фраза для этого ключа. После аутентификации сеанс sshшифруется с использованием согласованного симметричного ключа сеанса. Злоумышленнику, который украл ваш закрытый ключ, все равно нужно будет выяснить вашу парольную фразу. И этот злоумышленник не должен иметь возможности перехватить эту парольную фразу, не скомпрометировав машину, на которой хранится ваш закрытый ключ.

Ключи SSH являются криптографическими объектами и, следовательно, зависят от сроков действия алгоритма и/или уязвимостей, обнаруживаемых на протяжении всего жизненного цикла любого заданного алгоритма. Поэтому важно следить за тем, чтобы программное обеспечение вашего сервера часто обновлялось, а ваши пользовательские ключи проверялись на наличие вновь выявленных проблем.

Стандартным алгоритмом на момент написания этой статьи по-прежнему остается RSA 2048. Ключевой скрипт AWS генерирует ключи RSA 2048 в соответствии с документацией AWS . Однако я изменил все свои ключи на Curve 25519, поскольку эти ключи намного короче, а алгоритм предполагается разрабатывать независимо от каких-либо государственных органов или, возможно, скомпрометированных лиц.

Аудит сервера и ведение записей

Поскольку вы указали, что вначале включили аутентификацию с открытым ключом ssh, а также отключили аутентификацию по паролю,нет оснований подозревать, что аутентификация с открытым ключом была отключена удаленным злоумышленником. Так оно и есть, если только ваша учетная запись AWS не была скомпрометирована. Однако вы, вероятно, получите несколько уведомлений о неожиданных IP-адресах, используемых для доступа к вашей учетной записи AWS.

Если вам нужна более длинная запись журнала, вы можете увеличить время хранения файлов журнала с помощью logrotateи/или установить auditd .

Уровни здравомыслия для вашей конфигурации

Разумные меры безопасности ssh для небольших/персональных серверов

• Аутентификация с открытым ключом и только с открытым ключом
• Отключить доступ по ssh для пользователя root
• Включить sudoтолько для пользователей, которым требуются права root
• Используйте ключи RSA длиной не менее 2048 бит или ключи Curve 25519
• Никогда не размещайте материалы закрытого ключа на сервере
• Отключить переадресацию X11, если в этом нет крайней необходимости

Для большинства новых установок единственные параметры, которые следует изменить, — это включение аутентификации с открытым ключом и отключение X11.

/etc/ssh/shhd_config

...
PermitRootLogin no
...
PubkeyAuthentication yes
PasswordAuthentication no
X11Forwarding no
...

Безумная безопасность ssh

В дополнение к вышеперечисленному включите блокировку портов, ограничьте ключи хоста одним алгоритмом, таким как Curve 25519, поместите отпечаток ключа хоста вашего сервера в запись DNS вашего домена и защитите эту запись с помощью DNSSEC.

• Чтобы ограничить ключи хоста сервера, просто раскомментируйте алгоритм, который вы будете использовать, и перезапустите sshdсервер. Обратите внимание, что ключи хоста не будут совпадать, как только это будет сделано, и вы попытаетесь подключиться снова. Следуйте инструкциям при попытке подключения, чтобы заменить локально сохраненный отпечаток ключа хоста.

/etc/ssh/sshd_config

...
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
...

• Для создания sshfpзаписи DNS для выбранного ключа хоста:

ssh-keygen -r domain.tld -f /etc/ssh/ssh_host_ed25519_key

Полученную запись можно поместить в файл зоны DNS вашего домена, и sshподключения будут проверять этот отпечаток. Это защищает от атак Man -In -The -Middle для ssh при первом подключении или при изменении ключей хоста сервера.

• Установить стук

И настроить согласно документации:

knockd is a port-knock server.  It listens to all traffic on an ethernet (or PPP) interface, looking for special "knock" sequences of port-
hits.  A client makes these port-hits by sending a TCP (or UDP) packet to a port on the server.  This port need not be open -- since knockd
listens  at the link-layer level, it sees all traffic even if it's destined for a closed port.  When the server detects a specific sequence
of port-hits, it runs a command defined in its configuration file.  This can be used to open up holes in a firewall for quick access.

....

[options]
     logfile = /var/log/knockd.log

[openSSH]
     sequence    = 7000,8000,9000
     seq_timeout = 10
     tcpflags    = syn
     command     = /usr/sbin/iptables -A INPUT -s %IP% --dport 22 -j ACCEPT

[closeSSH]
     sequence    = 9000,8000,7000
     seq_timeout = 10
     tcpflags    = syn
     command     = /usr/sbin/iptables -D INPUT -s %IP% --dport 22 -j ACCEPT

• Конфигурация DNSSEC здесь подробно не рассматривается. Однако важно помнить, что спуфинг DNS — это реальная проблема, которую решает DNSSEC.