Как определить, который процессы используют сколько энтропии от/dev/urandom

В то время как не автоматизированный, Вы могли использовать инструмент как strace для наблюдения за чтениями от дескриптора (дескрипторов) файла, связанного с urandom. Затем посмотрите, сколько данных перечитано за определенный период времени для получения уровня чтения.

Есть несколько способов решения проблемы, если вы не знаете (или не подозреваете ), какой процесс может истощать энтропию _, доступную в Linux.

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

Вы можете использовать auditd для проверки того, какие процессы открыты /dev/random или /dev/urandom, но это не скажет вам, сколько данных считывается (, чтобы предотвратить проблемы с ведением журнала ). Вот некоторые команды, которые выводят список правил, а затем добавляют два наблюдения

auditctl -l
auditctl -w /dev/random
auditctl -w /dev/urandom
auditctl -l

Теперь подключитесь по SSH к ящику (или сделайте что-нибудь еще, что, как вы знаете, должно привести к открытию /dev/urandom или аналогичному, например dd ).

ausearch -ts недавние | аурепорт -ф

В моем случае я вижу примерно следующее:

[root@metrics-d02 vagrant]# ausearch -ts recent | aureport -f

File Report
===============================================
# date time file syscall success exe auid event
===============================================
1. 07/01/20 01:13:36 /dev/urandom 2 yes /usr/bin/dd 1000 6383
2. 07/01/20 01:16:43 /dev/urandom 2 yes /usr/sbin/sshd -1 6389
3. 07/01/20 01:16:43 /dev/urandom 2 yes /usr/sbin/sshd -1 6388
4. 07/01/20 01:16:43 /dev/urandom 2 yes /usr/sbin/sshd -1 6390
5. 07/01/20 01:16:44 /dev/urandom 2 yes /usr/sbin/sshd 1000 6408

Отключите эти часы

auditctl -W /dev/random
auditctl -W /dev/urandom

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

Тем не менее, я заметил (с помощью Prometheus и экспортера узлов _), что по-прежнему наблюдал пилообразный шаблон, в котором виртуальная машина (CentOS 7, не имеющая ничего для сбора энтропии ), сообщала об энтропии _. ] доступно повышение почти до 200 и после этого резко падает до 0.

Предлагает ли что-нибудь lsof (fuser, если вы предпочитаете )?

[root@metrics-d02 vagrant]# lsof /dev/random /dev/urandom
COMMAND  PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
chronyd 2184 chrony    3r   CHR    1,9      0t0 5339 /dev/urandom
tuned   2525   root    5r   CHR    1,9      0t0 5339 /dev/urandom

Обратите внимание на старший и младший номера символьного устройства; тестирование другим способом... (Я не уверен, что это будет полезно, просто думаю с точки зрения таких вещей, как Docker, который не работает на этой виртуальной машине)

[root@metrics-d02 vagrant]# ls -l /dev/*random
crw-rw-rw-. 1 root root 1, 8 Dec 19 01:24 /dev/random
crw-rw-rw-. 1 root root 1, 9 Dec 19 01:24 /dev/urandom

[root@metrics-d02 vagrant]# lsof | grep '1,[89]'
chronyd    2184           chrony    3r      CHR                1,9      0t0       5339 /dev/urandom
tuned      2525             root    5r      CHR                1,9      0t0       5339 /dev/urandom
gmain      2525  2714       root    5r      CHR                1,9      0t0       5339 /dev/urandom
tuned      2525  2715       root    5r      CHR                1,9      0t0       5339 /dev/urandom
tuned      2525  2717       root    5r      CHR                1,9      0t0       5339 /dev/urandom
tuned      2525  2754       root    5r      CHR                1,9      0t0       5339 /dev/urandom

Итак, у нас есть два процесса: chronyd и tuning. Используем strace. lsof сообщил нам, что хрони открыл /dev/urandom для чтения, используя файл -дескриптор 3

[root@metrics-d02 vagrant]# strace -p 2184 -f
strace: Process 2184 attached
select(6, [1 2 5], NULL, NULL, {98, 516224}
.... (I'm waiting)

Итак, хронид ждет какой-то активности,с тайм-аутом 98 секунд с момента запуска этого системного вызова.

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

Мы можем повторить и с Tuned... (на этот раз добавив несколько временных меток и фильтр grep только для файла -дескриптор 5 (вызовы read и т. д. будут иметь это в качестве первого аргумента)

[root@metrics-d02 vagrant]# strace -p 2525 -f -tt -T 2>&1 | grep '(5,'

У Red Hat есть блог, в котором обсуждается CSPRNG (Криптографически безопасный генератор псевдослучайных чисел). В нем обсуждаются некоторые другие способы, которыми процессы могут получить доступ к случайным числам :

• getrandom ()системный вызов < --рекомендуется для RHEL7.4+, высокое качество без блокировки после инициализации пула энтропии
• /dev/random < --легко заблокирует
• /dev/urandom < --проблема при использовании до инициализации пула. «никогда не блокирует»; должно быть тем, что должно использовать большинство приложений.
• AT _RANDOM < --устанавливает 16 случайных байтов один раз в execve -время

Хотя AT _RANDOM бесполезен, он присутствует для каждого процесса, поэтому сам процесс запуска процесса должен истощать хотя бы немного.

Теперь вы понимаете, что того, что я показал выше с помощью lsof, недостаточно, это не показывает использование getrandom (). Но так как getrandom ()является системным -вызовом, мы должны иметь возможность выявить его использование с помощью auditctl

[root@metrics-d02 vagrant]# auditctl -a exit,always -F arch=b64 -S getrandom
[root@metrics-d02 vagrant]# auditctl -l
-a always,exit -F arch=b64 -S getrandom
[root@metrics-d02 vagrant]# tail -F -n0 /var/log/audit/audit.log 
... (now we wait)

Мне стало скучно, и я подключился к ящику по ssh, и я увидел много интересных вещей, но не получил getrandom (), что не должно вызывать удивления, поскольку мы видели его с использованием /dev/urandom API. ранее.

Таким образом, пытаясь объяснить впадины на графике, ничего не открывается /dev/ *случайно,и ничто из того, что открыло его, в настоящее время не использует его, и ничто, похоже, не вызывает getrandom ()... Есть ли что-нибудь еще, что могло бы потреблять данные из [пула позади /dev/random]? Что с ядром? Рассмотрите такие функции, как рандомизация макета адресного пространства (ASLR ):

https://access.redhat.com/solutions/44460[требуется подписка]

[root@metrics-d02 vagrant]# cat /proc/sys/kernel/randomize_va_space 
2

«2» здесь означает, что в дополнение к рандомизации загрузки таких вещей, как mmap и стек (и т. д. ), он также включает рандомизацию кучи. Что произойдет, если мы отключим это

[root@metrics-d02 vagrant]# echo 0 > /proc/sys/kernel/randomize_va_space
[root@metrics-d02 vagrant]# cat /proc/sys/kernel/randomize_va_space 
0

(Ответ :то же самое... возможно, кто-то еще может проиллюстрировать это дальше)

Ядро также будет там, где установлено AT _RANDOM. Вот простой пример, который вы можете использовать, чтобы убедиться, что он не вызывает /dev/ *random или getrandom()

[vagrant@metrics-d02 ~]$ cat at_random.c 
#include <stdio.h>
#include <stdint.h>
#include <sys/auxv.h>

#define AT_RANDOM_LEN 16

int main(int argc, char *argv[])
{
    uintptr_t at_random;
    int i;

    at_random = getauxval(AT_RANDOM);

    for (i=0; i<AT_RANDOM_LEN; i++) {
        printf("%02x", ((uint8_t *)at_random)[i]);
    }
    printf("\n");

    /* show that it's a one-time thing */

    for (i=0; i<AT_RANDOM_LEN; i++) {
        printf("%02x", ((uint8_t *)at_random)[i]);
    }
    printf("\n");
}
[vagrant@metrics-d02 ~]$ make at_random
cc     at_random.c   -o at_random
[vagrant@metrics-d02 ~]$./at_random 
255f8d5711b9aecf9b5724aa53bc968b
255f8d5711b9aecf9b5724aa53bc968b
[vagrant@metrics-d02 ~]$./at_random 
ef4b25faf9f435b3a879a17d0f5c1a62
ef4b25faf9f435b3a879a17d0f5c1a62

Надеюсь, это будет полезно.

С практической точки зрения я бы сначала обратил внимание на рабочие нагрузки Java, так как именно здесь меня это больше всего раздражало. См.https://blogs.oracle.com/luzmestre/why-does-my-weblogic-server-takes-a-long-time-to-startдля примера.