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

66

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

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

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

Питер Мортенсен
источник
1
Существует много совпадений с serverfault.com/questions/42/securing-a-fresh-ubuntu-server и
Zoredache
1
У Ubuntu есть ufw, а у Debian нет;) Я задавался вопросом, настраивали ли люди сами по себе iptables или использовали какое-то программное обеспечение, такое как fireHOL
Thomaschaaf
Я всегда склонялся к написанию правил iptables самостоятельно. У меня есть котел, который выполняет такие вещи, как отбрасывание всех фрагментов, рождественские пакеты и т. Д. Все, что выходит за рамки, зависит от конкретной системы и обычно довольно мелко. Я не могу подчеркнуть, достаточно отбрасывая фрагменты при использовании iptables, кстати. По какой-то причине я еще не исследовал, iptables проверяет только первый фрагмент, а остальное пропускает без проверки. На мой взгляд, это делает фрагменты ответственностью.
Скотт Пак
3
Хм ... У Debian есть UFW. packages.debian.org/ufw
womble

Ответы:

50

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

  • установка системы в экспертном режиме, только те пакеты, которые мне нужны
  • рукописный межсетевой экран с политикой по умолчанию для 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 и настройте его время от времени на запуск
pQd
источник
4
После всего этого запустите BASTILLE против системы, чтобы найти что-нибудь еще. Я бы также порекомендовал сделать полнопроходные и небезопасные проверки системы Nessus; затем исправьте все, о чем он сообщает.
Скотт Пак
13
Компиляция собственного ядра не дает преимуществ безопасности, если вы действительно не знаете, что делаете. Вы также не будете обновлять его, если не поместите его в систему управления пакетами, что приведет к ухудшению безопасности.
Адам Гиббинс
3
-1 за безопасность через неизвестность. В противном случае достойный ответ.
DWC
@ Adam - да, я знаю это, но все же я предпочитаю иметь монолитное ядро, которое состоит только из частей, которые мне нужны. это, вероятно, очень отсталый, но все же я делаю это. @dwc - это всего лишь один дополнительный шаг, который является просто глазурью или, как мы говорим, вишней на вершине кучи неприятных вонючих вещей.
PQD
1
И ты имеешь в виду sudo not su
LapTop006
18

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

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

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

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

Ксеркс
источник
«... небольшое количество глаз против земли, полной глаз». - Я бы хотел, чтобы «корпорации» осознали это, но тенденция к безопасности через неизвестность, похоже, является наиболее популярной. Да, запуск службы, такой как ssh, на нестандартном порту не защитит решительного злоумышленника. Это, однако, будет держать в секрете скриптового сценария - кто-то запускает словарную атаку на диапазон IP-адресов на порту 22.
L0neRanger
12
  • отключить root-логин
  • отключить вход по паролю (разрешить вход только по открытому ключу)
  • изменить порт SSH
  • использовать denyhosts (или аналогичный)

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

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

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

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

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

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

jtimberman
источник
5

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

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

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

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

pcapademic
источник
+1 за хороший ответ. Я должен указать, что по умолчанию отрицать не раздражает, если вы подходите правильно. Конечно, вы должны знать, что вы разрешаете, верно? На самом деле, это должно быть записано простым языком как заявление о политике. Если вы не делаете это как обычную рутину, то вы не делаете свою работу в качестве администратора. Если да, обновить правила брандмауэра очень просто.
DWC
Очень хорошие очки. У каждой организации должен быть простой текст политики безопасности. По мере изменения потребностей организации, заявление о политике должно обновляться. Если бы только администратор планировал внедрение правил брандмауэра и CYA, умный администратор поддерживал бы такую ​​формулировку политики, даже если руководство организации не может думать о безопасности.
pcapademic
4

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

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

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

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

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

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

Тедди
источник
3

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

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

Виханг Д
источник
4
Тьфу. Вы заставили меня, пока "не измените порт SSH". Нет никакого смысла. Особенно если когда-нибудь Джо Шмоэ, у которого достаточно времени, может сканировать порты и мгновенно выяснить, на каком порту работает SSH. Он объявляет имя службы (и версию сервера), как только вы подключаетесь.
Мэтт Симмонс
3
Да, я знаю, что любой может сканировать порт и найти правильный порт. Но большинство атак на порт по умолчанию. Просто попробуйте получить статистику, изменив порт.
Виханг Д