LINUX.ORG.RU

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

Вообще предпочтение, если возможно запускать через firejail, в планах docker, chroot, просто виртуалки. rootkit запускался эпизодически

Плюс иногда и выборочно lsof|grep -i tcp|grep -i established.

Регулярная пересборка обновлений ядра.

glsa-check полезно

anonymous ()
Ответ на: комментарий от anonymous

glsa-check полезно

Приятно встретить однополчанина

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

Есть две идеи:

1. Написать проверочку для distfiles/*, получить архивы, их подписи, хеши с других источников, архива интернета, можно начать с официальных сайтов и сверить с портадж. (Помню инцендент с vsftpd, разные струи одной версии).

2. Возможность пересборки для верификации бинарников. Желательно чтобы такая возможность была в базовой системе. В теории если стейдж, portage-*, /etc/portage, список команд или скрипт установки одинаковы,- системы должны получится идентичны.

anonymous ()
Ответ на: комментарий от Deleted

У меня NixOS. Его разве рутуют?

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

anonymous ()

Руткиты в дистрибутивах Линукс.

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

Выполните в своём любимом дистре следующие 3 команды:

dmesg | grep -i 'x.*509'
modinfo usbcore | grep '^sig'
ls -l /usr/src/linux/certs/signing_key.pem

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

Вторая, вместо usbcore, можно ввести название любого другого модуля ядра, покажет подписаны ли модули ядра.

Третья - спрятан/уничтожен ли секретный ключ для подписи модулей ядра, этого файла в рабочей системе быть не должно!

И отпишите здесь название дистра и результат проверки.

anonymous ()
Ответ на: комментарий от King_Carlo
System checks summary
=====================

File properties checks...
    Files checked: 127
    Suspect files: 3

Rootkit checks...
    Rootkits checked : 476
    Possible rootkits: 2
    Rootkit names    : Sniffer component, Spam tool component

Applications checks...
    Applications checked: 2
    Suspect applications: 0

Applications checks...
    Applications checked: 2
    Suspect applications: 0
amd_amd ★★ ()
Ответ на: комментарий от Deleted

я так на винде баловался, брал простейшие шел команды - например эту

Get-AppxPackage  -AllUsers | Remove-AppxPackage
заворачивал все это в ехе, добавлял прав на запуск и вуаля ни один антивирус не мог определить подставу, но уже буквально через неделю мои поделия почему то палились обычным встрооеным защитником, хотя я ничего не отправлял в сеть - видать винда сама сливала данные...

amd_amd ★★ ()
Ответ на: комментарий от amd_amd

ни один антивирус не мог определить подставу, но уже буквально через неделю мои поделия почему то палились

Только вот тут ситуация не изменилась и через несколько лет.

Deleted ()
Ответ на: Руткиты в дистрибутивах Линукс. от anonymous

Fedora 30

bvn13@bvn13-book  ~  dmesg | grep -i 'x.*509'                                                                                                   ✔  1077  22:16:19 
[    0.716939] Asymmetric key parser 'x509' registered
[    0.802061] Loading compiled-in X.509 certificates
[    0.825092] Loaded X.509 cert 'Fedora kernel signing key: 7af26f362e0cda74a8cb6c31a1dc0c5ab045ce31'
[    2.255338] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20190509/nsarguments-59)
[    2.255384] ACPI Warning: \_SB.PCI0.RP01.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20190509/nsarguments-59)
[    6.535573] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    6.537466] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
 bvn13@bvn13-book  ~  modinfo usbcore | grep '^sig'~                                                                                             ✔  1078  22:16:21 
modinfo: ERROR: Module usbcore not found.
 bvn13@bvn13-book  ~  ls -l /usr/src/linux/certs/signing_key.pem                                                                             1|1 ↵  1079  22:16:38 
ls: cannot access '/usr/src/linux/certs/signing_key.pem': No such file or directory
 bvn13@bvn13-book  ~   
bvn13 ★★★★★ ()
Последнее исправление: bvn13 (всего исправлений: 1)
Ответ на: комментарий от Deleted

Все не как у людей же. FHS не соблюдается, да даже libc не по стандартному пути

Значительная часть эксплоитов даже не заметит разницы, потому что, внезапно, направлена на ядро.

Deleted ()

Никак, хотя была машинка попой в наружу, но после выставления попы всё переводилось в RO и только 2 рабочих каталога были активными, это tmp с noexec и каталог с базой и всё. Вот и вся безопасность, а вся эта активная защита хтьфу. Если в софте есть дырка то она никуда не денется пока её не закрыть, поэтому запрещено всё что не разрешено. Но на домашней системе лично мне глубоко всрать =)

LINUX-ORG-RU ()
Ответ на: комментарий от linuxnewb13

Ну, я хз как там с динамикой у меня на KORE.io был сервер, всё было просто как палка =) Ну, а если ты ты генерируешь скрипты и потом исполняешь их думаю у тебя не 100500 скриптов генерятся поэтому можно на tmp оставить noexec сделать ещё одну tmpfs размером метров в 50 (хватит наверное под дин-скриптоту) всё генерированно-запускаемое скидывать туда (по факту просто в память) после исполнения удалять, и вообще принципиально удалять всё что там может появится кроме момента когда нужно исполнить что-то. Но меня не слушай это просто идеи. Я уж 100 лет ничего подобного не делал =)

LINUX-ORG-RU ()
Ответ на: комментарий от amd_amd

1. Сертификаты подгружаемые в ядро Линукс.

1. обнаружено 5 сертификатов

Это капец как настораживает!

В подавляющего большинства должен быть один единственный сертификат, УНИКАЛЬНЫЙ для каждой установки Линукс. Это сертификат с помощью которого ядро крыптограытчески верифтцирует свои модули. В ядре есть только открытый ключ этого сертификата необходимый для верификации модулей. Секретный ключ должен уничтожался сразу после выполнения 'make modules_install' или очень надёжно прятался (а зачем его прятать? кому он нужен кроме руткита?). Если руткит украдет секретный ключ сертификата то выполнит:

/usr/src/linux/scripts/sign-file sha512 /usr/src/linux/certs/signing_key.pem /usr/src/linux/certs/signing_key.x509 virus_rootkit.ko
И все, руткит подписан, а его установка и загрузка в ядро дело двух строк кода.

Зачем у арча аж 5 сертификатов в ядерном кейринге? Заметте каждый с этих сертификатов должен быть уникален для каждой установки арча!

У меня в самых продвинутых установках GNU/Linux используется только 4 сертификата, хоть теория рекомендует максимум 3:

1. Ядерный сертификат для автоматической подписи модулей ядра.

2. Мой личный корневой сертификат CA который гружу в ядерный кейринг и использую для подписи других сертифткатов.

3. Сертификат в кейринге IMA подписанный моим CA (его считают устаревшим) используется для верификации всех неизменяемых файлов (бинарей, библиотек, настроек) начиная с init.

4. Сертификат в кейринге EVM используется для защиты разных атрибутов файла в файловых системах Линукс (IMA, Linux capabiletis, selinux,...)

Посмотреть загруженные сертификаты иногда можно в:

cat /proc/keys

Ещё раз в каждой установки Линукс ВСЕ сертификаты ядра должны быть уникальны!!! Наличие хоть одного одинакового сертификата ядра в дистрибутиве неприемлемо! Товарищ майор подойдёт к разрабу с длинным, толстым и сильно горячим паяльником и попросит предоставить этот ключ ему!!!

anonymous ()
Ответ на: комментарий от amd_amd

2. Подписание модулей ядра Линукс

Если в настройках ядра указано:

CONFIG_MODULE_SIG_FORCE=y

или при загрузки указан параметр ядра:

module.sig_enforce=1

то ядро Линукс не должно грузить модули не подписанные каким небудь ключом с кейринга ядра.

modinfo имя_модуля

выводит информацию о наличии подписи, если она есть.

Для тестирования можно с одного ненужного модуля в /lib/modules/*/kernel/*/*.ko удалить цифровую подпись и попробовать его погрузить в ядро:

modprobe имя_модуля

rmmod имя_модуля

Подписанный модуль нормально загружаться и его видно в lsmod

Теперь удаляем подпись:

strip --strip-debug /lib/modules/*/kernel/*/*.ko

modprobe имя_модуля

Выдаст ошибку, что нужный ключ отсутствует.

anonymous ()

в самых продвинутых
используется только 4 сертификата

у меня в sid 4 сертификата - типа самый продвинутый?

cat /proc/keys

но загружено только 2

Товарищ майор

это вообще лажа - клал на этих товарищей с высокой колокольни

amd_amd ★★ ()
Ответ на: комментарий от amd_amd

3. Гарантировать надёжное уничтожение/хранение секретных ключей ядра Линукс.

3. нет такого файла или каталога

Он был создан и во время выполнения 'make modules_install' подписал все модули ядра. Вы должны гарантировать его надёжное уничтожение/хранение.

ls -l /usr/src/linux*/certs/signing_key.pem

find / -name signing_key.pem -type f

Вы должны гарантировать надёжное уничтожение/хранение ВСЕХ созданных секретных ключей ядра после подписания ими всех модулей ядра, программ, библиотек, настроек, файловых атрибутов!

Стырят у вас ключ, разрабы дистров передадут ключ товварищу майору и будут здесь рыдания по поводу руткита в GNU/Linux и плохих антивирусов.

PS: Если вас вся эта криптография уже достала можете скомпилировать монолитное ядро без протдержки модулей.

anonymous ()
Ответ на: комментарий от bvn13

Федорка ;)

Loaded X.509 cert 'Fedora kernel signing key: 7af26f362e0cda74a8cb6c31a1dc0c5ab045ce31'

Этот ключ должен создаватся при каждой инсталляции Fedora и быть уникальным для каждого компа с Fedora GNU/Linux.

Наличие единого секретного ключа в разработчиков дистра - дыра безопасности неприличного размера.

Дайте вывод «dmesg | grep -i 'x.*509'» с другой установки федорки. ;)

anonymous ()
Ответ на: комментарий от alexferman

Манджаро.

В Manjaro один такой

Один это нормально, главное чтобы он был уникален в каждой установки Manjaro GNU/Linux, а не как в федорке один на всех с копией секретного ключа в майора АНБ.

anonymous ()

разрабы дистров передадут ключ товарищу майору

разрабы sid передадут ключ товарищу майору?

ядро без протдержки модулей

это вообще отстой какой то...

послушай товарищ - ты сильно зациклен на товарищах майорах, расслабся!

amd_amd ★★ ()
Ответ на: Руткиты в дистрибутивах Линукс. от anonymous
desktop / # dmesg | grep -i 'x.*509'
desktop / # modinfo usbcore | grep '^sig'
modinfo: ERROR: Module usbcore not found.
desktop / # modinfo soundcore | grep '^sig'
desktop / # ls -l /usr/src/linux/certs/signing_key.pem
ls: cannot access '/usr/src/linux/certs/signing_key.pem': No such file or directory

Расскажите, что делать? Я готов на любые эксперименты.

 $ cat /proc/keys
0abcefaa I--Q---   262 perm 3f030000  1000  1000 keyring   _ses: 1
32323232 I--Q---     1 perm 1f3f0000  1000 65534 keyring   _uid.1000: empty
linuxnewb13 ()
Ответ на: комментарий от amd_amd

Дебиан.

у меня в sid 4 сертификата - типа самый продвинутый?

А цель этих сертификатов? Вы гарантирует что все эти сертификаты были созданы на вашем компе во время установки Debian GNU/Linux? Вы гарантирует надёжное уничтожение/хранение всех секретных ядерных сертификатов Линукс в дистрибутиве Дебиан?

Вот на вас всех уже ножи точят: out-of-tree v1.0.0 ― инструментарий для разработки и тестирования эксплоитов и модулей ядра Linux

anonymous ()
Ответ на: комментарий от amd_amd

Максимум угрозы - деанонимизация.

cat /proc/keys

dmesg | grep -i 'x.*509'

modinfo usbcore | grep '^sig'

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

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

В случае хорошего дистрибутива GNU/Linux, в котором все ядерные ключи уникальны для каждой его установки, отпечаток ключа может использоваться товарищем майором для вашей деанонимизации!!! Но в виду того что отпечатки может просмотреть только root риск не велик. В прочем нормальные дистры предоставляют инструментарий для замены ядерных ключей - переустановка системы. ;)

anonymous ()
Ответ на: комментарий от linuxnewb13

Расскажите, что делать? Я готов на любые эксперименты.

Я не знаю вашей квалификации.. С предоставленного вами вывода могу сказать, что в вашем дистрибутиве криптографическая верификация модулей ядра не используется.

Если желаете включить верификации модулей вам необходимо чуть перенастроить и пересобрать ядро Линукс, начни читать здесь: https://wiki.gentoo.org/wiki/Signed_kernel_module_support

Заметь это лишь один с многих путей защиты модулей ядра Линукс - самый простой, но далеко не полный. Он не защищает само ядро и инитрд.

Тебе надо отдельной технологией защитить все програмы, библиотеки, настройки.

Технологиями безопасной загрузки защитит ядро, инитрд и на конец сам загрузчик.

Можешь посмотреть по ссылкам:

Защита модулей, настроек GRUB, ядра и инитрд: https://www.gnu.org/software/grub/manual/grub/grub.html#Using-digital-signatures

Дополнительные опции защиты Линукс: https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Config...

IMA/EVM крыптографически верифицирует всего начиная с init, включая все подгружаемые модули ядра: https://sourceforge.net/p/linux-ima/wiki/Home/

Для начала поставь любую IDS и научись её правильно использовать.

anonymous ()
Ответ на: комментарий от linuxnewb13

Ну в смысле 1 ключ на всех.

Напиши в этой теме пост, в заголовке укажи название дистрибутива, а в тексте сообщения укажи что дистрибутив не использует никаких методов onaccess верификации модулей ядра Линукс при загрузке. Возможно предусмотрена IDS проверка по требованию.

anonymous ()
Ответ на: комментарий от bvn13

[ 6.535573] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 6.537466] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'

А зачем этот сертификат Фёдоре? Что за «regulatory database»? Посмотри, если разберёшся, оно наверно кроме модулей верифтцирует некоторые этапы загрузки. Интересно насколько продвинулись и какие технологии используют в Фёдоре?

anonymous ()