SSH Versionsnummer verbergen

Lesenswerte Artikel, Anleitungen und Diskussionen
captaincrunch
Userprojekt
Userprojekt
Posts: 7066
Joined: 2002-10-09 14:30
Location: Dorsten

Re: SSH Versionsnummer verbergen

Post by captaincrunch » 2004-07-12 22:24

Ein letztes Wort zum ganzen hier:
CC und Roi schlafen. Beide wachen zur gleichen Zeit auf, nur ist es in einem Fall eventuell schon zu spaet.
Wenn du deine Kiste vernünftig abgesichert hast, kann dir sogar ein root-Exploit relativ egal sein, viel eher sogar erheblich amüsieren, wie sehr sich das Kiddie, das nun einmal das verdammte Glück hat, den Exploit auszunutzen bevor du gepatcht hast abmüht, und dich wundert, warum es selbst mit UID 0 nicht weit kommt. Von daher kannst du mir glauben dass wenn ich denn einmal schlafe ich auch einen verdammt erholsamen Schlaf habe. ;)

Und nein: ich werde hier jetzt nicht zum xten Mal meine (anscheinend) ach so geheimnisvolle "Trickkiste" öffnen, oder einmal mehr auf Doku verweisen, denn wer die Dinge, die ich hier schon zigfach abgelassen habe nicht findet, wird sie ohnehin nicht verstehen.
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

roi
Posts: 145
Joined: 2003-04-07 09:05
Location: Esslingen am Neckar

Re: SSH Versionsnummer verbergen

Post by roi » 2004-07-12 23:30

CaptainCrunch wrote:Und nein: ich werde hier jetzt nicht zum xten Mal meine (anscheinend) ach so geheimnisvolle "Trickkiste" öffnen, oder einmal mehr auf Doku verweisen, denn wer die Dinge, die ich hier schon zigfach abgelassen habe nicht findet, wird sie ohnehin nicht verstehen.
schade, dass du deine trickkiste nicht auf deiner ueberall angepriesenen seite http://www.debianhowto.de praesentierst sondern nur 0815-sachen und man hier im forum suchen muss. gut, kein problem, ist aber zeitaufwendig und fuer unregelmaessige leser eher unpraktisch und erschwert die sache jedoch ungemein. in deiner letzten aussage gehst du einfach davon aus, dass jeder, der hier nen account hat, jeden thread liest und auswendig lernt. oder du willst einem unglaeubigen einfach eine reinwuergen. nicht gelesen bzw nicht muehsam gesucht heisst naemlich nicht gleich nicht verstehen.

captaincrunch
Userprojekt
Userprojekt
Posts: 7066
Joined: 2002-10-09 14:30
Location: Dorsten

Re: SSH Versionsnummer verbergen

Post by captaincrunch » 2004-07-13 08:29

schade, dass du deine trickkiste nicht auf deiner ueberall angepriesenen seite http://www.debianhowto.de praesentierst sondern nur 0815-sachen und man hier im forum suchen muss
1. Ist das Debianhowto nicht meine Seite.
2. Habe ich seit geraumer Zeit zig andere Dinge zu tun, die mich nun einmal davon abhalten, zeitnah Howtos fertigzubekommen. Entschuldige, dass auch ich irgendwie meinen Lebensunterhalt verdienen muss, und nicht jedem hier alles vorkauen kann... :roll:
in deiner letzten aussage gehst du einfach davon aus, dass jeder, der hier nen account hat, jeden thread liest und auswendig lernt
Falsch: ich gehe davon aus dass jemand, der seine Kiste vernünftig absichern will in der Lage ist, mindestens die Suchfunktion hier zu betätigen, oder sich mal ein wenig hier im Security-Bereich umzuschauen...von Google möchte ich jetzt erst gar nicht reden.

Um mir nicht weiter vorwerfen lassen zu müssen, ich würde die User hier "doof" in ihr Verderben rennen lassen, hier also dann mal mein Security-"Leitfaden" (mal ganz nebenbei bemerkt: wieso bitteschön sollte ich hier eigentlich der einzige sein, der hier einen "Leitfaden" liefern könnte?):

Grundlegendes
1. Wer nicht in der Lage ist, seine Kiste wenigstens grundlegend abzusichern braucht keinen im Internet erreichbaren Server.
2. Eine Distri nutzen, mit der man selbst am besten klar kommt, und die einem das flauschig-wärmste Gefühl vermittelt. Was die Reaktionszeit auf Security-Updates angeht tun sich da alle (auf einem Server brauchbaren) nicht mehr allzu viel.
3. Auf dem laufenden bleiben, z.B. durch Mailinglisten wie die Security-Announce des Distributors (absolutes Pflichtprogramm), Bugtraq und/oder Full-Disclosure (wobei letztere qualitativ ziemlich abgenommen hat).
4. Ausarbeitung eines (groben) Sicherheitskonzepts bereits vor der Bestellung. Dieses sollte mindestens Ã?berlegungen enthalten, welche Dienste wem wie zur Verfügung gestellt werden. Darauf aufbauend kann überlegt werden, wie diese Dienste abzusichern sind. Auch sollte darin enthalten sein, welchen Aufwand ein Mindestmaß an Sicherheit überhaupt erforderlich macht, einfaches Beispiel: ein Server, der drei private Homepages lagert benötogt sicherlich (etwas) weniger Schutz als eine Kiste, mit der Umsätze in Millionenhöhe gemacht werden.
5. Umsetzung des Konzepts: Die zur Verfügung gestellten Dienste nach bestem Wissen und Gewissen "sicher" konfigurieren.
6. "Feintuning" des Konzepts. (*)
7. "Sicherheit" ist kein Zustand, sondern ein fortwährender Prozess. Daher sollte auch das eigene Sicherheitskonzept ständig auf's neue hinterfragt und vor allem (z.B. durch Hilfe externer) gestestet werden.

Alleine durch diese 7 Punkte hält man sich bereits den allergrößten Anteil potenzieller Angreifer vom Leib.

Proaktive Sicherheit
8. Der Einsatz von PaX, PIE, libsafe, systrace (in Maßen), etc. kann bereits im Vorfeld helfen, neu aufgetretene Bugs bereits im Keim zu ersticken, da diese Tools einen gewissen Schutz vor Buffer- und/oder Heap-Overflows bieten, und so viele Exploits ins Leere laufen lassen.

Durch diese relativ einfachen Maßnahmen ist die "Gefahr", die von Scritpkiddies ausgeht fast vollständig gebannt...der nächste Kernel-Bug wird aber wohl auch nicht allzu lange auf sich warten lassen, ergo ist auch hier kein vollständiger, dafür aber schon ziemlich großer Schutz gegeben.

Die "hohe Schule"
9. Mit Hilfe von GRSecurity-ACLs (na ja), SELinux oder RSBAC lässt sich das Prinzip der geringsten Privilegien perfekt umsetzen. z.B. wird es so (wie oben angedeutet) möglich, root endlich seiner Allmacht zu entheben.

Spätestens durch diese Maßnahmen werden auch Angreifer mit höherem Background ganz massiv auf die Probe gestellt. Denjenigen, die RSBAC aushebeln könn(t)en wird ein dösiger kleiner Rootserver jedenfalls ziemlich am Arsch vorbeigehen.

10. siehe Punkt 7.

Da jetzt zwangsläufig wieder die Frage kommt, warum das alles so "wischi-waschi"-Aussagen sind, werde ich die (auch bereits ziemlich oft zuvor gegebene) Antwort hier direkt einmal (erneut) vorwegnehmen:
"Sicherheit" und Sicherheitskonzepte sind in höchstem Maße individuelle Dinge, die sich ganz einfach beim besten Willen nicht pauschalisieren lassen. Eine (vermeintlich) simple "Abweichung" einer Konfiguration (z.B. des Apachen) kann daher ein komplett anderes Konzept erforderlich machen.
Darüber hinaus gibt es zig Möglichkeiten zur Umsetzung eines Sicherheitskonzepts, die sich durch Aufwand, Komplexität und tatsächlichem Sicherheitsgewinn teils massiv unterscheiden.

(*) Natürlich kann dieses Feintuning auch Maßnahmen wie die hier bereits genannten umfassen, bei einer korrekten Umsetzung des ganzen sind sie aber (IMHO immer noch) eher Zeitverschwendung, da sich besonders durch die Punkte, die über die Grundlagen hinaus gehen erheblich besserer Schutz gewährleisten lässt.

Nachtrag 1 (ohne hiermit jetzt den nächsten Distri-Flame vom Zaun brechen zu wollen): was die genannten erweiterten Maßnahmen angeht, nehmen einem Distris wie Adamantix oder Gentoo Hardened bereits einen Großteil der Arbeit, jedoch nicht das selbständige Denken ab.

Nachtrag 2: Wie oob schon sagte: "Security isn't". Perfekte Sicherheit wird's nie geben, es wird sich immer irgend jemand finden, der besser ist.
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

roi
Posts: 145
Joined: 2003-04-07 09:05
Location: Esslingen am Neckar

Re: SSH Versionsnummer verbergen

Post by roi » 2004-07-13 10:25

Guten Morgen CaptainCrunch!

Entschuldige, wollte Dir mit meinen Posts nicht zu nahe treten. Da die DebianHowTo recht oft mit Dir in Verbindung gebracht wurde und Du auch damit in Deinem Footer wirbst, bin ich davon ausgegangen, dass es auch "Deine" Seite ist. Umso mehr war ich natuerlich immer ueberrascht, dass auf dieser Seite ueber das erweiterte Standardprogramm (nicht negativ auffassen bitte) nichts zu finden ist.

Ich muss "nebenher" auch meinen Lebensunterhalt verdienen, insofern verstehe ich auch, dass es fuer Dich auch noch andere Dinge als das Rootoforum gibt. Nur ist es wahrscheinlich zeitlich aufwendiger, Dich mit mir und anderen in ewigen Diskussionen rumzuschlagen, immer wieder ein bisschen aus dem Naehkaestchen zu plaudern als das alles einmal zusammenzuschreiben. Damit soll nicht der Eindruck entstehen, dass ich alles vorgekaut bekommen moechte, ich spiel da nur auf den Zeit- und Nervenaufwand Deinerseits an. :-)

Vielen Dank fuer Deine Ausfuehrungen. Deine Vorschlaege, sofern bei mir nicht eh schon umgesetzt, werde ich mir mit der Suchfunktion im Rootforum und bei Google weitere Informationen beschaffen. Ich finde es wichtig, von anderen zu hoeren, was sie im grossen und ganzen so machen. Dabei ist es mir auch nicht 100%ig wichtig, dass ich alles vorgekaut und erklaert bekomme, das schaffe ich dann in den meisten Faellen auch selber. Aber im Trueben zu fischen finde ich laestig. Ich denke, dass es anfangs jedem so geht, wenn er sich mit nem Thema neu befasst.

Roi

captaincrunch
Userprojekt
Userprojekt
Posts: 7066
Joined: 2002-10-09 14:30
Location: Dorsten

Re: SSH Versionsnummer verbergen

Post by captaincrunch » 2004-07-13 10:39

Umso mehr war ich natuerlich immer ueberrascht, dass auf dieser Seite ueber das erweiterte Standardprogramm (nicht negativ auffassen bitte) nichts zu finden ist.
Das Hauptproblem bei den Themen, die über das "Standardprogramm" hinausgehen ist schlicht und ergreifend, dass diese Maßnahmen gleich ganze Bücher füllen könnten, und eine "Step-by-Step"-Anleitung extrem schwierig bis kaum durchführbar sind. Gerade beim Thema RSBAC kommt man alleine aufgrund der Komplexität der Thematik auf keinen Fall umhin, sich da selbst durchzuschlagen, was anfangs auch z.T. mit Trial and Error verbunden ist.
Dabei ist es mir auch nicht 100%ig wichtig, dass ich alles vorgekaut und erklaert bekomme, das schaffe ich dann in den meisten Faellen auch selber. Aber im Trueben zu fischen finde ich laestig. Ich denke, dass es anfangs jedem so geht, wenn er sich mit nem Thema neu befasst.
OK, wie wär's dann damit: Da ich mich ohnehin sehr über konstruktive Kritik an diesen Vorschlägen (ich lasse mich auch gern eines besseren belehren) freuen würde, werde ich mal ein paar Tage abwarten, ob andere vielleicht noch etwas beitragen, oder mir an manchen Stellen meine Blödheit aufzeigen. Wenn aus dieser möglichen Diskussion dann günstigstenfalls ein akzeptabels "Gesamtbild" entstanden ist, werde ich das ganze liebend gerne auch noch einmal (mindestens) als FAQ "verwursten".

Vorschläge / sonstiges, anyone? ;)
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

floschi
Userprojekt
Userprojekt
Posts: 3247
Joined: 2002-07-18 08:13
Location: München

Re: SSH Versionsnummer verbergen

Post by floschi » 2004-07-14 00:32

Roi wrote:schade, dass du deine trickkiste nicht auf deiner ueberall angepriesenen seite http://www.debianhowto.de praesentierst sondern nur 0815-sachen und man hier im forum suchen muss.
Sorry, dass ich mich einmische, aber das finde ich etwas zu viel. Les' dir durch, an wen sich die Seite richtet und merke, dass es eben nicht die Abhandlung aller wichtigen Themen in aller Tiefe ist, sondern ein Umsteigerleitfaden, der Wege aufzeigt, sie aber nicht beschreitet.

Sorry, aber ich bin ziemlich stinkig... :evil:

captaincrunch
Userprojekt
Userprojekt
Posts: 7066
Joined: 2002-10-09 14:30
Location: Dorsten

Re: SSH Versionsnummer verbergen

Post by captaincrunch » 2004-07-14 08:11

So, da sich ja bis dato niemand dazu geäußert hat, ergänze ich das ganze eifnach selber mal:

Zum Sicherheitskonzept gehört natürlich auch ein sinniges Backup- und Restorekonzept. Als "i-Tüpfelchen" in Verbindung mit automatisierten MD5- oder besser SHA1-Hashes, um eventuelle Veränderungen direkt feststellen zu können.
Zusätzlich ist es unabkömmlich, auch den Katastrophenfall im Falle von Datenverlust, oder schlimmer noch einem erfolgten Einbruch ständig auf's neue durchzuspielen.

Daran anschließend darf natürlich auch der Notfallplan für übrige Dinge nicht fehlen, sofern es doch einmal jemand geschafft hat, sich über die sorgsam ausgearbeitete (und hoffentlich auch durchgeführten) Sicherheitsmaßnahmen hinwegzusetzen.
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

roi
Posts: 145
Joined: 2003-04-07 09:05
Location: Esslingen am Neckar

Re: SSH Versionsnummer verbergen

Post by roi » 2004-07-14 16:34

Hallo!
Roi wrote:schade, dass du deine trickkiste nicht auf deiner ueberall angepriesenen seite http://www.debianhowto.de praesentierst sondern nur 0815-sachen und man hier im forum suchen muss.
olfi wrote:Sorry, dass ich mich einmische, aber das finde ich etwas zu viel. Les' dir durch, an wen sich die Seite richtet und merke, dass es eben nicht die Abhandlung aller wichtigen Themen in aller Tiefe ist, sondern ein Umsteigerleitfaden, der Wege aufzeigt, sie aber nicht beschreitet.

Sorry, aber ich bin ziemlich stinkig... :evil:
Entschuldige. Auch Dir wollte ich nicht zu nahe treten. Dass es sich bei der Seite eher um einen Umsteigerleitfaden handelt, ist mir auch klar. Ich habe mich hier im Thread lediglich darueber gewundert, dass von Leuten, die sich sehr gut auskennen, oft Posts zu lesen sind, man solle vorhandene FAQs bemuehen, das Rootforum durchsuchen und Google bemuehen. Da das Rootforum sehr unuebersichtlich durch das massive Aufkommen von Posts ist, brauche ich nicht zu erwaehnen, waere auch ein Wunder, wenn es nicht unuebersichtlich waere. Ich finde oft etwas, aber zu speziellen Themen suche ich lieber bei Google, da habe ich mehr Erfolg. Vorhandene HowTos zu "spezielleren" Themen gibt es leider selten direkt verlinkt. Das war es, was ich bemerken wollte.
Roi wrote:Umso mehr war ich natuerlich immer ueberrascht, dass auf dieser Seite ueber das erweiterte Standardprogramm (nicht negativ auffassen bitte) nichts zu finden ist.
CaptainCrunch wrote:Das Hauptproblem bei den Themen, die über das "Standardprogramm" hinausgehen ist schlicht und ergreifend, dass diese Maßnahmen gleich ganze Bücher füllen könnten, und eine "Step-by-Step"-Anleitung extrem schwierig bis kaum durchführbar sind. Gerade beim Thema RSBAC kommt man alleine aufgrund der Komplexität der Thematik auf keinen Fall umhin, sich da selbst durchzuschlagen, was anfangs auch z.T. mit Trial and Error verbunden ist.
CaptainCrunch wrote:OK, wie wär's dann damit: Da ich mich ohnehin sehr über konstruktive Kritik an diesen Vorschlägen (ich lasse mich auch gern eines besseren belehren) freuen würde, werde ich mal ein paar Tage abwarten, ob andere vielleicht noch etwas beitragen, oder mir an manchen Stellen meine Blödheit aufzeigen. Wenn aus dieser möglichen Diskussion dann günstigstenfalls ein akzeptabels "Gesamtbild" entstanden ist, werde ich das ganze liebend gerne auch noch einmal (mindestens) als FAQ "verwursten".

Vorschläge / sonstiges, anyone? ;)
Ich denke, es gaebe einiges zusammenzutragen. Wie ich ja oben nochmal angeschnitten habe, waere es doch eh sinnvoll, FAQs nicht nur zu Standarddingen zu haben, sondern auch zu weiterfuehrenden Dingen. So wie ich das hier immer mitbekomme wenn ich durch Threads durchklicke, werden oft Fragen zu weiterfuehrenden Dingen gefragt. An den Antworten erkenne ich, dass es zwar anspruchsvollere Fragen sind, trotzdem aber zigmal gefragt werden und fuer die Cracks hier im Forum ne alte Leier darstellen. Entsprechend fallen dann die Antworten aus und mir wuerde es nicht anders gehen. "Erst gucken und suchen, dann fragen." Ich stelle eben fest, dass man zwar problemlos etwas findet, aber dann auch wieder aufgeteilt in zig Threads, einfach schwierig und langwierig. Dh die Fragen kommen dann wieder weil die Leute nicht lang genug suchen oder aehnliches.

Ich wuerd einfach mal folgendes behaupten: Einmal eine FAQ zu nem bestimmten Thema zusammengestellt und die Zeit, die man verwendet, den Leuten das nochmal zu erklaeren oder sie auf die Suchfunktion des Forums zu verweisen, faellt zum Teil weg und man hat gar nicht viel mehr Zeit investiert alles in allem.

Schreiben koennen eine FAQ uebrigens viele Leute, sprich jeder, der etwas zu sagen hat zu dem Thema, kann etwas beitragen. Einer muss sie halt zusammentragen und veroeffentlichen.
CaptainCrunch wrote:So, da sich ja bis dato niemand dazu geäußert hat, ergänze ich das ganze eifnach selber mal:

Zum Sicherheitskonzept gehört natürlich auch ein sinniges Backup- und Restorekonzept. Als "i-Tüpfelchen" in Verbindung mit automatisierten MD5- oder besser SHA1-Hashes, um eventuelle Veränderungen direkt feststellen zu können.
Zusätzlich ist es unabkömmlich, auch den Katastrophenfall im Falle von Datenverlust, oder schlimmer noch einem erfolgten Einbruch ständig auf's neue durchzuspielen.

Daran anschließend darf natürlich auch der Notfallplan für übrige Dinge nicht fehlen, sofern es doch einmal jemand geschafft hat, sich über die sorgsam ausgearbeitete (und hoffentlich auch durchgeführten) Sicherheitsmaßnahmen hinwegzusetzen.
Backup/Restore muss auf jeden Fall dazu. Wenn ich rumschaue bei Leuten, die Rootserver oder Internetserver im allgemeinen betreiben, dann stelle ich fest, dass ich so ziemlich der einzige bin, der ein (tagesgenaues) Backup sein eigenen nennt. Imho ist eine bestimmte Backuploesung mit wenigen Aenderungen in aehnlichen Umgebungen (Rootserver) fuer die meisten zu verwenden.

Anders schaut es natuerlich bei dem Securitykonzept aus. Da kann es gewaltige Unterschiede geben. Haben z.B. Kunden Zugriff auf das System, wenn ja, in welchem Umfang. Was laeuft denn alles auf dem System und so weiter.

Aber auch hier kann man einige grundsaetzlichen Dinge erklaeren. Ich habe an meinem Rootserver schon einiges gemacht in der Richtung, wenn ich mir allerdings die Ausfuehrungen von CC weiter oben anschaue, dann stelle ich fest, dass es da noch viel zu tun gaebe. Vielleicht waere ne Liste mit Tools und was sie machen bzw machen koennten, ganz sinnvoll.

captaincrunch
Userprojekt
Userprojekt
Posts: 7066
Joined: 2002-10-09 14:30
Location: Dorsten

Re: SSH Versionsnummer verbergen

Post by captaincrunch » 2004-07-14 17:04

Schreiben koennen eine FAQ uebrigens viele Leute, sprich jeder, der etwas zu sagen hat zu dem Thema, kann etwas beitragen. Einer muss sie halt zusammentragen und veroeffentlichen.
Nicht zuletzt aus diesem Grunde warte ich immer noch auf Ergänzungen, Verbesserungsvorschläge, etc. ;)
Ganz nebenbei bemerkt: in die oben zu findende FAQ kann jeder Dinge eintragen, nicht nur wir Mods und Admins. In dem Fall hatte ich mich ja bereits angeboten, solltest du im speziellen aber noch Dinge vermissen, bist du herzlich eingeladen, sie zusammenzutragen und dort einzustellen.
Vielleicht waere ne Liste mit Tools und was sie machen bzw machen koennten, ganz sinnvoll.
Wie du bereits selbst oben festgestellt hast, geht die Anzahl möglicher Kombinationen von Tools und Vorgehensweisen ins Unendliche. Das alles pauschal zusammenzutragen dürfte also nicht wirklich einfach werden.
Gegenvorschlag: Sofern es hier Fragen zu konkreten Anwendungsfällen gäbe, ließen sich da sicherlich ein paar Dinge zusammentragen, die sich u.U. sogar so weit als möglich verallgemeinern ließen.
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

roi
Posts: 145
Joined: 2003-04-07 09:05
Location: Esslingen am Neckar

Re: SSH Versionsnummer verbergen

Post by roi » 2004-07-14 17:31

Schreiben koennen eine FAQ uebrigens viele Leute, sprich jeder, der etwas zu sagen hat zu dem Thema, kann etwas beitragen. Einer muss sie halt zusammentragen und veroeffentlichen.
CaptainCrunch wrote:Nicht zuletzt aus diesem Grunde warte ich immer noch auf Ergänzungen, Verbesserungsvorschläge, etc. ;)
Ganz nebenbei bemerkt: in die oben zu findende FAQ kann jeder Dinge eintragen, nicht nur wir Mods und Admins. In dem Fall hatte ich mich ja bereits angeboten, solltest du im speziellen aber noch Dinge vermissen, bist du herzlich eingeladen, sie zusammenzutragen und dort einzustellen.
Ist zwar ein bissel OT, aber egal. Vor einigen Tagen habe ich das hier ins MTA-Forum gepostet. Hatte mir sogar ueberlegt, das einem der Admins zu schicken. Da ich aber keine Ahnung mehr habe, was ich zwischenzeitlich alles installiert hatte, ist die FAQ nicht komplett, da ich an sich nur Config-Files bieten kann. Leider hab ich keinen Testrechner, auf dem ich Stand Null anfangen kann.

Postfix ist grad so ein Thema wo ich immer wieder was ueber "wie geht Postfix mit MySQL" u.ae. lese. Also wie geschaffen fuer eine etwas weiterfuehrende FAQ bzw einen Vorschlag, wie man's machen koennte.
Vielleicht waere ne Liste mit Tools und was sie machen bzw machen koennten, ganz sinnvoll.
Wie du bereits selbst oben festgestellt hast, geht die Anzahl möglicher Kombinationen von Tools und Vorgehensweisen ins Unendliche. Das alles pauschal zusammenzutragen dürfte also nicht wirklich einfach werden.
Mit Sicherheit gibt es mehr Tools als Sand am Meer. Manche machen verschiedene Dinge, einige aehnliche Dinge und wieder andere machen gleiche Dinge. Auch hier gilt aehnliches wie beim nur halb vollstaendigen Postfix-Howto von mir: Man koennte Wege aufzeigen wie man einen Server sicher machen kann und die Tools in der Konfiguration vorstellen, die man bei sich im Einsatz hat. Dann noch etwas ueber die Konfiguration des Servers sagen damit man sehen kann, ob es bei einem selber laufen koennte.
Gegenvorschlag: Sofern es hier Fragen zu konkreten Anwendungsfällen gäbe, ließen sich da sicherlich ein paar Dinge zusammentragen, die sich u.U. sogar so weit als möglich verallgemeinern ließen.
Ich fand die Vorschlaege, wie man einen Server mal grundsaetzlich absichern kann (PaX, safelib, PIE) ganz interessant. Und nachdem ich selber wenig Ahnung davon haette, waere eine solche FAQ fuer mich hoch interessant. Fuer andere mit Sicherheit auch. Tests wuerden angestellt und wenn die Leute nicht faul sind, kann man eine solche FAQ mit den Erfahrungen bzw geaenderten Konfigurationen erweitern. Andersrum koennten sich andere fuer mein Backup-Konzept interessieren.

andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

Re: SSH Versionsnummer verbergen

Post by andreask2 » 2004-07-17 20:54

@CC, ich bewundere Deine Geduld ;-)

Vorab würde mich mal interessieren, was aus dem Vorhaben ein Sicherheits Howto zu schreiben geworden ist: http://www.rootforum.org/forum/viewtopic.php?t=22924

Hab ich da was verpasst? Oder könnte man das nicht irgendwie mit diesen FAQ verbinden? Ich hatte damals überlegt, ob es vielleicht Sinn macht, sowas unter dem Dach von SELFLINUX zu machen, das heißt http://selflinux.org/selflinux/html/gru ... rheit.html etwas "aufzubohren", da hatten ja einige hier gesagt, "das wäre nicht so toll", vielleicht könnte man ja den Leuten dort helfen, dass es eben mal "toll" wird :-)
Also ein gutes, deutsches Sicherheits-Howto, welches womöglich noch die Voraussetzungen von Root-Servern berücksichtigt, wäre natürlich eine wirklich feine Sache. Ich fände auch eine Diskussion über Punkte so eines Howtos sehr interessant, weil man dabei sicher ne Menge lernt. Ich zumindest, und ich würde auch versuchen was beizutragen.

Zu den "CC-FAQ" hier im Thread:

Erstmal vielen Dank dass Du Dir nochmal die Mühe gemacht hast, das alles nochmal zusammenhängend aufzuschreiben! Sicher, es steht alles im Archiv, und noch viel mehr... nur ist es nicht so einfach dieses Wissen zusammenzutragen. Und ich bin da eigentlich auch nicht faul, nur es gibt so unglaublich viel zu lesen zum Thema, das es oft schwer fällt die wirklich guten Informationen herauszufiltern.

Ich finde in den FAQ eigentlich den Punkt 4 am kompliziertesten (von RSBAC rede ich erstmal lieber nicht ;-))

Gut, SSH ist nicht so komplex, da wurden ja eigentlich hier schon die wichtigsten Schritte genannt. In meinem Fall habe ich außer SSH nur den Apachen laufen, und das ist wirklich eine komplexere Geschichte, da geben folgende Artikel schonmal einen Einstieg:
http://httpd.apache.org/docs-2.0/misc/s ... _tips.html
http://www.securityfocus.com/infocus/1786
Wenn man Scripsprachen einsetzt, muss man hier ganz besonders aufpassen, und am Beispiel von PHP z.B. sowas lesen: http://de3.php.net/manual/de/security.index.php

Gut, ich hätte da noch PostgeSQL bzw. MySQL, die aber nicht von außen erreichbar sind, also nicht direkt gefährdet, aber indirekt, z.B. über PHP. Aber gut, was will man groß dazu sagen? Natürlich unter eigenem User laufen lassen...

Gut, Mailserver wäre sicher noch eine Sache, den brauche ich persönlich allerdings nur um Mails aus PHP zu versenden, uns so habe ich einen Postfix nur an localhost lauschen.

Mir hat der Gentoo Security Guide geholfen, und ist sicher auch auf andere Distributionen übertragbar, bzw. gibt es dort auch meist was Vergleichbares, zumindest bei Red Hat gibts das.

http://www.gentoo.org/doc/de/gentoo-security.xml

Ich finde auch das Thema "minimale Rechte" vergeben gar nicht so trivial. Gerade in Zusammenhang mit Apache/mod_php, SFTP... hat mir sehr viel Kopfzerberbrechen bereitet.

Ein weiteres interessantes Thema finde ich die Möglichkeit bei ext2 zusätzliche Flags wie "a" und "i" zu setzen, um z.B. Config- und Logfiles so zu schützen, dass selbst root sie nicht verändern kann. Was haltet Ihr eigentlich davon?
Siehe: http://selflinux.org/selflinux/html/gru ... l#d38e2871

Naja, und Backup/Restore, natürlich ein wichtiges Thema, gerade bei Root-Servern, denn nicht jeder User hat externen Backup-Space, bzw. kennt dessen Notwendigkeit. Wobei ich hier den Zusammenhang mit MD5 Prüfsummen nicht sehe, natürlich sollte man ein Backup verifizieren, meinst Du das? Denn was bringt das schönste Backup wenn es kaputt ist.... ;-)
Oder meinst Du z.B. die Kontrolle ob sich wichtige Binaries und Konfig-Dateien verändert haben? Bei solchen Dingen habe ich ein grunsätzliches Verständnis-Problem, gerade in bezug auf Root-Server. Das ist ja alles schön und gut, nur wenn ich irgendwo einbrechen würde, und an root-Rechte kommen würde, wäre das erste was ich mache die entgsprechenden md5-Summen anzupassen, so dass es nicht auffällt falls ich was verändert habe. Wie will man das verhindern? Ich meine, ein Root-Server hat kein Device welches nicht beschreibbar wäre. Spätestens nach einem reboot kann man überall drauf schreiben. Aber auch da ist es möglicherweise fraglich ob man einen Reboot bemerkt, wenn ein Angreifer Root-Rechte hat. Ich denke der Wert für "uptime" lässt sich schon irgendwie anpassen(gibt es einen weg einen reboot sicher zu erkennen?). Die einzige Alternative wäre meiner Meinung nach, die Prüfsummen auf einem anderen Rechner zu lagern. Wobei auch in dem Fall, der Angreifer kann doch entsprechend das System derart modifizieren, dass md5sum falsche Werte ausgibt...
Irgendwie verstehe ich den Sinn nicht ganz. Und wenn man davon ausgeht, dass es hilft solange der Angreifer nicht Root-Rechte hat, was ist dann der Vorteil, wenn man doch die entsprechenden Dateien einfach nur root zugänglich machen könnte?

Zum Punkt 9:
Thema grsec-RBAC und RSBAC, an grsec finde ich gut, dass es versucht dieses Zugriffsbeschränkungen möglichst einfach erlernbar/nutzbar zu machen. Wie Du selbst sagst ist RSBAC wirklich kompliziert, das kostet sehr, sehr viel Zeit, natürlich wird der Aufwand belohnt mit einer noch feineren Zugriffskontrolle als bei grsec, aber besser die RBAC von grsec (2.x), als nur Standard-Unix-Rechte, oder?

Ach ja, man sollte mal einen Blick auf http://www.tldp.org/ riskieren, da gibt es einige hilfreiche HOWTOs und Guides!


Viele Grüße
Andreas

captaincrunch
Userprojekt
Userprojekt
Posts: 7066
Joined: 2002-10-09 14:30
Location: Dorsten

Re: SSH Versionsnummer verbergen

Post by captaincrunch » 2004-07-17 23:04

Ich finde in den FAQ eigentlich den Punkt 4 am kompliziertesten
"Schwierig" klingt dabei so negativ. Vielleicht könnten wir uns auf "komplex" einigen?!? ;) Auf jeden Fall schon mal vielen Dank f+r die weiteren Links, denn diese Dinge lassen sich einfach nur anhand der bereits überall verstreuten Informationen anreißen, in voller Gänze wird man's in allen Bereichen vermutlich eh kaum schaffen.
Ansonsten danke ich dir, dass du (einmal mehr) durch deine Fragen und weiteren Ausführungen wieder Leben in eine der (IMHO) wichtigeren (und vor allem hier daher sehr gut passenden) Diskussionen bringst. Ich bin gerade ein kleines bisschen im Streß, daher gehe ich erstmal nicht allzu tief auf die Hashsummengeschichte ein, darüber können wir aber auch sehr gerne noch weiter fachsimpeln.
Ein weiteres interessantes Thema finde ich die Möglichkeit bei ext2 zusätzliche Flags wie "a" und "i" zu setzen, um z.B. Config- und Logfiles so zu schützen, dass selbst root sie nicht verändern kann. Was haltet Ihr eigentlich davon?
Das diese Maßnahmen "diskret" (im Sinne des Unix-Standard "Discretionary Access Control, d.h. der User / root kann über die Berechtigungen entscheiden) geschehen, und root sich im Zwiefelsfall darüber hinwegsetzen kann, halte ich persönlich sie für...nicht sicher. OK, ein paar Scriptkiddies haben die manpage zu chattr vielleicht noch nicht gelesen, aber wer die schon im Vorfeld nicht aussprerren konnte, hat eh andere Probleme.
Wobei ich hier den Zusammenhang mit MD5 Prüfsummen nicht sehe, natürlich sollte man ein Backup verifizieren, meinst Du das? Denn was bringt das schönste Backup wenn es kaputt ist....
Mir geht's dabei weniger darum, ob das File kaputt ist, sondern viel eher, ob es (unrechtmäßig) verändert wurde.
Das ist ja alles schön und gut, nur wenn ich irgendwo einbrechen würde, und an root-Rechte kommen würde, wäre das erste was ich mache die entgsprechenden md5-Summen anzupassen, so dass es nicht auffällt falls ich was verändert habe. Wie will man das verhindern? Ich meine, ein Root-Server hat kein Device welches nicht beschreibbar wäre.
Die MD5- (besser aber SHA1-) Summen können entweder "extern" gelagert werden, oder aber wahlweise durch (die "bessere" Mandatory Access Control) geschützt werden.
Thema grsec-RBAC und RSBAC, an grsec finde ich gut, dass es versucht dieses Zugriffsbeschränkungen möglichst einfach erlernbar/nutzbar zu machen.
Klar ist das der große Vorteil von GRSec-ACLs. Den Grundsatz, dass eine Maschine aber nur das macht, was man ihm vorsetzt lässt sich seit jeher dahingehend weiterspinnen, dass die menschliche Komponente immer die Hauptfehlerquelle ist.
Bezogen auf den GRSec-"learning" mode heißt das für mich im Klartext, dass
a) auch der gute spender keinesfalls perfekt ist, und es daher unweigerlich zum einen oder andeen Problem kommt. Ich habe z.B. auch schon gehört (leider nur, da ich es selbst noch nicht getstet habe), dass beim "lernen" totoaler Schwachsinn rauskam. Darüber hinaus kann
b) ein solch "automatisiertes" Lernen seine Aufgabe per Definition niemals so gut machen (jedenfalls noch nicht), wie es das menschliche Gehirn hinbekommt...na ja, in manchen Fällen vielleicht auch wieder nicht. ;)
Wie Du selbst sagst ist RSBAC wirklich kompliziert, das kostet sehr, sehr viel Zeit, natürlich wird der Aufwand belohnt mit einer noch feineren Zugriffskontrolle als bei grsec, aber besser die RBAC von grsec (2.x), als nur Standard-Unix-Rechte, oder?
Siehe oben: woher weißt du, dass GRSec dir überhaupt sinnige ACLs rausgeschmissen hat? Woher willst du ohne jegliches Hintergrundwissen bewerten, dass das resultierende "Regelwerk" "sicher" ist?
Richtig: du musst dir genau so das nötige Hintergrundwissen aneignen, wie es bei RSBAC der Fall wäre. Für mich besteht in dem Punkt kein Unterschied, ich für meinen Teil befasse mich aufbauend auf dieser Argumentation aber lieber mit der Sache, die später die bessere Sicherheit bietet. ;)
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

Re: SSH Versionsnummer verbergen

Post by andreask2 » 2004-07-18 00:50

CaptainCrunch wrote:
Ich finde in den FAQ eigentlich den Punkt 4 am kompliziertesten
"Schwierig" klingt dabei so negativ. Vielleicht könnten wir uns auf "komplex" einigen?!? ;)
na gut ;-)
CaptainCrunch wrote:Auf jeden Fall schon mal vielen Dank für die weiteren Links, denn diese Dinge lassen sich einfach nur anhand der bereits überall verstreuten Informationen anreißen, in voller Gänze wird man's in allen Bereichen vermutlich eh kaum schaffen.
Ja, das ist das Problem. Ich beschäftige mich verhältnismäßig viel mit Apache und PHP, dafür eher wenig mit Sachen wie Postfix oder Sendmail. Wobei es dafür sicher vergleichbare Informationen gibt
CaptainCrunch wrote:Ansonsten danke ich dir, dass du (einmal mehr) durch deine Fragen und weiteren Ausführungen wieder Leben in eine der (IMHO) wichtigeren (und vor allem hier daher sehr gut passenden) Diskussionen bringst. Ich bin gerade ein kleines bisschen im Streß, daher gehe ich erstmal nicht allzu tief auf die Hashsummengeschichte ein, darüber können wir aber auch sehr gerne noch weiter fachsimpeln.
Sehr gerne, auch wenn ich nicht überall denselben Durchblick habe wie manch andere hier, aber ich arbeite dran ;-)
CaptainCrunch wrote:
Ein weiteres interessantes Thema finde ich die Möglichkeit bei ext2 zusätzliche Flags wie "a" und "i" zu setzen, um z.B. Config- und Logfiles so zu schützen, dass selbst root sie nicht verändern kann. Was haltet Ihr eigentlich davon?
Das diese Maßnahmen "diskret" (im Sinne des Unix-Standard "Discretionary Access Control, d.h. der User / root kann über die Berechtigungen entscheiden) geschehen, und root sich im Zwiefelsfall darüber hinwegsetzen kann, halte ich persönlich sie für...nicht sicher. OK, ein paar Scriptkiddies haben die manpage zu chattr vielleicht noch nicht gelesen, aber wer die schon im Vorfeld nicht aussprerren konnte, hat eh andere Probleme.
Ich hätte vielleicht dazuschreiben sollen, dass ich dies mit dem "Capability Mechanismus des Kernels" gesehen habe, das heißt

Code: Select all

lcap CAP_LINUX_IMMUTABLE
lcap CAP_SYS_RAWIO
Wodurch selbst root diese Flags nicht mehr so ohne weiteres los wird, so wie ich das verstehe nur über einen reboot, oder? Das Problem ist halt nur, dass root dann eben rebootet und Spuren des reboots verwischen wird, das heißt, man ist im Prinzip auch nicht weiter als vorher, oder? Wobei ich nicht weiß wie einfach das ist, aber "uptime" zu manipulieren dürfte ja lächerich einfach sein, und ein paar Zeilen aus den Logs zu löschen ebenfalls. Sichere Logs zu haben ist ja so ein Thema, da wäre ein Log-Host sicher nicht verkehrt, am besten ein Rechner, der überhaupt keine offenen TCP-Ports hat, nur logs per UDP empfängt. Ist aber so ne Sache bei Root-Servern...

Wenn man sich wirklich vor einem Angreifer mit root-rechten schützen will, braucht man wohl ACLs...
CaptainCrunch wrote:
Wobei ich hier den Zusammenhang mit MD5 Prüfsummen nicht sehe, natürlich sollte man ein Backup verifizieren, meinst Du das? Denn was bringt das schönste Backup wenn es kaputt ist....
Mir geht's dabei weniger darum, ob das File kaputt ist, sondern viel eher, ob es (unrechtmäßig) verändert wurde.
Gut, aber was bringt ein Backup wenn es auf derselben Maschine liegt? Wen die Festplatte kaputt geht, dann ist das Backup weg.
CaptainCrunch wrote:
Thema grsec-RBAC und RSBAC, an grsec finde ich gut, dass es versucht dieses Zugriffsbeschränkungen möglichst einfach erlernbar/nutzbar zu machen.
Klar ist das der große Vorteil von GRSec-ACLs. Den Grundsatz, dass eine Maschine aber nur das macht, was man ihm vorsetzt lässt sich seit jeher dahingehend weiterspinnen, dass die menschliche Komponente immer die Hauptfehlerquelle ist.
Bezogen auf den GRSec-"learning" mode heißt das für mich im Klartext, dass
a) auch der gute spender keinesfalls perfekt ist, und es daher unweigerlich zum einen oder andeen Problem kommt. Ich habe z.B. auch schon gehört (leider nur, da ich es selbst noch nicht getstet habe), dass beim "lernen" totoaler Schwachsinn rauskam. Darüber hinaus kann
b) ein solch "automatisiertes" Lernen seine Aufgabe per Definition niemals so gut machen (jedenfalls noch nicht), wie es das menschliche Gehirn hinbekommt...na ja, in manchen Fällen vielleicht auch wieder nicht. ;)
Naja, man kann die RBAC von grsec 2.x ja auch manuell konfigurieren, so ein "learning-mode" ist mir eh zu unsicher, nicht dass hier im Live-Betrieb auf einmal komische Fehler auftreten, nur weil irgendeien besondere Aktion während des lernenens nicht ausgeführt wurde...
Nur leider ist das nicht wirklich toll dokumentiert, bzw. fast gar nicht , finde jedenfalls nichts. Da ich eh grsec einsetzem wegen den anderen Features, würe es mir am liebsten, wenn ich "alles aus einer Hand" verwenden könnte, denn ich hab irgendwie ein schlechtes Gefühl wenn ich verschiedene patches kombiniere, die selber alle möglichen Hooks wer weiß wo im Kernel einbauen, und sich möglicherweise selber im Weg stehen, um es mal mit den Worten eines nicht-kernel-sourcen-kenners auszudrücken ;-)
CaptainCrunch wrote: Siehe oben: woher weißt du, dass GRSec dir überhaupt sinnige ACLs rausgeschmissen hat? Woher willst du ohne jegliches Hintergrundwissen bewerten, dass das resultierende "Regelwerk" "sicher" ist?
Richtig: du musst dir genau so das nötige Hintergrundwissen aneignen, wie es bei RSBAC der Fall wäre. Für mich besteht in dem Punkt kein Unterschied, ich für meinen Teil befasse mich aufbauend auf dieser Argumentation aber lieber mit der Sache, die später die bessere Sicherheit bietet. ;)
Gut, ich hatte in dieser Linux-Magazin Sonderausgabe was zu RSBAC gelesen, und fand es nicht mal soooo kompliziert, aber vermutlich wurde da auch nur an der Oberfläche gekratzt, naja.

dodolin
Posts: 3840
Joined: 2003-01-21 01:59
Location: Sinsheim/Karlsruhe

Re: SSH Versionsnummer verbergen

Post by dodolin » 2004-07-18 01:30

Wobei ich hier den Zusammenhang mit MD5 Prüfsummen nicht sehe, natürlich sollte man ein Backup verifizieren, meinst Du das? Denn was bringt das schönste Backup wenn es kaputt ist....
Mir geht's dabei weniger darum, ob das File kaputt ist, sondern viel eher, ob es (unrechtmäßig) verändert wurde.
Gut, aber was bringt ein Backup wenn es auf derselben Maschine liegt? Wen die Festplatte kaputt geht, dann ist das Backup weg.
Ich glaube, es ging da nicht direkt um ein Backup, oder?
Ich nehme an, es geht eher um sowas wie Tripwire, was die Aufgabe hat, Einbrüche (wenn es schon zu spät ist) wenigstens zu erkennen bzw. im umgekehrten Fall auch ausschließen zu können.

Aber deine Frage ist da in der Tat berechtigt: Zuhause würde man die Prüfsummen auf ner schreibgeschützten Diskette oder CD lagern. Beides ist in Rootservern für gewöhnlich nicht enthalten. Lagert man die Prüfsummen auf einem anderen Rechner, muss auch dieser irgendwie erreichbar (und damit angreifbar) sein. Ziemlich dumme Sache das, da wäre ich auch mal zu Ideen gespannt...

captaincrunch
Userprojekt
Userprojekt
Posts: 7066
Joined: 2002-10-09 14:30
Location: Dorsten

Re: SSH Versionsnummer verbergen

Post by captaincrunch » 2004-07-18 12:06

Sehr gerne, auch wenn ich nicht überall denselben Durchblick habe wie manch andere hier, aber ich arbeite dran
Mal ernsthaft: wer kann bei der Komplexität, um die es hier geht für sich behaupten, auch nur annähernd den halben Durchblick zu haben? Ich schlage mich mit dirsen Themen zwar auch beruflich herum, lerne aber auch fast jeden Tag Neues dazu.
Wodurch selbst root diese Flags nicht mehr so ohne weiteres los wird, so wie ich das verstehe nur über einen reboot, oder?
Capabilities stellen zwar einen gewissen "Anfang" für eine Mandatory Access Control (im folgenden nur noch MAC genannt), sind aber im Standardkernel leider bei weitem nicht so konsequent umgesetzt wie in einer "echten" MAC-Lösung. Wenn es um die Abwägung zwischen Geschwindigkeit und Sicherheit geht, gibt Linus der Geschwindigkeit zunächst mal grundsätzlich den Vorrang.
Mal ganz nebenbei bemerkt: mir fallen spontan herzlich wenige Distris ein, die lcap im Lieferumfang bieten.
Das Problem ist halt nur, dass root dann eben rebootet und Spuren des reboots verwischen wird, das heißt, man ist im Prinzip auch nicht weiter als vorher, oder?
Jein: sofern die lcaps an den geeigneten Stellen im Init-Prozess untergebracht sind, bringt auch ein reboot erstmal relativ wenig. Wenn's um CAP_SYS_RAWIO geht, schießt man sich hier aber u.U. böse selbst ins Bein, da (z.B.) Lilo ein ziemliches Problem dadurch bekommt.
Sichere Logs zu haben ist ja so ein Thema, da wäre ein Log-Host sicher nicht verkehrt, am besten ein Rechner, der überhaupt keine offenen TCP-Ports hat, nur logs per UDP empfängt. Ist aber so ne Sache bei Root-Servern...
Gut, dass du's ansprichst: den Loghost hatte ich jetzt nämlich komplett vergessen.
Beim Satz mit den Logs per UDP gehen unsere Meinungen aber extrem auseinander. UDP ist ein verbindungsloses Protokoll, das im Falle von der Ã?bertragung von Logs keinerlei Garantie für die korrekte Zustellung und für die Authentizität der Logs bietet. Den ollen syslog würde ich jedenfalls nicht (ohne weiteres) remote loggen lassen. syslog-ng kann hier Abhilfe schaffen, da es die Logs
a) per TCP transportieren kann, und dadurch
b) z.B. in Verbindung mit stunnel auch für Verschlüsselung beim Transport sorgen.
Gut, aber was bringt ein Backup wenn es auf derselben Maschine liegt? Wen die Festplatte kaputt geht, dann ist das Backup weg.
???
Wie dodolin bereits bemerkte: ich spiele dabei wirklich eher auf Dinge a la Tripwire an, die einzig und allein dazu dienen, (möglicherweise) unberechtigte Ã?nderungen aufdecken zu können.
Lagert man die Prüfsummen auf einem anderen Rechner, muss auch dieser irgendwie erreichbar (und damit angreifbar) sein. Ziemlich dumme Sache das, da wäre ich auch mal zu Ideen gespannt...
Natürlich muss der Rechner, der die Summen lagert auch wieder (wenn nicht sogar besser) gesichert werden. Im Falle eines (mehr oder weniger) dedizierten Backup-Servers sehe ich hier aber auch kein allzu großes Problem darin.
Eine Alternativmöglichkeit wäre (wie bereits oben schon erwähnt), die "Prüfsummendatenbank", sofern sie wirklich auf der gleichen Kiste liegt per MAC zu schützen.

Bzgl. GRSec-ACLs:
Nur leider ist das nicht wirklich toll dokumentiert, bzw. fast gar nicht , finde jedenfalls nichts.
Haargenau das ist für mich der größte Kritikpunkt dabei, auch wenn's von spender immer als der große Vorteil verkauft wird. Ein Automatismus wird niemals so gut sein wie ein gut ausgeklügeltes ACL-System. Ohne Doku noch viel weniger.
Nur leider ist das nicht wirklich toll dokumentiert, bzw. fast gar nicht , finde jedenfalls nichts. Da ich eh grsec einsetzem wegen den anderen Features, würe es mir am liebsten, wenn ich "alles aus einer Hand" verwenden könnte, denn ich hab irgendwie ein schlechtes Gefühl wenn ich verschiedene patches kombiniere, die selber alle möglichen Hooks wer weiß wo im Kernel einbauen, und sich möglicherweise selber im Weg stehen, um es mal mit den Worten eines nicht-kernel-sourcen-kenners auszudrücken
Welche GRSec-Features setzt du denn zwingend bei dir ein?
Für mich interessant ist eigentlich nur PaX, das aber auch einzeln zu haben ist. Interessant fand ich mal die zusätzliche Absicherung von chroot()s, spätestens seitdem ich RSBAC-Jails kennengelernt habe, halte ich chroot ohnehin für ziemlich nutzlos. ;)
Rein zufällig bin ich aber momentan dabei dabei, ein paar "interessante" Dinge aus GRSec zu "extrahieren", und in einen RSBAC-Kernel zu intergrieren. Mal schauen, ob ich mir daran die Zähne ausbeiße. ;)
Gut, ich hatte in dieser Linux-Magazin Sonderausgabe was zu RSBAC gelesen, und fand es nicht mal soooo kompliziert, aber vermutlich wurde da auch nur an der Oberfläche gekratzt, naja.
Richtig, genau das ist das Problem: befasst man sich anfangs "nur" mit einem "einfachen" Modul wie Auth oder (noch einfacher) Jail, ist es gar nicht mal so schwierig, aufgrund der Mächtigkeit von MAC wird's aber spätestens da relativ komplex. Die Mühe lohnt sich aber in jedem Fall, da dieses mit Abstand den besten Schutz bietet.
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc

dodolin
Posts: 3840
Joined: 2003-01-21 01:59
Location: Sinsheim/Karlsruhe

Re: SSH Versionsnummer verbergen

Post by dodolin » 2004-07-18 12:58

Beim Satz mit den Logs per UDP gehen unsere Meinungen aber extrem auseinander. UDP ist ein verbindungsloses Protokoll, das im Falle von der Ã?bertragung von Logs keinerlei Garantie für die korrekte Zustellung und für die Authentizität der Logs bietet.
Deshalb würde ich in dem Fall "Loghost" lieber zu ner VPN-Lösung wie IPSec oder was kleineres greifen.

TCP für Logging finde ich schon ziemlich starken Overkill...

andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

Re: SSH Versionsnummer verbergen

Post by andreask2 » 2004-07-18 13:14

CaptainCrunch wrote:Mal ernsthaft: wer kann bei der Komplexität, um die es hier geht für sich behaupten, auch nur annähernd den halben Durchblick zu haben? Ich schlage mich mit dirsen Themen zwar auch beruflich herum, lerne aber auch fast jeden Tag Neues dazu.
Ja, ich lese mich gerade ein bisschen durch tldp.org, da gibt es ja fast nichts was es nicht gibt... aber leider manchmal etwas veraltet, wobei das bei viele Grundlagen ja erstmal egal ist...

Ich beschäftige mich grade mit

http://www.tldp.org/LDP/sag/html/sag.html
http://tldp.org/HOWTO/Security-Quicksta ... index.html
http://tldp.org/HOWTO/Security-HOWTO/index.html
http://en.tldp.org/HOWTO/Unix-and-Inter ... als-HOWTO/
http://nic.com/~dave/SecurityAdminGuide ... e-all.html
http://www.seifried.org/lasg/
http://tldp.org/LDP/solrhe/Securing-Opt ... n-v2.0.pdf (6MB)

Naja, aber das kann man alles nicht "mal eben" lesen... ;-)
Welche davon würdet Ihr empfehlen, oder habt Ihr noch Tipps?
Capabilities stellen zwar einen gewissen "Anfang" für eine Mandatory Access Control (im folgenden nur noch MAC genannt), sind aber im Standardkernel leider bei weitem nicht so konsequent umgesetzt wie in einer "echten" MAC-Lösung. Wenn es um die Abwägung zwischen Geschwindigkeit und Sicherheit geht, gibt Linus der Geschwindigkeit zunächst mal grundsätzlich den Vorrang.
Ja, das liest man öfter. Leider...
Mal ganz nebenbei bemerkt: mir fallen spontan herzlich wenige Distris ein, die lcap im Lieferumfang bieten.
Gut, aber wenn man sein Linux wirklich gut absichern will, darf man dann darauf Rücksicht nehmen? In dem Fall ist das ja kein großer Akt, oder?
Gut, dass du's ansprichst: den Loghost hatte ich jetzt nämlich komplett vergessen.
Beim Satz mit den Logs per UDP gehen unsere Meinungen aber extrem auseinander. UDP ist ein verbindungsloses Protokoll, das im Falle von der Ã?bertragung von Logs keinerlei Garantie für die korrekte Zustellung und für die Authentizität der Logs bietet. Den ollen syslog würde ich jedenfalls nicht (ohne weiteres) remote loggen lassen. syslog-ng kann hier Abhilfe schaffen, da es die Logs
a) per TCP transportieren kann, und dadurch
b) z.B. in Verbindung mit stunnel auch für Verschlüsselung beim Transport sorgen.
Die Idee dahinter ist, dass ein Angreifer nicht so ohne weiteres herausbekommt, wohin geloggt wird. UDP hat den Vorteil, dass er nicht mal eben per Scan den Loghost findet. Aber gut, da wären wir wieder beim Thema "Security by Obscurity", wobei ich das Argument hier gar nicht so dumm finde, denn vielleicht bekommt man auf diese Weise mehr Log-Information von einem kompromittierten System.
Wie dodolin bereits bemerkte: ich spiele dabei wirklich eher auf Dinge a la Tripwire an, die einzig und allein dazu dienen, (möglicherweise) unberechtigte Ã?nderungen aufdecken zu können.
OK, dann haben wir wohl aneinander vorbei geredet ;-)
Welche GRSec-Features setzt du denn zwingend bei dir ein?
Im Prinzip dasselbe was Du in Deiner Kernel-Konfig einsetzt. Jedenfalls gibt es ja einige weitergehende Beschränkungen, z.B. bzgl. /proc, TCP-Sequenzen... finde ich einiges von ganz nett.

Naja, PAX ist wohl das wichtigste, und das befindet sich zum Glück auch in den rsbac-sources von gentoo ;-)
Ist dort nur noch sehr neu, mal sehen, ich werde mir sowieso mehrere Lösungen ansehen, und auch mal mit SELinux testen(bzgl. LSM, wundert mich dass anscheinend nur so wenige Leute[grsec|rsbac] den Durchblick haben), das ist ganz nett dokumentiert, bei Gentoo, und auch älter und als "Stable" markiert. RSBAC läuft mir ja nicht weg, und es ist sicher nicht das Dümmste immer mal über den Tellerrand zu schauen, um mitreden zu können ;-)
Für mich interessant ist eigentlich nur PaX, das aber auch einzeln zu haben ist. Interessant fand ich mal die zusätzliche Absicherung von chroot()s, spätestens seitdem ich RSBAC-Jails kennengelernt habe, halte ich chroot ohnehin für ziemlich nutzlos. ;)
Gut, chroot habe ich noch nicht verwendet, ist bei Apache auch nicht wirklich trivial ;-)
Rein zufällig bin ich aber momentan dabei dabei, ein paar "interessante" Dinge aus GRSec zu "extrahieren", und in einen RSBAC-Kernel zu intergrieren. Mal schauen, ob ich mir daran die Zähne ausbeiße. ;)
Ich denke da werden wir noch von Dir hören, ja? ;-)
Richtig, genau das ist das Problem: befasst man sich anfangs "nur" mit einem "einfachen" Modul wie Auth oder (noch einfacher) Jail, ist es gar nicht mal so schwierig, aufgrund der Mächtigkeit von MAC wird's aber spätestens da relativ komplex. Die Mühe lohnt sich aber in jedem Fall, da dieses mit Abstand den besten Schutz bietet.
Danke, das werde ich sicher beherzigen!
Last edited by andreask2 on 2004-07-18 17:15, edited 1 time in total.

dodolin
Posts: 3840
Joined: 2003-01-21 01:59
Location: Sinsheim/Karlsruhe

Re: SSH Versionsnummer verbergen

Post by dodolin » 2004-07-18 13:53

Die Idee dahinter ist, dass ein Angreifer nicht so ohne weiteres herausbekommt, wohin geloggt wird. UDP hat den Vorteil, dass er nicht mal eben per Scan den Loghost findet.
Nuja, aber (ungesichertes) UDP hat auch den Nachteil, dass jeder beliebig die Absender IP spoofen kann, ohne dass der Loghost dies bemerkt (wie CC ja schon bemerkt hat). Außerdem gibts auch für UDP diverse Scan-Methoden, die in hinreichend vielen Fällen dann doch funktionieren.

andreask2
Posts: 696
Joined: 2004-01-27 14:16
Location: Aachen

Re: SSH Versionsnummer verbergen

Post by andreask2 » 2004-07-18 15:08

dodolin wrote:Nuja, aber (ungesichertes) UDP hat auch den Nachteil, dass jeder beliebig die Absender IP spoofen kann, ohne dass der Loghost dies bemerkt (wie CC ja schon bemerkt hat). Außerdem gibts auch für UDP diverse Scan-Methoden, die in hinreichend vielen Fällen dann doch funktionieren.
Naja, ihr habt schon Recht. Ich weiß im Moment leider auch nicht mehr wo ich das her hatte. Aber es klang so schön logisch ;-)

Für einen Root-Server ist sicher ein VPN die ideale Lösung - nur leider nicht so trivial wie ein SSH Tunnel.

Würdet Ihr denn dann _alles_ auf dem loghost loggen? Ich meine, gerade wenn man z.B. einen SSH-Tunnel verwendet, und ein bisschen mehr Last herrscht... da kommt ja schon so einiges zusammen. Was würdet Ihr in jedem Fall extern loggen - wenn man die Möglichkeit hat?

captaincrunch
Userprojekt
Userprojekt
Posts: 7066
Joined: 2002-10-09 14:30
Location: Dorsten

Re: SSH Versionsnummer verbergen

Post by captaincrunch » 2004-07-18 15:17

Im Prinzip dasselbe was Du in Deiner Kernel-Konfig einsetzt. Jedenfalls gibt es ja einige weitergehende Beschränkungen, z.B. bzgl. /proc, TCP-Sequenzen... finde ich einiges von ganz nett.
Stimmt, aber gerade, was die ganzen "Randomizer" angeht, gibt's die auch einzeln. Aber gut, dass du's sagst, denn genau solche Dinge wollte ich dann mal sinnig mit RSBAC "verheiraten". Gan nebenbei (ohne da jetzt allzu viel vorwegnehmen zu wollen), könnte das "Gesamtpaket", das ich dazu schnüre (also nicht nur der Kernel) vielleicht noch ganz interessant für den einen oder anderen hier sein. Genaueres gibt's aber erst wenn's fertig ist...wobei so viel jetzt nicht mehr fehlt. ;)
Für einen Root-Server ist sicher ein VPN die ideale Lösung - nur leider nicht so trivial wie ein SSH Tunnel.
OpenVPN ist IMHO sogar noch einfacher als ein SSH-Tunnel ;)
Würdet Ihr denn dann _alles_ auf dem loghost loggen?
Systemseitig auf jeden Fall (also Kernel, Logins, etc.). Ob man nun unbedingt die Meldungen seines MTA (oder noch schlimmer die des Apachen) remote loggen muss steht allerdings auf einem anderen Blatt.
DebianHowTo
echo "[q]sa[ln0=aln256%Pln256/snlbx]sb729901041524823122snlbxq"|dc