Предупреждение на AnyConnect за недоверен сървър: приемане или импортиране?

Поставяте името на хоста на шлюза в AnyConnect, прозорецът става червен или бял и диалог пита дали да се доверите на сървър, чийто сертификат клиентът не може да провери. Естественото движение е да кликнете и да продължите работа, а това е точно грешният рефлекс. Отговорът се записва в предпочитанията на клиента на тази машина и важи за следващи връзки, така че диалогът е решение за конфигурация, облечено като еднократно предупреждение. Ето какъв е редът, който следвам, в последователността, в която клиентът го показва.

Започнете от предупреждението, което наистина виждате

Червено и бяло не са козметични варианти. Червеното предупреждение означава, че профилът или предпочитанието е настроено да блокира недоверени сървъри, затова клиентът отказва да продължи, докато тази настройка не се промени; бялото предупреждение означава, че ще ви позволи да продължите, след като отговорите изрично. Трети случай изглежда подобно и се държи различно: изтекъл сертификат, който клиентът изобщо няма да предложи за импортиране, защото импортирането няма да го направи валиден. Различаването на трите отнема секунда и решава всичко следващо.

Зад всички тях стои един кратък списък причини: самоподписан сертификат на шлюза, частен CA, на който крайната точка не се доверява, или име на хост, което липсва в subject alternative names на сертификата. Всяка от трите дава същия диалог и изисква различно решение.

Прочетете сертификата, преди да отговорите на диалога

Отворете подробностите за сертификата от предупреждението и погледнете три полета, преди да пипнете бутон. Subject и SAN трябва да сочат шлюза, който наистина сте искали да достигнете, издателят трябва да е CA, който вашата организация управлява, а сроковете на валидност трябва да покриват днес. След това сравнете отпечатъка SHA-256 с копие, получено от друго място, не от тази връзка — вътрешна страница с документация или тикет, защото отпечатък, прочетен от същия диалог, не доказва абсолютно нищо. Ако не намерите независимо копие, нямате основание да приемете изключението.

Това е стъпката, която разделя лабораторията от продукционния шлюз. На тестова машина със самоподписан сертификат, генериран вчера, кликването е разумно. На корпоративен шлюз, където потребителите после въвеждат данни за вход, сертификат, който не можете да проверите, е вероятна схема за прихващане, а клиентът е единственият компонент, който още задава въпроса.

Знайте какво записва всеки отговор в хранилището за доверие

Отговорът да на въпроса за импортиране добавя сертификата на шлюза в довереното хранилище на клиента на тази машина. Това не е изключение за сесия: следващи връзки могат да завършат без същия въпрос, което е и целта, и рискът, защото нищо на екрана не напомня, че изключението съществува. Отговорът не продължава влизането само за тази сесия. И двата пътя ви свързват и само един от тях променя машината.

Ако сте на червения път, първият опит изобщо не е влизане. Документираната последователност на въвеждане е ред connect, последван от две потвърждения, които променят предпочитанието и излизат; скрипт, който приеме това за успех, е запазил настройка и никога не се е автентикирал. Въпросът за импортиране на сертификат се появява само при следващия опит, поради което хората заключават, че поканата е периодична.

Този ред е важен за автоматизацията, не само за пръстите. Скриптов отговор, който винаги казва да, продължава да работи след смяна на шлюза и продължава да се доверява на какъвто и сертификат да се появи след това.

Напишете отговорите в реда, в който клиентът пита

Когато клиентът предупреждава, но позволява връзката, отговорите идват в фиксиран ред: connect, да за продължаване, после въпросът за импортиране, после групата, потребителското име и паролата. Напишете ги като отделни редове във входния файл, вместо да гадаете времето на поканите. Отказът от импортиране е промяна на един знак в същия файл и е по-безопасната настройка по подразбиране за всичко, което работи без надзор.

connect vpn2.example.net
y
n
GROUP
LOGIN
PASSWORD

Предпочитайте разпространението на CA на организацията до крайните точки пред това да учите всеки скрипт да приема краен сертификат. Правилно издаден сертификат с правилния SAN премахва въпроса за всички, запазва смисъла на проверката и не зависи от паметта на една крайна точка за някое решение. Инсталирането на коренов CA е по-тежка промяна от импортирането на краен сертификат, затова го третирайте като управлявано внедряване, а не като бързо решение от помощното бюро.

Премахнете изключенията, които живеят по-дълго от шлюза си

AnyConnect пази тези предпочитания за всяка машина, затова стари отговори се натрупват на лаптопи, които са се местили между офиси. Прегледайте запазените предпочитания и импортираните сертификати на управляваните крайни точки и проверете дали изключение още сочи име на хост, което е сменило собственика си. Предпочитание, което приема всеки недоверен сървър, е по-широко от сертификата, за който е създадено.

Моделът, който си струва да се запази, е тесен: доверен сертификат за нормална употреба, документирана извънлентова проверка на отпечатък за временно изключение и посочен собственик, който го премахва, когато миграцията приключи. Ако откриете на машина, която управлявате, настройка, която приема всеки сървър, третирайте я като находка, а не като удобство.