Как проверить состояние IPsec, не публикуя его ключи

Дамп состояния IPsec — не отчёт о состоянии, и именно такое к нему отношение приводит к тому, что ключевой материал попадает в публичный трекер проблем. Некоторые результаты проверки ядра содержат ключи трафика, которые использует ядро, а также адреса, селекторы и счётчики, действительно полезные. Безопасная привычка — сначала собрать сводку и обращаться к сырому состоянию только тогда, когда сводка не может ответить на вопрос. Если всё же нужно посмотреть сырое состояние, смотрите локально и делитесь чем-то более узким.

Проверка 1: может ли этот артефакт вообще покинуть машину

Файл конфигурации, закрытый ключ, неограниченный перехват пакетов и сырой дамп состояния — всё это секреты, пока не доказано обратное. Команда, печатающая ключи, не становится безопасной от того, что вы запустили её для диагностики.

Правило достаточно просто, чтобы сформулировать его одним предложением: делитесь наблюдением, которое отвечает на вопрос, а не состоянием машины, которое его породило.

Проверка 2: выбирайте команду сводки, а не дамп состояния

Для strongSwan swanctl --list-sas показывает сводку ассоциации: идентичности, установленные дочерние SA, состояния и счётчики. Ей не нужен сырой дамп ключей, и именно её вставляют в тикет первой. На стороне ядра iproute2 поддерживает ip xfrm state list nokeys в версиях, где этот параметр документирован, что скрывает ключевой материал, сохраняя поля ассоциации.

Подтвердите синтаксис в локальном руководстве, прежде чем полагаться на него: параметр есть не в каждом выпуске, а общий список состояния без него — другая команда с другим выводом. Запуск ip xfrm state на старой сборке, чтобы узнать, есть ли флаг, — ровно та ошибка, о которой этот чек-лист.

Проверка 3: записывайте только то, что нужно расследованию

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

Скрывайте по умолчанию и добавляйте обратно по запросу. Тот, кто читает ваш тикет, может попросить ещё одно поле; но он не может сделать вид, что не видел вставленный ключ.

Есть промежуточный путь, который стоит знать: сводка тоже может быть чувствительной. Идентичности, адреса партнёров и имена дочерних SA описывают вашу топологию, а в некоторых организациях это само по себе закрытая информация. Решите, кто аудитория, до того как вставлять, и предпочитайте канал с надлежащим контролем доступа публичной проблеме. Безопасная команда — не то же самое, что безопасное место назначения.

Проверка 4: сопоставьте одну попытку на обоих концах

Захватите клиента и шлюз для одной и той же попытки соединения в один и тот же момент и убедитесь, что описываемая ассоциация — именно та, которую породила эта попытка. Смешивание устаревшей дочерней SA из прошлой попытки со свежим снимком маршрутов даёт отчёт, внутренне согласованный и совершенно вводящий в заблуждение.

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

Проверка 5: что делать, если материал уже раскрыт

Удаление вложения не доказывает, что никто его не сохранил, а публичная вставка копируется быстро.

Считайте это инцидентом и используйте процедуру замены оператора: смените затронутые ключи или учётные данные, проверьте, не означает ли раскрытие более широкой компрометации, и следуйте применимому порядку уведомления. Техническая очистка — простая часть; допущение, что никто это не читал, — сложная.

Устойчивая практика — небольшой шаблон, который вы заполняете перед вставкой: какой конец, какой идентификатор ассоциации, какое направление, какой счётчик и что уже исключено. документация swanctl list-sas описывает поля сводки, и именно это нужно большинству тикетов. Всё остальное доступно по запросу тому, кому это нужно. Диагностический отчёт должен содержать доказательства, а не доступ.