Защита сетей общего пользования от хищения параметров IP

Будучи студентом университета Пьюджет-Саунд, что в г. Такома, шт. Вашингтон, я работал в офисе ResNet главным консультантом по информационным технологиям и телекоммуникациям. Этот офис занимается всеми вопросами, связанными с поддержкой компьютерной сети на территории университета. В частности, он отвечает за платную сеть Ethernet, которая в настоящее время включает девять подсетей, охватывающих девять студенческих общежитий, восемь гостиниц и 78 принадлежащих университету жилых домов, что в общей сложности составляет 1450 сетевых соединений. Данная сеть IP предоставляет доступ к внутренним университетским ресурсам Intranet и к внешней сети Internet.

ПРОБЛЕМЫ

Еще два года назад для подключения студента-пользователя к нашей сети необходимо было физически передать ему назначенные параметры IP и затем вручную сконфигурировать его машину. Такой подход приводил к большому объему бумажной переписки и создавал массу проблем для нашего офиса. Все их можно разделить на три основные группы.

1. Статичность данных о пользователях. В университетской среде студенты не задерживаются надолго в одном и том же месте. Они переезжают из одной комнаты в другую, находят жилье вне университета, уезжают на учебу за границу, а иногда даже все вместе отправляются куда-либо на целый семестр. Оперативно обновляемые сведения из университета к нам не поступали, поэтому мы могли полагаться лишь на устные сообщения о местонахождении того или иного студента.
2. Конфигурирование клиентских машин вручную. Машины всех студентов, подключенные к нашей сети, конфигурировались вручную техническим специалистом из нашего офиса. Несмотря на все предпринимаемые нами усилия по упорядочению процесса подключения к сети ResNet, от длинных очередей избавиться не удавалось.
3. Похищение параметров IP. У этой проблемы две стороны. Поскольку мы полагались на конфигурирование вручную, предприимчивые студенты, знаний которых хватало для самостоятельной настройки своих машин, запросто могли «позаимствовать» данные адресов IP у другого студента и использовать их как свои собственные. Мало того, что такая практика приводила к конфликтам адресов IP и вызывала проблемы с соединением у других студентов, она уводила средства из дохода нашего офиса.

РЕШЕНИЕ

Необходимо было что-то предпринять как для защиты сети, так и для снятия чрезмерной нагрузки с наших администраторов и консультантов. Использование протокола динамического конфигурирования хоста для межсистемной связи (Intersystem Communication Dynamic Host Configuration Protocol, ISC DHCP) представлялось очевидным решением, поскольку позволяло динамически конфигурировать клиентские машины в сети. Однако один лишь DHCP не решал всех наших проблем. На самом деле требовалось найти способ расширить возможности DHCP так, чтобы мы могли обеспечить блокирование ресурсов и автоматизировать процесс регистрации пользователей, сохраняя при этом возможность автоматического конфигурирования, предоставляемую протоколом DHCP. Выход, который мы нашли, оказался достаточно простым. Ядро нашей системы авторегистрации (Autoreg) базируется на протоколе DHCP, службе имен доменов (Domain Name Service, DNS) и списках управления доступом (Access Control Lists, ACL), используемых на нашем маршрутизаторе для предоставления клиенту требуемого уровня доступа.

Для блокирования входа в сеть незарегистрированных пользователей мы сконфигурировали DHCP так, чтобы неизвестным клиентам IP-адреса выдавались в определенном диапазоне. Этот диапазон IP-адресов затем «отслеживается» посредством списков доступа на нашем маршрутизаторе, а также с помощью процесса, который мы называем «подмена DNS» (DNS spoofing), так что они могут получить доступ только к нашему серверу авторегистрации — машине, на которой работают DHCP и вспомогательные приложения. Для регистрации клиентов мы предоставляем сценарии CGI (я называю их сценариями, хотя на самом деле это откомпилированные исполняемые файлы С++) через Web-сервер Apache, работающий на сервере авторегистрации. Сценарии аутентифицируют пользователей, затем назначают для них новый, не имеющий ограничений IP-адрес, занося статическую запись о хост-узле для данной машины в конфигурационный файл ISC DHCP (conf), после чего перезапускают демон DHCP. Такой подход не только совершенно не затрагивает код ISC, но и позволяет создавать на основе сценариев CGI весь интерфейс Web.

Для осуществления контроля за аутентификацией пользователей и хранением данных мы обратились к университету с просьбой о доступе к главной базе данных Oracle. В ней мы завели таблицы, автоматически создающие учетные записи пользователей для студентов, проживающих на университетской жилой площади. На самом деле эти записи являлись ссылками на данные, хранящиеся в таблицах, принадлежащих другим подразделениям. Защита доступа к учетным записям с помощью пароля обеспечивается непосредственным взаимодействием с RADIUS, помогая нам перейти на архитектуру с однократной регистрацией (Single Sign-On, SSO). Доступ к университетской базе данных предоставлял нам возможность вносить сумму оплаты за обслуживание непосредственно в финансовые счета студентов, что освобождает от необходимости заниматься взиманием платежей. На Рисунках 1 и 2 представлена упрощенная схема нашей главной базы данных.

Рисунок 1. Упрощенная структура основной базы данных Oracle.

Рисунок 2. Структура системы автоматической регистрации.

КОНФИГУРИРОВАНИЕ BIND

Основная идея заключалась в необходимости дополнительно к «подмене DNS» иметь отдельный сервер DNS, который возвращал бы один IP-адрес на каждый полученный запрос. Для нашей системы авторегистрации мы выбрали ISC BIND и установили его на одной машине с сервером DHCP. Затем отслеживаемый нами диапазон IP-адресов был сконфигурирован в DHCP так, чтобы все запросы автоматически направлялись на сервер авторегистрации Autoreg для DNS. Поскольку большинство пользователей не настолько разбираются в TCP/IP, чтобы вручную указать настоящий сервер DNS, такой фиктивный DNS — действенный механизм по ограничению доступа к большинству ресурсов сети IP. К тому же «подмена DNS» помогает легко находить сайт регистрации, так как именно туда перенаправляются все запросы. Новые пользователи просто запускают свой любимый браузер Web и сразу попадают на наш сайт регистрации.

Конфигурирование ISC BIND таким образом, чтобы возвращался лишь один адрес, — дело достаточно тонкое, однако такой подход работает. По существу мы просто сконфигурировали сервер в предположении, что он «знает» ответ на любой запрос адреса. Ниже приводится полный текст нашего файла host.all. Сервер авторегистрации Autoreg, на котором работает DHCP, фиктивный BIND и сайт регистрации Web — все имеют адрес 210.207.100.30:

*.	IN	NS	resnet.ups.edu.
*	IN	A	210.207.100.30
resnet 	IN	A	210.207.100.30

Такой подход может работать и в более общем случае — важно лишь не допустить влияния фиктивного DNS на другие серверы системы DNS.

КОНФИГУРИРОВАНИЕ DHCP

Вторым шагом было конфигурирование DHCP и маршрутизатора для разделения сети на отслеживаемые и неотслеживаемые диапазоны IP-адресов. Несколько наших «подсетей» представляют собой разделяемые сети, состоящие из двух физических подсетей. В этом случае около 20 IP-адресов первой из них выделяются для незарегистрированных пользователей. Оставшиеся адреса первой подсети и все адреса второй выдаются зарегистрированным пользователям. В сетях, не функционирующих как разделяемые, квота для незарегистрированных пользователей составляет порядка 10 адресов. Обычно в файле dhcpd.conf указывается по одному глобальному определению для серверов DNS и NNS, а также задается продолжительность аренды. Для осуществления первого уровня слежения за IP-адресами в некотором диапазоне мы указали фиктивный сервер DNS отдельно, переопределив тем самым глобальные установки. Ниже приводится фрагмент из файла dhcpd.conf, где задается конфигурация нашей подсети greek-row. И как прежде, сервер Autoreg, на котором работает DHCP, фиктивный DNS и сайт регистрации Web — все это сайт resnet.ups.edu с адресом 210.207.100.30:

###GREEK ROW
###210.207.118.0 and 
210.207.119.0
shared-network greek-row
{
#Used for wounded IPs and for 
registered users
subnet 210.207.118.000 netmask 
255.255.255.000
{
option routers 210.207.118.001;
#Wounded IPs -DNS and lease 
times specified to
#override global definitions
pool
{
range 210.207.118.020 
210.207.118.029;
option domain-name-servers 
210.207.100.030;
option netbios-name-servers 
210.207.100.030;
default-lease-time 600;
max-lease-time 600;
allow unknown clients;
}
}
#Used for registered users 
only, therefore we?re not
#specifying DNS, lease times 
or lease ranges
subnet 210.207.119.000 netmask 
255.255.255.000
{
option routers 210.207.119.001;
}
}

Для статических записей о хост-узлах, заведенных для зарегистрированных пользователей и не попадающих в диапазон слежения, по умолчанию действуют глобальные настройки серверов DNS, NNS и времени аренды. В предположении, что зарегистрированные пользователи остаются таковыми длительное время, мы определили глобальное значение продолжительности аренды в несколько дней.

КОНФИГУРИРОВАНИЕ МАРШРУТИЗАТОРА

Большинство студентов используют нашу сеть для доступа в Web и к электронной почте, так что для отслеживания IP-адресов и ограничения доступа неавторизованных пользователей нам вполне хватало фиктивной DNS. Но среди студентов всегда найдутся такие, кто способен обойти любую систему защиты. В связи с этим пришлось предпринять дополнительные меры, дабы обезопасить нашу систему от тех, кто способен вручную указать настоящий сервер DNS. Мы создали списки контроля доступа на маршрутизаторе, разрешив доступ лишь к серверу DHCP. Например, для того чтобы пакет с адресом 210.207.118.20 имел доступ только к серверу регистрации Web (210.207.100.30, порт 80), нам пришлось добавить в конфигурацию маршрутизатора Cisco следующие строки:

access-list 118 permit 
tcp host 210.207.118.20 host 
210.207. 100.30 eq 80
access-list 118 deny ip host 
210.207.118.20 any

Эти записи блокируют данный IP-адрес, так что любой, кто будет его использовать, сможет попасть исключительно на сайт регистрации, и никуда более. Такой подход — прекрасный способ ограничения доступа, при этом, однако, вопросы производительности маршрутизатора заслуживают отдельного рассмотрения. Так как все списки доступа просматриваются по отдельности для каждого пакета, количество отслеживаемых IP-адресов необходимо минимизировать.

Маршрутизатор также использовался для задания списка подсетей, подлежащих контролю со стороны системы авторегистрации. Большая часть университета уже применяет DHCP, поэтому новую систему требовалось ввести в действие таким образом, чтобы она не осложняла работу пользователей. Для этого на маршрутизаторе мы создали по отдельному вспомогательному IP-адресу (IP helper) для каждой университетской подсети. К примеру, следующие строки, добавленные в конфигурацию маршрутизатора Cisco, определяют сервер авторегистрации Autoreg (210.207.100.30) как сервер DHCP для интерфейса 1, а наш основной сервер DHCP (210.207.100.69) как сервер DHCP для интерфейса 2:

ip forward-protocol udp
!
interface ethernet 1
ip helper-address 
210.207.100.30
interface ethernet 2
ip helper-address 
210.207.100.69

В дополнение ко всему вышесказанному, данный подход позволил нам обойтись одним сервером авторегистрации для всей сети ResNet.

НАПИСАНИЕ КОДА

Создание отслеживаемых диапазонов IP-адресов и предоставление пользователям фиктивного DNS — это, конечно, удачное решение, но для полноценного контроля нам не хватало возможности легко перемещать машины между отслеживаемыми и неотслеживаемыми диапазонами. Здесь на помощь пришли сценарии CGI. Для простоты я опишу лишь процесс регистрации пользователей в системе. Реализовав его, легко добавить и другие полезные функции: администрирование IP, управление системной конфигурацией или генерирование отчетов. Поскольку нам требовалось обеспечить поддержку соединений с базой данных Oracle и интегрировать в систему модуль аутентификации RADIUS, мы реализовали все сценарии CGI на С++. Само по себе написание сценариев CGI на С++ — нелегкая задача. К счастью, имеющиеся доступные библиотеки делают этот процесс таким же простым, как написание на Python или Perl. Мы использовали разработанную мной библиотеку С++, на создание которой меня вдохновила библиотека CGIC Томаса Боутелла (http://www.boutell.com/cgic).

Для начала надо было «научить» наше регистрационное приложение CGI взаимодействовать с системой RADIUS. Одна из университетских групп работала с продуктом под названием Squid для локального кэширования страниц Web, у которого имеется модуль аутентификации RADIUS, написанный Марком ван Сельмом (http://selm.www.cistron.nl/~selm/authtools). Мы видоизменили исходный код так, чтобы его можно было вызывать в качестве внешней функции из нашего регистрационного приложения. Кроме того, нам пришлось добавить внутрь библиотеки код для генерации множественных запросов, так как около половины пакетов UDP терялось по пути их следования на сервер RADIUS. В конце концов, после всех переделок мы просто передавали функции имя пользователя и пароль, а она возвращала результат аутентификации: успех, неудачу или истечение времени тайм-аута.

Вторым важным моментом было то обстоятельство, что Pro*C++ (используемая нами библиотека соединения с Oracle для С++), посредством которой создаются соединения с базой данных, требовала специфических переменных окружения. А поскольку наше приложение работало в среде CGI, мы не могли задать переменные окружения ни с помощью сценариев входа в систему, ни с помощью командных файлов. Нам пришлось добавить в приложение код, чтобы всякий раз при его запуске создавались требуемые переменные окружения, что гарантировало наличие всех необходимых для Oracle переменных окружения вне зависимости от рабочей конфигурации.

После того как заработал модуль аутентификации и была отлажена связь с базой данных, мы принялись за реализацию процесса перехода клиентов с одного IP-адреса на другой. Для создания в файле dhcpd.conf статической записи, определяющей хост-узел, требовался MAC-адрес клиента. К счастью, ISC DHCP отслеживает MAC-адрес при объявлении нового периода аренды:

lease 210.207.118.24 {
starts 6 2001/05/12 09:48:59;
ends 6 2001/05/12 09:58:59;
tstp 6 2001/05/12 09:58:59;
binding state free;
hardware ethernet 
00:48:54:88:bf:d8;
uid «0100HT210277337»;
client-hostname «ratbert»;
}

То, что аренда используется нами лишь для отслеживаемых диапазонов IP-адресов, позволило делать грамматический разбор файла аренды dhcpd.leases и извлекать из него запись hardware ethernet, ассоциированную с определенным IP-адресом. Таким образом, для получения MAC-адреса клиента, которого мы хотим зарегистрировать, сначала извлекается IP-адрес из среды CGI, а потом путем разбора файла аренды устанавливается аппаратный адрес клиента. Затем приложение запрашивает у базы данных очередной доступный неотслеживаемый IP-адрес в пользовательской подсети, после чего создает в файле dhcpd.conf статическую запись о хост-узле:

host 1239 {
hardware ethernet 
00:48:54:88:bf:d8;
fixed-address 
210.207.119.56;
}

Как уже упоминалось выше, данный подход предполагает необходимость перезапуска демона DHCP, чтобы тот фиксировал все изменения, сделанные в файле dhcpd.conf. Вместо подтверждения прав доступа в регистрационном приложении, мы написали простой сценарий на Perl, который считывает идентификатор процесса (PID) из dhcpd.pid, после чего завершает этот процесс и осуществляет перезапуск dhcpd. Далее, перед тем как повторить данную процедуру, сценарий в течение заданного времени находится в неактивном состоянии. Продолжительность ожидания задается в зависимости от загрузки системы. Когда частота регистрации высока, например в начале учебного года, мы задаем меньшее значение, чтобы демон DHCP перезапускался чаще по сравнению с периодами невысокой активности пользователей.

Весь код для этой системы был разбит на отдельные модули в соответствии с набором используемых демонов, системных файлов и интерфейсов для различных рабочих сред или созданием страниц Web. Однако нам пришлось учесть, что библиотека Pro*C++ плохо поддается разбиению на компоненты. Поэтому мы предпочли создать по одному исходному файлу Pro*C++ для каждой «утилиты» верхнего уровня в нашей системе (регистрация клиентов, поиск пользователей, IP-администрирование и т. д.) так, чтобы глобальные переменные Oracle «не наступали друг другу на пятки». Вот список файлов для нашего кода регистрации:

.pc содержит весь необходимый код Pro*C++, а также функцию main(). В данной статье мы имеем дело лишь с register.pc;

regpage.js включает код на JavaScript, используемый для проверки правильности заполнения формы на главной странице регистрации;

rad_auth.c содержит функцию authenticate(), используемую в модуле аутентификации RADIUS;

cgiinterface.h определяет класс объектов cgiInterface, используемый для взаимодействия с CGI;

conf.h содержит базовую конфигурацию, задающую пути и файлы, используемые системой авторегистрации (Autoreg);

configfile.h определяет класс объектов configFileInterface, используемый для взаимодействия с конфигурационным файлом авторегистрации (в нашем случае etc/autoreg.conf);

dhcpconf.h определяет класс объектов dhcpConfInterface, используемый для взаимодействия с файлом dhcpd.conf;

dhcplease.h определяет класс объектов dhcpLeaseInterface, используемый для взаимодействия с файлом dhcpd.leases;

errorlog.h определяет класс объектов errorLogInterface, используемый для взаимодействия с нашим файлом регистрации типовых ошибок;

filelock.h определяет класс объектов fileLock, используемый для виртуального блокирования файлов на время работы с ними системы;

html_reg_pages.h содержит функции вывода страниц HTML, используемых при регистрации;

ipfunctions.h содержит функции обработки IP-адресов;

md5.h необходим файлу rad_auth.c для аутентификации, выполняемой системой RADIUS;

oraclefunc.h содержит функции поддержки операций Oracle;

radius.h необходим файлу rad_auth.c для аутентификации, выполняемой системой RADIUS;

radiusd.h необходим файлу rad_auth.c для аутентификации, выполняемой системой RADIUS;

stringfunc.h содержит функции работы со строками;

sysdep.h необходим файлу rad_auth.c для аутентификации, выполняемой системой RADIUS;

timeutils.h содержит функции работы с системным временем.

Базовый код для самого приложения регистрации (register.pc) достаточно прост. Процесс регистрации включает четыре раздела.

Раздел 1. Страница по умолчанию. Выбор раздела осуществляется путем присвоения значения переменной sessionvars (переменная формы CGI). Если значение не присвоено, то предполагается, что пользователь еще не начинал процесс регистрации. Когда пользователь впервые попадает на сайт регистрации, ни одна из переменных еще не задана, и система отображает главную страницу, где пользователю предлагается ввести имя и пароль, а также информацию о своем компьютере. Эту функциональность обеспечивает вызов процедуры showHTMLregInitial Page().

Раздел 2. Аутентификация пользователя. Исполняемый файл регистрации с переменной sessionvars со значением AUTH запускается после нажатия кнопки register на главной странице регистрации. После считывания данных из формы CGI это приложение извлекает текущий IP-адрес пользователя из среды CGI, вызывая функцию cgiInterface.getRemoteAddr(). Извлеченный IP-адрес затем используется функцией dhcpLeaseInterface.findEntry() при разборе файла dhcpd.leases для получения пользовательского MAC-адреса. Далее выполняются ряд проверок, в том числе полномочий пользователя и принадлежности его IP-адреса (чтобы исключить регистрацию случайно попавших на сайт посетителей, не имеющих отношения к университету). Проводимая затем аутентификация пользователя с помощью RADIUS состоит в вызове внешней функции authenticate(), возвращающей код успеха или неудачи. И наконец, проверяется, не ассоциирован ли MAC-адрес, извлеченный из dhcpd.leases, с каким-либо зарегистрированным ранее пользователем. Посетителю, успешно прошедшему вереницу вышеописанных тестов, предлагается поставить цифровую подпись под соглашением о правилах пользования сетью. Если пользователь ранее уже подписывал данное соглашение, регистрационное приложение переходит в раздел 3, задавая для переменной sessionvars значение REG.

Раздел 3. Регистрация машины. Первым делом приложение, вызывая функцию getUnusedIP(), запрашивает у базы данных неиспользуемый IP-адрес из той же самой подсети, которой принадлежит и текущий IP-адрес регистрируемого компьютера. Затем с помощью вызова функции addNewMachine() для него создается новая запись в базе данных, после чего функцией dhcpConfInterface.addEntry() в файл dhcpd.conf добавляется соответствующая запись о хост-узле. Наконец, на экран выводится страница «регистрация завершена», где пользователя просят подождать 60 с, а затем перезагрузить свой компьютер. Мы предусмотрели на странице псевдоиндикатор выполнения операции с графическим отсчетом 60 с. На самом деле индикатор — не что иное, как анимация GIF, однако он создает у пользователя ощущение, что нечто происходит в период ожидания (за это время демон DHCP возобновит работу и зачитает обновленный файл dhcpd.conf).

Раздел 4. Регистрация закончена. По истечении 60 с страница «регистрация завершена» автоматически перезапускает регистрационное приложение CGI, задает для переменной sessionvars значение COMPLETE. На экран будет выведена страница с просьбой перезагрузить машину пользователя для обновления времени аренды DHCP. Рисунок 3 иллюстрирует процесс регистрации.

РЕЗУЛЬТАТЫ

Появление в университете такой системы привело к поразительным результатам. Загруженность администраторов и консультантов сети ResNet снизилась более чем на 75%, а для подключения к сети никому уже не приходилось томиться в долгих очередях. Мы выпустили небольшой буклет, посвященный ResNet; вместе с другими рекламно-информационными материалами он рассылался студентам по почте за месяц до того, как они прибудут на территорию университета. Инструкции по регистрации и подключению к сети новых пользователей умещались на одной странице. Отныне, вместо того чтобы ждать несколько недель, пока придет консультант и вручную настроит компьютер студентам, предлагалось выполнить несколько простых шагов.

1. Подсоединить компьютер к гнезду Ethernet на стене комнаты.
2. Включить питание компьютера.
3. Запустить браузер Web (в предположении, что большинство машин предварительно сконфигурировано для работы с DHCP). Появится страница регистрации.
4. Заполнить диалоговую форму регистрации, введя имя пользователя и пароль.
5. Нажать кнопку Register («Зарегистрироваться»). В самый первый раз, перед тем как продолжить регистрацию, система предложит пользователю поставить цифровую подпись под соглашением о правилах работы в сети.
6. Появляющийся затем экран сообщает, что регистрация завершена. Через 60 с (после перезапуска службы DHCP) пользователь должен будет перезагрузить свой компьютер.

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

ПУТИ ДАЛЬНЕЙШЕГО ПОВЫШЕНИЯ БЕЗОПАСНОСТИ СЕТИ

Наша система существенным образом повысила безопасность сети, однако лазейки для похищения IP-адресов все еще существуют. В целях дальнейшего укрепления защиты сети можно предпринять следующие меры. К примеру, одну из «дыр» в нашей системе представляет сама служба DHCP. Если пользователь обладает достаточными знаниями об устройстве сети, то ему не составит труда вручную сконфигурировать свой компьютер так, чтобы воспользоваться неотслеживаемым IP-адресом без какой бы то ни было регистрации. Для борьбы с этим можно было бы создать совместно используемые сети по одной на каждую физическую подсеть, в действительности состоящих из двух подсетей. Тогда одна из них служила бы исключительно для отслеживаемых IP-адресов, в то время как другая работала бы только с зарегистрированными пользователями. Такой подход запутывал бы вероятных нарушителей, затрудняя им выяснение IP-адресов, дающих неограниченный доступ в сеть.

Другой подход по обеспечению безопасности сети на случай, если пользователи вручную конфигурируют свои машины на использование неотслеживаемого IP-адреса, практикуется в Рочестерском технологическом институте (RIT) (http://www.rit.edu/~mrcsys/dhcp/ index.html). Для предотвращения доступа к ресурсам пользователей с неизвестными MAC-адресами там прибегают к помощи виртуальных локальных сетей (VLAN) в сочетании со снимками протокола разрешения адресов (Address Resolution Protocol, ARP). Важная роль в работе их системы отведена базе данных MAC- и IP-адресов, пополняемой за счет обращений по простому протоколу управления сетью (Simple Network Management Protocol, SNMP) к данным ARP на маршрутизаторе. Для перехвата обращений к маршрутизатору на сервере DHCP установлено средство мониторинга SNMP. Перехватывая запрос наподобие interface up, оно сверяет соответствующий MAC-адрес с содержимым базы данных и определяет, известна ли та машина, от которой получен запрос. Если неизвестна, MAC-адрес передается в виртуальную локальную сеть, сконфигурированную на доступ исключительно к серверу DHCP.

ЗАКЛЮЧЕНИЕ

Несмотря на некоторые «дыры» в безопасности нашей системы автоматической регистрации и до конца не устраненную возможность хищения параметров IP, система сняла-таки для нашего подразделения остроту проблемы обслуживания сети. От автоматизации процесса регистрации значительно выиграли студенты, получив возможность удаленного подключения к сети. Я надеюсь, что данная статья послужит для системных администраторов хорошим примером того, как интеграция нескольких готовых приложений может решить достаточно непростую задачу.