Forefront TMG Beta3: звіт про 3-х місячному тестуванні

1. Деякі пояснення по топології
2. резюме

Наша взаимовыгодная связь https://banwar.org/

У цій статті мова піде про тестування нового продукту Microsoft - Forefront Treat Management Gateway (TMG).

Дмитро Дурасов,
MCP, консультант по ІБ, системний адміністратор Windows-based IT.
www.itsecurityconsult.com

У липні 2009 року в одному з новинних бюлетенів Microsoft я прочитав про вихід третьої бета-версії нового продукту, покликаного замінити MS ISA Server 2006 - Forefront Treat Management Gateway - або скорочено TMG.

Що мені відразу привернуло в цьому продукті - це вбудована в TMG можливість балансування навантаження і забезпечення відмовостійкості Інтернет-з'єднання. Мені здається, що цю функцію слід реалізувати давно, бо тема періодично піднімається на форумах і забезпечення відмовостійкості і балансування навантаження для Інтернет-з'єднання є досить затребуваною, але, на жаль, ISA цього функціоналу не надає.

Відразу звернули на себе увагу значно зрослі, у порівнянні з попередником, системні вимоги - TMG вимагає мінімум 2 GB RAM і працює тільки на 64-бітної ОС Windows Server 2008. Для сучасного сервера це, звичайно, невисокі вимоги, але на старому обладнанні, де цілком успішно працював ISA Server 2006, новий TMG працювати вже не буде.

Для цілей тестування TMG було вирішено встановити на віртуальну машину, на сервер під керуванням Windows Server 2008 Hyper-V. Попередньо були сконфігуровані мережеві адаптери. Схема топології мережі:

Деякі пояснення по топології

Ця топологія 3-Leg Perimeter, «ніг» у неї, звичайно, більше, але суті це не міняє.

Окремо виділена гостьова мережа, підключення до якої можливо по Wi-Fi, вона створена для мобільних користувачів і гостей. У внутрішню мережу доступу вона не має, обмежуючись корпоративним порталом, OWA і доступом в Інтернет.
Внутрішня мережа сегментована на мережу Datacenter Network, де розташовуються сервера, і мережа Internal Network, до якої підключені комп'ютери користувачів.

У мережі Perimeter Network розташовані Web сервера, які публікуються в Інтернет.

Зовнішні мережі додатково захищені за допомогою простих Packet-filtering міжмережевих екранів, вони зазвичай вбудовані в більшість точок доступу і DSL модемів. Це додатково захищає мережу від різного мережевого сміття, і так само ховає сам TMG за NAT.

Не бачу сенсу наводити скріншоти при установці, слід зауважити лише те, що вона пройшла без проблем і не сильно відрізнялася від процедури встановлення тієї ж ISA.

Мої основні клієнти відносяться до сегменту small and medium business, тому тестування проводилося щодо застосування TMG саме в цьому сегменті, для цього був обраний TMG Standard Edition, який зазвичай в невеликих компаніях встановлюється в одному екземплярі.

Тестова конфігурація віртуальної машини:

Windows Server 2008 Ent. 64-bit SP2, TMG Standard Edition, 2 GB RAM. Даний сервер в домен вводити не планувалося, TMG був встановлений в workgroup mode.

Є різні доводи за і проти розташування TMG в складі домену або як standalone сервера, в даному випадку сервер в домен не входить і весь функціонал, який TMG може отримати, працюючи в домені, використаний не був. Якщо слідувати принципу "Least privileges", то наявність TMG в домені збільшує площу атаки. Але в будь-якому випадку, оптимальний захист - це баланс між функціональністю і безпекою, і як чинити вирішувати Вам. Єдина проблема, з якою я зіткнувся - це коректна публікація OWA. ISA може коректно публікувати OWA в workgroup mode, цей процес детально описується в літературі (зокрема, я, як настільну книгу використовую "Microsoft ISA Server 2006 Unleashed" Michael Noel). Намагаючись робити за аналогією, з TMG бажаного результату я не добився. Власне, довгі танці з бубном не планувалися, тому це завдання я вирішив в тестовому середовищі за допомогою звичайної публікації сервера через HTTPS. Я впевнений, що будь TMG в домені, OWA був би опублікований коректно. Я не виключаю, що, можливо, щось робилося неправильно, але відсутність документації і більш-менш осудних рекомендацій в Інтернеті роблять деякі, начебто прості речі, важко здійснюваним. В Інтернеті взагалі мало інформації по TMG і на TechNet можна часто зустріти описи, подібні до цього:

А огляди TMG в Інтернеті - це зазвичай набір знімків екрану при установці плюс кілька знімків консолі управління. Вони не блищать інформативністю, а прочитати те, що написано під кнопкою я можу і сам. Очікувати більшого, звичайно, на даному етапі дивно, бо функціонал змінюється від однієї бета-версії до іншої, але, тим не менш, є досить цікаві блоги, де люди всерйоз тестують TMG. Наприклад, ось: http://www.carbonwind.net/blog/

Отже, які основні завдання ставилися при тестуванні.

1. Перевірити, як працює ISP Redundancy.
2. Подивитися, що нового.

Почну по порядку.

ISP Redundancy. TMG вміє забезпечувати відмовостійке з'єднання з Інтернетом, використовуючи резервні канали зв'язку. При цьому він має два режими використання:

1. Балансування навантаження між каналами.
2. Обхід основного з'єднання в разі аварії і перехід на резервний канал.

Плюси і мінуси варіантів. Перший варіант, коли трафік балансується між двома каналами має сенс застосовувати при наявності декількох каналів з певною пропускною здатністю. Якщо канали мають різну смугу пропускання, то можна задати навантаження для кожного з них. Це дозволяє зробити з двох вузьких один широкий канал, при цьому аварія у одного з провайдерів не спричинить за собою глобальної припинення доступу в Інтернет, але, швидше за все, зробить роботу користувачів некомфортною.

Другий варіант хороший тим, що можна підключити один широкий канал з гарантованою купленої пропускною здатністю (наприклад, оптоволокно), а в якості резервного використовувати канал з оплатою по трафіку (наприклад, використовуючи технологію DSL). Це дозволить гарантовано забезпечити доступ в Інтернет на необхідної швидкості, при цьому не треба платити за гарантовану смугу пропускання два рази.

При плануванні відмовостійкості врахуйте, що вона функціонує тільки для організації доступу через NAT.

Я тестував як перший, так і другий варіант. Слід зауважити, що балансування навантаження, як мені здалося, працює за досить дивним алгоритмом. Наприклад, в тестовому середовищі були використані два з'єднання від різних провайдерів, одне - +1024 Kbit, друге 128 Kbit. Утилізація каналів була розподілена як 80% трафіку йде через мегабітний канал, 20% - через 128 кілобітний канал. Так ось. Користувачі в основному використовують мегабітний канал. Але, після певного часу використання, іноді мегабітний канал починає практично простоювати і весь трафік йде через вузький, 128 кілобітний канал, що викликає, природно, гальмування.

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

"Because of the specifics of the load balancing algorithm explained above , it is possible that a bandwidth-consuming session will be assigned to the" slower "ISP connection and will lead to an incorrect load balancing ratio ." - запис від 5 жовтня 2009 року J
Рекомендую підписатися на їх RSS стрічку: http://blogs.technet.com/isablog/rss.xml

Безпосередньо відмовостійкість з'єднання з Інтернетом. Відмовостійкість працює нормально. Правда, TMG трохи задумливий, і на визначення того, що канал помер йде десь 1-2 хвилини. Тобто повністю seamless цю процедуру не назвеш.

Можна сказати, що функція відмовостійкості є, вона працює, і варто сподіватися, що її робота буде відшліфована і представлена ​​у всій красі в фінальному релізі.

Наступна цікава нова функція - це Malware Inspection.

TMG самостійно оновлює сигнатури з сайту Microsoft і сканує весь вхідний контент на наявність вірусів і spyware. При серфінгу це відбувається непомітно для користувача, однак, якщо необхідно завантажити файл, то він буде спочатку отриманий і перевірений TMG, а вже потім тільки його дадуть скачати користувачеві. З боку користувача це виглядає ось так:

Відповідно, якщо вірус буде знайдений, то користувач побачить попередження.

Слід врахувати, що вірус все ж скачати можна. За замовчуванням TMG не виконує сканування HTTPS трафік, і вірус може бути завантажений, якщо доступ здійснюється по протоколу HTTPS.

Ось тому приклад - через HTTPS з'єднання вірус успішно скачати і був відразу ж виявлений Windows Defender'ом.

Але, це не проблема - все передбачено. Включаємо інспекцію HTTPS і генеруємо сертифікат для TMG.

Оскільки сеанс тепер контролює TMG, то користувач відразу побачить попередження

Після увімкнення режиму HTTPS інспекції TMG успішно сканує зашифрований трафік.

Природно, користувачам необхідно встановити сертифікати CA TMG на комп'ютер, щоб не бачити повідомлень про помилку сертифіката в подальшому.

Але, тоді виникає питання - а як же користувач буде знати, що сертифікат сайту дійсний? Чи не буде це компрометувати одне з призначень сертифікату - ідентифікувати власника ресурсу? Ні.

TMG перевірятиме і блокувати сайти з неправильними сертифікатами. Якщо ж користувачеві все одно буде потрібен доступ до цього сайту, його можна додати в список виключення. Слід зауважити, що при блокуванні користувач отримує зовсім неінформативне вікно такого змісту:

Мені здається, що це неправильно і може спричинити додаткові зайві звернення до системного адміністратора, я думаю, що розробники це врахують і помістять більш інформативне повідомлення, що доступ блокований, тому що сертифікат недійсний.
Налаштування блокування можна змінити, але я б не рекомендував цього робити.

Я помітив некоректну роботу режиму HTTPS фільтрації з деякими HTTPS сайтами, зокрема з Live.com і ще з деякими сайтами. Якщо таке відбувається, то адміністратор може додати необхідні сайти в розділ сайтів, які були виключені з інспекції HTTPS. Знову ж таки, не варто забувати що це бета-версія і TMG буде доопрацьовуватися і виправлятися.

Далі. Нова опція - фільтрація URL. Зараз Microsoft створює і буде підтримувати в актуальному стані базу URL адрес сайтів за різними категоріями. Всього пропонується близько 70 різних категорій, доступ до яких може бути дозволений або заборонений. Наприклад, можна обмежити доступ до пошукових машин і Web-email, або навпаки, дозволити доступ до категорії Dating / Personals, до якої відноситься сайт odnoklassniki.ru, скажімо, в обідній час і після закінчення робочого дня. Все у ваших руках. Слід зауважити, що багато сайтів не категоризуються і якщо ви плануєте впровадити жорстку політику категорій, то необхідно буде заборонити доступ до всього, крім дозволених категорій.

На бета-стадії продукту Microsoft попереджає, що категорії ще далекі від досконалості, але згодом вони будуть поліпшуватися і додаватися. Наприклад, ресурс porno.com не відноситься ні до однієї з категорій J і успішно показується, незважаючи на заборону демонстрації сайтів такого характеру. Забавно. За замовчуванням TMG блокує доступ до ресурсів порнографічного, рекламного та іншого сумнівного характеру.

Природно, все це гнучко настроюється. У разі, якщо користувач намагається зайти на заборонений ресурс, за умовчанням він отримує наступне:

Для аналізу, куди доступ користувачам слід вирішувати, а куди ні, можна уточнити, до якої категорії належить той чи інший сайт. Зокрема, як ми бачимо, securitylab.ru віднесений до категорії сайтів «Technical Information».

Нова функція TMG - E-mail Protection.
Як випливає з назви, вона покликана захищати електронну пошту. Але не все так гладко. E-mail Protection буде працювати тільки за двох умов:

1. Встановлений Microsoft Forefront Security for Exchange.
2. Встановлений Exchange Edge Transport Role.

Це не сильно радує. Я вважаю, що інтелектуальний міжмережевий екран повинен бути фаєрволом, і установка додаткового ПЗ потенційно робить його більш уразливим. Можливо, в рамках великої організації, спеціально виділені TMG сервера, які буде захищати тільки SMTP, цілком непогане рішення, але якщо TMG сервер єдиний (або array з двох серверів для забезпечення відмовостійкості) - це навряд чи гарне рішення. Мені незрозуміло, навіщо встановлювати додаткове ПЗ, якщо в TMG вже реалізовано сканування трафіку на віруси і інспекція SMTP з'єднань для запобігання низькорівневих атак на рівні протоколу. Що заважає так само сканувати SMTP трафік на віруси і блокувати спам безпосередньо силами TMG, включивши цей функціонал в міжмережевий екран? Я думаю, що це більше маркетинговий хід - практично не додаючи функціоналу, додати лише керуючу оснащення і розрекламувати як нова можливість захисту електронної пошти.

Загалом, E-mail protection я не тестував. Додатково встановлювати кілька серверів Exchange і стару Beta2 Forefront Security for Exchange у мене бажання не було. Тим більше, що вже вийшла версія FSE RC, яку TMG Beta3 не підтримує.
З цікавості я включив опцію E-mail protection, на що TMG відразу ж відреагував:

Більш детально механізм роботи E-mail Protection описаний тут: http://technet.microsoft.com/en-us/library/ee338733.aspx

Захист від вторгнень. Не може не радувати поява повноцінного функціоналу IDS / IPS. Звичайно, можливість захисту від вторгнень на низькому рівні присутня в ISA Server 2006, але в TMG ми бачимо набагато більш серйозну реалізацію і фундаментальний підхід.

Network Inspection System. Захищає мережу, перевіряючи трафік на утримання певних сигнатур.

Слід зауважити, що сигнатури Network Inspection System з'являються набагато швидше, ніж наступні за ними оновлення лінійки схильних до новим виявленим уязвимостям, продуктів. Зокрема, сигнатура нашумілої уразливості в реалізації протоколу SMB 2, до якої схильні Windows Server 2008 / Vista, була випущена через кілька годин в день виявлення.

Хочеться вірити, що бази будуть оновлюватися з такою ж оперативністю і далі.

Так само ми бачимо нову вкладку Behavioral Intrusion Detection. Там знаходиться управління функціями, аналогічними в ISA 2006 Server - низкоуровневая інспекція трафіку.

Найцікавіше - Behavioral IPS - на жаль не працює. Документація геть відсутня.

Наскільки я розумію, реалізація Behavioral Intrusion Prevention System здійснюється в інтеграції з новим продуктом Forefront codename Stirling. Я не тестував і не встановлював Stirling, але, взагалі мене це заінтригувало.

Природно, мені було цікаво, як себе веде TMG при скануванні на уразливості, а так само як утилізується канал при проведенні сканування. Я не міняв настройки за замовчуванням, які задані в TMG Flood Mitigation Settings. За допомогою більш тонкої настройки можна істотно знизити утилізацію каналу при скануванні, але тут головне, щоб ці настройки не торкнулися нормальну роботу користувачів. В оснащенні Flood Mitigation з'явилася нова закладка SIP Quotas, яка, як випливає з назви, покликана вирішити проблеми, що можуть виникнути при транзиті голосового трафіку через TMG.

Для сканування я скористався зовнішнім Інтернет-сервісом від Qualys. Якщо Вам цікаво, Ви теж можете протестувати свій IP адреса. Тестування займає близько 15 хвилин. Один адреса тестується безкоштовно. Провести тестування свого IP можна за посиланням: http://www.qualys.com/forms/trials/qualysguard_free_scan/

Я не приділяв багато часу тонкій настройці TMG. В основному, все було налаштоване, так би мовити, за замовчуванням. Як видно зі схеми топології мережі, TMG знаходиться за низькорівневими packet-filtering міжмережевими екранами. Це рекомендований рішення, дозволяє відрубувати більшу частину сміттєвого трафіку і приховує безпосередньо TMG за NAT. З PF Firewalls на TMG проброшени наступні порти: 25 (SMTP), 80 (HTTP), 443 (HTTPS), 3389 (RDP). Всі інші порти закриті. Власне, проводячи це тестування, я не розраховував, що будуть виявлені які-небудь уразливості, але мені було цікаво, як себе буде вести TMG, як буде спрацьовувати механізм NIS і чи позначиться це на продуктивності сервера.

Як я і очікував, тестування вразливостей не виявило. Ви можете бачити, що в звіті відображено те, що SSL сертифікат є саморобним (це дійсно так), а так само потенційну вразливість протоколу SSL 2 і рекомендацію застосовувати протокол SSL третьої версії. Це все.

NIS відпрацювала як годиться, видавши купу алертів.

Утилізація процесора під час сканування практично непомітна.

Чого не скажеш про трафік. Під час проведення сканування надсилається безліч HTTP запитів, які обробляються TMG і на маленький запит від сканера TMG відправляє згенерувала сторінка такого вигляду:

Це утилізує канал. Я не знайшов, де можна замінити цю сторінку на щось більш легке. Звичайно ж, для ефективної взаємодії слід більш жорстко обмежити кількість сесій з одного зовнішнього IP адреси і допустима кількість оброблюваних HTTP запитів (за замовчуванням коштує 600 IP і 600 HTTP запитів в хвилину з одного IP адреси).

Графік утилізації каналу наведено нижче. Червона лінія - вхідний трафік, зелена - вихідний. Масштаб по осі Y - 400 Kbit / s в верхній точці знімка екрана. Фрагмент графіка показує сканування HTTP. При скануванні SMTP утилізація каналу практично відсутня. Графік знімався безпосередньо з порту, до якого приєднаний TMG.

Ще раз повторюся, що метою тестування була комплексне проведення тестування на проникнення, а спостереження, як реагує на ці дії міжмережевий екран.

Решта нововведення. Я розглянув основні Особливості и нововведення, Які становляться Найбільший Інтерес и Які тестуваліся мною особисто. Я не ставив перед собою за мету найти в консолі 10 відмінностей между ISA 2006 и TMG. Смороду є, їх цікаво потікаті Ведмедики и поексперіментуваті. Якщо Ви працювали з ISA, то перехід до TMG не викличе ніяких труднощів.

резюме

E- mail Protection. Фактично, ця опція є лише оснащенням, інтегрованої в консоль управління TMG сервера. Так, це зручно, полегшує конфігурування і моніторинг, зводячи все в одне місце, але безпосередньо функції захисту пошти реалізуються за допомогою установки додаткового ПЗ.

Фільтрація URL. Безперечно, корисна функція, поки ще працює досить умовно через далеко не повною бази URL. Розробники настійно просять, якщо ви використовуєте TMG Beta3, встановити пакет телеметрії, який буде допомагати їм формувати цю базу. Завантажити пакет можна за посиланням:
http://www.microsoft.com/downloads/details.aspx?FamilyID=f7e5907d-60ae-4f39-8660-9a959db5a6e6
Forefront TMG RC вже буде містити його відразу.

Забезпечення відмовостійкості і балансування Інтернет-з'єднань. Давно бажана річ, яка реалізована тільки зараз. До цього доводилося використовувати апаратні або програмні рішення від інших виробників. Сподіваюся, що алгоритм роботи цієї функції буде покращено.

Network Inspection System і Malware Inspection. Так само не може не радувати. Суттєво зменшує поверхню атак, успішна реалізація цих функцій безпосередньо залежить від швидкості оновлення сигнатур. З огляду на те, що Microsoft серйозно націлився на ринок антивірусного ПО, можна наїдяться, що вони будуть оновлюватися оперативно.

Як видно, Forefront Threat Management Gateway значно відрізняється від MS ISA 2006, це вже не окремий продукт, а тісно інтегроване в середу Forefront рішення, покликане забезпечити Edge Security Підприємства. Повністю свої можливості він розкриває тільки у взаємодії з іншими продуктами лінійки Forefront.

Я розглядав TMG Beta3, але 1 жовтня вже був анонсований вихід TMG Release Candidate, який скоро повинен стати доступний для скачування і тестування. Після виходу RC, слід оновити TMG, тому що RC містить оновлений движок NIS і сигнатури NIS для Beta3 оновлюватися не будуть.

Взагалі, не дивлячись на Beta версію, продукт працює досить стабільно. За період 3-х місячного 24х7 тестування, сервіс брандмауера у мене зависав 1 раз. Це, звичайно, не є хороший показник, але все ж треба враховувати те, що це Beta. Так, поки що вискакують іноді помилки і деякі настройки працюють не так, як треба. Але в цілому мені подобаються ті можливості, які надає Forefront TMG, і я думаю, що його вихід серйозно потіснить виробників інших апаратних і програмних міжмережевих екранів.