mrash/fwknopОдиночная авторизация пакета > Port Knocking
fwknop реализует схему авторизации, известную как Single Packet Authorization (SPA) (авторизация одиночным пакетом), для надежного сокрытия сервисов. SPA требует только один пакет, который шифруется, невоспроизводим и аутентифицируется с помощью HMAC, чтобы сообщить о желаемом доступе к сервису, который скрыт за межсетевым экраном в режиме фильтрации с запретом по умолчанию. Основное применение SPA — использовать межсетевой экран для отклонения всех попыток подключения к сервисам, таким как SSH, чтобы затруднить эксплуатацию уязвимостей (как zero-day, так и неисправленных). Поскольку открытых портов нет, любой сервис, скрытый с помощью SPA, естественно, не может быть просканирован с помощью Nmap. Проект fwknop поддерживает четыре различных межсетевых экрана: iptables, firewalld, PF и ipfw на Linux, OpenBSD, FreeBSD и Mac OS X. Также есть поддержка пользовательских скриптов, чтобы fwknop можно было адаптировать для поддержки другой инфраструктуры, такой как ipset или nftables.
SPA, по сути, является следующим поколением Port Knocking (PK) (стука портов), но устраняет многие ограничения, присущие PK, сохраняя его основные преимущества. Ограничения PK включают общую сложность защиты от атак повторного воспроизведения, невозможность надежной поддержки асимметричных шифров и схем HMAC, а также тривиальную возможность проведения DoS-атаки на сервер PK путем подделки дополнительного пакета в последовательность PK при его передаче по сети (тем самым убеждая сервер PK, что клиент не знает правильной последовательности). Все эти недостатки решаются с помощью SPA. В то же время SPA скрывает сервисы за политикой межсетевого экрана с запретом по умолчанию, пассивно получает данные SPA (обычно через libpcap или другими средствами) и реализует стандартные криптографические операции для аутентификации и шифрования/дешифрования пакетов SPA.
Пакеты SPA, генерируемые fwknop, используют HMAC для аутентифицированного шифрования в модели «сначала шифрование, затем аутентификация». Хотя использование HMAC в настоящее время является необязательным (включается с помощью параметра командной строки --use-hmac), настоятельно рекомендуется по трем причинам:
Последняя причина выше объясняет, почему HMAC все равно следует использовать, даже когда пакеты SPA шифруются с помощью GnuPG, из-за того, что данные SPA не передаются через функции libgpgme, если только HMAC не будет сначала проверен. GnuPG и libgpgme являются относительно сложными программными кодами, и поэтому ограничение возможности потенциального злоумышленника взаимодействовать с этим кодом через операцию HMAC помогает поддерживать более высокий уровень безопасности. Генерация HMAC для связи SPA требует выделенного ключа в дополнение к обычному ключу шифрования, и оба могут быть сгенерированы с помощью опции --key-gen.
fwknop шифрует пакеты SPA либо с помощью блочного шифра Rijndael, либо с помощью GnuPG и связанного с ним асимметричного шифра. Если выбран метод симметричного шифрования, то, как обычно, ключ шифрования является общим для клиента и сервера (подробности см. в файле /etc/fwknop/access.conf). Фактический ключ шифрования, используемый для шифрования Rijndael, генерируется с помощью стандартного алгоритма вывода ключа PBKDF1, и устанавливается режим CBC. Если выбран метод GnuPG, то ключи шифрования извлекаются из связок ключей GnuPG.
Люди, использующие Single Packet Authorization (SPA) или его менее безопасного родственника Port Knocking (PK), обычно обращаются к SSHD, работающему на той же системе, где развернуто программное обеспечение SPA/PK. То есть межсетевой экран, работающий на хосте, имеет политику запрета по умолчанию для всех входящих SSH-соединений, чтобы SSHD нельзя было просканировать, но демон SPA перенастраивает межсетевой экран для временного предоставления доступа пассивно аутентифицированному клиенту SPA:
"Базовое использование SPA для доступа к SSHD"
fwknop поддерживает вышесказанное, но идет гораздо дальше и активно использует NAT (для межсетевых экранов iptables/firewalld). В конце концов, важные межсетевые экраны обычно являются шлюзами между сетями, а не просто развертываются на отдельных хостах. NAT обычно используется на таких межсетевых экранах (по крайней мере, для связи по IPv4) для предоставления доступа в Интернет внутренним сетям, находящимся в адресном пространстве RFC 1918, а также для разрешения внешним хостам доступа к сервисам, размещенным на внутренних системах.
Поскольку fwknop интегрируется с NAT, SPA может использоваться для доступа к внутренним сервисам через межсетевой экран пользователями из внешнего Интернета. Хотя это имеет множество применений в современных традиционных сетях, это также позволяет fwknop поддерживать облачные среды, такие как Amazon AWS:
"Использование SPA в облачных средах Amazon AWS"
Официальный кроссплатформенный пользовательский интерфейс клиента fwknop fwknop-gui (скачать, github) разработан Джонатаном Беннеттом. Поддерживаются большинство основных клиентских режимов SPA, включая запросы NAT, ключи HMAC и Rijndael (GnuPG пока не поддерживается), сохранение секций fwknoprc и многое другое. В настоящее время fwknop-gui работает на Linux, Mac OS X и Windows — вот скриншот из OS X:
"fwknop-gui на Mac OS X"
Аналогично обновленный клиент для Android также доступен.
Подробное руководство по fwknop можно найти здесь:
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html
Ниже приведен полный список функций, поддерживаемых проектом fwknop:
tcpdump -w <файл>), из средства записи pcap ULOG в iptables или напрямую через UDP-сокет в режиме --udp-server.Проект fwknop выпускается как программное обеспечение с открытым исходным кодом на условиях GNU General Public License (GPL v2) или (по вашему выбору) любой более поздней версии. Последний выпуск можно найти на http://www.cipherdyne.org/fwknop/
Этот файл README описывает текущее состояние проекта fwknop по состоянию на выпуск версии 2.5 в июле 2013 года. В настоящее время у нас есть реализация библиотеки Firewall Knock Operator; libfko, а также клиентские и серверные приложения fwknop. Библиотека предоставляет API и внутреннюю функциональность для управления данными Single Packet Authorization (SPA), которые используются другими компонентами fwknop. Она также может использоваться другими программами, которым требуется функциональность SPA (см. каталог perl для примера модуля FKO для perl, а также в каталоге python есть привязки для python).
Если вы обновляетесь с более старой версии fwknop (включая исходную реализацию на perl), вам следует прочитать следующую ссылку, чтобы обеспечить плавный переход на fwknop-2.5 или более позднюю версию:
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#backwards-compatibility
Этот дистрибутив использует GNU autoconf для настройки сборки. Пожалуйста, обратитесь к файлу INSTALL для получения основных сведений об использовании autoconf.
Существуют некоторые параметры «configure», специфичные для fwknop. Они приведены ниже (взято из ./configure --help):
--disable-client Не собирать клиентский компонент fwknop. По умолчанию клиент собирается.
--disable-server Не собирать серверный компонент fwknop. По умолчанию сервер собирается.
--with-gpgme поддержка шифрования gpg с использованием libgpgme [по умолчанию=check]
--with-gpgme-prefix=PFX префикс, где установлен GPGME (необязательно)
--with-gpg=/путь/к/gpg Укажите путь к исполняемому файлу gpg, который будет использовать gpgme [по умолчанию=check path]
--with-firewalld=/путь/к/firewalld Укажите путь к исполняемому файлу firewalld [по умолчанию=check path]
--with-iptables=/путь/к/iptables Укажите путь к исполняемому файлу iptables [по умолчанию=check path]
--with-ipfw=/путь/к/ipfw Укажите путь к исполняемому файлу ipfw [по умолчанию=check path]
--with-pf=/путь/к/pfctl Укажите путь к исполняемому файлу pf [по умолчанию=check path]
--with-ipf=/путь/к/ipf Укажите путь к исполняемому файлу ipf [по умолчанию=check path]
Examples:
./configure --disable-client --with-firewalld=/bin/firewall-cmd
./configure --disable-client --with-iptables=/sbin/iptables --with-firewalld=no
Для тех, кто в настоящее время использует Perl-версию и планирует перейти на эту версию, следует учитывать некоторые моменты:
Не все функции и возможности fwknop на основе Perl были перенесены в эту реализацию. Мы решили, что важно сохранить версию на C как можно более компактной и легковесной. Большинство пропущенных функций (например, оповещения по электронной почте) могут быть реализованы другими способами (т.е. с помощью внешнего скрипта для мониторинга файлов журнала и оповещения на основе соответствующих сообщений журнала).
Существуют некоторые различия в директивах и значениях файлов конфигурации и доступа fwknop. Некоторые из них довольно тонкие. Следует внимательно изучить документацию и комментарии в этих файлах.
Если вы получаете этот дистрибутив из git, вам следует запустить скрипт autogen.sh для генерации файлов autoconf. Если вы получаете ошибки об отсутствующих каталогах или файлах, попробуйте запустить autogen.sh снова. После этого вы можете запустить autoreconf -i, когда захотите перегенерировать конфигурацию. Если по какой-то причине autoreconf не работает, скрипта autogen.sh должно быть достаточно.
Исходные файлы nroff для man-страниц fwknop и fwknopd включены в соответствующие каталоги (client и server). Эти файлы nroff получены из исходных файлов AsciiDoc в каталоге 'docs'. Подробности см. в README в каталоге docs.