Spamattacken Postfix optimieren

  • Jetzt kann ich es mir auch nicht mehr verkneifen...



    [...]


    Sicher aber auch deswegen weil jede noch so kleine Sicherheitslücke in einem der CMS-Systeme eine Spamschleuder unter Linux ermöglicht.
    [...]


    Nur zur Info: Es wird weder Linux noch Windows bei einem (meist auf PHP basierenden) CMS ausgenutzt... Wenn schon den schon wäre es PHP selbst, welche es die Lücke zulässt! Lass die Seite rein HTML und dein Linux/Windows-Server wird, sofern das Passwort nicht geknackt wurde oder eine andere Lücke gefunden wurde, kein Spam versenden. Vorausgesetzt, du hast kein Open-Relay eingerichtet.


    Es gibt auch unter IIS und php die Mailfunktion von php! Daher zieht der Vergleich: Windows versendet weniger Spam in diesem Falle überhaupt nicht, da ja auch unter Windows (ob jetzt Apache2 oder IIS) PHP genutzt und somit ein CMS ausgenutzt werden kann.


    Nur zur info:
    ms empfiehlt den ie bis auf weiteres nicht zu nutzen da eine sicherheitslücke einem angreifer alle rollen und rechte am pc offenlegt.


    Der ganze Threat entwickelt sich ja richtig zum Kindergarten. Können wir betreffend Windows vs. Linux nicht einmal sachlich bleiben? Die Heartbleed Lücke war ja schliesslich auch zwei Jahre lang offen und niemand hats gekümmert bzw. entdeckt. In jeder Software gibt es Fehler (kleine, grosse, extrem grosse)... Da ist weder Linux, Windows noch Mac OS X eine Ausnahme.


    Ob über Linux bzw. Windows weniger für Spam verwendet wird, kann ich statistisch nicht belegen. Fakt ist: Ich habe von beiden Betriebssystemen regelmässig Spam-Nachrichten. OS X Server kommt am seltensten vor...


    Das Problem an und für sich lässt sich zur Zeit schlecht eindämmen. Und den Schwarzen Peter an Joomla zu schieben, empfinde ich persönlich als ein wenig thörig! Früher war Joomla sicher häufig heimgesucht. Das Problem war und ist immer noch, dass die Leute Ihre Joomla-Installation schlicht und einfach zu wenig warten. Und unterdessen liegt es meist nicht einmal mehr an Joomla selbst, sondern an einer schlampig programmierten Extension... Ich betreue unterdessen 28 Joomla Installationen. Es wurde noch keine einzige gehackt bzw. für Spam-Mails verwendet.



    Um den Mailserver (SMTP/POP3/IMAP) abzudichten reicht es im Normalfall, ip2ban richtig zu konfigurieren. Zusätzlich kann man ja per iptables noch ein Ratelimit einrichten.
    Bei Apache2 und PHP gibt es diverse Sicherheits-Tools, welche genutzt werden können. Modsecurity ist dabei sicherlich auch keine schlechte Wahl.


    Schlussendlich ist es auch ein abwegen zwischen: "Wieviel Aufwand (Kosten) gegen wieviel Nutzen (Gewinn)"
    Wobei jedes Sicherheits-Tool und jede Absicherung wieder "unbequeme" Arbeit mitbringt. <- Und genau hier liegt das Problem der Admins meine Damen und Herren!


    Zusätzlich ist überall der Kosten-/Zeit-Druck im Nacken, sowie: Alles muss möglichst günstig für den Kunden sein (vorallem beim Webhosting) und jederzeit funktionieren.


    Greez
    Fluser

  • Offtopic:


    Sorry wenn meine letzte Nachricht falsch interpretiert wurde.
    Ich wollte damit nur eine aktuelle Sicherheitswarnung teilen. War sicherlich der falsche Thread.


    Quelle: http://www.chip.de/news/Intern…rnen-vor-IE_69411713.html


    Haha, ok. In diesem Fall muss ich mich bei dir entschuldigen! Ich reagiere unterdessen extrem allergisch gegen diese streitereien oder etwas, was in diese Richtung geht ;) Ich verstehe einfach nicht, wieso man sich gegenseitig wegen einem Betriebssystem (Windows vs. Linux vs. OS X bzw. iOS vs. Android vs. Windows Phone) das Leben so zur Hölle machen muss. Alle haben ihre Berrechtigung zu existieren! Und solange jedes weiterentwickelt wird und Löcher geschlossen werden sowie die Admins wissen was sie tun(!), sehe ich keine Grund, auf dem anderen herum zu hacken... :P Schliesslich ist Linux auch nicht gleich Linux. So verhält es sich meiner Meinung auch bei den anderen Betriebssystemen. Ob ein System sicher ist oder nicht hat auch mit der installierten Software / den Treibern zu tun. Ebenso, welche Hardware benutzt wird (z.B. UEFI Boards unter Linux sind ja auch nicht immer der Hammer bzw. Stabil (siehe z.B. Samsung Note-/Netbooks)) :rolleyes:


    Jetzt ist mein Beitrag schon wieder viel länger geworden als gewollt... Was solls :blush:


    Greez
    Fluser

  • Um nochmal auf das zurück zu kommen, was Menky sagt ... Das ist Bullshit ... Spammails werden fast immer über unsichere PHP-Scripte versendet... Ist mir ebenfalls bereits 2-3x untergekommen. Eine Limitierung ist das lächerlichste überhaupt .. Nicht PHP ist dafür Schuld, nicht Linux, nicht Apache oder sonstwer ...


    Reintheoretisch ist der Entwickler des CMS, welches ausgenutzt wurde verantwortlich, weil dieser seine PHP-Scripte nicht abgesichert hat. Hier liegt meist der Kater ... Allerdings ist das fast utopisch, selbst der beste Programmierer übersieht etwas ... leider ... Menschlich ;-=)


    Nochmal die Limits, das ist Bullshit .. Mal hab ich 2 Mails am Tag .. mal über 100 .. Ein User vlt auch mal über 10k weil Newsletter raus gehen .. das händisch anzupassen .. pfiff ..


    Meine Lösung: Es läuft nen Script alle 10min ... Der checkt wieviele Mails in der Queue liegen .. über 100 werde ich benachrichtig, es wird geguckt ob die Mails okay sind oder Spam .. Falls Spam, 1. Klick die sind weg, 2. Klick der entsprechende User ist gesperrt ... Dann laufen noch paar Mails in die Queue bis der Prozess damit fertig ist und weg .. Somit konnte bislang eine Spamattacke ausgehobelt werden, gingen im Endeffekt vlt 2-3 hundert Mails raus. Die Attacke davor, wo noch nichts implementiert war, waren es über 10k Mails .. man lernt draus ;-)


  • Meine Lösung: Es läuft nen Script alle 10min ... Der checkt wieviele Mails in der Queue liegen .. über 100 werde ich benachrichtig, es wird geguckt ob die Mails okay sind oder Spam .. Falls Spam, 1. Klick die sind weg, 2. Klick der entsprechende User ist gesperrt ... Dann laufen noch paar Mails in die Queue bis der Prozess damit fertig ist und weg .. Somit konnte bislang eine Spamattacke ausgehobelt werden, gingen im Endeffekt vlt 2-3 hundert Mails raus. Die Attacke davor, wo noch nichts implementiert war, waren es über 10k Mails .. man lernt draus ;-)


    Wieso nimmst du nicht einfach Nagios und lässt dich so automatisch informieren? Gibt dort Warn/Critical Limits und weitere Dienste kannst du damit auch prüfen ;)


    Noch ein kleiner Nachtrag zu deinem Post:


    Quote

    Reimtheoretisch ist der Entwickler des CMS, welches ausgenutzt wurde verantwortlich, weil dieser seine PHP-Scripte nicht abgesichert hat. Hier liegt meist der Kater ... Allerdings ist das fast utopisch, selbst der beste Programmierer übersieht etwas ... leider ... Menschlich ;-=)


    Ist eigentlich genau das, was ich ausdrücken wollte, es aber irgendwie nicht hinbekommen habe

    Quote

    ...Wenn schon den schon wäre es PHP selbst, welche es die Lücke zulässt!...