Konfigurowanie reguł usługi Azure Firewall
Reguły nat, reguły sieci i reguły aplikacji w usłudze Azure Firewall można skonfigurować przy użyciu reguł klasycznych lub zasad zapory. Azure Firewall domyślnie odrzuca cały ruch, dopóki reguły nie zostaną ręcznie skonfigurowane tak, aby zezwalały na ruch. Reguły kończą działanie, więc przetwarzanie reguł zatrzymuje się na dopasowaniu.
Przetwarzanie reguł przy użyciu reguł klasycznych
Kolekcje reguł są przetwarzane zgodnie z typem reguły w kolejności priorytetu, mniejsze liczby do wyższych liczb z zakresu od 100 do 65 000. Nazwa kolekcji reguł może zawierać tylko litery, cyfry, podkreślenia, kropki lub łączniki. Musi zaczynać się literą lub cyfrą i kończyć literą, cyfrą lub podkreśleniami. Maksymalna długość nazwy to 80 znaków.
Najlepiej początkowo zwolnić numery priorytetów kolekcji reguł w 100 przyrostach (100, 200, 300 itd.), aby w razie potrzeby dodać więcej kolekcji reguł.
Przetwarzanie reguł przy użyciu zasad zapory
W przypadku zasad zapory reguły są zorganizowane wewnątrz kolekcji reguł i grup kolekcji reguł. Grupy kolekcji reguł zawierają zero lub więcej kolekcji reguł. Kolekcje reguł są typami TRANSLATOR adresów sieciowych, sieci lub aplikacji. W ramach jednej grupy reguł można zdefiniować wiele typów kolekcji reguł. W kolekcji reguł można zdefiniować zero lub więcej reguł. Reguły w kolekcji reguł muszą być tego samego typu (TRANSLATOR adresów sieciowych, sieci lub aplikacji).
Reguły są przetwarzane na podstawie priorytetu grupy kolekcji reguł i priorytetu kolekcji reguł. Priorytet to dowolna liczba z zakresu od 100 (najwyższy priorytet) do 65 000 (najniższy priorytet). Grupy kolekcji reguł o najwyższym priorytcie są najpierw przetwarzane. W grupie kolekcji reguł najpierw są przetwarzane kolekcje reguł o najwyższym priorytcie (najniższym numerze).
Jeśli zasady zapory są dziedziczone z zasad nadrzędnych, grupy kolekcji reguł w zasadach nadrzędnych zawsze mają pierwszeństwo niezależnie od priorytetu zasad podrzędnych.
Uwaga
Reguły aplikacji są zawsze przetwarzane po regułach sieci, które są przetwarzane po regułach DNAT niezależnie od grupy kolekcji reguł lub priorytetu kolekcji reguł i dziedziczenia zasad.
Tak więc, aby podsumować:
Zasady nadrzędne zawsze mają pierwszeństwo.
- Grupy kolekcji reguł są przetwarzane w kolejności priorytetów.
- Kolekcje reguł są przetwarzane w kolejności priorytetów.
- Reguły DNAT, a następnie reguły sieciowe, a następnie reguły aplikacji są przetwarzane.
Oto przykładowe zasady:
Zakładając, że BaseRCG1 jest priorytetem grupy kolekcji reguł (200), który zawiera kolekcje reguł: DNATRC1, DNATRC3,NetworkRC1.
BaseRCG2 to priorytet grupy kolekcji reguł (300), który zawiera kolekcje reguł: AppRC2, NetworkRC2.
ChildRCG1 to priorytet grupy kolekcji reguł (300), który zawiera kolekcje reguł: ChNetRC1, ChAppRC1.
ChildRCG2 to priorytet grupy kolekcji reguł (650), który zawiera kolekcje reguł: ChNetRC2, ChAppRC2,ChDNATRC3.
Zgodnie z poniższą tabelą:
Nazwisko | Typ | Priorytet | Reguły | Odziedziczone po |
---|---|---|---|---|
BaseRCG1 | Grupa kolekcji reguł | 200 | 8 | Zasady nadrzędne |
DNATRC1 | Kolekcja reguł DNAT | 600 | 7 | Zasady nadrzędne |
DNATRC3 | Kolekcja reguł DNAT | 610 | 3 | Zasady nadrzędne |
NetworkRC1 | Kolekcja reguł sieciowych | 800 | 1 | Zasady nadrzędne |
BaseRCG2 | Grupa kolekcji reguł | 300 | 3 | Zasady nadrzędne |
AppRC2 | Kolekcja reguł aplikacji | 1200 | 2 | Zasady nadrzędne |
NetworkRC2 | Kolekcja reguł sieciowych | 1300 | 1 | Zasady nadrzędne |
ChildRCG1 | Grupa kolekcji reguł | 300 | 5 | - |
ChNetRC1 | Kolekcja reguł sieciowych | 700 | 3 | - |
ChAppRC1 | Kolekcja reguł aplikacji | 900 | 2 | - |
ChildRCG2 | Grupa kolekcji reguł | 650 | 9 | - |
ChNetRC2 | Kolekcja reguł sieciowych | 1100 | 2 | - |
ChAppRC2 | Kolekcja reguł aplikacji | 2000 | 7 | - |
ChDNATRC3 | Kolekcja reguł DNAT | 3000 | 2 | - |
Początkowa iteracja reguł DNAT:
Proces rozpoczyna się od zbadania grupy kolekcji reguł (RCG) o najniższej liczbie, która jest BaseRCG1 z priorytetem 200. W tej grupie wyszukuje kolekcje reguł DNAT i ocenia je zgodnie z ich priorytetami. W tym przypadku DNATRC1 (priorytet 600) i DNATRC3 (priorytet 610) są odpowiednio przetwarzane i przetwarzane.
Następnie przechodzi do następnego RCG, BaseRCG2 (priorytet 300), ale nie znajduje kolekcji reguł DNAT.
Następnie przechodzi do childRCG1 (priorytet 300), również bez kolekcji reguł DNAT.
Na koniec sprawdza wartość ChildRCG2 (priorytet 650) i znajduje kolekcję reguł ChDNATRC3 (priorytet 3000).
Iteracja reguł sieci:
Wracając do baseRCG1, iteracja jest kontynuowana, tym razem dla reguł SIECI. Znaleziono tylko networkRC1 (priorytet 800).
Następnie zostanie przeniesiona do baseRCG2, gdzie znajduje się networkRC2 (priorytet 1300).
Przechodząc do childRCG1, odnajduje ChNetRC1 (priorytet 700) jako regułę SIECI.
Na koniec w childRCG2 znajduje ChNetRC2 (priorytet 1100) jako kolekcję reguł SIECI.
Ostateczna iteracja reguł aplikacji:
Wracając do baseRCG1, proces iteruje reguły APLIKACJI, ale żaden nie zostanie znaleziony.
W baseRCG2 identyfikuje appRC2 (priorytet 1200) jako regułę APPLICATION.
W childRCG1 ChAppRC1 (priorytet 900) jest znaleziony jako reguła APLIKACJI.
Na koniec w childRCG2 lokalizuje ChAppRC2 (priorytet 2000) jako regułę APPLICATION.
Podsumowując, sekwencja przetwarzania reguł jest następująca: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.
Ten proces obejmuje analizowanie grup kolekcji reguł według priorytetu i w każdej grupie, porządkowanie reguł zgodnie z ich priorytetami dla każdego typu reguły (DNAT, NETWORK i APPLICATION).
Najpierw wszystkie reguły DNAT są przetwarzane ze wszystkich grup kolekcji reguł, analizując grupy kolekcji reguł według kolejności priorytetu i porządkowania reguł DNAT w każdej grupie kolekcji reguł według kolejności priorytetu. Następnie ten sam proces dla reguł SIECI, a na koniec dla reguł APLIKACJI.
Aby uzyskać więcej informacji na temat zestawów reguł zasad zapory, zobacz Zestawy reguł usługi Azure Firewall Policy.
Analiza zagrożeń
Jeśli włączysz filtrowanie oparte na analizie zagrożeń, te reguły mają najwyższy priorytet i są zawsze przetwarzane jako pierwsze (przed regułami sieci i aplikacji). Filtrowanie analizy zagrożeń może blokować ruch przed przetworzeniem wszystkich skonfigurowanych reguł. Aby uzyskać więcej informacji, zobacz Filtrowanie oparte na analizie zagrożeń w usłudze Azure Firewall.
IDPS
Po skonfigurowaniu dostawcy tożsamości w trybie alertu aparat IDPS działa równolegle z logiką przetwarzania reguł i generuje alerty dotyczące pasujących podpisów zarówno dla przepływów przychodzących, jak i wychodzących. W przypadku dopasowania podpisu IDPS alert jest rejestrowany w dziennikach zapory. Jednak ponieważ aparat IDPS działa równolegle z aparatem przetwarzania reguł, ruch blokowany lub dozwolony przez reguły aplikacji/sieci może nadal generować kolejny wpis dziennika.
Po skonfigurowaniu dostawcy tożsamości w trybie alertu i odmowy aparat IDPS jest wbudowany i aktywowany po aucie przetwarzania reguł. W związku z tym oba aparaty generują alerty i mogą blokować pasujące przepływy.
Przerywanie sesji przez IDPS blokuje przepływ w trybie dyskretnym. Dlatego nie jest wysyłany RST na poziomie TCP. Ponieważ usługa IDPS sprawdza ruch zawsze po dopasowaniu reguły sieci/aplikacji (Zezwalaj/Odmów) i oznaczonych w dziennikach, w dziennikach może być rejestrowany inny komunikat drop , w którym dostawcy tożsamości zdecydują się odmówić sesji z powodu dopasowania podpisu.
Po włączeniu inspekcji protokołu TLS jest sprawdzany zarówno niezaszyfrowany, jak i zaszyfrowany ruch.
Łączność wychodząca
Reguły sieci i reguły aplikacji
Jeśli skonfigurujesz reguły sieci i reguły aplikacji, reguły sieci są stosowane w kolejności priorytetu przed regułami aplikacji. Reguły kończą się. W związku z tym, jeśli dopasowanie zostanie znalezione w regule sieciowej, żadne inne reguły nie są przetwarzane. W przypadku skonfigurowania dostawcy tożsamości są wykonywane na wszystkich ruchach przechodzących i po dopasowaniu podpisu, dostawcy tożsamości mogą powiadamiać lub/i blokować podejrzany ruch.
Reguły aplikacji oceniają pakiet w kolejności priorytetu, jeśli nie ma dopasowania reguły sieciowej, a jeśli protokół to HTTP, HTTPS lub MSSQL.
W przypadku protokołu HTTP usługa Azure Firewall wyszukuje dopasowanie reguły aplikacji zgodnie z nagłówkiem Host. W przypadku protokołu HTTPS usługa Azure Firewall wyszukuje dopasowanie reguły aplikacji zgodnie tylko z interfejsem SNI.
Zarówno w przypadku protokołu HTTP, jak i TLS sprawdzane protokoły HTTPS, zapora ignoruje docelowy adres IP pakietu i używa rozpoznanego adresu IP DNS z nagłówka Host. Zapora oczekuje, że numer portu w nagłówku hosta, w przeciwnym razie zakłada standardowy port 80. Jeśli istnieje niezgodność portów między rzeczywistym portem TCP a portem w nagłówku hosta, ruch zostanie porzucony. Rozpoznawanie nazw DNS odbywa się przez usługę Azure DNS lub niestandardową usługę DNS, jeśli została skonfigurowana w zaporze.
Uwaga
Protokoły HTTP i HTTPS (z inspekcją protokołu TLS) są zawsze wypełniane przez usługę Azure Firewall z nagłówkiem XFF (X-Forwarded-For) równym oryginalnemu źródłowemu adresowi IP.
Gdy reguła aplikacji zawiera inspekcję protokołu TLS, aparat reguł zapory przetwarza SNI, nagłówek hosta, a także adres URL zgodny z regułą.
Jeśli nadal nie znaleziono dopasowania w regułach aplikacji, pakiet jest oceniany względem kolekcji reguł infrastruktury. Jeśli nadal nie ma dopasowania, pakiet zostanie domyślnie odrzucony.
Uwaga
Reguły sieci można skonfigurować dla protokołu TCP, UDP, ICMP lub dowolnego protokołu IP. Każdy protokół IP zawiera wszystkie protokoły IP zdefiniowane w dokumencie Numery protokołów przypisanych do Internetu (IANA). Jeśli port docelowy jest jawnie skonfigurowany, reguła jest tłumaczona na regułę TCP+UDP. Przed 9 listopada 2020 r. dowolne oznaczało TCP, UDP lub ICMP. Dlatego można skonfigurować regułę przed tą datą z wartością Protocol = Any, a porty docelowe = "*". Jeśli nie zamierzasz zezwalać na używanie żadnego protokołu IP zgodnie z aktualnie zdefiniowaną definicją, zmodyfikuj regułę, aby jawnie skonfigurować żądane protokoły (TCP, UDP lub ICMP).
Łączność przychodząca
Reguły DNAT i reguły sieci
Łączność ruchu przychodzącego z Internetem lub intranetem (wersja zapoznawcza) można włączyć przez skonfigurowanie docelowego tłumaczenia adresów sieciowych (DNAT) zgodnie z opisem w temacie Filtrowanie przychodzącego ruchu internetowego lub intranetowego za pomocą DNAT usługi Azure Firewall przy użyciu witryny Azure Portal. Reguły NAT są stosowane priorytetowo przed regułami sieci. W przypadku znalezienia dopasowania ruch jest tłumaczony zgodnie z regułą DNAT i dozwolony przez zaporę. W związku z tym ruch nie podlega dalszemu przetwarzaniu przez inne reguły sieciowe. Ze względów bezpieczeństwa zalecane jest dodanie określonego źródła internetowego w celu umożliwienia dostępu DNAT do sieci i uniknięcia korzystania z symboli wieloznacznych.
Reguły aplikacji nie są stosowane dla połączeń przychodzących. Dlatego jeśli chcesz filtrować przychodzący ruch HTTP/S, należy użyć zapory aplikacji internetowej (WAF). Aby uzyskać więcej informacji, zobacz Co to jest usługa Azure Web Application Firewall?
Przykłady
W poniższych przykładach przedstawiono wyniki niektórych z tych kombinacji reguł.
Przykład 1
Połączenie z google.com jest dozwolone z powodu zgodnej reguły sieciowej.
Reguła sieci
- Akcja: Zezwalaj
name | Protokół | Source type | Źródło | Typ docelowy | Adres docelowy | Porty docelowe |
---|---|---|---|---|---|---|
Zezwalaj na sieć Web | TCP | Adres IP | * | Adres IP | * | 80 443 |
Reguła aplikacji
- Akcja: Odmów
name | Source type | Źródło | Protokół:port | Docelowe nazwy FQDN |
---|---|---|---|---|
Deny-google | Adres IP | * | http:80,https:443 | google.com |
Wynik
Połączenie z google.com jest dozwolone, ponieważ pakiet jest zgodny z regułą zezwalania na sieć internetową . Przetwarzanie reguł zatrzymuje się w tym momencie.
Przykład 2
Ruch SSH jest blokowany, ponieważ kolekcja reguł sieci o wyższym priorytcie Odmawiaj blokuje go.
Kolekcja reguł sieciowych 1
- Nazwa: Zezwalaj na zbieranie
- Priorytet: 200
- Akcja: Zezwalaj
name | Protokół | Source type | Źródło | Typ docelowy | Adres docelowy | Porty docelowe |
---|---|---|---|---|---|---|
Zezwalaj na protokół SSH | TCP | Adres IP | * | Adres IP | * | 22 |
Kolekcja reguł sieci 2
- Nazwa: Deny-collection
- Priorytet: 100
- Akcja: Odmów
name | Protokół | Source type | Źródło | Typ docelowy | Adres docelowy | Porty docelowe |
---|---|---|---|---|---|---|
Odmowa protokołu SSH | TCP | Adres IP | * | Adres IP | * | 22 |
Wynik
Połączenia SSH są odrzucane, ponieważ kolekcja reguł sieci o wyższym priorytcie blokuje je. Przetwarzanie reguł zatrzymuje się w tym momencie.
Zmiany reguły
Jeśli zmienisz regułę na odmowę wcześniej dozwolonego ruchu, wszystkie odpowiednie istniejące sesje zostaną porzucone.
Zachowanie trójkierunkowe uzgadniania
Jako usługa stanowa usługa Azure Firewall wykonuje trójkierunkowe uzgadnianie tcp dla dozwolonego ruchu z źródła do miejsca docelowego. Na przykład sieć wirtualna-A do sieci wirtualnej-B.
Utworzenie reguły zezwalania na ruch z sieci wirtualnej A do sieci wirtualnej B nie oznacza, że nowe połączenia inicjowane z sieci wirtualnej B do sieci wirtualnej A są dozwolone.
W związku z tym nie ma potrzeby tworzenia jawnej reguły odmowy z sieci wirtualnej-B do sieci wirtualnej-A.