ike-scan не атрымлівае адказу ад працуючага шлюза IPsec

Шлюз штодня абслугоўвае тэлефоны і ноўтбукі, але ike-scan паведамляе, што ніводны хост не адказаў. Гэты вывад выглядае як доказ таго, што IPsec на прыладзе няма. Звычайна гэта азначае, што прылада адхіліла кожную прапанову ў зондзе і выбрала не адказваць нічога. Маўчанне — гэта адказ, і ён найменш інфарматыўны з тых, што інструмент можа даць.

Разбярыцеся з трыма асобнымі пытаннямі: ці дайшоў пакет, ці супала якая-небудзь прапанова і ці не адхіліў партнёра штосьці іншае?

Крок 1: прачытайце прапанову, якую дасылае інструмент

Асноўны рэжым пачынаецца з карыснай нагрузкі SA, якая пералічвае пераўтварэнні, якія прыме ініцыятар, і ike-scan запаўняе гэты спіс са сціснутага стандарту. Стандартны набор наўмысна стары: DES і 3DES для шыфравання, MD5 і SHA1 для хэшавання, групы 1 і 2 для абмену ключамі, загадзя агульныя ключы для аўтэнтыфікацыі. Ніякага AES, ніякага SHA-2, ніякай групы 14. Шлюз, наладжаны на AES-256 з SHA-256 і modp2048, не мае з ім нічога агульнага.

Некаторыя рэалізацыі адказваюць на неадпаведны зонд апавяшчэннем NO-PROPOSAL-CHOSEN. Іншыя проста скідаюць яго, што звычайна для прылад, якія ўспрымаюць невядомых партнёраў як шум. Так ці інакш скан нічога не друкуе, і гэтае нішто цалкам тоеснае таму, як выглядае фільтраваны UDP 500 звонку, як дакументацыя праекта ike-scan ясна кажа пра стандартны набор.

Крок 2: прапануйце адну сучасную прапанову

Замяніце стандартны набор на --trans. Форма атрыбутаў бярэ нумары атрыбутаў IKE напрамую: 1 для шыфравання, 2 для хэша, 3 для аўтэнтыфікацыі, 4 для групы і 14 для даўжыні ключа, калі алгарытм яе прымае. На выхадзе — радок, які можна прачытаць уголас на разглядзе змен.

Пазыцыйная форма нясе тыя ж значэнні па парадку і пазбягае дужак, што важна, калі каманда ідзе праз абалонку.

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

Адна прапанова на пакет — гэта павольна пры пералічэнні, таму перабярыце праўдападобныя значэнні: шыфраванне 5, 7/128, 7/192, 7/256; хэш 1, 2, 5, 6, 7; групы 1, 2, 5, 14, 15, 19, 20, 21; аўтэнтыфікацыя 1 для загадзя агульнага ключа і 3 для подпісаў RSA. Друкуйце кожную каманду перад запускам, каб пратакол паказваў, што прапанавалася і ў якім парадку.

Крок 3: тлумачце адказ

Адказ даказвае роўна дзве рэчы: IKE-адказнік дасяжны на гэтым адрасе і адна з прапаноў была прымальнай. Ён нічога не кажа пра загадзя агульны ключ, слой L2TP або пра тое, ці існуе ўліковы запіс карыстальніка. Паспяховы скан цалкам сумяшчальны з правалам кожнага наступнага этапу.

На шлюзе, які вы абслугоўваеце, гэта сапраўды карысная частка. Скан кажа, якія прапановы прылада яшчэ прымае, а вынік, абмежаваны састарэлымі пераўтварэннямі, — гэта знаходка пра палітыку прылады, а не прычына паслабляць кліент.

Крок 4: тлумачце маўчанне

Маўчанне — больш слабы доказ, чым выглядае. Кожная прапанова магла быць адхілена, UDP 500 і 4500 маглі быць адфільтраваны, крыніца магла атрымаць абмежаванне хуткасці пасля ўсплёску, або служба можа слухаць на іншым адрасе, чым той, які вы сканавалі. Параўнайце журнал IKE шлюза з кліентам, які ўжо падключаецца з сапраўднымі ўліковымі данымі, перш чым рабіць высновы пра скрыню.

Паводзіны пры ўсплёсках належыць да гэтага спісу, бо пералічэнне стварае шмат пакетаў за кароткі час. Шлюз, які адказвае на першыя спробы, а потым змаўкае, апісвае сваю палітыку процідзеяння DoS, а не набор прапаноў.

Крок 5: запішыце, што вы даказалі

Запішыце прынятую камбінацыю побач з версіяй прашыўкі, потым параўнайце яе з пераўтварэннямі, якія кліенты, што вас цікавяць, прапануюць па змаўчанні. Разрыў паміж гэтымі двума спісамі — гэта праблема канфігурацыі, і скан толькі зрабіў яе бачнай. Калі адзіныя прынятыя прапановы — тыя, якія вы б не выбралі, выпраўленне належыць палітыцы шлюза або профілю кліента, але ніколі зонду.

Зонд, які ніколі не адказаў, усё ж нешта адказаў: ён паказвае, якія прапановы гэтая прылада гатова абмяркоўваць, а якія валне кінуць на падлогу.