Недавно прочитал статью про настройку Fwknop.

Недавно прочитал статью про настройку Fwknop. Впервые услышал про этот инструмент, как и подход в целом, хотя он не нов. Идея в том, что вы отправляете специальный зашифрованный пакет с клиента на сервер, а сервер вам открывает доступ на подключение. Открытие доступа может выражаться в разных действиях, но в общем случае - это разрешающее правило на файрволе. Получается аналог port knocking, но принцип действия немного другой, со своими плюсами и минусами.

Сразу перечислю плюсы и минусы:

➕ Достаточно отправить только 1 пакет, что позволяет обойтись без лишней логики в настройках файрвола
➕ Отправка осуществляется с помощью программы-клиента, что позволяет унифицировать использование
➕ С точки зрения безопасности это лучше, чем набор случайных нешифрованных сетевых пакетов в обычном port knocking.
➖ Пакет для аутентификации может блокироваться в каких-то сетях, то есть это менее надёжно, чем набор стандартных icmp или tcp пакетов
➖ Для корректной работы криптографии не должно быть больших расхождений по времени между клиентом и сервером
➖ Для доступа к инфраструктуре надо устанавливать и настраивать клиента

Из описания сразу понятно, что это всё своего рода костылинг. Но в современных условиях это может быть очень актуально, так как никогда не знаешь, в какой момент тот или иной vpn заблокируют и придётся искать другие способы подключения к инфраструктуре. Архитектурно fwknop и port knocking выглядят очень просто и надёжно, пока не заходит речь о разделении доступа по пользователям. Это вносит существенные ограничения на применение такого подхода.

У меня есть виртуальная инфраструктура, закрытая шлюзом на Debian с Iptables. Я сразу на нём и проверил работу fwknop для проброса портов во внутреннюю инфраструктуру.

Ставим сервер и создаём ключи:

# apt install fwknop-server
# fwknopd --key-gen
KEY_BASE64: tTxUvTOxidZdK3tTkXbgk1T0fbMyR8=
HMAC_KEY_BASE64: 4qYZt6SX5yqiYRrHLMG0g2YwvQexYLA==

Рисуем конфиг доступа /etc/fwknop/access.conf:

SOURCE       ANY
KEY_BASE64     tTxUvTOxidZdK3tTkXbgk1T0fbMyR8=
HMAC_KEY_BASE64   4qYZt6SX5yqiYRrHLMG0g2YwvQexYLA==
HMAC_DIGEST_TYPE  sha256
CMD_CYCLE_TIMER  60
CMD_CYCLE_OPEN   /usr/sbin/iptables -t nat -A PREROUTING -p tcp --dport 8080 -i ens19 -s $PKT_SRC -j DNAT --to 10.100.1.250:8080
CMD_CYCLE_CLOSE  /usr/sbin/iptables -t nat -D PREROUTING -p tcp --dport 8080 -i ens19 -s $PKT_SRC -j DNAT --to 10.100.1.250:8080

Здесь я на 60 секунд создаю правило проброса портов с внешнего интерфейса на 10.100.1.250:8080. Для разных пользователей можно использовать разные ключи и действия со своими наборами правил.

Рисуем конфиг fwknopd.conf самой службы:

ENABLE_NFQ_CAPTURE     N;
NFQ_INTERFACE        ens19;
NFQ_PORT          62201;

Запускаем службу:

# systemctl start fwknop-server

Проверьте, что служба слушает порт udp 62201, и откройте к ней доступ на файрволе.

В качестве клиента я взял Fwknop-gui. Клиенты есть под разные системы, как с gui, так и без. Ему нужно передать ключи KEY_BASE64 и HMAC_KEY_BASE64. ☝️ Очень внимательно их копируйте и переносите. Я где-то хапнул лишний символ или пробел и очень долго разбирался, почему аутентификация не работает.

В виндовом клиенте rijndael key = KEY_BASE64, а HMAC_KEY имеет идентичное именование. Пример настроек на картинке ниже. У меня в итоге всё заработало с этими настройками, но не скажу, что настройка была простая. Примеров не так много, ИИ тоже слабо помог.

Разбирался сам с помощью статьи выше. Документацию тоже всю просмотрел, но там в основном интеграция с файрволом через свой скрипт управления правилами, что мне не подходит, поэтому я сами правила записал в выполнение команды. А вообще клиент сам может выполнять разные команды на сервере после прохождения аутентификации. То есть правила для файрвола можно и в клиенте прописать, но надо на сервере разрешить исполнение. Мне схема как у меня показалась наиболее простой и удобной.

#security #gateway