WordPress has become the world’s most popular CMS. Because it is so popular, this is even more of a reason to enhance WordPress security if you are using it for your website. Most people understand how to make their page itself secure, but if you are not focusing on the the security of your WordPress site by limiting access to important files and folders, then you are still at risk. To do this you will not be making any changes to WordPress itself, but rather altering how WordPress runs on a server and how much access users have to its files. Step 1: Limiting access to wp-includes folder WordPress sites are comprised of a series of files and folders, each with their own unique URLs, which means if someone were to type in the correct URL they could access or alter sensitive files that run your site. One of the most common targets for this kind of hacking is the wp-includes folder, so we are going to add some additional code to the server configuration file to beef up security and
Permalink

Old but not busted … – Dieser Inhalt wurde vor mehr als 8 Jahren publiziert. Die Korrektheit und Verfügbarkeit von Links können leider nicht gewährleistet werden.

Intro

Schon seit ein paar Wochen versuche ich regelmäßig und konsequent mein neu erworbenes Wissen bzgl. GTD umzusetzen. Und da ich so ein kleiner Verspielter bin, habe ich mir auch gleich noch eine Software zugelegt: Tracks. Das Schöne (in ganz kurzer Kürze) an Tracks ist:

  • dass ich es auf dem eigenen Server einsetzen kann,
  • es gibt eine nette & kostenlose Andoid-App namens Shuffle dazu,
  • Tracks hat ne sehr QLe REST-API,
  • OpenID-Login,
  • der Export ist großartig (- detailliert und in den unterschiedlichsten Formaten: RSS, Text, iCal).

Allerdings ist es (noch) nicht ganz so hübsch wie bspw. Smartytask

Tracks lässt sich auf einem Webserver, der Ruby unterstützt, installieren und betreiben. – Damit fällt dann schonmal alles Gedankenmachen um die Sicherheit beim Ablegen privater Daten auf fremden Servern (wie bspw. bei RTM) weg.

Allerdings ist Tracks erst rudimentär fertig und an der ein oder anderen Stelle hakt es noch etwas… – Naja, für den nichtprofessionellen Einsatz – in meinem Fall hauptsächlich zum Festhalten von ToDos und Gedanken – reichts. (Außerdem gibt es eine regelmäßige Entwicklung…)

Nun aber an dieser Stelle mal schnell ein paar Tipps zur Installation von Tracks auf dem Server (mit Apache und FastCGI):

Der Apache-vhost

< VirtualHost 192.168.1.11:443 >
        ServerName abc.defghi.jk
        ServerSignature Off
        SuexecUserGroup webuser webgroup

        SSLEngine on
        SSLCertificateFile /path-to-the-cert/cert.cert
        SSLCertificateKeyFile /path-to-the-certkey/certkey.key
        SSLCipherSuite HIGH
        SSLProtocol all -SSLv2

        DocumentRoot /path-to-the-webroot/tracks/public
        < Directory / >
                Options -Indexes
        < /Directory >

        # Possible values include: debug, info, notice, warn, error, crit, alert, emerg.
        LogLevel warn
        CustomLog /path-to-the-logs/abc.defghi.jk-access.log combined
        ErrorLog  /path-to-the-logs/abc.defghi.jk-error.log
< /VirtualHost >

Die Datei: config/environment.rb

[...]
# (Use only when you can't set environment variables through your web/app server)
ENV['RAILS_ENV'] = 'production'
[...]

Die Datei: public/.htaccess

# If you're on Debian try the following instead of the fastcgi-script line:
AddHandler fcgid-script .fcgi
#AddHandler fastcgi-script .fcgi
AddHandler cgi-script .cgi
Options +FollowSymLinks +ExecCGI

misc

Hier gibts noch nen nettes HowTo zu „Tracks @Ubuntu 10.04″: http://www.getontracks.org/forums/viewthread/622/.
…und außerdem nicht vergessen: sudo service apache2 reload (nach jeder Änderung an den Tracks-Einstellungen)!