У меня есть небольшой SVN-сервер, старый dell optiplex под управлением debian. У меня не такие высокие требования к серверу, потому что это просто маленький SVN-сервер... но я хочу, чтобы он был безопасным.
Я только что обновил свой сервер на более новый и лучший optiplex и начал немного изучать старый сервер. Я отключил его после возникновения проблем. Когда я проверяю журналы, в них полно попыток перебора, и каким-то образом кому-то удалось войти на мою машину. Этот человек создал какой-то дополнительный том под названием «knarkgosse» с двумя дисками «root» и «swap1» или что-то в этом роде. Я не знаю, зачем и что они делают, но, конечно, хочу предотвратить повторение этого. Мне кажется это немного странным, потому что я меняю свой пароль каждые несколько месяцев или около того, а пароли всегда представляют собой случайные буквы и цифры, собранные вместе... их нелегко перебрать.
Я знаю, что могу предотвратить вход root, использовать sudoers и изменить порт SSH, но что еще я могу сделать?
Поэтому у меня есть несколько вопросов:
Как я могу запретить вход в систему в течение 5 минут после X количества неправильных попыток или замедлить попытки после каждой неправильной попытки?
Существует ли какой-то центральный черный список, к которому может подключиться сервер? Черный список, который отслеживает IP-адреса, которые являются «небезопасными» и никогда не должны получать доступ.
Что еще я могу сделать для обеспечения безопасности моего сервера?
Как я уже говорил, я использую 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-сервер, подключенный к интернету через порт по умолчанию, и я никогда не испытывал проблем...
tcp_wrappers (т. е. hosts.allow hosts.deny) для SSH. Я не думаю, что существует SSH, который не имеет встроенной поддержки.
iptables в сочетании с tcp_wrappers устранил около 99% моих случайных попыток сканирования портов/bruteforce. Единственная проблема в том, что вам нужно знать, откуда вы будете подключаться, чтобы разрешить эти IP/IP диапазоны. Я просто проверил популярных провайдеров в своем районе, чтобы увидеть их IP диапазоны и разрешить их. Большинство сканирований, кажется, приходят из далеких стран :)
PermitRootLogin без пароля (т. е. только пары ключей RSA/DSA, зашифрованные парольной фразой) прекрасно работает для автоматизированных задач. Когда я вхожу во взаимодействие, я, очевидно, использую свою учетную запись (обычную), которая настроена с доступом sudo.
sudoers.
Постоянные обновления. Я часто обновляю этот блок всеми обновлениями безопасности/критическими обновлениями.
Смена пароля/парольной фразы.
Время от времени запускаю chkrootkit, чтобы проверить, есть ли у меня какие-либо проблемы (есть несколько программ, которые выполняют эту функцию).
Надеюсь, это поможет!
Ответ 3
Вот что оказалось эффективным для меня:
Как уже говорили другие, никакого входа под root, PasswordAuthentication установлен на no (только вход с ключами) в sshd_config.
Только одному или двум пользователям разрешено входить через ssh, и у них квази-очевидные имена, которых нет в обычных списках имен пользователей для перебора (т. е. не «admin» или «apache», или «web», или «johnny»).
Ограничительные правила брандмауэра (в основном заблокировано все, кроме моего служебного порта и ssh). Я даже ограничиваю ping, чтобы предотвратить более грубое сканирование (к большому огорчению моего партнера).
На своем веб-хосте я ограничиваю доступ к нескольким определенным IP-адресам, но, похоже, для вас это не вариант. Конечно, я не могу сделать это сам на всех наших хостах. Возможно, вы также захотите изучить «port-knocking».
И мой любимый вариант: модуль активного реагирования 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