Autor: steffmaster

Installation

Test

Chromium.conf bearbeiten

Ersetze in Zeile

speichern und fertig.

Ubuntu-Desktop (Gnome) installieren

VNC Server installieren

Suche in der Datei nach ( Zeile: 57 )

danach einfügen

VNC Server starten

VNC Server läuft

VNC server als Service

Datei füllen mit:

Rechte setzen

VNC Server.conf erstellen

Füllen mit z.B.

Autostart

händisch

http://www.onlinehilfedatenbank.de/index.php?action=artikel&cat=5&id=7&artlang=de

http://www.krizna.com/ubuntu/install-vnc-server-ubuntu-14-04/

http://weidner.in-bad-schmiedeberg.de/archives/2012/11/ubuntu-precise-pangolin-xen-domu/

Quelle

Installation von Getmail und die Konfiguration
Wir installieren zuerst getmail mit einem

apt-get install getmail4
Wir legen nun eine neuen User getmail an, der für uns in Zukunft die Sache erledigen wird:

adduser getmail
Vergebt hier das Passwort. Da das kein Standarduser sein soll und falls Ihr einen ftp am Laufen habt, dann schließt bitte diesen User vom ftp- Zugriff aus. Dies erledigt Ihr, indem Ihr den User getmail in die Datei /etc/ftpusers eintragt.

nano /etc/ftpusers
Startet nach einer Änderung den proftp neu:

/etc/init.d/proftpd restart
Gleiches machen wir nun mit einem User postfach1. Ihr könnt den Namen frei auswählen, denn das werden dann die Mailnutzer werden, die dann via IMAP ihre Mails abrufen können. Legt auch diese mit adduser an und schließt diese aus dem ftp-Zugriff aus.

Jetzt wollen wir auch nicht, dass eventuell über ssh auf die Mailboxen zugegriffen werden kann. Wenn Ihr einen ssh Clienten nach außen offen habt, dann ist das sicherlich auch ratsam. Ihr könnt das Anmelden (auch damit lokal am Rechner) unterbinden, indem Ihr in der /etc/passwd für den jeweiligen User hinten das /bin/bash in /bin/false abändert. Dann ist auch das Anmelden nicht mehr möglich.

Um jetzt auch ganz sicher zu sein, dass Ihr das richtig konfiguriert habt versucht Euch jeweils mittels ftp und dann nochmal via ssh an beide User anzumelden. Erst wenn sichergestellt ist, dass beide Verbindungen nicht möglich sind können wir weiter machen.

Um später aber einen Test mit getmail durch zu führen muss die Änderung in der /etc/passwd nochmal rückgängig gemacht werden. Aber auch hier gehe ich dann im Bedarfsfall darauf ein.

Wenn das erledigt ist müssen wir aber immer daran denken, dass wir die als root angelegten Dateien später immer dann den jeweiligen User zuweisen, damit es kein Rechteproblem gibt. Darauf gehe ich dann aber noch ein, wenn es soweit ist.

Nun wechseln wir in das Verzeichnis /home/getmail :
cd /home/getmail
und legen ein neues verstecktes Verzeichnis an:

mkdir .getmail
Dort erstellen wir nun eine Konfigurationsdatei:

touch .getmail/mailbox1.conf
Diese befüllen wir nun mit folgenden Inhalt:

[options]
verbose = 0
delete = true # true= mails werden auf Server gelöscht false= Mails werden nicht gelöscht
read_all = false # true= alle Mails werden abgeholt false= nur neue Mails werden abgeholt
message_log = ~/.getmail/mailbox1.log # Fehler beim Abholen werden in die Logdatei mailbox1 geschrieben

[retriever]
type = SimplePOP3Retriever
server = mail.euerprovider.de # Die Adresse des Mailserversers Eures Providers
username = username # Der Username des Mailservers
password = euerpasswort # Passwort, Achtung, kann gelesen werden, wer auf den Server kommt

[destination]
type = MDA_external # Das sagt aus, dass ein externes Programm die Mails übernimmt
path = /usr/bin/procmail # Procmail nimmt alles in die Hand
arguments = („-dpostfach1“, ) # Der Nutzer postfach1 bekommt die Mails überstellt
(HINWEIS: Bitte entfernt die Kommentare hinten an den Zeilen – alles was mit # losgeht)

Wenn Ihr nun mehrere externe Mailboxen besitzt legt dann für jede Mailbox eine eigene Konfigurationsdatei an. Bennent jede Konfigurationsdatei eindeutig, damit Ihr diese später auseinanderhalten könnt. Zudem legt in jeder Datei fest, welcher Nutzer die Mails dann bekommen soll. Das wird im Bereich

arguments = („-dxyz“, )
festgelegt. xyz = der jeweilige Nutzer, der die Mails bekommen soll.

Damit nur getmail die Datei lesen darf regelt die Zugriffsrechte nun wie folgt: Aus dem Verzeichnis /home/getmail heraus gebt nun folgende Befehle ab:

cd /home/getmail
chown getmail:getmail -R .getmail
chmod 640 .getmail/*
Im Grunde haben wir nun unseren kleinen Dämonen schon fertig, der später regelmäßig all unsere Mailboxen nach neuen E-Mails abklappert. Bedenkt aber, wenn Ihr ein firewall- Skript am Laufen habt, dass Ihr den Port 110 (TCP_OUT) freischaltet, sonst kann Euer Server nicht auf den externen POP3 zugreifen.

Installation von Procmail und die Konfiguration
Procmail bekommt ja nun die Mails alle in einen Topf geschmissen und verteilt die Mails nun nach entsprechenden Schematas in die einzelnen Postfächer der Mailnutzer. Es kann sein, dass procmail bereits schon auf Eurem System vorhanden ist. Um hier sicher zu gehen setzt als root schnell mal ein

apt-get install procmail
ab. Jetzt wechselt in das Verzeichnis des Users postfach1:

cd /home/postfach1
Dort legt nun eine Konfigurationsdatei an:

touch .procmailrc
Zudem zwei neue Verzeichnisse:

mkdir mail
mkdir log
Nun befüllt die .procmailrc mit folgenden Inhalt:

MAILDIR=$HOME/mail # Hier kommen die Mails rein
LOGFILE=$HOME/log/procmail.log # Fehlermeldungen werden in der log gespeichert
VERBOSE=on

:0
* ^TO_.*beispiel.de # Mails dern Empfänger auf beispiel.de enden
.test/ # landen in INBOX.test

:0
* ^From: .*spammer@domain.com # Mails von einer bestimmten Adresse werden gelöscht
/dev/null

:0
* ^TO_.*test2@beispiel.de # alle Mails an eine bestimmte Adresse werden in
.test2/ # in die INBOX.test2 einsortiert

:0
./ # Alles andere an direkten Posteingang
Folgendes ist hier wichtig: Hinten müssen die Kommentare wieder entfernt werden, sonst werden diese in die Suchkriterien mit eingezogen und es gibt entsprechende Missmatches. Den Ordner ./ auf jeden Fall anlegen! Alternativ vielleicht auch .INBOX.missmatches/ benennen. Denn wenn mal was nicht in den Regeln zutreffen sollte, dann landet die Mail immer erst hier. Dann kann man in der Logfile nachsehen, warum die Mail nicht zugeordnet wurde und entsprechend die Regeln in der .procmailrc anpassen.

Das ^ am Anfang einer Regel bedeutet, dass das Wort am Zeilenanfang gesucht wird. Ein TO oder From im Header steht immer vorne. Mit einem .* vor einem Suchbegriff kann man mögliche zusätzliche Leerzeichen mit einschließen und vermeidet Missmatches bei zusätzlichen Leerzeichen.
Damit zum Schluss alle Zugriffsrechte passen, führen wir dann ein

chown -R postfach1:postfach1 /home/postfach1/
aus. Prüft mit einem ls -la innerhalb des Verzeichnisses dann nach, ob die Dateien und Verzeichnisse dem User postfach1 gehören.

Erster Test
Um nun zu überprüfen, ob die ersten Regeln funktionieren und auch von der Mailbox abgerufen werden kann müsst Ihr Euch als User getmail einloggen. Hierfür müssen wir unsere Sperre in der /etc/passwd rückgängig machen. In der Zeile des Users getmail ändert dort wieder das /bin/false auf /bin/bash ab. Jetzt funktioniert die Anmeldung:

su getmail
Ändert zum Testen auch in Eurer Getmail Config das

delete = true
auf

delete = false
ab, da Ihr garantiert das öfters testen müsst, bis es passt!

Führt nun den Abruf aus:

getmail -v –rcfile ~/.getmail/mailbox1.conf
Wenn Ihr mehrere Boxen abruft, dann einfach diese zusätzlich anhängen:

getmail -v –rcfile ~/.getmail/mailbox1.conf –rcfile ~/.getmail/mailbox2.conf
Wenn alles gut läuft bekommt Ihr eine entsprechende Meldung:

getmail -v –rcfile ~/.getmail/mailbox1.conf
getmail version 4.7.8
Copyright (C) 1998-2007 Charles Cazabon. Licensed under the GNU GPL version 2.
SimplePOP3Retriever:blah@mail.beispiel.de:110:
msg 1/14 (2428090 bytes) delivered
msg 2/14 (3415 bytes) delivered
msg 3/14 (3253 bytes) delivered
msg 4/14 (2940 bytes) delivered
msg 5/14 (4124 bytes) delivered
msg 6/14 (3687 bytes) delivered
msg 7/14 (4498 bytes) delivered
msg 8/14 (5705 bytes) delivered
msg 9/14 (5377 bytes) delivered
msg 10/14 (3863 bytes) delivered
msg 11/14 (4275 bytes) delivered
msg 12/14 (5422 bytes) delivered
msg 13/14 (3715 bytes) delivered
msg 14/14 (4015 bytes) delivered
14 messages (2482379 bytes) retrieved, 0 skipped
Loggt Euch wieder aus:

exit
Nun geht in das Homverzeichnis des Postfach1 und seht unter /mail nach, ob Ihr Mails dort unter new liegen habt. Wenn diese im Spam Ordner gelandet sind, dann stimmt was mit der procmail Regel nicht und müsst diese anpassen. Zum erneuten Test löscht dann unter /mail alle Verzeichnisse und wiederholt das so lange, bis die Mails korrekt einsortiert werden. Es wird sicherlich hin und wieder Mails geben, die nicht sauber einsortiert werden. Für diese Gelegenheiten müsst Ihr dann Eure Regeln entsprechend anpassen. Die procmailrc wird Euch somit noch lange begleiten bis alles wie gewünscht funktioniert.

Nun werden wir den Mailabruf automatisieren. Dazu öffnet noch als user getmail angemeldet die crontab mit

crontab -e
Dort fügt nun Euren Getmail-Aufruf ein und ergänzt die Zeile wie folgt:

*/5 * * * * /usr/bin/getmail -v –rcfile ~/.getmail/mailbox1.conf –rcfile ~/.getmail/mailbox2.conf > /dev/null 2>&1
Das ruft den Prozess nun alle 5 Minuten ab. D.h. alle 5 Minuten werden Eure externen Mailboxen auf neue E-Mails überprüft und dem procmail übergeben, der Weiteres für Euch erledigt, indem er filtert und in Mailboxen verteilt.

Wenn alles glatt läuft, dann meldet Euch als getmail ab und sperrt wieder den Zugriff auf den getmail in der /etc/passwd und setzt dort den User wieder auf /bin/false.

Getmail mit SSL Verbindung
Die Übertragung der Dateien sollte natürlich auch verschlüsselt erfolgen. Die meisten Provider sollten das auch zur Verfügung stellen. Wenn unser Test erfolgreich war, dann stellen wir noch die Konfiguration entsprechend um. Editiert dazu die entsprechende Getmail Konfigurationsdatei:

nano /home/getmail/.getmail/mailbox1.conf
Die Zeile

type = SimplePOP3Retriever

tauscht in

type = SimplePOP3SSLRetriever

aus. Solltet Ihr ein Firewallscript verwenden, dann müsst Ihr als TCP_OUT den Port 995 eintragen.
Führt dann nochmal einen Test wie oben beschrieben durch und prüft damit, ob der Abruf klappt.

Imap mit Dovecot
Beim Imap Server möchte ich es Euch recht einfach machen. Ihr benötigt hierfür einen Installationsbefehl und ein paar Kleinigkeiten zum Editieren.

Editiert zunächst die /etc/hosts

nano /etc/hosts
Die ersten zwei Zeilen sehen ungefähr so aus:

127.0.0.1 localhost
127.0.0.1 meinserver.example.org meinserver
Damit es später keinen Huddel gibt beim Erstellen der Sicherheitszertifikate ändert diese auf

127.0.0.1 localhost
192.168.1.77 192.168.1.77 meinserver
ab. Die Änderung speichert Ihr ab. Jetzt könnt Ihr die benötigten Programme installieren:

apt-get install dovecot-common dovecot-imapd
Wenn Ihr dann bei der Installation in dem Moment, in dem der Dovecot gestartet wird, eine Meldung

Fatal: Failed to start listeners
failed!

erhaltet, dann kracht es an einer Stelle mit dem IPv6, d.h. wird von Eurem Server nicht unterstützt.
Editiert deshalb die dovecot.conf:

nano /etc/dovecot/dovecot.conf
Schreibt unter die Zeile

#listen = *, ::

folgende Zeile:

listen = *

Startet dann nochmal den Dovecot:

/etc/init.d/dovecot restart
Der Fehler sollte jetzt weg sein und der Dovecot laufen.

Während er Installation werden automatisch die Zertifikate

/etc/dovecot/dovecot.pem
/etc/dovecot/private/dovecot.pem

für 10 Jahre angelegt. Solltet Ihr diese aus irgendeinem Grund neu generieren wollen dann löscht beide dovecot.pem Dateien und generiert diese wieder mit einem:

dpkg-reconfigure dovecot-common
Wir editieren noch drei Dovecot Konfigurationsdateien:

nano /etc/dovecot/conf.d/10-mail.conf
Hier muss das Standardverzeichnis /var/mail für die reinkommenden E-Mails von /var/mail auf das Homeverzeichnis umgestellt werden. Ändert deswegen die Mail Location wie folgt ab:

mail_location = maildir:~/mail

nano /etc/dovecot/conf.d/10-auth.conf
Sollte man Plaintext Auth verhindern wollen:

#disable_plaintext_auth = yes

in

disable_plaintext_auth = yes

nano /etc/dovecot/conf.d/10-ssl.conf

#ssl = yes

in

ssl = yes

Das war es dann auch schon. Speichert die Änderung und startet Euren Imap Server neu.

/etc/init.d/dovecot restart
An der stelle könnt Ihr Euch schon an den IMAP Server mittels Euren Mail Clienten wie den Thunderbird einloggen. Alternativ installieren wir jetzt noch den Webmailer Squirrelmail:

Squirrelmail Webmailer
Auf einem Debian Webserver (Apache2, php, MySQL) ist Squirrelmail recht schnell installiert.

Zunächst installieren wir Squirrelmail an der Konsole:

apt-get install squirrelmail
Solltet Ihr noch das Shared Kalender Plugin verwenden wollen, müssen noch zwei zusätzliche Pakete installiert werden:

apt-get install php-db php-pear
Squirrel verteilt sich entsprechend im Dateisystem. Die Files selbst liegen im Verzeichnis /usr/share/squirrelmail . Damit der Apache diese auch findet, richten wir einfach einen virtuellen Host ein. Editiert dazu die /etc/apache2/sites-enabled/000-default und fügt unter dem ersten Alias Abschnitt folgenden Abschnitt mit ein (bitte INNERHALB des virtual host Abschnitts!!!):

Alias /squirrelmail /usr/share/squirrelmail

Options Indexes
AllowOverride All
DirectoryIndex index.php
Order allow,deny
allow from all

Damit wird wenn Ihr an Eure URL /squirrelmail mit anfügt der Webmailer aufgerufen, da er über die Alias dann in das Verzeichnis /usr/share/squirrelmail geroutet werdet.

Konfiguriert nun Euren Webmailer mit

squirrelmail-configure
Ihr seht nun das Hauptmenü:

SquirrelMail Configuration : Read: config_default.php (1.4.0)
———————————————————
Main Menu —
1. Organization Preferences
2. Server Settings
3. Folder Defaults
4. General Options
5. Themes
6. Address Books
7. Message of the Day (MOTD)
8. Plugins
9. Database
10. Languages

D. Set pre-defined settings for specific IMAP servers

C Turn color on
S Save data
Q Quit

Command >>
Wählt hier D aus. Danach seht Ihr folgendes Menü:

Please select your IMAP server:
bincimap = Binc IMAP server
courier = Courier IMAP server
cyrus = Cyrus IMAP server
dovecot = Dovecot Secure IMAP server
exchange = Microsoft Exchange IMAP server
hmailserver = hMailServer
macosx = Mac OS X Mailserver
mercury32 = Mercury/32
uw = University of Washington’s IMAP server

quit = Do not change anything
Command >>
Wir nehmen hier natürlich den dovecot.

Danach müssen die Serversettings eingestellt werden (Im Hauptmenü Punkt 2):

Server Settings

General
——-
1. Domain : example.com
2. Invert Time : false
3. Sendmail or SMTP : SMTP

A. Update IMAP Settings : localhost:143 (dovecot)
B. Update SMTP Settings : localhost:25

R Return to Main Menu
C Turn color on
S Save data
Q Quit

Command >>
Stellt hier unter 1.) Euren Domain Namen ein. Dann geht in den Unterpunkt A.):

IMAP Settings
————–
4. IMAP Server : localhost
5. IMAP Port : 143
6. Authentication type : login
7. Secure IMAP (TLS) : false
8. Server software : dovecot
9. Delimiter : detect

B. Update SMTP Settings : localhost:25
H. Hide IMAP Server Settings

R Return to Main Menu
C Turn color on
S Save data
Q Quit

Command >>
Hier müssen die Settings entsprechend angepasst werden. Euer domain Name wo der Imap zu finden ist (localhost normalerweise). Zudem den Port auf 993 für SSL umstellen und Secure Imap auf True umstellen.

Im Unterpunkt 10 des Hauptmenüs könnt Ihr noch das en_US

Language preferences
1. Default Language : en_US
2. Default Charset : iso-8859-1
3. Enable lossy encoding : false

R Return to Main Menu
C Turn color on
S Save data
Q Quit

Command >>
… in de_DE umstellen. Speichert die Änderungen mit S ab und beendet das Konfigurationsprogramm mit Q .

Falls auf Lenny der Squirrel nicht auf Deutsch geht, obwohl Ihr das de_DE eingestellt habt, dann fehlt Euch noch „de_DE iso-8859-1“ in den locales, da bei einer deutschen Installation standardmäßig nur de_DE UTF-8 ausgewählt wurde. Also führt

dpkg-reconfigure locales
aus und fügt bei den Sprachen de_DE iso 8859-1 mit hinzu. Den Rest lasst ihr einfach wie voreingestellt.

Danach startet den Apachen neu:

/etc/init.d/apache2 restart
Ruft nun Euren Webmailer über

http://EURE_URL/squirrelmail
auf.

Jetzt wollen wir nur noch eine Verbindung über https zulassen. Dazu müssen wir dem Apache https als Erweiterung beibringen. Wechselt dazu in Euer Root Home:

cd /root
Danach legen wir unser Serverzertifikat an:

openssl genrsa -out server.key 4096
openssl req -new -key server.key -out server.csr
Jetzt werdet Ihr einige Angaben abgefragt:

Country Name (Ländercode): = DE
State or Province Name (Bundesland): = zB Bayern
Locality Name, eg. City (Stadt): = zB Nuernberg
Organization Name (Firmenname): = hier irgendwas eingeben wie privat, zuhause etc.
Organizational Unit Name (Abteilung) = bleibt leer
Common Name, eg. YOUR Name: = Euer Servername
Email Adress: = eine E-Mail Adresse
A challenge password: = bleibt leer
An optional company name: = bleibt leer

Jetzt generieren wir das Zertifikat. Ich mache das gleich mal für 10 Jahre, dann ist Ruhe:

openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt
Noch ein paar Rechte festlegen:

chmod 400 server.key
Jetzt müssen wir noch ein paar Änderungen in einigen Apache Konfigurationsdateien vornehmen:

nano /etc/apache2/sites-enabled/000-default
Am Ende der Konfigurationsdatei ergänzt folgende neue Sektion:

DocumentRoot /var/www
ServerName EUER_SERVERNAME
SSLEngine on
SSLCertificateFile /root/server.crt
SSLCertificateKeyFile /root/server.key

Alias /squirrelmail /usr/share/squirrelmail

Options Indexes
AllowOverride All
DirectoryIndex index.php
Order allow,deny
allow from all

EUER_SERVERNAME muss noch entsprechend eingetragen werden. Speichert die Änderung und editiert die ports.conf

nano /etc/apache2/ports.conf
und fügt ganz zum Schluss folgende Zeile ein:

NameVirtualHost *:443

Nun aktivieren wir das SSL Modul:

a2enmod ssl
Der Apache muss jetzt neu gestartet werden:

/etc/init.d/apache2 restart
Beachtet, dass das natürlich kein gekauftes Zertifikat ist. Euer Browser wird hier eine entsprechende Warnmeldung bringen. Aber Ihr wisst damit, warum diese Meldung kommt.

Wenn Ihr generell auf https umleiten wollt, auch wenn die Adresse über http abgerufen wird, müsst Ihr im Apache das Modul Rewrite aktivieren:

a2enmod rewrite
/etc/init.d/apache2 restart
Legt dann eine .htaccess Datei in /usr/share/squirrelmail an:

nano /usr/share/squirrelmail/.htaccess
Füllt diese mit folgenden Zeilen:

Options +FollowSymlinks
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Nun werden sämtliche Anfragen auf das verschlüsselte https Protokoll umgeleitet.

Zu guter Letzt wollen wir generell verhindern, dass man von außen einfach einen Zugriff auf das Login des Squirrelmail bekommt. Wir blockieren das deshalb mit .htaccess und aktivieren eine darüberliegende Passwortabfrage.

Fügt deshalb in der .htaccess noch folgendes ein:

AuthType Basic
AuthName squirrelmail
AuthUserFile /usr/share/squirrelmail/.htpasswd
require valid-user
Ihr seht, dass der Pfad zu dem dann erzeugtem Passwort im Dokumentenroot der Webanwendung liegt. Um das einwenig sicher zu machen, könnt Ihr durchaus dieses in ein anderes Verzeichnis legen, das außerhalb des Dokumentenroot liegt.

Das Passwort legt Ihr dann in diesem Verzeichnis (mittels cd dorthin wechseln!) mit einem

htpasswd -c .htpasswd username
an. Beim Befehl den Usernamen entsprechend Euren Vorstellungen ändern! Jetzt werdet Ihr zusätzlich nach einem Passwort gefragt.

E-Mails via Exim4 verschicken
Jetzt wollen wir noch E-Mails über den Server versenden können. Da wir keinen eigenen smtp Server einrichten wollen nehmen wir einfach den unseres Providers als smarthost (Ihr solltet Euch vergewissern, dass Euer Provider da nichts dagegen hat, allerdings merkt er nicht, ob ein Homeserver oder ein normaler Mail Client versendet. Solltet Euer Rechner als Spamschleuder missbraucht werden wird früher oder später Euer Provider auf den Plan treten 😉

Installiert den Exim4 mit einem

apt-get install exim4
Um einen Smarthost einzurichten startet die Konfiguration mit einem

dpkg-reconfigure exim4-config
Folgende Konfigurationsschritte:
1.) Versand über Sendezentrale (Smarthost); Empfang mit SMTP oder Fetchmail

2.) Email Name des Systems: Lasst einfach den voreingestellten Domänen Name stehen

3.) IP-Adressen, dan denen eingehende SMTP-Verbindungen erwartet werden: 127.0.0.1

4.) Weitere Ziele, für die die E-Mails angenommen werden sollen: Auch hier den default Domän Namen stehen lassen

5.) Rechner für die die E-Mails weitergeleitet werden sollen (Relay): Leer lassen, wenn nicht ein weiterer Rechner DIESEN Rechner als Smarthost verwendet. Also normal leer lassen.

6.) IP Adresse oder Rechnername der Sendezentrale für ausgehende E-Mails: Hier und genau hier kommt die IP Adresse oder der Rechnername (mail/smtp.xyz) Eures ISP rein!

7.) Lokalen E-Mail Namen in ausgehende Mails verbergen: Ja

8.) DNS Anfrage minimieren: Ja

9.) Versandart bei lokaler Mailzustellung: Mbox Format in /var/mail/

10.) Einstellungen auf kleine Dateien aufteilen: Nein

11.) 11.) Empfänger an die Benutzer „root“ und „postmaster“: leer lassen

Danach startet der MTA neu. Jetzt kann es auch sein, dass Euer Smarthost eine Authentifizierung abverlangt. Diese hinterlegt in der folgenden Datei: /etc/exim4/passwd.client

Hier das Passwort wie folgt hinterlegen:

IP_des_Mailserver_oder_Name:LOGIN:PASSWORT
Die Datei sollte nur lesbar für root sein.

Startet danach den MTA neu:

/etc/init.d/exim4 restart
Solltet Ihr eine Fehlermeldung exim paniclog /var/log/exim4/paniclog has non-zero size erhalten, dann greift Exim4 auf IPv6 zu, ohne dass IPv6 zur Verfügung steht. Entfernt zunächst die paniclog:

rm /var/log/exim4/paniclog
Lasst nochmal die Konfiguration durchlaufen:

dpkg-reconfigure exim4-config
Beim Punkt 3 IP-Adressen, dan denen eingehende SMTP-Verbindungen erwartet werden entfernt hinten das ; ::1 . Übernehmt den Rest und startet exim4 wieder neu:

/etc/init.d/exim4 restart
Jetzt könnt Ihr auch Mails verschicken.

Viren mit ClamAV herausfiltern
Viren haben nichts auf unseren Servern und schon gar nichts in unseren Mailboxen zu suchen. Deswegen installieren wir einen Mailscanner, der damit beauftragt wird, die einströmenden Mails auf Viren zu prüfen. Viren können als normale Datei anhängen oder als gepackte Versionen. Deswegen muss unser Server auch in der Lage sein, gepackte Dateien zu prüfen. Wir benötigen dazu einen ganzen Bündel an neuen Files. Dazu müssen wir erstmal unsere sources.list erweitern:

nano /etc/apt/sources.list
Bei unseren Standard Repositories setzen wir dann noch die Source Reopsitiries dazu:

deb http://ftp.de.debian.org/debian/ wheezy main contrib non-free
deb-src http://ftp.de.debian.org/debian/ wheezy main contrib non-free

deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free
Wir frischen nun die Repositories auf:

apt-get update
Jetzt müssen wir uns insgesamt 3 Pakete bauen:

unrar-nonfree
lha
libclamunrar6

Falls noch nicht geschehen müssen noch die build-essentials installiert werden:

apt-get install build-essential
Danach legen wir uns ein Arbeitsverzeichnis an und wechslen dorthin:

mkdir work
cd work
Wir beginnen mit unrar:

mkdir unrar-nonfree
cd unrar-nonfree
apt-get build-dep unrar-nonfree
apt-get source -b unrar-nonfree
Das fertiggestellte Paket seht Ihr als *.deb Paket mit einem ls -la. Installiert das Paket entsprechend seiner Versionsnummer (ggf. anpassen):

dpkg -i unrar_4.1.4-1.deb
cd ..
Danach das Paket lha:

mkdir lha
cd lha
apt-get build-dep lha
apt-get source -b lha
Das fertiggestellte Paket seht Ihr als *.deb Paket mit einem ls -la. Installiert das Paket entsprechend seiner Versionsnummer (ggf. anpassen):

dpkg -i lha_.1.14i-10.deb
cd ..
Wir bleiben im work Verzeichnis und installieren die folgenden Pakete:

apt-get install clamav clamav-base clamav-daemon clamav-freshclam unzip
Fehlermeldungen wegen einer nicht aktuellen Virendatenbank ignorieren wir zunächst.
Danach bauen wir uns noch den libclamunrar6:

mkdir libclamunrar6
cd libclamunrar6
apt-get build-dep libclamunrar6
apt-get source -b libclamunrar6
Das fertiggestellte Paket seht Ihr als *.deb Paket mit einem ls -la. Installiert das Paket entsprechend seiner Versionsnummer (ggf. anpassen):

dpkg -i libclamunrar6_0.98.5.deb
Jetzt aktualisieren wir den ClamAV:

freshclam
Und nun starten wir den ClamAV durch:

/etc/init.d/clamav-daemon start

Variante A) getmail

Fügt nun in jeder getmail Konfig Eures getmail Users noch folgenden Abschnitt mit ein:

[filter-virus]
type = Filter_classifier
path = /usr/bin/clamdscan
arguments = („–stdout“, „–no-summary“, „-„)
exitcodes_drop = (1, )
Das filtert nun nach dem ClamAV erkannte Virenmails heraus. Viren die in gepackten Dateien enthalten sind werden auch nach aktuellen Stand der Datenbank aussortiert.

Wenn Ihr wollt könnt Ihr Euch von heise Security aus Testviren (harmlos!) zusenden lassen. Diese könnt Ihr unter folgender URL anfordern: http://www.heise.de/security/dienste…e=virendummies Lasst Euch hier eine normale Testmail und eine mit einem zip Paket zuschicken. Wenn alles klappt wird die Testmail Eure Mailbox nie erreichen, da diese kommentarlos gedropped (gelöscht) wird. Ob dies tatsächlich der Fall ist seht Ihr entweder in der .getmail/xyz.log , dort wird ausgegeben, welche Mail mit welchen Absender gedropped wurde. Ebenso seht Ihr unter /var/log/clamav/clamav.log, ob Viren gefunden wurden.

Variante B) procmail

Eine meiner Meinung nach etwas schönere Lösung gibt es über den Procmail mittels clamassassin. Das Script kann in den procmail integriert werden, markiert den Titel einer infizierten Mail mit einer entsprechenden Warnung und schiebt dies dann in einen eigenen Ordner. Auf diesem Weg werden keine Falschmeldungen einfach gelöscht und man hat die Mail nochmal vor Augen. Der User sollte diese dann tunlichst löschen, wenn er diese vielleicht noch mit einem Scanner auf seinem Rechner geprüft hat.

Als erstes installieren wir den clamassassin aus den Repositories:

apt-get install clamassassin
Dieser arbeitet out of the box allerdings anscheinend nur mit dem clamscan und nicht über den deutlich schnelleren Weg des clamdscan Deamons. Von daher müssen wir den clamassassin aus den Quellen nochmal neu kompilieren. Hierzu bitte die build-essentials installieren und ein Arbeitsverzeichnis erstellen, in das wir dann gleich wechseln:

cd /
mkdir work
apt-get install build-essential
cd /work
Jetzt laden wir uns die Quellen herunter

apt-get source clamassassin
und wechseln in das Hauptverzeichnis des Quellcodes:

cd clamassassin-1.2.4
Jetzt muss der Übersetzungsvorgang vorbereitet werden. Hierzu folgendes eingeben

./configure –bindir=/usr/bin –enable-clamdscan –enable-subject-rewrite=***INFECTED***
Damit haben wir Folgendes geregelt:

-Die übersetzte Datei wird nach /usr/bin installiert
-clamassassin wird clamdscan verwenden, wenn dieser läuft
-Die Mailüberschrift wird mit ***INFECTED*** markiert

Jetzt installieren wir das Script:

make install
Das sollte ohne Fehler durchlaufen.

In der ~/.procmailrc schreiben wir dann als erste Regeln (das muss ja auf alle eingehenden Mails angewandt werden) folgende:

0 fw
| /usr/bin/clamassassin

:0:
* ^X-Virus-Status: Yes
.virus/
Danach werden alle Mails, in denen ein Virus entdeckt wurde, in den Ordner virus in Eurer Mailbox erschoben. Prüft nach, ob der Clamassassin auch tatsächlich filtert, indem Ihr Euch eine Testmail schickt. Im Header dieser Mail solltet Ihr dann folgende Zeile relativ weit unten finden:
X-Virus-Checker-Version: clamassassin 1.2.4 with clamdscan…

virentest
Eine entdeckte Virentestmail

Spam tilgen mit Spamassassin
Jetzt widmen wir uns der schlimmsten Mailplage im Netz, dem Spam. Auch hier gibt es einige Möglichkeiten, gegen Spam anzutreten. Unter Linux hat sich derweilen als Filter das Programm Spammassassin etabliert. Wir wollen nun unseren Mailserver so konfigurieren, dass er eingehende Mails auf Spam untersucht und sollte er der Meinung sein, dass es sich um Spam handelt, dieser die Mails als Spam markiert und in einen eigenen Ordner Junk verschiebt. Der User hat dann die Möglichkeit, den Ordner weiterhin auf „Falsepositives“ zu untersuchen und löscht einfach den Rest raus. Hier sind zumindest die Mails vorsortiert und man geht dabei nicht das Risiko ein, dass vielleicht irgendwo noch erwünschte Mails einen generellen Löschvorgang zum Opfer fallen.

Zuerst installieren wir den Spamassassin:

apt-get install spamassassin
Dies liefert uns noch wietere zahlreiche Pakete hauptsächlich aus dem Bereich „perl“. Wenn die Pakete installiert sind, dann bauen wir erstmal eine einfache Grundkonfiguration auf, die natürlich noch durch viele weitere ausgeklügelte Filtermaßnahmen erweitert werden können. Wir editieren zuerst einmal die Datei

nano /etc/spamassassin/local.cf
Hier bitte bei folgende Zeilen das „#“ entfernen um diese zu aktivieren:

rewrite_header Subject *****SPAM*****

required_score 5.0

use_bayes 1

bayes_auto_learn 1

bayes_ignore_header X-Bogosity
bayes_ignore_header X-Spam-Flag
bayes_ignore_header X-Spam-Status
Unter die drei bayes_ignore Zeilen schreibt dann bitte noch folgende Zeilen:

bayes_ignore_header X-getmail-filter-classifier
Das verhindert, dass Headererweiterungen des Getmail irgendwann als Spam ausgewertet und gekennzeichnet werden.

Jetzt editiert bitte die Datei /etc/default/spamassassin

Dort stellt den Eintrag
ENABLED=0
auf

ENABLED=1
Dies stellt sicher, dass der Filter beim Booten des Servers automatisch gestartet wird. Da dieser eben nach der Installation nicht angefahren wird können wir den Spamfilter auch manuell scharf machen ohne erst dafür unseren Server neu zu starten:

/etc/init.d/spamassassin start
Damit das alles über den Getmail läuft, geht dann noch in Eure jeweilige Getmail Konfiguration unter .getmail und fügt zum Schluss der Konfigurationsdatei folgende Filterregel ein:

[filter]
type = Filter_external
path = /usr/bin/spamc
Über Procmail lassen wir nun noch nach der Headererweiterung *****SPAM***** suchen. Dazu fügen wir folgende Regel (am besten als erste Regel unterhalb der Virenregeln) in der ~/.procmailrc ein:

:0
* ^Subject:.******SPAM*****
.Junk/
Das sollte nun alle vom Spamassassin mit SPAM gekennzeichnete Mails in den Junk – Ordner schieben.

Hinweis: Da der Procmail als Platzhalter ein Sternchen * verwendet, ist es auch ratsam, die Subject Markierung auf ein anderes Symbol zu setzen, beispielsweise +++++SPAM+++++ . Ändert dies dann in der /etc/spamassassin/local.cf ab und in der .procmailrc. Danach natürlich den Spamassassin neu starten:

/etc/init.d/spamassassin restart
Woran sehe ich nun, ob der Spamfilter läuft? Hierzu schickt Euch einfach mal eine Testmail. Als Betreff dann gleich die entsprechende Änderung, die eben der Spamassassin einfügen würdee, wenn Spam erkannt werden würde (also beispielsweise +++++SPAM+++++). Das zeigt uns dann erstmal, ob der Procmail dann auch sauber filtern würde und die Mail in unseren Junk Ordner verschiebt. Wenn Ihr Eure Mail dann im Junk Ordner liegen habt, dann seht Euch den Quelltext an. Im Header der Mail solltet Ihr dann in etwa Folgendes lesen können:

X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on myserver
X-Spam-Level: *
X-Spam-Status: No, score=1.5 required=5.0 tests=AWL,SPF_FAIL autolearn=no
version=3.2.5
Hier seht Ihr, dass der Spamassassin aktiv war und seinen Score ( 1.5 ) eingetragen hat. Daneben steht der benötigte Score, damit die Mail als Spam markiert wird. Ihr könnt hier jetzt nur abwarten und zusehen, ob die Geschichte auf Dauer Euch in der Form genügt, oder Ihr noch ein paar „Goodies“ einbauen wollt.

Spamassassin prüfen
Der Dienst sollte regelmäßig daraufhin geprüft werden, ob er noch am Laufen ist. Wenn ein Mailserver rund um die Uhr aktiv ist, wäre es schlecht, wenn der Scanner im Hintergrund sich verabschieden sollte. Dazu bauen wir uns unter /usr/local/bin ein eigenes Script, das den Dienst spamd prüft, zur Not neu startet und dann eine E-Mail verschickt. Das Script sieht dann so aus:

nano /usr/local/bin/spamdcheck
Füllt den Inhalt wie folgt:

#!/bin/bash

#Spamd checkup for being running
#Skript by Gargi 2015

top -b -n 1 | grep /usr/sbin/spamd
spamd=$?
if [ $spamd = 1 ]; then
service spamassassin restart
echo „Spamd restarted cause it was not found active!“ > /var/log/spamdcheck.log
echo „“ >> /var/log/spamdcheck.log
/etc/init.d/spamassassin status >> /var/log/spamdcheck.log
mail -s „[System] Spamd recovered“ EURE @ MAILADRESSE < /var/log/spamdcheck.log exit 1 else echo "Spamd alive, nothing to be done" fi Speichert die Änderung und macht das Skript ausführbar: chmod +x /usr/local/bin/spamdcheck Dies lasst Ihr über den cron alle 5 Minuten beispielsweise laufen: crontab -e # Spamdcheck every 5 minutes */5 * * * * /usr/local/bin/spamdcheck > /dev/null

Spamassassin regelmäßig aktualisieren
Um den Spamassassin regelmäßig zu aktualisieren richten wir uns ein kleines Skript ein:

nano /usr/local/bin/sa-updater
Dies füllt mit folgenden Inhalt:

#!/bin/bash

/usr/bin/sa-update
date > /var/log/sa-update.log
echo „updated spamassassin“ >> /var/log/sa-update.log
Danach macht das Skript ausführbar:

chmod +x /usr/local/bin/sa-updater
Dies lasst Ihr über den cron ein mal am Tag beispielsweise laufen:

crontab -e
# Spamassassin Update 2 o clock in the morning
1 2 * * * /usr/local/bin/sa-updater > /dev/null

Scripterweiterungen
An der Stelle werde ich noch ein paar Konfigurationserweiterungen für Spamassassin, procmail und getmail bringen.

a) Razor und Pyzor anwenden
Eine Erweiterung für den Spamassassin stellt razor und pyzor dar. Via einer Checksumme werden Mails dann mit einer Datenbank verglichen. Wurde eine Spammail von mehreren Usern gemeldet, dann wird eine empfangene Spammail als solche auf Basis dieser Meldungen auf dem lokalen Server von Spamassassin erkannt.
Stellt zunächst einmal fest, dass die UDP Ports 24441 (in + out für pyzor) und TCP Port 2703 (out für razor) offen sind und passt gegebenfalls Eure Firewall an.

Jetzt installiert die beiden Pakete;

apt-get install razor pyzor
Die Spamassassin Konfiguration wird automatisch angepasst. Führt nun noch folgende Befehle aus, um den razor zu aktivieren:

razor-admin -d -home=/etc/razor -create
razor-admin -d -home=/etc/razor -register
Testet noch, ob pyzor nach außen funken kann:

pyzor ping
pyzor –homedir /etc/spamassassin discover
Ein public.pyzor.org:24441 (200, ‚OK‘) deutet darauf hin, dass die Kommunikation funktioniert. Ändert dann die /etc/spamassassin/local.cf und fügt unter den Bayes Bereich noch folgendes mit ein:

use_pyzor 1
pyzor_path /usr/bin/pyzor

use_razor2 1
razor_config /etc/razor/razor-agent.conf
Startet Euren Spamassassin neu:

/etc/init.d/spamassassin restart
Schaut Euch dann die gefilterten Spam Mails an. Wenn alles klappt, dann findet Ihr Pyzor und Razor Punkte entsprechend gelistet.
z.B. Razor:

2.4 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level
above 50%
[cf: 100]
0.4 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
[cf: 100]
1.7 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/)
z.B. Pyzor:

2.0 PYZOR_CHECK Listed in Pyzor (http://pyzor.sf.net/)

b) Mails mit speziellen Anhängen filtern
Manche Anhänge einer Mail sind potentielle Risiken. Hier kann man um die Aufmerksamkeit einwenig zu heben solche Mails gleich von Haus aus in einen speziellen Ordner (Bsp.: dangerous) schieben. Der User sieht dann gleich, dass man hier besondere Vorsicht walten lassen sollte im Umgang mit einer derartigen Mail. Der Code für die .procmailrc würde so aussehen:

:0 B:
* name=.*\.(vbs\“|wsf\“|exe\“|vbe\“|src\“|rar\“|dll\*)
.dangerous/
Dies könnt Ihr mit entsprechenden Erweiterungen noch versehen. Die Regel setzt am besten recht weit nach oben unter die Spamregel.

Apache SSL-Verschlüsselung aktivieren
Siehe z.B. : http://wiki.ubuntuusers.de/Apache/SSL

Zertifikat

Zertifikat erstellen:

# mkdir -p /etc/apache2/ssl
# openssl req -new -x509 -days 3650 -nodes -out /etc/apache2/ssl/apache.pem -keyout /etc/apache2/ssl/apache.pem
-> Country: DE
-> State: BW
-> Locality: Stuttgart
-> Organization: OWNCLOUD
-> Organizational Unit Name: Chief
-> Common Name: owncloud.example.org
Achtung: Hostname muss zum FQDN passen!
-> Email Address: user@example.org
Zertifikat verlinken und gegen Zugriff schützen:

# ln -sf /etc/apache2/ssl/apache.pem /etc/apache2/ssl//usr/bin/openssl x509 -noout -hash < /etc/apache2/ssl/apache.pem.0
# chmod 600 /etc/apache2/ssl/apache.pem
Testen: Zertifikat ansehen

# openssl x509 -in /etc/apache2/ssl/apache.pem -text
# openssl x509 -noout -in /etc/apache2/ssl/apache.pem -fingerprint -sha1
Apache für SSL konfigurieren

In vorhandene /etc/apache2/ports.conf eintragen:

Listen 443

# a2enmod ssl
# service apache2 force-reload
Neu anlegen: /etc/apache2/sites-available/ssl

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/apache.pem
DocumentRoot /var/www/owncloud

# a2ensite ssl
# service apache2 force-reload
Kommt bei a2ensite ssl eine Fehlermeldung, half es, in /etc/apache2/sites-available die Datei ssl nach ssl.conf umzubenennen.

Testen mit Firefox: https://owncloud.example.org (sollte nach Zertifikatsannahme tun)

SSL-Port evtl. Umstellen

Aus Sicherheitsgründen ist es evtl. sinnvoll einen Anderen Port als den für https üblichen (443) zu verwenden. Z.B. 1234:

Editiere: /etc/apache2/ports.conf (443 –> 1234, evtl. mehrmals)

# service apache force-reload
Editiere /etc/apache2/sites-available/ssl (443 –> 1234)

# service apache force-reload

Testen mit Firefox: https://owncloud.example.org:1234 (sollte nach Zertifikatsannahme tun)

SSL erzwingen mit Umleitung auf SSL-Port

Damit jeder User nur verschlüsselt mit dem Owncloud Server kommuniziert, wird eine angeforderte HTTP-Verbindung auf den Port 1234 mit HTTPS umgebogen (rewrite):

Siehe z.B. http://wiki.ubuntuusers.de/Apache/mod_rewrite

# a2enmod rewrite
# mkdir -p /var/run/apache2
# chown -R www-data /var/run/apache2
# service apache2 force-reload
Rewrite Rules in /etc/apache2/sites-available/default eintragen(Innerhalb ):

RewriteEngine on
RewriteRule ^/(.*)$ https://%{SERVER_NAME}$1:1234 [L,R]
RewriteLog "/var/log/apache2/rewrite.log"
RewriteLogLevel 2

NTP installieren

Den NTP Daemon konfigurieren:

Seit Januar 2010 bietet Hetzner drei Zeit-Server mit dem NTP-Protokoll an. Diese sind an drei unterschiedlichen Standorten untergebracht und haben folgende Adressen:

Um diese Zeit-Server unter Linux zu verwenden, muss der ntpd entsprechend konfiguriert werden.
Bei Debian Linux sind beispielsweise folgende drei Zeilen in die Datei

einzufügen bzw. die bestehenden mit „server“ beginnenden Zeilen zu ersetzen:

Optional können weitere öffentliche Server hinzugefügt werden:

Abschliessend muss der ntpd neu gestartet werden.

Läuft!