Blogs

Es war eine mehr als schwere Geburt ein Site-to-Site VPN mit Openswan als Client und einem Draytek Vigor Router als Server herzustellen. Hier nun die Auflösung wie simple es doch sein könnte.

1. Netzwerktopologie
left = Openswan
right = Draytek Vigor Router
10.0.1.0/24 ... 194.1.2.3 == 194.3.2.1 ... 10.0.2.0/24

Es wird ein Site-to-Site VPN für das Subnetz 10.0.1.0/24 und 10.0.2.0/24 über die öffentlichen IPs der Gateway hergstellt. Bei der Verbindung wird kein NAT verwendet! Für die Authentifizierung wird PSK genutzt und die Verbindung mittels ESP im Tunnelmodus aufgebaut.

2. Installation Openswan
# aptitude install openswan

3. Konfiguration Openswan
/etc/ipsec.conf:

version	2.0
 
config setup
	plutodebug=none
	klipsdebug=none
	myid=194.1.2.3
 
conn site-to-site
	type=tunnel
	connaddrfamily=ipv4
	left=194.1.2.3
	leftsubnet=10.0.1.0/24
	right=194.3.2.1
	rightsubnet=10.0.2.0/24
	keyexchange=ike
	auto=add
	auth=esp
	authby=secret
	dpddelay=10
	dpdtimeout=300
	pfs=no
	keylife=28800
	rekey=no
	keyingtries=2
	ikelifetime=3600
	compress=no
 
#Disable Opportunistic Encryption
include /etc/ipsec.d/examples/no_oe.conf

/etc/ipsec.secrets:
194.1.2.3 194.3.2.1 : PSK "dasgeheimepasswort"

3. Konfiguration Vigor Router
VPN und externe Einwahl > LAN-zu-LAN: Neues Profil anlegen
- 3. Allgemeine Einstellungen:
- Einwahl zulassen über IPSec
- Pre-shared Key
- IPSec Sicherheitsmethode: Hoch ESP (AES)

- 4. TCP/IP Netzwerk-Einstellungen:
- Meine WAN-IP: 194.3.2.1
- Remote Gateway-IP: 194.1.2.3
- Remote Netzwerk-IP: 10.0.1.0
- Remote Netzwerk-Maske: 255.255.255.0

4. Starten der IPSec-Verbindung
Aus irgendeinem Grund konnte bei meinen Tests nie eine Verbindung automatisch aufgebaut werden (auto=start), daher initiere ich die Einwahl manuell.
# ipsec auto --up site-to-site

Nun wird der Tunnel aufgebaut und eure lokalen Subnetze können über den IPSec-Tunnel kommunizieren. Um den Tunnel zu Testen versucht aus dem Netz 10.0.1.0 einen Host aus dem Netz 10.0.2.0 zu erreichen. Bedenkt, dass durch eine IPSec-Restriktion vom Gateway kein Host aus dem jeweils anderen Subnetz erreicht werden kann!!

tuxj0b.de ist frei von Vorratsdatenspeicherung. Sämtliche IP-Adressen und Verbindungsdaten auf tuxj0b.de werden unkenntlich gemacht und können nicht zur Auswertung oder Verfolgung genutzt werden.
Dies betrifft natürlich nur den Bereich meines Einflusses (Webserver), euer ISP wird speichern.

Stoppt die Vorratsdatenspeicherung (auch wenn es zu spät sein sollte)

Ich hatte einen kleinen Fehler in der Konfiguration von "virtual_mailbox_domains" der fatale Auswirkungen hatte. Der Fehler bewirkte, dass keine Domain aus der Datenbank aufgelöst werden konnte und daher jeder Sende- oder Empfangsversuch einer Mail mit "Relay access denied" unterbunden wurde. Fehler lag am übergebenen Wert im SQL-Query. Statt "%d" muss "%s" benutzt werden. Fehler wurde korrigiert.

Debian 4.0 bietet von Haus aus leider keine Unterstützung für die 4-Port PCI-E Gigabit Karte NC364T von HP. HP bietet direkt auch nur Treiber für Windows 2003 Server, jedenfalls auf den ersten Blick. Auf den zweiten Blick findet man genau das was man sucht die Linux Netzwerk Treiber, gefunden über Google. Mittels "alien --to-tgz dateiname" könnt ihr die RPM nach tar.gz umwandeln und den Anweisung in der README folgen. Mal wieder traurig, dass Google bessere Ergebnisse liefert, als die Suchfunktion auf der HP Webseite.

Die unter Debian 4.0 mitgelieferte Version von Clamd scheint einige Probleme bezüglich des Erstellen seines Sockets unter "/var/run/clamav" zu haben. Nach dem Start dauert es ca. 30 Minuten bis der Socket endlich erstellt wurde. Dieses Problem hat zur Folge, dass Konfigurationen in Verbindung mit Amavis oder Postfix die ersten 30 Minuten Fehlermeldungen bringen, da der Socket nicht geöffnet werden kann. Dadurch werden die ersten 30 Minuten Mails nicht nach Viren gescannt oder Mails nicht zugestellt.
Scheinbar wurde dieses Problem in den ClamAV Paketen im Debian Volatile Zweig behoben. Konnte aber leider nichts genaues in den Changelogs von clamav-daemon feststellen.

Zur Lösung:
- Einbinden des Debian Volatile Zweigs in die sources.list
echo "deb http://volatile.debian.org/debian-volatile etch/volatile main contrib non-free" >> /etc/apt/sources.list

- Paketcache neu laden
aptitude update

- Patches laden / Debian updaten
aptitude upgrade

Wenn kein Komplettupdate unerwünscht ist, dann nur Clamav updaten.
aptitude install clamav clamav-deamon

Die neue Dovecot Version 1.0.8, erschienen am 28. November, konnte ohne Probleme für das Mailserver-Howto verifiziert werden. Das Howto wurde entsprechend angepasst.

Ich konnte mich dazu aufraffen heute den 3. Teil des Mailserver-Howto fertig zu stellen. Im 3. Teil geht es um die Bekämpfung von Spam und Viren.
Zum Einsatz kommen dabei Amavis, Spamassassin, ClamAV, Razor, Pyzor, DCC und RBLs. Wie immer ist die Konfiguration grob erklärt. Bei Detailfragen hilft euch Google oder ihr schreibt mir eine E-Mail.
Mit dieser Konfiguration habe ich je nach Spamaufkommen bis zu 95% der Spams erkannt. Von 1000 sind das immerhin 950 erkannte Spams, bei 0 False-Positivs. Wenn man sich noch ein bisschen mit Spamassassin Regeln und weiteren RBLs auseinander setzt, bekommt man sicherlich bis zu 99% hin, also 990 von 1000.

Dies ist ein kleines Howto um ein Windows ActiveDirectory als Authentifizeirungs-backend für vsftpd zu nutzen. Die Authentifizierung findet mittels Kerberos 5 statt.

Installieren der benötigten Pakete
aptitude install vsftpd krb5-clients krb5-user libpam-krb5

Bearbeiten der vsftpd Konfig

# /etc/vsftpd.conf
 
# Network
listen=YES
listen_ipv6=NO
listen_port=21
connect_from_port_20=YES
 
# Dir
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
chown_uploads=NO
chown_username=whoever
 
# Anonymous
anonymous_enable=NO
anon_upload_enable=NO
anon_mkdir_write_enable=NO
 
# User
userlist_enable=YES
userlist_deny=NO
 
# Log
syslog_enable=YES
xferlog_enable=YES
xferlog_file=/var/log/vsftpd.log
xferlog_std_format=YES
 
# Banner
ftpd_banner=Welcome
 
# Chroot
chroot_local_user=YES
chroot_list_enable=NO
 
# System
check_shell=NO
nopriv_user=ftp
secure_chroot_dir=/var/run/vsftpd
pam_service_name=vsftpd

Bearbeiten der Kerberos Konfigdatei

[libdefaults]
        default_realm = ADDOMAIN.LOCAL
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
 
[realms]
ADDOMAIN.LOCAL = {
        kdc = server.addomain.local
        admin_server = server.addomain.local
        default_domain = ADDOMAIN.LOCAL
}
 
[domain_realm]
        .addomain.local = ADDOMAIN.LOCAL
        addomain.local = ADDOMAIN.LOCAL
 
[login]
        krb4_convert = true
        krb4_get_tickets = true
 
[appdefaults]
        pam = {
            minimum_uid = 100
            ADDOMAIN.LOCAL = {
                ignore_k5login = true
            }
        }

Bearbeiten der PAM Module Konfigdatei /etc/pam.d/vsftpd

auth            sufficient      pam_krb5.so ignore_root
session         optional        pam_krb5.so ignore_root
account         required        pam_krb5.so ignore_root
password        optional        pam_krb5.so ignore_root
@include common-account
@include common-session
@include common-auth

Benutzer, der sich über den FTP-Server einloggen soll auf dem Linux-Server anlegen

groupadd freach
useradd -c "freach" -d /srv/ftp/freach -g freach -m -s /bin/false freach

Zur Freigabe des Benutzers auf dem FTP-Server müsst ihr seinen Benutzername in der Datei /etc/vsftpd.user_list eintragen.

Neustarten des FTP-Servers
/etc/init.d/vsftpd restart

Nun könnt ihr eure Daten auf dem Linux-Server ablegen euch aber mit dem Passwort aus der Windows Domäne authentifizieren. Leider müsst ihr beim erstellen eines neuen Windows Accounts auch einen Linux Account anlegen. Bedenkt das bei FTP das Passwort im Klartext übertragen wird und eine Authentifizierung über das Netzwerk nicht empfohlen ist. Eine SSL gesicherte Verbindung würde dieses Problem jedoch beheben.

Dokumentation vsftpd
Dokumentation libpam-krb5
Dokumentation Kerberos

Wer in den Genuß eines Groupwise Servers kommt und seinen Client gerne unter Linux, aber nicht auf SuSE betreiben möchte, der kann z.B. auf Ubuntu 7.10 zurückgreifen. Dazu hier ein kleines Howto.
Bevor man beginnen kann muss man sich den aktuellen Groupwise Client auf download.novell.com runterladen. Der Groupwise Client ist für SuSE Systeme vorgesehen, daher nur als RPM Verfügbar, ist aber kein Problem, das ändern wir.

Herunterladen der benötigten Pakete
aptitude install alien libstdc++5 sun-java6-jre sun-java6-plugin

Umwandeln der RPM in eine tgz
alien -t novell-groupwise-gwclient-7.0.1-20060613.i386.rpm

Entpacken und verschieben des Clients

tar xzf novell-groupwise-gwclient-7.0.1.tgz
mv opt/novell /opt/

Löschen der enthaltenen Java Version und linken der Ubuntu Version

rm -R /opt/novell/groupwise/client/jre
ln -s /usr/lib/jvm/java-6-sun/jre /opt/novell/groupwise/client/jre
ln -s /usr/lib/jvm/java-6-sun/jre /usr/lib/jre

Ausführen des Grouwise Clients
/opt/novell/groupwise/client/bin/groupwise.sh

Manchmal ist es nötig Squid nur als Cache zu betreiben und die Anfragen, die nicht im Cache aufgelöst werden können, an einen anderen Proxy weiterzuleiten. Solch eine Lösung kann z.B. praktisch sein, wenn man den Cache-Proxy vom Contenfilter-Proxy trennen möchte. Dazu wird der Contenfilter-Proxy als cache_peer beim Cache-Proxy eingebunden und der Direktzugriff am Contentfilter-Proxy vorbei unterbunden.

prefer_direct off
cache_peer contenproxy.domain.tld parent 8080 0 no-query

Per ACL wird der Direktzugriff untersagt.

acl all src 0.0.0.0/0.0.0.0
 
# Keinen direkten Zugriff.
never_direct allow all