Как я могу получить ключи шифрования для моего сеанса IPsec / L2TP? - PullRequest
Новая
       31

Как я могу получить ключи шифрования для моего сеанса IPsec / L2TP?

1 голос
/ 01 февраля 2020

Я изучаю стек протоколов IPse c с помощью wireshark. Если мне нужно расшифровать туннельный трафик c, я использую команду ip xfrm state, которая возвращает все необходимые данные. Во время исследования исходного кода ip я обнаружил, что ключи шифрования извлекаются из ядра через NETLINK. Итак, мне было интересно, есть ли другой способ получить эту информацию из ядра в обход NETLINK? Возможно, есть некоторые ioctl, чтобы сделать это. Я хотел бы знать, где в коде ядра хранятся эти ключи.

1 Ответ

0 голосов
/ 20 марта 2020

Два основных интерфейса, о которых я знаю, это:

  • netlink (о котором вы уже упоминали) - опция linux - родная, начиная с ~ 2.6, включена через конфигурационную опцию ядра XFRM_USER
  • pfkey (для совместимости с инструментами, портированными из KAME) - включен с помощью опции конфигурации ядра NET_KEY

См. здесь для получения справочной информации о них.

С точки зрения пользовательских инструментов, насколько я понял, инструмент iproute2 "ip" и его подкоманда "xfrm" являются более новым / лучшим способом для ручного манипулирования ipse c SAD и SPD на * 1026. * как тонкий слой через интерфейс netlink к модулю xfrm, в то время как инструмент «setkey» использует интерфейс pfkey (к тому же модулю) для совместимости (и в других системах, таких как BSD). Я думаю, что на самом деле (или очень редко?) На linux не будет необходимости использовать интерфейс pfkey, если вы уже можете общаться через интерфейс netlink, кроме как для совместимости с существующим кодом.

Вот некоторые примеры ( 1 , 2 ) разработчиков, взаимодействующих по поводу обработки связи с обоими интерфейсами (по моему опыту они, как известно, плохо, а иногда просто нет, документированы - и мне пришлось поработать несколько раз, прочитав источник модулей xfrm несколько раз).

Единственный другой способ взаимодействия с модулем xfrm - чтение данных из / proc / net / xfrm_ * files (в зависимости от версии и конфигурации ядра, которые могут присутствовать или не присутствовать), перехватывая его с помощью ftrace / kprobes / et c или написав свой собственный модуль ядра для непосредственного взаимодействия со структурами xfrm напрямую. Я подозреваю, что последний вариант почти всегда плохая идея.

...