Во время настройки экземпляров моего виртуального сервера мне требуется, чтобы некоторые приложения были построены с использованием make. Существуют ли какие-либо риски безопасности, связанные с makeустановкой? Или мне следует очистить его перед развертыванием экземпляра?
У меня также есть gccкомпилятор на сервере, который я использую для сборки приложений перед развертыванием.
решение1
Некоторые люди будут утверждать, что наличие инструментов разработки на производственной машине облегчит жизнь злоумышленнику. Однако это настолько незначительное препятствие для злоумышленника, что любой другой аргумент, который вы сможете найти за или против установки инструментов разработки, будет иметь больший вес.
Если злоумышленник смог проникнуть в систему настолько, что он может вызвать любые инструменты, имеющиеся на сервере, то у вас уже есть серьезная брешь в безопасности. Без инструментов разработки есть много других способов записать двоичные данные в файл, а затем выполнить chmod для этого файла. Злоумышленник, желающий использовать пользовательскую сборку исполняемого файла в системе на этом этапе, может просто собрать ее на своей собственной машине и передать на сервер.
Есть и другие, гораздо более важные вещи, на которые стоит обратить внимание. Если установленная часть программного обеспечения содержит ошибку безопасности, есть несколько способов, которыми она может быть подвержена атаке злоумышленника:
- Пакет может содержать исполняемый файл suid или sgid.
- Пакет может запускать службы в системе.
- Пакет может устанавливать скрипты, которые вызываются автоматически при определенных обстоятельствах (сюда входят задания cron, но скрипты могут вызываться и другими событиями, например, при изменении состояния сетевого интерфейса или при входе пользователя в систему).
- Пакет может устанавливать иноды устройств.
Я бы не ожидал, что инструменты разработки будут соответствовать чему-либо из вышеперечисленного, и, таким образом, это не пакет с высоким уровнем риска.
Если у вас есть рабочие процессы, в которых вы хотели бы использовать инструменты разработки, то вам сначала нужно решить, являются ли они разумными рабочими процессами, и если да, то вам следует установить инструменты разработки.
Если вы обнаружите, что эти инструменты вам на сервере не нужны, вам следует воздержаться от их установки по нескольким причинам:
- Экономит дисковое пространство как на сервере, так и на резервных копиях.
- Меньшее количество установленного программного обеспечения упрощает отслеживание ваших зависимостей.
- Если пакет вам не нужен, нет смысла подвергать себя дополнительному риску безопасности, устанавливая его, даже если этот риск незначителен.
Если вы решили, что по соображениям безопасности вы не позволите непривилегированным пользователям размещать свои собственные исполняемые файлы на сервере, то вам следует избегать не инструментов разработки, а каталогов, доступных для записи этим пользователям в файловых системах, смонтированных с разрешениями на выполнение. Даже при таких обстоятельствах инструменты разработки все еще могут быть полезны, но это маловероятно.
решение2
make— это оболочка, синтаксис которой отличается от bash.
Компилятор типа gcc— это мощный, awkнастроенный с набором подстановок, которые стандарт awkне поддерживает. Он несовместим с POSIX sortили catвставляет мусор в вывод. Это интерактивный текстовый редактор (думаю vi), который настроен на редактирование при запуске, а затем выход перед отображением пользовательского интерфейса.
В них нет ничего изначально небезопасного, они не делают вашу машину более небезопасной, чем та, на которой у вас установлено catперенаправление bash ++ shell.
решение3
makeсамо по себе прекрасно. makeэто просто фреймворк для отслеживания и автоматизации зависимостей. Однако обычно он используется вместе с компиляторами, и желательно, чтобы они не были доступны в производственной системе, поскольку они совершенно не нужны. То же самое касается всех ненужных пакетов, будь то общие библиотеки, интерпретаторы и т. д. Программное обеспечение, установленное в производственных системах, должно строго контролироваться, и должны присутствовать только те пакеты, которые требуются приложению.
Вам следует собрать свое приложение на сервере сборки, упаковать его, а затем развернуть двоичный пакет в ваших производственных системах.
Примечание: собственные инструменты упаковкиотстой. Даже не пытайтесь их понять. Вместо этого посмотрите Джордана Сисселаfpm. Это превращает процесс упаковки в настоящее удовольствие.
решение4
Вы спрашиваете, makeследует ли устанавливать на рабочем сервере, но мой настоящий вопрос был бы таким: у кого есть доступ к этому рабочему серверу и какие меры безопасности вы используете для борьбы с вторжением? Если он makeне был установлен, но кто-то получил rootдоступ, угадайте, что? Они могут вручную установить makeвсе, что захотят.
Суровая реальность компьютерной безопасности заключается в том, что как бы вы ни хотели предотвратить нежелательный доступ, зацикленность на блокировке доступа не так важна, как:
- Кто имеет доступ к серверу?
- Что можно сделать, чтобы восстановиться после взлома?
Все зависит от того, какую работу вы выполняете. Я работаю в основном в сфере веб-серверов, и мое отношение к этому таково: любой, кто получает от меня доступ к производственному серверу, должен доказать свои навыки, знания и зрелость. Вот и все. Иногда это занимает несколько дней. Иногда это занимает месяцы. Но в целом, ваша лучшая линия безопасности на производственных серверах — это контроль доступа в дополнение к прочим вещам, которые мы делаем для защиты серверов.