ike-scan nesaņem atbildi no strādājošas IPsec vārtejas

Vārteja katru dienu apkalpo tālruņus un klēpjdatorus, tomēr ike-scan ziņo, ka neviens resursdators nav atbildējis. Šī izvade izskatās kā pierādījums tam, ka ierīcē nav IPsec. Parasti tas nozīmē, ka ierīce atmeta katru zondes priekšlikumu un izvēlējās neko neatbildēt. Klusums arī ir atbilde, un tā ir vismazāk informatīvā atbilde, ko rīks jums var sniegt.

Izskatiet trīs atsevišķus jautājumus: vai pakete ieradās, vai kāds priekšlikums saskanēja un vai kaut kas cits noraidīja partneri?

Solis 1: izlasiet priekšlikumu, ko rīks sūta

Galvenais režīms sākas ar SA lietderīgo slodzi, kurā uzskaitītas transformācijas, ko iniciators pieņems, un ike-scan aizpilda šo sarakstu no kompilētā noklusējuma. Noklusējuma kopa ir apzināti veca: DES un 3DES šifrēšanai, MD5 un SHA1 jaucēšanai, grupas 1 un 2 atslēgu apmaiņai, iepriekš koplietotas atslēgas autentifikācijai. Nav AES, nav SHA-2, nav grupas 14. Vārteja, kas konfigurēta ar AES-256, SHA-256 un modp2048, ar to neko nedala.

Dažas implementācijas uz nesaskanējušu zondi atbild ar NO-PROPOSAL-CHOSEN paziņojumu. Citas to vienkārši izmet, kas ir ierasti ierīcēs, kuras nezināmus partnerus uzskata par troksni. Jebkurā gadījumā skenēšana neko neizdrukā, un šis nekas ir identisks tam, kā no ārpuses izskatās filtrēts UDP 500, kā ike-scan projekta dokumentācija skaidri norāda par noklusējuma kopu.

Solis 2: piedāvājiet vienu modernu priekšlikumu

Aizstājiet noklusējuma kopu ar --trans. Atribūtu forma tieši ņem IKE atribūtu numurus: 1 šifrēšanai, 2 jaucēšanai, 3 autentifikācijai, 4 grupai un 14 atslēgas garumam, ja algoritms to ņem. Rezultāts ir rinda, ko varat skaļi nolasīt izmaiņu pārskatā.

Pozicionālā forma pārnēsā tās pašas vērtības secībā un izvairās no iekavām, kas ir svarīgi, kad komanda iet caur čaulu.

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

Viens priekšlikums uz paketi ir lēns, kad uzskaitāt, tāpēc atkārtojiet iespējamās vērtības: šifrēšana 5, 7/128, 7/192, 7/256; jaucēšana 1, 2, 5, 6, 7; grupas 1, 2, 5, 14, 15, 19, 20, 21; autentifikācija 1 iepriekš koplietotai atslēgai un 3 RSA parakstiem. Izdrukājiet katru komandu pirms tās izpildes, lai stenogramma parādītu, kas tika piedāvāts un kādā secībā.

Solis 3: interpretējiet atbildi

Atbilde pierāda tieši divas lietas: IKE atbildētājs ir sasniedzams šajā adresē un viens piedāvātais priekšlikums bija pieņemams. Tā neko nepasaka par iepriekš koplietoto atslēgu, L2TP slāni vai to, vai lietotāja konts pastāv. Veiksmīga skenēšana ir pilnībā savienojama ar visu turpmāko posmu neveiksmi.

Vārtējā, ko pārvaldāt, šī ir patiešām noderīgā daļa. Skenēšana parāda, kurus priekšlikumus ierīce joprojām pieņem, un rezultāts, kas ierobežots ar mantotajām transformācijām, ir atklājums par ierīces politiku, nevis iemesls vājināt klientu.

Solis 4: interpretējiet klusumu

Klusums ir vājāks pierādījums, nekā izskatās. Katrs priekšlikums var būt noraidīts, UDP 500 un 4500 var būt filtrēti, avots var būt ātruma ierobežots pēc uzliesmojuma, vai pakalpojums var klausīties citā adresē nekā tā, kuru skenējāt. Salīdziniet vārtejas IKE žurnālu ar klientu, kas jau savienojas ar derīgiem akreditācijas datiem, pirms izdarāt jebkādu secinājumu par šo kasti.

Uzliesmojuma uzvedība ietilpst šajā sarakstā, jo uzskaitīšana ģenerē daudz pakešu īsā laika logā. Vārteja, kas atbild uz pirmajiem mēģinājumiem un pēc tam apklust, apraksta savu anti-DoS politiku, nevis savu priekšlikumu kopu.

Solis 5: pierakstiet, ko pierādījāt

Pierakstiet pieņemto kombināciju blakus aparātprogrammatūras versijai, pēc tam salīdziniet to ar transformācijām, ko klienti, kas jums svarīgi, piedāvā pēc noklusējuma. Starpība starp šiem diviem sarakstiem ir konfigurācijas problēma, un skenēšana tikai padarīja to redzamu. Ja vienīgie pieņemtie priekšlikumi ir tādi, ko jūs neizvēlētos, labojums ir vārtejas politikā vai klienta profilā, nekad zondē.

Zonde, kas nekad neatbildēja, tomēr uz kaut ko atbildēja: tā parāda, kurus priekšlikumus šī ierīce ir gatava apspriest un kurus tā labprātāk nomestu uz grīdas.