INN: Cancel-Lock und Cancel-Key
Im Rahmen der notwendigen Umbaumaßnahmen und der Neueinrichtung von news.szaf.org habe ich endlich auch die Unterstützung von Cancel-Lock und Cancel-Key umgesetzt.
Cancel sind Steuernachrichten zur Löschung anderer Nachrichten im Usenet, vorgesehen zur Löschung eigener Beiträge (oder ggf. noch zur Löschung von Beiträgen durch den Newsadministrator des einspeisenden Servers). Das Protokoll sieht aber keine Verifizierung dieser Nachrichten vor; grundsätzlich kann also jeder Teilnehmer Nachrichten von jedem anderen Teilnehmer löschen, was zwar unzulässig ist und auf breite Ablehnung stößt, aber dennoch in der Vergangenheit gerne vieltausendfach genutzt wurde, nicht nur für von der Netzgemeinschaft akzeptierte Spamcancel, sondern auch für Attacken gegen bestimmte Newsgroups ("leercanceln") oder Netzteilnehmer. Die als Reaktion oft erfolgte Abschaltung der Cancel-Funktionalität war aber auch nicht der Weisheit letzter Schluß.
Daher wurden bereits Ende der Neunziger Vorschläge gemacht, wie das Canceln von Beiträgen nur für Befugte ermöglicht werden kann, nämlich durch das Hinzufügen eines kryptographischen Cancel-Locks in jedem Beitrag, zu dem eine Cancelnachricht den passenden Cancel-Key enthalten muß, wenn sie ausgeführt werden soll. Cancel-Lock und -Key sind dabei zusammengesetzt aus einem geheimen Schlüssel und der Message-ID des jeweiligen (bzw. zu cancelnden) Postings. Nachdem diese Vorschläge jedenfalls auf Client-Seite nie breite Umsetzung - außerhalb einiger unixoider Newsreader - fanden (und sich das Prinzio vermutlich deshalb auch auf Serverseite nicht durchsetzte), bekamen Cancel-Lock und -Key Ende Juni 2007 durch deren verpflichtende Einführung bei dem bedeutenden deutschen Newsserver news.individual.de neuen Auftrieb. Dort hat man nämlich nicht nur die Überprüfung von Cancel-Locks aktiviert, sondern zugleich hinsichtlich der fehlenden Unterstützung im Client zumindest für die eigenen Nutzer insoweit Abhilfe geschaffen als Cancel-Locks durch den Server (!) automatisch allen Beiträgen hinzugefügt werden (und bei berechtigten Canceln wird in gleicher Weise automatisch der passende Cancel-Key eingetragen).
Bereits kurz danach wurden in de.comm.software.newsserver - namentlich durch Alexander Bartolich - erste Implementationen sowohl zum Einfügen als auch zum Prüfen von Cancel-Lock und -Key für den INN veröffentlicht:
Grundsätzlich sind für die Überprüfung von Cancel-Lock und -Key zwei Varianten denkbar: Entweder läßt man die Cancelverarbeitung in Betrieb und filtert unerwünschte Cancel (und Supersedes!) im filter_innd aus, oder man deaktiviert die Cancel-Verarbeitung komplett und führt nur erwünschte Cancel aus filter_innd heraus aus. Letzteres ermöglicht die weitere Unterscheidung, ob man Cancel ablehnen oder zwar annehmen und weiterverbreiten, aber nicht ausführen oder annehmen und ausführen möchte. Weiterhin muß man sich entscheiden, wie man mit Postings ohne Cancel-Lock umgehen will. Für diese Postings kann man weiterhin alle Cancel akzeptieren - oder keinen. (Und man muß sich eine Lösung für Spamcancel überlegen; entweder akzeptiert man signierte Cancel aus vertrauenswürdiger Quelle, oder man implementiert zugleich NoCeM als Ergänzung.)
Update: Die aktuellen Fassungen gibt es in meinem Git-Repository. Dort sind auch Anpassungen für Debian Wheezy eingepflegt.
Egal, wie man zu der Überprüfung von Cancel-Lock und -Key steht: zumindest das automatische Einfügen derselben in Postings der eigenen Benutzer (Cancel-LOck für jedes Posting, Cancel-Key für Cancel und Supersedes) ist in keinem Fall schädlich und durchaus hilfreich, eben weil es Server gibt, die Cancel nur noch mit passendem Cancel-Key ausführen. Es bietet sich an, diese Funktionalität für den INN im filter_nnrpd zu implementieren, dem Filter also, den alle, aber auch nur die lokal geposteten Beiträge durchlaufen. Eine denkbare Implementation ist die folgende für filter_nnrpd.pl, basierend auf dem Posting von Alexander Bartolich:
- #
- # Do any initialization steps.
- #
- use Digest::SHA1();
- use Digest::HMAC_SHA1();
- use MIME::Base64();
- $CANCEL_LOCK = 'hereasecretword';
- #
- # Filter
- #
- sub filter_post {
- my $rval = "" ; # assume we'll accept.
- $modify_headers = 1;
- [...]
- # Cancel-Lock / Cancel-Key
- add_cancel_lock(\%hdr, $user);
- my $key = calc_cancel_key($user, $1);
- add_cancel_item(\%hdr, 'Cancel-Key', $key);
- }
- my $key = calc_cancel_key($user, $hdr{"Supersedes"});
- add_cancel_item(\%hdr, 'Cancel-Key', $key);
- }
- }
- #
- # Cancel-Lock / Cancel-Key
- #
- sub add_cancel_item($$$) {
- my ( $r_hdr, $name, $value ) = @_;
- my $prefix = $r_hdr->{$name};
- $r_hdr->;{$name} = $prefix . $value;
- }
- sub calc_cancel_key($$) {
- my ( $user, $message_id ) = @_;
- }
- sub add_cancel_lock($$) {
- my ( $r_hdr, $user ) = @_;
- my $key = calc_cancel_key($user, $r_hdr->{'Message-ID'});
- my $lock = MIME::Base64::encode(Digest::SHA1::sha1($key), '');
- add_cancel_item($r_hdr, 'Cancel-Lock', $lock);
- }
Dort, wo oben [...] steht, können andere Teile des Filters eingefügt werden.
Die Überprüfung kann bspw. in cleanfeed in die cleanfood.local eingebunden werden; zunächst sind wieder die notwendigen Perl-Module einzubinden:
- use MIME::Base64();
- use Digest::SHA1();
- use Digest::HMAC_SHA1();
Danach wird in local_filter_cancel() die Validität des Cancels geprüft und in local_filter_after_emp() die Validität von Supersedes:
- #
- # local_filter_cancel
- #
- sub local_filter_cancel {
- unless($hdr{Control} =~ m/^cancel\s+(<[^>]+>)/i) {
- }
- }
- sub local_filter_after_emp {
- #return verify_cancel(\%hdr, $hdr{'Supersedes'}, 'Supersedes');
- # verify_cancel is called, but not returned, so the
- # posting is unconditionally accepted
- # verify_cancel calls INN:cancel() if verification suceeds
- verify_cancel(\%hdr, $hdr{'Supersedes'}, 'Supersedes');
- }
- }
Diese Variante setzt voraus, dass die Cancelverarbeitung in INN deaktiviert ist (innflags: -C in inn.conf setzen und INN neu starten). Sie akzeptiert nur Cancel mit passendem Cancel-Key; Supersedes werden in jedem Fall angenommen, aber nur ausgeführt, wenn sie über einen passenden Cancel-Key verfügen. Bei aktivierter Cancelverarbeitung sind die Zeilen 13 und 17 auszutauschen, d.h. die eine ist durch Entfernen des Kommentarzeichens zu aktivieren, die andere auszukommentieren.
Die eigentliche "Arbeit" erfolgt dann in den folgenden zusätzlich noch einzufügenden Funktionen:
- sub verify_cancel($$$) {
- my %headers;
- if ($line =~ m/^([[:alnum:]-]+):\s+(.*)/) {
- $headers{$1} = $2;
- }
- }
- my $lock = $headers{'Cancel-Lock'};
- #return verify_cancel_key($key, $lock, ' target=' . $target);
- }
- }
- sub verify_cancel_key($$$) {
- # -thh
- my $target = $msg;
- $msg = ' target=' . $msg;
- my %lock;
- next unless($l =~ m/^(sha1|md5):(\S+)/);
- $lock{$2} = $1;
- }
- unless($k =~ m/^(sha1|md5):(\S+)/) {
- INN::syslog('notice', "Invalid Cancel-Key syntax '$k'.$msg");
- next;
- }
- my $key;
- if ($1 eq 'sha1') {
- $key = Digest::SHA1::sha1($2); }
- elsif ($1 eq 'md5') {
- $key = Digest::MD5::md5($2);
- }
- $key = MIME::Base64::encode_base64($key, '');
- INN::syslog('notice', "Valid Cancel-Key $key found.$msg");
- # -thh
- # article is canceled now
- INN::cancel($target) if ($target);
- }
- }
- INN::syslog('notice',
- "No Cancel-Key[$cancel_key] matches Cancel-Lock[$cancel_lock]$msg"
- );
- }
Auch diese Funktionen sind für eine generell deaktivierte Cancelverarbeitung geschrieben; wenn die Cancelverarbeitung aktiv ist, ist die Zeile 59 wegzulassen oder auszukommentieren.
Auch der Code für cleanfeed stammt im wesentlichen von Alexander Bartolich und ansonsten von "Ray Banana".
(Die obigen Codeteile sind aus Postings zusammengetragen, getestet und für meine eigenen Zwecke angepaßt; dieser Blog-Beitrag soll eine mögliche Umsetzung von Cancel-Lock und -Key vorstellen, die ich im Rahmen der Neueinrichtung meines Newsserver vorgenommen habe. Er kann und will keine Darstellung des Für und Wider und der verschiedenen Möglichkeiten des Umgangs damit bieten.)
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt