Здравствуйте, уважаемые коллеги!

Сегодня мы с вами рассмотрим модель саморегулирующейся системы обеспечения доступа в Интернет для небольшой компании. Саморегулирующейся – потому что предлагаемый способ реализации доступа к интрнет-ресурсам делает Интернет-статистику абсолютно прозрачной, что отбивает охоту у пользователей излишне увлекаться посторонними ресурсами. Данная модель неоднократно опробована и подтвердила свою работоспособность в боевых условиях.

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

Ах да! Чуть не забыл попиарить ресурс www.mednikov.ru, на котором публикуются все предыдущие статьи из данной серии и другие материалы (например, на тему ИТ-аутсорсинга для малого бизнеса).

Все то время, что я работал системным администратором самым отвратительным делом, которым мне приходилось заниматься – это устранять последствия деятельности пользователей в Cети. Не секрет, что люди – не роботы, и потому не могут с 9:00 до 18:00 сидеть и выполнять одну и ту же работу, например, уставившись в окошко Word’а или 1С. Естественно, в какой-то момент им хочется отвлечься и немного передохнуть. Причем, чем ближе конец дня, тем чаще возникает такое желание. Тут мы все одинаковые, чего скрывать…

Если раньше в конторах целыми днями гоняли чаи и болтали в курилках, то сегодня офисный пролетариат «зависает» на бесконечных развлекательных сайтах, убивает сотни часов в ICQ и других IM-сетях, переправляя друг другу «прикольные файлы» через IM-клиенты. Некоторые особо продвинутые личности – те проводят бесчеловечные опыты над своим рабочим компьютером, устанавливая на него гигабайты всевозможного софта. Происхождение и назначение этого ПО зачастую способно вызвать у системных администраторов нервные судороги. Думаю, не стоит объяснять, какие последствия имеет все это для вашей сети.

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

Предлагаю вашему вниманию сценарий, неоднократно опробованный во множестве организаций и прекрасно себя зарекомендовавший. Для его исполнения нам потребуется:

1. Маршрутизатор, способный фильтровать IP-пакеты
2. Прокси-сервер, способный ограничивать доступ к Интернет-ресурсам по имени пользователя
3. Система, позволяющая собирать статистику с прокси-сервера и публиковать ее для последующего просмотра
4. DHCP-сервер
5. Домен Windows (не обязательно, но его наличие сильно облегчит жизнь)

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

Пользовательские машины должны быть настроены на безоговорочное использование прокси-сервера, а доступ к соответствующим настройкам браузера должен быть закрыт при помощи групповой политики Active Directory (если вы используете домен Windows), либо через соответствующие ключи реестра Windows.

Прокси-сервер должен пускать пользователя в Интернет, аутентифицируя его по имени и паролю. Это нужно не столько для обеспечения безопасности, сколько для того, чтобы персонализировать пользователей в логах прокси не по безликому IP-адресу, а по логину, который более удобочитаем. Аутентификацию крайне желательно сделать «прозрачной», т.е. пользователь вообще не должен знать, что его браузер передает прокси-серверу какие-то учетные  данные. Проще всего этого добиться, опять же, в сетях, построенных на основе домена Windows, поскольку существует масса продуктов (в том числе и open source), поддерживающих NTLM- и LDAP-аутентификацию (а Active Directory как раз является LDAP-каталогом). При использовании подобных продуктов мы можем контролировать доступ пользователей в Интернет, опираясь на то, под каким именем он залогинен в домене, причем в некоторых случаях (например, при использовании MS ISA или SQUID с модулем squid_ldap_auth) пользователь даже не увидит запроса пароля, поскольку проверка учетных данных произойдет без его участия.

Подобный подход заодно позволит администратору сэкономить время на управлении пользовательскими учетными данными: создали нового пользователя, добавили его в созданную ранее группу пользователей Интернет (если это требуется) – и все. Пользователь будет использовать для выхода в Интернет тот же пароль, что и для доступа к сети. Конечно, это не совсем безопасно, но если не быть излишним параноиком и помнить, что мы строим конфигурацию не для огромной корпорации, а для небольшого предприятия, то уровень безопасности достаточен. К тому же, единственный пароль забыть сложнее, чем десяток разных, хотя иногда встречаются те еще уникумы…

Помимо собственно http- и https-трафика, наши пользователи могут потреблять трафик и других служб. Как правило, к ним относятся электронная почта и IM-сервисы (ICQ, MSN и др.), IP-телефония (например, Skype).

Особняком стоя бухгалтеры. Их волшебное ПО под названием «банк-клиенты» может использовать тысячи всевозможных способов соединения с банком, начиная от банального FTP и заканчивая установкой десятка соединений со всевозможными портами нескольких удаленных серверов. Естественно, все порты, необходимые для работы этого ПО нужно будет открыть на брандмауэре. Чтобы у какого-нибудь хитросделаного менеджера не было соблазна установить на свою машину локальный прокси, организующий доступ к Интернет через открытые нестандартные порты в обход корпоративного прокси с, мы должны разрешить соединения с нужными нам портами на строго ограниченном перечне серверов (а установку ПО, кстати, имеет смысл вообще запретить средствами Active Directory).

Например, если ваш почтовый сервер стоит за пределами локальной сети, то для работы с ним нужно разрешить на маршрутизаторе исходящий трафик на 25, 110 и 143 порты (smtp, pop3 и imap соответственно) и входящий трафик с этих портов, но разрешение должно распространяться только на IP-адрес вашего почтового сервера. Т.е. с другими почтовыми серверами соединение должно быть запрещено до тех пор, пока вам не понадобиться дать доступ к ним в связи со служебной необходимостью.

То же касается и всех других служб. Если вы разрешаете доступ к icq, то разрешите трафик на порт 5190 но только на те серверы, которые обслуживают «аську». Серверы ICQ имеют и используют две сети - 64.12.0.0/16 и 205.188.0.0/16. Соответственно трафик на порт 5190 (и с порта 5190) должен быть разрешен только для этих сетей.

Подобным же образом следует ограничить доступ к нужным вам серверам FTP (порт 21) и другим службам. Однако на этом останавливаться мы не станем.

Поскольку не все пользователи в вашей сети – бухгалтеры, доступ к «бухгалтерским» серверам нужен не всем. Чтобы отсечь лишних пользователей, на маршрутизаторе необходимо разрешить доступ по «бухгалтерским портам» только определенным машинам из локальной сети (на основании IP-адреса компьютера). Некоторым вашим сослуживцам по долгу службы, возможно, приходится работать с большим количеством Интернет-служб, перечислить все адреса которых не представляется возможным, поэтому нам ничего другого не остается, кроме как разрешить таким людям доступ на нужные им порты по любому адресу. Естественно, таких привилегированных пользователей нужно как-то выделить из общей массы, и разрешить им соответствующий доступ, используя в качестве критерия доступа IP-адрес машины привилегированного пользователя.

Чтобы избежать путаницы, IP-адреса лучше всего раздавать при помощи DHCP-сервера. DHCP, как правило, встроен во все серьезные маршрутизаторы и, естественно, реализован в Windows Server. Привяжем выдаваемые IP-адреса к MAC-адресам привилегированных машин, и они всегда будут получать одни и те же адреса. Чтобы прочие хитрецы не могли втихаря сменить на свое машине IP-адрес, необходимо запретить эту операцию при помощи групповых политик (если вы используете AD), заблокировав заодно доступ к командной строке.

Поскольку человеческая зловредность не знает границ, необходимо организовать на маршрутизаторе статическую arp-таблицу, чтобы тупое изменение IP-адреса на клиентской машине приводило бы к потере связи с маршрутизатором, а не к получению привилегированного доступа к Интернет-ресурам. Этот трюк понятен тем, кто знаком с протоколом arp, а остальным нужно просто запомнить о существовании такой возможности. Подробно arp-таблицу  и назначение протокола arp мы рассмотрим в другой раз, но особо любопытные могут заглянуть сюда.  Конечно, понимающий принципы работы протоколов Ethernet и TCP/IP человек найдет возможность обойти и эту защиту (довольно легко, притом),  но если в вашей компании уровень паранойи настолько высок, то лучше все-таки приобрести активное сетевое оборудования типа Catalyst, при помощи которого эту задачу контроля доступа можно решить гораздо эффективнее.

Теперь поговорим об инструментарии, который позволяет сделать все это. В идеале желательно иметь отдельный аппаратный маршрутизатор или брандмауэр, а прокси-сервер организовывать на отдельной машине, но в суровой российской действительности желаемое и достижимое – это не одно и то же. Скорее всего, денег на оборудование, как всегда, не будет, поэтому для реализации нашего проекта мы будем использовать старенький системный блок, в который будет установлено две сетевых платы, а на жестком диске которого будет стоять Linux или FreeBSD.

При всем моем уважении к компании Microsoft и ее продукту Windows в частности, я всерьез считаю, что любые решения для организации доступа в Интернет, построенные на основе Windows – это зло. И если продукт MS ISA заслуживает хоть какое-то уважение благодаря серьезному функционалу и полной интеграции с Active Directory, то ПО типа WinGate, WinRoute, Traffic Inspector, UserGate и др. просто не место в корпоративных сетях, какими бы маленькими они не были. Если хотите, это мое предвзятое мнение как человека, использовавшего и WinRoute, и ISA, и Linux, и оборудование Cisco для решения боевых задач, а потому знающего цену стабильной работе оборудования. Поэтому мой приговор таков: при отсутствии бюджета лучший выбор - *nix-система.

Можно до хрипоты спорить, что лучше – FreeBSD или Linux, но мы этого делать не будем. Хотя FreeBSD и считается более безопасной и удобной для использования в сети системой, поверьте, малому бизнесу это совершено не важно. Он просто не предъявляет к безопасности ТАКИХ требований. Спорить о нюансах дистрибутивов Linux и FreeBSD в применении к малому бизнесу также бессмысленно, как рассуждать с сельским алкоголиком об оттенках вкуса бордо урожая 1978 года. Рассматриваемую задачу можно решить при помощи любого *nix-дистрибутива на ваш вкус, причем одинаково эффективно и безопасно, поэтому спорить не будем.

Для решения нашей задачи нам понадобятся следующие пакеты:

• IPTABLES – для построения брандмауэра
• SQUID – в качестве прокси-сервера
• SAMS (http://sams.irc.perm.ru/) – система управления SQUID’ом. На самом деле, подобных решений навалом, но мне SAMS нравится своей логичностью, наглядностью отчетов, простотой эксплуатации, возможностью интеграции с Active Directory на уровне учетных записей и возможностью предоставить доступ к статистике людям, не имеющим административных прав в системе.
• MySQL – СУБД для хранения служебных данных
• APACHE – web-сервер.

Если вы используете сеть с Active Directory, DHCP лучше настроить на одним из контроллеров домена. Если же нет, то службу DHCP нужно будет установить на Linux-машине.

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

Если это необходимо, создадим статическую arp-таблицу, чтобы сделать бесполезной подмену IP-адресов клиентов для получения привилегированного доступа к Интернет-ресурсам. Удостоверьтесь, что все работает, как надо.

Далее наступает очередь IPTABLES. Сперва организуем маршрутизацию и обычный NAT без ограничений трафика для всей сети. Сделав начальные настройки IPTABLES, поставим SQUID и настроим его на работу в качестве обычного прокси без каких-либо ограничений. Настроим локальные машины на работу с прокси. Запретим весь исходящий трафик из сети всем клиентским компьютерам, кроме нашей Linux-машины и административного компьютера и начнем создавать правила, разрешающие доступ к определенным ресурсам всем без исключения (например, к почте), а также доступ для привилегированных машин.

После того, как мы удостоверимся, что работать с браузером можно только через прокси-сервер, и все машины, нуждающиеся в особом режиме доступа, имеют таковой, необходимо принять меры, чтобы затруднить пользователям менять настройки сетевых плат и параметры прокси-сервера в браузере. Конечно, в выигрыше окажутся те, кто использует Active Directory – там большая часть работы может быть выполнена при помощи групповых политик, запрещающих изменение нужных нам настроек. Остальным же придется колдовать с ключами реестра и распространять *.reg-файлы по всем машинам.

Когда все необходимые работы будут проведены, приступим к самой интересной части – к системе сбора статистики и управления работой SQUID. Установим SAMS и необходимые для его работы APACHE и MySQL. Вся необходимая документация может быть взята на официальном сайте проекта. Учтите, если вы планируете организовать прозрачную аутентификацию пользователя SQUID в домене Windows, то SQUID, возможно, придется пересобрать с поддержкой модуля squid_ldap_auth, чтобы обеспечить его работу с LDAP. После установки SAMS задайте с его помощью перечень запрещенных ресурсов и, если хотите, трафиковые квоты, выделенные пользователям.

SAMS требует наличие списка пользователей, которым разрешен доступ к Интернету, поэтому я всерьез настаиваю на настройке связки SQUID+SAMS+AD – так вы значительно упростите добавление в SAMS новых учетных записей и сделаете возможным существование единого пароля, по которому пользователи смогут как логиниться в домен, так и попадать в Интернет.

Теперь остается поработать с системой в тестовом режиме, обращая внимание на недоделки и устраняя их. Через месяц-полтора можно разрешить в SAMS руководителям подразделений смотреть статистику по трафику пользователей и научить их это делать. Публичное распространение статистики за месяц играет очень важную роль. Когда пользователь знает, что все его ходы в сети записаны и будут проанализированы в итоге, он ведет себя более осмотрительно. Очень забавно видеть лица людей, когда ты при всех сообщаешь ему что-то вроде: «Саша, я думал, что знаю о порнографии все, но тот сайт с девочками и собачками, на котором ты проводишь столько времени – это что-то особое!». Вручите пару раз публично своим сослуживцам почетные грамоты в номинации «Знаток порносайтов», «Эксперт в косметике» или «За особые достижения в изучении контента сайта fishki.net», и поверьте, сознательность проснется даже у самого законченного серфера. А уж если вам удастся подключить к своей инициативе руководство компании, которое начнет покрывать расходы на Интернет за счет самых активных серферов, воспитательный эффект будет просто потрясающий.

Итог. Воспользовавшись предложенным сценарием, вы сможете построить систему, не накладывающую жестких ограничений на поведение пользователя в сети (пользователи контролируют себя сами, помня о награде за излишнее потребление трафика в конце месяца), но абсолютно прозрачную для анализа. Особое ее достоинство заключается в том, что пользователь, пытающийся получить доступ к сети способом, отличающимся от заданного вами, потерпит неудачу. У сценария есть два недостатка: анализ логов SQUID не даст полноты картины по потреблению трафика по каким-либо протоколам, кроме http и https, а использование онлайн-анонимайзеров позволит обойти все ограничения, существующие на прокси-сервере. В то же время, мы говорили не о полноценном биллинге, а о контроле посещаемых пользователями ресурсов (полую статистику можно снимать со счетчиков iptables, например). Что же касается анонимайзеров, то их легко вычислить по анализу логов и закрыть для посещения. Вычисляется это все просто: как только в top10 посещаемых сайтов вылезает что-то с доменным именем типа hidemyass.org, с большим количеством трафика, значит пользователь вдруг возомнил себя хитрее черта и пользуется web-based анонимайзером. Такие сайты можно закрывать, а можно поступить проще и приравнять использование онлайн-анонимайзера к посещению порносайтов, награждая пользователя за это соответветствующим образом.

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

В следующий раз мы с вами будем рассматривать каталоги LDAP и их практическую пользу для применения в наших с вами локальных сетях. В частности, вы узнаете о том, как научить почтовый сервер на Linux самостоятельно создавать новые почтовые ящики при создании учетной записи в Active Directory и некоторые другие аспекты применения LDAP в гетерогенных системах.

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

С уважением,
Павел Медников