Nessus през VPN: къде да стои скенерът преди първото сканиране
Фактът, че браузърът достига конзолата на Nessus, не доказва, че скенерът достига целта. Проверете местоположението на процеса, маршрута, обхвата и идентификационните данни преди стартиране.
Иконата на VPN до браузъра не казва нищо за процеса, който изпраща пакетите за сканиране. Ако конзолата и скенерът работят на различни хостове, тунелът на браузъра е един път, а източникът на сканирането е друг. Започнете от точката на изпълнение и след това вървете навън: маршрутът, оторизацията и идентификационните данни. Това разграничение е първият пункт в списъка не случайно.
Това е списък за проверки преди стартиране, а не урок по сканиране. Всяка стъпка дава факт, който можете да запишете в протокола на ангажимента, преди който и да е пакет да напусне скенера.
Проверка първа: намерете процеса, който изпраща сондите
Начертайте трите роли изрично: браузъра на лаптопа A, конзолата за сканиране на хост B и частната цел C. Ако на B работи и машината за сканиране, на браузъра му трябва само път до B. Ако работата я върши отделно устройство за сканиране, на това устройство му трябва път до C.
Browser on laptop A -> console on host B
Scanner process on B (or another appliance) -> private target C
Браузър, свързан към VPN, може да достига конзолата, докато скенерът зад него все още няма маршрут до C. Възможно е и обратното: скенерът е в частната мрежа, а конзолата е отдалечена. Разберете коя подредба всъщност използвате, преди да промените каквато и да е мрежова настройка. Назовете устройството в конфигурацията за сканиране, преди да обвините мрежата.
Ако скенерът работи на A, хостът на браузъра и скенерът споделят контекст, но само докато този процес запазва същото именно пространство и същата таблица за маршрутизация. Контейнер или служебен акаунт може да не наследява това, което вижда интерактивният браузър. Конзолата е интерфейс за управление, а не машината за сканиране.
Проверка втора: докажете маршрута и DNS на скенера
Изпълнете проверката на маршрута на хоста на скенера, а не на лаптопа. Попитайте ядрото кой интерфейс и кой шлюз би използвало за адреса на целта, след което повторете за името на хоста на целта. Маршрут, който съществува за IP, и име, което се разрешава до друг адрес, са две различни повреди.
Потвърдете адреса на източника, който ще се появи в целта. VPN клиент може да зададе адрес, различен от очаквания от защитната стена на целта, а NAT устройство може да го пренапише отново. Собственикът на целта се нуждае от наблюдавания източник, а не от адреса, отпечатан в профила на VPN.
Проверете и обратния път. Скенер, който достига целта, но не получава отговори, има проблем с маршрутизацията или защитната стена по обратния път, и това изглежда идентично с недостъпна цел.
Проверка трета: получете оторизация за обхвата и гледната точка
Накарайте собственика на целта писмено да назове системите, услугите, средата, източника и времевия прозорец. Решете каква гледна точка представлява оценката: външен VPN потребител, допуснат вътрешен клиент или конкретен сегмент на скенера.
Частният маршрут не е разрешение да тествате съседни мрежи. Дръжте списъка с цели тесен, избройте изключените системи и се договорете за условия за спиране и контакт, който може да спре изпълнението. Скенерът с удоволствие проверява всичко, до което достигне, и точно затова обхватът трябва да е изричен.
Запишете одобрения източник в същия документ. Ако наблюдаваният източник на скенера се различава от одобрения, изпълнението не представлява договорената гледна точка, дори когато списъкът с цели е правилен.
Проверка четвърта: съгласувайте идентификационните данни с дълбочината на оценката
Проверката за достижимост и оценката с удостоверяване са различни тестове. Отговор от порт доказва, че нещо е отговорило; той не доказва, че са изпълнени проверки с идентификационни данни или че приложението е оторизирало акаунта.
Използвайте отделни идентификационни данни само когато договореният обхват изисква проверки с удостоверяване. Потвърдете правата и политиката за заключване на акаунта и решете как ще се съхраняват и споделят констатациите, преди сканирането да ги създаде.
Ако идентификационните данни се провалят, не преминавайте тихо към изпълнение без удостоверяване и не назовавайте доклада планирана оценка. Резултатът е друг тест с друго значение и тази разлика принадлежи в доклада.
Проверка пета: запазете плана и след това стартирайте съзнателно
В работния процес за сканиране на Nessus изборът на шаблон, конфигурирането на настройките и запазването или стартирането на сканирането са отделни стъпки. Използвайте това разделение, за да прегледате списъка с цели, източника и графика, преди да започне какъвто и да е трафик.
Преди да разрешите стартирането, проверете кой източник допуска VPN, какъв трафик носи и как се възстановява след прекъснат тунел. Не разширявайте достъпа през защитната стена само защото предварителна връзка се е провалила; намерете слоя, който я е отказал, и поправете този слой.
След изпълнението запишете хоста на скенера, наблюдавания източник, списъка с цели и всички проверки, които не са могли да завършат. Доклад, изготвен от друг източник или без предвидените идентификационни данни, не представлява първоначалния план и да се каже това е част от резултата.
Оттеглете достъпа за ангажимента и обработвайте запазените резултати по договорения процес. Списъкът с проверки е завършен едва когато доказателствата отговарят на одобрения от вас път, а не когато сканирането просто е върнало резултати.