Собирает ли PureOS мои данные каким-либо образом? [закрыто]

Мне нравится следующая установка для управления доступом по SSH, которую я использовал для управления группой пользователей на небольшом парке серверов. Безопасность и простота управления занимают одно из первых мест в списке моих приоритетов.

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

Настройка

Установка программного обеспечения (необязательно, но полезно):

yum install members   # or apt install members

Добавить группы:

addgroup --system allowssh
addgroup --system sftponly

В /etc/ssh/sshd_configубедитесь, что следующие настройки установленыNo:

PermitRootLogin no
PubkeyAuthentication no
PasswordAuthentication no

И в конце /etc/ssh/sshd_configдобавить эти две строфы:

Match Group allowssh
    PubkeyAuthentication yes

Match Group sftponly
    ChrootDirectory %h
    DisableForwarding yes
    ForceCommand internal-sftp

(не забудьте перезапустить SSH после редактирования файла)

Пояснение

Итак, что все это делает?

  • В качестве дополнительной меры безопасности он всегда отключает вход в систему с правами суперпользователя.
  • Он всегда отключает вход в систему на основе пароля -(слабые пароли представляют большой риск для серверов, на которых работает sshd ).
  • Он разрешает вход (pubkey )только для пользователей в группе allowssh.
  • Пользователи в группе sftponlyне могут получить оболочку через SSH, только через SFTP.

Управление доступом осуществляется просто путем управления членством в группе. (Изменения членства в группе вступают в силу немедленно, перезапуск SSH не требуется; но обратите внимание, что существующие сеансы не затрагиваются ). members allowsshпокажет всех пользователей, которым разрешен вход через SSH, а members sftponlyпокажет всех пользователей, которым разрешен доступ к SFTP.

# adduser marcelm allowssh
# members allowssh
marcelm
# deluser marcelm allowssh
# members allowssh
#

Обратите внимание, что ваши пользователи sftp должны быть членами как sftponly(, чтобы гарантировать, что они не получат оболочку ), так и allowssh(, чтобы разрешить вход в систему в первую очередь ).

Дополнительная информация

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

    Если вы действительно этого не хотите, то также добавьте PasswordAuthentication yesк строфе Match Group allowssh. Это позволит пользователям allowsshавторизоваться как по публичному ключу, так и по паролю. Кроме того, вы можете добавить еще одну группу (и Match Groupстрофу ), чтобы выборочно предоставлять пользователям вход на основе пароля -.

  2. Эта конфигурация ограничивает любого sftponlyпользователя своим домашним каталогом. Если вы этого не хотите, удалите директиву ChrootDirectory %h.

    Если вы действительно хотите, чтобы chroot работал, важно, чтобы домашний каталог пользователя (и любой каталог над ним )принадлежал root:rootи не был доступен для записи группе/другим. Подкаталоги домашнего каталога могут принадлежать пользователю -и/или доступны для записи.

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

  3. Установка оболочки sftponlyпользователей на /sbin/nologinне является ни необходимой, ни вредной для этого решения, поскольку ForceCommand internal-sftpSSH переопределяет оболочку пользователя.

    Тем не менее, использование /sbin/nologinможет помочь остановить их вход в систему с помощью других способов (физической консоли, Samba и т. д. ).

  4. Эта настройка не разрешает прямой rootвход через SSH; это формирует дополнительный уровень безопасности. Если вам действительно действительно нужны прямые входы в систему root, измените директиву PermitRootLogin. Попробуйте установить его на forced-commands-only, prohibit-passwordи (в крайнем случае)yes.

  5. Чтобы получить бонусные баллы, обратите внимание на ограничение suдоступа к root-доступу; добавьте системную группу с именем wheelи добавьте/включите auth required pam_wheel.soв /etc/pam.d/su.

-2
14.03.2019, 09:06
1 ответ

Исходный код PureOS доступен здесь :http://repo.pureos.net/pureos/pool/main/. Копание в исходном коде и/или установка дистрибутива и анализ сетевого трафика являются лучшими прямыми способами определения безопасности дистрибутива.

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

PureOS основана на Debian, у которого «много глаз» на коде, и хотя производные теоретически могут вносить любые модификации, которые они хотят, с доступным кодом и такими вещами, как проверка соответствия FSF, хотя и не невозможно, я бы сказал, что это маловероятно, что этот дистрибутив представляет собой исключительную угрозу вашей конфиденциальности.

Недавняя -некоторая активность в системе отслеживания ошибок :https://tracker.pureos.net/, и это хорошо. Может показаться пугающим видеть этот большой список ошибок, но с миллионами строк кода в дистрибутиве они есть у каждого, и активные попытки устранить ошибки — лучший признак, чем бездействие (, что указывает на безразличие ).

Если у вас нет исключительных потребностей в безопасности, которые потребуют «усиленного», -ориентированного на безопасность дистрибутива, такого как Qubes, могу поспорить, что с PureOS все в порядке. Кроме того, его основной аргумент в пользу «Все бесплатное программное обеспечение», поэтому в нем нет неразборчивых двоичных двоичных объектов.

2
28.01.2020, 05:15

Теги

Похожие вопросы