RootForum Community

Hi,

jetzt ist auch mein Server gekackt worden. Zugegeben habe ich wenig Vorkehrungen getroffen, dies zu verhindern, eher wegen fehlendem Know-How.

Ich mache gerade einen Backup und werde dann den Startschuss zum Reinitialiesieren geben. Auf dem Server lief suse7.2, ist der Server nach der Neuinstallation und suse 8.1 schon etwas sicherer? Was sollte ich nach der Neuinstallation sofort unternehmen? Ich glaube die Kiste wurde über proftp gehackt, soll ich komplett auf fpt verzichten?

Ich schicke auch mal einen Auszug aus der log/message um Eure Meinung dazu zu hören:

************* 16.00 Uhr startete er seine Versuche *************
Jan 1 16:02:51 p15097586 proftpd[26416]: connect from 213.23.177.199 (213.23.177.199)
Jan 1 16:02:51 p15097586 proftpd[26416]: p15097586.pureserver.info (dsl-213-023-177-199.arcor-ip.net[213.23.177.199]) - FTP session opened.
Jan 1 16:02:51 p15097586 proftpd[26416]: p15097586.pureserver.info (dsl-213-023-177-199.arcor-ip.net[213.23.177.199]) - no such user 'anonymous'
Jan 1 16:02:51 p15097586 last message repeated 4 times
Jan 1 16:02:51 p15097586 proftpd[26416]: p15097586.pureserver.info (dsl-213-023-177-199.arcor-ip.net[213.23.177.199]) - USER anonymous: no such user found from dsl-213-023-177-199.arcor-ip.net [213.23.177.199] to 217.160.128.156:21
Jan 1 16:02:51 p15097586 proftpd[26416]: p15097586.pureserver.info (dsl-213-023-177-199.arcor-ip.net[213.23.177.199]) - FTP session closed.
Jan 1 15:54:00 p15097586 /USR/SBIN/CRON[23197]: (root) CMD (/root/confixx/confixx_counterscript.pl)
Jan 1 16:01:20 p15097586 popper[25873]: connect from 80.143.166.254 (80.143.166.254)
Jan 1 16:01:21 p15097586 popper[25880]: connect from 80.143.166.254 (80.143.166.254)
Jan 1 16:01:21 p15097586 popper[25881]: connect from 80.143.166.254 (80.143.166.254)
Jan 1 16:01:22 p15097586 popper[25888]: connect from 80.143.166.254 (80.143.166.254)
Jan 1 16:02:00 p15097586 /USR/SBIN/CRON[26114]: (root) CMD (/root/confixx/confixx_counterscript.pl)
Jan 1 16:02:51 p15097586 proftpd[26416]: connect from 213.23.177.199 (213.23.177.199)
Jan 1 16:02:51 p15097586 proftpd[26416]: p15097586.pureserver.info (dsl-213-023-177-199.arcor-ip.net[213.23.177.199]) - FTP session opened.
Jan 1 16:02:51 p15097586 proftpd[26416]: p15097586.pureserver.info (dsl-213-023-177-199.arcor-ip.net[213.23.177.199]) - no such user 'anonymous'
Jan 1 16:02:51 p15097586 last message repeated 4 times
Jan 1 16:02:51 p15097586 proftpd[26416]: p15097586.pureserver.info (dsl-213-023-177-199.arcor-ip.net[213.23.177.199]) - USER anonymous: no such user found from dsl-213-023-177-199.arcor-ip.net [213.23.177.199] to 217.160.128.156:21
Jan 1 16:02:51 p15097586 proftpd[26416]: p15097586.pureserver.info (dsl-213-023-177-199.arcor-ip.net[213.23.177.199]) - FTP session closed.

*********** Und um 16.37 Uhr dann das: *******************
Jan 1 16:37:58 p15097586 kernel: x uses obsolete (PF_INET,SOCK_PACKET)
Jan 1 16:37:58 p15097586 kernel: eth0: Promiscuous mode enabled.
Jan 1 16:37:58 p15097586 kernel: device eth0 entered promiscuous mode
Jan 1 16:37:58 p15097586 modprobe: modprobe: Can't locate module ppp0
Jan 1 16:38:00 p15097586 /USR/SBIN/CRON[8824]: (root) CMD (/root/confixx/confixx_counterscript.pl)
Jan 1 16:38:01 p15097586 modprobe: modprobe: Can't locate module ppp0
Jan 1 16:38:37 p15097586 xc[9283]: log: executing remote command as root: /usr/bin/passwd root
******************************************************

Danke schon mal für Eure Hinweise und Meinungen!

Hi,
erstmal die Reinitialisierung ist eine gute Idee :lol:

Ich würde nicht davon ausgehen, dass er durch den FTP gekommen ist, er versuchte sich mehrfach als anonymous einzuloggen, was anscheinend aber nicht erfolgreich war (seh zumindest in diesen Logs nichts anderes).

Viel mehr sorgen würde mir:

Formisano wrote:[...]
Jan 1 16:38:37 p15097586 xc[9283]: log: executing remote command as root: /usr/bin/passwd root
[...]

machen. Was ist dieses xc?

so long
static

Formisano wrote:Zugegeben habe ich wenig Vorkehrungen getroffen, dies zu verhindern, eher wegen fehlendem Know-How.

no comment

Formisano wrote:ist der Server nach der Neuinstallation und suse 8.1 schon etwas sicherer?

Nein.

Formisano wrote:Was sollte ich nach der Neuinstallation sofort unternehmen?

1) shutdown -h now
2) https://vertrag.1und1.de/
3) http://hosting.1und1.de/xml/static?__page=exclusive

Formisano wrote:soll ich komplett auf fpt verzichten?

Ja.

phantom wrote:

Code: Select all

Title:		XC Comm
Version:	4.3.2

Das ist nicht Dein Ernst, oder?

Denkmal die sind eher über einen kernel BUG auf das System gekommen.

XC war das nicht irgendwas von XFREE86 ??

Die Kiste richtig sicher machen ist ein laaaanger Weg und ganz sicher wirst Du Sie auch nicht bekommen da es immer einen BUG, ein Schlupfloch wie auch immer geben wird, Du kannst nur versuchen es dem Angreifer so schwer wie möglich zu machen und zumindest die ganzen Script-Kiddies abzuweheren, die eh wenn Ihr Script nicht von Anfang an funktioniert sich ein neues Opfer suchen.

Ich kann Dir nur sagen wie ich meine Server einrichte und fertig mache, allerdings eigene Server keine 1&1 Server.

Zunächst spiel Dir ein "vernünftiges" OS auf den Server (Debian, FreeBSD, Redhat ((bedingt)) mit dem remote tool soll das ja vernünftig gehen.

Dann richte Dir Deine Standardsoftware ein Apache, MySQL etc. pp. was ein Webserver ebend "zum leben braucht" :)

/tmp Verzeichniss als noexec, nosuid mounten:

Zunächst ein Backup der /etc/fstab
cp /etc/fstab /etc/fstab.original

cd /dev/
dd if=/dev/zero of=Tmp bs=1024 count=100000

(100 MB sollten reichen)

Dateisystem anlegen:
mkfs -t ext3 /dev/Tmp

cd /

Backup der alten tmp Files:
cp -aR /tmp /tmp_backup

und das Teil mounten:
mount -o loop,noexec,nosuid,rw /dev/Tmp /tmp

Backup Dateien zurücksichern:
cp -aR /tmp_backup/* /tmp/

und die rechte des tmp Verzeichnisses setzen:
chmod 0777 /tmp
chmod +t /tmp

danach die /etc/fstab mit:
/dev/Tmp /tmp ext3 loop,rw,nosuid,noexec 0 0

modifizieren.

Tripwire (http://www.tripwire.org/) installieren ist sehr gut um zu sehen welche Dateien auf dem Server geändert wurden.

Rootlogin per SSH abschalten:

pico /etc/ssh/sshd_config
die zeile welche lautet:
# PermitRootLogin yes
ändern in:
PermitRootLogin no

Den User welcher das su Kommando ausführen darf wählen:
usermod -G wheel username

pico /etc/pam.d/su

und das # vor:
auth required /lib/security/pam_wheel.so use_uid
entfernen.

Normalerweise nehme ich auf für SSH eine extra IP an einem anderen Port (eg. 55555) aber bei PT gibt es ja nur eine IP

Firewall installieren:

Ich nehme dazu immer APF lässt sich gut konfigurieren und habe damit ganz gute Erfahrungen (hat auch ein Antidos Modul)
http://www.rfxnetworks.com/apf.php

Bastille ist aber auch zu empfehlen.

Compiler unschädlich machen:

Entweder ganz deinstallieren oder wenn Du das nicht willst chmod 000

cd /usr/bin/
chmod 000 perlcc byacc yacc bcc kgcc cc gcc i386*cc
chmod 000 *c++ *g++
chmod 000 /usr/lib/bcc /usr/lib/bcc/bcc-cc1

Das selbe mit wget, lynx, w3m


Als Standard:
Telnet deaktivieren
Kernel updaten
Alles Software auf den neuesten Stand bringen

Und vorallem nur das Installieren was Du wirklich benötigst je mehr Software, umsomehr angriffsstellen


Es gibt noch viel, viel mehr Tips zu dem Thema aber als Einstieg sollte das eigentlich reichen ---->> Google is your Friend :)

IMHO sind die meisten Tips meines Vorredners Security by obscurity (und damit z.T. relativ nutzlos (sorry)):

ssh an eigener IP? So lange der Dienst erreichbar ist, ist er angreifbar.

"Firewall" auf einem einzelnen Rechner? Um ehrlich zu sein traue ich den wenigsten hier zu, das ganze auch vrnünftig genug konfigurieren zu können, damit es überhauot irgend einen kleinsten Sinn ergibt.

Bastille? Wenn du nicht ganz genau weißt, was du tust, hast du auf einem System ohne Konsolenzugang komplett verloren.

CaptainCrunch wrote:IMHO sind die meisten Tips meines Vorredners Security by obscurity (und damit z.T. relativ nutzlos (sorry)):.

Du hast gegen einen Angreifer, der sein "Handwerk" versteht sowieso nur eine minimal Chance.

ssh an eigener IP? So lange der Dienst erreichbar ist, ist er angreifbar.

Klar ist er angreifbar und erreichbar aber wenn ein Server angegriffen wird, dann zumeisst über die Domain. Die Scripte Scannen dann auch nur die IP der Domain und dort läuft kein SSH, da der Port beim Scan der IP auch geschlossen ist. Welche IP's auf einem Server noch laufen lässt sich zwar über Umwege ermitteln aber nicht für das gro der Script-Hacker

"Firewall" auf einem einzelnen Rechner? Um ehrlich zu sein traue ich den wenigsten hier zu, das ganze auch vrnünftig genug konfigurieren zu können, damit es überhauot irgend einen kleinsten Sinn ergibt.

Jeder muss wissen was er tut, aber ganz ohne würd ich Ihn nicht laufen lassen. server von "Billig-Anbietern" sind immer wieder bevorzugtes Angriffsziel

Bastille? Wenn du nicht ganz genau weißt, was du tust, hast du auf einem System ohne Konsolenzugang komplett verloren.

Gibt ja bei 1&1 wenigstens das recovery Tool :)

Also CaptainCrunch hat schon recht. ssh ist im normalfall wirklich das kleinste Problem. Wenn man möchte kann man ja den Port ändern, aber das halte ich kaum für sinnvoll. Genau wie die Firewall, aber hierzu hab ich mich schon oft genug hier im Forum geäußert. Die Sache mit dem noexec,sosuid /tmp ist schonmal ne gute Sache, genau wie Tripwire, was aber nicht ganz einfach zu konfigurieren ist. Den Compiler zu chmodden ist auch nur bedingt sinnvoll, wenn der Angreifer eh schon root ist. Ansonsten reicht 700, damit man den stuff zumindest selbst noch benutzten kann.

Du hast gegen einen Angreifer, der sein "Handwerk" versteht sowieso nur eine minimal Chance.

Schon klar, nur halten sich Leute, die "ihr Handwerk" verstehen nicht mit einem solchen Kleinsch... auf.

Die Scripte Scannen dann auch nur die IP der Domain und dort läuft kein SSH

Gefährlicher Irrglaube. Mehr ist dazu leider nicht zu sagen.

Jeder muss wissen was er tut

Genau, und gerade wenn's um Dinge wie eine "Firewall" geht, wissen es halt nur herzlich wenige. Ach ja, ich vergaß: mittlerweile kann man sich die supersichere, tollste und beste Firewall ja von Scripten automatisch basteln lassen ... :roll:

Higgins wrote:

CaptainCrunch wrote:IMHO sind die meisten Tips meines Vorredners Security by obscurity (und damit z.T. relativ nutzlos (sorry)):.

Du hast gegen einen Angreifer, der sein "Handwerk" versteht sowieso nur eine minimal Chance.

Ein Admin, welcher sein "Handwerk" beherscht, beherscht auch das "Handwerk" eines potentiellen Angreifers, da beide vom gleichem "Handwerk" leben.

Higgins wrote:

"Firewall" auf einem einzelnen Rechner? Um ehrlich zu sein traue ich den wenigsten hier zu, das ganze auch vrnünftig genug konfigurieren zu können, damit es überhauot irgend einen kleinsten Sinn ergibt.

Jeder muss wissen was er tut, aber ganz ohne würd ich Ihn nicht laufen lassen. server von "Billig-Anbietern" sind immer wieder bevorzugtes Angriffsziel

Deine "Firewall" schützt Deinen RootServer genauso effektiv, wie Zonealarm einen WindowsPC, nämlich gar nicht!

Higgins wrote:Gibt ja bei 1&1 wenigstens das recovery Tool :)

Aua.

øxygen wrote:Also CaptainCrunch hat schon recht. ssh ist im normalfall wirklich das kleinste Problem. Wenn man möchte kann man ja den Port ändern, aber das halte ich kaum für sinnvoll. Genau wie die Firewall, aber hierzu hab ich mich schon oft genug hier im Forum geäußert. Die Sache mit dem noexec,sosuid /tmp ist schonmal ne gute Sache, genau wie Tripwire, was aber nicht ganz einfach zu konfigurieren ist. Den Compiler zu chmodden ist auch nur bedingt sinnvoll, wenn der Angreifer eh schon root ist. Ansonsten reicht 700, damit man den stuff zumindest selbst noch benutzten kann.

Wenn er schon root ist, ist eh alles zu spät nur um bisdahin zu kommen braucht er nen Compiler (ja, ja nicht zwingend ich weiss)

Tripwire Grundconfig für redhat:

Sollte normalerweise schon installiert sein, ansonsten

up2date - tripwire

/etc/tripwire/twinstall.sh

Das Standard Tripwire config File etwas "entmüllen"
cat > ./cleantw.pl ^D

und ausführen:
perl cleantw.pl < twpol.txt > cleanedpol.txt

pico cleanedpol.txt

und hier zumindest noch den Hostnamen ändern sowie
/usr/sbin/twadmin -m P cleanedpol.txt
/usr/sbin/tripwire --init

wenn man die Ergebnisse zugemailt haben will dann den Cronjop von Tripwire ändern von:
in
wie gesagt ur eine Grundconfig


Ergänzend:

http://www.troubleshooters.com/lpm/200304/200304.htm

Die Scripte Scannen dann auch nur die IP der Domain und dort läuft kein SSH

Nö, die scannen ganze Subnetze, und zwar per IP-Block. Hostnamen sind denen sowas von Wurscht...
Ok, Ausnahme bilden wohl höchstens die IRC-/Gamer-Wars und privaten Kleinkriege...

n'abend,

habe mal wie weiter oben versucht /tmp Verzeichniss als noexec, nosuid mounten. laut sysinfo, wird aber jetzt der disk swap völlig ignoriert. der physical memory ist bei ca. 93% und der disk swap komplett bei null. sonst waren da immer so 10% gestanden. hat jemand von euch eine ahnung?

danke

Wo bitte siehst du da den Zusammenhang? Die VM-Algorithmen des Kernels sind halt (fast) unergründlich. ;)

na, das ist eben erst aufgetreten, als ich diese o.g. modifikationen durchgeführt hatte. demzufolge schließe ich darauf, dass es was damit zu tun hat :-))