Gefälschte IP-Adressen

[charlie]

Hi Forum,

bei mir hat sich jemand zugriff auf das System verschafft, mit normalen Linux User Rechten. Der Server wurde abgeschaltet wegen gefälschter IP Adressen:

Code: Select all

TCPdump

09:37:46.636589 00:0b:6a:e2:27:36 > 00:00:5e:00:01:d1, ethertype IPv4 (0x0800), length 62: 231.65.163.8.3072 > 81.161.170.19.22: S 3864550407:3864550407(0) win 8192 <mss 1460,nop,nop,sackOK>
09:37:46.636646 00:0b:6a:e2:27:36 > 00:00:5e:00:01:d1, ethertype IPv4 (0x0800), length 62: 66.179.187.102.3072 > 81.161.170.19.22: S 188615236:188615236(0) win 8192 <mss 1460,nop,nop,sackOK>
09:37:46.636707 00:0b:6a:e2:27:36 > 00:00:5e:00:01:d1, ethertype IPv4 (0x0800), length 62: 73.114.2.14.3072 > 81.161.170.19.22: S 658794367:658794367(0) win 8192 <mss 1460,nop,nop,sackOK>
09:37:46.636782 00:0b:6a:e2:27:36 > 00:00:5e:00:01:d1, ethertype IPv4 (0x0800), length 62: 39.169.239.78.3072 > 81.161.170.19.22: S 3136433504:3136433504(0) win 8192 <mss 1460,nop,nop,sackOK>
09:37:46.636823 00:0b:6a:e2:27:36 > 00:00:5e:00:01:d1, ethertype IPv4 (0x0800), length 62: 71.202.85.80.1024 > 81.161.170.19.22: S 318382646:318382646(0) win 8192 <mss 1460,nop,nop,sackOK>

Der User ist jetzt gelöscht und das Home Verzeichnis und /tmp auch. Ich habe kein chroot installiert. Ich hoffe und denke das die Rechte immer gut gesetzt wurden. Es wurde laut Logfiles versucht root rechte zu erreichen aber nicht erreicht. Der User war insgesamt ca. 12 Stunden auf dem System. Was meint Ihr was der User auf dem System erreicht haben kann. Wie wäre installierte Software von ihm zu finden??

help,
charlie

[djcrackman]

Server neu installieren - alles andere steht nicht zur Diskussion.

[Roger Wilco]

http://www.rootforum.org/faq/14_183_de.html
http://www.rootforum.org/faq/14_104_de.html

[nyxus]

Server neu installieren - alles andere steht nicht zur Diskussion.

versuchen herauszufinden was man beim nächsten Mal besser machen könnte bzw. sollte steht nicht zur Diskussion? Interessant ...

[djcrackman]

@Nyxus Nix für ungut - wenn auf einem deiner Systeme 12 Stunden lang jemand aktiv war und du nicht den geringsten Deut einer Ahnung hast -> dann steht wohl wirklich nichts zur Diskussion. Backup/Image muss er so oder so noch machen -> da kann er sich das Image DANACH auch noch in ne VMWare laden und nachsehen. Vorher bringt ihm das Wenig. Und wenn er nicht wirklich weiß wie, wo, wann, was -> dann is das einzige was er im Moment machen sollte: Kiste abschalten und Admin anschaffen!

[wgot]

Hallo,

Es wurde laut Logfiles versucht root rechte zu erreichen aber nicht erreicht.

oder es wurden Rootrechte erreicht und die Logfiles so verändert, daß es aussieht als ob keine Rootrechte erreicht wurden.

Root kann alles, auch Logfiles manipulieren.

Fehleranalyse (aber bitte im Rescue) und Neuinstallation.

Gruß, Wolfgang

[nyxus]

@Nyxus Nix für ungut - wenn auf einem deiner Systeme 12 Stunden lang jemand aktiv war und du nicht den geringsten Deut einer Ahnung hast -> dann steht wohl wirklich nichts zur Diskussion. Backup/Image muss er so oder so noch machen -> da kann er sich das Image DANACH auch noch in ne VMWare laden und nachsehen. Vorher bringt ihm das Wenig.

Wenn er nach Deinem ersten Vorschlag vorgehen würde ist aber nichts mehr mit "hinterher Logfiles anschauen"

Und wenn er nicht wirklich weiß wie, wo, wann, was -> dann is das einzige was er im Moment machen sollte: Kiste abschalten und Admin anschaffen!

schon eine ganz andere Aussage, die in Deinem letzten Beitrag auch noch nicht zur Diskussion stand.

Allerdings war in dem Beitrag deutlich erkennbar, daß der OP herausfinden wollte was los war. Und dazu hat er ja z.B. auch von Roger einen Hinweis bekommen, *zusammen* mit dem Hinweis auf die Neuinstallation.

[mattiass]

Root kann alles, auch Logfiles manipulieren.

Bei richtigen Betriebssystemen sind die wirklich wichtigen Logfiles Append-Only gesetzt. Da sich das Securelevel nur erhöhen lässt, ist ein Reboot nötig, um Logfiles manipulieren zu können.

<troll>
Achso, ich bin in einem Linux-Forum. Muss man bei dem Bastel-Unix solche Features erst mit Patches nachrüsten oder geht das mittlerweile auch Out-Of-The-Box? :D
</troll>

[captaincrunch]

"chatttr +a /var/log/messages" ist selbst beim "Bastel-Unix" möglich, auch wenn's nicht ganz so weit geht wie bei den Troll-OS. ;)

[nyxus]

Bei richtigen Betriebssystemen sind die wirklich wichtigen Logfiles Append-Only gesetzt. Da sich das Securelevel nur erhöhen lässt, ist ein Reboot nötig, um Logfiles manipulieren zu können.

Bei welchem System geht das out-of-the-Box? Schon mit xBSD?

[mattiass]

Bei richtigen Betriebssystemen sind die wirklich wichtigen Logfiles Append-Only gesetzt. Da sich das Securelevel nur erhöhen lässt, ist ein Reboot nötig, um Logfiles manipulieren zu können.

Bei welchem System geht das out-of-the-Box? Schon mit xBSD?

Sogar bei MacOS X...

man securelevel

[daemotron]

Blöde Frage - wie funktioniert in einem solchen Fall dann logrotate? Theoretisch dürfte der dann dem Logfile ja nicht zuleibe rücken (kopieren und packen natürlich schon, aber leeren :?: )

[captaincrunch]

wie funktioniert in einem solchen Fall dann logrotate?

Gar nicht, bzw. hat logrotate in diesem Fall erst gar nichts zu tun. Bei den "wirklich wichtigen Logfiles", die Matthias ansprach handelt es sich nämlich "nur" um [uw]tmp. So viel weiter ist die BSD-Fraktion an dieser Stelle nämlich auch noch nicht.

[mattiass]

Gar nicht, bzw. hat logrotate in diesem Fall erst gar nichts zu tun. Bei den "wirklich wichtigen Logfiles", die Matthias ansprach handelt es sich nämlich "nur" um [uw]tmp. So viel weiter ist die BSD-Fraktion an dieser Stelle nämlich auch noch nicht.

Naja, kommt drauf an. Abgesehen davon kann man durch Erhöhen der Securelevel bspw. verhindern, dass Dateisysteme RW gemountet werden etc., was bspw. bei Firewalls Sinn machen kann. Unter Linux würde ich für ein solches System wahrscheinlich schnell eine BusyBox und einen Kernel ohne Module zusammenschustern und beides von CD laden.

Es gibt halt immer verschiedene Ansätze, ein Problem zu lösen. Wirklich schade finde ich, dass bei Linux einige bei BSD serienmäßige Features (funktionierendes UnionFS, Jails) erst reingepatcht werden müssen... Ich fahre deshalb derzeit gerade auf dem Server sehr gut mit BSD.

[captaincrunch]

Auch wenn die Diskussion jetzt vom eigentlichen Punkt der "sicheren" Logfiles wegführt: keine Sorge, ich möchte weder dir, noch sonst irgend jemandem "sein" System streitig machen, und bin durchaus in der Lage, über meinen Tellerrand hinaus zu schauen. Gerade im Firewallbereich setze ich z.B. lieber auf OpenBSD statt auf Linux.

Wie du selbst schon sagst: Unter Unix führen mehrere Wege zum Ziel, und je verbreiteter Techniken vie Jails und Co. werden, desto einfacher wird es, diese out of the box nutzen zu können. Schau dir z.B. einmal das auf Sicherheit getrimmte (aber IMHO seit langem mehr oder weniger tote) Adamantix an. Richtig eingesetzt und von einem Admin mit genug Background verwaltet, können diverse andere Systeme (um es bewusst global zu halten) ganz schnell einpacken.

Ich finde es halt nur immer wieder spaßig, solch kleine Sticheleien der Jungs vom anderen OS wenigstens zum Teil wiederlegen zu können, daher nichts für ungut. ;)

[charlie]

Hi,

ja man sollte auch mal die Kirche im Dorf lassen.
Es ist ja nicht immer notwendig des ganze Haus ein zu reisen, wenn mal der Dachstuhl kaputt ist.
Hatte mir mehr erwartet als wie immer die gelobte radikal Methode. Der Server läuft nach dem stopfen des Lochs nun mehr seit 5 Tagen ohne gefälschte IP- Adressen. Also es gibt noch Hoffung für alle geschädigten...

mfg
charlie