Один из наиболее распространенных вопросов, которые я видел форумах ISAServer.org состоит в том, как получить информацию об URL и пользователе в журналах и сообщениях брандмауэра ISA 2004. Брандмауэр ISA создает свои отчеты на основе обобщения журналов (логов), которые в свою очередь образуются из информации фильтра Web Proxy и журналов службы брандмауэра. Если вы хотите увидеть пользовательскую информацию и URL (вместо IP-адресов) в отчетах, прежде всего необходимо чтобы эта информация попала в журналы (логи).
Как записать URL и информацию о пользователе в журналах и отчетах брандмауэра ISA 2004
Чтобы пользовательская информация попала в логи, вам необходимо сделать следующее :
Важно: Эта статья не является всеобъемлющим отчетом о возможностях настройки журналов и отчетов брандмауэра ISA.
Фильтр Web Proxy и служба брандмауэра записывают имена пользователей по умолчанию (фильтр Web proxy если правило требует идентификации). Однако возможно, что кто-то запретил вести журнализацию имен пользователей. Можете убедиться, что опция Client user name выбрана в диалоговом окне Firewall Logging Properties:
Рисунок 1
Обратите внимание, что в меню Firewall Logging Properties нет опции для регистрации URL. Причина этого в том, что клиент брандмауэра не посылает URL для Web-сайтов, доступных через клиента брандмауэра. Однако, мы исправим эту проблему позже путем настройки клиента Web proxy.
Теперь мы должны подтвердить, что журналы фильтра Web proxy включают поля имени пользователя и URL так, чтобы эта информация появилась в журналах и отчетах брандмауэра ISA:
Рисунок 2
Заметьте, что только журнал фильтра Web Proxy поддерживает информацию URL. Это важно поскольку это подтверждает, что клиенты должны быть настроены как клиенты Web proxy (или использовать фильтр LogHostname)
Пользовательская информация, связанная с запросом доступна только когда запросы посланы Web Proxy и/или клиентами брандмауэра. Клиент SecureNAT не может послать пользовательскую информацию по запросу. Клиент SecureNAT не может сделать это, потому что соединения SecureNAT — не передаются брандмауэром ISA или на службу брандмауэра.
Прокси-соединения — клиент-серверные и клиент требует собственной программной компоненты. Но нет никакого программного обеспечения клиента, чтобы послать пользовательскую информацию брандмауэру клиентам SecureNAT . Клиентские запросы Web Proxy и брандмауэра проходят брандмауэр ISA используя программное обеспечение клиента брандмауэра и конфигурацию Web-браузера.
Пользователи клиента брандмауэра должны быть зарегистрированы в том же домене, что и брандмауэр ISA, или быть зарегистрированы в доверенном домене. Клиент брандмауэра всегда пропускает пользовательские удостоверения, и клиент брандмауэра всегда посылает пользовательские удостоверения, даже когда правила доступа не требуют идентификации.
Вы можете сказать что когда клиент брандмауэра послал пользовательские удостоверения брандмауэру ISA для установлениия соединения не требующего идентификации из-за того что вопросительная пометка появится рядом с именем пользователя в таблице Session закладки Monitoring . Служба брандмауэра никогда не требует у пользователя сертификатов. Если Вы видите регистрацию в меню то это не служба брандмауэра спрашивает у Вас удостоверение.
ВНИМАНИЕ:
Это действительно серьезный вопрос. Чтобы надлежащим образом настроить систему установления подлинности, авторизации, контроля доступа и поддержки протокола, обеспеченнуя клиентским программным обеспечением брандмауэра, брандмауэр ISA должен быть членом пользовательского или доверенного домена. Вы проигрываете и в безопасности брандмауэра ISA и в гибкости, если не делаете брандмауэр ISA членом домена.
В отличие от схемы идентификации клиента брандмауэра, пользователь не обязательно должен быть зарегистрирован в домене при использовании клиента Web Proxy и брандмауэр ISA не должен быть членом домена. Однако, в любом случае если пользователь не зарегистрирован в домене, то точной идентификации через установление подлинности не будет. Если базовая идентификация разрешена, то регистрация пользователя может быть зафиксирована в меню .
Чтобы настроить пользователей как клиентов Web Proxy и клиентов брандмауэра, вам необходимо:
Выполните следующие шаги чтобы настроить брандмауэр на пользователей:
Рисунок 3
Следующим шагом будет настройка Web proxy listener в этой же сети:
Рисунок 4
Рисунок 5
Вы можете многое сделать, чтобы настроить клиентов брандмауэра и Web proxy в брандмауэре ISA. Смотрите главу про типы клиентов ISA в моей книге для подробностей.
Следующим шагом будет установка клиентской части брандмауэра ISA на компьютерах пользователей. На самом деле чтобы установить клиентскую часть ISA вы должны установить клиентскую часть и на самом брандмауэре, либо на файл-сервере в вашей сети. Я настоятельно рекомендую вам установить ее на файловом сервере, если вы не хотите разрешать SMB/CIFS соединения на брандмауэре ISA. Вы можете установить клиента брандмауэра с помощью автоматического меню, которое появляется когда вы вставляете диск ISA Server 2004 в свой CD-ROM.
Если Вы не будете устанавливать клиента брандмауэра, вы можете все равно получать имена пользователя и URL из файлов системного журнала и сообщений путем настройки Web-браузеров как
Ключевое значение здесь имеет то, что пользователи настроены как клиенты Web proxy. Клиенты Web proxy смогут отправлять пользовательские удостоверения, запрашиваемые фильтром Web proxy брандмауэра для идентификации. Клиенты SecureNAT не будут опрашиваться и не смогут предоставить удостоверения. Кроме того, только соединения клиентов Web proxy зарегистрируют URL в файлах журналов . Соединения клиентов брандмауэра и SecureNAT не смогут зарегистрировать информацию об URL в журналах и все что вы увидите — будут IP-адреса. Единственное исключение — если бы вы установили ПО LogHostname на брандмауэр ISA.
Вообще, политика брандмауэра ISA firewall policy должна формироваться используя следующие принципы:
В действительности, конфигурация хорошо обработанной политики брандмауэра, которая делает точно то, что требуются для безопасности, немного более сложна. Посмотрите мою статью ISA Server 2004 Firewall Policies на http://techrepublic.com.com/5100-6345_11-5579216.html?tag=search — описание лучшего способа формирования политик брандмауэра ISA и правил для оптимальной безопасности и работы.
Ключ к получению имен пользователей и URL в файлах системного журнала в том, чтобы убедиться, что Вы не создаете никаких анонимных, разрешающих или запрещающих правил относящихся к сайтам пользовательскую информацию которых вы хотите получить. Пока клиент брандмауэра будет всегда посылать пользовательскую информацию брандмауэру, клиент Web proxy не будет посылать пользовательскую информацию, если установление подлинности не требуется.
Например, единственными анонимными правилами доступа должны быть те, которые требуются для доступа сервера к Интернету. Так как серверы обычно (и не должны) регистрировать пользователей, вы должны создать анонимные правила доступа разрешающие или запрещающие соединения этих серверов (контроль доступа для серверов обычно делаются, используя исходный IP адрес). Все другие правила должны требовать от пользователя установления подлинности как от клиента Брандмауэра, так и от клиента Web proxy, или же от обоих.
Обратите внимание, что следующая причина, почему ваши анонимные правила доступа формируются для только серверов, состоит в том, что серверы не должны иметь установленного программного обеспечения клиента брандмауэра. Хотя они могут быть настроены как клиенты Web proxy если серверы требуют доступа Web proxy, когда нет зарегистрированного пользователя, правило идентификации доступа будет причиной отказа для сервера соединиться с Интернетом.
В этом статье я объяснил что чтобы получить имена пользователей в файлах системного журнала вы должны настроить ваших пользователей как клиентов брандмауэра, или Web proxy клиентов, или и тех и тех. Другого пути нет. Нет ничего такого в TCP, UDP, IP или ином «пакетном» заголовке что даст пользовательской информации возможность быть помещенной в журналы клиентов SecureNAT. Клиенты брандмауэра обеспечат пользовательскую информацию в журналах для всех приложений Winsock используемых для соединения с Интернетом (по существу все TCP и UDP приложения) и настройка клиента Web proxy позволит пользовательской информации появиться в журналах соединений Web (HTTP/HTTPS/HTTP-туннель FTP).
Чтобы получить информацию об URL в журналах и сообщениях, вы должны настроить пользователей как клиентов Web proxy. Клиент брандмауэра и соединения клиента SecureNAT не дают информацию об URL в логах, будут видны журналах только IP-адреса для сайтов, посещенных клиентами брандмауэра и SecureNAT. Там что здесь вы ничего не можете сделать.
Итак, до сих пор нельзя было ничего с этим поделать. Сейчас мы уже можем не страдать от отсутствия URL в файлах системного журнала для клиентов брандмауэра и SecureNAT. Почему? Потому что Collective Software (www.collectivesoftware.com) выпустило Loghostname Web Filter!
Фильтр Loghostname Web filter волшебным образом преобразовывает файлы системного журнала в брандмауэре ISA, чтобы обеспечить информацию URL для сайтов, посещенных клиентами Брандмауэра и SecureNAT. Если по каким-то причинам Вы не сможете сделать ваших пользователей клиентами Web proxy (хотя вы должны всегда использовать конфигурацию клиента Web proxy — но ведь администраторы не всегда делает то, что является лучшим для них), то Loghostname от Collective Software (www.collectivesoftware.com) — это мечта, которая сбылась.
Важный момент, на который стоит обратить внимание — фильтр Loghostname является фильтром Web. Поскольку это фильтр Web, он связан с фильтром Web proxy брандмауэра ISA. Все связи, установленные фильтром Web proxy брандмауэра ISA регистрируются в журнале Web proxy. Обратите внимание, что запросы клиентов SecureNAT и брандмауэра автоматически переадресуются на Web proxy фильтр брандмауэра ISA когда фильтр Web proxy связан с HTTP протоколом. Если Вы разделяете фильтр Web proxy с протоколом HTTP, то соединения клиентов SecureNAT и клиентов Брандмауэра не будут автоматически переадресованы на фильтр Web proxy, и Loghostname не сможет регистрировать имена хостов в журнале Web proxy. Фильтр Web proxy должен быть разрешен на HTTP протоколе (который установлен по умолчанию во всех брандмауэрах ISA) чтобы имена хостов Интернета появились в журнале Web proxy брандмауэра ISA.
Loghostname — это простой Web фильтр, устанавливаемый файлом .msi. Просто скачайте его с http://www.collectivesoftware.com/Products/ и двойной щелчок автоматически установит фильтр. После установки Web-фильтра перезапустите службу брандмауэра.
Вот как выглядит журнал для соединения клиента SecureNAT перед установкой Loghostname:
Рисунок 6
А с Loghostname журнал клиента SecureNAT выглядит так:
Рисунок 7
Здорово, да?
Брандмауэр ISA облегчает получение детальной информации о пользователе в файлах журналов Web Proxy и брандмауэра. Вам просто нужно принудить всех пользователей использовать брандмауэр и конфигурацию клиента Web Proxy, настроить журналы для записи пользовательской информации, запретить правило допускающие анонимный доступ, за исключением необходимых для серверов, которые должны получить доступ в Интернет без регистрации. Вы также можете получить информацию об URL в журналах брандмауэра ISA путем настройки пользователей как клиентов Web Proxy, или путем установки фильтра Loghostname. Я обычно создаю эту конфигурацию, потому что главный фактор в безопасности — отчетность. Единственный способ получить отчетность состоит в том, чтобы требовать от пользователей установления идентификации. Такой уровень журнализации может быть также необходим в средах, с высокими требованиями.
www.isaserver.org
Tags: dns, ftp, ISA Server, mac, monitoring, nat, proxy, redirect, search