Hilfe! Postfix verschickt SPAM mit Apache (wwwrun) als Absender

[jsommer]

Es ist ein Jammer, wir kommen hier einfach nicht weiter. Folgendes Problem: Auf unserem Linux Server (Apache2) gibt es wohl irgendwo ein Script, dass es geschafft hat, über Postfix SPAM zu verschicken. Absender ist wwwrun - also der Apache selbst. Wir haben alle Logs durchschaut aber können einfach nichts finden - gibts eine Möglichkeit den Apachen / Postfix zu monitoren? Wo könnte ich in welchem Log vielleicht doch was finden? Hilfe Hilfe Hilfe... das bringt mich um. Postfix schickt ohne Ende nach Brasilien - ich bin mir sicher, dort ist unser Server schon in den TopTen der Blacklistserver :-(. Was könnten wir tun? Wer hat sowas schonmal überstanden? Hilfe - bitte! :-/

[oxygen]

Als erstes Postfix beenden.

Dann die Scripts auf dem Server durchforsten. Eine Möglichkeit wäre es z.B. die PHP Fehler in eine Datei umzuleiten und sich die anzuschauen, so sollte ich leicht der Ã?beltäter finden. Oder einfach das access_log auf ungewöhnlich viele Hits auf einzelne Scripts beobachten.

[jsommer]

also die scripte durchforsten ist unmöglich - sind rund 70 domains - keine ahnung, was da alles am laufen ist - wie genau ist das mit den fehlermeldungen als datei ausgeben - kann man das irgendwie globalisieren?

[cat]

huch?

was bitte machst Du mit 70 Domains?

gruesse
Cat

[chris76]

huch?

was bitte machst Du mit 70 Domains?

gruesse
Cat

Hi Cat, ich denke er meint eher 70 Kunden ;).

[jsommer]

35 Kunden mit insgesamt 70 Domains ... hilft aber nicht weiter ...

[chris76]

Was hast du bisher gemacht? Postfix beendet und die Logs durchforstet?

[jsommer]

logs durchsucht, postfix gestoppt, klar... meine letzte rettung war heute nacht als ich ein paar tausend mals aus der mailqueue entfernt habe seitdem hat er keinen spam mehr verschickt, klar aber, dass da jetzt erstmal millionen von nichtzustellbaren mails wieder zurückkommen :-/ ... achja ... kollege hat auch nach nen rootkit oder so gschaut - aber negativ.

[chaosad]

wärs evtl. möglich über den server-status des apaches rauszufinden welches Skript hier verwendet wird? Das müsste ja dann auch laufend aufgerufen werden. Klappt allerdings auch nur, wenn natürlich grad versucht wird drüber zu versenden.

[jsommer]

wie rufe ich den denn auf? :-/ also ´ps´ sagt mir halt nur, dass ordentlich mails verschickt werden - wobei im moment ruhe ist :-/, da die queue ja leer ist :-)

[chaosad]

du trägst in deiner apache config folgendes ein:

Code: Select all

<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from "deine IP oder localhost"
</Location>

Wenn du deine aktuelle IP einträgst kannst du im Browser dann folgendes eingeben:

http://serverip/server-status

[jsommer]

werd ich mal probieren, wie gesagt, im moment ist er brav :-/

[gerks]

Hi JSommer,

mit dem Befehl "mailq" schauen wann die E-Mails abgefeuert worden sind und dann einfach im /var/log/apache2/access.log gucken welche Domain dahintersteckt. Meistens ist es ein sendmail.php oder ähnliches was von Spammern gerne missbraucht wird. :twisted:

Grüsse
Göks

[jsommer]

Hi, vergiss es ... in der mailq standen "millionen von mails" :-) also da ging schonmal so gut wie gar nix mehr und im log findet sich nix :-(

[alexander newald]

Lass mal das folgende Perl Script auf deine Apache Logdatei los (evtl. Logdateiname anpassen)

Code: Select all

#!/usr/bin/perl

my $logfile = "/var/log/httpd/access_log";
$limit = 50;

%urls = ();
open(FILE,"<$logfile");
while(<FILE>) {
        chomp($tmp =$_);
        $url = (split(/ /,$tmp))[7];
        ++$urls{$url}
        }
close(FILE);
foreach my $url (keys %urls) {
        my $hits = $urls{$url};
        if ($hits > 50) {
                push(@sorting,"$hits $url");
                }
        }
foreach my $tmp (sort NummernSortKleiner @sorting) {
        print "$tmpn";
        }

sub NummernSortKleiner
  {
   if($a < $b)
    { return -1; }
   elsif($a == $b)
    { return 0; }
   else
    { return 1; }
  }

[jsommer]

ganz dämliche frage: wie start ich denn in der shell ein perl-script? :-) habs daliegen, ist auch rechtetechnisch ausführbar nur wie rufe ich das teil auf? *bittenichtwürgen* :-)

[timeless2]

chmod 700 /pfad/zum/skript
/pfad/zum/skript

[jsommer]

er gibt mir das hier aus:
46826 HTTP/1.0"
289388 HTTP/1.1"

Was sagt mir das nun?

[alexander newald]

Dann speichert dein Apache die Logdatei anders als bei mir.

Mach aus

Code: Select all

$url = (split(/ /,$tmp))[7]; 

Code: Select all

$url = (split(/ /,$tmp))[6]; 

und probier es nochmal

[jsommer]

dann gibts diesen output (teilweise, nummeriert aufsteigend)

808 /gallery/album466
808 /gallery/images/nav_dot_left.gif
829 /cms/index2.php?option=shoutit&task=showshouts
848 //counter//template/AllMyPHP/images/amvinfo.gif
861 //counter//template/AllMyPHP/images/headlinebg.gif
915 /blank.gif
939 /files/greenfreiklein.jpg
955 /gallery/images/nav_prev.gif
956 /gallery/images/nav_first.gif
959 /mainnews/balken.jpg
974 //counter//index.php?AMV_open=screenstat&AMV_w=1024&AMV_h=768
996 /arrow_r.gif
1005 /gallery/images/nav_next.gif
1009 /gallery/images/nav_last.gif
1010 /files/sushiz2.jpg
1012 /files/greenklein.jpg
1019 /files/sushiz4.jpg
1023 /files/pat1.jpg
1033 //counter//template/AllMyPHP/style/allmyphp.css
1034 /files/ft555.jpg
1039 /arrow_w.gif
1047 /mainnews/default.css
1050 /files/sush6aa.jpg
1050 /files/gunzen10a.jpg
1060 /files/gunzen50.jpg
1063 /stm31.js
1066 /files/hansp3.jpg
1072 /files/stun1.jpg
1072 /files/sush50b.jpg
1073 /files/sush50a.jpg
1078 /files/hansp71a.jpg
1088 /mainframe/header3.gif
1090 /mainframe/header2.gif
1093 /files/aoao1.jpg
1097 /mainframe/header1.gif
1101 /files/gunzen60.jpg
1159 /gallery/images/nav_home.gif
1167 /gallery/pictures.html
1201 /tm.css
1215 /gallery/skins/soft003/images/mod_navbar.jpg
1228 /albums/album467/aaa.highlight.jpg
1289 /gallery/skins/soft003/images/background.jpg
1553 /gallery/album450
1559 /gallery/index.php
1610 /gallery/skins/soft003/css/standalone_style.css
1611 /gallery/skins/soft003/css/embedded_style.css
1629 /favicon.ico
1663 /mainnews/index.php
2421 /

Sagt mir jetzt auch nicht wirklich was - was könnte ich daraus lesen?

[lord_pinhead]

Bist du sicher das nicht mittlerweile schon ein Script läuft das im Benutzerkontext des www liegt? Ansonsten vielleicht mal eine Mail lesen die im Spool liegt ob es nicht einer deiner Kunden mit Absicht war, ist auch schon oft passiert das ein lieber Kunde selbst Spammt.

[jsommer]

Also wir vermuten ein Script, welches durch eine fehlende input verification böööööööööösen Code auf die Maschine gebracht hat und nun mit wwwrun Mails versenden kann. Ein Kunde selbst kanns nicht sein, denn dann wäre es kaum wwwrun also Absender - ausser natürlich ein Kunde hat ein solches Script eingebaut. Seltsam nur, dass ich im Cache von google eine indonesische Site gefunden hab, mit genau dem Spam-Teil, was bei uns über den Server lief. Guckst Du:

http://72.14.203.104/search?q=cache:ljD ... =firefox-a

Rootkit ist nix drauf, hat ein Könner gecheckt! Script also - nur wie findet man den Dreck. Ich weiß nur, dass wwwrun die Mails gesendet hat, aus den Logs bekommt man definitv nicht raus, woher wwwrun diesen Input erhalten hat. Derzeit isses ruhig, auf der einen Seite: gottseidank, andererseits ist es natürlich hot, kann ja jede Minute wieder kommen. Im Moment fällt mit im warn-log auf, dass irgendwelche check relay domains abgehen - Auszug:

Feb 1 20:15:06 h9419 postfix/smtpd[11943]: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead
Feb 1 20:18:25 h9419 postfix/smtpd[12211]: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead
Feb 1 20:20:55 h9419 postfix/smtpd[12429]: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead
Feb 1 20:24:05 h9419 postfix/smtpd[12766]: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead
Feb 1 20:25:53 h9419 postfix/smtpd[12882]: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead
Feb 1 20:28:49 h9419 postfix/smtpd[13102]: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead
Feb 1 20:31:01 h9419 postfix/smtpd[13249]: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead
Feb 1 20:33:43 h9419 postfix/smtpd[13492]: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead
Feb 1 20:35:45 h9419 postfix/smtpd[13694]: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead
Feb 1 20:37:55 h9419 postfix/smtpd[13886]: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead
Feb 1 20:41:35 h9419 sshd[14249]: error: PAM: System error
Feb 1 20:49:42 h9419 postfix/smtpd[15061]: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead
Feb 1 20:49:46 h9419 postfix/smtpd[14971]: warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead

Was das nun wieder ist weiß ich auch nicht, bin kein Postfix-Spezialist, werde ich aber noch rausfinden - oder weiß es jemand?!. Ansonsten stehen wir jetzt erstmal mit ein paar Updates auf der Matte, php, confixx, phpmyadmin und so wird mal ordentlich upgedatet. Manche Fehler, die wir in den Logs gefunden haben (so favicon nicht vorhanden und son Käse) werden wir jetzt mal nach und nach beheben. Ich will jetzt nicht aus Panik den kompletten Inhalt (also die 35 Kunden und mehr als 70 Domains) auf nen neuen Server packen - die Gefahr ist da immerhin da, dass ich die Schwachstelle auch mit auf den neuen Server mitnehme, was recht dämlich wäre - da könnte "es" ja dann nur noch leistungsstärker spammen. Ich bin mir sicher, dass wir in Brasilien jetzt in den topten der Blacklistserver stehen :-( alles Mist und richtig dumm, wenn man sowas ausfindig machen will/muss. Auf jeden Fall wurden mal alle Kunden darauf hingewiesen, dass die gefälligst mal saubere Scripte einsetzen und auf evtl. Schwachstellen prüfen, aber ihr wisst ja selber, da sind mitunter Jungs dabei, die ganz stolz Ihr erstes eigenes Gästebuch geschrieben haben, andererseits Kollegen, die echt lausig gecodete Scripte einsetzen und am besten noch mit admin/admin in den Accountdaten. Meine Nerven :-/

###update###

Hab eben diesen Link gefunden - kann zwar nur wenig spanisch, aber das ist das Teil, was über unseren Server verschickt wurde ... wer weiß, war das genau sein soll? Augenzeugen gesucht :-)

http://www.machall.com/iotm/index.php

###update .q###

[adjustman]

Code: Select all

warning: the "check_relay_domains" restriction is going away; use "reject_unauth_destination" instead

Ersetz in main.cf
check_relay_domains mit reject_unauth_destination
Steht aber auch da => use reject_unauth_destination instead

[jsommer]

danke

[adjustman]

1. Frage woher kommt diese Meldung plötzlich?
2. Wo find ich main.cf?
3. :-)

1. von falschem Eintrag main.cf
2. man locate, man find
3. das ist nicht :) das ist :(