Time-Based ACL: Zugriff nach Uhrzeit steuern

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.

• Time-Range: definiert, wann eine Regel aktiv ist.
• ACL bleibt aktiv: Sie wenden die ACL wie gewohnt an Interface/VTY an; nur einzelne Einträge sind zeitgesteuert.
• Implizites deny bleibt: Am Ende jeder ACL steht weiterhin das implizite deny any, sofern nicht anders erlaubt.
• First Match: Reihenfolge bleibt entscheidend – auch bei Zeitbedingungen.

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:

• Administrationszugriff nur zu Bürozeiten: SSH/HTTPS/Management nur Mo–Fr 08:00–18:00 aus Adminnetzen.
• Wartungsfenster: Partnerzugang zu einem System nur samstags 22:00–02:00 (geplant und dokumentiert).
• Temporäre Freigaben: Eine Regel gilt nur bis zu einem Datum (z. B. Projektphase), danach automatisch inaktiv.
• Nachtabschaltung bestimmter Services: z. B. SMB/RDP in einem Segment außerhalb definierter Zeiten blocken, um Missbrauch zu reduzieren.
• Gastnetz-Policies: Gäste haben nur tagsüber Zugang zu bestimmten Ressourcen, nachts wird restriktiver gefiltert.

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:

• Absolute: gültig zwischen zwei konkreten Zeitpunkten (z. B. nur in einem Projektfenster).
• Periodic: wiederkehrend nach Muster (z. B. Mo–Fr 08:00–18:00).
• Mehrere Einträge: Ein Time-Range kann mehrere Perioden enthalten (z. B. getrennte Zeitfenster pro Tag).

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:

• Management auf VTY: Zugriff auf SSH wird häufig über access-class geregelt (Standard ACL).
• Management über Interface ACL: möglich, aber VTY-Filter ist oft sauberer, weil er direkt den Loginweg schützt.

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:

• Zu offen: Ein zeitgebundenes deny fällt weg, und später erlaubt eine Permit-Regel den Traffic.
• Zu restriktiv: Ein zeitgebundenes permit fällt weg, und am Ende greift implizites deny.

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

• Spezifische zeitgebundene Permits vor allgemeine Regeln.
• Wenn außerhalb des Fensters Block gewünscht ist: ein dauerhaftes Deny (ohne time-range) für die gleiche Zielmenge ergänzen.
• Wenn außerhalb des Fensters „normaler Traffic“ weiterlaufen soll: die restlichen Permits so schreiben, dass sie die gewünschte Basispolicy abbilden.

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:

• show clock (Uhrzeit, Zeitzone)
• show ntp status (NTP synchron?)
• show time-range (zeigt definierte Zeitbereiche und deren Status)
• show ip access-lists (ACL-Zeilen und Hit Counter)
• show running-config | section time-range (Konfigcheck)

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:

• Logging nur auf eng matchenden Denies einsetzen (z. B. nur für Partnernetz → Zielhost).
• Logging eher temporär für Diagnose aktivieren und danach wieder entfernen.
• Primär mit Hit Countern arbeiten, da sie performanter sind.

Typische Fehler und wie Sie sie vermeiden

• NTP fehlt oder Uhrzeit falsch: Regel greift „zur falschen Zeit“. Lösung: NTP redundant, Zeitzone/Sommerzeit sauber konfigurieren, NTP überwachen.
• Mitternacht und Wochenenden: Zeitfenster über Mitternacht falsch definiert. Lösung: Fenster in zwei Perioden teilen (z. B. Samstag + Sonntag).
• Außerhalb zu offen: Zeitgebundene Denies fallen weg, spätere Permits erlauben Traffic. Lösung: Basispolicy bewusst definieren, ggf. dauerhaftes Deny ergänzen.
• Außerhalb zu restriktiv: Zeitgebundene Permits fallen weg, implizites deny blockt alles. Lösung: Restliche Permits prüfen, Basispolicy vollständig machen.
• Falsche Platzierung: ACL am falschen Interface oder falsche Richtung (in/out). Lösung: Datenfluss prüfen, Bindings verifizieren.
• Management-Lockout: Zeitgebundene VTY-ACL sperrt Adminzugang. Lösung: Break-Glass-Account, Console/OOB, Änderungen mit zweiter Session testen.

Best Practices für den Betrieb

• Time-Range-Namen sprechend wählen: z. B. OFFICE-HOURS, MAINT-WINDOW, PARTNER-WEB-HOURS.
• Policy dokumentieren: remarks in ACLs, description in Object Groups; Owner und Zweck festhalten.
• Änderungen schrittweise: erst erweitern, testen, dann bereinigen; Rollback vorbereiten.
• Monitoring: NTP-Status, ACL-Hits und relevante Deny-Events überwachen.
• Least Privilege: Zeitsteuerung ergänzt Sicherheitsprinzipien, ersetzt sie aber nicht (z. B. AAA, Segmentierung, starke Authentifizierung).

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

• Ist die Zeitbasis korrekt (Zeitzone, Sommerzeit, NTP synchron)?
• Ist das Zeitfenster eindeutig definiert (auch über Mitternacht/Wochenenden)?
• Ist klar, was außerhalb des Fensters passieren soll (blocken oder Basispolicy)?
• Ist die ACL korrekt gebunden (Interface/SVI, Richtung in/out oder VTY access-class)?
• Sind DNS, Rückwege und notwendige Nebenservices berücksichtigt?
• Wurden Hit Counter innerhalb und außerhalb des Fensters geprüft?
• Gibt es einen Notfallzugang (Break-Glass, Console/OOB), besonders bei Management-ACLs?

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:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

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.