SVN Locks auslesen und als Tabelle im Web darstellen

In Subversion kann man via

svnadmin lslocks /srv/svn-parent/$REP_NAME/

die jeweils in einem Repository befindlichen Locks auf Dateien auslesen.

Das würde auf der Konsole dann so aussehen:

Pfad: /trunk/scaling.tdms_index
UUID-Marke: opaquelocktoken:a956dfad-8b20-43a1-84c0-789290b1c611
Eigentümer: USERNAME
Erstellt: 2016-08-17 20:10:56 +0200 (Mi, 17. Aug 2016)
Läuft ab:
Kommentar (1 Zeile):

...

Das ist weder übersichtlich, noch informativ, wenn man sich einen Überblick verschaffen möchte.

Daher gibt es hier zum Download eine kleine Webapplikation, die die Informationen schöner und übersichtlicher darstellt. Der Inhalt muss auf dem Subversion Server selbst in ein neues Verzeichnis des Apache Servers gelegt werden.

2016-08-30 15_45_01-Subversion Server - Locks

In der Anwendung kann man die Einträge über die Suche oben rechts filtern.

Das enthaltene PHP-Skript greift auf eine Datei zu, die die Ausgabe des o.g. Befehls enthält.

Um das Ausgabeformat anzupassen, muss folgendes Shell Skript als Cronjob regelmäßig laufen und die Ausgabe in das root Verzeichnis der Applikation legen:

[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”]


#!/bin/bash
# Das Programm dient dazu alle Locks mehrerer Repos auszugeben

# Deklarationen
SVN_SOURCE_DIR="/srv/svn-parent/"

# Alle Repositories auflisten und in LIST_REPS zwischenspeichern
find $SVN_SOURCE_DIR -maxdepth 1 -type d | sort > LIST_REPS

# 1 Zeile löschen (srv/svn-parent ist kein Repo)
sed -i 1D /root/LIST_REPS

# Schleife um Locks im jeweiligen Repostiory zu finden
for line in `cat /root/LIST_REPS`;do
REP=$line
REP_NAME=$(basename $REP)
# Locks ausgeben
echo [repository:$REP_NAME]
svnadmin lslocks /srv/svn-parent/$REP_NAME/
done

In der Crontab folgendes hinzufügen:

*/5 * * * * /root/show_locks > /var/www/locks/svn/locks_unsorted

Diese Lösung ist nicht unbedingt “sauber” programmiert, aber funktional…[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

Advertisements

Automatische Updates installieren unter Ubuntu/Debian

Genutzt wird das Tool unattended-upgrades, dessen Aufgabe es ist, die letzten (Sicherheits-) Patches automatisch einzuspielen.

Unattended Upgrades

Zum Installieren muss folgender Befehl ausgeführt werden:

apt-get install unattended-upgrades

Die Standardkonfiguration findet man unter /etc/apt/apt.conf.d/50unattended-upgrades

Die Konfiguration passt soweit, das Durchlesen kann aber nicht schaden, um es nach seinen Vorstellungen anzupassen.
Hier wird angepasst, welche Pakete installiert werden sollen:

// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};

Diese Zeile sollte auskommentiert/angepasst werden, um Benachrichtigungsmails zu erhalten:

Unattended-Upgrade::Mail "root";

Automatischer Aufruf durch /etc/apt/apt.conf.d/20auto-upgrades

Zum Aktivieren von unattended-upgrades, kann das Erstellen der apt Konfig Datei unter /etc/apt/apt.conf.d/20auto-upgrades genutzt werden.
Folgende Beispiel-Konfig kann genutzt werden:

// Do "apt-get update" automatically every n-days (0=disable)
APT::Periodic::Update-Package-Lists "1";

// Run the "unattended-upgrade" security upgrade script
// every n-days (0=disabled)
// Requires the package "unattended-upgrades" and will write
// a log in /var/log/unattended-upgrades
APT::Periodic::Unattended-Upgrade "1";

// Do "apt-get autoclean" every n-days (0=disable)
APT::Periodic::AutocleanInterval "7";

Um sicher zu sein, dass das Skript funktioniert, kann man es mit folgendem Befehl testen:
unattended-upgrade --debug --dry-run
Das sollte dann in etwa so ausssehen:

[...]
Option --dry-run given, *not* performing real actions
Packages that will be upgraded: libcurl3 libcurl3-gnutls
Writing dpkg log to '/var/log/unattended-upgrades/unattended-upgrades-dpkg_2016-09-09_08:33:07.332526.log'
Reading changelogs...
/usr/bin/dpkg --status-fd 9 --unpack --auto-deconfigure /var/cache/apt/archives/libcurl3-gnutls_7.35.0-1ubuntu2.9_amd64.deb /var/cache/apt/archives/libcurl3_7.35.0-1ubuntu2.9_amd64.deb
/usr/bin/dpkg --status-fd 11 --configure libcurl3-gnutls:amd64 libcurl3:amd64
All upgrades installed
InstCount=2 DelCount=0 BrokenCount=0

Damit die automatischen Updates auch ausgeführt werden, muss sichergestellt sein, dass das Cron Skript von apt auch aktiviert ist.
ls -la /etc/cron.daily/ zeigt die Cron Skripte an, die täglich durchgeführt werden. Das apt Skript muss vorhanden sein. Wenn es die Endung “.disabled” hat, einfach umbenennen mv /etc/cron.daily/apt.disabled /etc/cron.daily/apt

Jira Re-Indexing failed: failed to locate current segments_N file

Der Jira Index wurde beschädigt und kann nicht wiederhergestellt werden.

The issue index is inconsistent with the database state. Database has (5681) issues but the index has (0) issues.

Die Datenbank an sich ist noch intakt, jedoch wurde der Jira eigene Index zerstört.

Eine Neuindexierung über System – Advanced – Indexing schlägt fehl.

Im Catalina Log taucht folgende Meldung auf:
tail /opt/atlassian/jira/logs/catalina.out -f

[fusion_builder_container hundred_percent="yes" overflow="visible"][fusion_builder_row][fusion_builder_column type="1_1" background_position="left top" background_color="" border_size="" border_color="" border_style="solid" spacing="yes" background_image="" background_repeat="no-repeat" padding="" margin_top="0px" margin_bottom="0px" class="" id="" animation_type="" animation_speed="0.3" animation_direction="left" hide_on_mobile="no" center_content="no" min_height="none"][...]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at com.atlassian.jira.task.ForkedThreadExecutor$ForkedRunnableDecorator.run(ForkedThreadExecutor.java:216)
        at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.lucene.index.CorruptIndexException: failed to locate current segments_N file
        at org.apache.lucene.index.IndexFileDeleter.(IndexFileDeleter.java:219)
        at org.apache.lucene.index.IndexWriter.(IndexWriter.java:1173)
        at com.atlassian.jira.index.DefaultIndexEngine.clean(DefaultIndexEngine.java:176)
        ... 28 more

Zum Beheben, kann man Jira zwingen, den Index neu aufzubauen.
Dazu den Dienst stoppen, alle vorhandenen Indexdateien löschen/umbenennen und Jira neu starten.
service jira stop
cd /var/atlassian/application-data/jira/caches
mv indexes indexes_old
mkdir indexes
chown jira:jira indexes -R
service jira start

Achtung: Es werden bis zu Neuindexierung keinerlei Issues angezeigt!
Dann kann man die Neuindexierung im Menü starten.
jira-reindexing

[...]
JiraTaskExectionThread-1 INFO braun 628x131x1 7gi885 172.30.18.99,127.0.0.1 /secure/admin/IndexReIndex.jspa [c.a.j.w.a.admin.index.IndexAdminImpl] Re-indexing started
JiraTaskExectionThread-1 INFO braun 628x131x1 7gi885 172.30.18.99,127.0.0.1 /secure/admin/IndexReIndex.jspa [c.a.j.util.index.CompositeIndexLifecycleManager] Reindex All starting...
JiraTaskExectionThread-1 INFO braun 628x131x1 7gi885 172.30.18.99,127.0.0.1 /secure/admin/IndexReIndex.jspa [c.a.j.w.a.admin.index.IndexAdminImpl] Re-indexing is 0% complete. Current index: Issue
JiraTaskExectionThread-1 INFO braun 628x131x1 7gi885 172.30.18.99,127.0.0.1 /secure/admin/IndexReIndex.jspa [c.a.j.issue.index.DefaultIndexManager] ReindexAll in foreground: {indexIssues=true, indexChangeHistory=true, indexComments=true, indexWorklogs=true, forceReloadFromDatabase=false}
IssueIndexer:thread-7 INFO braun 628x131x1 7gi885 172.30.18.99,127.0.0.1 /secure/admin/IndexReIndex.jspa [c.a.j.w.a.admin.index.IndexAdminImpl] Re-indexing is 1% complete. Current index: Issue
[...]
JiraTaskExectionThread-1 INFO braun 628x131x1 7gi885 172.30.18.99,127.0.0.1 /secure/admin/IndexReIndex.jspa [c.a.j.w.a.admin.index.IndexAdminImpl] Re-indexing is 100% complete. Current index: PortalPage
JiraTaskExectionThread-1 INFO braun 628x131x1 7gi885 172.30.18.99,127.0.0.1 /secure/admin/IndexReIndex.jspa [c.a.j.util.index.CompositeIndexLifecycleManager] Reindex took: 390ms. Indexer: SharedEntityIndexManager: paths: []
JiraTaskExectionThread-1 INFO braun 628x131x1 7gi885 172.30.18.99,127.0.0.1 /secure/admin/IndexReIndex.jspa [c.a.j.w.a.admin.index.IndexAdminImpl] Re-indexing is 100% complete. Current index:
JiraTaskExectionThread-1 INFO braun 628x131x1 7gi885 172.30.18.99,127.0.0.1 /secure/admin/IndexReIndex.jspa [c.a.j.util.index.CompositeIndexLifecycleManager] Reindex All complete. Total time: 95451ms. Reindex run: 27

[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

Amavis-Spam-Virenfilter

Diese Anleitung erweitert den Postfix-Mailserver um Virenscanner und Spamfilter sowie automatische Mailfilter.

  • amavisd-new (Interaktion zwischen MTA und Virenscanner/Spamfilter )
  • clamav-daemon (Virenscanner )
  • spamassassin (Spamfilter )
  • razor (Online-Spamdatenbank )
  • pyzor (Online-Spamdatenbank )

AMaViS steht für A MAil Virus Scanner und ist ein serverseitiger Virenscanner, der auf Unix/Linux Mail-Servern zum Einsatz kommt. Mittlerweile wurde die Funktion um einen Spamfilter erweitert. AMaViS ist kein Virenscanner im eigentlichen Sinne, sondern eine Software, die dazu entwickelt wurde, Virenscanner in Mailserver einzubinden. Sie bietet eine Standardschnittstelle zwischen den Mail Transfer Agents (MTA) und den Contentfiltern, damit die Hersteller von Mailservern und Antivirenprogrammen nicht ständig neue Schnittstellen entwickeln müssen.

ClamAV (Clam AntiVirus) ist ein unter der GNU General Public License stehendes Virenschutzprogramm – also eine Anwendung gegen Schädlinge wie etwa Viren – mit einem Phishing-Filter, welcher häufig auf E-Mail-Servern zur Ausfilterung sogenannter Computerwürmer und Phishing-E-Mails zum Einsatz kommt.

SpamAssassin ist ein weitverbreitetes und ausgezeichnetes Filterprogramm, mit dem unerwünschte E-Mails (Spam) automatisch aussortiert werden können. SpamAssassin ist als freie Software unter den Bedingungen der Version 2 der Apache-Lizenz freigegeben.

Quelle: Wikipedia

 

Pakete installieren

apt-get install amavisd-new clamav-daemon spamassassin razor pyzor

Clamav-Daemon

Clamav erfordert normalerweise keine Anpassungen. Der Daemon ist gestartet, und Virensignaturen werden täglich aktualisiert. Damit Amavis und Clamav-Daemon zusammenarbeiten, muss der Benutzer clamav der Gruppe amavis über die Verwaltung der Benutzer und Gruppen zugeordnet werden. Dies erfolgt über die Befehle:

adduser clamav amavis
service clamav-daemon restart

Amavis

Zur Aktivierung müssen die jweiligen Bereiche in/etc/amavis/conf.d/15-content_filter_mode auskommentiert werden:

@bypass_virus_checks_maps = (
%bypass_virus_checks, @bypass_virus_checks_acl, $bypass_virus_checks_re);
@bypass_spam_checks_maps = (
%bypass_spam_checks, @bypass_spam_checks_acl, $bypass_spam_checks_re);

Wer nur auf Spam oder Viren prüfen will, lässt die Kommentarzeichen vor dem Block, den er nicht benötigt, stehen.

Spamassassin

Amavis greift direkt auf die spamassassin-Bibliotheken zu und benötigt keinen laufenden spamd Demon. Von daher ist keine weitere Konfiguration von spamassassin notwendig.

su - amavis -s /bin/bash
razor-admin -create
razor-admin -register
pyzor discover
exit

Postfix

Postfix muss nun so eingestellt werden, dass eintreffende E-Mails durch den Amavis Filter geschickt werden, sodass sie von Spamassassin kontrolliert werden können.

In die Datei /etc/postfix/main.cf wird folgende Zeile eingefügt:

content_filter=smtp-amavis:[127.0.0.1]:10024

Die Konfigurationsdatei /etc/postfix/master.cf wird um folgende Zeilen erweitert:

smtp-amavis unix - - - - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20

127.0.0.1:10025 inet n - - - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks

Unmittelbar hinter der Zeile mit dem Dienst pickup:

-o content_filter=
-o receive_override_options=no_header_body_checks

service postfix restart

Spammails mit ***SPAM*** kennzeichnen

In der Standardeinstellung filtert Amavis erkannten Spam einfach weg. Möglicherweise möchte man jedoch seinen Spam lieber selber nochmal auf falsche Treffer überprüfen. Dafür bietet Amavis die Möglichkeit, Spam in der Betreffszeile zu kennzeichnen. Außerdem kann man verschiedene Kopfzeilen, die mit X-Spam beginnen, einfügen lassen, wo Amavis Informationen über den Spamwert und die angeschlagenen Tests hinterlegt.

Dazu muss man in /etc/amavis/conf.d/20-debian_defaults folgende Variablen den eigenen Bedürfnissen anpassen:

  • $sa_tag_level_deflt: Mail, die höher als dieser Wert eingestuft wird, erhält die oben erwähnten X-Spam-Kopfzeilen.
  • $sa_tag2_level_deflt: Ab diesem Wert wird die Mail als Spam eingestuft, eine entsprechende Kopfzeile eingefügt und der Betreff mit dem Präfix ***SPAM*** versehen.
  • $sa_kill_level_deflt: Dieser Wert legt fest, ab wann die Mail so eindeutig als Spam eingestuft wird, dass sie sofort vernichtet wird.

Folgende Einstellungen haben sich in der Praxis als sinnvoll erwiesen:

$sa_tag_level_deflt = -999;
$sa_tag2_level_deflt = 5;
$sa_kill_level_deflt = 20;

Zum Übernehmen der Änderungen muss Amavis neu gestartet werden

service amavis restart

Wie soll Amavis mit SPAM, Viren und Anhängen umgehen?

Sobald unerwünschte Mails gefunden werden, hat AMaViS die Fähigkeit, sie unter Quarantäne zu stellen, zu verwerfen und / oder die unerwünschte Mail passieren lassen und zu zustellen.
Dabei können nützliche Informationen im Header platziert werden.

Der kritische Punkt von AMaViS Konfiguration ist zu entscheiden, welche Maßnahmen ergriffen werden sollten, wenn eine unerwünschte Nachricht gefunden wird.

Einstellungen, die mit Viren umgehen, verboten Anhängen und Bad Header:

$final_virus_destiny =
$final_banned_destiny =
$final_bad_header_destiny =

$virus_quarantine_to =
$banned_quarantine_to =
$bad_header_quarantine_to =

Mögliche Einstellungen für $final_*_destiny sind: D_PASS, D_BOUNCE, D_REJECT and D_DISCARD.

D_PASS:

E-Mails werden an die Empfänger weitergeben , unabhängig von schlechten Inhalten. Ist Quarantäne konfiguriert ist, wird eine Kopie der E-Mail dorthin gelegt, wenn nicht, erhält aber mindestens der Empfänger die E-Mail.

D_BOUNCE:

Die Mail wird nicht zugestellt und der Absender erhält eine Unzustellbarkeitsnachricht. Dies aber nicht, sollten Viren gefunden werden. Ist Quarantäne konfiguriert, geht die Mail dort hin. Ansonsten ist sie verloren.

D_REJECT:

Die Mail wird nicht zugestellt. AMaViS schickt die typischen 55x Antworten auf die Upstream-MTA und dieser kann eine Mitteilung über die Zurückweisung an den Absender senden. Die Infos sind aber nicht so aussagekräftig wie beim Bounce.

D_DISCARD:

Mail wird nicht zugestellt und der Absender nicht informiert. Eine Kopie wandert in die Quarantäne, wenn sie konfiguriert ist.

Anpassungen unter Ubuntu

Mails werden immer geblockt, auch wenn andere Einstellungen vorgenommen sind

Die Direktiven

$final_virus_destiny =
$final_banned_destiny =
$final_bad_header_destiny =
$final_spam_destiny =

greifen nicht, wenn der Server unter Ubuntu läuft. Daher muss die Datei /etc/amavis/conf.d/21-ubuntu_defaults dahingehend angepasst werden:

$final_virus_destiny = D_DISCARD; # (data not lost, see virus quarantine)
$final_banned_destiny = D_BOUNCE; # D_REJECT when front-end MTA
$final_spam_destiny = D_PASS;
$final_bad_header_destiny = D_PASS; # False-positive prone (for spam)

Spam im Betreff kennzeichnen

Damit der Header umbenannt werden kann und die X-Spam-Flag, X-Spam-Score, X-Spam-Level, X-Spam-Status Tags eingefügt werden, muss die Domain übereinstimmen.

Sollte diese nicht stimmen, werden keine Änderungen vorgenommen.

head -n 1 /etc/mailname

muss die Domain ergeben. Wenn die Ausgabe mail.example.org o.ä. ausgibt, ist dies der Bug in Amavis.

Die einfachste Lösung ist in /etc/amavis/conf.d/05-domain_id

chomp($mydomain = `head -n 1 /etc/mailname`);

zu ändern in

$mydomain = "example.com";

Infomail bei Spam oder Virus

In der Datei /etc/amavis/conf.d/21-ubuntu_defaults die Zeilen hinzufügen oder anpassen, damit bei einem Spam oder Virenfund eine Infomail an den Admin geht:

$virus_admin = "postmaster@$mydomain";

$spam_admin = "postmaster@$mydomain";

Soll  bei einem Virenfund ebenfalls der Empänger benachrichtigt werden so ist folgendes zu ergänzen:

$warnvirusrecip = 1;

Testen des Mailservers

Zum Testen, wie das Konstrukt mit Mails umgeht, eignet sich bspw. der Online Dienst von byteplant.

Mailadresse eingeben, bestätigen und schauen, was der Server tut:

amavis

SquidGuard Web Filter Plugin für Squid3

squidGuard ist ein Internetfilter, der in Verbindung mit dem Web-Cache-Proxy Squid über den Redirector-Mechanismus eingesetzt werden kann. SquidGuard ist freie Software und unter der GNU General Public License lizenziert.

SquidGuard kann nicht gegen Viren oder andere Malware eingesetzt werden. Surft ein Benutzer eine Website an, so schickt Squid den Seitenaufruf an squidGuard zur Überprüfung. Findet squidGuard die Domain oder die URL, so wird der Benutzer auf eine Seite umgelenkt, die ihm sagt, dass er keinen Zugriff auf diese Seite hat.

SquidGuard wird über eine zentrale, textbasierte Datei konfiguriert. Hier wird hinterlegt, welche Ziele wann für wen gesperrt sind und welche Seite statt der blockierten angezeigt werden soll. Die Informationen über die gesperrten Domänen und URLs sind dabei üblicherweise in verschiedene Klassen unterteilt. Neben dem Einsatz von Domain- oder URL-Listen kann der Zugang auch mit Hilfe von Regulären Ausdrücken verhindert werden. Hier kann die Fehlerquote sehr hoch sein, also mehr gesperrt werden als notwendig. Wird zum Beispiel jede URL gesperrt, die das Wort sex enthält, werden auch Seiten über das Staatsexamen nicht angezeigt. Es ist möglich, weiße Listen zu hinterlegen, auf deren Einträge stets zugegriffen werden kann.

Der squidGuard-Administrator kann die Zugriffsbedingungen sehr differenziert gestalten. Der Zugang kann je nach Benutzer, Uhrzeit, Ursprungsseite und anderen Kriterien erlaubt oder verweigert werden.
Quelle: Wikipedia

Squidguard installieren

apt-get install squidguard

Blacklist installieren

Blacklists gibt es von diversen Anbietern. Teilweise kostenlos, teilweise kostenpflichtig.

  1. MESD blacklists (kostenlos).
  2. Shalla’s Blacklists (kostenlos für private Nutzung).
  3. Urlblacklist (kommerziell)

Nachfolgend wird die MESD Blacklist genutzt.

Download der Liste, entpacken und kopieren in den Datenbankpfad von Squidguard:

wget http://squidguard.mesd.k12.or.us/blacklists.tgz
tar -zxvf blacklists.tgz
cd blacklists/
cp -avr * /var/lib/squidguard/db/

Erstellen der Datenbank:

cd /var/lib/squidguard/db/porn
squidGuard -b -C domains
squidGuard -b -C urls

Oder direkt für alle Kategorien:

squidGuard -C all

Squid zum Lesen der Dateien berechtigen:

chown proxy:proxy -R /var/lib/squidguard/db/

Squid konfigurieren

URL Rewriter definieren (/etc/squid3/squid.conf):

url_rewrite_program /usr/bin/squidGuard

Squidguard konfigurieren

/etc/squidguard/squidGuard.conf öffnen und anpassen

dbhome /var/lib/squidguard/db
logdir /var/log/squidguard

src clients {
ip 172.30.0.0/16
}

dest good {
}

dest local {
}

dest porn {
domainlist porn/domains
urllist porn/urls
redirect http://proxyserver/blocked.html?clientaddr=%a&clientname=%n&clientuser=%i&clientgroup=%s&targetgr$
}

acl {
clients {
pass good !in-addr !porn any
} else {
pass any
}

default {
pass local none
redirect http://proxyserver/blocked.hmtl?clientaddr=%a&clientname=%n&clientuser=%i&clientgroup=%s&$
}
}

Die Seite für den Redirect anlegen und je nach Wünschen befüllen:

<html>
	<head>
		<title>URL Blocked</title>
	</head>
	<body>
		<h1>URL Blocked</h1>
		<p>Access to this site / url has been blocked.</p>
	</body>
</head>
</html>

Dienst neu starten
service squid3 restart

Installation und Konfiguration von DKIM mit Postfix unter Ubuntu

Einleitung

Die Einstufung von E-Mails als Spam kann diverse Gründe haben, wird aber meistens durch einen der folgenden Punkte verursacht:

  • Der Server ist ein Open Relay
  • Der Absender oder die Server IP steht auf einer Blacklist
  • Der Server hat keinen FQDN und/oder PTR Eintrag
  • Der Sender Policy Framework (SPF) DNS Eintrag fehlt oder ist fehlerhaft konfiguriert
  • Die Implementierung von DomainKeys Identified Mail (DKIM) fehlt oder ist nicht korrekt aufgesetzt

Die Spamfilter testen auf einige Basis Eigenschaften. Das Erfüllen dieser Eigenschaften ist sehr wichtig für gut konfigurierte Mailserver.
Im Folgenden wird die Einrichtung von DKIM beschrieben. Genutzt wird dazu “OpenDKIM”, eine OpenSource Implementierung des “DKIM sender authentication system”.

DKIM

DKIM ist ein Internet Standard, der es ermöglicht, Personen oder Unternehmen und deren Domainnamen einer E-Mail Nachricht zu verknüpfen. DKIM funktioniert über eine asymmetrische Verschlüsselung. Der MTA signiert jede ausgehende Mail mit seinem privaten Schlüssel. Der Empfänger erhält den öffentlichen Schlüssel vom DNS des Absenders. Er verifiziert anschließend, ob es keine Veränderungen im Mail Body und einigen der Header Feldern seit der Signierung gibt.

Installation von OpenDKIM

Vor der Installation sollte ein Systemupdate erfolgen und das Paket anschließend installiert werden.
apt-get update && apt-get upgrade
apt-get install opendkim opendkim-tools

Konfiguration von OpenDKIM

Zur Konfiguration müssen einige Dateien angepasst oder erstellt werden.
Angefangen mit der Hauptkonfigurationsdatei:

nano /etc/opendkim.conf

Hier sollten folgende Dinge an die Konfiguration angehängt werden:

AutoRestart Yes
AutoRestartRate 10/1h
UMask 002
Syslog yes
SyslogSuccess Yes
LogWhy Yes
Canonicalization relaxed/simple
ExternalIgnoreList refile:/etc/opendkim/TrustedHosts
InternalHosts refile:/etc/opendkim/TrustedHosts
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
Mode sv
PidFile /var/run/opendkim/opendkim.pid
SignatureAlgorithm rsa-sha256
UserID opendkim:opendkim
Socket inet:12301@localhost

Erklärung

  • AutoRestart: Startet den Filter bei Fehlern automatisch neu
  • AutoRestartRate: Gibt an, wie oft der Filter maximal neugestartet werden darf. Sollte ein Neustart öfter erfolgen, so wird der Filter beendet; 10/1h – 10 maximal 10 Neustarts pro Stunde sind erlaubt.
  • UMask: Erteilt vollständige Zugriffsrechte für die Gruppe, welche durch die UserID definiert ist. Andere Benutzer dürfen die Dateien ausführen und lesen. In diesem Fall wird das Erstellen und Bearbeiten der Pidfile erlaubt.
  • Syslog, SyslogSuccess, *LogWhy: Erlauben detailliertes Logging via Syslog.
  • Canonicalization: Legt die Methode der Kanonisierung beim Signieren fest. Die “simple” MEthode erlaubt fast keine Modifikationen, wohingegen die “relaxed” Methode kleinere Änderungen erlaubt wie das Entfernen von Leerzeichen; relaxed/simple – Header: relaxed, Body: simple
  • ExternalIgnoreList: Legt Hosts fest, die Mails mit der Domain durch diesen Server versenden dürfen, ohne, dass Anmeldedaten mitgegeben werden müssen.
  • InternalHosts: Legt eine Liste von Hosts fest, dessen Mail nicht verifiziert aber signiert werden soll.
  • KeyTable: Ordnet maps key names den signing keys zu
  • SigningTable: Liste der Signaturen, die auf die Mail angewendet werden soll, basierend auf dem Header Feld “From”
  • Mode: Legt den Modus der Ausführung fest. In diesem Fall arbeitet der milter als Signierer (s) und Verifizierer (v)
  • PidFile: Pfad zur Pidfile, welche die Nummer des Prozesses beinhaltet
  • SignatureAlgorithm: Algorithmus, der beim Erstellen der Signaturen verwendet wird.
  • UserID: ID (Benutzer und Gruppe) unter welcher der Prozess läuft
  • Socket: Der Milter hört auf diesen Port, Postfix sendet Mails an opendkim zur Signierung und Verifikation an diesen Socket. 12301@localhost TCP Socket, der auf Localhost, Port 12301 hört.

Mehr Infos zu den Einstellungen und Möglichkeiten gibt es hier.

Verbinden des Milters zu Postfix:

nano /etc/default/opendkim

Die folgende Zeile muss eingefügt und evtl. angepasst werden, sollte ein anderer Port genutzt worden sein:

SOCKET="inet:12301@localhost"

Postfix mitteilen, dass er den Milter nutzen soll:

nano /etc/postfix/main.cf

milter_protocol = 2
milter_default_action = accept
smtpd_milters = inet:localhost:12301
non_smtpd_milters = inet:localhost:12301

Oder so, falls schon andere Filter vorhanden sind (SpamAssasin etc.)

smtpd_milters = unix:/spamass/spamass.sock, inet:localhost:12301
non_smtpd_milters = unix:/spamass/spamass.sock, inet:localhost:12301

Nun müssen die Ordner erstellt werden, die die oben definierten Hosts, Tabellen und Schlüssel beinhalten:

mkdir /etc/opendkim
mkdir /etc/opendkim/keys

Hosts defninieren:

nano /etc/opendkim/TrustedHosts

Diese Datei gilt für die Richlinie ExternalIgnoreList und InternalHosts. Mails dieser Hosts, Domänen und IP Adressen wird vertraut und werden signiert.

127.0.0.1
localhost
192.168.0.1/24

*.tj-braun.de

Keytable anlegen:

nano /etc/opendkim/KeyTable

Diese Tabelle enthät das “Selector/Domain” Paar und den Pfad zum privaten Schlüssel. Jeder String kann als Selector genutzt werden. Hier ist es “mail”

mail._domainkey.tj-braun.de tj-braun.de:mail:/etc/opendkim/keys/tj-braun.de/mail.private

SigningTable anlegen:

nano /etc/opendkim/SigningTable

Diese Datei wird für die Definition der Domains/E-Mails und deren Selektoren verwendet.

*@tj-braun.de mail._domainkey.tj-braun.de

Privaten und öffentlichen Schlüssel generieren

Wechsel ins Schlüsselverzeichnis:

cd /etc/opendkim/keys

Ordner für die Domain erstellen.

mkdir tj-braun.de
cd tj-braun.de/

Schlüssel generieren

opendkim-genkey -s mail -d tj-braun.de

-s definiert der Selektor und -d die Domain. Es werden 2 Dateien erstellt. mail.private enthält den privaten Schlüssel und mail.txt den öffentlich Schlüssel.

Öffentlichen Schlüssel zum DNS hinzufügen

Inhalt der mail.txt

mail._domainkey IN TXT ( "v=DKIM1; k=rsa; "
"p=MIGfMA0GCSqGSIb3DQEBAQU...KPofdPZnZjpk5kQ5+PdomLzxesY2NYOG---- DKIM key mail for tj-braun.de

Mit diesem Schlüssel erstellt man nun einen TXT Record  im DNS.

Name: mail._domainkey
Text: "v=DKIM1; k=rsa; " "p=MIGfMA0GCSqGSIb3DQEBAQU...KPofdPZnZjpk5kQ5+PdomLzxesY2NYOG"

Nameserver

Neustart von Postfix und OpenDKIM

service postfix restart
service opendkim restart

Testen

1. Leere Mail an check-auth@verifier.port25.com, dort sollte “DKIM check: pass” stehen, wenn alles funktioniert.

==========================================================
Summary of Results
==========================================================
SPF check: pass
DomainKeys check: neutral
DKIM check: pass
Sender-ID check: pass
SpamAssassin check: ham

2. Mail an eine GMail Adresse schicken. Dort kann man sich den Header anschauen, der so aussehen sollte:

Received-SPF: pass (google.com: domain of tj-braun.de designates 81.169.183.170 as permitted sender) client-ip=81.169.183.170;
Authentication-Results: mx.google.com;
dkim=pass header.i=@tj-braun.de;
spf=pass (google.com: domain of tj-braun.de designates 81.169.183.170 as permitted sender) smtp.mailfrom=tj-braun.de

3. Syslog

opendkim[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”][12772]: 2F49015260E04: DKIM-Signature field added (s=mail, d=tj-braun.de)[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

Google Drive Proxy Authentification Bypass Squid

Google Drive kann zwar mit Proxys umgehen, jedoch nicht mit einer Authentifizierung durch den Proxy.
Dementsprechend müssen diverse URLs durchgelassen werden, ohne, dass eine Authentifizierung erfolgt.
Die einzelnen URLs findet man direkt bei Google.

Die Squid Konfiguration muss folgendermaßen angepasst werden:

# Seiten, die keine Authentifizierung benötigen
acl whitelist dstdomain .google.com .googleusercontent.com .googleapis.com
acl http proto http
acl port_80 port 80
acl port_443 port 443

# Whitelist Seiten ohne Authentifizierung freigeben
http_access allow http port_80 whitelist
http_access allow CONNECT port_443 whitelist