Realtime-Attack-Map
SURICATA / LIVE FEED

Standardvorgaben für Firewall-Konfigurationen (Check Point & FortiGate)

Diese Referenz definiert die verbindlichen Namenskonventionen, Syntax-Vorgaben und Skript-Templates für die Automatisierung von Firewall-Regelwerken. Sie gilt primär für Check Point R82 und FortiOS 7.4.

1. Objektbenennung

Die Namensgebung für alle Netzwerk- und Host-Objekte muss strikt dem folgenden Schema folgen:

Schema: <SYSTEMCODE>[-<SYSTEMCODE2>][6]-<TYPE>-<LOCATION>.<bezeichnung>

Parameter-Definition:

  • SYSTEMCODE: max. 8 Zeichen, ausschließlich Kleinbuchstaben, abgeleitet aus der Einrichtung oder Anwendung (z. B. sap, ldap).
  • SYSTEMCODE2: (Optional) max. 8 Zeichen, Kleinbuchstaben. Wird nur genutzt, wenn das Objekt Teil eines übergeordneten, komplexen Systems ist.
  • 6: Wird direkt und ohne Bindestrich an den letzten SYSTEMCODE angehängt, aber ausschließlich bei IPv6-Objekten. Bei IPv4 wird dies komplett weggelassen.
  • TYPE:
    • h = Host / Gateway
    • n = Netzwerk
    • r = Adressrange
    • g = Gruppe
    • t = NAT-Objekt
  • LOCATION: IATA-Flughafencode des Standorts (z. B. fra, bre).
    • ext = Partner / Internet
    • div = Standortübergreifend
  • bezeichnung: Fachlich sprechender Name, ausschließlich Kleinbuchstaben (aus Auftrag, IPAM, Assetdaten, bzw. abgeleitet von SourceHostname/DestinationHostname).

Kollisionsregel:

Haben zwei Objekte denselben generierten Namen, verweisen aber auf unterschiedliche IP-Adressen, ist ein Suffix anzuhängen (-2, -3, etc.).

Beispiele Netzwerkobjekte:

  • sap-n-fra.dmz-prod (Netzwerk, IPv4)
  • ldap-sap6-h-ext.dc01 (Host, IPv6)
  • backup-h-fra.srv01 (Host, IPv4)

Vorgaben für Service-Objekte:

  • ICMP: icmp-proto / PING
  • TCP Port 22: ssh / SSH
  • UDP Port 161: snmp / SNMP
  • UDP Port 162: udp_162 / SNMPTRAP
  • Sonstige TCP/UDP Ports: tcp_<PORT> oder udp_<PORT> (z. B. tcp_15671)

2. Check Point (R82.10) - Konfigurationsvorlagen

2.1 CLISH (Interfaces & Routen)

Aufbau von Interfaces erfolgt immer in der Reihenfolge: physisches Interface → VLAN → IPs setzen → Interface aktivieren (state on) → Routen setzen. Der Abbau erfolgt exakt umgekehrt (Routen löschen → IPs entfernen → state off). Soll ein Route migriert werden, so ist sie zuerst zu entfernen und danach die neue Route anzulegen.

Beispiel Aufbau (Hinzufügen):

add interface eth-s1p2 vlan 1644
set interface eth-s1p2.1644 ipv4-address 10.231.210.50 mask-length 28
set interface eth-s1p2.1644 state on
set static-route 10.0.0.0/8 nexthop gateway address 10.1.2.254 on

Beispiel Abbau (Entfernen):

set static-route 10.0.0.0/8 off
delete interface eth1-02 ipv4-address
set interface eth1-02 state off

2.2 API Skript (mgmt_cli) für Objekte & Regeln

Die Erstellung auf dem Management-Server (SmartCenter) erfolgt über ein Bash-Skript nach dem unten angegebenen Vorschlag. Es muss immer geprüft werden, ob ein Objekt mit der entsprechenden IP bereits existiert, um Duplikate zu vermeiden (Prüfung auf IP-Adresse, nicht Name!). Neue Regeln werden immer als letzte Regel (position last) angefügt. Policy-Paket und Access-Layer sollen im Script abgefragt werden. Weitere fehlende Informationen müssen durch das Script beim User abgefragt werden, sodass auf jeden Fall ein Script ausgegeben werden kann. Da bei Löschaufträgen die UUID nicht aus dem Auftrag hervorgeht, sollen durch das Script nur Elemente hinzugefügt werden. Zu löschende Elemente sollte als Anleitung ausgegeben werden.

Standard-Skriptrahmen:

#!/bin/bash
# Login-Daten abfragen
read -rp "SmartCenter-Benutzer: " SC_USER
read -rsp "Passwort: " SC_PASS; echo
read -rp "Policy Package / Access Layer: " SC_LAYER

# Session initialisieren
SESSION=$(mgmt_cli login user "$SC_USER" password "$SC_PASS" --format json \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['sid'])")

# Existenzprüfung und Anlage von Objekten
EXISTING=$(mgmt_cli -s "$SESSION" show hosts limit 500 --format json | \
  python3 -c "import sys,json; d=json.load(sys.stdin); \
[print(o['name']) or exit() for o in d.get('objects',[]) if o.get('ipv4-address')=='10.1.2.3']")

if [ -z "$EXISTING" ]; then
  mgmt_cli -s "$SESSION" add host name "sap-h-fra.appserver01" ipv4-address "10.1.2.3"
  OBJ_SAP_H_FRA_APPSERVER01="sap-h-fra.appserver01"
else 
  OBJ_SAP_H_FRA_APPSERVER01="$EXISTING"
fi

# Anlage der Regel (Nutzung der Variablen ohne führendes $)
mgmt_cli -s "$SESSION" add access-rule layer "$SC_LAYER" position last name "RULE-NAME" source "$OBJ_SAP_H_FRA_APPSERVER01" destination "ANY" service "SSH" action "Accept"

# Änderungen publizieren und abmelden
mgmt_cli -s "$SESSION" publish
mgmt_cli -s "$SESSION" logout

3. FortiOS (7.4.11) - Konfigurationsvorlagen

3.1 Interfaces und VLANs

config system interface
  edit "eth1.1298"
    set vdom "root"
    set ip 10.1.2.1 255.255.255.0
    set vlanid 1298
    set interface "eth1"
  next
end

3.2 Statisches Routing

config router static
  edit 0
    set dst 10.0.0.0 255.0.0.0
    set gateway 10.1.2.254
    set device "eth1.1298"
  next
end

Soll ein Route migriert werden, so muss vom Admin die Nummer der Route beschafft werden. In der Ausgabe muss danach gefragt werden, um den vollständigen Auftrag auszugeben.

3.3 Adress-Objekte

config firewall address
  edit "sap-n-fra.dmz-prod"
    set type ipmask
    set subnet 10.1.2.0 255.255.255.0
  next
end

3.4 Firewall Policies (Regelwerk)

Regeln werden bei FortiGate standardmäßig mit edit 0 am Ende angehängt (Next Free ID).
Regelnamen (set name): Sofern im Auftrag kein Regelname vorgegeben ist, werden diese automatisch generiert. Werden fortlaufende IDs im Namen verwendet, erfolgen diese zur Wahrung der Übersichtlichkeit immer in 10er-Schritten (z. B. POLICY-0010, POLICY-0020).

config firewall policy
  edit 0
    set name "POLICY-0010"
    set srcintf "eth0"
    set dstintf "eth1"
    set srcaddr "sap-h-fra.appserver01"
    set dstaddr "sap-n-fra.dmz-prod"
    set service "SSH"
    set action accept
    set logtraffic all
  next
end