Sdílet prostřednictvím

Konfigurace pravidel Azure Firewall

Pravidla NAT, pravidla sítě a pravidla aplikací ve službě Azure Firewall můžete nakonfigurovat pomocí klasických pravidel nebo zásady Firewallu. Služba Azure Firewall ve výchozím nastavení zamítá veškerý provoz, dokud ručně nenakonfigurujete pravidla tak, aby provoz povolovala. Pravidla jsou konečná, takže zpracování pravidel se zastaví při shodě.

Zpracování pravidel pomocí klasických pravidel

Kolekce pravidel se zpracovávají podle typu pravidla v pořadí priority, od nižších čísel k vyšším číslům, od 100 do 65 000. Název kolekce pravidel může obsahovat pouze písmena, číslice, podtržítka, tečky nebo pomlčky. Musí začínat písmenem nebo číslem a končit písmenem, číslem nebo podtržítkem. Maximální délka názvu je 80 znaků.

Je nejlepší původně rozmístit čísla priorit kolekce pravidel ve 100krokových intervalech (100, 200, 300 atd.), aby bylo možné v případě potřeby přidat další kolekce pravidel.

Zpracování pravidel pomocí politiky brány firewall

Pravidla jsou v zásadách brány firewall uspořádána do kolekcí pravidel a souvisejících skupin kolekcí pravidel. Skupiny kolekcí pravidel obsahují nula nebo více kolekcí pravidel. Kolekce pravidel jsou typu NAT, Network nebo Applications. V rámci jedné skupiny pravidel můžete definovat více typů kolekce pravidel. V kolekci pravidel můžete definovat nula nebo více pravidel. Pravidla v kolekci pravidel musí být stejného typu (NAT, Network nebo Application).

Pravidla se zpracovávají na základě priority skupiny kolekcí pravidel a priority kolekce pravidel. Priorita je libovolné číslo mezi 100 (nejvyšší prioritou) až 65 000 (nejnižší priorita). Skupiny kolekcí pravidel s nejvyšší prioritou se zpracovávají jako první. Uvnitř skupiny kolekcí pravidel se nejprve zpracovávají kolekce pravidel s nejvyšší prioritou (nejnižším číslem).

Pokud je zásada brány firewall zděděná z nadřazené zásady, kolekce pravidel v nadřazené zásadě mají vždy přednost bez ohledu na prioritu podřízené zásady.

Poznámka:

Pravidla aplikací se zpracovávají vždy po pravidlech sítě, která se zpracovávají po pravidlech DNAT bez ohledu na skupinu kolekcí pravidel nebo prioritu kolekce pravidel a dědičnost zásad.

Shrnutí:

Nadřazené zásady mají vždy přednost.

  1. Skupiny kolekcí pravidel se zpracovávají v pořadí priority.
  2. Kolekce pravidel se zpracovávají v pořadí priority.
  3. Pravidla DNAT, pak pravidla sítě a pak se zpracovávají pravidla aplikace.

Tady je příklad zásady:

Za předpokladu, že BaseRCG1 je prioritní skupina kolekcí pravidel (200), která obsahuje kolekce pravidel: DNATRC1, DNATRC3, NetworkRC1.
BaseRCG2 je priorita skupiny kolekcí pravidel (300), která obsahuje kolekce pravidel: AppRC2, NetworkRC2.
Skupina kolekcí pravidel ChildRCG1 má prioritu (300) a obsahuje kolekce pravidel: ChNetRC1, ChAppRC1.
ChildRCG2 je skupina kolekcí pravidel s prioritou (650), která obsahuje kolekce pravidel: ChNetRC2, ChAppRC2, ChDNATRC3.

Podle následující tabulky:

Název Typ Priorita Pravidla Zděděno od
BaseRCG1 Skupina kolekcí pravidel 200 8 Nadřazené zásady
DNATRC1 Kolekce pravidel DNAT 600 7 Nadřazené zásady
DNATRC3 Kolekce pravidel DNAT 610 3 Nadřazené zásady
NetworkRC1 Kolekce pravidel sítě 800 1 Nadřazené zásady
BaseRCG2 Skupina kolekcí pravidel 300 3 Nadřazené zásady
AppRC2 Kolekce pravidel aplikace 1 200 2 Nadřazené zásady
NetworkRC2 Kolekce pravidel sítě 1 300 1 Nadřazené zásady
ChildRCG1 Skupina kolekcí pravidel 300 5 -
ChNetRC1 Kolekce pravidel sítě 700 3 -
ChAppRC1 Kolekce pravidel aplikace 900 2 -
ChildRCG2 Skupina kolekcí pravidel 650 9 -
ChNetRC2 Kolekce pravidel sítě 1100 2 -
ChAppRC2 Kolekce pravidel aplikace 2000 7 -
ChDNATRC3 Kolekce pravidel DNAT 3000 2 -

Počáteční iterace pro pravidla DNAT:

Proces začíná prozkoumáním skupiny kolekcí pravidel (RCG) s nejnižším číslem, což je BaseRCG1 s prioritou 200. V této skupině vyhledává kolekce pravidel DNAT a vyhodnocuje je podle svých priorit. V tomto případě jsou nalezeny a zpracovány DNATRC1 (priorita 600) a DNATRC3 (priorita 610).
V dalším kroku se přesune na další RCG BaseRCG2 (priorita 300), ale nenajde žádnou kolekci pravidel DNAT.
Následně pokračuje do childRCG1 (priorita 300), a to i bez kolekce pravidel DNAT.
Nakonec zkontroluje ChildRCG2 (priorita 650) a najde kolekci pravidel ChDNATRC3 (priorita 3000).

Iterace pro pravidla sítě:

Po návratu do BaseRCG1 iterace pokračuje, tentokrát pro síťová pravidla. Byl nalezen pouze NetworkRC1 (priorita 800).
Pak se přesune na BaseRCG2, kde se nachází NetworkRC2 (priorita 1300).
Přesuneme-li se k ChildRCG1, jako pravidlo sítě se zjistí ChNetRC1 (priorita 700).
Nakonec v ChildRCG2 najde ChNetRC2 (prioritu 1100) jako kolekci pravidel SÍTĚ.

Konečná iterace pro pravidla APLIKACE:

Při návratu do BaseRCG1 proces iteruje pro pravidla APPLICATION, ale žádné se nenajdou.
V BaseRCG2 identifikuje AppRC2 (priorita 1200) jako pravidlo APLIKACE.
V ChildRCG1 se jako pravidlo APLIKACE nachází ChAppRC1 (priorita 900).
Nakonec v ChildRCG2 vyhledá jako pravidlo APLIKACE ChAppRC2 (priorita 2000).

Shrnutí: sekvence zpracování pravidel je následující: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, ChNetRC2, AppRC2, ChAppRC1, ChAppRC2.

Tento proces zahrnuje analýzu skupin kolekcí pravidel podle priority a v každé skupině řazení pravidel podle jejich priorit pro každý typ pravidla (DNAT, NETWORK a APPLICATION).

Proto se nejprve zpracovávají všechna pravidla DNAT ze všech skupin kolekcí pravidel a analyzují skupiny kolekcí pravidel podle pořadí priority a řazení pravidel DNAT v rámci každé skupiny kolekcí pravidel podle pořadí priority. Pak stejný postup pro pravidla SÍTĚ a nakonec pro pravidla APPLICATION.

Další informace o sadách pravidel pro bránu Azure Firewall najdete v pravidlech Azure Firewall Policy.

Analýza hrozeb

Pokud povolíte filtrování na základě analýzy hrozeb, jsou tato pravidla nejvyšší prioritou a vždy se zpracovávají jako první (před pravidly sítě a aplikací). Filtrování analýzy hrozeb může zakázat provoz před zpracováním nakonfigurovaných pravidel. Další informace najdete v tématu Filtrování na základě analýzy hrozeb na základě služby Azure Firewall.

Systém detekce a prevence průniku (IDPS)

Pokud je IDPS nakonfigurovaný v režimu upozornění , modul IDPS funguje paralelně s logikou zpracování pravidla a generuje výstrahy na odpovídající podpisy pro příchozí i odchozí toky. Při shodě podpisu IDPS je v protokolech firewallu zaznamenáno upozornění. Vzhledem k tomu, že modul IDPS funguje paralelně s modulem pro zpracování pravidel, může však provoz odepřený nebo povolený pravidly aplikace nebo sítě stále generovat další položku protokolu.

Pokud je IDPS nakonfigurovaný v režimu výstrah a zamítnutí , modul IDPS je vložený a aktivovaný po modulu pro zpracování pravidel. Oba moduly proto generují výstrahy a můžou blokovat odpovídající toky. 

Přerušení relace vykonané systémem IDPS nezaznamenaně blokuje tok. Proto se na úrovni PROTOKOLU TCP neposílají žádné protokoly RST. Vzhledem k tomu, že IDPS kontroluje provoz vždy po spárování pravidla sítě/aplikace (Allow/Deny) a kdy jsou zaznamenány v protokolech, může být zaznamenána další zpráva o zamítnutí, kde se IDPS rozhodne zablokovat relaci z důvodu shody podpisu.

Pokud je povolena kontrola protokolu TLS, kontroluje se jak nešifrovaný, tak šifrovaný provoz. 

Odchozí připojení

Pravidla sítě a pravidla aplikací

Pokud konfigurujete pravidla sítě a pravidla aplikace, použijí se pravidla sítě v pořadí priority před pravidly aplikace. Pravidla končí. Pokud se tedy v pravidle sítě najde shoda, žádná další pravidla nejsou zpracována. Pokud je nakonfigurováno, IDPS se provádí na veškerém procházejícím provozu a při shodě podpisu může IDPS upozornit nebo/a zablokovat podezřelý provoz.

Pravidla aplikace pak vyhodnocují paket v pořadí priority, pokud se neshoduje žádné pravidlo sítě, a pokud je protokol HTTP, HTTPS nebo MSSQL.

V případě protokolu HTTP služba Azure Firewall hledá shodu pravidla aplikace podle hlavičky hostitele. V případě protokolu HTTPS azure Firewall hledá shodu pravidla aplikace pouze podle SNI.

V obou případech inspekce HTTP a TLS pro HTTPS firewall ignoruje cílovou IP adresu paketu a použije IP adresu přeloženou pomocí DNS z hostitelské hlavičky. Firewall očekává, že v hlavičce Host získá číslo portu, jinak předpokládá standardní port 80. Pokud dojde k neshodě portů mezi skutečným portem TCP a portem v hlavičce hostitele, provoz se zahodí. Řešení DNS provádí Azure DNS nebo vlastní DNS, pokud je nakonfigurovaná v bráně firewall. 

Poznámka:

Protokoly HTTP i HTTPS (s inspekcí TLS) jsou vždy vyplňovány Azure Firewall hlavičkou XFF (X-Forwarded-For), která odpovídá původní zdrojové IP adrese. 

Pokud pravidlo aplikace obsahuje kontrolu protokolu TLS, modul pravidel brány firewall zpracuje SNI, hlavičku hostitele a také adresu URL odpovídající pravidlu.

Pokud se stále nenajde žádná shoda v pravidlech aplikace, paket se vyhodnotí podle kolekce pravidel infrastruktury. Pokud stále neexistuje shoda, paket se ve výchozím nastavení zamítá.

Poznámka:

Pravidla sítě je možné nakonfigurovat pro protokol TCP, UDP, ICMP nebo jakýkoli protokol IP. Jakýkoli protokol IP zahrnuje všechny protokoly IP, jak jsou definovány v dokumentu Internet Assigned Numbers Authority (IANA) Protocol Numbers. Pokud je cílový port explicitně nakonfigurovaný, pravidlo se přeloží na pravidlo TCP+UDP. Před 9. listopadem 2020 znamenalo některý z protokolů TCP, UDP nebo ICMP. Proto jste možná nakonfigurovali pravidlo před tímto datem pomocí protokolu = Any a cílových portů = *. Pokud nemáte v úmyslu povolit žádný protokol IP, jak je aktuálně definováno, upravte pravidlo tak, aby explicitně nakonfiguruje požadované protokoly (TCP, UDP nebo ICMP).

Příchozí připojení

Pravidla DNAT a pravidla sítě

Příchozí připojení k internetu nebo intranetu je možné povolit konfigurací překladu cílových adres (DNAT), jak je popsáno v tématu Filtrování příchozího internetového nebo intranetového provozu pomocí DNAT služby Azure Firewall pomocí webu Azure Portal. Pravidla překladu adres (NAT) mají přednost při použití před pravidly sítě. Pokud se najde shoda, provoz se přeloží podle pravidla DNAT a povolí ho brána firewall. Provoz proto není předmětem dalšího zpracování jinými pravidly sítě. Z bezpečnostních důvodů je doporučeným postupem přidat konkrétní internetový zdroj pro umožnění DNAT přístupu do sítě a vyhnout se použití zástupných znaků.

Pravidla aplikace se pro příchozí připojení nepoužijí. Pokud tedy chcete filtrovat příchozí provoz HTTP/S, měli byste použít firewall webových aplikací (WAF). Další informace najdete v tématu Co je Azure Web Application Firewall?

Příklady

Následující příklady ukazují výsledky některých z těchto kombinací pravidel.

Příklad 1

Připojení k google.com je povolené kvůli odpovídajícímu pravidlu sítě.

Pravidlo sítě

  • Akce: Povolit
jméno Protokol Typ zdroje Zdroj Typ cíle Cílová adresa Cílové porty
Povolit web Protokol tcp IP adresa * IP adresa * 80,443

Pravidlo aplikace

  • Akce: Odepřít
jméno Typ zdroje Zdroj Protokol:port Cílové plně kvalifikované názvy domén
Odepřít google IP adresa * http:80,https:443 google.com

Výsledek

Připojení k google.com je povoleno, protože paket odpovídá pravidlu sítě Allow-Web . Zpracování pravidel se v tuto chvíli zastaví.

Příklad 2

Provoz SSH je odepřen, protože sada síťových pravidel s vyšší prioritou Odepřít jej blokuje.

Kolekce pravidel sítě 1

  • Název: Allow-collection
  • Priorita: 200
  • Akce: Povolit
jméno Protokol Typ zdroje Zdroj Typ cíle Cílová adresa Cílové porty
Povolit SSH Protokol tcp IP adresa * IP adresa * 22

Kolekce pravidel sítě 2

  • Název: Odepření sbírky
  • Priorita: 100
  • Akce: Odepřít
jméno Protokol Typ zdroje Zdroj Typ cíle Cílová adresa Cílové porty
Odepřít SSH Protokol tcp IP adresa * IP adresa * 22

Výsledek

Připojení SSH jsou odepřena, protože je blokuje kolekce síťových pravidel s vyšší prioritou. Zpracování pravidel se v tuto chvíli zastaví.

Změny pravidel

Pokud změníte pravidlo tak, aby blokovalo dříve povolený provoz, všechny relevantní existující relace budou ukončeny.

Třícestné chování metody handshake

Azure Firewall jako stavová služba dokončí třícestný handshake protokolu TCP pro povolený provoz z výchozího bodu do cíle. Například VNet-A do VNet-B.

Vytvoření pravidla povolení z virtuální sítě A do virtuální sítě B neznamená, že jsou povolena nová iniciovaná připojení z virtuální sítě B do virtuální sítě A.

V důsledku toho není potřeba vytvořit explicitní pravidlo zamítnutí z VNet-B do VNet-A.

Další kroky

  • Last updated on