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

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

Я хочу, чтобы часть этого вопроса охватила то, что вы используете в качестве брандмауэра? Просто iptables настроен вручную или вы используете какое-то программное обеспечение, чтобы помочь вам? Какой лучший способ? Заблокировать все и разрешить только то, что нужно? Есть ли хорошие учебники для начинающих по этой теме?

Вы меняете свой порт SSH? Используете ли вы программное обеспечение, такое как Fail2Ban, для предотвращения атак грубой силы?

Обязательно:

• установка системы в экспертном режиме, только те пакеты, которые мне нужны
• рукописный межсетевой экран с политикой по умолчанию для iptables'input: drop, разрешающий доступ к SSH, HTTP или любому другому серверу, на котором работает
• Fail2Ban для SSH [и иногда FTP / HTTP / другое - в зависимости от контекста]
• отключить root-логины, принудительно использовать обычного пользователя и sudo
• кастомное ядро ​​[просто старая привычка]
• плановое обновление системы

В зависимости от уровня паранойи дополнительно:

• отбросить политику на выходе, кроме пары разрешенных пунктов назначения / портов
• integritдля проверки, не были ли изменены некоторые части файловой системы [с контрольной суммой, хранящейся вне машины], например Tripwire
• плановое сканирование по крайней мере с Nmap системы извне
• автоматическая проверка журналов на наличие неизвестных шаблонов [но это в основном для обнаружения неисправности оборудования или некоторых небольших сбоев]
• запланированный запуск chkrootkit
• неизменный атрибут для /etc/passwdдобавления новых пользователей немного сложнее
• / tmp смонтирован с помощью noexec
• перехватчик портов или другой нестандартный способ открытия портов SSH [например, посещение «секретной» веб-страницы на веб-сервере разрешает входящее соединение SSH в течение ограниченного периода времени с IP-адреса, который просматривал страницу. Если вы подключаетесь, -m state --satete ESTABLISHEDзаботитесь о разрешении потока пакетов, пока вы используете один сеанс SSH]

Вещи, которые я не делаю сам, но имеет смысл:

• безопасность для ядра
• удаленный системный журнал, поэтому журналы не могут быть перезаписаны при взломе системы
• оповещение о любых SSH логинах
• настройте rkhunter и настройте его время от времени на запуск

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

• Используйте белый, а не черный список - т.е. блокируйте все, и разрешайте только то, что вам нужно, запрещайте все остальное.
• Не используйте 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. И я блокирую все, что не нужно. Чем больше вы блокируете, тем меньше вам нужно беспокоиться.