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


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

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

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


66


Источник


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


Ответы:


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

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

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

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

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

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

50



После выполнения всех этих действий BASTILLE против системы, чтобы искать что-нибудь еще. Я также рекомендовал бы делать все возможное, небезопасные проверки Nessus системы; затем исправить все, что он оповещает. - Scott Pack
Компиляция настраиваемого ядра не обеспечивает преимуществ безопасности, если вы действительно не знаете, что делаете. Вы также не будете следить за обновлениями, если не поместите его в систему управления пакетами, что приведет к ухудшению безопасности. - Adam Gibbins
-1 для обеспечения безопасности через неясность. В противном случае достойный ответ. - dwc
@Adam - да, я знаю, что, тем не менее, я предпочитаю иметь монолитное ядро, состоящее только из частей, которые мне нужны. вероятно, очень отсталым, но все же я это делаю. @dwc - это всего лишь один дополнительный шаг, который является лишь обледенением или, как мы говорим, вишня на вершине кучи неприятных вонючих вещей. - pQd
И вы имеете в виду sudo not su - - LapTop006


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

  • Используйте белый список, а не черный список, т. Е. Блокируйте все, и только разрешите то, что вам нужно, отрицайте все остальное.
  • Не используйте 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% безопасным - это просто невозможно, поэтому цель состоит в том, чтобы сделать максимально безопасным - если это слишком много усилий, чтобы сломать вашу систему, это достаточно хорошо, и большинство ламеров script-kiddies перейдут на следующую систему.

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

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

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


18



«... небольшое количество глаз и земля, полная глаз». - Я желаю, чтобы «корпорации» осознали это, но безопасность через неясность, по-видимому, является основной тенденцией. Да, запуск службы, такой как ssh, на нестандартном порту, не будет удерживать определенного атакующего. Тем не менее, он уберет детей-сценаристов - кто-то запустит атаку словаря на ряд IP-адресов на порту 22. - L0neRanger


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

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

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

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

12



Вы получаете upvote для отключения пароля auth. - derobert


Начало здесь:

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


9



Руководство по безопасности Debian - это фантастический ресурс. - kce


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

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

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


6





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

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

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

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


5



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


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

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

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

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

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

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


4





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

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


3



Тьфу. Вы заставили меня «изменить SSH-порт». Нет никакого смысла. Особенно, когда какой-либо joe schmoe с достаточным временем на руках может сканировать порт и мгновенно узнать, какой порт SSH работает. Он объявляет имя службы (и версию сервера), как только вы подключаетесь. - Matt Simmons
Да, я знаю, что кто-то может сканировать порт и узнать правильный порт. Но большинство атак приходится на порт по умолчанию. Просто попробуйте получить некоторую статистику, изменив порт. - Vihang D