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


21

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

Ответы:


19

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

Что касается выключения аутентификации по паролю, как мне войти на сервер, если я потеряю его открытый ключ? (У меня нет физического доступа к серверу, это VPS)
Дзямид,

Публичный ключ можно публиковать везде, где вы захотите.
Pedram

Подробнее читайте здесь: en.wikipedia.org/wiki/Public-key_cryptography
Педрам,

Есть ли способ настроить сервер для показа его открытого ключа при запросе?
Дзямид

1
Используя ssh, я так не думаю. Если у вас установлен веб-сервер, такой как apache, вы можете поделиться ключом через веб.
Pedram

8

Я получаю 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
Мой /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Указывает ли такая запись на атаку?
Дзямид

1
Ну, это означает, что кто-то с IP 218.15.136.38 пытался войти в систему как root. Может быть, вы, но, вероятно, не потому, что с помощью tools.whois.net/whoisbyip я вижу, что этот IP-адрес зарегистрирован в Китае, что довольно далеко от Минска ;-) Так что да, это похоже на угадывание вашего пароля , Мораль: отключите root-вход через ssh (PermitRootLogin нет в / etc / ssh / sshd_config), потому что нет веских причин оставлять это включенным. А затем рассмотрите denyhosts или fail2ban. Кроме того, убедитесь, что у вас есть брандмауэр, позволяющий получать только необходимый доступ через порт 22 и все, что вам нужно (но не больше)
DrSAR

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

3
-1 за первый совет, усложняет ситуацию, фактически не повышая безопасность
steabert

Если вы используете ssh-ключи и отключаете аутентификацию по паролю через ssh, мне действительно нужны 1,2,3?
Дзиамид,

4
@steabert это помогает против сценаристов, которые просто пытаются перебрать свой путь через порт 22. Это мой опыт: кто-то продолжает перебирать сервер с выходом в Интернет, когда я настраивал его, заставляя систему отправлять мне предупреждения после предупреждений. Я перенес порт, и предупреждения стихли.
pepoluan

Ключи @Dziamid ssh предотвращают взлом вашей системы. но это не мешает им пытаться подключиться к порту 22.
pepoluan

3
@ Дзиамид Нет, не правильно. Другие методы аутентификации (RSAAuthentication, PubkeyAuthentication, #KerberosAuthentication и т. Д.) Все еще устанавливают связь через порт 22.
DrSAR

3

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

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

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

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


Как мне подключиться к серверу, если я потеряю его открытый ключ?
Дзямид

1
Только через консоль или прямой доступ. Я совершенно уверен, что вы не потеряете свой ключ, если сможете администрировать сервер.
ddeimeke

0

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


0

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

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

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

Недостатки:

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

0

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

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

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

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

PermitRootLogin without-password

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

PermitRootLogin prohibit-password

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

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

  1. отредактируйте /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» есть множество примеров. Я предпочел бы иметь хороший графический интерфейс, чтобы пройти через это, мне не нужно делать это все время. Может быть, другие могут сказать нам, если есть один сейчас.

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

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

  1. Если вы должны оставить сервер открытым для 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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.