Customized Baustein CB 5.92 Application Server

Größe: px
Ab Seite anzeigen:

Download "Customized Baustein CB 5.92 Application Server"

Transkript

1 Anhang Referenzdokument A4 BayLfSt Customized Baustein CB 5.92 Application Server Status: Freigegeben Datum: Autor: Olaf Schlüter, secunet Security Networks AG

2 Inhaltsverzeichnis 1 Einleitung 3 2 Customized Baustein CB 5.92 Application Server Beschreibung des Application Servers Gefährdungslage Höhere Gewalt Organisatorische Mängel Menschliche Fehlhandlungen Technisches Versagen Vorsätzliche Handlungen Maßnahmen Planung und Konzeption Beschaffung Umsetzung Betrieb Notfallvorsorge Ableitungstabelle 145 Status: Freigegeben Datum: Seite 1 von 146

3 Historie Version Datum Änderung Autor Erste Version Olaf Schlüter Version für Review Olaf Schlüter Review durch PL Rupert Lipowsky Review durch QS Andreas Mann Überarbeitung und Korrekturen Rupert Lipowsky Status: Freigegeben Datum: Seite 2 von 146

4 1 Einleitung Ein vorgefertigter Baustein für einen nach J2EE-Spezifikation arbeitenden Application Server existiert nicht nach dem GSHB des BSI. Das GSHB erlaubt bzw. fordert für Nicht-Standardanwendungen die Erstellung eines Customized Bausteins mit den Gefährdungen und den daraus resultierenden Sicherungsmaßnahmen. Dieser Customized Baustein für den Application Server wurde mit Hilfe der Standardmaßnahmen B 5.4 Webserver und B 5.11 Apache Webserver des GSHB modelliert. Die Nummerierung der verwendeten Maßnahmen wurde nicht verändert. Um die Veränderung zu kennzeichnen wurden ihre Bezeichner mit einem * versehen. Da die Inhalte der jeweiligen Maßnahmen meist generisch aufgebaut sind, wurden sie sinngemäß übernommen und auf einen Application Server übertragen. Status: Freigegeben Datum: Seite 3 von 146

5 2 Customized Baustein CB 5.92 Application Server 2.1 Beschreibung des Application Servers Ein Application Server im Sinne dieses Bausteins ist ein IT-System, dass im wesentlichen einen Dienst zum Aufruf von Methoden in Enterprise Java Beans (EJBs) gemäß der J2EE-Spezifikation anbietet. Ein solcher Application Server besteht üblicherweise aus einer Reihe von Teilsystemen: einem JNDI (Java Network Directory Interface) Dienst zur Lokalisierung von EJBs und anderen Diensten, einem J2EE-Container als Laufzeitumgebung für EJBs, optional einem JMS (Java Message Service) Provider, optional einem Servlet-Container (z. B. Tomcat) für Servlet-Dienste und Präsentation von dynamischem HTML-Content via JSP (Java Server Pages), optional einem Web-Server (z.b. Apache) zur Präsentation von statischem HTML-Content, optional Web Services (über http/soap oder ähnlichem), im Regelfall eine oder mehrere Adminstrationsschnittstellen und ggf. weiteren Diensten, die teilweise nur lokal, teilweise via Netzwerk genutzt werden können. Ein Application Server nutzt im Regelfall als Client mindestens eine Datenbank, die auf dem gleichen oder einem entfernten IT-System betrieben wird. Er kann auch Module zur Verbindung mit anderen entfernten IT-Systemen haben, insbesondere mit weiteren Application Servern. Ein Application Server ähnelt aus sicherheitstechnischer Sicht grundsätzlich einem Web-Server, der bei der Verarbeitung von http-requests auf dem Server hinterlegte Java-Anwendungen (z.b. in Form von Servlets oder JSPs) ausführt. Ein solcher Server ist im Sonderbaustein Tomcat-Server beschrieben. Die dort genannten Gefährdungen und Schutzmaßnahmen bilden daher auch die Grundlage zur Gestaltung des Sonderbausteins Application Server. Darüberhinaus bietet ein Application Server weitere Netzwerkdienste an, die auf die unterschiedlichste Art und Weise als eine Art Unterprogramme für aufrufende IT- Systeme agieren. Die beim Dienstaufruf verwendeten Netzwerkports und Protokolle Status: Freigegeben Datum: Seite 4 von 146

6 sind dabei oft herstellerspezifisch und besitzen nicht immer inhärente Sicherheitsfunktionen für Vertraulichkeit oder Integrität. Insbesondere darf auch nicht davon ausgegangen werden, dass die Identität des Aufrufers dem Application Server bekannt ist und eine von dieser Identität abhängige Zugriffskontrolle wirkt. In der Elster-Infrastruktur finden zwei Application Server-Typen Verwendung: Bean Transactions (BeanTA) von Fujjitsu Siemens Computers Oracle Application Server 10g von Oracle Corp Nur bei BeanTA wird die vorhandene RMI-Schnittstelle von anderen IT-Systemen für den Aufruf von Enterprise Java Beans genutzt. Die Aufrufe erfolgen über Servlets dieser anderen Systeme. Die Zugriffe auf die Oracle Application Server erfolgen von einem Browser aus via http und https. Weiterhin bieten beide Servertypen Remote- Adminstration über http/https, SSH sowie proprietäre Netzwerkschnittstellen. 2.2 Gefährdungslage Für den IT-Grundschutz werden pauschal die folgenden Gefährdungen als typisch für einen Application Server angenommen: Höhere Gewalt G 1.2* Ausfall des IT-Systems Der Ausfall eines Application Servers kann zur Behinderung des IT- Betriebs führen Organisatorische Mängel Die folgenden organisatorischen Mängel werden von den Standardbausteinen übernommen, die diesem Baustein zugrunde liegen: G 2.1* Fehlende oder unzureichende Regelungen Übergreifende und organisatorische Regelungen und Vorgaben spielt eine wichtige Rolle auch für einen Application Server. Die Regelungen umfassen z.b. die Festlegung der Zuständigkeiten für die Administration und Konfiguration des Application Server, Zugriffsregeln auf den Application Server usw. Fehlende oder unzureichende Regelungen können große Auswirkungen auf die Verfügbarkeit sowie die Sicherheit des Application Servers. Aber nicht nur fehlende oder unzureichende Regelungen haben Status: Freigegeben Datum: Seite 5 von 146

7 negative Auswirkung auf den IT-Betrieb sondern auch nicht angepasste Regelungen alte Regelungen die vielleicht mal ausreichend waren aber nicht mehr sind, also veraltete Regelungen. Oft werden nach Veränderungen technischer, organisatorischer oder personeller Art, die wesentlichen Einfluss Fehlende oder unzureichende Regelungen auf die IT-Sicherheit haben, bestehende Regelungen nicht angepasst. Veraltete Regelungen können dem störungsfreien IT-Betrieb entgegen stehen. G 2.2* Unzureichende Kenntnis über Regelungen Die Festlegung von Regelungen allein sichert den störungsfreien IT- Einsatz noch nicht. Allen Mitarbeiter müssen die geltenden Regelungen auch bekannt sein, vor allem den Funktionsträgern. Der Schaden, der sich aus einer unzureichenden Kenntnis über bestehende Regelungen ergeben kann, darf sich nicht mit den Aussagen entschuldigen lassen: "Ich habe nicht gewusst, dass ich dafür zuständig bin." oder "Ich habe nicht gewusst, wie ich zu verfahren hatte." Beispiel: Wenn Regelungen zur Systemprotokollierung vereinbart wurden, diese aber den Administratoren des Application Servers nie überreicht wurden bzw. von ihnen nicht zur Kenntnis genommen wurden, dann wären diese Regelungen nutzlos. G 2.4* Unzureichende Kontrolle der IT-Sicherheitsmaßnahmen Nach der Einführung von Maßnahmen, die der Sicherheit der IT dienen (z. B. Datensicherung, Zutrittskontrolle, Vorgaben für Verhalten bei Notfällen), müssen diese auch konsequent umgesetzt werden. Finden keine oder nur unzureichende Kontrollen der Sicherheitsmaßnahmen statt, wird weder deren Missachtung noch ihre effektive Wirksamkeit festgestellt. Eine rechtzeitige und der jeweiligen Situation angemessene Reaktion wird dadurch verhindert. Darüber hinaus gibt es Sicherheitsmaßnahmen, die nur mit der Durchführung entsprechender Kontrollen ihre Wirkung entfalten. Hierzu zählen beispielsweise Protokollierungsfunktionen, deren Sicherheitseigenschaften erst mit der Auswertung der Protokolldaten zum Tragen kommen. Beispiel: Application Server werden zur externen Datenkommunikation eingesetzt. Aufgrund ihrer zentralen Bedeutung sieht das IT- Sicherheitskonzept vor, dass die Application Server wöchentlich einer Integritätsprüfung unterworfen werden. Da diese Status: Freigegeben Datum: Seite 6 von 146

8 Überprüfungen nicht regelmäßig nachgehalten werden, fällt erst bei der Klärung eines Sicherheitsvorfalls auf, dass die IT- Abteilung auf solche Integritätsprüfungen verzichtet hat. Als Grund wurde die mangelhafte personelle Ausstattung der Abteilung genannt. G 2.7* Unerlaubte Ausübung von Rechten Rechte wie Zutritts-, Zugangs- und Zugriffsberechtigungen werden als organisatorische Maßnahmen eingesetzt, um eine sichere und ordnungsgemäße IT-Nutzung zu gewährleisten. Werden solche Rechte an die falsche Person vergeben oder wird ein Recht unautorisiert ausgeübt, können sich eine Vielzahl von Gefährdungen ergeben, die die Vertraulichkeit und Integrität von Daten oder die Verfügbarkeit von Rechnerleistung beeinträchtigen. Beispiel: Ein Administrator installiert zum Ausprobieren eine nicht freigegebene und nicht getestete Webanwendung. Diese verstößt u. U. gegen das Urheberrecht (Siehe auch G 2.28) oder enthält Schadcode, der Webanwendungen in derselben Java VM beeinflusst. G 2.9* Mangelhafte Anpassung an Veränderungen beim IT-Einsatz Die speziell für den Einsatz von Informationstechnik geschaffenen organisatorischen Regelungen, aber auch das gesamte Umfeld einer Behörde bzw. eines Unternehmens unterliegen ständigen Veränderungen. Sei es nur, dass Mitarbeiter ausscheiden oder hinzukommen, Mitarbeiter das Büro wechseln, neue Hardware oder Software beschafft wird, der Zulieferbetrieb für die Betriebsmittel Konkurs anmeldet. Dass sich bei einer ungenügenden Berücksichtigung der vorzunehmenden organisatorischen Anpassungen Gefährdungen ergeben, zeigen folgende Beispiele: Vor Urlaubsantritt vergisst ein Mitarbeiter, der Urlaubsvertretung Zugriffsrechte auf alle von dieser benötigten Dateien und Verzeichnisse zu übertragen. Hierdurch können sich Verzögerungen im IT-Betrieb ergeben. Beim Kauf eines neuen Kryptomoduls wird ein Gerät gewählt, das ein kryptografisches Verfahren nicht unterstützt, welches von einer bestehenden Webanwendung benötigt wird. Beim Empfang elektronischer Dokumente werden diese nicht automatisch auf Makro-Viren überprüft, da dieses Problem noch Status: Freigegeben Datum: Seite 7 von 146

9 nicht bekannt ist oder kein Virenprüfprogramm vorhanden ist. Bei der Übermittlung elektronischer Dokumente wird nicht darauf geachtet, diese in einem für die Empfängerseite lesbaren Format abzuspeichern. G 2.22 Fehlende Auswertung von Protokolldaten Die meisten IT-Systeme und Anwendungen bieten Funktionalitäten an, um die Nutzung der Operationen, ihre Reihenfolge und ihre Auswirkungen zu protokollieren. Im Lebenszyklus eines IT-Systems kommen verschiedene Protokollierungskonzepte zum Einsatz. Während der Entwicklungsphase werden ausführliche Protokolle erstellt, um im Fehlerfall die Protokolldaten für eine detaillierte Problemanalyse heranziehen zu können und die Fehlerbehebung zu erleichtern. In der Einführungsphase werden Protokolle genutzt, um unter anderem die Performance des IT-Systems in der Produktivumgebung zu optimieren oder um die Wirksamkeit des Sicherheitskonzepts erstmals in der Praxis zu überprüfen. In der Produktivphase werden Protokolle hauptsächlich auf die Sicherstellung des ordnungsgemäßen Betriebs bezogen. Protokolldaten dienen dann dem Zweck, nachträglich feststellen zu können, ob Sicherheitsverletzungen im IT-System stattgefunden haben oder ob ein Angriffsversuch unternommen wurde. Protokolldaten werden für die Fehleranalyse im Schadensfall und zur Ursachenermittlung bzw. zur Integritätsprüfung genutzt. Die Protokollierung kann auch der Täterermittlung und damit auch der Abschreckung von potenziellen Tätern dienen. Durch regelmäßige Auswertung der Protokolldaten können vorsätzliche Angriffe auf ein IT-System unter Umständen frühzeitig erkannt werden. Findet die Auswertung der Protokolldaten nicht oder nur unzureichend statt, können diese nicht für Präventivmaßnahmen genutzt werden. Bei einigen IT-Systemen oder Anwendungen fehlen ausreichende Protokollierungsmöglichkeiten. Häufig ist es mit systemeigenen Mitteln nicht oder nur schwer möglich, bei der Protokollierung nach der Art der Ereignisse zu differenzieren. Teilweise ist überhaupt keine Protokollierung vorgesehen. Beispiele: Ein nicht autorisierter Benutzer versucht, Zugriff auf einen Datenbank-Server zu erlangen, indem er zu bekannten Benutzernamen die entsprechenden Passwörter rät. Die Status: Freigegeben Datum: Seite 8 von 146

10 erfolglosen Authentisierungsversuche werden im System protokolliert. Aufgrund fehlender Auswertung der Protokolldateien werden die Angriffsversuche nicht erkannt. Der unautorisierte Benutzer kann unerkannt den Angriffsversuch gegebenenfalls bis zum Erfolg fortsetzen. Auf einem nicht vernetzten Windows 95-Rechner gibt es keine Möglichkeit, die Aktivitäten eines oder mehrerer Benutzer benutzerspezifisch zu protokollieren. Es ist daher nicht festzustellen, ob Sicherheitsverletzungen im IT-System stattgefunden haben oder ob ein solcher Versuch unternommen wurde. G 2.26 Fehlendes oder unzureichendes Test- und Freigabeverfahren Wird neue Hard- oder Software nicht oder nur unzureichend getestet und ohne Installationsvorschriften freigegeben, kann es passieren, dass Fehler in der Hard- oder Software nicht erkannt werden oder dass die notwendigerweise einzuhaltenden Installationsparameter nicht erkannt bzw. nicht beachtet werden. Diese Hardware-, Software- oder Installationsfehler, die aus einem fehlenden oder unzureichenden Software- Test- und Freigabeverfahren resultieren, stellen eine erhebliche Gefährdung für den IT-Betrieb dar. Im Vertrauen auf eine problemlose Installation neuer Hard- bzw. Software wird oftmals übersehen, dass mögliche Schäden in keinem Verhältnis zu dem Aufwand stehen, den ein geordnetes Test- und Freigabeverfahren erfordert. Programme oder IT-Systeme werden unzureichend getestet und mit Fehlern in eine Produktionsumgebung eingebracht. Die Fehler wirken sich in der Folge störend auf den bis zu diesem Zeitpunkt problemlosen Betrieb aus. Beispiele für solche Schäden werden nachfolgend aufgezeigt: Programme oder Programm-Updates lassen sich nicht sinnvoll nutzen, da für ein annehmbares Verarbeitungstempo mehr Ressourcen (z. B. Hauptspeicher, Prozessorkapazität) als erwartet benötigt werden. Wird dies nicht im Test erkannt, kann das zu erheblichen Fehl- oder Folgeinvestitionen führen. Nicht selten führten Entscheidungen gegen weitere Investitionen dazu, dass ein Softwareprodukt zwar gekauft und bezahlt, jedoch nie benutzt wurde. Eingeübte Arbeitsabläufe werden nach Installation neuer Software maßgeblich behindert. Der mit der Installation des Programms beabsichtigte Nutzen stellt sich erst bedeutend später ein, da die Mitarbeiter im Vorfeld nicht geschult bzw. nicht über die neuen Funktionen des Programms informiert wurden. Status: Freigegeben Datum: Seite 9 von 146

11 Durch das Einspielen eines Updates einer DBMS- Standardsoftware, das mit Fehlern behaftet ist, steht die Datenbank nicht mehr zur Verfügung oder es kommt zu Datenverlust. Einige Software-Produkte installieren die Microsoft Server Desktop Engine (MSDE) als Datenbank, ohne dass dies vom Benutzer bemerkt wird. Hierbei handelt sich um eine Ausprägung des Microsoft SQL Servers mit den typischen Gefährdungen eines Datenbanksystems. Oft sind die Benutzer des Produktes bzw. die Administratoren, die das Produkt installieren, nicht ausreichend über diese Gefährdungen informiert und versäumen, sicherheitsrelevante Maßnahmen zu ergreifen. So wird häufig in Verbindung mit MSDE ein Benutzerkonto in der Datenbank für den Administrator angelegt, das in der Grundinstallation über keinen Passwortschutz verfügt. Auf diese Weise können Angreifer einen Vollzugriff auf die Daten und gegebenenfalls sogar auf das Betriebssystem erhalten. G 2.27 Fehlende oder unzureichende Dokumentation Verschiedene Formen der Dokumentation können betrachtet werden: die Produktbeschreibung, die Administrator- und Benutzerdokumentation zur Anwendung des Produktes und die Systemdokumentation. Eine fehlende oder unzureichende Dokumentation der eingesetzten IT- Komponenten kann sowohl im Auswahl- und Entscheidungsprozess für ein Produkt, als auch bei einem Schadensfall im Wirkbetrieb erhebliche Auswirkungen haben. Bei einer unzureichenden Dokumentation kann sich im Schadensfall, beispielsweise durch den Ausfall von Hardware bzw. Fehlfunktionen von Programmen, die Fehlerdiagnose und -behebung erheblich verzögern oder völlig undurchführbar sein. Dies gilt auch für die Dokumentation von Leitungswegen und Verkabelungen innerhalb der Gebäude-Infrastruktur. Ist aufgrund unzureichender Dokumentation die genaue Lage von Leitungen nicht bekannt, so kann es bei Bauarbeiten außerhalb oder innerhalb eines Gebäudes zu Beschädigungen von Leitungen kommen. Dabei kann es zu längeren Ausfallzeiten (Eintritt eines Notfalls) oder unter Umständen sogar zu lebensbedrohenden Gefahren, z. B. durch Stromschlag, kommen. Beispiele: Wenn von einem Programm Arbeitsergebnisse in temporären Status: Freigegeben Datum: Seite 10 von 146

12 Dateien zwischengespeichert werden, ohne dass dies ausreichend dokumentiert ist, kann dies dazu führen, dass die temporären Dateien nicht angemessen geschützt und vertrauliche Informationen offengelegt werden. Durch fehlenden Zugriffsschutz auf diese Dateien oder eine nicht korrekte physikalische Löschung der nur temporär genutzten Bereiche können Informationen Unbefugten zugänglich werden. Bei Installation eines neuen Softwareproduktes werden bestehende Konfigurationen abgeändert. Andere, bislang fehlerfrei laufende Programme sind danach falsch parametrisiert und stürzen ggf. ab. Durch eine detaillierte Dokumentation der Veränderung bei der Installation von Software ließe sich der Fehler schnell lokalisieren und beheben. In einer größeren Behörde wurde die Verkabelung der IT durch eine externe Firma vorgenommen. Die Anfertigung einer Dokumentation war im Leistungsumfang nicht enthalten. Da nach Fertigstellung der Verkabelung mit der Firma kein Wartungsvertrag abgeschlossen wurde, verfügte die Behörde nicht über die notwendige Dokumentation. Erweiterungen des Netzes konnten nur mit erheblichen Verzögerungen vorgenommen werden (siehe auch G 2.12 Unzureichende Dokumentation der Verkabelung). In einer z/os-installation wurden jeden Abend automatisch Batch-Jobs zur Verarbeitung von Anwendungsdaten gestartet. Für die Verarbeitung war es wichtig, dass die Batch-Jobs in der richtigen Reihenfolge abliefen. Als eines Abends die Automation versagte, mussten die Jobs manuell gestartet werden. Aufgrund fehlender Dokumentation wurden die Batch-Jobs in der falschen Reihenfolge gestartet. Dies führte zu Abbrüchen in der Verarbeitung der Anwendungsdaten und zu Verzögerungen in der Produktion um mehrere Stunden. G 2.28* Verstöße gegen das Urheberrecht Der Einsatz nicht-lizenzierter Software kann einen Verstoß gegen das Urheberrecht darstellen und sowohl zu zivil- als auch strafrechtlichen Konsequenzen führen. Behörden und Unternehmen, in denen Raubkopien zum Einsatz kommen, können im Rahmen des Organisationsverschuldens, unabhängig von der Schuldform (Vorsatz oder Fahrlässigkeit) vom Urheberrechtseigentümer schadensersatzpflichtig gemacht werden. Status: Freigegeben Datum: Seite 11 von 146

13 Beispiel: Für die Entwicklung einer Webanwendung wurden Bibliotheken Dritter verwendet, die entweder für die Entwicklung frei sind oder für die eine entsprechende Entwicklerlizenz vorlag. Für die Produktion muss aber eine gesonderte Lizenz erworben werden. G 2.29 Softwaretest mit Produktionsdaten Vielfach ist zu beobachten, dass Softwaretests mit Produktionsdaten vollzogen werden. Als wesentliche Gründe werden hierfür angeführt, dass nur im direkten Vergleich mit vorhandenen Arbeitsergebnissen eine abschließende Beurteilung über die Funktion und Performance des Produktes möglich ist. Darüber hinaus sind mangelndes Sicherheitsbewusstsein, überzogenes Vertrauen in die zu testende Software und Unkenntnis über mögliche schädliche Auswirkungen ursächlich für diese Vorgehensweise. Beim Test mit Produktionsdaten kann es zu folgenden Problemen kommen: Software wird mit Kopien von Produktionsdaten in isolierter Testumgebung getestet: Wenn neue Software mit nicht anonymisierten Daten getestet wird, erhalten evtl. nicht befugte Mitarbeiter, bzw. Dritte, die mit dem Softwaretest beauftragt worden sind, hierbei Einblick in Dateien mit evtl. vertraulichen Informationen. Software wird mit Produktionsdaten im Wirkbetrieb getestet: Fehlfunktionen von Software während des Testens können über den oben geschilderten Fall hinaus beispielsweise dazu führen, dass neben der Vertraulichkeit der Produktionsdaten auch deren Integrität und Verfügbarkeit beeinträchtigt werden. Aufgrund der Inkompatibilität unterschiedlicher Programme können Seiteneffekte auftreten, die bei anderen Systemkomponenten zu nachhaltigen Beeinträchtigungen führen können. Bei vernetzten Systemen kann das von Performanceverlusten bis hin zum Systemabsturz des Netzes reichen. Durch fehlerhaftes Verhalten der zu testenden Software oder Bedienfehler können Produktionsdaten ungewollt verändert werden. Möglicherweise wird diese Veränderung nicht festgestellt. Da Datenbestände, um unnötige Redundanz zu vermeiden, zunehmend durch unterschiedliche Programme gemeinsam genutzt werden, können sich diese Fehler auch auf andere IT-Anwendungen auswirken. Im Schadensfall ist nicht nur der Aufwand für die Rekonstruktion der Daten Status: Freigegeben Datum: Seite 12 von 146

14 notwendig, darüber hinaus müssen bereits erstellte Arbeitsergebnisse auf ihre Integrität überprüft werden. G 2.32* Unzureichende Ressourcen Bei der Planung von Systemen wird oft der Fehler begangen, die Kapazitätsauslegung ausschließlich am aktuellen Bedarf vorzunehmen. Dabei wird übersehen, dass die Kapazitätsanforderungen an das System stetig steigen, z. B. wenn neue IT-Systeme in das Netz integriert werden oder das übertragene Datenvolumen zunimmt. Beispiele: Wenn die Kapazität des Netzes nicht mehr ausreicht, werden die Übertragungsgeschwindigkeit und ggf. auch die Erreichbarkeit im Netz für alle Benutzer stark eingeschränkt. Wenn zu viele Anfragen gleichzeitig bearbeitet werden, kann die verfügbare Rechenzeit bzw. der verfügbare Speicher aufgebraucht werden. Dies kann den Absturz des System verursachen. Über einen Monat verteilt werden nur vereinzelt Anfragen an das System gestellt, während die Hauptlast nur zu bestimmten Zeitpunkten auftritt, z. B. zum Wochen- oder Monatsende. G 2.59* Betreiben von nicht angemeldeten Webanwendungen In der Regel sollten alle Webanwendungen eines Systems der Systemadministration bekannt sein. Es muss auf organisatorischer Ebene gewährleistet sein, dass neue Webanwendungen bei der Systemadministration angemeldet und freigegebenen werden, z. B. durch einen entsprechenden Antrag der die Webanwendung betreibenden Organisationseinheit. Nicht angemeldete Webanwendungen stellen ein Sicherheitsrisiko dar, da sie nicht in organisatorische innerbetriebliche Abläufe und Kontrollen eingebunden sind. Dies kann einerseits zu Gefahren für die Benutzer der nicht angemeldeten Webanwendung führen (z. B. Datenverlust, da das System nicht in die Datensicherung eingebunden ist), aber auch zur Gefährdung anderer Netzkomponenten, z. B. können durch nicht erfasste Webanwendungen zum Netz Schwachstellen entstehen, wenn diese schlecht oder gar nicht gegen unbefugten Zugriff abgesichert sind. Da eine solche Webanwendung nicht der Kontrolle des Systemmanagements unterliegt, können insbesondere Fehlkonfigurationen zu einem Sicherheitsloch führen. Status: Freigegeben Datum: Seite 13 von 146

15 G 2.69* Fehlende oder unzureichende Planung des Einsatzes eines Application Servers Eine Planung des Einsatzes spielt eine wichtige Rolle für einen ordnungsgemäßen Betrieb eine Application Servers. Die Planung sollte mindestens folgende Aspekte berücksichtigen: Die Planung der Zugriffsmöglichkeiten auf den Server ist ein Kernthema für die Systemsicherheit. Weiterhin ist die Planung der Administration des Application Servers ein wichtiges Thema. Insbesondere die Art des Zugriffs, z.b. über eine Webanwendung oder über die Kommandozeile, kann von entscheidender Bedeutung für die Sicherheit sein. Bei fehlender oder fehlerhafter Planung der Administrationsaufgaben besteht die Gefahr, dass das System unsicher oder unzulänglich administriert wird. Darüber hinaus können sich bei fehlender oder unzureichender Planung auch folgende Probleme ergeben: Der Administrationszugriff auf das System kann unzureichend gesichert sein, die Systemperformance zu gering sein und es kann zu Datenverlusten kommen, sofern Replikation und Backup nicht ausreichend berücksichtigt wurden. G 2.87* Verwendung unsicherer Protokolle in öffentlichen Netzen Bei der Kommunikation über öffentliche Netze, insbesondere das Internet, existiert eine Reihe von Gefahren, die aus der Verwendung unsicherer Protokolle entstehen. Eine wichtige Gefahr ist, dass vertrauliche Informationen in fremde Hände gelangen können. Als unsichere Protokolle müssen insbesondere solche Protokolle gelten, bei denen Informationen im Klartext übertragen werden. Da der Weg der Datenpakete im Internet nicht vorhersagbar ist, können in diesem Fall die übertragenen Informationen an verschiedensten Stellen mitgelesen werden. Besonders kritisch ist dies, wenn es sich um Authentisierungsdaten wie Benutzernamen und Passwörter, Autorisierungsdaten, beispielsweise Transaktionsnummern beim Electronic Banking oder Electronic Brokerage, Status: Freigegeben Datum: Seite 14 von 146

16 andere vertrauliche Informationen, beispielsweise in Dokumenten, die per verschickt werden, handelt. Protokolle, bei denen sämtliche Informationen im Klartext übertragen werden, sind beispielsweise das Hypertext Transfer Protocol http, das bei der Kommunikation zwischen Webbrowsern und Webservern verwendet wird, das telnet Protokoll, das noch an einigen Stellen für Remote Logins verwendet wird, das File Transfer Protocol ftp, das noch häufig für den Zugriff auf Server benutzt wird, die Dateien zum Download bereitstellen, das Simple Mail Transfer Protocol smtp, das zur Übertragung von verwendet wird, die Protokolle rsh (Remote Shell), rlogin (Remote Login) und andere verwandte Protokolle. Bei solchen Protokollen können sämtliche übertragenen Informationen auf jedem Rechner, über den eine entsprechende Verbindung läuft, mitgelesen und gegebenenfalls auch verändert werden. Kritisch ist beispielsweise die Übertragung von Kreditkartennummern oder Passwörtern über http-verbindungen im WWW. Mittels Password-Sniffings können in einem ersten Schritt Passwörter bei der Übertragung zu einem System abgefangen werden. Dies erlaubt dem Angreifer anschließend auf dieses IT-System zu gelangen, um dann weitere Angriffe lokal auf dem Rechner durchzuführen. Bei den erwähnten Protokollen (besonders bei http oder telnet) drohen auch sogenannte Man-in-the-middle-Angriffe oder Session Hijacking (siehe G 5.89 Hijacking von Netz-Verbindungen). Bei dieser Art von Angriffen ist ein Angreifer nicht nur dazu in der Lage, Informationen mitzulesen, sondern kann darüber hinaus aktiv Schaden anrichten, indem laufende Transaktionen verändert werden. Beispielsweise können Preise oder Bestellmengen bei Geschäften über das Internet so verändert werden, dass der Besteller nur die Artikel oder Lieferadresse sieht und bestätigt bekommt, die er eingibt, während der Angreifer eine wesentlich höhere Menge und eine andere Lieferadresse an den Verkäufer schickt. Neben den erwähnten Protokollen, bei denen sämtliche Informationen im Klartext übertragen werden, existieren auch solche, bei denen zumindest die Übertragung der Authentisierungsdaten verschlüsselt Status: Freigegeben Datum: Seite 15 von 146

17 erfolgt. Dabei droht jedoch immer noch das Mitlesen der übertragenen Nutzinformation. Bei einem Application Server wird die Situation noch dadurch verschärft, dass viele Dienste auf einem solchen Server über proprietäre Protokolle abgewickelt werden, von denen weder ihre Sicherheitseigenschaften noch Art und Umfang der übertragenen Daten bekannt sind. G 2.97* Unzureichende Notfallplanung für einen Application Server Eine unzureichende Planung für Notfälle kann Probleme, die beim Betrieb eines Application Servers auftreten, wesentlich verschlimmern und Ausfallzeiten verlängern. Zusätzlich zu allgemeinen Fehlern, die oft im Bereich Notfallvorsorge gemacht werden, können bei einem Application Server einige spezielle Fehler passieren, die eine schnelle Reaktion auf Zwischenfälle sehr erschweren oder gar unmöglich machen können. Einige dieser Fehler werden im Folgenden beschrieben. Wird nach einem Notfall (etwa einem Hackereinbruch) eine Neuinstallation eines Application Servers nötig, so kann es zu erheblichen Verzögerungen führen, wenn die bei der Installation verwendeten Pakete (Quelltexte oder Distributionspakete) nicht mehr verfügbar sind. Sind die Installationspakete zwar verfügbar, aber beispielsweise auf dem Webserverrechner selbst und nicht auf einem anderen Rechner oder einem schreibgeschützten Datenträger gespeichert, so müssen sie nach einem Hackereinbruch als unsicher angesehen werden. Existiert keine oder nur eine unzureichende Dokumentation der Konfiguration, dies gilt insbesondere für die installierten Webanwendungen, so kann es sehr schwierig sein, nach einem Notfall überhaupt wieder eine funktionierende Konfiguration herzustellen. Schlechte Dokumentation kann auch dazu führen, dass Konfigurationsfehler zunächst nicht entdeckt werden und bei auftretenden Problemen eine aufwendige Fehlersuche erforderlich wird. Bei der Systemwiederherstellung nach einem Notfall kann es wünschenswert sein, einen älteren Stand der Konfiguration wieder herzustellen. Wird für die Konfigurationsdateien keine Versionsverwaltung durchgeführt, so kann dies schwierig oder gar unmöglich sein. Status: Freigegeben Datum: Seite 16 von 146

18 2.2.3 Menschliche Fehlhandlungen G 3.1 Vertraulichkeits-/Integritätsverlust von Daten durch Fehlverhalten der IT-Benutzer Durch Fehlverhalten können IT-Benutzer den Vertraulichkeits- bzw. Integritätsverlust von Daten herbeiführen bzw. ermöglichen. Die Folgeschäden ergeben sich aus der Schutzbedürftigkeit der Daten. Beispiele für ein solches Fehlverhalten sind: Mitarbeiter holen versehentlich Ausdrucke mit personenbezogenen Daten nicht am Netzdrucker ab. Es werden Datenträger versandt, ohne dass die vorher darauf gespeicherten Daten physikalisch gelöscht wurden. Dokumente werden auf einem Webserver veröffentlicht, ohne dass geprüft wurde, ob diese tatsächlich zur Veröffentlichung vorgesehen und freigegeben sind. Aufgrund von fehlerhaft administrierten Zugriffsrechten vermag ein Mitarbeiter Daten zu ändern, ohne die Brisanz dieser Integritätsverletzung einschätzen zu können. Neue Software wird mit nicht anonymisierten Daten getestet. Nicht befugte Mitarbeiter erhalten somit Einblick in geschützte Dateien bzw. vertrauliche Informationen. Möglicherweise erlangen überdies auch Dritte Kenntnis von diesen Informationen, weil die Entsorgung von Testausdrucken nicht entsprechend geregelt ist. Beim Ausbau, Verleih, Einsendung zur Reparatur oder Ausmusterung von Festplatten können Daten auf zum Teil intakten Dateisystemen in unbefugte Hände gelangen. Betreut ein Outsourcing-Dienstleister mehrere Mandanten, so können Daten einer auslagernden Organisation durch menschliches Versagen anderen Mandanten des Outsourcing-Dienstleisters zugänglich werden. Mögliche Ursachen können beispielsweise folgende sein: Falsches Routing einer Druckausgabe. Auswahl einer falschen -Adresse aus dem Adressbuch. Fehler in einer Datenbank. Status: Freigegeben Datum: Seite 17 von 146

19 Unbedachtes copy - paste (z. B. von Konfigurationsdateien von Systemen verschiedener Auftraggeber). Postversand (z. B. von Backup-Medien, Verträgen) an die falsche Adresse. G 3.3 Nichtbeachtung von IT-Sicherheitsmaßnahmen Aufgrund von Nachlässigkeit und fehlenden Kontrollen kommt es immer wieder vor, dass Personen die ihnen empfohlenen oder angeordneten IT-Sicherheitsmaßnahmen nicht oder nicht im vollen Umfang durchführen. Es können Schäden entstehen, die sonst verhindert oder zumindest vermindert worden wären. Je nach der Funktion der Person und der Bedeutung der missachteten Maßnahme können sogar gravierende Schäden eintreten. Vielfach werden IT-Sicherheitsmaßnahmen aus einem mangelnden Sicherheitsbewusstsein heraus nicht beachtet. Ein typisches Indiz dafür ist, dass wiederkehrende Fehlermeldungen nach einer gewissen Gewöhnungszeit ignoriert werden. Beispiele: Der verschlossene Schreibtisch bietet zur Aufbewahrung von Disketten oder anderen Informationsträgern keinen hinreichenden Schutz gegen unbefugten Zugriff, wenn der Schlüssel im gleichen Büro aufbewahrt wird, z. B. auf dem Schrank oder im Zettelkasten. Geheimzuhaltende Passwörter werden schriftlich fixiert in der Nähe eines Terminals oder PCs aufbewahrt. Obwohl die schadensmindernde Eigenschaft von Datensicherungen hinreichend bekannt ist, treten immer wieder Schäden auf, wenn Daten unvorhergesehen gelöscht werden und aufgrund fehlender Datensicherung die Wiederherstellung unmöglich ist. Dies zeigen insbesondere die dem BSI gemeldeten Schäden, die z. B. aufgrund von Computer-Viren entstehen. Der Zutritt zu einem Rechenzentrum sollte ausschließlich durch die mit einem Zutrittskontrollsystem (z. B. Magnetstreifenleser, Chipkartenleser oder biometrische Verfahren) gesicherte Tür erfolgen. Die Fluchttür wird jedoch, obwohl sie nur im Notfall geöffnet werden darf, als zusätzlicher Ein- und Ausgang genutzt. Status: Freigegeben Datum: Seite 18 von 146

20 In einem z/os-system liefen täglich Batch-Jobs für die RACF- Datenbank-Sicherungen. Die korrekte Ausführung dieser Abläufe sollte täglich von den zuständigen Administratoren geprüft werden. Da die Sicherungen jedoch über mehrere Monate ohne Probleme durchgeführt wurden, kontrollierte niemand mehr den Ablauf. Erst nachdem die RACF- Datenbanken des Produktionssystems defekt waren und die Sicherungen zurückgespielt werden sollten, wurde festgestellt, dass die Batch-Jobs seit mehreren Tagen nicht mehr gelaufen waren. Dies führte dazu, dass keine aktuellen Sicherungen vorhanden waren und die Änderungen der letzten Tage von Hand nachgetragen werden mussten. Neben einem erheblichen zusätzlichen Administrationsaufwand ergab sich dadurch ein Unsicherheitsfaktor, da nicht alle Definitionen sicher rekonstruiert werden konnten. G 3.9 Fehlerhafte Administration des IT-Systems Eine fehlerhafte Administration beeinträchtigt die Sicherheit eines IT- Systems, wenn dadurch IT-Sicherheitsmaßnahmen missachtet oder umgangen werden. Eine fehlerhafte Administration liegt z. B. vor, wenn Netzzugangsmöglichkeiten geschaffen oder nicht verhindert werden, die für den ordnungsgemäßen Betrieb des IT Systems nicht notwendig sind oder auf Grund ihrer Fehleranfälligkeit eine besonders große Bedrohung darstellen. Ein häufiges Problem ist, dass bei Arbeiten am System Zugangskonten verwendet werden, die mehr Zugriffsrechte besitzen, als für die Tätigkeit unbedingt nötig sind. Hierdurch erhöht sich unnötig die Gefahr von Schäden durch Viren und Trojanischen Pferden. Alle Zugangskonten, die nicht mehr benötigt werden, müssen deaktiviert werden. Standard-Installationen von Betriebssystemen oder Systemprogrammen weisen in den seltensten Fällen alle Merkmale einer sicheren Installation auf. Mangelnde Anpassungen an die konkreten Sicherheitsbedürfnisse können hier ein erhebliches Risiko darstellen. Die Gefahr von Fehlkonfigurationen besteht insbesondere bei komplexen Sicherheitssystemen, wie zum Beispiel RACF unter z/os. Viele Systemfunktionen beeinflussen sich gegenseitig. Besondere Beachtung müssen Systeme finden, deren fehlerhafte Administration Einfluss auf den Schutz anderer Systeme haben (Firewalls). Status: Freigegeben Datum: Seite 19 von 146

21 Jede Modifikation von Sicherheitseinstellungen und die Erweiterung von Zugriffsrechten stellt eine potentielle Gefährdung der Gesamtsicherheit dar. Beispiele: Über das bei G 3.8 Fehlerhafte Nutzung des IT-Systems gesagte hinaus kann der Systemadministrator durch eine fehlerhafte Installation neuer oder vorhandener Software Gefährdungen schaffen. Eine fehlerhafte Administration liegt auch vor, wenn Protokollierungsmöglichkeiten nicht genutzt oder vorhandene Protokolldateien nicht ausgewertet werden, wenn zu großzügig Zugangsberechtigungen vergeben und diese dann nicht in gewissen Abständen kontrolliert werden, wenn Login-Namen oder UIDs mehr als einmal vergeben werden oder wenn vorhandene Sicherheitstools, wie z. B. unter Unix die Benutzung einer shadow-datei für die Passwörter, nicht genutzt werden. Mit dem Lebensalter von Passwörtern sinkt deren Wirksamkeit. Grund dafür ist die sich stetig erhöhende Wahrscheinlichkeit eines erfolgreichen Angriffes. Der Administration eines Firewall-Systems gilt es besondere Aufmerksamkeit zu schenken, da dieses Voraussetzung für den Schutz einer Vielzahl anderer Systeme ist. In einem z/os-system wurden die Dateien der Anwender durch RACF-Profile via Universal Access derart geschützt, dass niemand unkontrolliert darauf zugreifen konnte (UACC = NONE). Durch eine Unachtsamkeit des Administrators erlaubte ein Eintrag in der Conditional Access List des Profils allen IDs (* Eintrag) den Zugriff READ. Als Folge konnte trotz der Definition UACC=NONE jeder Anwender im System über die Conditional Access List die Dateien einsehen. G 3.16 Fehlerhafte Administration von Zugangs- und Zugriffsrechten Zugangsrechte zu einem IT-System und Zugriffsrechte auf gespeicherte Daten und IT-Anwendungen dürfen nur in dem Umfang eingeräumt werden, wie sie für die Wahrnehmung der Aufgaben erforderlich sind. Werden diese Rechte fehlerhaft administriert, so kommt es zu Betriebsstörungen, falls erforderliche Rechte nicht zugewiesen wurden, bzw. zu Sicherheitslücken, falls über die notwendigen Rechte hinaus weitere vergeben werden. Status: Freigegeben Datum: Seite 20 von 146

22 Beispiel: Durch eine fehlerhafte Administration der Zugriffsrechte hat ein Sachbearbeiter die Möglichkeit, auf die Protokolldaten zuzugreifen. Durch gezieltes Löschen einzelner Einträge ist es ihm daher möglich, seine Manipulationsversuche am Rechner zu verschleiern, da sie in der Protokolldatei nicht mehr erscheinen. G 3.27* Fehlerhafte Zeitsynchronisation Um einen reibungslosen Ablauf der Netzdienste, wie z. B. Datumsund Zeitangaben der Dateien, Revision und Protokollierung und die zeitlichen Beschränkungen bei der Anmeldung zu gewährleisten, ist eine gleiche Uhrzeit auf allen Servern von großer Bedeutung. Weiterhin ist bei der Verarbeitung digital signierte Dokumente bzw. digitaler Zertifikate die aktuelle Zeit unbedingt notwendig. Beispiele: Der Abgleich von Protokolldaten über mehrere Systeme hinweg ist nahezu unmöglich, wenn alle beteiligten Systeme nicht dieselbe Zeit verwenden. Der Einsatz neuer Zertifikate wird für eine gewisse Zeitspanne unmöglich, wenn die Systemzeit des Applikationsservers im Verhältnis zur CA, die das notbefore-attribut im Zertifikat anhand ihrer aktuellen Systemzeit setzt, nachgeht. Gleiches gilt für das notafter-attribut, was dazu führt, dass das Zertifikat länger verwendet werden kann. G 3.32* Verstoß gegen rechtliche Rahmenbedingungen beim Einsatz von kryptographischen Verfahren Beim Einsatz kryptographischer Produkte sind diverse gesetzliche Rahmenbedingungen zu beachten. In einigen Ländern dürfen beispielsweise kryptographische Verfahren nicht ohne Genehmigung eingesetzt werden. Dies kann dazu führen, dass bei der Übermittlung verschlüsselter Datensätze in solche Länder die Empfänger diese nicht lesen können, da sie die benötigten Kryptomodule nicht einsetzen können, oder sich vielleicht sogar strafbar machen. Außerdem ist in sehr vielen Ländern auch der Export von Produkten mit starker Kryptographie erheblich eingeschränkt. Hier sind insbesondere die USA zu nennen. Bei Exportrestriktionen wird häufig die Stärke von an sich starken Verschlüsselungsprodukten künstlich (durch Reduzierung der Schlüsselmannigfaltigkeit) herabgesetzt. Solche künstlich geschwächten Verfahren bieten teilweise nicht Status: Freigegeben Datum: Seite 21 von 146

23 einmal für mittleren Schutzbedarf ausreichenden Schutz. Dies gilt z.b. für aus den USA stammende PC Standardsoftware wie Internet- Browser (SSL), in denen nur eine reduzierte Schlüssellänge von 40 Bit eingesetzt wird. Teilweise erfordern die Exportregelungen aber auch, dass Teile der Schlüssel hinterlegt werden, so dass die Kryptomodule zwar im Prinzip uneingeschränkt nutzbar sind, aber für die ausländischen Nachrichtendienste eine Zugriffsmöglichkeit im Bedarfsfall bleibt. Auf der anderen Seite können solche Einschränkungen, die beim Einsatz innerhalb mancher Länder bzw. beim Export gelten, dazu verleiten, schützenswerte Daten unverschlüsselt zu lassen oder mit minderwertigen Kryptoprodukten zu schützen. Dies kann zum einen Angreifern Tür und Tor öffnen und zum anderen auch zum Verstoß gegen nationales Recht führen. So kann durch Datenschutzgesetze der Einsatz adäquater kryptographischer Verfahren zum Schutz personenbezogener Daten vorgeschrieben sein. Beispiel: Ein Anwender muss aus einem Land, für das Exportrestriktionen gelten, auf eine Webanwendung zugreifen, die starke Verschlüsselung verwendet. G 3.34* Ungeeignete Konfiguration des Managementsystems Für den sicheren Einsatz eines Netz- und/oder Systemmanagementsystems ist eine konsistente Konfiguration aller beteiligten Komponenten nötig. Zwar werden die einzelnen Komponenten in der Regel von einer zentralen Instanz aus verwaltet (Managementkonsole), das Managementsystem besteht jedoch aus vielen Einzelkomponenten, die auf die zu verwaltenden Netzkomponenten verteilt sind. Eine konsistente Konfiguration eines solchen Systems lässt sich in zwei Bereiche unterteilen: Einerseits müssen die mit Hilfe des Managementsystems eingestellten Konfigurationen der Systemkomponenten (z. B. Rechner, Router) insgesamt konsistent sein. Ein Server sollte also so konfiguriert sein, dass alle berechtigten Client- Maschinen zugreifen können, aber auch nur diese. Andererseits muss auch die Managementsoftware selbst konsistent konfiguriert werden. Wird beabsichtigt oder unbeabsichtigt die Konsistenz der Konfigurationen verletzt, so arbeiten die Komponenten nicht mehr reibungslos zusammen, was zu Sicherheitsproblemen führen kann. Status: Freigegeben Datum: Seite 22 von 146

24 Beispielsweise könnte ein Server nicht mehr zugreifbar oder Zugriffsrechte zu offen gesetzt sein. Bemerkung: Diese Gefährdung ist nur relevant, wenn die Administration und/oder Überwachung eines Application Servers über die eingebaute bzw. eine externe Managementkonsole erfolgt. G 3.36* Fehlinterpretation von Ereignissen Beim Einsatz eines Managementsystems ist es eine Aufgabe des jeweils verantwortlichen Systemadministrators, die Meldungen des Managementsystems zu analysieren und zu interpretieren, um dann geeignete Maßnahmen einzuleiten. In der Regel basieren die Meldungen des Managementsystems auf Überwachungsmechanismen, die Systemprotokolle unterschiedlichster Art automatisch nach gewissen Regeln durchsuchen. Es ist dabei nicht einfach, aus der Fülle der anfallenden Protokolldaten automatisiert Anomalien, die auf Systemfehler hindeuten, zu erkennen und entsprechende Meldungen an den Systemadministrator zu erzeugen. Darüber hinaus kann ein Fehler hier sogar unentdeckt bleiben. Die eingehenden Meldungen müssen daher immer vom Systemadministrator gesichtet und interpretiert werden, da die Meldungen (im Fehlerfall) auf Fehlersymptome und deren (automatischer) Interpretation beruhen. Ein Systemadministrator muss hier auch Fehlalarme und Falschmeldungen erkennen können. Werden Systemmeldungen vom Administrator falsch interpretiert, so führen vermeintlich korrigierende Gegenmaßnahmen u. U. zu einer Verschlimmerung der Situation. G 3.62* Fehlerhafte Konfiguration des Betriebssystems für einen Application Server Eine fehlerhafte Konfiguration des Betriebssystems für einen Application Server kann den sicheren und fehlerfreien Betrieb des Servers stören oder die Auswirkungen von Störungen verschlimmern. Einige häufige Fehler bei der Konfiguration des Betriebssystems sind: Wenn die Partitionen bzw. Filesysteme nicht groß genug angelegt werden, dann kann es zu Betriebsstörungen kommen, wenn die Dateisysteme "voll-laufen". Sind die Filesysteme auf einer einzigen Festplatte angelegt oder schlecht auf verschiedene Festplatten verteilt, so kann dies zu einer deutlich verschlechterten Performance des Servers führen. Falls auf dem Serverrechner unnötige Netzdienste laufen, so kann dadurch die Sicherheit des Gesamtsystems gefährdet Status: Freigegeben Datum: Seite 23 von 146

25 sein. Oft sind in Standardinstallationen von Betriebssystemen auch zu viele Benutzer eingerichtet oder Benutzer haben zu viele oder falsche Rechte. Sind auf dem Serverrechner Compiler oder Interpreter für Skriptsprachen installiert, so können diese von Angreifern, die sich Zugang zum Server verschafft haben, für weitere Angriffe benutzt werden. Oft erfordern bestimmte Schritte auch das Herunterladen von Dateien von Rechnern, die der Angreifer kontrolliert. Dazu benötigt der Angreifer eventuell einen Telnet-, ssh- oder ftp-client oder Download-Tools wie wget, die für den normalen Serverbetrieb nicht nötig sind. Oft sind die betriebssystemseitigen Zugriffsberechtigungen für die Programm- und Konfigurationsdateien eines Application Servers so gewählt, dass zu viele lokale Benutzer Lese- oder gar Schreibzugriff auf diese Dateien haben. Dadurch können Unbefugte Informationen über die Konfiguration des Servers erlangen, die eventuell einen Angriff erleichtern oder erst ermöglichen. Haben Unbefugte Leseberechtigung auf.die Benutzerdaten, so können die Passwörter für den Zugriff auf geschützte Bereiche des Webangebotes leicht über einen Brute-Force-Angriff geknackt werden. Die Benutzerdaten können in unterschiedlicher Form vorliegen: als Datei, in einer Datenbank, in einem Verzeichnisdienst oder im Betriebssystem (PAM). G 3.63* Fehlerhafte Konfiguration eines Application Servers Application Server sind in der Default-Konfiguration aufgrund der Vielzahl der angebotenen Dienste unsicher. Es kann erhebliche Sicherheitslücken verursachen, wenn für den Application Server eine Default-Konfiguration einfach übernommen oder nur geringfügig abgeändert wird. Bei der Konfiguration eines Application Servers können verschiedene Fehler gemacht werden. Einige häufige Fehler werden hier kurz erläutert: Application Server aktivieren im Regelfall Webanwendungen, die zur Verwaltung des Application Servers dienen. Sofern diese Webanwendungen zur Administration verwendet werden, sollten diese zur Vermeidung von unerwünschten Zugriffen, die die Gefahr einer Manipulation der Konfiguration bergen, durch eine Filterung der berechtigten Remote-Adressen sowie die Einrichtung und Nutzung von Authentisierungsverfahren beim Zugriff auf diese Webanwendungen geschützt werden. Status: Freigegeben Datum: Seite 24 von 146

26 Werden Pfade für Protokolldateien nicht angepasst, so werden diese im Unterverzeichnis logs des Installationsverzeichnisses abgelegt. Da Protokolldateien sehr schnell eine beachtliche Größe erreichen können, droht ein "Voll-Laufen" der entsprechenden Partition. Dies kann zu ernsthaften Störungen des Serverbetriebs führen. Es werden zu viele Informationen vom Application Server und/oder den aktiven Webanwendungen protokolliert. Dies kann zum einen das Voll-Laufen des Dateisystems beschleunigen und zum anderen könnten sensitive und/oder sicherheitsrelevante Informationen enthalten. Die Application Server Konfiguration bzw. die Konfiguration der Java-VM, die der Server nutzt, enthält Vorgabewerte für bestimmte Einstellungen, die Einfluss auf die Performance des Application Servers haben. Werden diese Einstellungen ohne genaue Kenntnis der Auswirkungen geändert, so kann dies die Performance bedeutend verschlechtern. Oft sind auch die Auswirkungen einer Änderung nicht sofort erkennbar. Bei der Verwendung von SSL kann durch verschiedene Konfigurationsfehler das Serverzertifikat unzureichend geschützt sein. Oft wird das Serverzertifikat nicht durch eine Passphrase geschützt, so dass ein Einbrecher, der sich eine Kopie der Zertifikatsdatei verschafft, einen "gefälschten" Server aufsetzen kann. Wird eine Passphrase verwendet, so kann es zu Problemen mit der Verfügbarkeit des Webservers kommen, da in diesem Fall ein automatischer unbeaufsichtiger Neustart des Servers nicht möglich ist, weil die Passphrase eingegeben werden muss. Ein Application Server bietet in der Default-Einstellung eine Vielzahl von Netzdiensten, die für den eigentlichen Betrieb ggf. nicht, nur lokal oder nur von bestimmten anderen IT-Systemen genutzt werden. Ungenutzte oder nicht zugangsbeschränkte Dienste sind potentieller Angriffs- und Schwachpunkte für Versuche zur Datenausspähung, Datenmanipulatuion oder andersartiger Kompromittierung der Systemsicherheit. Status: Freigegeben Datum: Seite 25 von 146

27 2.2.4 Technisches Versagen G 4.8 Bekanntwerden von Softwareschwachstellen Unter Softwareschwachstellen sollen unbeabsichtigte Programmfehler verstanden werden, die dem Anwender nicht oder noch nicht bekannt sind und ein Sicherheitsrisiko für das IT-System darstellen. Es werden ständig neue Sicherheitslücken in vorhandener, auch in weit verbreiteter oder ganz neuer Software gefunden. Beispiele: Ein Sendmail Bug unter Unix, durch den es für jeden Benutzer möglich war, unter der UID und GID von sendmail Programme auszuführen und Dateien zu verändern. Die Routine gets unter Unix. Diese wurde vom Programm fingerd zum Einlesen einer Zeile benutzt, ohne dass eine Überprüfung der Variablengrenzen vorgenommen wurde. So konnte durch einen Überlauf der Stack so verändert werden, dass eine neue Shell gestartet werden konnte. cgi-scripte, die mit WWW-Servern mitgeliefert wurden. Entfernte Anwender konnten sensible Informationen über den WWW-Server erlangen. Ein Bug in der DNS-Software ermöglichte das Fälschen zwischengespeicherter DNS-Daten. Fehlerhafte Implementationen des TCP/IP-Stacks. Diese ermöglichten das Lahmlegen ganzer Netze mittels übergroßer oder anders manipulierter Pakete. G 4.10 Komplexität der Zugangsmöglichkeiten zu vernetzten IT-Systemen Im Gegensatz zu Stand-alone-Systemen, bei denen im wesentlichen der Log-in-Prozess für die Zugangskontrolle verantwortlich ist und die somit nur durch schlechte oder fehlende Passwörter korrumpiert werden können, gibt es auf Netzrechnern sehr viele komplexe Prozesse, die die verschiedensten Arten von Zugängen erlauben. Abgesehen davon, dass alle diese Prozesse durch eine falsche oder fehlerhafte Konfiguration eine Sicherheitslücke darstellen können, ist auf Grund ihres Umfanges natürlich auch die Wahrscheinlichkeit, dass in einem dieser Prozesse ein sicherheitsrelevanten Programmierfehler ist, wesentlich größer. Status: Freigegeben Datum: Seite 26 von 146

28 G 4.26 Ausfall einer Datenbank Der Ausfall einer Datenbank zeigt sich dem Benutzer zumeist durch fehlende Reaktion des DBMS, welches die Daten der Datenbank darstellen soll. Der Ausfall kann durch geplante Ereignisse, wie z. B. Wartungsarbeiten, ausgelöst sein oder auf unvorhersehbare Ereignisse zurückgeführt werden. Zum letzteren Bereich gehören z. B. Hardware-, Software- oder Netzprobleme. Produktfehler, höhere Gewalt, Fahrlässigkeit oder Sabotage können beispielsweise Ursachen für solche Datenbankausfälle sein. Steht eine Datenbank für einen Benutzer oder eine Anwendung nicht mehr zur Verfügung, kann dies je nach Einsatzzweck und Bedeutung der Datenbank weitreichende Folgen haben. Sämtliche Anwendungen, die auf die Daten der Datenbank angewiesen sind, können nur noch eingeschränkt oder gar nicht mehr benutzt werden. Die Benutzer solcher Anwendungen können ihre Aufgaben nur noch teilweise oder gar nicht mehr wahrnehmen, falls sie diese nicht mit anderen Mitteln erfüllen können. Je nach Art der Aufgaben, die nur mittels IT-Unterstützung unter Benutzung der Datenbank ausgeführt werden können, sind unter anderem folgende Konsequenzen möglich: wirtschaftlicher Schaden, gesundheitlicher Schaden, Vertrauensverlust bei Kunden oder Partnern durch die Nichterbringung vereinbarter Leistungen, eingeschränkte oder vollständige Handlungsunfähigkeit. Beispiel: Webanwendungen innerhalb eines Application Servers verwenden ein DBMS für die Speicherung von Inhalten und/oder Accountinformationen. Beim Ausfall dieses DBMS steht die Webanwendung nicht mehr zur Verfügung. G 4.33* Schlechte oder fehlende Authentikation Authentikationsmechanismen können zur Authentikation von Benutzern oder Komponenten oder zur Bestimmung des Datenursprungs eingesetzt werden. Wenn Authentikationsmechanismen fehlen oder zu schlecht sind, besteht die Gefahr, dass Unbefugte auf IT-Systeme oder Daten Zugriff nehmen können, Status: Freigegeben Datum: Seite 27 von 146

29 die Verursacher von Problemen nicht identifiziert werden können oder die Herkunft von Daten nicht bestimmt werden kann. Sicherheitslücken entstehen bei der Benutzerauthentikation, wenn z. B. Benutzer Passwörter wählen, die einfach zu erraten sind, oder wenn sie die Passwörter nie wechseln, bei der Komponentenauthentikation, wenn z. B. nach Inbetriebnahme eines IT-Systems Default-Passwörter nicht durch individuell gewählte ersetzt werden, wenn die Passwörter, die bei vielen IT Systemen fest eingegeben werden, nie wieder geändert werden oder wenn die Passwörter nicht sicher hinterlegt werden und sich nach einem Systemabsturz herausstellt, dass das jetzt dringend benötigte Passwort vergessen wurde, bei der Wahl der Verfahren, wenn diese z. B. völlig untauglich sind oder Sicherheitslücken bekannt werden, auf die im laufenden Betrieb aber nicht reagiert wird. Application Server sind hier besonders gefährdet, da beim Aufruf von Diensten durch andere IT-Systeme deren Identitäten protokollbedingt oftmals verloren gehen und zur Bestimmung von Ausführungsrechten im Application Server nicht mehr zur Verfügung stehen. G 4.34 Ausfall eines Kryptomoduls Wird ein Kryptomodul zur Sicherung der Vertraulichkeit schützenswerter Daten eingesetzt, kommt dem fehlerfreien Funktionieren des Kryptomoduls eine besondere Bedeutung zu. Der Ausfall eines solchen im Einsatz befindlichen Kryptomoduls kann auf verschiedene Ursachen zurückzuführen sein: technischer Defekt, der die Funktionsfähigkeit beeinträchtigt, Stromausfall, in dessen Folge die flüchtig gespeicherten kryptographischen Schlüssel gelöscht werden, so dass das Kryptomodul infolgedessen nicht mehr ordnungsgemäß verschlüsseln kann, unabsichtliche oder absichtliche Zerstörung durch mechanische Einwirkung, Fehlbedienung oder ähnliches. Die Folgeschäden aufgrund des Ausfalls eines Kryptomoduls können Status: Freigegeben Datum: Seite 28 von 146

30 ebenfalls vielseitig sein. Hier sind insbesondere zu nennen: Die kryptographische Absicherung einer Datenübertragungsstrecke ist nicht mehr möglich, so dass die Vertraulichkeit temporär nicht mehr gewahrt werden kann. Dies ist insbesondere dann kritisch, wenn der Ausfall nicht bemerkt wird und durch die Fehlfunktion keine Verschlüsselung mehr stattfindet, obwohl die Anwender auf die Sicherstellung der Vertraulichkeit der Daten durch das Kryptomodul bauen. Verschlüsselte Daten können nicht mehr entschlüsselt werden, solange das erforderliche Kryptomodul nicht mehr verfügbar ist. Daraus können sich Verfügbarkeitsprobleme für IT Anwendungen ergeben, die die entschlüsselten Daten weiterverarbeiten. Arbeitet das Kryptomodul fehlerhaft, ohne dass ein vollständiger Ausfall eintritt, werden Daten unvollständig oder inkorrekt verschlüsselt. In beiden Fällen kann es bedeuten, dass im Falle der Datenübertragung der Empfänger der Daten bzw. bei lokaler Speicherung der Daten der Anwender die Daten nicht mehr korrekt entschlüsseln kann. Ohne entsprechende Datensicherungen bedeutet dies ggf. einen Totalverlust der Daten. G 4.35* Unsichere kryptographische Algorithmen Der Sicherheitszugewinn durch Einsatz kryptographischer Verfahren ist grundsätzlich von zwei Parametern abhängig: es müssen sichere kryptographische Algorithmen eingesetzt werden und die geheimen Schlüssel müssen vertraulich gehandhabt werden (zur Kompromittierung kryptographischer Schlüssel siehe G 5.83 Kompromittierung kryptographischer Schlüssel). Unsichere kryptographische Algorithmen sind dadurch gekennzeichnet, dass es einem potentiellen Angreifer mit vertretbaren Ressourcen gelingt, das eingesetzte kryptographische Verfahren zu brechen. Bei Verschlüsselungsalgorithmen bedeutet dies, dass es gelingt, aus dem verschlüsselten Text den ursprünglichen Klartext zu ermitteln, ohne dass zusätzliche Informationen bekannt sind. Dabei sind als relevante Ressourcen auf Angreiferseite z. B. die verfügbare Rechenleistung, Hilfsmittel wie Analysetools, vorhandene Kenntnisse, verfügbare Arbeitszeit, Kenntnisse über Schwachstellen etc. zu berücksichtigen. Werden also unsichere kryptographische Algorithmen eingesetzt, besteht für Angreifer die Möglichkeit, den kryptographischen Schutz zu unterlaufen. Status: Freigegeben Datum: Seite 29 von 146

31 Ob jedoch ein kryptographischer Algorithmus unsicher ist, muss jeweils im Einzelfall untersucht werden. Es gibt jedoch einige Kriterien, die auf Unsicherheiten schließen lassen: Werden bei symmetrischen Verschlüsselungsverfahren geheime Schlüssel benutzt, deren effektive Länge geringer als 60 Bit ist, so können sie heute mit moderatem Rechnereinsatz durch Ausprobieren aller potentiell möglichen Schlüssel gebrochen werden. Mit steigender Rechnerleistung ist anzunehmen, dass diese Grenze in Zukunft über 100 Bit steigen wird. Werden bei asymmetrischer Verschlüsselungs- und Signaturverfahren Algorithmen eingesetzt, deren Sicherheit auf dem Problem des Faktorisierens großer Zahlen basiert, so wird heute angenommen, dass Schlüssellängen von weniger als 1024 Bit als unsicher zu betrachten sind. Dies begründet sich in den Fortschritten bei der Entwicklung effizienter Faktorisierungsalgorithmen, die heute unter massivem Rechnereinsatz Faktorisierungen von Zahlen mit rund 500 Bit erlauben. Daneben ist die mögliche Entwicklung von opto-elektronischen Beschleunigern für einen wesentlichen Teil-Rechenschritt bei diesen Verfahren in Betracht zu ziehen, was diese wesentlich beschleunigen würde. Hashfunktionen, die eine beliebig lange Zeichenkette auf einen Hashwert mit konstanter Bitlänge abbilden, können als unsicher betrachtet werden, wenn die konstante Länge des Hashwertes geringer ist als 128 Bit, da sonst zwei Zeichenketten ermittelt werden können, die den gleichen Hashwert ergeben. Kryptographische Algorithmen, die von unerfahrenen Entwicklern entworfen wurden und nicht in der wissenschaftlichen Szene untersucht wurden, sollten als potentiell unsicher betrachtet werden, da die Entwicklung sicherer kryptographischer Algorithmen langjährige Erfahrung voraussetzt. Nicht veröffentlichte kryptographische Algorithmen, die auffällig schnell in Software ablaufen, sollten ebenfalls als potentiell unsicher betrachtet werden. Die Erfahrung zeigt, dass sichere Algorithmen meist auf komplexen mathematischen Funktionen beruhen müssen. Bei der Anwendung kryptographischer Verfahren werden häufig Zufallszahlen benötigt. Schlechte Zufallszahlengeneratoren können dazu führen, dass die damit erzeugten Werte Status: Freigegeben Datum: Seite 30 von 146

32 vorhersagbar sind. Dadurch können z. B. kryptographische Checksummen, die die Nachrichtenintegrität sicherstellen sollen, wertlos werden. Von diesen Kriterien betroffen ist beispielsweise der weltweit sehr häufig eingesetzte DES-Algorithmus zur symmetrischen Verschlüsselung. Dieser benutzt eine effektive Schlüssellänge von 56 Bit. Der so genannte Triple-DES-Algorithmus als dreifache Hintereinanderausführung mit zwei Schlüsseln hat eine effektive Schlüssellänge von 112 Bit und kann zurzeit noch als ausreichend sicher betrachtet werden. Auch betroffen ist der RSA-Algorithmus, der als asymmetrisches Verfahren auf dem Faktorisierungsproblem basiert. Wird RSA mit einer Schlüssellänge unter 768 Bit betrieben, muss davon ausgegangen werden, dass dies keine ausreichende Sicherheit bietet. Für die nächsten Jahre kann eine Schlüssellänge von mindestens 1024 Bit noch als ausreichend sicher angesehen werden. Ein häufiges Beispiel unsicherer, aber sehr schneller Algorithmen ist die so genannte XOR-Funktion, bei der konstante Werte mit dem ursprünglichen Klartext auf einfache Weise verknüpft werden. Dies ist ein hochperformanter Algorithmus, der jedoch sehr schnell gebrochen werden kann. Die XOR-Funktion kann andererseits aber der sicherste Verschlüsselungsalgorithmus überhaupt sein, wenn die zu verschlüsselnden Daten mit nicht vorhersagbaren Zufallswerten XORiert werden (One-Time-Pad). Für den Laien ist es praktisch unmöglich, festzustellen, ob ein kryptographischer Algorithmus ausreichend sicher ist. Daher sollten nur solche Algorithmen eingesetzt werden, die bekanntermaßen von Experten entwickelt wurden oder die einer langjährigen Untersuchung durch die wissenschaftliche Szene unterzogen wurden. Beispiel: Eine Webanwendung innerhalb des Application Servers verwendet unsichere Schlüssel. G 4.39 Software-Konzeptionsfehler Bei der Planung von Programmen und Protokollen können sicherheitsrelevante Konzeptionsfehler entstehen. Häufig sind diese Fehler historisch gesehen durchaus verständlich. So ist sicherlich keiner der Entwickler der im Internet verwendeten Protokolle Ende der 60er- Jahre davon ausgegangen, dass diese Protokolle einmal die Grundlage für ein weltumspannendes und kommerziell höchst bedeutendes Computer-Netz werden würden. Status: Freigegeben Datum: Seite 31 von 146

33 Beispiele: Beispiele für Konzeptionsfehler sind die offene Übertragung der Daten im Internet, so dass Daten (z. B. Passwörter) mitgelesen oder verändert werden können, oder die Möglichkeit, Pakete mit Internet-Adressen zu versenden, die einem anderen Rechner zugeteilt worden sind. Ein Spezialfall hiervon ist die so genannte FTP-Bounce-Attacke, bei der ausgenutzt wird, dass die Verbindung, die beim FTP-Protokoll für die Datenübertragung eingesetzt wird, zu einem beliebigen Rechner aufgebaut werden kann. Im ungünstigen Fall können auf diese Weise sogar Firewalls mit dynamischen Paketfiltern überwunden werden (siehe CERT Advisory 97-27). Weitere Fehler in den Internet-Protokollen sind sicherlich vorhanden und werden zukünftig publiziert werden. Ein weiteres Beispiel für einen Konzeptionsfehler ist das so genannte DNS-Spoofing (siehe auch G 5.78 DNS-Spoofing). Das Domain Name System ist der zentrale Auskunftsdienst im Internet, der die Übersetzung der leicht merkbaren Rechnernamen wie in die zugehörige Internet- Adresse ermöglicht. Bei DNS-Spoofing versucht ein Angreifer, einem Rechnernamen einen falschen Rechner zuzuweisen, so dass Auskunftsuchende fehlgeleitet werden. Ein weiteres Beispiel für einen Konzeptionsfehler ist die Möglichkeit, anonym sehr viele Werbe- s zu versenden (Mail-Spamming). Hierbei werden häufig fremde Mailserver als so genannte R er eingesetzt, so dass Gegenaktionen durch den Empfänger ins Leere laufen. Die Ursache für diese Angriffe liegt eindeutig in den mangelhaften Authentisierungsmöglichkeiten, die das Internet zur Zeit bietet. G 4.44* Ausfall eines LDAP-Servers Durch technisches Versagen aufgrund von Hardware- oder Software- Problemen kann es zum Ausfall eines LDAP-Servers oder Teilen davon kommen. Als Konsequenz davon können die im Verzeichnis gehaltenen Daten temporär nicht mehr zugänglich sein, und zwar weder für die Benutzer noch für etwaige Netzapplikationen, die auf den LDAP-Server zugreifen. Im Extremfall kann es auch zu Datenverlusten kommen. Sind Repliken der ausgefallenen Systemteile funktionsfähig vorhanden, so ist der Zugriff zwar weiterhin möglich, jedoch unter Umständen - abhängig von der Netztopologie - mit reduzierter Status: Freigegeben Datum: Seite 32 von 146

34 Performance. Beispiel: Eine Webanwendung innerhalb eines Application Servers verwendet für die Verwaltung der zugehörigen Accounts einen LDAP-Verzeichnisdienst. Die Administrationsbenutzer eines Application Servers werden aus einem LDAP-Verzeichnisdienst gelesen. Bemerkung: Diese Gefährdung ist nur relevant, wenn das Managementsystem des Application Servers oder eine der aktiven Webanwendungen einen LDAP-Verzeichnisdienst direkt oder indirekt verwendet. G 4.47 Veralten von Kryptoverfahren Die Zuverlässigkeit von Kryptosystemen ist direkt mit der fortschreitenden Entwicklung der Rechenleistung von IT-Systemen, der Entwicklung neuerer Algorithmen sowie der Forschung auf dem Gebiet der Kryptoanalyse verknüpft. Durch die Steigerung der Leistungsfähigkeit von IT-Systemen können als sicher geltende Kryptoalgorithmen bzw. Schlüssellängen zukünftig möglicherweise kompromittiert werden. Hierdurch besteht die Gefahr, dass im Falle der Kompromittierung von Kryptoverfahren oder Kryptoschlüsseln verschlüsselte Daten unbefugt entschlüsselt werden können, von Unbefugten Dokumente mit einer technisch gültigen Signatur versehen werden können, so dass dann authentische, signierte Dokumente nicht mehr von gefälschten unterschieden werden können. Beispiel: Krankenhäuser müssen die Akten ihrer Patienten auch nach Abschluss der Behandlung für einen langen Zeitraum sicher aufbewahren. Ein deutsches Krankenhaus hat dementsprechend 1980 angefangen, die elektronisch gespeicherten Krankendaten zu verschlüsseln. Das dazu verwendete Verfahren basierte auf DES mit 40 Bit langen Schlüsseln. Da sich im Krankenhaus niemand mit Verschlüsselung auskannte, wurde dieses Verfahren auch im Jahr 2001 noch eingesetzt, obwohl mittlerweile bereits im Internet Programme verfügbar Status: Freigegeben Datum: Seite 33 von 146

35 waren, um die damit verschlüsselten Daten auszulesen. Dies fiel erst bei einer Datenschutzkontrolle auf Vorsätzliche Handlungen G 5.2 Manipulation an Daten oder Software Daten oder Software können auf vielfältige Weise manipuliert werden: durch falsches Erfassen von Daten, Änderungen von Zugriffsrechten, inhaltliche Änderung von Abrechnungsdaten oder von Schriftverkehr, Änderungen in der Betriebssystemsoftware und vieles mehr. Ein Täter kann allerdings nur die Daten und Software manipulieren, auf die er Zugriff hat. Je mehr Zugriffsrechte eine Person besitzt, desto schwerwiegendere Manipulationen kann sie vornehmen. Falls die Manipulationen nicht frühzeitig erkannt werden, kann der reibungslose IT-Einsatz empfindlich gestört werden. Manipulationen an Daten oder Software können aus Rachegefühlen, um einen Schaden mutwillig zu erzeugen, zur Verschaffung persönlicher Vorteile oder zur Bereicherung vorgenommen werden. Beispiele: 1993 wurde in einem Schweizer Finanzunternehmen durch einen Mitarbeiter die Einsatzsoftware für bestimmte Finanzdienstleistungen manipuliert. Damit war es ihm möglich, sich illegal größere Geldbeträge zu verschaffen. Sehr häufig werden Kundendatenbanken von Mitarbeitern beim Verlassen der Firma kopiert. Auch das mutwillige Zerstören von Datenbanken oder die Erpressung mit der Zerstörung stellen ein Risiko dar. Archivierte Dokumente stellen meist besonders schützenswerte Daten dar. Die Manipulation solcher Dokumente ist besonders schwerwiegend, da sie unter Umständen erst nach Jahren bemerkt wird und eine Überprüfung dann oft nicht mehr möglich ist. Eine Mitarbeiterin hat sich über die Höhergruppierung ihrer Zimmergenossin in der Buchhaltung dermaßen geärgert, dass sie sich während einer kurzen Abwesenheit der Kollegin aus dem Zimmer Zugang zu deren Rechner verschafft hat. Hier hat sie durch einige Zahlenänderungen in der Monatsbilanz enormen negativen Einfluss auf das Jahresergebnis des Unter- Status: Freigegeben Datum: Seite 34 von 146

36 nehmens nehmen können. G 5.9 Unberechtigte IT-Nutzung Ohne Mechanismen zur Identifikation und Authentisierung von Benutzern ist die Kontrolle über unberechtigte IT-Nutzung praktisch nicht möglich. Selbst bei IT-Systemen mit einer Identifikations- und Authentisierungsfunktion in Form von Benutzer-ID- und Passwort- Prüfung ist eine unberechtigte Nutzung denkbar, wenn Passwort und zugehörige Benutzer-ID ausgespäht werden. Um das geheim gehaltene Passwort zu erraten, können Unbefugte innerhalb der Login-Funktion ein mögliches Passwort eingeben. Die Reaktion des IT-Systems gibt anschließend Aufschluss darüber, ob das Passwort korrekt war oder nicht. Auf diese Weise können Passwörter durch Ausprobieren erraten werden. Viel Erfolg versprechender ist jedoch die Attacke, ein sinnvolles Wort als Passwort anzunehmen und alle Benutzereinträge durchzuprobieren. Bei entsprechend großer Benutzeranzahl wird damit oft eine gültige Kombination gefunden. Falls die Identifikations- und Authentisierungsfunktion missbräuchlich nutzbar ist, so können sogar automatisch Versuche gestartet werden, indem ein Programm erstellt wird, das systematisch alle möglichen Passwörter testet. Beispiel: 1988 nutzte ein Internet-Wurm eine Schwachstelle der betroffenen Unix-Betriebssysteme aus, um gültige Passwörter zu finden, obwohl die gültigen Passwörter verschlüsselt gespeichert waren. Dazu probierte ein Programm sämtliche Eintragungen eines Wörterbuches aus, indem es sie mit der zur Verfügung stehenden Chiffrierfunktion verschlüsselte und mit den abgespeicherten verschlüsselten Passwörtern verglich. Sobald eine Übereinstimmung gefunden war, war auch ein gültiges Passwort erkannt. G 5.16 Gefährdung bei Wartungs-/Administrierungsarbeiten durch internes Personal Zum eigenen Vorteil oder aus Gefälligkeit für Kollegen könnte bei Wartungs- oder Administrationsarbeiten durch internes Personal versucht werden, Berechtigungen (z. B. Auslandsberechtigung für Telefongespräche oder Zugriff auf Internetdienste) zu ändern oder Leistungsmerkmale zu aktivieren. Dabei können durch Unkenntnis Systemabstürze verursacht werden oder weitere Sicherheitslücken Status: Freigegeben Datum: Seite 35 von 146

37 durch Konfigurationsfehler eröffnet werden. Ferner können durch unsachgemäße Handhabung der Hardwarekomponenten diese u. U. zerstört werden. Zusätzlich hat das Wartungspersonal vollen oder eingeschränkten Zugriff auf die gespeicherten Daten (lesend und schreibend) und könnte diese unbefugt weitergeben oder manipulieren. Auch die eigenhändige Steuerung oder zeitweilige Deaktivierung von Regel- oder Alarmtechnik birgt ein hohes Gefährdungspotential. Dies betrifft auch Gefahrenmeldeanlagen und Leitsysteme. Beispiele: Eine kurzfristig eingestellte Aushilfe, die die Aufgabe hatte, nicht mehr genutzte Accounts zu sperren, nutzt ihre umfassende Berechtigung, um sich urheberrechtlich geschützte Software vom zentralen Applikationsserver für private Zwecke herunterzuladen. Um das Programm auch gleich an Freunde verteilen zu können, nutzt er dienstliche CD- ROM-Brenner und Datenträger. Damit eine Kollegin auch während der Dienstzeit ihre privaten Homebanking-Transaktionen ausführen kann, wird ihr aus Gefälligkeit ein exklusiver Zugang zu ihrem Internet-Provider via ISDN zugänglich gemacht. Als sie sich zu Ostern einen Bildschirmschoner aus dem Internet herunterlädt, infiziert sie ihren PC mit einem Virus. Da der Rechner mit dem Hausnetz verbunden ist, verbreitet sich der Virus sehr schnell. Das Unternehmensnetz ist bis zur Behebung des Problems für mehrere Stunden nicht nutzbar. Einbruchmeldeanlagen haben in vielen Fällen einen integrierten Protokollierungsdrucker. Es kommt immer wieder vor, dass die Einbruchmeldeanlage zum Auswechseln der hierzu erforderlichen Papierrolle "vorsorglich" abgeschaltet wird. Beim anschließenden Wiedereinschalten besteht die Gefahr, dass das System unsachgemäß gestartet wird und sich dadurch Fehlfunktionen ergeben. G 5.17 Gefährdung bei Wartungsarbeiten durch externes Personal Ein IT-System kann bei Wartungsarbeiten auf jedwede Weise manipuliert werden. Die Gefahr besteht in erster Linie darin, dass der Eigentümer oft nicht in der Lage ist, die vorgenommenen Modifikationen nachzuvollziehen. Darüber hinaus hat der externe Wartungstechniker genau wie der interne auch üblicherweise Zugriff auf alle auf der Anlage gespeicherten Daten. Status: Freigegeben Datum: Seite 36 von 146

38 G 5.18* Systematisches Ausprobieren von Passwörtern Zu einfache Passwörter lassen sich durch systematisches Ausprobieren herausfinden. Dabei ist zwischen dem simplen Ausprobieren aller möglichen Zeichenkombinationen bis zu einer bestimmten Länge (sogenannter Brute-Force-Angriff) und dem Ausprobieren anhand einer Liste mit Zeichenkombinationen (sogenannter Wörterbuch- Angriff) zu unterscheiden. Beide Ansätze lassen sich auch kombinieren. Bei den meisten Application Server finden Passwörter Verwendung bei der Authentisierung von http-zugriffen und RMI-Calls. Ein Brute- Force-Angriff ist über systematisches Ausprobieren von http- Requests mit unterschiedlichen Credentials oder über Ausprobieren von RMI-Calls möglich. Die Zeit, die bei einem Brute-Force-Angriff zum Herausfinden eines Passworts benötigt wird, hängt ab von der Dauer einer einzelnen Passwortprüfung, der Länge des Passworts und der Zeichenzusammensetzung des Passworts (z. B. Buchstaben/Zahlen). Die Dauer einer einzelnen Passwortprüfung hängt stark vom jeweiligen System und dessen Verarbeitungs- bzw. Übertragungsgeschwindigkeit ab. Im Falle eines Angriffs spielen auch die Methode und die Technik des Angreifers eine Rolle. Länge und Zeichenzusammensetzung des Passworts lassen sich dagegen durch organisatorische Vorgaben oder sogar durch technische Maßnahmen beeinflussen. Beispiel: Mit einem gut ausgestatteten PC lassen sich derzeit bei der Standard-Passwort-Verschlüsselung von Unix bzw. Linux etwa Passwortprüfungen pro Sekunde durchführen. Bei der Standard-Passwort-Verschlüsselung von Windows NT/2000/ XP sind es sogar über Prüfungen pro Sekunde (Quelle: Der Hamburgische Datenschutzbeauftragte, 2003). Bei einem Zeichenvorrat von 26 Zeichen dauert es somit etwa 6 Tage, um ein 8 Zeichen langes Passwort unter Unix bzw. Linux zu ermitteln (Standard-Passwort-Verschlüsselung). Die Status: Freigegeben Datum: Seite 37 von 146

39 gleiche Aufgabe dauert unter Windows sogar nur etwa 9 Stunden. G 5.20 Missbrauch von Administratorrechten Eine missbräuchliche Administration liegt vor, wenn man vorsätzlich recht- oder unrechtmäßig erworbene Super-User- (root-) Privilegien ausnutzt, um dem System oder dessen Benutzern zu schaden. Beispiel: Da root auf Unix-Anlagen keinerlei Beschränkungen unterliegt, kann der Administrator unabhängig von Zugriffsrechten jede Datei lesen, verändern oder löschen. Außerdem kann er die Identität jedes Benutzers seines Systems annehmen, ohne dass dies von einem anderen Benutzer bemerkt wird, es ist ihm also z. B. möglich unter fremden Namen Mails zu verschicken oder fremde Mails zu lesen und zu löschen. G 5.21* Trojanische Pferde Ein Trojanisches Pferd, oft auch (eigentlich fälschlicherweise) kurz Trojaner genannt, ist ein Programm mit einer verdeckten, nicht dokumentierten Funktion oder Wirkung. Der Benutzer kann daher auf die Ausführung dieser Funktion keinen Einfluss nehmen - insoweit besteht eine gewisse Verwandtschaft mit Computer-Viren. Es ist jedoch keine Selbstreproduktion vorhanden. Als Träger für Trojanische Pferde lassen sich alle möglichen Anwenderprogramme benutzen. Aber auch Scriptsprachen, wie Batch-Dateien, ANSI- Steuersequenzen, REXX Execs und ISPF Command Tables bei z/os-betriebssystemen, Postscript und Ähnliches, die vom jeweiligen Betriebssystem oder Anwenderprogramm interpretiert werden, können für Trojanische Pferde missbraucht werden. Die Schadwirkung eines Trojanischen Pferdes ist umso wirkungsvoller, je mehr Rechte sein Trägerprogramm besitzt. Bemerkung: Diese Gefährdung betrifft einerseits die Installation der Serversoftware und andererseits Dateien, die von Benutzern an den Application Server geschickt werden. G 5.23 Computer-Viren Computer-Viren gehören zu den Programmen mit Schadensfunktionen. Als Schaden ist hier insbesondere der Verlust oder die Verfälschung von Daten oder Programmen sicherlich von größter Tragweite. Solche Funktionen von Programmen können sowohl Status: Freigegeben Datum: Seite 38 von 146

40 unbeabsichtigt als auch bewusst gesteuert auftreten. Die Definition eines Computer-Virus bezieht sich nicht unmittelbar auf eine möglicherweise programmierte Schadensfunktion: Ein Computer-Virus ist eine nicht selbständige Programmroutine, die sich selbst reproduziert und dadurch vom Anwender nicht kontrollierbare Manipulationen in Systembereichen, an anderen Programmen oder deren Umgebung vornimmt. (Zusätzlich können programmierte Schadensfunktionen des Virus vorhanden sein.) Die Eigenschaft der Reproduktion führte in Analogie zum biologischen Vorbild zu der Bezeichnung "Virus". Die Möglichkeiten der Manipulation sind sehr vielfältig. Besonders häufig sind das Überschreiben oder das Anlagern des Virus-Codes an andere Programme und Bereiche des Betriebssystems. Computer-Viren können im Prinzip bei allen Betriebssystemen auftreten. Die größte Bedrohung ist jedoch im Bereich der IBMkompatiblen Personalcomputer (PC) vorhanden. Bei den hier am meisten verbreiteten Betriebssystemen (MS-DOS, PC-DOS, DR DOS, NOVELL DOS etc.) werden derzeit weltweit rund Viren (einschließlich Varianten) gezählt. Spezielle Computer-Viren für die Betriebssysteme Windows 3.x, Windows NT, Windows 95, OS/2 und Unix spielen in der Praxis eine untergeordnete Rolle. Bei PC-typischer Hardware können jedoch die Festplatten dieser Rechner von DOS-Boot-Viren infiziert werden, wenn die Boot-Reihenfolge zuerst ein Booten von Diskette vorsieht. Für Apple-Computer sind ca. 100 spezielle Computer-Viren bekannt, für die es auch entsprechende Suchprogramme gibt. Arten von Computer-Viren Es werden drei Grundtypen von Computer-Viren unterschieden: Boot-Viren Datei-Viren Makro-Viren Es sind auch Misch- und Sonderformen dieser drei Typen bekannt. Weitere Unterteilungsmerkmale sind die Tarnmechanismen, mit denen die Viren oft gegen die Erkennung durch Benutzer und Suchprogramme geschützt sind. Status: Freigegeben Datum: Seite 39 von 146

41 Boot-Viren Als "Booten" bezeichnet man das Laden des Betriebssystems. Hierbei werden u. a. Programmteile ausgeführt, die zwar eigenständig sind, sich aber in sonst nicht zugänglichen und im Inhaltsverzeichnis der Disketten und Festplatten nicht sichtbaren Sektoren befinden. Boot-Viren überschreiben diese mit ihrem Programm. Der originale Inhalt wird an eine andere Stelle auf dem Datenträger verlagert und dann beim Start des Computers anschließend an den Virus-Code ausgeführt. Dadurch startet der Computer scheinbar wie gewohnt. Der Boot-Virus gelangt jedoch bereits vor dem Laden des Betriebssystems in den Arbeitsspeicher des Computers und verbleibt dort während der gesamten Betriebszeit. Er kann deshalb den Boot- Sektor jeder nicht schreibgeschützten Diskette infizieren, die während des Rechnerbetriebs benutzt wird. Boot-Viren können sich nur durch Booten oder einen Boot-Versuch mit einer infizierten Diskette auf andere Computer übertragen. Datei-Viren Die meisten Datei-Viren (auch File-Viren genannt) lagern sich an Programmdateien an. Dies geschieht jedoch so, dass beim Aufruf auch hier der Virus-Code zuerst ausgeführt wird und erst anschließend das originale Programm. Dadurch läuft das Programm anschließend scheinbar wie gewohnt und der Virus wird nicht so schnell entdeckt. Es sind jedoch auch primitivere, überschreibende Viren bekannt, die sich so an den Anfang des Wirtsprogramms setzen, so dass dieses nicht mehr fehlerfrei läuft. Datei-Viren verbreiten sich durch Aufruf eines infizierten Programms. Bei den Mischformen von Boot- und Datei-Viren haben so genannte multipartite Viren eine größere Bedeutung erlangt. Sie können sich sowohl durch Aufruf eines infizierten Programms als auch durch Booten (oder einen Boot-Versuch) von einer infizierten Diskette verbreiten. Makro-Viren Auch Makro-Viren sind in Dateien enthalten, diese infizieren jedoch nicht die Anwendungsprogramme, sondern die damit erzeugten Dateien. Betroffen sind alle Anwendungsprogramme, bei denen in die erzeugten Dateien nicht nur einzelne Steuerzeichen, sondern auch Programme und andere Objekte eingebettet werden können. Davon sind insbesondere Microsoft Word- und Excel-Dateien betroffen. Bei diesen steht eine leistungsfähige Programmiersprache für Makros zur Verfügung, die auch von weniger geschulten Benutzern leicht zur Programmierung von Viren missbraucht werden kann (siehe auch G Status: Freigegeben Datum: Seite 40 von 146

42 5.43 Makro-Viren). Makros sind Programme, mit deren Hilfe das Anwenderprogramm um zusätzliche Funktionen erweitert werden kann, die auf den Anwendungsfall zugeschnitten sind (z. B. Erzeugen einer Reinschrift aus dem Entwurf eines Textes). Diese Makros laufen erst mit dem jeweiligen Anwendungsprogramm (Microsoft Word, Excel etc.) bei der Bearbeitung des Dokuments ab, indem der Benutzer das Makro aktiviert oder das Makro automatisch gestartet wird. Wird z. B. eine Word-Datei über einen WWW-Browser empfangen, der das Dokument automatisch mit Microsoft Word öffnet, kann hierdurch ein enthaltenes Makro aktiviert werden. Da Datendateien auch häufiger als herkömmliche Programmdateien über Datenträger und vernetzte IT-Systeme verteilt werden, ist die Gefährdung durch Makro-Viren inzwischen größer als durch Boot- und Datei-Viren. Bemerkung: Diese Gefährdung betrifft einerseits die Installation der Serversoftware und andererseits Dateien, die von Benutzern an den Application Server geschickt werden. G 5.24 Wiedereinspielen von Nachrichten Angreifer zeichnen bei diesem Angriff eine Nachricht auf und spielen diese Information zu einem späteren Zeitpunkt unverändert wieder ein. Beispiele: Ein Angreifer zeichnet die Authentisierungsdaten (z. B. Benutzer-ID und Passwort) während des Anmeldevorgangs eines Benutzers auf und benutzt diese Informationen, um sich unter Vortäuschen einer falschen Identität Zugang zu einem System zu verschaffen. Um finanziellen Schaden beim Arbeitgeber (Unternehmen oder Behörde) zu verursachen, gibt ein Mitarbeiter eine genehmigte Bestellung mehrmals auf. G 5.28* Verhinderung von Diensten Ein solcher Angriff, auch "Denial of Service" genannt, zielt darauf ab, die IT-Benutzer daran zu hindern, Funktionen oder Geräte zu benutzen, die ihnen normalerweise zur Verfügung stehen. Dieser Angriff steht häufig im Zusammenhang mit verteilten Ressourcen, indem ein Angreifer diese Ressourcen so stark in Anspruch nimmt, dass andere Benutzer an der Arbeit gehindert werden. Es können z. B. die folgenden Ressourcen künstlich verknappt werden: Prozesse, Status: Freigegeben Datum: Seite 41 von 146

43 CPU-Zeit, Plattenplatz, Inodes, Verzeichnisse. Dies kann z. B. geschehen durch das Starten von beliebig vielen Programmen gleichzeitig, das mehrfache Starten von Programmen, die viel CPU-Zeit verbrauchen, das Belegen aller freien Inodes in einem Unix-System, so dass keine neuen Dateien mehr angelegt werden können, unkoordiniertes Belegen von Bandstationen in z/os-systemen, so dass Anwendungen auf freie Bandstationen warten müssen und die Online-Verarbeitung eingeschränkt ist, bewusste Falscheingabe von Passwörtern (auch Skriptgesteuert) mit dem Ziel der Sperrung aller Kennungen eines z/os-systems, das Anlegen sehr vieler kleiner Dateien in einem Verzeichnis auf einem DOS-PC, so dass in diesem Verzeichnis keine neuen Dateien mehr angelegt werden können, die gezielte Überlastung des Netzes, das Kappen von Netzverbindungen, Versand äußerst komplexe XML-Dokumente, Versand übergroßer Dokumente. G 5.71* Vertraulichkeitsverlust schützenswerter Informationen Für Informationen, die einen Schutzbedarf bezüglich ihrer Vertraulichkeit besitzen (wie Passwörter, personenbezogene Daten, firmen- oder amtsvertrauliche Informationen, Entwicklungsdaten, Protokolle), besteht die inhärente Gefahr, dass die Vertraulichkeit durch Unachtsamkeit oder auch durch vorsätzliche Handlungen beeinträchtigt wird. Dabei kann auf diese vertraulichen Informationen an unterschiedlichen Stellen zugegriffen werden, beispielsweise auf Speichermedien innerhalb von Rechnern (Festplatten), auf austauschbaren Speichermedien (Disketten, Magnetbänder), Status: Freigegeben Datum: Seite 42 von 146

44 in gedruckter Form auf Papier (Ausdrucke, Akten) und auf Übertragungswegen während der Datenübertragung. Auch die Art und Weise, wie die vertraulichen Informationen gewonnen werden, kann sehr unterschiedlich sein: Auslesen von Dateien, Kopieren von Dateien, Wiedereinspielen von Datensicherungsbeständen, Diebstahl des Datenträgers und anschließendes Auswerten, Abhören von Übertragungsleitungen und Mitlesen am Bildschirm. Je höher der Vertraulichkeitsbedarf der Informationen ist, umso größer ist auch der Anreiz für Dritte, diese Informationen zu erlangen und zu missbrauchen. Status: Freigegeben Datum: Seite 43 von 146

45 G 5.78 DNS-Spoofing Um im Internet mit einem anderen Rechner kommunizieren zu können, benötigt man dessen IP-Adresse. Diese Adresse setzt sich aus vier Zahlen zwischen 0 und 255 zusammen, also zum Beispiel Da solche Nummern nicht sehr einprägsam sind, wird einer solchen IP-Adresse fast immer ein Name zugeordnet. Das Verfahren hierzu nennt sich DNS (Domain Name System). So kann der WWW-Server des BSI sowohl unter als auch unter angesprochen werden, da der Name bei der Abfrage in die IP-Adresse umgewandelt wird. Die Datenbanken, in denen den Rechnernamen die zugehörigen IP- Adressen zugeordnet sind und den IP-Adressen entsprechende Rechnernamen, befinden sich auf so genannten Nameservern. Für die Zuordnung zwischen Namen und IP-Adressen gibt es zwei Datenbanken: In der einen wird einem Namen seine IP-Adresse zugewiesen und in der anderen einer IP-Adresse der zugehörige Name. Diese Datenbanken müssen miteinander nicht konsistent sein! Von DNS-Spoofing ist die Rede, wenn es einem Angreifer gelingt, die Zuordnung zwischen einem Rechnernamen und der zugehörigen IP- Adresse zu fälschen, d. h. dass ein Name in eine falsche IP-Adresse bzw. umgekehrt umgewandelt wird. Dadurch sind unter anderem die folgenden Angriffe möglich: r-dienste (rsh, rlogin, rsh) Diese Dienste erlauben eine Authentisierung anhand des Namens des Clients. Der Server weiß die IP-Adresse des Clients und fragt über DNS nach dessen Namen. Web-Spoofing Ein Angreifer könnte die Adresse einem falschen Rechner zuweisen, und bei Eingabe von würde dieser falsche Rechner angesprochen werden. Wie leicht es ist, DNS-Spoofing durchzuführen, hängt davon ab, wie das Netz des Angegriffenen konfiguriert ist. Da kein Rechner alle DNS-Informationen der Welt besitzen kann, ist er immer auf Informationen anderer Rechner angewiesen. Um die Häufigkeit von DNS-Abfragen zu verringern, speichern die meisten Nameserver Informationen, die sie von anderen Nameservern erhalten haben, für eine gewisse Zeit zwischen. Status: Freigegeben Datum: Seite 44 von 146

46 Ist ein Angreifer in einen Nameserver eingebrochen, kann er auch die zur Verfügung gestellten Informationen abändern. Der Fall eines direkten Einbruchs auf einen Nameserver soll hier nicht weiter betrachtet werden. Vielmehr geht es darum, prinzipielle Schwächen im DNS aufzuzeigen. Beispiele: Ein Benutzer auf dem Rechner pc.kunde.de will zuerst auf und dann auf den Konkurrenten zugreifen. Um auf zugreifen zu können, muss er erst die zugehörige IP-Adresse bei seinem Nameserver ns.kunde.de nachfragen. Dieser kennt die Adresse auch nicht und fragt beim Nameserver von ns.firmax.de nach. Dieser antwortet mit der IP-Adresse, die von ns.kunde.de an den Benutzer weitergeleitet und gespeichert wird. Befindet sich in dem Antwortpaket von ns.firma-x.de neben der IP-Adresse von auch noch eine beliebige IP-Adresse für den Rechnernamen so wird auch diese gespeichert. Versucht der Benutzer nun, auf zuzugreifen, fragt der eigene Nameserver ns.kunde.de nicht mehr bei dem Nameserver ns.firma-y.de nach, vielmehr gibt er die Informationen weiter, die ihm von ns.firma-x.de untergeschoben wurden. Firma X weiß, dass ein Benutzer mit dem Rechner pc.kunde.de auf den Konkurrenzrechner zugreifen will. Firma X verhindert dies, indem sie den Nameserver ns.kunde.de nach der Adresse fragt. Dieser muss beim Nameserver ns.firma-x.de nachfragen und bekommt wie in Beispiel 1 auch die falschen Angaben über zurück. Diese beiden Beispiele beruhen darauf, dass ein Nameserver auch zusätzliche Daten, die er gar nicht angefordert hat, akzeptiert. In neuen Versionen bestimmter Software (z. B. bind) ist dieser Fehler beseitigt, so dass diese Art von Angriffen verhindert wird. Es ist allerdings unter Verwendung von IP-Spoofing noch immer möglich, falsche DNS-Einträge zu erzeugen. Dieser Angriff ist jedoch technisch viel anspruchsvoller. G 5.84 Gefälschte Zertifikate Zertifikate dienen dazu, einen öffentlichen kryptographischen Schlüssel an eine Person zu binden. Diese Bindung des Schlüssels an den Namen der Person wird wiederum kryptographisch mittels einer digitalen Signatur einer vertrauenswürdigen dritten Stelle Status: Freigegeben Datum: Seite 45 von 146

47 abgesichert. Diese Zertifikate werden von Dritten dann verwendet, um digitale Signaturen der im Zertifikat ausgewiesenen Person zu prüfen bzw. um dieser Person Daten mit dem im Zertifikat aufgezeichneten Schlüssel verschlüsselt zuzusenden. Ist ein solches Zertifikat gefälscht, werden digitale Signaturen fälschlicherweise als korrekt geprüft und der Person im Zertifikat zugeordnet oder es werden Daten mit einem ggf. unsicheren Schlüssel verschlüsselt und versandt. Beide Angriffsmöglichkeiten können einen Täter bewegen, gefälschte Zertifikate in Umlauf zu bringen. Gefälschte Zertifikate können auf verschiedene Weise erzeugt werden: Ein Innentäter der vertrauenswürdigen Stelle erstellt mit dem eigenen Signaturschlüssel ein Zertifikat mit gefälschten Angaben. Dieses Zertifikat ist authentisch und wird bei einer Prüfung als korrekt verifiziert. Ein Täter gibt sich als eine andere Person aus und beantragt ein Zertifikat, welches auf diese andere Person ausgestellt wird, obwohl der Täter im Besitz des geheimen Schlüssels ist, der mit dem öffentlichen Schlüssel im Zertifikat korrespondiert. Ein Täter erzeugt ein Zertifikat und signiert es mit einem eigenen Schlüssel. Die Fälschung fällt nur auf, wenn das Zertifikat geprüft wird und dabei festgestellt werden kann, dass das Zertifikat von einer nichtvertrauenswürdigen Stelle ausgestellt wurde. Wenn ein Täter erst einmal ein Zertifikat mit falschen Angaben auf irgendeinem Weg erhalten hat, kann er sich gegenüber Kommunikationspartnern jederzeit als eine andere Person ausgegeben, und zwar sowohl beim Versand als auch beim Empfang von Nachrichten. G 5.85 Integritätsverlust schützenswerter Informationen Wenn Daten nicht mehr integer sind, kann es zu einer Vielzahl von Problemen kommen: Daten können im einfachsten Fall nicht mehr gelesen, also weiterverarbeitet werden. Daten können versehentlich oder vorsätzlich so verfälscht werden, dass dadurch falsche Informationen weitergegeben werden. Hierdurch können beispielsweise Überweisungen in falscher Höhe oder an den falschen Empfänger ausgelöst Status: Freigegeben Datum: Seite 46 von 146

48 werden, die Absenderangaben von s könnten manipuliert werden oder vieles mehr. Wenn verschlüsselte oder komprimierte Datensätze ihre Integrität verlieren und hier reicht die Änderung eines Bits - können sie u. U. nicht mehr entschlüsselt bzw. entpackt werden. Dasselbe gilt auch für kryptographische Schlüssel, auch hier reicht die Änderung eines Bits, damit die Schlüssel unbrauchbar werden. Dies führt dann ebenfalls dazu, dass Daten nicht mehr entschlüsselt oder auf ihre Authentizität überprüft werden können. Dokumente, die in elektronischen Archiven gespeichert sind, verlieren an Beweiskraft, wenn ihre Integrität nicht nachgewiesen werden kann. Zu Integritätsverlusten kann es auf verschiedene Weise kommen: Bei der Datenübertragung kann es zu Übertragungsfehlern kommen. Durch Computer-Viren können ganze Datenbestände verändert oder zerstört werden. Durch Fehleingaben kann es zu so nicht gewünschten Transaktionen kommen, die sogar häufig lange Zeit nicht bemerkt werden. Angreifer können versuchen, Daten für ihre Zwecke zu manipulieren, z. B. um Zugriff auf weitere IT Systeme oder Datenbestände zu erlangen. G 5.87* Web-Spoofing Bei Web-Spoofing "fälscht" ein Angreifer WWW-Server, d. h. er spiegelt durch die Gestaltung seines WWW-Servers vor, dass dieser ein bestimmter, vertrauenswürdiger WWW-Server ist. Dazu wählt er eine WWW-Adresse so, dass viele Benutzer alleine durch die Adresswahl davon ausgehen, mit einer bestimmten Institution verbunden zu sein. Selbst bei Verwendung eines richtigen Rechnernamens ist Web-Spoofing möglich, wenn ein Angreifer DNS- Spoofing verwendet (siehe G 5.78 DNS-Spoofing). Status: Freigegeben Datum: Seite 47 von 146

49 Beispiel: Unter der Adresse findet sich nicht die offizielle Homepage des weißen Hauses, sondern die eines Scherzboldes. Die XY Bank hat die WWW-Adresse Ein Angreifer kann unter oder WWW-Seiten einrichten, die auf den ersten Blick denjenigen der XY Bank ähneln. Dazu trägt er diese Adressen auf diversen Suchmaschinen ein, wobei er Stichworte wählt, nach denen XY-Kunden voraussichtlich suchen könnten. Benutzer, die diese Seiten aufrufen, werden annehmen, dass sie mit dem WWW-Server ihrer Bank kommunizieren. Daher sind sie bereit, ihre Kontonummer und PIN oder andere Zugangscodes einzugeben. Vielleicht lesen sie dort auch für sie interessante, aber gefälschte Angebote wie günstige Geldanlagen oder Immobilien und wollen diese wahrnehmen. Kann die Bank diese nicht zu diesen Konditionen oder überhaupt nicht anbieten, sind die Kunden im besten Fall nur unzufrieden, im schlechtesten Fall kann es sogar zu Rechtsstreitigkeiten kommen. Statt zu versuchen, einen vorhandenen WWW-Server zu manipulieren oder nachzuahmen, kann ein Angreifer auch ein eigenes WWW-Angebot ins Internet einbringen und dieses so gestalten, dass jeder Besucher den Eindruck hat, mit einer etablierten, seriösen Institution verbunden zu sein. Beispiele: Es könnte ein Warenangebot angepriesen werden, das nur zu dem Zweck gestaltet wurde, um Kreditkartennummern von potentiellen Käufern zu erhalten. Es hat Fälle gegeben, in denen gutgläubige Kunden bei vermeintlichen Banken zu lukrativen Konditionen Geld anlegen wollten. Diese Banken waren ihnen nur übers Internet bekannt und erst, als die erwarteten Zinsen nicht eintrafen, fiel ihnen auf, dass es sich nur um eine, inzwischen gelöschte, private WWW-Seite handelte. Bemerkung: Diese Gefährdung ist nur relevant, wenn auf den Application Server über öffentliche Netze zugegriffen wird. Status: Freigegeben Datum: Seite 48 von 146

50 G 5.88* Missbrauch aktiver Inhalte Während des Surfens im Internet können WWW-Seiten mit aktiven Inhalten auf den Anwenderrechner geladen werden (z. B. ActiveX oder Java-Applets). Diese Software kann gezielt zu dem Zweck erstellt worden sein, dass sie vertrauliche Daten des Benutzers ausspioniert und anschließend so ausgespähte Informationen an den Angreifer über das Internet zurückgibt. Ein Java-fähiger Browser erlaubt es dem Benutzer, Java-Applets vom Netz zu laden und auszuführen, ohne dass der Benutzer das Applet erkannt hat. Dies stellt Java-Benutzer vor bedeutende Sicherheitsrisiken: Ein Java-Applet kann Standardnetzprotokolle (wie zum Beispiel SMTP) benutzen, um Daten vom Rechner des Benutzers aus zu verschicken. Ein Java-Applet kann das Java-System angreifen, indem es dessen Speicher korrumpiert, oder es kann das darunterliegende Betriebssystem angreifen, indem es Dateien fälscht oder wichtige Prozesse beendet. Ein Java-Applet kann den gesamten Speicher des Systems belegen oder hochprioritäre Nachrichten erzeugen. Der Verfügbarkeitsangriff ist auch bei der korrekten Interpretation des Java-Sicherheitsmodells möglich. Bei ActiveX ist anders als bei Java die Funktionsvielfalt kaum eingeschränkt: Bis hin zur Formatierung der Festplatte kann ein ActiveX-Programm alle Befehle enthalten. Diese kleinen ausführbaren Codes nennt man Controls. Die meist zur Illustration oder Unterhaltung verteilten Controls können auch böswillige Elemente besitzen, die dann Zugriff auf den Datenspeicher des Anwenderrechners haben oder andere Programme - für den Benutzer unbemerkt - fernsteuern. ActiveX-Controls können die Festplatte löschen, einen Virus oder ein Trojanisches Pferd enthalten oder die Festplatte nach bestimmten Informationen durchsuchen. All dies kann passieren, ohne dass der Nutzer bzw. Betrachter des Controls dies bemerkt. Während der Betrachter ein durch Controls übertragenes Spiel ausführt, kann im Hintergrund dieses Control die nach bestimmten Informationen durchsuchen. Bei entsprechender Voreinstellung seines WWW-Browsers kann ein Benutzer zwar dafür sorgen, dass nur digital signierte ActiveX- Controls ausgeführt werden. Eine solche digitale Signatur beweist allerdings nur, dass der Hersteller des ActiveX-Controls bei einer Status: Freigegeben Datum: Seite 49 von 146

51 Zertifizierungsstelle bekannt ist und dass das von diesem Hersteller bereitgestellte Control unverändert geladen wurde. Hierdurch wird nichts über die Funktionsweise oder Schadensfreiheit eines solchen Controls ausgesagt und auch keine Gewähr dafür übernommen. Bemerkung: Diese Gefährdung ist nur relevant, wenn eine oder mehrere Webanwendungen, die innerhalb des Application Servers laufen, eine interaktive Schnittstelle bieten. G 5.89* Hijacking von Netz-Verbindungen Weitaus kritischer als das Abhören einer Verbindung ist das Übernehmen einer Verbindung. Hierbei werden Pakete in das Netz eingeschleust, die entweder zum Abbruch oder Blockieren des Clients führen. Der Serverprozess kann daraufhin nicht erkennen, dass ein anderes Programm an die Stelle des Original-Clients getreten ist. Bei dieser Übernahme einer bestehenden Verbindung kann der Angreifer nach erfolgreicher Authentisierung einer berechtigten Person beliebige Aktionen in deren Namen ausüben. Bemerkung: Diese Gefährdung ist nur relevant, wenn auf den Application Server über öffentliche Netze zugegriffen wird. G 5.109* Ausnutzen systemspezifischer Schwachstellen beim Application Server Wie jede Software ist auch der Application Server nicht frei von Schwachstellen und Programmierfehlern. Systemspezifische Schwachstellen beim Application Server finden sich entweder im eigentlichen Server, in der verwendeten Java VM, in den Webanwendungen für die Verwaltung (manage bzw. admin) oder in den Modulen zur Anbindung an den Apache Webserver (mod_jk) bzw. für die Verwendung von SSL. Durch Ausnutzen von Schwachstellen (beispielsweise Buffer- Overflows) im Application Server, in der Java VM oder in Webanwendungen können Angreifer im Extremfall den Serverrechner kompromittieren. Da der Application Server meist unter einem nicht privilegierten Account läuft, ist zwar das direkte Erlangen von rootoder Administratorrechten meist nicht möglich, hat ein Angreifer aber bereits einen Zugang zum Serverrechner selbst erlangt, so kann er durch Ausnutzen lokaler Schwachstellen des Betriebssystems oder anderer installierter Programme oft recht leicht erweiterte Berechtigungen erlangen. Selbst wenn für eine Schwachstelle kein Exploit bekannt ist, der dadurch, dass ein Angreifer eigenen Code auf dem Serverrechner ausführen kann, zu einer Kompromittierung des Rechners führt, Status: Freigegeben Datum: Seite 50 von 146

52 können Buffer-Overflows und ähnliche Schwachstellen dazu ausgenutzt werden, den Application Server zum Absturz zu bringen und so einen Denial-of-Service herbei zu führen. Schwachstellen im Application Server oder in Erweiterungsmodulen können auch dazu führen, dass Zugriffsbeschränkungen umgangen werden können und so eventuell vertrauliche Dateien an unberechtigte Besucher ausgeliefert werden. Außerdem ist es möglich, dass durch eine Sicherheitslücke Konfigurationsinformationen (wie Installationspfade oder Systempfade) nach außen gelangen. Solche Informationen können Angriffe erleichtern, da die Angreifer in einem solchen Fall keine Pfade durchprobieren müssen. G SQL-Injection Unter SQL-Injection versteht man das Einschleusen (injizieren) schädlicher oder unerwünschter Datenbankbefehle in die Datenbankabfragen einer Applikation. Ermöglicht wird diese Technik durch eine unzureichende Prüfung bzw. Maskierung der Eingaben innerhalb der Applikation. Die in Eingabefelder oder Parameter der Applikation eingetragenen Daten werden benutzt, um dynamisch Anfragen an die dahinterliegende Datenbank zu generieren. Ein Angreifer verwendet bestimmte Sonderzeichen in seinen Eingaben, um die dynamisch erzeugte Datenbankanfrage zu manipulieren und so seine eigenen Befehle an die Datenbank zu schicken. Dieses Vorgehen eröffnet einem Angreifer vielfältige Möglichkeiten: unberechtigter Zugriff auf Daten, Manipulation von Daten, Gewinnung von Informationen durch Auslösen von Fehlermeldungen, Ausführen von Betriebsystembefehlen, Kontrolle über die Datenbank, Kontrolle über den Server. Die Gefährdung richtet sich grundsätzlich sowohl gegen Web- Applikationen als auch gegen eigenständige Applikationen. Web- Applikationen sind hier jedoch besonders betroffen, da sie häufig nicht von einer geschlossenen Benutzergruppe verwendet werden. Dadurch erhöht sich die Anzahl der potentiellen Angreifer. Außerdem bleibt der Angreifer anonym, da er in keiner lokalen Benutzerver- Status: Freigegeben Datum: Seite 51 von 146

53 waltung registriert ist. Bemerkung: Diese Gefährdung ist nur relevant, wenn das Managementsystem des Application Servers oder eine der aktiven Webanwendungen ein DBMS verwendet. G Unautorisierte Benutzung web-basierter Administrationswerkzeuge Die Administration mit Webbrowser-basierten Werkzeugen hat stark an Bedeutung gewonnen. Einer der entscheidenden Vorteile für das technisch verantwortliche Personal ist die Unabhängigkeit von der Betriebssystem-Plattform des zu betreuenden IT-Systems dem Standort des zu betreuenden IT-Systems. Allen Werkzeugen gemein ist, dass sie kritische Anmeldedaten verwenden. Sie sind auf gängige für das Internet standardisierte Authentisierungsmethoden angewiesen, um technischem Personal autorisierten Zugriff auf die kritischen lokalen Systeme zu gewähren. Viele Administrationswerkzeuge besitzen zusätzlich eigene Authentisierungsmechanismen oder bedienen sich lokaler, teils nicht standardisierter Authentisierungs- und Sicherheitsmechanismen. Es besteht die Gefahr der Kompromittierung durch nicht autorisierte Benutzer. Eine hohe Gefährdung entsteht, wenn die IT-Sicherheitsrichtlinie für die Authentisierung im Netz bzw. deren Umsetzung im betrachteten IT-Verbund durch ungeeignete Authentisierungsverfahren für Webbasierte Administrationswerkzeuge unterlaufen wird. Die häufigsten Ursachen dafür sind: die Wahl einer falschen oder veralteten Authentisierungsmethode, weil das jeweilige Werkzeug keine stärkere Authentisierung unterstützt oder weil andere beteiligte IT-Systeme (z. B. Sicherheitsgateways) das favorisierte Protokoll nicht unterstützen die ungeeignete Umsetzung bzw. Übernahme der Webbasierten Authentisierung in das lokale Authentisierungssystem Eine Gefährdung kann z. B. entstehen, wenn zum Zwecke der Nutzung Web-basierter Administrationshilfen die Windowskomponente Internetinformationsdienst aktiviert wird, ohne diese entsprechend den Empfehlungen zu konfigurieren. Eine Gefahr könnte dann darin bestehen, dass in der Standardkonfiguration nur schwächere Authentisierungsverfahren aktiviert sind. Es ist darauf Status: Freigegeben Datum: Seite 52 von 146

54 hinzuweisen, dass eine mangelhafte Konfiguration ein großes Risiko für alle auf dem Markt befindlichen Lösungen zur Web-basierten Administration darstellt. 2.3 Maßnahmen Zur Abwehr der genannten Gefährdungen sind folgende Maßnahmen zu treffen: Planung und Konzeption M 2.11 Regelung des Passwortgebrauchs Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement Verantwortlich für Umsetzung: IT-Sicherheitsmanagement, Benutzer Werden in einem IT-System Passwörter zur Authentisierung verwendet, so ist die Sicherheit der Zugangs- und Zugriffsrechteverwaltung des Systems entscheidend davon abhängig, dass das Passwort korrekt gebraucht wird. Dafür ist es empfehlenswert, eine Regelung zum Passwortgebrauch einzuführen und den IT-Benutzer diesbezüglich zu unterweisen. Vorgaben für die Passwortgestaltung müssen immer einen praktikablen Kompromiss zwischen folgenden Sicherheitszielen darstellen: 1. Die Zeichenzusammensetzung des Passwortes muss so komplex sein, dass es nicht leicht zu erraten ist. 2. Die Anzahl der möglichen Passwörter im vorgegebenen Schema muss so groß sein, dass es nicht in kurzer Zeit durch einfaches Ausprobieren ermittelt werden kann. 3. Das Passwort darf nicht zu kompliziert sein, damit der Besitzer mit vertretbarem Aufwand in der Lage ist, es auswendig zu lernen. Folgende Regeln zum Passwortgebrauch sollten deshalb beachtet werden: Das Passwort darf nicht leicht zu erraten sein. Namen, Kfz- Kennzeichen, Geburtsdatum usw. dürfen deshalb nicht als Status: Freigegeben Datum: Seite 53 von 146

55 Passwörter gewählt werden. Innerhalb des Passwortes sollte mindestens ein Zeichen verwendet werden, das kein Buchstabe ist (Sonderzeichen oder Zahl). Wenn für das Passwort alphanumerische Zeichen gewählt werden können, sollte es mindestens 8 Zeichen lang sein. Wenn für das Passwort nur Ziffern zur Verfügung stehen, sollte es mindestens 6 Zeichen lang sein und das Authentisierungssystem sollte den Zugang nach wenigen Fehlversuchen sperren (für eine bestimmte Zeitspanne oder dauerhaft). Es muss getestet werden, wie viele Stellen des Passwortes vom Rechner wirklich überprüft werden. Voreingestellte Passwörter (z. B. des Herstellers bei Auslieferung von Systemen) müssen durch individuelle Passwörter ersetzt werden. Passwörter dürfen nicht auf programmierbaren Funktionstasten gespeichert werden. Das Passwort muss geheim gehalten werden und sollte nur dem Benutzer persönlich bekannt sein. Das Passwort sollte allenfalls für die Hinterlegung schriftlich fixiert werden, wobei es in diesem Fall in einem verschlossenen Umschlag sicher aufbewahrt werden muss. Wird es darüber hinaus aufgeschrieben, ist das Passwort zumindest so sicher wie eine Scheckkarte oder ein Geldschein aufzubewahren (siehe M 2.22 Hinterlegen des Passwortes). Das Passwort muss regelmäßig gewechselt werden, z. B. alle 90 Tage. Ein Passwortwechsel ist durchzuführen, wenn das Passwort unautorisierten Personen bekannt geworden ist oder der Verdacht besteht. Alte Passwörter sollten nach einem Passwortwechsel nicht mehr gebraucht werden. Die Eingabe des Passwortes sollte unbeobachtet stattfinden. Status: Freigegeben Datum: Seite 54 von 146

56 Falls IT-technisch möglich, sollten folgende Randbedingungen eingehalten werden: Die Wahl von Trivialpasswörtern (z. B. "BBBBBBBB", "123456") sollte verhindert werden. Jeder Benutzer muss sein eigenes Passwort jederzeit ändern können. Für die Erstanmeldung neuer Benutzer sollten Einmalpasswörter vergeben werden, also Passwörter, die nach einmaligem Gebrauch gewechselt werden müssen. In Netzen, in denen Passwörter unverschlüsselt übertragen werden, empfiehlt sich die dauerhafte Verwendung von Einmalpasswörtern (siehe M 5.34 Einsatz von Einmalpasswörtern). Nach dreifacher fehlerhafter Passworteingabe sollte das Authentisierungssystem den Zugang sperren (für eine bestimmte Zeitspanne oder dauerhaft). Bei der Authentisierung in vernetzten Systemen sollten Passwörter selbst im Intranet nicht unverschlüsselt übertragen werden. Erfolgt die Authentisierung über ein ungesichertes Netz hinweg, so dürfen Passwörter keinesfalls unverschlüsselt übertragen werden. Bei der Eingabe sollte das Passwort nicht auf dem Bildschirm angezeigt werden. Die Passwörter müssen im System zugriffssicher gespeichert werden, z. B. mittels Einweg-Verschlüsselung (Hashfunktionen). Der Passwortwechsel sollte vom System regelmäßig initiiert werden. Die Wiederholung alter Passwörter beim Passwortwechsel sollte vom IT-System verhindert werden (Passworthistorie). Ergänzende Kontrollfragen: Sind die Benutzer über den korrekten Umgang mit Passwörtern unterrichtet worden? Wird die Passwort-Güte kontrolliert? Status: Freigegeben Datum: Seite 55 von 146

57 Wird der Passwort-Wechsel erzwungen? Ist jeder Benutzer im Netz mit einem Passwort ausgestattet? Bemerkung: Diese Regelungen sind, soweit sinnvoll, auch auf solche Passwörter anzuwenden, die als Credentials bei der Authentisierung von Dienstaufrufen im Application Server Verwendung finden. M 2.164* Auswahl eines geeigneten kryptographischen Verfahrens Verantwortlich für Initiierung: Verantwortlich für Umsetzung: IT-Sicherheitsmanagement IT-Sicherheitsmanagement Die Auswahl eines kryptographischen Verfahrens zerfällt in die beiden Teilaufgaben Auswahl des kryptographischen Algorithmus und Auswahl einer technischen Realisierung. Bevor der Anwender sich auf bestimmte Verfahren festlegt, sollte er genaue Vorstellungen davon haben, welche Anforderungen er an Vertraulichkeit und Authentizität der bearbeiteten Daten in jedem "Punkt" seines informationsverarbeitenden Systems stellt. Auswahl von kryptographischen Algorithmen Bei der Auswahl von kryptographischen Algorithmen ist zunächst zu klären, welche Art kryptographischer Verfahren benötigt werden, also symmetrische, asymmetrische oder hybride Verfahren, und dann sind geeignete Algorithmen, also solche mit entsprechender Mechanismenstärke auszuwählen. Verschlüsselungsverfahren - symmetrische Verschlüsselung: Die Vor- bzw. Nachteile symmetrischer Verfahren sind in M 3.23 Einführung in kryptographische Grundbegriffe beschrieben. Geeignete Algorithmen sind z. B. Triple-DES, IDEA, AES, RC 5, wobei die Schlüssellänge mindestens 100 Bit sein sollte. - asymmetrische Verschlüsselung: Die Vor- bzw. Nachteile asymmetrischer Verfahren sind ebenfalls in M 3.23 Einführung in kryptographische Grundbegriffe beschrieben. Geeignete Algorithmen sind z. B. RSA oder auf Elliptischen Kurven basierende Status: Freigegeben Datum: Seite 56 von 146

58 Verschlüsselungsverfahren (zur Schlüssellänge siehe unten). Authentisierungsverfahren - Nachrichtenauthentisierung Zur Nachrichtenauthentisierung können verschiedene Verfahren eingesetzt werden, etwa ein Message Authentication Code (MAC) oder ein digitales Signaturverfahren. Der Einsatz eines MACs ist von Vorteil, wenn extrem hohe Durchsatzraten gefordert sind (oder nur eine geringe Rechenkapazität zur Verfügung steht) und das Risiko der Schlüsseloffenlegung auf beiden Seiten sehr gering ist. Der Einsatz eines digitalen Signaturverfahrens ist von Vorteil, wenn das Risiko der (Signatur-) Schlüsseloffenlegung auf einer Seite wesentlich höher ist als auf der anderen Seite; und in aller Regel geboten, wenn Verbindlichkeitsdienste verlangt werden. Es sei noch einmal bemerkt, dass für den Dienst Verbindlichkeit eine Infrastruktur vertrauenswürdiger Dritter vorhanden sein muss. Der bekannteste MAC-Algorithmus ist die Verschlüsselung einer Nachricht mit DES oder einem anderen Block-Chiffrierverfahren im CBCoder CFB-Mode. Dabei wird als MAC der letzte verschlüsselte Block an die Nachricht angehängt. Solche Varianten sind z. B. in den Normen ANSI X9.9, ANSI X9.19, ISO oder ISO 9797 spezifiziert. In neuerer Zeit gab es weitere Vorschläge für Blockchiffren-basierte MAC-Konstruktionen, hier ist wohl OMAC1 der aussichtsreichste Kandidat. Daneben gibt es dedizierte MAC-Konstruktionen auf Basis von Hashfunktionen, hier ist an erster Stelle der weithin akzeptierte und verwendete HMAC aus dem RFC 2104 zu nennen. Geeignete Algorithmen für Digitale Signaturen sind z. B. RSA, DSA (Digital Signature Algorithm) oder auf elliptischen Kurven basierende DSA-Varianten, z. B. ISO/IEC , IEEE-Standard P1363, Abschnitt ("Nyberg-Rueppel Version"), IEEE-Standard P1363, Abschnitt ("DSA Version"). - Authentisierung von Benutzern oder Komponenten Ein einfaches Verfahren zur Authentisierung ist eine Passwortabfrage. Werden die Passwörter dabei aber unverschlüsselt über ein Netz übertragen, können diese verhältnismäßig einfach mitgelesen werden. Daher sollten hier bessere Verfahren verwendet werden. Geeignete Verfahren sind beispielsweise - Einmalpasswörter (siehe auch M 5.34 Einsatz von Einmalpasswörtern), die software- oder hardwaregestützt erzeugt werden können. Hierbei sind die hardwarebasierten Authentisierungsmethoden Status: Freigegeben Datum: Seite 57 von 146

59 vorzuziehen, da sie einen geringeren organisatorischen Aufwand und höhere Sicherheit bieten. - Die Authentisierung mittels PAP oder besser CHAP, die bei der Nutzung des Point-to-Point-Protocol eingesetzt werden (siehe auch M 5.50 Authentisierung mittels PAP/CHAP). - Die Authentisierung mittels CLIP/COLP, die bei der Kommunikation über ISDN eingesetzt wird (siehe auch M 5.48 Authentisierung mittels CLIP/COLP). - Ein weiteres bekanntes Verfahren ist das Authentikationsprotokoll Kerberos, das am MIT (Massachusetts Institute of Technology) entwickelt wurde. Es wird in Netzen zur gegenseitigen Authentisierung von Benutzer/Client und Servern eingesetzt. Die zentrale Autorität bei Kerberos ist der Ticket-Granting-Server, der Tickets ausstellt, mit denen sich Clients und Server gegenseitig authentisieren können. Mit Hilfe dieser Tickets können Benutzer sich nach einmaliger Authentikation Sitzungsschlüssel für die verschiedensten Dienste anfordern. Hashverfahren Geeignete Algorithmen sind z. B. SHA-1 und RIPEMD-160, daneben auch die neueren SHA-2 Versionen (SHA-224, SHA-256, SHA-384, SHA-512) die für Anwendungen mit höheren Anforderungen an die Kollisionresistenz ausgelegt sind. Auswahlkriterien - Mechanismenstärke / Schlüssellänge Ein wesentliches Kriterium für die Auswahl von kryptographischen Verfahren ist ihre Mechanismenstärke. Bei symmetrischen Verfahren sollte insbesondere die Schlüssellänge ausreichend groß sein. Je größer die verwendete Schlüssellänge bei einem kryptographischen Verfahren ist, desto länger dauert es, ihn z. B. durch eine Brute-Force-Attacke zu berechnen. Andererseits werden die Verfahren bei der Verwendung längerer Schlüssel langsamer, so dass immer zu überlegen ist, welche Schlüssellänge unter Nutzen-/Leistungsgesichtspunkten angemessen ist. Als Faustregel für gute Verfahren (Triple-DES, IDEA, RC5, AES,...) und mittleren Schutzbedarf gilt derzeit, dass die eingesetzten Schlüssel mindestens 100 Bit lang sein sollten. Bei Verwendung von Blockchiffren sollten größere, strukturierte Datenmengen nicht im ECB-Modus verschlüsselt werden. Stattdessen sollten dazu der CBC-Modus oder der CFB-Modus verwendet werden. Mindestens eine dieser Betriebsarten sollte daher implementiert sein. Status: Freigegeben Datum: Seite 58 von 146

60 Bei asymmetrischen Verfahren sollte die Mechanismenstärke so gewählt werden, dass die Lösung der zu Grunde liegenden mathematischen Probleme einen unvertretbar großen bzw. praktisch unmöglichen Rechenaufwand erfordert (die zu wählende Mechanismenstärke hängt daher vom gegenwärtigen Stand der Algorithmik und der Rechentechnik ab). Gegenwärtig kann man davon ausgehen, dass man mit - Modullängen von 1024 Bit bei RSA bzw. - Untergruppenordnungen in der Größe von 160 Bit bei ElGamal-Verfahren auf einer geeigneten elliptischen Kurve "auf der sicheren Seite" ist. Es sollten keine "unbekannten" Algorithmen verwendet werden, d. h. es sollten Algorithmen eingesetzt werden, die veröffentlicht sind, die von einem breiten Fachpublikum intensiv untersucht worden sind und von denen keine Sicherheitslücken bekannt sind. Häufig bieten Hersteller Sicherheitsprodukte an mit neuen Algorithmen, die "noch viel sicherer und noch viel schneller" sein sollen als andere Algorithmen. Aber vor der Verwendung von unbekannten Algorithmen aus Quellen, deren kryptographische Kompetenz nicht ausreichend nachgewiesen ist, kann nur gewarnt werden. - Symmetrische oder hybride Verfahren? Aus Performancegründen werden für Verschlüsselungszwecke keine reinen Public-Key-Implementierungen eingesetzt. Alle gängigen Implementierungen von Public-Key-Kryptographie nutzen hybride Verfahren (siehe auch M 3.23 Einführung in kryptographische Grundbegriffe). In Anwendungen mit großen oder offenen Nutzergruppen empfiehlt sich meist die Verwendung eines hybriden Verfahrens (wegen der Vorzüge für das Schlüsselmanagement). Bei kleinen, geschlossenen Nutzergruppen (insbesondere natürlich bei einem einzelnen Benutzer) kann man sich auf symmetrische Verfahren beschränken. Bei Einsatz hybrider Verfahren ist es sinnvoll, die Stärken des symmetrischen und des asymmetrischen Anteils aufeinander abzustimmen. Da mit dem asymmetrischen Verfahren vor einem Schlüsselwechsel in der Regel viele Schlüssel für das symmetrische Verfahren überschlüsselt werden, sollte der asymmetrische Algorithmus eher etwas stärker ausgelegt werden. - Realisierbarkeit von technischen Anforderungen Die Chiffrieralgorithmen müssen so beschaffen sein, dass die Status: Freigegeben Datum: Seite 59 von 146

61 technischen Anforderungen, insbesondere die geforderte Performance, durch eine geeignete Implementation erfüllt werden können. Hierunter fallen Anforderungen an die Fehlerfortpflanzung (z. B. falls über stark rauschende Kanäle gesendet wird), aber auch Anforderungen an Synchronisationsoverhead und Zeitverzögerung (z. B. falls "Echtzeit"- Verschlüsselung von großen Datenmengen erfordert wird). - Andere Einflussfaktoren Manche kryptographische Algorithmen (z. B. IDEA) sind patentiert, für ihren Einsatz in kommerziellen Anwendungen (wozu auch der behördliche Bereich zählt) sind evtl. Lizenzgebühren zu entrichten. Veröffentlichungen der Bundesnetzagentur Die Bundesnetzagentur veröffentlicht regelmäßig im Bundesanzeiger eine Übersicht über die Algorithmen, die zur Erzeugung von Signaturschlüsseln, zum Hashen zu signierender Daten oder zur Erzeugung und Prüfung qualifizierter elektronischer Signaturen als geeignet angesehen werden können. Diese Veröffentlichungen können auch vom Webserver der Bundesnetzagentur (http://www.bundesnetzagentur.de) herunter geladen werden. Sie können zusätzliche Hinweise zur Auswahl liefern. Ergänzende Kontrollfragen: - Sind die kryptografischen Verfahren, die von Webanwendungen eingesetzt werden, bekannt? - Wird die Sicherheit der verwendeten kryptografischen Verfahren regelmäßig hinterfragt? - Ist bekannt, wie bei den Webanwendungen das krptografische Verfahren gewechselt werden kann? M 2.172* Entwicklung eines Konzeptes für die WWW-Nutzung Verantwortlich für Initiierung: Behörden-/Unternehmensleitung, IT- Sicherheitsmanagement Verantwortlich für Umsetzung: Leiter IT, Administrator Bevor ein Webangebot eingerichtet wird, muss zunächst in einem Konzept dargestellt werden, welche Informationen und Dienste angeboten werden sollen. Das Konzept sollte mindestens einen allgemeinen und einen organisatorischen Teil enthalten: Status: Freigegeben Datum: Seite 60 von 146

62 Ziele und Inhalte festlegen Im allgemeinen Teil sollte beschrieben werden, welche Ziele die Organisation mit dem Webangebot verfolgt, welches die Zielgruppen des Webangebots sind und welche Informationen oder Dienstleistungen in dem Webangebot zur Verfügung gestellt werden sollen. Erscheinungsbild und Redaktion Im organisatorischen Teil sollte eine grobe Übersicht darüber gegeben werden, wer in der Organisation verantwortlich ist für die Bereitstellung und Aktualisierung der Informationen und die Ausarbeitung und Pflege des optischen Erscheinungsbildes des Webangebots (Webdesign). Technik Im organisatorischen Teil des WWW-Konzepts sollte auch festgelegt werden, wer für die technischen Aspekte des Betriebs des Webservers verantwortlich ist. Das Konzept für das Webangebot sollte regelmäßig auf Aktualität überprüft werden. Bei Änderungen in den Zielen oder Strategien der Organisation muss geprüft werden, welche Auswirkungen diese auf das WWW-Konzept haben. Bei der Entwicklung des Konzeptes sollten folgende Aspekte berücksichtigt werden: Verwendungszweck beeinflusst Sicherheitsanforderungen Ein Webangebot kann als rein interner Informationsdienst eingesetzt werden, als Mittelpunkt eines Intranets, oder als öffentliches Angebot im Internet, das verschiedene Dienste anbietet. Je nach Art der geplanten Ausgestaltung unterscheiden sich auch die Sicherheitsanforderungen, die an den Webserver gestellt werden müssen. In einer kleinen Organisation, in der ein Webserver als Intranet-Server ohne kritische Anwendungen betrieben wird, sehen die Anforderungen ganz anders aus als für einen Webserver, der ans Internet angeschlossen werden soll und vielleicht sogar Daten enthält, die nicht jeder abrufen können soll. Status: Freigegeben Datum: Seite 61 von 146

63 Firewall Wenn sowohl im Intranet als auch im Internet WWW-Dienste angeboten werden sollen, empfiehlt es sich, hierfür zwei getrennte Systeme einzusetzen: einen Intranet-Webserver und einen Internet-Webserver. Wenn der Internet-Webserver auch mit dem internen Netz verbunden werden soll, muss der Übergang zum internen Netz durch eine Firewall geschützt werden, siehe Baustein B Sicherheitsgateway (Firewall). Wenn vorgesehen ist, dass Teile der Inhalte des Webservers aus einer Datenbank kommen sollen, muss auch die Verbindung zur Datenbank in das Firewall-Konzept für den Webserver einbezogen werden. Was bei der Anordnung von Informationsservern zu beachten ist, ist in M 2.77 Integration von Servern in das Sicherheitsgateway beschrieben. Bei der Erarbeitung des Konzepts für das Webangebot sollte zumindest grob festgelegt werden, wie die Anbindung ans Internet geregelt ist und welche Arten von Verbindungen zum internen Netz benötigt werden. Der Anschluss ans Internet darf erst dann erfolgen, wenn überprüft worden ist, dass mit dem gewählten WWW-Konzept sowie den personellen und organisatorischen Randbedingungen alle Risiken beherrscht werden können. Outsourcing in Betracht ziehen Ein Webserver für die Präsenz einer Organisation im Internet muss nicht zwangsläufig von dieser selbst betrieben werden. Wenn die Betriebskosten oder der Administrationsaufwand zu hoch oder die Restrisiken zu unkalkulierbar erscheinen, können auch die entsprechenden Angebote von Internet Service Providern oder anderen Dienstleistern in Anspruch genommen werden, einen Webserver durch diese betreiben zu lassen. In diesem Fall muss der Baustein B 1.11 Outsourcing berücksichtigt werden. Ergänzende Kontrollfragen: Existiert ein Konzept für das Webangebot? Wird das Konzept regelmäßig überprüft und nötigenfalls angepasst? Ist die Zielgruppe bekannt bzw. wird auch aus dem Ausland auf das Angebot zugegriffen? Bemerkung: Wenn die Webanwendung nur Webservices und keine interaktive Bedienoberfläche anbietet, können die Punkte Inhalt, Erscheinungsbild und Redaktion vernachlässigt werden. Status: Freigegeben Datum: Seite 62 von 146

64 M 2.173* Festlegung einer Application-Server-Sicherheitsstrategie Verantwortlich für Initiierung: Behörden-/Unternehmensleitung, IT- Sicherheitsmanagement Verantwortlich für Umsetzung: Leiter IT, Administrator Application Server sind für Angreifer sehr attraktive Ziele, da sie oft den Zugriff auf kritische Unternehmensdaten bieten. Daher muss der Absicherung eines Application Servers ein hoher Stellenwert eingeräumt werden. Vor dem Einrichten eines Application Servers sollte in einer Sicherheitsstrategie beschrieben werden, welche Sicherheitsmaßnahmen in welchem Umfang umzusetzen sind. Anhand der in der Sicherheitsstrategie festgelegten Anforderungen kann dann regelmäßig überprüft werden, ob die getroffenen Maßnahmen ausreichend sind. In der Sicherheitsstrategie für den Betrieb eines Application Servers sollten die folgenden Fragen beantwortet werden: Welche Dienste soll der Application Server anbieten? Wer ist für die Konfiguration und den Betrieb verantwortlich Welche anderen Systeme und welche Netzverbindungen sind für den sicheren Betrieb des Application Servers wichtig? Können zeitweise Störungen oder Ausfälle dieser Systeme gegebenenfalls überbrückt werden? Wie werden die Verantwortlichen geschult, insbesondere hinsichtlich möglicher Gefährdungen und einzuhaltender Sicherheitsmaßnahmen? Welche Zugriffsbeschränkungen auf den Application Server sollen realisiert werden (siehe auch M Aufbau eines Application Server)? Vorgehen bei Sicherheitsvorfällen In der Sicherheitsstrategie müssen auch Reaktionen auf bestimmte application-server-spezifische Sicherheitsvorfälle festgelegt werden (siehe auch Baustein B 1.8 Behandlung von Sicherheitsvorfällen). Hackerangriff Es sollte beschrieben werden, was beim Verdacht auf einen Hackerangriff auf dem Application Server zu tun ist. Wichtig ist vor Status: Freigegeben Datum: Seite 63 von 146

65 allem die Frage, wann der Server notfalls vom Netz genommen werden muss und wer die Entscheidung dazu trifft. Teil einer Sicherheitsstrategie muss auch die regelmäßige Informationsbeschaffung über potentielle Sicherheitslücken sein, um rechtzeitig Vorsorge dagegen treffen zu können. Neben den in M 2.35 Informationsbeschaffung über Sicherheitslücken des Systems angesprochenen Informationsquellen ist für Sicherheitshinweise zur WWW-Nutzung besonderes die "World Wide Web Security FAQ" eine wertvolle Quelle Die Master-Kopie dieses Dokumentes ist unter zu finden. Ergänzende Kontrollfragen: Existiert eine Sicherheitsstrategie für den Betrieb eines Application Servers? - Werden die getroffenen Regelungen regelmäßig überprüft und gegebenenfalls angepasst? M 2.175* Aufbau eines Application Servers Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Behörden-/Unternehmensleitung Leiter IT, Administrator Um einen Application Server aufbauen zu können, muss neben adäquater Hardware auch entsprechende Software beschafft werden. Das sind zum einen eine aktuelle Version des Application Servers sowie eine passende Java VM. Falls der Tomcat Server mit anderen Webservern zusammenarbeiten soll, sind noch die entsprechenden Zusatzmodule notwendig, z.b. mod_jk für die Integration in einen Apache Webserver. Organisationsstruktur anpassen Es muss überlegt werden, welche Informationen im Internet bzw. in einem Intranet zur Verfügung gestellt werden sollen. Weiterhin ist zu klären, wie und wo Dokumente erstellt werden, wer welche Dokumente erzeugt, welche Dokumente wo zum Einsatz kommen und wer diese Dokumente benötigt. Auf Basis dieser Erkenntnisse sollten dann Richtlinien für ein einheitliches Erscheinungsbild von Dokumenten, Dateinamen und Verzeichnisnamen aufgestellt und nach Möglichkeit standardisierte Entwicklungswerkzeuge bestimmt werden. Eventuell sollte ein eigenes WWW-Redaktionsteam eingerichtet werden (siehe M Status: Freigegeben Datum: Seite 64 von 146

66 2.272 Einrichtung eines WWW-Redaktionsteams). Verantwortliche benennen Beim Betrieb eines Webservers, egal ob intern oder extern, sollte nicht jeder Benutzer beliebig Dateien einstellen können. Es sollte daher ein Verantwortlicher für das Einstellen von Informationen benannt werden, der neue Dateien auch auf die Einhaltung der Richtlinien überprüft. Je nach Größe der Organisation können auch weitere Teil-Verantwortliche für einzelne Organisationseinheiten oder Teilbereiche des Webservers benannt werden. Entsprechend der hier gewählten Organisationsstruktur ist auch die Rechtevergabe und die Verzeichnisstruktur auf dem Webserver festzulegen. Vor allem sollte jeder Teil-Verantwortliche nur Zugriff auf die von ihm betreuten Unterverzeichnisse haben. Automatische Kontrolle der Richtlinien Um sicherzustellen, dass die angelegten Dateien und Verzeichnisse immer den jeweiligen Richtlinien genügen, sollte deren Einhaltung automatisiert überprüft werden, z. B. über geeignete Skripten oder Makros. Ein entsprechend vorbereitetes Programm sollte für alle zur Verfügung gestellt werden und nach jeder Änderung aufgerufen werden. Dabei sollte insbesondere überprüft werden, ob die Zugriffsrechte aller Verzeichnisse, Dateien, Servlets, Ressourcen und CGI-Skripte (falls eingerichtet) korrekt gesetzt wurden. Ein Protokoll über die durchgeführten Änderungen sollte ebenfalls direkt erzeugt werden. Rechte- und Rollenkonzept Ein allgemeines Problem bei der Einrichtung und beim Betrieb eines Webservers ist die notwendige Zusammenarbeit vieler verschiedener Personen mit unterschiedlichen Kompetenzen. So werden Aufgaben wie Erstellen neuer Inhalte, Administration des Webservers, Status: Freigegeben Datum: Seite 65 von 146

67 Durchführung des Designs des Webauftritts, Entwurf einzelner Grafiken, Programmierung von Zusatzfunktionalität für den Webserver (z.b. eine Datenbankanbindung) und Programmieren von Zusatzfunktionalität, die auf dem WWW- Client genutzt wird (Javascript, etc.), in der Regel von unterschiedlichen Personen wahrgenommen. Aus technischen Gründen ist in der Regel eine vollständige Trennung der Zugriffsrechte nicht oder zumindest nicht vollständig möglich. Die oben geforderten Zugriffsbeschränkungen lassen sich auf einem Entwicklungssystem daher in der Regel nicht durchsetzen. In diesem Fall muss darauf geachtet werden, dass das Entwicklungssystem keine sensitiven Daten enthält. Die Zugriffsrechte auf einem produktiven Webserver lassen sich jedoch auch in einer solchen Umgebung restriktiv handhaben. Neben der Zuständigkeit müssen auch die für den Transfer notwendigen Tätigkeiten geplant werden. Dies umfasst neben der oben erwähnten Kontrolle der vergebenen Zugriffsrechte auch eine Überprüfung der zu veröffentlichenden Inhalte. Zugriffsbeschränkungen auf den Application Server Vor der Inbetriebnahme bzw. jeder Aktualisierung eines Application Servers muss festgelegt werden, wer Informationen vom Application Server abfragen darf. Es ist zu klären, ob nur Personen innerhalb der eigenen Organisation, eventuell zusätzlich Telearbeiter, oder auch jeder Externe oder nur ein eingeschränkter Kreis auf bereitgestellte Informationen zugreifen dürfen. Diese Einschränkungen können auch abhängig von den jeweiligen Informationen variieren Wenn der Zugriff auf den Application Server nur einem begrenzten Personenkreis möglich sein soll, sind entsprechende Maßnahmen zu implementieren, wie z. B. in M 4.94* Schutz der Dateien des Application Servers. Es muss außerdem geklärt werden, ob grundsätzlich nur Informationen abgerufen werden dürfen oder ob es auch für Benutzer möglich sein soll, selber neue Informationen einzustellen. Auch hier ist wieder festzulegen werden, welcher Personenkreis welche Rechte hat. Übersichtliche Strukturierung Da HTML-Dateien und andere zugreifbare Ressourcen nicht hierarchisch angeordnet werden müssen, ist die Verzeichnisstruktur innerhalb eines Status: Freigegeben Datum: Seite 66 von 146

68 Application Servers für die Funktionsweise irrelevant. Um die Wartung zu erleichtern, sollte allerdings auf eine übersichtliche Struktur geachtet werden. Sprechende Pfadnahmen Es ist empfehlenswert, die Verzeichnisstruktur so zu wählen, dass der URL, unter dem eine Datei erreichbar ist, bereits gewisse Informationen über die Datei gibt. Dies führt zwar unter Umständen zu relativ langen Pfadnamen, aber es macht es Besuchern leichter, sich bestimmte Stellen zu merken und wieder zu finden. Da viele Internet-Suchmaschinen bei einer Suche den vollständigen WWW-Pfad eines Treffers ausgeben, verbessert diese Art der Strukturierung auch die Auffindbarkeit der Informationen. Da unter Umständen in anderen Webservern Links auf ihre Dokumente angelegt werden, sind Änderungen an Dokument- und Verzeichnisnamen zu vermeiden. Die Verzeichnisstruktur muss deshalb erweiterungsfähig geplant werden. Dokumente bereitstellen Ein öffentliches Webangebot im Internet ist eine Form der Außendarstellung einer Organisation. Entsprechend sorgfältig sollte daher die Internet-Präsenz vorbereitet werden. Es empfiehlt sich, mit einem Webangebot im Intranet erste Erfahrungen zu sammeln, bevor ein Webserver an das Internet angebunden wird. Hier sollte mit wenigen, einfachen Anwendungen begonnen werden. Informationen in einem Webangebot werden normalerweise in HTML- Dateien bereitgestellt, die direkt im Webbrowser dargestellt werden können. Es können aber auch Dateien in beliebigen anderen Formaten zum Download bereitgestellt werden. In diesem Fall muss die Anwendung zum Anzeigen des Dokuments beim Benutzer vorhanden sein und die Dateien müssen im Allgemeinen zunächst auf dem IT- System des Benutzers gespeichert werden, bevor sie weiterverarbeitet werden können. Sofern es nicht erforderlich ist, dass Benutzer in den bereitgestellten Dokumenten Änderungen vornehmen (beispielsweise Ausfüllen von Formularen), sollten Dokumente in Formaten bereitgestellt werden, bei denen Veränderungen nicht einfach möglich sind. Proprietäre Dokumentenformate sollten so weit wie möglich vermieden werden. Qualitätssicherung Alle für die Veröffentlichung im Internet vorgesehenen HTML-Dokumente Status: Freigegeben Datum: Seite 67 von 146

69 und WWW-Dateien sollten vor der Veröffentlichung genauso qualitätsgesichert und inhaltlich genehmigt werden wie jede andere Veröffentlichung. HTML-Dokumente werden meist mit speziellen HTML-Editoren erstellt. In anderen Formaten erstellte Dokumente können mit HTML-Konvertern in HTML umgewandelt werden. Sollen viele, sich oft ändernde Dokumente zur Verfügung gestellt werden, empfiehlt es sich, den Application Server mit einer Dokumentendatenbank zu verbinden. Diese Lösung bietet dem Benutzer schnelle Such-, Ansichts- und Dokumentenverwaltungsmöglichkeit. Nützlich ist es auch, wenn mit Hilfe einer Datenbankanbindung der Zugriff auf bereits vorhandene Firmendaten ermöglicht wird. In diesem Fall muss jedoch der Datenbankserver bzw. die Dokumentendatenbank in das WWW-Sicherheitskonzept mit einbezogen werden. Konfigurationsmanagement Da sich die Inhalte von WWW-Seiten erfahrungsgemäß häufig ändern, ist es wichtig, ein funktionierendes Konfigurationsmanagement aufgebaut zu haben. Die Aktualität von Links und Verweisen ist zu überprüfen, ebenso wie vor Veröffentlichung eine Virenkontrolle mit einem aktuellen Computer-Virensuchprogramm durchzuführen ist. Kontrolle und Freigabeverfahren Es ist ebenso wichtig, dass alle Veröffentlichungen ein festgelegtes und nachvollziehbares Kontrollverfahren durchlaufen. Dies sollte eine inhaltliche Qualitätskontrolle ebenso umfassen wie eine formale Freigabe. Hier muss auch überprüft werden, ob die Informationen überhaupt für eine Veröffentlichung geeignet sind oder ob sie z. B. vertraulich sind, dem Datenschutz unterliegen, Copyright-geschützt sind oder ähnliches. Bei größeren Webangeboten kann es sinnvoll sein, ein Web-Content- Management-System einzusetzen. Solche Systeme vereinfachen viele Arbeitsabläufe, die im Zusammenhang mit der Pflege eines Webangebots anfallen. Informationen, die zur Veröffentlichung über elektronische Medien freigegeben worden sind, sollten digital signiert werden, um allen Lesern die Möglichkeit zu geben, die Authentizität der Informationen zu überprüfen. Veröffentlichungen, die nicht die Meinung der Organisation widerspiegeln, müssen als solche gekennzeichnet sein. Status: Freigegeben Datum: Seite 68 von 146

70 Beachtung rechtlicher Rahmenbedingungen Beim Betrieb eines Application Servers müssen verschiedene rechtliche Rahmenbedingungen (in Deutschland sind dies unter anderem das Teledienstegesetz, der Mediendienste-Staatsvertrag, Vorschriften zum Datenschutz) berücksichtigt werden. Beispielsweise wird für ein gewerbliches WWW-Angebot das Vorhandensein eines Impressums gefordert, in dem der Name der verantwortlichen Person und eine Kontaktadresse genannt werden müssen. Je nach dem Inhalt des WWW-Angebots oder der Branche des Anbieters sind unter Umständen weitere Angaben erforderlich. Bevor ein WWW-Angebot freigeschaltet wird, sollte geklärt sein, welche Informationen dies sind und wo und in welcher Form diese veröffentlicht werden müssen. Ergänzende Kontrollfragen: Existieren Richtlinien für Inhalt und Form von Dokumenten, die auf dem Application Server veröffentlicht werden? Gibt es Richtlinien für ein einheitliches Erscheinungsbild? Wie werden Dokumente vor ihrer Veröffentlichung qualitätsgesichert? Existiert ein Rechte- und Rollenkonzept? Gibt es ein Freigabeverfahren bei der Veröffentlichung von Dokumenten auf dem Application Server? Werden Links regelmäßig überprüft? Sind alle vorgeschriebenen Angaben wie Impressum vorhanden? Bemerkung: Wenn die Webanwendungen auf dem Application Server nur Webservices und keine interaktive Bedienoberfläche anbietet, können alle Punkte, die sich mit der Bereitstellung von Inhalten befassen, vernachlässigt werden. M 2.269* Planung des Einsatzes eines Application Servers Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator Die Detailplanung für den Einsatz eines Application Servers baut auf der allgemeinen Planung für den Aufbau eines Webangebots (siehe M Status: Freigegeben Datum: Seite 69 von 146

71 Entwicklung eines Konzeptes für die WWW-Nutzung) auf. Aus den festgelegten Zielen des Webangebots und weiteren Rahmenbedingungen (beispielsweise Zugriff auf Datenbanken) ergeben sich Anforderungen, die in der konkreten Planung für den Application Server berücksichtigt werden müssen. Die folgenden Themen, die auch untereinander Abhängigkeiten aufweisen, sollten bei der Planung berücksichtigt werden: Auswahl der Hardware- und Betriebssystemplattform, der Java VM und der Apache Tomcat Version Die Hardware, auf der der Application Server eingesetzt wird, kann einen entscheidenden Einfluss auf die Gesamtleistung des entstehenden Systems haben. Dabei spielen bei einem Servlet Container, der vor allem dynamische Seiten ausliefert, Anzahl und Takt der eingesetzten Prozessoren, Geschwindigkeit des Speicherzugriffs und die Größe des Speichers eine entscheidende Rolle. Bei der Auswahl des Plattensubsystems sollte darauf geachtet werden, dass das System hohe Datenübertragungsraten beim "zufälligen" Lesen verschiedener Dateien bietet. Es sollte überlegt werden, die Partition, auf der die Webanwendungen abgelegt werden sollen, auf einem externen RAID-System zu installieren. Das RAID-System sollte das Austauschen von Festplatten im laufenden Betrieb (hot-swap) unterstützen und als RAID 5 organisiert werden. Dies erlaubt es, defekte Platten ohne Betriebsunterbrechung des Servers auszutauschen. Der Application Server kann unter allen Betriebssystemen eingesetzt werden, für die eine Java VM in der vorgegebenen Version existiert. Der Application Server kann entweder aus dem Quellcode selbst kompiliert werden, oder es kann eine Binärversion installiert werden. Der Quellcode kann vom Server der Apache Foundation (http://tomcat.apache.org) heruntergeladen werden. Die Apache Foundation bietet auch vorkompilierte Versionen an. Falls das Webangebot statische Seiten enthalten soll, sollte spätestens an dieser Stelle entscheiden werden, mit welcher Technik diese realisiert werden sollen. Sollen statische Inhalte über einen vorgeschalteten Webserver ausgeliefert werden oder soll dies auch über den Application Server erfolgen. Es sollte eine Liste der Webanwendungen erstellt werden, die im Application Server eingesetzt werden müssen, um die Anforderungen zu erfüllen. Webanwendungen, die in der Standardkonfiguration aktiv sind, für die jedoch kein konkreter Bedarf besteht, sollten nach Möglichkeit entfernt werden. Status: Freigegeben Datum: Seite 70 von 146

72 M 2.270* Planung des SSL-Einsatzes beim Application Server (zusätzlich) Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Administrator Leiter IT IT-Sicherheitsmanagement IT-Sicherheitsmanagement SSL (Secure Sockets Layer) bzw. TLS (Transport Layer Security) ist ein Transportprotokoll, das kryptographische Mechanismen zur Gewährleistung von Integrität, Vertraulichkeit und Authentizität übertragener Daten nutzt (siehe M 5.66 Verwendung von SSL). Einsatzmöglichkeiten von SSL beim Application Server Es gibt zwei Szenarien, in denen SSL zum Einsatz kommen kann: Im ersten Szenario verfügt nur der Application Server über ein Zertifikat. Der WWW-Client kann dann aufgrund dieses Zertifikates den Application Server authentisieren. Im Rahmen des SSL-Protokolles wird dann ein verschlüsselter und integritätsgeschützter Kanal etabliert, über den im folgenden die Daten zwischen Application Server und WWW-Client ausgetauscht werden können. Im zweiten Szenario verfügt auch der Benutzer des Application Servers über ein eigenes Zertifikat, so dass im Rahmen des SSL-Protokolles eine gegenseitige Authentisierung erfolgen kann. Der Einsatz von SSL in Verbindung mit einem Application Server erfordert eine sorgfältige Planung, bei der eine ganze Reihe von Aspekten berücksichtigt werden müssen. Beim Einsatz von SSL im ersten Szenario etwa kommen die folgenden Aspekte zum Tragen: Der Application Server benötigt ein SSL-Zertifikat, das für ihn von einer Zertifizierungsstelle ausgestellt wurde. Der Zertifikatsspeicher des Application Server muss ausreichend gegen unbefugten Zugriff gesichert sein. Bei der Auswahl dieser Zertifizierungsstelle muss berücksichtigt werden, dass die WWW-Clients, die auf den Application Server zugreifen sollen, über das entsprechende Wurzelzertifikat dieser Zertifizierungsstelle verfügen müssen. Das SSL-Zertifikat eines Servers muss regelmäßig erneuert werden. Neben der Laufzeit des Zertifikates selbst muss hier auch Status: Freigegeben Datum: Seite 71 von 146

73 die Laufzeit des Wurzelzertifikates berücksichtigt werden. Ein SSL-Zertifikat kann auch selbst erzeugt werden, beispielsweise mit dem OpenSSL Paket. Da solche Eigen- Zertifikate nicht von einer der Zertifizierungsstellen stammen, die normalerweise den Browsern bekannt sind, bekommen die Besucher in diesem Fall jedoch meist beim Zugriff eine Warnung angezeigt. Dies kann dadurch behoben werden, dass das zum Ausstellen des Server-Zertifikats benutzte Zertifikat manuell auf den Browsern installiert wird. Bei einer Nutzung eines SSLgesicherten Webservers im Intranet kann dies eine berücksichtigenswerte Option sein. Wird SSL im zweiten Szenario auch zur Client-Authentisierung genutzt, so muss im Prinzip eine vollständige Public-Key- Infrastruktur geplant werden. Folgende Aspekte müssen dabei berücksichtigt werden: Für die einzelnen Benutzer müssen SSL-Zertifikate erstellt und verteilt werden. Die Gültigkeitsdauer der Benutzer-Zertifikate muss ebenso berücksichtigt werden, wie das Szenario eines Schlüsselwechsels der eingesetzten Zertifizierungsstelle. Die Richtlinien der für die Benutzer-Zertifikate genutzten Zertifizierungsstelle müssen konform zu den Anforderungen an die Authentisierung der Benutzer sein. Es muss in Betracht gezogen werden, dass der private SSL- Schlüssels eines Benutzers kompromittiert sein könnte. Daher sollte es auch Möglichkeiten geben, diese zu sperren. Dies kann durch Prüfen gegen eine Positivliste (noch gültige Zertifikate) oder durch Verwendung einer Negativliste (gesperrte Zertifikate) geschehen. Prinzipiell besteht die Möglichkeit, SSL-Benutzerzertifikate nicht nur zur Authentisierung zu nutzen, sondern darüber hinaus auch Zugriffsrechte in Abhängigkeit von einzelnen Einträgen des Zertifikates zu vergeben (z. B. der Zugehörigkeit zu einer bestimmten Abteilung). Soll diese Möglichkeit genutzt werden, so muss darauf geachtet werden, dass die relevanten Einträge bei der Zertifizierung von Benutzern korrekt vorgenommen werden und die Zertifikate gesperrt werden, sobald die relevanten Einträge Status: Freigegeben Datum: Seite 72 von 146

74 ungültig werden (z. B. wenn Mitarbeiter die Institution verlassen oder die Abteilung wechseln). Können diese Voraussetzungen nicht gewährleistet werden, so ist im Rahmen der Definition einer Sicherheitsrichtlinie für den Webserver festzuhalten, dass Zugriffsrechte nicht auf der Basis von Zertifikatsfeldern eingerichtet werden dürfen. Im Rahmen der Planung müssen schließlich die notwendigen Abläufe und Zuständigkeiten definiert werden. Die Planung ist zu dokumentieren. Die Dokumentation der Planung sollte getroffene Entscheidungen und die Beweggründe, die für diese Entscheidungen ausschlaggebend waren, klar herausstellen. Für die Unterstützung von SSL muss Die Java Secure Socket Implementation (JSSE) installiert sein. Diese ist in der Regel in der Java VM von Sun Microsystems enthalten. Der private Schlüssel des Servers sowie die Zertifikate werden im sogenannten Keystore der Java VM gespeichert. Der Keystore sowie der private Schlüssel des Server- Zertifikats sollte aus Sicherheitsgründen durch eine Passphrase geschützt sein. Dies bedeutet, dass die Passphrase beim Neustart des Servers eingegeben werden muss. Ein automatischer unbeaufsichtigter Neustart des Servers ist somit nicht möglich. Dieser Aspekt muss bei der Planung des Betriebs berücksichtigt werden. Ergänzende Kontrollfragen: Ist geklärt, welche Art von Zertifikat für den Application Server benötigt wird? Wird SSL auch zur Benutzer-Authentisierung verwendet? Falls ja, sind die entsprechenden Rahmenbedingungen erfüllt? - Ist festgelegt, welche Implementierung von SSL eingesetzt werden soll? M 2.272* Einrichtung eines WWW-Redaktionsteams Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Behörden-/Unternehmensleitung Leiter IT, Fachverantwortliche Ein Webangebot benötigt regelmäßige Pflege. Vor allem dann, wenn Inhalte oder Dienste angeboten werden, die sich häufiger ändern, wird der Pflegeaufwand relativ schnell anwachsen. Status: Freigegeben Datum: Seite 73 von 146

75 Im Konzept für das Webangebot (siehe M Entwicklung eines Konzeptes für die WWW-Nutzung) werden Verantwortliche für verschiedene Aspekte der Pflege des Webangebots benannt. Überschreitet der Umfang des Angebots und der damit verbundene Pflegeaufwand ein bestimmtes Maß, so kann es sinnvoll sein, zur besseren Koordination eine eigenständige WWW-Redaktion einzurichten. Auf diese Weise werden die Verantwortlichkeiten noch einmal betont und sichtbar in der Organisationsstruktur abgebildet. Die Einrichtung einer WWW-Redaktion bietet den Vorteil, dass ein zentraler Kontakt für alle Fragen, die das Webangebot betreffen, zur Verfügung steht. Innerhalb einer solchen Redaktion können meist einfacher effiziente Prozesse zur Sicherstellung der Aktualität und Korrektheit der Informationen im Webangebot (beispielsweise bestimmte Freigabeprozesse oder ein Vieraugenprinzip) etabliert werden, als wenn dies über verschiedene Organisationseinheiten hinweg geschehen müsste. Die Redaktion sollte mindestens diejenigen Personen umfassen, die im WWW-Konzept als Verantwortliche genannt wurden. Oft ist es sinnvoll, weitere Personen in die Redaktion einzubinden. Eine WWW-Redaktion sollte folgende Mitglieder umfassen: einen Chefredakteur, der die Gesamtverantwortung für die Inhalte und Dienste im Webangebot übernimmt, für die verschiedenen inhaltlichen Bereiche jeweils einen Fachredakteur, einen Verantwortlichen für das optische Erscheinungsbild (Webdesign) des Webangebots, einen "technischen Webmaster", der für die technischen Aspekte des Betriebs des Webservers zuständig ist. Falls auf dem Webserver umfangreichere Webanwendungen eingesetzt werden, so sollte auch für diese Anwendungen ein Ansprechpartner in der WWW-Redaktion vertreten sein. Die Fachredakteure, der Webdesigner und der technische Webmaster dienen jeweils als Ansprechpartner (Schnittstelle) zu den jeweiligen Fachbereichen. Innerhalb der WWW-Redaktion müssen neben den normalen Redaktionsprozessen auch Vorgehensweisen und Zuständigkeiten für den Fall von Problemen festgelegt werden, damit eine schnelle und effiziente Reaktion auf Sicherheitsvorfälle gewährleistet ist (siehe auch M Festlegung einer WWW-Sicherheitsstrategie). Status: Freigegeben Datum: Seite 74 von 146

76 Bemerkung: Wenn die Webanwendungen auf dem Application Server nur Webservices und keine interaktive Bedienoberfläche anbieten bzw. keine Inhalte anzeigen, kann dieser Punkt vernachlässigt werden. M 2.298* Verwaltung von Internet-Domainnamen Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Leiter IT Internet-Domainnamen (Domains) müssen bei Registrierungsstellen (Registrars) angemeldet werden. Eine Registrierungsstelle kann Namen für eine oder mehrere sogenannte Top-Level-Domains (beispielsweise die "klassischen" Domains.com,.org,.gov und die diversen Länder- Domains wie.de für Deutschland,.at für Österreich und.ch für die Schweiz) vergeben. Domains werden jeweils für einen bestimmten Zeitraum registriert. Ist dieser Zeitraum abgelaufen, so muss die Registrierung gegen Zahlung einer Gebühr verlängert werden. Wird die Verlängerung einer Registrierung vergessen, so kann dies unangenehme Folgen haben (siehe G Fehler bei der Beantragung und Verwaltung von Internet-Domainnamen). Es muss daher sichergestellt sein, dass die Registrierungen für alle Domains, die von einer Organisation benutzt werden, regelmäßig und rechtzeitig verlängert werden. Dazu sollte in jeder Organisation eine Stelle festgelegt werden, die die Verwaltung der Domainnamen bei den verschiedenen Registrierungsstellen koordiniert. Neben der Verwaltung der Domainnamen und der Sicherstellung der rechtzeitigen Verlängerung der Registrierungen sollten beim Management von Internet-Domainnamen auch folgende Punkte berücksichtigt werden: DNS Nameserver Bei der Registrierung eines Domainnamens müssen mindestens zwei DNS-Nameserver (Primary Nameserver) angegeben werden, die für die Zuordnung von Rechnernamen zu IP-Adressen zuständig sind. Ein Nameserver wird oft vom Internet-Zugangsprovider betrieben, kann aber auch von der Organisation selbst betrieben werden. Bei der Festlegung der Nameserver sollte zumindest darauf geachtet werden, dass die Primary Nameserver in verschiedenen Class C Netzen liegen. Ist dies nicht der Fall, so kann ein Denial of Service Angriff auf den Router, mit dem dieses Netz ans Internet angebunden ist, die komplette Domain lahm legen, da keine Namen aus dieser Domain mehr aufgelöst werden können. Bei hohen Anforderungen an die Verfügbarkeit der Namensauf- Status: Freigegeben Datum: Seite 75 von 146

77 lösung sollten die Primary Nameserver idealerweise in verschiedenen Netzen mit Anbindung über unterschiedliche Provider angesiedelt werden Domainnamen Zu Anfang des "Internet-Zeitalters" reichte es meist aus, wenn eine Organisation eine einzige Internet-Domain betrieb. Mit der wachsenden Popularität des World-Wide-Web wurde es üblich, nicht nur eine Domain mit beispielsweise dem eigenen Firmennamen zu betreiben, sondern auch für bekannte Produkte Domains einzurichten. Um zu verhindern, dass Domains mit dem Namen eigener Produkte und Dienstleistungen von Anderen registriert werden, die unter dieser Adresse dann eventuell pornographische oder andere anstößige Inhalte verbreiten, die von Besuchern dann mit der eigenen Organisation in Verbindung gebracht werden, sollten soweit möglich nicht nur der eigene Firmenname und die Namen bekannter eigener Produkte in der korrekten Schreibweise registriert werden, sondern jeweils auch Varianten davon, etwa mit oder ohne Bindestrichen bei zusammengesetzten Namen. Diese Namen sollten unter den verschiedenen "relevanten" Top-Level- Domains (etwa.de,.com,.org,.info) registriert werden. Außerdem sollte geprüft werden, ob nicht auch bestimmte falsch geschriebene Varianten (etwa bestimmte "Buchstabendreher") von Produkt- oder Firmennamen registriert werden sollten. Der dadurch entstehende Mehraufwand ist gering im Vergleich zu dem Aufwand, gegebenenfalls die "Herausgabe" einer Domain gerichtlich erzwingen zu müssen. Für solche "sicherheitshalber" registrierten Domains sollte zumindest ein minimales Webangebot eingerichtet werden, das den Domainnamen nennt, auf dem das eigentliche Angebot eingerichtet ist und eine Weiterleitung dort hin anbietet. Gegebenenfalls kann auch einfach der Haupt-Webserver der Organisation über eine entsprechende Namensauflösung auch als Webserver für diese Domain agieren. Registrierungsstellen und Registrierungszeiträume Für mehrere Top-Level Domains (etwa.com und.org) existieren verschiedene Registrierungsstellen. Ein Wechsel der Registrierungsstelle ist jederzeit möglich, aber meist mit Kosten verbunden. Es ist wichtig, für alle registrierten Domains einen Überblick über die jeweilige Laufzeit der Registrierung, den Preis für die Verlängerung und die Bankverbindung der Registrierungsstelle zu haben, um eine rechtzeitige Verlängerung der Registrierung sicher zu stellen. Vertragsgestaltung mit Internetdienstleistern Wenn die Domains der Organisation nicht in Eigenregie registriert und Status: Freigegeben Datum: Seite 76 von 146

78 verwaltet werden, sondern dies über einen Internetdienstfeister geschieht, so muss bei der Vertragsgestaltung darauf geachtet werden, dass die Organisation selbst die Kontrolle über die Domains behält. Dies kann beispielsweise bei einem eventuellen Wechsel des Registrars oder bei der Auflösung von Namensstreitigkeiten von Bedeutung sein. Für den Fall von Fehlern und Versäumnissen des Dienstleisters im Bezug auf die Verwaltung von Domainnamen sollten entsprechende Regelungen getroffen werden, da in solchen Fällen erheblicher Schaden entstehen kann (siehe G Fehler bei der Beantragung und Verwaltung von Internet-Domainnamen). Falls die Nameserver nicht in der Organisation selbst betrieben, sondern bei einem Dienstleister gehostet werden, sollten in den Service-Level- Agreements insbesondere Vereinbarungen über die Anforderungen an die Verfügbarkeit der Nameserver und an Bearbeitungszeiten für Änderungen im DNS der Organisation getroffen werden. Ergänzende Kontrollfragen: Welche Domainnamen wurden registriert? Existiert ein Überblick über Laufzeiten, Preise und Kontakte für die Domainregistrierungen? Wo werden die Nameserver der Organisation betrieben? Bemerkung: Wenn Der Application Server nur innerhalb eines internen Netzes angesprochen werden soll, kann dieser Punkt entfallen. M 4.176* Auswahl einer Authentisierungsmethode für Webangebote Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator Für E-Commerce- und E-Government-Anwendungen, personalisierte Webangebote, Webservices oder nur allgemein zur Realisierung von Zugriffsbeschränkungen auf bestimmte Bereiche eines Webangebots werden Mechanismen zur Identifikation und Authentisierung verschiedener Benutzer benötigt. In Abhängigkeit von den konkreten Anforderungen an den Schutz der Dokumente oder Webservices vor unbefugtem Zugriff und die Qualität der Authentisierung muss eine geeignete Methode ausgewählt werden. Die Wahl der Authentisierungsmethode und die Gründe, die zu der Wahl Status: Freigegeben Datum: Seite 77 von 146

79 geführt haben, sollten dokumentiert werden. Authentisierungsmethoden bei HTTP Das Protokoll HTTP/1.1 sieht zwei verschiedene Methoden zur Benutzerauthentisierung vor. Die erste Methode ist die so genannte Basic-Access-Authentisierung. Dabei sendet der Client den Benutzernamen und das Passwort Base64- kodiert im so genannten Authorization Header des HTTP-Requests an den Server. Base64 ist eine Methode zur Kodierung von Binärdaten in 7- Bit ASCII, die hier zur Übertragung von Sonderzeichen über die HTTP- Schnittstelle genutzt wird. Das Passwort ist somit zwar nicht auf den ersten Blick ablesbar, kann aber von einem potentiellen "Lauscher" problemlos ermittelt werden, da es unverschlüsselt ist. Daher ist dieser Authentisierungstyp allenfalls für sehr geringe Vertraulichkeitsanforderungen zu gebrauchen. Die zweite Methode zur HTTP-Authentisierung ist die Digest- Authentisierung. Bei dieser Art der Authentisierung muss auf dem Server das Passwort des Benutzers im Klartext vorliegen. Der Client erhält vom Server einen Zufallsstring, die so genannte Challenge. Aus dieser Challenge und dem Passwort des Benutzers errechnet der Client nach einem standardisierten Verfahren einen so genannten Digest, der dann zur Authentisierung an den Server gesandt wird. Da der Server sowohl über den von ihm generierten Zufallsstring, als auch über das Passwort des Benutzers verfügt, kann er den Digest ebenfalls berechnen und so die Authentisierung durchführen. Da bei der Digest-Authentisierung das Passwort nicht über das Netz verschickt wird, eignet sich diese Methode für einen etwas höheren Schutzbedarf. Ein Problem bei der Verwendung der oben genannten Authentisierungsmethoden ist die Sicherheit der Passwortdaten auf dem Server: Bei Verwendung der Digest-Authentisierung müssen die Authentisierungsdaten der Benutzer auf dem Webserver im Klartext vorhanden sein. Bei Verwendung der Basic-Authentisierung wird meist ein Hash-Wert des Passwortes gespeichert. Eine Sicherung der Passwortdateien auf dem Server vor unbefugtem Zugriff ist daher besonders wichtig. Neben der HTTP-Authentisierung existiert ein weiterer Weg, Zugriffskontrolle über das HTTP-Protokoll zu realisieren: die Authentisierung kann nicht über den Webserver selbst, sondern über eine serverseitige Anwendung durchgeführt werden. Dabei werden Benutzername und Passwort über normale HTML Formulare eingegeben und von der Anwendung überprüft. Dieses Verfahren ist häufig bei Internet- Angeboten realisiert. Es sollte jedoch stets beachtet werden, dass Pass- Status: Freigegeben Datum: Seite 78 von 146

80 wörter oder PINs, die im Klartext über das Internet übertragen werden, leicht mitgelesen werden können. Zudem werden natürlich auch sämtliche Daten, selbst wenn sie auf authentisierte Anfragen hin ausgeliefert werden, unverschlüsselt übermittelt. Die Formularbasierte Authentisierung kann nicht ohne weiteres für Webservice-Angebote verwendet werden. Manche Webangebote identifizieren die Benutzer über spezielle Cookies, die im Browser gespeichert werden. Da Cookies bei der Verwendung von HTTP ebenfalls im Klartext übertragen werden, ist diese Methode für die Authentisierung beim Zugriff auf schutzbedürftige Informationen ebenfalls nicht geeignet. Da im Zusammenhang mit Cookies noch weitere Sicherheitsprobleme existieren, sollte diese Methode generell nicht verwendet werden. Verwendung von SSL Wenn im Rahmen von E-Government- oder E-Commerce-Angeboten höhere Anforderungen an die Sicherheit der Authentisierung und die Vertraulichkeit der übertragenen Daten bestehen, dann sollte die Übertragung durch die Verwendung von SSL abgesichert werden (siehe auch M 5.66 Verwendung von SSL). Bei der Verwendung von SSL gibt es zwei verschiedene Betriebsarten: bei der ersten Variante besitzt nur der Server ein Zertifikat. Dies dient dem Benutzer dazu, zu erkennen, dass er wirklich mit dem "richtigen" Server verbunden ist, und ermöglicht nach dem Aufbau einer verschlüsselten Verbindung die sichere Übertragung von Authentisierungsinformationen und Anwendungsdaten. Ein Server-Zertifikat enthält neben dem Namen der Zertifizierungsstelle auch den Namen des Servers, für den es gültig ist. Es kann von einer Wurzelzertifizierungsstelle (Root-CA) ausgestellt sein oder auch selbst erzeugt werden, beispielsweise mit den im OpenSSL Paket enthaltenen Tools. Zertifikate, die nicht von einer Wurzelzertifizierungsstelle ausgestellt wurden, die dem Browser bekannt ist, werden vom Browser meist nicht ohne weiteres akzeptiert, sondern der Benutzer muss explizit bestätigen, dass das betreffende Zertifikat akzeptiert werden soll. Bei der zweiten Variante, verfügt auch der Benutzer über ein Zertifikat, das auf dem Client-Rechner vorhanden sein muss, und das der Browser zur Authentisierung an den Server schickt. Voraussetzung dafür ist jedoch, dass die Zertifizierungsstellen, deren Zertifikate verwendet werden, vertrauenswürdig sind. Dass diese Art der Authentisierung in der Praxis nicht häufiger verwendet wird, liegt an dem Aufwand, der zur Status: Freigegeben Datum: Seite 79 von 146

81 Umsetzung einer solchen Lösung erforderlich ist. Die serverseitige Konfiguration ist relativ einfach: Neben der Konfiguration des Webservers für SSL muss ein SSL-Server-Zertifikat beschafft und implementiert werden. Der Aufwand, der für jeden einzelnen Benutzer zu betreiben ist, ist jedoch relativ hoch: Jeder Benutzer muss über ein SSL- Client-Zertifikat verfügen, das jeweils im Browser des Benutzers installiert ist. Dies führt zu einer gewissen Einschränkung der Bequemlichkeit, da einer der großen Vorteile der normalen WWW-Nutzung gerade darin besteht, dass der Zugriff von praktisch jedem beliebigen Rechner aus erfolgen kann. Werden Client-Zertifikate zur Authentisierung benutzt, so ist diese Flexibilität deutlich eingeschränkt, weil das Client-Zertifikat meist nicht überall vorhanden ist. Andererseits kann in bestimmten Situationen, etwa beim Einsatz eines Intranet-Webservers, genau dies erwünscht sein. Eine häufig verwendete Methode der Benutzerauthentisierung für Webangebote ist die Kombination von formularbasierter Authentisierung und SSL-verschlüsselter Datenübertragung. Diese Methode bietet, wenn die gewählte SSL-Verschlüsselung ausreichend stark gewählt wird, bei vertretbarem Aufwand (Benutzerverwaltung in der Webanwendung und Implementierung eines SSL-geschützten Zugriffs auf den Webserver) ein Sicherheitsniveau, das auch für höhere Sicherheitsanforderungen angemessen ist. Die folgende Tabelle fasst die verschiedenen Möglichkeiten der Benutzerauthentisierung bei Webservern zusammen: Methode Sicherheitsniveau Aufwand für Implementierung Serveranforderungen Kommentare Standard- Authentisierung Niedrig Niedrig Benutzerverwaltung Authentisierungsinformationen und Daten werden unverschlüsselt übertragen! Formularbasierte Authentisierung ohne gesicherte Übertragung Niedrig Niedrig bis mittel Implementierung in der jeweiligen Anwendung Authentisierungsinformationen und Daten werden unverschlüsselt übertragen! Digest- Authentisierung Mittel Niedrig Benutzerverwaltung Daten werden unverschlüsselt übertragen. Formularbasierte Hoch Mittel bis SSL-Unterstützung im Authentisierungsinformationen und Daten werden Status: Freigegeben Datum: Seite 80 von 146

82 Authentisierung über SSL hoch Server, Implementierung in der jeweiligen Anwendung verschlüsselt übertragen! Zertifikatbasierte Authentisierung über SSL Hoch bis sehr hoch Hoch bis sehr hoch Installation von Server- Zertifikaten. Zertifikatsverwaltung, Public-Key Infrastruktur. Wird hauptsächlich für sichere Transaktionen über das Internet verwendet. Tabelle: Benutzerauthentisierung bei Webservern Der Microsoft Internet Information Server bietet darüber hinaus noch eine weitere Methode, bei der die Windows-Benutzeranmeldung benutzt wird. Diese Methode funktioniert allerdings nur mit dem Microsoft Internet Explorer als Client. Beim Aufbau einer SSL-Verbindung wird der zu verwendende Verschlüsselungsmodus zwischen Client und Server ausgehandelt. Unter den zur Verfügung stehenden Algorithmen befinden sich auch solche, die nicht mehr als sicher angesehen werden können. Insbesondere gibt es auch den so genannten Null-Encryption-Modus, bei dem keine Verschlüsselung stattfindet. Bei der Konfiguration des Webservers für die Verwendung von SSL muss darauf geachtet werden, dass der Server keinen der schwachen Algorithmen und insbesondere nicht den Null- Encryption-Modus akzeptiert. Andernfalls könnte es dazu kommen, dass scheinbar eine sichere Verbindung aufgebaut wird (es wird https verwendet), die jedoch in Wirklichkeit zu schwach oder gar nicht verschlüsselt ist. Eine solche Situation könnte von einem Angreifer bewusst herbeigeführt werden, um Authentisierungsinformationen und andere Daten abzuhören. Daher sollte in der SSL-Konfiguration des Webservers die Verwendung des Null-Encryption-Modus und der schwachen Algorithmen abgeschaltet werden. Ergänzende Kontrollfragen: Ist dokumentiert, wie die Entscheidung für die gewählte Authentisierungsmethode gefällt wurde? Wurden der Null-Encryption-Modus und die schwachen Algorithmen in der SSL-Konfiguration abgeschaltet? Status: Freigegeben Datum: Seite 81 von 146

83 M 5.64 Secure Shell Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator, Benutzer Ohne spezielle Erweiterungen bieten die Protokolle telnet und ftp nur rudimentäre Mechanismen zur Authentisierung. In der Regel wird eine einfache Abfrage von Benutzer-Kennung und Passwort durchgeführt, die dann - ebenso wie die Nutzdaten - im Klartext gesendet werden. Die Vertraulichkeit der Authentisierungs- und Nutzdaten ist also nicht gesichert. Die verwandten Protokolle rsh, rlogin und rcp, die oft unter der Bezeichnung r Dienste zusammengefasst werden, weisen ähnliche Sicherheitsmängel auf. Secure Shell (ssh) kann als Ersatz für die r-dienste genutzt werden, wobei umfangreiche Funktionen zur sicheren Authentisierung und zur Wahrung von Vertraulichkeit und Integrität zum Einsatz kommen. Hierzu wird ein hybrides Verschlüsselungsverfahren, also eine Kombination aus asymmetrischer und symmetrischer Verschlüsselung, verwendet. Angesiedelt ist die Secure Shell auf Schicht 7 (Anwendungsschicht) des ISO/OSI-Referenzmodells, allerdings können auch andere Protokolle wie das X11-Protokoll, das von der graphischen Oberfläche X Windows verwendet wird, über ssh transportiert werden. Derzeit basiert Secure Shell auf drei Protokollen, die aufeinander aufbauen und für die jeweils ein Internet-Draft existiert. Das unterste Protokoll ist das Transport Layer Protocol. Dieses Protokoll leistet den Großteil der Sicherungsfunktionen von ssh, nämlich Authentisierung auf Host-Ebene, Verschlüsselung und Schutz der Datenintegrität. Die kryptographischen Algorithmen sind zwischen den Kommunikationspartnern aushandelbar. Das mittlere Protokoll ist das User Authentication Protocol. Dies erlaubt die Authentisierung auf Benutzer-Ebene, wobei auch hier das Verfahren ausgehandelt werden kann. Wenn zur Authentisierung eine einfache Übertragung von Benutzer-Kennung und Passwort verwendet wird, so ist die Vertraulichkeit dieser Informationen gegenüber dem Kommunikationsweg durch das darunterliegende Transport Layer Protocol gesichert. Empfohlen wird jedoch die Authentisierung durch ein Public-Key-Verfahren. Das Connection Protocol baut auf den beiden vorhergehenden Protokollen auf und erlaubt den Aufbau von mehreren logischen Status: Freigegeben Datum: Seite 82 von 146

84 Nutzkanälen. Die Daten auf diesen Nutzkanälen werden gemeinsam über eine einzelne abgesicherte Secure Shell- Verbindung übertragen. Für alle gängigen Unix-Betriebssysteme existieren Implementierungen sowohl von ssh-clients als auch von ssh-servern. Darüber hinaus gibt es ssh-clients unter anderem für 32 Bit Windows, OS/2, Macintosh und als Java-Applet. Grundsätzlich ist der Einsatz von Secure Shell zu empfehlen, wenn die Funktionalitäten der r-dienste über Kommunikationskanäle genutzt werden, die nicht ausreichend gegen Kompromittierung und/oder Manipulation gesichert sind (z. B. über das Internet). Im Folgenden werden einige Hinweise für den sicheren Einsatz von ssh gegeben. Von besonderer Bedeutung ist die Gefährdung durch so genannte manin-the-middle-attacken. Hierbei filtert der Angreifer den gesamten Verkehr zwischen den Kommunikationspartnern und reicht gefälschte öffentliche Schlüssel weiter. Ist es den Kommunikationspartnern nicht möglich, die öffentlichen Schlüssel zu prüfen, kann der Angreifer den gesamten Verkehr lesen und manipulieren, indem er die Daten jeweils selbst entschlüsselt, dann liest bzw. modifiziert und schließlich mit einem anderen Schlüssel verschlüsselt und weiterleitet. Dies kann mit Hilfe eines geeigneten Schlüssel-/Zertifikatmanagements verhindert werden. Beim praktischen Einsatz von Secure Shell wird jedoch oft eine Kompromisslösung angewandt, die den Einsatz von ssh ohne jede zusätzliche Infrastruktur erlaubt. Dabei wird bei einem Verbindungsaufbau zu einem Host, dessen öffentlicher Schlüssel noch nicht bekannt ist, dieser über das unsichere Netz gesendet und in einer lokalen Datenbank abgelegt. Bei allen nachfolgenden Verbindungen mit diesem Host kann dessen öffentlicher Schlüssel dann anhand der lokalen Datenbank überprüft werden. Im Rahmen des Sicherheitskonzeptes muss geklärt werden, ob dieses Verfahren, das eine reduzierte Sicherheit gegenüber man-in-the-middle-angriffen bietet, für die vorliegende Anwendung ausreichend ist. In den Internet-Drafts sind kryptographische Verfahren festgelegt, die von den Secure Shell-Implementierungen zur Verfügung gestellt werden müssen. Optional können jedoch zusätzliche kryptographische Algorithmen implementiert werden. Die tatsächlich benutzten Verfahren werden beim Verbindungsaufbau ausgehandelt. Durch Wahl geeigneter Client- und Server-Programme und durch entsprechende Konfiguration ist sicherzustellen, dass sich ssh-client und ssh-server auf qualifizierte kryptographische Algorithmen einigen, die den Sicherheitsanforderungen genügen. Wenn ssh zum Einsatz kommt, sollten nach Möglichkeit alle anderen Status: Freigegeben Datum: Seite 83 von 146

85 Protokolle, deren Funktionalität durch Secure Shell abgedeckt wird, also z. B. die r-dienste und telnet, vollständig abgeschaltet werden, damit die Sicherheitsmaßnahmen nicht umgangen werden können. Dies setzt allerdings voraus, dass alle Kommunikationspartner über geeignete Implementierungen verfügen. Von älteren Implementierungen von ssh sind sicherheitsrelevante Programmfehler bekannt. Es sollte daher eine Version verwendet werden, bei der solche Mängel beseitigt sind. Die Kompatibilität zwischen Implementierungen, deren Programmversionen sich stark unterscheiden, ist unter Umständen problematisch. Ein Mischbetrieb sollte deshalb möglichst vermieden werden. Zu beachten ist, dass beim Einsatz von ssh über Firewalls eine inhaltssensitive Kontrolle des Datenstroms nicht mehr möglich ist. Ergänzende Kontrollfragen: Werden r-dienste oder ähnliche Protokolle über unsichere Kommunikationskanäle genutzt? Wie ist bei der Nutzung von Secure Shell die Verifizierung von öffentlichen Host-Schlüsseln geregelt (z. B. organisatorische Maßnahmen)? Wird eine Version von Secure Shell genutzt, bei der alle bekannten Sicherheitsmängel behoben sind? M 5.66* Verwendung von SSL Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator, Benutzer Das bei der WWW-Nutzung am häufigsten verwendete Sicherheitsprotokoll ist SSL ("Secure Socket Layer"). SSL ist von Netscape entwickelt worden und wird von allen aktuelleren Browsern unterstützt. Mit SSL können Verbindungen abgesichert werden durch Verschlüsselung der Verbindungsinhalte, durch Überprüfung der Vollständigkeit und Korrektheit der übertragenen Daten, durch Prüfung der Identität des Servers und Status: Freigegeben Datum: Seite 84 von 146

86 optional durch Prüfung der Identität der Client-Seite. Bei SSL wird eine Verbindung zwischen dem Browser eines Benutzers und dem Server eines Anbieters aufgebaut, über die zunächst die Zertifikate mit den öffentlichen Schlüsseln ausgetauscht werden. Anschließend wird geschützt durch das asymmetrische Verschlüsselungsverfahren RSA ein symmetrischer Schlüssel sicher ausgetauscht. Für die Verschlüsselung der eigentlichen Datenübertragung wird nun ein symmetrisches Verfahren benutzt, da dies große Datenmengen schneller verschlüsseln kann. Bei jeder Transaktion wird ein anderer symmetrischer Schlüssel als "Session Key" ausgehandelt, mit dem dann die Verbindung verschlüsselt wird. Ein Benutzer kann WWW-Seiten, die eine SSL-gesicherte Datenübertragung ermöglichen, beispielsweise daran erkennen, dass die Adresse um ein "s" erweitert ist (https://www...), dass am unteren Bildschirmrand im Netscape Navigator der sonst unterbrochene Schlüssel geschlossen ist oder dass im Internet Explorer das Vorhängeschloss geschlossen statt offen ist. Die Nutzung von SSL ist nicht auf HTTP-Clients und -Server beschränkt. Auch Anwendungen wie Telnet oder FTP können SSL zur sicheren Kommunikation nutzen. Allerdings setzt dies voraus, dass die betreffenden Clients und Server jeweils dafür angepasst werden. SSL besteht aus zwei Schichten. Auf der oberen Schicht arbeitet das SSL Handshake Protokoll. Dieses dient dem Client und dem Server dazu, sich gegenseitig zu identifizieren und zu authentisieren sowie dazu, für den anschließenden Datenverkehr einen Schlüssel und einen Verschlüsselungsalgorithmus auszuhandeln. Die untere Schicht, das SSL Record Protokoll, das die Schnittstelle zur TCP-Schicht bildet, verund entschlüsselt den eigentlichen Datenverkehr. Da SSL für den Zugriff auf TCP auf der Socket-Schnittstelle aufsetzt und diese durch eine sicherheitserweiterte Version ersetzt, ist sie auch für andere Dienste verwendbar. SSL läuft dadurch auch transparent im Hintergrund jedes Internet-Dienstes ab. Die Benutzer müssen nur bei Wahl eines Zertifikates aktiv werden. Ihnen fehlt somit - im Gegensatz zu S-HTTP - die Möglichkeit, die Sicherheitsfunktionen zu konfigurieren und ihren speziellen Sicherheitserfordernissen anzupassen. Dagegen mag SSL für Nutzer komfortabler erscheinen, die sich nicht bei jeder Web-Anfrage mit der Konfiguration von Sicherheitsfunktionen aufhalten wollen. SSL sollte nur ab Version 3 eingesetzt werden, da hier durch die zusätzliche Server-Authentikation keine "Man-in-the-Middle"-Angriffe wie bei SSLv2 mehr möglich sind. Status: Freigegeben Datum: Seite 85 von 146

87 Schlüssellänge Bei SSL können verschiedene kryptographische Algorithmen mit verschiedenen Schlüssellängen eingesetzt werden, so z. B. RC2 oder RC4 mit 40 oder 128 Bit Schlüssellänge, DES mit 56 Bit Schlüssellänge, Tripel-DES mit 112 Bit Schlüssellänge, IDEA mit 128 Bit Schlüssellänge und als Hashfunktionen z. B. MD5 oder SHA-1 (siehe hierzu auch M 3.23 Einführung in kryptographische Grundbegriffe). Beim Verbindungsaufbau müssen sich Client und Server auf die in der Sitzung verwendeten Verfahren einigen. In Browsern US-amerikanischer Hersteller sind aufgrund der US- Exportrestriktionen teilweise nur Verschlüsselungsverfahren mit extrem kurzen Schlüssellängen (40 Bit) integriert. Diese halten Brute-Force- Angriffen, d. h. Angriffen durch einfaches Ausprobieren aller möglichen Schlüssel, nicht lange stand. Bei einem geringen Schutzbedarf der übertragenen Daten kann diese kurze Schlüssellänge ausreichend sein und schützt zumindest vor Gelegenheitstätern. Ansonsten sollte auf Browser-Versionen zurückgegriffen werden, die Verschlüsselungsverfahren mit mindestens 80 Bit Schlüssellänge anbieten. Inzwischen sind internationale Versionen der gängigen Browser verfügbar, die 128 Bit Schlüssellänge unterstützen. Alternativ kann auf Zusatzprodukte einheimischer Hersteller zurückgegriffen werden, die ebenfalls innerhalb von Standard-Browsern die Benutzung längerer Schlüssel ermöglichen. Hierzu kann auch Public Domain Software wie SSLeay oder OpenSSL eingesetzt werden. Zertifikate Ein schwieriges Problem bei der Datenkommunikation über offene Netze ist die Überprüfung der Identität der Kommunikationspartner, da man sich nicht darauf verlassen kann, dass Namensangaben korrekt sind. Bei SSL erfolgt die Überprüfung der Identität des Kommunikationspartners über so genannte Zertifikate. Zertifikate enthalten deren öffentliche Schlüssel sowie eine Bestätigung einer weiteren Instanz über die korrekte Zuordnung des öffentlichen Schlüssels zu dessen "Besitzer", hier also ein Server oder Client. Der Wert eines Zertifikates hängt also nicht zuletzt davon ab, wie vertrauenswürdig diese Bestätigungsinstanz (auch Trustcenter oder Zertifizierungsstelle genannt) ist. Die Echtheit des Zertifikates lässt sich wiederum mit dem öffentlichen Schlüssel der Bestätigungsinstanz überprüfen. Bei SSL sind drei Varianten von Zertifikaten zu unterscheiden: Benutzerzertifikate, die für eine Client-Authentisierung benötigt werden, Status: Freigegeben Datum: Seite 86 von 146

88 Zertifikate von Zertifizierungsstellen, wobei manche Zertifizierungsstellen mehrere Zertifikate haben, je nach der zugrunde gelegten Sicherheitspolitik, und Zertifikate von Software-Herstellern bzw. Betreibern von Webseite Alle Browser enthalten bereits bei der Installation SSL-Zertifikate einiger Zertifizierungsstellen. Diese Zertifizierungsstellen haben sehr unterschiedliche Sicherheitsleitlinien und Bedingungen, unter denen sie Zertifikate erteilen. Daher sollten zunächst alle Zertifikate ausgeschaltet und erst dann wieder aktiviert werden, wenn man sich davon überzeugt hat, dass deren Sicherheitspolitik den eigenen Sicherheitsbedürfnissen genügt. Bei der Aufnahme eines neuen Zertifikates sollte darauf geachtet werden, dieses erst nach Überprüfung des "Fingerprints" zu aktivieren. Der Fingerprint ist eine hexadezimale Zahl, die zusammen mit dem Zertifikat übermittelt wird. Zusätzlich sollte sie auf einem anderen Weg übermittelt und verglichen werden, da diese die Korrektheit des Zertifikats sicherstellen soll. Betreiber von Application Servern, die mit den Besuchern ihrer WWW- Seiten sicherheitsrelevante Daten austauschen wollen, sollten hierzu einen kryptographisch abgesicherten Weg anbieten, also z. B. SSL. Hinweis: Sind die Benutzer durch eine Firewall vor aktiven Inhalten und Computer-Viren geschützt, so müssen sie bei der Verwendung von SSL eigene Schutzmaßnahmen gegen diese Gefährdungen treffen, wie z. B. in M 4.33 Einsatz eines Viren-Suchprogramms bei Datenträgeraustausch und Datenübertragung bzw. M 5.69 Schutz vor aktiven Inhalten beschrieben. Ergänzende Kontrollfragen: Verträgt sich die Nutzung von SSL mit den vorhandenen Sicherheitsleitlinien für die Firewall bzw. für die Nutzung von WWW-Diensten? Wissen die Benutzer, was bei der Nutzung von SSL zu beachten ist? Status: Freigegeben Datum: Seite 87 von 146

89 M 5.69 Schutz vor aktiven Inhalten Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Administrator Leiter IT, IT-Sicherheitsmanagement IT-Sicherheitsmanagement, Bis vor kurzem galten Firewalls als der Schutz schlechthin vor Angriffen aus dem Internet auf das eigene Netz. Sie stellten sicher, dass aus dem Internet heraus kein Verbindungsaufbau in das interne Netz möglich war und interne Nutzer problemlos auf Informationen im Internet zugreifen konnten. Aufgrund der immer größeren Verbreitung von so genannten aktiven Inhalten auf WWW-Seiten hat sich diese Situation allerdings geändert. Informationen aus dem Internet werden nicht mehr nur betrachtet, sondern teilweise wird beim Betrachten auch fremder Programmcode ausgeführt. Momentan ist hiermit Java, ActiveX und Javascript gemeint, künftig könnten auch noch weitere hinzukommen. Auch ist über so genannte Plug-Ins das Starten anderer Programme aus dem Browser heraus möglich, teilweise sogar automatisch aus einer HTML-Seite heraus. Je nach Art dieser Programme ist mit ihrem Ausführen eventuell ein Sicherheitsrisiko verbunden. Um ein internes Netz vor Missbrauch durch aktive Inhalte aus dem Internet zu schützen, sind aus heutiger Sicht mehrere Vorgehensweisen denkbar, die im folgenden anhand von Java, ActiveX und Javascript vorgestellt werden. Verbieten von aktiven Inhalten auf der Firewall Auch heute noch kann man sehr gut auf das Internet zugreifen, ohne wirklich aktive Inhalte zu benötigen. Dies ist die sicherste und deshalb empfohlene Methode für den Zugriff auf das Internet, da hiermit weiterhin die Firewall die Hauptkontrolle übernehmen kann. Um die Entgegennahme von aktiven Inhalten zu verhindern, benötigt man auf dem Application Gateway einen Proxy, der HTML-Seiten auf aktive Inhalte untersucht. Findet er diese, müssen sie aus der Seite herausgefiltert werden. Es gibt eine Reihe von Application Gateways, die diese Funktionalität bieten (siehe M 2.75 Geeignete Auswahl eines Application-Level-Gateways). Es muss allerdings davon ausgegangen werden, dass diese Lösung, obwohl sie die sicherste ist, in Zukunft eine immer geringere Akzeptanz finden wird, da die Anzahl derjenigen Seiten zunimmt, wo der aktive Inhalt die eigentliche Information enthält. Wird der aktive Inhalt herausgefiltert, kann der interne Benutzer nicht mehr auf diese Status: Freigegeben Datum: Seite 88 von 146

90 Information zugreifen. Hinweis: Auch in E Mails können aktive Inhalte versteckt sein, daher sollten auch diese daraufhin überprüft werden. Da verschlüsselte Kommunikation nicht auf aktive Inhalte überprüft werden kann, dürfen bei zentraler Filterung SSL-basierte WWW-Zugriffe nicht erlaubt werden. Verbieten von aktiven Inhalten im WWW-Browser Bei zentral administrierten Arbeitsplatzrechnern ist es denkbar, die Rechte der einzelnen Benutzer so weit einzuschränken, dass diese die Sicherheitseinstellungen ihres WWW-Browsers nicht mehr ändern können. Diese könnten dann so konfiguriert werden, dass aktive Inhalte nicht ausgeführt werden. Hierbei kann dann auch auf dem Application Gateway auf die Filterung nach aktiven Inhalten verzichtet werden, da aktive Inhalte unter diesen Umständen im internen Netz keinen Schaden mehr anrichten können. Eine andere Lösung ist, für den Zugriff auf das Internet nur bestimmte WWW-Browser zuzulassen. So gibt es nicht nur den Netscape Communicator und den Internet Explorer, sondern auch andere Browser, die keine Möglichkeiten zum Ausführen von aktiven Inhalten haben. Zum einen könnte die Verwendung solcher Browser durch eine entsprechende Verwaltung der Arbeitsplatzrechner sichergestellt werden. Hierbei müssen aber die Betriebssysteme der Arbeitsplatzrechner eine zuverlässige Rollentrennung zwischen Benutzer und Administrator bieten, damit vom Administrator voreingestellte Konfigurationen von den Benutzern nicht rückgängig gemacht werden können. Bei Betriebssystemen wie Windows 3.1 und Windows 95 sind daher zusätzliche Sicherheitsvorkehrungen notwendig. Zum anderen könnte der Proxy auf der Firewall so eingerichtet werden, dass nur Internet-Zugriffe einer vorgegebenen Browser-Software erlaubt sind. Hierbei ist allerdings zu berücksichtigen, dass die Sicherheit dieser Variante von der Kennung der verwendeten WWW-Browser abhängt. Mit einem Hex-Editor sollte ein versierter Benutzer keine Schwierigkeiten haben, einen WWW-Browser seiner Wahl so abzuändern, dass dieser die gewünschte Kennung hat. Sensibilisierung der Benutzer Es ist auch denkbar, die Verantwortung ganz in die Hände der Benutzer zu legen. Die aktiven Inhalte sollten im WWW-Browser im Regelfall abgeschaltet sein, die Benutzer haben aber die Erlaubnis, unter bestimmten Umständen auch aktive Inhalte auszuführen. Dies könnte z. B. der Fall sein, wenn sie auf das WWW-Informationsangebot eines Status: Freigegeben Datum: Seite 89 von 146

91 bekannten Herstellers ohne aktive Inhalte nicht mehr zugreifen können. Insbesondere ActiveX erlaubt mit seinen verschiedenen Sicherheitseinstellungen, das Ausführen von ActiveX auf bestimmte WWW-Server zu beschränken, so dass der Benutzer nicht dauernd seine Einstellungen ändern muss. Es ist aber zu bezweifeln, dass ein Benutzer wirklich immer wieder die Sicherheitseinstellungen seines WWW-Browsers ändert, wenn er auf eine andere WWW-Seite wechselt, wo ihn z. B. ein Link vom "bekannten Hersteller" hingeführt haben könnte. Außerdem kann eine einzelne Web- Seite auf einem "sicheren" Rechner auch weitere Web-Seiten laden, die sich auf "unsicheren" Rechnern befinden. Darüber hinaus sind Angriffe im Internet möglich, bei denen ein Benutzer gar nicht die WWW-Seite bekommt, die er angefordert hat (siehe z. B. G 5.48 IP-Spoofing und G 5.78 DNS-Spoofing). Filterung bestimmter aktiver Inhalte In der letzten Zeit sind Programme entwickelt worden, die analog zu Computer-Virensuchprogrammen aktive Inhalte daraufhin untersuchen, ob darin sicherheitsgefährdender Code enthalten ist. Dies ist für die Benutzer eine sehr akzeptable Lösung, da diese dann auf alle ungefährlichen aktiven Inhalte zugreifen können. Es stellt sich allerdings die Frage, ob solche Programme wirklich einen Schutz bieten. So kann beispielsweise ein Virensuchprogramm nicht vor trojanischen Pferden schützen, und solche können natürlich auch beträchtlichen Schaden anrichten. Ausführen aktiver Inhalte in einer geschützten Umgebung Java und Javascript sind so in den WWW-Browsern implementiert, dass diese in einer so genannten Sandbox ausgeführt werden. Wurde diese Sandbox richtig implementiert, so kann der aktive Inhalt nicht auf Daten außerhalb dieser Sandbox zugreifen. Zwar sind noch immer so genannte Verfügbarkeitsattacken (Denial of Service: DOS) möglich, aber die Vertraulichkeit und Integrität anderer Daten ist nicht gefährdet. Dieses Sandbox-Verfahren kann noch weiter ausgedehnt werden. Hierfür bieten sich zwei Verfahren an: 1. Auf einem Betriebssystem mit Rollentrennung kann der WWW- Browser unter der Kennung eines Benutzers mit minimalen Rechten laufen. Dadurch können aktive Inhalte keinen Schaden anrichten, falls die Rechteprüfung korrekt funktioniert. Auf einem Unix-Rechner ist es z. B. möglich, einen WWW-Browser in Status: Freigegeben Datum: Seite 90 von 146

92 einer change-root-umgebung zu starten, in der der WWW-Browser nur noch Zugriff auf ein eingeschränktes Dateisystem hat. Sollte ein aktiver Inhalt Schaden anrichten, so kann er dies nur innerhalb dieser eingeschränkten Umgebung. Damit ein Benutzer von seinem Arbeitsplatzrechner aus arbeiten kann, muss der WWW-Browser auf diesem angezeigt werden, was beispielsweise über X-Windows möglich wäre. Auch mit Windows NT ist ein solcher Aufbau möglich. 2. Es gibt neuerdings Proxies, die dem Arbeitsplatzrechner das Ausführen von Java-Applets abnehmen, d. h. das Java-Applet wird auf dem Proxy ausgeführt, aber auf dem Arbeitsplatzrechner angezeigt. Verglichen mit dem ersten Verfahren stellt dieser Ansatz einen wesentlich schonenderen Umgang mit der verfügbaren Netzbandbreite dar. Empfehlung: 1. Aktive Inhalte in Form von ActiveX sollten, wenn überhaupt, nur dann ausgeführt werden, wenn sie aus einer vertrauenswürdigen Quelle kommen, d. h. wenn sie signiert sind, diese Signatur auch verifiziert wurde und der Signierer vertrauenswürdig ist. 2. Java und Javascript sollten, wenn überhaupt, nur dann erlaubt werden, wenn diese aus einer vertrauenswürdigen Quelle kommen, oder aber, wenn obige Sicherheitsmaßnahmen nachprüfbar umgesetzt worden sind. 3. Es wird empfohlen, aktive Inhalte nicht nur von den WWW- Browsern kapseln zu lassen, sondern auch von einem dafür geeigneten Betriebssystem zusätzlich einzuschränken Beschaffung M 4.177* Sicherstellung der Integrität und Authentizität von Softwarepaketen Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator Durch unvorsichtiges Ausführen von Programmen, die aus "unsicheren" Quellen stammen, kann beträchtlicher Schaden entstehen. Bösartige Programme (so genannte Malware) können beispielsweise Programme zum Ausspähen von Passwörtern, Status: Freigegeben Datum: Seite 91 von 146

93 Trojaner oder Backdoors auf einem Computer installieren, oder ganz einfach Daten beschädigen oder löschen. Beliebte Quellen für solche Schadsoftware sind beispielsweise Programme, die sich als Windows Bildschirmschoner, Virenscanner oder sonstige Hilfsprogramme ausgeben, und per unter gefälschten Absenderadressen an sehr viele Empfänger verschickt werden. Oft laden auch unvorsichtige Anwender die Programme aus dem Internet herunter und installieren sie ohne Überprüfung. Software sollte grundsätzlich nur aus bekannten Quellen installiert werden, besonders dann, wenn sie nicht auf Datenträgern geliefert, sondern beispielsweise aus dem Internet heruntergeladen wurde. Dies gilt besonders für Updates oder Patches, die normalerweise nicht mehr auf Datenträgern ausgeliefert werden. Beispielsweise können die Installationspakete für die Java Umgebung bzw. die Java VM von der Website des Herstellers Sun Microsystems (http://java.sun.com/javase/downloads/index.jsp) heruntergeladen werden. Die Dateien werden von einer Seite heruntergeladen, die durch ein SSL-Serverzertifikat geschützt ist. Dieses Zertifikat ist in jedem Fall vor dem Herunterladen der Installationspakete zu prüfen. Ergänzende Kontrollfragen: Ist bekannt, ob für die Installationspakete mittlerweile Prüfsummen oder digitale Signaturen verfügbar sind? Sind die notwendigen Programme zur Überprüfung von Prüfsummen oder digitalen Signaturen verfügbar, sofern diese vom Hersteller eingesetzt werden? Werden digitale Signaturen, sofern verfügbar, überprüft? M 4.191* Überprüfung der Integrität und Authentizität der Application Server Pakete Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator Unabhängig davon, ob bei der Planung für den Einsatz des Application Servers entschieden worden ist, den Application Server entweder aus dem Quelltext zu kompilieren oder eine der Binärversionen zu verwenden, muss in jedem Fall die Integrität des Quellcode- oder Installationspaketes, das aus dem Internet Status: Freigegeben Datum: Seite 92 von 146

94 heruntergeladen wurde, überprüft werden (siehe auch M Sicherstellung der Integrität und Authentizität von Softwarepaketen). Vor der Installation des Application Servers aus einem Paket, das aus dem Internet geladen wurde, sollte stets die Integrität und Authentizität der Software durch Kontrolle der entsprechenden Signatur überprüft werden. Es bieten sich eine oder mehrere der folgenden Methoden an: Verwendung einer KEYS Datei, die bereits vor längerer Zeit vom zentralen Webserver des Application Server Projektes (und nicht von einem Spiegelserver) heruntergeladen wurde. Verwendung von KEYS Dateien von mehreren Spiegelservern. Verwendung einer KEYS Datei aus einer bereits auf CD-ROM vorhandenen Version des Application Servers. Prinzipiell genügt es schon, nur den Fingerabdruck (englisch: Fingerprint) des jeweiligen benutzten öffentlichen GPG-Schlüssels zu vergleichen. Die Herkunft der zu installierenden Software sollte ebenso wie der Prozess der Integritätsprüfung der Software dokumentiert werden. Ergänzende Kontrollfragen: Wurde eine Integritätsprüfung der Software vorgenommen? Sind die Herkunft der Software und die vorgenommene Integritätsprüfung dokumentiert? Umsetzung M Schutz gegen SQL-Injection Verantwortlich für Initiierung: IT-Sicherheitsmanagement, Leiter IT Verantwortlich für Umsetzung: Administrator, Anwendungsentwickler Um die Ausnutzung von SQL-Injections (siehe G SQL-Injection) zu verhindern oder zumindest zu erschweren, sind eine Reihe von Maßnahmen zu ergreifen. Diese erstrecken sich über alle Status: Freigegeben Datum: Seite 93 von 146

95 Komponenten einer Anwendung, von der Applikation selbst über den Server bis hin zum Datenbank-Managmentsystem (DBMS). Maßnahmen bei der Programmierung von Applikationen Eine der wichtigsten Maßnahmen zur Vermeidung von SQL-Injection ist die sorgfältige Überprüfung und Filterung von Eingaben und Parametern durch die Applikation. Überprüft werden sollte, ob die übergebenen Daten dem erwarteten Datentyp entsprechen. Wird z. B. ein numerischer Parameter erwartet, kann man diesen in PHP ("PHP: Hypertext Preprocessor") mit der Funktion is_numeric() prüfen. Die Filterung hingegen muss dafür sorgen, dass Sonderzeichen wie das Quote-Zeichen ('), das Semikolon (;) und doppelte Bindestriche (--) ignoriert werden. Sicherer ist der Einsatz von Stored Procedures beziehungsweise Prepared SQL-Statements (Java = PreparedStatement-Klasse, PHP- MySQL = mysql_real_escape_string()-funktion). Diese werden von vielen Datenbank-Managementsystemen (DBMS) angeboten und sind ursprünglich dazu gedacht, häufiger auftretende Abfragen zu optimieren. Der Vorteil dieser parametrisierten Statements ist, dass Parameter nicht mehr direkt in ein SQL-Statement eingebunden werden. Vielmehr werden diese getrennt vom SQL-Statement separat an die Datenbank übergeben. Das Zusammenführen von Statement und Parametern erfolgt durch das DBMS selbst, wobei die oben genannten Sonderzeichen automatisch maskiert werden. Um potentiellen Angreifern keine Anhaltspunkte für Angriffe zu liefern, sollte besonderes Augenmerk darauf gelegt werden, dass Applikationen möglichst keine Fehlermeldungen nach außen ausgeben, die Rückschlüsse auf das verwendete System oder auf die Struktur der dahinterliegenden Datenbank zulassen. Serverseitige Maßnahmen Die wichtigste Sicherheitsmaßname auf dem Server ist das Härten des Betriebssystems. Um so wenig Angriffspunkte wie möglich zu bieten, werden dabei Maßnahmen ergriffen wie: das Deaktivieren nicht benötigter Dienste, das Löschen nicht benötigter Benutzerkonten, das Einspielen relevanter Patches, das Löschen aller für die Funktion des Servers unnötigen Status: Freigegeben Datum: Seite 94 von 146

96 Bestandteile. Darüber hinaus sollte der Einsatz eines Application-Level-Gateways (ALG) (siehe M Integration eines Datenbank-Servers in ein Sicherheitsgateway) erwogen werden. ALGs können auf Applikationsebene die Daten überwachen, die zwischen Webbrowser und Anwendung ausgetauscht werden, und verhindern, dass schädliche Daten den Server erreichen. Eine weitere zusätzliche Sicherheitsmaßnahme stellt der Einsatz von Intrusion-Detection-Systemen (IDS) und Intrusion-Prevention-Systemen (IPS) dar. IDS analysieren den über ein Netz übertragenen Datenverkehr und erkennen potentiell gefährliche Daten. Die dazu eingesetzten Analysetechniken unterteilen sich in Misuse und Anomaly Detection. Die Misuse Detection versucht, bereits bekannte Angriffsmuster zu erkennen. Die Anomaly Detection verfolgt den Ansatz, die zulässigen Verhaltensmuster zu lernen und Abweichungen davon als Angriff zu identifizieren. Während ein IDS in der Lage ist, Angriffe zu erkennen und Warnungen auszugeben, ist ein IPS in der Lage, entsprechende Reaktionen auszuführen. Die Reaktion kann beispielsweise darin bestehen, die Verbindung zu blockieren, Daten zu verwerfen oder zu ändern. Bei erhöhten Sicherheitsanforderungen sollte geprüft werden, ob der Einsatz von IDS beziehungsweise IPS zweckmäßig ist. Datenbankseitige Maßnahmen Ebenso wie beim Betriebssystem sollte auch eine Härtung der Datenbank erfolgen. Im Falle der Datenbank bedeutet dies z. B.: das Entfernen nicht benötigter Stored Procedures, das Deaktivieren nicht benötigter Dienste, das Löschen nicht benötigter Benutzerkonten und Default Accounts, das Einspielen relevanter Patches. In diesem Zusammenhang sollte auch ein speziell für den Datenbankzugriff vorgesehener Account angelegt werden, der mit möglichst eingeschränkten Zugriffsrechten auskommen sollte. Darüber hinaus sollten sensitive Daten, wie z. B. Passwörter, in der Datenbank soweit möglich nur verschlüsselt gespeichert werden. Von vielen Herstellern werden mittlerweile sogenannte Status: Freigegeben Datum: Seite 95 von 146

97 Schwachstellen-Scanner angeboten, die sowohl Applikationen als auch Datenbanken auf Sicherheitslücken, wie beispielsweise mögliche SQL-Injections, überprüfen können. M 3.37* Schulung der Administratoren eines Application Servers Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement IT-Sicherheitsmanagement Um den Application Server korrekt und sicher administrieren zu können, ist eine Schulung der verantwortlichen Administratoren unumgänglich. Schon kleine Konfigurationsfehler können dazu führen, dass Sicherheitslücken entstehen. Besonders die korrekte Konfiguration von Zugangsbeschränkungen zu bestimmten Bereichen der Webanwendungen erfordert gute Kenntnisse der vorhandenen Möglichkeiten und ihrer Beschränkungen. Aufgrund der starken Interaktion zwischen den Sicherheitsmechanismen der Apache Tomcat Software und des zugrundeliegenden Betriebssystems müssen den Administratoren des Application Servers auch die Sicherheitsmechanismen des Betriebssystems bekannt sein. Dies gilt auch dann, wenn die Administratoren des Application Servers nicht gleichzeitig auch für die Administration des Betriebssystems zuständig sind. Neben den Aspekten der allgemeinen Betriebssystemsicherheit sollten folgende Aspekte Gegenstand der Schulung sein: Methoden der Installation des Application Servers (Installation über die Paketverwaltung des Betriebssystems, Binärversionen der Apache Foundation, gegebenenfalls Kompilieren aus dem Quellcode). Konfigurationsmöglichkeiten des Application Servers, Syntax der Konfigurationsdateien. Konfigurationsmöglichkeiten der Protokollierungsmechanismen des Application Servers und der Webanwendungen. Möglichkeiten zur Einbindung des Application Servers in den Startprozess des Betriebssystems. Mechanismen der Benutzerauthentisierung beim Application Server, Einsatzgebiete, Vor- und Nachteile der einzelnen Status: Freigegeben Datum: Seite 96 von 146

98 Mechanismen. Einrichten und Verwalten von Zugangsbeschränkungen beim Application Server. Zusammenspiel der Konfiguration von Zugangsbeschränkungen in der Apache-Konfiguration mit Zugriffsberechtigungen auf Betriebssystem- und Dateiebene, beispielsweise bei Verwendung des Security Managers. Möglichkeiten zur Aufteilung von Kompetenzen zwischen den Server-Administratoren und "Redakteuren", Entwicklung von Rechte- und Rollenkonzepten. Möglichkeiten zur Abbildung eines "organisatorischen" Rechteund Rollenkonzepts mit Hilfe der Benutzer- und Rollenverwaltung des Betriebssystems. Einsatzmöglichkeiten und Konfiguration von SSL beim Application Server. Maßnahmen zur Sicherstellung der Verfügbarkeit beim Application Server. Datensicherung beim Application Server. Ergänzende Kontrollfragen: Sind die Administratoren auf den Umgang mit dem Application Server vorbereitet und insbesondere in sicherheitsrelevanten Aspekten geschult? Sind die Administratoren im Umgang mit dem genutzten Betriebssystem und seinen sicherheitsrelevanten Aspekten geschult? M 4.94* Schutz der Dateien des Application Servers und der Webanwendungen Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator Die Dateien und Verzeichnisse auf einem Application Server müssen gegen unbefugte Veränderungen, aber auch - je nach Sicherheitsanforderungen - gegen unbefugten lesenden Zugriff Status: Freigegeben Datum: Seite 97 von 146

99 geschützt werden. Dies gilt zusätzlich und ganz besonders für die verwendete Java VM. Generelle Aspekte Generell muss zwischen zwei verschiedenen Aspekten unterschieden werden, nämlich dem Schutz vor unbefugtem Zugriff lokaler Benutzer und dem Schutz vor unbefugtem Zugriff von außen über das WWW. Schutz vor unbefugten Veränderungen Beim Application Server und bei vielen Webanwendungen ändern sich nur die Protokolldateien ständig, alle anderen Dateien sind statisch. Die Schreib- und Leserechte der Dateien der Webanwendungen sollten als lokale Dateien nur berechtigten Benutzern Zugriff erlauben. Daher sollte bereits bei der Planung des Webangebots ein Benutzerund Rollenkonzept erstellt werden (siehe auch M Festlegung einer WWW-Sicherheitsstrategie). Um sicherzustellen, dass keine Dateien auf dem Webserver unbemerkt abgeändert werden können, können über alle statischen Dateien, Klassen, Bibliotheken und Verzeichnisse Prüfsummen gebildet werden, z. B. mit einem Programm wie tripwire, siehe auch M 4.93 Regelmäßige Integritätsprüfung. Diese sollten dann regelmäßig überprüft werden. Um zu verhindern, dass Dateien der Webanwendungen überhaupt von Unbefugten geändert werden können, können statische Daten auf einem schreibgeschützten Speichermedium (z. B. CD-ROM oder Festplatte mit Schreibschutz) gespeichert werden. Da das Webangebot nicht nur aus statischen HTML-Dateien besteht, sondern fast alle Inhalte dynamisch erzeugt werden, müssen die dazu benutzten Programme (Java Server Pages und Java Servlets) besonders sorgfältig programmiert werden, um zu verhindern, dass auf diesem Weg ein unbefugter Zugriff oder gar eine Kompromittierung des Servers erfolgen kann. Auf dem Server müssen die Webanwendungen vor unbefugtem Zugriff geschützt werden. Nur die Benutzer oder Benutzergruppen, die unbedingt Zugriff auf diese Programme oder Skripte brauchen (etwa Entwickler oder Administratoren), dürfen eine Schreibberechtigung haben. Normalerweise dürfen die Programme nicht für den Benutzer schreibbar sein, unter dessen Kennung der Webserver-Prozess ausgeführt wird. Für normale Benutzer sollten insbesondere Skripte nicht lesbar sein, da diese eventuell sensitive Status: Freigegeben Datum: Seite 98 von 146

100 Informationen wie Authentisierungsdaten für den Zugriff auf Datenbanken enthalten können. Gleiches gilt für eventuell vorhandene Konfigurationsdateien. Schutz vor unbefugtem Zugriff über das Internet Der Zugriff über das WWW auf Dateien oder Verzeichnisse eines Application Servers kann auf verschiedene Arten gesteuert werden. Die folgenden Möglichkeiten sind verbreitet und werden von den meisten Webservern und Clients unterstützt. Authentisierung von Clients über IP Adressen Der Zugriff auf Webanwendungen kann auf frei wählbare IP- Adressen, Teilnetze oder Domänen beschränkt werden. Die Authentisierung über numerische IP-Adressen bietet nicht den Schutz kryptographischer Verfahren, da sie über einen auf IP-Spoofing basierenden Angriff unwirksam gemacht werden kann. Bei IP- Spoofing fälscht ein Angreifer IP-Pakete, um vorzugeben, von einem vertrauenswürdigen IT-System zu kommen (siehe G 5.48 IP- Spoofing). Über eine Firewall kann jedoch verhindert werden, dass Externe vortäuschen können, Interne zu sein. Wird der Zugriff nicht auf numerische IP-Adressen oder Teilnetze sondern auf bestimmte Rechnernamen oder Domainnamen beschränkt, ist außerdem die Gefährdung durch DNS-Spoofing (siehe G 5.78 DNS-Spoofing) zu betrachten. Wenn der WWW-Browser über einen Proxy-Server auf den Application Server zugreift, ist zu bedenken, dass der Tomcat Server nur die IP-Adresse des Proxy erfährt. Ein Proxy kann aber nur dann als vertrauenswürdig angesehen werden, wenn alle IT-Systeme und Benutzer, die hinter ihm verborgen sind, ebenfalls vertrauenswürdig sind. Wenn der Zugriff auf Webanwendungen auf vorgegebene IP- Adressen, Teilnetze oder Domänen beschränkt wird, kann es daher sinnvoll sein, diese zusätzlich mit einem Passwort zu schützen. Passwortschutz Eine weitere Möglichkeit der Zugriffssteuerung stellt der Schutz über Benutzernamen und Passwörter dar. Der Benutzer gibt beim erstmaligen Zugriff auf ein entsprechend geschütztes Verzeichnis in seinem Browser einen Benutzernamen und ein Passwort an, das zum Zugriff auf die entsprechende Ressource berechtigt. Über das Protokoll HTTP lässt sich ein Passwortschutz (Benutzer- Authentisierung) auf verschiedene Arten realisieren, die sich im Status: Freigegeben Datum: Seite 99 von 146

101 Bezug auf Implementierungsaufwand und Sicherheit unterscheiden. In Abhängigkeit von den Sicherheitsanforderungen muss eine geeignete Methode zur Benutzer-Authentisierung ausgewählt werden. Bei höheren Sicherheitsanforderungen sollte SSL zur Verschlüsselung der Datenübertragung und gegebenenfalls auch zur Benutzer-Authentisierung über Client-Zertifikate eingesetzt werden. Näheres ist in M Auswahl einer Authentisierungsmethode für Webangebote beschrieben, Informationen zu SSL finden sich in M 5.66 Verwendung von SSL. Ergänzende Kontrollfragen: Wie werden die Dateien der Webanwendungen gegen unbefugten lokalen Zugriff geschützt? - Sind Konfigurationsdateien besonders geschützt? M 4.1* Passwortschutz für IT-Systeme Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement Verantwortlich für Umsetzung: Benutzer Der Passwortschutz eines IT-Systems soll gewährleisten, dass nur solche Benutzer einen Zugriff auf die Daten und IT-Anwendungen erhalten, die eine entsprechende Berechtigung nachweisen. Unmittelbar nach dem Einschalten des IT-Systems muss der Berechtigungsnachweis erfolgen. Kann der Benutzer die erforderliche Berechtigung nicht nachweisen, so verhindert der Passwortschutz den Zugriff auf das IT-System. Realisiert werden kann der Passwortschutz an einem IT-System auf verschiedene Weise: Die meisten BIOS-Varianten bieten die Installation eines Boot-Passwortes an. Bei Fehleingaben wird der Boot- Vorgang nicht fortgesetzt. Ein BIOS-Passwort ist nicht schwer zu überwinden, schützt aber vor Zufallstätern, sollte also zumindest überall da eingesetzt werden, wo keine besseren Zugriffsschutzmechanismen vorhanden sind (siehe auch: M 4.84 Nutzung der BIOS- Sicherheitsmechanismen). Gute Betriebssysteme enthalten bereits Zugriffsschutzmechanismen. In den meisten Fällen Status: Freigegeben Datum: Seite 100 von 146

102 müssen diese aber noch aktiviert werden, beispielsweise durch die Vergabe von Passwörtern für alle Benutzer. Näheres hierzu findet sich in den betriebssystemspezifischen Bausteinen. Es wird Zusatzhardware oder -software installiert, die vor dem eigentlichen Start des Rechners ein Passwort abfragt und bei falscher Passworteingabe die weitere Nutzung des IT-Systems verhindert. Die verwendeten RMI-Protokolle beim Zugriff auf Application-Server und/oder Web Services erlauben in der Regel ebenfalls mindestens eine Authentisierung mit einem Benutzernamen und einem Passwort. Für den Umgang mit Passwörtern sind die Hinweise in M 2.11 Regelung des Passwortgebrauchs zu beachten, insbesondere ist das Passwort regelmäßig zu ändern. Ergänzende Kontrollfragen: Ist auf den betroffenen Rechnern ein Passwortschutz installiert? Sind die vom IT-System angebotenen Dienste mindestens mit einem Paßwortschutz versehen? M 4.42 Implementierung von Sicherheitsfunktionalitäten in der IT-Anwendung Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement, Datenschutzbeauftragter, Verantwortliche der einzelnen IT- Anwendungen Verantwortlich für Umsetzung: Anwendungsentwickler Mehrere Gründe können zu der Notwendigkeit führen, dass innerhalb der Anwendungsprogramme selbst Sicherheitsfunktionalitäten wie eine Zugangskontrolle, eine Zugriffsrechteverwaltung und -prüfung oder eine Protokollierung implementiert werden müssen: Reichen die Protokollierungsmöglichkeiten des IT- Systems einschließlich zusätzlich eingesetzter IT- Sicherheitsprodukte nicht aus, um eine ausreichende Beweissicherung zu gewährleisten, so müssen diese Protokollelemente im Anwendungsprogramm implementiert werden. (Beispiel: BDSG, Anlage zum 9, Eingabekontrolle: "zu gewährleisten, dass nachträglich überprüft und festgestellt werden kann, welche Status: Freigegeben Datum: Seite 101 von 146

103 personenbezogenen Daten zu welcher Zeit von wem in Datenverarbeitungssysteme eingegeben worden sind".) Reicht die Granularität der Zugriffsrechte des IT-Systems einschließlich zusätzlich eingesetzter Sicherheitsprodukte nicht aus, um einen ordnungsgemäßen Betrieb zu gewährleisten, so muss eine Zugriffsrechteverwaltung und -kontrolle im Anwendungsprogramm implementiert werden. (Beispiel: eine Datenbank mit einer gemeinsamen Datenbasis. Vorausgesetzt sei, dass je nach Funktion des Benutzers nur Zugriffe auf bestimmte Felder zulässig sind.) Ist es mit dem IT-System einschließlich zusätzlich eingesetzter IT-Sicherheitsprodukte nicht möglich, den Administrator daran zu hindern, auf bestimmte Daten zuzugreifen oder zumindest diesen Zugriff zu protokollieren und zu kontrollieren, dann muss dies bei Bedarf durch zusätzliche Sicherheitsfunktionen im Anwendungsprogramm implementiert werden. Zum Beispiel kann mit einer Verschlüsselung der Daten verhindert werden, dass der Administrator diese Daten im Klartext liest, wenn er nicht im Besitz des zugehörigen Schlüssels ist. Diese zusätzlichen Anforderungen an IT-Anwendungen müssen schon in der Planung und Entwicklung berücksichtigt werden, da eine nachträgliche Implementation meist aus Kostengründen nicht mehr möglich ist. Ergänzende Kontrollfragen: Wird bei der Entwicklung neuer IT-Anwendungen systematisch festgestellt, welche Sicherheitsfunktionen die Anwendung bereitstellen muss? M 4.95* Minimales Betriebssystem Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator Rechner in einem sicherheitskritischen Umfeld sollten so konzipiert sein, dass sie möglichst wenig Angriffspunkte bieten. Da heutige Betriebssysteme standardmäßig viele Netzdienste bereitstellen, reicht für den Betrieb eines sicheren Servers ein gut konzipierter Serverdienst (z. B. ein SSL-basierter Webserver) nicht aus. Vielmehr Status: Freigegeben Datum: Seite 102 von 146

104 muss auch das Betriebssystem abgesichert werden, da ansonsten über eine Schwachstelle im Betriebssystem die Sicherheitsfunktionen des Serverdienstes umgangen werden könnten. Ein sogenanntes minimales Betriebssystem zeichnet sich dadurch aus, dass es im Idealfall keinen einzigen Netzdienst zur Verfügung stellt. Ein potentieller Angreifer kann also eine Schwachstelle in einem Netzdienst dieses Betriebssystems nicht ausnutzen. Und sollte ein Angreifer doch durch eine Schwachstelle Zugriff auf den Rechner bekommen haben, so wird er durch das Minimalsystem weiter behindert. Je weniger Programme ein Angreifer auf einem Zielrechner vorfindet, desto schwieriger wird es für ihn, weitere Schwachstellen in dem Zielrechner zu finden bzw. auszunutzen. Außerdem erleichtert dies die Pflege eines Servers sehr stark, da die Patches bzw. Service Packs für Diensteprogramme nicht mehr eingespielt werden müssen, wenn diese nicht vorhanden sind. Im Folgenden wird die Konfiguration eines Betriebssystems anhand eines Internet-Servers beschrieben, da hier im allgemeinen sehr hohe Sicherheitsanforderungen an das Betriebssystem gestellt werden müssen. Ein Internet-Server hat meist nur eine einzige Aufgabe: stabil eine bestimmte Anzahl von Diensten (z. B. die Bereitschaft, entgegenzunehmen) anderen Rechnern zur Verfügung zu stellen. Das zugrunde liegende Betriebssystem sollte keine weiteren Dienste anbieten. Deshalb sollte bei der Installation eines Internet-Servers folgendes Vorgehen eingehalten werden: 1. Grundinstallation des Betriebssystems Kann man bei der Installation den Umfang der zu installierenden Pakete beeinflussen, so sollten schon hier nur die notwendigen Pakete eingespielt werden. Die Notwendigkeit bestimmter Pakete ist allerdings nicht immer zu erkennen, so dass zumindest die offensichtlich überflüssigen Pakete nicht eingespielt werden sollten. 2. Abschalten nicht benötigter Programme Beim Start eines Rechners werden eine Vielzahl von Programmen automatisch gestartet. Einige dieser Programme sind für einen Internet Server völlig überflüssig und sollten deaktiviert werden. Die Deaktivierung kann durch das Verhindern des automatischen Starts erfolgen (Startskripte unter Unix, Autostart und Dienstemanager unter Windows NT) und durch zusätzliches Löschen der entsprechenden Programme. Aus Gründen der Sicherheit wird das Löschen empfohlen, da dann ein Angreifer die Dienste nicht wieder reaktivieren kann. Allerdings ist es manchmal sehr schwierig, alle zu Status: Freigegeben Datum: Seite 103 von 146

105 einem bestimmten Dienst gehörigen Dateien zu finden und zu löschen, so dass im Zweifel das Löschen unterbleiben sollte. 3. Konfiguration der Netzparameter Falls dies nicht schon bei der Installation geschehen ist, müssen die Netzparameter des Internet-Servers eingestellt werden. Relevant für die Sicherheit des Internet-Servers sind unter anderem die Wahl eines Default Gateways und eines Domain Name Servers. Findet beispielsweise die Kommunikation des Internet-Servers mit dem Internet über einen Proxy (siehe M 2.73 Auswahl geeigneter Grundstrukturen für Sicherheits-gateways) statt, so ist ein Default Gateway überflüssig. Ohne ein Default Gateway ist eine direkte Antwort vom Internet-Server ins Internet nicht möglich, so dass bei Umgehung des Proxies keine Kommunikation, d. h. auch kein Angriff, stattfinden kann. Auch DNS ist für einen Internet-Server häufig überflüssig und sollte möglichst vermieden werden, da dies einen direkten Kommunikationskanal zum Betriebssystem ermöglicht (siehe M 4.96 Abschaltung von DNS). Zusätzlich gibt es noch eine Vielzahl von Parametern, die den sogenannten TCP/IP-Stack direkt beeinflussen, z. B. die maximale Größe von IP-Paketen. Diese Parameter sind extrem stark vom jeweiligen Betriebssystem abhängig, so dass hier nur das Abschalten von IP-Forwarding erwähnt werden kann. Weitere Änderungen könnten beispielsweise die Stabilität gegenüber fehlerhaften IP-Paketen oder aber auch den Netzdurchsatz erhöhen. 4. Abschalten nicht benötigter Netzdienste Einige benötigte Diensteprogramme stellen eine Vielzahl weiterer Dienste bereit (insbesondere ist hier der inetd unter Unix gemeint). Die entsprechenden Konfigurationsdateien sind auf die notwendigen Netzdienste einzuschränken (siehe auch M 5.16 Übersicht über Netzdienste). 5. Installation von Sicherheitsprogrammen Das Betriebssystem sollte um zusätzliche Sicherheitsprogramme erweitert werden, falls diese nicht schon Teil des Betriebssystems sind. Insbesondere sinnvoll sind ein Integritätsprüfprogramm (siehe M 4.93 Regelmäßige Integritätsprüfung) und ein Softwarepaketfilter (bei Windows NT schon enthalten). Empfehlenswert sind zusätzlich Programme zur Virensuche und zur Auswertung der Protokolleinträge. Ist eine Fernadministration des Internet-Servers gewünscht, so muss ein entsprechendes Sicherheitsprodukt installiert werden, z. B. der Secure Shell Daemon (siehe M 5.64 Secure Shell), und regelmäßig die Sicherheit des Systems überprüft werden (siehe Status: Freigegeben Datum: Seite 104 von 146

106 auch M 4.26 Regelmäßiger Sicherheitscheck des Unix-Systems). 6. Konfiguration und Überprüfung der Netzdienste Idealerweise stellt ein minimales Betriebssystem keinen einzigen Netzdienst zur Verfügung und ist somit von außen nicht angreifbar. Gerade in größeren Netzen ist dieses Vorgehen aufgrund der Administration nicht mehr praktikabel, so dass ein Fernzugang notwendig ist. Ob der Internet-Server Dienste bereitstellt, kann sowohl unter Unix als auch Windows NT mit dem Befehl netstat -a überprüft werden. Jeder der aufgelisteten Dienste sollte in seiner Konfiguration so eingeschränkt werden, dass nur berechtigte Rechner auf ihn zugreifen können (z. B. ist der Fernzugang zum Internet-Server auf die Rechner des Netzmanagements einzuschränken). 7. Löschen nicht mehr benötigter Programme Sobald die Installation eines minimalen Betriebssystems abgeschlossen ist, sollten verschiedene Programme gelöscht werden, die einem potentiellen Angreifer hilfreich sein könnten. Insbesondere sind eventuell vorhandene Compiler zu entfernen, da diese einem Angreifer ein wertvolles Hilfsmittel sein könnten. Außerdem sind Compiler auf Internet-Servern auch deshalb nicht sinnvoll, da diese Rechner Produktionsmaschinen sind und Programmentwicklung und Tests auf anderen Rechnern durchgeführt werden sollten. Ebenfalls denkbar ist das Löschen aller Editoren, was einem Angreifer die Manipulation von Konfigurationsdateien sehr stark erschweren würde. Allerdings ist dann auch die Administration komplizierter. Bei Änderungen an Konfigurationsdateien muss dann jeweils wieder ein Editor installiert werden oder aber, und dies ist empfehlenswert, die Konfigurationsdateien müssen auf einem anderen Rechner editiert und dann überspielt werden. Ein minimales Betriebssystem sollte natürlich kein Selbstzweck sein. Für einen Internet-Server muss selbstverständlich noch der eigentliche Serverdienst installiert werden. Ob dies am Ende der obigen Liste geschieht oder beispielsweise zwischen den Punkten 6 und 7 oder auch direkt nach Punkt 1, hängt von der jeweiligen Installation ab. Problematisch wird es, wenn die Installation wegen fehlender Betriebssystempakete fehlschlägt, da man dann die fehlenden Pakete suchen und selber nachinstallieren muss. Besser wäre es, der Hersteller des Serverdienstes gäbe die Betriebssystemabhängigkeiten an, so dass das Minimalsystem von Anfang an darauf ausgerichtet werden könnte. Auch ein mit einem Minimalsystem konfigurierter Rechner ist nicht gänzlich vor Angriffen geschützt. Die wahrscheinlichste Ursache für Status: Freigegeben Datum: Seite 105 von 146

107 einen erfolgreichen Angriff ist sicherlich der Serverdienst, aber auch das Minimalsystem selber ist noch angreifbar, insbesondere nämlich der TCP/IP-Stack, der die Netzpakete zur Applikation weiterleiten muss. Nahezu alle bisher bekannt gewordenen Angriffe gegen den TCP/IP-Stack betrafen allerdings nur die Verfügbarkeit, indem die betroffenen Rechner abstürzten, d. h. ein Eindringen in Rechner ist noch nicht beobachtet worden. Um auch diese Gefahr weiter zu verkleinern, sollte auch M 4.98 Kommunikation durch Paketfilter auf Minimum beschränken umgesetzt werden. Ergänzende Kontrollfragen: Sind nicht benötigte Programme bei den Servern deaktiviert worden? Sind alle nicht benötigten Netzdienste abgeschaltet? Werden die Server auf ihre Netzdienste regelmäßig überprüft? M 4.96 Abschaltung von DNS Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator Ein Internet-Server braucht normalerweise kein DNS (Domain Name System), um Informationen zur Verfügung zu stellen, es sei denn, über ihn wird die versandt, wovon aber abzuraten ist (siehe dazu auch M 4.97 Ein Dienst pro Server). So wird bei den meisten WWW-Servern DNS nur dazu verwendet, in den jeweiligen Protokolldateien Rechnernamen statt IP-Adressen einzutragen. Diese Umwandlung von IP-Adressen zu Rechnernamen könnte auch später bei der Analyse der Protokolldateien durchgeführt werden. Zwar ist dann der Umgang mit den Protokolldateien etwas umständlicher, aber die Vertrauenswürdigkeit der Protokolldaten steigt. Die Zuordnung zwischen einer IP-Adresse und einem Rechnernamen ist nämlich weder eindeutig noch statisch. Ein Verzicht auf DNS gibt zusätzlich Schutz vor DNS-Spoofing (siehe M 5.59 Schutz vor DNS-Spoofing) und erhöht häufig die Performance des Internet-Servers. Folgendes Szenario zeigt mögliche negative Auswirkungen: Ein Angreifer verfüge über eine eigene Domain mit einem Test-PC. Dieser Test-PC ist gleichzeitig auch DNS-Server für diese Domain. Mit dem Test-PC baut er eine Verbindung zu einem Internet-Server Status: Freigegeben Datum: Seite 106 von 146

108 auf. Der Internet-Server kennt am Anfang der Verbindungsanfrage nur die IP-Adresse des Test-PCs und versucht, sich über DNS den Rechnernamen des Test-PCs zu verschaffen. Zu diesem Zweck muss das Betriebssystem eine Verbindung mit einem DNS-Server aufnehmen, der sich wiederum die Daten von dem Test-PC holen muss, da dieser der DNS-Server der Angreifer-Domain ist. Anstatt nun dem DNS-Server des Internet-Servers zu antworten, kann der Angreifer nun auch direkt eine beliebige Antwort zum Internet-Server selber schicken (unter Verwendung von IP-Spoofing, siehe G 5.78). Auf diese Weise kann der Angreifer nicht nur Daten zu dem eigentlichen DNS-Server schicken, sondern auch direkt zum Internet- Server. Eventuelle Fehler in dessen Betriebssystem könnten so ausgenutzt werden. Hinweis: Soll beispielsweise der Zugriff auf einen WWW-Server nur einer bestimmten Domain erlaubt sein, z. B. nur *.de, so kann allerdings nicht auf DNS verzichtet werden. Jedoch ist ein solcher Zugriffsschutz sehr schwach und daher nicht empfehlenswert. Ergänzende Kontrollfrage: - Ist DNS bei den Internet Server abgeschaltet? M 4.97 Ein Dienst pro Server Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator Viele Schwachstellen in IT-Systemen sind einzeln nicht für einen potentiellen Angreifer ausnutzbar. Häufig wird erst durch die Kombination von Schwachstellen ein erfolgreiches Eindringen in einen Rechner möglich. Eine Empfehlung für den Betrieb von sicheren Servern ist deshalb: Verschiedene Dienste gehören auf verschiedene Rechner! Auf einem Minimalsystem (siehe auch M 4.95 Minimales Betriebssystem) sollte deshalb nur ein einziger Dienst aufgesetzt werden, also beispielsweise entweder ein WWW-Server oder ein E- Mailserver. Außerdem sind einzelne Dienste auch unterschiedlich in ihrer Sicherheitseinstufung. So ist ein erfolgreiches Eindringen in einen WWW-Server unter Umständen sehr ärgerlich, insbesondere wenn der Angreifer die extern verfügbaren WWW-Seiten abändert. Zugriff auf interne Informationen ist dem Angreifer hierdurch aber nicht möglich. Ist der WWW-Server aber gleichzeitig der E Mailserver, so kann der Angreifer unter Umständen den gesamten - Status: Freigegeben Datum: Seite 107 von 146

109 Verkehr mitlesen, was möglicherweise viel schlimmere Auswirkungen hat. Die Aufteilung kann sogar noch verstärkt werden, indem für einen einzelnen Dienst verschiedene Aufgaben auf unterschiedliche Rechner verteilt werden. So könnte es beispielsweise einen E- Mailserver A geben, der s aus dem Internet annimmt und in das interne Netz weiterleitet, und einen anderen server B, der s aus dem internen Netz an das Internet weiterleitet. Da die Kommunikationsaufnahme aus dem Internet nur mit dem E- Mailserver A möglich ist, kann ein Angreifer auch nur diesen attackieren. Der server A darf selber keine s in das Internet verschicken, deshalb kann dieser Rechner auch nicht für E- Mail-Spamming missbraucht werden. Eine Aufteilung verschiedener Dienste auf unterschiedliche Rechner hat unter anderem folgende Vorteile: Leichtere Konfiguration der einzelnen Rechner Einfachere und sicherere Konfiguration eines vorgeschalteten Paketfilters Erhöhte Widerstandsfähigkeit gegenüber Angriffen Erhöhte Ausfallsicherheit Eine eventuelle negative Auswirkung wie erhöhte Hardware-Kosten für die Anschaffung mehrerer Rechner sollte dadurch ausgeglichen werden können, dass die einzelnen Rechner weniger Leistung erbringen müssen und dadurch in der Summe bei gleicher Performance nicht teurer als ein besonders leistungsfähiger Rechner sein müssen. Auch muss der Administrationsaufwand nicht zwangsläufig mit der Anzahl der Rechner steigen, da eine einfachere Konfiguration der einzelnen Rechner für Zeitersparnis sorgt. Ergänzende Kontrollfrage: Wird darauf geachtet, nur einen Dienst pro Server anzubieten? M 4.98* Kommunikation durch Paketfilter auf Minimum beschränken Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator Status: Freigegeben Datum: Seite 108 von 146

110 Paketfilter sind IT-Systeme mit spezieller Software, die die Informationen der unteren Schichten des OSI-Modells filtern und entsprechend spezieller Regeln Pakete weiterleiten oder abfangen (siehe M 2.74 Geeignete Auswahl eines Paketfilters). Die Konfiguration eines Paketfilters, der zum Schutz von Internet- Servern eingesetzt wird, sollte sehr restriktiv sein, um die Widerstandsfähigkeit gegen Angriffe zu maximieren. Zwar sollte ein gut konfigurierter Internet-Server (siehe M 4.95 Minimales Betriebssystem) sich selbst vor Angriffen schützen können, jedoch ist die Software eines Internet-Servers viel komplexer und fehleranfälliger als die eines auf Sicherheit konzipierten Paketfilters. Der Paketfilter sollte nur diejenigen Kommunikationskanäle durchlassen, die für die Funktion der Internet-Server notwendig sind. Insbesondere ist nicht nur die Kommunikation zu kontrollieren, die vom Internet zum Internet-Server initiiert wird, sondern auch die Kommunikation, die der Internet-Server zum Internet hin aufbauen darf. Für viele Angriffe ist es eine notwendige Voraussetzung, dass der angegriffene Rechner neue Verbindungen zum Internet hin aufbauen kann. Ist dies nicht möglich, so sind auch viele Angriffe nicht erfolgreich. So war 1997 ein Angriff auf News-Server sehr "beliebt", bei dem sich der Angreifer über einen Fehler in einem News-Daemon per wichtige Systeminformationen zuschicken lassen konnte. Hätten die angegriffenen Rechner nicht die Berechtigung zum Verschicken von s gehabt, so hätte der Angreifer auch keine Rückmeldung bekommen. Der Angriff wäre nicht erfolgreich gewesen. Im Folgenden werden einige Beispiele für die Konfiguration von Paketfiltern für verschiedene Internet-Server dargestellt. 1. Application Server: Internet darf auf Port 8080 und 8443 des WWW-Servers TCP WWW-Server darf ins Internet von Port 8080 und 8443 TCP/ack, sonst nichts! 2. News-Server: Newsfeed-Server dürfen auf Port 119 des News-Servers TCP Status: Freigegeben Datum: Seite 109 von 146

111 News-Server darf von Port 119 auf Newsfeed-Server TCP/ack News-Server darf auf Port 119 der Newsfeed-Server TCP Newsfeed-Server dürfen von Port 119 auf den News-Server TCP/ack 3. server (Provider stellt -Gateway zur Verfügung): server des Providers darf auf Port 25 des servers TCP server darf von Port 25 auf server des Providers TCP/ack server darf auf Port 25 des servers des Providers TCP server des Providers darf von Port 25 auf server TCP/ack 4. server (eigenes Verschicken ins Internet): Internet darf auf Port 25 des servers TCP server darf von Port 25 ins Internet TCP/ack server darf auf Port 25 im Internet TCP Internet darf von Port 25 auf den server TCP/ack Werden nur diese Regeln implementiert, ist eine Kommunikationsaufnahme aus dem Internet nur auf die freigegebenen Dienste beschränkt. Können zusätzlich die Kommunikationspartner noch weiter eingeschränkt werden (siehe obige Beispiele 2 und 3), so kann ein Angreifer gar keine direkte Verbindung zu dem Internet-Server aufbauen. Hinweis: Obige Regeln können bewirken, dass der Internet-Server nicht von jedem Rechner aus erreicht werden kann, da ICMP nicht durchgelassen wird. Deshalb empfiehlt es sich, den ICMP Subtype icmp unreachable vom Internet hin zum Internet-Server durchzulassen. Ergänzende Kontrollfrage: Wird regelmäßig überprüft, ob die Kommuniktaion durch Status: Freigegeben Datum: Seite 110 von 146

112 Paketfilter auf ein Minimum reduziert wurde? M 4.99* Schutz gegen nachträgliche Veränderungen von Informationen Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator, Benutzer Dateien, die an Dritte weitergegeben werden, können von diesen im allgemeinen auch weiterbearbeitet werden. Dies ist nicht immer im Sinne des Erstellers. Daher wäre ein Schutz gegen nachträgliche Veränderungen, auszugsweise Weitergabe oder Verarbeitung wünschenswert. Häufig steht man vor dem Problem, dass Informationen über das Internet oder andere Netze Dritten zwar zur Verfügung gestellt, aber nicht hundertfach ausgedruckt oder nahtlos in andere Werke integriert werden sollen. Hierzu gibt es verschiedene Lösungen, die teilweise auch miteinander kombiniert werden können. Beispiele hierfür sind: Die Verwendung von digitalen Signaturen, um unbemerkte Änderungen an Dateien zu verhindern (siehe auch M 4.34 Einsatz von Verschlüsselung, Checksummen oder Digitalen Signaturen oder M 3.23 Einführung in kryptographische Grundbegriffe). Das Hinzufügen von Copyright-Vermerken zu WWW- Informationen oder Dateien. Diese können wie folgt lauten: "Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen des Urheberrechtsgesetzes ohne Zustimmung des Autors ist unzulässig und strafbar." sowie "Copyright ( ) 7/1999 by BSI". Die Verwendung von Dateiformaten, die nachträgliche Änderungen bzw. auszugsweise Weiterverarbeitung erschweren. Hierfür kann z. B. Postscript genutzt werden oder die Sicherheitseigenschaften von Anwendungsprogrammen, z. B. bei PDF-Dateien. PDF-Dokumente können bei der Erstellung mit Zugriffsbeschränkungen versehen werden. So kann z. B. das Öffnen, Drucken oder Kopieren von PDF-Dateien eingeschränkt werden. Mit Acrobat Exchange, also der Anwendung, mit der PDF-Dateien Status: Freigegeben Datum: Seite 111 von 146

113 erstellt und nachbearbeitet werden können, ist die Vergabe von zwei Arten von Passwörtern möglich. Die einen werden zum Öffnen des Dokuments, die anderen zum Ändern der Sicherheitsattribute benötigt. Gegen unbefugtes Öffnen geschützte PDF-Dokumente werden dabei mit RC4 verschlüsselt. Über die Sicherheitsattribute können folgende Funktionen eingeschränkt werden: Drucken Ändern des Dokuments Text oder Graphik auswählen Notizen und Formularfelder hinzufügen oder ändern So können sehr einfach die Rechte beschränkt werden, so dass niemand mit Cut and Paste die Inhalte einer Veröffentlichung übernehmen kann. Wenn im Extremfall sogar das Ausdrucken verhindert wird, kann die Datei nur online gelesen werden. Leider bietet dies nur einen rudimentären Schutz, da PDF-Dateien nämlich auch mit Programmen geöffnet werden können, die diese Sicherheitsattribute ignorieren. Solange z. B. Drucken erlaubt wird, kann das Dokument sogar jederzeit wieder in eine PDF-Datei ohne jegliche Einschränkungen verwandelt werden. Ergänzende Kontrollfragen: Welche Sicherheitsmaßnahmen werden ergriffen, damit Dateien nicht unerwünscht verändert werden? Status: Freigegeben Datum: Seite 112 von 146

114 M 4.192* Konfiguration des Betriebssystems für einen Application Server Verantwortlich für Initiierung: Administrator, IT- Sicherheitsmanagement Verantwortlich für Umsetzung: Administrator Das Betriebssystem des Rechners, auf dem ein ApacheTomcat Server installiert werden soll, muss vor der Installation sicher und möglichst "schlank" konfiguriert werden. Der Rechner sollte keine anderen als die zum Betrieb des Servers nötigen Dienste nach außen anbieten. Alle anderen nicht benötigten Systemdienste und Programme sollten so weit wie möglich entfernt werden. Allgemeine Hinweise zur Konfiguration finden sich beispielsweise in den Bausteinen B Unix-Server und B Windows 2000 Server. Diese Maßnahme beschreibt einige zusätzliche Schritte, die unternommen werden sollten, wenn ein Rechner für die Installation eines Application Servers vorbereitet wird. Auf dem Server-Rechner sollte nur die Java Laufzeitumgebung (JRE) installiert sein. Soll der Application Server aus den Quelltexten kompiliert werden, so sollte dies nicht auf dem Produktionsrechner geschehen, sondern auf einem entsprechend ausgestatteten und konfigurierten Entwicklungsrechner. Client-Programme zum Einloggen auf andere Rechner oder zum Herunterladen von Dateien aus dem Internet (beispielsweise sshoder Telnet-Clients, Webbrowser, ftp-clients oder wget) sollten möglichst nicht auf dem Webserver installiert sein, sofern sie nicht für den Betrieb des Webservers unbedingt benötigt werden. Sind keine derartigen Programme installiert, so kann dies weniger versierte Angreifer daran hindern, nach dem erfolgreichen Ausnutzen einer Sicherheitslücke den Webserver dauerhaft zu kompromittieren, da sie dazu oft Dateien (etwa rootkits oder Backdoor-Programme) von anderen Rechnern unter ihrer Kontrolle herunterladen müssen. Das Verzeichnis, das für die Logdateien des Application Servers und der aktiven Webanwendungen vorgesehen ist, sollte ebenfalls in einem eigenen Filesystem bzw. auf einer eigenen Partition angelegt werden. Je nach Auslastung des Servers und dem gewählten Logformat können die Logdateien schnell eine beträchtliche Größe annehmen. Daher sollte das entsprechende Filesystem von vorne herein genügend groß angelegt werden. Unter Windows sollte auf Status: Freigegeben Datum: Seite 113 von 146

115 jeden Fall NTFS als Dateisystem gewählt werden, da FAT keine sinnvolle Benutzertrennung und Rechtevergabe erlaubt. Sofern das Betriebssystem verschiedene Filesystem-Typen unterstützt, sollte ein Filesystem gewählt werden, das eine möglichst gute Performance beim Lesen von Dateien bietet. Erfolgt die Administration des Serverrechners nicht lokal, so sollten zur Administration des Server-Betriebssystems nur entsprechend sichere Produkte bzw. Protokolle verwendet werden. Gleiches gilt, falls die WWW-Dateien nicht über Wechseldatenträger, sondern über das Netz auf den Webserver übertragen werden. Telnet und ftp sollten nicht eingesetzt werden, stattdessen sollte ssh bzw. sftp benutzt werden. Bei der Standardinstallation eines Betriebssystems werden oft Accounts (Benutzerkonten) angelegt, die in der Minimalkonfiguration, wie sie für einen Webserver hergestellt werden sollte, nicht benötigt werden. Diese Accounts sollten gelöscht oder zumindest deaktiviert werden. Stattdessen sollte für den Application Server ein eigener Account (etwa tomcat) und eine eigene Gruppe eingerichtet werden, der über möglichst wenig Rechte verfügt. Unter diesem Account sollte insbesondere keine interaktive Anmeldung am System möglich sein. Dazu kann dem Tomcat-Account beispielsweise auf den meisten Unix-Systemen die Login-Shell /bin/false zugeordnet werden. Soll der Rechner als öffentlicher Server dienen und in einer Firewall- Umgebung aufgestellt werden, so sollte in Erwägung gezogen werden, die Logdateien des Systems und gegebenenfalls auch des Application Servers nicht nur auf dem Rechner selbst zu speichern, sondern auf einen zweiten Rechner zu kopieren. Wie dies konkret implementiert wird, hängt stark von der jeweiligen Einsatzumgebung ab, so dass an dieser Stelle keine detaillierten Empfehlungen gegeben werden können. Prinzipiell sollte jedoch die Übertragung der Logdaten auf den anderen Rechner so gelöst werden, dass keine Verbindung aus der Firewall-Umgebung in das interne Netz geschaffen wird, die eventuell von einem Angreifer ausgenutzt werden könnte. Ergänzende Kontrollfragen: Wurden unnötige Accounts gelöscht? Wurde auch die Berechtigungen auf die Java VM entsprechend gesetzt? Welche Skript-Interpreter und Compiler sind auf dem Webserver-Rechner installiert? Wozu werden diese Status: Freigegeben Datum: Seite 114 von 146

116 gegebenenfalls benötigt? Auf welche Art erfolgt die Administration des Systems? Wie sieht das Partitions- bzw. Filesystem-Layout des Systems aus? Werden Logdaten auf einen weiteren Rechner übertragen? M Sichere Installation eines Application Servers Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator Bei der Installation eines Application Servers sind verschiedene Aspekte zu berücksichtigen, die direkten Einfluss auf die Sicherheit haben. Das Betriebssystem des Webserver-Rechners muss sicher installiert und konfiguriert sein. Dazu müssen die entsprechenden IT- Grundschutz-Bausteine umgesetzt werden. Darüber hinaus gibt M Konfiguration des Betriebssystems für einen Application Server Hinweise, welche zusätzlichen Schritte auf dem Rechner durchgeführt werden sollten, der den Application Server beherbergen soll. Ein wichtiger Aspekt, der bei der Installation des Application Servers beachtet werden muss, ist die Integrität der zu installierenden Software (siehe M Überprüfung der Integrität und Authentizität der Apache Tomcat Pakete). Die mit dem Application Server mitgelieferte Dokumentation ist sehr detailliert und beschreibt die notwendigen Schritte recht ausführlich. Diese Grundschutz-Maßnahme kann die mitgelieferte Dokumentation nicht ersetzen, sondern lediglich Hinweise auf Punkte geben, die besonders zu beachten sind. Sie bezieht sich auf die Installation einer Binärversion von der Apache-Foundation oder eines aus dem Quellcode kompilierten Application Servers. Tomcat Versionen von Betriebssystemherstellern oder Distributoren können davon abweichen. Das Kompilieren des Application Servers aus dem Quellcode sollte nicht als root oder Systenadministrator erfolgen. Nachdem die Integrität und Authentizität des Quellcodepackets anhand der digitalen Signaturen überprüft wurde, sollten das Entpacken, die Konfiguration (configure, Festlegung des Installationsverzeichnisses Status: Freigegeben Datum: Seite 115 von 146

117 sowie von Vorgabewerten, die fest einkompiliert werden, sowie der zu kompilierenden Module) und der eigentliche Übersetzungsvorgang (make) unter einem unprivilegierten Benutzeraccount durchgeführt werden. Erst der letzte Schritt, die eigentliche Installation des übersetzten Programms (make install) muss gegebenenfalls mit höheren Privilegien erfolgen. Wird das Zielverzeichnis der Installation vorab manuell angelegt und erhält der unprivilegierte Benutzeraccount Schreibberechtigung für dieses Verzeichnis, so kann selbst dieser letzte Schritt unter diesem Account durchgeführt werden. Wird der Application Server aus dem Quellcode übersetzt, so muss genau dokumentiert werden, welche Konfigurationsoptionen dabei gewählt wurden. Die Konfiguration muss sich anhand dieser Dokumentation jederzeit nachvollziehen und reproduzieren lassen. Es empfiehlt sich auch, ein Protokoll der Ausgaben des Konfigurationsund Übersetzungslaufs (beispielsweise durch Umleiten der Ausgaben in eine Datei) anzufertigen und aufzubewahren. Bei der Installation des Application Servers werden im Zielverzeichnis der Installation mehrere Unterverzeichnisse erstellt. Als Zielverzeichnis unter Unix wird im Rahmen dieser Maßnahme das Verzeichnis /usr/share/apache-tomcat angenommen, unter Windows d:\programme\apache-tomcat. Das Unterverzeichnis conf enthält die Konfigurationsdateien. Das Unterverzeichnis logs ist in der Standardinstallation für Logdateien vorgesehen. Dieses sollte jedoch nicht benutzt werden, sondern es sollten Verzeichnisse auf eigenen Partitionen benutzt werden (siehe auch M Konfiguration des Betriebssystems für einen Application Server). Im Rahmen dieser Maßnahme werden dafür L:\tomcat-logs unter Windows und /var/tomcat-logs unter Unix angenommen. Die zentrale Konfigurationsdatei für den Application Server ist die Datei server.xml im Unterverzeichnis conf. Dabei handelt es sich um eine XML-Datei, die je nach Installationsart bereits mit sinnvollen Konfigurationseinstellungen vorbelegt ist. Die Datei ist außerdem mit ausführlichen Kommentaren zur Dokumentation versehen, die sie weitgehend selbsterklärend machen. Die Konfiguration erfolgt durch sogenannte Tags. Standardmäßig basiert das Logging des Application Servers auf den java.util.logging Klassen der Java VM und wird über die Datei Status: Freigegeben Datum: Seite 116 von 146

118 logging.properties im Unterverzeichnis conf konfiguriert. In der Dokumentation des Application Servers wird auf eine alternative Logging-Möglichkeit hingewiesen, die auf der log4j-bibliothek des Jakarta Projektes basiert. Alle Schritte, die bei der Installation gemacht werden, sollten so dokumentiert werden, dass sich die Konfiguration im Notfall schnell verstehen und reproduzieren lässt. Dies betrifft neben den Einstellungen beim Kompilieren auch Installationspfade, Berechtigungen, Änderungen an der Datei server.xml, Konfigurationen der Webanwendungen und ähnliche Informationen. Sichere Installation des Application Servers unter Unix Der Start des Application Servers sollte im Allgemeinen aus den Startupskripts des Betriebssystems erfolgen. So steht der Webserver auch nach einem Reboot des Server-Rechners direkt zur Verfügung. Ausnahmen bestehen hier unter Umständen beim Einsatz von SSL (siehe auch M Verwendung von SSL im Application Server). Nur wenn der Application Server den WWW-Port 80/tcp benutzen soll, muss der Start unter dem Benutzerkonto root erfolgen. Der Tomcat Server darf jedoch nicht ständig mit Root-Rechten ausgeführt werden. Zu diesem Zweck muss ein eigenes Benutzerkonto und eine eigene Gruppe, z. B. tomcat, angelegt werden. Mit Hilfe des Unix- Werkzeuges su bzw. sudo kann der Tomcat Server als Benutzer tomcat gestartet werden. Nach der Installation sollte die Konfiguration der Dateizugriffsrechte kontrolliert werden. Das Tomcat-Verzeichnis und alle darüber liegenden Verzeichnisse müssen dem Benutzer root (oder einem sonstigen Systemkonto) und einer entsprechenden Systemgruppe gehören. Nur die Eigentümer dürfen Schreibzugriff auf diese Verzeichnisse haben. Gleiches gilt für die Unterverzeichnisse des Tomcat-Verzeichnisses, die Binärdateien, Webanwendungs-, Konfigurations- oder Logdateien enthalten. Auch die Binärdateien selbst sollten nur von root geschrieben werden können. Gleiches gilt für das Verzeichnis und die Dateien der Java VM. Sichere Installation unter Windows Eine sichere Installation des Application Servers unter Windows erfordert einige zusätzliche Maßnahmen, da die Standardkonfiguration, wie sie direkt aus der Kompilierung der Quelltextdistribution entsteht, genauso wie die Standardinstallation des Apache Tomcat mit dem mitgelieferten Microsoft Installer Plugin einige wichtige Regeln zur Absicherung des Application Servers nicht umsetzen. Status: Freigegeben Datum: Seite 117 von 146

119 Beispielsweise wird der Application Server damit unter dem Konto LocalSystem ausgeführt. Im Rahmen der Installation sollten daher die folgenden Änderungen an der Konfiguration vorgenommen werden: Für den Application Server sollte ein spezielles Benutzerkonto (bspw. tomcat) eingerichtet werden, das nur über die minimal notwendigen Rechte verfügt. Dieses Benutzerkonto muss ein Mitglied der Gruppe Benutzer sein. Außerdem sollten die Zugriffsrechte im Dateisystem modifiziert werden, da in der Voreinstellung alle Benutzer Vollzugriff auf alle Dateien des Application Servers haben. Bei der Beschränkung des Zugriffs auf diese Verzeichnisse muss jedoch sichergestellt werden, dass der Application Server über die für den ordnungsgemäßen Ablauf notwendigen Zugriffsrechte verfügt. Der Zugriff auf das webapps Verzeichnis, das die Dateien der Ergänzende Kontrollfragen: Wurde die Integrität der Software vor der Installation überprüft? Wie ist die Konfiguration dokumentiert? Welche Zugriffsrechte bestehen auf das Verzeichnis der Webanwendungen (webapps)? M 4.194* Sichere Grundkonfiguration eines Application Servers Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator Nachdem der Application Server installiert wurde, muss eine sichere Grundkonfiguration vorgenommen werden. Dies betrifft beispielsweise die Einstellungen für Zugriffe auf Verzeichnisse innerhalb und außerhalb der Webanwendungen, aber auch Einstellungen, die auf den Performance des Servers Einfluss haben. Zur Überprüfung von Zertifikaten verwendet JAVA und somit auch der in JAVA geschriebene Tomcat Servlet Container standardmäßig den JAVA Zertifikatspeicher, der in der Datei ${JAVA_HOME}/jre/lib/security/cacerts abgelegt ist. Da somit die dort abgelegten Zertifikate eine zentrale Rolle bei der Sicherheit besitzen, wird empfohlen, das Standardpasswort changeit des Zertifikat- Status: Freigegeben Datum: Seite 118 von 146

120 speichers direkt nach dessen Installation, die im Rahmen der Installation des JAVA SDKs erfolgt, neu zu setzen. Alternativ können in Tomcat die Zertifikate der die Client-Zertifikate signierenden Certification Authorities (CAs), im Tomcat-Zertifikatspeicher abgelegt werden, der mit den zusätzlichen Optionen truststorefile und ggf. truststorepass in der <Connector>-Deklaration der Konfigurationsdatei $CATALINA_HOME/conf/server.xml spezifiziert wird. Auch dieser gegebenenfalls verwendete Zertifikatspeicher ist entsprechend durch ein ausreichend sicher gewähltes Passwort gegen unbefugte Manipulationen zu schützen. Beim Produktiveinsatz des Application Servers ist zu überprüfen, welche Log-Informationen für den Betrieb und zur Fehlersuche tatsächlich benötigt werden, um übermäßigen Ressourcen-Verbrauch hinsichtlich CPU-Leistung oder Speicherplatzbedarf zu vermeiden. Das Logging kann unterschieden werden nach dem Logging auf der Ebene der Betriebszustände von Tomcat auf der Stufe der Tomcat-Engine, der virtuellen Hosts, etc.. Hierunter fällt z. B. das Hoch- oder Herunterfahren von Tomcat oder Webanwendungen, die Änderung der Konfiguration oder die Aktualisierung von Webanwendungen oder die Protokollierung von Fehlern zur Laufzeit. dem Logging der Zugriffe auf die bereitgestellten Webanwendungen mit Informationen über den anfragenden Webclient, den Benutzer, die angefragte Webanwendungsressource, etc.. Während beim Debugging umfangreiche Log-Informationen zur Fehlersuche und behebung sinnvoll sein können, sollten im Produktivsystem die debug Attribute auf 0 gesetzt sein und das AccessLogValve nur bei Bedarf eingesetzt werden. Weiterhin ist zu beachten, dass je nach Detaillierungsgrad der Protokollierung u. U. datenschutzrechtlich relevante Informationen gewonnen werden könnten. Insbesondere in Verbindung mit der Protokollierung der Zugriffe, wobei z. B. Benutzernamen oder Cookie-Informationen festgehalten werden können sind datenschutzrechtliche Belange zu beachten. Daraus resultierend sind natürlich die Log-Dateien entsprechend zu behandeln. Maßnahmen für den Zugriffsschutz und Beschränkung der Verwendungs- / Auswertungsmöglichkeit sind dann auf jeden Fall umzusetzen. Wird das AccessLogValve eingesetzt, so werden wesentliche Informationen über den Zugriff auf Tomcat bereits mit den Log- Pattern pattern= common erfasst. Wird das Log-Pattern Status: Freigegeben Datum: Seite 119 von 146

121 pattern= combined selektiert, so werden zusätzlich die Werte Referer und User-Agent des HTTP Headers protokolliert, wobei die zum Wert Referer gespeicherten Informationen für den Datenschutz relevante Inhalte umfassen könnte, wie beispielsweise in der URL des vorigen Zugriffs eingebettete Authentisierungsinformationen. Erfolgreiche bzw. fehlgeschlagene Zugriffe werden unterscheidbar durch den HTTP Status Code protokolliert. Zur Vermeidung von Denial-of-Service (DoS) Angriffen sollte auf die Freigabe eines Ports zum Herunterfahren des Application Servers verzichtet werden, da für das Herunterfahren lediglich die Kenntnis der dafür konfigurierten Zeichenkette erforderlich ist und eine weiter gehende Authentisierung zur Feststellung der Berechtigung zum Herunterfahren nicht erfolgt. Zwar ist gemäß der Tomcat Dokumentation das Herunterfahren durch eine Kontaktierung des Ports nur vom lokalen Host, auf dem der Application Server selbst auch läuft, möglich, jedoch kann jeder auf diesem Host eingeloggte Nutzer mit Kenntnis der Shutdown-Zeichenkette das Herunterfahren durch das Kommando telnet localhost 8005 sowie der anschließenden Eingabe dieser Shutdown-Zeichenkette initiieren. Vielmehr sollte auf die übliche Methode der Verwendung von System- Startup-Skripts (unter /etc/init.d) zurückgegriffen werden, um Tomcat zu starten bzw. zu beenden. Diese Skripts können durch entsprechend berechtigte Nutzer, ggf. über die Verwendung des sudo Kommandos, ausgeführt werden. Somit ist die Nutzung von Shutdown-Port und -String nicht notwendig, um den Tomcat Servlet Container durch berechtigte Benutzer herunter zu fahren. Sofern die manager bzw. admin Webanwendungen zur Administration von Tomcat verwendet werden, sollten diese zur Vermeidung von unerwünschten Zugriffen, die die Gefahr einer Manipulation der Konfiguration bergen, durch eine Filterung der berechtigten Remote-Adressen beim Zugriff auf diese Webanwendungen geschützt werden. Hierzu wird ein RemoteAddrValve in den zu den Applikationen gehörigen Konfigurationsdateien $CATALINA_HOME/conf/Catalina/localhost/manager.xml bzw. $CATALINA_HOME/conf/Catalina/localhost/admin.xml eingefügt: <Valve classname= org.apache.catalina.valves.remoteaddrvalve allow= , *.* /> Hierbei sind unter allow die für den Zugriff zugelassenen Adressen entsprechend anzupassen. Hierin sind durch Kommata getrennte Listeneinträge mit IP-Adressen, ggf. mit Wildcard-Zeichen einzufügen. Die Konfiguration entsprechender URL-Sperrlisten in einem Status: Freigegeben Datum: Seite 120 von 146

122 vorgelagerten Application Server reichen, falls diese überhaupt aktiviert sind, unter Umständen nicht aus, wenn ein Direktzugriffe über den HTTP(S)-Connector von Tomcat beispielsweise aus dem lokalen Netzwerk heraus möglich ist. Werden diese beiden Administrationswerkzeuge überhaupt nicht verwendet, so sollten sie aus Sicherheitsgründen nicht installiert sein. Wird zur Administration der Tomcat-Konfiguration die admin Webanwendung verwendet, so gehen eventuell manuell in die Konfigurationsdateien eingetragene XMLKommentare verloren. Webanwendungen sind Java Programme, die in derselben JAVA VM laufen, wie ihr Container. Deshalb kann das Betriebssystem bei Zugriff auf Systemressourcen nicht zwischen dem Container und einer Webanwendung unterscheiden. Innerhalb der JAVA VM können deshalb den einzelnen Java Threads bzw. Java Klassen über Security Policies, die vom Security-Manager durchgesetzt werden, Rechte zugewiesen bzw. entzogen werden. Der Application Server verwendet den Standard Security-Manager von Java und die Policy- Datei {$CATALINA_HOME}/conf/catalina.policy. Für die Aktivierung des Security-Managers muss zum einen die Policy-Datei entsprechend angepasst werden, und zum anderen muss Tomcat mit der Option security (startup.sh security) gestartet werden. Der Application Server erlaubt verschiedene Einstellungen, mit denen die Performance beeinflusst werden kann. Diese Einstellungen hängen teilweise vom Betriebssystem und den Einstellungen der zu Grunde liegenden JAVA VM ab. Insbesondere die Einstellung des maximal zulässigen Speichers, der der JAVA VM zur Verfügung steht, hat einen signifikanten Einfluss auf die Leistungsfähigkeit des Tomcat Servers. Für diese Einstellungen enthält die Standardkonfiguration Vorgabewerte, die in vielen Fällen ausreichend sind. In der Dokumentation werden die einzelnen Einstellungen erläutert. Von den Vorgabewerten sollte nur dann abgewichen werden, wenn die Auswirkungen absehbar sind, idealerweise sollten Änderungen auf einem Testsystem überprüft werden, bevor sie auf einem Produktivsystem übernommen werden. Generell sollte bei Änderungen an systemnahen Einstellungen, die auf das Zusammenspiel zwischen dem Tomcat Server und dem unterliegenden Betriebssystem bzw. der verwendeten JAVA VM Einfluss haben, eher konservativ vorgegangen werden. Status: Freigegeben Datum: Seite 121 von 146

123 Ergänzende Kontrollfragen: Welche Webanwenungen werden geladen? Ist dokumentiert, zu welchem Zweck? Sind die Webanwendungen admin und manage wirklich notwendig? In welchen Abständen werden die Logfiles archiviert? M Installation eines Application Servers in einem chroot-käfig Verantwortlich für Initiierung: Verantwortlich für Umsetzung: Leiter IT, IT-Sicherheitsmanagement Administrator Zur Erhöhung der Systemsicherheit kann der Application Server in einem sogenannten chroot-käfig installiert werden. Dieser Schritt sollte insbesondere dann in Betracht gezogen werden, wenn der Application Server ein öffentlich zugängliches Webangebot beherbergt. Durch den Systemaufruf chroot() wird unter Unix der Zugriff eines bestimmten Programms auf einen Teil des Dateibaums beschränkt. Dies geschieht dadurch, dass alle Zugriffe, die dieses Programm (und die von ihm aufgerufenen Programme) auf das Dateisystem durchführt, relativ zu dem Verzeichnis erfolgen, das beim Aufruf der Funktion chroot() angegeben wurde. Dieses Verzeichnis wird so zur Wurzel eines virtuellen Dateibaums, der als chroot-käfig oder chroot jail bezeichnet wird. Abbildung: Wurzelverzeichnis Status: Freigegeben Datum: Seite 122 von 146

Sicherheit im IT Umfeld

Sicherheit im IT Umfeld Sicherheit im IT Umfeld Eine Betrachtung aus der Sicht mittelständischer Unternehmen Sicherheit im IT Umfeld Gibt es eine Bedrohung für mein Unternehmen? Das typische IT Umfeld im Mittelstand, welche Gefahrenquellen

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-5

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-5 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen SLA Software Logistik Artland GmbH Friedrichstraße 30 49610 Quakenbrück für das IT-System Meat Integrity Solution

Mehr

Technische und organisatorische Maßnahmen zur Datensicherheit bei cojama Infosystems GmbH gem. 9 BDSG

Technische und organisatorische Maßnahmen zur Datensicherheit bei cojama Infosystems GmbH gem. 9 BDSG Datensicherheit bei gem. 9 BDSG Der Auftragnehmer verpflichtet sich gegenüber dem Auftraggeber zur Einhaltung nachfolgender technischer und organisatorischer Maßnahmen, die zur Einhaltung der anzuwendenden

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Datenschutz und Datensicherheit in Schulverwaltungssystemen Fachtagung Datenschutz in der mediatisierten Schule, 23. und 24. Oktober 2014 Kay Hansen

Datenschutz und Datensicherheit in Schulverwaltungssystemen Fachtagung Datenschutz in der mediatisierten Schule, 23. und 24. Oktober 2014 Kay Hansen Datenschutz und Datensicherheit in Schulverwaltungssystemen Fachtagung Datenschutz in der mediatisierten Schule, 23. und 24. Oktober 2014 Kay Hansen Rechtsgrundlagen Personenbezogene Daten Datenschutz

Mehr

Gute Beratung wird verstanden

Gute Beratung wird verstanden Gute Beratung wird verstanden Sehr geehrte Damen und Herrn! Wüssten Sie gern, ob die in Ihrem Unternehmen angewandten Maßnahmen zur Sicherheit der Informationstechnik noch ausreichen? Wenn Sie sicher sein

Mehr

1. Schritt: Benutzerkontensteuerung aktivieren

1. Schritt: Benutzerkontensteuerung aktivieren Inhalt: 1. Schritt: Benutzerkontensteuerung aktivieren 2. Schritt: Firewall aktivieren 3. Schritt: Virenscanner einsetzen 4. Schritt: Automatische Updates aktivieren 5. Schritt: Sicherungskopien anlegen

Mehr

AGENDA. Einleitung. Warum IT-Notfallplanung. Was ist IT-Notfallplanung. Der IT-Notfallplan

AGENDA. Einleitung. Warum IT-Notfallplanung. Was ist IT-Notfallplanung. Der IT-Notfallplan IT-Notfallplanung AGENDA Einleitung Warum IT-Notfallplanung Was ist IT-Notfallplanung Der IT-Notfallplan Es kommt nicht darauf an, die Zukunft zu wissen, sondern auf die Zukunft vorbereitet zu sein (Perikles)

Mehr

Installationsanleitung TOPIX WebSolution Server

Installationsanleitung TOPIX WebSolution Server Installationsanleitung TOPIX WebSolution Server WebSolution Version 1.309 TOPIX:8 Ab Version 8.9.3v2 Stand 08/2014 Inhalt 1 Systemvoraussetzungen...3 2 Vorbereitungen für die Installation...4 Die aktuelle

Mehr

FREIHEIT GESTALTEN VERSCHLÜSSELUNG ALS FREIHEIT IN DER KOMMUNIKATION. Christian R. Kast, Rechtsanwalt und Fachanwalt für IT Recht

FREIHEIT GESTALTEN VERSCHLÜSSELUNG ALS FREIHEIT IN DER KOMMUNIKATION. Christian R. Kast, Rechtsanwalt und Fachanwalt für IT Recht FREIHEIT GESTALTEN VERSCHLÜSSELUNG ALS FREIHEIT IN DER KOMMUNIKATION Christian R. Kast, Rechtsanwalt und Fachanwalt für IT Recht INHALTSÜBERSICHT Risiken für die Sicherheit von Kommunikation und die Freiheit

Mehr

Bestimmungen zur Kontrolle externer Lieferanten

Bestimmungen zur Kontrolle externer Lieferanten Bestimmungen zur Kontrolle externer Lieferanten Internet-Sicherheit Für Lieferanten der Kategorie Geringes Internetrisiko Internet- 1. Ressourcenschutz und Systemkonfiguration Die Daten von Barclays sowie

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen Agfa HealthCare GmbH Konrad-Zuse-Platz 1-3 53227 Bonn für das IT-System IMPAX/web.Access die Erfüllung aller

Mehr

Dynamische Web-Anwendung

Dynamische Web-Anwendung Dynamische Web-Anwendung Christiane Lacmago Seminar Betriebssysteme und Sicherheit Universität Dortmund WS 02/03 Gliederung Einleitung Definition und Erläuterung Probleme der Sicherheit Ziele des Computersysteme

Mehr

Installationsanleitung für den Online-Backup Client

Installationsanleitung für den Online-Backup Client Installationsanleitung für den Online-Backup Client Inhalt Download und Installation... 2 Login... 4 Konfiguration... 5 Erste Vollsicherung ausführen... 7 Webinterface... 7 FAQ Bitte beachten sie folgende

Mehr

INFORMATIONSSICHERHEIT GEFÄHRDUNGEN IN DER ARZTPRAXIS

INFORMATIONSSICHERHEIT GEFÄHRDUNGEN IN DER ARZTPRAXIS INFORMATIONSSICHERHEIT GEFÄHRDUNGEN IN DER ARZTPRAXIS WAS SIND INFORMATIONEN? Informationen sind essentiellen Werte einer Arztpraxis. müssen angemessen geschützt werden. 2 WAS IST INFORMATIONSSICHERHEIT?

Mehr

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors Installation und Konfiguration des Outlook Connectors Vertraulichkeit Die vorliegende Dokumentation beinhaltet vertrauliche Informationen und darf nicht an etwelche Konkurrenten der EveryWare AG weitergereicht

Mehr

MSXFORUM - Exchange Server 2003 > Installationsanleitung Exchange 2003

MSXFORUM - Exchange Server 2003 > Installationsanleitung Exchange 2003 Page 1 of 12 Installationsanleitung Exchange 2003 Kategorie : Exchange Server 2003 Veröffentlicht von webmaster am 18.02.2005 Diese Anleitung ist eine "step by step" Leitfaden zur Installation eines Exchange

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-3 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen RWE Effizienz GmbH Flamingoweg 1 44139 Dortmund für das IT-System RWE eoperate IT Services die Erfüllung aller

Mehr

Version 4.4. security.manager. Systemvoraussetzungen

Version 4.4. security.manager. Systemvoraussetzungen Version 4.4 security.manager Systemvoraussetzungen Version 4.4 Urheberschutz Der rechtmäßige Erwerb der con terra Softwareprodukte und der zugehörigen Dokumente berechtigt den Lizenznehmer zur Nutzung

Mehr

Sicherheitsaspekte unter Windows 2000

Sicherheitsaspekte unter Windows 2000 Sicherheitsaspekte unter Windows 2000 Margarete Kudak Sascha Wiebesiek 1 Inhalt 1. Sicherheit 1.1 Definition von Sicherheit 1.2 C2 - Sicherheitsnorm 1.3 Active Directory 2. Sicherheitslücken 3. Verschlüsselung

Mehr

MVB3. Einrichten eines Servers für MVB3 ab Version 3.5. Admin-Dokumentation. Inhalt V3.05.001

MVB3. Einrichten eines Servers für MVB3 ab Version 3.5. Admin-Dokumentation. Inhalt V3.05.001 V3.05.001 MVB3 Admin-Dokumentation Einrichten eines Servers für MVB3 ab Version 3.5 Inhalt Organisatorische Voraussetzungen... 1 Technische Voraussetzungen... 1 Konfiguration des Servers... 1 1. Komponenten

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

Checkliste: Technische und organisatorische Maßnahmen

Checkliste: Technische und organisatorische Maßnahmen Checkliste: Technische und organisatorische Maßnahmen Folgende technische und organisatorische Maßnahmen wurden nach 9 BDSG für folgende verantwortliche Stelle getroffen: Musterstein GmbH Musterweg 2 4

Mehr

Installationscheckliste ADNOVA office Version 2013, Stand 30.09.2012

Installationscheckliste ADNOVA office Version 2013, Stand 30.09.2012 Installationscheckliste ADNOVA office Version 2013, Stand 30.09.2012 ADNOVA office Checkliste für die Neuinstallation in einem Windows-Netzwerk einschl. Remote Desktop Session Host Umgebung Bitte prüfen

Mehr

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet Ralph Lehmann. Computerservice und IT-Beratung. Kochstraße 34. 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Kochstraße 34 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Tel.:

Mehr

Schwachstellenanalyse 2013

Schwachstellenanalyse 2013 Schwachstellenanalyse 2013 Sicherheitslücken und Schwachstellen in Onlineshops Andre C. Faßbender Schwachstellenforschung Faßbender 09.01.2014 Inhaltsverzeichnis 1. Abstract... 3 2. Konfiguration der getesteten

Mehr

Online-Banking. 45 Tipps für das sichere Online-Banking

Online-Banking. 45 Tipps für das sichere Online-Banking Online-Banking 45 Tipps für das sichere Online-Banking Notwendige Sicherheitsvorkehrungen am PC Versuchen Sie, möglichst wenige Personen an 1 dem PC arbeiten zu lassen, an dem Sie auch das Online-Banking

Mehr

Verschlüsselung der Kommunikation zwischen Rechnern

Verschlüsselung der Kommunikation zwischen Rechnern Verschlüsselung der Kommunikation zwischen Rechnern Stand: 11. Mai 2007 Rechenzentrum Hochschule Harz Sandra Thielert Hochschule Harz Friedrichstr. 57 59 38855 Wernigerode 03943 / 659 0 Inhalt 1 Einleitung

Mehr

SFTP Datenübertragungsclient PK-SFTP. automatische Verbindung zu einem SFTP-Server in einstellbaren Zeitintervallen

SFTP Datenübertragungsclient PK-SFTP. automatische Verbindung zu einem SFTP-Server in einstellbaren Zeitintervallen SFTP Datenübertragungsclient PK-SFTP automatische Verbindung zu einem SFTP-Server in einstellbaren Zeitintervallen senden, abholen und verifizieren der bereitstehenden Daten Protokollierung der Datenübertragung

Mehr

IKONIZER II Installation im Netzwerk

IKONIZER II Installation im Netzwerk Der IKONIZER II ist netzwerkfähig in allen bekannten Netzwerken. Da jedoch etwa 95% der Installationen lokal betrieben werden, erfolgt diese grundsätzlich sowohl für das Programm wie auch für den lizenzfreien

Mehr

Datensicherung EBV für Mehrplatz Installationen

Datensicherung EBV für Mehrplatz Installationen Datensicherung EBV für Mehrplatz Installationen Bitte beachten Sie EBV 3.4 bietet Ihnen die Möglichkeit eine regelmäßige Sicherung der Daten vorzunehmen. Wir möchten Sie darauf hinweisen, dass Sie für

Mehr

Mindtime Online Backup

Mindtime Online Backup Mindtime Online Backup S e r v i c e L e v e l A g r e e m e n t Inhaltsangabe Service Definition... 3 1) Datenverschlüsselung... 3 2) Gesicherte Internetverbindung... 3 3) Datencenter... 4 4) Co- Standort...

Mehr

Produktbeschreibung Penetrationstest

Produktbeschreibung Penetrationstest Produktbeschreibung Penetrationstest 1. Gestaltungsmöglichkeiten Ein Penetrationstest stellt eine Möglichkeit zum Test der IT-Sicherheit dar. Um die vielfältigen Möglichkeiten eines Penetrationstests zu

Mehr

Checkliste: Technische und organisatorische Maßnahmen

Checkliste: Technische und organisatorische Maßnahmen Checkliste: Technische und organisatorische Maßnahmen Folgende technische und organisatorische Maßnahmen wurden nach 9 BDSG für folgende verantwortliche Stelle getroffen: Musterstein GmbH Musterweg 2-4

Mehr

1 Automatisierung von Datensicherungen mit Microsoft Dynamics NAV (CSIDE) amball empfiehlt ExpandIT Backup Utility

1 Automatisierung von Datensicherungen mit Microsoft Dynamics NAV (CSIDE) amball empfiehlt ExpandIT Backup Utility 1 Automatisierung von Datensicherungen mit Microsoft Dynamics NAV (CSIDE) amball empfiehlt ExpandIT Backup Utility Backups sind unverzichtbarer Bestandteil jeder verlässlichen ERP-Lösung. Das Backup der

Mehr

Installationscheckliste ADNOVA finance Version 2013, Stand 06.12.2012

Installationscheckliste ADNOVA finance Version 2013, Stand 06.12.2012 Installationscheckliste ADNOVA finance Version 2013, Stand 06.12.2012 ADNOVA finance Checkliste für die Neuinstallation in einem Windows-Netzwerk Bitte prüfen Sie auf unseren Webseiten www.landdata.de

Mehr

Information Security Policy für Geschäftspartner

Information Security Policy für Geschäftspartner safe data, great business. Information Security Policy für Geschäftspartner Raiffeisen Informatik Center Steiermark Raiffeisen Rechenzentrum Dokument Eigentümer Version 1.3 Versionsdatum 22.08.2013 Status

Mehr

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/ Einführung Was ist Unison? Unison ist ein Dateisynchronisationsprogramm für Windows und Unix. Es teilt sich viele Funktionen mit anderen Programmen, wie z.b. CVS und rsync. Folgend einige Vorteile des

Mehr

Installation und Dokumentation. juris Autologon 3.1

Installation und Dokumentation. juris Autologon 3.1 Installation und Dokumentation juris Autologon 3.1 Inhaltsverzeichnis: 1. Allgemeines 3 2. Installation Einzelplatz 3 3. Installation Netzwerk 3 3.1 Konfiguration Netzwerk 3 3.1.1 Die Autologon.ini 3 3.1.2

Mehr

Installation Anleitung für JTheseus und MS SQL Server 2000

Installation Anleitung für JTheseus und MS SQL Server 2000 Installation Anleitung für JTheseus und MS SQL Server 2000 Inhaltsverzeichnis 1 Installation der Datenbank 3 1.1 Erstellen der Datenbank 3 1.2 Tabellen und Minimal Daten einlesen 4 1.3 Benutzer JTheseus

Mehr

DCOM Einstellungen zur rechnerübergreifenden Kommunikation zwischen OPC Server und OPC Client

DCOM Einstellungen zur rechnerübergreifenden Kommunikation zwischen OPC Server und OPC Client DCOM Einstellungen zur rechnerübergreifenden Kommunikation zwischen OPC Server und OPC Client 1. Einleitung Für die rechnerübergreifende Kommunikation zwischen OPC Client und OPC Server wird bei OPC DA

Mehr

Installationshandbuch für den DAKOSY J Walk Windows Client

Installationshandbuch für den DAKOSY J Walk Windows Client Installationshandbuch für den DAKOSY J Walk Windows Client Version 1.1 DAKOSY Datenkommunikationssystem AG Mattentwiete 2 20457 Hamburg Telefon: 040 370 03 0 Fax: - 370 Erstellt von : Jan Heins Geprüft

Mehr

Datensicherheit und Backup

Datensicherheit und Backup Beratung Entwicklung Administration Hosting Datensicherheit und Backup Dipl.-Inform. Dominik Vallendor & Dipl.-Inform. Carl Thomas Witzenrath 25.05.2010 Tralios IT Dipl.-Inform. Dominik Vallendor und Dipl.-Inform.

Mehr

2. Sie sind der Administrator Ihres Netzwerks, das den SBS 2011 Standard ausführt.

2. Sie sind der Administrator Ihres Netzwerks, das den SBS 2011 Standard ausführt. Arbeitsblätter Der Windows Small Business Server 2011 MCTS Trainer Vorbereitung zur MCTS Prüfung 70 169 Aufgaben Kapitel 1 1. Sie sind der Administrator Ihres Netzwerks, das den SBS 2011 Standard ausführt.

Mehr

Leitfaden Datensicherung und Datenrücksicherung

Leitfaden Datensicherung und Datenrücksicherung Leitfaden Datensicherung und Datenrücksicherung Inhaltsverzeichnis 1. Einführung - Das Datenbankverzeichnis von Advolux... 2 2. Die Datensicherung... 2 2.1 Advolux im lokalen Modus... 2 2.1.1 Manuelles

Mehr

MSXFORUM - Exchange Server 2003 > SSL Aktivierung für OWA 2003

MSXFORUM - Exchange Server 2003 > SSL Aktivierung für OWA 2003 Page 1 of 23 SSL Aktivierung für OWA 2003 Kategorie : Exchange Server 2003 Veröffentlicht von webmaster am 20.05.2005 Die Aktivierung von SSL, für Outlook Web Access 2003 (OWA), kann mit einem selbst ausgestellten

Mehr

Dokumentation der technischen und organisatorischen Maßnahmen zur Einhaltung des Datenschutzes bei Collmex

Dokumentation der technischen und organisatorischen Maßnahmen zur Einhaltung des Datenschutzes bei Collmex Bastian Wetzel Dokumentation der technischen und organisatorischen Maßnahmen zur Einhaltung des Datenschutzes bei Collmex Verteiler: Alle Mitarbeiter sowie interessierte Kunden der Collmex GmbH, Anlage

Mehr

I. Travel Master CRM Installieren

I. Travel Master CRM Installieren I. Travel Master CRM Installieren Allgemeiner Hinweis: Alle Benutzer müssen auf das Verzeichnis, in das die Anwendung installiert wird, ausreichend Rechte besitzen (Schreibrechte oder Vollzugriff). Öffnen

Mehr

Installationshandbuch

Installationshandbuch Installationshandbuch Erforderliche Konfiguration Installation und Aktivierung - 1 - Erforderliche Konfiguration Programme der 4D v15 Produktreihe benötigen folgende Mindestkonfiguration: Windows OS X

Mehr

IT-Sicherheit. Informationssicherheit: IT-Sicherheit bzw. IT-Risikomanagement

IT-Sicherheit. Informationssicherheit: IT-Sicherheit bzw. IT-Risikomanagement IT-Sicherheit Informationssicherheit: Schutz aller Informationen im Unternehmen elektronisch gespeicherte Daten Informationen in nichtelektronischer Form z.b. auf Papier Expertenwissen, in den Köpfen der

Mehr

Die Sicherheit Ihres Praxisverwaltungssystems

Die Sicherheit Ihres Praxisverwaltungssystems Die Sicherheit Ihres Praxisverwaltungssystems Was Sie im Umgang mit EDV-Anlagen und Onlinediensten beachten sollten Gefahren bei Sicherheitslücken Ihr Praxisbetrieb ist in hohem Maße abhängig von Ihrem

Mehr

Informationssicherheit

Informationssicherheit Informationssicherheit Dipl.-Kfm., CISA, CISM 2007 RÖVERBRÖNNER Consulting GmbH Das einzige System, welches wirklich sicher ist, ist ausgeschaltet und ausgesteckt, eingesperrt in einem Safe aus Titan,

Mehr

IT-Sicherheit auf dem Prüfstand Penetrationstest

IT-Sicherheit auf dem Prüfstand Penetrationstest IT-Sicherheit auf dem Prüfstand Penetrationstest Risiken erkennen und Sicherheitslücken schließen Zunehmende Angriffe aus dem Internet haben in den letzten Jahren das Thema IT-Sicherheit für Unternehmen

Mehr

Beschreibung Mobile Office

Beschreibung Mobile Office Beschreibung Mobile Office 1. Internet / Netz Zugriff Für die Benutzung von Mobile Office ist lediglich eine Internet oder Corporate Netz Verbindung erforderlich. Nach der Verbindungsherstellung kann über

Mehr

Installation und Lizenz

Installation und Lizenz Das will ich auch wissen! Kapitel 2 Installation und Lizenz Inhaltsverzeichnis Überblick über dieses Dokument... 2 Diese Kenntnisse möchten wir Ihnen vermitteln... 2 Diese Kenntnisse empfehlen wir... 2

Mehr

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr

Konsistenz, Replikation und Fehlertoleranz

Konsistenz, Replikation und Fehlertoleranz Konsistenz, Replikation und Fehlertoleranz Zugangssicherheit Kaufmann Daniel, Kranister Jürgen, Stundner Lukas Allgemeines Zugangssicherheit = Absicherung, dass nur berechtigte User/Geräte bestimmte Aktionen

Mehr

Sicherheitskonzept für externe Datenbank. Erstellt von Alt Roman und Schüpbach James

Sicherheitskonzept für externe Datenbank. Erstellt von Alt Roman und Schüpbach James Sicherheitskonzept für externe Datenbank Erstellt von Alt Roman und Schüpbach James Inhaltsverzeichnis 1 Risikoanalyse...3 1.1 Intern...3 1.2 Extern...3 1.3 Physisch...3 2 Risiko Klassifizierung...4 3

Mehr

PowerMover. Eine Zusatz-Anwendung für Outlook-PowerUser. Damit können eingehende E-Mails schneller verwaltet werden. Vasquez Systemlösungen

PowerMover. Eine Zusatz-Anwendung für Outlook-PowerUser. Damit können eingehende E-Mails schneller verwaltet werden. Vasquez Systemlösungen PowerMover Eine Zusatz-Anwendung für Outlook-PowerUser. Damit können eingehende E-Mails schneller verwaltet werden. PowerMover Seite 1/7 Inhaltsverzeichnis: 1 Beschreibung... 3 2 Funktionalität... 4 2.1

Mehr

Checkliste für Systempflege Verbindliche Vorgaben für den Systemanwender Stand 09. Juni 2011

Checkliste für Systempflege Verbindliche Vorgaben für den Systemanwender Stand 09. Juni 2011 ANLAGE 3 Checkliste für Systempflege Verbindliche Vorgaben für den Systemanwender Stand 09. Juni 2011 Allgemein Um den Support des DV-Systems sicher und effektiv gewährleisten zu können ist es unerlässlich,

Mehr

Sicherheitsmaßnahmen bei modernen Multifunktionsgeräten (Drucker, Kopierer, Scanner, FAX)

Sicherheitsmaßnahmen bei modernen Multifunktionsgeräten (Drucker, Kopierer, Scanner, FAX) Sicherheitsmaßnahmen bei modernen Multifunktionsgeräten (Drucker, Kopierer, Scanner, FAX) Sommerakademie 2008 Internet 2008 - Alles möglich, nichts privat? Die Situation Multifunktionsgeräte (Drucker,

Mehr

Programmfehler / Verbesserungen

Programmfehler / Verbesserungen Hinweise zur Installation von NdAuxio Lesen Sie sich die Datei NdAuxio.pdf im Doc-Verzeichnis durch. Sie enthält weitere Angaben zum Programmstart mit Parametern usw. Inhaltsverzeichnis Programmfehler

Mehr

TYPO3-Workshop Zugangsgeschützte Webbereiche in TYPO3

TYPO3-Workshop Zugangsgeschützte Webbereiche in TYPO3 Leibniz Universität IT Services TYPO3-Workshop Zugangsgeschützte Webbereiche in TYPO3 Workshop TYPO3@RRZN Sep. 2012 Dr. Thomas Kröckertskothen - RRZN Zugangsgeschützte Webbereiche in TYPO3 Was sind zugangsgeschützte

Mehr

Installationsanleitung biz Version 8.0.0.0

Installationsanleitung biz Version 8.0.0.0 bizsoft Büro Software A-1040 Wien, Waaggasse 5/1/23 D-50672 Köln, Kaiser-Wilhelm-Ring 27-29 e-mail: office@bizsoft.de internet: www.bizsoft.de Installationsanleitung biz Version 8.0.0.0 Die biz Vollversion

Mehr

Persona-SVS e-sync auf Windows Terminal Server

Persona-SVS e-sync auf Windows Terminal Server Persona-SVS e-sync auf Windows Terminal Server 2014 by Fraas Software Engineering GmbH Alle Rechte vorbehalten. Fraas Software Engineering GmbH Sauerlacher Straße 26 82515 Wolfratshausen Germany http://www.fraas.de

Mehr

Fortbildung Sachbearbeiter EDV

Fortbildung Sachbearbeiter EDV Fortbildung Sachbearbeiter EDV BSB Andreas Brandstätter November 2012 1 / 42 Überblick Themen Hintergrund Anforderungen der Benutzer Schutzziele konkrete Bedeutung Maßnahmen WLAN Datenspeicherung Backup

Mehr

Ist Ihr Netzwerk sicher? 15 Fragen die Sie sich stellen sollten

Ist Ihr Netzwerk sicher? 15 Fragen die Sie sich stellen sollten Ist Ihr Netzwerk sicher? 15 Fragen die Sie sich stellen sollten Innominate Security Technologies AG Rudower Chaussee 29 12489 Berlin Tel.: (030) 6392-3300 info@innominate.com www.innominate.com Die folgenden

Mehr

Systemempfehlungen. Sage HWP / Primus SQL 25.11.2013. Robert Gabriel ROCONGRUPPE

Systemempfehlungen. Sage HWP / Primus SQL 25.11.2013. Robert Gabriel ROCONGRUPPE 25.11.2013 Systemempfehlungen Sage HWP / Primus SQL Robert Gabriel ROCONGRUPPE Inhalt Einzelplatzrechner:... 2 Thema SQL Server... 2 Thema Microsoft Office... 3 Server/Netzwerke... 3 Hinweis SBS Server

Mehr

IT-Grundschutz-Zertifizierung von ausgelagerten Komponenten

IT-Grundschutz-Zertifizierung von ausgelagerten Komponenten Ergänzung zum Zertifizierungsschema Nr. 1 Titel ITGrundschutzZertifizierung von ausgelagerten Komponenten Status Version 1.0 Datum Diese Ergänzung zum Zertifizierungsschema gibt verbindliche Hinweise,

Mehr

Abruf und Versand von Mails mit Verschlüsselung

Abruf und Versand von Mails mit Verschlüsselung Bedienungstip: Verschlüsselung Seite 1 Abruf und Versand von Mails mit Verschlüsselung Die folgende Beschreibung erklärt, wie man mit den üblichen Mailprogrammen die E- Mailabfrage und den E-Mail-Versand

Mehr

PLESK 7 FÜR WINDOWS INSTALLATIONSANLEITUNG

PLESK 7 FÜR WINDOWS INSTALLATIONSANLEITUNG PLESK 7 FÜR WINDOWS INSTALLATIONSANLEITUNG Copyright (C) 1999-2004 SWsoft, Inc. Alle Rechte vorbehalten. Die Verbreitung dieses Dokuments oder von Derivaten jeglicher Form ist verboten, ausgenommen Sie

Mehr

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-5

Sicherheitstechnische Qualifizierung (SQ), Version 10.0 Security Assurance Level SEAL-5 Die Zertifizierungsstelle der TÜV Informationstechnik GmbH bescheinigt hiermit dem Unternehmen e-netz Südhessen GmbH & Co. KG Dornheimer Weg 24 64293 Darmstadt für das IT System Querverbundleitstelle Darmstadt

Mehr

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

Die Top 10 Gebote. der industriellen Datenkommunikation für mehr IT-Sicherheit

Die Top 10 Gebote. der industriellen Datenkommunikation für mehr IT-Sicherheit Die Top 10 Gebote der industriellen Datenkommunikation für mehr IT-Sicherheit 1. Gebot Sei einzigartig! Passwörter dienen dazu, jemanden zuverlässig zu identifizieren. Sehr kritisch und hoch bedroht sind

Mehr

Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware

Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware Das E-Mail-Programm Outlook 98 von Microsoft bietet Ihnen durch die Standard- Integration des E-Mail-Protokolls S/MIME (Secure/MIME) die Möglichkeit,

Mehr

Personal Firewall (PFW) und Virenscanner. Präsentation von Gunawati A.-Tillmann, Miguel Lopez und Andreas Angelkorte

Personal Firewall (PFW) und Virenscanner. Präsentation von Gunawati A.-Tillmann, Miguel Lopez und Andreas Angelkorte Personal Firewall (PFW) und Virenscanner Präsentation von Gunawati A.-Tillmann, Miguel Lopez und Andreas Angelkorte Gliederung Personal Firewall Virenscanner 1. Zweck einer Firewall 2. Funktionsweise einer

Mehr

B 5.11. Schicht Anwendungen. Apache-Webserver

B 5.11. Schicht Anwendungen. Apache-Webserver Schicht Anwendungen B 5.11 B 5.11 Apache-Webserver Beschreibung Der Apache-Webserver ist seit 1997 der bei weitem am häufigsten eingesetzte Webserver. Laut der Netcraft- Webserverstatistik war im August

Mehr

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen

Konzept für eine Highperformance- und Hochverfügbarkeitslösung für. einen Anbieter von Krankenhaus Abrechnungen Konzept für eine Highperformance- und Hochverfügbarkeitslösung für Anforderungen : einen Anbieter von Krankenhaus Abrechnungen Es soll eine Cluster Lösung umgesetzt werden, welche folgende Kriterien erfüllt:

Mehr

Checkliste IT-Sicherheit

Checkliste IT-Sicherheit Ist die Administration organisatorisch angemessen aufgebaut? Wie werden die Bereiche Benutzerverwaltung, Rechteverwaltung, Protokollauswertung sowie Netzwerk- und Systemsicherheit abgedeckt? Sind die Bereiche

Mehr

Serverumzug mit Win-CASA

Serverumzug mit Win-CASA Serverumzug mit Win-CASA Wenn Sie in Ihrem Netzwerk einen Umzug der Server-Version durchführen müssen, sollten Sie ein paar Punkte beachten, damit dies ohne Probleme abläuft. 1. Nachweis-Ordner In der

Mehr

1 Outlook 2013-Installation und Konfiguration

1 Outlook 2013-Installation und Konfiguration Outlook 2013-Installation und Konfiguration 1 Outlook 2013-Installation und Konfiguration Outlook kann in zwei Betriebsmodi verwendet werden: Exchange Server-Client: In diesem Modus werden die E-Mails

Mehr

Windows Server Update Services (WSUS)

Windows Server Update Services (WSUS) Windows Server Update Services (WSUS) Netzwerkfortbildung, Autor, Datum 1 WSUS in der Windows Was ist WSUS? Patch- und Updatesoftware von Microsoft, bestehend aus einer Server- und einer Clientkomponente

Mehr

Benutzerzertifikate für Java Webstart

Benutzerzertifikate für Java Webstart Benutzerzertifikate für Java Webstart Benutzerdokumentation Wien 5. Dezember 2011 Florian Bruckner, Florian Heinisch 3kraft IT GmbH & Co KG Wasagasse 26/2 1090 Wien Österreich Tel: +43 1 920 45 49 Fax

Mehr

Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH

Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH von Dominick Baier (dbaier@ernw.de) und Jens Franke (jfranke@ernw.de) 1 Einleitung Dieses Dokument behandelt die flexible

Mehr

Installationshinweise zur lokalen Installation des KPP Auswahltools 7.6

Installationshinweise zur lokalen Installation des KPP Auswahltools 7.6 Installationshinweise zur lokalen Installation des KPP Auswahltools 7.6 Installationsvoraussetzungen: Die Setup-Routine benötigt das DotNet-Framework 4.0 Client Profile, das normalerweise über Microsoft

Mehr

Wo ist mein Geld? Identitätsmissbrauch im Online-Banking. Christoph Sorge Universität des Saarlandes juris-stiftungsprofessur für Rechtsinformatik

Wo ist mein Geld? Identitätsmissbrauch im Online-Banking. Christoph Sorge Universität des Saarlandes juris-stiftungsprofessur für Rechtsinformatik Wo ist mein Geld? Identitätsmissbrauch im Online-Banking Christoph Sorge Universität des Saarlandes juris-stiftungsprofessur für Rechtsinformatik C. Sorge 2 Überblick Rechner des Kunden Server der Bank

Mehr

Quip Trade Business Manager auf Windows Terminal Server

Quip Trade Business Manager auf Windows Terminal Server Quip Trade Business Manager auf Windows Terminal Server 2009 by Fraas Software Engineering GmbH (FSE). Arne Schmidt. Alle Rechte vorbehalten. Fraas Software Engineering GmbH Sauerlacher Straße 26 82515

Mehr

Leitfaden zum sicheren Betrieb von Smart Meter Gateways

Leitfaden zum sicheren Betrieb von Smart Meter Gateways Leitfaden zum sicheren Betrieb von Smart Meter Gateways Wer Smart Meter Gateways verwaltet, muss die IT-Sicherheit seiner dafür eingesetzten Infrastruktur nachweisen. Diesen Nachweis erbringt ein Gateway-

Mehr

Abbildung der Gefährdungen der WASC und OWASP auf die Gefährdungen und Maßnahmenempfehlungen des IT-Grundschutz-Bausteins B 5.

Abbildung der Gefährdungen der WASC und OWASP auf die Gefährdungen und Maßnahmenempfehlungen des IT-Grundschutz-Bausteins B 5. Abbildung der Gefährdungen der WASC und OWASP auf die Gefährdungen und Maßnahmenempfehlungen des IT-Grundschutz-Bausteins B 5.21 Die Zusammenstellung der Gefährdungen für den Baustein 5.21 bediente sich

Mehr

Übersicht Kompakt-Audits Vom 01.05.2005

Übersicht Kompakt-Audits Vom 01.05.2005 Übersicht Kompakt-Audits Vom 01.05.2005 Bernhard Starke GmbH Kohlenstraße 49-51 34121 Kassel Tel: 0561/2007-452 Fax: 0561/2007-400 www.starke.de email: info@starke.de Kompakt-Audits 1/7 Inhaltsverzeichnis

Mehr

SMTP-Verfahren POP-Verfahren IMAP-Verfahren

SMTP-Verfahren POP-Verfahren IMAP-Verfahren IT Zertifikat Mailserver 01 Server Mailserver Protokolle Teil des Client-Server-Modells bietet Dienste für lokale Programme/ Computer (Clients) an -> Back-End-Computer Ausbau zu Gruppe von Servern/ Diensten

Mehr

Windows 7-Installation leicht gemacht

Windows 7-Installation leicht gemacht Windows 7-Installation leicht gemacht Wenn Sie Windows 7 haben wollen, und bisher nicht Windows Vista hatten, kommen Sie nicht um eine Komplettinstallation herum. Diese dauert etwa 45 Minuten. COMPUTER

Mehr

1 Installationen. 1.1 Installationen unter Windows

1 Installationen. 1.1 Installationen unter Windows 1 Installationen Dieses Kapitel beschreibt die Installationen, die für die Nutzung von PHP und MySQL unter Windows, unter Ubuntu Linux und auf einem Mac mit OS X notwendig sind. 1.1 Installationen unter

Mehr

Setup Time ix Zeitsystem Version 2.2

Setup Time ix Zeitsystem Version 2.2 Setup Time ix Zeitsystem Version 2.2 Stand 12/2011 Hotline von Mo bis Fr 08:30 bis 12:30 Uhr und Mo bis Do 13:30 bis 15:00 Uhr (außer Feiertage) Seite 1 / 7 Inhaltsverzeichnis Impressum 2 1. Zur Beachtung

Mehr

Root-Server für anspruchsvolle Lösungen

Root-Server für anspruchsvolle Lösungen Root-Server für anspruchsvolle Lösungen I Produktbeschreibung serverloft Internes Netzwerk / VPN Internes Netzwerk Mit dem Produkt Internes Netzwerk bietet serverloft seinen Kunden eine Möglichkeit, beliebig

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Migration/Neuinstallation der Rehm- Programme

Migration/Neuinstallation der Rehm- Programme Migration/Neuinstallation der Rehm- Programme Inhalt Systemvoraussetzungen... 2 Software... 2 Hardware... 2 Änderungen im Vergleich zur alten InstallShield-Installation... 2 Abschaffung der Netzwerkinstallation...

Mehr

TimePunch SQL Server Datenbank Setup

TimePunch SQL Server Datenbank Setup TimePunch TimePunch SQL Server Datenbank Setup Benutzerhandbuch 26.11.2013 TimePunch KG, Wormser Str. 37, 68642 Bürstadt Dokumenten Information: Dokumenten-Name Benutzerhandbuch, TimePunch SQL Server Datenbank

Mehr

KYOFLEETMANAGER DATA COLLECTOR AGENT VORAUSSETZUNGEN UND INSTALLATION

KYOFLEETMANAGER DATA COLLECTOR AGENT VORAUSSETZUNGEN UND INSTALLATION KYOFLEETMANAGER DATA COLLECTOR AGENT VORAUSSETZUNGEN UND INSTALLATION Bitte verwenden Sie diese Unterlagen, um vorab sicherzustellen, dass alle Voraussetzungen zur Installation des KYOfleetmanager DCA

Mehr

Informationen zu Schwachstellen

Informationen zu Schwachstellen 40 DFN Mitteilungen Ausgabe 77 November 2009 SICHERHEIT Informationen zu Schwachstellen Das neue DFN-CERT Portal (Teil 2) Text: Gerti Foest (DFN-Verein), Torsten Voss (DFN-Cert Services GmbH) Foto: moodboard,

Mehr