Security

Защита SSH-сервера от брутфорса

У меня есть небольшой SVN-сервер, старый dell optiplex под управлением debian. У меня не такие высокие требования к серверу, потому что это просто маленький SVN-сервер... но я хочу, чтобы он был безопасным.

Я только что обновил свой сервер на более новый и лучший optiplex и начал немного изучать старый сервер. Я отключил его после возникновения проблем. Когда я проверяю журналы, в них полно попыток перебора, и каким-то образом кому-то удалось войти на мою машину. Этот человек создал какой-то дополнительный том под названием «knarkgosse» с двумя дисками «root» и «swap1» или что-то в этом роде. Я не знаю, зачем и что они делают, но, конечно, хочу предотвратить повторение этого. Мне кажется это немного странным, потому что я меняю свой пароль каждые несколько месяцев или около того, а пароли всегда представляют собой случайные буквы и цифры, собранные вместе... их нелегко перебрать.

Я знаю, что могу предотвратить вход root, использовать sudoers и изменить порт SSH, но что еще я могу сделать?

Поэтому у меня есть несколько вопросов:

  1. Как я могу запретить вход в систему в течение 5 минут после X количества неправильных попыток или замедлить попытки после каждой неправильной попытки?

  2. Существует ли какой-то центральный черный список, к которому может подключиться сервер? Черный список, который отслеживает IP-адреса, которые являются «небезопасными» и никогда не должны получать доступ.

  3. Что еще я могу сделать для обеспечения безопасности моего сервера?

Как я уже говорил, я использую Debian 5 с Apache (проблема с пользователем www-data?), svn, mysql, php, phpmyadmin, hudson. Он находится в домашней сети с пробросом портов на 80, 443, 8080, 8180, 23 и 22.

Ответ 1

Невозможно заменить надежные пароли и аутентификацию по ключу. Учитывая это, Fail2Ban – отличный инструмент для запрета IP-адресов пользователей, которые пытаются аутентифицироваться слишком часто. Он также доступен в виде готового пакета для большинства дистрибутивов. Будьте внимательны, вы можете случайно забанить себя, поэтому убедитесь, что у вас есть IP из белого списка для восстановления или легкий доступ к консоли... Fail2Ban имеет несколько хороших примеров того, как настроить все, о чем вы спрашивали, однако он не имеет универсального хранилища плохих адресов. Я не думаю, что такое хранилище существует где-либо из-за легкости получения другого IP (dhcp renew/bot-net attacks/etc...). Я бы также запретил вход по ssh с использованием обычных имен пользователей типа «администратор» (root/admin/administrator/sysop/etc...), поскольку они наиболее часто подвергаются взлому.

Ответ 2

У меня есть SSH-сервер, подключенный к интернету через порт по умолчанию, и я никогда не испытывал проблем...

  1. tcp_wrappers (т. е. hosts.allow hosts.deny) для SSH. Я не думаю, что существует SSH, который не имеет встроенной поддержки.

  2. iptables в сочетании с tcp_wrappers устранил около 99% моих случайных попыток сканирования портов/bruteforce. Единственная проблема в том, что вам нужно знать, откуда вы будете подключаться, чтобы разрешить эти IP/IP диапазоны. Я просто проверил популярных провайдеров в своем районе, чтобы увидеть их IP диапазоны и разрешить их. Большинство сканирований, кажется, приходят из далеких стран :)

  3. PermitRootLogin без пароля (т. е. только пары ключей RSA/DSA, зашифрованные парольной фразой) прекрасно работает для автоматизированных задач. Когда я вхожу во взаимодействие, я, очевидно, использую свою учетную запись (обычную), которая настроена с доступом sudo.

  4. sudoers.

  5. Постоянные обновления. Я часто обновляю этот блок всеми обновлениями безопасности/критическими обновлениями.

  6. Смена пароля/парольной фразы.

  7. Время от времени запускаю chkrootkit, чтобы проверить, есть ли у меня какие-либо проблемы (есть несколько программ, которые выполняют эту функцию).

Надеюсь, это поможет!

Ответ 3

Вот что оказалось эффективным для меня:

  1. Как уже говорили другие, никакого входа под root, PasswordAuthentication установлен на no (только вход с ключами) в sshd_config.

  2. Только одному или двум пользователям разрешено входить через ssh, и у них квази-очевидные имена, которых нет в обычных списках имен пользователей для перебора (т. е. не «admin» или «apache», или «web», или «johnny»).

  3. Ограничительные правила брандмауэра (в основном заблокировано все, кроме моего служебного порта и ssh). Я даже ограничиваю ping, чтобы предотвратить более грубое сканирование (к большому огорчению моего партнера).

  4. На своем веб-хосте я ограничиваю доступ к нескольким определенным IP-адресам, но, похоже, для вас это не вариант. Конечно, я не могу сделать это сам на всех наших хостах. Возможно, вы также захотите изучить «port-knocking».

  5. И мой любимый вариант: модуль активного реагирования OSSEC блокирует ряд условий грубой силы и предупреждает о других ошибках. Он обнаруживает «x» недействительных входов в систему за «y» времени, а затем блокирует (через команду iptables firewall-drop) на определенный период времени. Я блокирую примерно на 12 часов, что, на мой взгляд, оптимально.

Одна вещь, которую я делаю здесь, чтобы убедиться, что я не блокирую слишком много неправильных вещей, это то, что в /etc/ossec.conf я устанавливаю активный ответ на высокий уровень (который не существует в конфигурации по умолчанию), а затем прохожу через sshd_rules.xml и устанавливаю правила, которые я хочу блокировать, на этот уровень и изменяю пороговые значения для блокирования и предупреждения по мере необходимости. Если вы используете Apache, вы также можете блокировать то, что нарушает apache-правила. Я не блокирую их только из-за проблемы NAT. Кроме того, вы можете написать пользовательские правила для блокировки при определенных условиях в лог-файлах, что может быть действительно полезно.

Ответ 4

DenyHosts, http://denyhosts.sourceforge.net/ – хороший проект, с которым мне повезло. Если вы настроите denyhosts на синхронизацию, он будет загружать новые IP-адреса для добавления в бан-лист, которые пришлось перебирать другим системам, использующим denyhosts. Он также исключает IP-адреса, которые не пытались перебрать в течение некоторого времени.

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

Ответ 5

То, о чем здесь не упоминается, а следовало бы, – ограничение доступа через брандмауэр. Это не подходит для всех ситуаций, но, если вы подключаетесь к хосту из постоянного места со статическим IP, вы можете просто полностью заблокировать SSH, за исключением этого IP. Это гарантирует, что злоумышленники не смогут проникнуть внутрь. Однако, как я уже говорил, это не всегда подходит для любой ситуации, особенно если ваш IP динамический и часто меняется.

Схожие статьи

Security

Может ли виртуальная машина (ВМ) «взломать» другую ВМ, работающую на той же физической машине?

Security

Насколько сложно настроить почтовый сервер?

Security

Насколько полезен mounting/tmp noexec?

Как защитить сервер от взлома без сторонней помощи и затрат?
Security

Как защитить сервер от взлома без сторонней помощи и затрат?