Beiträge von mensmaximus

Das liegt zu 99.9% daran, dass die Hoster PHP immer noch als Apache mod-php Modul laufen lassen. Durch eine Umstellung auf php-cgi, fastcgi oder php-fpm wird das Problem eliminiert. Alternativ kannst Du das upload Verzeichnis auf 775 Stellen damit auch die Gruppe (apache user) Schreibrechte erhält. Bei Host Europe kannst Du auch den Besitzer im KAS ändern. Wenn man viel ändern muss ist das lästig, sobald die Seiten aber stehen ist das nicht weiter tragisch.

Ja. Bei Mainwp sind die Erweiterungen günstiger als bei InfiniteWP.

Zitat von Lawless-Diablo

Danke, das habe ich schon - Tipp vom Provider. Auf dem Ordner liegt ein Verzeichnisschutz per .htaccess.

Das hemmt aber die Versuche nicht.

Dann hast Du nur /wp-admin geschützt. Du kannst auch die wp-login.php absichern. In der .htaccess im selben Verzeichnis wie wp-login.php gibst Du folgendes ein:

[COLOR=#000000]<Files wp-login.php>
[/COLOR][COLOR=#000000]AuthType Basic
[/COLOR][COLOR=#000000]AuthName "no access for bad guys"
[/COLOR][COLOR=#000000]AuthUserFile /pfad/zu/deiner/.htpasswd
[/COLOR][COLOR=#000000]Require valid-user 
[/COLOR][COLOR=#000000]</Files>
[/COLOR]

Ich kann seit der Umstellung auf 3.9.2 keine erhöhten Anmeldeversuche feststellen. Einen Zusammenhang mit dem Update kann man aber schon deshalb nicht ausschließen, weil Angreifer möglicherweise versuchen eine Schwachstelle in 3.9.1 (und älter) zu nutzen, da diese jetzt bekannt ist.

Eine beliebte Methode ist das "Abgreifen" des "Author Slug", also die URL zum Autorenprofil, die im Regelfall öffentlich sichtbar ist, weil Blogposts den Verfasser tragen, welcher wiederum einen Link zu seinem Profil trägt. Wenn dieser "Slug" den Benutzernamen darstellt, was dem Standard entspricht, hat der Angreifer bereits eine wichtige Hürde genommen: er kennt den Benutzernamen.

Mit "Limit Login Attempts", entsprechend restriktiven Einstellungen (max. 3 Versuche mit 24 Std. Sperre bei einem weiteren Fehlversuch) und sicheren Passwörtern (min. 12 Zeichen die min. 2 Sonderzeichen, 2 Zahlen, 2 Großbuchstaben und Kleinbuchstaben enthalten) bist Du ganz gut abgesichert.

Falls keine User oder Autoren existieren bzw. die Anzahl überschaubar ist, kann man mit einer .htaccess das Backend sichern (/wp-admin/). Hast Du eine feste IP Adresse stellt die .htaccess (wenn richtig konfiguriert) keinen zusätzlichen Aufwand für Dich dar.

Eine weitere Möglichkeit, die ich immer empfehle, ist das Ändern der "Author Slugs" auf eine Wert, der nicht dem User entspricht. Das passende Plugin gibt es hier. Praktischer Nebeneffekt: man bekommt SEO freundliche Slugs.

Für Besitzer von V-Servern oder dedizierten Servern bietet sich noch der Einsatz von fail2ban an, um die IP Adressen der Angreifer nach x Fehlversuchen in der Firewall (z.B. IP-Tables) zu blocken. Das entlastet WordPress bzw. die PHP Engine.

Die verdienen über den Verkauf der Plugins und des Support. WordPress ist auch kostenlos und Automattic verdient viel Geld.

Du machst aber auch Sachen. In diesem Post steht die komplette .htaccess. Am besten Du erstellt Dir gleich mal eine Kopie, die Du aber nicht auf dem Webspace liegen lässt.

Btw. Maximus Decimus Meridius ist der Gladiator. Ich bin Mensmaximus

Nur mal am Rand bemerkt, weil Du zum zweiten mal erwähnst, dass Du das Upload Verzeichnis temporär auf 777 gesetzt hast. In Deinem anderen Thread stand 775 als Standard. Das Grundübel von 777 scheint Dir also bewusst zu sein. Aber die richtigen Rechte wären 755.

Zu viele Rechte sind nicht nur ein Sicherheitsproblem, sondern können dazu führen, dass gut geschriebene Programme/Plugins die Arbeit verweigern, weil sie prüfen ob die Rechte richtig vergeben wurden. Stell Dein PHP auf FastCGI oder PHP-FPM um und gib den Verzeichnissen 755er Rechte. Wenn dann Uploads nicht gehen hat es garantiert nichts mit den Berechtigungen zu tun.

http://codecanyon.net/item/wordpress…-plugin/3952877

Was stand denn in der .htaccess? Nur weil der Eintrag ein Problem ausgelöst hat, bedeutet das nicht das der Eintrag sinnfrei war. Er ist eben möglicherweise nur falsch oder zu restriktiv.

Woher soll der Button wissen, dass man das Teil kaufen kann? Setzt doch den Button einfach ein, sobald es soweit ist.

Willkommen im Club :-) Das steht bei mir schon lange auf der Agenda und ich habe immer wieder mal angesetzt aber aus Zeitmangel nicht richtig daran gearbeitet.

Es gibt aus meiner Sicht einen guten Ansatz von Jeremy Clark:
http://clark-technet.com/2010/12/wordpr…ugin-update-api

Die aktuelle Version gibt es auf Github:
https://github.com/jeremyclark13/…e-plugin-update

Dem ganzen fehlt nur das "Pushen". Da könnte die ein oder andere Routine von http://mainwp.com/ interessant sein.

Ja. Aber Du hast doch zwei davon. Einmal DE und einmal EN. Also müsste der eine z.B. 'sidebar-custom-header-de' und der andere 'sidebar-custom-header-en' heißen. Wie gesagt ich verstehe das Konzept bzw. den Workflow nicht. Warum hat man unterschiedliche Sidebars für unterschiedliche Sprachen? Wenn Du jetzt 10 Sprachen hättest, dann würdest Du 10 Sidebars bauen? Bei mir wäre es ein und der selbe Sidebar und die darin enthaltenen Widgets würden in der gewählten Sprache erscheinen. Oder sitze ich auf dem Schlauch? In dem Fall bitte ich um Aufklärung wozu die sprachspezifischen Sidebars dienen?

Das hat der "Fluch der Sidebars" wieder zugeschlagen. Es gibt bessere Lösungen ein einzelnes Widget unterzubringen. Dann wirkt die Seite auch gleich nicht mehr zu "leer". Außerdem würde sich hier ein Grid bzy. Masonry Layout anbieten.

Den Vorschlag habe ich ja schon gemacht. Entweder keine zusätzlichen Sidebars oder jedem Sidebar eine eigene ID.

Möglicherweise für Dich interessant: https://wordpress.org/plugins/easy-restaurant-menu-manager/

Zitat von dikig

... der virtuelle Server als Apache Modul läuft und hat mir angeboten, auf einen anderen Server mit FastCGI umzusteigen ...

Evanzo hat richtig geantwortet. Lasse den Umzug durchführen, Du wirst mit keiner anderen Lösung glücklich.

Nein. Ich verstehe den Workflow nicht. Ich übersetze das Plugin (Widget) benötige dafür aber keine eigene Widget Area bzw keinen zusätzlichen Sidebar. So wie Du es machst müsste der neue Sidebar auch eine eigene ID bekommen, sonst kollidiert er mit der Sidebar ID der anderen Sprache.

Damit ich es richtig verstehe, Du entwickelst ein eigenes Plugin und möchtest, dass es automatisch upgedated wird, wenn Du eine Änderung vornimmst. Quasi als Push Technologie, so dass jeder der Dein Plugin verwendet ein automatisches Update erhält. Ist das was Du erreichen möchtest?

Zitat von SirEctor

Wenn Du über Einstellungen->Allgemein die beiden URLs falsch angegeben hast und nicht mehr ins Backend kommst, kann man die URLs in der wp-config.php korrigieren (über FTP). Ich schätze das war gemeint.

Richtig. Oder eben wenn dort tatsächlich alte Einträge existieren.

Das müsste ich mal sehen, aus der Beschreibung werde ich nicht schlau.