ищем нелегальный прокси-сервер в корпоративной сети

Предлагаемая статья преставляет собой не что иное, как пересказ дискуссии на одном достаточно популярном среди системных и сетевых администраторов техническом форуме. Отличие сего пересказа от оригинала – систематизация, чего всегда не хватает форумам, хотя попытка оной в рамках данного конктетного thread’а была предпринята, даже неоднократно. Статья предназначена в первую очередь администраторам, причем даже тем, для кого нелегальные прокси-серверы вовсе не являются проблемой: поскольку идеология форума предполагает дискуссию, информация на нем чаще всего бывает избыточна, затрагивая более широкий по сравнению с изначальной темой круг вопросов. Может статья быть интересной и пользователям. Вы узнаете много интересного о том, что и в каких выражениях думают о вас админы, какие зверские требования и меры предпринимаются против вашего сословия в других компаниях, и даже – о ужас – мимолетом будет проскакивать информация о том, как схитрить (если ваш администратор – ротозей и/или не читал эту статью ;) В общем, как это часто водится в “СР” – и вашим, ;) В ;)

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

Юзер – тварь ушлая и хитрая до одурения. Задумали юзеры перехитрить админа и «изобрели» вот что. На машины, коим доступ в Интернет был разрешен, юзеры стали устанавливать прокси-серверы и методом каскадирования соединять их с центральным прокси-сервером фирмы. Через эти пиратские прокси-серверы юзеры, не уполномоченные использовать Интернет, просачивались туда самым хамским образом под видом легального пользователя, на хосте у которого, повторюсь, установлен прокси.

Пришел админ той системы на технический форум уважаемого проекта Opennet правды искать. И был задан вопрос: как выявить наличие прокси-серверов на хостах в своей организации. Если кто-то из вас никогда не пользовался форумами во всех их ипостясях (www, usenet, fido), вы наверное не в курсе, что форум – это такое место, где можно получить ответы на все вопросы мира, кроме того, который вы задаете. Самый частые ответы – «а на кой хрен тебе это надо?», «не знаю, как сделать именно то, что ты хочешь, но можешь попробовать … /далее следует предложение сделать нечто совершенно другое, на другой платформе, софте, и.т.д./».

Но вернемся к нашим баранам. Ответы на вопрос разделились на две большие категории: собственно как найти прокси, и (более многочисленная категория) как предотвратить подобную активность. В свою очередь, мероприятия из последней категории условно делим на:

• административно-коммандные;
• технологические (системные и сетевые политики).

Реальные ответы зачастую содержали комбинации вышеозначенных мер – как поискового, так и «предотвратительного» характера. Я опишу все эти меры (в том числе и неудачные) в порядке живой очереди, а наиболее удачные комбинации вы, уважаемый читатель, при необходимости сможете составить сами.

как найти прокси

1. Сканирование портов.Самый неинтеллектуальный метод, предполагающий как минимум сканирование портов 80, 8080, 3128 и 1080 на всех хостах, допущенных в Интернет (далее для краткости будем называть их “разрешенными”). Метод применим в среде, где продвинутость пользователей не выходит за рамки поиска нужного софта и инсталляции его с настройками по умолчанию. Более разумный юзер научит прокси-сервер отвечать на другом порте. Таким образом, в продвинутой среде количество портов увеличивается до 65535 на один хост. Умножим на количество хостов. Потом на количество сканов в неделю… Не годится, однозначно. 

2. Анализ HTTP-заголовков.Некоторые (еси не все) прокси вставляют свои специфические заголовки, типа X-ForwardedFor: <ip клиента>. Есть и другие заголовки, например squid добавляет еще такие:

Via: <версия протокола, имя хоста и порт, версия squid’а>
Cache-Control: <max-age=?????>

Обсудим отрицательные стороны этого, бесспорно, более интеллектуального решения. Прокси-серверов нынче развелось превеликое множество, и работают они с заголовками самым различным образом. В некоторых лишние заголовки можно отключить при конфигурации, в некоторых ничего лишнего нет по умолчанию (в народе прокси-серверы, мимикрирующие под клиентов, называют анонимными). Делать ставку на squid не стоит – вряд-ли пользователи возьмутся за установку этого монстра, тем более под win32, хотя… из условия задачи мы не знаем, кто работает в фирме, поэтому думаем о самом худшем (программисты, инженеры, мелкое хакерье). А в самом худшем случае будет подправлен и пересобран squid или написана собственная программа (студент курса 3-го соответсвующей специализации должен справиться с самым тривиальным проксиком за максимум час-полтора). В общем, метод оказывается даже более трудоемким, чем сканирование портов, поскольку нам надо собрать коллекцию заголовков, вставляемых по умолчанию всеми имеющимися в природе прокси-серверами, искать все это хозяйство по многотонным логам корпоративного прокси-сервера, и даже в этом случае успех не гарантирован.

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

4. Анализ трафика в сети (между клиентскими машинами).При правильной реализации метод может дать 100%-ную отдачу. Как реализовать это – ваше дело, да и зависит это главным образом от топологии сети. Подскажу что искать:

• HTTP-трафик. Эта находка будет именно тем, что мы искали, во всех случаях кроме одного: мы имеем дело с фирмой-разработчиком, скажем, интранет-приложений, и чуть ли не у каждого сотрудника на машине установлен веб-сервер для тестирования. Впрочем, запасшись усидчивостью, можно выявить не только факт наличия веб-трафика, но и его природу. Согласитесь, запрос вида GEThttp://www.mail.ruHTTP/1.0 вряд-ли относится к процессу тестирования веб-приложения в локальной среде ;)
• Нетипичный трафик. Доказательство, так сказать, от противного. Считаем, что в нашей среде нормальным трафиком между хостами пользователей является Microsoft Network (SMB over NetBIOS). Ну еще бродкасты всякие той же природы, да современные Microsoft’овские творения генерят всякую дрянь вроде BOOTP, DNS SRV и что-то еще. Значит весь остальной трафик – подозрительный. Таким образом можно убить сразу двоих заинек: найти прокси и по ходу обнаружить другие правонарушения: локальное мочилово в quake, или работу таких, безусловно, Интернетовских приложений, как telnet, ftp, irc, которые могут работать через gateways (отображаемые порты), которые мапятся, скажем, на туннель HTTPort’а, установленного на разрешенном хосте.

Пару слов о реализации анализа трафика. Если у вас некоммутируемый Ethernet, вам достаточно любого сниффера – от аскетичного tcpdump до навороченных Observer или Sniffer. Учтите только, что чем больше дополнительных аналитических функций включено в сниффер, тем более комфортной будет ваша «охота на прокся». Вам же не хочется с утра до вечера вчитываться в сырые дампы, а, небось хочется, чтоб оно само детектировало подозрительную активность и дружелюбным образом (звуковой сигнал, сообщение в мылу или на пейджер/телефон) сообщало о безобразиях.

В коммутрируемой или маршрутизируемой сетевой среде простеньким сниффером не отделаешься. Придется воспользоваться либо бесплатными «хакерскими» решениями плана ettercap (ettercap.sourceforge.net) , влияние которого на общее самочуствие сети еще не до конца изучено, либо приобретать распределенную систему анализа трафика, что не есть дешево, но вещь полезная во всех отношениях.

5. Агентурная работа.Очень просто. Устанавливаем на все машины в обязательном порядке некое трояноподобное software, которое пользователь по техническим либо административным причинам не может удалить или заблокировать. Агент может выполнять одну из следующих функций: доставлять администратору (по почте, ftp, SMB – кому что больше нравится) списки запускаемых на машине процессов. Где-то в этих списках (для упрощения и уменьшения объема сего спама каждый процесс можно записывать только один раз) обнаружится и прокси, и гульки, и все-все-все.

предоставлять администратору доступ к системе (в текстовом режиме или передача экрана – опять же, кому как нравится). Как правильно употребить этот доступ для скорейшего отлова преступников – дело хозяйское.

техники “активного противостояния”

Для начала поговорим о мерах технологического характера, поскольку они лично моему сердцу всегда были милее. Эти меры могут быть сетевого и системного уровня. Начнем, пожалуй, с последнего. Аппаратно-программные комплексы по ущемлению прав пользователей. Самый простой пример чисто программного характера – правильно сконфигурированная с т.з. безопасности многопользовательская ОС, например, Windows NT. Разумеется, сотрудники, работающие на хостах воспринимаются не как локальные администраторы ;) Можно и понавороченней, что нибудь класса Secret Net, который уже представляет собой программно-аппаратное решение, исключающее возможность загрузки с другого носителя и очень много других ценных фич. В такой среде юзеры просто ну никак не смогут проинсталлировать себе прокси, потому что они вообще ничего проинсталлировать не смогут ;)

А теперь о самом интересном – о сети.

1. Маршрутизируемые сегменты.Идея проста чрезвычайно: “растаскиваем по углам” разрешенные и запрещенные хосты. Первое, что обычно приходит в голову (и пришло некоторой части участников описываемого выше форума) – просто раздать IP-адреса из разных (под)сетей и под этим благовидным предлогом затащить всех на маршрутизатор, а уж на нем-то, родимом, отфайерволлить «запрещенных» от Интернета и попутно писать в лог все, что касается междусобойной активности юзеров, особенно принадлежащих к разным группам. Однако оставлять их всех на общей шине – опасное решение: при минимальном обучении из ваших юзеров могут вырасти мелкие такие хакерюшки. Кто-то может надоумить их менять IP-адреса, а еще более умный «доброжелатель» просто научит обходить маршрутизатор, включив друг друга в прямую маршрутизацию. Исполненная «на брудершафт» (то бишь на обеих станциях) комманда Route ADD <my_ip> <friends_ip> лишит сидящих на общей шине хостов противоестественной необходимости слать все свои пакетики на маршрутизатор. Поэтому растащите юзеров в --

2. Маршрутизируемые физически разделенные сегменты.Можете реализовать это через PC-router с двумя сетевыми интерфейсами. Если для разделения пользователей придется перекраивать всю СКС – не мучайтесь, заведите коммутатор(ы) с поддержкой VLAN и «растащите» хосты с его помощью – а на маршрутизаторе они все равно «встретятся», но общаться будут уже по навязанным вами правилам, без права на «личную переписку» ;)

3. Немаршрутизируемые физически разделенные сегменты.Купите коммутатор 4 уровня, способный разгребать заголовки пакетов высокоуровневых протоколов. Говорят, есть даже машинки, понимающие кое-что в уровне приложений, например HTTP. При таком раскладе маршрутизатор не понадобится – в рамках нашей задачи свитч будет ему достойной заменой. Однако столь умные коммутаторы пока чрезвычайно дороги, и соорудить на них ЛВС портов эдак на 200 будет просто неподъемно. Можно попробовать использовать такой свитч только на участке, где сливается трафик разрешенной и запрещенной группы. Остальное построить на коммутаторах попроще. Впрочем, это уже проблемы network design’а, выходящие за рамки этой статьи.

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

"Вводишь правила работы в сети с запретом установки программ. Даешь на подпись начальству, потом каждый пользователь расписывается в журнальчике. Потом административные наказания вплоть до увольнения. Помогает. А так отследил, кто какой объем качает, прошел на его рабочее место и проверил, что стоит. Обычно наказание в половину з/п хватает раз и навсегда. У нас в фирме у юзеров даже дисководов нет. Ибо не надо.Весь необходимый софт лежит на серваках."

"За бардак в своей сети отвечать должен админ - не можешь организовать работу сети на программном уровне, организуй на бюрократическом. А таких хитрых жуков мы у себя быстро вылавливаем и отправляем в “службу наказания”. У нас пользователю (даже самым крутым программерам) категорически и под страхом смертной казни, на бумажном уровне, запрещено ставить софт не относящийся к их проф.деятельности.”

“Поймаем - накажем. Человеку разъясняются последствия нарушения инструкции и он подписывает бумажку. Потом все что он делает - делает на свою задницу и прекрасно это понимает.”

Тут остается открытым вопрос, что именно и как закреплять на бумажном уровне, поскольку излишний бюрократизм не есть двигатель прогресса. Некоторые руководители вообще склонны считать, что сотрудник сам должен соображать, что не относящаяся к профессиональной деятельности активность на рабочем месте приравнивается к банальному воровству, и склонны карать без предварительного ознакомления сотрудника с теми или иными требованиями. Хозяин-барин, и нечего мне тут добавить.

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

“Ставишь юзверам лимит по трафику + логинство типа sarg (где четко видно, когда и куда он зашел) + delay-pools или ограничение трафика на более низком уровне. Тогда юзверу2 (“ запрещенному”) придется много платить юзверу1(“ разрешенному”) за прокси (психологическая атака на юзвера :)”.

Кстати говоря, тема бюрократического администрирования и человеческого взаимодействия босс-админ-юзер редко поднимается в “СР”. А зря. Как выяснилось – это неотъемлемая и важная часть нашей нелегкой работы. Активизируйтесь, читатели! Пишите письма и рассказывайте свои реальные сисадминские байки. Regardz, всетакое,

Вместе со мной статью (сами об этом не догадываясь) писали: Star__ (автор вопроса, послужившего темой этой статьи), ntlm, Andrey, MF_FLIP, vlad, Sergey, LMax, pinkpiton, Botva, BartSimpson, VZ и другие.

Alice D. Saemonsr@nestor.minsk.by
обсуждение статьи