Site icon bintorosoft.com

Time-Based ACL: Zugriff nach Uhrzeit steuern

Red Snapper

Complex network illustrating data flow between various devices and applications.

In vielen Netzwerken reicht es nicht aus, Zugriffe nur nach Quelle, Ziel und Port zu filtern. Häufig gibt es organisatorische Anforderungen wie „Administrationszugriff nur während der Bürozeiten“, „Partnerzugriff nur im Wartungsfenster“ oder „bestimmte Dienste nachts sperren, um Missbrauch zu reduzieren“. Genau dafür ist eine Time-Based ACL (zeitbasierte Access Control List) in Cisco IOS/IOS XE gedacht: Sie können damit den Zugriff nach Uhrzeit steuern, ohne jedes Mal Regeln manuell zu aktivieren oder zu deaktivieren. Technisch kombiniert Cisco dafür klassische ACL-Einträge (Standard oder Extended) mit einem time-range-Objekt. Innerhalb dieses Zeitfensters greift die Regel wie gewohnt; außerhalb des Zeitfensters verhält sich der Eintrag so, als wäre er nicht vorhanden. Das ist ein wichtiger Unterschied: Zeitbasierte ACLs sind kein „Scheduler, der eine ACL an- und ausschaltet“, sondern eine zeitgesteuerte Bedingung pro Eintrag. Damit lassen sich Policies elegant und wartbar umsetzen – vorausgesetzt, Uhrzeit und Zeitzone sind korrekt konfiguriert. In der Praxis ist die Zeitbasis der häufigste Stolperstein: Wenn NTP nicht sauber läuft, die Zeitzone falsch ist oder Sommerzeitwechsel nicht berücksichtigt werden, greifen Regeln nicht wie geplant. Dieser Artikel zeigt Ihnen Schritt für Schritt, wie Sie Time-Based ACLs auf Cisco Geräten einrichten, welche Use Cases sich bewährt haben, wie Sie Zeitfenster sicher definieren, wie Sie die Wirkung verifizieren und welche Best Practices Sie im Betrieb beachten sollten.

Was ist eine Time-Based ACL und wie funktioniert sie?

Eine Time-Based ACL ist keine eigene ACL-Art, sondern eine Erweiterung klassischer ACLs durch ein Zeitobjekt. Sie definieren zuerst einen Zeitbereich mit time-range und binden diesen anschließend in eine ACL-Zeile ein – über das Schlüsselwort time-range. Innerhalb des definierten Zeitfensters wird die Zeile ausgewertet (permit/deny). Außerhalb des Zeitfensters gilt: Die ACL-Zeile matcht nicht, als wäre sie nicht vorhanden. Dadurch entsteht ein sehr flexibles Verhalten, das man sauber planen muss: Wenn ein deny-Eintrag außerhalb des Zeitfensters „wegfällt“, kann der Traffic je nach restlichen ACL-Regeln plötzlich erlaubt sein.

Für ACL-Grundlagen und allgemeine Konfigurationsprinzipien eignet sich der Anchor-Text Cisco ACL Grundlagen und Konfiguration. Für Befehlsvarianten je IOS/IOS XE-Version ist die Cisco IOS Command Reference eine verlässliche Quelle.

Typische Use Cases: Zugriff nach Uhrzeit steuern

Time-Based ACLs sind besonders sinnvoll, wenn Sicherheits- oder Betriebsprozesse an feste Zeitfenster gekoppelt sind. Typische Beispiele aus der Praxis:

Wichtig: Time-Based ACLs sind kein Ersatz für Identity- und Rollenmodelle (AAA, NAC, Zero Trust). Sie sind ein ergänzender Kontrollmechanismus, der organisatorische Regeln technisch unterstützt.

Voraussetzung Nummer 1: Korrekte Uhrzeit, Zeitzone und NTP

Die beste Time-Based ACL ist wertlos, wenn die Uhrzeit nicht stimmt. Deshalb ist die Zeitbasis die wichtigste Best Practice: Zeitzone korrekt setzen, Sommerzeit berücksichtigen (falls relevant) und NTP stabil konfigurieren. In produktiven Umgebungen ist NTP Pflicht, weil Geräteuhren sonst driften.

Zeitzone und Sommerzeit (Beispiel)

configure terminal
clock timezone CET 1
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
end

Hinweis: Die genaue Sommerzeit-Syntax kann je nach IOS/IOS XE-Version variieren. Prüfen Sie die Kommandoreferenz Ihrer Plattform. Wenn Sie Sommerzeit nicht nutzen (z. B. in reinen UTC-Setups), sollten Sie konsequent in UTC arbeiten und die Zeitfenster entsprechend definieren.

NTP konfigurieren (Beispiel)

configure terminal
ntp server 10.10.10.10
ntp server 10.10.10.11
end

Verifikation:

show clock
show ntp status
show ntp associations

Best Practice: Nutzen Sie mindestens zwei NTP-Server, idealerweise aus unterschiedlichen Pfaden, und überwachen Sie NTP-Status. Eine falsche Uhrzeit ist eine typische Root Cause, wenn zeitbasierte Regeln „unerwartet“ greifen.

Time-Range erstellen: Absolute, periodische und wiederkehrende Zeitfenster

Ein time-range ist ein benanntes Objekt. Innerhalb dieses Objekts definieren Sie, wann es aktiv ist. Cisco unterstützt typischerweise mehrere Formen:

Beispiel: Bürozeiten Mo–Fr 08:00–18:00

configure terminal
time-range OFFICE-HOURS
periodic weekdays 8:00 to 18:00
end

Beispiel: Wartungsfenster samstags 22:00–02:00

Für Zeitfenster, die über Mitternacht gehen, ist eine saubere Definition wichtig. Je nach IOS-Variante ist es oft am sichersten, zwei Perioden zu definieren (Samstag 22:00–23:59 und Sonntag 00:00–02:00), um Interpretationsfehler zu vermeiden.

configure terminal
time-range MAINT-WINDOW
periodic Saturday 22:00 to 23:59
periodic Sunday 0:00 to 2:00
end

Beispiel: Zeitlich befristete Freigabe (absolut)

Ein absoluter Zeitraum eignet sich für temporäre Projekte oder Ausnahmezugänge:

configure terminal
time-range TEMP-PROJECT
absolute start 09:00 01 March 2026 end 18:00 31 March 2026
end

Best Practice: Absolut-Zeitfenster sollten immer mit Change-ID und Owner dokumentiert werden, damit klar ist, warum die Regel existiert und wann sie ausläuft.

Time-Based ACL in der Praxis: Extended ACL mit Time-Range

Die häufigste Anwendung ist eine Extended ACL, die einen bestimmten Service nur innerhalb eines Zeitfensters erlaubt oder verbietet. Beispiel: Ein Partnernetz darf einen internen Wartungsserver nur im Wartungsfenster erreichen, und zwar nur per SSH (TCP/22) und HTTPS (TCP/443).

Beispiel: Partnerzugriff nur im Wartungsfenster

configure terminal
ip access-list extended PARTNER-MAINT
remark Partnernetz darf nur im Wartungsfenster auf Maint-Server
permit tcp 198.51.100.0 0.0.0.255 host 10.10.50.10 eq 22 time-range MAINT-WINDOW
permit tcp 198.51.100.0 0.0.0.255 host 10.10.50.10 eq 443 time-range MAINT-WINDOW
remark Ausserhalb des Wartungsfensters alles zu diesem Host blocken
deny ip 198.51.100.0 0.0.0.255 host 10.10.50.10
permit ip any any
end

Warum steht hier ein dauerhaftes Deny (ohne time-range)? Weil die Permit-Regeln außerhalb des Zeitfensters nicht matchen würden – und ohne ein bewusstes Deny könnte der Traffic durch spätere „permit“-Regeln eventuell doch erlaubt werden. Dieses Muster ist eine wichtige Best Practice: Zeitbasierte Permits sollten oft durch klare Denies ergänzt werden, wenn die Policy außerhalb des Fensters restriktiv bleiben soll.

ACL anwenden

Sie binden die ACL wie gewohnt an ein Interface, typischerweise inbound nahe an der Quelle:

configure terminal
interface vlan 100
ip access-group PARTNER-MAINT in
end

Time-Based ACL für Management: Zugriff auf SSH nach Uhrzeit

Ein weiterer sehr praxisnaher Use Case ist Managementzugriff. Häufig sollen Router/Switches nur aus Adminnetzen erreichbar sein – und idealerweise nur zu definierten Zeiten. Hier ist es wichtig zu unterscheiden:

Beispiel: Admin-SSH nur Mo–Fr 08:00–18:00

Schritt 1: Time-Range definieren:

configure terminal
time-range MGMT-HOURS
periodic weekdays 8:00 to 18:00
end

Schritt 2: Standard ACL mit Zeitbedingung nutzen:

configure terminal
ip access-list standard MGMT-SSH-TIME
remark Adminnetz darf nur zu MGMT-HOURS auf VTY
permit 10.100.0.0 0.0.255.255 time-range MGMT-HOURS
deny any
end

Schritt 3: Auf VTY anwenden:

configure terminal
line vty 0 4
transport input ssh
access-class MGMT-SSH-TIME in
login local
end

Best Practice: Bei zeitbasiertem Managementzugriff müssen Sie einen Notfallzugang planen. Ein lokaler Break-Glass-User und Console-/Out-of-Band-Zugriff sind essenziell, falls eine Zeitregel falsch greift oder NTP ausfällt.

Reihenfolge und „implizites deny“ bei Time-Based ACLs

Das wichtigste Denkmuster lautet: Außerhalb des Zeitfensters sind zeitgebundene Einträge „unsichtbar“. Das kann zwei gegensätzliche Effekte haben:

Deshalb sollten Sie ACLs, die zeitbasierte Regeln enthalten, besonders bewusst strukturieren:

Object Groups und Time-Range kombinieren: Effizient und wartbar

In größeren Umgebungen wird die ACL schnell unübersichtlich, wenn Sie viele Hosts und Services zeitgebunden steuern. Hier sind Object Groups besonders hilfreich: Sie fassen Netze und Ports zusammen und kombinieren diese dann mit einem time-range. Dadurch bleibt die Policy auch bei Wachstum lesbar.

Beispiel: Web-Ports als Service-Gruppe, Partnernetze als Netzwerkgruppe

configure terminal
object-group network PARTNER-NETS
network-object 198.51.100.0 255.255.255.0
object-group service WEB-PORTS tcp
port-object eq 80
port-object eq 443
time-range PARTNER-WEB-HOURS
periodic weekdays 9:00 to 17:00
ip access-list extended PARTNER-WEB
permit tcp object-group PARTNER-NETS host 10.10.60.20 object-group WEB-PORTS time-range PARTNER-WEB-HOURS
deny ip object-group PARTNER-NETS host 10.10.60.20
permit ip any any
end

Dieses Muster ist besonders effizient, weil Änderungen (neuer Partner, zusätzlicher Port) in der Objektgruppe erfolgen und nicht in jeder ACL-Zeile.

Verifikation: So prüfen Sie, ob die Zeitregel wirklich greift

Time-Based ACLs sollten Sie immer verifizieren – sowohl innerhalb als auch außerhalb des Zeitfensters. In Cisco IOS/IOS XE sind diese Befehle in der Praxis besonders hilfreich:

Wichtig: Trefferzähler (Hit Counter) sind oft der schnellste Realitätscheck. Wenn innerhalb des Fensters ein Permit nie Treffer bekommt, matcht entweder die ACL nicht, sie ist am falschen Interface gebunden oder der Traffic läuft anders (Routing/PBR). Wenn außerhalb des Fensters dennoch Traffic durchkommt, ist meistens eine andere Permit-Regel verantwortlich oder ein Deny fehlt.

Logging: Sinnvoll einsetzen, ohne Logflut

ACL-Logging kann in zeitbasierten Szenarien besonders nützlich sein, weil Sie sichtbar machen möchten, ob außerhalb des Fensters tatsächlich geblockt wird. Gleichzeitig gilt: Ein pauschales deny ip any any log kann Logs und CPU belasten, vor allem auf stark genutzten Links. Best Practices:

Typische Fehler und wie Sie sie vermeiden

Best Practices für den Betrieb

Als ergänzende Orientierung für Zugriffsmanagement, Logging und Change-Disziplin ist der Anchor-Text CIS Controls hilfreich, weil dort Best Practices für sichere Betriebsprozesse und nachvollziehbare Änderungen beschrieben werden.

Praxis-Checkliste: Time-Based ACL sicher einführen

copy running-config startup-config

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version