Beiträge von browsingman

    Ich habe auch einige Wildcard-Zertifikate im Einsatz und das Verhalten tritt bei mir genauso auf.
    Was für mich auch logisch wäre, denn ich vermute mal das hier einfach der Common Name des Zertifikates mit dem DNS-Namen des Webauftritts gematcht wird.


    Sollte das zutreffen, wäre es sinnvoll, die Prüfung im pd-admin abzuändern, da viele Kunden Wildcard-Zertifikate nehmen und über sub-Domains unterschiedliche Inhalte abbilden.

    Ich würde im Maillog mal schauen, wohin dieser Mail-Account Mails versendet.
    Wenn es viele verschiedene Adressen sind, die teils nur leicht variieren, dann würde ich darauf tippen, das das Passwort des Mail-Acounts von einem Trojaner entwendet wurde und von einem Bot missbraucht wird.

    Für diejenigen, welche es interessiert:
    Ich habe das von tooliload zur Verfügung gestellte addon bei mir auf einem Server testweise im Einsatz und kann sagen, das dies bereits einen erheblichen Beitrag zur Vermeidung von Ärger geleistet hat.


    Konkret hat ein Kunde auf seiner Wordpress Präsenz ein unsicheres Addon verwendet, das vom SteelRat Botnet entsprechend ausgenutzt wurde.


    Dank des Addons gingen nur die ersten 50 dieser Mails raus (festgelegtes Limit auf Spam-Erkennung) und über 3700 Mails wurden abgefangen und einfach gedropped.


    Vorteile:
    1. Server wird gar nicht erst im cbl gelistet
    2. Fehlerbereinigung (Identifizierung des Skriptes) ist leichter und kann zudem in Ruhe durchgeführt werden
    3. Serverlast bleibt niedrig, da die Mails gar nicht erst in der Queue landen


    An dem Grundproblem (Verwendung unsicherer php-Skripte seitens des Kunden) wird das zwar nichts ändern können, aber es ist meiner Meinung doch ein erheblicher Beitrag zur Schadensbegrenzung.

    Meine TOP3 wären (in genau dieser Reihenfolge):


    - Mail-Wrapper für PHP, der beim Nutzen der php Mail-Funktion prüft, ob ein bestimmtes Limit beim Mail-Versand überschritten wird und dann ggfs. den Mail-Versand blockt
    (in php.ini Verweis auf einen Wrapper a la sendmail-php und dort die Funktionalität einbauen)


    - Dovecot als Standart Imap Server, Courier weg und alle Mailboxes konvertieren damit kein Resync nötig ist. Durch einen standard Server eventuell dann über PD-Admin konfigurierbar machen (Zertifikat für SSL über Webinterface einrichten usw).
    (einfach mal aus einem anderen Beitrag übernommen, weil sinnvoll ....)


    - Tool um Accounts von einem PD-Admin Server auf einen anderen umzuziehen, inklusive Config, Mailboxen, Datenbanken und Daten. Exporta in ein Accountpackage auf Server A und Import des gleichen Accounts auf Server B.
    (auch übernommen aus einem anderen Beitrag, weil ich genau das schon EWIG vermisse)

    Hallo,
    Das wäre super. Ich verwende die Einstellung FastCGI... Scheint mir bisher die sicherste zu sein.


    Mein Ansatz wäre ein sendmail Wrapper gewesen, auf den ich dann in der php.ini verweise und dann im Wrapper auch ein Limit einzuführen.....

    Hallo zusammen,


    ich habe regelmäßig das Problem, das irgendwelche Botnets über WordPress, e107 oder andere CMS Systeme eine Möglichkeit finden, sich zu verewigen und dann Mails über meine Server zu versenden.


    Bis jetzt habe ich noch keine Möglichkeit gefunden, dafür Sorge zu tragen, das über die php mail() Funktion nur Mails mit passender Authentifizierung bzw. Mails mit bestimmten Merkmalen versendet werden dürfen.


    Da ich auch mit fail2ban nur bestimmte Situationen abfangen kann, stellt sich mir die Frage, wie man hier eine dauerhafte Lösung finden kann.


    Kennt hier jemand schon eine Lösung (so a la chainmail für sendmail) oder hat eine Idee?


    Falls nein, würde ich mir wünschen, das hier eine Lösung geschaffen wird.

    Hmm,


    muss wohl ne andere Linux Distribution sein.


    Ich habe CentOS (noch die 5.x Reihe) und da habe ich nur:
    /var/log/secure
    /var/log/messages


    Da sehe ich nirgends irgendwelche Logins vom FTP Service.
    Wie sieht denn deine /etc/syslog.conf aus?

    Na Mahlzeit ... das ist ja wieder mal toll.


    Besides:
    Wo protokolliert die ProFTPd Version aus pd-Admin eigentlich Login Versuche hin? Bei mir finde ich nirgendswo in der messages oder secure irgendwelche Login-Versuche, lediglich ins wtmp wird was geschrieben.


    Ich hatte erst gedacht, das ich beim Syslog was falsch konfiguriert hätte, aber das ist soweit sauber.

    Wenn die aktuelle PD-Admin Umgebung eingesetzt wird, ist proftpd 1.3.4e installiert. Diese Version ist laut heise bereits gefixt.


    Insofern ergibt sich das Problem ohnehin nicht, selbst wenn das Modul einkompiliert wäre ....

    Wenn ich das richtig verstehe, hast du bei einem Reseller 2 IPs zugewiesen und mit diesem Reseller ein Angebot eingerichtet, auf welchem eine Domain zugeordnet worden ist?


    In diesem Falle würde ich mal sagen, das das ein normales Verhalten ist.
    Denn bei den Angeboten selbst und bei den Kunden kann keine IP-Konfiguration vorgenommen werden. Ergo wird wohl die Voreinstellung des Resellers übernommen.


    Schau doch mal in der Tabelle vadmin.domains sowie vadmin.vhosts, was in dem Feld IP eingetragen ist. Ich würde mal tippen, das da jeweils für beide IPs Einträge drin stehen.


    Ggfs. müsste man an dieser Stelle ansetzen, um das zu bereinigen, da die Generierung der http.conf basierend auf diesen Daten erfolgen dürfte.


    Beste Grüße,


    BrowsingMan


    P.S.:
    Stellt sich trotzdem die Frage, ob die Zuordnung der IPs nicht im Angebot und/oder Kunden-Menü konfigurierbar sein müsste/sollte.....

    Ich würde mal vermuten, das es helfen würde innerhalb des httpd.conf-template Files für den relevanten Default VirtualHost Container die folgende Zeile einzufügen:
    SetEnv PHP5_VERSION 5.3.24


    Damit sollte dann der Roundcube mit PHP 5.3 ausgeführt werden.
    Zumindest wird diese Zeile bei dem jeweiligen VirtualHost des Kunden eingefügt, wenn er die PHP Version in seinem Webauftritt auf PHP 5.3 umstellt.


    Aber wie gesagt: Es ist eine Vermutung und von mir noch nicht getestet.

    Als Bug würde ich das nicht bezeichnen, sondern eher als ein noch nicht genutzes Feature.


    Seit MySQL 5.1.6 gibt es die Möglichkeit, zu bestimmten Zeitpunkten Aktionen ausführen zu lassen (scheduled events).


    Voraussetzung ist natürlich, das ein entsprechendes Recht gewährt wird (grant privilege).


    So die Events mit gesichert werden sollen, müsste hier das Skript backup_write_dumps.sh (in der Regel im Verzeichnis /opt/pdadmin/bin) angepasst werden und um die Option --events ergänzt werden.

    Ich habe die Installation auf Basis von CentOS 5.5 64bit durchgeführt.


    Hier im Forum ist auch ein Hinweis enthalten, welche Libraries zusätzlich installiert werden müssen.


    Die Installation läuft auf dem System sehr stabil; bisher habe ich noch nie Probleme in dieser Konstellation gehabt.


    Beste Grüße,


    BrowsingMan

    Zitat

    Original von Daniel Bradler


    Sie kennen sich da anscheinend gut aus. Wieviele Passwort-Tests pro Sekunde können Sie denn in der Praxis erreichen?


    Sachliche Antwort? Ja, ich arbeite bei der Siemens und führe unter anderem Security Audits durch.


    Ihre Versteifung auf die maximale Anzahl von Passwort-Tests ist zwar sicherlich mathematisch richtig, sofern nur 1 Netzwerkkarte mit 100Mbit zum Einsatz kommt; sie trifft aber schon bei mehreren Netzwerkkarten und/oder höherer Bandbreite nicht mehr zu.


    Davon ab reduziert sich die Anzahl der Passwörter allein durch die Tatsache, das Anwender niemals ausschließlich Zufallspasswörter verwenden, was Hacker durchaus bei ihren Angriffen berücksichtigen.


    Aber wahrscheinlich wollten Sie mit ihrer Spitze eine andere Antwort provozieren :D


    Zitat

    Inwieweit würde ein längeres Passwort dieses Problem lösen?


    Glauben Sie etwa, das Hacker keine Suchmaschinen verwenden? Wie jeder Mensch suchen sie auch im Internet nach Informationen wie z. B. Schwachpunkten, um ihre Ziele daraufhin abzustimmen.


    Und die sind ja in Hinblick auf PD-Admin hier im Forum ausreichend angesprochen ....


    Eine Lösung würde ja wahrscheinlich ebenfalls publiziert und somit einen Angriff unattraktiver machen.


    Last not least:
    Davon abgesehen ist die Verwendung längerer Passwörter nicht nur aus Sicherheitsgründen wünschenswert, sondern wird heutzutage von vielen Anwendern einfach als Komfortfeature erfunden, welches ihnen ermöglicht, die Buchstabenfolgen längerer Sätze zu verwenden (welche zudem für viele als Eselsbrücke leichter merkbar ist)


    Aber mal so als Alternativ-Vorschlag:
    Wenn denn die Unterstützung längerer Passwörter so schwierig ist, wie wäre es denn dann mit Sperren der IP per Firewall Regel bei einer vorgegebenen Anzahl von Fehlversuchen? Ist zwar nicht im Standard-Umfang der Server-Umgebung, ließe sich aber bestimmt als Addon einbinden.

    Zitat

    Original von Daniel Bradler
    Derzeit wird an vielen Stellen crypt() zur Erzeugung der Passwort-Hashes verwendet. Hier sind nur die ersten 8 Zeichen signifikant. Eine Änderung des Algorithmus wäre recht aufwendig und einen echten Sicherheitsgewinn sehe ich nicht.


    Ja, klar. Deswegen ist auch bei allen aktuellen Linux Distributionen nicht mehr crypt, sondern md5 in Verwendung.....


    Davon ab gibt es gute Gründe für eine Umsetzung:
    a) Hacker suchen mittlerweile immer gezielter nach Schwachstellen
    b) Verteilte Angriffe (auch aufgrund von Clouds) ermöglichen schnelle verteilte Angriffe
    c) Auch wenn die Angriffe wahrscheinlich nicht erfolgreich sind, werden sie den regulären Betrieb allein durch die Last stark beeinträchtigen.
    Daraus resultiert, das man sein System so sicher wie nur irgendmöglich gestalten sollte, um es von vornherein für Angriffe unattraktiv zu gestalten


    Mal ehrlich, dieser Thread ist lächerlich und läßt sich verkürzen:


    a) Viele Kunden möchten gerne diesen sogenannten "echten Sicherheitsgewinn"
    b) Der Hersteller der Software möchte dies nicht, weil es Aufwand bedeutet.


    Punkt. Wenn Herr Bradler nicht will, sehen wir diese Verbesserung auch in 20 Jahren nicht.

    Hallo,


    zur Zeit setze ich ein:
    pd-admin 414
    SE 3-0.162
    PHP wird mit cgiwrap betrieben


    Im error_log sehe ich seit einiger Zeit folgenden Eintrag extrem häufig:
    [error] [client xx.xx.xx.xx] svwrap: Warning 438: PHP5_VERSION '9.9.99' not found, using default.


    Kennt hier jemand vielleicht
    a) den Grund/die Ursache?
    b) einen Weg, diese Fehlermeldungen abzustellen.


    Update:
    Testhalber habe ich derzeit auf FastCGI umgestellt. Ist wesentlich erträglicher von der Menge der geloggten Daten (einmal den FastCGI Starter Block beim Intialisieren ...)

    Naja,


    das ist halt immer eine Frage des Blickwinkels:


    Funktioniert PD-Admin sowie die Server-Umgebung?


    Sicherlich ja. Da wird man kein wirkliches Defizit finden.


    Gibt es überflüssige Sachen?
    Etliche Kleinigkeiten. Zum Beispiel Bereinigungen in der MySql Datenbank:
    Die tabellen traffic und user (welche wohl längst durch traffic_new und users abgelöst sind)


    Ist die Dokumentation von PD-Admin vollständig?
    Eher nicht. Das sieht man auch ganz klar an den vielen Nachfragen im PD-Admin Forum. Wobei viele damit nicht nur PD-Admin, sondern auch die Server-Umgebung meinen, in welcher neue Komponenten regelmäßig aufgenommen, aber nicht wirklich dokumentiert werden.


    Sind angekündigte Features vollständig umgesetzt?
    Eher nicht. One Click Installer, Spam und Virus Filter auf Userlevel sind ja nicht umgesetzt.


    Kurz:
    Es gibt zwar vieles, was nicht eingehalten worden ist, aber insgesamt funktioniert das Produkt gut und der Support funktioniert im Ernstfall ebenfalls.