Ответы:
Есть разные решения. Лучше всего использовать аутентификацию RSA, которая использует открытые / закрытые ключи для аутентификации пользователей.
Посмотрите это отличное руководство для разных подходов (включая аутентификацию RSA): http://www.la-samhna.de/library/brutessh.html
Я использую 3-е решение на своем сервере, потому что я не хочу усложнять его для своих нетехнических пользователей: использование iptables
для ограничения количества соединений в минуту, что делает атаки bruteforce неэффективными и неэффективными.
Вот решение, которое я использую:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Как упомянуто здесь : это позволит подключаться к трем портам 22 с любого данного IP-адреса в течение 60-секундного периода и потребовать 60 секунд без последующих попыток подключения, прежде чем он возобновит разрешение на подключение снова. Опция --rttl также учитывает TTL дейтаграммы при сопоставлении пакетов, чтобы попытаться уменьшить количество поддельных адресов источника.
Как указано в упомянутом руководстве, лучше использовать белый список, чтобы отделить доверенных пользователей от этих правил:
iptables -N SSH_WHITELIST
затем добавьте доверенные хосты:
iptables -A SSH_WHITELIST -s $TRUSTED_HOST -m recent --remove --name SSH -j ACCEPT
и после этого составьте правила:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Я получаю ssh-атаки методом перебора на моих серверах со скоростью от 1 до 2 в день. Я установил denyhosts (пакет ubuntu: denyhosts). Это очень простой, но эффективный инструмент для этой цели: по сути, он периодически сканирует ваши журналы для обнаружения атак методом перебора и помещает IP-адреса, с которых эти атаки происходят, в ваш файл /etc/hosts.deny. Вы не услышите от них больше, и ваша нагрузка должна быть значительно уменьшена. Он очень легко настраивается через конфигурационный файл /etc/denyhosts.conf для настройки проблем, таких как, сколько неправильных попыток вызывает атаку и т. Д.
Благодаря прозрачной работе вы можете легко увидеть, что происходит (уведомление по электронной почте: «ага, еще одна подлая атака сорвана!») И отменить ошибки, связанные с тем, что ваши пользователи неоднократно неправильно набирают свои пароли.
Конечно, все, что ранее говорилось о переходе на другие методы аутентификации, сохраняется, но иногда ваши требования не совпадают с требованиями ваших пользователей.
Кроме того, ограничение скорости нового соединения в iptables может быть лучшим выбором, чем отказ в доступе через hosts.deny. Итак, взгляните на fail2ban. Но если вы знаете, что ssh brute-force - ваша главная задача (чтобы выяснить это вручную, посмотрите /var/log/auth.log), используйте этот очень простой и малоэффективный инструмент.
Mar 27 10:28:43 smartfood sshd[17017]: Failed password for root from 218.15.136.38 port 33119 ssh2 Mar 27 10:28:47 smartfood sshd[17019]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.15.136.38 user=root
Указывает ли такая запись на атаку?
knockd
для реализации системы стука портовrecent
и hashlimit
совпадения для ограничения последовательных попыток SSHПрежде всего, вы должны рассмотреть возможность не использовать пароли и использовать вместо них ключи. Там нет необходимости использовать пароль. Если это работает для вас, вы можете настроить OpenSSH-сервер так, чтобы он не реагировал на пароли при входе.
https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html
Использование fail2ban, также может быть вариантом.
Альтернативой fail2ban является CSF: ConfigServer Security & Firewall .
Он поставляется с LFD: демон сбоя при входе в систему, который может обнаруживать несколько неудачных попыток входа в систему для различных служб и блокирует вызывающий сбой IP-адрес (временно или постоянно).
У него есть некоторые другие опции, которые могут помочь против атак наводнения и, возможно, обнаружить вторжения.
Недостатки:
Намереваетесь ли вы разрешить SSH обслуживание всему миру? Или просто для членов команды в определенных местах? Мой ответ немного зависит от серьезности вашего вызова.
В любом случае вы должны убедиться, что сервер SSH не разрешает вход в систему с паролями для пользователя root.
В моих системах у меня есть этот параметр
PermitRootLogin without-password
но я замечаю, в более новой Ubuntu они имеют
PermitRootLogin prohibit-password
Если вы читаете «man sshd_config», я думаю, что это означает, что этот более новый «пароль-запрет» означает то же самое и, безусловно, более очевидно по смыслу. Это НЕ по умолчанию в некоторых системах Linux, но, вероятно, должно быть.
Теперь о вашей проблеме. Ваш системный сервер только некоторые пользователи в определенных местах? Сделай это!
отредактируйте /etc/hosts.deny и вставьте
ВСЕ: ВСЕ
Затем отредактируйте /etc/hosts.allow и перечислите IP-номера или диапазон, которые хотите разрешить использовать SSH. Обозначения там немного сбивают с толку, потому что если вы хотите разрешить всем системам с IP-номерами, такими как 111.222.65.101 - 111.222.65.255, вы вводите такую запись в hosts.allow
ALL: 127.0.0.1
sshd: 111.222.65.
sshdfwd-X11: 111.222.65.
Это грубое, мощное решение. Если ваши пользователи могут быть перечислены по диапазону IP, сделайте это!
Это решение существовало до того, как были созданы таблицы IP, его администрирование (я думаю) намного проще, но оно не так хорошо, как решение для таблиц IP, поскольку процедуры таблиц IP обнаружат врагов быстрее, чем программы, управляемые hosts.allow и hosts .отказываться от. Но это верный огонь, простой способ закрыть множество проблем, не только из SSH.
Обратите внимание на проблему, которую вы создаете для себя. Если вы хотите открыть FTP-сервер, веб-сервер или еще что-то, вам нужно разрешить записи в хостах.
Вы можете достичь той же основной цели, поигравшись с iptables и брандмауэром. В некотором смысле это предпочтительное решение, потому что вы блокируете врагов на внешней границе. В Ubuntu есть «ufw» (несложный брандмауэр), а в «man ufw» есть множество примеров. Я предпочел бы иметь хороший графический интерфейс, чтобы пройти через это, мне не нужно делать это все время. Может быть, другие могут сказать нам, если есть один сейчас.
Другой источник разочарования произойдет, когда некоторые пользователи накапливают разные ключи ssh для разных серверов. Поскольку у меня есть ключи SSH для примерно 12 различных проектов, теперь ssh завершается сбоем, потому что у меня слишком много открытых ключей (требуется либо "ssh -o PubkeyAuthentication = false", либо создание записи в файле .ssh / config. Это PITA)
В наших системах Centos Linux я заметил, что они отбросили пакет denyhosts и предлагают только fail2ban. Мне понравились denyhosts, потому что он создал список проблемных диапазонов user / ip, а затем в hosts.deny этот список был отмечен. Вместо этого мы установили fail2ban, и это нормально. Насколько я понимаю, вы бы предпочли блокировать этих плохих пользователей на внешнем краю сервера, поэтому блокировщики на основе таблиц ip, такие как fail2ban, на самом деле лучше. Denyhosts работает на вторичном уровне, после того как враги преодолели iptables, они затем отклоняются демоном sshd.
В обеих этих программах несколько утомительно вытащить пользователей из тюрьмы, если они забывают свой пароль и несколько раз пытаются войти в систему. Немного трудно вернуть людей, когда они совершают ошибки входа в систему. Вы бы догадались, что будет графический интерфейс типа «укажи и щелкни», в котором можно будет просто указать и позволить людям вернуться, но это не так. Я должен делать это только каждые несколько месяцев и забывать, как время от времени, поэтому я написал инструкции для себя на своей веб-странице http://pj.freefaculty.org/blog/?p=301