Оттегляне на PPTP/MS-CHAPv2: наръчник за остарял VPN
По-дълга парола не прави PPTP с MS-CHAPv2 по-добър. Изпълнете стъпките за инвентаризация, миграция, проверка и изчистване на идентификационните данни по ред.
Пароли от двадесет знака, сменяни всеки месец и пазени в трезор, не превръщат PPTP сървър с MS-CHAPv2 в модерен VPN. Паролата е вход към обмен, чиято слабост живее в самия обмен. Този наръчник е за онзи, който е наследил този сървър и трябва да премести потребителите от него, без да отреже сайта, който зависи от него. Изпълнявайте стъпките по ред, защото всяка оставя запис, който ще ви трябва, когато някой попита защо достъпът изведнъж се е променил.
Запишете стека, преди да пипате нещо
Три слоя се сгъват в думата PPTP и всеки се проваля по свой начин. Тунелът е самият PPTP, тоест GRE плюс TCP 1723. Удостоверяването е онзи PPP метод, който сървърът предлага, тук MS-CHAPv2. Защитата на връзката е MPPE, чиито ключове се извличат от този обмен на удостоверяване. Назоваването и на трите пречи на по-късна поправка да попадне на грешния слой.
Четете живата конфигурация, вместо да вярвате на уики страница, и запишете файла, слушателя и последните сесии, които са се удостоверили.
grep -RniE 'mschap|mppe|require-mppe' /etc/ppp/options.pptpd /etc/pptpd.conf
ss -lntp 'sport = :1723'
journalctl -u pptpd -n 40 --no-pager
При роля за отдалечен достъп в Windows същата инвентаризация идва от две команди и втората е важна, защото ролята може да обявява няколко метода едновременно, докато клиентите на терен договарят само най-слабия.
Get-VpnAuthProtocol
netstat -ano | findstr :1723
Решете какво всъщност пренася тунелът днес
Избройте потребителите, преди да изберете замяна: преносими компютри в движение, маршрутизатор на клон, платежен терминал, набор полеви таблети. Потребител, който трябва да достигне само един вътрешен хост, се мести лесно. Потребител, вграден в хардуер, който не можете да презапишете, може да се нуждае от междинен шлюз вместо ъпгрейд на клиента и това решение принадлежи в плана, а не в средата на прехода.
После попитайте какво ще получи нападател, който може да наблюдава или влияе на обмена при вход. При MS-CHAPv2 отговорът включва материал, който позволява офлайн възстановяване на паролата на потребителя и точно затова дължината и ротацията не поправят дизайна: възстановената тайна е валидна във всяка система, където потребителят я е използвал повторно.
MPPE наследява същата слабост, защото ключовете ѝ идват от този обмен, и не ви дава целостта на всеки пакет и поведението при повторение на модерен AEAD шифър. Сесия, която се удостоверява чисто, е доказала съвместимост с конфигурираните проверки и нищо повече.
Нито кратката обедна почивка, нито малкият брой потребители превръщат криптографско свойство в политическо.
Извършете миграцията в един прозорец за поддръжка
Вдигнете замяната, докажете я с една пилотна група, после спрете стария слушател, вместо да го оставите като тих резервен вариант. Резерв, до който всеки още може да стигне, не е миграция и държи слабия обмен достъпен точно за потребителите, които никога не си правят труда да преминат.
sudo systemctl disable --now pptpd
sudo ss -lntp | grep -E ':(1723|1194|51820)\b'
sudo nft list ruleset | grep -i gre
Затворете пътя през защитната стена в същия прозорец. GRE няма порт, който да се помни, затова правило, което разрешава протокол 47 по номер, лесно се пропуска и оставя услугата достъпна дори след като демонът е изчезнал. Запишете премахнатото правило, предишната му позиция и причината, за да не го възстанови по-късен преглед на промените по случайност.
Работете с идентификационните данни отделно от конфигурацията. Премахването на клиентски профил не е отнемане и акаунт, който още се удостоверява другаде, не е изведен от употреба.
Проверете дали замяната върши работата на PPTP
Контролният списък не е „свързва ли се“. А дали удостоверяването, назначаването на адреси, разрешаването на DNS, изборът на маршрут, поведението при повторно свързване и проверката на партньора все още се държат под замяната. Тествайте всяко на пилотно устройство, в този ред, и запишете наблюдавания резултат до очакването.
ip -4 addr show tun0
ip route get 198.51.100.23
resolvectl query intranet.example.net
Адрес на интерфейса доказва, че договарянето е завършило. Той не доказва, че далечната страна е разрешила маршрута, който очаквате, а справката по-горе отговаря само за този хост, не за препратен LAN. Отговорът на резолвер доказва достъпност на резолвер, не че политиката за разделен DNS изпраща правилните имена към него.
Проверете повторното свързване последно, защото там повечето замени регресират: приспите лаптоп, сменете мрежи и потвърдете, че тунелът се възстановява, без да оставя застояли маршрути.
Откат, отнемане и записът, който оставяте
Откатът възстановява услуга; той не възстановява сигурност и разликата трябва да се каже на глас, преди прозорецът да се отвори. Ако новият път се провали, върнете потребителите през втора модерна крайна точка или временен шлюз, а не чрез повторно включване на PPTP за всички. Задържането на един авариен път по стария протокол разширява излагането, което току-що документирахте.
След прехода отнемете акаунтите, които са се удостоверявали през PPTP, оставете запазените им профили да изтекат и потвърдете, че правилото за GRE е изчезнало от всяко крайно устройство, включително копието за аварийно възстановяване, което никой не помни.
Оставете кратък запис: протоколите, които намерихте, датата, на която всеки слушател е спрял, поддържаните от замяната версии на клиента и собственика, който може да отвори решението отново. Хигиената на паролите след това още има значение, но като хигиена на протокол, който я заслужава, а не като аргумент старият да остане жив.