Метка: псевдобезопасность

Обновление с небезопасного репозитария

Posted on by

Иногда нужно поставить какой-нибудь старый или просто сторонний софт с «левых» репозитариев. Для этого apt настойчиво требует добавить в систему открытые части ключей для сверки подписей, что делать не всегда нецелесообразно. Но в последних версиях дебиановцы очень «позаботились» о пользователях и просто не позволяют качать софт и даже вообще получать его списки с левых репозитариев, что уже совсем негоже. Да, небезопасно. Да, в общем случае не правильно. Но не разрабам дистра решать как действовать в той или иной ситуации. К сожалению, приходиться обходить это отмычкой, невольно вспоминая что-то похожее в Windows стародавних версий.

Отмычка такая. Добавляем кастомный конфиг /etc/apt/apt.conf.d/99custom такого содержания:

Acquire::Check-Valid-Until "false";
Acquire::AllowInsecureRepositories "true";
Acquire::AllowDowngradeToInsecureRepositories "true";

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

Обновление с репозитария без подписи

Posted on by

Начиная примерно с дистрибутива buster стандартный установщик дебиана apt-get требует подписи всех используемых репозитариев. Обычный способ использования репозитария — добавление его подписи в систему. Это, однако, не всегда удобно и целесообразно. Иногда нужно что-то взять из сторонних репозитариев не добавляя подписи в систему. Это можно сделать разово при обновлении с помощью опции

apt-get update --allow-unauthenticated

Намного удобнее сделать это навсегда в отдельном списке репозитариев по типу:

deb [arch=amd64 allow-insecure=yes] http://www.deb-something-exampe.org buster main

Использование репозитериев без подписи в общем случае не безопасно, но в определённых случаях разумно обновляться именно так.

UPD: Обновленный и более хороший способ

Парольная безопасность

Posted on by

Всем информационным безопасникам известны стандартные схемы повышения парольной безопасности. В частности, к таковым относятся:

  • Обязательная смена паролей по истечении определённого срока,
  • Автогенерация «бессмысленного» пароля с хорошим разнообразием символов и длиной, но который проблематично запомнить.

Эти новшества в последнее время вводят начиная от панелей хостинга, заканчивая интернет-банками. Я вижу всего два варианта, почему их вводят: чисто для бюрократии — что у нас есть парольный аудит и мы блюдём безопасность (с пониманием, что такая мера плохо работает) и когда инициатор действительно верит в то, что этим самым делает продукт безопаснее. Последнее в корне неверно.

А дело в том, что не будет пользователь, какой бы квалифицированный он не был, каждые 3 месяца получать «белибердовый» 12-значный пароль и запоминать его. А тётя Маша-бухгалтер и тем более не будет этого делать. Будут обходные пути и саботаж: пароль запишут на бумажку или ещё хуже — в файлик на компьютере. Причем, «тётя Маша» сделает это очевидным способом на самое видное место — рабочий стол, и ещё подпишет куда это вводить надо…

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

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

Господа безопасники, если читаете это: применяйте схемы разумно. Давайте выбирать пароль пользователю самому, проверку на сложность и длину сделать — элементарная программисткая задача. Срок действия пароля тоже должен быть разумый. И обучайте пользователей: один долгий пароль в памяти намного лучше десятка сменных, но на бумажке или в файлике.