Вопрос или проблема
У меня есть сервер с Ubuntu 20.04 Server. Я купил свой сервер в Digital Ocean около года назад и каждый месяц стараюсь улучшить его безопасность, и, к счастью, у меня это получается. Но по поводу организации пользователей у меня всегда есть сомнения.
Это личный сервер, поэтому я на самом деле спрашиваю, чтобы улучшить свое понимание для будущих проектов, которые могут включать больше пользователей.
Права доступа к моему корневому каталогу следующие:
0 lrwxrwxrwx 1 root root 7 May 14 2020 bin -> usr/bin
4 drwxr-xr-x 4 root root 4096 Feb 10 06:59 boot
0 drwxr-xr-x 16 root root 3820 Oct 12 02:34 dev
12 drwxr-xr-x 110 root root 12288 Feb 16 18:11 etc
4 drwxr-xr-x 4 root root 4096 Apr 3 2021 home
0 lrwxrwxrwx 1 root root 7 May 14 2020 lib -> usr/lib
0 lrwxrwxrwx 1 root root 9 May 14 2020 lib32 -> usr/lib32
0 lrwxrwxrwx 1 root root 9 May 14 2020 lib64 -> usr/lib64
0 lrwxrwxrwx 1 root root 10 May 14 2020 libx32 -> usr/libx32
16 drwx------ 2 root root 16384 May 14 2020 lost+found
4 drwxr-xr-x 2 root root 4096 May 14 2020 media
4 drwxr-xr-x 2 root root 4096 May 14 2020 mnt
4 drwxr-xr-x 3 root root 4096 Dec 18 13:48 opt
0 dr-xr-xr-x 197 root root 0 Jun 12 2021 proc
4 drwx------ 10 root root 4096 Feb 6 19:31 root
0 drwxr-xr-x 31 root root 1040 Feb 16 13:04 run
0 lrwxrwxrwx 1 root root 8 May 14 2020 sbin -> usr/sbin
4 drwxr-xr-x 8 root root 4096 Feb 16 17:56 snap
4 drwxr-xr-x 3 root root 4096 Apr 3 2021 srv
0 dr-xr-xr-x 13 root root 0 Jun 12 2021 sys
4 drwxrwxrwt 20 root root 4096 Feb 16 18:39 tmp
4 drwxr-xr-x 15 root root 4096 Aug 6 2021 usr
4 drwxr-xr-x 16 root root 4096 Dec 4 18:50 var
Вы можете видеть, сколько файлов имеет права выполнения для others groups, но действительно ли это необходимо? Права x означают, что любой пользователь может выполнить
cd /boot
Или что-то подобное. Я знаю, что они не могут редактировать или удалять что-либо там, но если они могут войти в каталог и выполнить ls, этот случайный пользователь может получить информацию, которую я, возможно, не хочу, чтобы пользователь получил. Однажды друг, который знал больше о Linux, чем я, сказал мне, что если вы хотите сломать сервер Ubuntu, вы можете сделать это, изменив права доступа к файлам. Поэтому я не хочу это тестировать.
Моя цель заключается в том, чтобы каждый пользователь не мог делать ничего с дополнительными полномочиями (входить в /dev или /boot), только пользовательские действия.
Но я боюсь что-то сломать, изменяя права доступа.
Моя идея такая: я владелец сервера и я могу получить root, поэтому мой первый шаг:
В корневом каталоге я бы выполнил sudo chown root:power, где power — это группа, в которую я могу добавить некоторых пользователей, которые могут делать больше, чем обычно, затем chmod 750 на все (кроме temp, например)
Но я слышал, что если вы делаете такие вещи, например, www-data не сможет управлять службами apache или что-то изменить.
Так что мне придется добавить к группе power пользователя www-data, хорошо, тогда он сможет управлять своими ресурсами, но я думаю, что есть много других системных пользователей/групп, которым нужны аналогичные настройки, о которых я не осведомлен в данный момент.
Я надеюсь, вы можете более или менее понять, что я хочу сделать, и какова моя цель: изменить сервер для лучшего управления пользователями, ограничивая по roles, например. Но я немного потерян в том, с чего начать.
Спасибо всем.
Нет.
Права и владельцы системных файлов уже настроены для обеспечения безопасности.
Единственное, что вы достигнете, меняя владельцев и права доступа к системным файлам, это сломать свою систему.
Это очень опасный способ мышления, особенно если вы не знакомы с использованием Linux. Играться с системой в целом нормально, если вы знаете, что делаете. Но Стремление улучшить то, что не сломано, обычно не является хорошей идеей.
Разработчики Ubuntu потратили десятилетия на тонкую настройку и улучшение программного обеспечения, чтобы сделать его более чистым и безопасным.
Если вы думаете, что нашли способ сделать систему лучше или безопаснее, пожалуйста, подумайте о вкладе в разработку Ubuntu. В случае вклада в разработку много других людей рассмотрит и проверит ваши предложенные изменения, прежде чем они станут частью ОС.
Безопасность Unix, а позже и Linux, всегда по умолчанию была максимально открытой. Вещи закрываются, когда они должны быть закрыты, и остаются открытыми в противном случае.
Это означает, что если вы попытаетесь сделать что-то необычное, но не совсем опасное, есть большая вероятность, что вам это разрешено.
Специалисты по безопасности не любят такой подход. Они хотят, чтобы вещи были закрыты максимально и открывались только в случае необходимости. Так меньше неприятных сюрprises. Похоже, ваши инстинкты находятся в этом лагере.
В закрытой системе у вас есть разрешение делать свою работу и ничего больше. Каждый раз, когда вы хотите сделать что-то, что даже немного выходит за рамки ваших возможностей, вам нужно получить разрешение. Разработчики ненавидят работать в такой системе.
Сложно взять старую открытую систему вроде Ubuntu и попробовать ее закрыть. Вы обнаружите, что существуют неопубликованные зависимости, когда, казалось бы, не связанные программы перестают работать с странными сообщениями об ошибках, когда доступ закрывается.
Таким образом, это вопрос приоритетов: что для вас важнее, безопасность или удобство использования? Есть версии Unix, которые более закрыты, чем Ubuntu. Их разработали эксперты по безопасности, которые провели тяжелую работу по обнаружению этих неопубликованных зависимостей.
С учетом всего вышесказанного, ответ Nmath также верен. Множество очень умных людей рассмотрели безопасность Ubuntu и признали ее адекватной. Вероятность того, что вас поразит неизвестная уязвимость, очень и очень мала.
Если я могу добавить свои два цента: делиться своим логином в оболочке опасно, так как вектор атаки значительно открывается, и это гораздо более опасно, если открывать его случайным людям, которых вы никогда не встречали лично. Доверяйте с осторожностью всему, что кто-либо говорит о безопасности Ubuntu, или безопасности RHEL, или безопасности HardenedBSD, или любого общедоступного сетевого хоста, потому что самой распространенной причиной проблем с безопасностью компьютера являются пользователи, и если вы позволяете им войти, вы также впускаете этот риск в свой хост. SELinux — это хорошая идея, но я нахожу, что это очень сложно. Это для меня крайне сложное программное обеспечение для мира Linux, но крайне впечатляющее, когда используется правильно. Я не знаю, есть ли у Ubuntu целевая политика, которую вы можете загрузить, в Debian есть такая для Debian 11 в последний раз, когда я это делал, однако дистрибутивы корпоративного Linux, такие как Rocky Linux, RHEL, OpenSUSE или Fedora, гораздо более дружелюбны по отношению к SELinux (за исключением LTS OpenSUSE Leap), и я получил выгоду от установки OpenSUSE Tumbleweed (обновление в реальном времени) с использованием целевых и обязательных политик SELinux. Я думаю, что Fedora использует это по умолчанию, поправьте меня, если я неправ. Если это то, что вы хотите, подготовьте ясную таблицу и много времени для изучения. Это было бы невероятно полезно!
Я рекомендую учитывать это, но также скачать этот совершенно революционный инструмент для аудита безопасности, он с открытым исходным кодом и находится на github: https://github.com/CISOfy/lynis (или с помощью apt install lynis для возможно немного старой версии, но это не критично).
Мои серверы обычно не подвергаются атакам, и если это происходит, я вижу, как это начинает происходить, наблюдая за журналами, тестируя свое программное обеспечение безопасности и следя за необъяснимой аномальной активностью и даже атакуя свой собственный хост. Хорошая частая проверка предупреждений журнала, остановленных служб systemd, работы брандмауэра, просмотр ваших сетевых подключений watch -n0.2 "netstat --inet -anep6 | sort -g " (или команды ss). Также, как только вы отдаляетесь от конфигурации, над которой работаете, полезно быть как можно более уверенным в том, что конфигурация, а также любое связанное абстрактное программное обеспечение или устройства или порты или адреса находятся в порядке, и если у вас есть сомнения, то полезно читать больше или попросить о помощи.
Возможно, используйте свои порты доступа пользователей на :22, но перенаправляйте из контейнера LXC в некое подобие тюрьмы там. Docker может сделать это довольно просто, но в зависимости от того, что нужно вашим пользователям. Или посмотрите на настройки пользователей SSH chroot, это тоже возможно. Lynis посоветует вам множество техник аудита сервера SSH! Умный администратор быстро это обнаружит ^^ Удачи!
Ответ или решение
Изменение разрешений каталога root в Unix-подобных системах, таких как Ubuntu Server, является весьма тонким вопросом, требующим глубокого понимания принципов безопасности и структуры операционной системы. Ваша цель улучшить безопасность системы вполне оправдана, однако не следует поддаваться соблазну менять разрешения в корневом каталоге без убедительных оснований и предварительного анализа последствий.
1. Почему не стоит изменять разрешения root-каталога?
Основные разрешения в Ubuntu и других дистрибутивах Linux ориентированы на баланс между функциональностью и безопасностью. Разрешения, выставленные по умолчанию, разработаны для того, чтобы минимизировать риски, не нарушая при этом работоспособность системы. Например, ваши настройки, такие как drwxr-xr-x для каталогов /boot или /etc, позволяют обычным пользователям просматривать содержимое данных каталогов, но не изменять его. Это важно для работы системных процессов и обеспечения совместимости различных служб и демонов.
2. Риски изменения разрешений
Изменив разрешения на каталогах, вы можете столкнуться с рядом проблем:
- Нарушение функциональности: Многие приложения и службы зависят от определённых разрешений. Например, если вы закроете доступ www-data к некоторым каталогам, это может привести к сбоям в работе веб-сервера Apache или неработоспособности веб-приложений.
- Сложности с поддержкой: Если в будущем вам понадобится провести администрирование или настройку системы, вы можете столкнуться с непонятными ошибками. Изменение разрешений может вызвать непредсказуемое поведение программ без явной причины.
- Отсутствие документации: Ubuntu и другие дистрибутивы не проектировались с учетом того, что системные администраторы будут широко менять разрешения. Это может привести к отсутствию документации и поддерживаемым решениям при возникновении проблем.
3. Рекомендации по улучшению безопасности
Вместо изменения разрешений в корневом каталоге рекомендуется рассмотреть другие методы повышения безопасности вашего сервера:
- Использование групп доступа: Создайте специфические группы для пользователей, которым необходимо больше прав. Например, добавьте пользователей в группу
sudo, чтобы они могли выполнять команды от имени суперпользователя, сохраняя при этом разделение прав. - Управление SSH-доступом: Настройте доступ через SSH, ограничив пользователей, которые могут подключаться к серверу. Использование SSH-ключей вместо паролей значительно повысит безопасность.
- Мониторинг и аудит: Используйте инструменты для аудита системы, такие как Lynis, для анализа и рекомендации по устранению уязвимостей.
- Настройка файервола: Убедитесь, что ваши правила файервола ограничивают доступ к необходимым сервисам и портам, минимизируя возможные точки входа для злоумышленников.
4. Заключение
Изменение разрешений в каталоге root на сервере Ubuntu 20.04 не рекомендуется как метод повышения безопасности. Это может привести к более серьезным проблемам, чем вы хотите решить. Вместо этого, лучше использовать стандартные механизмы управления доступом и безопасности, которые уже можно эффективно настроить для достижения ваших бизнес-целей. Используйте существующие инструменты и передовые практики, чтобы защитить свою систему и избежать ненужного риска.