Die FortiGate ist ein genialer Kommunikationsspezialist in vielfacher Hinsicht. Gleichzeitig ist es aber auch ein Türsteher und Wächter erster Güte. Von Zeit zu Zeit stellt sich nun die Frage, welcher dieser Qualitäten der Vorrang eingeräumt werden soll. Natürlich mögen wir alle die eierlegende Woll-Milch-Sau, auch wenn wir uns oft darüber amüsieren. Jedoch sind in gewissen Situationen Qualitäten gefragt, welche eine eierlegende Woll-Milch-Sau nicht bieten kann. Die FortiGate schon.
Update vom 12.05.2021: Fortinet stellt die Informationen über offene Ports und wozu diese verwendet werden nun im “Ports and Protocols” Dokument bereit. Dieses ist für die jeweilige FortiOS Version zu finden unter:
https://docs.fortinet.com/document/fortigate/6.4.0/ports-and-protocols/303168/fortigate-open-ports
Auf der FortiGate haben wir ein unglaublich breit-gefächertes Featureset. Vom SIP-Proxy über Multicast Support bis zum VXLAN ist alles vertreten was das Herz begehrt. Natürlich bieten gewisse Dienste eine grössere Angriffsfläche und andere eine weniger grosse. Die besten Chancen für ein einfaches Einbrechen über das Internet hat ein Angreifer, wenn Ports von aussen auf Anfragen antworten. Egal, ob diese auf der FortiGate beantwortet werden oder an einen DMZ Host weitergeleitet und von diesem beantwortet werden. Aus dem Aspekt der Sicherheit gesehen ist es daher erstaunlich, dass genau auf der FortiGate gewisse Ports auch aus öffentlichen Netzwerken erreichbar sind. Und noch erstaunlicher ist, dass diese auch dann erreichbar sind, wenn die zugehörigen Features ausser Betrieb sind und nicht genutzt werden.
Es handelt sich bei FortiOS 5.6 um folgende Ports:
UDP Port 68 (DHCP Client)
UDP Port 1144 (AeroScout Mobileview -> Kommunikation zu den FortiAP’s)
UDP Port 2000 (Cisco Skinny Client Control Protocol -> SCCP -> Wird vom SIP Proxy verwendet)
UDP Port 3799 (Radius COA -> Change Of Authorization)
UDP Port 8014 (EMS -> Um FortiClient-Diagnostikdaten abzufragen)
Zu finden sind diese Ports im WebGUI unter “Policy & Objects” -> “Local In Policy”. Möglicherweise muss dieser Menüpunkt zuerst eingeblendet werden: “System” -> “Feature Visibility” -> “Local In Policy”
Weitere Dienste sind in den “Local In Policies” zwar offen, bei korrekter Konfiguration jedoch nicht von öffentlichen Quellen erreichbar, wenn das Feature nicht genutzt wird. Der DHCP Port (68) wird unter 6.0.0 bereits automatisch geschlossen.
Die oben genannten Dienste können bei Nichtgebrauch in den “Local In Policies” geschlossen werden. Bei diversen anderen Diensten (Explicit Proxy, SIP Proxy, …) werden die Ports automatisch geschlossen, sobald die zugehörigen Dienste deaktiviert sind. Bei diesen fünf ist dies nicht der Fall. Wer Fortinet vertraut, dass die Serverdienste hinter diesen Ports genügend gehärtet sind, kann die Ports natürlich belassen wie sie sind. Wer auf Nummer sicher gehen will, prüft ob die Ports benötigt werden und schliesst die nicht benötigten dann mit eigenen Local-In Policies.
Im Fall von UDP Port 3799 sieht dies zum Beispiel folgendermassen aus:
config firewall service custom edit "radius-coa" set udp-portrange 3799 next end config firewall local-in-policy edit <id> set intf "any" set srcaddr "all" set dstaddr "all" set service "radius-coa" set schedule "always" next end
Nicht zu vergessen die Ports für Webfilter Override.
http://:8008 oder https://:8010
Ohne Trusted Hosts ist per Default für jeden von extern ersichtlich ob es sich um eine Fortigate handelt.
Lässt sich mit Local-in Policy von extern schliessen oder konfigurieren über:
# config webfilter fortiguard
(fortiguard) # get
cache-mode : ttl
cache-prefix-match : enable
cache-mem-percent : 2
ovrd-auth-port-http : 8008
ovrd-auth-port-https: 8010
ovrd-auth-port-https-flow: 8015
ovrd-auth-port-warning: 8020
ovrd-auth-https : enable
warn-auth-https : enable
close-ports : disable
request-packet-size-limit: 0
Etwas unschöner lässt es sich mit NAT und Deny Policy lösen