Offene Ports an der FortiGate

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

One thought on “Offene Ports an der FortiGate

  1. Ruben Reply

    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

Leave a Reply

Your email address will not be published. Required fields are marked *