mySQL: Laufende Prozesse auflisten

Um bei einem laufenden mySQL Server alle laufenden (aktiven und wartenden) Prozesse und Befehle auflisten zu können, nutzen Sie folgenden Befehl auf der Kommandozeile:

mysqladmin -u[Benutzer] -p[Passwort] processlist
Alle Prozesse ds Servers erhalten Sie als "root". Im folgenden Beispiel ersetzen Sie das Passwort "12345" bitte durch Ihr "root" Passwort:
mysqladmin -uroot -p12345 processlist
Dieser Befehl kann Ihnen dabei helfen, kritische, langsame oder abgestürzte Befehle zu erkennen. Meist ist im ersten Blick nur der komplette mySQL Prozess auffällig langsam oder braucht besonders viel CPU Zeit; durch den o.a. Befehl können Sie hingegen den einzelnen Verursacher innerhalb des mySQL Servers herausfinden. Das kann die Suche nach der Ursache erheblich vereinfachen und beschleunigen.

modx: Backend verstecken (hide the modx-manager)

Um in einer modX Installation das Backend zu verstecken, führen Sie einfach folgende Schritte aus:

  1. Denken Sie sich einen alternativen Namen aus:
    In diesem Beispiel benutze ich «max»
    Bitte ersetzen Sie im folgenden immer «max» durch Ihre gewählte Bezeichnung
  2. Benennen Sie das Verzeichnis «manager» um in «max»
  3. Öffnen Sie die Datei «core/config/config.inc.php»
  4. Gehen Sie zum Bereich der Manager-Pfad-Definition und ersetzen Sie in Zeile 2+3:
    if (!defined('MODX_MANAGER_PATH')) {
      $modx_manager_path= '/your-path-to-public/manager/';
      $modx_manager_url= '/manager/';
      define('MODX_MANAGER_PATH', $modx_manager_path);
      define('MODX_MANAGER_URL', $modx_manager_url);
    }

    zu
    if (!defined('MODX_MANAGER_PATH')) {
      $modx_manager_path= '/your-path-to-public/max/';
      $modx_manager_url= '/max/';
      define('MODX_MANAGER_PATH', $modx_manager_path);
      define('MODX_MANAGER_URL', $modx_manager_url);
    }
  5. Löschen Sie den Cache indem Sie einfach alle Dateien und Verzeichnisse im Order «/core/cache» löschen

Ab jetzt können Sie sich unter «/max» anstelle von «/manager» anmelden.

Die Anzahl der Brute-Force-Loginversuche wird deutlich abnehmen und dadurch ist Ihre modx Installation wieder ein wenig sicherer geworden.

WordPress und die Sicherheit

Wir bieten derzeit ein paar WordPress Plugins an und freuen uns über die positive Resonanz und aktive Nutzung durch unsere Kunden. Aber neuerdings versucht das WordPress Team, neue Plugins nach individuellen Richtlinien zu prüfen. An sich ist eine solche Prüfung eine gute Sache und längst überfällig. Wenn jedoch jeder freiwillige WordPress Helfer (also "Mitarbeiter") seinen eigenen und dann noch flexiblen Wunsch-Maßstab ansetzt - dann wird eine effektive Prüfung Glückssache.

Genau in diesem Dilemma befinden wir uns derzeit mit unsererm neuesten Plugin "Abuse Protector" für WordPress.

Es schützt WordPress Systeme vor den steigenden, nervigen und teils riskanten Bot-Angriffen. Dabei gibt es diverse Angriffsmuster. Bemerkt unser Plugin einen solchen Angriff, meldet es diesen sofort an unsere Datenbank ... nicht mit dem Namen der Webseite sondern zum Schutz mit einem Schlüssel (API Key) kodiert. Dadurch können alle anderen Seiten mit unserem Plugin beim ersten Besuch einer solchen IP diesen Zugriff direkt blockieren - natürlich profitiert jeder davon. Denn ein Angriff in Kapstadt kann nach wenigen Sekunden auch Ihren Blog schützen.

Und WordPress ? Man hat uns untersagt, das Plugin mit dem folgenden Lizenzzusatz zu vertreiben:

"Die kommerzielle Nutzung und Verbreitung ist untersagt"

WordPress: "Das müsse man jedem erlauben."

Das sehen wir anders, denn wir haben das Plugin in unserer Freizeit erarbeitet und wir sehen es partout nicht ein, dass eine Firma damit Geld macht und Sie als unseren Kunden ggf. dafür zahlen sollen. Zudem soll das Plugin den API-Key nicht automatisch bei der Installation erzeugen. Man fordert, dass unserere Kunden sich bei uns extra registrieren und sich einen API-Key manuell abholen oder zuschicken lassen. Dann soll der Key in dem Plugin manuell eingetragen werden. Der Weg sei besser (sagt das WordPress Team).

Das finden wir garnicht, denn (neben dem Zusatzaufwand für unsere Kunden):

  • Was passiert denn bei einem Fehler beim Aptippen des API-Keys ?
  • Oder beim fehlerhaften Kopieren des Keys (z.Bsp. Vergessen des letzten Zeichens) ?

Wir müssten dann sofort jeden Key mit unserem Server verifizieren und unsere Kunden um Korrektur bitten ... viel zu viel Aufwand für ein einfaches Plugin, oder ? Wer soll denn diesen Aufwand (zusätzliche bereiche auf unserer Webseite) programmieren, pflegen und schützen ? Wir ? Klar. Aber das System ist kostenlos und wir haben auch nicht alle zeit der Welt für kostenlose Plugins und Arbeiten.

Fazit: Wir werden das Plugin nur auf unserer Seite anbieten und nicht auf WordPress.

Zudem bauen wir das Plugin um für andere CMS Systeme ... denn dort hat man Interessen an unserem System.

Linux Firewall "iptables": Doppelte Regeln entfernen

Um mit einem kurzen Befehl aus Ihrer Linux Firewall "IPTABLES" doppelte Regeln zu entfernen, nutzen Sie diesen Befehl:
iptables-save | uniq | iptables-restore
Dabei werden die aktuellen Regeln ausgegeben, durch den Befehl "uniq" optimiert und dann wieder als Regeln eingelesen.

Wordpress: Verbergen von Benutzernamen und ID Zuordnung (WordPress User IDs and User Names disclosure)

Wenn man bei einer WordPress Webseite die URL "http://www.example.com/?author=1" angibt, dann erhält man eine Liste der Artikel des entsprechenden Benutzers und seinen Namen. Das klingt auf den ersten Blick nicht sonderlich schlimm - erlaubt jedoch die Zuordnung der Benutzernamen und das Zuordnen dieser Namen zur internen Benutzer ID. Aber: Das zeigt auf, dass ...
  1. die Benutzer-IDs generisch (fortlaufend) erzeugt werden und man dadurch herausfinden kann, wieviele Benutzer auf der WordPress Installation arbeiten
  2. eine Benutzer-ID vergeben / aktiviert ist
  3. durch die Umleitung Schwachstellen entstehen können
Diese Schwachstelle in WordPress kann durch eine Ergänzung in der .htaccess Datei gesperrt werden:
RewriteCond %{QUERY_STRING} author=\d
RewriteRule ^ /? [L,R=301]
Diese Ergänzung leitet entsprechende Anfragen auf die Startseite (bzw. das Rootverzeichnis) des Webservers um. Die Daten können auf diese Weise nicht ausgelesen werden.

Apache: "HTTP Strict Transport Security" auf Debian Server aktivieren

Um eine SSL Verschlüsselung weiter gegen Schachstellen abzudichten, sollten Sie Ihre SL Zertifikate bzw. der Funktionsfähigkeit regelmäßig selbst überprüfen lassen. Denn neben einem gültigen und guten SSL Zertifikat gehört auch eine entsprechend gute Apache WebServer Konfiguration zum Schutzsystem Ihres Servers bzw. Ihres Systems.

Eine SSL Überprüfung können Sie z.Bsp. hier durchführen lassen: https://sslcheck.globalsign.com

Sollte bei der Überprüfung eine Fehlermeldung wie z.Bsp. folgende angezeigt werden, dann kann Ihnen dieser Artikel helfen: "HTTP Strict Transport Security nicht aktiviert." Lösung Öffnen Sie Ihre Apache2 Konfigurationsdatei:

nano /etc/apache2/sites-enabled/domainname.com.conf
Fügen Sie dort im SSL Bereich (unter "VirtualHost 1.2.3.4:443") folgende Zeile ein:
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Speichern und schließen Sie die Datei wieder ("Strg+X" drücken) und aktivieren Sie das HTTP Header Modul im Apache:
a2enmod headers
Starten Sie nun Ihren Apache-WebServer neu:
/etc/init.d/apache2 restart
Prüfen Sie anschließend Ihren Server erneut auf die SSL Sicherheit. Ggf. müssen Sie dafür den Cache bei GlobalSign (sh. auf der o.a. Webseite bei den Ergebnissen) löschen.

Raspberry PI: UMTS Dongle von 1&1 installieren

Vorbereitung Der SIM Karte muss die PIN Sperre genommen werden:
  1. Die SIM Karte in ein normales, ausgeschaltetes Handy (Mobiltelefon) eingelegen
  2. Das Telefon dann einschalten und sich mit dem PIN der SIM Karte anmelden
  3. In den Sicherheitseinstellungen die PIN Sperre deaktivieren
  4. Das Telefon ausschalten und die SIM Karte entnehmen
  5. Die SIM Karte in den UMTS Stick einlegen
  6. Diesen UMTS Stick dann in das Raspberry PI per USB anstecken
Setup / Installation Einstecken und den Befehl "lsusb" eingeben:
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 1c9e:f000 OMEGA TECHNOLOGY
Das Gerät ist in Zeile 4 erkannt. Im Kernel-Log wurde das Gerät "falsch" erkannt:
usb 1-1.2: new high-speed USB device number 4 using dwc_otg
usb 1-1.2: New USB device found, idVendor=1c9e, idProduct=f000
usb 1-1.2: New USB device strings: Mfr=3, Product=2, SerialNumber=4
usb 1-1.2: Product: USB Modem
usb 1-1.2: Manufacturer: USB Modem
usb 1-1.2: SerialNumber: 1234567890ABCDEF
scsi0 : usb-storage 1-1.2:1.0
scsi 0:0:0:0: CD-ROM            USBModem Disk             2.31 PQ: 0 ANSI: 2
sr0: scsi-1 drive
cdrom: Uniform CD-ROM driver Revision: 3.20
sr 0:0:0:0: Attached scsi CD-ROM sr0
Das liegt daran, dass diese Geräte (USB Dongles) häufig für Windows Installationen bei dem ersten Erkennen durch einen PC einen USB Speicherstick simulieren und dadurch dem PC die Treiber-Software anbieten können. Nach dem Installieren der Treiber wird das Gerät dann richtig als "UMTS Modem" erkannt. Bei Linux wird diese Umweg nicht benötigt und führt daher zu diesem Erkennungsproblem des USB UMTS Sticks. Nähere Erklärungen finden Sie beim Paket: https://packages.debian.org/de/sid/usb-modeswitch Aus dem oberen Grund wird das Paket "usb-modeswitch" benötigt:
apt-get install usb_modeswitch
Nun das Raspberry Pi einfach rebooten:
reboot
Nach dem Neustart ist im Kernel Log das richtige Gerät erkannt:
dmesg
... zeigt das aktuelle Boot-Log an:
usb 1-1.2: generic converter now attached to ttyUSB0
usbserial: USB Serial Driver core
usbcore: registered new interface driver option
USB Serial support registered for GSM modem (1-port)
Den UMTS Dongle aus dem USB Anschluss ziehen, ein paar Sekunden warten und wieder in den USB Anschluss einstecken. Linux erkennt den UMTS Stick jetzt. Das kann mit dem Befehl "lsusb" überprüft werden:
Bus 001 Device 008: ID 1c9e:9605 OMEGA TECHNOLOGY
Wichtig ist die kleine (aber entscheidende Änderung) in der ID: "1c9e:f000" in "1c9e:9605" Die Datei "/etc/wvdial.conf" bearbeiten:
nano /etc/wvdial.conf
[Dialer Defaults]
Phone =
Username =
Password =
New PPPD = yes

[Dialer umts]
Modem = /dev/ttyUSB1
ISDN = off
Modem Type = USB Modem
Baud = 115200
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1,"IP","web.vodafone.de"
Phone = *99#
Dial Prefix =
Dial Attempts = 5
Dial Command = ATM1L3DT
Ask Password = off
Password = vodafone
Username = vodafone
Auto Reconnect = on
Abort on Busy = off
Carrier Check = on
Check Def Route = on
Abort on No Dialtone = on
Stupid Mode = off
Idle Seconds = 0
Auto DNS = on
Die Datei speichern und den Editor beenden (per "Strg+X").

VirtualMin & WebMin: Sicherheit von SSL im Apache erhöhen

Es ist als Inhaber von SSL Zertifikaten auch wichtig, diese regelmäßig selbst zu prüfen. Eine Möglichkeit ist der SSL Checker von GlobalSign: https://sslcheck.globalsign.com Dort geben Sie in das Feld den zu prüfenden Domainnamen ein, klicken auf "Abfrage" und warten. Sollte dabei z.Bsp. die folgende Fehlermeldung erscheinen, dann hilft Ihnen dieser Artikel weiter. "SSL Sitzungen könnten durch BEAST Attacken angreifbar werden." Lösung Öffnen Sie die entsprechende .conf-Datei:
nano /etc/apache2/sites-available/domainname.com.conf
und fügen Sie dort folgende Zeilen ein:
SSLHonorCipherOrder     On
SSLCipherSuite          ECDHE-RSA-AES256-SHA384:AES256-SHA256:AES256-SHA256:RC4:HIGH:!MD5:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!DH:!ADH:!EDH:!AESGCM
Beispiel einer ergänzten .conf-Datei (= "Apache Configfile"):
SSLEngine on
SSLCertificateFile /home/domainname/www.domainname.com.crt
SSLCertificateKeyFile /home/domainname/www.domainname.com.key
SSLCACertificateFile /home/domainname/www.domainname.com.ca
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:AES256-SHA256:RC4:HIGH:!MD5:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!DH:!ADH:!EDH:!AESGCM
Danach muss der Apache-Webserver neu gestartet werden:
/etc/init.d/apache restart
Jetzt (anschließend) bitte das SSL Zertifikat bzw. die Funktionssicherheit nochmals prüfen: https://sslcheck.globalsign.com

WordPress: Automatische Zeilenumbrüche verhindern (<p> und <br>)

WordPress ergänzt nur allzu gerne den HTML Code einer Seite oder eines Artikels mit Zeilenumbrüchen und Absätzen. Im Großteil der Fälle mag diese Technik entweder unbemerkt oder gar hilfreich sein - es gibt aber auch Seiten, auf denen dieses Verhalten stört. Um dieses Verhalten in WordPress zu deaktivieren, fügen Sie die folgenden beiden Zeilen einfach in die "functions.php" in Ihrem Layout ("theme") ein:
remove_filter("the_content", "wpautop");
remove_filter("the_excerpt", "wpautop");

lowriter: "Error: Please reverify input parameters..."

Beim Ausführen des Programmes "lowriter", auch im "-- headless" Modus, erhalten Sie die folgende Fehlermeldung:
Error: Please reverify input parameters...
Die Ursache liegt häufig in Pfadangaben für die Dateien. "lowriter" kann mit Pfaden (absoluten Pfaden) derzeit nicht umgehen. Lösung: Schreiben Sie Ihre lowriter-Befehle um. Aus
lowriter --headless --convert-to pdf --outdir /path/to/file/test.doc /path/to/file/test.odt
machen Sie
cd /path/to/file/; lowriter --headless --convert-to pdf --outdir test.doc test.odt
un schon kann "lowriter" Ihre Datei erstellen.