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

Question 1

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

Question 2

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

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

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

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

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

Question 3

Question 4

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

Question 5

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

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

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

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

Question 6

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

Question 7

Question 8

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

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

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

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

Question 9

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

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

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

Недостатки:

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

Question 10

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

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

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

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

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

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

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

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

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

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

Pedram · Accepted Answer · 28 March 2011 в 03:21

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

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

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

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

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

pepoluan · Answer 2 · 28 March 2011 в 03:21

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

DrSAR · Answer 3 · 28 March 2011 в 03:21

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

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

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

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

bitwelder · Answer 4 · 28 March 2011 в 03:21

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

ddeimeke · Answer 5 · 28 March 2011 в 03:21

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

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

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

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

joeytwiddle · Answer 6 · 28 March 2011 в 03:21

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

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

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

Недостатки:

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

pauljohn32 · Answer 7 · 28 March 2011 в 03:21

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

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

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

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

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

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

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

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

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

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

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

7 ответов

Другие вопросы по тегам:

Похожие вопросы: