Укрепване на VPN в Windows: поправете удостоверяването преди тунела

Вашият Windows VPN сървър иска потребителско име и парола и този единствен диалог скрива три несвързани задължения. Едно доказва кой е човекът, едно пази това доказателство да не бъде възпроизведено от някого, който наблюдава връзката, а едно решава до кои адреси той може да се докосне после. Повечето малки внедрявания първо укрепват тунела и оставят първите две задължения по подразбиране, което е грешният ред.

Работете в реда, в който работи нападателят. Първо идва това, което може да се прихване от мрежата. После това, което може да се възпроизведе по-късно с този запис. Накрая това, до което удостоверен нападател може да стигне, след като е вътре.

Три задължения, един диалогов прозорец

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

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

Разделете трите в бележките си, преди да докоснете настройка, после ги поправяйте от най-слабото звено нагоре.

Защо MS-CHAPv2 не издържа тест за възпроизвеждане

Ако сървърът все още приема PPTP с MS-CHAPv2, тунелът не защитава паролата в никакъв смислен смисъл. Предизвикателството и отговорът могат да бъдат прихванати и атакувани офлайн, а през 2012 година публична услуга за разбиване демонстрира възстановяване от такова ръкостискане за около ден при типична парола. По-дълга и по-сложна парола повишава цената; тя не премахва материала, който нападателят получава от мрежата.

Свойството, което искате, е идентификационни данни, които не могат да бъдат възпроизведени. EAP-TLS с клиентски сертификати дава на всяко устройство собствена идентичност и ви позволява да отмените точно едно устройство.

Внедряването на сертификати е истинска работа: частен CA, път за отмяна, който клиентите проверяват, и план за подновяване, който издържа на смяна на персонал. Третирайте тази работа като проекта, а не като пречка между вас и работещ тунел. Предвидете бюджет за нея, както бихте предвидели за подмяна на защитна стена. Споделената парола е по-евтина само до първата отмяна.

Предварително споделеният ключ удостоверява двойката, не човека

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

Всеки клиент в този профил споделя тайната, така че премахването на един човек означава преразпределянето ѝ към всички останали. Дръжте отделна стъпка за удостоверяване на потребител над тайната на ниво машина и преминавайте към сертификати с растежа на клиентите. Предварително споделен ключ в комбинация с MS-CHAPv2 са два слаби слоя и вторият обезсмисля първия.

Оторизацията принадлежи на Network Policy Server

NPS в Windows решава кой може да се свързва и го прави, след като удостоверяването вече е успяло. Това разделение е най-полезният контрол за укрепване в продукта и много внедрявания го оставят недокоснат.

Използвайте условия на политиката, които отразяват реални ограничения: членство в група, времевия прозорец, в който поддръжката е осигурена, и състоянието на устройството от проверка за здраве. Добавете втори фактор там, където данните оправдават триенето, и помнете, че политиката се оценява за всеки опит за свързване, което я прави жив контрол, а не документ.

Отчитането на RADIUS също ви дава един запис кой и кога се е свързал. Този журнал е разликата между преглед на инцидент и догадка и съществува независимо дали някой някога го чете.

Ограничете до какво може да стигне успешен вход

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

Нито един от двата избора не е настройка по подразбиране за сигурност. И двата трябва да бъдат записани до профила на защитната стена, който предполагат.

Проверете пътищата на отказ

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

После потвърдете кои портове са публикувани и защо. PPTP изисква TCP 1723 и GRE като IP протокол, а не порт, IKEv2 изисква UDP 500 и 4500, а L2TP изисква UDP 1701 плюс IPsec. Излагането на интерфейс за управление, за да се свърже клиент, не е ремонт, а втори инцидент, който чака да бъде открит.

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