WebSecurity - Joomla

Aus THM-Wiki
Wechseln zu: Navigation, Suche
Dokumentation
Arbeitstitel WebSecurity - Joomla
Kurs Web Security
Semester SS 10
Teilnehmer James Antrim, Wolf Rost, Dennis Sack, Jochen Woidich, Alexander Ahrendt, Christian Peter, Markus Baier, Dennis Priefer
Programmiersprache PHP

Diese Seite dient zur Dokumentation des erarbeiteten Sicherheitskonzeptes für Joomla!(MNI-Seite) im Rahmen des Kurses Web Security im SS 2010.

Inhaltsverzeichnis

Konzept

Analyse und Bewertung der bestehenden Sicherheitsmaßnahmen des Zielsystems

(Autor: Peter, Woidich)

Die Klasse JDatabase

Die Klasse JDatabase des Joomla!-Frameworks stellt die Methode Quote() zur Verfügung. Mit dieser Methode werden angreifende SQL-Injections vorgebeugt und vermieden. Intern wird die Methode getEscaped() aufgerufen, die bisher nur ein return; macht. Der Entwickler hat hier die Möglichkeit seine eigene Implementierung vorzunehmen.

--Christian.peter:mni 18:22, 9. Sep. 2010 (CEST) --Jochen.uwe.woidich:mni.fh-giessen 19:51, 24. Sep. 2010 (CEST)

Die Methode Quote()

Durch die Methode Quote() wird eine übergebene Datenbankanfrage escaped, um somit angreifende SQL-Injections zu vermeiden. Intern wird hier die Methode getEscaped() benutzt, die aber so keine Implementierung hat. Die Implementierung scheint von den Entwicklern des Joomla-Frameworks vorgesehen zu sein, aber bis zur heutigen Version noch nicht realisiert wurde.

--Christian.peter:mni 18:22, 9. Sep. 2010 (CEST) --Jochen.uwe.woidich:mni.fh-giessen 19:51, 24. Sep. 2010 (CEST)

Die Klasse JFilterInput

Die Aufgabe der Klasse JFilterInput des Joomla!-Frameworks ist es, Eingabe auf verdächtigen Code hin zu überprüfen. Die dient somit als Filter für Eingabedaten und bereinigt von Benutzern eingegebene Formular-Daten.

--Christian.peter:mni 10:25, 13. Sep. 2010 (CEST) --Jochen.uwe.woidich:mni.fh-giessen 19:51, 24. Sep. 2010 (CEST)

Die Methode checkAttribute()

Die Methode checkAttribute() überpüft die übergebenen Eingabedaten auf das Vorkommen von Inhalten wie:

  • expression
  • style
  • javascript:
  • behaviour:
  • vbscript:
  • mocha:

Die Methode liefert im Falle von Bad Code den Rückgabewert true. Es kann somit also genau festgestellt werden, ob sich in den Eingabedaten irgendwelche unerwünschte Attribute befinden.

--Christian.peter:mni 10:25, 13. Sep. 2010 (CEST) --Jochen.uwe.woidich:mni.fh-giessen 19:51, 24. Sep. 2010 (CEST)

Die Methode clean()

Die Methode clean() überprüft übergebene Daten anhand von regulären Ausdrücken und stellt sicher, dass nur Typen wie INT, FLOAT, BOOLEAN, WORD, ALNUM, CMD, BASE64, STRING, ARRAY, PATH, NONE aus den Daten gefiltert werden. Alle Inhalte, die nicht auf den Filtertyp passen werden verworfen und nicht weiter berücksichtigt. Durch diesen Filter kann man gewährleisten, dass die Eingabedaten den gewünschten Datentypen enthalten. Erwartet man beispielsweise aus einem Eingabefeld eine Ganzzahl, werden die Daten mit dem Filter INT bzw. INTEGER überprüft.

--Christian.peter:mni 12:32, 13. Sep. 2010 (CEST) --Jochen.uwe.woidich:mni.fh-giessen 19:51, 24. Sep. 2010 (CEST)

Die Klasse JFilterOutput

Mit der Klasse JFilterOutput stellt Joomla! 1.5 einen weiteren vorgefertigten Mechanismus zur Verfügung, um Daten von schadhaften Inhalten zu befreien und sie so für die Ausgabe vorzubereiten

--Christian.peter:mni 10:25, 13. Sep. 2010 (CEST) --Jochen.uwe.woidich:mni.fh-giessen 19:51, 24. Sep. 2010 (CEST)

Die Methode objectHTMLSafe()

Diese Methode dient dazu, Objekte für die Ausgabe in HTML-Formularen vorzubereiten. Zu diesem Zweck werden in Member-Variablen des Objektes vorkommende Sonderzeichen mit der Hilfe der PHP-Funktion htmlspecialchars in entsprechende HTML-Entitäten umgewandelt.

--Jochen.uwe.woidich:mni.fh-giessen 19:51, 24. Sep. 2010 (CEST)

Die Methode linkXHTMLSafe()

Wandelt das Zeichen "&" in Links in die HTML-Entität "&amp" um. Dadurch wird verhindert, dass Links manipuliert und z.B. für XSS-Attacken eingesetzt werden können.

--Christian.peter:mni 12:32, 13. Sep. 2010 (CEST) --Jochen.uwe.woidich:mni.fh-giessen 19:51, 24. Sep. 2010 (CEST)

Die Methode stringURLSafe()

Bereitet den Übergebenen String für die Verwendung als GET-Parameter in einer URL vor. Zu diesem Zweck werden alle UTF8-Zeichen (insbesondere Umlaute) in passende ASCII7-Zeichen konvertiert und überflüssige Whitespaces entfernt.

--Christian.peter:mni 12:32, 13. Sep. 2010 (CEST) --Jochen.uwe.woidich:mni.fh-giessen 19:51, 24. Sep. 2010 (CEST)

Bisherige Verwendung der Klassen in Joomla!

Die Kernkomponenten und Module des Joomla-Frameworks verwenden bereits die Klassen JDatabase, JFilterInput und JFilterOutput. Im Rahmen der Implementierung der MNI-Seite werden aber nur die Filterklassen JfilterInput und JFilterOutput teilweise verwendet.

--Christian.peter:mni 12:32, 13. Sep. 2010 (CEST) --Jochen.uwe.woidich:mni.fh-giessen 19:51, 24. Sep. 2010 (CEST)

Fazit

Joomla! bietet einige Möglichkeiten, um die häufigsten Sicherheitsprobleme zu vermeiden, verfügt jedoch nicht über eine zentrale Sicherheitsinstanz. Ein weiteres Problem ist, dass viele der im Laufe der Zeit hinzugekommenen Komponenten der MNI-Seite nicht ausreichend auf die vorhandenen Möglichkeiten zurückgreifen und damit potentiell angreifbar erscheinen.

--Christian.peter:mni 12:29, 8. Sep. 2010 (CEST) --Jochen.uwe.woidich:mni.fh-giessen 19:51, 24. Sep. 2010 (CEST)

Schutzbedarfsfeststellung für die Einsatz-Szenarien der MNI-Seite

(Autor: Ahrendt, Sack)

Die THM Giessen stellt eine öffentliche Homepage für den Fachbereich MNI zur Verfügung, welche repräsentativ für die TH, den Fachbereich sowie die damit verbundenen Personen ist. Diese basiert auf Joomla! und ist für jedermann erreichbar und somit sehr sicherheitskritisch zu bewerten. Um nun den Schutzbedarf der Applikation festzustellen, müssen zunächst die einzelnen Einsatz-Szenarien identifiziert werden, um sie dann sicherheitskritisch einzustufen.

--Alexander.ahrendt:mni 16:15, 22. Sep. 2010 (CEST)

Welche Einsatz-Szenarien gibt es?

Das grundsätzliche Einsatz-Szenario der Webapplikation ist die Bereitstellung von Informationen über das Internet und ist somit also als Homepage zu verstehen. Hierbei gibt es folgende zwei Bereiche, in welche die Applikation gegliedert ist:

  • Frontend
  • Backend

Das Frontend wiederum ist in einen öffentlichen und einen privaten bzw. Mitglieds Bereich unterteilt. Die Besucher der Webseite haben also die Möglichkeit sich zum einen anonym als auch autorisiert als angemeldeter Nutzer auf der Plattform zu bewegen.

Das Backend wiederum ist verständlicherweise nur für autorisierte Nutzer zugänglich und erfordert somit eine Anmeldung die den Nutzer identifiziert.

--Alexander.ahrendt:mni 16:15, 22. Sep. 2010 (CEST)

Benutzergruppen in Joomla! 1.5:

In Joomla! 1.5 wird zwischen verschiedenen Benutzergruppen unterschieden. Veröffentlichte Inhalte oder Menüpunkte sind entweder öffentlich (public) oder nur für registrierte Benutzer verfügbar.

Jeder Benutzer gehört zu einer Gruppe mit bestimmten Rechten. Die Gruppenzugehörigkeit teilt sich in zwei große Bereiche. Benutzer, die sich nur im Frontend anmelden dürfen, und Benutzer, die sich in der Joomla!-Administration bzw. im Backend anmelden dürfen. Alle Inhalte in Joomla! 1.5 können diesen Gruppen zugeordnet werden. Es gibt 4 Benutzergruppen für das Frontend und 3 Benutzergruppen für das Backend.

Die Zuweisung von Benutzern zu diesen Benutzergruppen wird vom Administrator im Backend, unter „Benutzerverwaltung, des Systems vorgenommen.

Hier ein kurzer Überblick über die verschiedenen Benutzergruppen:

--Alexander.ahrendt:mni 16:15, 22. Sep. 2010 (CEST)

Frontend

Registered
Ein registrierter Benutzer darf sich einloggen und teile der Seite sehen, die ein Besucher nicht sehen darf.
Author
Kann im Frontend Inhalte ins System eingeben und eigene Inhalte bearbeiten. Diese Inhalte müssen von einem Mitglied einer Backend-Benutzergruppe freigeschaltet werden, um sichtbar zu sein.
Editor
Hat alle Rechte von „Author“. Zusätzlich kann ein Editor ALLE Inhalte im Frontend editieren. Allerdings, müssen auch von ihm eingegebene Inhalte freigeschaltet werden.
Publisher
Hat alle Rechte von „Editor“. Seine Inhalte müssen nicht von einem Mitglied einer Backend-Benutzergruppe freigeschaltet werden.

--Alexander.ahrendt:mni 16:15, 22. Sep. 2010 (CEST)

Backend

Manager
Hat Zugriff auf das Backend. Er kann somit Menüs bearbeiten, Sections und Categories erstellen und hat Zugriff auf Statistiken und den Media Manager. Er kann, wie der Publisher Inhalte einfügen und Inhalte von anderen Usern editieren. Zudem verfügt er über das Recht, Inhalte von Mitgliedern von Frontend-Gruppen freizuschalten.
Administrator
Hat alle Rechte von „Manager“. Er kann Komponenten, Module und Mambots verwalten. Zudem ist er berechtigt, Benutzer zu verwalten und kann dort Rechte bis „Administrator“ vergeben.
Super Administrator
Hat alle Rechte von „Administrator“. Zudem kann er Templates installieren, Systemnachrichten empfangen, Systeminfos abfragen und alle Inhalte global einchecken.

Das Anlegen von eigenen Benutzergruppen ist bei Joomla! 1.5 nicht möglich. Dies kann man als Sicherheitsproblem sehen, da man nicht genau festlegen kann, was ein Benutzer im Speziellen können darf.

--Alexander.ahrendt:mni 16:15, 22. Sep. 2010 (CEST)

Bewertung kritischer Interaktionspunkte:

Die Interaktionspunkte die hauptsächliche Angriffspunkte darstellen, werden folgend identifiziert und sicherheitskritisch eingestuft.

--Alexander.ahrendt:mni 16:15, 22. Sep. 2010 (CEST)

Frontend - Public

Als anonymer Nutzer hat man folgende Möglichkeiten mit der Anwendung zu interagieren:

--Alexander.ahrendt:mni 16:15, 22. Sep. 2010 (CEST)

Suche / Login

Die Suche und der Login sind wie gewöhnlich als Eingabefelder realisiert und senden eine Anfrage an die dahinter stehende Datenbank. Hierbei währen beispielsweise SQL- oder XSS-Injektions denkbar, wodurch kritische Daten erspäht werden könnten. Schafft es hierbei ein Angreifer sich Zugang als beispielsweise Superadmin zu verschaffen, hat er die Möglichkeit alles Sichtbare der Anwendung zu modifizieren. Die Möglichkeit Einstellungen wie Rechtevergabe, Datenbankinhalte etc. zu verändern besteht nicht und somit ist der Schutzbedarf an dieser Stelle zwar hoch jedoch hinter dem des Backends einzustufen. Allerdings kann der Angreifer die erspähten Daten dazu nutzen sich im Backend einzuloggen. Hierbei nutzt der Angreifer die Schwäche des Joomlasystems 1.5, die darin besteht, dass die Adresse des Backends nicht veränderbar und somit allgemein bekannt ist.

--Alexander.ahrendt:mni 16:15, 22. Sep. 2010 (CEST)

Backend

Im Backend bestehen die größten Möglichkeiten ins System einzugreifen und dieses zu verändern. Dies ist so gewollt, da hier nur Benutzer Zugang haben, die in einer Backend-Benutzergruppe sind. Im vorliegenden Szenario (Bereitstellung einer Website für den Fachbereich MNI), sind hier vorwiegend Dozenten und Mitarbeiter der FH in einer dieser Backend-Benutzergruppe. Die Frage ist nun, wie sicherheitskritisch diese Benutzer betrachtet werden müssen. Problematisch ist, wenn, wie oben erwähnt, sich ein Angreifer die Login-Daten einer dieser berechtigten Benutzer verschafft.

Zudem ist das Backend bei einer Joomla!-Installation immer unter derselben URL zu erreichen. Somit kann auf die Login-Felder des Backend-Bereichs sehr leicht ein Angriff durchgeführt werden. Dieser kann beispielsweise durch eine Brute-Force-Methode realisiert werden.

--Alexander.ahrendt:mni 16:15, 22. Sep. 2010 (CEST)

Fazit

Zusammenfassend kann gesagt werden, dass alle Eingabefelder abgesichert werden müssen. Dies muss unabhängig davon geschehen, in welcher Rolle ein Benutzer ist und ob er sich im Front- oder Backend befindet.

--Alexander.ahrendt:mni 16:15, 22. Sep. 2010 (CEST)

Konzeption und Implementierung eines IPS basierend auf PHPIds für Joomla!

(Autor: Antrim, Rost)

Idee

PHPIDS wird mittels eines System-Plugins in Joomla! integriert. Das Plugin überwacht alle Eingaben und protokolliert entdeckte Angriffe.--Wolf.normann.gordian.rost:mni.fh-giessen 11:06, 24. Sep. 2010 (CEST)

Plugin:

Die Angriffe werden in eine Datenbank geschrieben falls die Komponente(s. nächsten Abschnitt) installiert ist. Auf jedenfall werden alle Angriffe in ein Log-File geschrieben und gegebenenfalls eine E-Mail an den Administrator geschickt wenn der Impactwert zu hoch ist oder zu viele Angriffe von einem Benutzer stammen.

Im Backendbereich des Plugins kann konfiguriert werden wohin protokolliert werden soll (Datenbank, Log-File, Email).

Außerdem was bei welchem Impactwert geschehen soll (Impactwert > 50 -> Email an Administrator, etc...).--Wolf.normann.gordian.rost:mni.fh-giessen 11:06, 24. Sep. 2010 (CEST)

Spezifizierung der abzulegenden Daten:

Folgende Informationen sollten in der Komponente dargestellt werden:

  • Typ des Angriffs (XSS,SQL-Injection,....)
  • Angriffszeitpunkt
  • Ziel des Angriffs (Welches Modul bzw. welche Komponente in Joomla ist betroffen)
  • Statistische Auswertung (Graph,...)
  • Angriffsherkunft (interner-oder externer Angriff)
  • Impact des Angriffs (Darstellung als Zahl und farbliche Markierung)
  • Interpretation des Impact (kritisch, unkritisch oder Fehlalarm)
  • Informationen über den Angreifer (IP-Adresse, Username, Session-ID zur Überprüfung von internen Benutzern)

Es gibt ein System-Plugin das sich EasyIDS nennt. EasyIDS wurde von EasyJoomla entwickelt und ist unter der GNU/GPL Lizenz frei verfügbar.

In EasyIDS wird phpIDS verwendet um Angriffe zu erkennen. Die Angriffe werden nur protokolliert aber keine Gegenmaßnahmen ergriffen.

Das System-Plugin EasyIDS wird von uns verändert und an unsere Ansprüche angepasst. D.h. es werden Angriffe protokolliert und auf diese Angriffe reagiert.

Somit wird aus dem EasyIDS Plugin ein selbst entwickeltes IPS-Plugin für Joomla!.--Wolf.normann.gordian.rost:mni.fh-giessen 11:06, 24. Sep. 2010 (CEST)

Maßnahmen:

IDS Ablauf

Maßnahmen gegen den Angreifer wären zum Beispiel:

  • Der Angreifer muss zuerst ein reCaptcha ausfüllen bevor er weiter machen kann
  • Der Angreifer wird auf eine Error Page weitergeleitet
  • Angemeldete Benutzer werden ausgeloggt und müssen auch erst ein reCaptcha ausfüllen
  • Der Benutzer wird aus dem System für einen Zeitraum oder für immer ausgeschlossen--Wolf.normann.gordian.rost:mni.fh-giessen 11:06, 24. Sep. 2010 (CEST)

Ablauf:

In der Abbildung rechts wird der Eingabe Prozess angegeben so wie er realisiert werden soll. Unterschieden wir am Anfang ob bei der Eingabe ein reCaptcha verwendet wurde oder nicht. Wird ein reCaptcha verwendet muss überprüft werden ob es korrekt ist. Ist es falsch musserneut ein reCaptcha eingegeben werden oder falls die maximalen reCaptcha-Versuche getätigt wurden, wird der Vorgang protokolliert und der Benutzer eine Zeitlang gesperrt. Ist es jedoch korrekt oder wurde gar kein reCaptcha verwendet werden die Eingaben durch PHPIDS überprüft.

Werden keine Angriffe entdeckt werden die Daten auf Gültigkeit überprüft und der Benutzer ist eingeloggt. Werden jedoch Angriffe entdeckt wird je nach Schwere des Angriffs dieser protokolliert und eventuell der Benutzer gesperrt. Ist der Impactwert des Angriffes gering hat der Benutzer noch einmal die Chance die Eingabe zu wiederholen.--Wolf.normann.gordian.rost:mni.fh-giessen 11:06, 24. Sep. 2010 (CEST)

Überwachung und statistische Auswertung der aufgezeichneten Angriffsversuche

(Autor: Baier, Priefer)

Idee

Zur Überwachung und statistischen Auswertung der aufgezeichneten Angriffsversuche soll eine Komponente sowie ein Modul entwickelt werden. --Dennis.priefer:mni 22:21, 7. Sep. 2010 (CEST)

Komponente:

Die Komponente legt bei der Installation eine Datenbanktabelle an, in welche das IDS-Plugin Angriffsinformationen schreibt, sobald die Komponente installiert ist. Die Komponente kann dann im Backend administriert werden. Zusätzlich kann der Administrator im Backend die Angriffe Überwachen, d.h. er bekommt Statistiken über die Angriffe angezeigt, und kann daraufhin handeln (z.B. bei mehrfachem Angriff).

Sie soll einige Views für die Veranschaulichung der Angriffsversuche beinhalten. Dazu muss eine Logik implementiert werden, welche die Angriffsversuche auswertet und als Statistik anzeigt, bestenfalls mit zusätzlichen Grafiken. Die Grafiken sollen dann die in der Spezifikation festgelegten Informationen so darstellen, dass der Administrator der Seite sofort, wenn nötig, Gegenmaßnahmen einleiten kann.

Letztendlich soll die Komponente nur zur Darstellung der Angriffe genutzt werden und dem Administrator als Stütze dienen, die Angriffe auf das System in formatierter Form einzusehen. --Dennis.priefer:mni 22:21, 7. Sep. 2010 (CEST)

Spezifizierung der Komponenten-View:

Folgende Informationen sollten in der Komponente dargestellt werden:

  • Typ des Angriffs (XSS,SQL-Injection,....)
  • Angriffszeitpunkt
  • Ziel des Angriffs (Welches Modul bzw. welche Komponente in Joomla ist betroffen)
  • Statistische Auswertung (Graph,...)
  • Angriffsherkunft (interner-oder externer Angriff)
  • Impact des Angriffs (Darstellung als Zahl und farbliche Markierung)
  • Interpretation des Impact (kritisch, unkritisch oder Fehlalarm)
  • Informationen über den Angreifer (IP-Adresse, Username, Session-ID zur Überprüfung von internen Benutzern)

--Dennis.priefer:mni 22:21, 7. Sep. 2010 (CEST)

Modul:

Es soll ein Modul entwickelt werden, welches im Frontend (ggf. auch im Backend) versuchte Angriffe anzeigt. Dies soll ähnlich dem Modul auf der Seite von PHPIDS fungieren und dem Administrator(ggf. auch anderen Usern) nach einem Login die versuchten Angriffe anzeigen.

Das Modul dient ebenfalls nur der Darstellung der Angriffe.

--Markus.baier:mni 09:36, 8. Sep. 2010 (CEST)


Spezifizierung der Modul-View:

Vision – Modul

Das Modul soll im Backend konfigurierbar sein. Die Darstellung des Moduls soll an die der PHPIDS-Seite angelehnt werden. (siehe: Attacks against us). Des Weiteren soll es möglich sein die Darstellung nach seinen eigenen Bedürfnissen anzupassen. Dies geschieht über Modulparameter, die im Backendbereich des Moduls ausgewählt werden können.

--Markus.baier:mni 09:36, 8. Sep. 2010 (CEST)

Weiteres:

Als zusätzliches Feature soll es möglich sein, bereits vorhandene Log-Protokolle per Datenbankimport in die Datenbank zu schreiben. Dies wäre der Fall, falls die Komponente/das Modul nach dem Plug-In(s. Plug-In für IDS-Funktion) installiert werden sollte. --Dennis.priefer:mni 22:21, 7. Sep. 2010 (CEST)

Konzeptdiagramm:

Konzeptdiagramm

Das folgende Diagramm zeigt das komplette Konzept der Architektur des Projektes. Es zeigt das Zusammenspiel der verschiedenen Komponenten(Komponente, Modul, Plugin) sowie deren Arbeitsweise.

Das Plugin kann völlig selbstständig ohne die Komponente arbeiten. Ist dies der Fall, werden erkannte Angriffe nur in Logfiles niedergelegt, da dann keine Datenbank vorhanden ist. Wird die Komponente später nachinstalliert, können die Angriffe auch in der Datenbank protokolliert werden. Zuvor geloggte Angriffe können durch einen Datenbankimport nachträglich in der Datenbank aufgenommen werden. Das funktioniert, da das Plugin die Angriffe nicht nur als für den Mensch lesbare Logdatei ablegt, sondern eine zusätzliche Logdatei im JSON-Format ablegt, welche später besser für den Import in die Datenbank geeignet ist. Es soll allerdings im Administratorbereich des Plugins konfigurierbar sein, in welcher Form die Angriffe abgelegt werden. --Dennis.priefer:mni 22:21, 7. Sep. 2010 (CEST) Das Modul kann ohne Komponente nicht arbeiten, da es ebenfalls die Datenbank als Quelle benutzt. Die Komponente, sowie das Modul können nun die Daten aus der Datenbank auslesen, verarbeiten und angepasst für den Benutzer auf der Seite anzeigen.--Markus.baier:mni 10:19, 15. Sep. 2010 (CEST)

Umsetzung

Plugin plg_giessenAegis

(Autor: Antrim, Rost)

PHPIDS wurde durch ein System-Plugin in Joomla! integriert. Ein System-Plugin wird in Joomla! direkt nach dem laden des Joomla!-Frameworks ausgeführt. Somit können Benutzereingaben mittels PHPIDS überprüft und eventuell Gegemaßnahmen ergriffen werden. Das heißt giessenAegis fungiert auch gleichzeitig als IPS. Das Plugin giessenAegis arbeitet autark was bedeutet dass die Komponente com_giessenAegis und das Modul mod_giessenAegis nicht installiert sein müssen. Jede Benutzereingabe wird auf eine mögliche Attacke überprüft. Wurde eine Attacke entdeckt kann anhand des Impactwerts die Schwere des Angriffs ermittelt werden. Dadurch können dann entsprechende Gegenmaßnahmen ergriffen werden. Plugin Giessen Aegis verfügt aber über weitere zusätzliche Funktionalitäten. Administratoren können für Testzwecken den Simulationsmodus anschalten um die Reaktionen des IPS zu prüfen. Im Backend können mittel PHP IDS Update die aktuellsten Bedrohungsdefinitionen heruntergeladen werden. Somit kann das System immer aktuell und sicher gehalten werden.--James.antrim:mni 11:56, 17. Sep. 2010 (CEST) --Wolf.normann.gordian.rost:mni.fh-giessen 11:02, 24. Sep. 2010 (CEST)

Gegenmaßnahmen

Die Attacken werden in ein LogFile (joomlaids.log.php) gespeichert welches in dem Logs Ordner von Joomla! liegt. In diesem LogFile sind die Attacken wie im Konzeptteil zum Plugin giessenAegis beschrieben aufgelistet. Ist die Komponente com_giessenAegis installiert werden die Attacken auch in die Datenbank geschrieben. Siehe dazu Komponente com_giessenAegis Abschnitt Datenbank. Weitere Maßnahmen sind Benachrichtigung des Benutzer über seine Aktivitäten, Email an den Administrator, Ausloggen des Benutzers und Bannen des Benutzerkontos oder der IP für eine bestimmte Zeit. Das Benutzerkonto wird permanent gebannt bis ein Administrator den Benutzer wieder freigibt und die IP nur über einen bestimmten (im Backend einstellbar) Zeitraum. Es ist durchaus möglich das mehrere Maßnahmen auf einmal ergriffen werden. Um auch Benutzeraktivitäten über einen Zeitraum aufzeichen zu können werden die Angriffe und Impactwerte in der UserSession bzw. in der Datenbank gespeichert. Somit ist es möglich die Impactwerte über einen bestimmten Zeitraum für einen Benutzer zusammenzuaddieren und so eine höhere Gegenmaßnahme einzuleiten. --James.antrim:mni 11:56, 17. Sep. 2010 (CEST) --Wolf.normann.gordian.rost:mni.fh-giessen 11:02, 24. Sep. 2010 (CEST)

Neben den IPS-Funktionen stellt plg_giessenAegis ebenfalls die Integration von reCaptcha als Schutz vor automatisierten Angriffen und Crawlern zur Verfügung. Das Plugin protokolliert die Uhrzeit jeder Anfrage und berechnet in konfigurierbaren Intervallen die durchschnittliche Zeit zwischen den einzelnen Anfragen. Liegt der errechnete Wert unter einem (ebenfalls konfigurierbaren) Schwellwert wird der anfragende Client automatisch zu einem reCaptcha umgeleitet, dass er zwingend lösen muss, um die Seite weiter nutzen zu können. --Jochen.uwe.woidich:mni.fh-giessen 19:52, 24. Sep. 2010 (CEST)

Backend

Backend des System-Plugins giessenAegis

Im administrativen Bereich von Joomla! das sogenannte Backend ist vieles am Plugin einstellbar. Im Bild sind die Plugin Einstellungen dargestellt.

Operation Mode Modus in dem der Plugin arbeiten soll.
Mode Selection Betrieb kann in den Simulationsmodus gesetzt werden. In Simulationsmodus werden alle Angriffe geloggt aber es hat keine Konsequenzen für den Angreifer ie. Ausloggen/Bannen.
Dependencies Abhängigkeiten die für den korrekten/vollständigen Betrieb des Plugins benötigt werden.
PHP IDS Update Aktualisiert bzw läd alle Dateien/Ordner der aktuellsten PHP IDS Bibliothek herunter. Dies ist nötig um neue und neu erfasste Bedrohungsdefinitionen abzufangen und zu bearbeiten. Diese Bibliothek umfasst mehrere hundert Dateien und das Aktualisieren kann bis zu anderthalb Minuten dauern.
Component Status Überprüft ob die Komponente Giessen Aegis installiert ist. Dies ist zwar nicht nötig für die Verteidigung des Zielsystems dennoch erweitert es die Funktionalitäten des Plugins wie etwa Log in die Datenbank Tabellen. Ein grünes Häckchen wird agezeigt falls die Komponente installiert ist, sonst ein rotes "X".
Countermeasure Thresholds Hier können feste Werte für die Bedrohungsschwelle angegeben werden. Ab dennen eine bestimmte Gegenmaßnahmen ausgeführt wird.
Activity Time Die Zeit (in Minuten) für die eine Bedrohungsschwelle für den jeweiligen Benutzer berechnet werden soll.
... Wert der Hemmschwelle für die jeweilige Gegenmaßnahme.
Countermeasure Specific Settings Weitere Einstellungen bezogen auf bestimmte Gegenmaßnahmen.
Warning Type Welche Art der Anzeige an den Benutzer ausgegeben werden soll: wahlweise Webpage/Ressource Anzeige, Text, Meldungen spezifisch der Gegenmaßnahme.
Display URL URL der anzuzeigenden Webpage/Ressource falls Anzeige Meldungen gewählt sind.
Warning Text Text der angezeigt werden sollte falls Text Meldungen gewählt sind.
Mail Recipients Eine Liste der Systemadministratoren, welche im Falle eines Angriffs benachrichtigt werden.
Log Management Elemente für das Kürzen bzw Löschen des Logs
Date Ein Datum welches durch einen Kalender ausgewählt werden kann. Dieses wird für das Kürzen des Logs verwendet. Falls leer wird der komplette Log gelöscht.
Log File Die größe der Log Datei wird angezeigt (falls vorhanden). Diese Größe wird in KB bzw MB dargestellt. Größen bis zu 10 MB werden grün gefärbt danach in rot. Die Datei selbst kann per Knopfdruck angezeigt oder "gelöscht" werden. Löschen beinhaltet das löschen der Logeinträge älter als das Datum in dem "Date" Parameter, sollte "Date" leer sein wird der Log komplett gelöscht.
Log DB Die Anzahl der Datenbankeinträge werden angezeigt (falls vorhanden). Sollte die Komponente Giessen Aegis nicht installiert sein, und somit die Datenbanktabelle wird ähnlich wie in "Component Status" ein rotes "X" angezeigt. Zudem kann per Knopfdruck Datenbankeinträge älter als das Datum in dem "Date" Parameter gelöscht werden, sollte "Date" leer sein wird die Datenbanktabelle geleert.
reCaptcha Settings Einstellungen für die Captcha Funktionalität
reCaptcha Public Key Public Key für das reCaptcha Verfahren
reCaptcha Private Key private Key für das reCaptcha Verfahren
reCaptcha Request Threshold Anzahl der Requests nach dennen überprüft wird ob die Zeit in reCaptcha Avg Request Time überschritten wurde
reCaptcha Avg Request Time Zeit die die maximale Durchschnittszeit zwischen der Anzahl der Request in reCaptcha Request Threshold angibt
White Lists Hier werden Komponenten Ansichten ausgewählt die nicht vom Giessen Aegis Plugin berücksichtigt werden sollen.
... Auswählbare Listen der Komponent Ansichten der Öffentlichen und Administrativen Bereiche

--James.antrim:mni 11:56, 17. Sep. 2010 (CEST) --Wolf.normann.gordian.rost:mni.fh-giessen 11:02, 24. Sep. 2010 (CEST)









Komponente com_giessenAegis

Das zuvor erwähnte Plugin plg_giessenAegis diente unter anderem zur Ermittlung bestimmter Messdaten bezüglich sicherheitskritischer Benutzerinteraktionen. Die Komponente com_giessenAegis benutzt nun diese ermittelten Daten, bereitet sie auf und stellt diese dem Administrator zur Verfügung. Diese Aufbereitung findet man als dessen grafische Darstellung wieder. Somit wird die statistische Auswertung dieser Daten erheblich vereinfacht und die daraus resultierenden Sterungsprozesse optimiert. Außerdem enthält die Komponente Funktionen, die Ermittlung und die Darstellung der Daten sowie das zuvor erwähnte Plugin zu Verwalten und zu Steuern. Somit bietet es beispielsweise eine Übersicht der vom Plugin gebannten User und die Möglichkeit diese wieder zuzulassen sowie eine Verwaltungsmöglichkeit der genutzten Attackentypen. Die Komponente ist erweiterbar und sollte im Endstadium die vollständige Verwaltung und Steuerung der Statistiken sowie des Plugins übernehmen. --Dennis.priefer:mni 22:14, 7. Sep. 2010 (CEST)

--Alexander.ahrendt:mni 16:22, 22. Sep. 2010 (CEST)

Datenbank

Das PHPIDS berechnet aufgrund sicherheitskritischer Benutzeraktivitäten eine numerische Bedrohungsschwelle und führt somit zu entsprechenden Maßnahmen. Eine Maßnahme ist unter anderem das Loggen bzw. Sammeln von im Zusammenhang stehender, relevanter Daten. Um diese Daten später statistisch auswerten zu können, werden diese Daten, falls com_giessenAegis installiert ist, zusätzlich zur Log-Datei auch in folgender erläuterten Datenbank gespeichert.

Hierfür gibt es folgende zwei Datenbanktabellen:

--Alexander.ahrendt:mni 16:22, 22. Sep. 2010 (CEST)

Sicherung der geloggten Angriffe

Dies ist die Datenbanktabelle namens jos_giessen_aegis_attacks, welche vollständig zur Speicherung der statistischen Daten dient. Sie enthält Platz für folgend Parameter:

Darstellung der Datenbanktabelle in UML Format
Parameter Bedeutung
id Eindeutige Id d. Eintrags
ip IP d. Benutzers
userid ID d. Benutzers
attacks Enthaltende Angriffsarten (xss/csrf/id/...)
vector Benutzereingabe
impact Impact (PHPIDS-Bedrohungsschwelle)
timestamp Datum
url URL der Quellseite
vectortype Benutzte Methode (GET/POST/...)
field Name des Eingabefelds

--Dennis.priefer:mni 22:14, 7. Sep. 2010 (CEST)

--Alexander.ahrendt:mni 16:22, 22. Sep. 2010 (CEST)

--Christian.peter:mni 17:14, 25. Sep. 2010 (CEST)

Auflistung der möglichen Attackentypen

In dieser Tabelle namens jos_giessen_aegis_attacks werden die nach PHPIDS gängigen Attackentypen abgelegt. Diese Liste ist vordefiniert, kann aber über die Komponente modifiziert werden. So ist es möglich, Attackentypen einzutragen, zu bearbeiten sowie zu löschen. Die Einträge dieser Tabelle beziehen sich auf die in jos_giessen_aegis_log - attacks abgelegten Werte und dienen zur Zuordnung von Abkürzung und Langname.

Darstellung der Datenbanktabelle in UML Format
Parameter Bedeutung
id Eindeutige Id d. Eintrags
abbr Abkürzung des Attackentyps
fullname Vollständiger Name des Attackentyps

--Dennis.priefer:mni 22:14, 7. Sep. 2010 (CEST)

--Alexander.ahrendt:mni 16:22, 22. Sep. 2010 (CEST)

--Christian.peter:mni 17:16, 25. Sep. 2010 (CEST)

Statistiken

Wie oben beschrieben werden auf Grund sicherheitskritischer Benutzeraktivitäten relevante Messdaten gesammelt. Damit der Administrator nun diese Daten ensprechend auswerten kann, werden sie ihm übersichtlich grafisch dargestellt. Somit ist es leichter möglich die gesammelten Daten auszuwerten und entsprechend schnell zu reagieren.

--Alexander.ahrendt:mni 16:22, 22. Sep. 2010 (CEST)

Realisierung

Realisiert wurde diese Aufbereitung der Daten mit Hilfe der Bibliothek jpGraph, welche frei nutzbar und sehr gut zum Darstellen von Graphen geeignet ist. jpGraph ist vollständig in PHP implementiert und konnte somit ohne große Schwierigkeiten in die Komponente integriert werden, sodass bei einer Neuinstallation der Komponente alle benötigten Klassen vorhanden sind.

Zur Zeit sind fünf verschiedene Statistiken in der Komponente implementiert, welche man grundsätzlich folgenden zwei Gruppen zuordnen kann...

--Alexander.ahrendt:mni 16:22, 22. Sep. 2010 (CEST)

--Christian.peter:mni 17:15, 25. Sep. 2010 (CEST)

Typbezogen

... zum einen der typbezogenen, welche sich auf die statistische Darstellung der Attackentypen konzentriert:

Anzahl der Angriffsversuche bezogen auf den entsprechenden Attackentyp
Dieser Graph zeigt mit Hilfe eines sogenannten Barchart (dt. Balkendiagramm), wie oft der entsprechende Attackentyp vom PHPIDS erkannt wurde. Hierbei ist es zunächst irrelevant von welchem Benutzer dieser Versuche gestartet wurden. Es zeigt lediglich wie oft ein spezifischer Attackentyp aufgetreten ist.

Anzahl der Angriffsversuche bezogen auf den entsprechenden Attackentyp

Prozentualer Anteil der Angriffsversuche bezogen auf den entsprechenden Attackentyp
Dieser Graph zeigt mit Hilfe eines sogenannten Piechart (dt. Tortendiagramm), mit welchem prozentualen Anteil ein spezifischer Attackentyp aufgetreten ist.

Prozentualer Anteil der Angriffsversuche bezogen auf den entsprechenden Attackentyp

--Alexander.ahrendt:mni 16:22, 22. Sep. 2010 (CEST)

--Christian.peter:mni 17:16, 25. Sep. 2010 (CEST)

Personenbezogen

... und zum anderen der personenbezogenen, welche beispielsweise hervorhebt, aus welchem Umfeld und von welcher IP bzw. welchem Benutzer Angriffsversuche stammen:

Prozentualer Anteil an internen und externen Angriffsversuchen
Mit dieser statistischen Darstellung wird gezeigt mit welchem prozentualem Anteil Angriffe aus dem internen sowie externen Umfeld kommen. Hierbei ist es irrelevant von welchem Attackentyp der Angriffsversuch stammt. Das Diagramm zeigt vielmehr in welchem Verhältnis die Angriffe von innen oder außen kommen.

Prozentualer Anteil an internen und externen Angriffsversuchen

Anzahl der Angriffsversuche bezogen auf den entsprechenden Benutzer
Diese Statistik zeigt, wie oft das PHPIDS einen Angriffsversuch pro Benutzer erkannt hat. Sie zeigt also von welchem Benutzer überhaupt Angriffe ausgegangen sind und wieviele Versuche diesem Benutzer zugeordnet sind. Gleichzeitig sind hier nur Angriffe aus dem internen Umfeld, also von autorisierten Benutzern, zu sehen.

Anzahl der Angriffsversuche bezogen auf den entsprechenden Benutzer

Anzahl der Angriffsversuche bezogen auf die entsprechende IP
Diese Statistik zeigt, wie oft das PHPIDS einen Angriffsversuch pro IP erkannt hat. Sie zeigt also von welcher IP überhaupt Angriffe ausgegangen sind und wieviele Versuche dieser IP zugeordnet sind. Gleichzeitig sind hier nur Angriffe aus dem externen Umfeld, also von nicht autorisierten Benutzern, zu sehen.

Anzahl der Angriffsversuche bezogen auf die entsprechende IP

--Alexander.ahrendt:mni 16:22, 22. Sep. 2010 (CEST)

--Christian.peter:mni 17:14, 25. Sep. 2010 (CEST)

Verwaltung und Steuerung

Für die Verwaltung und Steuerung sind momentan ein Reiter namens Verwaltung und einer namens Attackentypen implementiert. Dieser Managementbereich ist zur Zeit jedoch noch etwas spärlich ausgestattet.

Im Bereich Verwaltung ist es lediglich möglich die vom PHPIDS automatisch verbannten Benutzer einzusehen und diese wiederum, falls nötig, frei zu schalten. Zukünftig soll dieser Bereich erweitert werden, sodass beispielsweise entschieden werden kann, welche und mit welchen Parametern die Statistiken dargestellt werden sollen. Es soll also eine gewisse Dynamik in den Auswertungsbereich gebracht werden, um die Benutzeranforderungen individuell einstellen zu können.

Der Bereich Attackentypen bietet zunächst einen Überblick über die definierten Attackentypen. Der Zweck dieses Bereichs liegt darin, die Abkürzungen der Attackentypen, welche das PHPIDS erkennt, den Langnamen zuzuordnen. Diese erscheinen dann beispielsweise auch in den Legenden der grafisch dargestellten Statistiken.

--Dennis.priefer:mni 22:14, 7. Sep. 2010 (CEST)

--Alexander.ahrendt:mni 16:22, 22. Sep. 2010 (CEST)

Modul mod_giessenAegis

Das Modul mod_giessenAegis dient der kompakten Darstellung der letzten durchgeführten Attacken auf der MNI-Seite. Das Modul besteht aus einem Frontend und Backendbereich. Der Frontendbereich kann an einer beliebigen Modulposition einer Joomla-Seite positioniert werden. Der Backendbereich des Moduls dient der Konfiguration.

--Markus.baier:mni 09:36, 8. Sep. 2010 (CEST)

Frontend

Die Darzustellenden Angriffsinformationen des Moduls werden aus der Tabelle jos_giessen_aegis_attacks der Komponente ausgelesen.

Die Moduldarstellung im Frontend beinhaltet:

  • der Zeitpunkt der Attacke
  • den Angriffsvektor
  • Informationen zu einer Attacke (Attackentyp, Impactwert)
  • Art der Attacke (Intern/Extern)
  • Informationen zu einem Angreifer (IP-Adresse/Benutzername in Joomla)

Desweiteren werden zusätzliche Informationen als Tooltip dargestellt. Ein Tooltip erscheint mittels onmouseover-Event an verschiedenen Positionen des Moduls.

  • Angriffsart(Intern/Extern): IP-Adresse oder Benutzernamen eines Joomla-Users
  • Warning-Icon): Informationen zu einem Angriff
    • Angriffsarten (z.B. xss,rfe, ...)
    • Impact
  • Angriffsvektor: Darstellung des vollständigen Angriffvektors


--Markus.baier:mni 09:36, 8. Sep. 2010 (CEST)

Backend

Der Backendbereich verfügt über folgende Parameter:

Backend
  • Anzahl der Attacken
  • Beschränkung der Attackenausgabe
  • Vektor anzeigen (ja/nein)
  • Datum des Angriffs anzeigen (ja/nein)
  • Angriff mit einem "Neu"-Icon versehen (ja/nein)
  • Ab wann ein Angriff als "Neu" gekennzeichnet wird
  • Icon-Symbol
  • Angriff mit einem Warning-Icon gekennzeichnet wird
  • Ab welchem Impactwert ein Angriff mit einem Warning gekennzeichnet wird
  • Warning-Symbol

--Markus.baier:mni 09:35, 8. Sep. 2010 (CEST)

Modul mod_suhosin

Backend

Diese Modul dient der Konfiguration der PHP-Extension Suhosin. Um dieses Joomla-Modul nutzen zu können, muss daher Suhosin auf dem Web-Server installiert und konfiguriert sein. Bei diesem Joomla-Modul handelt es sich um ein "Administrator-Modul". Solche Typen von Module können nur im Backend von Joomla eingebunden werden kann. Typischerweise setzt man solche Administrator-Module auf die Startseite des Backends.

Folgende Aktionen können innerhalb des Moduls durchgeführt werden:

  • Ein-und Ausschalten des Simulationsmodus von Suhosin
  • Darstellung der Log-Datei
  • Parametrisierung der Suhosin-Config

Um die Parametrisierung der Suhosin-Config zu ermöglichen, liest das Modul beim ersten Start alle für Suhosin verfügbaren Direktiven dynamisch aus und schreibt sie, zusammen mit den aktuell gesetzten Werten, in die Datenbank. Das hat den Vorteil, dass die Direktiven nicht manuell gepflegt werden und immer den Fähigkeiten der eingesetzten Version entsprechen.

Nach dem Bearbeiten der Konfiguration werden alle nicht leeren Direktiven zusammen mit entsprechenden Anweisungen in die Datei .htaccess im Hauptverzeichnis von Joomla! geschrieben. Damit sind sie sofort aktiv. Ein Neustart des Webservers ist nicht nötig.

Anzumerken ist, dass das Konfigurieren von Suhosin mit dem Modul nur bei der Verwendung des Webservers Apache funktioniert.

--Markus.baier:mni 09:50, 22. Sep. 2010 (CEST) --Jochen.uwe.woidich:mni.fh-giessen 20:05, 24. Sep. 2010 (CEST)

Modul mod_phpConfigCheck

Übersicht über sicherheitsrelevante Direktiven

Dieses kleine Backend-Modul vergleicht die aktuell aktive Konfiguration von PHP mit den auf Sicherheit getrimmten Empfehlungen und soll dazu dienen, dem Administrator einen ersten Überblick über mögliche Optimierungen seiner Konfigurationsdatei aufzuzeigen. Die aufgeführte Liste ist dabei allerdings keine vollständige Aufführung aller wichtigen Einstellungen, sondern stellt allenfalls die kritischsten Punkte dar. Durch den einfachen Aufbau das Moduls ist sie jedoch problemlos erweiterbar.

Schwebt der Benutzer mit der Maus über einer der Tabellenzeilen, wird ein Tooltip eingeblendet, der die Funktion der Direktive kurz umschreibt.

Direktiven, die nicht den Empfehlungen entsprechen, werden rot markiert, andernfalls grün.

--Jochen.uwe.woidich:mni.fh-giessen 15:28, 25. Sep. 2010 (CEST)




Aktueller Stand

--Dennis.priefer:mni 13:18, 03. Aug. 2010 (CEST)

Ausblick

Plugin plg_giessenAegis

  • Weitere Maßnahmen
    • Polizeisirene
    • Abschreckende Texte
  • Filterlisten direkt von PHPIDS upgedatet werden können(default_filter.xml), eventuell umsetzbar über RSS-Feeds

--Wolf.normann.gordian.rost:mni.fh-giessen 11:04, 24. Sep. 2010 (CEST)

Komponente com_giessenAegis

  • Die Verwaltungsansicht könnte noch weiter ausgebaut werden, so dass:
    • benutzerdefinierte Statistiken angezeigt werden könnten
  • Die Statistiken-Ansicht könnte weitere Standard-Statistiken sowie benutzerdefinierte Statistiken anzeigen

--Dennis.priefer:mni 22:18, 7. Sep. 2010 (CEST)

Modul mod_giessenAegis

  • Darstellung erweiterter Informationen zu einem Angriff, in einem modalen Popup-Fenster
    • Statistiken anzeigen
    • kompletter Angriffsvektor

--Markus.baier:mni 09:35, 8. Sep. 2010 (CEST)

Projektwoche

In diesem Abschnitt wird die Projektwoche des Moduls WebSecurity des Teams Hardening Joomla dokumentiert.

Hierzu wird jeder Tag in einem einzelnen Abschnitt zusammengefasst und abschließend eine Zusammenfassung der ganzen Woche aufgezeigt. Zunächst wird jedoch ein Überblick über die Aufgabenstellungen gegeben.

--Dennis.sack:mni 11:43, 6. Sep. 2010 (CEST)

Verlauf der Projektwoche

Die Projektwoche findet vom 06.09.2010 bis zum 10.09.2010 statt. Das Team ist in diesem Zeitraum im Raum I307 anzutreffen.

In dieser Woche sind folgende Projektaufgaben anzugehen:

  • Montag und Dienstag: Abschließende Arbeiten an der Sicherheitsarchitektur (IDS/IPS) von Joomla!, Test der Sicherheitsarchitektur mit Apache-JMeter-Skripten, die netzbekannte Exploits gegen Joomla! absetzen, Dokumentation der Ergebnisse im Wiki
  • Mittwoch: Konfiguration der Suhosin-Extension der Laufzeitumgebung von Joomla! anhand umfassender Testskripte
  • Donnerstag: Konfiguration von ModSecurity für Joomla!
  • Freitag: Security-Scanning von Joomla mit Acunetix, Team-Abschlusspräsentation

--Dennis.sack:mni 11:42, 6. Sep. 2010 (CEST)

Montag

Aufgabe:

Abschließende Arbeiten an der Sicherheitsarchitektur (IDS/IPS) von Joomla!, Test der Sicherheitsarchitektur mit Apache-JMeter-Skripten, die netzbekannte Exploits gegen Joomla! absetzen, Dokumentation der Ergebnisse im Wiki

  • Erstes finden des Teams und feststellen, wer noch dabei und anwesend ist
  • Überblick über die schon geleisteten Arbeiten verschaffen
  • Aufteilen der noch verbleibenden Arbeiten
  • Ggf. Lokale Installation von Joomla! zum Entwickeln und Testen.

TODOs:

  • Überblick über die Komponenten schaffen, die auf dem Server installiert werden müssen (Anmerkung: Zugangsdaten für den Produktivserver sind für das Team momentan nicht vorhanden, deshalb Installation der Komponenten vorerst nur auf einem Testserver möglich)
  • Wiki muss erweitert und gepflegt werden
  • Abschließende Arbeit an Plugin, Modul und Komponente:
  • Plugin: --Wolf.normann.gordian.rost:mni.fh-giessen 11:20, 24. Sep. 2010 (CEST)
    • Der vermeintliche Angreifer muss über die Konsequenzen seines Angriffsversuchs informiert werden. ("Angiff wurde geloggt", "Der Administrator wurde per eMail informiert" etc.).
    • Effekte zur Abschreckung müssen eingebaut werden (Brainstorming im Team zu Anzahl und Art der einzubauenden Effekte. Bsp.: animierte Gitterstäbe).
    • Captcha im Backend muss entfernt werden.
  • Modul:
    • Zeilenumbruch zur besseren Übersichtlichkeit beim Anzeigen der Angriffe muss eingefügt werden.--Markus.baier:mni 10:21, 15. Sep. 2010 (CEST)
  • Komponente:
    • Benutzerdefinierte Statistiken müssen einsehbar gemacht werden.
    • Evtl. Auto-Update des PHPIDS (Aufwandsabschätzung nötig)
Effekt zur Abschreckung

Geleistete Arbeit:

  • Suhosin auf dem Testserver installiert--Markus.baier:mni 10:21, 15. Sep. 2010 (CEST)--James.antrim:mni 11:48, 17. Sep. 2010 (CEST)
  • Effekt zur Abschreckung eingebaut (Zwei synchron laufende Musik-Videos, Rick Roll'd) (Plugin)

--Dennis.priefer:mni 20:07, 9. Sep. 2010 (CEST)

  • Neue Parameter im PlugIn: --Wolf.normann.gordian.rost:mni.fh-giessen 11:20, 24. Sep. 2010 (CEST)
    • Anzeige einer Errorseite mit individuellem Text oder
    • Anzeige einer eigenen Seite (in unserem Fall die Musikvideos)
  • Zeilenumbruch bei langen Angriffsvektoren (Modul)--Markus.baier:mni 10:21, 15. Sep. 2010 (CEST)
  • Tooltips angepasst (Modul)--Markus.baier:mni 10:21, 15. Sep. 2010 (CEST)
  • Captcha im Backend entfernt (Plugin) --Jochen.uwe.woidich:mni.fh-giessen 20:09, 24. Sep. 2010 (CEST)
  • Netzbekannte Exploits für Joomla! als Vorbereitung für Dienstag gesucht -> Erfolglos! Keine Exploits für Joomla-Core oder installierte Komponenten gefunden (werden durch große Community schnell gefixt) --Jochen.uwe.woidich:mni.fh-giessen 20:09, 24. Sep. 2010 (CEST)
  • Entscheidung getroffen: Update soll möglich sein

--Dennis.priefer:mni 20:07, 9. Sep. 2010 (CEST)

  • Wiki erweitert und gepflegt--Dennis.sack:mni 11:40, 27. Sep. 2010 (CEST)
  • Vorbereitet auf Review

Noch nicht abgeschlossene Aufgaben:

  • Der vermeintliche Angreifer muss über die Konsequenzen seines Angriffsversuchs informiert werden. ("Angiff wurde geloggt", "Der Administrator wurde per eMail informiert" etc.).
  • Benutzerdefinierte Statistiken müssen einsehbar gemacht werden.

--Dennis.sack:mni 13:06, 6. Sep. 2010 (CEST) --Dennis.priefer:mni 14:45, 6. Sep. 2010 (CEST)

Dienstag

Aufgabe:

Fertigstellen aller verbliebenen Aufgaben von Montag, Feinschliff und Test des Systems.

Test der Sicherheitsarchitektur mit Apache-JMeter-Skripten, die netzbekannte Exploits gegen Joomla! absetzen.

Im Meeting wurden die zu schreibenden Test-Skripte genauer definiert:

Benutzerdefinierte Statistiken
Konfiguration der benutzerdefinierten Statistiken
Möglichkeit zum Löschen der Logs

TODOs:

  • Arbeitsjournal verstehen und führen (Im Kurs WebSec)
  • Überlegungen müssen angestellt werden wie die Eigenentwicklungen der Joomla!-Community zugänglich gemacht werden können. (Pflicht!, da GNU-Licence)
  • Fertigstellen der Aufgabe von Montag: "Der vermeintliche Angreifer muss über die Konsequenzen seines Angriffsversuchs informiert werden. ("Angiff wurde geloggt", "Der Administrator wurde per eMail informiert" etc.)"
  • Fertigstellen der Aufgabe von Montag: Benutzerdefinierte Statistiken müssen einsehbar gemacht werden.
  • Montag Entscheidung getroffen: Update von PHPIDS soll integriert werden -> Updatemöglichkeit implementieren
  • Log-Dateien müssen gelöscht werden können (Da sonst die Festplatte auf Dauer "zugemüllt" wird). Zudem müssen Log-Einträge in der Datenbank gelöscht werden. --Wolf.normann.gordian.rost:mni.fh-giessen 11:18, 24. Sep. 2010 (CEST)
  • Backend Whitelist --Wolf.normann.gordian.rost:mni.fh-giessen 11:18, 24. Sep. 2010 (CEST)
  • Nochmalige Suche von Exploits --Jochen.uwe.woidich:mni.fh-giessen 20:09, 24. Sep. 2010 (CEST)
  • Die Test-Skripte für Apache-JMeter müssen geschrieben werden --Christian.peter:mni 17:18, 25. Sep. 2010 (CEST)
  • Wiki muss weitergeführt werden
  • Joomla! mit IDS/IPS und den Apache-JMeter-Skripten abnehmen lassen

Geleistete Arbeit:

  • Statistiken verfeinert: Es kann eingestellt werden, welche Graphen angezeigt werden und welcher Zeitraum mit diesen Graphen abgebildet wird -> Benutzerdefinierte Statistiken.

--Dennis.priefer:mni 20:07, 9. Sep. 2010 (CEST)

--Alexander.ahrendt:mni 16:34, 22. Sep. 2010 (CEST)

  • Folgende JMeter-Tests erstellt: --Jochen.uwe.woidich:mni.fh-giessen 20:09, 24. Sep. 2010 (CEST)
    • Captcha
    • Cross-Site-Scripting auf Suchfeld
    • SQL-Injection auf Suchfeld
    • Folgender Test konnte (noch) nicht erstellt werden: Einloggen -> Hack -> Automatisch ausgeloggt werden. Dies liegt am Problem, dass der Login in das System mit JMeter nicht möglich ist.
  • Löschen von Logs implementiert (Dies ist im Backend möglich). Größe der Logfiles auf der Festplatte wird angezeigt. --Wolf.normann.gordian.rost:mni.fh-giessen 11:18, 24. Sep. 2010 (CEST)
  • Der Angreifer wird über die Konsequenzen seine Angriffes informiert. --Wolf.normann.gordian.rost:mni.fh-giessen 11:18, 24. Sep. 2010 (CEST)

Noch nicht abgeschlossene Aufgaben:

  • Automatisches Update von PHPIDS
  • Zeit- und Angriffsbezogene Graphen sollen Statistik vervollständigen
  • Ausnahmen für Superadmin
  • Anzeige von Nachrichten für Angreifer überprüfen
  • Fehlende JMeter-Tests schreiben --Christian.peter:mni 17:19, 25. Sep. 2010 (CEST)
  • Möglichkeit Datenbank-Log-Einträge zu löschen

--Dennis.sack:mni 11:12, 7. Sep. 2010 (CEST)

Mittwoch

Aufgabe:

Konfiguration der Suhosin-Extension der Laufzeitumgebung von Joomla! anhand umfassender Testskripte.

Morgendliches Meeting ergab folgende Änderungen der Agenda der Projektwoche:

  • Kein ModSecurity
  • Kein Acunetix
  • Dafür: Suhosin pur

Desweiteren soll folgendes überprüft werden:

  • Session-Sicherheit
    • session_regenerate_id() -> Muss lokalisiert oder eingefügt werden
  • Cookie-Sicherheit
    • Müssen verschlüsselt werden
    • Whitelist muss möglicherweise für JavaScript-Anwendungen erstellt werden
  • Upload-Sicherheit
    • Virenscanner muss Dateien direkt beim Upload prüfen
    • Dieser sollte ausgewählt werden können
  • php.ini muss überprüft werden

Insbesondere sollen hier die OWASP-Risks beachtet werden und das System mit Paros-Scans überprüft werden.

TODOs:

  • Verbleibende Arbeiten von Dienstag beenden.
  • Suhosin Logs auswerten und in die Anzeige der Statistiken integrieren. (Hier werden bis jetzt die Statistiken von PHPIDS angezeigt; Suhosin soll diese ergänzen)
  • Administrationsoberfläche für Suhosin. Genauer:
    • Zur Konfiguration von Suhosin soll die php.ini nicht angefasst werden müssen.
    • Die Einstellungen müssen also über eine Administrationsoberfläche im Backend geändert und angepasst werden können.
    • Insbesondere soll der Simulationsmodus schnell und problemlos aktiviert werden können, falls im Livebetrieb Fehler durch Suhosin entstehen sollten.
    • Zur Konfiguration muss ein neues Backend-Modul entwickelt werden.
  • Update-Check für Suhosin (Ampeldarstellung zur Aktualität) -> Auto-Update? --Wolf.normann.gordian.rost:mni.fh-giessen 11:23, 24. Sep. 2010 (CEST)
Suhosin Statusanzeige
php.ini Statusanzeige
Möglichkeit zum Einstellen von Whitelists

Geleistete Arbeit:

  • Suhosin auf Testserver konfiguriert

--Markus.baier:mni 10:22, 15. Sep. 2010 (CEST)

--Alexander.ahrendt:mni 16:36, 22. Sep. 2010 (CEST)

  • In Suhosin und Konfigurationsparameter eingearbeitet und diese getestet

--Markus.baier:mni 10:22, 15. Sep. 2010 (CEST)

--Alexander.ahrendt:mni 16:36, 22. Sep. 2010 (CEST)

  • Problem gelöst, dass Suhosin Log-Dateien nicht geschrieben wurden.

--Markus.baier:mni 10:22, 15. Sep. 2010 (CEST)

--Alexander.ahrendt:mni 16:36, 22. Sep. 2010 (CEST) --Dennis.sack:mni 11:43, 27. Sep. 2010 (CEST)

  • Überlegung wie Konfiguration von Suhosin über Backend möglich ist. Frage: Muss der Apache nach Neukonfiguration neu gestartet werden. --> Nein, also ist die Konfiguration möglich.

--Jochen.uwe.woidich:mni.fh-giessen 20:09, 24. Sep. 2010 (CEST) --Dennis.priefer:mni 20:07, 9. Sep. 2010 (CEST)

  • Überlegung über Anzeige ob Suhosin auf aktuellem Stand ist. (MD5-Hash auf Website) Auto-Update nicht möglich, da Dateien auf Webserver überschrieben werden müssen. Ampelsemantik: Rot = Suhosin nicht verfügbar, Gelb = nicht aktuell, Grün = aktuell. Ampelgrafiken fertig designed. Der Versionenvergleich erfolgt durch Parsen der Suhosin-Website, sowie der phpinfo. --Wolf.normann.gordian.rost:mni.fh-giessen 11:23, 24. Sep. 2010 (CEST)

--Dennis.priefer:mni 20:07, 9. Sep. 2010 (CEST)

  • Modul zum Check von Sicherheit der php.ini entwickelt. Anzeige: Wenn recommended value von current value abweicht: rot; wenn übereinstimmend: grün. --Jochen.uwe.woidich:mni.fh-giessen 20:09, 24. Sep. 2010 (CEST)
  • An JMeter-Tests weitergearbeitet. Probleme beim Einloggen:
    • Da Joomla! tags verwendet mussten reguläre Ausdrücke zum Parsen geschrieben werden. (erledigt) --Christian.peter:mni 17:20, 25. Sep. 2010 (CEST)
    • Login müsste eigentlich funktionieren (Benutzerzähler auf der Site wird hochgezählt), allerdings wird dies nicht von JMeter erkannt
  • Superadmin ist von Konsequenzen von Hacks ausgeschlossen, bekommt allerdings die Meldungen angezeigt. (Dies ist beabsichtigt, da er dann Tests laufen lassen kann, und überprüfen kann, ob das System korrekt reagiert) --Wolf.normann.gordian.rost:mni.fh-giessen 11:18, 24. Sep. 2010 (CEST)
  • Die Anzahl der Log-Einträge von PHPIDS in der Datenbank werden angezeigt und die Tabelle kann komplett geleert werden. --Wolf.normann.gordian.rost:mni.fh-giessen 11:18, 24. Sep. 2010 (CEST)

Noch nicht abgeschlossene Aufgaben:

  • Update von Suhosin und PHPIDS noch nicht final
  • Einbeziehen von Suhosin-Logs in Graphen
  • Administrationsoberfläche für Suhosin
  • Session-, Cookie- und Uploadsicherheit müssen noch genauer überprüft werden

--Dennis.sack:mni 11:50, 8. Sep. 2010 (CEST)

Donnerstag

Ursprüngliche Aufgabe:

Konfiguration von ModSecurity für Joomla!

Aufgabe:

Fertigstellung aller noch verbleibenden Arbeiten am System.

TODOs:

  • Update von PHPIDS ermöglichen
  • Anzeige implementieren, die Status von Suhoshin anzeigt
  • Session-, Cookie- und Uploadsicherheit überprüfen
  • Administrationsoberfläche für Suhoshin muss entwickelt werden (Dynamische Übernahme der Konfiguration über .htaccess möglich)
  • Suhoshin-Log muss in geeigneter Art ausgegeben werden
  • Weitere JMeter-Skripte müssen geschrieben werden
  • Es muss möglich gemacht werden, PHPIDS in einen Simulationsmodus zu schalten --Wolf.normann.gordian.rost:mni.fh-giessen 11:18, 24. Sep. 2010 (CEST)
  • Quellcode muss der Community einfach zugänglich gemacht werden (Über das FH-SVN schwierig, da nur mit VPN-Verbindung und Login-Daten möglich)
Suhosin Übersicht im Backend (Status, Simulationsmodus, Log, Konfiguration)

Geleistete Arbeit:

  • Verbleibende Arbeit verteilt

--Dennis.priefer:mni 20:07, 9. Sep. 2010 (CEST)

  • Cookie- und Sessionsicherheit überprüft --Jochen.uwe.woidich:mni.fh-giessen 20:09, 24. Sep. 2010 (CEST)
  • PHPIDS kann in Simulationsmodus geschaltet werden
  • Account bei joomlacode.org angelegt--Dennis.sack:mni 11:45, 27. Sep. 2010 (CEST)
  • Projekt bei joomlacode.org erstellt und beschrieben, um Quellcode öffentlich zugänglich machen zu können--Dennis.sack:mni 11:45, 27. Sep. 2010 (CEST)
  • ClamAV auf Testserver installiert

--Markus.baier:mni 10:23, 15. Sep. 2010 (CEST)

--Alexander.ahrendt:mni 16:38, 22. Sep. 2010 (CEST)--Dennis.sack:mni 11:45, 27. Sep. 2010 (CEST)

  • Uploadsicherheit mit ClamAV gewährleistet

--Markus.baier:mni 10:23, 15. Sep. 2010 (CEST)

--Alexander.ahrendt:mni 16:38, 22. Sep. 2010 (CEST)--Dennis.sack:mni 11:47, 27. Sep. 2010 (CEST)

  • Weiter JMeter-Tests erstellt
  • Anzeige implementiert, die Status von Suhosin widergibt (Ob es installiert ist und ob Updates verfügbar sind)

--Dennis.priefer:mni 20:07, 9. Sep. 2010 (CEST)

  • Schalter implementiert, mit dem Suhosin in den Simulationsmodus geschaltet werden kann

--Dennis.priefer:mni 20:07, 9. Sep. 2010 (CEST)

  • Anzeige implementiert, die anzeigt, ob Suhosin im Simulationsmodus ist

--Dennis.priefer:mni 20:07, 9. Sep. 2010 (CEST)

--Dennis.sack:mni 11:37, 9. Sep. 2010 (CEST)

Freitag

Ursprüngliche Aufgabe:

Security-Scanning von Joomla mit Acunetix, Team-Abschlusspräsentation.

Aufgabe:

Feinschliff und Test der entwickelten Erweiterungen und Team-Abschlusspräsentation.

TODOs:

  • Fertigstellen aller noch offenen Aufgaben
    • Administrationsoberfläche von Suhosin fertigstellen
    • Suhoshin-Log ausgeben
  • Überblick über die entwickelten Erweiterungen verschaffen
  • Erweiterungen unter den Teammitgliedern aufteilen
  • Jedes Teammitglied reviewed die Erweiterungen
  • Finale Tests der Sicherheitsmaßnahmen
  • Dokumentieren, dass Joomla! mit den geschriebenen Erweiterungen gemäß den Top-Ten OWASP Risiken sicher ist
  • Erstellen der 30-minütigen Abschlusspräsentation
  • Englische Folien der Abschlusspräsentation im pdf-Format ins Wiki stellen
Suhosin Konfiguration im Backend

Geleistete Arbeit:

  • Administrationsoberfläche von Suhosin fertiggestellt--Dennis.priefer:mni 19:03, 22. Sep. 2010 (CEST)

--Markus.baier:mni 10:23, 15. Sep. 2010 (CEST) --Jochen.uwe.woidich:mni.fh-giessen 20:09, 24. Sep. 2010 (CEST)

  • Update fertiggestellt
  • Suhosin Logs werden ausgegeben

--Markus.baier:mni 10:23, 15. Sep. 2010 (CEST)

  • Erweiterungen gereviewed--Dennis.priefer:mni 19:03, 22. Sep. 2010 (CEST)
  • Finale Tests der Sicherheitsmaßnahmen durchgeführt
  • Dokumentation von OWASP Risks in Bezug auf die Sicherheitsarchitektur geschrieben

--Alexander.ahrendt:mni 16:43, 22. Sep. 2010 (CEST) --Christian.peter:mni 17:21, 25. Sep. 2010 (CEST)

Noch offene Aufgaben:

  • SVN-Respository von joomlacode.org muss angegeben werden
  • Fertigstellen und Feinschliff des Wiki-Artikels--Dennis.sack:mni 11:49, 27. Sep. 2010 (CEST)
  • Erweiterungen in das Livesystem übertragen (www.mni.fh-giessen.de)


Produktivsystem: http://www-test.mni.fh-giessen.de

SVN-Respository: http://tracking.mni.fh-giessen.de/svn/joomla/ , ab demnächst wird zusätzlich das SVN von JoomlaCode (http://joomlacode.org/) benutzt.

--Dennis.priefer:mni 19:57, 9. Sep. 2010 (CEST)

--Dennis.sack:mni 11:41, 9. Sep. 2010 (CEST)

OWASP Risiken

OWASP Top 10 Web Application Security Risks for 2010

  • A1: Injection
  • A2: Cross-Site Scripting (XSS)
  • A3: Broken Authentication and Session Management
  • A4: Insecure Direct Object References
  • A5: Cross-Site Request Forgery (CSRF)
  • A6: Security Misconfiguration
  • A7: Insecure Cryptographic Storage
  • A8: Failure to Restrict URL Access
  • A9: Insufficient Transport Layer Protection
  • A10: Unvalidated Redirects and Forwards

Welche Risiken von welchem System abgedeckt werden, zeigt der Screenshot auf der rechten Seite:

Weitere Informationen: http://www.owasp.org/

--Dennis.sack:mni 10:33, 10. Sep. 2010 (CEST)

Zusammenfassung der Projektwoche

Anmerkung: Auch die noch offenen Aufgaben vom Freitag (SVN bei joomlacode.org und Fertigstellung des Wiki-Artikels) wurden abgeschlossen. Die Erweiterungen müssen allerdings noch auf das Livesystem übertragen werden.

Zusammengefasst kann gesagt werden, dass die angestrebten Aufgaben des Teams alle gelöst wurden. Die noch offenen Punkte, die vor der Projektwoche noch vorhanden waren, konnten alle abgeschlossen werden.

Ein IDS und IPS wurden erfolgreich in Joomla! integriert und sind voll Konfigurierbar. Zudem ist nun eine komfortable Übersicht über die Statistiken der Systeme verfügbar und einsehbar. Suhosin wurde in Joomla! integriert und ist über das Backend auch voll Konfigurierbar. Auch ein Sicherheitscheck der php.ini und der Einbau der ReCaptcha-Methode konnte realisiert werden.

Da es bei Sicherheitserweiterungen besonders wichtig ist, dass diese immer auf dem neuesten Stand sind, wurden für diese eine Up-To-Date-Anzeige implementiert.

Das entwickelte System wurde mit JMeter in Bezug auf die OWASP Risiken getestet und hat die erwünschten Ergebnisse erzielt.

Die Sicherheits-Erweiterungen wurden der Community über joomlacode.org zur Verfügung gestellt. (Siehe Abschnitt Veröffentlichung und SVN)


Die Projektwoche kann also als voller Erfolg gewertet werden, da durch die verfügbare Zeit das Projekt fertig gestellt werden konnte und den Anforderungen entspricht.

--Dennis.sack:mni 10:33, 10. Sep. 2010 (CEST)

Abschlußpräsentation

Abschließende Kundenpräsentation in Englisch.

Datei:Abschlusspräsentation english.pdf

Abschließende Kundenpräsentation in Deutsch.

Datei:Abschlusspräsentation deutsch.pdf

--Dennis.priefer:mni 11:57, 23. Sep. 2010 (CEST)

--Dennis.sack:mni 18:34, 26. Sep. 2010 (CEST)

Suhosin Extension

Die Suhosin erweiterung für PHP soll es ermöglichen Server gegen bekannte und unbekannte Angriffsvektoren abzuhärten. Was nicht explizit erwähnt wird ist dass Suhosin ausschliesslich auf Linux Betriebsysteme kompiliert und im Stande genommen werden kann.--James.antrim:mni 10:38, 7. Sep. 2010 (CEST)

Installation

Die Joomla! Instanzen arbeiten mit Debian Linux unter PHP 5.2.6. Um Suhosin vorgefertigt zu installieren und Neuerungen/Fixes (möglicherweise auch Sicherheitslücken zu schliessen) in Core PHP haben wir entschieden PHP komplett neu auf unseren Servern zu installieren mit der Version 5.3.3. Zusätzlich wurde der Suhoson-Patch installiert, um mögliche Komplikationen der Suhosin PHP-Extension, mit dem Web-Server zu vermeiden. Anschließend wurde Suhosin mithilfe des Deiban-Paketmanagers, als PHP-Extension installiert (php-suhosin Package).

--James.antrim:mni 10:38, 7. Sep. 2010 (CEST) --Markus.baier:mni 16:13, 24. Sep. 2010 (CEST)

Konfiguration

Unsere verwendete Konfiguration richtet sich weitestgehend an den default-Werten der Suhosin-Konfiguration. Besonders haben wir uns mit folgenden Parametern beschäftigt:

  • suhosin.executor.func.blacklist
    • Mit diesem Parameter kann man eine Blacklist für PHP-Core-Funktionen anlegen. Der erste Schritt bestand zunächst darin, möglichst alle sicherheitskritischen Funktionen für die Verwendung im PHP-Code auszuschließen. Der nächste Schritt bestand darin, diese strikte Konfiguration hinsichtlich der Blacklist, auf Kompatibilität mit unserer Joomla!-Instanz zu testen. Der Test im Simulationsmodus ergab, dass diese Konfiguration zu restriktiv war. Die Einträge in der Log-Datei zeigten Konflikte hinsichtlich der Funktionen preg_replace() und popen() an. Daraufhin wurden diese Funktionen wieder aus der Blacklist verbannt. In der Zeit nach der Projektwoche konnten bislang keine weiteren Konflikte entdeckt werden.
  • suhosin.cookie.encrypt
    • Aktiviert die Verschlüsselung von Cookies
  • suhosin.session.encrypt
    • Verschlüsselung von Session-IDs
  • suhosin.log.file und suhosin.log.file.name
    • Aufzeichenen aller verfügbaren Security-Alerts in einem Log-File
  • suhosin.upload.verification_script
    • Ein Shellscript das vor dem Datei-Upload ausgeführt wird, um die hochzuladende Datei mit dem Virenscanner ClamAV zu scannen.
#!/bin/bash
if [ -n "`clamscan --infected --no-summary $1`" ]; then
  echo 0;
else
  echo 1;
fi

Abschließend kann man diese Konfiguration weitestgehend als stabil bezeichnen. Allerdings muss beachtet werden, dass diese Konfiguration auf der Joomla!-Instanz auf unserem Testserver lief. Die abschließende Bewertung der Konfiguration kann erst mit dem Einsatz auf dem Produktivsystem durchgeführt werden. Aufgrund der höherer Benutzerzahl und der Menge an Eigenentwicklungen (Joomla!-Extensions) die getestet werden müssen, ist ein längerer Beobachtungszeitraum der Log-Dateien erforderlich. Danach kann dann die Suhosin-Extension endgültig "scharf" gestellt werden.

--Markus.baier:mni 16:48, 24. Sep. 2010 (CEST)

Veröffentlichung und SVN

Das Projekt ist nun bei JoomlaCode(http://joomlacode.org/gf/project/giessenaegis/) angelegt und damit für die Community erreichbar. Gleichzeitig wird ein von JoomlaCode bereitgestelltes SVN-Plugin genutzt, um die Quelldateien für alle zugänglich zu machen.

JoomlaCode bietet Entwicklern eine sehr gute Arbeitsumgebung und könnte für spätere Projekte schon von Beginn an dienen. Man kann sämtliche Plugins zur Projektorganisation(Tracker, Document manager, File Release System,SVN,CVS,...), sowie zur Kommunikation(Wiki, Forum, News,...) innerhalb der Projektgruppe nutzen.

SVN

Auf das bereitgestellte SVN (http://joomlacode.org/svn/giessenaegis) des Projektes kann man folgendermaßen zugreifen:

Checkout:

svn checkout http://joomlacode.org/svn/giessenaegis

User: anonymous

Es wird kein Passwort benötigt (lesender Zugriff).

Um selbst Code zu bearbeiten muss man einen Account anlegen und dem Projekt beitreten.

--Dennis.priefer:mni 13:41, 27. Sep. 2010 (CEST)

TRAC

Die Timeline im Trac kann unter folgender Adresse aufgerufen werden: http://tracking.mni.fh-giessen.de/joomla/timeline

Dazu muss man nicht registriert sein. Die einzige Voraussetzung ist, dass man sich im FH-Netz befinden muss(ggf. über VPN). --Dennis.priefer:mni 10:12, 4. Okt. 2010 (CEST)