Archiv verlassen und diese Seite im Standarddesign anzeigen : Das sicherste Linux!
Hallo an alle!
Ich suche Leute, die sich mit der Thematik "Sicheres System" auseinander setzen und nicht bei der Firewall aufhören.
Vor allem Zugriffskontrollen wie
http://www.rsbac.org/
und Programme die die Rechte von Prozessen beschneiden wie
http://www.linux-magazin.de/Artikel/ausgabe/2003/01/systrace/systrace.html
interessieren mich.
Guckt euch auch mal mein Posting auf
http://www.linuxforen.de/forums/showthread.php?s=&threadid=59034
an.
Wer Interesse an solchen Themen hat und mit mir drüber diskutieren will wie ein sicheres System am besten zu realisieren ist
postet hier
oder mailt an Halbe1@gmx.de
Bin gespannt auf alles!
Einen Guten Rutsch wünscht
cane
Hallo,
bin gerade dabei mit meiner Debian Umstellung mein System zu sichern.
bei jedem Systemstart wird von einem schreibgeschützten USB Stick nach
folgenden Sachen gesucht:
Viren
Rootkits
noch nicht ganz fertig:
Tripwire
- bin gerade beim überlegen, welche Dateien / Ordner ich überwache
Systrace ??
- ( nehme kernel 2.4.19, weil ext3 Bug 2.4.20; ist mir zu unsicher)
habe Systrace aber nur für den 2.4.20 gefunden.
hat jemand eine geniale Idee ??
m.f.g.
Jogibär
Linux Sicherheit / Security mit Open-Source-Software, Grundlagen und Praxis / Tobias Klein / dpunkt.verlag / ISBN 3-932588-04-5
Ist zu diesem Thema sich ein guter Einstieg.
Noch eine Anregung: Mit UMLinux liessen sich gefährdete Dienste in einer geschützten Umgebung ausführen.
Gruss, Andy
Newbie2001
28.12.02, 15:37
ext3-bug in 2.4.20 ?? seit wann das ?? wo hast du die info her ?? habe aufgrund von ein paar features nämlich schon überlegt den kernel 2.4.20 einzusetzen, aber wenn ich das höre glaub ich überdenke ich das nochmals weil ich auf funktionierenden ext3-support angewiesen bin ...
vserver ist auch sehr nett!
pinkelpause
28.12.02, 15:52
ext3-bug in 2.4.20 ?? seit wann das ?? wo hast du die info her ??
kuckst du hier http://www.kerneltrap.org/node.php?id=515
Hallo,
folgender Link
http://www.pro-linux.de/news/2002/4974.html
oder hier:
> Zitat Pro-Linux :
Fehler im ext3-Dateisystem im Kernel 2.4.20
Gesendet von demon am Mo, 2. Dez 2002 um 17:08
Ein Bug im ext3-Dateisystem des neuen Kernels kann zum Datenverlust führen - Fix noch nicht verfügbar.
Wie Andrew Morton in der Linux Kernel Mailingliste (LKML) bekannt gab, beinhaltet das ext3-Dateisystem im Kernel 2.4.20 einen Fehler. Dieser führt unter Umständen dazu, dass gespeicherte Informationen nicht wirklich auf die Hard-Disk abgelegt werden und verworfen werden. Der Zeitraum der Gefahr ist nach Angaben Mortons auf 30 Sekunden vor jedem Umount der Platten begrenzt.
Als der Verursacher des Problems stellt sich die Option »data=journal«, die während des Mountens des Dateisystems als Parameter übergegeben werden kann, dar. »data=journal« sorgt normalerweise für Datenkonsistenz, indem sie ext3-Datenblöcke ins Log übernimmt und später auf die Platte überträgt. Diese Vorgehensweise soll vor allem bei langsamen Platten mehr Geschwindigkeit garantieren, da die Daten aufeinander folgend ins Log geschrieben und später erst endgültig auf die Platte übertragen werden. Leider scheint bei einem Reboot die Erkennung nicht korrekt zu funktionieren, so dass beim Abschalten des Rechners die anstehenden Log-Informationen nicht abgearbeitet werden.
Als Fix empfiehlt Morton, vor jedem Remount der Platten einen Sync durchzuführen. Ein Eintrag in die entsprechenden Init-Scripte der jeweiligen Distribution sollte das Problem, bis ein Fix verfügbar ist, lösen.
> Zitat Ende
Das soll zwar sehr unwahrscheinlich sein, aber ich bin da sehr vorsichtig.
m.f.g.
Jogibär
es ist unwahrscheinlich und tritt nur auf wenn du in der fstab explizit data=journal mountest!
PS hatten wir schon im Forum! Suchen!
joey.brunner
28.12.02, 16:03
schoen, dass hier anscheinend alle das linuxmagazin lesen ;)
meine bescheidene meinung ist:
ein sicheres linux muss vor allem durchdacht sein. es ist doch schwachsinn ein sicheres u produktives system auf einer distri aufzusetzen, auch wenn man minimal oder wie das auch immer heisst waehlt, so ist da soviel mist drauf den man nicht braucht. also bevor man prozesse einschraenkt, die syscalls ueberwacht und so weiter sollte man sein eigenes linux bauen, LFS ist ein sehr guter Weg zum sicheren Linux, sobald man das gewuensche grundsystem hat, kann man ueber weitee schritte nachdenken ! Ein solches System braucht dann auch keine firewall vor sich
joey
Original geschrieben von joey.brunner
schoen, dass hier anscheinend alle das linuxmagazin lesen ;)
meine bescheidene meinung ist:
ein sicheres linux muss vor allem durchdacht sein. es ist doch schwachsinn ein sicheres u produktives system auf einer distri aufzusetzen, auch wenn man minimal oder wie das auch immer heisst waehlt, so ist da soviel mist drauf den man nicht braucht. also bevor man prozesse einschraenkt, die syscalls ueberwacht und so weiter sollte man sein eigenes linux bauen, LFS ist ein sehr guter Weg zum sicheren Linux, sobald man das gewuensche grundsystem hat, kann man ueber weitee schritte nachdenken ! Ein solches System braucht dann auch keine firewall vor sich
joey
ja klar ist ein LFS ein guter Weg dazu! Aber ich stehe ein LFS immer ein bischen skeptisch gegenüber aufgrund des högeren Admin-Aufwands, wenn dann doch mal irgendwo eine Sicherheitslücke gefunden wurde! Außerdem finde ich es nicht ratsam auf einem System was sicher sein soll ein gcc zu installieren!
Naja du kannst mich viellieicht eines besseren belehren!
Badsteve
@joey.brunner
Hast Du im Prinzip schon Recht aber da ich erst seit drei Monaten Linux fahre ist mir es noch zu kompliziert ein LFS aufzusetzen.
Deshalb ist es für mich (im Moment zumindest noch) einfacher eine Standartdistri (in meinem Fall SuSE 8.1 pro) zu nehmen die unnötigen Prozesse wegzukürzen und Tools a la Systrace einzusetzen.
@Alle die gepostet haben
Antworte morgen oder heute Nacht ausführlich auf eure Postings, da ich im Moment bei meiner Freundin bin und die das wahnsinnig interessant findet was ich zu Linux poste;)
mfg
cane
moin moin
@joey.brunner
ein sicheres linux muss vor allem durchdacht sein. es ist doch schwachsinn ein sicheres u produktives system auf einer distri aufzusetzen, auch wenn man minimal oder wie das auch immer heisst waehlt, so ist da soviel mist drauf den man nicht braucht
es gibt auch distri's wo *minimal* auch wirklich *minimal* ist ;)
@Badsteve
Außerdem finde ich es nicht ratsam auf einem System was sicher sein soll ein gcc zu installieren! Naja du kannst mich viellieicht eines besseren belehren!
in gewisser weise hast du schon recht mit dem gcc. allerdings dürfte es für einen angreifer auch nicht allzu schwierig sein, wenn er denn erstmal im system ist, bei einer *rpm basierten* linux distri einen weg zu finden, sich das teil aus dem netz zu laden und dann zu installieren.
@cane
Außerdem ist im Linux Magazin noch ein Bericht über SE Linux - ein von der NSA entwickelter Kernel, der sehr viel sicherer als der Standartkernel ist.
ich glaube ich bin doch noch etwas paranoider :) die NSA wäre der letzte verein von dem ich mir irgendwas installieren würde ;)
RSBAC und Systrace hört sich interessant an. das werde ich mir auf jedenfall mal ansehen. allgemein bin ich aber der meinung, das die *sicherheit* weniger was mit der distribution als vielmehr mit der richtigen administration dieser zu tun hat.
Gruß HL
in gewisser weise hast du schon recht mit dem gcc. allerdings dürfte es für einen angreifer auch nicht allzu schwierig sein, wenn er denn erstmal im system ist, bei einer *rpm basierten* linux distri einen weg zu finden, sich das teil aus dem netz zu laden und dann zu installieren.
ja stimmt schon! Kommt aber auch drauf an wie er angreift!
ich glaube ich bin doch noch etwas paranoider die NSA wäre der letzte verein von dem ich mir irgendwas installieren würde
muss ich zustimmen, obwohl in den Patches noch nichts gefunden wurde!
die *sicherheit* weniger was mit der distribution als vielmehr mit der richtigen administration dieser zu tun hat.
so ähnlich sehe ich das auch! Einige Distris sind aber von natur aus sicherer, weil sie weniger Dienste starten .....
und weil sie nicht immer die neuesten Packete benutzen.
Badsteve
Original geschrieben von HangLoose
in gewisser weise hast du schon recht mit dem gcc. allerdings dürfte es für einen angreifer auch nicht allzu schwierig sein, wenn er denn erstmal im system ist, bei einer *rpm basierten* linux distri einen weg zu finden, sich das teil aus dem netz zu laden und dann zu installieren.
NACK.
Wenn der Compiler bereits installiert ist, braucht er ja nur per Copy & Paste sein Programm kopieren und zu kompilieren.
Bei der anderen Variante benötigt er zuerst mal ein Programm mit dem er etwas herunterladen kann :D
Original geschrieben von HangLoose
allgemein bin ich aber der meinung, das die *sicherheit* weniger was mit der distribution als vielmehr mit der richtigen administration dieser zu tun hat.
Gruß HL [/B]
das finde ich auch immer wird gleich nach firewall ,systrace, lids etc. geschrien aber nicht geschaut ob unnötige services laufen oder unnötige Programme installiert sind .Es geht doch vielmehr um das komplette Konzept was soll die Kiste machen und nur das nötigste dafür installieren,wer hat zugriff und wie sichere ich das ab (Sicherheitskonzept)
MfG AB
@Jinto
was zur hölle ist NACK. NO ACK? ;)
Wenn der Compiler bereits installiert ist, braucht er ja nur per Copy & Paste sein Programm kopieren und zu kompilieren. Bei der anderen Variante benötigt er zuerst mal ein Programm mit dem er etwas herunterladen kann:D
oder er baut das teil *statisch*, dann braucht er auch nur copy&paste ;).
wenn der angreifer erstmal im system ist und sich noch dazu die nötigen privilegien verschaffen konnte, spielt es keine große rolle mehr, ob der gcc vorhanden ist oder nicht. das kind ist dann nämlich schon in den brunnen gefallen.
Gruß HL
Zumindest früher hat es einige Würmer gegeben (Morris-Wurm), die sich zuerst aus den Sourcen kompiliert haben, damit ist er nicht vom Rechner-Typ abhängig. Findet der Wurm keinen gcc, ist er tot.
Gerade bei privaten Systemen will ein Angreifer möglichst schnell ein "Sprungbrett" für weitere Angriffe (DDoS, Spuren verwischen). Findet er keinen Compiler, nimmt er ein anderes System. Für produktive Systeme hat der Angreifer eine Hürde mehr zu überwinden, die dem Admin ev. den nötigen Zeitvorsprung gibt.
Auch einem LFS kann man den Compiler entziehen, z.B. könnte man diesen auf eine CD oder ein NFS auslagern, das nur bei Bedarf gemoutet wird.
@AB65:
ACK: Ein sicheres System ist ein minimales, gut administriertes System. Will man die Sicherheit erhöhen, fügt man zusätzliche Komponenten hinzu: Paketfilter/Firewall, IDS, Sicherheits-Kernel-Patches, Tripwire, Security by obscurity. Security ist auch kein Status sondern ein Prozess: Security-Patches einspielen, System der Umgebung anpassen...
Gruss, Andy
@RapidMax
Zumindest früher hat es einige Würmer gegeben (Morris-Wurm), die sich zuerst aus den Sourcen kompiliert haben, damit ist er nicht vom Rechner-Typ abhängig. Findet der Wurm keinen gcc, ist er tot.
das ist natürlich ein argument.
Gerade bei privaten Systemen will ein Angreifer möglichst schnell ein "Sprungbrett" für weitere Angriffe (DDoS, Spuren verwischen). Findet er keinen Compiler, nimmt er ein anderes System. Für produktive Systeme hat der Angreifer eine Hürde mehr zu überwinden, die dem Admin ev. den nötigen Zeitvorsprung gibt.
seh ich genauso, es ist eine weitere hürde, mehr aber auch nicht. konsequenterweise müßte man dann bei einer rpm basierten distri das tool rpm auch gleich entfernen. womit wir wieder hier landen => "ACK: Ein sicheres System ist ein minimales, gut administriertes System"
Auch einem LFS kann man den Compiler entziehen, z.B. könnte man diesen auf eine CD oder ein NFS auslagern, das nur bei Bedarf gemoutet wird.
einen ähnlichen vorschlag hab ich mal in einem anderen thread gemacht. allerdings ging es dabei um gentoo
Gruß HL
Kernel patches gibts auch ne Menge,
unter anderem
grsecurity
alle Dienste in eine Chroot und nicht als
User ausführen lassen,
um die Jail zu bauen entw. makejail benutzen
oder selber hand anlegen.
Für ssh gibts einen chroot patch.
Vserver (hab ich hier schon mal gehört),
damit kann man ein Linux in einem
Linux laufen lassen,
Resourcenlimits kann man so gut
einstellen, verbraucht allerdings
sch**** viel Speicherplatz.
Viele Partitionen ist auch eine sehr gute Wahl,
am Besten für jeden Dienst, der gechrootet
ist auch ne eigene Partition.
eigene Partitionen für /home (damit die
Systempartitionen nicht von dummen Usern
vollgeschrieben werden können)
/var /var/log /var/spool/mail
/usr /usr/local/bin ......
um die Partitionsgröße während des Betriebs
zu ändern empfhielt sich ein Blick auf lvm.
Datensicherheit: Raid (evtl. Softwareraid)
ansonten noch also gute Dokumentation
das Debian Security Howto:
http://www.debian.org/doc/manuals/securing-debian-howto/index.en.html
=
und was sehr wichtig ist,
die ständige Überprüfung, ob das System
gehackt wurde (z.B. tripwire)
Backups sind natürlich auch sehr wichtig.
Weitere Sicherheit lässt sich durch die zusätzlichen Attribute des ext2/3 fs erreichen: Das Immutable-Attribut schützt Daten vor Veränderungen jeder Art, eignet sich also für alle "festen" Files (execurables, libs) und Konfigurations-Dateien, die während des Betrieb nicht geändert werden. Das Append-Only Attribut ist besonders für Log-Files interessant. Diese Beschränkungen gelten selbst für root, allerdings kann er das auch wieder aufheben. Denoch bietet dieses Feature einen gewissen Schutz, denke man an einen exploit, der z.B. "echo ALL : ALL > /etc/hosts.allow" ausführt.
Gruss, Andy
wie setzt man den dieses flags?
Hoppla, vergessen :rolleyes:
chattr, Anzeigen mit lsattr
Gruss, Andy
@HangLoose
NACK=NO (NEGATIVE) ACKNOWLEDGMENT
oder er baut das teil *statisch*, dann braucht er auch nur copy&paste[/I] Schonmal versucht binaries mittels Copy & Paste einzufügen? :D
Natürlich ist das Kind schon im Brunnen, die Frage ist nur wie schnell das Kind den Brunnen vergrößert bzw. ob es ihm überhaupt möglich ist :)
alle Dienste in eine Chroot und nicht als
User ausführen lassen,
um die Jail zu bauen entw. makejail benutzen
oder selber hand anlegen.
Für ssh gibts einen chroot patch.
Vserver (hab ich hier schon mal gehört),
damit kann man ein Linux in einem
Linux laufen lassen,
Resourcenlimits kann man so gut
einstellen, verbraucht allerdings
sch**** viel Speicherplatz.
Ich habe mir gestern abend, angeregt durch diesen Thread, den vserver Artikel im LinuxMagazin durchgelsen! Ich muss sagen das ist sicherer als chroot !
Zum Platz kann ichauch noch was sagen entweder man kann Hardlinks verwenden oder du kannst dir natürlich auch ein LFS bauen! Für einen Webserver würde das eine Menge Platz sparen glaube ich!
BTW Könntest du deine Beiträge über die ganze Breite ausdehnen ? Ist nicht so ganz angenehem zu lesen. THX
Original geschrieben von Badsteve
Ich habe mir gestern abend, angeregt durch diesen Thread, den vserver Artikel im LinuxMagazin durchgelsen! Ich muss sagen das ist sicherer als chroot !
Zum Platz kann ichauch noch was sagen entweder man kann Hardlinks verwenden oder du kannst dir natürlich auch ein LFS bauen! Für einen Webserver würde das eine Menge Platz sparen glaube ich!
lfs würde ich dafür nicht empfehlen, das upgraden ist viel zu umnständlich. Eine minimale Debian installation für jeden vserver ist eigentlich perfekt. und hardlinks zu verwenden setzt vorraus, dass man dieselebe partition verwendet, was nicht zu empfehlen ist. Außerdem kann root in dem Vserver ja dann auch die Binarys ändern, wenn das immutable flag nicht gesetzt ist.
> BTW Könntest du deine Beiträge über die ganze Breite ausdehnen ? Ist nicht so ganz angenehem zu lesen. THX
sorry, bei mir ist das eingabenfeld so klein (opera)
Markus
Außerdem kann root in dem Vserver ja dann
auch die Binarys ändern, wenn das immutable flag nicht gesetzt ist.
aber nur im vserver! Man müsste den host natürlich auch absichern am besten nur ssh von bestimmten IPs zulassen!
Eine minimale Debian installation für jeden vserver ist eigentlich perfekt. und hardlinks zu verwenden setzt vorraus, dass man dieselebe partition verwendet, was nicht zu empfehlen ist
ja da könntest du recht haben, aber man könnte auch von anderen Distris Minimalinstallationen machen! Bei den Hardlink wird natürlich vorrausgesetzt dass alles auf einer Partition ist!
sorry, bei mir ist das eingabenfeld so klein (opera)
aso
>> Außerdem kann root in dem Vserver ja dann auch die Binarys ändern, wenn das immutable flag nicht gesetzt ist.
> aber nur im vserver! Man müsste den host natürlich auch absichern am besten nur ssh von bestimmten IPs zulassen!
wenn die binarys, libs etc per hardlink auf dem vserver und auf dem Main System (Security Context #0) gleich sind, kann rooot im vserver die Daten dort ändren und ändert sie gleichzeitig im Main System.
moin moin
@Jinto
Schonmal versucht binaries mittels Copy & Paste einzufügen? :D
ich glaube du weißt, wie das ganze gemeint war ;)
Gruß HL
@alle die gepostet haben
Schön, dass ves hier im Forum Leute gibt die sich für die selben Themen interessieren wie ich.
Ich werde eure Infos und Meinungen zu den verschiedenen Konzepten aufarbeiten, bin gleichzeitig dabei einen Haufen
(leider größtenteils enlischsprachiges) Texte, Dokus und HowTos durchzuarbeiten und werde dann meine persönliche Meinung zum besten Konzept posten.
Ob gcc nun installiert ist oder nicht hat meiner Meinung nach keine Relevanz es geht primär darum den Angreifer davon abzuhalten root zu werden.
Ein Großteil aller Eingreifer wird über Exploits root also ist es am sinnvollsten die syscalls aller Prozesse soweit zu beschränken, dass die Prozesse nur das dürfen was auch notwendig ist.
Welches Programm sich dazu am besten eignet da bin ich mir noch nicht schlüssig.
Vor allem "Programmpakete" wie sie unter den beiden Links unten zu finden sind vereinen teilweise sehr viele Funktionen und das ganze muß ja auch administrierbar bleiben.
Hier noch zwei nette Links:
http://www.kaladix.org/docs/information.shtml
http://www.grsecurity.net/features.php
Sind beides fast schon "Komplettlösungen".
Bis bald;)
cane
Original geschrieben von cane
Ob gcc nun installiert ist oder nicht hat meiner Meinung nach keine Relevanz es geht primär darum den Angreifer davon abzuhalten root zu werden. NACK.
Weil du eben verhindern willst, dass ein Angreifer root wird solltest du dir über den Compiler sorgen machen. In einer perfekten Welt, würde ein Angreifer nichtmal eine Shell bekommen, trotzdem gehst du davon es das es möglich ist diese zu erlangen.
Wenn du nun auch noch den compiler installierst ermöglicht du dem Angreifer das erstellen und ausführen eigener Programme Du kannst davon ausgehen, dass diese gefährlicher sein werden, als die Dinge die du bereits installiert hast (Ausnahme: Compiler :D).
Man beachte nur mal den direkten Zugriff auf den Speicher :)
PS: selbst wenn jemand root auf einer Maschine wurde, muss er immer noch seine benötigten Programme hin und her kopieren. Je nach Umfeld dürfte könnte das aber nicht möglich sein.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.