Назад | Перейти на главную страницу

Безопасно ли устанавливать make на производственном сервере?

Во время настройки экземпляров виртуального сервера мне нужно, чтобы некоторые приложения были созданы с использованием make. Есть ли риски безопасности, связанные с make установлены? Или мне следует очистить его перед развертыванием экземпляра?

У меня также есть gcc компилятор на сервере, который я использую для создания приложений перед развертыванием.

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

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

Есть и другие, более важные вещи, на которые стоит обратить внимание. Если установленная часть программного обеспечения содержит ошибку безопасности, есть несколько способов раскрыть ее злоумышленнику:

  • Пакет может содержать исполняемый файл suid или sgid.
  • Пакет может запускать службы в системе.
  • Пакет может устанавливать сценарии, которые автоматически запускаются при определенных обстоятельствах (это включает задания cron, но сценарии могут быть вызваны другими событиями, например, при изменении состояния сетевого интерфейса или при входе пользователя в систему).
  • Пакет может устанавливать inodes устройств.

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

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

Если вы обнаружите, что вам действительно не нужны эти инструменты на сервере, вам следует воздержаться от их установки по нескольким причинам:

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

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

make это оболочка, синтаксис которой отличается от bash.

Компилятор вроде gcc это мощный awk настроен с набором замен, которые стандартные awk не поддерживает. Это не POSIX-совместимый sort или cat что вводит мусор в вывод. Это интерактивный текстовый редактор (подумайте vi), который настроен на редактирование при запуске, а затем выход до отображения пользовательского интерфейса.

В них нет ничего небезопасного по своей сути, они не делают вашу машину более небезопасной, чем та, на которой у вас установлен bash + cat + перенаправление оболочки.

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

Вы должны собрать свое приложение на сервере сборки, упаковать его, а затем развернуть двоичный пакет в своих производственных системах.

Примечание: собственные инструменты упаковки сосать. Даже не пытайся их грокнуть. Вместо этого посетите Джордан Сиссель fpm. Это делает упаковку абсолютным удовольствием.

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

Вы спрашиваете, если make должен быть установлен на производственном сервере, но мой реальный вопрос будет таков: у кого есть доступ к этому производственному серверу и какие меры предосторожности у вас есть, чтобы справиться с вторжением? Если make не был установлен, но кто-то получил root доступ, угадайте что? Их можно установить вручную make и все, что они хотят.

Суровая реальность компьютерной безопасности такова, что вы хотите предотвратить нежелательный доступ, одержимость блокировкой доступа не так важна, как:

  1. У кого есть доступ к серверу?
  2. Что вы можете сделать, чтобы откатиться после взлома?

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

make сам по себе безвреден. Все, что он делает, - это запускает приложения в установленном порядке, в зависимости от указанных вами зависимостей и того, какие файлы уже существуют в системе. Он даже может быть полезен как часть процесса установки: вы можете использовать его для размещения предварительно скомпилированных файлов там, где они должны быть, или для запуска модульных тестов или для других вещей.

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