Archiv

Artikel Tagged ‘MySQL’

MoWeS Portable II Installationspakete

4. März 2013 9 Kommentare

MoWes Portable II ist für mich schon lange eine unverzichtbare portable Softwareperle auf meinem USB-Stick. Der zuverlässige Webserver to go hat mich noch nie im Stich gelassen, ganz im Gegensatz zu seinem hoch gelobten Verwanten XAMPP, welcher zwar auch als Portable Edition zu haben ist, mir aber in der Vergangenheit mehr Ärger bereitete als Nutzen brachte.

Mit Bedauern musste ich vor einigen Monaten dann feststellen, dass die Firma hinter MoWeS ohne Vorankündigung ihre Geschäftstätigkeit eingestellt hat und im selben Zuge auch die Webseite offline genommen wurde. Somit war kein rankommen an die Installationspakete mehr möglich. Hätte man das vorher bekannt gegeben, ich hätte mir noch schnell eine Sicherung der aktuellsten Pakete gemacht.

Heute hatte ich mal ein wenig Zeit und Lust, mich auf die Suche nach einer dezentralen Sicherungskopie zu begeben und wurde schnell bei Softpedia fündig. Dort gibt es aber „nur“ die Serverkomponenten, die vorgefertigten Softwarepakete haben sie nicht im Angebot, was aber nicht weiter tragisch ist, die kann man schließlich selbst installieren.

Falls jemand nur einzelne Pakete benötigt, habe ich mal alles bei uploaded.to hochgeladen. Enthalten sind die folgenden Pakete:

  • MoWeS Portable II (Version 2.2.3)
  • Apache 2 (Version 2.2.11) + SE
  • MySQL 5 (Version 5.5.8) + SE
  • ImageMagick (Version 4.2.9)
  • PHP 4 (Version 4.4.9) + SE
  • PHP 5 (Version 5.3.5) + SE
  • PHP 5.2 (Version 5.2.17)

mowes_portable.zip ist ein Pflichtdownload und muss nur entpackt werden. Die anderen Pakete werden im Stammverzeichnis von MoWeS gespeichert und anschließend das Programm gestartet. Es beginnt mit der Einrichtung, installiert die einzelnen Pakete und startet anschließend den portablen Server. Fertig 🙂

Ich hoffe, der Download hilft dem einen oder anderen Fan von MoWeS.

 
Update 06.01.2015

Da Uploaded nun wirklich nicht die beste Wahl war, hier noch eine zusätzliche Download-Quelle: Google Drive. Zwar auch nicht optimal, aber zumindest schneller und keine Mengen- bzw Zeitbegrenzung.

Es sind auch ein paar Pakete dazu gekommen, für weitere Infos einfach mal dem Link folgen.

Mehr Sicherheit für WordPress

29. März 2012 Keine Kommentare

Nachdem ich mich in letzter Zeit ein wenig mit SEO beschäftigt habe, und die Seite dahingehend etwas optimiert habe, kam mir nun das Thema Sicherheit in den Sinn. Aber da dies mein erster Blog ist, kann ich diesbezüglich auf keinen allzu großen Wissenschatz zurückgreifen, sondern muss mich an den Hinweisen und Empfehlungen anderer orientieren. Als hilfreich habe ich dabei die foldenden Seiten empfunden:

Ich werde aber selbst auf die aus meiner Sicht wichtigsten Punkte nochmal genauer eingehen. Ich gehe dabei von einer vorhandenen Installation mit der Version 3.3.1 aus.

 
1. Admin-Account sinnvoll benennen

Der bei der Blog-Installation angelegte Admin-Account sollte nicht admin heißen! Ideal wäre ein Name, der nicht im direkten Zusammenhang mit der URL oder dem Thema des Seite steht. Der eigene Nickname sollte ebenfalls nicht genutzt werden. Hat man sich daran schon bei der Installation gehalten, kann man den folgenden Absatz überspringen, andernfalls weiterlesen.

Lege einen neuen Benutzer mit Admin-Rechten an, vergebe einen passenden Namen und nutze ein sicheres Passwort. Anschließend mit dem neuen Account einloggen und den alten Account löschen. Man wird gefragt, was mit den vorhandenen Inhalten des Benutzers passieren soll, hier wählt man die Übernahme auf den neuen Account.

Wähle im Profil auf jeden Fall aus, dass der angezeigte Name nicht der Benutzername ist.

Eine Sache fehlt aber noch: die ID des Accounts in der Datenbank hat nun noch immer die 1 oder, wenn es keine anderen Benutzer gibt, die 2. Das wissen auch potentielle Angreifer. Daher sollte man diese ID auf einen zufälligen Wert ändern. Dazu läd man sich entweder ein Plugin wie Search & Replace, öffnet phpMyAdmin oder greift sonst wie auf die Datenbank zu.

Es muss in 4 Tabellen je ein Wert geändert werden, und zwar in wp_users, wp_usermeta, wp_posts und wp_links. Im folgenden SQL-Statement nehme ich exemplarisch die ID 194, diese Zahl sollte aber jeder selbst festlegen. Die aktuelle ID muss selbstverständlich auch angepasst werden.

UPDATE wp_users    SET ID          = 194 WHERE ID          = 1;
UPDATE wp_usermeta SET user_id     = 194 WHERE user_id     = 1;
UPDATE wp_posts    SET post_author = 194 WHERE post_author = 1;
UPDATE wp_links    SET link_owner  = 194 WHERE link_owner  = 1;

 
2. Tabellen-Präfix != wp_

Was bei der Installation dem Benutzernamen das admin ist dem Tabellen-Präfix das wp_. Auch hier sollte man eine Änderung in Betracht ziehen. Je nachdem, wie viele Tabellen man noch in seiner Datenbank hat, kann es sinnvoll sein, das Präfix mit bestimmten Zeichen beginnen zu lassen, um die Position der WordPress-Tabellen bei der Sortierung zu beeinflussen.

In der Basisinstallation umfasst dies 11 Tabellen, die ich nachfolgend schon mal als fertiges SQL-Statement vorbereitet habe. Das Präfix wird für dieses Beispiel auf 19a7Z4_ gesetzt.

RENAME TABLE wp_commentmeta        TO 19a7Z4_commentmeta;
RENAME TABLE wp_comments           TO 19a7Z4_comments;
RENAME TABLE wp_links              TO 19a7Z4_links;
RENAME TABLE wp_options            TO 19a7Z4_options;
RENAME TABLE wp_postmeta           TO 19a7Z4_postmeta;
RENAME TABLE wp_posts              TO 19a7Z4_posts;
RENAME TABLE wp_terms              TO 19a7Z4_terms;
RENAME TABLE wp_term_relationships TO 19a7Z4_term_relationships;
RENAME TABLE wp_term_taxonomy      TO 19a7Z4_term_taxonomy;
RENAME TABLE wp_usermeta           TO 19a7Z4_usermeta;
RENAME TABLE wp_users              TO 19a7Z4_users;

Wenn man Plugins installiert hat, können es auch durchaus mehr Tabellen sein. Diese müssen dann ebenfalls umbenannt werden.

Damit allein ist es aber noch nicht getan, es sind noch weitere Schritte notwendig, damit WordPress weiterhin fehlerfrei seinen Dienst verrichtet. In der Tabelle 19a7Z4_options und evtl. auch in 19a7Z4_usermeta müssen noch Einträge abgeändert werden.

UPDATE 19a7Z4_options  SET option_name = REPLACE(option_name,'wp_','19a7Z4_');
UPDATE 19a7Z4_usermeta SET meta_key    = REPLACE(meta_key,   'wp_','19a7Z4_');

Zu guter letzt muss die Datei wp-config.php bearbeitet werden, damit WordPress das neue Tabellen-Präfix auch bekannt ist.

$table_prefix  = '19a7Z4_';

 
3. Verzeichnisschutz für wp-content und wp-includes

In diesen Verzeichnissen liegt nichts, worauf ein Besucher direkt zugreifen müsste, außer vielleicht den Uploads. Daher sollte man sie auch entsprechend absichern. In jedes Verzeichnis kommt eine .htaccess mit folgendem Inhalt:

Order Allow,Deny 
Deny from all 
<Files ~ ".(css|jpe?g|png|gif|js|svg)$"> 
  Allow from all 
</Files>

Grundsätzlich wird der Zugriff auf alle Dateien in diesen Verzeichnissen verboten, mit Ausnahme bestimmter Dateiendungen, die man individuell anpassen und ergänzen sollte.

 
4. Verzeichnisschutz für wp-admin oder nur wp-login.php ?

Diese Frage ist auf Playground sehr gut beantwortet und erläutert worden. In vielen Anleitungen wird dazu geraten, den kompletten Ordner wp-admin via .htaccess und .htpasswd zu schützen. Da WordPress aber auch außerhalb des Backends auf die Dateien in dem Verzeichnis zugreifen kann, wäre ein reibungsloser Betrieb für normale Besucher nicht gewährleistet. Daher wird nur die Datei wp-login.php zusätzlich geschützt.

# protect wp-login.php
<files wp-login.php>
  AuthType Basic
  AuthName "Admin-Bereich"
  AuthUserFile /absoluter-serverpfad/.htpasswd
  require valid-user
</files>

Ein doppelter Login also. Muss man aber nur machen, wenn man seinen für WordPress gewählten Benutzernamen und das Passwort für unzureichend hält… aber ob dann ein zusätzlicher Schutz mit ähnlich schwachen Daten die Situation großartig verbessert, darf angezweifelt werden.

Aus meiner Sicht nicht notwendig, für Sicherheitsfanatiker aber garantiert eine tolle Option 😉

 
5. Umgang mit fehlerhaften Login-Versuchen

Man kennt es von vielen Seiten, x-mal das Password falsch eingegeben, schon kann man sich erstmal Kaffee kochen gehen oder gleich den Support anrufen. WordPress bietet diesen Luxus von Haus aus nicht, aber er lässt sich leicht über Plugins nachrüsten. Limit Login Attempts oder Login LockDown sind zwei Vertreter dieser Plugin-Gattung, die Konfiguration sollte selbsterklärend sein.

 
6. Fehlerhinweise auf der Login-Seite ausblenden

Es ist immer wieder schön, wenn man die Zugangsdaten vergessen hat, und einem die Seite genau sagt, wo der Fehler liegt. So macht es auch WordPress und sagt einem genau, ob der Benutzername oder nur das Passwort falsch sind. Für einen selbst eine tolle Hilfe, aber leider auch für jeden anderen, der Zugang haben will.

Daher sollte man auch hier entweder mit Plugins wie WSD security arbeiten oder selbst die entsprechenden Änderungen im Quelltext vornehmen. Bei iNove zeigt das Plugin jedenfalls keine Wirkung, aber das kann durchaus am Theme liegen.

Man öffne also die Datei functions.php im iNove-Verzeichnis und kopiere folgende Zeile an den Anfang der Datei:

add_filter('login_errors',create_function('$a', "return null;"));

 
7. Versionsnummer nicht mehr ausgeben

WordPress gibt seine aktuelle Versionsnummer immer als meta-Tag aus. Eine wertvolle Information, weiß man so doch gleich, ob WordPress aktuell ist und welcher Exploit am ehesten Erfolg haben kann. Also weg mit der Information. Auch zu diesem Zweck gibt es wieder viele Plugins (erneut sei WSD security genannt) oder die Möglichkeit, händisch vorzugehen.

Man muss dafür im Theme-Verzeichnis entweder in der header.php oder der index.php die Zeile, in welcher der meta-Tag erzeugt wird, löschen.

<meta name="generator" content="WordPress <?php bloginfo('version'); ?>" />

Da die Version aber auch im RSS-Feed angegeben wird, und einige Funktionen und Plugins diese Information auch benötigen, kann man die Versionsnummer leider nicht ganz löschen. Das Ausblenden via Plugin scheint daher am flexibelsten.

Zudem sollte man noch den Zugriff auf zwei Dateien unterbinden, in denen die Versionsnummer ebenfalls nachzulesen ist: liesmich.html und readme.html. Einige Seiten empfehlen deren Löschung, was man dann aber nach jedem Update wiederholen darf. Als eine langfristige Lösung scheint mir hier der Einsatz von .htaccess hilfreich zu sein.

# protect liesmich.html
<files liesmich.html>
  Order deny,allow
  deny from all
</files>

# protect readme.html
<files readme.html>
  Order deny,allow
  deny from all
</files>

 
Fazit

Mit ein paar relativ einfachen Aktionen kann man die Sicherheit von WordPress ein gutes Stück erhöhen, auch wenn es zugleich etwa schade ist, dass man als normaler Nutzer überhaupt an sowas denken muss, denn einige Dinge könnten bereits voreingestellt ausgeliefert werden.

Aber so hat man zumindest immer mal wieder etwas neues, um sich zu beschäftigen ^^