Support-Forum Mirko Böer Softwareentwicklungen

Danke für die Rückmeldung.

Die Idee das man Brutfoce Attacken in der Anwendung verhindern oder erschweren will, zeigt ja schon das es Grundsätzlich auch in Zukunft immer Potential gibt die Anwendung für "neue" Arten des Angriffs zu schützen. Ich würde einfach empfehlen die entsprechenden Funktionen in Unterverzeichnisse "einfacher" zu kapseln. So könnte man einfacherer und übersichtlicher die Anwendung je nach Zweck mit htaccess Dateien schützen.

So könnte man die Anwendung die für das Gestalten der Newsletter zuständig ist in einen Ordner legen, die Administration der Listen und alle anderen Administrativen Funktionen in einen Ordner. Alles was so oder so "Public" könnte dann wiederum in einen Ordner.

Das aktuell ist es ein wenig schwierig dinge zu testen, da "fast" alles in einem Ordner (die Hauptebene) liegt. Das ist aber nur eine Anregung von meiner Seite, also nicht falsch verstehen. Ein Upgrade würde bei solch einer Veränderung nicht so einfach sein... aber das sollte kein Grund sein es nicht zu tun.


Gruß

Nein weitere Einschränkungen gibt es derzeit nicht. Irgendwann vielleicht mal die Anzahl Login-Versuche begrenzen, so dass ein Brute-Force-Angriff schwierig wird aber viel mehr kann man nicht machen.

Ein vernünftiges Passwort ist selbstverständlich.

Wenn man Anwendungen auf diese Weise schützt, dann macht man dies um Sicherheitslücken in der Anwendung vorzubeugen. Es ist also eine weitere Ebene des Schutzes. Des Weitern schütze ich lieber alles und mach dann eventuell ausnahmen, als "nur" eine Datei.

Bei den weiterverbreiteten Anwendungen ist ja sogar bei Ordnern die im DocumentRoot liegen aber nie direkt aufgerufen werden müssen schon bei der Installation eine .htaccess Datei Dabei die ein direktes nutzen des Ordnern inklusive des Inhaltes verhindern.

An so etwas habe ich gedacht. Aber versteh mich nicht falsch... im Zweifel werde ich auch "nur" die "login.php" schützen. Also verstehe ich es so, weitere Einschränkungen kann man nicht machen?


Gruß

Ordentliches, schweres = langes Passwort, verwenden, anders kann man den Login-Bereich nicht schützen. Per .htaccess und RewriteCond ist aber sicher auch ein Schutz des Scripts login.php möglich.

Hallo Zusammen,

ich teste gerade den SuperWebMailer. Zwar habe ich noch ein paar Installationsprobleme, dies versuche ich jedoch zuerst noch selbst zu klären.

Andere Konzeptionelle Probleme beschäftigen mich vorher schon.

Administrative Anwendungen möchten wir schützen. So ist der Administrative Bereich von einer Joomla/Wordpress Seite zum Beispiel über den Webserver nur von gewissen Festen-IP Adressen erreichbar. Einen ähnlichen Schutz möchten wir auch sehr gerne für den SuperWebMailer einrichten.

Die Frage der Fragen ist nun, geht dies überhaupt Sinnvoll. Kann man die Teile, die öffentliche nutzbar sein müssen so klar trennen und auch benennen? Denn der Abmelde-Link in den Mailings muss ja nun auf jeden Fall für die Öffentlichkeit erreichbar sein. Die Ziele der Formulare denke ich auch. Aber wohin die Gedanken gehen sollte ja nun klar sein. Hat sich hier jemand vielleicht schon Gedanken gemacht?

Über Ideen, Diskussionen oder sogar Lösungen wäre ich sehr dankbar.
Und ich denke der eine oder andere auch


PS: Es soll später alles auf einem CentOS 7 mit Plesk 12 laufen.
Aber das sollte ja eine Standardumgebung sein.