Как да проверите състоянието на 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 описва полетата на обобщението и точно това е нужно на повечето тикети. Всичко останало е достъпно при поискване за този, който има нужда. Диагностичният отчет трябва да съдържа доказателства, а не достъп.