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 дневник гејтвеја са клијентом који се већ повезује са важећим акредитивима пре него што закључите било шта о кутији.

Понашање при рафалу припада том списку јер набрајање ствара много пакета у кратком прозору. Гејтвеј који одговара на прве покушаје и затим утихне описује своју anti-DoS политику, а не свој скуп предлога.

Корак 5: запишите шта сте доказали

Запишите прихваћену комбинацију поред верзије фирмвера, па је упоредите са трансформацијама које клијенти који су вам важни нуде подразумевано. Јаз између те две листе је проблем конфигурације, а скенирање га је само учинило видљивим. Ако су једини прихваћени предлози они које не бисте изабрали, исправка припада политици гејтвеја или профилу клијента, никада проби.

Проба која никада није одговорила ипак је нешто одговорила: показује које је предлоге овај уређај спреман да размотри и које би радије пустио да падну на под.