Розмістіть VPN-шлюз поруч із Windows XP, а не всередині нього

Десь у будівлі стоїть машина, яка запускає застосунок, який ніхто не може замінити, на операційній системі, яку не можна ні до чого підключати. Вихід від мережевого адаптера цього хоста назовні — найшвидший спосіб побачити, де має бути тунель. У більшості проєктів він взагалі не належить хосту. Перенесіть його на один крок убік, на шлюз, що обслуговується, і стара проблема зменшиться назад до застосунку, з якого почалася.

Почніть з адаптера хоста, а не з VPN-клієнта

Відкрийте властивості адаптера і дайте хосту фіксовану адресу в невеликому виділеному сегменті, а шлюз зробіть його маршрутом за замовчуванням. Тоді хосту не потрібні ні клієнт тунелю, ні облікові дані тунелю, ні записи таблиці маршрутизації до ширшої корпоративної мережі. Якщо застосунку потрібна одна віддалена підмережа, додайте саме цей один маршрут.

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

Ця команда прив’язує єдиний пункт призначення до шлюзу і залишає все інше без маршруту, і це потрібна форма. Підтвердьте результат за допомогою route print, а не довіряючи коду виходу. Потім перевірте, чи застосунок досі розв’язує ім’я свого сервера, бо старий хост зі зламаним розв’язувачем виглядає точно як збій мережі, а виправлення розв’язувача — п’ятихвилинна робота, тоді як перезбирання застосунку після помилкової зміни мережі — ні. Кожен пункт призначення, до якого хост не дістає, — це на одну річ менше, яку можна вмовити старий мережевий стек атакувати.

Помістіть тунель на обладнання, яке можна оновлювати

Шлюзу потрібні два інтерфейси: один у бік сегмента хоста і один у бік місця, де живе застосунок, причому тунель завершується на другому. Цей пристрій може отримувати оновлення прошивки, замінювати свою криптографічну конфігурацію і вести журнал потоків, ніхто не чіпає стару машину. Його постачальник також випускає виправлення для реалізації тунелю, які хост ніколи не отримає. Дві машини і термін — не причина копіювати рецепт зі статичним секретом із повідомлення на форумі.

Дайте кожному шлюзу власну ідентичність вузла замість клонування однієї клієнтської конфігурації на весь парк. Коли пристрій замінюють, відкликайте стару ідентичність у той самий момент, коли вмикаєте нову, інакше залишаться дві некеровані копії, що автентифікуються в одній кінцевій точці. Зберігайте ключі там, де їх очікує площина керування шлюзу, ставтеся до резервної копії конфігурації як до секрету і перегляньте, хто може надсилати цю конфігурацію, бо тепер це визначає, куди може дістатися старий хост.

Дозволяйте послуги, а не мережі

Напишіть політику в термінах протоколу, порту й напрямку між двома підключеннями. Один дозволений порт до однієї адреси застосунку — звичайна відповідь, а адміністративний шлях через проміжний хост покриває решту.

Віддалене адміністрування старого хоста не повинно йти тим самим правилом, що й застосунок, і перевірка відмови така ж важлива, як написання правила. Надішліть один запит з хоста до пункту призначення, який має бути відхилено, і підтвердьте, що відмова походить із політики, а не з відсутнього маршруту. Записуйте дозволені потоки, поки проєкт новий, щоб бачити, що застосунок справді використовує, а не що стверджує його документація. Об’єднання двох підмереж тому, що посібник із мостом виглядав коротшим, — це спосіб, у який старий сегмент тихо стає плацдармом.

Не виставляйте старий слухач напряму в інтернет як обхідний шлях навколо шлюзу. Тримайте адміністративний шлях окремо від шляху застосунку, щоб компрометація одного не передавала інший. Правило, яке ніколи не виконується, — це правило, яке ніхто не перевірив, тому відхилений пункт призначення входить до приймального прогону.

Відновлення має працювати без тунелю

Вирішіть, хто оновлює й відновлює шлюз, до першого збою, і переконайтеся, що ця людина може дістатися до нього без тунелю, який він завершує. Доступ через консоль, локальний порт керування або позасмуговий шлях — усе це відповіді. Шлюз, який можна налаштувати лише через тунель, який він надає, — це пастка, що терпляче чекає на погане оновлення прошивки.

Напишіть інструкцію для збою, з яким ви справді зустрінетеся: тунель упав, шлюз мертвий, диск хоста зник. Тримайте образ відновлення хоста в межах будь-якої ще чинної угоди про підтримку і пам’ятайте, що відновлення повертає також стан програмного забезпечення й облікові дані в цьому образі. Спочатку відновіть на ізольованому сегменті, підтвердьте, що застосунок запускається, і лише потім підключайте щось знову; коли шлюз змінюється, оновіть інструкцію та інвентаризацію в тому самому сеансі.

Сертифікати, годинники та попередження про підпис

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

Не переводьте системний годинник назад і не вимикайте перевірки підпису, щоб запустити старий інсталятор. Отримайте авторизований артефакт у того, хто досі підтримує застосунок, і нехай вони скажуть, що приймає платформа. Публікації, які стверджують, що певна збірка була останньою для XP, сприймайте як історію, а не як мету встановлення, бо реальна вимога залежить від застосунку; якщо робота зі збереження справді потрібна, тримайте її на ізольованому сегменті далеко від виробничого доступу і документуйте, чому вона існує.