NO_PUBKEY

März 23rd, 2011 von chems

Immer wieder erhalte ich die Anfrage, wie man bei einer neuen APT-Quelle die Signatur hinzufügt, da oft folgender Fehler auftritt:

1
2
W: GPG error: http://download.bitdefender.com bitdefender Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY A373FB480EC4FE05
W: Probieren Sie »apt-get update«, um diese Probleme zu korrigieren.

In diesem Falle wäre es am einfachsten, den Schlüssel hinzuzufügen. Zum Beispiel damit:

1
apt-key adv --recv-keys --keyserver keyserver.ubuntu.com A373FB480EC4FE05

Dies liefert die folgende Ausgabe

1
2
3
4
5
6
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --recv-keys --keyserver keyserver.ubuntu.com A373FB480EC4FE05
gpg: fordere Schlüssel 0EC4FE05 von hkp-Server keyserver.ubuntu.com an
gpg: Schlüssel 0EC4FE05: Öffentlicher Schlüssel "BitDefender Packages <packages@bitdefender.com>" importiert
gpg: keine uneingeschränkt vertrauenswürdige Schlüssel gefunden
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                              importiert: 1

Schon kann man wieder updaten.

Geschrieben in Server, PC und Netzwerkgeschichten | 1 Kommentar »

Mac-Adresse unter Ubuntu & Debian einfach manipulieren

Februar 26th, 2011 von chems

Manchmal kommt es vor, dass die Mac-Adresse einer Netzwerkschnittstelle nicht wie gewünscht ist.

Dies passiert beispielsweise wenn man zwei Karten (oder mehr) über Bonding zusammenschaltet. Oft passiert es, dass Beispielsweise „eth1“ danach „eth1_rename_ren“ heißt, da es ein Problem mit doppelter Mac-Adresse gibt.

Um dieses Problem zu lösen, sollte man dann einfach die Mac-Adresse ändern. Dies geht mit dem Paket „macchanger“.

Hier die wichtigsten Aufrufe:

1
macchanger -r eth0

eth0 bekommt eine zufällig generierte MAC-Adresse

1
macchanger --mac=6b:fd:10:37:d2:34 eth1

Die Mac-Adresse „6b:fd:10:37:d2:34“ wird der Schnittstelle eth1 zugewiesen

1
macchanger --endding eth2

eth2 bekommt eine neue Mac-Adresse. es wird jedoch der herstellerspezifische Teil beibehalten, und nur das Ende der Adresse geändert. Dies eignet sich beispielsweise auch um einen DHCP-Server zu testen.

6b:fd:10:37:d2:34

 

 

 

Geschrieben in Server, PC und Netzwerkgeschichten | Keine Kommentare »

Debian und Ubuntu (etc): libept0 deinstallieren?

September 12th, 2010 von chems

Ich wunderte mich seit einer Woche, warum mir aptitude vorschlug, libept0 zu deinstallieren. Ich entschied, erst einmal das Paket beizubehalten, und verfolgte dies erstmal nicht weiter.

Da diese Meldung jedoch noch immer existiert, habe ich mich jetzt näher damit befasst.

Als erstes fragte ich mich: Für was gibt es das Paket „libept0“ (war mir bisher noch nicht aufgefallen)

High-Level-Bibliothek, um Informationen von Debian-Paketen zu verwalten

Die Bibliothek definiert ein sehr minimales Rahmenwerk, in dem viele Datenquellen von Debian-Paketen eingefügt und gemeinsam abgefragt werden können.

Die Bibliothek enthält vier Datenquellen:

* APT: Zugriff auf die APT-Datenbank
* Debtags: Zugriff auf die Tag-Informationen von Debtags
* Popcon: Zugriff auf die Paketwertungen von Popcon
* Der Xapian-Index, gebaut von apt-xapian-index

Ok, diese Erklärung lieferte erst einmal einen Hinweis worum es sich handelt, erklärte mir aber noch nicht warum ich es deinstallieren soll. Ein näheres hinschauen, sowie ein Ubuntu-Forum (Wichtige Beiträge: #1 & #2)brachte die Erklärung:

libept0 wurde durch libept1 ersetzt
Alles klar, keine Fragen 🙂

High-Level-Bibliothek, um Informationen von Debian-Paketen zu verwalten

Die Bibliothek definiert ein sehr minimales Rahmenwerk, in dem viele Datenquellen von Debian-Paketen eingefügt und gemeinsam abgefragt werden können.

Die Bibliothek enthält vier Datenquellen:

 * APT: Zugriff auf die APT-Datenbank
 * Debtags: Zugriff auf die Tag-Informationen von Debtags
 * Popcon: Zugriff auf die Paketwertungen von Popcon
 * Der Xapian-Index, gebaut von apt-xapian-index

Geschrieben in Server, PC und Netzwerkgeschichten | 1 Kommentar »

Selektiv E-Mail-Adressen sperren

April 7th, 2010 von chems

In Ausnahmefällen kann es dazu kommen, dass man eine Absender-Adresse für E-Mails sperren möchte, damit man von einer Person keine Mails mehr empfängt. Interessant ist dies vor Allem, wenn der Absender eine Standard-Benachrichtigung erhält, dass die E-Mail leider nicht zugestellt werden konnte (Fehler 550).

Für dieses Kurztutorial erkläre ich die Vorgehensweise für den Postfix-Server, welcher sehr oft in Linux-Umgebungen eingesetzt wird. Grundlage ist hier ein Debian, deshalb könnten eventuell bei anderen Distributionen Verzeichnisse unterschiedlich sein.

1. Postfix – Konfiguration ergänzen.

Die Datei main.cf im Verzeichnis /etc/postfix enthält normalerweise einen folgenden Block:

1
2
3
4
5
6
7
8
9
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
                               reject_unknown_recipient_domain,
                               permit_mynetworks,
                               permit_sasl_authenticated,
                               reject_unauth_destination,
                               reject_unlisted_recipient,
                               check_policy_service inet:127.0.0.1:12525,
                               check_policy_service inet:127.0.0.1:10023,
                               permit

Diesen erweitert man um den Inhalt „check_sender_access hash:/etc/postfix/sender_access,„. Dies sieht dann danach folgendermaßen aus:

1
2
3
4
5
6
7
8
9
10
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
                               reject_unknown_recipient_domain,
                               permit_mynetworks,
                               permit_sasl_authenticated,
                               reject_unauth_destination,
                               reject_unlisted_recipient,
                               check_policy_service inet:127.0.0.1:12525,
                               check_policy_service inet:127.0.0.1:10023,
                               check_sender_access hash:/etc/postfix/sender_access,
                               permit

Bitte drauf achten, dass am Ende der Zeile ein Komma gesetzt wird, da es ansonsten zu Fehlern kommen kann.

Ich habe nun als Dateiname „sender_access“ im Verzeichnis /etc/postfix gewählt. Diese Datei wird nun angelegt:

1
mcedit /etc/postfix/sender_access

In diese Datei stehen ab nun die E-Mail-Adressen, welche abgelehnt werden sollen.

Das Format in dieser Datei ist folgendermaßen:

1
abc@xyz.tld     REJECT

Dies macht man als fortlaufende Liste mit Zeilenumbruch.

Am Ende muss man dies noch für Postfix mit folgenden Befehl übersetzen:

1
postmap /etc/postfix/sender_access

Danach nur noch den Postfix neustarten, und fertig ist es.

1
/etc/init.d/postfix restart

(beziehungsweise „force-reload“ anstatt „restart“ für Konfiguration neu laden)

Ab jetzt muss man immer darauf achten, nach jeder Ergänzung in obiger Datei den postmap – Befehl immer wieder neu auszuführen, und die Konfiguration neu zu laden.

Geschrieben in Internet, Server, PC und Netzwerkgeschichten | 3 Kommentare »

Die virtuelle Spammer-Teergrube „targrey“

September 13th, 2009 von chems

Das Spam-Aufkommen der letzten Jahre erzürnt alle Nutzer des World Wide Webs zugleich. Es gibt jedoch verschiedene Instrumente, sich dagegen zu schützen, sei es durch die Installation von spamassassin, postgrey, etc.

Jedoch sind dies „nur“ effektive Schutzmechanismen. Wie wäre es, wenn man sagen würde, man möchte die Spammer auch noch ärgern ?

Ich empfand diese Überlegung als äußerst reizvoll, und suchte deshalb nach einem geeigneten Instrument, und stieß auf targrey.

1. Was sind Teergruben im Informatikbereich und was nützen diese ?

Wenn man das Wort „Teergrube“ betrachtet, so erschließt sich meist von selbst der Sinn dieses Begriffs. Es wird erreicht, dass bestimmte Dinge in einer Grube aus Teer feststecken.

Die Nutzung in Netzwerken

Um unliebsame Besucher oder Portscanner von sich fern zu halten, nutzt man oft die Möglichkeit, Verbindungen künstlich ins leere Laufen zu lassen.

Um eine verlustfreie Verbindung aufzubauen, hat sich im TCP/IP Bereich der 3-Wege-Handschlag etabliert. Der Sinn besteht darin, sich gegenseitig den Empfang einer Information/Nachricht zu bestätigen, um sicher gehen zu können, dass diese auch wirklich angekommen ist. Das dabei ein gewisser Overhead an Daten entsteht, ist nicht zu vermeiden, weshalb es für manche Bereiche (Fernsehen über Internet,IP-Telephonie) das UDP-Protokoll gibt.

Was bringt hier nun die Teergrube ? Man überlege sich, dass der Portscanner (Server A) eine Verbindung zu Server B aufbaut, um zu schauen, ob der Port XY offen ist. Er sendet also nun eine Anfrage, und Server B gaukelt vor, dass dieser Port existiert und sendet eine Bestätigung zurück. Nun beginnt der Server B, den Portscanner in die Grube wandern zu lassen, und antwortet dann nicht mehr auf die Bestätigung von Server A. Jetzt bleibt also die Verbindung für eine Lange Zeit offen, und kostet den Portscanner viel Rechenleistung und Zeit. Irgendwann bricht die Verbindung mit einem Timeout ab.

Neuere Verfahren basieren auch auf der Idee, wirkliche Antworten zu senden, und so den Portscanner zu beschäftigen, welcher dann trotzdem ins leere läuft, da die Ergebnisse erst einmal nicht so sinnvoll sind.

Teergruben kann man aber auch dazu nutzen, ungebetene Besucher das Aufrufen eigenener Internetseiten künstlich zu erschweren, indem man die Verbindung künstlich extrem verlangsamt (HTTP-Teergruben).

Die Nutzung bei SMTP

Nachdem wir uns nun die normalen Bereiche angeschaut haben, schauen wir nun auf die klassische E-Mail-Teergrube. Hier nutzt man das gleiche Prinzip und verlangsamt Verbindungen von Servern, oder lässt sie genauso ins leere laufen. Ziel dabei ist, Spamserver kostbare Zeit zu rauben, die dann für andere Spams fehlt. Jedoch ist dabei immer das Problem, dass es genug Spam-Server gibt, die sich darauf eingestellt haben, und beim Auftreten von Teergruben die Verbindung von sich aus schließen, und dann je nach Config diese Teergruben-Server auf eine Blacklist aufnehmen. Jedoch ist auch unserem Server geholfen, wenn man garnicht erst kontaktiert wird, oder andererseits die Spam-Server verlangsamt.

Fakt ist: Jede Sekunde, die ein Spam-Server blockiert ist und nicht zum weitersenden anderer Mails nutzen kann, ist eine gute Sekunde.

2. Funktionsweise von targrey

Um targrey nutzen zu können, sollte man vorerst postgrey installiert haben. Die Funktionsweise kann man hier nachlesen.

Versucht wird bei targrey, dass man nach einer Reihe von Prüfungen den Spam-Server in einer Warteschleife verharren lässt und nun schaut, ob er brav wartet oder nicht. Bricht er die Verbindung nicht ab, so kommt er in das normale Greylisting und die Prozedur geht weiter.  Am besten verdeutlicht der Entwickler selber die Funktionsweise in folgender Graphik:

Bildautor: º´Æ£ ·é (SATOH Kiyoshi) |  http://d.hatena.ne.jp/stealthinu/

Bildautor: º´Æ£ ·é (SATOH Kiyoshi) | http://d.hatena.ne.jp/stealthinu/

3. Installation unter Debian

Als erstes muss man herausfinden, welche Postgrey-Version installiert ist:

1
postgrey --version

In meinem Fall lautete die Antwort:  postgrey 1.32

Um Postgrey nun mit targrey zu ergänzen, muss man Postgrey patchen, und deshalb von der Entwicklerseite den Patch downloaden.

Gehen wir also auf die Entwicklerseite, und suchen uns den richtigen Patch, in meinem Fall: taRgrey-patch for postgrey-1.32.

Haben wir unseren Patch gefunden, speichern wir uns den link zwischen und wechseln in das richtige Verzeichnis:

1
cd /usr/sbin/

Als nächstes laden wir den patch herunter:

1
wget http://k2net.hakuba.jp/pub/targrey-0.31-postgrey-1.32.patch

und erzeugen uns anschließend ein Backup unserer Postgrey-Datei aus Sicherheitsgründen:

1
cp postgrey postgrey.bak

Nun nur noch postgrey patchen:

1
patch postgrey targrey-0.31-postgrey-1.32.patch

Die Postfix main.cf beinhaltet schon nach der Installation normalerweise die benötigten Einstellungen, deshalb gehen wir hier nicht weiter darauf ein.

Editiert werden müssen jedoch noch die Postgrey-Optionen:

1
2
mcedit /etc/default/postgrey
POSTGREY_OPTS="--inet=10023 --delay=360 --tarpit=90 --retry-count=2"

Die neuen Optionen sind (Quelle: Entwicklerseite):

1
2
3
4
5
tarpitting: --tarpit=35 (35 second tarpitting and greylisting)
taRgrey mode: --tarpit=65 --targrey (greylists if blocked by 65 sec tarpitting)
greylisting retry threshold: --retry-count=2 (permits after 2 time retries)
auto-whitelist count delay: --auto-whitelist-delay=3600 (counts up once an hour)
outputs client's IP addresses to the auto-whitelist log

Danach muss man nur noch Postfix und Postgrey neu starten. Thats it!

4. Der nicht zu unterschätzende Haken an der ganzen Sache:

Mit targrey behindert man leider auch die vielen ehrlichen Servern im weltweiten Netz. Sind diese nicht gerade auf der whitelist, sorgt man auch bei Ihnen für ein langes Warten, was eigentlich ärgerlich ist. Würden alle Server auf der Welt targrey einsetzen, würde dies für mehr Traffic und längere Zeiten beim übermitteln von E-Mails nach sich ziehen.

Insgesamt ist es traurig, dass man Greylisting und Co. einsetzen muss, um den Wahnsinn in unserem Netz Herr zu werden. Seitdem ich Greylisting einsetze, ist insgesamt der Mail-Traffic spürbar zurückgegangen, und der auftretende Spam wurde auf ein großes Minimum reduziert.

Nach ersten Auswertungen des Mail-Logs hat sich gezeigt, dass auf meinem Server viele Spam-Versender in der Teergrube landen und schön ausgebremst werden. Also trifft es bisher gott sei dank auch die Richtigen. In einem halben Jahr sollte man die ganze Sache jedoch sicherlich noch einmal evaluieren.

Geschrieben in Server, PC und Netzwerkgeschichten | Keine Kommentare »