oxSecurity - Hacker Modul

Hallo acpi,

[QUOTE=acpi;118529]Wenn du Opfer eines Angriff warst, ist es bereits zu spät und die häufigsten Gründe Opfer zu werden erfasst das Modul ja eben auch nicht (siehe voriges Post). Ich halte es aber für ein Problem, wenn sich ein Betreiber darauf ausruht das ein “IDS” im Hintergrund läuft. [/QUOTE]

nein ein Opfer wurden wir selbst noch nicht - Angriffe jegliche Art stellen wir aber genügend fest.

Ich gebe Dir Recht, ein Shopbetreiber sollte sich nicht auf einem IDS ausruhen, eine 100%ige Sicherheit gibt es nie. Der Shopbetreiber sollte aber auch nicht einfach darauf verzichten.

Bei PHPIDS gibt es die Filter, diese gilt es speziell für OXID bei Bedarf zu erweitern.

Mögliche Sicherheitslücken könnten man so blocken bis z.B. OXID oder der externe Hersteller eines Moduls mit einem FIX oder Update reagiert - wir wissen ja das dies nicht immer von heute auf morgen möglich ist.

Wie bereits erklärt ist die Lösung nicht gedacht um sich darauf auszuruhen, es ist eine von vielen wichtigen Bausteinen die neben Lösungen wie Suhosin oder ModSecurity ihre Berechtigung haben.

Dir muss ich ja nicht sagen das Lösungen im Hintergrund die Applikation zwar schützen, aber der betroffene Shopbetreiber weiß gar nicht wie hoch die Gefahr für ihn ist.

Wenn bei mir Nachts ständig 10 -30 Einbrecher ums Haus schleichen dann möchte ich das wissen und nicht erst wenn der erste vor meinem Bett :psteht

Für alle Shopbetreiber deren Gefahr größer ist und die sich noch mehr schützen wollen gibt es z.B. IRONBEE Wir richten dann gerne einen Server ein mit gentoo und Deployment per Chef inkl. der nötigen Sicherheitslösungen und betreuen diese dann auch.

Hallo Mitglieder,

wir freuen uns über Eure vielen Anregungen die wir per eMail und Telefon erhalten haben.

Für interessierte Shopbetreiber haben wir ein Update, bitte kontaktiert uns per eMail / Telefon bei weiteren Fragen.

Hallo zusammen,

für alle die es interessiert

http://exchange.oxid-esales.com/de/Controlling/Webshop-Controlling/oxSecurity-1-0-3-Stable-CE-4-6-x-4-7-x.html

Hi Timo,

mich hat es interessiert und ich habe die Version 1.0.3 aus dem eXchange mal getestet.
Mit den CMS-Seiten habe ich nun keine Probleme mehr, die kann ich speichern.

Allerdings erzeugt nun das Umbenennen einer Zahlungsart einen Impact von 78.

Hallo nickname,

danke für die Info, es wäre von Vorteil wenn Du mir das mitteilst was dazu geloggt wird, siehe Logdatei.

Wir müssen solche internen Funktionen einmalig erfassen und ausschließen.

[QUOTE=nickname;120991]
Allerdings erzeugt nun das Umbenennen einer Zahlungsart einen Impact von 78.[/QUOTE]

[QUOTE=itratosTeam;121025]
Wir müssen solche internen Funktionen einmalig erfassen und ausschließen.[/QUOTE]

Was überwacht den das Modul dann noch wenn das ganze OXID Framework bald auf der Whitelist steht?

Und wie geht es mit möglichen Bugs um in den Funktionen die whitelisted wurden?

Oh und wie vermeidet der Benutzer das es Fehlfunktionen in allen möglichen Modulen gibt? Du kannst ja unmöglich jedes Modul erfassen.

Fragen über Fragen.

Hallo acpi,

es tut mir leid das ich erst jetzt reagieren konnte.
Wir haben uns entschlossen den Adminbereich auszuschließen, dies bedeutet das wir Aktionen des Admins im Adminbereich nicht als Angriff werten.

Das Frontend überwacht die Lösung weiterhin komplett inkl. aller Formulare, Loginbereiche - dazu zählt auch der Login zum Admin.
Wenn ein Hacker schon im Adminbereich ist dann muss er nicht mehr angreifen.

Man sieht an der Meldung wie wichtig es ist mögliche Angriffe zu erfassen bzw. überhaupt zu wissen das es jemand versucht:
[B]10.04.2013 - Verstärkte Angriffe gegen WordPress Installationen bei deutschen Hostern[/B]

[QUOTE=acpi;121046]Was überwacht den das Modul dann noch wenn das ganze OXID Framework bald auf der Whitelist steht?

Und wie geht es mit möglichen Bugs um in den Funktionen die whitelisted wurden?

Oh und wie vermeidet der Benutzer das es Fehlfunktionen in allen möglichen Modulen gibt? Du kannst ja unmöglich jedes Modul erfassen.

Fragen über Fragen.[/QUOTE]

Zum Thema WP Artikel:
Bruteforce Attacken auf Passwörter sind doch sowas von uneffektiv, wer alberne Passwörter verwendet die sich per Dictionary knacken lassen, dem ist eh nicht zu helfen. Ein anständiges Passwort von 10 alphanumerischen Zeichen inkl. Gross/Kleinschreibung ist auf dem Weg nicht zu knacken. Warum so was bei Massenhostern passiert ist doch eingetlich logisch, dort erwartet man einfach massenhaft unbedarfte Nutzer mit Passwörtern wie test123 und hat damit Erfolg. Ausserdem ist bei WP der Admin Benutzername immer bekannt (admin).

Viel effektiver bei einem Shop sind doch SQL Injections oder ähnliches bei bekannten Modulen oder selbstgestricktem, wenn der Admin aber komplett ausgenommen wird nutzt das rein gar nichts.

Andere mögliche Konfigurationsschwächen die viel gefährlicher sind hatte ich ja vorher in diesem Thread schon gennant, die werden gar nicht erfasst.

Auch ist mir nach wie vor nicht klar wie das PHP IDS eigentlich bei einem MVC aufgebauten PHP Projekt so richtig funktionieren soll, der bootstrap ist ja nun nicht der einzige Weg zur Initialisierung z.B. bei der Nutzung des Frameworks.

Zusammengefasst überwacht es also weder Admin noch Modulfunktionen und beschränkt sich rein auf das Frontend und Login, andere, wesentlich wichtiger Punkte erfasst es gar nicht. Wenn hier nun auch noch false positive auftreten und mehr Ausnahmen gemacht werden ist bald gar nichts mehr übrig was überwacht wird.

Ich halte das ganze nach wie vor für den absolut falschen Ansatz und eine gefährliche Art falsche Sicherheit zu vermitteln, die unterm Strich effektiv nicht existiert.

Hallo acpi,

der Hinweis zu dem aktuellen Wordpress Angriff war nur ein Hinweis - Thema Sicherheit kann man nicht ignorieren.

Ich teilte mit das wir vorerst den Adminbereich, aber nicht den Admin (Admin Account) ausklammern. Im Adminbereich fängt es schon mit der Eingabe in den Editor an - einiges wertet IDS als verdächtig, was ja auch nicht falsch ist.

Also, wir konzentrieren uns jetzt auf Angriffe auf das Frontend und Module die dort mögliche Opfer eines Angreifers werden können.
Der mögliche Angriff muss ja nicht direkt auf der Startseite durch einen Gast erfolgen, er könnte auch im Checkout durchgeführt werden.

Wenn man eine 100%ige Lösung anstrebt, dann müsste man den Shop vom Netz nehmen - PHP Security hört dort auf wo der Hacker über ein einfaches Passwort direkt in den FTP kommt, oder gleich die Shell eines Server hackt.

Es geht hier lediglich darum den Shopbetreibern einen Einstieg in Web Applikation Security langsam zu ermöglichen - wir wissen aber auch das dies nur einer von vielen Schritten ist.

Wenn ich im Rahmen von Projekten sehe wie einfach die Usernamen/Passwörter zu Shop Admin, FTP oder auch phpmyadmin sind bzw. das Kunden diese allen Entwicklern senden - sogar per PN hier über das Forum - dann ist mir klar das wir noch viel Arbeit vor uns haben.

Wie ich schon mitteilte, Entwickler mit Ideen und der Bereitschaft in der Richtung etwas ändern zu wollen, sind herzlich Willkommen. Es würde uns freuen wenn auch Du mit Idee oder Code mitwirkst.

[QUOTE=acpi;121222]
Auch ist mir nach wie vor nicht klar wie das PHP IDS eigentlich bei einem MVC aufgebauten PHP Projekt so richtig funktionieren soll, der bootstrap ist ja nun nicht der einzige Weg zur Initialisierung z.B. bei der Nutzung des Frameworks.

Zusammengefasst überwacht es also weder Admin noch Modulfunktionen und beschränkt sich rein auf das Frontend und Login, andere, wesentlich wichtiger Punkte erfasst es gar nicht. Wenn hier nun auch noch false positive auftreten und mehr Ausnahmen gemacht werden ist bald gar nichts mehr übrig was überwacht wird.

Ich halte das ganze nach wie vor für den absolut falschen Ansatz und eine gefährliche Art falsche Sicherheit zu vermitteln, die unterm Strich effektiv nicht existiert.[/QUOTE]

Hallo zusammen,

nur mal so als weiteren Hinweis aus der jüngsten Vergangenheit:

Massenweise osCommerce Shops gehackt

Der Hinweis dort bestätigt auch meine Meinung:

Gerade bei Shop-Systemen sollten die Betreiber stets auf entsprechende Sicherheit und Aktualität von Sicherheitspatches achten.

Aber wie acpi bereits ausführt, es gibt noch mehr Stellen über die ein Hacker ins System kommen kann. Man muss aber mal beginnen ein paar Löcher zu stopfen.

11.07.2012 - Sicherheitslücke in Plesk 10

Im Webshop sind fremde Kundendaten für die man verantwortlich ist, ich möchte nicht in der Haut des Shopbetreibers stecken wenn seine Kunden erfahren das deren Daten geklaut wurden - oder über Monate die Kreditkarten Zahlungen abgefangen und Kartendaten nach China weitergeleitet wurden.

Wir haben das Modul nun seit einigen Tagen installiert und verzeichnen rund zwei bis dreimal am Tag einen “Angriff” mit Impact 40. Wie sieht das bei euch aus?

Kommt drauf an, wie die Angriffe aussehen …