Защита вашей беспроводной сети с помощью authpf

          Специалисты  в  области  безопасности  сходятся  во  мнении,  что  даже  если  WEP  и предлагает слабую защиту, этого вполне достаточно, чтобы предупредить атакующих, что вы не намерены отдавать кому бы то нибыло  свои сетевые ресурсы. Использование стандарта   WPA   в   некоторой   степени   повышает   уровень   безопасности,   за   счёт незначительного усложнения конфигурации. Конфигурации которые мы построили ранее являются   вполне   функциональными.  Обе   конфигурации   WEP   и   WPA,   позволяют подключать любых разумно сконфигурированных клиентов, что  может стать проблемой, поскольку   конфигурация   не   имеет   возможности   контролировать   разрешения   на

использования вашей сети.

Как упоминалось ранее, фильтрация MAC адресов, на самом деле, не даёт  требуемого уровня защиты, поскольку можно, достаточно просто, изменить MAC адрес. Разработчики

OpenBSD решили использовать радикально иной подход к этой проблеме, введя authpf в

OpenBSD 3.1. Вместо того, чтобы привязать идентификацию к оборудованию  сетевого адаптера, например к MAC адресу карты, они решили расположить  надёжные и гибкие механизмы аутентификации пользователя в месте, более  подходящем для этой цели. Пользовательская  оболочка  authpf   позволяет   привязать  загружаемые  правила  PF базируясь на пользователе, эффективно решая задачу раздачи прав пользователям.

Для использования authpf, вы создаёте пользователя с оболочкой authpf. В  процессе получения доступа к сети, пользователи регистрируются на шлюзе с использованием SSH. Как только пользователь успешно завершает SSH аутентификацию, загружаются которые вы  определили  для  пользователя  или  соответствующего  класса  пользователей.  Эти правила, которые применяются  к IP адресу пользователя, действуют до тех пор пока пользователь остаёстя  связанным с системой через SSH соединение. После завершения SSH сессии, правила выгружаются, и в большинстве случаев, весь не SSH трафик от IP адреса пользователя запрещается. При разумных настройках, будет  проходить  только трафик авторизованных пользователей.

Примечание

В OpenBSD, authpf – один из классов логинов предлагаемых по умолчанию, и вы можете это заметить когда будеде создавать пользователя используя команду adduser.

Для систем, в которых класс authpf не доступен по умолчанию, может быть необходимым добавление некоторых строк в файл /etc/login.conf:

authpf:\

:welcome=/etc/motd.authpf:\

:shell=/usr/sbin/authpf:\

:tc=default:

Несколько  следующих  разделов  содержат  примеры,  которые  могут  (или  не  могут) соответствовать вашей  ситуации,  но  я  надеюсь,  что  они  дадут  вам  некоторые  идеи которые вы сможете использовать.

Базовая аутентификация шлюза                                            Настройка  аутентификации шлюза с  authpf включает в  себя  создание  и  поддержку нескольких  дополнительных  файлов,  помимо  вашего  основного  файла  конфигурации pf.conf. Основное дополниние – файл authpf.rules. Все  прочие файлы имеют достаточно

статичные записи, и вам не придётся тратить на них много времени в дальнейшем.

Начните с создания пустого файла /etc/authpf/authpf.conf. Этот файл  необходим для работы authpf, однако содержимое его может быть разнообразным, т.ч. создание пустого

файла будет разумным.

Далее следуем в /etc/pf.conf. Сначала, создаём макросы интерфейса:

ext_if = "re0" int_if = "ath0"

Дополнительно, если вы определите таблицу названную <authpf_users>,  authpf будет добавлять IP адреса аутентифицируемых пользователей в эту таблицу:

table <authpf_users> persist

Если вам необходимо запустить NAT, правила которые занимаются трансляцией, проще определить в authpf.rules, а не хранить их в файле pf.conf:

pass out on $ext_if from $localnet nat-to ($ext_if)

Синтаксис для pre-OpenBSD 4.7:

nat on $ext_if from $localnet to any -> ($ext_if)

Далее, мы создадим якорь authpf, который позволит загружать правила из  authpf.rules при аутентификации пользователя:

anchor "authpf/*"

Для версии authpf pre-OpenBSD 4.7, требуется несколько якорей, т.ч. соответствующая секция должна выглядеть так:

nat-anchor "authpf/*" rdr-anchor "authpf/*" binat-anchor "authpf/*" anchor "authpf/*"

Этим мы завершим конфигурирование pf.conf связанное с authpf.

В части фильтрации, мы начнём  block all по умолчанию, и будем добалять разрешающие правила (pass) по необходимости. Здесь для нас важно, чтобы SSH трафик проходил во внутреннюю сеть:

pass quick on $int_if inet proto { tcp, udp } to $int_if port ssh

С  этого  момента  всё  зависит  от  вас.  Вы  хотите,  чтобы  ваши  клиенты  получили разрешение  мён  прежде  чем  аутентифицировались?  Если  это  так,  вставьте  правило пропуска для TCP и UDP сервиса разрешения имён в ваш файл pf.conf. Для относительно простых установок, вы можете включить остальную часть нашего базового набора правил, изменив   пропускающие    правила   для   позволения   трафика   адресов   в   таблице

<authpf_users>, вместо любого адреса вашей локальной сети:

pass quick inet proto { tcp, udp } from <authpf_users> to port $udp_services pass inet proto tcp from <authpf_users> to port $client_out

Для  более  дифференцированной  установки,  вы  можете  поместить  остальную  часть вашего  набора  правил  в  /etc/authpf/authpf.rules  или  разместить  отдельные  правила пользователя   в   пользовательских   файлах   authpf.rules   в   поддиректории   каждого пользователя в /etc/uathpf/users/. Если вашим пользователям нужна защита, ваш общий файл /etc/authpf/authpf.rule может выглядеть например так:

client_out = "{ ssh, domain, pop3, auth, nntp, http, https }" udp_services = "{ domain, ntp }"

pass quick inet proto { tcp, udp } from $user_ip to port $udp_services pass inet proto tcp from $user_ip to port $client_out

Макрос user_ip встроен в authpf и расширяется в IP адрес пользователя который прошёл аутентификацию.  Эти  правила  будут  применяться  к  любому  пользователю,  который проходит проверку подлинности на шлюзе. Если файл authpf.rules существует в каталоге пользователя   /etc/authpf/users,   правила   из   этого   файла   будут   загружаться   для пользователя. Это значит, что ваш наивный пользователь Пётр (пусть будет Пётр – п.п.) котору необходимо только просматривать странички в интернет и иметь доступ к службе работающей на верхнем порту специфичной машины может получить только то, что ему нужно при наличии файла /etc/authpf/users/peter/authpf.rules подобного следующему:

client_out = "{ domain, http, https }"

pass inet from $user_ip to 192.168.103.84 port 9000

pass quick inet proto { tcp, udp } from $user_ip to port $client_out

С другой стороны, коллега Петра, Кристина, запускает OpenBSD и вообще не знает, что она делает, даже если она создаёт трафик. Вы могли бы дать ей волю, создав примерно такой файл /etc/authpf/users/cristina/authpf.rules:

pass from $user_ip os = "OpenBSD" to any

Это   означает,   что   Кристина   может   делать   всё   что   ей   захочется,   пока   она аутентифицирована на своей OpenBSD.

Широко открытая закрытая сеть                                             В  некоторых случаях, имеет смысл  настроить сеть  таким образом,  чтобы  она  была открытой и не зашифрованной на канальном уровне, в то же время соблюдая некоторые ограничения по authpf. Следующий пример   – Wi-Fi  зона которая может создаваться в аэропортах или других общественных  местах, где любой желающий может связаться с точками доступа и получить  IP  адрес, однако любая попытка выхода в Интернет будет перенаправлена на  специальную страницу, до тех пор, пока пользователь не получит

аутентификации5.

Следующий  файл  pf.conf  построен  на  нашей  предыдущей  базе,  с  двумя  важными дополнениями в базовой настройке authpf: макросами и перенаправлениями.

ext_if = "re0" int_if = "ath0" auth_web="192.168.27.20"

dhcp_services = "{ bootps, bootpc }" # DHCP server + client table <authpf_users> persist

pass in quick on $int_if proto tcp from ! <authpf_users> to port http rdr-to $auth_web match out on $ext_if from $int_if:network nat-to ($ext_if)

anchor "authpf/*" block all

pass quick on $int_if inet proto { tcp, udp } to $int_if port $dhcp_services pass quick inet proto { tcp, udp } from $int_if:network to any port domain pass quick on $int_if inet proto { tcp, udp } to $int_if port ssh

5.  Благодарю Вегарда Энгена (Vegard Engen) за идею и его конфигурацию, которая сохранена здесь если не во всех деталях, то хотя бы в целом.

Для старой версии authpf, используйте такой файл:

ext_if = "re0" int_if = "ath0" auth_web="192.168.27.20"

dhcp_services = "{ bootps, bootpc }" # DHCP server + client table <authpf_users> persist

rdr pass on $int_if proto tcp from ! <authpf_users> to any port http -> $auth_web nat on $ext_if from $localnet to any -> ($ext_if)

nat-anchor "authpf/*" rdr-anchor "authpf/*" binat-anchor "authpf/*" anchor "authpf/*"

block all

pass quick on $int_if inet proto { tcp, udp } to $int_if port $dhcp_services pass quick inet proto { tcp, udp } from $int_if:network to port domain pass quick on $int_if inet proto { tcp, udp } to $int_if port ssh

Макрос auth_web и перенаправление позволяет перенаправлять весь web  трафик от адресов,   которые   не   попадают   в   таблицу   <authpf_users>   аутентифицированных пользователей на специальный адрес. На этом адресе вы создаёте web-сервер, который обеспечивает  информационные  службы  для   клиентов.  Это  могут  быть  страницы  с инструкциями, информирующими к кому следует обратиться за получением доступа или подсистема обработки данных кредитных карточек для получения платного доступа. Следует отметить, что в этом случае будет работать сервис разрешения имён, однако все попытки   web   сёрфинга   будут   перенаправлены   на   адрес   auth_web.   Как   только пользователи пройдут аутентификацию, вы можете добавить для них общие правила или специфические правила пользователя в файлах authpf.rules, в  зависимости от вашей ситуации.

Источник: Книга о PF, by Peter N.M. Hansteen, Перевод выполнил Михайлов Алексей aka iboxjo

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий