Windows Event Log kann nach Archivieren nicht gelöscht werden

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.

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

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.

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.

 

 

Mit einer Cisco ASA 5505 mit Basic Lizenz eine DMZ aufbauen

Die Cisco ASA 5505 Firewall ist ja ein super tolles Gerät mit dem man allerlei Sachen anstellen kann. Leider gibt es für die kleine ASA aber zwei unterschiedliche Lizenzen, einmal die Basic Lizenz und einmal die Security Plus Lizenz. Die Preisdifferenz macht dann zwischen den beiden Lizenzen Modellen ca. 400 € aus, die man eventuell sparen kann.

Mit der Basic Lizenz kann man zwar theoretisch 3 Vlans anlegen, leider ist das dritte Vlan aber kein vollwertiges Vlan. Somit ist es fast unmöglich eine DMZ aufzubauen, da das dritte Vlan nur zu einem der beiden anderen Vlans eine Verbindung aufbauen kann. Wenn man nun doch eine DMZ benötigt, dann muss man sich im Vorfeld darüber Gedanken machen ob Geräte in der DMZ mit dem Inside oder dem Outside Vlan Verbindungen aufbauen müssen. Beides gleichzeitig geht nicht. Hosts die von Inside oder Outside  eine Verbindung zur DMZ aufbauen wollen funktionieren dagegen einwandfrei.

Hier einmal die Konfiguration für das Inside und Outside Vlan:

!
interface Vlan1
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 192.168.2.1 255.255.255.0
!

Und nun das Vlan 3 für die DMZ:

!
interface Vlan3
description DMZ
no forward interface Vlan2
nameif DMZ
security-level 50
ip address 172.16.1.1 255.255.255.0
!

Beim Anlegen der DMZ per ASDM wird ein Fehler gemeldet, da der ASDM erst den nameif DMZ Eintrag erstellt und dann den no forward interface Vlan2 Eintrag. Mit der Basic Lizenz muss die Reihenfolge genau umgedreht sein, so wie im Beispiel. Die ASA setzt hier mit der Lizenz Prüfung an und meldet den Fehler

ciscoasa(config)# int vlan 3
ciscoasa(config-if)#  description DMZ
ciscoasa(config-if)#  nameif DMZ
ERROR: This license does not allow configuring more than 2 interfaces with nameif and without a "no forward" command on this interface or on 1 interface(s) with nameif already configured.
ciscoasa(config-if)#  no forward interface Vlan2
ciscoasa(config-if)#  nameif DMZ
INFO: Security level for "DMZ" set to 0 by default.
ciscoasa(config-if)#  security-level 50
ciscoasa(config-if)#  ip address 172.16.1.1 255.255.255.0

falls die Einträge in der falschen Reihenfolge eingegeben werden.

Entscheidend ist also der Eintrag no forward interface VlanX mit dem ich vorher bestimmen muss zu welchem Interface ich aus der DMZ keine Verbindung aufbauen möchte. Wer einen Web-Server betreiben will, der wählt das Outside Interface zum Sperren aus, da dort die Verbindungen immer vom Kunden aufgebaut werden, also von Außen. Gleichzeitig muss der Web-Server aber Logfiles oder Syslog-Meldungen an das Interne Interface weiter leiteten, um sie dort auf einem sicheren Server zu speichern.