Zeit für Webentwicklung – mit dem eigenen Managed Server

Backlinkseller

Als Webentwickler will man sich voll und ganz auf das coden von PHP-Templates, CMS-Extensions und Scripting mit Javascript konzentrieren. Da hilft es, wenn man jemanden im Hintergrund hat, der einem den Betrieb und die Administration eines eigenen Servers abnimmt. Die Lösung: Managed Server.

server

In der heutigen Zeit haben nur noch große Firmen und Behörden ein eigenes Rechenzentrum. Viele mieten sich in einem solchen ein, um Kosten zu sparen und Infrastrukture as a Service (auch IaaS genannt) zu nutzen. Dabei kümmert sich der Rechenzentrumsbetreiber um die Hardware, die Absicherung der Stromversorgung und sonstiger Schutz des Rechenzentrums vor höherer Gewalt und vorsätzlichem Handeln. Der Rechenzentrumsbetreiber hat dabei aufgrund eines mit dem Kunden geschlossenen Vertrages (sog. Service-Level-Agreement) die festgelegte Verfügbarkeit der physikalischen Maschinen zu gewährleisten.

Da für den Betrieb eines im Internet erreichbaren Servers ein Mindestmaß an Fachwissen über die professionelle Verwaltung benötigt wird und die Wartung des Betriebssystems und der eingesetzten Verwaltungssoftware (z.B. Verwaltung der Kundenaccounts) viel Zeit benötigt, kann dies nicht von jedermann erfüllt werden. Dies ist jedoch kein Problem, denn die Administration kann ganz leicht mit dem Server zusätzlich vom Betreiber des Rechenzentrums eingekauft werden. Dies nennt sich dann Plattform as a Service (auch PaaS). Sie als Webentwickler, der für verschiedene Nutzer Projekte erstellt, können sich in diesem Modell voll auf Ihre Haupttätigkeit konzentrieren.

In Zeiten von Bedrohungen durch Hackern ist es immer schwieriger die Systeme korrekt nach außen abzusichern und zu härten. Jeder der einen Server betreibt, ist jedoch für den sicheren Betrieb verantwortlich und gerät in Gefahr, wenn seine Maschine gehackt und für kriminelle Machenschaften genutzt werden. Der Betreiber ist dafür haftbar und muss daher sicherstellen, dass die Systeme immer auf dem neuesten Sicherheitsstand sind (autom. Einspielung von Sicherheitsupdates).

Bei einem Managed Server garantiert der Provider, dass jederzeit die Betriebssicherheit und Datensicherheit (Stichwort: RAID 1) gewährleistet ist. Er hält die Systeme aktuell und sichert sie mit Firewalls gegen Angreifer ab. Dies läuft dezent im Hintergrund, sodass man immer ein sicheres Gefühlt hat. Dies wird verstärkt, wenn man weiß, dass der Provider eigenes hoch qualifiziertes und professionell arbeitendes Personal hat. So hat man immer einen schnellen und sehr guten Service und hängt nicht in der Warteschleife eines Callcenters mit Mitarbeitern ohne technischen Hintergrund. Am Besten hilft hierbei mit bestehenden Kunden des Anbieters zu sprechen und deren Erfahrungen nutzen.

Ein Provider eines Managed Servers garantiert üblicherweise einen 7 x 24 Stunden Support an 365 Tagen im Jahr. Dies ist ein weiteres wichtiges Kriterium bei der Auswahl.

Hosting bei Mittwald ermöglicht es z.B. mit ihrer „Agentur Toolbox“ für die eigenen Kunden in kürzester Zeit Webprojekte zu erstellen, die bereits erfolgreich bei anderen laufen. Mit Vorlagen können ganz schnell komplexe Projekte geklont werden. Mit anderen Tools können Sie Ihren Kunden ein Kundencenter mit Ihrem Corporate Design anbieten. So sind Lösungen aus einem Guss von der Idee über die Konzeption und Implementierungen bis zum Betrieb möglich. Auch diese Tools sollten bei der Auswahl berücksichtigt werden, da sie einem die täglichen Arbeitsprozesse sehr vereinfachen und einem manche schlechte Erfahrung sparen (Wiederherstellungsmanager).

Zum Blog milsystems

wichtige Kriterien bei Auswahl BPMN-Werkzeug

Backlinkseller

In diesem Artikel gebe ich einen Überblick über die Kategorien von BPMN-Modellierungstools und verrate nützliche Tipps bei der Toolauswahl. Mit diesem systematisches und klares Vorgehen gelingt der Weg zur geeigneten Businesslösung.

Arten von Tools

Bei BPM-Tools wird zwischen BPMA- und BPMS-Tools unterschieden. BPMA steht für Business Process Modeling and Analysis. Es geht dabei darum die Prozesse im Unternehmen zu dokumentieren, auf Schwachstellen zu untersuchen (z.B. Flaschenhälse mittels Simulation) und Prozessverbesserungen zu entwerfen. BPMS bedeutet Business-Process-Management-System und meint die Unterstützung der Geschäftsprozesse mittels IT. Hierbei kommt eine sog. Prozessengine zum Einsatz, welche wie ein Dirigent die Prozesse steuert und auch Webservices aufrufen kann, was zu einer serviceorientierten Architektur (SOA) führt. Im Zuge der Weiterentwicklung der Lösungen und der einzelnen Hersteller, werden BPMA und BPMS in einer Suite integriert, um den gesamten Lifecyle bei BPMN abdecken zu können.

BPMN 2.0 verringert die Lücke

Der Vorteil von BPMN gegenüber anderer Prozessnotation ist, dass diese in der Version 2.0 sowohl von einem Menschen visuell erfasst als auch von einer Maschine über die dahinter liegende XML-Struktur eingelesen werden kann. Damit wird der Gap zwischen Business (Process-Analyst) und IT (Process Engineer) sehr stark reduziert, wobei immer noch eine Lücke bleibt, die zwischen Businessprozessmodellen und Ausführungsprozessmodellen (execution layer) liegt. Auch ein Techniker kann bei zweiterem mit der grafischen Notation die technische Ausführbarkeit auf einer Prozessengine erreichen und es muss nicht so viel Quellcode geschrieben werden. Auf einen Entwickler wird man jedoch nie ganz verzichten können, da dieser u.a. auch die Webservices entwickeln und an das technische Prozessmodell anbinden muss. Der zuvor für die Ausführung von BPMN genutzte BPEL-Standard (Busines Process Execution Language) gehört damit schon heute der Vergangenheit an, da er überflüssig und schwer zu lesen ist.

Kriterien bei der Auswahl eines Tools

Bei der Vielzahl der heutigen Anbieter für BPM-Lösungen fällt es schwer, die richtige BPM-Lösung zu finden. Folgende Punkte sollten bei einer gründlichen Evaluierung berücksichtig werden.

Standards bevorzugen, um vom Anbieter unabhängig zu sein

Man möchte meinen, dass heute der BPMN 2.0 Standard bei allen Anbietern zu 100% umgesetzt ist. Dies ist nach meinen praktischen Erfahrungen leider nicht der Fall. Gerade bei der Ausführung von Prozessmodellen auf einer Prozessengine sind Restriktionen (= Empfehlungen) der Anbieter zu beachten. Insbesondere wenn es um das Tuning zur Steigerung der Performance geht, merkt man, welche geheimen Features bei den Herstellern eingebaut sind, die ohne Garantie benutzt werden können. Dabei kann jedoch alles auch viel schlechter werden (also immer gut testen!). Hier hilft nur eine intensive Evaluation von realen Prozessmodellen im Unternehmen von der fachlichen Modellierung bis hin zur Ausführung, um zu ermitteln, ob die Modellierungspattern im Tool/ der Engine anwendbar sind.

Es gibt keine Software auf Knopfdruck!

Leider gab es in den Anfängen von prozessorientierter Software Anbieter, die ihren potentiellen Kunden dieses Wunder versuchten zu verkaufen. Dem ist mitnichten so, was dazu geführt hat, dass der anfängliche gute Ruf von Realisierung mittels BPM/SOA im Management in Mitleidenschaft gezogen wurde! Das Wunder ist fast nur unter speziellen Voraussetzungen und mit einem hohen Preis möglich. Der Preis ist, dass man sich in die Abhängigkeit von proprietären Lösungen der Toolhersteller begibt, aus denen man nicht mehr herauskommt und das IT-Projekt zu einer Kostenfalle werden lässt (zumindest langfristig!). Die speziellen Voraussetzungen sind, dass man einfache Prozesse (z.B. der Urlaubsantragsprozess) automatisieren möchte. Das ist jedoch ehr die Ausnahme in komplexen Unternehmen.

Es ist herauszustellen: Mit BPM/SOA kann die Fachseite nicht auf erfahrene Entwickler verzichten. Der Sinn dieser Technik war vielmehr, durch Standards (alle verstehen das gleiche) das Alignment zwischen Business und IT herzustellen, sodass die Fachseite die IT nicht als Belastung sondern als Unterstützung wahrnimmt.

mehrere Softwarestacks selbst über einen längeren Zeitraum testen

Probieren geht bekanntlich über studieren. So ist es natürlich auch bei der Auswahl von BPMA- und BPMS-Tools. Man wählt einen unkritischen Prozess im Unternehmen, an dem möglichst viele Kriterien der Tools, die für die spätere Entscheidung wichtig sind, evaluiert werden können. Bei BPMN/SOA handelt es sich langfristig gesehen um kritische Bereiche eines Unternehmen, da Prozesse mehr und mehr automatisiert werden und damit das Unternehmen durchdringen. Es empfiehlt sich daher neben einer Realisierung unter Anwendung von allgemeingültigen Standards auch das Wissen dazu in der eigenen IT-Abteilung aufzubauen. Ein Ziel von BPM/SOA ist ja, dass ein Prozess agil über grafische Tools um modelliert werden kann. Dies sollte just in time von der eigenen Entwicklungsabteilung leistbar sein. Weiterhin sind die eigenen Angestellten eine unabhängige Informationsquelle bzgl. der Eignung eines Produkts (Leistungsfähigkeit, Benutzerfreundlichkeit, etc.), da diese praktische Erfahrungen sammeln konnten und sich kaum eine Software ins Haus holen werden, die unpraktikabel in der Anwendung ist (gut ausgebildetes IT-Personal ist bekanntlich Mangelware und muss teuer eingekauft werden).

Know-How aufbauen und Mitarbeiter sensibilisieren

Es bringt nichts, wenn man sich als Unternehmen einen ESB und eine teure BPM-Suite anschafft und keiner da ist, der die Funktionalitäten vollständig nutzen kann. Von der Prozesserfassung bis zur Auführung muss im Unternehmen eine Transformation zum Denken in der Prozesswelt geschafft werden. Der Erfolg dieser Systeme wird auf den Menschen aufgebaut, die im Entwicklungsprozess beteiligt sind. So werden bereich in der fachlichen Modellierung gute Ergebnisse erzielt, die mit weniger Aufwand für die Automatisierung angereichert werden müssen.

Einsatzzweck festlegen

Für was nutzen Sie die Software im Unternehmen. Gerade in kleinen Unternehmen muss ressourcenbewusst gewirtschaftet werden. Daher muss man sich genau überlegen, wo man langfristig mit dieser Software hin möchte. Will man diese schrittweise im gesamten Unternehmen etablieren, lohnt sich oft schon Open-Source-Lösungen, bei denen die anfänglichen Investitionen für die Schulung der Realisierer höher sind, jedoch geringere Lizenzkosten zu erwarten sind. Hier hilft nur mit den Beteiligten sprechen, Anforderungen sammeln und diese für eine Entscheidung priorisieren. So werden alle ins Boot geholt.

 

Viel Erfolg dabei!

Zum Blog milsystems

Ablage von Testdaten unter Einbeziehung von ISTQB


In diesem Artikel stelle ich skizzenhaft den Aufbau eines KM-Repositories für den Softwaretest vor. Dieses ist allgemein gültig und kann daher in vielen Testprojekten verwendet werden.

1. pruefspezifikationen

hier werden alle Prüfspezifikationen abgelegt

2. drehbuch

hier wird das Drehbuch abgelegt

3. testdaten

hier werden alle Testdaten abgelegt

4. testdokumentation

4.1. pruefplan

hier wird prueffall_management_XX.xls abgelegt

4.2. screenshots

hier werden alle WORD-Dokumente mit den Screenshots abgelegt

4.3. erfasste_tickets

hier wird die EXCEL-Datei mit den erfassten Tickets abgelegt

4.4. fachliche_fragen

hier wird der Katalog mit den fachlichen Fragen für die Fachkonzepterstellung eingestellt

5. abschlussbericht

hier wird der Abschlussbericht abgelegt

 

 

Zum Blog milsystems

Die Zukunft von Truecrypt …

Backlinkseller

Wie man bereits auf heise.de nachlesen konnte, hat es beim Open-Source-Projekt Truecrypt, welches ich für die Verschlüsselung von Dateicontainern verwende, ernste Veränderungen gegeben. In diesem Artikel schreibe ich, meinen Umgang damit.

Entwickler empfehlen Umstieg auf Bitlocker

Wenn man aktuell die Domain truecrypt.com ansurft, landet man auf truecrypt.sourceforge.net. Dort kann man lesen, dass die Entwickler den Umstieg auf BitLocker von Microsoft empfehlen. Es wird sogar eine Anleitung zum Umstieg gegeben. Die aktuelle Version von Truecrypt, TrueCrypt 7.2, eignet sich nur noch zum Entschlüsseln von Containern bzw. Festplatten, die mit einer älternen Version von Truecrypt verschlüsselt wurden. Laut heise.de haben die Entwickler kein Interesse mehr an der Weiterentwicklung. Einem Fork, der aktuell von der Open-Source-Community verfolgt wird, stehen die Entwickler kritisch gegenüber, da nur sie den Code genau kennen würden.

Ich bin jedoch eher der Meinung, dass die Entwickler von der NSA aufgespürt wurden (für sie ist ja Privatsphäre sehr wichtig) und diese einen national security letter (NSL) unterschreiben mussten. Diese Theorie unterstützt auch Fefe:

WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues

Dieser Satz steht ganz oben auf der neuen Seite von Truecrypt truecrypt.sourceforge.net. Ob dies wahr ist oder nicht, wird man sicher noch sehen. Es ist auf jeden Fall klar, das Truecrypt der NSA schon lange ein Dorn im Auge war.

Ergebnis der Quellcodeüberprüfung

Das von unabhängiger Stello durchgeführte Code-Review hat Keine Backdoor, jedoch laxe Programmierstandards zu Tage gefördert. Lediglich ein paar Bugs sind laut heise.de gefunden worden. Die Nutzung der letzten vollwertigen Version von Truecrypt ist daher meiner Ansicht unbedenklich nutzbar.

Wie geht es weiter?

Wie schon Herr Schmidt von heise.de empfiehlt: abwarten und Tee trinken…

Bis durch das Codereview keine gravierenden Sicherheitslücken aufgedeckt wurden, werde ich die letzte gültige Version von Truecrypt nutzen. Diese kann man von

herunterladen. Die Version 7.2 würde ich aufgrund des Postings von Fefe nicht installieren. Auch einem Umstieg auf Bitlocker stehe ich kritisch gegenüber, da Microsoft leider auch als amerikanisches Unternehmen mit der NSA “zusammenarbeit”.

Zum Blog milsystems

WLAN-Passwort FIFA-WM Brasilien in Zeitung

Backlinkseller

Die Zeichen stehen auf Fußball. Doch auch bei aller Freude die WM im eigenen Land zu haben, sollte das WM-Sicherheitszentrum ein bisschen sensibler mit ihren Sicherheitsmaßnahmen sein und nicht das WLAN-Passwort in der Zeitung ablichten lassen.

Das Sicherheitszentrum der FIFA-WM in Brasilien hat sein WLAN-Passwort auf einem Großbildschirm im Kontrollzentrum für einen Zeitungsartikel ablichten lassen.

 

FIFA WM Passwort leaked

Die Mitarbeiter hatten das Passwort und die SSID des internen WLAN-Netzes groß und breit auf den Bildschirmen in ihrem Büro angezeigt. Ein Witz bei dem, was die Vertreter des BSI bei ihren Sicherheitsinitiativen versuchen zu vermitteln: “bloß keine Passwörter am Bildschirm mit PostIts befestigen”.

Wäre das nicht schon leichtsinnig genug, ließ sich der Chef für internationale Polizeikooperation Luiz Cravo Dorea in genau jenem Büro von der brasilianischen Zeitung Correio Braziliense ablichten. Zusammen mit dem Passwort, was hoffentlich bereits geändert ist (ich kann es aufgrund der Entfernung leider nicht testen).

Das Passwort, b5a2112014, für Brazil 2014 ist zusätzlich noch leicht zu erraten. Alles in allem also ein Beispiel für alle Admins, wie man es nicht machen sollte.

Zum Blog milsystems

OpenSSL – Bug oder Backdoor?

Beim OpenSSL-Projekt geht es derzeit in den Medien und Foren hoch her. War es ein Backdoor für die Geheimdienste oder doch nur ein blöder Bug. In diesem Artikel stelle ich die einzelnen Positionen in den Medien zusammen.

aktuelle Situation

Nachdem die am 8. April 2014 bekannt gewordene schwere Sicherheitslücke des OpenSSL-Projekts (genannt Heartbleed-Bug) behoben wurde, geht die durch die Linux Foundation finanzierte Analyse von OpenSSL weiter. Es wurden am 5. Juni 2014 7 weitere Sicherheitslücken behoben. Eine davon errecht wiederum Aufmerksamkeit: Die Lücke im DTLS-Code stammt vom gleichen Entwickler, der auch die Heartbleed-Lücke programmiert hat.

Es stellt sich daher zusehends die Frage, hat der Entwickler R. S. einfach einen Fehler begangen oder fand hier eine bewusste Implementierung eines Backdoors für Organisationen (wie NSA, BND, GCHQ und Co) mit dem technischen Wissen, wie diese ausgenutzt werden kann, statt. Im Netz findet dabei eine regelrechte Hexenjagd auf den Entwickler statt.

Hier habe ich einmal die Meinungen zusammengetragen, die für die zwei Varianten Bug oder Backdoor sprechen.

Positionen für Bug

Die ZDI (Zero Day Initiative von HP) sagt, dass der Entwickler R. S. nicht Schuld daran ist, sondern das das Konzept von Open-Source an dieser kritischen Softwarekomponente versagt hat. Die Code-Änderung wurde einfach durch gewunken, da sie in einem Bereich war, der für unkritisch empfunden wurde. Das Konzept der vielen Augen hat hier nicht gegriffen und es wird jetzt jeder Code, den der besagte Entwickler dem Projekt beigesteuert hat, genaue geprüft um weitere Fehler schnell zu entdecken (“Blut ist im Wasser”).

Der eigentliche Entwickler hat dazu auch bereits ggü. der Presse bekannt gegeben, dass der Fehler aus seiner Sicht nur ein Versehen war. Auch dem Reviewer fiel es nicht auf. Er appeliert daran, dass mehr Leute zu Open-Source-Projekten beitragen, gerade wenn sie so wichtig sind wie OpenSSL.

It was not intended at all, especially since I have previously fixed OpenSSL bugs myself, and was trying to contribute to the project.

Weiter sagt er:

Der Fehler ist ein simpler Programmierfehler gewesen, der im Rahmen eines Forschungsprojektes entstanden ist. T-Systems und BND oder andere Geheimdienste waren zu keiner Zeit beteiligt und zu meiner späteren Anstellung bei T-Systems bestand zu keiner Zeit ein Zusammenhang. Dass T-Systems im RFC genannt wird, liegt an der verspäteten Fertigstellung des RFCs und es ist üblich, den bei der Fertigstellung aktuellen Arbeitgeber anzugeben.

Das OpenSSL-Projekt wird von ihm umsonst gepflegt, obwohl es bereits für 80 Plattformen genutzt wird. OpenSSL wird derzeit von 13 Personen betreut.

Laut Fefe gibt es für einen derartigen Fehler bei einer derartig sicherheitskritischen Komponente, die er mit der Kritikalität eines Flugzeugs oder einem Atomkraftwerks vergleicht, keine Entschuldigung. Der Entwicklungsprozess muss grundlegend verändert werden, da jeder Bug bei einer solchen Software gleich gefixt werden muss unabhängig von der Risikostufe. Qualitätsstandards bei Open-Source sind schwierig durchzusetzen, da man einen Entwickler nicht mit Entlassung drohen kann.

Positionen für Backdoor

Für Alexander Benesch von recentr.com fällt das Urteil etwas anders aus:

Es ist nicht einfach nur so, dass Geheimdienste und Militärs die Infrastruktur des Internets im Laufe der Zeit infiltriert haben. Stattdessen schuf der militärisch-industrielle Komplex das Internet und gab es vordergründig an obskure Programmierer weiter. Dies war aber lediglich ein Weg, um die Spuren zu verwischen.

Demnach ist das Internet vom Militär deswegen an die Zivilbevölkerung weitergegeben worden, um ein wirksames Überwachungsinstrument zu haben. Er bringt auch Ben Laurie, der bei Google arbeitet, mit dem MI6 in Beziehung. Dieser hätte auch bei Apache Software Foundation seine Finger drin, in dem supersicheren Hosting-Anbieter “The Bunker”, bei FreeBMD und FreeBSD und er gehört zum Computerlabor der Cambridge-University.

Fefe meint wiederum, dass Dr. Stephen Henson, der den Code von R. S. gereviewt hat, nur 100 Meilen von Cheltenham (GCHQ-Sitz) entfernt wohnt. Weiterhin führt er aus:

Eine Sache noch. Nehmen wir mal an, jemand würde mich bezahlen, eine Backdoor in OpenSSL einzubauen. Eine, die auf den ersten Blick harmlos aussieht, die aber ohne Exploit-Schwierigkeiten auf allen Plattformen tut und von den verschiedenen Mitigations nicht betroffen ist. Genau so würde die aussehen.

Meine Meinung

Für mich ist das alles ein blöder Zufall, d.h. der Entwickler R. S. hat hier meiner Meinung ohne Vorsatz gehandelt und wollte keine Backdoor implementieren. Die Geheimdienste haben diesen Bärendienst gerne angenommen und die Lücke aktiv genutzt. Die Gefahr der Entdeckung und die Rufschädigung für den Entwickler, die bereits jetzt um sich greift, ist hier viel zu groß.

Wäre es eine andere Person ohne derartigen Hintergrund (keine Doppelidentität, Dissertation über das Thema, nachvollziehbarer Lebenslauf), würde ich Fefe zustimmen: von der Art ist es eine Backdoor (schmeckt danach). Wäre es ein Mitglied des Geheimdienstes, könnte der sich nach Einbringung der Sicherheitslücke (der Bug kam bereits vor 2 Jahren in die Software) schnell eine andere Identität beschaffen und wäre damit unauffindbar. Man könnte in einem solchen Fall keine Hexenjagd mehr in Gang setzen, da kein Opfer mehr zu finden ist.

Test auf Heartbleed-Lücke

Um seinen Webserver gegen die Lücke zu testen, empfiehlt heise.de folgende Webapps:

Zweiteres hat bei mir auf Anhieb schnelle Resultate gebracht.

Wie geht es weiter?

Die Linux Foundation hat ein Projekt namens Core Infrastructure Initiative vorgestellt, das derartige super GAUs in den kritischen Softwarekomponenten für das Internet zukünftig verhindern soll. Mit jährlich 1,2 Millionen Dollar sollen Entwickler und Kryptografie-Experten sich mit dem quelloffenen Code befassen und ihn sicherer machen. Diese finanzielle Unterstützung soll den Reviewprozess erheblich beschleunigen.

Ich bin daher zuversichtlich, dass durch die Entdeckung dieser Sicherheitslücke die großen kommerziellen Profiteure des Internets erkennen, dass ähnlich wie bei der Raspberry Pi Foundation immer ein Rückfluss der Gewinne in derartige Projekte erfolgen muss. Man sägt sonst am Ast auf dem man sitzt und das tut bekanntlich schnell weh!

Zum Blog milsystems

OpenSSL – Bug oder Backdoor?

Beim OpenSSL-Projekt geht es derzeit in den Medien und Foren hoch her. War es ein Backdoor für die Geheimdienste oder doch nur ein blöder Bug. In diesem Artikel stelle ich die einzelnen Positionen in den Medien zusammen.

aktuelle Situation

Nachdem die am 8. April 2014 bekannt gewordene schwere Sicherheitslücke des OpenSSL-Projekts (genannt Heartbleed-Bug) behoben wurde, geht die durch die Linux Foundation finanzierte Analyse von OpenSSL weiter. Es wurden am 5. Juni 2014 7 weitere Sicherheitslücken behoben. Eine davon errecht wiederum Aufmerksamkeit: Die Lücke im DTLS-Code stammt vom gleichen Entwickler, der auch die Heartbleed-Lücke programmiert hat.

Es stellt sich daher zusehends die Frage, hat der Entwickler R. S. einfach einen Fehler begangen oder fand hier eine bewusste Implementierung eines Backdoors für Organisationen (wie NSA, BND, GCHQ und Co) mit dem technischen Wissen, wie diese ausgenutzt werden kann, statt. Im Netz findet dabei eine regelrechte Hexenjagd auf den Entwickler statt.

Hier habe ich einmal die Meinungen zusammengetragen, die für die zwei Varianten Bug oder Backdoor sprechen.

Positionen für Bug

Die ZDI (Zero Day Initiative von HP) sagt, dass der Entwickler R. S. nicht Schuld daran ist, sondern das das Konzept von Open-Source an dieser kritischen Softwarekomponente versagt hat. Die Code-Änderung wurde einfach durch gewunken, da sie in einem Bereich war, der für unkritisch empfunden wurde. Das Konzept der vielen Augen hat hier nicht gegriffen und es wird jetzt jeder Code, den der besagte Entwickler dem Projekt beigesteuert hat, genaue geprüft um weitere Fehler schnell zu entdecken (“Blut ist im Wasser”).

Der eigentliche Entwickler hat dazu auch bereits ggü. der Presse bekannt gegeben, dass der Fehler aus seiner Sicht nur ein Versehen war. Auch dem Reviewer fiel es nicht auf. Er appeliert daran, dass mehr Leute zu Open-Source-Projekten beitragen, gerade wenn sie so wichtig sind wie OpenSSL.

It was not intended at all, especially since I have previously fixed OpenSSL bugs myself, and was trying to contribute to the project.

Weiter sagt er:

Der Fehler ist ein simpler Programmierfehler gewesen, der im Rahmen eines Forschungsprojektes entstanden ist. T-Systems und BND oder andere Geheimdienste waren zu keiner Zeit beteiligt und zu meiner späteren Anstellung bei T-Systems bestand zu keiner Zeit ein Zusammenhang. Dass T-Systems im RFC genannt wird, liegt an der verspäteten Fertigstellung des RFCs und es ist üblich, den bei der Fertigstellung aktuellen Arbeitgeber anzugeben.

Das OpenSSL-Projekt wird von ihm umsonst gepflegt, obwohl es bereits für 80 Plattformen genutzt wird. OpenSSL wird derzeit von 13 Personen betreut.

Laut Fefe gibt es für einen derartigen Fehler bei einer derartig sicherheitskritischen Komponente, die er mit der Kritikalität eines Flugzeugs oder einem Atomkraftwerks vergleicht, keine Entschuldigung. Der Entwicklungsprozess muss grundlegend verändert werden, da jeder Bug bei einer solchen Software gleich gefixt werden muss unabhängig von der Risikostufe. Qualitätsstandards bei Open-Source sind schwierig durchzusetzen, da man einen Entwickler nicht mit Entlassung drohen kann.

Positionen für Backdoor

Für Alexander Benesch von recentr.com fällt das Urteil etwas anders aus:

Es ist nicht einfach nur so, dass Geheimdienste und Militärs die Infrastruktur des Internets im Laufe der Zeit infiltriert haben. Stattdessen schuf der militärisch-industrielle Komplex das Internet und gab es vordergründig an obskure Programmierer weiter. Dies war aber lediglich ein Weg, um die Spuren zu verwischen.

Demnach ist das Internet vom Militär deswegen an die Zivilbevölkerung weitergegeben worden, um ein wirksames Überwachungsinstrument zu haben. Er bringt auch Ben Laurie, der bei Google arbeitet, mit dem MI6 in Beziehung. Dieser hätte auch bei Apache Software Foundation seine Finger drin, in dem supersicheren Hosting-Anbieter “The Bunker”, bei FreeBMD und FreeBSD und er gehört zum Computerlabor der Cambridge-University.

Fefe meint wiederum, dass Dr. Stephen Henson, der den Code von R. S. gereviewt hat, nur 100 Meilen von Cheltenham (GCHQ-Sitz) entfernt wohnt. Weiterhin führt er aus:

Eine Sache noch. Nehmen wir mal an, jemand würde mich bezahlen, eine Backdoor in OpenSSL einzubauen. Eine, die auf den ersten Blick harmlos aussieht, die aber ohne Exploit-Schwierigkeiten auf allen Plattformen tut und von den verschiedenen Mitigations nicht betroffen ist. Genau so würde die aussehen.

Meine Meinung

Für mich ist das alles ein blöder Zufall, d.h. der Entwickler R. S. hat hier meiner Meinung ohne Vorsatz gehandelt und wollte keine Backdoor implementieren. Die Geheimdienste haben diesen Bärendienst gerne angenommen und die Lücke aktiv genutzt. Die Gefahr der Entdeckung und die Rufschädigung für den Entwickler, die bereits jetzt um sich greift, ist hier viel zu groß.

Wäre es eine andere Person ohne derartigen Hintergrund (keine Doppelidentität, Dissertation über das Thema, nachvollziehbarer Lebenslauf), würde ich Fefe zustimmen: von der Art ist es eine Backdoor (schmeckt danach). Wäre es ein Mitglied des Geheimdienstes, könnte der sich nach Einbringung der Sicherheitslücke (der Bug kam bereits vor 2 Jahren in die Software) schnell eine andere Identität beschaffen und wäre damit unauffindbar. Man könnte in einem solchen Fall keine Hexenjagd mehr in Gang setzen, da kein Opfer mehr zu finden ist.

Test auf Heartbleed-Lücke

Um seinen Webserver gegen die Lücke zu testen, empfiehlt heise.de folgende Webapps:

Zweiteres hat bei mir auf Anhieb schnelle Resultate gebracht.

Wie geht es weiter?

Die Linux Foundation hat ein Projekt namens Core Infrastructure Initiative vorgestellt, das derartige super GAUs in den kritischen Softwarekomponenten für das Internet zukünftig verhindern soll. Mit jährlich 1,2 Millionen Dollar sollen Entwickler und Kryptografie-Experten sich mit dem quelloffenen Code befassen und ihn sicherer machen. Diese finanzielle Unterstützung soll den Reviewprozess erheblich beschleunigen.

Ich bin daher zuversichtlich, dass durch die Entdeckung dieser Sicherheitslücke die großen kommerziellen Profiteure des Internets erkennen, dass ähnlich wie bei der Raspberry Pi Foundation immer ein Rückfluss der Gewinne in derartige Projekte erfolgen muss. Man sägt sonst am Ast auf dem man sitzt und das tut bekanntlich schnell weh!

Zum Blog milsystems

OpenSSL – Bug oder Backdoor?

Beim OpenSSL-Projekt geht es derzeit in den Medien und Foren hoch her. War es ein Backdoor für die Geheimdienste oder doch nur ein blöder Bug. In diesem Artikel stelle ich die einzelnen Positionen in den Medien zusammen.

aktuelle Situation

Nachdem die am 8. April 2014 bekannt gewordene schwere Sicherheitslücke des OpenSSL-Projekts (genannt Heartbleed-Bug) behoben wurde, geht die durch die Linux Foundation finanzierte Analyse von OpenSSL weiter. Es wurden am 5. Juni 2014 7 weitere Sicherheitslücken behoben. Eine davon errecht wiederum Aufmerksamkeit: Die Lücke im DTLS-Code stammt vom gleichen Entwickler, der auch die Heartbleed-Lücke programmiert hat.

Es stellt sich daher zusehends die Frage, hat der Entwickler R. S. einfach einen Fehler begangen oder fand hier eine bewusste Implementierung eines Backdoors für Organisationen (wie NSA, BND, GCHQ und Co) mit dem technischen Wissen, wie diese ausgenutzt werden kann, statt. Im Netz findet dabei eine regelrechte Hexenjagd auf den Entwickler statt.

Hier habe ich einmal die Meinungen zusammengetragen, die für die zwei Varianten Bug oder Backdoor sprechen.

Positionen für Bug

Die ZDI (Zero Day Initiative von HP) sagt, dass der Entwickler R. S. nicht Schuld daran ist, sondern das das Konzept von Open-Source an dieser kritischen Softwarekomponente versagt hat. Die Code-Änderung wurde einfach durch gewunken, da sie in einem Bereich war, der für unkritisch empfunden wurde. Das Konzept der vielen Augen hat hier nicht gegriffen und es wird jetzt jeder Code, den der besagte Entwickler dem Projekt beigesteuert hat, genaue geprüft um weitere Fehler schnell zu entdecken (“Blut ist im Wasser”).

Der eigentliche Entwickler hat dazu auch bereits ggü. der Presse bekannt gegeben, dass der Fehler aus seiner Sicht nur ein Versehen war. Auch dem Reviewer fiel es nicht auf. Er appeliert daran, dass mehr Leute zu Open-Source-Projekten beitragen, gerade wenn sie so wichtig sind wie OpenSSL.

It was not intended at all, especially since I have previously fixed OpenSSL bugs myself, and was trying to contribute to the project.

Weiter sagt er:

Der Fehler ist ein simpler Programmierfehler gewesen, der im Rahmen eines Forschungsprojektes entstanden ist. T-Systems und BND oder andere Geheimdienste waren zu keiner Zeit beteiligt und zu meiner späteren Anstellung bei T-Systems bestand zu keiner Zeit ein Zusammenhang. Dass T-Systems im RFC genannt wird, liegt an der verspäteten Fertigstellung des RFCs und es ist üblich, den bei der Fertigstellung aktuellen Arbeitgeber anzugeben.

Das OpenSSL-Projekt wird von ihm umsonst gepflegt, obwohl es bereits für 80 Plattformen genutzt wird. OpenSSL wird derzeit von 13 Personen betreut.

Laut Fefe gibt es für einen derartigen Fehler bei einer derartig sicherheitskritischen Komponente, die er mit der Kritikalität eines Flugzeugs oder einem Atomkraftwerks vergleicht, keine Entschuldigung. Der Entwicklungsprozess muss grundlegend verändert werden, da jeder Bug bei einer solchen Software gleich gefixt werden muss unabhängig von der Risikostufe. Qualitätsstandards bei Open-Source sind schwierig durchzusetzen, da man einen Entwickler nicht mit Entlassung drohen kann.

Positionen für Backdoor

Für Alexander Benesch von recentr.com fällt das Urteil etwas anders aus:

Es ist nicht einfach nur so, dass Geheimdienste und Militärs die Infrastruktur des Internets im Laufe der Zeit infiltriert haben. Stattdessen schuf der militärisch-industrielle Komplex das Internet und gab es vordergründig an obskure Programmierer weiter. Dies war aber lediglich ein Weg, um die Spuren zu verwischen.

Demnach ist das Internet vom Militär deswegen an die Zivilbevölkerung weitergegeben worden, um ein wirksames Überwachungsinstrument zu haben. Er bringt auch Ben Laurie, der bei Google arbeitet, mit dem MI6 in Beziehung. Dieser hätte auch bei Apache Software Foundation seine Finger drin, in dem supersicheren Hosting-Anbieter “The Bunker”, bei FreeBMD und FreeBSD und er gehört zum Computerlabor der Cambridge-University.

Fefe meint wiederum, dass Dr. Stephen Henson, der den Code von R. S. gereviewt hat, nur 100 Meilen von Cheltenham (GCHQ-Sitz) entfernt wohnt. Weiterhin führt er aus:

Eine Sache noch. Nehmen wir mal an, jemand würde mich bezahlen, eine Backdoor in OpenSSL einzubauen. Eine, die auf den ersten Blick harmlos aussieht, die aber ohne Exploit-Schwierigkeiten auf allen Plattformen tut und von den verschiedenen Mitigations nicht betroffen ist. Genau so würde die aussehen.

Meine Meinung

Für mich ist das alles ein blöder Zufall, d.h. der Entwickler R. S. hat hier meiner Meinung ohne Vorsatz gehandelt und wollte keine Backdoor implementieren. Die Geheimdienste haben diesen Bärendienst gerne angenommen und die Lücke aktiv genutzt. Die Gefahr der Entdeckung und die Rufschädigung für den Entwickler, die bereits jetzt um sich greift, ist hier viel zu groß.

Wäre es eine andere Person ohne derartigen Hintergrund (keine Doppelidentität, Dissertation über das Thema, nachvollziehbarer Lebenslauf), würde ich Fefe zustimmen: von der Art ist es eine Backdoor (schmeckt danach). Wäre es ein Mitglied des Geheimdienstes, könnte der sich nach Einbringung der Sicherheitslücke (der Bug kam bereits vor 2 Jahren in die Software) schnell eine andere Identität beschaffen und wäre damit unauffindbar. Man könnte in einem solchen Fall keine Hexenjagd mehr in Gang setzen, da kein Opfer mehr zu finden ist.

Test auf Heartbleed-Lücke

Um seinen Webserver gegen die Lücke zu testen, empfiehlt heise.de folgende Webapps:

Zweiteres hat bei mir auf Anhieb schnelle Resultate gebracht.

Wie geht es weiter?

Die Linux Foundation hat ein Projekt namens Core Infrastructure Initiative vorgestellt, das derartige super GAUs in den kritischen Softwarekomponenten für das Internet zukünftig verhindern soll. Mit jährlich 1,2 Millionen Dollar sollen Entwickler und Kryptografie-Experten sich mit dem quelloffenen Code befassen und ihn sicherer machen. Diese finanzielle Unterstützung soll den Reviewprozess erheblich beschleunigen.

Ich bin daher zuversichtlich, dass durch die Entdeckung dieser Sicherheitslücke die großen kommerziellen Profiteure des Internets erkennen, dass ähnlich wie bei der Raspberry Pi Foundation immer ein Rückfluss der Gewinne in derartige Projekte erfolgen muss. Man sägt sonst am Ast auf dem man sitzt und das tut bekanntlich schnell weh!

Zum Blog milsystems

Suchmaschinen ohne Zensur – Yacy auf Root-Server

In Zeiten von totaler Überwachung u.a. durch NSA und GCHQ und den jüngeren Vorfällen zu Lavabit und Truecrypt ist man gut beraten, wenn man sich seine eigene Suchmaschine betreibt. Hier ist keine Zensur möglich und man ist nicht vom Ranking Algorithmus großer Suchmaschinenbetreiber abhängig.

Die beständige Aufklärung über die Aktivitäten der Geheimdienste aus den Quellen von Eduard Snowden geben einem das Gefühl von beständiger Unsicherheit. Dies hat eine Umfrage der BITKOM ans Tageslicht gebracht. Die Abschaltung von Lavabit, das Ende von Truecrypt, einem beliebten Verschlüsselungsprogramm für Windows-Nutzer, und die vielen Schwachstellen bei OpenSSL sind gute Belege, dass dies berechtigt ist.

Was ist Yacy

Einfach nur herumsitzen und den Kopf in den Sand stecken, ist jedoch keine Idee, die das fehlende Gleichgewicht wieder herstellt. Ich bin in diesem Zusammenhang auf Yacy gestoßen. YaCy (von Yet another Cyberspace, homophon zu englisch ya see) ist eine Suchmaschine, die nach dem Peer-to-Peer-Prinzip – kurz P2P – arbeitet. Dabei gibt es keinen zentralen Server, sondern alle Teilnehmer sind gleichwertig. Es gibt also keine zentralen Suchmaschinenbetreiber wie Google oder Bing, sondern jeder Teilnehmer steuert über das P2P-Netzwerk einen kleinen Teil der Suchergebnisse bei. Das Netz lebt hierbei von der Anzahl der Teilnehmer, da hierdurch die Last besser verteilt werden kann.

Vorteile von Yacy

Dadurch ergeben sich folgende wichtige Vorteile für den Nutzer bzw. Betreiber der lokalen YaCy-Suchmaschine:

  • Die mit YaCy aufgebaute globale Suchmaschine ist aufgrund des P2P-Netzwerks sehr robust gegen Ausfälle.
  • Die Internetnutzer sind durch YaCy als Suchmaschine unabhängig von den großen Suchmaschinen, deren Werbegeschäftsmodellen und etwaige Zensur (vgl. Internetzensur in China).
  • Die Software ist Open Source, wurde unter der GNU General Public License veröffentlicht und ist kostenlos.

Dies hört sich verlockend an auf den ersten Blick. Jedoch erscheint es auf dem zweiten Blick schwierig. Das dem jedoch nicht so ist und YaCy eine Alternative zu “normalen” Suchmaschinen ist, zeige ich im Folgenden.

Einfacher Start

Auf der Youtube-Plattform sind bereits gut gemachte Videos enthalten, die einem zeigen, wie einfach man Schritt für Schritt einen YaCy-Server aufsetzt. Weiterhin hilft einem das ausführliche deutsche Wiki bei allen Detailfragen.

Installation unter Windows

Installation unter Linux

Wie man aus den Videos sieht, ist die Installation sehr einfach, da in der Installationsdatei alles erforderliche vorhanden ist. Sie dauert ca. 3 Minuten und man kann danach die ersten Suchläufe starten bzw. im Administrationsbereich die genaue Konfiguration durchführen.

Suchmaschine auf Root-Server

server

Um dieses weltweite Netzwerk von Knoten aus Suchmaschinen zu unterstützen bzw. um im eigenen Unternehmen (Intranet) eine Suchmaschine anbieten zu können, die mit der immensen Datenmenge zurecht kommt und die nötige Performance hat, empfiehlt sich ein eigener Root-Server. Auf diesem hat man alle Rechte, die man für den Betrieb einer YaCy-Suchmaschine benötigt. Auf einem derartigen Server können dann auch andere private bzw. business Dienste aufgesetzt werden (z.B. eigene Cloud, Mailserver, Webauftritt, Webshop u.v.m.), also nicht nur für eine Suchmaschine kaufen. Dies erhöht natürlich die Wirtschaftlichkeit eines solchen Dienstes (Nachts kann man z.B. die ungenutzte Rechenleistung für Crawling und Indexierung nutzen).

Diesen muss man nicht im eigenen Haushalt bzw. der Firma betreiben, sondern kann in der heutigen Zeit günstig gemietet werden (Infrastructure as a Service – IaaS). Um hier sich hier ein preiswertes Angebot zu finden, empfiehlt es sich Zeit zu nehmen und bei Server Anbietern/Server Hostern die Preise zu vergleichen.

Wie finde ich das passende Angebot?

Nicht immer der teuerste Anbieter  ist auch der Beste. Hier sollte man also neben den Erfahrungen anderer Kunden bzgl. kompetentem Support und Qualität der Erreichbarkeit des Anbieters (Stichwort: Server Ausfall, Verfügbarkeit) auch das Preis-Leistungs-Verhältnis immer im Blick haben.

  • Wie viel Speicherplatz bekommt man für sein Geld? (wichtig zum Betrieb einer Suchmaschine)
  • Wie hoch ist die Geschwindigkeit der Maschine (Prozessor/Hauptspeicher)? Je schneller, desto höhere Indexierungsraten schafft er.
  • Wichtig ist es bei der Suche nach günstigen Webhoster-Anbietern auf das inklusive Traffic-Volumen zu achten, da es beim Crawlen schnell zu unkalkulierbaren Kosten kommt.

Weitere Fragen für andere Einsatzzwecke:

  • Wie viele Datenbanken sind möglich?
  • Wie häufig macht der Anbieter Datensicherungen?
  • Wie viele E-Mail-Postfächer sind zulässig?
  • Wie hoch ist die Ausfallsicherheit?

Ich habe bereits meinen eigenen Server und crawle das Internet. Hier leiste ich einen Betrag zu einer unabhängigen und eigenständige Suche im www. Bei Fragen und Anregungen stehe ich gerne zur Verfügung!

Zum Blog milsystems

Babythermometer – Microcontroller überwacht Baby (Bluetooth Variante)

In diesem Artikel beschreibe ich die Entwicklung eines intelligenten Babythermometers. Dieses Thermometer verfügt über eine akkustische und visuelle Warnung, sofern eine kritische Temperatur erreicht wird. Weiterhin kann es drahtlos die Temperatur weitergeben und mittels Sprache ein und ausgeschaltet werden.

Erklärung

Ziel dieser Schaltung ist es, die Körpertemperatur eines Neugeborenen zu überwachen und dieses so vor Überhitzung und dem plötzlichen Kindstod zu bewahren. Im Notfall wird Alarm ausgelöst, sodass die Eltern schnell reagieren können.

Die unten gezeigte Schaltung verfügt über einen Bluetooth Empfänger. Ich verwende hier ein HC-05-Modul, welches sowohl als Master als auch als Slave geschaltet werden kann. Über das Smartphone kann ich mit der Android-App Blueterm auf den Sender zugreifen (dort erfolgt auch die Sprachsteuerung). Dazu verwende ich die Google-Spracherkennung innerhalb von Blueterm (vgl. hierzu das Tutorial von Gordon Williams).

Die Verbindung mit meinem Debian Linux Laptop stelle ich mit Blueman her. Sofern die Verbindung erfolgreich war, verbinde ich die Espruino Web-IDE über einen Seriellen Anschluss (trägt bei mir die Bezeichnung “/dev/rfcomm0″). Dort wird mir dann die Bluetooth Ausgabe des Espruino angezeigt. Als Temperatursensor verwende ich einen DS18B20+ in der Hochtemperaturvariante.

Schaltungsaufbau

Babythermometer Bluetooth Schaltungsaufbau

 

Verbindungsübersicht

Kabel Espruino Thermometer DS18B20+ Lautsprecher Bluetooth HC-05
3,3 rot 3,3
GND schwarz 2. Eingang GND
A1 orange
A0   1. Eingang
B6   RXD
B7 TXD

Programmcode

Der Quellcode ist gut kommentiert, sodass man ihn leicht verstehen sollte. Das Uhrwerk muss zuerst initialisiert werden in Zeile 19 bis 23. Auf meiner Espruino habe ich für eine genauere Uhrzeit einen 32,768KHz Quarz Kristall angelötet. Um die Temperaturwarnung zu testen, kann man den Temperatursensor an eine Lampe halten, um schneller die Maximaltemperatur zu erreichen.

Hier der Quellcode:

//Bluetooth HC-05 (optional)
function onInit() {Serial1.setup(9600,{tx:B6,rx:B7});}
//wie oft temperatur messen (in ms)
var PRUEFINTERVALL=5000;
//temperatur sensor
TEMPANSCHLUSS=A1;
var ow = new OneWire(TEMPANSCHLUSS);
var sensor = require("DS18B20").connect(ow);
//maximale temperatur
var maxTemp = 37.5;
//warnsignal
var SPEAKER = A0;
//Warnung
var next_LED=0;
var warnintervall;
var ton;
var tonTimeout;
//LEDs initial aus
LED1.write(0);
LED2.write(0);
LED3.write(0);
function tonAn() {
 //audiosignal abgeben
 ton=setInterval(function() {
 analogWrite(SPEAKER,0.5,{freq:500});
 tonTimeout=setTimeout(function() {
 digitalRead(SPEAKER);
 }, 80);
 },100);
}
function tonWarnung(an) {
 //Tonwarnung nur anschalten, wenn bisher aus
 if (an) {
 if (ton===undefined) {
 tonAn();
 }
 } else {
 if (ton!==undefined) {
 clearInterval(ton);
 ton=undefined;
 }
 }
}
function ledBlink() {
 warnintervall=setInterval(function() {
 switch(next_LED) {
 case 1:
 LED1.write(1);
 LED3.write(0);
 break;
 case 2:
 LED2.write(1);
 LED1.write(0);
 break;
 case 3:
 LED3.write(1);
 LED2.write(0);
 break;
 }
 //Schleife über LEDs
 next_LED = Math.wrap(next_LED, 3) + 1;
 }, 100);
}
function ledWarnung(an) {
 //Lichtwarnung nur anschalten, wenn bisher aus
 if (an) {
 if (warnintervall===undefined) {
 ledBlink();
 }
 } else {
 if (warnintervall!==undefined) {
 clearInterval(warnintervall);
 warnintervall=undefined;
 }
 LED1.write(0);
 LED2.write(0);
 LED3.write(0);
 //LED2 betriebsanzeige
 LED2.write(1);
 ledTimeout=setTimeout(function(){LED2.write(0);},1000);
 }
}
function pruefung() {
 var message="";
 //Temperatur auslesen
 var temp = sensor.getTemp();
 // pruefung der temperatur
 if (temp > maxTemp){
 tonWarnung(true);
 ledWarnung(true);
 message="temperaturwarnung: "+temp+" Grad";
 } else {
 tonWarnung(false);
 ledWarnung(false);
 message="temperatur: "+temp+" Grad";
 }
 //Prüfergebnis ausgeben
 console.log(message);
 //über Bluetooth
 Serial1.println(message);
}
//Prüfung initial starten
pruefInt=setInterval(function(){
 pruefung();
 command="";
}, PRUEFINTERVALL);
//Sprachsteuerung
var command = "";
Serial1.onData(function(e) {
 command += e.data;
 //ausschalten
 if (command=="Ende"){
 command="";
 if (pruefInt!=="undefined"){
 clearInterval(pruefInt);
 pruefInt=undefined;
 }
 }
 //anschalten
 else if (command=="Start"){
 command="";
 if (pruefInt=="undefined"){
 pruefInt=setInterval(function(){
 pruefung();
 command="";
 }, PRUEFINTERVALL);
 }
 }
});

Zum Blog milsystems