Alter des Cisco Gerätes über Seriennummer ermitteln

Das Alter eines Cisco Gerätes

Das Alter eines Cisco Gerätes kann man recht einfach mit „show inventory“ aus der  Seriennummer des Gerätes raus bekommen.
Die 4+5 Stelle gibt das Herstellungs-Jahr an, die 6+7 Stelle die Produktions-Woche.

Code für das Jahr:

01 = 1997  09 = 2005 17 = 2013 25 = 2021
02 = 1998 10 = 2006 18 = 2014 26 = 2022
03 = 1999 11 = 2007 19 = 2015 27 = 2023
04 = 2000 12 = 2008 20 = 2016 28 = 2024
05 = 2001 13 = 2009 21 = 2017 29 = 2025
06 = 2002 14 = 2010 22 = 2018 30 = 2026
07 = 2003 15 = 2011 23 = 2019 31 = 2027
08 = 2004 16 = 2012 24 = 2020 32 = 2028

Code für die Woche:

01-05 : Januar 15-18 : April 28-31 : Juli 41-44 : Oktober
06-09 : Februar 19-22 : Mai 32-35 : August 45-48 : November
10-14 : März  23-27 : Juni 36-40 : September 49-52 : Dezember

Hier noch ein Beispiel:

Router#show inventory
NAME: „chassis“, DESCR: „1841 chassis“
PID: CISCO1841         , VID: V05 , SN: FHK1120184B
[…]

Das wäre dann ein Gerät aus Mai 2007.

Windows Event Log kann nach Archivieren nicht gelöscht werden

Event-Log löschen

Mit dem Programm Eventsave von Frank Heyne Software ist es sehr einfach möglich in regelmäßigen Zeitabständen das Event Log eines Windows Rechners zu archivieren. Damit der Zugriff auf das Windows Event Log funktioniert lassen sich auf dem zu archivierenden Rechner entsprechende Berechtigungen vergeben, die einen Zugriff auf das Event Log einschränken oder sogar ganz verbieten.

Für die Zugriffsberechtigung wird ein passender SID String in der Registry benötigt, der im Format der Microsoft SDDL (security descriptor definition language) sein muss. In der Microsoft Knowlegde Base findet sich unter http://support.microsoft.com/kb/323076 eine Anleitung wo der Eintrag in der Registry zu finden ist. Leider fehlt dort aber eine brauchbare Beschreibung welche Teile der Berechtigung angepasst werden müssen, damit die archivierten Event Logs auch gelöscht werden können. Die Berechtigungen werden wie hier zu sehen ist gespeichert:

O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0005;;;SY)(A;;0x3;;;BA)(A;;0x3;;;DA)

In blau sind hier die Berechtigungen dargestellt. In rot sind hier die Benutzer Gruppen angegeben, für die die jeweilige Berechtigung gilt.

Berechtigungen

Die Berechtigungen werden addiert als hexadezimale Zahl dargestellt:

1 = Lesen
2 = Schreiben
4 = Löschen

Eine 5 wäre also Lesen + Löschen, eine 3 wäre Lesen + Schreiben.

Die Benutzer Gruppen werden im Microsoft MSDN im Artikel http://msdn.microsoft.com/en-us/library/windows/desktop/aa379602%28v=vs.85%29.aspx ausführlich beschrieben. Folgende Gruppen werden hier im Beispiel benutzt:

AN = Anonymous logon
BG = Built-in guests
SY = Local system
BA = Built-in administrators
DA = Domain administrators

Für den Zugriff von einem entfernten System auf das Event Log muss also die Berechtigung für die Gruppe „DA“ angepasst werden, von Lesen + Schreiben (3) auf Lesen + Schreiben + Löschen (7). Der geänderte Eintrag unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog\Security\CustomSD sieht nach der Änderung etwas so aus:

O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0005;;;SY)(A;;0x3;;;BA)(A;;0x7;;;DA)

Leider gibt es in Windows nicht die Möglichkeit den Eintrag per Script gezielt um ein Recht zu erweitern. Die einzige Möglichkeit ist den Eintrag vollständig neu zu schreiben. Deswegen sollte man sich auch vorher den Eintrag auslesen da die Berechtigungen je nach Art der Installation und der installierten Dienste noch weitere Einträge beinhalten kann. Wenn der Eintrag „A;;0x7;;;DA“ in dem SID String nicht vorhanden ist, dann gibt es dafür auch keine Zugriffsbeschränkungen. Das Löschen des Eintrags sollte jedoch wohl überlegt sein.

 

APC USV an Windows 2003 Server per Radius authentifizieren

APC USV authentifizieren

Die Firma APC bietet für fast alle USVs eine passende Netzwerk Schnittstelle an. Wenn man mehrere dieser USVs im Unternehmen hat ist es sehr aufwendig auf jeder der Karten die Benutzer zu pflegen. Ein weiteres Manko an der Karte ist das es nur 3 Benutzer gibt. Wer mehrere Administratoren im Unternehmen hat wünscht sich hier natürlich pro Administrator eine eigene Benutzerkennung um eine USV zu konfigurieren.

Einfacher und besser als mit den 3 eingebauten Benutzern geht das mit einem Radius Server der eine zentrale Authentifizierung erlaubt. Der Windows 2003 Server bietet einen solchen Radius Server mit Bordmitteln an, er muss nur noch installiert werden.

Damit die APC USVs per Radius eingebunden werden kann muss der Microsoft IAS Server dafür vorbereitet werden. Als Erstes wird ein Radius Client angelegt, dessen Name mit „APC“ beginnt und dessen IP-Adresse auf die Management Karte der USV verweist. Der Name wird extra so gewählt damit er später im Radius Server zugeordnet werden kann.

Windows Konfiguration

Damit die USV später vollständig konfiguriert werden kann muss für die USVs eine separate RAS-Richtlinie   erstellt werden.

APC Policy Bild 1

Die neue Richtlinie bekommt einen Namen (ich habe hier „APC“ gewählt) und es wird die „Benutzerdefinierte Richtlinie“ verwendet. Danach geht es mit „Weiter“ zur nächsten Seite.

APC Policy Bild 2

Nun wird die Windows Benutzergruppe mit einem Eintrag freier Wahl und der Eintrag „Client-Friendly-Name“ mit dem Wert „APC*“ gefüllt und eingetragen. Die Richtlinie zieht dann nur noch wenn der Radius-Client Name mit „APC“ anfängt. Statt „APC“ kann natürlich auch ein anderer Name gewählt werden.

APC Policy Bild 3

Im nächsten Schritt wird die Berechtigung verteilt.

APC Policy Bild 4

Nun muss noch das Profil angepasst werden. Bei der Authentifizierung müssen alle Verschlüsselungsmethoden deaktiviert werden, nur die unverschlüsselte Authentifizierung (PAP, SPAP) wird aktiviert.

APC Policy Bild 5

Unter der Lasche „Verschlüsselung“ wird nur „Keine Verschlüsselung“ ausgewählt. Alle anderen werden deaktiviert.

APC Policy Bild 6

Unter der Lasche „Erweitert“ werden alle vorhandenen Attribute gelöscht und das Attribut „Service-Type“ mit dem Wert „Administrative“ eingetragen.

APC Policy Bild 7

Nun ist der Radius Server soweit vorbereitet das er die passenden Attribute an die APC USV übergeben kann, so das man auch in das Administrations-Menü der USV gelangt.

 

Cisco: ATM-Interface mit mehreren PPPOE Sessions zum DSL Provider

Wer in der glücklichen Lage ist mehr als einen DSL-Zugang zu haben wird auf den Cisco Seiten schnell fündig wie er einen Cisco Router einrichten muss damit er ins Netz kommt. Das wollte ich auch gleich mal ausprobieren und parallel zu meinem T-DSL Zugang einen weiteren Provider benutzen, über den ich eine feste IP-Adresse bekomme. Seit dem IOS Release 12.4(15) gibt es dazu die Möglichkeit mehr als eine dialer-group am ATM-Interface zu definieren. Also schnell mal eingestellt und probiert.


!
interface ATM0/0/0
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
no atm ilmi-keepalive
pvc 1/32
pppoe-client dial-pool-number 2
pppoe-client dial-pool-number 1
!
!
interface Dialer1
description # DSL Telekom
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
no cdp enable
ppp authentication pap chap callin
ppp chap hostname 00XXXXX0001@t-online.de
ppp chap password 7 XXXXX
ppp pap sent-username 00XXXXX0001@t-online.de password 7 XXXXX
ppp ipcp dns request accept
ppp ipcp route default
ppp ipcp address accept
!
!
interface Dialer2
description # DSL VIADSL
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 2
no cdp enable
ppp authentication pap chap callin
ppp chap hostname XXXXX@viadsl.de
ppp chap password 7 XXXXX
ppp pap sent-username XXXXX@viadsl.de password 7 XXXXX
ppp ipcp dns request accept
ppp ipcp route default
ppp ipcp address accept
!

Nach ein paar Versuchen stellte sich sehr schnell Frustration ein, da der Router immer nur zu einem der beiden Provider eine Verbindung aufgebaut hat. Ein Blick in „show pppoe sesions“ bestätigte das:

2 client sessions

Uniq ID  PPPoE  RemMAC          Port                  Source   VA         State
SID  LocMAC                                         VA-st
N/A    580  0090.1a41.650c  ATM0/0/0              Di2      Vi2        UP

001b.d51b.eb56  VC:  1/32                      UP
N/A    0     0000.0000.0000  ATM0/0/0              Di1      N/A        PADISN

0000.0000.0000  VC:  1/32

Nach längerer Suche wird dann auch klar warum das Verhalten so ist. Das ATM-Interface baut jede PPPOE-Session mit der selben MAC-Adresse auf. Da beide Verbindungen aber auf dem selben DSLAM enden kann das nicht klappen. Es muss also eine Lösung her wie man für jede PPPOE-Session eine eigene MAC-Adresse einstellen kann. Das mag nur leider Cisco überhaupt nicht und es ist auch so nicht vorgesehen. Man kann zwar an einem ATM-Interface eine andere MAC-Adresse vergeben, man kann das aber nicht in einer PVC pro Dialer-group machen.

Die einzige Lösung ist sich ein EEM-Script zu basteln das die MAC-Adresse bei Bedarf am ATM-Interface setzt, damit jede PPPOE-Session ihre eigene MAC-Adresse benutzen kann. Falls hier jemand vom Hersteller mit liest, darf das gerne als Feature Wunsch aufgenommen werden (ATM-Interface with random mac-address per pppoe session).

!
event manager applet MAC-DIAL1
event syslog pattern "Line protocol on Interface Virtual-Access3, changed state to up"
action 1.0 cli command "enable"
action 1.1 cli command "conf t"
action 1.2 cli command "interface atm0/0/0"
action 1.3 cli command "mac-address 101b.d51b.eb56"
action 1.4 cli command "end"
action 1.5 cli command "exit"
!
event manager applet MAC-DIAL2
event syslog pattern "Line protocol on Interface Virtual-Access2, changed state to up"
action 1.0 cli command "enable"
action 1.1 cli command "conf t"
action 1.2 cli command "interface atm0/0/0"
action 1.3 cli command "mac-address 201b.d51b.eb56"
action 1.4 cli command "end"
action 1.5 cli command "exit"
event manager applet MAC-DIAL3
!
event syslog pattern "Interface Virtual-Access2, changed state to down"
action 1.0 cli command "enable"
action 1.1 cli command "conf t"
action 1.2 cli command "interface atm0/0/0"
action 1.3 cli command "mac-address 301b.d51b.eb56"
action 1.4 cli command "end"
action 1.5 cli command "exit"
!
event manager applet MAC-DIAL4
event syslog pattern "Interface Virtual-Access3, changed state to down"
action 1.0 cli command "enable"
action 1.1 cli command "conf t"
action 1.2 cli command "interface atm0/0/0"
action 1.3 cli command "mac-address 401b.d51b.eb56"
action 1.4 cli command "end"
action 1.5 cli command "exit"
!

Damit wird nach einem Verbindungsaufbau oder Abbau einer PPPOE-Session sofort die MAC-Adresse geändert und die nächste Verbindung kann aufgebaut werden.

Router#show pppoe session
2 client sessions

Uniq ID  PPPoE  RemMAC          Port                  Source   VA         State
SID  LocMAC                                         VA-st
N/A   1466  0090.1a41.650c  ATM0/0/0              Di2      Vi2        UP

301b.d51b.eb56  VC:  1/32                      UP
N/A   1476  0090.1a41.650c  ATM0/0/0              Di1      Vi3        UP

201b.d51b.eb56  VC:  1/32                      UP

Hier kann man die beiden aufgebauten PPPOE-Sessions sehen, da sie jetzt unterschiedliche MAC-Adressen haben. Für das DSLAM ist das unerheblich, solange die MAC-Adresse nicht von jemand anderem verwendet wird.

Ein kleiner Nachteil ergibt sich daraus noch: Der ATM-Adapter im Router muss jetzt im Promiscuous Modus arbeiten was zu einer etwas höheren Prozessor Last führt, da jedes einzelne Datenpaket vom Adapter gelesen werden muss um zu überprüfen ob das Datenpaket verarbeitet werden soll oder nicht.

Router#show ip interface brief
Interface                  IP-Address      OK? Method Status                Prot
ocol
FastEthernet0/0            192.168.10.1   YES NVRAM  up                    up

FastEthernet0/1            unassigned      YES NVRAM  administratively down down

ATM0/0/0                   unassigned      YES NVRAM  up                    up

NVI0                       192.168.10.1    YES unset  up                    up

Virtual-Access1            unassigned      YES unset  up                    up

Virtual-Access2            unassigned      YES unset  up                    up

Virtual-Access3            unassigned      YES unset  up                    up

Dialer1                    84.135.89.184   YES IPCP   up                    up

Dialer2                    194.231.187.196 YES IPCP   up                    up

Hier haben beide Dialer ihre IP-Adresse zugewiesen bekommen und die Routen werden aufgebaut.

Router#show ip route
[ ... ]
Gateway of last resort is 217.0.116.114 to network 0.0.0.0

84.0.0.0/32 is subnetted, 1 subnets
C       84.135.89.184 is directly connected, Dialer1
C    192.168.10.0/24 is directly connected, FastEthernet0/0
217.0.116.0/32 is subnetted, 1 subnets
C       217.0.116.114 is directly connected, Dialer1
194.231.190.0/32 is subnetted, 1 subnets
C       194.231.190.1 is directly connected, Dialer2
194.231.187.0/32 is subnetted, 1 subnets
C       194.231.187.196 is directly connected, Dialer2
S*   0.0.0.0/0 [1/0] via 217.0.116.114
[1/0] via 194.231.190.1
is directly connected, Dialer2
is directly connected, Dialer1

Was jetzt noch fehlt ist Network Adress Translation (NAT), aber das ist ein anderes Thema was bei mehr als einer Verbindung nicht so ganz trivial ist.