Какие шаги вы предпринимаете для защиты сервера 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).
    Escape-символ '^]'.
    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. И я блокирую все, что не нужно. Чем больше вы блокируете, тем меньше вам нужно беспокоиться.