Konfigurace pravidel Azure Firewall

  • Článek

Pravidla překladu adres (NAT), pravidla sítě a pravidla aplikací ve službě Azure Firewall můžete nakonfigurovat pomocí klasických pravidel nebo zásad brány firewall. Služba Azure Firewall ve výchozím nastavení zamítá veškerý provoz, dokud ručně nenakonfigurujete pravidla tak, aby provoz povolovala.

Zpracování pravidel pomocí klasických pravidel

Kolekce pravidel se zpracovávají podle typu pravidla v pořadí priority, nižší čísla na vyšší čísla 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ů.

V 100 krocích (100, 200, 300 atd.) je nejlepší nejdřív vysadit čísla priorit kolekce pravidel, abyste v případě potřeby měli místo pro přidání dalších kolekcí pravidel.

Zpracování pravidel pomocí zásad brány firewall

Pomocí zásad brány firewall jsou pravidla uspořádána do kolekcí pravidel a 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, skupiny kolekcí 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.

Tady je příklad zásady:

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

Podle následující tabulky:

Name Type 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 0 Nadřazené zásady
BaseRCG2 Skupina kolekcí pravidel 300 3 Nadřazené zásady
AppRC2 Kolekce pravidel aplikace 1200 2 Nadřazené zásady
NetworkRC2 Kolekce pravidel sítě 1300 0 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í zpracování:

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 200), 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 v rámci skupin kolekcí pravidel:

Když se vrátíte do BaseRCG1, iterace bude pokračovat, tentokrát pro pravidla SÍTĚ. Byl nalezen pouze NetworkRC1 (priorita 800).
Pak se přesune na BaseRCG2, kde se nachází NetworkRC2 (priorita 1300).
Při přechodu na ChildRCG1 se jako pravidlo SÍTĚ zjistí ChNetRC1 (priorita 700).
Nakonec v ChildRCG2 najde ChNetRC2 (prioritu 1100) jako kolekci pravidel SÍTĚ.

Konečná iterace pro pravidla APLIKACE:

Když se vrátíte do BaseRCG1, proces iteruje pravidla APPLICATION, ale žádné se nenašly.
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 (prioritu 2000).

Shrnutí: DNATRC1, DNATRC3, ChDNATRC3, NetworkRC1, NetworkRC2, ChNetRC1, 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 osadch

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.

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. Pro shodu podpisu IDPS se v protokolech brány firewall zaprotokoluje 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 provedené službou IDPS tiše 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ě nebo aplikace (Allow/Deny) a označených v protokolech, může být zaznamenána další zpráva drop , kde se IDPS rozhodne relaci odepřít z důvodu shody podpisu.

Pokud je povolená kontrola protokolu TLS nešifrovaný i šifrovaný provoz, zkontroluje se. 

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 se ukončují. Pokud se tedy v pravidle sítě najde shoda, nezpracují se žádná jiná pravidla. Pokud je nakonfigurované, idPS se provádí u veškerého provozu procházení a shody podpisů, můžou ho IDPS upozorňovat nebo blokovat 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 případě protokolu HTTPS kontrolovaných protokolem HTTP i TLS brána firewall ignoruje cílovou IP adresu paketu a použije IP adresu přeloženou SLUŽBou DNS z hlavičky hostitele. Brána firewall očekává, že v hlavičce hostitele 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í. Překlad DNS provádí Azure DNS nebo vlastní DNS, pokud je nakonfigurovaný v bráně firewall. 

Poznámka:

Protokoly HTTP i HTTPS (s kontrolou protokolu TLS) jsou vždy vyplněny hlavičkou XFF (X-Forwarded-For) a rovnají se 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 v pravidlech aplikace nenajde žádná shoda, paket se vyhodnotí jako 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 obsahuje všechny protokoly IP definované v dokumentu IANA (Internet Assigned Numbers Authority). Pokud je cílový port explicitně nakonfigurovaný, pravidlo se přeloží na pravidlo TCP+UDP. Před 9. listopadem 2020 znamená jakýkoli 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 je možné povolit tak, že nakonfigurujete překlad adres (DNAT) cíle, jak je popsáno v tématu Filtrování příchozího provozu pomocí DNAT služby Azure Firewall pomocí webu Azure Portal. Pravidla překladu adres (NAT) se použijí podle priority 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íchdůvodůch

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í na google.com je povolená kvůli odpovídajícímu pravidlu sítě.

Pravidlo sítě

  • Akce: Povolit
name Protokol Source type Source Typ cíle Cílová adresa Cílové porty
Povolit web TCP IP adresa * IP adresa * 80,443

Pravidlo aplikace

  • Akce: Odepřít
name Source type Source 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 shromažďování pravidel sítě s vyšší prioritou blokuje.

Kolekce pravidel sítě 1

  • Název: Allow-collection
  • Priorita: 200
  • Akce: Povolit
name Protokol Source type Source Typ cíle Cílová adresa Cílové porty
Allow-SSH TCP IP adresa * IP adresa * 22

Kolekce pravidel sítě 2

  • Název: Odepřít kolekci
  • Priorita: 100
  • Akce: Odepřít
name Protokol Source type Source Typ cíle Cílová adresa Cílové porty
Odepřít SSH TCP IP adresa * IP adresa * 22

Výsledek

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

Změny pravidel

Pokud změníte pravidlo na odepření dříve povoleného provozu, všechny relevantní existující relace se zahodí.

Třícestné chování metody handshake

Azure Firewall jako stavová služba dokončí třícestný metodu handshake protokolu TCP pro povolený provoz ze zdroje 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. Pokud vytvoříte toto pravidlo zamítnutí, přerušíte třícestné metody handshake z počátečního pravidla povolení z VNet-A na VNet-B.

Další kroky