Würmer auch bei Mac?

[Krill]

Über meine mail-adressen bei t-online (ich hab seit vielen, vielen Jahren dieselbe) und bei mac.com bekomme ich weder Viren noch Spams, dort scheint es gute Filter zu geben. (Bei mac.com gibt es ja auch noch die Möglichkeit, Alias-Adressen immer wieder zu wechseln, ohne die eigentliche Adresse aufgeben zu müssen.) Über die beiden Provider, bei denen ich websites habe, ist das etwas anderes, Post über diese Sites ist öfter mal verseucht. Aber immerhin wird ein großer Teil davon auch schon abgefangen, wie ich den Nachrichten entnehme. Nur nicht alles.

 

[sevY]

Ich hab's Dir mal eben rausgesucht…

Dem Anbieter bleibt das Recht vorbehalten, Leistungen zu erweitern, zu ändern und Verbesserungen vorzunehmen, insbesondere wenn diese dem technischen Fortschritt dienen, notwendig erscheinen, um Missbrauch zu verhindern, oder der Anbieter aufgrund gesetzlicher Vorschriften hierzu verpflichtet ist. Insbesondere bleibt dem Anbieter das Recht vorbehalten, sämtlichen Emailverkehr auf mißbräuchlichen Inhalt wie Schadcode (z.B. Virusattachments) oder sogenannten Spam automatisiert und nach im Ermessen des Anbieters liegenden, bewährten und sensiblen Kritieren zu filtern um eine entsprechende Zustellung durch vorzeitiges Abweisen oder Löschen zu verhindern. Freiwillige, unentgeltliche Dienste und Leistungen des Anbieters, die ausdrücklich als solche bezeichnet und nicht Teil der Leistungsbeschreibung sind, können jederzeit eingestellt werden. Der Anbieter wird bei Änderungen und der Einstellung kostenloser Dienste und Leistungen auf die berechtigten Interessen des Kunden Rücksicht nehmen.

 

[asg]

Wie Yves schon schrieb, mittels Postfix, clamav, dspam/spamd, amavisd, RBLs/RHSBL dem header/mime/bodycheck von postfix und diveresen reject bei bezüglich header, hostname, sender und receipient ist spam und Virenquark bei 0 angekommen.

Email macht was die Konfiguration der Mailserver angeht keinen Spass mehr und verursacht mittlerweile eine Last im gesammten Internet die nicht mehr feierlich ist.

Grenudebil wird es dann noch wenn Kunden ihren mailserver und DNS nicht richtig aufsetzen können und die Email vom eigenen Mailserver verworfen wird weil der Name nicht aufgelöst werden kann oder zu einem anderen aufgelöst wird.
Noch grenzdebiler ist es wenn Admins den Mailserver so einstellen das dieser auf jede spam eine Antwort an den vermeintlichen Absender absetzt (diese sind zu 99,9% gefälscht) und somit selbst "Spam" verteilt, die Antwort trifft immer den falschen.

Nene, Mail ist wirklich versaut worden.

 

[sevY]

Noch grenzdebiler ist es wenn Admins den Mailserver so einstellen das dieser auf jede spam eine Antwort an den vermeintlichen Absender absetzt (diese sind zu 99,9% gefälscht) und somit selbst "Spam" verteilt, die Antwort trifft immer den falschen.

Solche Admins gehören aber geschlagen
Das ist ja auch wieder das „Schiffe versenken - Prinzip“.

Bezüglich Mailserver Administration / Setup… ich finde schon, dass es Spaß macht. Ich habe mir letzten Monat mit einem guten Freund den Cyrus Murder mit Postfix entsprechend der weiter oben genannten Erweiterungen vorgenommen… und ich finde es sehr interessant, die ganzen Filter-Mechanismen einzubetten.
Was auch toll ist, ist Sendmail und Milter!

Natürlich ist ein Apache(2) einfacher im Setup… aber ein sauberes Mailsystem, dass Spamharvesting und Virus-Storms gewachsen ist, ist auch eine Herausforderung.

Ich bin mir sicher, dass wenn alle Provider kontinuierlich mitziehen und an OpenSource Projekten wie z.B. SpamAssassin mitarbeiten (SA-Learn z.B. sei hier mal genannt…), dann kriegt man das Netz auch irgendwann wieder sauber.
Und die Regierungen werden ja langsam auch wach und leiten Schritte ein.

Ich habe heute morgen noch lange mit einem Kollegen vom BSI darüber gesprochen… was ich derzeit viel schlimmer finde (und was Anlass des Gesprächs war), ist, dass letzte Woche fast täglich um die 500 Brute-Force-Attempts auf FTP und SSH Protokollebene zu verzeichnen waren… und da half kein IP-Tables IP-Blacklisting… die IP war schön fluktuierend (oder waren es Proxies?), aber immer wieder in die dieselbe Region tracerouteable.

Wie sieht es eigentlich rechtlich aus, wenn ich in so einem Falle den Host des Angreifers mit Nessus unter die Lupe nehme und „deaktiviere“, sofern möglich?

Yves

 

[asg]

Solche Admins gehören aber geschlagen
Das ist ja auch wieder das „Schiffe versenken - Prinzip“.

Bezüglich Mailserver Administration / Setup… ich finde schon, dass es Spaß macht. Ich habe mir letzten Monat mit einem guten Freund den Cyrus Murder mit Postfix entsprechend der weiter oben genannten Erweiterungen vorgenommen… und ich finde es sehr interessant, die ganzen Filter-Mechanismen einzubetten.
Was auch toll ist, ist Sendmail und Milter!

Sicher, es ist interessant, müsste aber allers nicht sein wenn es nicht diesen mistigen Spam geben würde. Ständig muss man nachziehen, aufpassen das nichts verloren geht was durch soll (privat mag das noch egal sein, aber geschäftlich kann das zu Schaden führen) undsoweiterundsofort.
Dann kommt noch SASL/TLS/SSL zum Einsatz, Pflege der blacklists, drauf hoffen das die RBL und RHSBL nicht ausfallen da sonst auch Asche mit Filterung oder gar Zustellung. Das ganze Mailsystem ist mittlerweile auf Krücken gebaut die immer mehr werden.

Natürlich ist ein Apache(2) einfacher im Setup… aber ein sauberes Mailsystem, dass Spamharvesting und Virus-Storms gewachsen ist, ist auch eine Herausforderung.

Och ich finde ein einfacher Postfix ist schnell auufgesetzt. Was am längsten dauert ist das compilieren von postfix, amavisd-new, clamav und Konsorten aus den Ports. Dann kann man zu 95% eine schon vorhandene Konfiguration einfach drüberklatschen, hostname und IP noch ändern, fertig.

Ich bin mir sicher, dass wenn alle Provider kontinuierlich mitziehen und an OpenSource Projekten wie z.B. SpamAssassin mitarbeiten (SA-Learn z.B. sei hier mal genannt…), dann kriegt man das Netz auch irgendwann wieder sauber.
Und die Regierungen werden ja langsam auch wach und leiten Schritte ein.

So lange es noch Offene Relays zu Hauf git, so lange rennt der Spam. Es kommt dabei auch nicht darauf an ob ein User davon 10 oder 100 im Postfach hat sondern allein darauf das der Dreck überhaupt im Netz unterwegs ist und unsäglich Bandbreite frisst und sich mein Mailserver damit rumschlagen muss den Dreck zu droppen.

Ich habe heute morgen noch lange mit einem Kollegen vom BSI darüber gesprochen… was ich derzeit viel schlimmer finde (und was Anlass des Gesprächs war), ist, dass letzte Woche fast täglich um die 500 Brute-Force-Attempts auf FTP und SSH Protokollebene zu verzeichnen waren… und da half kein IP-Tables IP-Blacklisting… die IP war schön fluktuierend (oder waren es Proxies?), aber immer wieder in die dieselbe Region tracerouteable.

Naja, Hintergrundrauschen. Wenn man ordentlich Passwörtet hat und bei ssh noch auf keys setzt dann kann da nichts passieren, rein vom Aspekt der Sicherheit (ausser sshd hat nen Loch).
Was nervt ist das das Log einfach nicht mehr lesbar ist und man kaum noch unterscheiden kann ob das ein brute force war oder ob da jemand nebenher mehr versucht. So ein Log liest auch keiner mehr. Wirklich eklig.
Und dann kommt der Mist immer von anderen IPs, meist noch dynamische IPs von irgendwelchen Windows Borgs. Sperre ich die mit portsentry direkt als erste FW rule schön und gut, oder via hosts.allow, aber das ist auch alles Gülle da ich dann wieder manuell den Kram entfernen muss, oder nen cronjob rennen lasse der dies macht. Soll heissen wieder mehr Arbeit um den Dreck wieder wegzuwaschen.
Richtig eklig wird es dann wenn es in die tausende an Anfragen geht, dann steht man vor einem DoS. Und dann heisst es warten.
Und das alles wegen den sorglos Windows Usern (zum grössten Teil).

Wie sieht es eigentlich rechtlich aus, wenn ich in so einem Falle den Host des Angreifers mit Nessus unter die Lupe nehme und „deaktiviere“, sofern möglich?
Yves

Was willst Du machen? Jeder einzelnen IP hinterherhecheln und versuchen, was noch illegal wäre, diesen Rechner zu deaktivieren? Wird nichts bringen, das ist wie mit Spam, ekliges Hintergrundrauschen was nicht sein müsste aber leider ist.

 

[maceis]

Ich hab's Dir mal eben rausgesucht…
[...]

Danke, das finde ich sehr interessant.

Wie haltet Ihr das mit Einlieferung von Mails von Dial-Up Hosts?
Ist mW ein Grenzfall, der unterschiedlich bewertet wird.

Ich frage deswegen so genau, weil meine Provider seit kurzem die Einlieferung von Mails von Dial-Up Hosts mit einer "550 RBL rejection" unterbindet.
Finde ich natürlich nicht so toll, zumal auch (alle) Adressen aus dem eigenen Adresspool (also die Adressen, die den Kunden zugewiesen werden) geblockt werden.
Im Augenblick stehe ich mit dem technischen Support in Kontakt.
Mal seh'n, wie das ausgeht.

 

[asg]

Danke, das finde ich sehr interessant.

Wie haltet Ihr das mit Einlieferung von Mails von Dial-Up Hosts?
Ist mW ein Grenzfall, der unterschiedlich bewertet wird.

Wie meinst Du das? Normalerweise nutzen diese User ja einen Relay von ihrem Provider (bzw. nutzen einfach ihren account über Programme wie Outlook, thunderbird,..). Dort wird dann ja der richtige mailserver mitgegeben der sich dann wiederum via DNS auflösen lässt.
Nutzt der Dial-in User hingegen dyndns und setzt darauf einen eigenen mailserver auf, dann ist der selber schuld. Das ist krampf und Spielerei die in einem geschäftlichen Umfeld nichts zu suchen hat.

Ich frage deswegen so genau, weil meine Provider seit kurzem die Einlieferung von Mails von Dial-Up Hosts mit einer "550 RBL rejection" unterbindet.
Finde ich natürlich nicht so toll, zumal auch (alle) Adressen aus dem eigenen Adresspool (also die Adressen, die den Kunden zugewiesen werden) geblockt werden.
Im Augenblick stehe ich mit dem technischen Support in Kontakt.
Mal seh'n, wie das ausgeht.

Ich verstehe Dich nicht wirklich.
Ein T-Online User schickt eine Mail ab und diese kommt dann nicht an? Das wäre sinnfrei.
Wenn dann geschieht sowas:

May 23 19:03:14 sffwd0 postfix/smtpd[27812]: NOQUEUE: reject: RCPT from pD9E60EAE.dip0.t-ipconnect.de[217.230.14.174]: 550 <kevin@unseredomain.de>: Recipient address rejected: User unknown in local recipient table; from=<serg@de.abb.com> to=<kevin@unseredomain.de> proto=ESMTP helo=<de.abb.com>
May 23 19:03:36 sffwd0 postfix/smtpd[27812]: NOQUEUE: reject: RCPT from pD9E60EAE.dip0.t-ipconnect.de[217.230.14.174]: 550 <kevin@unseredomain.de>: Recipient address rejected: User unknown in local recipient table; from=<serg@de.abb.com> to=<kevin@unseredomain.de> proto=ESMTP helo=<de.abb.com>

May 23 19:21:57 sffwd0 postfix/smtpd[27915]: NOQUEUE: reject: RCPT from pD9E60EAE.dip0.t-ipconnect.de[217.230.14.174]: 550 <smith@unseredomain.de>: Recipient address rejected: User unknown in local recipient table; from=<dan@bilmed.at> to=<smith@unseredomain.de> proto=ESMTP helo=<bilmed.at>

Eine dial-in verbindung wahrscheinlich eine Windowsbüchse mit Wurm der sich verbreiten will. Die Absender IP bleibt die gleiche, er wechselt dann die Adresse des Empfängers und sein Servernamen "helo" mit der sich vorstellt.
Da der User bei uns nicht vorhanden ist wird das Ding verworfen. Sollte er vorhanden sein dann passt da IP mit Name nicht überein, wird verworfen.
Das ist üblicher Müll der das log zumüllt und zum Hintergrundrauschen gehört.

 

[sevY]

Das ganze Mailsystem ist mittlerweile auf Krücken gebaut die immer mehr werden.

Naja… dafür haben wir immer noch Heartbeat im Einsatz (für Fallover bei Hardwareausfällen oder eben auch DoS…) und in AmaVis entsprechend immer einen Fallback Service, wenn z.B. mal Clamd nicht mehr will (hat sich in der Vergangenheit ja gerne mal die DB geschossen und dann weggehängt…).

Och ich finde ein einfacher Postfix ist schnell auufgesetzt. Was am längsten dauert ist das compilieren von postfix, amavisd-new, clamav und Konsorten aus den Ports. Dann kann man zu 95% eine schon vorhandene Konfiguration einfach drüberklatschen, hostname und IP noch ändern, fertig.

Naklar… Out-of-the-Box funktioniert das meiste halbwegs… was uns am meisten Zeit gekostet hat war die Implementation von OpenSSL, MD5 zusammen mit dem saslauthd und pam_mysql.
Und was ganz schlimm war… web-cyradm… der ist zur Zeit mit mod_auth zusätzlich abgesichert und wird neugeschrieben… Der Code ist teilweise die Hölle

So lange es noch Offene Relays zu Hauf git, so lange rennt der Spam.

Ja… wir waren bis vor 8 Monaten leider auch noch ein offenes Relay… aber mittlerweile geht es nicht mehr anders… auch wenn die Kunden reihenweise gejammert haben, weil Sie die Outlook Express Option für SMTP-Auth nicht gefunden haben (und die Newsletter ignorieren).

Was nervt ist das das Log einfach nicht mehr lesbar ist und man kaum noch unterscheiden kann ob das ein brute force war oder ob da jemand nebenher mehr versucht. So ein Log liest auch keiner mehr. Wirklich eklig.

Genau darum geht es mir.
An sich ist die Tatsache, dass jemand es teilweise und derart massiv versucht, schon sehr befremdlich.
Passiert ist bis jetzt nichts. Über SSH kommt man auf unsere Server auch nur von einem einzigen „Steuerserver“ im Subnetz und der Authentifiziert mit einen 1024er RSA Key.
Wer also via SSH kompromitieren möchte, muss erstmal den „Steuerungsserver“ ausfindig machen, da nur seine IP akzeptiert wird… und auf dem läuft ein BSD Derivat und nichts anderes als SSH… also kaum ein Ansatzpunkt.
Aber es geht generell auch um den Ärger den man bekommen kann, was Arbeitszeit angeht… man kann seine Kunden noch so sehr aufklären, Sie mögen bitte nur FTP/TLS und IMAPs, POP3s, sSMTP verwenden… nichts ist… das wäre ja Umstellung. Und wenn dann mal irgendwo zwischendrin ein paar TCP/IP Päckchen dumped werden und im schlimmsten Fall das Homeverzeichnis versaut wird, ist das Geschrei groß…

Nicht, dass ich mich über meine Kunden auslassen möchte… hehe… aber manchmal frage ich mich schon, warum ich mir Nächte für solche Sicherheitsimplementationen um die Ohren haue, die dann doch nicht verwendet werden.
Und da wären wir auch wieder beim Thema „Spam“… wenn ich das Filtering in die Hand nehme, tun es meine Kunden bestimmt nicht.
Meist auch aus Respekt vor eventuellen Folgen, die Sie durch Ihre vermeintliche Unwissenheit verschulden könnten…

Was willst Du machen? Jeder einzelnen IP hinterherhecheln und versuchen, was noch illegal wäre, diesen Rechner zu deaktivieren? Wird nichts bringen, das ist wie mit Spam, ekliges Hintergrundrauschen was nicht sein müsste aber leider ist.

Wie gesagt… ein wirkliches Risiko ist das für uns nicht. Ich denke nicht, dass so schnell was durchkommt… absolute Sicherheit gibt es nicht… aber ich denke, wir sind schon sehr nah dran (zumindest hat seit 2 Jahren kein Einbruchsversuch Erfolg gehabt).


Nur lasse ich mir manchmal am WE mit tail -f sämtliche Logs nebenbei an meinem kleinen iMac über die Shell laufen… einfach aus reiner Entdeckungsfreude während der Wartungsarbeiten… und wenn dann auf einmal massive Spamzustellversuche von irgendeiner Dial-Up Windowskiste kommen (hier die Anwort auf Maceis Frage =>) und diese zwar Rejected werden, dennoch lästig sind, würde ich dem manchmal liebend gern einen Riegel vorschieben.

Mir ist klar, dass das ganze nur Zeitverschwendung wäre.
Aber bei uns an der Uni werden manchmal auch Bücher über SSL auf Kosten von Amazon-Kunden, die kurz zuvor eben ohne dieses auf der Website shopped haben, bestellt. Und das zeigt Wirkung

Yves

 

[maceis]

...
Nutzt der Dial-in User hingegen dyndns und setzt darauf einen eigenen mailserver auf, dann ist der selber schuld. Das ist krampf und Spielerei die in einem geschäftlichen Umfeld nichts zu suchen hat.

Nicht alle Kunden sind Geschäftskunden.
Der User (in diesem Fall ich ) benutzt einen lokalen Mailserver z. B. um sich diverse Systemmeldungen/Sicherheitswarnungen/Scriptausgaben etc. an seine eigene (externe) Emailadresse senden zu lassen, um Webseiten mit mailversand lokal vollwertig testen zu lassen und verschiednenes anderes ... (allerdings zur Zeit ohne dyndns).

Auch in einem geschäftlichen Umfeld kann der Einsatz eines internen Mailservers u. U. sehr sinnvoll sein.
Schade, wenn die mißbräuchliche Nutzung des Internets durch einige, zur undifferenzierten Beschränkung aller Nutzer führt.
Das wiederspricht auch meinem persönlichen Rechtsempfinden.

Unverständlich, weil überflüssig finde ich vor allem, wenn Provider selbst den eigenen Kunden die Suppe versalzen, wo doch da die Möglichkeit besteht, diejenigen die Mißbrauch betreiben, sicher zu identifizieren.

...Ich verstehe Dich nicht wirklich.
Ein T-Online User schickt eine Mail ab und diese kommt dann nicht an? Das wäre sinnfrei.
Wenn dann geschieht sowas:

May 23 19:03:14 sffwd0 postfix/smtpd[27812]: NOQUEUE: reject: RCPT from pD9E60EAE.dip0.t-ipconnect.de[217.230.14.174]: 550 <kevin@unseredomain.de>: Recipient address rejected: User unknown in local recipient table; from=<serg@de.abb.com> to=<kevin@unseredomain.de> proto=ESMTP helo=<de.abb.com>
May 23 19:03:36 sffwd0 postfix/smtpd[27812]: NOQUEUE: reject: RCPT from pD9E60EAE.dip0.t-ipconnect.de[217.230.14.174]: 550 <kevin@unseredomain.de>: Recipient address rejected: User unknown in local recipient table; from=<serg@de.abb.com> to=<kevin@unseredomain.de> proto=ESMTP helo=<de.abb.com>

....

Nein, sowas:

host my.provider.de[xxx.xxx.xxx.xxx] refused to talk to me: 550 RBL rejection: direct deliveries from this dynamic/dialup ip refused, use your ISP's smarthost.

Und das bei den Adressen der eigenen Kunden.
Bisher musste man nur bei T-Online extra was zahlen, wenn man (z. B. als Firma) einen eigenen Mailserver benutzen wollte.
Aber offensichtlich geht die Tendenz dazu, eigene Server grundsätzlich nur noch gegen anständig Kohle zuzulassen ;(.

 

[sevY]

Der User (in diesem Fall ich ) benutzt einen lokalen Mailserver z. B. um sich diverse Systemmeldungen/Sicherheitswarnungen/Scriptausgaben etc. an seine eigene (externe) Emailadresse senden zu lassen, um Webseiten mit mailversand lokal vollwertig testen zu lassen und verschiednenes anderes ... (allerdings zur Zeit ohne dyndns).

Solange die Mails nicht wirklich lokal rausgehen, sondern vom MTA direkt in eine lokale Mailbox sortiert werden, ist das sinnvoll.
Sofern Du damit aber Mails über Netz versendest, fehlt Dir bei einem Dial-Up entsprechend der Reverse-Lookup, sofern du kein DyDNS verwendest… und selbst mit DyDNS ist es noch dahingestellt, ob der Reputationseffekt entsprechend und ausreichend schnell eintritt, wenn deine IP wechselt.
Ein Mailserver lokal mit z.B. T-DSL zu betreiben, empfinde ich als interessant… aber unter produktiven Gesichtspunkten sind das Geek-Toys.

Auch in einem geschäftlichen Umfeld kann der Einsatz eines internen Mailservers u. U. sehr sinnvoll sein.

Natürlich. Aber sofern in einem „geschäftlichen Umfeld“ der Einsatz notwendig wird, ist 100% auch mindestens eine günstige Standleitung im Budget, welche dann praktisch das entsprechende „Miniatur-Rechenzentrum“ im Kleinbetrieb ermöglicht.

Schade, wenn die mißbräuchliche Nutzung des Internets durch einige, zur undifferenzierten Beschränkung aller Nutzer führt.
Das wiederspricht auch meinem persönlichen Rechtsempfinden.

So ist aber leider die Realität… auch wenn ich Dich da 100% verstehen kann…*ich kann z.B. nicht den Regelbetrieb meiner Server aufs Spiel setzen, weil ich die aus wirtschaftlicher Sicht als „hypermoralisch“ zu sehenden „Rechtsideale“ schützen möchte.
In so einem Fall kann man auch mit der Aufgabe der Gemeinschaft, oder viel weiter gegriffen, der Gesellschaft, argumentieren, die meine Restriktionen als Folge sehen sollte und Ihre Beschwerden daher auf die Ursache fokussieren bzw. mit allen Möglichkeiten versuchen muss, diese zu bekämpfen.

Unverständlich, weil überflüssig finde ich vor allem, wenn Provider selbst den eigenen Kunden die Suppe versalzen, wo doch da die Möglichkeit besteht, diejenigen die Mißbrauch betreiben, sicher zu identifizieren.

Indivuelle Lösungen kosten Zeit. Und Zeit ist Geld.
Maximal kann man da halt ein Webfrontend zu freien Konfiguration dem User in die Hände legen… nur wenn man dann etwas teurer wird (gerade weil man beim SharedHosting die Kunden/Server Zahl minimieren muss… akzeptierter Spam frisst Ressourcen… und Kunden verhindern eben wie gesagt selten diesen) und mal rüber „zu den 3 großen Providern des Landes“*schaut, hat man doch gar keine Chance mehr…

Aber offensichtlich geht die Tendenz dazu, eigene Server grundsätzlich nur noch gegen anständig Kohle zuzulassen ;(.

Du bekommst bei uns schon einen dedicated Server mit 200GB Traffic/Monat, aktueller Hardware (Athlon XP 2200+, 120GB Platte, 1GB RAM) für unter 40,00 EUR im Monat.
Dazu gehört dann eine statische IP, die es Dir erlaubt, einen komplett eigenen, ordentlichen Mailserver zu betreiben.


Yves

 

[maceis]

Hallo Yves,

ich verstehe und akzeptiere Deine Argumentation, die letztendlich ja repräsentativ für die Providerseite stehen kann.

Vollständig teilen kann ich sie aber nicht.
So finde ich es z. B. schon ein bisschen überzogen, die "Rechte" sämtlicher Kunden einzuschränken, nur weil die _Möglichkeit_ eines Missbrauchs besteht.
Das kommt mir ein bisschen so vor, als würde man das Führen von Kraftfahrzeugen auf öffentlichen Straßen nur noch Berufskraftfahrern erlauben, da die Möglichkeit einer Geschwindigkeitsüberschreitung (oder von mir aus eines Unfalls) besteht.
Besonders blöd finde ich es, wenn ein Provider seinen eigenen Adresspool "blacklisted".

Inwieweit hier schon der Tatbestand des § 206 II, Ziffer 2 StGB (Unterdrückung von zur Übermittlung anvertrauten Sendungen) gegeben ist wird derzeit ja noch widersprüchlich diskutiert.
Wenn das aufgrund der bloßen Möglichkeit eines Mißbrauchs geschieht finde ich persönlich, dass das zu weit geht.
Mal ganz abgesehen davon, dass man mit einem simplen Perls Skript die selben Mißbrauchsmöglichkeiten hat, ohne dass der Provider das mit einer Blacklist unterbinden kann.

Was die Sache mit den reverse-lookups angeht, so ist das (zumindest hier) nicht das Problem, da (wie bei vielen ISP's) ein entsprechender DNS Eintrag vorhanden ist.

Das mit dem "dedicated Server" ist zwar schön, aber ich brauche und will sowas eigentlich nicht. Lediglich ne feste IP wäre reizvoll .

Aber hey;
Mir fällt grade ein, dass mein Webhoster (besser gesagt der meines Bruders, aber da hab ich ne subdomain) auch nen Mailserver hat.
Muss ich mir halt da eine Adresse anlegen; der nimmt nämlich (noch) meine "Dial-Up Emails" an.
Insofern: "Rutsch mir den Buckel runter 0und0!" .

 

[sevY]

Hi,

So finde ich es z. B. schon ein bisschen überzogen, die "Rechte" sämtlicher Kunden einzuschränken, nur weil die _Möglichkeit_ eines Missbrauchs besteht.
Das kommt mir ein bisschen so vor, als würde man das Führen von Kraftfahrzeugen auf öffentlichen Straßen nur noch Berufskraftfahrern erlauben, da die Möglichkeit einer Geschwindigkeitsüberschreitung (oder von mir aus eines Unfalls) besteht.

Der Vergleich hinkt leider total
Der absolute Bruchteil der „Kunden“ verwendet einen eigenen Mailserver… setze hier mal bitte realistische Maßstäbe an und nimm' eine Frage wie „Wie kriege ich meine Emailadresse in Outlook Express – und, was ist das überhaupt?“ als Referenz…
Um das dann auf dein o.g. Beispiel zu übertragen wäre es so, die Restriktionen nicht auf Personkreise, sondern auf Fahrzeugtypen zu relativieren.
So müsste das Beispiel korrekt heissen:

„Das Führen von selbstgebauten Kraftfahrzeugen ohne TÜV auf öffentlichen Straßen wird verboten, da die empirisch nachgewiesene Möglichkeit eines Unfalls besteht.“

Und ein Mailserver, welcher von einem Dial-Up Host betrieben wird, ist in den meisten Fällen eine Drecksschleuder… sofern ein Mailserver wirklich ernsthaft genutzt wird, ist auch meist die Frage nach einer „TÜV-Plakete“, respektive einer statischen IP mit Hostnamen und entsprechendem Reverse-Lookup obligatorisch.

Besonders blöd finde ich es, wenn ein Provider seinen eigenen Adresspool "blacklisted".
(…)
Mal ganz abgesehen davon, dass man mit einem simplen Perls Skript die selben Mißbrauchsmöglichkeiten hat, ohne dass der Provider das mit einer Blacklist unterbinden kann.

Was meinst Du damit?
Ausgehende Emails werden von uns generell mit „passthrough“ durchgeschleust… wir vertrauen unseren Kunden, die sich mittels SMTP-Auth als unsere Kunden am Mailserver verifiziert haben.

Eine Verifizierung allein über die Emailadresse reicht hier nicht, sondern erfolgt über eine interne, inkrementelle ID (virtuelle UserID/MailboxOwnerID).
Sofern also mittels Perl o.ä. „from localhost“ ohne vorheriges SMTP-Auth gesendet wird, erfolgen sämtliche Anti-Spam/Virus Prüfungen.
Um das zu umgehen, kann der Kunde ja auch via SMTP (mit Auth) seine Scripts entsprechend Mails versenden lassen.

Und was „incoming mail“ angeht… wenn wir hier alle Emailadressen (oder gar Domains), die in der Datenbank unseren virtuellen Usern zuordbar wären, auf die Whitelist setzen, dann wären wir mittellos gegen Spoofing… bestes Beispiel sind die NPD Spammails, welche häufig auch mit gefälschtem Envelope-Sender rausgehen (wobei das natürlich eine andere Ursache hat… aber das ist hier nicht Thema).

Inwieweit hier schon der Tatbestand des § 206 II, Ziffer 2 StGB (Unterdrückung von zur Übermittlung anvertrauten Sendungen) gegeben ist wird derzeit ja noch widersprüchlich diskutiert.
Wenn das aufgrund der bloßen Möglichkeit eines Mißbrauchs geschieht finde ich persönlich, dass das zu weit geht.

Unter der u.g. Adresse findest Du eine umfangreiche Antispamstudie mit allen relevanten Informationen und Entscheidungshilfen.
Lade Dir dort einfach die PDF „Spamstudie des Bundesministeriums für Sicherheit in der Informationstechnologie“ herunter.
http://www.bsi.bund.de/literat/studien/antispam/index.htm

Was die Sache mit den reverse-lookups angeht, so ist das (zumindest hier) nicht das Problem, da (wie bei vielen ISP's) ein entsprechender DNS Eintrag vorhanden ist.

Ich glaube, da verwechselt Du etwas.

Wenn Du von einem lokalen Mailserver eine Mail an unseren Server sendest, dann überprüft das System, ob der Mailserver (hier dein Dial-Up Host) entsprechend seiner IP seinem Hostname über ReverseLookup zuzuordnen ist.

Die einzige Möglichkeit wäre bei Dial-Up, das man eine DynDNS Adresse als Hostname (FQDN) angibt… nur wird hier der Propagationseffekt einen Strich durch die Rechnung machen…

Im Falle des fehlenden oder falschen ReverseLookups erfolgt bei uns ein Reject (immerhin das… es gibt Provider, die verwenden D_DISCARD).

Das mit dem "dedicated Server" ist zwar schön, aber ich brauche und will sowas eigentlich nicht. Lediglich ne feste IP wäre reizvoll .

Und dazu brauchst Du einen permanenten Uplink… eventuell mal bei 'nem Carrier anrufen, ob man Dir nen 1GB Uplink in die Bude legt

Aber hey;
Mir fällt grade ein, dass mein Webhoster (besser gesagt der meines Bruders, aber da hab ich ne subdomain) auch nen Mailserver hat.
Muss ich mir halt da eine Adresse anlegen; der nimmt nämlich (noch) meine "Dial-Up Emails" an.
Insofern: "Rutsch mir den Buckel runter 0und0!" .

Hehe… solange es geht… aber darauf bauen würde ich nicht.

 

[surrender]

danke wieder was gelernt

 

[maceis]

Hallo Yves,

Du hast Recht, der Vergleich hinkt natürlich, aber was besseres ist mir spontan nicht eingefallen.

Und ein Mailserver, welcher von einem Dial-Up Host betrieben wird, ist in den meisten Fällen eine Drecksschleuder… sofern ein Mailserver wirklich ernsthaft genutzt wird, ist auch meist die Frage nach einer „TÜV-Plakete“, respektive einer statischen IP mit Hostnamen und entsprechendem Reverse-Lookup obligatorisch.

Würdest Du den gleichen Maßstab an die Mailclients und/oder Betriebssysteme Deiner Kunden stellen, dann müsstest Du Den Einsatz von Outlook Express und Windows in Euren AGB ebenfalls verbieten.
Woher die Virenflut kommt ist schließlich auch hinreichend "empirisch nachgewiesen".
Abgesehen davon garantiert eine statische IP (die es ja bei Euch auch ohne TÜV gibt) ja nicht, dass ein selbst gemanagter Mailserver plötzlich keine potentielle Dreckschleuder mehr ist.
Gibt genügend Mailserver "mit TÜV", die absolut übel administriert werden.

Mit dem Perl Skript meine ich einen selbstgeschriebenen Client, der problemlos beliebig viele Spam Mails in kurzer Zeit einliefern kann.
Ich hab jetzt nicht nachgesehen, aber ich bin mit ziemlich sicher, dass Net::SMTP AUTH beherrscht (was mich jetzt, wo ich drüber nachdenke, schon wieder auf den Gedanken bringt, dass ich so auch die emails meines privaten postfix bei meinem Provider einliefern kann ).
Klar, dass man das dann zurückverfolgen kann - kann man beim lokal betriebenen Mailserver im Mißbrauchsfall ja ebenfalls.

Dass keine Adressen oder Domains auf die Whitelist gesetzt werden sollten ist mir auch klar; bei den IP Adressen der eigenen Kunden (die sich ja beim "Einwählen" authentifizieren) seh' ich das aber schon als vertretbar an.

Mit dem reverse_lookup hast Du Recht; das geht nur mit dynDNS und entsprechendem $myorigin; das hatte ich ünersehen.
Ich dachte eigentlich, dass bisher nur China/HongKong die dynDomains generell aussperren

Und dazu brauchst Du einen permanenten Uplink… eventuell mal bei 'nem Carrier anrufen, ob man Dir nen 1GB Uplink in die Bude legt

Das machen die sicher; ist nur eine Frage der Bezahlung .
In anderen Ländern ist es ja teilweise etwas einfacher (und billiger) an eine feste IP zu kommen. Aber was soll's.


Fazit des Ganzen:
Ich werd doch tatsächlich mal ausprobieren, ob ich das hinbekomme, über ein Perlskript meine mails einzuliefern.
Denn wie Du sagst; meine aktuelle Lösung ist auch nicht dauerhaft verlässlich.
Nachdem der Postfix so herrlich modular aufgebaut ist, dürfte es auch nicht so schwer sein, so ein kleines "Weiterleitungsmodul" einzubinden.
Da müsste doch schon fast eine pipe in transport reichen *grübel*

 

[sevY]

Würdest Du den gleichen Maßstab an die Mailclients und/oder Betriebssysteme Deiner Kunden stellen, dann müsstest Du Den Einsatz von Outlook Express und Windows in Euren AGB ebenfalls verbieten.

Du weisst selbst, dass das nicht in unseren Kompetenzbereich gehört… und dass diese Maßnahme auch nur flächendeckend ausgeführt etwas bringen würde
Aber prinzipiell müsste M$ (und andere Anbieter von entsprechend nachlässig konzipierter Software) hier zur Rechenschaft gezogen werden! Da würde ich Dir komplett recht geben!
Wir empfehlen übrigens unseren Kunden generell Thunderbird/Firefox bzw. die Mozilla Suite und machen Ihnen dieses schmackhaft, indem wir Ihnen anbieten, dass Sie uns bei Verwendung dieser Clients unter unserer kostenlosen 0800 Supportnummer Step-By-Step eine Installations-/Konfigurationsanleitung bekommen.
Apple User haben wir nur einen Kunden… und der Sack muss ausgerechnet Entourage benutzen

Woher die Virenflut kommt ist schließlich auch hinreichend "empirisch nachgewiesen".

Naklar. Deswegen, wie gesagt, die Softwarehersteller mehr in die Pflicht nehmen, Spammer härter bestrafen bzw. zumindest versuchen intensiver zu verfolgen… gegen Provider wird ja schon rechtlich vorgegangen (mittlerweile macht man sich mit einem OpenRelay unter Umständen strafbar… siehe o.g. BSI Studie).

Abgesehen davon garantiert eine statische IP (die es ja bei Euch auch ohne TÜV gibt) ja nicht, dass ein selbst gemanagter Mailserver plötzlich keine potentielle Dreckschleuder mehr ist.
Gibt genügend Mailserver "mit TÜV", die absolut übel administriert werden.

Ok, das stimmt. Aber man kann halt eine statische IP relativ schnell blacklisten, den Admin ausfindig machen und entsprechende weitere Schritte gemäß eines Abuse-Scenarios einleiten.
Bei Dial-Up Hosts ist das doch kaum möglich… von daher haben statische IPs schon einen gewissen Vorteil bzw. sind gutmütiger als dyn. Ips zu behandeln.

Mit dem Perl Skript meine ich einen selbstgeschriebenen Client, der problemlos beliebig viele Spam Mails in kurzer Zeit einliefern kann.
Ich hab jetzt nicht nachgesehen, aber ich bin mit ziemlich sicher, dass Net::SMTP AUTH beherrscht (was mich jetzt, wo ich drüber nachdenke, schon wieder auf den Gedanken bringt, dass ich so auch die emails meines privaten postfix bei meinem Provider einliefern kann ).

Ok, dann authentifizierst Du Dich ja auch als regulärer Kunde.
Dann ist es ja auch egal, von wo aus und wie Du deine Mails schickst…
Habe ich mich etwa da undeutlich ausgedrückt?

Dial-Up MTAs werden nur rejected, wenn Sie versuchen, ihnen zur Zustellung übermittelte Emails an uns zuzustellen.
Fungiert ein MTA aber (zweckentfremdet) als eine Art Client, der sich regulär authentifiziert, darf er seine Nachrichten abladen, die dann unseren Mailboxes natürlich zugestellt werden.
Möchte der MTA uns als SMTP Relay benutzen, muss er sich natürlich authentifizieren.

Klar, dass man das dann zurückverfolgen kann - kann man beim lokal betriebenen Mailserver im Mißbrauchsfall ja ebenfalls.

Wesentlich schwerer! Bei einer statischen IP ist zunächst das Auswerten von verschiedenen Spamreports einfacher, da so verschiedene Vorfälle anhand derselben IP zusammengefasst werden können.
Dynamische IPs muss man, abhängig von Inhalt, erstmal als jeweils eigenständige Vorgänge ansehen.
Und die Herkunft statischer IPs und das Versenden von Abuse-Mails bzw. das Melden solcher Vorfälle ist so mit dyn. Ips nicht möglich.

Dass keine Adressen oder Domains auf die Whitelist gesetzt werden sollten ist mir auch klar; bei den IP Adressen der eigenen Kunden (die sich ja beim "Einwählen" authentifizieren) seh' ich das aber schon als vertretbar an.

Woher wissen wir denn, wer unserer Kunden sich mit welcher IP im Internet bewegt? Das geht nur, wenn man Fullservice ISP wie z.B. 1&1 ist.
Da könnte man sagen, dass alle IPs aus dem Dial-Up Pool als vertrauenswürdig eingestuft werden.

Mit dem reverse_lookup hast Du Recht; das geht nur mit dynDNS und entsprechendem $myorigin; das hatte ich ünersehen.
Ich dachte eigentlich, dass bisher nur China/HongKong die dynDomains generell aussperren

Wir sperren z.B. die Redirector-Service-Domains nicht generell… wir versuchen zumindest vorher unsere Gutmütigkeit zu beweisen, indem wir einen Reverselookup machen (der aber meistens in die Hose geht).
Schließlich soll es Admins geben, die auf z.B. DynDNS (oder einem anderen Redirector) eine FallOver Strategie bauen… Redirector Domains generell zu blocken halten ich daher für äußerst bedenklich.
Andererseits kann man natürlich sagen, dass es äußerst bedenklich ist, Fallover Strategien auf DynDNS aufzubauen (…was auch so ist ).

Das machen die sicher; ist nur eine Frage der Bezahlung .
In anderen Ländern ist es ja teilweise etwas einfacher (und billiger) an eine feste IP zu kommen. Aber was soll's.

Ich werd doch tatsächlich mal ausprobieren, ob ich das hinbekomme, über ein Perlskript meine mails einzuliefern.
Denn wie Du sagst; meine aktuelle Lösung ist auch nicht dauerhaft verlässlich.
Nachdem der Postfix so herrlich modular aufgebaut ist, dürfte es auch nicht so schwer sein, so ein kleines "Weiterleitungsmodul" einzubinden.
Da müsste doch schon fast eine pipe in transport reichen *grübel*

Alles klar, berichte mal über Erfolg/Mißerfolg!

 

[maceis]

...
Apple User haben wir nur einen Kunden… und der Sack muss ausgerechnet Entourage benutzen

Lass den das mal bloss nicht hier lesen .

...(mittlerweile macht man sich mit einem OpenRelay unter Umständen strafbar… siehe o.g. BSI Studie).

Ja, das habe ich gelesen.
Grundsätzlich ist in dem ganzen Themenbereich aber leider derzeit noch null Rechtssicherheit gegeben, da Gerichten und anderen Staatsorgane halt die Einschätzung der technischen Gegebenheiten recht schwer fällt.

...Woher wissen wir denn, wer unserer Kunden sich mit welcher IP im Internet bewegt? Das geht nur, wenn man Fullservice ISP wie z.B. 1&1 ist.
Da könnte man sagen, dass alle IPs aus dem Dial-Up Pool als vertrauenswürdig eingestuft werden.

Genau das ist mein Wunch.
Und ca. seit Pfingsten hat 1&1 alle Adressen aus dem eigenen Adresspool ge-"blacklisted". Pfui!
...

...
berichte mal über Erfolg/Mißerfolg!

Werd ich machen.
Wir nur evtl. ne Weile dauern bis ich dazukommen.
Das BSI-Teil hab ich mir übrigens runtergeladen und werde da auch mal reinlesen, sobald meine Zeit das erlaubt.

 

[asg]

Auch in einem geschäftlichen Umfeld kann der Einsatz eines internen Mailservers u. U. sehr sinnvoll sein.
Schade, wenn die mißbräuchliche Nutzung des Internets durch einige, zur undifferenzierten Beschränkung aller Nutzer führt.
Das wiederspricht auch meinem persönlichen Rechtsempfinden.

Naja, es ist schon gut so das nicht jeder einen eigenen DNS und seinen eigenen mailserver betreiben darf.

Nein, sowas:

host my.provider.de[xxx.xxx.xxx.xxx] refused to talk to me: 550 RBL rejection: direct deliveries from this dynamic/dialup ip refused, use your ISP's smarthost.

Und das bei den Adressen der eigenen Kunden.
Bisher musste man nur bei T-Online extra was zahlen, wenn man (z. B. als Firma) einen eigenen Mailserver benutzen wollte.
Aber offensichtlich geht die Tendenz dazu, eigene Server grundsätzlich nur noch gegen anständig Kohle zuzulassen ;(.

Ich würde mal sagen die Leute mit dem dial-in verbindungen sollten als RELAY in bei ihrem Mailserver einfach den ihres Provider angeben. Dann gehen die mails zuerst zu diesem und dann raus, damit sollte das Problem gelöst sein.

 

[Saintine]

Dazu fällt mir eine Geschichte ein, die sich vor ein paar Tagen abgespielt hat. Mein Freund (Win User, noch) hat mir erzählt, dass ich mir da nicht mehr so sicher sein soll, dass es für meinen ach so geliebten Mac keine Viren gint. Er hätte gelesen, dass schon "diverse" in den Startlöchern stehen...

 

[asg]

Naja… dafür haben wir immer noch Heartbeat im Einsatz (für Fallover bei Hardwareausfällen oder eben auch DoS…) und in AmaVis entsprechend immer einen Fallback Service, wenn z.B. mal Clamd nicht mehr will (hat sich in der Vergangenheit ja gerne mal die DB geschossen und dann weggehängt…).

Wenn Du einem DoS ausgesetzt bist dann wird das heartbeat auch nicht viel bringen. Ist der Master nicht mehr erreichbar nimmt der Slave die Arbeit auf und wir direkt mit sinnfreien Anfragen bombardiert. Das macht auch diesem dem gar aus.
Es ist leider so das man DoS Angriffe nur aussitzen kann, denn die IP zu sperren von wo der Angriff kommt wird kaum etwas bringen da es meist tausende verschiedene IPs sind.
Btw. die Krücke heartbeat lief bei uns auch bis ich meinen Chef endlich davon überzeugen konnte den ganzen SuSE Linux Dreck zu entsorgen und FreeBSD zu nutzen. Nun rennt da PF als Firewall und CARP+pfsync für einen transparenten Cluster der Firewalls. Sehr schöne Sache und um längen besser als heartbeat.

Ja… wir waren bis vor 8 Monaten leider auch noch ein offenes Relay… aber mittlerweile geht es nicht mehr anders… auch wenn die Kunden reihenweise gejammert haben, weil Sie die Outlook Express Option für SMTP-Auth nicht gefunden haben (und die Newsletter ignorieren).

Hehe, jaja die lieben Kunden und User.

Wer also via SSH kompromitieren möchte, muss erstmal den „Steuerungsserver“ ausfindig machen, da nur seine IP akzeptiert wird… und auf dem läuft ein BSD Derivat und nichts anderes als SSH… also kaum ein Ansatzpunkt.

Was ssh angeht kein Ansatzpunkt, andere wären da nur die anderen Dienste die von aussen erreichbar sind, aber das geht nun zu weit.
Nein, um ssh mache ich mir auch keine Sorge wenn es keys gibt.

Aber es geht generell auch um den Ärger den man bekommen kann, was Arbeitszeit angeht… man kann seine Kunden noch so sehr aufklären, Sie mögen bitte nur FTP/TLS und IMAPs, POP3s, sSMTP verwenden… nichts ist… das wäre ja Umstellung. Und wenn dann mal irgendwo zwischendrin ein paar TCP/IP Päckchen dumped werden und im schlimmsten Fall das Homeverzeichnis versaut wird, ist das Geschrei groß…

Hör mir auf mit Umstellung.
Unsere Kunden schubsen uns via FTP Daten rüber und holen diese ab. Es sind ca. 150 Kunden und davon machen mittlerweile gerade einmal 6 Secure FTP. Die anderen sind zu faul oder zu blöde. Ich rechne bald mit zweiterem so oft wie wir für die Support machen dürfen (was absolut nicht unsere Aufgabe sondern die der IT dort ist).
Da hilft es auch nicht wenn ich mit ngrep das PW mitlese und es ihnen unter die Nase halte.

 

[asg]

Das mit dem "dedicated Server" ist zwar schön, aber ich brauche und will sowas eigentlich nicht. Lediglich ne feste IP wäre reizvoll .

Schau Dir dann mal www.kamp-dsl.de an.
Ich bin dort über zwei Jahre und habe seitdem auch dort eine statische IP. Inkl. MX Eintrag auf deren DNS welcher auf meine IP und somit auf meinen Server unterm Dach zeigt.
Ich kann es nur empfehlen.