Oktober 2015 - Seite 3 von 3 - fxelectronics.de

Cisco Hash Typ 7 Passwort knacken

Die nach dem Cisco proprietären Typ 7 generierten Hash-Werte auf Cisco Devices kann man zurückrechnen.
Dazu findet man viele Webseiten, die das erledigen.
Bsp.:
http://packetlife.net/toolbox/type7/

Da man nie genau weiß, was mit den eingegebenen Daten geschieht, kann man auch den Algorithmus direkt nutzen.
Hierzu wurde auf insecure.org der Quellcode eines entsprechenden Exploits veröffentlicht:
http://insecure.org/sploits/cisco.passwords.html

Exkurs Dev-Cpp:
Download über sourceforge.net (in diesem die Windows Version):
http://sourceforge.net/projects/orwelldevcpp/

Dann die Software installieren und ein neues Projekt starten (bitte Konsolenanwendung und C auswählen).

Dann kann der Quelltext von insecure.org auch schon reinkopiert werden.

Große Probleme hatte ich mir der bzero-Funktion im Windows Dev-C++.
Ich konnte diese nicht in der string.h finden.

Im Internet habe ich einen Trick gefunden ein Makro für bzero zu definieren:

„Cisco Hash Typ 7 Passwort knacken“ weiterlesen

Check_MK Plugin zum Abfragen des Cleaning Status von Bandlaufwerken in Dell ML6000 u.ä.

Anhand des Tutorials auf der Check_MK-Seite (https://mathias-kettner.de/checkmk_devel_snmpbased.html) habe ich ein kleines Plugin geschrieben, mit dem man den Cleaning Status der Bandlaufwerke in einer Dell ML6000 Bandbibliothek per SNMP abfragen kann.

Das Plugin habe ich im local-Zweig der OMD-Site unter „~/local/share/check_mk/checks“ abgelegt.

Hier der Code:

def inventory_backupdriveclean(info):
inventory = []
for cleaning in info:
inventory.append ( ( None, None ) )
return inventory

def check_backupdriveclean(item, params, info):
cleaning = int(info[0][0])
if cleaning == 2:
return (0, „OK Cleaning not required“ )
else:
return (2, „CRITICAL Cleaning required“ )

check_info[„backupdriveclean“] = (check_backupdriveclean, „backupdriveclean“, 0, inventory_backupdriveclean)

snmp_info[„backupdriveclean“] = ( „.1.3.6.1.4.1.3764.1.10.10.11.3.1.12“, [ „1“ ] )

Check_MK Konfiguration main.mk

Als Betriebssystem für das Monitoring System wird aktuell ein SuSE Linux Enterprise Server 11 eingesetzt. Weiter stützt sich das System dann auf die Open Monitoring Distribution OMD, die auch die Check_MK Installation beinhaltet. Auf der Homepage gibt es auch Installationspakete für weitere Linux-Distributionen:

Open Monitoring Distribution – http://omdistro.org
Check_MK – https://mathias-kettner.de/check_mk.html

Hier zeige ich eine Check_MK Konfigurationsdatei main.mk. Diese stammt aus einem Monitoringsystem, wurde aber um einige Hosts gekürzt. Auch wurden Hostnamen und IP-Adressen durch „fiktive“ Werte ersetzt. Dadurch kann es sein, dass darauffolgende Definitionen mal auf einen nicht existenten Host zeigen. Aber als Beispiel für eigene Konfigurationen kann es genutzt werden.

all_hosts

In diesem Abschnitt werden die zu überwachenden Hosts eingetragen. Damit die Abfrage richtig funktioniert, müssen die angegebenen Hostnamen auflösbar sein.
Auch können an die Hostnamen getrennt durch das Pipe-Zeichen „|“ Tags definiert werden, die in weiteren Definitionen verwendet werden können.

Native Nagios Konfigurationsoptionen beeinflussen

Mit der Variable extra_host_conf können native Nagios Optionen beeinflusst werden und z.B. an per Tag gruppierte Hosts oder gar all_hosts übergeben werden.

Die Timeperiod GoodForSleep habe ich über die Nagios Konfiguration ~/etc/nagios/conf.d/timeperiods.cfg eingerichtet.

extra_host_conf[„notification_interval“] = [ ( „0“, ALL_HOSTS ) ]
extra_host_conf[„notification_period“] = [ ( „GoodForSleep“, ALL_HOSTS ) ]
extra_service_conf[„notification_interval“] = [ ( „0“, ALL_HOSTS, ALL_SERVICES ) ]
extra_service_conf[„contact_groups“] = [ ( „admins“, ALL_HOSTS, ALL_SERVICES ) ]
extra_service_conf[„notification_period“] = [ ( „GoodForSleep“, ALL_HOSTS, ALL_SERVICES ) ]

…

#Auszug der Nagios Konfig timeperiods.cfg
define timeperiod{
timeperiod_name GoodForSleep
alias Only Good For Sleep
sunday 06:00-22:00
monday 06:00-22:00
tuesday 06:00-22:00
wednesday 06:00-22:00
thursday 06:00-22:00
friday 06:00-22:00
saturday 06:00-22:00
}

„Check_MK Konfiguration main.mk“ weiterlesen

Know How zu Barcode Scanner

Hier kommen nur einige kurze Notizen, die aber vielleicht viel Zeit sparen können.

Alphanumerische Barcodes

Im Laborumfeld bin ich mal darauf gestoßen, dass beim Abscannen von Patienten-Etiketten auf den Blutröhren Fehler passierten. Entgegen anderer Kunden, gab es hier die Spezialität, dass alphanumerische Barcodes genutzt wurde und nicht nur numerische. Bei allen aufgezeigten problematischen Barcode fiel auf, dass jeweils ein „Z“ oder ein „Y“ im Barcode vorhanden war. Der Barcode-Scanner war als Keyboard-Barcodescanner am PC angeschlossen. Leider war die Spracheinstellung auf Englisch gestellt, sodass die Buchstaben „Z“ und „Y“ vertauscht wurden. Nach Korrektur der Spracheinstellungen funktionierte das Barcodescannen ordnungsgemäß.

Stromversorgung

Ein weiteres zeitraubendes Problem kann die korrekte Stromversorgung von Barcode-Scannern bzw. aller angeschlossener USB-Peripherie sein. Bei nur sporadischen möglichen Betrieb von Barcode-Scannern sollte die Anschlussposition der USB-Anschlüsse geprüft werden, sodass der Barcode-Scanner an einem der ersten Ports genügend Strom bekommt. Zum Beispiel kann man dann die Maus etwas weiter hinten/unten anschließen. Im Zweifelsfall kann auch auf einen aktiven USB-Hub zurückgegriffen werden, der die konstante Stromversorgung für die USB-Geräte übernimmt.

Performance Probleme durch Hardware Interrupts Windows 2003 in VMware ESX 5.5

Bei einem Server für ein Dienstplanungsprogramm stellte sich vor einigen Tagen ein massives Performance Problem ein. Ich vermute, dass jemand etwas an der virtuellen Hardware durchgeführt hat. Konnte aber keine weiteren Informationen dazu erhalten. Vielleicht gab es ein VMware-Tools Update etc. Leider konnte ich mich aus Zeitgründen nicht weiter damit befassen, da es für mich für nur noch um die Lösung des Problems ging.

Auffällig war, dass die Datenträgerwarteschlange im Perfomance Monitor von Windows sehr hoch war.

Weiter fiel mir auf, dass der Taskmanager permanent 100% CPU Last anzeigte, jedoch die Addition der CPU-Last der laufenden Prozesse max. auf 80% CPU-Last kamen.

Darauf hin habe ich mir die Sache mit dem Process Explorer angesehen.

„Performance Probleme durch Hardware Interrupts Windows 2003 in VMware ESX 5.5“ weiterlesen