[postfix-users] [OT] Abfangen von NS-Problemen
Hallo,
aus aktuellem Anlass taucht bei mir die Frage auf:
Lassen sich Nameserver-Ausfälle schon durch zwei unabhängige Nameserver abfangen?
Bei einigen meiner Domains wurde das DNS-System heute durch einen DDOS lahmgelegt.
Da Primary- und Secondary-NS bisher beim Anbieter standen frage ich mich, ob es nicht sinnvoller wäre zumindest einen zu verlagern.
Und damit auch gleich die Frage: Reicht von der Hardware-Anforderung ein virtueller Server dafür aus, oder sind meine Bauchschmerzen dabei mehr als berechtigt.
Thomas
Am 21.11.2008 um 16:00 schrieb Thomas Schwenski:
Da Primary- und Secondary-NS bisher beim Anbieter standen frage ich mich, ob es nicht sinnvoller wäre zumindest einen zu verlagern.
Das ist sicherlich sinnvoll.
Und damit auch gleich die Frage: Reicht von der Hardware-Anforderung ein virtueller Server dafür aus, oder sind meine Bauchschmerzen dabei mehr als berechtigt.
Ich wüßte nicht, warum z.B. bind auf einem virtuellen Server ohne Rekursion nicht in der Lage sein sollte, 250qps auszuhalten. Von "handgebauten" Lösungen wie einem djbdns ganz abgesehen. Unsere Backup- DNS-Server liegen alle auf virtuellen Kisten.
Gruß Stefan
Stefan Förster schrieb:
Ich wüßte nicht, warum z.B. bind auf einem virtuellen Server ohne Rekursion nicht in der Lage sein sollte, 250qps auszuhalten. Von
Es sei denn, Du nimmst die 9.5.0p2, bedienst rekursiv ne Menge Clients und hostest ein paar 100 Zonen ;) Da habe ich gerade ein paar ausgelastete 'echte' Maschinen gesehen (zugegeben etwas ältere Modelle). Mit der 9.5.1b1 daddeln die so zw 0.15-0.30 vor sich hin.
* Thomas Schwenski mailing-lists@thomasschwenski.de:
Hallo,
aus aktuellem Anlass taucht bei mir die Frage auf:
Lassen sich Nameserver-Ausfälle schon durch zwei unabhängige Nameserver abfangen?
Bei einigen meiner Domains wurde das DNS-System heute durch einen DDOS lahmgelegt.
Da Primary- und Secondary-NS bisher beim Anbieter standen frage ich mich, ob es nicht sinnvoller wäre zumindest einen zu verlagern.
Absolut sinnvoll. Soll wohl auch so gemacht werden.
Ralf Hildebrandt schrieb:
- Thomas Schwenski mailing-lists@thomasschwenski.de:
Hallo,
aus aktuellem Anlass taucht bei mir die Frage auf:
Lassen sich Nameserver-Ausfälle schon durch zwei unabhängige Nameserver abfangen?
Bei einigen meiner Domains wurde das DNS-System heute durch einen DDOS lahmgelegt.
Da Primary- und Secondary-NS bisher beim Anbieter standen frage ich mich, ob es nicht sinnvoller wäre zumindest einen zu verlagern.
Absolut sinnvoll. Soll wohl auch so gemacht werden.
Nur zum Verständnis: Das Primary- und Secondary-NS in unterschiedlichen Netzbereichen stehen soll(t)en ist mir klar und war auch beim Domain-Hoster so. Bei dem problemverursachenden Ereignis handelte es sich aber um einen gezielten DDOS gegen mehrere der zur Verfügung gestellten Nameserver, so dass es dummerweise beide für meine Domains zuständigen erwischt hat.
Meine Bauchschmerzen bei einem virtuellen Server rühren mehr daher, dass auf dem Gerät mehrere "Benutzer" Hardware-Ausfälle verursachen können.
Was für Hardwareanforderungen haltet Ihr für nötig?
Und könnt Ihr gute VServer-Hoster empfehlen?
Lohnt es sich noch einen 2. Backup-MX vorzuhalten? (Also insgesamt dann 3 NS? 2 virtuelle und einer beim Domain-Hoster.)
Thomas
Zitat von Thomas Schwenski mailing-lists@thomasschwenski.de:
Ralf Hildebrandt schrieb:
- Thomas Schwenski mailing-lists@thomasschwenski.de:
Hallo,
aus aktuellem Anlass taucht bei mir die Frage auf:
Lassen sich Nameserver-Ausfälle schon durch zwei unabhängige Nameserver abfangen?
Bei einigen meiner Domains wurde das DNS-System heute durch einen DDOS lahmgelegt.
Da Primary- und Secondary-NS bisher beim Anbieter standen frage ich mich, ob es nicht sinnvoller wäre zumindest einen zu verlagern.
Absolut sinnvoll. Soll wohl auch so gemacht werden.
Nur zum Verständnis: Das Primary- und Secondary-NS in unterschiedlichen Netzbereichen stehen soll(t)en ist mir klar und war auch beim Domain-Hoster so. Bei dem problemverursachenden Ereignis handelte es sich aber um einen gezielten DDOS gegen mehrere der zur Verfügung gestellten Nameserver, so dass es dummerweise beide für meine Domains zuständigen erwischt hat.
Meine Bauchschmerzen bei einem virtuellen Server rühren mehr daher, dass auf dem Gerät mehrere "Benutzer" Hardware-Ausfälle verursachen können.
Wohl eher OS-Ausfälle? Ich glaube nicht das die V-Server Benutzer Zugriff auf die Hardware haben...
Was für Hardwareanforderungen haltet Ihr für nötig?
Das kommt ganz auf die Zugriffszahlen an. Ein Nameserver für "microsoft.com" würde ich nicht als V-Server betreiben, ansonsten sollte es kein Problem sein. Kritisch sind bei den V-Server übrigens weniger CPU und RAM sondern eher Dinge wie max. offene Dateien/File-Handles und Sockets.
Und könnt Ihr gute VServer-Hoster empfehlen?
Du solltest eher schauen das der Hoster nicht bei deinem eigentlichen Provider Leistungen einkauft sprich dort seine Hardware stehen hat :-) Ansonsten die üblichen Verdächtigen.
Lohnt es sich noch einen 2. Backup-MX vorzuhalten? (Also insgesamt dann 3 NS? 2 virtuelle und einer beim Domain-Hoster.)
Nur wenn du die NS auch noch Geographisch verteilen willst :-)
Gruß
Andreas
Meine Bauchschmerzen bei einem virtuellen Server rühren mehr daher, dass auf dem Gerät mehrere "Benutzer" Hardware-Ausfälle verursachen können.
Wohl eher OS-Ausfälle? Ich glaube nicht das die V-Server Benutzer Zugriff auf die Hardware haben...
Nein, dahingehend hast Du recht, ich dachte mehr an ungewollte bzw. nicht direkt verursachte Hardware-Probleme. Habe ich einen dedizierten Server bin ich diesbezüglich der alleinige "Risikopunkt". Bei einem virtuellen System sieht das schon anders aus.
Das kommt ganz auf die Zugriffszahlen an. Ein Nameserver für "microsoft.com" würde ich nicht als V-Server betreiben, ansonsten sollte es kein Problem sein. Kritisch sind bei den V-Server übrigens weniger CPU und RAM sondern eher Dinge wie max. offene Dateien/File-Handles und Sockets.
Wenn ich jetzt keinen falschen Denkansatz habe, wäre das ja aber auch eher ein Punkt gegen einen VServer, oder? Falls ich - wie ich befürchte - falsch liege, dann bitte ich um Aufklärung.
Und könnt Ihr gute VServer-Hoster empfehlen?
Du solltest eher schauen das der Hoster nicht bei deinem eigentlichen Provider Leistungen einkauft sprich dort seine Hardware stehen hat :-)
Wie kann man das verlässlich prüfen? Gibt es irgendwie die Möglichkeit IPs den Hostern zuzuordnen?
Ansonsten die üblichen Verdächtigen.
Ich würde auf konkreten Erfahrungen basierende Empfehlungen mehr schätzen, als nur den allgemeinen Hinweis zu Hetzner, Strato und Co.
Thomas
Zitat von Thomas Schwenski mailing-lists@thomasschwenski.de:
Das kommt ganz auf die Zugriffszahlen an. Ein Nameserver für "microsoft.com" würde ich nicht als V-Server betreiben, ansonsten sollte es kein Problem sein. Kritisch sind bei den V-Server übrigens weniger CPU und RAM sondern eher Dinge wie max. offene Dateien/File-Handles und Sockets.
Wenn ich jetzt keinen falschen Denkansatz habe, wäre das ja aber auch eher ein Punkt gegen einen VServer, oder? Falls ich - wie ich befürchte - falsch liege, dann bitte ich um Aufklärung.
Nicht prinzipiell "gegen" sondern ein Hinweis was zu beachten ist wenn der Traffic etwas höher wird.
Und könnt Ihr gute VServer-Hoster empfehlen?
Du solltest eher schauen das der Hoster nicht bei deinem eigentlichen Provider Leistungen einkauft sprich dort seine Hardware stehen hat :-)
Wie kann man das verlässlich prüfen? Gibt es irgendwie die Möglichkeit IPs den Hostern zuzuordnen?
www.ripe.net als erste Anlaufstelle, international www.arin.net.
Ansonsten die üblichen Verdächtigen.
Ich würde auf konkreten Erfahrungen basierende Empfehlungen mehr schätzen, als nur den allgemeinen Hinweis zu Hetzner, Strato und Co.
Ich habe auch schon lange versucht mir über Meinungen ein Bild zu machen. Leider gibt es zu jedem Provider nahezu ausgeglichen gute/schlechte Nachrichten. Ich habe bereits Netclusive/United-Hoster/Strato getestet und jeder hat so seine Macken. Generell ist bei V-Servern insbesonders die I/O-Performance stark schwankend, da dies immer von den anderen auf dem selben Server abhängt. Ist für DNS aber nicht so wichtig da die Zone-Dateien üblicherweise in den Speicher passen.
Gruß
Andreas
Thomas Schwenski schrieb:
Ralf Hildebrandt schrieb:
- Thomas Schwenski mailing-lists@thomasschwenski.de:
Hallo,
aus aktuellem Anlass taucht bei mir die Frage auf:
Lassen sich Nameserver-Ausfälle schon durch zwei unabhängige Nameserver abfangen?
Bei einigen meiner Domains wurde das DNS-System heute durch einen DDOS lahmgelegt.
Da Primary- und Secondary-NS bisher beim Anbieter standen frage ich mich, ob es nicht sinnvoller wäre zumindest einen zu verlagern.
Absolut sinnvoll. Soll wohl auch so gemacht werden.
Nur zum Verständnis: Das Primary- und Secondary-NS in unterschiedlichen Netzbereichen stehen soll(t)en ist mir klar und war auch beim Domain-Hoster so. Bei dem problemverursachenden Ereignis handelte es sich aber um einen gezielten DDOS gegen mehrere der zur Verfügung gestellten Nameserver, so dass es dummerweise beide für meine Domains zuständigen erwischt hat.
Meine Bauchschmerzen bei einem virtuellen Server rühren mehr daher, dass auf dem Gerät mehrere "Benutzer" Hardware-Ausfälle verursachen können.
Was für Hardwareanforderungen haltet Ihr für nötig?
Und könnt Ihr gute VServer-Hoster empfehlen?
Lohnt es sich noch einen 2. Backup-MX vorzuhalten? (Also insgesamt dann 3 NS? 2 virtuelle und einer beim Domain-Hoster.)
Thomas _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Wir haben reale Machinen als dns server xeon raid1 2 GB Ram ganze einfach weil das unsere kleinsten standart server sind man kann die Frage auch nicht einfach beantworten weil es ja auch damit zusammenhaengt wie viel domains man hostet usw, im allgemeinen braucht dns mit bind wenig Leistung
Ausfall sicherheit auf netzebene erreicht man am besten dass man die dnsserver einfach in verschiedenene Netze rechenzentren upstreams usw legt, im Prinzip alles nur eine Sache des Geldes, wie weit man das treiben will, ausserdem gibts da auch div Loesungen
wenn man es ausfallsicher konfiguriert zb vmware cluster kann man auch dediziert virtuelle server nehmen fuer dns das tut nicht wirklich was zur sache
ein 3 Server ist auf jeden Fall einen gute Idee fuer diesen Zweck sollten alle gaengigen Hoster ok sein ( nur ein wenig auf das traffic limit achten sonst wirds vieleicht teuer )
Thomas Schwenski schrieb:
Hallo,
aus aktuellem Anlass taucht bei mir die Frage auf:
Lassen sich Nameserver-Ausfälle schon durch zwei unabhängige Nameserver abfangen?
Bei einigen meiner Domains wurde das DNS-System heute durch einen DDOS lahmgelegt.
Da Primary- und Secondary-NS bisher beim Anbieter standen frage ich mich, ob es nicht sinnvoller wäre zumindest einen zu verlagern.
Und damit auch gleich die Frage: Reicht von der Hardware-Anforderung ein virtueller Server dafür aus, oder sind meine Bauchschmerzen dabei mehr als berechtigt.
Thomas _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Normalerweise hat man 2 nameserver in verschiedenen Netzen und wenn moeglich einen dritten der am besten gleich in einem anderem Rechnenzentrum steht und an einem komplett anderem upstream haengt
heute scheint es mehrere Nameserver geschmissen zu haben sieht mind so aus in meinen logs
Am Freitag, 21. November 2008 schrieb Robert Schetterer:
heute scheint es mehrere Nameserver geschmissen zu haben sieht mind so aus in meinen logs
http://www.heise.de/newsticker/DDoS-Attacke-auf-InternetX-Update--/meldung/1...
Gruß, Gregor
Hallo Postfix Gemeinde,
ab Januar 2009 sollten laut unserem super Gesetzgeber ja auch Informationen hinsichtlich eMail-Verkehr vorgehalten werden. Im Fokus stehen dabei ja
Absender, Empfänger, in Welche Mailbox wurde zugestellt, wann wurde die Mailbox abgerufen und von wem.
Prinzipiell könnte man ja einfach die Logfiles archivieren, das würde reichen. Ich bin grad auf dem Trichter, nen Parser auf Perl-Basis zu erstellen, der die relevanten Daten ausliest und in eine MySQL pumpt.
Bevor das Rad zweimal erfunden wird, hat jemand von euch in der Richtung schon was gemacht ?
Danke, Werner
Am Wednesday 03 December 2008 11:52:05 schrieb Werner D.:
<snip> ... Bevor das Rad zweimal erfunden wird, hat jemand von euch in der Richtung schon was gemacht ?
Ich frag eher mal: hat irgendjemand schon eine konkrete Ahnung, was eigentlich genau wie gespeichert werden soll? Ich hab zumindest auf Heise bisher gelesen, dass es noch keine konkreten Richtlinien gibt, und hab nur mal einen Pseudo-Policy-Dienst geschrieben, der prinzipiell die Daten, um die es hier geht, verwalten und archivieren kann/könnte. Allerdings eben ohne zu wissen, was genau gespeichert werden soll.
Gibts da irgendwo schon mal einen technischen Hinweis (den auch ein Normalsterblicher bekommen kann), auf den jemand verweisen könnte?
<snip> ... Bevor das Rad zweimal erfunden wird, hat jemand von euch in der Richtung schon was gemacht ?
Ich frag eher mal: hat irgendjemand schon eine konkrete Ahnung, was
eigentlich
genau wie gespeichert werden soll? Ich hab zumindest auf Heise bisher gelesen, dass es noch keine konkreten Richtlinien gibt, und hab nur mal
einen
Pseudo-Policy-Dienst geschrieben, der prinzipiell die Daten, um die es
hier
geht, verwalten und archivieren kann/könnte. Allerdings eben ohne zu
wissen,
was genau gespeichert werden soll.
Gibts da irgendwo schon mal einen technischen Hinweis (den auch ein Normalsterblicher bekommen kann), auf den jemand verweisen könnte?
Nö. :) Abwarten und Tee trinken.
Sven Eulberg schrieb:
<snip> ... Bevor das Rad zweimal erfunden wird, hat jemand von euch in der Richtung schon was gemacht ?
Ich frag eher mal: hat irgendjemand schon eine konkrete Ahnung, was
eigentlich
genau wie gespeichert werden soll? Ich hab zumindest auf Heise bisher gelesen, dass es noch keine konkreten Richtlinien gibt, und hab nur mal
einen
Pseudo-Policy-Dienst geschrieben, der prinzipiell die Daten, um die es
hier
geht, verwalten und archivieren kann/könnte. Allerdings eben ohne zu
wissen,
was genau gespeichert werden soll.
Gibts da irgendwo schon mal einen technischen Hinweis (den auch ein Normalsterblicher bekommen kann), auf den jemand verweisen könnte?
Nö. :) Abwarten und Tee trinken.
Ich meine gelesen zu haben dass es auch schon erfolgreiche Klagen gegeben hat die es einem Provider erlaubten eine Ausnahme zu erwirken (es war aber im speziellen Umfeld afair) ....
Zahlen darf die "Hirnwinde (im Sinne von Blähungen)" unserer Politiker eh wieder der gebeutelte "Enduser" :-(.
Wenn es dann konkret wird gibt es bestimmt bald ein neues Open-Source-Projekt das man per filter etc. reinklemmt dass die erforderlichen Daten speichert (Hoff ich zumindest).
Am Wednesday 03 December 2008 13:46:23 schrieb Matthias Haegele:
Wenn es dann konkret wird gibt es bestimmt bald ein neues Open-Source-Projekt das man per filter etc. reinklemmt dass die erforderlichen Daten speichert (Hoff ich zumindest).
Ich hab nichts dagegen (und mein Arbeitgeber bestimmt auch nicht), den Filter, den ich dafür geschrieben/geplant hab (einen milter-Dienst), unter BSD-Lizenz zu veröffentlichen, wenn mir irgendjemand dafür die Spezifikationen zukommen lässt, wenn sie denn veröffentlicht werden.
Wäre wie gesagt nett, wenn sich da jemand, der genaueres weiß (oder es früher mitbekommt als ich über Heise) bei mir melden würde.
Hi Heiko,
Ich hab nichts dagegen (und mein Arbeitgeber bestimmt auch nicht), den Filter, den ich dafür geschrieben/geplant hab (einen milter-Dienst), unter BSD-Lizenz zu veröffentlichen, wenn mir irgendjemand dafür die Spezifikationen zukommen lässt, wenn sie denn veröffentlicht werden.
Hast du damit schon angefangen?
Ciao, Werner
Am Wednesday 03 December 2008 15:30:04 schrieb Werner D.:
Ich hab nichts dagegen (und mein Arbeitgeber bestimmt auch nicht), den Filter, den ich dafür geschrieben/geplant hab (einen milter-Dienst), unter BSD-Lizenz zu veröffentlichen, wenn mir irgendjemand dafür die Spezifikationen zukommen lässt, wenn sie denn veröffentlicht werden.
Hast du damit schon angefangen?
Der milter (bzw. dessen Struktur) in C++ ist schon fertig, ja, mit Backend unter postgresql (mittels libpqxx). Allerdings hab ich effektiv noch keine Spezifikationen gefunden, _was_ genau gespeichert werden soll, und laut Heise gibts die auch noch nicht (wirklich).
Ich hab das Ding als milter implementiert, weil mit dem EOM-Callback ein besserer Indikator besteht, ob eine Mail tatsächlich vom Postfix angenommen wurde, als wenn man das Ding als policy-Dienst implementiert (weil die rcpts bei multirecipient-mails eben bei einer reinen end_of_data_restriction nicht mehr zur Verfügung stehen, und wenn man das Ding in die recipient_restrictions einbaut hat man keinerlei Indikation, ob die Mail überhaupt angenommen wurde im Hinblick auf amavis, etc. bei einer späteren Phase der SMTP-Sitzung).
Ich werd zuschauen, dass ich das Ding demnächst mal öffentlich mache, und würde mich natürlich auch über Beteiligung freuen. :-)
* Werner D. postfix-users@de.postfix.org:
Hallo Postfix Gemeinde,
ab Januar 2009 sollten laut unserem super Gesetzgeber ja auch Informationen hinsichtlich eMail-Verkehr vorgehalten werden. Im Fokus stehen dabei ja
Absender, Empfänger, in Welche Mailbox wurde zugestellt, wann wurde die Mailbox abgerufen und von wem.
Prinzipiell könnte man ja einfach die Logfiles archivieren, das würde reichen. Ich bin grad auf dem Trichter, nen Parser auf Perl-Basis zu erstellen, der die relevanten Daten ausliest und in eine MySQL pumpt.
Bevor das Rad zweimal erfunden wird, hat jemand von euch in der Richtung schon was gemacht ?
policyd v2 kann das ggf. schon. http://www.policyd.org/tiki-index.php?page=ModuleFeatures
Wenn nicht, würde ich dafür ein Modul entwickleln.
p@rick
Patrick Ben Koetter schrieb:
- Werner D. postfix-users@de.postfix.org:
Hallo Postfix Gemeinde,
ab Januar 2009 sollten laut unserem super Gesetzgeber ja auch Informationen hinsichtlich eMail-Verkehr vorgehalten werden. Im Fokus stehen dabei ja
Absender, Empfänger, in Welche Mailbox wurde zugestellt, wann wurde die Mailbox abgerufen und von wem.
Prinzipiell könnte man ja einfach die Logfiles archivieren, das würde reichen. Ich bin grad auf dem Trichter, nen Parser auf Perl-Basis zu erstellen, der die relevanten Daten ausliest und in eine MySQL pumpt.
Bevor das Rad zweimal erfunden wird, hat jemand von euch in der Richtung schon was gemacht ?
policyd v2 kann das ggf. schon. http://www.policyd.org/tiki-index.php?page=ModuleFeatures
Wenn nicht, würde ich dafür ein Modul entwickleln.
Wenn du nicht schon einer wärst würde ich Dir den Heldenstatus verleihen :-). btw: Wie war die Perl Schulung?
p@rick
* Matthias Haegele postfix-users@de.postfix.org:
Bevor das Rad zweimal erfunden wird, hat jemand von euch in der Richtung schon was gemacht ?
policyd v2 kann das ggf. schon. http://www.policyd.org/tiki-index.php?page=ModuleFeatures
Wenn nicht, würde ich dafür ein Modul entwickleln.
Wenn du nicht schon einer wärst würde ich Dir den Heldenstatus verleihen :-). btw: Wie war die Perl Schulung?
Dankeschön. :)
Die Perl-Schulung läuft noch. Momentan ist mein Mut grösser als mein Können. Mal sehen, wie das nach der nächsten Aufgabe sein wird. ;)
p@rick
Servus Patrick,
Wenn nicht, würde ich dafür ein Modul entwickleln.
Könnte ich unterstützend mitmachen sofern Perl.
Ciao, Werner
* Werner D. werner@aloah-from-hell.de:
Servus Patrick,
Wenn nicht, würde ich dafür ein Modul entwickleln.
Könnte ich unterstützend mitmachen sofern Perl.
Ist Perl und jeder der kann, ist willkommen.
Ich persönlich möchte das Thema wieder aufgreifen, sobald die Regelung klare Vorgaben macht bzw. klar ist, wann sie in Kraft treten wird.
trac.de.postfix.org kann diese Projekt ein Zuhause bieten.
p@rick
Patrick Ben Koetter schrieb:
- Werner D. werner@aloah-from-hell.de:
Servus Patrick,
Wenn nicht, würde ich dafür ein Modul entwickleln.
Könnte ich unterstützend mitmachen sofern Perl.
Ist Perl und jeder der kann, ist willkommen.
Ich persönlich möchte das Thema wieder aufgreifen, sobald die Regelung klare Vorgaben macht bzw. klar ist, wann sie in Kraft treten wird.
trac.de.postfix.org kann diese Projekt ein Zuhause bieten.
Sehr schön :-)
Werner D. schrieb:
Servus Patrick,
Wenn nicht, würde ich dafür ein Modul entwickleln.
Könnte ich unterstützend mitmachen sofern Perl.
Da ich mich grad mit Perl anfreunde würd ich mich freuen wenn jemand (gerne auch offlist, damit der Traffic hier nicht explodiert ;-) ). Sagen kann was ihm beim Start geholfen hat.
(Ausser die Bücher von Oreilly wie Learning Perl ...)
Hab mir überlegt ob ich: Perl für CGI von dort machen soll: http://www.oreillyschool.com/courses/web-programming.php
Ciao, Werner
On Wed, Dec 03, 2008 at 02:33:13PM +0100, Matthias Haegele wrote:
Werner D. schrieb:
Servus Patrick,
Wenn nicht, würde ich dafür ein Modul entwickleln.
Könnte ich unterstützend mitmachen sofern Perl.
Da ich mich grad mit Perl anfreunde würd ich mich freuen wenn jemand (gerne auch offlist, damit der Traffic hier nicht explodiert ;-) ). Sagen kann was ihm beim Start geholfen hat.
Eigentlich folgendes:
perldoc -f <function> perldoc -q <question> man perl und den Tuturials folgen IRC: undernet #perl (da sitzen 2-3 extrem kompetente perl gurus) Google (keine spezifische Seite)
Die Erfahrung waechst prinzipiell mit den Fehlschlaegen.
Robert Felber schrieb:
On Wed, Dec 03, 2008 at 02:33:13PM +0100, Matthias Haegele wrote:
Werner D. schrieb:
Servus Patrick,
Wenn nicht, würde ich dafür ein Modul entwickleln.
Könnte ich unterstützend mitmachen sofern Perl.
Da ich mich grad mit Perl anfreunde würd ich mich freuen wenn jemand (gerne auch offlist, damit der Traffic hier nicht explodiert ;-) ). Sagen kann was ihm beim Start geholfen hat.
Eigentlich folgendes:
perldoc -f <function> perldoc -q <question> man perl und den Tuturials folgen IRC: undernet #perl (da sitzen 2-3 extrem kompetente perl gurus) Google (keine spezifische Seite)
Die Erfahrung waechst prinzipiell mit den Fehlschlaegen.
Wie immer möchte ich gerne letzere minimieren :-)
Danke dir:
Helfen tut mir gerade: Das Lama Buch: http://oreilly.com/catalog/9780596520106/
später vielleicht das fortgeschrittene Buch, das jetzt aktuell online verfügbar ist: Higher Order Perl: http://hop.perl.plover.com/book/
und die Freaks hier: www.perlmonks.org
Da hab ich mich auch noch in einen Kurs eingeschrieben (bei dem Dollar-> Euro-Kurs ist es grad verschmerzbar ...):
http://www.oreillyschool.com/courses/index.php
Vielleicht hilft es ja jemand ...
Werner D. schrieb:
Hallo Postfix Gemeinde,
ab Januar 2009 sollten laut unserem super Gesetzgeber ja auch Informationen hinsichtlich eMail-Verkehr vorgehalten werden. Im Fokus stehen dabei ja
Absender, Empfänger, in Welche Mailbox wurde zugestellt, wann wurde die Mailbox abgerufen und von wem.
Prinzipiell könnte man ja einfach die Logfiles archivieren, das würde reichen. Ich bin grad auf dem Trichter, nen Parser auf Perl-Basis zu erstellen, der die relevanten Daten ausliest und in eine MySQL pumpt.
Bevor das Rad zweimal erfunden wird, hat jemand von euch in der Richtung schon was gemacht ?
Danke, Werner _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Hallo Werner,
nach meinen letzten Informationen ist das Gesetz in seiner jetzigen Form immer noch nicht gueltig ( Einsprueche sind anhaengig ) selbst wenn das Gesetz gueltig wird , gibt es immer noch noch nicht wirklich eine technisch klare Durchfuehrungsverordnung also reichen logs , oder logs mit Betreff, oder die ganze Mail ( eigentlich das einzig wahre wenn man konsequent ist ) ausserdem ist das ganze auch sonst voellig uferlos, grosse Mailprovider muessen dass ja schon laenger die haben ein carnivore system drannhaengen, kleine Mailprovider und hier gilt die Anzahl der Kunden ( voellig wiedersinnig weil die Kunden ja abermillionen emailadressen haben koennten ) mussten es bis jetzt nicht ( was wiederum geschaeftliche Mailinhaber nicht von ihrer Archivierungspflicht entbunden hat, dass ist aber wiederum deren Problem )
( alles ohne Gewaehr )
technisch ist das recht einfach aus meiner Sicht ein always bcc ( bei full virtual setup) an zb lokale mailbox mit zb procmail das gleich in datumsubordner und wiederum submailadressenordner sortiert alles im maildir Format, allerdings braucht man da evtl immense Speicherkapazitaet die im Prinzip ja nicht mal voraussagbar ist, denn wer weiss schon im vorraus wieviel mails ueber ein halbes Jahr gespeichert werden muessen, anderer Fall ,will man ausser den postfix logs evtl nur noch das Betreff mitspeichern (also nicht die ganze mail) geht das bei Verwendung von dovecot lda und darin verbose logging
Wie man den Kunden klar machen soll dass sie in Zukunkt evtl das alles mitbezahlen zu haben bleibt aussen vor.
Ganz ehrlich es ist einfach zum verzweifeln mit unseren Politikern keiner der geplanten technischen Massnahmen in welchem Teilbereich bzgl Internet auch immer wird die dazufuehren die wirklich boesen Jungs zu fangen, alles absolut hirnrissig.
nach meinen letzten Informationen ist das Gesetz in seiner jetzigen Form immer noch nicht gueltig ( Einsprueche sind anhaengig )
Doch, doch. Das Gesetz ist 01.01.08 in Kraft getreten. Es gibt allerdings eine Übergangsfrist bis 01.01.09 für "Anbieter von ... Diensten der elektronischen Post".
selbst wenn das Gesetz gueltig wird , gibt es immer noch noch nicht wirklich eine technisch klare Durchfuehrungsverordnung also reichen logs , oder logs mit Betreff, oder die ganze Mail ( eigentlich das einzig wahre wenn man konsequent ist ) ausserdem ist das ganze auch sonst voellig uferlos, grosse Mailprovider muessen dass ja schon laenger die haben ein carnivore system drannhaengen, kleine Mailprovider und hier gilt die Anzahl der Kunden ( voellig wiedersinnig weil die Kunden ja abermillionen emailadressen haben koennten ) mussten es bis jetzt nicht ( was wiederum geschaeftliche Mailinhaber nicht von ihrer Archivierungspflicht entbunden hat, dass ist aber wiederum deren Problem )
Nene, du wirfst das mit der TKÜV und den Sina-Boxen durcheinander. Das hat nichts mit der Vorratsdatenspeicherung zu tun.
Die TKÜV regelt die angeordnete Überwachung einzelne Personen.
technisch ist das recht einfach aus meiner Sicht ein always bcc ( bei full virtual setup) an zb lokale mailbox mit zb procmail das gleich in datumsubordner und wiederum submailadressenordner sortiert alles im maildir Format, allerdings braucht man da evtl immense Speicherkapazitaet die im Prinzip ja nicht mal voraussagbar ist, denn wer weiss schon im vorraus wieviel mails ueber ein halbes Jahr gespeichert werden muessen, anderer Fall ,will man ausser den postfix logs evtl nur noch das Betreff mitspeichern (also nicht die ganze mail) geht das bei Verwendung von dovecot lda und darin verbose logging
Technisch würde ich da mal abwarten. ;) Solange es keinen Fahrplan gibt, braucht man auch keine Fahrkarten kaufen.
Wie man den Kunden klar machen soll dass sie in Zukunkt evtl das alles mitbezahlen zu haben bleibt aussen vor.
Das ist wieder ein ganz anderes Thema.
Ganz ehrlich es ist einfach zum verzweifeln mit unseren Politikern keiner der geplanten technischen Massnahmen in welchem Teilbereich bzgl Internet auch immer wird die dazufuehren die wirklich boesen Jungs zu fangen, alles absolut hirnrissig.
Bringen tut das alles nix, außer dass die Politiker etwas besser schlafen können, weil sie damit ihr Gewissen beruhigen.
Hallo Sven,
Sven Eulberg schrieb:
nach meinen letzten Informationen ist das Gesetz in seiner jetzigen Form immer noch nicht gueltig ( Einsprueche sind anhaengig )
Doch, doch. Das Gesetz ist 01.01.08 in Kraft getreten. Es gibt allerdings eine Übergangsfrist bis 01.01.09 für "Anbieter von ... Diensten der elektronischen Post".
selbst wenn das Gesetz gueltig wird , gibt es immer noch noch nicht wirklich eine technisch klare Durchfuehrungsverordnung also reichen logs , oder logs mit Betreff, oder die ganze Mail ( eigentlich das einzig wahre wenn man konsequent ist ) ausserdem ist das ganze auch sonst voellig uferlos, grosse Mailprovider muessen dass ja schon laenger die haben ein carnivore system drannhaengen, kleine Mailprovider und hier gilt die Anzahl der Kunden ( voellig wiedersinnig weil die Kunden ja abermillionen emailadressen haben koennten ) mussten es bis jetzt nicht ( was wiederum geschaeftliche Mailinhaber nicht von ihrer Archivierungspflicht entbunden hat, dass ist aber wiederum deren Problem )
Nene, du wirfst das mit der TKÜV und den Sina-Boxen durcheinander. Das hat nichts mit der Vorratsdatenspeicherung zu tun.
Die TKÜV regelt die angeordnete Überwachung einzelne Personen.
wir haben das erst letzte Woche mit unserem Anwalt besprochen, ich rede hier ausschliesslich ueber Mail, mag ja sein dass das Gesetz in Kraft tritt aber die Duchfuehrungsverordnung ist so schwammig dass es eben voellig unklar ist was wie in welcher Form gespeichert werden muss, die Postfix logs habe ich schon immer fuer ein halbes Jahr gespeichert insofern gibts da nichts zu aendern erstmal.
der Anwalt meinte man soll gelassen bleiben, denn ein Zwangsgeld wuerde vor keinem Gericht standhalten solange nicht im Gesetz eindeutig geregelt ist wie was in welcher Form gespeichert werden soll, fuer uns als kleinem ISP ist es ohnehin so, dass wenn wir alle Mails fuer ein halbes Jahr ( oder laenger ...) speichern muessen, es schlichtweg bei uns kein Produkt email mehr geben wird dass muessen die Kunden dann zusaetzlich bezahlen oder selbst regeln ( zb auf root servern ) ansonsten wuerden wir wohl schlichtweg einen Rechtsstreit fuehren im Ernstfall
technisch ist das recht einfach aus meiner Sicht ein always bcc ( bei full virtual setup) an zb lokale mailbox mit zb procmail das gleich in datumsubordner und wiederum submailadressenordner sortiert alles im maildir Format, allerdings braucht man da evtl immense Speicherkapazitaet die im Prinzip ja nicht mal voraussagbar ist, denn wer weiss schon im vorraus wieviel mails ueber ein halbes Jahr gespeichert werden muessen, anderer Fall ,will man ausser den postfix logs evtl nur noch das Betreff mitspeichern (also nicht die ganze mail) geht das bei Verwendung von dovecot lda und darin verbose logging
Technisch würde ich da mal abwarten. ;) Solange es keinen Fahrplan gibt, braucht man auch keine Fahrkarten kaufen.
Wie man den Kunden klar machen soll dass sie in Zukunkt evtl das alles mitbezahlen zu haben bleibt aussen vor.
Das ist wieder ein ganz anderes Thema.
Ganz ehrlich es ist einfach zum verzweifeln mit unseren Politikern keiner der geplanten technischen Massnahmen in welchem Teilbereich bzgl Internet auch immer wird die dazufuehren die wirklich boesen Jungs zu fangen, alles absolut hirnrissig.
Bringen tut das alles nix, außer dass die Politiker etwas besser schlafen können, weil sie damit ihr Gewissen beruhigen.
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Robert Schetterer schrieb:
Hallo Sven,
Sven Eulberg schrieb:
nach meinen letzten Informationen ist das Gesetz in seiner jetzigen Form immer noch nicht gueltig ( Einsprueche sind anhaengig )
Doch, doch. Das Gesetz ist 01.01.08 in Kraft getreten. Es gibt allerdings eine Übergangsfrist bis 01.01.09 für "Anbieter von ... Diensten der elektronischen Post".
selbst wenn das Gesetz gueltig wird , gibt es immer noch noch nicht wirklich eine technisch klare Durchfuehrungsverordnung also reichen logs , oder logs mit Betreff, oder die ganze Mail ( eigentlich das einzig wahre wenn man konsequent ist ) ausserdem ist das ganze auch sonst voellig uferlos, grosse Mailprovider muessen dass ja schon laenger die haben ein carnivore system drannhaengen, kleine Mailprovider und hier gilt die Anzahl der Kunden ( voellig wiedersinnig weil die Kunden ja abermillionen emailadressen haben koennten ) mussten es bis jetzt nicht ( was wiederum geschaeftliche Mailinhaber nicht von ihrer Archivierungspflicht entbunden hat, dass ist aber wiederum deren Problem )
Nene, du wirfst das mit der TKÜV und den Sina-Boxen durcheinander. Das hat nichts mit der Vorratsdatenspeicherung zu tun.
Die TKÜV regelt die angeordnete Überwachung einzelne Personen.
wir haben das erst letzte Woche mit unserem Anwalt besprochen, ich rede hier ausschliesslich ueber Mail, mag ja sein dass das Gesetz in Kraft tritt aber die Duchfuehrungsverordnung ist so schwammig dass es eben voellig unklar ist was wie in welcher Form gespeichert werden muss, die Postfix logs habe ich schon immer fuer ein halbes Jahr gespeichert insofern gibts da nichts zu aendern erstmal.
der Anwalt meinte man soll gelassen bleiben, denn ein Zwangsgeld wuerde vor keinem Gericht standhalten solange nicht im Gesetz eindeutig geregelt ist wie was in welcher Form gespeichert werden soll, fuer uns als kleinem ISP ist es ohnehin so, dass wenn wir alle Mails fuer ein halbes Jahr ( oder laenger ...) speichern muessen, es schlichtweg bei uns kein Produkt email mehr geben wird dass muessen die Kunden dann zusaetzlich bezahlen oder selbst regeln ( zb auf root servern ) ansonsten wuerden wir wohl schlichtweg einen Rechtsstreit fuehren im Ernstfall
technisch ist das recht einfach aus meiner Sicht ein always bcc ( bei full virtual setup) an zb lokale mailbox mit zb procmail das gleich in datumsubordner und wiederum submailadressenordner sortiert alles im maildir Format, allerdings braucht man da evtl immense Speicherkapazitaet die im Prinzip ja nicht mal voraussagbar ist, denn wer weiss schon im vorraus wieviel mails ueber ein halbes Jahr gespeichert werden muessen, anderer Fall ,will man ausser den postfix logs evtl nur noch das Betreff mitspeichern (also nicht die ganze mail) geht das bei Verwendung von dovecot lda und darin verbose logging
Technisch würde ich da mal abwarten. ;) Solange es keinen Fahrplan gibt, braucht man auch keine Fahrkarten kaufen.
Wie man den Kunden klar machen soll dass sie in Zukunkt evtl das alles mitbezahlen zu haben bleibt aussen vor.
Das ist wieder ein ganz anderes Thema.
Ganz ehrlich es ist einfach zum verzweifeln mit unseren Politikern keiner der geplanten technischen Massnahmen in welchem Teilbereich bzgl Internet auch immer wird die dazufuehren die wirklich boesen Jungs zu fangen, alles absolut hirnrissig.
Bringen tut das alles nix, außer dass die Politiker etwas besser schlafen können, weil sie damit ihr Gewissen beruhigen.
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
Hi @ll also wenn ich mir das hier durchlese sollten normale postfix logs reichen wenn zusaetzlich logs von pop3/imap zugriffen darin oder extra gespeichert sind, allerdings bin ich kein Anwalt und ob wikipedia hier die allumfassende Wahrheit wiedergibt will mal dahingestellt lassen
http://de.wikipedia.org/wiki/Vorratsdatenspeicherung
---snip
Anbieter von Diensten der elektronischen Post (E-Mail) speichern
1. bei Versendung einer Nachricht die Kennung des elektronischen Postfachs und die Internetprotokoll-Adresse des Absenders sowie die Kennung des elektronischen Postfachs jedes Empfängers der Nachricht, 2. bei Eingang einer Nachricht in einem elektronischen Postfach die Kennung des elektronischen Postfachs des Absenders und des Empfängers der Nachricht sowie die Internetprotokoll-Adresse der absendenden Telekommunikationsanlage, 3. bei Zugriff auf das elektronische Postfach dessen Kennung und die Internetprotokoll-Adresse des Abrufenden, 4. die Zeitpunkte der in den Nummern 1 bis 3 genannten Nutzungen des Dienstes nach Datum und Uhrzeit unter Angabe der zugrunde liegenden Zeitzone.
Werner D. schrieb:
ab Januar 2009 sollten laut unserem super Gesetzgeber ja auch Informationen hinsichtlich eMail-Verkehr vorgehalten werden. Im Fokus stehen dabei ja
Da bin ich neulich zufällig drauf gestoßen: -> http://www.manitu.de/vds.php
Marc
Marc Patermann schrieb:
Da bin ich neulich zufällig drauf gestoßen: -> http://www.manitu.de/vds.php
und aktuell:
Weg frei für Entschädigung für Vorratsdatenspeicherung
http://www.heise.de/newsticker/Weg-frei-fuer-Entschaedigung-fuer-Vorratsdate...
grüße
Alexander
On Wed, Dec 03, 2008 at 11:52:05AM +0100, Werner D. wrote:
Hallo Postfix Gemeinde,
ab Januar 2009 sollten laut unserem super Gesetzgeber ja auch Informationen hinsichtlich eMail-Verkehr vorgehalten werden. Im Fokus stehen dabei ja
Absender, Empfänger, in Welche Mailbox wurde zugestellt, wann wurde die Mailbox abgerufen und von wem.
Prinzipiell könnte man ja einfach die Logfiles archivieren, das würde reichen.
Korrekt.
Ich bin grad auf dem Trichter, nen Parser auf Perl-Basis zu erstellen, der die relevanten Daten ausliest und in eine MySQL pumpt.
Wozu? Lass die Arbeit bitte die Deppen machen.
Hallo Robert,
Am Freitag, 12. Dezember 2008 schrieb Robert Felber:
Prinzipiell könnte man ja einfach die Logfiles archivieren, das würde reichen.
Korrekt.
Ich bin grad auf dem Trichter, nen Parser auf Perl-Basis zu erstellen, der die relevanten Daten ausliest und in eine MySQL pumpt.
Wozu? Lass die Arbeit bitte die Deppen machen.
ich werde auch nur die Logfiles länger aufheben, zumindest bis es endlich auch eine technische Durchführungsrichtlinie gibt. Wenn dann allerdings wirklich mal eine Anforderung kommen sollte steht man vor dem Problem, die viel zu umfangreichen Logdateien auf die minimale zu liefernde Datenmenge einzudampfen. Wenn du zuviel lieferst verstößt du gegen die Rechte der Betroffenen, was sicher auch wieder eine Ordnungswidrigkeit ist. Dann musst du also doch einen entsprechenden Parser entwickeln und stehst dabei noch unter Zeitdruck... Also lieber als gemeinsames Projekt spätestens dann damit anfangen, wenn die tech. Richtlinie endlich kommt (, das BVerfG sein Urteil gesprochen hat und die VDS dann nicht vom Tisch sein sollte). "Deppen" ist hier sicher fehl am Platz.
Gruß, Gregor
Gregor Hermens schrieb:
Hallo Robert,
Am Freitag, 12. Dezember 2008 schrieb Robert Felber:
Prinzipiell könnte man ja einfach die Logfiles archivieren, das würde reichen.
Korrekt.
Ich bin grad auf dem Trichter, nen Parser auf Perl-Basis zu erstellen, der die relevanten Daten ausliest und in eine MySQL pumpt.
Wozu? Lass die Arbeit bitte die Deppen machen.
ich werde auch nur die Logfiles länger aufheben, zumindest bis es endlich auch eine technische Durchführungsrichtlinie gibt. Wenn dann allerdings wirklich mal eine Anforderung kommen sollte steht man vor dem Problem, die viel zu umfangreichen Logdateien auf die minimale zu liefernde Datenmenge einzudampfen. Wenn du zuviel lieferst verstößt du gegen die Rechte der Betroffenen, was sicher auch wieder eine Ordnungswidrigkeit ist. Dann musst du also doch einen entsprechenden Parser entwickeln und stehst dabei noch unter Zeitdruck... Also lieber als gemeinsames Projekt spätestens dann damit anfangen, wenn die tech. Richtlinie endlich kommt (, das BVerfG sein Urteil gesprochen hat und die VDS dann nicht vom Tisch sein sollte). "Deppen" ist hier sicher fehl am Platz.
Gruß, Gregor
Hi Gregor, die Diskussion ist rein akademisch solange man eben nicht genau weiss was gelogged werden muss,davonausgehend dass die Postfix logs ausreichen geht das doch schon jetzt wunderbar ueber i.e syslog syslog-ng rsyslog usw in eine Datenbank, auch Auswertungstools auf php basis dafuer gibts da auch schon
( in groesseren Setups wird man ohnehin schon zentrale syslog server verwenden aus rein praktischen Erwaegungen )
warum die Bibel also 2 mal schreiben, ich will natuerlich niemanden hindern weitere analyse tools zu schreiben aber Dringlichkeiten gibts da aus meiner Sicht nicht
ansonsten reicht ja schon ein normaler grep, mach ich staendig aus anderen technischen Gruenden ueber GB grosse logfiles das sollte in jeden Fall immer ausreichend sein
On Behalf Of Robert Schetterer
warum die Bibel also 2 mal schreiben, ich will natuerlich niemanden hindern weitere analyse tools zu schreiben aber Dringlichkeiten gibts da aus meiner Sicht nicht
Wenn nur die Logs aufgehoben werden könnte die Menge schon recht Groß werden bei einem halben Jahr. Die connect Versuche die zu keiner Einlieferung führen dürften den größten Teil ausmachen. Das parsen auf zusammenhängende Logeinträge in Massen ist recht aufwendig je nachdem was die alles wissen wollen.
So was wäre dann fein, wenn es sauber je Einlieferung und Zustellung, einen Datensatz aus einer Datenbank gibt.
Zeitdruck das das jetzt in 5 Minuten auf dem Tisch liegen müsste sehe ich da allerdings auch nicht unbedingt. Die Regel wird sein das ein Richterlicher Beschluss per Zustellurkunde ins Haus flattert und man gebeten wird dies oder jenes vorzulegen
Auf der anderen Seite sollte dem Genüge getan sein auch wenn die Daten (selectiv) im Rohformat vorliegen. Das sortieren darf dann gerne der ermittelnde Beamte tun *gg
ansonsten reicht ja schon ein normaler grep, mach ich staendig aus anderen technischen Gruenden ueber GB grosse logfiles das sollte in jeden Fall immer ausreichend sein
Mit freundlichen Grüßen
Drießen
Uwe Driessen schrieb:
On Behalf Of Robert Schetterer
warum die Bibel also 2 mal schreiben, ich will natuerlich niemanden hindern weitere analyse tools zu schreiben aber Dringlichkeiten gibts da aus meiner Sicht nicht
Wenn nur die Logs aufgehoben werden könnte die Menge schon recht Groß werden bei einem halben Jahr. Die connect Versuche die zu keiner Einlieferung führen dürften den größten Teil ausmachen. Das parsen auf zusammenhängende Logeinträge in Massen ist recht aufwendig je nachdem was die alles wissen wollen.
So was wäre dann fein, wenn es sauber je Einlieferung und Zustellung, einen Datensatz aus einer Datenbank gibt.
Zeitdruck das das jetzt in 5 Minuten auf dem Tisch liegen müsste sehe ich da allerdings auch nicht unbedingt. Die Regel wird sein das ein Richterlicher Beschluss per Zustellurkunde ins Haus flattert und man gebeten wird dies oder jenes vorzulegen
Auf der anderen Seite sollte dem Genüge getan sein auch wenn die Daten (selectiv) im Rohformat vorliegen. Das sortieren darf dann gerne der ermittelnde Beamte tun *gg
scnr: Aber dann bitte auf Recyclingpapier ausdrucken, und die LKW-Ladung direkt auf dem Schreibtisch abkippen ;-).
Mit freundlichen Grüßen
Drießen
Uwe Driessen schrieb:
On Behalf Of Robert Schetterer
warum die Bibel also 2 mal schreiben, ich will natuerlich niemanden hindern weitere analyse tools zu schreiben aber Dringlichkeiten gibts da aus meiner Sicht nicht
Wenn nur die Logs aufgehoben werden könnte die Menge schon recht Groß werden bei einem halben Jahr.
ich hab mal nachgesehen unkomprimiert auf einem sehr beschaeftigtem Server ( logtechnisch ) sinds 21 GB fuer 7 Monate , find ich jetzt nicht uebertrieben viel aber das ist Ansichtssache
Die connect Versuche die zu keiner Einlieferung führen dürften den größten Teil ausmachen.
stimmt, bots halt
Das parsen auf zusammenhängende Logeinträge in Massen ist recht aufwendig je nachdem was die alles wissen wollen.
tja genau dass weiss man erst , wenn soweit ist, aber mit grep bzw einem kleinen shell script ist das bei 20 Gb noch beherrschbar
So was wäre dann fein, wenn es sauber je Einlieferung und Zustellung, einen Datensatz aus einer Datenbank gibt.
wie bereits geschildert , ist ja jetzt schon ohne grossen aufwand moeglich zb http://www.rsyslog.com/doc-rsyslog_mysql.html
Zeitdruck das das jetzt in 5 Minuten auf dem Tisch liegen müsste sehe ich da allerdings auch nicht unbedingt. Die Regel wird sein das ein Richterlicher Beschluss per Zustellurkunde ins Haus flattert und man gebeten wird dies oder jenes vorzulegen
das sehe ich auch so
Auf der anderen Seite sollte dem Genüge getan sein auch wenn die Daten (selectiv) im Rohformat vorliegen. Das sortieren darf dann gerne der ermittelnde Beamte tun *gg
naja vorsortieren muss man evtl, ich bin mir nicht sicher ob man nicht wiederum gegen den Datenschutz verstoesst wenn man einfach ungefiltert seine logs weitergibt , aber das kommt halt dann auch darauf an was genau gefordert wird
die richtig boesen Jungs duerften dass eh schlauer anstellen ist ja kein Problem mit knoppix aeehnlichen distros dyndns und client wie server Verschluesselung am besten gleich noch ueber dialup ( suspekte handy karten und/oder ungeschuetzte wlan accounts ) da laesst sich ueber mehrere Ebenen alles moegliche verschleiern/verschluesseln und die Frage ist ohnehin warum die Mail benutzen sollten verschluesselte Komunikation ist ja ueber alle moegliche Protokolle im Internet moeglich und es zeigt sich immer wieder dass es durchaus moeglich ist seine Spuren zu verwischen
ansonsten reicht ja schon ein normaler grep, mach ich staendig aus anderen technischen Gruenden ueber GB grosse logfiles das sollte in jeden Fall immer ausreichend sein
Mit freundlichen Grüßen
Drießen
On Fri, Dec 12, 2008 at 01:55:20PM +0100, Gregor Hermens wrote:
liefernde Datenmenge einzudampfen. Wenn du zuviel lieferst verstößt du gegen die Rechte der Betroffenen,
Wuesste jetzt nicht was man da noch "zu viel" liefern kann, ausser evtl. Logging von Subjects (fuer die, die es betrifft), etc. Hm. Okay.
was sicher auch wieder eine Ordnungswidrigkeit ist. Dann musst du also doch einen entsprechenden Parser entwickeln und stehst dabei noch unter Zeitdruck... Also lieber als gemeinsames Projekt spätestens dann damit anfangen, wenn die tech. Richtlinie endlich kommt
Tut mir leid, spaetestens hier woellte ich aus persoenlichen Gruenden keinen vorauseilenden Gehorsam leisten. Dann lieber mit einer Strafe leben, bzw den Klageweg betreten, bzw E-Mail canceln (das war sowieso ernster Vorschlag Chef, Stichwort GDPdU).
(, das BVerfG sein Urteil gesprochen hat und die VDS dann nicht vom Tisch sein sollte). "Deppen" ist hier sicher fehl am Platz.
"Deppen" war nicht auf jene bezogen die tatsaechlich sich die Muehe machen und dafuer Code schreiben, sondern jene, die die Daten begehren. Sorry, wenn es falsch ankam.
On Behalf Of Robert Felber
Tut mir leid, spaetestens hier woellte ich aus persoenlichen Gruenden keinen vorauseilenden Gehorsam leisten. Dann lieber mit einer Strafe leben, bzw den Klageweg betreten, bzw E-Mail canceln (das war sowieso ernster Vorschlag Chef, Stichwort GDPdU).
Ernster Vorschlag von mir "alle Firmen melden Ihr Gewerbe oder den Betrieb für 14 Tage ab..." Bei der heutigen Last an Verwaltungsauflagen von Väterchen Staat wäre das eine schöne Rache. Die die Politiker evtl. mal ins grübeln bringen würde. *gg
Mit freundlichen Grüßen
Drießen
participants (16)
-
Alexander Muth -
Gregor Hermens -
Heiko Wundram -
Jan P. Kessler -
lst_hoe02＠kwsoft.de -
Marc Patermann -
Matthias Haegele -
Patrick Ben Koetter -
Ralf Hildebrandt -
Robert Felber -
Robert Schetterer -
Stefan Förster -
Sven Eulberg -
Thomas Schwenski -
Uwe Driessen -
Werner D.