
Ich versuche derzeit, einen Server zu bereinigen und zu sichern, auf dem pnscan läuft. Diese Instanz von pnscan wurde von einem externen Anbieter installiert, der unseren Server höchstwahrscheinlich als Teil eines Port-Scanning-Botnetzes verwendet. Es scheint, dass er seine Binärdateien in /dev/shm und /tmp schreiben kann.
Hier ist die Ausgabe von „lsof | grep pnscan“:
[email protected]:/home/bitnami# lsof | grep pnscan
pnscan 9588 daemon cwd DIR 8,1 4096 647169 /tmp
pnscan 9588 daemon rtd DIR 8,1 4096 2 /
pnscan 9588 daemon txt REG 8,1 18468 647185 /tmp/pnscan
pnscan 9588 daemon mem REG 8,1 42572 418331 /lib/tls/i686/nosegneg/libnss_files-2.11.1.so
pnscan 9588 daemon mem REG 8,1 1421892 418349 /lib/tls/i686/nosegneg/libc-2.11.1.so
pnscan 9588 daemon mem REG 8,1 79676 418329 /lib/tls/i686/nosegneg/libnsl-2.11.1.so
pnscan 9588 daemon mem REG 8,1 117086 418343 /lib/tls/i686/nosegneg/libpthread-2.11.1.so
pnscan 9588 daemon mem REG 8,1 113964 402913 /lib/ld-2.11.1.so
pnscan 9588 daemon 0r CHR 1,3 0t0 705 /dev/null
pnscan 9588 daemon 1w CHR 1,3 0t0 705 /dev/null
pnscan 9588 daemon 2w FIFO 0,8 0t0 37499 pipe
pnscan 9588 daemon 3r REG 8,1 203 516243 /opt/bitnami/apache2/cgi-bin/php-cgi
pnscan 9588 daemon 4u REG 0,15 0 37558 /dev/shm/.x
pnscan 9588 daemon 5u IPv4 37559 0t0 TCP domU-12-31-39-14-41-41.compute-1.internal:52617->lab1.producao.uff.br:www (ESTABLISHED)
pnscan 9588 daemon 6u IPv4 3688467 0t0 TCP domU-12-31-39-14-41-41.compute-1.internal:55926->200.25.69.27:www (SYN_SENT)
Und hier ist die Ausgabe von „ps aux | grep pnscan“:
daemon 9588 2.3 0.1 3116204 3272 ? Sl 21:42 1:55 /tmp/pnscan -rApache -wHEAD / HTTP/1.0\r\n\r\n 200.0.0.0/8 80
Wir wären für jeden Ratschlag dankbar, der uns hilft, die Ursache dafür zu finden.
Danke!
Antwort1
Normalerweise ist ein kompromittierter Server
- als Bild für weitere Untersuchungen in einem geschlossenen Labor gesichert
- neu abgebildet oder neu installiert/wiederhergestellt, um die Produktion aufrechtzuerhalten
Einen kompromittierten Rechner, selbst wenn er scheinbar bereinigt wurde, in der Produktion zu belassen, ist keine sichere Vorgehensweise.
Antwort2
es sieht so aus, als ob dieser „pnscan“-Code von UID 9588 ausgeführt wird.
Sie könnten eine iptables-Direktive einrichten, die mit dieser UID übereinstimmt und den gesamten ausgehenden Datenverkehr VERRINGERT. Oder Sie könnten die Verbindung auf ausschließlich ausgehendes TCP/80 und TCP/22 oder so etwas beschränken …