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

Мои пароли защищены, но я слышал, как люди жалуются на то, что сервер резко падает, когда происходит атака грубой силы. Как я могу защитить свой сервер Ubuntu 10.10 от таких атак? Для этого есть профиль apparmor? Или как-то иначе?

Есть разные решения. Лучше всего использовать аутентификацию 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), используйте этот очень простой и малоэффективный инструмент.

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

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

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

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

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

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

Альтернативой fail2ban является CSF: ConfigServer Security & Firewall .

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

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

Недостатки:

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

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