Защита SSH-сервера от взлома

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

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

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

Итак, у меня есть несколько вопросов:

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

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

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

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

Fail2ban и Port Knocking должны удовлетворить большинство ваших потребностей.

Также рекомендуется изменить порт SSH и разрешить только аутентификацию на основе ключей.

Можно утверждать, что при добавлении дополнительных мер безопасности вы можете достигнуть точки убывающей отдачи, но опять же, вам решать, когда вы «достаточно безопасны».

Это также хорошая идея, чтобы запретить вход в систему root.

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

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

Я прекратил атаки грубой силы с помощью:

• fail2ban
• sshd.config:
  • ПарольАутентификация Нет
  • PermitRootLogin Нет
• Ограничение скорости SSH Connect с помощью iptables ( http://www.debian-administration.org/articles/187 )

Есть много хороших предложений, предлагаемых здесь. Я с уважением предлагаю, чтобы три вещи сделали это относительно безопасным:

1. Запустите sshd на случайном высоком порту. Боты обычно идут только после порта 22 и вариантов порта 22, например, 2222.
2. Отключите аутентификацию на основе пароля в конфигурации sshd:

UsePAM нет

3. Только аутентифицируйтесь с этим сайтом через предварительно переданные пары ключей SSH. Человек на ssh-keygen, чтобы начать с аутентификации на основе PKI.

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

Я всегда был большим поклонником CSF / LFD, который может блокировать IP-адреса людей, пытающихся использовать bruteforce, portcan и некоторые другие варианты. По сути, это огромная perl-оболочка для таблиц IP, но файл конфигурации не сложен для чтения и документация не плохая.

Вы также можете посмотреть в sshguard. Я не использовал это, но я слышал хорошие вещи.

Источники:
http://isc.sans.edu/diary.html?storyid=9370

http://www.sshguard.net/

http://www.sshguard.net/docs/faqs/

«Sshguard контролирует серверы по их активности в журнале. Когда в журналах сообщается, что кто-то совершает Плохую Вещи, sshguard реагирует, блокируя его / ее / ее на некоторое время. Sshguard обладает раздражительной индивидуальностью: когда непослушный тюк настаивает на том, что он мешает вашему хосту, он реагирует крепче и крепче. "

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

• tcp_wrappers (т. е. hosts.allow hosts.deny) для SSH ... Я не думаю, что есть SSH, в котором нет скомпилированной поддержки
• iptables это в сочетании с tcp_wrappers исключило около 99% моих случайных сканирований портов / попыток брутфорса ... единственная проблема - вам нужно знать, откуда вы будете подключаться, чтобы разрешить эти диапазоны IP / IP ... Я просто сделал поиск популярных провайдеров в моем регионе, чтобы увидеть их диапазоны IP-адресов и разрешить эти ... большинство сканов, кажется, приходят из далеких стран :)
• PermitRootLogin без пароля (т. Е. Только пары ключей RSA / DSA, которые зашифрованы парольной фразой) прекрасно работает для автоматизированных задач. Когда я вхожу для взаимодействия, я, очевидно, использую свою учетную запись (обычную), которая настроена с доступом sudo
• sudoers
• постоянные обновления .. Я часто обновляю эту коробку со всеми критическими обновлениями безопасности
• изменения пароля / парольной фразы
• запускайте chkrootkit время от времени, чтобы увидеть, есть ли у меня какие-либо проблемы .. (есть несколько, которые выполняют эту функцию)

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

Есть лучший способ сделать это, использование fail2ban означает, что вам нужно добавить приложение, и оно работает на уровне приложений.

Если вы используете iptables, он более эффективен, поскольку работает на сетевом уровне, и вам не нужно устанавливать дополнительное приложение.

Используйте последний модуль iptables http://www.snowman.net/projects/ipt_recent/

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
iptables -A SSHSCAN -j ACCEPT

Опция (которая будет использоваться в дополнение к другим мерам безопасности) - это прослушивание sshd на порте, отличном от 22. Я сам не пробовал, но слышал, что это уменьшает количество атак с использованием грубой силы ботов.

Я должен подчеркнуть, что это не настоящая безопасность, а просто уменьшает количество автоматических атак методом перебора. Слишком много работы, чтобы проверить каждый порт.

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

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

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

Что было эффективным для меня:

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

2. Только одному или двум пользователям разрешено входить через ssh, и у них есть квази-непонятные имена, которых нет в общих списках имен пользователей инструментов грубой силы (т. Е. Не "admin", "apache", "web" или " Джонни")

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

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

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

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

Если вы работаете с Apache, вы можете заблокировать и то, что нарушает правила apache. Я не блокирую их только из-за проблемы NAT, я хочу подумать о блокировании всего университета или чего-то еще. :) Кроме того, вы можете написать собственные правила для блокировки определенных условий в лог-файлах, что может быть очень полезным.