Андрей Бешков

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

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

Например, для UNIX-платформ характерны решения на основе межсетевого экрана и прокси-сервера, который может работать как на шлюзе, так и на отдельной машине. Самыми часто используемыми прокси-серверами являются Squid, Delegate, Socks. Для каждого из них написана большое количество разнообразных скриптов, которые анализируют протоколы запросов, поступавших к прокси-серверу от пользователей, и на их основе строят отчеты. К сожалению, такие подсчеты являются весьма приблизительными, так как в них не учитываются сетевые протоколы нижнего уровня. Возьмем, к примеру, ситуацию, когда пользователь скачивает из Интернета файл по протоколу HTTP. Предположим, что в качестве транспорта используется протокол TCP/IP, который отвечает за гарантированную доставку пакетов. Если какой-то из пакетов будет испорчен во время путешествия через сеть, то отправитель по запросу получателя пошлет его заново. И такая ситуация может повторяться много раз. Испорченные пакеты отбраковываются раньше, чем попадут к приложению прокси-сервера. Таким образом, получается, что статистика использования канала, выдаваемая прокси-сервером, будет весьма отличаться от количества данных, реально переданных по каналу связи. Этот недостаток можно исправить, если кардинально изменить систему учета трафика. Теперь мы будем считать количество пакетов, прошедших через межсетевой экран. К сожалению, в этом случае нам скорее всего придется отказаться от услуг прокси-сервера, потому что все запросы пользователей будут направлены ему. А с точки зрения межсетевого экрана во внутренней сети будет находиться единственная машина, потребляющая львиную долю трафика. Думаю, всем понятно, что именно прокcи-сервер будет этой машиной, так как межсетевой экран не имеет никакого понятия об остальных компьютерах, потому что они не обращаются к нему напрямую. В ситуации, когда от возможностей, предоставляемых прокси-сервером, отказываться не хочется, наиболее простым выходом будет ведение двойной статистики. Одна по количеству и размеру пакетов, обработанных межсетевым экраном, а вторая по количеству запросов от пользователей и размерам файлов, кочевавших между пользовательскими рабочими станциями и прокси-сервером. На самом деле это не такая уж и сложная проблема. За многие годы эксплуатации администраторами этих систем придумано достаточно много уловок, позволяющих избавиться от большинства неудобств вышеописанных методов. Впрочем, обсуждение столь сложных вопросов выходит далеко за рамки данной статьи. Рассмотрев методики контроля за потреблением интернет-трафика, наиболее часто применяемые в Unix-системах, давайте сделаем то же самое и для комплексов, работающих на основе Windows.