Как обезопасить сервер Ubuntu от атак bruteforce ssh?

Альтернативой fail2ban является CSF: ConfigServer Security & amp; Брандмауэр .

Он поставляется с LFD: демон сбоя при входе в систему, который может обнаруживать множественные неудачные попытки входа в систему для различных служб и блокирует вызывающий сбой IP-адрес (временно или постоянно).

У него есть некоторые другие опции, которые могут помочь против атак наводнения и, возможно, обнаружить вторжения.

Недостатки:

• Вы должны использовать CSF в качестве брандмауэра, чтобы LFD мог выполнять свою работу. Поэтому, если у вас есть существующий брандмауэр, вам нужно будет заменить его на CSF и перенести конфигурацию через него.
• Он не упакован для Ubuntu. Вам нужно будет доверять автообновлению с configserver.com или отключить автоматические обновления.
• Я слышал, что он довольно популярен, поэтому умные злоумышленники, вероятно, будут знать, как отключить обнаружение вторжений, прежде чем их обнаружат!

Прежде всего, вы должны рассмотреть возможность не использовать пароли и вместо них использовать ключи. Там нет необходимости использовать пароль. Если это работает для вас, вы можете настроить OpenSSH-сервер так, чтобы он не реагировал на пароли при входе.

https://help.ubuntu.com/10.04/serverguide/C/openssh-server.html

Использование fail2ban также может быть вариантом.

https://help.ubuntu.com/community/Fail2ban

Существуют разные решения. Лучше всего использовать аутентификацию RSA, которая использует открытый / закрытый ключи для аутентификации пользователей.

Проверьте это великое руководство для различных подходов (включая аутентификацию RSA): http://www.la-samhna.de/library/brutessh.html

Я использую 3-е решение на моем сервере, потому что я не хочу усложнять его для моих нетехнических пользователей: использование iptables для ограничения количества соединений в минуту, что делает атаки методом брутфорс неэффективными и неэффективными. [1110 ]

Вот решение, которое я использую:

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

Насколько широко сервер выставлен в сети? Возможно, вы можете поговорить с сетевым администратором и проверить, можно ли отслеживать и ограничивать сетевой доступ к серверу. Даже если вход в учетную запись безопасен, похоже, что сервер может пострадать от простой DoS / DDoS-атаки.

Намереваетесь ли вы разрешить SSH обслуживание всему миру? Или просто для членов команды в определенных местах? Мой ответ немного зависит от серьезности вашего вызова.

В любом случае вы должны убедиться, что SSH-сервер не разрешает ввод паролей для пользователя root.

1. В / etc / ssh / sshd_config убедитесь, что вы никогда не разрешаете вход с правами root, кроме как с помощью ключа SSH.

В моих системах у меня есть этот параметр

PermitRootLogin without-password

, но я замечаю, что в более новой Ubuntu они имеют

PermitRootLogin prohibit-password

Если вы читаете «man sshd_config «Я думаю, что это означает, что этот новый« пароль-запрет »означает то же самое и, безусловно, более очевиден по смыслу. Это НЕ по умолчанию в некоторых системах Linux, но, вероятно, должно быть.

Теперь о вашей проблеме. Ваш системный сервер только некоторые пользователи в определенных местах? Сделайте это!

2. отредактируйте /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.deny. Но это верный огонь, простой способ закрыть множество проблем, не только из SSH.

Обратите внимание на проблему, которую вы создаете для себя. Если вы хотите открыть FTP-сервер, веб-сервер или еще что-то, вам нужно разрешить записи в хостах.

Вы можете достичь той же основной цели, поигравшись с iptables и брандмауэром. В некотором смысле это предпочтительное решение, потому что вы блокируете врагов на внешней границе. В Ubuntu есть «ufw» (несложный брандмауэр), а в «man ufw» есть множество примеров. Я предпочел бы иметь хороший графический интерфейс, чтобы пройти через это, мне не нужно делать это все время. Может быть, другие могут сказать нам, если есть один сейчас.

3. Другие посты здесь предлагают использовать открытый ключ SSH только для ваших пользователей. Это, безусловно, поможет ценой сложности и разочарования для ваших пользователей. В нашей лаборатории 15 компьютеров. Пользователи ходят среди компьютеров. Требование аутентификации по ключу SSH вызовет большие хлопоты, потому что люди переходят с одного компьютера на другой.

Еще один источник разочарования произойдет, когда некоторые пользователи накапливают разные ключи ssh для разных серверов. Поскольку у меня есть ключи SSH для примерно 12 различных проектов, теперь ssh завершается сбоем, потому что у меня слишком много открытых ключей (требуется либо "ssh -o PubkeyAuthentication = false", либо создание записи в файле .ssh / config. Это PITA)

4. Если вы хотите оставить сервер открытым для SSH из большого мира, то вам определенно следует использовать процедуру отклонения, чтобы заблокировать местоположения, которые часто пытаются войти в систему. Для этого есть две хорошие программы, мы использовали denyhosts и fail2ban. Эти программы имеют настройки, которые позволяют вам блокировать нарушителей на любой срок.

В наших системах Centos Linux я заметил, что они отбросили пакет denyhosts и предлагают только fail2ban. Мне понравились denyhosts, потому что он создал список проблемных диапазонов user / ip, а затем в hosts.deny этот список был отмечен. Вместо этого мы установили fail2ban, и это нормально. Насколько я понимаю, вы бы предпочли блокировать этих плохих пользователей на внешнем краю сервера, поэтому блокировщики на основе таблиц ip, такие как fail2ban, на самом деле лучше. Denyhosts работает на вторичном уровне, после того как враги преодолели iptables, они затем отклоняются демоном sshd.

В обеих этих программах несколько утомительно вытащить пользователей из тюрьмы, если они забывают свой пароль и несколько раз пытаются войти в систему. Немного трудно вернуть людей, когда они делают ошибки входа. Вы бы догадались, что будет графический интерфейс типа «укажи и щелкни», в котором можно будет просто указать и позволить людям вернуться, но это не так. Я должен делать это только раз в несколько месяцев и забывать, как это происходит время от времени, поэтому я написал для себя инструкции на своей веб-странице http://pj.freefaculty.org/blog/?p=301

Я получаю ssh-атаки методом перебора на моих серверах со скоростью от 1 до 2 в день. Я установил denyhosts (пакет ubuntu: denyhosts). Это очень простой, но эффективный инструмент для этой цели: по сути, он периодически сканирует ваши журналы для обнаружения атак методом перебора и помещает IP-адреса, откуда происходят эти атаки, в файл /etc/hosts.deny. Вы не услышите от них больше, и ваша нагрузка должна быть значительно уменьшена. Он очень легко настраивается через его конфигурационный файл /etc/denyhosts.conf для настройки таких вопросов, как количество неправильных попыток вызвать атаку и т. Д.

Благодаря прозрачной работе вы можете легко видеть, что происходит (уведомление по электронной почте: ' ага, еще одна подлая атака была сорвана! ') и отмените ошибки, связанные с тем, что ваши пользователи неоднократно неправильно набирают свои пароли.

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

Кроме того, ограничение скорости нового соединения в iptables может быть лучшим выбором, чем отказ в доступе через hosts.deny. Итак, взгляните на fail2ban. Но если вы знаете, что ваша основная задача - ssh brute-force (чтобы определить это вручную, просмотрите /var/log/auth.log), воспользуйтесь этим очень простым и малоэффективным инструментом.

1. Измените порт sshd на что-то нестандартное
2. Используйте knockd для реализации системы стучания портов
3. Используйте iptables 'recent и [ 112] соответствует ограничению последовательных попыток SSH
4. Не используйте пароли, но вместо этого используйте ключи SSH