Adresa 240.80.1.1 se používá pro některé interní lokální IP komunikace mezi procesy uvnitř Logmanageru. Může se tak objevit u logů, které jsou vytvářeny v samotném Logmanageru.
Komunikační diagram Logmanageru
Logmanager pro svoji řádnou funkci vyžaduje řadu povolených síťových portů. Pro správné nastavení firewallů, případně dalších síťových prvků, prosím využijte následující diagram:
Reportování chyb - tato komunikace je ve výchozím stavu zakázana, pro její funkci ji musí operátor zapnout. Více naleznete zde: Automaticky posílat chyby směrem k výrobci.
Přístup na aktualizační server Logmanager up.logmanager.cz a servery Microsoft pro čtení událostí z cloudu vyžadují transparentní komunikaci, tzn. bez HTTPS/SSL inspekce. Zkontrolujte nastavení vašeho firewallu, zda komunikaci neblokujete, nebo zda nemáte zapnutou HTTPS/SSL inspekci (známou také jako MITM, tedy Man in the middle). Pokud vám to váš firewall umožňuje, vytvořte pro Logmanager speciální unikátní pravidlo, kterým povolíte jen požadovanou komunikaci.
Komunikace Logmanager clusteru:
Zdroj
Cíl
Port / Protokol
Popis
Logmanager
Logmanager
443 / TCP
Konfigurace clusteru
Logmanager
Logmanager
51820 / UDP
WireGuard
Minimální MTU mezi nody v clusteru Logmanager je 1500.
Komunikace Logmanager Forwarderu:
Zdroj
Cíl
Port / Protokol
Popis
Logmanager Forwarder
Logmanager
443 / TCP
Konfigurace Forwarderu
Logmanager Forwarder
Logmanager
51821 / UDP
WireGuard
Minimální MTU mezi Logmanager a Logmanager Forwarderem je 1410.
Komunikace s logovacími službami:
Zdroj
Cíl
Port / Protokol
Popis
RELP
Logmanager
20514 / TCP
BEATS
Logmanager
5044 / TCP
Beats vstupní Plugin
Syslog
Logmanager
514 / UDP
Syslog
Logmanager
514 / TCP
O365 příjem logů
Logmanager
8443 / TCP
Příjem událostí z O365 (bez SSL inspekce)
Syslog
Logmanager
10514 / UDP
Syslog
Logmanager
10514 / TCP
Syslog
Logmanager
51000 - 51100 / UDP
Syslog
Logmanager
51000 - 51100 / TCP
Syslog
Logmanager
6514 / TCP
TLS
Logmanager automaticky ořízne každou příchozí Beat souborovou zprávu, která přesáhne velikost 64000 bajtů. Každá oříznutá zpráva bude automaticky označená jako truncated. Více informací naleznete zde - Beats.
Podpora výrobcem:
Zdroj
Cíl
Port / Protokol
Popis
SSH
Logmanager
22 / TCP
Přístup na webové rozhraní:
Zdroj
Cíl
Port / Protokol
Popis
Web
Logmanager
443 / TCP
WebUI
Komunikace agenta WES (podpora):
Zdroj
Cíl
Port / Protokol
Popis
WES
Logmanager
443 / TCP
Konfigurace agenta
WES
Logmanager
20514 / TCP
RELP
WES
Logmanager
20515 / TCP
TLS RELP
Komunikace s VMware:
Zdroj
Cíl
Port / Protokol
Popis
Logmanager
VMware
443 (default) / TCP
HTTPS access
Komunikace s SQL servery:
Zdroj
Cíl
Port / Protokol
Popis
Logmanager
Microsoft SQL
1433 / TCP
komponenta SQL
Logmanager
Microsoft SQL Server Browser
1434 / UDP
komponenta SQL
Logmanager
MySQL
3306 / TCP
komponenta SQL
Logmanager
Oracle Database
1521 / TCP
komponenta SQL
Logmanager
PostgreSQL
5432 / TCP
komponenta SQL
Komunikace s Logmanager Orchestratorem:
Zdroj
Cíl
Port / Protokol
Popis
Logmanager Orchestrator
Logmanager
443 / TCP
Konfigurace agenta
Logmanager Orchestrator
Logmanager
5044 / TCP
Beats vstupní Plugin
Komunikace Logmanager v rámci clusteru
Jak je v komunikační matici naznačeno, v rámci clusteru Logmanager komunikuje oběma směry. Komunikace a synchronizace dat zde probíhá mezi jednotlivými členy. Ke komunikaci používá TCP/443 a UDP/51820.
V případě nasazení Logmanager v clusteru je tedy potřeba povolit síťový prostup nejen směrem na jednotlivé členy, ale zároveň mezi členy samotnými. Jinými slovy, pro korektní funkci by měl mít každý člen clusteru identická firewallová pravidla.
Komunikace musí být povolena mezi všemi členy clusteru.
Důležité upozornění, POZOR na Logmanager komunikaci mezi forwardery/nody skrz firewally. Doporučujeme používat blackhole pro vaše interní subnety. Veškerá Logmanager komunikace probíhá skrz UDP porty. Některé firewally za určitých okolností nerespektují routovací tabulku, ale používají session tabulku pro odesílání paketů do špatného interface, což způsobí nefunkční komunikaci mezi Logmanagery/forwardery.
Příklad špatného chování FortiGate, pokud forwarder komunikuje skrz IPSEC interface na centrálu:
UDP session je navázána skrz IPSEC tunel.
IPSEC tunel se ocitne ve stavu down (výpadek internetu, rekonfigurace apod.), firewall deaktivuje routy vedoucí do tunelu.
Firewall zlikviduje session, nicméně UDP pakety stále chodí, vytvoří tedy novou session, dle aktuální routovací tabulky (zbývá jen defaultní route do internetu).
IPSEC tunel se znovu nastartuje a aktivuje route do tunelu.
Session nicméně stále existuje na interface do internetu, a jelikož UDP pakety stále přicházejí, jsou firewallem chybně odesílány do internetu.