RootForum Community

was hastn du nun für nen beitrag gequotet? :-) hihi

JSommer wrote:was hastn du nun für nen beitrag gequotet? :-) hihi

DEINEN - und du denkst wohl auch, dass das hier ein Witzforum ist? :twisted:

Sorry nein, ich hab nur eben den Beitrag editiert, als ich den Edit fertig hatte, las ich schon Deinen Thread. Also wollte damit nicht scherzend rüberkommen. Sorry nochmal. Zurück zum Problem.

Grüße,
Jürgen

@JSommer

Zur Ausgabe vom Skript:

Zeigt an, wie oft eine URL aufgerufen worden ist. Sieht aber normal aus. Hast du evtl. logrotate oder ein anderes Programm, welches die Logdateien rotiert? Dann wären die Einträge vom Versender der Mails evtl. schon nicht mehr in der Apache Logdatei.

Hallo Ihr Leute hier,

<blabla>

dies ist mein erster Eintrag hier und dazu gleich mal ne (gut gemeinte) Rüge:

bitte nicht gleich mit so Antworten wie "is das hier ein Witzforum" etc. antworten. Lieber adjustMan nehm das jetzt, wenns geht, BITTE net persönlich.

Die Domain hier heisst rootforum.org/; also sind wir doch alle root auf irgendeinem Webserver. Wenn man sowas hat, dann entweder zum Spass weil man sich das nebenbei leisten kann oder um mit den Kisten sein Geld zu verdienen. Wenn ein Rechner nimmer funzt, weil irgendwelche *******-Typen ( selber zensiert ;-) ) ihr Unwesen darauf treiben, so versucht man jede, sich ergebende Möglichkeit zu nutzen um alles wieder ins Lot zu bringen. Es kann durchaus eine Existenz dran hängen, wenn ein Server nicht das macht was er soll ... verärgerte Kunden sind echt KEIN SPASS!

Wenn dann mal das ein oder andere Posting daneben geht, sollte man sich doch net gleich dran aufhängen, sondern lieber wieder zum Problem zurückkehren.

Dies soll nun das Ende meiner schlauen Sprüche zum Umgangston hier sein. Ich selbst bin auch kein Gott und eigentlich nur deshalb in Foren aktiv um Hilfe zu finden und Anderen mit meinem bescheidenen Wissen zu helfen. Keinesfalls um mein Ego zu beweisen (naja.. manchmal scho *gg*).
( Antworten auf diese Zeilen bitte als PM, da ich das Forum nicht zumüllen möchte )

</blabla>

ich bin oben genannter Kollege, der sich nach nem Rootkit umgeschaut hat.

Das Problem mit diesem Spamproblenm hab ich nun gelöst 8)

Folgende Fakten waren gegeben:

1 Rechner - 35 Kunden - 70 Domains
load average in 'top' war bei durchschnittlich 70 8O
der virtualmemorymanager (vmm) hat einen Prozess nach dem anderen gekillt
fazit: Die Kiste war nimmer zu gebrauchen!

wir stellten erstmal fest, dass der Server Spam verschickt
( die ganzen Antworten an den Postmaster, von wegen Mail nicht zustellbar etc. von den Posteingangsservern der Opfer ) Die Antwortadresse war jedesmal wwwrun@server

Erste Vermutung: Irgendein php-script is offen wie ein Scheunentor und läßt Spammern freien Lauf.

Das Durchsuchen der access_log des Apachen war sinnlos.
Das Suchen ( mit cat | grep ) nach irgendwelchen verdächtigen Einträgen ging ins Leere. Das half uns auch nicht, das Script zu finden, da wir keinerlei Anhaltspunkte hatten, von welcher IP das ganze kam resp. welches Script oder welche Domain das verursacht.

Wir aktivierten das server_status Modul des Webservers, doch das half uns auch nicht weiter. Warum wusste ich auch erst hinterher, denn der Aufruf des entsprechenden Mailscripts erfolgt nur einmalig, relativ kurz. Bei einer Wiederholung dann von einer anderen IP, denn die Spammer sind nicht dumm. Der Befehl 'rcapache2 full-server-status' ( jaja is SuSE ) zeigte uns allerdings nur die 'grossen' Ressourcen-Verbraucher wie Einträge in Gästebücher bzw. Aufrufe von Bildern sowie länger bestehende Verbindungen.

postfix an sich loggt zwar die Mails, aber nicht von welchem Script sie kommen. Die Einträge dass diese Dinger vom wwwrun kamen, halfen uns auch nicht weiter, da ja nicht festgehalten wird welches Script das ganze verursacht. Alle Threads, die via einer Webseite aufgerufen werden erscheinen einfach als Mail von wwwrun.

In meiner Notsituation ( /me weiss halt auch net alles *g* ), griff ich nun zu folgendem Mittel:

Wir mussten herausfinden, welche *.php Dateien den Befehl mail(xxxxx) verwenden. Das Problem dabei: Es müssen alle Verzeichnisse unterhalb des DocumentRoot rekursiv untersucht werden. Der Gedanke, das händisch bei 35 Usern zu bewerkstelligen verursachte mir Bauchscmerzen --> der Rechner muss das also machen. Kurzerhand entstand folgender Shell-Befehl:

( leicht abgeändert -- bei Nachahmung keine Garantie und die Pfade bitte selbst ergänzen )

Es dreht sich um 36 Kunden, die der Befehl untersuchen sollte. Wir befinden uns als 'root' im htdocs-Stammverzeichnis des Webservers. Die Userverzeichnisse befinden sich in den Ordnern web0 - web35 ( ja, könnte CONFIXX© sein )

Folgender Befehl startet eine Schleife, die nacheinander diese Verzeichnisse nach Dateien mit der Endung .php durchforstet und in den entsprechenden Dateien nach dem Ausdruck " mail( " sucht. Die Ausgabe des Befehls wird an die Datei "schettlguggt" angehängt. Wichtig sind die beiden '>>', da bei einfachem '>' jedesmal ne neue Datei geschrieben wird und die alte ersetzt wird!! Bei weniger Daten wär es auch ohne Schleife gegangen, doch der grep Befehl unterstützt nur ne begrenzte Zahl an Argumenten.

--> Fleissaufgabe: Ich habe den Befehl wie oben ausgeführt, dabei bin ich auf zwei kleine Fehler gestossen. Der eine = nicht aufgepasst, der andere = mit einem Shell Script nicht zu lösen. Wer sie findet > PM :D

ENDRESULTAT:

Wir fanden schliesslich den Ã?beltäter, haben die Seite des Kunden vom Netz genommen, und schon wars aus mit der Spammerei!! Dieser Kunde konnte aber wirklich nicht wissen, was er da für Schei**e gebaut hat!

Dies geht natürlich nur, wenn man nicht zu viele Kunden auf der Kiste hat. Wenn mehr Kunden dann muss man doch ein Script schreiben.

FAZIT:

ACHTET DARAUF, WER WAS FÃ?R SCRIPTE AUF EUREM SERVER INSTALLIERT!!


FAZIT II:

das nächste Mal auf jeden Fall PERL ;-)

viele Grüße

Uwe


( nothing more important than input-validation )

hi,

schettlu wrote: Wir aktivierten das server_status Modul des Webservers, doch das half uns auch nicht weiter. Warum wusste ich auch erst hinterher, denn der Aufruf des entsprechenden Mailscripts erfolgt nur einmalig, relativ kurz. Bei einer Wiederholung dann von einer anderen IP, denn die Spammer sind nicht dumm.

Aber auch wenn die Einträge immer von unterschiedlichen IP´s stammen, so sollten diese doch beim aktivieren von server_status ersichtlich sein.
Natürlich nur, wenn in dem moment gerade die Attacke noch läuft. Im Nachhinein bringt das nichts mehr.


P.S keiner ist perfekt :) Von daher hab ich auch wieder eine klein wenig dazugelernt.

Wär's mit grep-"Standardmitteln" (Stichwort Rekursion) nicht einfacher gegangen? ;)

@CaptainCrunch

hmmmm, grep "standardmittel" ... wir haben einige grep -[optionen] Befehle ausgeführt, bis das da oben entstand. Keiner schreibt zum Spass solche ewig langen Zeilen. Aber was man in der Eile unter Zeitdruck nicht alles macht... Unser letzer Versuch vor der Schleife war:

grep "mail(" `find -name *.php` >> dateiname

Dadurch wurden grep zuviele Parameter übergeben und grep beendete sich, da 'find -name *.php' einfach zu viele php-Dateien gefunden hat.
Wenn Du mir einen Befehl mit grep"Standardmittel" zeigst, einen der funktioniert, dann lass ich mich gerne belehren :?

@chaosad

Dann müsste der Angriff eben genau in der Sekunde stattfinden, in der ich den Status aufrufe. Ich rufe ihn mit rcapache2 -full-server-status auf( geht das anderes? mach ich was falsch? ). Was ich dann bekomme ist die Liste der Verbindungen, die an dem Zeitpunkt enstanden, als ich Return drückte. Es ist also leider kein richtiges Monitoring, sondern nur ne Momentaufname

Die Spammer verwenden die Sicheheitslücken meist so, dass sie nicht 1000 mal eine Verbindung zu dem Script herstellen sonderen durch den gekonnten Aufruf eines ungesicherten Mailscripts gleich beim ersten Aufruf ihre 1000 Emailadressen ins Empfängerfeld des Scripts schreiben ( z.B.: To: user@host.netrnBcc:user@woanders1.de, user@woanders2.com, user@weisdergeier.de, etc ).

Da etliche Bildergallerien und auch Foren auf dem Computer laufen, welche relativ stark frequentiert sind, ist es schwierig den entsprechenden Aufruf da rauszufiltern. Grade in diesem Moment zeigt mir netstat ca.50 Verbindungen am 80er Port established...
( Hab grade mal 'tail -f /var/log/apache2/access_log' laufen ... geht ab wie Schmidts Katze .... )

Das access_log nach verräterischen Daten, wie z.B. mail.php war zu unsicher, denn es kann ja in jedem .php File ein mail() befehl drinstecken (auch wenn das file z.B. klaus-dieter.php heisst). Außerdem is das Logfile recht gigantisch ( allein heute hats der Cronjob schon 2mal archiviert, weil die festgelegte Größe überschritten war.

-----------------------------

Wenn es für diese Problematik elegantere Lösungen gibt, so bin ich wirklich dankbar wenn sie hier gepostet werden!
Zu Vermuten, dass es was besseres gibt, mag nicht unangebracht sein bringt uns aber auch nicht wirklich weiter :roll: Außerdem machts den Thread mit unnötigen Beiträgen voll. -> sowas dann als private message, bitte

Schlussendlich sollte die Disskusion aber ohnehin auf etwas anderes hinauslaufen. Das ich dieses schadhafte script gefunden habe war ja eher Glück als können. Wenn das nicht 35, sondern 135+ User gewesen wären ... omg!

Viel wichtiger ist die Frage:

WIE VERHINDERT MAN SOWAS??

Das mailen via PHP ( oder auch anderer Scriptsprachen ) abzuschalten wäre wohl das uncleverste was man machen kann. Wie schützt man sich aber vor Anfänger- bzw. Idioten-Scripten?? Das sollte die Frage sein.

Was macht man? Regelmässig die .php Dateien aufm Rechner kontrollieren? -> vergisses!
Regelmäßig ein Spammertool drüber laufen lassen? So eines das die Spammer verwenden um unsichere Mailscripte zu entdecken? -> Bingo
Ein solches müsste dann eben modifiziert werden, dass es nur die eigenen Domains scannt und schon würde das passen. Falls jemand weiss, wo man sowas bekommt --> Private Message oder EMail, denn ich denke, dass solche Tools nicht öffentlich verlinkt werden sollten... scriptkiddies dream, sag ich da nur

Viele Grüße

Uwe

Dadurch wurden grep zuviele Parameter übergeben und grep beendete sich, da 'find -name *.php' einfach zu viele php-Dateien gefunden hat.
Wenn Du mir einen Befehl mit grep"Standardmittel" zeigst, einen der funktioniert, dann lass ich mich gerne belehren

Mal ganz fix aus der Hüfte geschossen: Gibt dir direkt den Dateinamen zurück, in dem der String vorkommt.

CaptainCrunch wrote:Mal ganz fix aus der Hüfte geschossen:

Code: Select all

grep -rl 'mail(' web*/*.php

Gibt dir direkt den Dateinamen zurück, in dem der String vorkommt.

Antwort von bash:
.. Antworten ähnlich mit ..... web0/*.php, web1/*.php usw.

was meinst Du, wie oft wir mal ganz fix aus der Hüfte geschossene Befehle hatten *gg* Der Teufel steckt halt im Detail ...

Strange. Bei mir tut's. Mag aber wohl auch an der ziemlich aktuellen Bash-Version liegen. ;)

Hallo,

verhindern kann man das nicht. Vielleicht in den AGBs fest machen um zumindest die Haftungsfrage zu klähren.

Ansonsten ist php als CGI mit suexec ganz sinnvoll. Dann hat man in den Mails den Header X-UID: der schön die UserID des VHosts angibt, von dem aus die Mail per mail() versendet worden ist.

Joe User wrote:

Code: Select all

for file in `find . -type f -o -name "*.php"`;
do grep -E "mail[:space:]*(" ${file}; done

Filenamen mit Spaces drin? Bumm!

find . -type f -name *.php -print0 | xargs -0 grep -E "..."

oder ein simples
"back to the roots"

schettlu wrote:bitte nicht gleich mit so Antworten wie "is das hier ein Witzforum" etc. antworten. Lieber adjustMan nehm das jetzt, wenns geht, BITTE net persönlich.

nein, nicht persönlich. Aber erst 3 Punkte (Fragen) posten
und wärend ich antworte, editieren. Und sich dann totlachen wollen.
Das sind die Leute, deren Thread normalerweise gesperrt wird.
Das ist alles.

dann sorry, adjustMan ... hab das nochmal angschaut ...das erklärt nun auch das "hihi" :idea:

Sorry, Eure Befehle funzen alle nicht. Liegt wohl doch an der etwas betagten bash-Version ... 2.05b

Naja, Hauptsache es hat geklappt!

@ Alexander Newald

Das hört sich doch schon mal sehr interessant an! Sollte ich mich mal schlau machen...

schettlu wrote:
Viel wichtiger ist die Frage:

WIE VERHINDERT MAN SOWAS??

Diese Methode gefällt mir je länger je besser.
http://www.modsecurity.org

mod_security ist ein Sicherheitsmodul für den Apache.

Auf einem Produktiv Server mit -zig Domains und verschiedenen Kunden
ist das eine wirksame Möglichkeit, gefährliche Requests und Outputs zu unterbinden. Gefährliche Scripts zu entlarven und vieles mehr.

Handling für den Admin:
Sehr anspruchsvoll, mehrere Tage Studium und Tests sind angesagt.

Schutz für den Server:
Gegen Einbrüche über Webseiten absolut top.

Gruss, danu

danu wrote:Schutz für den Server:
Gegen Einbrüche über Webseiten absolut top.

Leider nur reaktiv, nicht präventiv. Du mußt die "bösen" Queries kennen, um dich dagegen wirkungsvoll mit mod_security zu schützen.

Roger Wilco wrote:Du mußt die "bösen" Queries kennen

Das muss ich in dem Falle gerade nicht. Mit der neuesten Version mod_security 1.9.2 kann man auf

http://www.modsecurity.org/

die neuesten rules herunterladen. Damit sind der grösste Anteil
"bösartiger Queries" bereits bekannt und implementiert. Wie ich bereits andeutete, befasste ich mich ein paar Tage mit dem Studium und TESTS derselben. Ich handhabe dieses Tool in dem Sinne "alle BEKANNTEN und GUTEN Queries" werden zugelassen ... und the rest go west - ins Logfile :lol:

In diesem Sinne habe ich bereits ein Rundschreiben an meine Kunden
versandt ... überprüfen Sie bitte Ihre verwendeten Scripte und Webapplikationen auf Sicherheit und Aktualität ... Webmail ist nur noch über https://.... erreichbar etc. etc. etc.

Als einfaches Beispiel sind hier die Gästebücher auf den Webseiten.
Dank mod_security werden sie nicht mehr gespamt und sind auch im weitesten Sinne "sicher", obwohl zum Teil noch die ältesten und primitivsten CGI-Scripts verwendet werden. Meiner Meinung nach lohnt es sich auf jeden Fall ein paar Tage Arbeit zu investieren, und sich wirklich ernsthaft mit diesem Powertool auseinanderzusetzen. :idea:

bis bald, danu

schettlu wrote:FAZIT II:

das nächste Mal auf jeden Fall PERL ;-)

Hi Uwe,

was versprichst Du Dir von Perl? Wenn ein Kunde bei Dir den ältesten Formmailer draufpackt und den auf die Menschheit losläßt, bis Du genauso am Poppers.

Daß irgendein Idiot seinen Recipient nicht hardcoded oder sonst irgendwie überprüft, kannst Du als Serverbetreiber nicht verhindern - Mist kann ich auch in C oder Pascal schreiben.

flo.

@flo:

Ich meinte dass ich beim nächsten Mal, wenn ich tausende Dateien durchsuchen muss, ein PERL-Script nehmen werde (anstelle eines shell-Befehls). Ich meinte nicht, dass ein formmailer mit PERL sicherer ist, als einer in einer anderen Sprache!

@ danu:

DAS werd ich mal unter die Lupe nehmen! Sieht gut aus!

schettlu wrote:Ich meinte dass ich beim nächsten Mal, wenn ich tausende Dateien durchsuchen muss, ein PERL-Script nehmen werde (anstelle eines shell-Befehls). Ich meinte nicht, dass ein formmailer mit PERL sicherer ist, als einer in einer anderen Sprache!

Sorry mißverstanden, aber dafür ... ... schreib ich kein Script !?

flo.

danu wrote:Das muss ich in dem Falle gerade nicht. Mit der neuesten Version mod_security 1.9.2 kann man auf

http://www.modsecurity.org/

die neuesten rules herunterladen. Damit sind der grösste Anteil
"bösartiger Queries" bereits bekannt und implementiert.

Ja, d. h. du oder derjenige, der die Regeln erstellt hat, mußte genau wissen, was die Angriffe machen und wie sie aussehen, welche Zeichenketten in den Requests enthalten sind. Wenn nun eine Webapplikation für einen bösen Request anfällig ist, der nicht von deinem Ruleset abgedeckt wird, mußt bzw. kannst du die entsprechende Regel erst nachträglich hinzufügen (sofern du es überhaupt bemerkt hast). Daher ist mod_security ein rein reaktiver Ansatz.

@schettlu

vor einiger zeit hatte ich eine ähnliches problem, da ich auch nicht genau wusste, welches skript für den spamversand zuständig ist. ich hatte mir damals überlegt, direkt an dem sendmail anzusetzen, das ja von PHP mail() aufgerufen wird. nach ein bisschen recherche bin ich auf diesen link gestossen, da gibt es ein skript das diesen ansatz auch verwendet:

http://gregmaclellan.com/blog/sendmail-wrapper/

dieser ansatz gefällt mir gut, da man zentral ansetzt. damit könnte man auch ressourcenbeschränkung umsetzen, wenn man das ganze ein bisschen umprogrammiert. und Bcc verbieten, darüber versuchen es bei mir die ganzen spammer.

Bart