Das GUI als auch die CLI sollen gleichwertig benutzbar sein. Features, die den jeweils anderen Weg behindern sind zu vermeiden.
remarks in ACLs stehen vor der betreffenden ACL.
Zusätzlich sollten remarks mit einem „v“ markiert werden, um zu zeigen, dass sich der Kommentar auf die folgende Zeile bezieht
Kommaseparierte object-groups im GUI sind zu vermeiden, weil dieses Feature durch automatisch generierte object-groups emuliert wird, die im CLI schwer verständlich sind
Konzeptionell
Vermeiden sie NAT/PAT so lange wie möglich. Für NAT/PAT muss die Firewall im gesamten Protokoll IP und Ports umschreiben, dazu muss die Firewall das Protokoll unterstützen. Dies ist aber für viele neueren oder selbst entwickelte Protokolle nicht der Fall.
Sichern sie ihre Konfiguration vor und nach Änderungen
Benutzen sie wo möglich VLANs
Benutzen sie wo möglich virtuellen Kontexte
Vermeiden sie doppelte IPs auch in privaten lokalen Netzen; man weiss nie ob man sie nicht doch irgendwann verbinden muss.
Aktualisieren sie ihre Firewall-Firmware (latest patchlevel of your release) in regelmaessigen Abstaenden (z.B. alle zwei Wochen)
Fehlersuche
Erlauben sie den Teil von ICMP, der für ping und traceroute nötig ist
Benutzen sie packet tracer um ihr Regelwerk zu prüfen
Setzen sie ein explicites Deny an das Ende ihrer ACL. Am Ende jeder ACL werden Pakte verworfen (implizites Deny), dieses wird aber nicht geloggt, darum ist es ratsam ans Ende der ACL nochmal explizit eine Deny-Regel zu setzen, damit man nachvollziehen kann welche Pakete dort verworfen werden.
Halten sie in ihrem IP-Range bewusst kleinere Bereiche frei, die nie vergeben werden dürfen (Dark-IP-Ranges) und setzen sie dann eine Art Alarmregel, wenn diese IPs, die eigentlich nie vorkommen dürfen, benutzt werden (das sind dann meist Angriffe oder Fehlkonfigurationen)
Vermeiden sie es zur Fehlersuche Regeln zu löschen, sondern setzen sie sie auf inactive.
Saubere und verständliche Konfiguration
Orientieren sie sich bei der Konfiguration an den Cisco Config Guides und Beispielen
Widerstehen sie der Versuchung jedes oder sehr viele 'expotische' Features zu nutzen. Es ist meist sicherer, eine einfache und verständliche Konfiguration zu haben, statt für ein bischen 'mehr' Sicherheit eine unverständliche Konfiguration zu riskieren.
Benutzen sie object-groups um gängige Dienste zusammenzufassen
Benutzen sie generell Standardschablonen (Templates) für object-groups und ganz allgemein sich wiederholdene Konfigurationsteile
Versuchen sie generell ihre Konfiguration so einfach wie möglich zu halten
Benutzen sie 'description' und 'remark' um ihre Konfiguration zu kommentieren
Versehen sie 'description' und 'remark' mit einen ' – ' am Anfang, um diese in der Konfig leicht zu finden (oder einem anderen auffallenden Marker)
Benutzen sie ein einheitliches Namensschema (interfaces, object-groups, hosts usw)
Benutzen sie vom Interface aus betrachtet nur Filter für eingehenden Traffic nicht für Ausgehenden (inbound-ACLs nicht am mit outbound-ACLs am gleichen Interface mixen).
Technische Tips
Sortieren sie die meistgenuzten ACL-Komponenten an den Anfang der Liste (Performance)
Nützen sie im Failover-Setup ein Interface für die Uebertragung von Status uns Verbindungszustand (failover lan and failover state)
Erstmaliges Aufsetzen
Starten sie mit einer definierten bzw. leeren Konfiguration (clear configuration all oder configure factory-default)
Optinal
Aktivieren sie reverse path check. D.h. das SG checkt, ob das Paket, das an dem Interface ankommt, überhaupt aus dieser Richtung routingtechnisch ankommen darf.
Aktivieren sie an den Switchen in der DMZ private VLANs. D.h. Server innerhalb einer DMZ können nur zum Gateway kommunizieren, aber nicht untereinander. Dadurch gewinnt man zusätzliche Sicherheit und man kann die DMZs evtl. weniger kleinteilig konzeptionieren.