Prinzipiell erlaubt Postfix mit permit_sasl_authenticated jedem SASL-authentifizierten Benutzer beliebige FROM E-Mail-Adressen zu verwenden. Mit der Option reject_sender_login_mismatch wird dieses Verhalten verboten und überprüft ob der SASL-Username bzw. die damit verknüpften Mail-Adressen und -Aliase mit dem FROM der E-Mail übereinstimmt.

Wenn man die Option reject_sender_login_mismatch nun nur auf bestimmte SASL-Usernamen beschränken will, wird es kompliziert. Das lässt sich nämlich nicht so einfach in der Postfix-Konfiguration (main.cf) einstellen, da sämtliche Lookup-Tables nicht den SASL-Username als Index benutzen.

Was wir wollen

Der User foo@example.org soll ausschließlich E-Mails mit foo@example.org als Absender senden können.
Der User bar@example.org soll hingegen beliebige Absenderadressen wählen können.

Das geht nur über einen Policy Daemon: Hört sich kompliziert an, ist aber im einfachsten Fall ein simples Script, dem von Postfix unter anderem der SASL-Username übergeben wird.

smtpd Policy Daemon mit PHP

Das funktioniert mit anderen Scriptsprachen wie Python oder Perl natürlich ähnlich, und wahrscheinlich sogar besser, wir machen das aber mal, weil wir es können, mit PHP!

Unser PHP Policy Daemon soll unter /usr/local/bin/policyd liegen (chmod +x nicht vergessen, chroot beachten). Die Parameter von Postfix kommen über STDIN. Das Ergebnis geben wir ganz normal über echo an Postfix zurück. Als Ergebnis kommt ACCEPT oder REJECT in Frage, oder aber jede bekannte Postfix UCE restriction, also auch reject_sender_login_mismatch! (Siehe dazu auch access(5))

/usr/local/bin/policyd

#!/usr/bin/php
<?php
    $allow_relay = array(
        'bar@example.org',
    );
       
    $fp = fopen('php://stdin', 'r');
    while (true) {
        $line = fgets($fp, 512);
        if (strpos($line, '=')) {
            list($k, $v) = explode('=', trim($line));
            $env[$k] = $v;
        }

        if($line == "\n") break;
    }
    fclose($fp);
 
    if ($env['sasl_username']) {
        if (!in_array($env['sasl_username'], $allow_relay)) {
            echo "action=reject_sender_login_mismatch\n\n";
            die();
        }
    }
    echo "action=DUNNO\n\n";

Simple String-Funktionen: Ist der sasl_username nicht in unserem Array mit erlaubten Relay-Logins, wird die reject_sender_login_mismatch UCE restriction zurück gegeben. Das FROM muss nun also mit sasl_username übereinstimmen. Im anderen Fall wird ein “DUNNO” zurückgegeben, was Postfix dazu veranlasst mit der nächsten Regel weiter zu machen. reject_sender_login_mismatch gilt dann für diesen sasl_username also nicht.

Wichtig ist hier, den STDIN mit fgets zeilenweise zu lesen und aufzuhören sobald eine leere Zeile empfangen wird. Versucht man den gesamten STDIN über file_get_contents zu holen, beträgt der Timeout 60 Sekunden bis das Script fortgeführt wird und Postfix das Ergebnis übergeben werden kann.

Neben dem sasl_username kommen über STDIN noch weitere Parameter, wie z.B. die Absender-Adresse, Empfänger-Adresse oder die Client-IP. Eine vollständige Übersicht gibt es hier: http://www.postfix.org/SMTPD_POLICY_README.html#protocol

Postfix Konfiguration

master.cf

policy  unix    -       n       n       -       0       spawn
    user=nobody argv=/usr/local/bin/policyd

main.cf

smtpd_sender_restrictions = permit_mynetworks,
    check_policy_service unix:private/policy,
    permit_sasl_authenticated,
    [..]

~$ /etc/init.d/postfix restart

Das wars!

Eigentlich ganz einfach

Alles was wir brauchen ist:

• eine IPv6-Adresse
• einen Nameserver, der per IPv6 erreichbar ist
• DNS AAAA-Records
• Apache für den Dualstack-Betrieb konfigurieren

Eine IPv6-Adresse

Der vServer ALUMINIUM von Netcup, auf dem neunzehn83.de läuft, ist IPv6 fähig. Per OpenVCP-Panel kann man bis zu 15 einzelne IPv6-Adressen aktivieren. Nach einem Reboot stehen diese zur Verfügung.

~$ sudo ifconfig
eth0      Link encap:Ethernet  HWaddr 00:24:21:b4:xy:ab
      inet addr:188.40.201.74  Bcast:188.40.201.127  Mask:255.255.255.192
      inet6 addr: 2a01:4f8:100:5462:0:bc28:c94a:1/64 Scope:Global
      inet6 addr: 2a01:4f8:100:5462:0:bc28:c94a:2/64 Scope:Global

Nameserver

Für IPv4 schreibt die DeNIC mindestens zwei Nameserver in unterschiedlichen /24 Netzen vor. Bei IPv6 genügt im Moment noch ein einziger. Wie bereits erwähnt, verwende ich die Nameserver von Regworld, meinem Domain-Registrar. Zusätzlich läuft auf dem vServer noch ein Bind Nameserver als zweiter Secondary. Dieser lauscht auch gleichzeitig an der IPv6-Adresse und wird somit als einziger Nameserver für IPv6-Anfragen genutzt.

Die Nameserver von Regworld kommen dafür leider nicht in Frage, da diese (noch) nicht per IPv6 erreichbar sind. Das lässt sich aber relativ leicht lösen, indem man einen Bind-Nameserver an eine oder mehrere IPv6 adressen binded und als reinen Forwarder für die Regworld-Nameserver via IPv4 konfiguriert.

In meinem Fall gebe ich mich aber mal mangels RAM mit nur einem Nameserver für IPv6 zufrieden.

Zu guter Letzt muss noch ein IPv6 GLUE-Record für den Nameserver angelegt werden. Das geht im Domainrobot von Regworld (AutoDNS) genau so wie bei IPv4: Man schreibt den IPv6-Glue einfach per Leerzeichen vom v4-Glue getrennt dahinter:

ns.example.org 1.1.1.1 ::1

Beim DeNIC-Whois sieht das dann so aus:

DNS AAAA-Records

Was der A-Record bei v4 ist der AAAA (Quad-A) Record bei v6. Diesen legen wir jetzt also für die Domain (neunzehn83.de) und die www-Subdomain an. Zusätzlich habe ich eine neue Subdomain ipv6.neunzehn83.de erstellt, die nur ein AAAA aber kein A Record hat, somit also exklusiv über IPv6 erreichbar ist.

@    IN A    188.40.201.74    
@    IN AAAA 2a01:4f8:100:5462::bc28:c94a:1
www  IN A    188.40.201.74
www  IN AAAA 2a01:4f8:100:5462::bc28:c94a:1
ipv6 IN AAAA 2a01:4f8:100:5462::bc28:c94a:1

IPv6 hat übrigens Priorität vor IPv4, weshalb alle Besucher die sowohl mit IPv4 als auch mit IPv6 unterwegs sind, diese Webseite bereits über IPv6 betrachten.

Apache Dualstack

Dual-Stack nennt man das Verfahren, bei dem der Apache sowohl per IPv4 also auch per IPv6 erreichbar ist. Alles was dafür nötig ist, ist den Apachen auch auf der IPv6-Adresse lauschen zu lassen und die Virtualhost-Konfiguration um die IPv6-Adresse zu erweitern.

Listen 188.40.201.74:80
Listen [2a01:4f8:100:5462::bc28:c94a:1]:80

<Virtualhost 188.40.201.74:80 [2a01:4f8:100:5462::bc28:c94a:1]:80>
[...]
</Virtualhost>

Nach einem Apache-Restart ist alles klar.

IPv6 und Froxlor

Dummerweise schreibe ich für diesen Server die Apache-Configs nicht selbst, sondern lass das Froxlor machen. Froxlor ist der Nachfolger von SysCP, unterstützt aber ebenso noch kein Dualstack, weshalb ich selbst an der Source Hand angelegt habe. Alle Änderungen finden sich in diesem Patch, welchen ich auch in einem Thread bei Froxlor zur Diskussion veröffentlicht habe. In der Datenbank muss die Varchar-Länge des ip-Feldes der panel_ipsandports-Tabelle auf 55 vergrößert werden.

ALTER TABLE `panel_ipsandports` CHANGE `ip` `ip` VARCHAR( 55 ) NOT NULL DEFAULT ''

Nun können unter IPs und Ports Dualstack-IPs angeben werden, indem die IPv4 einfach durch ein Leerzeichen von der IPv6-Adresse getrennt wird:

Achtung: der Patch berücksichtigt nur die Apache und Bind Konfiguration. NGIX und Lighttpd sind unverändert und somit wahrscheinlich nicht funktionsfähig.

IPv6 und PHP

Wenn die eigene Webseite auch per IPv6 erreichbar ist, kann das auch Auswirkungen auf PHP-Scripte haben. $_SERVER['REMOTE_ADDR'] beinhaltet dann nämlich die IPv6-Adresse als String und die ist in den meisten Fällen deutlich länger als eine IPv4-Adresse. Das kann ein Problem werden, wenn die IP-Adresse in einer Datenbank als ein VARCHAR(15) gespeichert wird. Hier benötigt man nun ein VARCHAR(40). Auch ip2long() funktioniert nicht mit IPv6-Adressen.

Schon vor einiger Zeit habe ich festgestellt, dass bei Verwendung vieler Alias-Domains die erzeugte Apache-Konfiguration fehlerhaft sein kann. Dann nämlich, wenn die ServerAlias-Direktive mehr als 8000 Zeichen hat. Scheinbar hat noch keiner zuvor so viele Alias-Domains einer Hauptdomain hinzugefügt. 8000 Zeichen hört sich auch viel an, doch wenn pro Domain jeweils noch die www-Subdomain hinzukommt, reichen bereits ca. 150 Domains um dieses Limit zu erreichen.

Der Apache vHost-Container unterstützt mehrere ServerAlias-Direktiven, so dass bevor die 8000 Zeichen erreicht werden einfach ein neuer ServerAlias-Eintrag erzeugt werden sollte. Die Datei cron_tasks.inc.http.10.apache.php in scripts/jobs ist für das Erstellen der Apache-Konfigurationsdateien verantwortlich und mit wenigen Zeilen auf dieses Verhalten anpassbar (Patch).

Da ich nicht nach jedem Update daran denken möchte, diese Änderung einzuspielen, habe ich bei Froxlor mal ein Ticket erstellt und diesen Patch angehängt. Vielleicht schafft er es ja in die 0.9.27 :)

Der Unix-Timestamp ist in PHP sehr populär. Funktionen wie date() oder strtotime() arbeiten mit UNIX Timestamps. Das ist auf den ersten Blick auch unheimlich praktisch, weil sich damit relativ platzsparend Daten (Plural von Datum) speichern lassen. Außerdem lässt es sich mit einem Timestamp leicht rechnen.

Ein PHP signed Integer auf 32bit-Systemen kann Werte zwischen -2147483648 und 2147483647 annehmen. Am 19. Januar 2038 3:14:08 läuft der Int also über und es ist plötzlich der 13. Dezember 1901 20:45:52 Uhr (Freitag der 13.!).

Folgendes Beispiel zeigt das Verhalten auf 32bit-Systemen. Mit einem 64bit-System und 64bit PHP kann PHPs unsinged Int Werte bis 9223372036854775807 annehmen. Dort stellt sich die Y2K38-Frage also garnicht. Hier stellt sich dann die Jahr 292471210689-Frage – aber bis dahin sind 64bit Systeme genau so ausgestorben, wie es 2038 die 32bit-Systeme sein werden.

var_export(strtotime("20 jan 2038")); // false :(

Der aktuelle Fortschritt lässt sich auch ganz einfach mit echo ausgeben – kein (ob_)flush notwendig.

Wenn man mit echo einen Carriage Return ("\r") ausgibt, wird der Cursor auf den Anfang der Zeile zurückgestellt und man kann eine bereits ausgegebene Zeile überschreiben. Perfekt also für einen Fortschrittsbalken!

$total = 10;
$bar_length = 20;
$spinner = '-\\|/';
for ($i = 1; $i <= $total; $i++) {
    usleep(1000000);

    $spin = $spinner[$i%strlen($spinner)];    
    $cur = sprintf('%'.strlen($total).'.d', $i);
    $percent = $i/$total*100;

    $progress_len = floor($bar_length * $percent / 100);
    $progress = str_repeat('=', $progress_len);
    if ($progress_len < $bar_length) {
        $progress .= '>';
        $progress .= str_repeat('-', $bar_length-$progress_len-1);
    }

    echo " $cur/$total $spin [$progress] $percent%\r";
}

Wie auch schon letztes Jahr habe ich den Geburtstag (oder sagt man Jahrestag) meines Blogs knapp verpennt. Macht aber nichts, zu bloggen hab ich nämlich auch vergessen. 2011 waren die Anspüche groß, die Resultate blieben aber wie so oft weit hinter den Erwartungen zurück. So habe ich es in einem Jahr auf gerade einmal 16 Beiträge gebracht. Pfui!

2012 wird aber alles besser. Gebloggt wird ab sofort übrigens mit WordPress 3 und markdown (yay). Ideen für neue Beiträge habe ich einige, mitunter sind das echte Kracher, also dranbleiben, denn die kalte Jahreszeit kommt bestimmt.

Möchte man ein SVG in PNG (oder sonstige Pixelgrafikformate) umwandeln, versucht man das wohl zunächst mit ImageMagick. Das funktioniert solange auch prima, bis im SVG ein <textpath> vorkommt. Dieser verschwindet nämlich bei der Umwandlung in ein PNG mit imagick. Selbes Problem tritt mit meiner zweiten Wahl, dem Tool rsvg (librsvg2-bin), auf.

Mit inkscape funktioniert die Umwandlung wie gewünscht. Es ist mit Sicherheit weniger verbreitet wie convert (imagick), aber immerhin ist es als Debian-Paket (“inkscape”) verfügbar. Die Windowsversion ist im Übrigen ebenfalls einen Blick wert: ein wirklich brauchbares, quelloffenes Vektorgrafikprogramm!

Path traversal bzw. directory traversal ist eine Methode, um aus vorgesehenen Verzeichnissen auszubrechen. In Bezug auf PHP findet diese Sicherheitslücke  Anwendung, da Dateien oftmals anhand des Querystrings eingebunden werden. Beispiel:

http://example.org/index.php?site=impressum.php

<?php
    include './includes/sites/' . $_GET['site'];
?>

Oftmals wird das Ausbrechen aus einem Verzeichnis dadurch versucht zu verhindern, indem ‘../’ aus $_GET['site'] entfernt wird.

$save = str_replace('../', '', $_GET['site']);

Sehr verbreitet ist auch die Dateiendung vorzugeben:

include './includes/sites/' . $_GET['site'] . '.php';

http://example.org/index.php?site=../../../../../../../etc/passwd%00

Mit aktiviertem allow_url_fopen gibt es noch weitere Zeichen zu prüfen – das ist dann aber kein path traversal mehr und somit nicht bestandteil dieses Blog-Beitrages.

Was tun?

Statt str_replace sollte man besser preg_replace mit einem Pattern wie #\.+[/\]+# verwenden. Noch besser ist es natürlich von vorne herein eine Whitelist zu führen – also ein Array mit erlaubten Dateinamen und dann prüfen, ob $_GET['site'] in diesem Array vorkommt. Eine weitere Methode ist, den kanonischen, absoluten Pfad mittels realpath() zu erzeugen und dann den Beginn dieses Pfades mit dem Document-Root (bzw. dem erlaubten Verzeichnis) abzugleichen.

list($a, $b) = array($b, $a);

Beispiele

1. Online-Shop: $kunde erhält seine Bestellbestätigung per E-Mai mit der Bestellnummer 27.

Das wäre mir (als Shop-Betreiber) ein Dorn im Auge, da es Rückschlüsse auf die Anzahl der bisherigen Bestellungen zulässt. Das lässt sich noch relativ leicht beheben, indem man die auto_increment-Spalte nicht bei 1 sondern bei einer höheren Zahl beginnen lässt (ALTER TABLE tbl AUTO_INCREMENT = 1000;). Doch was, wenn der Kunde zwei Wochen später erneut bestellt, und eine nur wenig höhere Bestellnummer erhält? Dies lässt wiederum Rückschlüsse auf die Häufigkeit von Bestellungen im Shop zu. Daran ändert auch der Beginn bei höheren Zahlen nichts.

2. URL: http://domain.com/user/123

Wir nehmen an, hinter dieser URL verbirgt sich ein öffentliches Benutzerprofil. Auch hier selbes Problem wie oben (Aussage über Quantität). Zudem kann man hier, aufgrund der fortlaufenden Nummer, die “Umgebung erkunden”, andere Benutzerprofile erraten oder per Script sämtliche Userprofile crawlen (for i=1; i<999;i++). Hier bräuchte man also im Idealfall eine zufällig fortlaufende Zahlen/Nummernkombination, mit genügend “Lücken” um das direkte erraten anderer Profile zu verhindern erschweren. Dennoch sollte die User-ID natürlich so kurz wie möglich sein.

Das dürfte ja alles soweit bekannt sein. In den meisten Szenarien spielt das auch überhaupt keine Rolle. In einem Blog oder Forum z.B. dürfen die Post-IDs gerne den Primary-Keys entsprechen. Was aber, wenn der paranoide Webmaster Rückschlüsse nicht (oder sagen wir besser: nur erschwert) zulassen will?

Anforderungen an eine ID-Verschleierung

• wenig Overhead (nicht länger als nötig)
• leicht reversibel (ohne Datenbankabfrage, ohne Speicherung der verschleierten ID in extra DB-Spalte)
• Erhöhung des PK um 1 soll große Änderung der verschleierten ID bewirken
• kollisionsfrei, zu 100%
• optional: Spielraum/Lücken um das Erraten von weiteren IDs zu erschweren

Mögliche Lösungen zum Verbergen der ID

GUID

GUIDs haben mit Sicherheit Ihre Daseinsberechtigung. In den meisten Fällen sind sie aber einfach nur des Guten zu viel. Von der Performance auf Datenbankseite möchte ich jetzt gar nicht reden. Auch nicht über die Tatsache, dass GUID in URLs schrecklich aussehen. Das Ziel muss sein, so wenig wie möglich Overhead zu erzeugen. GUID: no-go!

Hashen des PKs

Ein Hash resultiert immer in einem String mit fester Länge. Selbst bei sehr kleinen Primary-Keys, wäre der Hash immer gleich lang. Welch’ Verschwendung! Außerdem sind Hashs nicht kollisionsfrei*, und sie lassen sich auch nicht zurückrechnen. D.h. man müsste den Hash zusätzlich zum Primary-Key speichern (noch mehr Overhead).

[* zugegeben, in diesem Ganzzahlbereich um den es hier geht wohl schon]

Basis

Man kann den Primary-Key einfach in einer anderen Basis darstellen, Base32 od. 64 zum Beispiel. Wenn man darauf besteht, dass die ID nach wie vor aus Zahlen bestehen soll, hat man Pech. Auch doof ist, dass eine Erhöhung des PK um 1 nur eine sehr kleine Änderung der verschleierten ID bewirkt. Beispiel: 12345(base10) = C1P (base32), 12346(base10) = C1Q(base32)).

Random-ID

Die Idee dahinter ist, im Vorfeld einen Pool an Random-IDs zu erzeugen (in einer extra DB-Tabelle). Ein UNIQUE-Key verhindert Duplikate. Beim Anlegen eines neuen Datensatzes, wird aus der Kandidaten-Tabelle dann eine Zufallszahl geholt und mit dem PK verknüpft. Das Ganze geht auch ohne vorheriges Erstellen der Kandidaten-Tabelle. Endlos-Schleife und race conditions nicht ausgeschlossen.

ID Verschleiern

Alles “Bekannte” scheint hier nicht zum Erfolg zu führen. Es gibt unendlich viele Methoden, durch logische Verknüpfung (XOR in erster Linie) und sonstige mathematische Funktionen, Zahlen zu verschleiern. Eine einfache, auf diese Problematik passende, möchte ich hier vorstellen.

Man nehme einmalig eine zufällige Zahl (“secret”), die mindestens so groß ist, wie die höchste Primary ID. Der längste PK kann, wenn wir ein MySQL SMALLINT unsigned annehmen, max. 65535 sein. Unsere Zufallszahl: 99565. Diese Zahl ist systemweit immer gleich – wird also für alle späteren Ver- und Entschleierungen verwendet.

Das eigentliche Prozedere ist einfach: Die binäre Präsentation des PK wird umgekehrt und mit der Zufallszahl mit XOR verknüpft. Von der Zufallszahl verwenden wir nur so viele binäre Stellen, wie unser PK hat. Da durch das Umkehren und XORen führende Nullen entstehen können, stellen wir immer eine binäre 1 dem  umgekehrten Binärstring voran – sonst kommt es zu Kollisionen. Beispiel: PK 12 = 1100 Flip +1 = 10011 99565 = _1100[0010011101101] (das ist unser Secret) XOR = 11111 = 31

PK 13      =  1101
Flip +1    = 11011
99565      = _1100[0010011101101] das ist unser Secret)
XOR        = 10111 = 23

PHP-Code

function obfuscateID($pk, $secret, $margin = 5) {
    if ($margin) {
        $pk = base_convert($pk, 10, 10-$margin);
    }

    $pk = bindec(1 . strrev(decbin($pk)));
    $pk ^= bindec(substr(decbin($secret), 0, strlen(decbin($pk))-1));

    return $pk;
}

function deObfuscateID($pk, $secret, $margin = 5) {
    $pk ^= bindec(substr(decbin($secret), 0, strlen(decbin($pk))-1));
    $pk = bindec(substr(strrev(decbin($pk)), 0, -1));

    if ($margin) {
        $pk = base_convert($pk, 10-$margin, 10);
    }

    return $pk;
}

Hier mit Highlighting.

Vorsicht mit bindec() und decbin() auf 32bit-Systemen: hier sind max. Umwandlungen bis zu 4,294,967,295 möglich. Wer auf 32bit mehr braucht, muss sich diese Funktionen auf Stringbasis selber basteln. Anregung dazu findet man wie so oft in den Kommentaren des PHP-Manuals.

Sicherheitsmarge

Um das Erraten von Nachbarn zu erschweren, können die Lücken zwischen den PKs vergrößert werden. Das passiert mit dem Parameter $margin. Dieser muss ebenso wie das $secret systemweit immer gleich sein. Beim Zurückwandeln muss also das selbe Margin angegeben werden, wie für die Verschleierung. $margin kann ein Wert zwischen 0 und 9 haben und basiert auf einer simplen Basisumwandlung (umgerechnet wird von Basis 10 in Basis 10-$margin).

Ausgabe

Bis hierhin war’s ganz schön trocken. Höchste Zeit für ein wenig Praxis! Der folgende PHP-Schnipsel in Kombination mit den obigen Funktionen..

$secret = 99565;
for ($i = 1; $i < 1000; $i++) {
    $camo = obfuscateID($i, $secret);  
    echo "$i: $camo <br />";
}

ergibt folgende Ausgabe:

[..]
524: 7960
525: 15439
526: 11343
527: 13391
528: 9295
[..]
991: 19678
992: 29406
993: 21214
994: 25310
995: 30430
[..]

Zahlen oder Alphanum?

Um Platz zu sparen, könnte man die nach wie vor aus Zahlen bestehende, verschleierte ID in eine höhere Basis (32, 64) umwandeln. Auch mit dieser Umwandlung kann man relativ einfach für (weitere) Lücken sorgen. Da dies aber gefühlt ohnehin schon mein längster Blogbeitrag ist (in jedem Fall was die investierte Zeit angeht), lassen wir das mal so offen stehen bzw. überlasse ich es dem Leser als Übung :)