Unberechtigte Root-Berechtigungen erkennen und entfernen
Hallo, ich muss zu nächster Woche Montag drei Linux-Server (SuSE 7.3) übernehmen und habe nun das Problem das ich herausfinden muss ob und wenn ja, welche User noch Berechtigungen haben tiefer in das System einzugreifen. Es muss also sichergestellt sein, dass nachdem ich das Root-Kennwort geändert habe, ich der einzige bin der Administrationsarbeiten im System vornehmen darf. Klar ist es nun nicht die feine Art dem Kunden von vornherein mal Boshaftigkeiten zu unterstellen, aber immerhin hängt u.a. die (Betiebs-)Sicherheit und relativ hohe Vertragsstrafen dran. Ich kann mir vorstellen das es wohl kaum reicht einen Blick in die /etc/passwd bzw /etc/sudoers zu werfen und mal zu schauen welchen Usern die UID 0 zugewiesen wurde bzw welche Kommandos mit Root-Rechten ausgeführt werden dürfen... Also mit anderen Worten hab ich die schwere Aufgabe alle evtl. offenstehenden Hintertürchen wieder zu verschließen... Vielleicht hat ja jemand noch den ein oder anderen Tipp bzw. Link?!? Dank im Voraus Oliver Meißner
Hallo, Am Mittwoch, 27. April 2005 12:40 schrieb Oliver Meißner:
Also mit anderen Worten hab ich die schwere Aufgabe alle evtl. offenstehenden Hintertürchen wieder zu verschließen...
Vielleicht hat ja jemand noch den ein oder anderen Tipp bzw. Link?!?
Ein Tipp: Files, die SUID oder SGID gesetzt haben und für andere beschreibbar sind: -rwsrwxrwx admin other 555 1.1.1979 meinps mit Inhalt ps -ef Später macht $user einfach cp /bin/bash /hier/meinps. HTH, Wolfgang
Oliver Meißner wrote:
Hallo,
ich muss zu nächster Woche Montag drei Linux-Server (SuSE 7.3) übernehmen und habe nun das Problem das ich herausfinden muss ob und wenn ja, welche User noch Berechtigungen haben tiefer in das System einzugreifen. Es muss also sichergestellt sein, dass nachdem ich das Root-Kennwort geändert habe, ich der einzige bin der Administrationsarbeiten im System vornehmen darf. Klar ist es nun nicht die feine Art dem Kunden von vornherein mal Boshaftigkeiten zu unterstellen, aber immerhin hängt u.a. die (Betiebs-)Sicherheit und relativ hohe Vertragsstrafen dran.
Ich kann mir vorstellen das es wohl kaum reicht einen Blick in die /etc/passwd bzw /etc/sudoers zu werfen und mal zu schauen welchen Usern die UID 0 zugewiesen wurde bzw welche Kommandos mit Root-Rechten ausgeführt werden dürfen...
Also mit anderen Worten hab ich die schwere Aufgabe alle evtl. offenstehenden Hintertürchen wieder zu verschließen...
Im Prinzip musst du also davon ausgehen, dass der Server nicht vertrauenswürdig ist und ihn so umkonfigurieren, dass er auf einer definierten Basis arbeiten kann. Die übliche und bestimmt korrekte Antwort darauf lautet: Neuinstallation. :-(( Wenn das aus welchen Gründen auch immer nicht geht, dann sollte zunächst geklärt werden, wer für die Kernel- und Boot-Konfiguration und -Installation geradesteht. Im Prinzip musst du sämtliche Scripte und Binaries prüfen, ob sie vertrauenswürdig sind. Den Aufwand für nur einen Server zu übernehmen kann schon etliche Tage, eher Wochen in Anspruch nehmen. Eine saubere Neuinstallation ist da erheblich effizienter. Versuche, einen neuen Server parallel aufzubauen und dann die Dienste der Server zu migrieren. Wenn alles läuft, kann der alte plattgemacht werden und der nächste Server in Angriff genommen werden. Sandy
Am 27.04.2005 um 12:40 Uhr schrieb Oliver Meißner:
Ich kann mir vorstellen das es wohl kaum reicht einen Blick in die /etc/passwd bzw /etc/sudoers zu werfen und mal zu schauen welchen Usern die UID 0 zugewiesen wurde bzw welche Kommandos mit Root-Rechten ausgeführt werden dürfen...
Also mit anderen Worten hab ich die schwere Aufgabe alle evtl. offenstehenden Hintertürchen wieder zu verschließen...
Vielleicht hat ja jemand noch den ein oder anderen Tipp bzw. Link?!?
Du könntest nach Dateien suchen, wo das setgid- bzw setuid-Bit gesetzt ist: find / -perm +6000 -type f -exec ls -ld {}\; Am Schluss vielleicht noch > set-id.txt einfügen, dann hast du das Ergebniss gleich als Datei zum Ausdrucken und Aufhängen ;-) cu PeeGee
Hallo Oliver, hallo Leute, Am Mittwoch, 27. April 2005 12:40 schrieb Oliver Meißner:
ich muss zu nächster Woche Montag drei Linux-Server (SuSE 7.3)
BTW: Für die 7.3 gibt es seit langem keine Sicherheitsupdates mehr...
übernehmen und habe nun das Problem das ich herausfinden muss ob und wenn ja, welche User noch Berechtigungen haben tiefer in das System einzugreifen. Es muss also sichergestellt sein, dass nachdem ich das Root-Kennwort geändert habe, ich der einzige bin der Administrationsarbeiten im System vornehmen darf. [...]
Suche mal auf http://blog.koehntopp.de nach "Ein komplett überflüssiger Artikel". Auch wenn sich die Überschrift so anhört, ist der Artikel definitiv nicht überflüssig ;-) rpm -Va findet geänderte Dateien - es können allerdings auch modifizierte RPMs installiert sein, die natürlich nicht gemeldet werden. Und die Dateiliste von /etc/ durchzusehen, wird lustig... Im Zweifelsfall (und mangels Support für die 7.3) wäre eine Neuinstallation angebracht. Gruß Christian Boltz --
Kann man das für alle MUAs sagen? Nein, wohl nicht. Es gibt todkranke, kranke (die durch richtige Konfiguration wieder gesund werden) und gesunde MUAs. [> Ratti und Mathias Bauer in suse-linux]
Am Mittwoch, 27. April 2005 12:40 schrieb Oliver Meißner:
ich muss zu nächster Woche Montag drei Linux-Server (SuSE 7.3) übernehmen und habe nun das Problem das ich herausfinden muss ob und wenn ja, welche User noch Berechtigungen haben tiefer in das System einzugreifen. Es muss also sichergestellt sein, dass nachdem ich das Root-Kennwort geändert habe, ich der einzige bin der Administrationsarbeiten im System vornehmen darf. Klar ist es nun nicht die feine Art dem Kunden von vornherein mal Boshaftigkeiten zu unterstellen, aber immerhin hängt u.a. die (Betiebs-)Sicherheit und relativ hohe Vertragsstrafen dran.
Wenn der Server beim Kunden steht, und der hat da physischen Zugang zu und kann vielleicht sogar einfach eine Knoppix-CD einschieben, dann hast Du gar keine Möglichkeit Dich vor Boshaftigkeiten Seitens des Kundens zu schützen.
Ich kann mir vorstellen das es wohl kaum reicht einen Blick in die /etc/passwd bzw /etc/sudoers zu werfen und mal zu schauen welchen Usern die UID 0 zugewiesen wurde bzw welche Kommandos mit Root-Rechten ausgeführt werden dürfen...
<Korinthenkackermodus> Es gibt nicht mehrere User mit der UID 0, es gibt höchstens einen User mit mehreren Namen. User werden nach der UID und nicht nach dem Namen unterschieden. </Korinthenkackermodus> Bernd
Am Donnerstag, 28. April 2005 18:51 schrieb Bernd Brodeßer:
Wenn der Server beim Kunden steht, und der hat da physischen Zugang zu und kann vielleicht sogar einfach eine Knoppix-CD einschieben, dann hast Du gar keine Möglichkeit Dich vor Boshaftigkeiten Seitens des Kundens zu schützen.
Man kann aber ein Biospass setzen und die Bootreihenfolge auf HD-Only stellen. MFG Markus
Markus Wunder tat kund:
Am Donnerstag, 28. April 2005 18:51 schrieb Bernd Brodeßer:
Wenn der Server beim Kunden steht, und der hat da physischen Zugang zu und kann vielleicht sogar einfach eine Knoppix-CD einschieben, dann hast Du gar keine Möglichkeit Dich vor Boshaftigkeiten Seitens des Kundens zu schützen.
Man kann aber ein Biospass setzen und die Bootreihenfolge auf HD-Only stellen.
Dann gehen wir aber sicherlich davon aus, ein Board mit einer fest montierten Batterie zu haben. IMHO kann ein System mit lokalem Zugriff nicht komplett geschützt werden. So long, George --
PS.: Don't drink as root! Das kann man gar nicht oft genug sagen: "uups, rm -rf * statt rm -rf *~ in /etc", das war eine Meisterleistung nachts um 3 mit 2.6 auf dem Turm ;-)) [Volker Müller und Thomas Bendler in suse-linux]
Am Freitag, 29. April 2005 06:58 schrieb Georg Schilling:
Dann gehen wir aber sicherlich davon aus, ein Board mit einer fest montierten Batterie zu haben. IMHO kann ein System mit lokalem Zugriff nicht komplett geschützt werden.
So long, George
Viele Gehäuse, die ich kenne, haben irgendwo auf der Rückseite eine Lasche, an der man ein Vorhängeschloß anbringen kann und dann geht das Gehäuse nur noch mit der Flex auf :) MFG Markus
Am Freitag, 29. April 2005 11:00 schrieb Markus Wunder:
Am Freitag, 29. April 2005 06:58 schrieb Georg Schilling:
Dann gehen wir aber sicherlich davon aus, ein Board mit einer fest montierten Batterie zu haben. IMHO kann ein System mit lokalem Zugriff nicht komplett geschützt werden.
So long, George
Viele Gehäuse, die ich kenne, haben irgendwo auf der Rückseite eine Lasche, an der man ein Vorhängeschloß anbringen kann und dann geht das Gehäuse nur noch mit der Flex auf :)
Ja, und es geht mit der Flex auf. Wo ist das Problem? Bernd
Bernd Brodeßer schrieb:
Viele Gehäuse, die ich kenne, haben irgendwo auf der Rückseite eine Lasche, an der man ein Vorhängeschloß anbringen kann und dann geht das Gehäuse nur noch mit der Flex auf :)
Ja, und es geht mit der Flex auf. Wo ist das Problem?
das eine flex im computerraum dann doch nicht unauffällig ist. das gehäuse macht auch nicht soviel sinn zu sichern, der zugang zum raum sollte da schon eher gesichert werden. wenn man das ganze z.B. in einen guten 19" schrank einbaut (vorzugsweise edelstahl) ist es schon nicht mehr so einfach ranzukommen... ciao T
Am Sonntag, 1. Mai 2005 20:45 schrieb Dr. Thorsten Brandau:
Bernd Brodeßer schrieb:
Viele Gehäuse, die ich kenne, haben irgendwo auf der Rückseite eine Lasche, an der man ein Vorhängeschloß anbringen kann und dann geht das Gehäuse nur noch mit der Flex auf :)
Ja, und es geht mit der Flex auf. Wo ist das Problem?
das eine flex im computerraum dann doch nicht unauffällig ist.
das gehäuse macht auch nicht soviel sinn zu sichern, der zugang zum raum sollte da schon eher gesichert werden. wenn man das ganze z.B. in einen guten 19" schrank einbaut (vorzugsweise edelstahl) ist es schon nicht mehr so einfach ranzukommen...
Ich habe das so verstanden, daß hier jemand einen Auftrag hat, aber dem Auftraggeber nicht traut. Dieser bösartig sein könnte und die Daten verändern, damit er Vertragsstrafen kassieren kann. Wenn man sich dabei aber auf einen Server verläßt, der bei ihm steht, hat man schlechte Karten. Bernd
Hi! Oliver Meißner schrieb:
Also mit anderen Worten hab ich die schwere Aufgabe alle evtl. offenstehenden Hintertürchen wieder zu verschließen...
Vielleicht hat ja jemand noch den ein oder anderen Tipp bzw. Link?!?
wie wärs damit, das ding erst mal in eine "kiste" zu sperren? XEN oder VMWare sind dafür nette tools. bei VMWARE gibt es eine 30 tage kostenlose lizenz, das sollte reichen, die services zu migrieren. darüber steckst du einen firewall (also auf dem rechner, auf dem dann der "virtuelle" server läuft), die nur die eigentlichen ports der services an die virtuelle umgebung weitergibt. mit jedem service den du migrierst ziehst du das forwarding weg, und zum schluss sind alle services auf der neuen maschine. die alte kannst du dann abschalten. die passwd kannst du (gleiche verschlüsselung vorausgesetzt) auch übernehmen. dazu musst du nur die platten umbauen bzw. eine neue als bootplatte einbauen. apropos: du kannst auch einfach das einloggen von remote verhindern. und wenn du die dateirechte auf "paranoid" setzt, dann kommst du mit einem "su" auch nicht mehr weiter. so kann man die "einfachen" sachen schon mal dicht machen. ciao T
participants (9)
-
Bernd Brodeßer -
Christian Boltz -
Dr. Thorsten Brandau -
Georg Schilling -
Markus Wunder -
Oliver Meißner -
Peter Geerds -
Sandy Drobic -
Wolfgang Hinsch