Man könnte Fail2Ban anweisen die ankommende IP zu blocken, falls diese von Postscreen auf einer Blacklist oder mehreren Blacklists gefunden wurde.
Der entsprechende Postscreen Log-Eintrag sieht so aus:

NOQUEUE: reject: RCPT from [x.x.x.x]:xxxx: 550 5.7.1 Service unavailable;
client [x.x.x.X] blocked using zen.spamhaus.org;
from=<spammer@domain.tld>, to=<spam@kupschke.net>, proto=ESMTP, helo=<...>

Nun muss man den Fail2Ban Postfix Filter entsprechend anpassen, diesen findet man in der Datei /etc/fail2ban/filter.d/postfix.conf:
Original:

 failregex = reject: RCPT from (.*)\[<HOST>\]: 554

Meine Anpassungen:

 failregex = reject: RCPT from (.*)\[<HOST>\]: 554
             reject: RCPT from (.*)\[<HOST>\]:([0-9]{4,5}:)? 550

Sofern die Fail2Ban Standardeinstellungen gesetzt sind, würde ein Spammer jetzt nach 3 Versuchen für 10 Minuten gebannt werden.
Mein Postscreen fragt allerdings mehrere Blacklists ab und blockiert den Spammer erst wenn er in mehreren Blacklists eingetragen ist, diese Überprüfungen sind recht teuer, daher möchte ich den Spammer bei seinem ersten Versuch für eine Stunde blockieren.
Um diese Konfiguration einzurichten öffnen wir die Datei /etc/fail2ban/jail.conf und ändern die Einträge wie folgt ab:
Originial:

[postfix]
enabled  = true
port     = smtp
filter   = postfix
logpath  = /var/log/mail.log

Meine Anpassungen:

[postfix]
enabled  = true
port     = smtp
filter   = postfix
logpath  = /var/log/mail.log
maxretry = 1
bantime = 3600

Ob man auch alles richtig eingestellt hat, und welchen Erfolg man bisher mit diesen Regeln gehabt hätte, kann man sich mit diesem Befehl anzeigen lassen:

fail2ban-regex /var/log/mail.log /etc/fail2ban/filter.d/postfix.conf

Mithilfe von Fail2Ban kann man natürlich auch auf alle anderen Ausgaben von Postscreen und Postfix reagieren und die Spammer sehr effizient abwehren.

update-alternatives --config x-terminal-emulator

Auf meinem System erhalte ich folgende Ausgabe:

Es gibt 5 Auswahlmöglichkeiten für die Alternative x-terminal-emulator
(welche /usr/bin/x-terminal-emulator bereitstellen).

  Auswahl      Pfad                 Priorität Status
------------------------------------------------------------
* 0            /usr/bin/terminator   50        Auto-Modus
  1            /usr/bin/koi8rxterm   20        manueller Modus
  2            /usr/bin/lxterm       30        manueller Modus
  3            /usr/bin/terminator   50        manueller Modus
  4            /usr/bin/uxterm       20        manueller Modus
  5            /usr/bin/xterm        20        manueller Modus

Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,
oder geben Sie die Auswahlnummer ein: 4

In meinem Beispiel war "terminator" als Standard gesetzt, dies habe ich durch die Eingabe der 4 auf die Unicode Variante von xterm umgestellt.

git remote add <symbolischer-name> protocol://example.org/git/<remote-repository>

Mit diesem Befehl kann man sich dann alle verfügbaren Repositorys anzeigen lassen:

git remote show

Als Ausgabe erhält man alle Symbolischen Namen, welche man während des hinzufügen der Remote Locations vergeben hat.

Falls man mehr Information über ein bestimmtes Remote Repository erfahren möchte muss nur dessen Symbolischen Namen angeben:

git remote show <symbolischer-name>

1. Benötigte Pakete installieren

apt-get install git git-core openjdk-6-jre apache2 libapache2-mod-jk mysql-server tomcat6

2. CA Zertifikat in den Java Keystore übernehmen
Dieser Schritt ist nur dann wichtig, wenn der LDAP-Server über eine SSL/TLS geschützte Verbindung angesprochen werden soll.

Für OpenJDK lautet der Importbefehl wie folgt:

keytool -import -trustcacerts -alias "example-ca" -file CA.pem -keystore /etc/ssl/certs/java/cacerts -storepass "changeit"

Falls ein Oracle Java genutzt wird sieht der Befehl etwas anders aus:

keytool -import -trustcacerts -alias "example-ca" -file CA.pem -keystore /etc/java6-sun/security/cacerts -storepass "changeit"

3. MySQL-Datenbank anlegen
Zuerst muss man sich in die MySQL-Datenbank mit dem während der Installation gesetzten Passwort einloggen:

mysql -u root -p

Nun legt man eine neue Datenbank und einen Benutzer für die Gerrit Instanz an:

CREATE USER 'gerrit'@'localhost' IDENTIFIED BY 'gerrit';
CREATE DATABASE reviewdb;
ALTER DATABASE reviewdb charset=latin1;
GRANT ALL ON reviewdb.* TO 'gerrit'@'localhost';
FLUSH PRIVILEGES;
quit;

4. Initiale Gerrit Konfiguration durchführen
Zuerst muss ein Ordner für die Gerrit Git-Repositorys und einige Konfigurationsdateien angelegt werden:

mkdir /opt/gerrit
cd /opt/gerrit

Nun können die benötigten Installationsdateien heruntergeladen werden:

wget https://gerrit.googlecode.com/files/gerrit-2.4.2.war -O gerrit.war

Die Gerrit Installation wird mit diesem Befehl gestartet:

java -jar gerrit.war init -d /opt/gerrit/gerrit-home

Während der Installation werden einige Fragen gestellt, die entsprechenden Antworten habe ich fett markiert:


*** Gerrit Code Review 2.4.2
***

Create '/opt/gerrit/review_site' [Y/n]? y

*** Git Repositories
***

Location of Git repositories [git]: /opt/gerrit/git

Database server type [H2/?]: mysql

Gerrit Code Review is not shipped with MySQL Connector/J 5.1.10
** This library is required for your configuration. **
Download and install it now [Y/n]? y
Downloading http://repo2.maven.org/maven2/mysql/mysql-connector-java/5.1.10/mysql-connector-java-5.1.10.jar ... OK
Checksum mysql-connector-java-5.1.10.jar OK

Server hostname [localhost]:
Server port [(MYSQL default)]:
Database name [reviewdb]:
Database username [root]:
gerrit's password :
confirm password :

*** User Authentication
***
Authentication method [OPENID/?]: ldap
LDAP server [ldap://localhost]: ldaps://ldap.example.org
LDAP username :
Account BaseDN [DC=example,DC=org]: OU=Users,DC=example,DC=org
Group BaseDN [OU=Users,DC=example,DC=org]: OU=Groups,DC=example,DC=org
*** Email Delivery
***

SMTP server hostname [localhost]:
SMTP server port [(default)]:
SMTP encryption [NONE/?]:
SMTP username :

*** Container Process
***

Run as [root]:
Java runtime [/usr/lib/jvm/java-6-openjdk-i386/jre]:
Copy gerrit.war to /opt/gerrit/review_site/bin/gerrit.war [Y/n]? y
Copying gerrit.war to /opt/gerrit/review_site/bin/gerrit.war

*** SSH Daemon
***

Listen on address [*]:
Listen on port [29418]:

Gerrit Code Review is not shipped with Bouncy Castle Crypto v144
If available, Gerrit can take advantage of features
in the library, but will also function without it.
Download and install it now [Y/n]? n
Generating SSH host key ... rsa(simple)... done

*** HTTP Daemon
***

Behind reverse proxy [y/N] y?
Use SSL (https://) [y/N] y?
Listen on address [*]:
Listen on port [8080]:

5. Gerrit in den Tomcat deployen
Als aller erstes wird Tomcat gestoppt:

/etc/init.d/tomcat6 stop

Damit der Zugriff auf die Datenbank aus dem Tomcat funktioniert muss eine Datasource in der Datei /etc/tomcat6/context.xml angelegt werden:

<Context>
....
  <Resource name="jdbc/ReviewDb" auth="Container" type="javax.sql.DataSource"
               maxActive="100" maxIdle="30" maxWait="10000"
               username="gerrit" password="gerrit" driverClassName="com.mysql.jdbc.Driver"
               url="jdbc:mysql://localhost:3306/reviewdb"/>
....
</Context>

Um nachher die den Apache-Webserver über mod_jk anzubinden muss zuerst der AJP1.3 freigeschaltet werden. Die Freischaltung geschieht in der Datei /etc/tomcat6/server.xml, so sehen die Zeilen vor der Bearbeitung aus:

    <!-- Define an AJP 1.3 Connector on port 8009 -->
    <!--
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
    -->

Und so nach der Bearbeitung:

    <!-- Define an AJP 1.3 Connector on port 8009 -->
        <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> 

Nun werden die benötigten Daten in die entsprechenden Tomcat Verzeichnisse verschoben:

cd /opt/gerrit/gerrit-home/
cp bin/gerrit.war /var/lib/tomcat6/webapps/
cp lib/mysql-connector-java-5.1.10.jar /usr/share/tomcat6/lib/
chown tomcat6.tomcat6 -R /opt/gerrit/

6. Tomcat über mod-jk anbinden
JK-Worker für Gerrit anlegen:

vi /etc/libapache2-mod-jk/workers.properties

Die workers.properties sollte so aussehen:


workers.tomcat_home=/usr/share/tomcat6
workers.java_home=/usr/lib/jvm/default-java
ps=/

worker.list=gerrit_worker

worker.gerrit_worker.port=8009
worker.gerrit_worker.host=localhost
worker.gerrit_worker.type=ajp13
worker.gerrit_worker.lbfactor=1

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=gerrit_worker

Als nächstes wird eine Konfigurationsdatei für eine generelle mod_jk Konfiguration angelegt:
touch /etc/apache2/conf.d/jk.conf

Die Datei wird mit diesem Inhalt gefüllt:

JkShmFile /var/log/apache2/mod_jk.shm
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +RejectUnsafeURI +ForwardKeySize
JkMount /gerrit gerrit_worker
JkMount /gerrit/* gerrit_worker


Als letztes muss man die VirtualHosts anpassen, in denen die Applikationen verfügbar sein sollen, dazu fügt man folgende Zeile ein:

JkMountCopy On


Zum Abschluss sollten der Tomcat- und der Apache-Server einmal neugestartet werden:

/etc/init.d/tomcat6 restart
/etc/init.d/apache2 restart


Nun könnt ihr euer Gerrit Code Review System über http(s)://your-host/gerrit aufrufen.

Zum Abschluss poste ich hier noch meine funktionierende gerrit.config:

[gerrit]
basePath = /opt/gerrit/git
[database]
type = MYSQL
hostname = localhost
database = reviewdb
username = gerrit
[auth]
type = LDAP
[ldap]
server = ldap://ldap.example.org
accountBase = OU=Users,DC=example,DC=org
groupBase = OU=Groups,DC=example,DC=org
[sendemail]
smtpServer = localhost
[container]
user = root
javaHome = /usr/lib/jvm/java-6-openjdk-i386/jre
[sshd]
listenAddress = *:29418
[httpd]
listenUrl = proxy-http://*:8080/
[cache]
directory = cache


Warum EAP-TTLS?
EAP-TTLS ist eines der flexibelsten EAP Verfahren, da es kaum eine Beschränkung in der Auswahl des Backends zur Passwortverwaltung gibt ( Textdateien, SQL-Datenbanken, Active Directory oder LDAP ).
EAP-TTLS ist wie auch EAP-PEAP ein sogenanntes 2 Phasen Verfahren, hierbei wird in der ersten Phase ein TLS-Tunnel zwischen dem WLAN Client und dem FreeRADIUS-Server aufgebaut.
In der zweiten Phase unterscheiden sich die Verfahren jedoch deutlich, hier unterstützt EAP-PEAP nur MS-CHAPV2, dagegen werden unter EAP-TTLS folgende Verschlüsselungsverfahren unterstützt:

1. EAP
2. CHAP
3. MS-CHAP
4. MS-CHAPv2
5. PAP

Sollten die Passwörter im LDAP-Server als besonders sichere "Salted SHA-1"-Hashes hinterlegt sein kann nur PAP in der zweiten Phase eingesetzt werden, wie man in dieser Tabelle erkennen kann:
Protocol and Password Compatibility

Der in der ersten Phase initialisierte TLS-Tunnel schützt die im unverschlüsselten Password Authentication Protocol (PAP) übertragenen Zugangsdaten.

2. Konfiguration des FreeRADIUS Servers
Installation der Software
Auf dem Server werden die folgenden Pakete installiert:

apt-get install freeradius freeradius-ldap freeradius-utils

SSL Zertifikate erzeugen
Während der Installation werden zumindest unter Ubuntu und Debian sogenannte selbst signierte SnakeOil Zertifikate angelegt.
Diese SnakeOil Zertifikate eignen sich zum testen des Aufbaus sollten aber vor der Inbetriebnahme durch Kaufzertifikate oder zumindest durch die Zertifikate einer eigenen CA ausgetauscht werden, um Man in the Middle Attacken abzuwehren.

AccessPoints als Clients des FreeRADIUS-Server einrichten
Die AccessPoints werden in der Datei /etc/freeradius/clients.conf eingerichtet:

client {
secret = Passwort
shortname = Symbolischer Name
}

Den FreeRADIUS-Server auf EAP-TTLS konfigurieren
Die zu verwendende Verschlüsselungsmethode wird in der Datei /etc/freeradius/eap.conf eingerichtet:
Zuerst muss der Standard EAP-Typ eingestellt werden:

default_eap_type = ttls

Für die TLS Konfiguration müssen das Server Zertifikat, der Private Key, die Diffie-Hellman Parameter und /dev/urandom als Zufallszahlengenerator angegeben werden:

tls {
private_key_file = /etc/freeradius/certs/radius-key.pem
certificate_file = /etc/freeradius/certs/radius-cert.pem
dh_file = /etc/freeradius/certs/dh.pem
random_file = /dev/urandom
cipher_list = "DEFAULT"
}

Zuletzt müssen noch einige EAP-TTLS Konfigurationen angepasst werden:

ttls {
default_eap_type = md5
virtual_server = "inner-tunnel"
}

Warum in der TTLS Konfiguration der default_eap_type auf MD5 gestellt werden muss konnte ich nicht herausfinden, falls man den Wert ändert startet der FreeRADIUS Server nicht mehr.
Der Parameter virtual_server lädt die entsprechende Konfiguration für die Phase 2.

Verbindung zum OpenLDAP Server einrichten
Um den FreeRADIUS-Server an den LDAP Server anzubinden müssen die Verbindungsparameter und die entsprechenden LDAP-Filter eingetragen werden:

ldap {
server = ldap.example.org
port = 636 # Oder 389 falls der LDAP-Server keine SSL gesicherten Verbindungen anbietet.
basedn = "dc=example,dc=org"
filter = "(&(objectClass=posixAccount)(uid=%{User-Name}))"
groupmembership_filter = "(&(objectClass=posixGroup)(memberUid=%{User-Name}))"
groupmembership_attribute = "cn=Gruppe,ou=Groups,dc=example,dc=org"
ldap_connections_number=5
dictionary_mapping = ${confdir}/ldap.attrmap
}

Die LDAP Filter in diesem Beispiel müssen nicht unbedingt auf jedem LDAP Setup funktionieren, diese muss man dann an dass jeweiliges Schema anpassen.

Abschließend muß die Umsetzung zwischen den RADIUS und den LDAP Attributen in der Datei /etc/freeradius/ldap.attrmap konfiguriert werden.
Es sollte alle eventuell vorhandenen Attribute gelöscht werden, sodass die Datei die folgenden fünf Zeilen enthält:

checkItem $GENERIC$ radiusCheckItem
replyItem $GENERIC$ radiusReplyItem
checkItem LM-Password sambaLmPassword
checkItem NT-Password sambaNtPassword
checkItem SMB-Account-CTRL-Text acctFlags


3. Konfiguration der AccessPoints
Mittlerweile unterstützen die gängisten AccessPoints und WLAN-Router das RADIUS-Protokoll, hierbei sind immer folgende Angaben zu machen:

1. IP-Adresse des RADIUS-Servers
2. Der RADIUS-Server Port: 1812
3. Das Shared Secret aus der clients.conf

Nun sollte man ein funktionsfähiges WPA2 Enterprise Setup besitzen, falls es zu Problemen kommt kann man den FreeRADIUS in einem ziemlich gesprächigem Modus starten:
freeradius -vv

RADIUS und EAP als Protokolle und FreeRADIUS als Software sind recht komplexe Themengebiete, also nicht gleich aufgeben falls etwas nicht klappt.
Für alle die sich tiefer mit der Materie auseinandersetzen wollen kann ich folgende RFCs empfehlen:
RFC zu RADIUS: http://www.ietf.org/rfc/rfc2865.txt
RFC zu EAP-TTLS: http://tools.ietf.org/html/rfc5281

1. Software installieren
Zusätzlich zu einem bestehenden Apache Webserver wird nur noch folgendes Paket benötigt:
apt-get install git-core

2. Verzeichnisstruktur für Git anlegen
Für die Git Projekte lege ich typischerweise eine neue Ordnerstruktur an:
mkdir -p /data/git

3. Git Repository anlegen
Zuerst wird ein leeres Verzeichnis angelegt:
mkdir /data/git/<projekt>

Jetzt wechselt man in das Verzeichnis und initialisiert das Repository, hierbei ist es wichtig die Datei "git-daemon-export-ok" anzulegen, damit das Repository über Smart HTTP exportiert werden kann:

cd ${GIT_REPO}
git init --bare
git update-server-info
touch git-daemon-export-ok


Zum Schluss müssen die Recht soweit angepasst werden, damit der Apache Webserver in dem Verzeichnis lesen und schreiben darf:

chgrp www-data ${GIT_DIR} -R
chown www-data ${GIT_DIR} -R
chmod 750 ${GIT_DIR}


4. Repository übergreifende Apache Konfiguration
Damit der Smart HTTP Export nachher funktioniert müssen einige Umgebungsvariablen definiert werden, dafür legen wir unter /etc/apache2/conf.d die Datei git.conf an:

SetEnv GIT_PROJECT_ROOT /data/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/

Jetzt werden alle Repositorys exportiert in denen die Datei "git-daemon-export-ok" enthalten ist, die Absicherung über einen Benutzernamen und Passwort wird in Punkt 5 des Tutorials beschrieben.

In dem VirtualHost über den die Git-Repositorys angeboten werden muss folgender Alias gesetzt werden:

Alias /git /data/git


5.Absicherung des Git-Repositorys mit einer Basic-Authentication
Zuerst wird eine Datei angelegt, in der die einzelnen Gruppen definiert werden:

touch /etc/apache2/groups

Die Gruppen und Benutzer trägt man nach diesem Schema ein:

groupname : user1 user2


Jetzt wird eine Passwortdatei angelegt in der später die Benutzer und ihre Passwörter eingetragen werden:

touch /etc/apache2/passwd


Die Nutzer werden mit diesem Befehl angelegt:

htpasswd /etc/apache2/passwd username

Nun wird man aufgefordert das Passwort des Benutzers zweimal einzugeben.

In dem Verzeichnis /etc/apache2/conf.d/ wird nun für das Repository eine eigene Konfigurationsdatei angelegt, zum Beispiel projekt.conf mit folgendem Inhalt:

< Location "/git/projekt" >
AuthType Basic
require group groupname
AuthName "Projekt"
AuthUserFile /etc/apache2/passwd
AuthGroupFile /etc/apache2/groups
SSLRequireSSL
< /Location >


Solche Angriffe sind dann interessant, wenn man sich in dem gleichem WLAN-Netzwerk wie das Opfer befindet, um dann die Session Cookies abzugreifen und die Sitzung zu übernehmen (Firesheep).

Es muss sich allerdings nicht immer gleich um einen Angriff handeln, manchmal sind es sich auch schlicht Fehler in der Website/Web-Applikation welche den Benutzer auf einen ungeschützten Bereich umleiten.

Um solche Fehler und / oder Angriffe ins leere laufen zu lassen kann der Webserver dem Browser des Nutzers mitteilen, wie lange er diese Domain oder auch alle Subdomains nur noch HTTPS gesichert aufrufen darf.

Um HSTS im Apache zu aktivieren benötigt man erst das "Headers"-Modul, dieses aktiviert man mit diesem Befehl:

a2enmod headers


Jetzt trägt man den HSTS-Header in jeden VirtualHost ein den man absichern möchte:

<VirtualHost www.kupschke.net:443>
ServerAdmin dominik@kupschke.net
DocumentRoot /var/www
Header always set Strict-Transport-Security "max-age=31556926"
</VirtualHost>

Mit dieser Anweisung sagen wir dem Browser, dass er die nächsten 365 Tage die Domain www.kupschke.net nur noch über HTTPS aufrufen soll.

Die entsprechende Dauer kann man über den Wert "max-age" einstellen, welcher die Zeit in Sekunden aufnimmt.

Falls man zusätzlich noch alle Subdomains mit absichern möchte erweitert man die Zeile wie folgt:
Header always set Strict-Transport-Security "max-age=31556926 includeSubDomains"

Folgendes Script komprimiert alle Repositorys in einem bestimmten Verzeichnis und gibt die Größe des Ordners vor und nach der Komprimierung aus:

#!/bin/bash
GIT_PATH=/data/git</code>

echo 'Gesamtgröße vor der Komprimierung:'
du -sh ${GIT_PATH}

cd ${GIT_PATH}

for i in *
do

cd ${GIT_PATH}/$i
git gc

done

echo 'Gesamtgröße nach der Komprimierung:'
du -sh ${GIT_PATH}

Das Script lässt sich mit lokalen und bare Repositorys auf einem Server nutzen.

Damit Debian Wheezy von jeder Festplatte des RAID Verbundes booten kann, muss folgende Zeile in der Datei "/etc/default/grub" auskommentiert werden:
GRUB_TERMINAL=console

Jetzt müssen alle Datenträger für den Grub2 registriert werden:

grub-mkdevicemap -n

Zum Schluss aktualisiert man noch die Grub2 Konfiguration und installiert den Grub2 Bootloader in jede Festplatte des RAID-Verbunds:

update-grub

grub-install /dev/sda grub-install /dev/sdb

Jetzt kann das System von jeder Festplatte des RAIDs gestartet werden.

1. Konfiguration des Apache2 Webservers
Ein Apache auf einem aktuellen Debian Squeeze ist von Haus aus in der Lage, einen VirtualHost mit einem über IPv6 auflösbaren DNS-Record auszuliefern. Probleme bekommt man allerdings wenn man einen SSL-VirtualHost für IPv4 und IPv6 nutzen möchte, als Lösung bleibt einem nur die Konfiguration des VirtualHosts zu kopieren und die IPv6 Adresse in den neuen VirtualHost einzutragen.

Die Lösung wird an diesem Beispiel verdeutlicht:
Alter IPv4 SSL-VirtualHost (bleibt bestehen):

<VirtualHost kupschke.net:443>

ServerName kupschke.net
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl.crt
SSLCertificateKeyFile /etc/apache2/ssl/ssl.key

</VirtualHost>

Neuer IPv6 SSL-VirtualHost:

<VirtualHost [2a01:4f8:121:1085::58c6:9011:1]:443>

ServerName kupschke.net
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/ssl.crt
SSLCertificateKeyFile /etc/apache2/ssl/ssl.key

</VirtualHost>

Nach einem Neustart des Apache Webservers sollte es problemlos möglich sein, die Website geschützt mit SSL unter IPv4 und IPv6 aufzurufen.

2. Konfiguration des Postfix
Einen Postfix auf den Betrieb von IPv4 und IPv6 umzustellen ist recht einfach, dazu wird /etc/postfix/main.cf mit einem Editor geöffnet und diese Zeile entsprechend erweitert:
inet_protocols = ipv4,ipv6

3. Konfiguration des Dovecot IMAP / POP3 Servers:
Der Dovecot Daemon lässt sich sehr leicht an die neue Situation anpassen, dazu öffnet man die Konfigurationsdatei /etc/dovecot/dovecot.conf und sucht nach folgender Zeile:
listen = *
diese wird dann wie folgt erweitert:
listen = *,[::]

Anhand der drei exemplarischen Dienste sieht man, dass eine Umstellung auf IPv6 aus Sicht der Softwarefeatures nicht unbedingt schwer ist.
Ein Großteil der Fehler wird typischerweise durch fehlerhafte DNS-Records erzeugt, hier sollte man genügend Zeit für eine entsprechende Qualitätssicherung und Tests einplanen.