Какие шаги вы предпринимаете для защиты сервера Debian?

Просто заметка о брандмауэре вашей машины ...

• Используйте белый, а не черный список - т.е. блокируйте все и разрешайте только то, что вам нужно, запрещайте все остальное.
• Не используйте GUI/ncurses или иное программное обеспечение, которое пытается создать для вас брандмауэр. Если вы это сделаете, вы позволите программному обеспечению делать предположения за вас - вам не нужно рисковать и не следует. Настройте его самостоятельно, если вы не уверены, отключите его - вы скоро узнаете, требуется ли это. Если это уже запущенная и работающая система, и вы не можете нарушить трафик (случайно заблокировав его), запустите tcpdump (дамп в файл) и возьмите примеры - изучите их позже, а затем выясните, что действительно, а что нет.
• Лично я не вижу смысла запускать службу на нестандартном порте, в наши дни инструменты не настолько глупы, чтобы предполагать, что, если что-то работает, например, на порту 22, то это должно быть ssh, а не иначе - для пример amap и ​​nmap 's -A вариант. Сказав это, вы можете (и, вероятно, должны, если беспокоитесь) изменить свои службы, чтобы скрыть себя от посторонних глаз, например, следующее позволит злоумышленнику узнать точную версию OpenSSH, которую вы используете, они Затем можно искать эксплойты для этой точной версии. Если вы прячете такие вещи, вам будет труднее для них.

 [root @ ud-olis-1 uhtbin] # telnet localhost 22 
 Попытка 127.0.0.1 ... 
 Подключено к localhost.localdomain (127.0.0.1). 
 Экранирующий символ - "^]". 
 SSH-2.0-OpenSSH_3.9p1 

• Держите все ваши публичные сервисы в актуальном состоянии и обновляйте их самыми последними обновлениями безопасности.
• Не храните никакие ДАННЫЕ на самом сервере шлюза, по крайней мере, вы выиграете время, когда им удастся взломать эту машину, и вы потеряете одну или две службы, и некоторое время, но не данные.

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

• iptables - это путь для любой системы Linux, но настройте его самостоятельно.

Никогда не используйте никакое "программное обеспечение для обеспечения безопасности", которое не основано на открытых стандартах - они обречены быть плохо написанными и будут взломаны (не вопрос "если", а "когда"). Открытые исходные коды и открытые протоколы открыты для публичного изучения и становятся зрелым и надежным продуктом; Программное обеспечение с закрытым исходным кодом полагается, главным образом, на уверенность авторов в том, насколько великим/безопасным продуктом они думают, что это так, т. е. небольшое количество глаз против земли, полной глаз.

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

• отключить root-логин
• отключить вход по паролю (разрешить вход только по открытому ключу)
• Правка порт SSH

• использовать denyhosts (или аналогичный)

• написать свой собственный скрипт iptbles (чтобы вы точно контролировали, что разрешать, и могли отбросить все остальное)

• принудительное использование защищенных соединений SSL/TLS и наличие действительных, не просроченных и подписанных сертификатов

• включить строгую проверку сертификатов для всех внешних служб (например, при аутентификации пользователей с помощью сервера LDAP на другом компьютере)

Начните здесь:

http://www.debian.org/doc/manuals/securing-debian-howto/

В качестве общей отправной точки я следую эталону/руководству из Центра интернет-безопасности , которые представляют собой исчерпывающую подборку лучших рекомендаций по безопасности. Не похоже, что их тест Debian был обновлен через некоторое время, но общий обзор шагов:

• Применяйте последние патчи/пакеты ОС
• Включить учет системы/ядра/процесса.
• Включить MAC (например, SELinux или AppArmor).
• Включить брандмауэр на основе хоста (iptables).
• Проверьте APT sources.list (ключи верны, источники являются доверенными).
• Минимизируйте сетевые службы, отключите все, что не требуется, и брандмауэр, который есть.
• Используйте TCPWrappers для дальнейшего ограничения доступа к системе.
• Используйте только зашифрованные сетевые протоколы, отключайте незашифрованные сервисы (telnet, ftp и т.д.).
• Настройте удаленный доступ только по SSH.
• Отключить пароли для входа пользователя и требовать аутентификацию на основе ключей.
• Отключить совместное использование файловой системы (NFS, SMB).
• Включите ведение журнала удаленной/централизованной системы (и регулярно просматривайте журналы!).
• Установите пароль уровня BIOS/прошивки.
• Установите пароль для загрузчика.
• Настройте резервные копии системы, имейте план аварийного восстановления и ТЕСТ, чтобы резервные копии были действительными, и чтобы персонал знал процедуры аварийного восстановления!

Существует множество ресурсов по всем этим различным настройкам, включая конкретные команды и файлы конфигурации для внедрения в систему в тестах CISecurity.

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

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

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

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

Некоторые люди указывают на Руководство по безопасности Debian . Этого должно быть вполне достаточно для всего, кроме военных потребностей.

Многие думают, что быть смехотворно параноиком - это круто, профессионально или что-то в этом роде. Это не , это просто раздражает для других администраторов и откровенно репрессивный для ваших пользователей. Большинство вещей, которые вы увидите рекомендуемыми, это просто фальшивая занятая работа, чтобы чувствовать себя полезной для параноидального администратора, но на самом деле не полезной, так как реальное нарушение безопасности, вероятно, вызвано недостаточно обновленной системой и/или из внутреннего источника.

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

Я нахожусь в процессе перехода на полное шифрование диска для всех моих серверов.

Я устанавливаю только те сервисы, которыми пользуюсь. У меня нет брандмауэра; Я настраиваю сервисы, которые мне требуются, для аутентификации или ограничиваю их (с помощью собственной конфигурации программы или TCP-упаковщиков) для определенных IP-адресов. Единственное, что мне когда-либо нужно было блокировать с помощью iptables, это memcached, так как он не имел файла конфигурации и не использовал TCP-оболочки.

Я использую хорошие случайно сгенерированные пароли для своих учетных записей и доверяю своему SSH-серверу (и всем другим службам), чтобы не пускать тех, кто не знает пароль. fail2ban только для тех, у кого ограниченное пространство для файлов журнала, IMO. (У вас должно быть достаточно хороших паролей, чтобы доверять им.)

Пройдите этот хороший практический совет на www.debian.org/doc/manuals/securing-debian-howto/

Я лично изменяю порт ssh и использую fail2ban + denyhosts. И я блокирую все, что не нужно. Чем больше вы блокируете, тем меньше вам нужно беспокоиться.