Single Packet Authorization: port knocking с криптографией
Цикл «Не светим лишнего». Выпуск 7.
У классического knocking есть понятная проблема: секретная последовательность летит по сети открытым текстом. Кто увидел — тот может повторить.
Single Packet Authorization, или SPA, решает ту же задачу иначе. Клиент отправляет один специальный пакет, внутри которого находится криптографически защищённый запрос. Шлюз проверяет подлинность и только потом временно меняет firewall.
Что лежит в пакете
Конкретный формат зависит от реализации, но логика обычно включает:
- идентификатор клиента или ключа;
- временную метку;
- случайное значение, nonce;
- желаемый сервис или порт;
- шифрование и/или HMAC для проверки целостности и подлинности.
Сервер хранит сведения о недавно принятых пакетах и не принимает тот же запрос повторно. Поэтому просто записать трафик и воспроизвести вечером уже недостаточно.
Из известных open-source реализаций есть fwknop. Он описывает SPA-пакет как зашифрованный, неповторяемый и аутентифицированный HMAC. Скрытый SSH остаётся недоступным для обычного сканирования, пока сервер не принял корректный пакет.
Чем SPA лучше knocking
Здесь нет цепочки, которую можно случайно собрать сканированием портов. Подмена содержимого ломает проверку HMAC. Временная метка и защита от повторов уменьшают риск replay. В запрос можно аккуратно вложить параметры: какой сервис требуется и на какое разумное время.
При этом сам защищаемый сервис всё ещё не выставлен постоянно.
Цена удобства
На клиентской стороне нужна утилита, ключ и конфигурация. Для системного администратора это нормально. Для случайного подрядчика, который пришёл со смартфоном, — уже нет.
Ключи надо выдавать персонально, хранить, отзывать и менять. Если один общий ключ лежит в десяти скриптах, преимущества криптографии быстро заканчиваются.
Ещё один момент: SPA-сервер должен видеть пакет до обычного firewall drop. На Linux это понятная схема с fwknop и поддерживаемым firewall. На RouterOS готовая интеграция не такая прямая; обычно нужен внешний сервис, который проверит пакет и через API обновит MikroTik, либо SPA завершается на Linux-шлюзе.
Плюсы
- сервис скрыт до авторизации;
- один пакет вместо последовательности;
- криптографическая проверка;
- защита от простого повторного воспроизведения;
- возможность персональных ключей;
- удобно для скриптов и технических пользователей.
Минусы
- клиентское ПО или собственная утилита;
- управление ключами;
- более сложная диагностика;
- не очень подходит обычному офисному пользователю;
- интеграция с конкретным firewall может потребовать отдельного контроллера.
Где можно больно ошибиться
Один ключ для всех. Тогда невозможно понять, кто открыл доступ, и отозвать одного клиента.
Не проверять время и повторы. Подписанный, но бесконечно повторяемый пакет превращается в вечный ключ.
Открывать порт надолго. SPA подтверждает запрос в момент отправки, но не контролирует присутствие пользователя через два часа.
Хранить ключ прямо в публичном скрипте. Автоматизация должна использовать защищённое хранилище и минимальные права.
Считать источник индивидуальным после открытия. Сам SPA-пакет может быть персональным, но обычный последующий трафик firewall снова различает прежде всего по адресу. Общий NAT никуда не делся.
Когда SPA имеет смысл
Это хороший инструмент для администраторов, автоматизации и аварийного доступа, когда установка клиента допустима. Если основное требование — открыть браузер на любом компьютере и ничего не устанавливать, удобнее captive portal или TOTP-портал. К ним и переходим.