Архив

Публикации с меткой ‘TMG’

Ошибка в консоли TMG 2010: An error has occurred in the script on this page. Line 283. Char 13. Error: Invalid argument

16 ноября 2011

Столкнулся с проблемой после установки Forefront TMG 2010 на сервер под управлением Windows Server 2008 R2: консоль управления выдавала сообщение об ошибке выполнения скрипта на странице. Цитата:

An error has occurred in the script on this page.
Line: 283
Char: 13
Error: Invalid argument.
Code: 0
URL: file:///C:/Program%20Files/Microsoft%20Forefront%20Threat%20Management%20Gateway/UI_HTMLs/Generic.htm?guid=%7BF1BF89DE-2B7A-4BF4-9944-05434FC5854F%7D

И фото на память:

Продолжение или отказ выполнения скрипта ни к чему не приводили: TMG оставался неуправляем и в том, и в другом случае.

Решение:

1) открываем файл C:\Program Files\Microsoft Forefront Threat Management Gateway\UI_HTMLs\TabsHandler\TabsHandler.htc в Блокноте;

2) выполняем поиск по выражению «paddingTop». Должны вернуться 3 строки;

3) перед найденными строками добавляем «//», без кавычек, ествественно:

4) сохраняем файл;

5) перезапускаем консоль управления TMG и видим…

Вуаля!

Default ,

Настройка сетевых интерфейсов MS ISA/TMG

30 сентября 2011

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

Можно было бы, конечно, поворчать, да подзакидать администраторов (на моей практике — 9 из 10) гнилыми помидорами, но оставим. Жизнь научит. Лично знаком с практикующим ИТ-специалистом, который стал делать бэкапы и уделять внимание ИТ-безопасности только после второго увольнения (далеко не по собственному желанию). К делу.

Абстрагируясь от вышеописанного аудита, я предлагаю рассмотреть наиболее распространенный в SMB сценарий, когда TMG оснащен двумя сетевыми интерфейсами, один из которых смотрит в Интернет, а второй — в локальную сеть:

Первое, что требуется сделать еще ДО установки TMG, — это правильно наименовать интерфейсы. Local Area Network #2, конечно, ничего себе имечко, но, во-первых, оно не позволяет сходу определить, куда смотрит интерфейс, и, во-вторых, усложняет администрирование из командной строки, где имена интерфейсов приходится вводить вручную (ввести с клавиатуры «WAN» и «Local Area Network #2» не одно и то же, правда ведь?). Обычно используются варианты Internal или LAN для внутренней сети и External, Internet или WAN для внешней. Взращенный на ICND, я привык мыслить в терминах, предложенных в ней, поэтому ратую за WAN (Wide Area Network) и LAN (Local Area Network):

После переименования, перейдем в Advanced Settings сетевых подключений:

Здесь мы определим порядок опроса сетевых интерфейсов клиентом DNS и выключим ненужные (и ВРЕДНЫЕ!) сетевые службы. На интерфейсе LAN обычно принято выключать «File and Printer Sharing for Microsoft Networks», т.к. редко встречаются сценарии совместного использования сервера TMG и файловых служб. Но у меня именно такой сценарий, поэтому на скриншоте ниже в LAN включены все службы. А вот на WAN-интерфейсе НЕОБХОДИМО отключить и «Client for Microsoft Networks», и «File and Printer Sharing for Microsoft Networks». Вы же не используете функциональность Windows-сети вне периметральной и локальной сетей? (если используете, то советую немедленно удалить себе глаз столовой ложкой в качестве наказания) Чтобы недоброжелатели тоже не смогли ее использовать, отключайте.

Что касается клиента DNS, то тут действует следующий алгоритм:

1. Вы выполняете http-запрос к хосту host1.network.local с хоста TMG, включенного в домен network.local. В домене network.local действует DNS-сервер dns.network.local, адресующий зону network.local и использующий root hints для разрешения имен вне зоны network.local.

2. В Advanced Settings определен порядок опроса DNS-серверов, настроенных в каждом из подключений. Верхней позицией определен интерфейс LAN, настроенный на использование DNS-сервера dns.network.local. Следовательно, ваш запрос для разрешения имени host1.network.local уйдет на сервер dns.network.local, знающий о существовании хоста host1, и немедленно разрешающий этот адрес. Success.

Если бы вы выполняли запрос к серверу ya.ru (например), то dns.network.local разрешил бы и его с помощью root hints. Опять же success.

Если же вы бы определили иной порядок, поставив WAN выше LAN, то запрос к хосту из локальной сети сперва ушел бы на публичный или провайдерский DNS-сервер. Это чревато: а) задержками в разрешении имен; б) раскрытием информации об узлах вашей локальной сети.

Теперь можно углубиться в настройку самих интерфейсов, в частности, параметров TCP/IPv4. Начнем с LAN:

Первое, что бросается в глаза — это отсутствие шлюза по умолчанию. TMG сам себе шлюз. DNS-серверы — внутренние. Открываем «Advanced…» и переходим на вкладку «WINS»:

Первое, что стоит сделать — это отключить LMHOSTS lookup. Этот параметр включает разрешение имен с помощью статического файла lmhosts вперед DNS и WINS. Нам это ни к чему, особенно в свете того, что hosts-файлы часто являются объектами для атаки вредоносного ПО. Прочитайте внимательно пояснение над чекбоксом: LMHOSTS lookup — глобальный параметр, поэтому его отключение на одном интерфейсе автоматически приведет к отключению на всех. Что нам только на руку.

В части NetBIOS замечу, что его использование в LAN вовсе не во вред, но при действующей службе DNS бесполезно, поэтому его тоже можно перевести в режим «Disabled». В моей демонстрационной сети NetBIOS включен, т.к. через него работает одно довольно древнее приложение.

Перейдем к настройкам WAN-интерфейса:

Это контрольная точка для проверки «на отключенность» клиента сетей Microsoft и функций File and Printer Sharing.

В свойствах внешнего интерфейса не принято указывать DNS, если работает внутренняя служба. Опять же, мой частный случай — это мой частный случай. Идем в «Advanced…»:

Во вкладке «DNS» снимите галочку с параметра «Register this connection’s addresses in DNS». Ни к чему нам регистрировать это соединение на публичных или провайдерских DNS-серверах.

Во вкладке «WINS» отключите NetBIOS. Во внешней сети он не нужен, это тоже одна из брешей.

Что мы получаем в итоге? Хорошо защищенную систему, лишенную «детских болезней», ценой 5 минут вашего времени. Ну не кошерно ли?

На этом можно раскланиваться. Чтите секьюрность и будьте счастливы.

Default , ,

Не работает upload данных по FTP через шлюз Microsoft TMG

22 марта 2011

Проблема: при попытке загрузить данные на внешний FTP-сервер из сети, спрятанной за NAT’ом на Microsoft TMG 2010 (к ISA тоже применимо), возникает ошибка 550.

Объяснение: в правилах исходящего трафика, созданных мастером TMG, определена политика FTP «только для чтения».

Решение:

1. Найдите ваше правило, разрешающее FTP наружу. У меня оно выглядит так:

2. Нажмите на правило правой кнопкой мыши, чтобы вызвать контекстное меню. Выполните команду «Настроить FTP»:

 

3. Снимите галочку с «Только для чтения»:

4. Примените изменения. Вуаля!

Default , ,