Forefront TMG 2010 – część 7 – Toolbox

Autor: Jacek Światowiak

Opublikowano: 2011-07-14

Wprowadzenie

W poprzedniej części omówiono reguły sieciowe serwera TMG 2010 Standard Edition. Zrozumienie działania reguł sieciowych jest niezbędne, aby reguły zapory (reguły dostępu oraz reguły publikacji) działały prawidłowo. W niniejszej części pierwotnie planowano omówienie zagadnienia reguł dostępu, lecz przy ich tworzeniu wymagana jest wiedza z zakresu tworzenia i wykorzystania wielu obiektów zgrupowanych w specjalnej zakładce o nazwie Toolbox, stąd drobna modyfikacja kolejności publikacji poszczególnych części.

Zakładka Toolbox

Toolbox to zgrupowanie elementów, z których budowane są reguły zapory. Elementy Toolbox zostały podzielone na następujące kategorie:

• Protocols – protokoły sieciowe,
• Users – użytkownicy.
• Content Types – typy zawartości (treści).
• Schedules – harmonogramy.
• Network Objects – typowe obiekty sieciowe.

Rysunek 7.1. Toolbox – widok ogólny.

Obiekt sieciowy Network

Obiekty sieciowe Network to te same elementy, które zostały zdefiniowane na poziomie Networking, zakładka Networks. Listę przykładowych zdefiniowanych obiektów Network przedstawia rysunek 7.2.

Rysunek 7.2. Rozwinięta gałąź obiektów sieciowych–sieci (Networks).

 

Obiekt sieciowy Network Sets

Obiekty sieciowe Network Sets to te same elementy, które zostały zdefiniowane na poziomie Networking, zakładka Network Sets. Listę przykładowych zdefiniowanych obiektów Network Sets przedstawia rysunek 7.3.

Rysunek 7.3. Rozwinięta gałąź obiektów sieciowych –zestawy sieci (Network Sets).

 

Obiekt sieciowy Computer

Obiekt Computer reprezentuje pojedynczy komputer, który zdefiniowany jest nazwą i adresem IP. Domyślnie lista jest pusta. Tworzenie nowego obiektu komputer jest proste. Z menu wybieramy opcję New i wypełniamy prosty formularz. Na rysunku 7.4 w prawej części przedstawiono zawartość formularza, zaś w lewej utworzony obiekt komputer o nazwie DC. W przypadku gdy serwer TMG będzie członkiem domeny, po kliknięciu przycisku Browse… będzie można wybrać konta komputerów dostępne w usłudze Active Directory. Jak widać, nie można definiować adresu IPv6 dla obiektu komputer.

Rysunek 7.4. Tworzenie obiektu sieciowego komputer (Computer).

 

Obiekt sieciowy AddressRanges

Obiekt AddressRanges to zwykły zakres adresów, który możemy dowolnie nazwać. Domyślnie lista jest pusta. Procedura tworzenia nowego obiektu AddressRanges jest identyczna jak dla komputera. Na rysunku 7.5 w prawej części przedstawiono zawartość formularza, zaś w lewej utworzony obiekt typu zakres adresów o nazwie Zakres DHCP. Jak widać, nie można tworzyć zakresu adresów dla protokołu IPv6.

Rysunek 7.5. Tworzenie obiektu sieciowego zakres adresów (AddressRanges).

 

Obiekt sieciowy Subnet

Obiekt Subnet reprezentuje podsieć opisaną za pomocą adresu sieciowego wraz z maską podsieci (prefiksem). Domyślnie lista jest pusta. Na rysunku 7.6 w prawej części przedstawiono zawartość formularza, zaś w lewej utworzony obiekt typu podsieć o nazwie Siec LAN 2. Jak widać, nie można tworzyć podsieci (dla protokołu IPv6).

Rysunek 7.6. Tworzenie obiektu sieciowego podsieć (Subnets).

 

Obiekt sieciowy ComputerSets

Obiekty sieciowe ComputerSets reprezentują grupy komputerów pełniące wspólne funkcje, np.:

• Anywhere – to abstrakcyjne pojęcie; realizuje ruch do wszystkich adresów IP zarówno w sieci wewnętrznej, jak i na zewnątrz.
• IPSec Remote Gateways – wykorzystywane jest w przypadku budowania sieci VPN typu Site-To-Site opartych na protokole IPSec.

Rysunek 7.7.Rozwinięta gałąź obiektów sieciowych –ComputerSets–grupy komputerów.

 

Uwaga praktyczna

Projektanci serwera TMG, podobnie jak i jego poprzednika (czyli serwera ISA), nie wyposażyli serwera TMG w możliwość pobierania grup komputerów z Active Directory ani w możliwość tworzenia grup w sposób dynamiczny. Jest to duża niedogodność, gdyż często zachodzi konieczność manualnego dodawania komputerów do list – ComputerSets. Można tę procedurę częściowo zautomatyzować, korzystając ze skryptów przygotowanych w języku Visual Basic Scripts.

***Obiekt sieciowy URL Set ***

Obiekt URL Set – definiuje adresy sieciowe w formacie URL (rysunek 7.8) – tylko i wyłącznie dla protokołu HTTP! Na rysunku poniżej przykładowa składnia listy –URL Set:

Rysunek 7.8. Definiowanie nowego obiektu URL Set.

 

Elementów URL Categories oraz URL CategorySets nie będziemy omawiać w niniejszej części. Zostaną one omówione osobno w jednej z kolejnych części.

**

Obiekt sieciowy DomainName Set**

DomainName Set* to predefiniowane listy domen (wraz z poddomenami). Serwer TMG zawiera kilka predefiniowanych list domen – wykorzystywanych główne dla celów administracyjnych.

Rysunek 7.9. Rozwinięta gałąź obiektów sieciowych–DomainNameSets–predefiniowana lista domen.

 

Kolejne dwa elementy, Web listener oraz Servers Farm, zostaną omówione w późniejszych rozdziałach przy omawianiu publikowania serwerów.

Obiekt sieciowy Schedules

Obiekt Schedules– harmonogram (rysunek 7.10) – jest wykorzystywany do tworzenia reguł zapory działających w określonych godzinach przez określone dni tygodnia. Domyślnie reguła działa zawsze. Po instalacji serwera TMG zdefiniowane i dostępne są harmonogramy: Weekends, Workhours oraz niewidoczny Always. Dla celów przykładowych dodano element o nazwie Nocna zmiana (praca w godzinach od 22.00 do 6.00 od poniedziałku do piątku).

Rysunek 7.10. Obiekty Schedules– harmonogramy.

 

Korzystając z kreatora, można zdefiniować nowy harmonogram w okresie 7-dniowym (tygodniowym). Na rysunku 7.11 poniżej pokazano zdefiniowany nowy harmonogram o nazwie Nocna zmiana. Ma on zapewnić działanie reguły: poniedziałek–piątek od 22.00 do 6.00.

Rysunek 7.11. Nowo zdefiniowany harmonogram Nocna zmiana.

 

Definiowanie typów treści, danych

Reguły domyślnie zezwalają na pobieranie i wysyłanie danych dowolnego typu. Serwer TMG umożliwia również ograniczanie ruchu do określonego typu danych–Content Type – zdefiniowanego w elemencie sieciowym. Dostępne typy danych przedstawione zostały na rysunku 7.1 poniżej:

Rysunek 7.12. Obiekty typu Content Types–typy treści, danych.

 

Serwer ISA pozwala zdefiniować również inne, niż dostępne typy danych. Typy treści (typy danych) są definiowane dwojako – jako typy MIME (ang*.Multipurpose Internet Mail Extensions*) bądź jako rozszerzenia plików, np. .txt. W przypadku protokołu HTTP weryfikacja następuje w pierwszej kolejności po typie MIME, a dopiero potem po rozszerzeniu nazwy pliku. Dla protokołu FTP brane jest pod uwagę wyłącznie rozszerzenie nazwy pliku. Serwer TMG posiada zdefiniowanych 11 typów danych. W razie konieczności mogą zostać zdefiniowane inne typy. Tabela 7.1 zawiera zestawienie predefiniowanych obiektów typu Content Types.

Typ zawartości	Zawartość
Application	Typ treści określający zawartość aplikacji wykonywalnych, jak np. biblioteki dll, ole czy .vbs.
Application Data Files	Typ treści określający zawartość danych aplikacji, np. pliki perfmon, help czy .wmf.
Audio	Typ treści określający zawartość audio, np. pliki MP3 czy WAV.
CompressedFiles	Typ treści określający dokumenty skompresowane, jak .z czy .zip.
Documents	Typ treści określający dokumenty w formacie tekstowym, Adobe PDF oraz XML.
HTML doduments	Typ treści określający zawartość typu HTML, np. pliki .xsl czy .htm.
Images	Typ treści określający rysunki, zdjęcia, grafikę, np. Windows Bitmap, JPEG czy GIF.
Macro Documents	Typ treści określający pliki zawierające makrodefinicje, np. z dokumentów pakietu Office, jak Word czy Excel.
Text	Typ treści określający pliki tekstowe, np. z rozszerzeniem .txt.
Video	Typ treści określający zawartość wideo, np. pliki .avi, Quick Time czy MPEG.
VRML	Typ treści określający zawartość typu VRML, np. pliki .flr czy .wrl.

** Tabela 7.1. Zestawienie predefiniowanych obiektów typu Content Types.**

*** ***

***Obiekt sieciowy Users ***

Obiekt Users (rysunek 7.13) definiuje grupy użytkowników wykorzystywane przy autoryzowanym – na podstawie nazwy użytkownika, a nie adresu IP (nazwy) urządzenia sieciowego – dostępie do zasobów:

• AllAuthenticatedUsers – predefiniowana grupa reprezentująca wszystkich użytkowników, którzy zostali uwierzytelnieni za pomocą dowolnej metody,
• AllUsers – predefiniowana grupa reprezentująca wszystkich użytkowników, zarówno uwierzytelnionych, jak i nieuwierzytelnionych,
• System and Network Service – predefiniowana grupa reprezentująca konta systemowe, jak Local System czy Network Service na serwerze TMG.

Rysunek 7.13. Rozwinięta gałąź obiektów sieciowych –użytkownicy (Users).

Uwaga praktyczna

Zarówno użytkownicy zdefiniowani w urządzeniach sieciowych, jak i domyślnie użytkownicy komputerów traktowani są jako klienci typu – SecureNATClients, a zatem jako użytkownicy nieuwierzytelnieni.

Protokoły sieciowe (Protocols)

Serwer TMG posiada bardzo bogatą listę protokołów sieciowych wykorzystywanych do budowania zasad zapory. Poniżej przedstawiono okno zakładki Toolbox–Protocols. Ze względu na przeznaczenie czy pełnione funkcje protokoły zostały podzielone na grupy zaprezentowane na rysunku 7.14:

Rysunek 7.14. Lista grup protokołów wykorzystywanych do budowania zasad zapory.

 

Serwer rozróżnia ogólnie dwa typu protokołów – protokoły zwykłe wykorzystywane najczęściej przy regułach dostępu Access Rule (które omówione będą w następnej części) oraz tzw. protokoły serwerowe, wykorzystywane przy regułach Publikacji lub ZWROTNYCH regułach dostępu (pojęcie to zostanie omówione wraz z regułami publikacji).

Różnice we właściwościach protokołów przedstawimy na przykładzie DNS protocol (rysunek 7.15) i DNS Server protocol (rysunek 7.16). Aby dostrzec różnice, należy zwrócić uwagę na kierunek (Direction) oraz aktywację filtra aplikacji.

Rysunek 7.15. Opcje protokołu–DNS protocol.

 

Rysunek 7.16. Opcje protokołu–DNS Server protocol.

 

Protokoły z rodziny serwerowej mają najczęściej zdefiniowane i włączone filtry aplikacyjne (ang. Application Filters), a kierunek określany jest jako wchodzący (ang. Inbound lub/i ReceiveSend).

Tworzenie definicji nowego protokołu

Jeżeli na liście nie ma poszukiwanego protokołu, można utworzyć nową definicję. Zostanie ona umieszczona w grupie User-Defined. Poniżej przedstawiono procedurę tworzenia nowego protokołu. Dostępne są dwa typy tworzonych protokołów–Protocol oraz RPC Protocol. Okno wyboru typu tworzonego protokołu przedstawiono na rysunku 7.17:

Rysunek 7.17. Wybór typu nowego protokołu.

 

W pierwszym oknie kreatora–Welcome to the New Protocol Definition Wizard (rysunek 7.18) – wpisujemy nazwę nowego protokołu. W oknie następnym definiuje się parametry podstawowego połączenia (definiując protokół warstwy transportowej z parametrami dodatkowymi).

Rysunek 7.18. Kreator tworzenia definicji nowego protokołu.

 

Okno konfiguracji parametrów podstawowego połączenia –Primary Connection Information – przedstawiono na rysunku 7.19:

Rysunek 7.19. Kreator tworzenia definicji nowego protokołu–okno Primary Connection Information.

 

Dla naszego przykładu wybierzemy protokół transportowy połączeniowy (TCP), kierunek wychodzący (Outbound) oraz port docelowy o numerze 1800. Na rysunku 7.20 przedstawiono wygląd okna New/Edit Protocol Connection:

Rysunek 7.20. Kreator tworzenia definicji nowego protokołu–okno New/Edit Protocol Connection.

 

Okno konfiguracji parametrów podstawowego połączenia po modyfikacji przedstawiono na rysunku 7.21:

Rysunek 7.21. Kreator tworzenia definicji nowego protokołu–okno Primary Connection Information po utworzeniu definicji protokołu.

 

Okno definiowania połączenia typu SecondaryConnections przedstawiono na rysunku 7.22. W przykładzie nie definiujemy połączenia typu secondary.

Rysunek 7.22. Kreator tworzenia definicji nowego protokołu–opcje SecondaryConnections.

 

Ostatnie okno pominiemy, gdyż nie wnosi żadnych informacji do procesu definiowania nowego protokołu.

Widok gałęzi User-DefiniedProtocol ze zdefiniowanym nowym protokołem o nazwie Protocol-X przedstawia rysunek 7.23:

Rysunek 7.23. Nowo utworzona definicja protokołu, umieszczona w gałęzi User-DefinedProtocol.

 

Lista typów protokołów przy przygotowywaniu definicji nowego protokołu

Tworzenie definicji nowych protokołów polega na wykorzystaniu standardowych protokołów z rodziny IP (określamy je jako protokoły bazowe). Mamy zatem TCP, UDP, ICM oraz protokoły opisane numerami (czyli IP-level). Dla protokołów TCP oraz UDP będziemy definiowali zakres portów wykorzystywanych przez nasz nowy protokół. Wygląd okna definiowania parametrów nowego protokołu przedstawiono na rysunku 7.24:

Rysunek 7.24. Dostępne protokoły bazowe wykorzystywane przy tworzeniu definicji nowych protokołów dla serwera TMG.

 

Właściwości protokołu bazowego TCP

Dla protokołu bazowego TCP (rysunek 7.25) definiujemy kierunek ruchu (Direction):

• Inbound (ruch wchodzący),
• Outbound (ruch wychodzący)

 

oraz zakres wykorzystywanych portów. Jeżeli wykorzystujemy jeden port w obu polach (From oraz To), podajemy ten sam numer portu.

Rysunek 7.25. Właściwości protokołu bazowego TCP.

 

Właściwości protokołu bazowego UDP

Dla protokołu bazowego UDP (rysunek 7.26) definiujemy kierunek ruchu (Direction):

• Receive,
• Receive-Send (odpowiada funkcjonalnie Inbound dla TCP),
• Send,
• SendReceive (odpowiada funkcjonalnie Outbound dla TCP)

oraz zakres wykorzystywanych portów. Jeżeli wykorzystujemy jeden port w obu polach (From oraz To), podajemy ten sam numer portu.

Uwaga informacyjna

Oznaczenie kierunku tylko Receive lub tylko Send oznacza, iż z danym portem związana jest komunikacja wyłącznie jednokierunkowa.

 

Rysunek 7.26. Właściwości protokołu bazowego UDP.

*** ***

Właściwości protokołu bazowego ICMP

Dla protokołu bazowego ICMP (rysunek 7.27) definiujemy kierunek ruchu (Direction):

• Send,
• Send Receive

oraz parametry ICMP Code oraz ICMP Type.

Rysunek 7.27. Właściwości protokołu bazowego ICMP.

Właściwości protokołów bazowych typu IP-Based

Dla protokołu bazowego typu IP-based (rysunek 7.28) definiujemy kierunek ruchu (Direction):

• Send,
• Send Receive

oraz numer protokołu (w zakresie od 0 do 255).

Rysunek 7.28. Właściwości protokołów bazowych typu IP-Based.

Podsumowanie

W niniejszej części cyklu artykułów przedstawiono podstawowe elementy, z których budowaną będą reguły zapory. Znajomość tych komponentów, sposoby ich tworzenia czy właściwości są niezbędne do zrozumienia sposobu budowania i zarządzania najważniejszymi opcjami zapory – regułami odpowiadającymi za kształtowanie ruchu sieciowego przechodzącego przez zaporę. 

 

---