Beiträge von dfroe

    Hallo,
    das Fehlen des lo-Devices ist korrekt. Wenn du dich an den Support wendest kannst du allerdings ein eth-Alias mit einer IP-Adresse aus dem privaten 10er-Subnetz bekommen. Das ist dann zwar kein Loopback-Device, aber immerhin eine IP-Adresse, die nicht ins Internet geroutet wird. Du musst dann nur darauf achten, sämtliche Anwendungen auch auf die 10er-IP zu binden, da viele per Default eben ausschließlich das lo-Dev verwenden.

    Hallo,
    ich habe mein Bash-Script nun so weit vervollständig, dass dieses nun endlich was sinnvolles macht. :)


    Es holt sich die Traffic-Daten direkt vom vservercontrolpanel, man kann sich also sicher sein, dass die ermittelten Werte auch tatsächlich korrekt sind (bzw. zumindest mal die sind, die später auch auf der Rechnung erscheinen :rolleyes:)


    Das Skript lässt sich über drei Wege aufrufen:


    1.) Wenn man das Script einfach ohne irgendwelche Argumente ausführt gibt es den Traffic (incoming, outgoing, total) in MB und mit Semikolon getrennt aus. Diese Werte ließen sich dann z.B. in eine Datenbank einpflegen.


    2.) Wenn man dem Script als Argument eine Ganzzahl übergibt, so wird der Traffic wie in 1.) ausgegeben, allerdings nur dann, wenn der TotalTraffic größer ist als die per Parameter übergebene Ganzzahl. Beide Werte wieder in MB.


    3.) Man übergibt als ersten Parameter eine Ganzzahl (Traffic in MB) und als zweiten Parameter eine Mail-Adresse. Übersteigt nun der TotalTraffic das angegebene Limit, so wird automatisch eine Benachrichtigung an die angegebene Mail-Adresse verschickt.


    Ideal wäre nun das Script nach Methode drei immer um 23:59 UTC (d.h. 00:59 Uhr) per CronJob zu starten. War an dem Tag der Traffic-Verbrauch übermäßig hoch findet man am nächsten Morgen eine entsprechende Mail in seinem Postfach und kann nach eigenem Ermessen darauf reagieren. Setzt man die Traffic-Grenze auf InklusivTraffic/30 dürfte eigentlich nichts mehr schief gehen solange man keine Warn-Mail bekommt. :)


    Das Bash-Script benötigt wget, awk, mail und die bash.
    Auf Debian-Systemen tut's folgender Befehl:
    "apt-get install bash wget mawk mailx"


    So, dann viel Spass beim Füttern eurer Cron-Tabs. :D


    Bash-Script "vservertraffic":

    n'Abend,
    ich hab mir mal ein kleines Bash-Script gebastelt, welches sich auf dem vservercontrolpanel einloggt und dort den Traffic des heutigen Tages ausliest. Nach der Ausführung gibt das Script Traffic_Incoming, Traffic_Outgoing und Traffic_Total (in GB) jeweils durch Semikolon getrennt aus.


    Wenn man nun dieses Script immer um 23:59 UTC ausführt und die Ergebnisse in eine CSV-Datei, Datenbank, o.ä. schreibt, lässt sich mit diesen Daten dann machen was man will.

    Tach,
    das mag ja so schon stimmen, ich bin mir nur eben nicht sicher, ob die Werte, die vnStat dadurch übermittelt bekommt, auch tatsächlich stimmen. Sicherlich kann man den Traffic auf den Zeitraum runterechnen in dem er angefallen ist usw.. Wenn nun aber einfach die Trafficmenge, die vnStat zu Gesicht bekommt, falsch ist, lässt sich da auch nicht mehr viel ausbessern.
    Es ist mir eben einfach nur aufgefallen, dass der Traffic des eth-Devices definitiv nicht nur mein eigener Traffic ist.

    Jep, den Hinweis auf vnStat habe ich schon gesehen. :)
    Dort steht "The traffic information is analyzed from the /proc filesystem". Wenn ich auf meinem vServer den Traffic über /proc/net/dev auslese, so stehen dort bei mir aber auch die 200 GB.
    Und das Programm vnStat greift wenn man es ausführt auch auf die o.g. proc-Datei zu.


    Code
    edv-froehlich:~# strace vnstat -u -i eth0 2>&1 | grep proc
    open("/proc/net/dev", O_RDONLY)         = 3

    Daher bin ich immer noch der Meinung, dass das Programm in dieser von Netcup eingesetzten vServer-Umgebung nicht brauchbar ist.

    Hallo,
    die Idee für ein solches Tool könnte durchaus interessant sein, aber wenn du den Traffic einfach über das ethX Device abrufst wirst du falsche Werte erhalten.
    Das eth0-Device meines vServers hat laut ifconfig jeweils über 200 GB versendet und empfangen. Dies ist aber für meinen vServer um Längen zu hoch angesetzt (habe gerade einmal 2 GB seit bestehen des vServers übertragen).
    Ich vermute, dass das Gastsystem hier auch einfach den gesamten Traffic des eth-Devices des Wirtssystems zu sehen bekommt.
    Somit bräuchte man wohl einen anderen Ansatz, als einfach nur das ethX Device abzufragen.


    Eine Möglichkeit wäre es, über ein Script sich auf dem vservercontrolpanel einzuloggen und dort dann die Traffic-Seite zu interpretieren. Ich denke, das ist die einzige zuverlässige Möglichkeit, korrekte Daten zu erhalten.

    Was mir dazu gerade noch einfällt:
    Es könnte unter Umständen auch der Fall gewesen sein, dass du Opfer einer Brute-Force Spam-Attacke geworden bist. Und zwar gibt es Spam-Bots, die auf der Suche nach neuen Opfern einfach etliche Mail-Adressen einer Domain auf gut Glück durchprobieren, bis sie eine gültige Mail-Adresse gefunden haben. Eine Adresse der Form vorname.nachname@ ist nun relativ lang, und der Spam-Bot würde da nur durch probieren nicht ohne weiter draufkommen. Wenn du als Mail-Adresse allerdings einfach nur b@ hast, dann ist die Chance diese Adresse zu erraten relativ hoch. Vielleicht könnte aus auch damit was zu tun haben, ist aber nur reine Spekulation.

    Okay, 3000 solcher Mails ist natürlich "nicht normal".
    Alternative: Könnte es sein, dass dein Server Spam eine eine Adresse ...@furanat.com (in diesem Beispiel) schickt, und der Mail-Server bei Furanat diese Spam-Mail dann einfach wieder an dich zurück schickt (z.B. weil der Empfänger nicht existiert)?
    Schau doch da mal in der mail.log nach irgendwelchen Auffälligkeiten. Du kannst auch einfach testweise mal den Apache anhalten und beobachten ob dann eine Besserung eintritt. Wenn da nämlich irgendein PHP-Skript zum Versenden von Spam missbraucht wird, sollte kein Spam mehr rausgehen wenn der Apache nicht läuft.
    Sollte es tatsächlich ein PHP-Skript gewesen sein, dass zum Spam-Versand missbraucht wird, bleibt abschließend nach dem Finden des Fehlers noch zu hoffen, dass dein Server dadurch nicht bei Spamhaus&Co. geblacklistet wurde.

    Hallo,
    SPF ist sicherlich ein möglicher Lösungsansatz, ob man das aber tatsächlich einsetzen möchte, ich weiß nicht so ganz. Schließlich kann ich z.B. auch von meinem GoogleMail-Konto aus eine Mail verschicken, die als Absender-Adresse meine GMX-Adresse trägt. Oder wenn ich diese EMail-Flatrate von T-Mobile nutze werden meine Mails auch über den T-Online Mail-Server verschickt; mit GMX-From-Adresse. Solche Mails würde das SPF dann ebenfalls aussortieren.


    Aber was deine konkrete E-Mail angeht, so ist das wie bereits gesagt eindeutig:

    Code
    Received from post.senzor.dk by root.hubutz.de for <b@achmann.de>

    Der Server post.senzor.dk hat eine Verbindung zu deinem Server root.hubutz.de aufgebaut, um darüber eine Mail an b@achmann.de zu übermitteln. Was in dieser E-Mail (nach dem DATA-Befehl) aber als To und From übertragen wird, da können ganz einfach beliebige Mail-Adressen drin stehen. Somit hat einfach irgendein (Spam-)Mailserver dir direkt eine Spam-Nachricht zugeschickt. Die To und From Felder können dabei frei erfunden sein. Von daher, keine Panik, das ist einfach eine ganze normale Spam-Nachricht, so wie sie in jedem Musterbeispiel genannt werden könnte. :)


    Was ich nun aber an dieser Mail konkret bei dir etwas vermisse: Der PolicyD-Weight. Dieser scheint hier nicht zum Einsatz gekommen zu sein. Andernfalls sollte der nämlich auch seine Spuren im Header hinterlassen haben (X-policyd-weight).

    Hallo,
    dass sämtliche Ordner "Unterodner von INBOX" sind, ist soweit schon korrekt. Wenn du deinen Mail-Client aber korrekt konfigurierst, zeigt es dir diese Ordner auf der gleichen Ebene an als die Inbox. Und zwar musst du einfach als Ordner-Präfix "INBOX" bzw. "INBOX." angeben. Im Thunderbird nennt sich diese Option "IMAP-Server-Verzeichnis" bei den Erweiterten Konto-Einstellungen. Dort einfach "INBOX" reinschreiben und Thunderbird neustarten. Bei Web-Frontends sollte das ähnlich funktionieren, sofern diese eine Option für dieses IMAP-Basis-Verzeichnis mitbringen. So etwas wie "Oberordner" wirst du nicht hinbekommen, da meines Wissens nach der Inbox-Ordner quasi das Root-Directory deiner Mails darstellt.

    n'Abend,

    Zitat

    für reverse DNS ist nicht der Betreiber des DNS zuständig, der die Domain beherbergt, sondern der Besitzer des IP-Blocks


    Ja, das würde ich so unterschreiben. Wenn ich falsch liegen sollte lasse ich mich aber auch gerne korrigieren.

    Zitat

    auch wenn beide häufig ein und derselbe sind


    Das würde ich nicht so pauschal stehen lassen. Es kann ein und derselbe Provider hierfür zuständig sein, aber eine bestimmte Wahrscheinlichkeit würde ich dafür nicht angeben wollen.
    Die IP-Adresse gehört dem Provider deines Servers, aber eine Domain kannst du bei jedem x-beliebigen Anbieter registrieren und den A-Record dieser dann auf die IP-Adresse deines Server setzen. Ich kann bei HostEurope einen vServer anmieten und bei Domainfactory eine Domain erwerben, die ich dann auf den vServer zeigen lassen. Das funktioniert mit jeder beliebigen Provider-Konstellation.

    Hallo Tim,
    wie bereits von Felix gesagt: Kurze Mail an den Support und gut ist.
    Wenn du eine Domain für den vServer hast ist es sicherlich immer eine gute Idee, auch den rDNS-Eintrag dementsprechend zu setzen. Zum einen was eventuell das Spam-Problem betrifft, und zum anderen sieht ein rDNS auf die eigene Domain auch einfach schöner aus, als auf so einen anonymen Standard-Eintrag. :)

    Hallo,
    gern gescheh'n, kein Ding. Das war jetzt auch für mich schonmal eine gute Trockenübung, bevor ich das selber in ein paar Tagen auf einem Netcup-vServer praktizieren darf. Da es sich hierbei allerdings um ein Produktiv-System handelt, dass funktionieren muss, war das jetzt hier schonmal ganz gut, um quasi sämtliche Parameter aufzuspüren, die auf die private IP-Adresse angepasst werden müssen. :)


    Wenn du im Laufe der Zeit merken solltest, dass es doch zu false positives kommt, oder zu viele Spam-Mails dem SpamAssassin durch die Finger gehen, dann kannst du auf jeden Fall mal mit dem Parameter sa_tag2_level_deflt herumspielen. Die Score-Threshold von 5.0 passt nun bei mir zwar recht gut, das kann bei dir u.U. aber wieder anders aussehen. Du siehst ja in jeder Mail die jeweilige Score, so dass du das ggfs. anpassen kannst.


    Dann viel Spass beim Filtern-Lassen des Postfachs; auch wenn der PolicyD-Weight nur Mails sinnvoll filtert, die direkt an den vServer geschickt werden; Weiterleitungen von GMX&Co. gehen da auf jeden Fall durch. Aber für den Fall hast du dann ja immer noch den Amavis/SpamAssassin.

    Supi, na das ist doch mal was. ;)
    Du kannst den Parameter mydomain natürlich auch irgendwie korrekt konfigurieren, aber da das bei mir auch nur Probleme gemacht hat, hab ich ihn einfach leer gelassen, was nichts weiter heißt, als alle Domains zu scannen. Und außer den Mails für mich wird der Postfix da schon nichts annehmen; hoffe ich zumindest. :)


    Den SpamAssassin nun aber mit dem Bayes-Filter zu trainieren wird relativ kompliziert sein. Du müsstest ihn über den Befehl sa-learn mit Ham und Spam füttern und die daraus gewonnene Bayes-Datenbank dann mit dem Amavis verknüpfen. Und dieser Lern-Vorgang gestaltet sich beim SpamAssassin relativ langwierig.
    Was diesen Punkt betrifft müsste ich dann passen.


    Aber ich behaupte mal, dass die Menge an Spam, die durch den PolicyD-Weight und den Amavis/SpamAssassin durchkommt, verschwindend gering sein sollte, so dass sich der Aufwand für einen Bayes-Filter wahrscheinlich gar nicht erst lohnt.

    Hallo,
    der Amavis-Alert ist schonmal nicht schlecht, sowas kommt immer dann, wenn eine E-Mail nicht standard-konform ist. Hier z.B. kein korrektes MIME, häufig kommt sowas auch, wenn Umlaute im Header nicht korrekt kodiert sind.


    Aber hast du mal probiert, die mydomain-Zeile wirklich so zu setzen wie ich's da reingeschrieben habe:


    $mydomain = '';


    Also nicht durch deine Domain o.ä. ersetzen, sondern einfach nur so mit einer leeren Zeichenkette stehen lassen. Das führt dann dazu, dass der Amavis nicht nur Mails an mydomain sondern grundsätzlich alle eingehenden Mails scannt. Vielleicht bringt's was. Der Rest deiner Config sieht nämlich ganz gut aus.

    So, dann schaun wir mal.
    Die Mail wird auf jeden Fall schonmal durch den Amavis durchgeschleust, d.h. der Postfix leitet sie an den Amavis weiter und dieser schickt die abgearbeitete Mail anschließend wieder an den Postfix zurück. Das sagen uns die beiden Received-Zeilen.


    Soweit, sogut. Amavis bekommt die Mail also, möchte sie aber aus irgendeinem Grund nicht verarbeiten. Könnte gut sein, dass der Amavis meint, für das Scannen dieser Mail nicht verantwortlich zu sein. Damit hatte ich anfangs bei meiner Installation auch ein paar Schwierigkeiten.


    Mal schauen, was ich dazu so an Amavis-Einstellungen bei mir finden kann.

    Code
    $mydomain = '';
    @local_domains_acl = ( ".$mydomain" );
    chomp($myhostname = `hostname --fqdn`);
    $X_HEADER_LINE = "Debian $myproduct_name at $myhostname";


    Zur Einbindung des SpamAssassin habe ich noch folgende Zeilen bei mir gefunden:

    Code
    @bypass_spam_checks_maps = (
       \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);
    $final_virus_destiny = D_DISCARD;
    $final_banned_destiny = D_REJECT;
    $final_spam_destiny = D_PASS;
    $final_bad_header_destiny = D_PASS;


    Vielleicht bringt dir das noch was, ansonsten müsstest du mal schauen, ob sich dem Amavis-Daemon während des Scan-Vorgangs irgendwie eine Meldung entlocken lässt, warum er diese Mail ungescannt passieren lässt.


    Aber eins steht fest, wir stehen kurz vor dem Ziel: Postfix und Amavis bekommen alle die Mail so zu sehen wie es sein soll, nur lässt sie der Amavis ohne zu scannen passieren. Das kann nur noch eine Kleinigkeit sein. :)

    Tach,
    ja, das mit der Zusammenfassung ist sicherlich keine schlechte Idee. Werd mal schauen, ob sich da was machen lässt.


    Und um dich ein wenig zu entwirren: Wir haben AmavisD-New eingerichtet, korrekt. Nur was war ist denn nun eigentlich AmavisD-New? ;)


    AmavisD-New ist ein sog. Content-Filter, der z.B. in Postfix eingebunden werden kann. Jede Mail wird nun also nach deren Annahme an den Amavis geschickt, dieser macht "irgendwas" mit ihr, und schickt sie wieder an den Postfix zurück.


    Der Amavis selber kann nun vorallem zwei Dinge ganz gut: Die Mail durch einen Virenscanner durchschleußen und - was mehr Sinn macht - den SpamAssassin drüber laufen lassen. Dabei wird nun kein eigener SpamAssassin-Daemon benötigt, denn der Amavis lädt beim Starten die SA-Libraries (Perl-Module) mit in den RAM und wendet diese dann auf die Mails an. Dieses Mitladen der SA-Module ist auch der Grund dafür, warum der Amavis-Daemon relativ viel RAM verbraucht.


    Unterm Strich sollte eigentlich der SpamAssassin nun bereits deine Mails durchleuchten. Zur Kontrolle kannst du dir einfach mal den Quelltext einer eingehenden Mail anschauen, und da dann ganz genau die Kopfzeilen:


    Code
    X-Virus-Scanned: amavisd-new


    Das heißt, die Mail ist auf jeden Fall schonmal durch den Amavis durchgelaufen.


    Code
    X-Spam-Status: No, score=-2.599 [...]


    Hier siehst du den Status des SpamAssassin und dessen Score für diese Mail.


    Sollte das nicht wie gewünscht funktionieren einfach mal mit "apt-get install spamassassin" überprüfen, ob die SpamAssassin-Module tatsächlich installiert sind. Kann nämlich sein, dass der Amavis diese nicht gleich durch eine Abhängigkeit mit installiert. Den SA-Daemon brauchst du aber jedenfalls nicht starten, kannst also in der Datei /etc/default/spamassassin ENABLED=0 setzen.

    Tach Benny,
    na dann war das mit deinem Mail-Server nun fast so eine schwere Geburt wie mein Abitur; es ist ein langer Weg bis zum Ziel, aber am Schluss zählt nur das Ergebnis: Es funktioniert, bzw. (zu 99%) bestanden. ;)


    Wie dem auch sei, Amavis-Tutorials dürftest du im Internet reichlich finden. Ansonsten kann ich dir hier mal noch kurz und knapp die Zeilen nennen, die bei mir sehr gute Ergebnisse liefern (auch wieder in der 50-user ergänzen):


    Code
    $sa_spam_subject_tag = '***SPAM*** ';
    $sa_tag_level_deflt  = -9.9;
    $sa_tag2_level_deflt = 5.00;
    $sa_kill_level_deflt = 99.0;
    $sa_dsn_cutoff_level = 10;

    Damit werden alle Mails mit einer SpamAssassin-Score von mindestens 5.0 als Spam behandelt und mit dem Subject-Tag ***SPAM*** versehen.


    Du kannst noch Virenscanner wie z.B. ClamAV einbinden. In meinen zwei Jahren in denen ich Amavis bisher einsetze wurde aber noch nie eine Mail wegen eines Virusfundes abgelehnt; außer Test-Mails mit absichtlichen Viren. :)


    Ich glaube schlussendlich haben wir mit diesem Thread jetzt hier eine ganz nette "Anleitung" aufgestellt, wie man Postfix mit PolicyD-Weight, Amavis und SpamAssassin auf den netcup-Servern ohne Loopback-Device einrichtet. :cool:


    Das werde ich dann auch gleich nachahmen können wenn mein vServer zum Monatswechsels auch zu netcup umzieht; im Moment habe ich hier nämlich nur meinen Secondary (Backup) vServer liegen. Auf diesem habe ich aber nur einen einfachen Mail-Daemon laufen; der muss auch nur Mails handhaben wenn mal der Primary vServer ausfallen sollte.