/usr/sbin/ap und 99% CPU Last ?

[tomquenten]

Hallo,

also heute waren es gleich 4 Prozesse. Hier die gewünschten Informationen.

--------------------
ls -alh /proc/*/task/3322/
--------------------

insgesamt 0
dr-xr-xr-x 5 wwwrun www 0  8. Okt 09:14 .
dr-xr-xr-x 3 wwwrun www 0  8. Okt 09:14 ..
dr-xr-xr-x 2 wwwrun www 0  8. Okt 09:53 attr
-r-------- 1 wwwrun www 0  8. Okt 09:53 auxv
-r--r--r-- 1 wwwrun www 0  8. Okt 09:53 cgroup
--w------- 1 wwwrun www 0  8. Okt 09:53 clear_refs
-r--r--r-- 1 wwwrun www 0  8. Okt 09:53 cmdline
-rw-r--r-- 1 wwwrun www 0  8. Okt 09:53 comm
-r--r--r-- 1 wwwrun www 0  8. Okt 09:53 cpuset
lrwxrwxrwx 1 wwwrun www 0  8. Okt 09:53 cwd -> /
-r-------- 1 wwwrun www 0  8. Okt 09:53 environ
lrwxrwxrwx 1 wwwrun www 0  8. Okt 09:53 exe -> /usr/bin/perl
dr-x------ 2 wwwrun www 0  8. Okt 09:53 fd
dr-x------ 2 wwwrun www 0  8. Okt 09:53 fdinfo
-r--r--r-- 1 wwwrun www 0  8. Okt 09:14 io
-r--r--r-- 1 wwwrun www 0  8. Okt 09:53 latency
-rw------- 1 wwwrun www 0  8. Okt 09:53 limits
-rw-r--r-- 1 wwwrun www 0  8. Okt 09:53 loginuid
-r--r--r-- 1 wwwrun www 0  8. Okt 09:53 maps
-rw------- 1 wwwrun www 0  8. Okt 09:53 mem
-r--r--r-- 1 wwwrun www 0  8. Okt 09:53 mountinfo
-r--r--r-- 1 wwwrun www 0  8. Okt 09:53 mounts
-rw-r--r-- 1 wwwrun www 0  8. Okt 09:53 oom_adj
-r--r--r-- 1 wwwrun www 0  8. Okt 09:53 oom_score
-r-------- 1 wwwrun www 0  8. Okt 09:53 pagemap
-r-------- 1 wwwrun www 0  8. Okt 09:53 personality
lrwxrwxrwx 1 wwwrun www 0  8. Okt 09:53 root -> /
-rw-r--r-- 1 wwwrun www 0  8. Okt 09:53 sched
-r--r--r-- 1 wwwrun www 0  8. Okt 09:53 schedstat
-r-------- 1 wwwrun www 0  8. Okt 09:53 sessionid
-r--r--r-- 1 wwwrun www 0  8. Okt 09:53 smaps
-r-------- 1 wwwrun www 0  8. Okt 09:53 stack
-r--r--r-- 1 wwwrun www 0  8. Okt 09:14 stat
-r--r--r-- 1 wwwrun www 0  8. Okt 09:14 statm
-r--r--r-- 1 wwwrun www 0  8. Okt 09:53 status
-r-------- 1 wwwrun www 0  8. Okt 09:53 syscall
-r--r--r-- 1 wwwrun www 0  8. Okt 09:53 wchan

--------------------
cat /proc/*/task/3322/status
--------------------

Name:   perl
State:  R (running)
Tgid:   3322
Pid:    3322
PPid:   1
TracerPid:      0
Uid:    30      30      30      30
Gid:    8       8       8       8
FDSize: 64
Groups: 8
VmPeak:    22336 kB
VmSize:    22336 kB
VmLck:         0 kB
VmHWM:      4128 kB
VmRSS:      3780 kB
VmData:     3024 kB
VmStk:       136 kB
VmExe:      2716 kB
VmLib:      2036 kB
VmPTE:        60 kB
VmSwap:      328 kB
Threads:        1
SigQ:   0/11848
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000015083
SigCgt: 0000000180000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed:   1
Cpus_allowed_list:      0
Mems_allowed:   1
Mems_allowed_list:      0
voluntary_ctxt_switches:        15992
nonvoluntary_ctxt_switches:     1216426

--------------------
cat /proc/*/task/3322/cmdline
--------------------

/usr/sbin/ap^@

Da ich mich nun schon seit einigen Tagen intensiv damit beschäftige wie ich dem Treiben nun endlich auf die Schliche kommen kann, habe ich mir sicherheitshalber auch noch weitere Informationen ausgeben lassen.

netstat | grep ssh

Ergebniss

tcp        0      0 mailserver.servername:ssh dslb-088-074-2:nicelink VERBUNDEN
tcp        0      0 mailserver.servername:ssh dslb-088-074-:gc-config VERBUNDEN

Also okay, denn ich bin immer 2 x selber verbunden. Es ist auch meine IP Adresse.

Da der Prozess unter wwwrun läuft, habe ich mir auch noch die Verbindungen von HTTP ausgeben lassen.

netstat | grep HTTP

Ergebniss

tcp        0      0 mailserver.cot:www-http p5DDBA46E.dip.t-d:59686 TIME_WAIT
tcp        0      0 mailserver.cot:www-http p5DDBA46E.dip.t-d:59698 TIME_WAIT
tcp        0      0 mailserver.cot:www-http p5DDBA46E.dip.t-d:59681 TIME_WAIT
tcp        0      0 mailserver.cot:www-http p5DDBA46E.dip.t-d:59692 TIME_WAIT
tcp        0      0 mailserver.cot:www-http ANancy-552-1-47-211:pip TIME_WAIT
tcp        0      0 mailserver.cot:www-http ANancy-552-1-47-21:brcd TIME_WAIT
tcp        0      0 mailserver.cot:www-http p5DDBA46E.dip.t-d:59689 TIME_WAIT
tcp        0      0 mailserver.cot:www-http p5DDBA46E.dip.t-d:59688 TIME_WAIT
tcp        0      0 mailserver.cot:www-http ANancy-5:vrts-ipcserver TIME_WAIT
tcp        0      0 mailserver.cot:www-http crawl-66-249-66-2:38125 VERBUNDEN
tcp        0      0 mailserver.cot:www-http ANancy-552:bmc_patroldb TIME_WAIT
tcp        0      0 mailserver.cot:www-http p5DDBA46E.dip.t-d:59695 TIME_WAIT
tcp        0      0 mailserver.cot:www-http ANancy-55:dx-instrument TIME_WAIT
tcp        0      0 mailserver.cot:www-http p5DDBA46E.dip.t-d:59663 TIME_WAIT
tcp        0      0 mailserver.cot:www-http p5DDBA46E.dip.t-d:59705 TIME_WAIT
tcp        0      0 mailserver.cot:www-http p5DDBA46E.dip.t-d:59694 TIME_WAIT
tcp        0      0 mailserver.cot:www-http p5DDBA46E.dip.t-d:59696 TIME_WAIT
tcp        0      0 mailserver.cot:www-http p5DDBA46E.dip.t-d:59697 TIME_WAIT
tcp        0      0 mailserver.cot:www-http p5DDBA46E.dip.t-d:59690 TIME_WAIT
tcp        0      0 mailserver.cot:www-http ANancy-552-1-47-211:els TIME_WAIT

Leider haben ich es versäumt mit

netstat -p

zu schauen ob externe Verbindungen die Prozesse ausgelöst haben. Mein Puls war als ich das sah ohnehin schon wieder auf 180.

Was mich etwas verwundert ist die Tatsache das ich ab und zu für einen kurzen Augenblick eine UDP Verbindung habe. Lt. meines Providers sollte dies eigentlich nicht sein.

udp        0      0 mailserver.servername:50405 not-updated.host:domain VERBUNDEN

Was lässt sich von den o.g. 3 gewünschten Informationen alles ablesen? Ich sehe das es Perl Scripte sind, die ich aber auch diesmal nicht in dem angegebenen Verzeichnis finden konnte.

Was tun? Ich weiß nicht mehr weiter.


Gruss
tomquenten

 

[tomquenten]

Hallo,

zur Lösung kann ich noch etwas mehr beisteuern.

Gerade eben waren wieder 2 Prozesse aktiv. Ich bin der Sache etwas auf die Schliche gekommen. Mit der PID habe ich nun versucht mehr rauszubekommen

netstat -p | grep 1986

brachte erstaunliches zu Tage...

tcp  0   1 mailserver.servername:48400 88.146.220.23:ircu      SYN_SENT  1986/ap

Es handelt sich also um einen externen Verbindungsversuch. Der Port ist aber in der Firewall zu. Im übrigen waren die Prozesse jetzt "friedlich", sie schlummerten. Als einer anfing zu arbeiten habe ich ihn getötet.

Mit der IP hatte ich dann in den Logfiles gesucht, ohne Erfolg. Die IP habe ich jetzt erst einmal in die hosts.deny eingetragen. Natürlich löst dies noch nicht mein Problem. Für weitere Vorschläge bin ich auch sehr dankbar.

Gruss + Danke
tomquenten

 

[Joe User]

Riecht nach einem IRC-Bot und deutet mit den anderen Informationen somit darauf hin, dass Dein System ungeschickt aber erfolgreich über eine WebApp gecrackt wurde. Da weder Du noch wir ein RootKit oder Ähnliches ausschliessen können, musst Du nun in exakt dieser Reihenfolge und ohne Ausnahme:
1.) die Kiste Offline nehmen,
2.) Beweise sichern (HDD-Image anlegen),
3.) Deine WebApps analysieren und patchen,
4.) gegebenenfalls Bugreports verfassen,
5.) Dein Sicherheitskonzept entsprechend anpassen,
6.) die Kiste komplett neu aufsetzen und
7.) Dein Nutzdatenbackup einspielen.

 

[Lord_Icon]

Hast du den Eintrag in der richtigen php.ini gemacht? Wenn du sie per cron direkt mit /usr/bin/php ausführst wird (zumindest bei mir, debian) eine andere php.ini als die vom apache verwendet.

Vermutlich nicht.

Ein locate php.ini sollte da aber schon mal die beiden ini's anzeigen.
Und da es sich um ein Suse OS handelt, dürften das wohl die korrekten Pfade sein:

/etc/php5/apache2/php.ini
/etc/php5/cli/php.ini

Riecht nach einem IRC-Bot und deutet mit den anderen Informationen somit darauf hin, dass Dein System ungeschickt aber erfolgreich über eine WebApp gecrackt wurde.

Dieser Aussage würde ich mich anschließen. Allein deshalb schon, das gewisse "Schad"-prozesse als wwwrun:www ausgeführt werden.

Der Threadsteller hat es nach eigenen Aussagen zwar schon erwähnt... aber da möchte ich mal meine Zweifel anmerken.
Irgend eine Lücke muß irgend ein Script haben. Sonst würden wir uns ja hier nicht unterhalten.
Drum wäre Punkt 3 von Joe User als besonders wichtig anzusehen.

Suhousin wird ja mit PHP sicherlich mit einbebunden sein. Es ist zwar kein All-Heil-Mittel... aber das inkludieren von fremdem Datein per URL sollte damit shcon mal unterbunden sein.

@Joe User
Deine 7-Punkte Roadmap ist sicherlich sinnvoll... aber fraglich, ob der diese Zeit nicht besser Nutzen könnte und sich nochmal der eigentlichen Sicherheitslücke zuwenden sollte.

Ein Backup würde nur soviel bringen, das er für wenige Tage Ruhe hätte. Die Lücke bleibt bestehen und die Scriptkiddy's werden wieder die Lücke "angreifen".

Wobei man aber ab den neu einspielen besser(höher) Loggen könnte und beim erneuten auftreten des AP Prozesses alle Logs detailierter und gezielter auswerten könnte.

Denn ich vermute mal, das der Threadersteller nicht weiß, wann er nun genau gehackt worden ist.

Mal eine andere Frage.

6667 ist ein IRC-Bot. Selbst SSF hat ja einen ^^
Aber wnn in der Firewall dieser Port nicht freigegeben worden ist... kann dann eine Verbindung überhaupt etabliert werden ?

Ich gehe bis dato immer noch davon aus, das der Angreifer keine root-Rechte erhalten hat. Somit könnte man die Möglichkeit, das gewisse Programme Grundlegend verändert worden sind erstmal etwas beiseite schieben. Ganz ausschließen sollte man es natürlich nicht.

nmap -v <IP or Domain>

sollte ja von aussen schon mal recht schnell zeigen, ob der 6667 offen ist. Da dieser Befehl von einer anderen Maschine ausgeführt wird, würde ich dann schon mal eine korrekte Ausgabe/Rückgabe von geöffneten Port's voraussetzen.

 

[tomquenten]

Hello and Good Day,

Vermutlich nicht.

Ich habe SELBSTVERSTÄNDLICH in beiden Dateien den Pfad gesetzt. Ich bin zwar (NOCH!) kein Unix Guru, aber ich probiere viel und lerne. Nobody is perfect. Und ja, ich benutze auch die geliebte Tante google bevor ich hier weiter Hilfe suche.

Darüber hinaus hatte ich aber auch kein Ergebnis diesbezüglich auf meiner Spielwiese erhalten. (Suse 11.3.) Auch dort bekomme ich keine Einträge in die Logs, wenn ich eine mail mittels der mail Funktion von PHP versende.

Ich habe mir auch ein kleines Script geschrieben mit dem ich alle Logs mit einmal durchsuchen kann, das Ergebnis wird dann auch gleich in eine Datei geschrieben. Ich habe die letzten Tage fast nichts anderes gemacht als ständig Logs zu durchsuchen. Da mir das schnell zu viel wurde, kam mal schnell dieses Script zusammen. Evtl.hilft dies ja auch anderen weiter.

#!/bin/bash

DATUM=`date +"%d.%m.%Y %T"`

echo '' > /var/log/info_search_logfile.log
echo '--------------------------------------------------' >> /var/log/info_search_logfile.log
echo 'LOGFILE SEARCH INFORMATIONEN VOM '${DATUM} >> /var/log/info_search_logfile.log
echo '--------------------------------------------------' >> /var/log/info_search_logfile.log
echo '' >> /var/log/info_search_logfile.log

echo '--------------------' >> /var/log/info_search_logfile.log
echo 'ACCESS_LOG' >> /var/log/info_search_logfile.log
echo '--------------------' >> /var/log/info_search_logfile.log
echo '' >> /var/log/info_search_logfile.log
cat /var/log/apache2/access_log | grep ${1} >> /var/log/info_search_logfile.log

echo '--------------------' >> /var/log/info_search_logfile.log
echo 'ACCESS.LOG' >> /var/log/info_search_logfile.log
echo '--------------------' >> /var/log/info_search_logfile.log
echo '' >> /var/log/info_search_logfile.log
cat /var/log/apache2/access.log | grep ${1} >> /var/log/info_search_logfile.log

echo '--------------------' >> /var/log/info_search_logfile.log
echo 'ERROR_LOG' >> /var/log/info_search_logfile.log
echo '--------------------' >> /var/log/info_search_logfile.log
echo '' >> /var/log/info_search_logfile.log
cat /var/log/apache2/error_log | grep ${1} >> /var/log/info_search_logfile.log

echo '--------------------' >> /var/log/info_search_logfile.log
echo 'MAILLOG' >> /var/log/info_search_logfile.log
echo '--------------------' >> /var/log/info_search_logfile.log
echo '' >> /var/log/info_search_logfile.log
cat /var/log/mail | grep ${1} >> /var/log/info_search_logfile.log

echo '--------------------' >> /var/log/info_search_logfile.log
echo 'FIREWALL' >> /var/log/info_search_logfile.log
echo '--------------------' >> /var/log/info_search_logfile.log
echo '' >> /var/log/info_search_logfile.log
cat /var/log/firewall | grep ${1} >> /var/log/info_search_logfile.log

echo '--------------------' >> /var/log/info_search_logfile.log
echo 'DENYHOST' >> /var/log/info_search_logfile.log
echo '--------------------' >> /var/log/info_search_logfile.log
echo '' >> /var/log/info_search_logfile.log
cat /var/log/denyhosts | grep ${1} >> /var/log/info_search_logfile.log

echo '--------------------' >> /var/log/info_search_logfile.log
echo 'VSFTP' >> /var/log/info_search_logfile.log
echo '--------------------' >> /var/log/info_search_logfile.log
echo '' >> /var/log/info_search_logfile.log
cat /var/log/vsftpd.* | grep ${1} >> /var/log/info_search_logfile.log

echo '--------------------' >> /var/log/info_search_logfile.log
echo 'WARN' >> /var/log/info_search_logfile.log
echo '--------------------' >> /var/log/info_search_logfile.log
echo '' >> /var/log/info_search_logfile.log
cat /var/log/warn | grep ${1} >> /var/log/info_search_logfile.log

echo '--------------------' >> /var/log/info_search_logfile.log
echo 'LASTLOG' >> /var/log/info_search_logfile.log
echo '--------------------' >> /var/log/info_search_logfile.log
echo '' >> /var/log/info_search_logfile.log
cat /var/log/lastlog | grep ${1} >> /var/log/info_search_logfile.log

echo '--------------------' >> /var/log/info_search_logfile.log
echo 'DOVECOT.INFO' >> /var/log/info_search_logfile.log
echo '--------------------' >> /var/log/info_search_logfile.log
echo '' >> /var/log/info_search_logfile.log
cat /var/log/dovecot.info | grep ${1} >> /var/log/info_search_logfile.log

echo '--------------------' >> /var/log/info_search_logfile.log
echo 'DOVECOT.ERR' >> /var/log/info_search_logfile.log
echo '--------------------' >> /var/log/info_search_logfile.log
echo '' >> /var/log/info_search_logfile.log
cat /var/log/dovecot.err | grep ${1} >> /var/log/info_search_logfile.log

echo '--------------------' >> /var/log/info_search_logfile.log
echo 'FAILLOG' >> /var/log/info_search_logfile.log
echo '--------------------' >> /var/log/info_search_logfile.log
echo '' >> /var/log/info_search_logfile.log
cat /var/log/faillog | grep ${1} >> /var/log/info_search_logfile.log

Natürlich habe ich auch nochmals mit

nmap -v <IP or Domain>

selbst geprüft ob und welche Ports offen sind. Um auch GANZ sicher zu gehen, habe ich dies auch von meiner Spielwiese ausgeführt, die definitiv sauber ist, das Sie nicht ständig läuft und zusätzlich auch noch an einer DSL Leitung hängt, sprich die IP sich ohnehin alle 24 Stunden ändert.

Ergebnis...
Port 6667 ist geschlossen.

Beim durchsuchen der Logs habe ich auch die Uhrzeiten berücksichtigt. Sprich, ich habe mir beim Auftreten der ap Scripte auch die Einträge mit den Uhrzeiten des Auftretens in allen Logs gesucht. Beim ersten Auftreten, welches ich bemerkt habe - kann mir da ja nicht sicher sein ob vorher schon was war, habe ich mit den Uhrzeiten nichts gefunden. Ich werde jetzt erst einmal für jeden Kunden ein separates www temp erstellen, um dahingehend eingrenzen zu können von wem die Schwachstelle sein könnte.

Ich werde sicher wieder berichten....



Danke

tomquenten

 

[Joe User]

Ähm, der Server des OP baut eine IRC-Verbindund nach aussen auf, da bringt einem nmap herzlich wenig...

@Lord_Icon
Punkt 3 erledigt man read-only an Punkt 2 und nicht am lebenden Objekt. Desweiteren schrieb ich Nutzdatenbackup und nicht Fullbackup. Nutzdaten beinhalten ausdrücklich keine Apps (Binaries, Libraries, Scripts) sondern ausschliesslich die zum Betrieb der Websites zwingend benötigten Daten (DB, Text, Bilder). Apps, Configs und temporäre Daten lassen sich jederzeit neu erzeugen und/oder beliebig austauschen, Nutzdaten hingegen nicht.

@OP
Nimm endlich die Kiste vom Netz bevor Du die rechtlichen Konsequenzen tragen musst!

 

[Lord_Icon]

Das ist ja alles korrekt. Sicherlich wird hier keiner sagen wollen, das eine kompromittiert Kiste weiter am Netz bleiben sollte.

Aber egal. Das muß der Threadersteller selbst wissen.

Interessieren würde mich jetzt aber mal:

Mittels netstats kann ich doch erstmal alle Verbindungen zum Server ausgeben lassen. Hier müßte ja dann eine etablierte Verbingung zu finden sein.

Ähm, der Server des OP baut eine IRC-Verbindund nach aussen auf, da bringt einem nmap herzlich wenig...

Diesbezüglich muß ich nochmal nachfragen.

Wenn das stimmen sollte, liegt mir ein falsches Wissen vor. (was sicherlich möglich wäre)
Wenn ich in der Firewall z.B. ausschließlich den HTTP also Port 80 erlaubt habe, dann bezieht sich das auf interne Verbindungen ?

Scriptkiddy's können dennoch einen 6667 Port öffnen und erfolgreich eine Verbindung etablieren ?


Ich bin der Meinung, das eine Firewall (egal welche es sein sollte) immer beide Seiten dicht macht.

Ausgenommen natürlich: Die Kiste ist gehackt... Scripte sind verändert worden und tarnen sich.

 

[Joe User]

Ich bin der Meinung, das eine Firewall (egal welche es sein sollte) immer beide Seiten dicht macht.

Nö, sie tut nur Das was man ihr explizit sagt, nicht mehr und oft so gar weniger. Zudem verhexelst Du hier Firewall (dedizierte Hardware) mit Paketfilter (lokale Software). Beide haben allerdings Eines gemeinsam: Man muss ganz genau wissen, was man tut und wie man es tut. Anderenfalls schiesst man sich gewaltig ins eigene Knie. Aus diesem Grund sind auch Tools wie DenyHosts oder Fail2Ban regelrecht gefährlich, da die 99,9% ihrer User keine Ahnung haben, was diese Tools tun beziehungsweise nicht tun. Aber das hier zu erläutern führt eindeutig zu weit...