RootForum Community

mahlzeit,

das es immer noch leute gibt die security by obscurity pauschal verdammen gibts hier mal etwas aufklaerung:

http://en.wikipedia.org/wiki/Security_t ... n_favor_of
http://www.bastille-linux.org/jay/obscu ... sited.html

(vergesst bitte den deutschen wikipedia-artikel zu dem thema, der ist quatsch.)

einfach nochmal 2 beispiele fuer die unverbesserlichen:

1. SSH auf einen nicht-standard-port:
ein skript-kind kriegt einen bisher unbekannten exploit in die finger, kein patch verfuegbar. es schreibt natuerlich einen wurm, der erstmal nur auf port 22 angreift weil er sich so viel viel schneller verbreitet als den vollen portscan 1-65535 durchzuziehen. der security-by-obscurity-hasser installiert 2 tage lang seine kiste neu, ich bohr in der nase.

2. das skript-kind hat einen exploit der nur fuer apache 2.0.32-.35 funktioniert und dummerweise 100.000 versuche braucht, bis er die richtige sprungadresse gefunden hat. natuerlich schreibt er ein skript, das zuerst die apache-version anschaut bevor er die 100.000 versuche startet. der security-by-obscurity-hasser installiert 2 tage lang seine kiste neu, ich bohr in der nase.

zusammenfassung: es ist falsch sich ALLEINE auf security by obscurity zu verlassen, aber es hilft deutlich dabei sein system sicherer zu machen.

fragt Euch doch mal, warum die boesen buben als allererstes mit informationen sammeln anfangen ? warum gibt es tools, die remote betriebssystem und dienst-version feststellen ? weils nuetzlich ist beim angreifen!

hoert bitte um himmels willen damit auf, leute von security by obscurity abzuhalten! klar sind SSH-keys besser als port 22222, aber beides ist noch besser.

tschoe
arnim

Klasse, ein selbsternannter Apostel der uns das Security through obscurity-Konzept predigt. Amen. :roll:

Pauschal wird es doch i.d.R. sowieso nicht verdammt. Ein Passwort ist schließlich auch nichts anderes als "security by obscurity". Verdammt wird es dort wo do obscurity eben nur sehr wenig security bringt, oder noch schlimmer, wo obscurity ein (falsches) Sicherheitsgefühl erzeugt, welches zu riskanterem Verhalten führt - Wenn du nämlich bspw. in deinem Fall-1 so sicher wärest, dass du dein Update auch erst nächste Woche einspielen kannst (weil du davon ausgehst, ein Wurm würde keinen Portscan durchführen), dann könntest du nämlich tatsächlicher schlechter dastehen, als der Kollege der ohne Aufschieben gleich upgedatet hat, weil er sich nicht auf die "Sicherheit" eines Non-Standard-Port verlassen hat. (Will ich dir natürlich nicht unterstellen, sollte nur ein Beispielszenario erweitern).

Ich nehme mal an, dass sich Dein Post auf meine Antwort in diesem Thread bezieht.

Mich stört einfach die Vorstellung, dass (ohne weitere Erläuterung) einige Leute, die nach entsprechenden Log-Einträgen googlen, auf den Thread stoßen und dann glauben, den Port zu verlegen wäre die Lösung all ihrer Probleme. Das wollte ich damit lediglich zum Ausdruck bringen...

Egal, wie CC schon treffend geschrieben hat:

Captain Crunch wrote:Meinungen sind wie Nasen: jeder hat eine.

caput wrote:Klasse, ein selbsternannter Apostel der uns das Security through obscurity-Konzept predigt. Amen. :roll:

Obscurity bringt keine Sicherheit.

Aber Obscurity bringt Untersetzung, in dem Sinne, daß man von 100 Angriffen nur gegen einen verteidigen muß. Es geht als nicht so sehr um Sicherheit als vielmehr um etwas, das sehr verwandt mit DDoS und mit Spam Control ist. Auch bei diesen Problemen muß man ja in der Regel einen mehrstufigen Ansatz fahren, wobei jede Stufe nicht dazu dient, eine 100% Immunität herzustellen, sondern die Anzahl der angesehen Fälle so weit zu reduzieren, daß das Problem für die nächste, aufwendigere Stage handhabbar wird.

Das ist durchaus ein korrekter Ansatz, nur sollte man ihn nicht mit einem Sicherheitskonzept verwechseln wie der OP es hier öffentlich tut.

R. U. Serious wrote:Pauschal wird es doch i.d.R. sowieso nicht verdammt. Ein Passwort ist schließlich auch nichts anderes als "security by obscurity".

Nein, es besteht ein wesentlicher Unterschied zwischen einem Verfahren, dessen Sicherheit darauf beruht, daß das Verfahren geheim bleibt und einem Verfahren, dessen Sicherheit darauf beruht, daß ein Schlüssel (Geheimnis) geheim bleibt.

Der Begriff der Security-by-obscurity stammt ursprünglich aus der Kryptographie, und dort ist er als Kerckhoffs Prinzip bekannt. Die Regel dort lautet "Wir müssen davon ausgehen, daß dem Angreifer das zu Grunde liegende Kryptosystem bekannt ist", oder "Die Sicherheit eines Kryptosystem darf nicht auf der Geheimhaltung eines Algorithmus basieren."

Das ist aus zweierlei Gründen so:

Zum einen müssen wir die Implementierung des Kryptosystems aus unserem Kontrollbereich entlassen, um Kommunikation zu ermöglichen - die Enigma zum Beispiel war auf jeder Menge von deutschen Schiffen und U-Booten installiert und es mußte jederzeit davon ausgegangen werden, daß Exemplare der Enigma in Feindeshand fallen, selbst wenn die Betriebsprozeduren für das Gerät eine Zerstörung bei Aufgabe oder Eroberung des Schiffes vorgesehen haben.

Wir müssen also davon ausgehen, daß der Angreifer Kontrolle über ein Exemplar des Kryptosystems verfügt oder eines analysieren konnte.

Das andere Problem ist, daß wir bis zum heutigen Tage zwar Kryptosysteme brechen können ("gebrochen" == "Ein Verfahren besser als brute force zum Auffinden des Schlüssels oder Klartextes existiert"), aber wir aus prinzipiellen Gründen in den meisten Fällen nicht entscheiden können, ob ein Kryptosystem unbrechbar oder gar sicher ist. Ein Kryptosystem gilt im Allgemeinen als vertrauenswürdig, wenn der Algorithmus möglichst vielen Personen in der kryptographsischen Community bekannt ist und alle sich daran die Zähne ausgebissen haben ("Vertrauenswürdig bis zum Beweis des Gegenteils").

Wir sind also darauf angewiesen, daß ein kryptographisches Verfahren möglichst viel Review gesehen hat, um seine Stärke besser beurteilen zu können.

Dem steht die Anforderung an die geheimen Schlüssel, mit denen das Verfahren initialisiert wird, diametral gegenüber. Diese Schlüssel müssen geheim gehalten werden und dürfen niemandem außer den berechtigten Parteien bekannt sein.

Wie Du siehst ist ein Paßwort (allgemeiner: Geheimnis zur Initalisierung eines Verfahrens) etwas vollkommen anderes als Security-by-obscurity (allgemeiner: Geheimhaltung eines Verfahrens)


Während die Verdammung von Security-by-obscurity in der Kryptographie relativ absolut ist, ist sie im Bereich der allgemeinen Sicherheit gelegentlich diskussionswürdig. Hier muß man zwischen Diskussion von Verfahren und Best Practice auf der einen Seite ("Für alle eingehenden Verbindungen zur Administration ist immer ssh zu verwenden") und Diskussion von konkreten Verfahrensanweisungen auf der anderen Seite ("Bei uns wird ssh grundsätzlich auf Port 199 installiert") unterscheiden.

Es ist dumm und schädlich, Best Practice nicht zu diskutieren - nur durch Peer Review kann sich Best Practice bilden und nur durch Fehleranalyse können Probleme mit BPs erkannt und ausgemerzt werden.

Es ist aber unter Umständen auch dumm und schädlich lokale konkrete Verfahrensanweisungen Personen zugänglich zu machen, die diese Informationen für ihre Arbeit nicht benötigen ("need to know" Prinzip).

Und es ist sicherlich notwendig, wenn auch nicht hinreichend, die lokale Installlation auf eine Weise zu variieren, die es wahrscheinlich macht, daß Angriffe die auf Monokulturen von Installationen setzen bei einem selbst nicht greifen können. Man darf nur nicht vergessen, die hinreichenden Bedingungen auch zu implementieren

In diesem Fall wäre es also auch notwendig, um nicht zu sagen: fundamental,

- eine laufende Selbstevaluierung durch einen Scanner durchzuführen,
- eine Bestandsverwaltung zu haben, mit der man betroffene Systeme schnell und vollständig bestimmen kann wenn ein Alert für ein Paket eingeht,
- und ein Test-and-Rollout-Regime für bestehende Systeme zu habeb, mit dem man verwundbare Systeme ohne großen Aufwand auf Stand bringen kann.

Die meisten Firmen, die ich kenne (und das sind beruflich bedingt nun einmal eine ganze Menge), haben so etwas nicht - das Ausbringen von Patches in produktive Systeme ist für diese Firmen jedes einzelne Mal nahezu so schwer und risikoreich wie eine Neuinstallation. Darum ist eine der zentralen Forderung eines CSO in der Regel eine vollständige Automatisierung des Deploymentprozesses für Systeme, d.h. ein gut gepflegter Installations- und Patchserver sowie eine Testumgebung für Installs und Patches.

Ich kann mit Isotop nur anschliessen, es dient nicht das man sicher ist, es dient das man nicht ins Visier von Scriptkiddies und Bots kommt. Beispiel Websoftware ala PHP Nuke: Warum soll ich die Version anzeigen lassen wenn 80% der Bots nach dem String "Powerd by PHP Nuke 2.3.4" suchen? Sobald meine Seite bei dieser Suchanfrage nicht auftaucht hab ich doch schon etwas erreicht. Es ist eigentlich ein Teil des Sicherheitskonzepts finde ich. Aber wie schon gesagt wurde, man darf sich nicht darauf verlassen. Ich werd auch in Zukunft das ganze Verwenden, auch wenn es nur die Logfiles etwas sauberer hält ;)

isotopp wrote:Nein, es besteht ein wesentlicher Unterschied zwischen einem Verfahren, dessen Sicherheit darauf beruht, daß das Verfahren geheim bleibt und einem Verfahren, dessen Sicherheit darauf beruht, daß ein Schlüssel (Geheimnis) geheim bleibt.
[...]
Wie Du siehst ist ein Paßwort (allgemeiner: Geheimnis zur Initalisierung eines Verfahrens) etwas vollkommen anderes als Security-by-obscurity (allgemeiner: Geheimhaltung eines Verfahrens)

Um die theroetischen Kozepte zu diskutieren und zu vergleichen ist es in jedem Fall sinnvoll eine Unterscheidung zwischen Verfahren und Schlüssel zu machen, das unterschreibe ich. Darum ging es mir aber gar nicht.

Mein Kommentar ging aber in eine etwas andere Richtung. Viele Parameter in der Praxis lassen sich nämlich nicht so strikt aufteilen - wie eben bspw. die Portnummer (eine konkrete Portnummer ist weder inhärenter Bestandteil des Verfahrens, noch ist es Teil des Schlüssels des Verfahrens). Meine pointierte Äußerung sollte eben darauf hinweisen. Sollte meine Äußerung so mißverständlich gewesen sein, dass man sie so lesen kann, ich security-by-obscurity genauso sicher halte, wie jedes Verfahren, dass mit Schlüseln oder shared secrets arbeitet, dann ziehe ich sie natürlich zurück.

R. U. Serious wrote:Mein Kommentar ging aber in eine etwas andere Richtung. Viele Parameter in der Praxis lassen sich nämlich nicht so strikt aufteilen - wie eben bspw. die Portnummer (eine konkrete Portnummer ist weder inhärenter Bestandteil des Verfahrens, noch ist es Teil des Schlüssels des Verfahrens).

Die Kerckhoffsche Regel ("Die Sicherheit eines kryptographischen Algorithmus darf niemals von der Geheimhaltung des Algorithmus abhängen") ist direkt nur anwendbar bei kryptographischen Verfahren. In allen anderen Zusammenhängen ist die Argumentation so direkt nicht anwendbar - in Bezug auf Portnummern sind Begriffe wie Schlüssel und Algorithmus Unsinn.

In der Security allgemein muß man daher die andere, mittelbare Argumentation wählen, damit das verständlich wird: Best Practice ("Fachwissen" - "Man macht sinnvollerweise dies, jenes und solches")) muß man diskutieren und offen legen. Konkrete Implementierungen dieser Best Practice ("Sachwissen" - "Wir hier machen dies so, jenes so und solches noch wieder anders") sollten auf einer need-to-know-Basis mitgeteilt werden.

jfreund wrote:Ich nehme mal an, dass sich Dein Post auf meine Antwort in diesem Thread bezieht.

Mich stört einfach die Vorstellung, dass (ohne weitere Erläuterung) einige Leute, die nach entsprechenden Log-Einträgen googlen, auf den Thread stoßen und dann glauben, den Port zu verlegen wäre die Lösung all ihrer Probleme. Das wollte ich damit lediglich zum Ausdruck bringen...

[/quote]

ich finds ja OK das Du mit SSH-keys einen weiteren loesungsvorschlag gebracht hast, aber warum hast Du von der port-verlegung abgeraten? das minimiert definitv das risiko.

jfreund wrote: Egal, wie CC schon treffend geschrieben hat:

Captain Crunch wrote:Meinungen sind wie Nasen: jeder hat eine.

moment mal, erst findest Du port-verlegung doof, raets andern davon ab ihr system sicherer zu konfigurieren, und jetzt wo Du sachlich nicht mehr weiter weisst kommt hier so'n universal-spruch mit dem man sich immer nett aus der affaere ziehen kann :)

isotopp wrote:

caput wrote:Klasse, ein selbsternannter Apostel der uns das Security through obscurity-Konzept predigt. Amen. :roll:

Obscurity bringt keine Sicherheit.

jap, aber dann nenn mir doch mal eine sache die "sicherheit" bringt ausser der vollstaendigen physikalischen zerstoerung des servers ?

isotopp wrote: Aber Obscurity bringt Untersetzung, in dem Sinne, daß man von 100 Angriffen nur gegen einen verteidigen muß. Es geht als nicht so sehr um Sicherheit als vielmehr um etwas, das sehr verwandt mit DDoS und mit Spam Control ist. Auch bei diesen Problemen muß man ja in der Regel einen mehrstufigen Ansatz fahren, wobei jede Stufe nicht dazu dient, eine 100% Immunität herzustellen, sondern die Anzahl der angesehen Fälle so weit zu reduzieren, daß das Problem für die nächste, aufwendigere Stage handhabbar wird.

100% agree

isotopp wrote: Das ist durchaus ein korrekter Ansatz, nur sollte man ihn nicht mit einem Sicherheitskonzept verwechseln wie der OP es hier öffentlich tut.

da keine massnahme, konzept oder sonstwas eine 100% sicherheit herstellen kann geht es immer nur darum die latte fuer den angreifer hoeher zu legen. das erreicht man mit port-verlegung, patchen und mit SSH-keys. warum ist das eine ein sicherheitskonzept und das andere nicht ?

ich hab gerade im forum mal nach "obscurity" gesucht, und der populaere irrtum, das es nichts bringt wird hier regelmaessig gepredigt, im letzten halben jahr 3 mal:

So auf Anhieb fällt mir dazu nur in.. Security by Obscurity funktioniert nie.

Ach ja, doch noch einer: Security by obscurity hat noch nie funktioniert, funktioniert nicht, und wird auch nie funktionieren.

Ein anderer Port ist http://de.wikipedia.org/wiki/Security_by_obscurity und von daher nur Kosmetik.

leute, Ihr sorgt dafuer das es die skript-kinder einfacher haben und es hier ofters mein-server-ist-geknackt-was-nun?-threads gibt. Ihr koennt gerne Euren SSH auf port 22 laufen lassen und alle versionsnummern anzeigen, aber haltet bitte niemanden davon ab sein system sicherer zu machen!

Hallo,

buddaaa wrote:bringt wird hier regelmaessig gepredigt, im letzten halben jahr 3 mal

nur? Dann wird's Zeit für häufigere Aufklärung. :lol:

es hier ofters mein-server-ist-geknackt-was-nun?-threads gibt.

Die gibt es, wenn ein Server nicht korrekt abgesichert ist, was meistens insbesondere an verschlampten Updates liegt.

Ihr koennt gerne Euren SSH auf port 22 laufen lassen und alle versionsnummern anzeigen

Ein korrekt konfigurierter und regelmäßig mit Updates versorgter Server hat damit kein Problem.

Wer zu faul für regelmäßige Updates ist kann die Konsequenzen mit verlegtem Port und verlogener Versionsnummer allenfalls etwas hinausschieben aber nicht verhindern.

Meine Server geben sich klar und ehrlich als Linux und Apache zu erkennen, trotzdem hab ich in den Logfiles laufend Angriffsversuche die völlig sinnlos sind, weil sie nur bei Windows und IIS funktionieren.

aber haltet bitte niemanden davon ab sein system sicherer zu machen!

Ganz im Gegenteil, wir versuchen immer wieder zur korrekten Absicherung motivieren. Dazu gehört auch, klarzustellen was keine Absicherung darstellt.

Die Obscurity-Maßnahmen (und die immer wieder beliebten "Firewalls") bringen nicht mehr als eine Beruhigungspille - einen beruhigten Admin, sonst garnix.

Es gibt nichts schlimmeres als einen Admin, der meint sein Server sei sicher.

Gruß, Wolfgang

Wir sind doch jetzt schon wieder auf der Ebene "Samba auf Rootserver" ... Natürlich bringt es etwas, wenn das System nicht Standards entspricht, die evtl. verwundbare Details darstellen. Eine umfassene Sicherheitspolitik ist das aber nicht.

Und ich denke, daß wenn das Wissen um die Serverabsicherung vorhanden ist, es keinen großen Unterschied macht, ob ssh auf Port 22 oder 22 im Quadrat oder sonstwas lauscht. Im Umkehrschluß sind solche Empfehlungen dann genau das, wie "Anfänger" dann anfangen ihr(e) System(e) abzusichern, und da liegt der Hund begraben. Man kann sich darauf nicht verlassen, daß nicht ein Portscanner nicht nach der Versionsnummer sucht - siehe nmap.

Es ist keine Sicherheitsmaßnahme, höchstens unterstützendes, aber leider unwichtiges Beiwerk.

flo.

flo wrote:Wir sind doch jetzt schon wieder auf der Ebene "Samba auf Rootserver" ...

bleib mal beim thema.

flo wrote: Natürlich bringt es etwas, wenn das System nicht Standards entspricht, die evtl. verwundbare Details darstellen. Eine umfassene Sicherheitspolitik ist das aber nicht.

das hat nie jemand behauptet, aber es macht einen server deutlich sicherer bei keine relevanten nachteilen. oder was sind die handfesten nachteile von SSH != 22, fehlenden versionsnummern, nicht-pingbarkeit ?

flo wrote: Und ich denke, daß wenn das Wissen um die Serverabsicherung vorhanden ist, es keinen großen Unterschied macht, ob ssh auf Port 22 oder 22 im Quadrat oder sonstwas lauscht. Im Umkehrschluß sind solche Empfehlungen dann genau das, wie "Anfänger" dann anfangen ihr(e) System(e) abzusichern, und da liegt der Hund begraben.

wieso, werd mal konkret, was ist schlecht daran ?

flo wrote: Man kann sich darauf nicht verlassen, daß nicht ein Portscanner nicht nach der Versionsnummer sucht - siehe nmap.

ich weiss jetzt nicht genau was Du damit sagen willst, aber falls Du meinst nmap zeigt die version an wenn sie im dienst unterdrueckt ist: nmap macht auch nichts anderes als sich den version-string des dienstes anzuschauen.

flo wrote: Es ist keine Sicherheitsmaßnahme, höchstens unterstützendes, aber leider unwichtiges Beiwerk.

quatsch, es ist ratzfatz erledigt, hat keine nachteile und erhoeht die sicherheit signifikant. bitte mal die beiden links aus meinem urspruenglichen post durchlesen.

wuerdest Du als skript-kind lieber durschnittlich 32768 port eines einzigen servers nach einem bestimmten port scannen, oder 32768 unterschiedliche server auf dem standard-port ?

nur mal ein paar zahlen: ich hatte seit 30.3.06 keinen einzigen full-port-scan, aber 474 versuche auf port 22 wo keine SSH mehr laeuft. warum sollte ich mich dem risiko ausetzen das einer von denen einen funktionierenden exploit hat?

und les Dir bitte mal den beitrag von isotopp durch, der erklaert auch nochmal die ausfuehrliche geschichte, das die pauschale verdammnis von "security by obscurity" nur fuer algorithmen gedacht ist!

Es ist ja schön, wenn Du Deine Meinung verteidigst, aber das ändert nunmal wenig am Gehalt der Sache.

Script-Kiddies und Würmer werden getäuscht --> Ja, es bringt etwas.

So, nachdem wir den pauschalen Punkt geklärt haben, kannst Du nun entweder mal die Augen aufmachen und die restlichen Posts hier vernünftig lesen oder den Browser schließen und Dir auf die gute Idee ein Bierchen gönnen.

Dein verlegter SSH-Port bringt schlicht und ergreifend gar nichts, wenn irgendeine Lücke einer Webanwendung zu einem lokalen Exploit mit evtl. anschließenden Root-Rechten führt. Und dies ist mittlerweile (hier) der absolute Standard in den "Server-gehackt"-Threads. Und mach mir bitte nicht weis, daß vor "wget"-Zugriffen irgendwelche Versionen überprüft würden - wäre das der Fall, würde ich die nicht ständig in meinem Default-Host finden.

Auch der geübte Angreifer wird sich dadurch nicht abschrecken lassen, eher wird er noch neugieriger gemacht.

flo.

buddaaa wrote:moment mal, erst findest Du port-verlegung doof, raets andern davon ab ihr system sicherer zu konfigurieren, und jetzt wo Du sachlich nicht mehr weiter weisst kommt hier so'n universal-spruch mit dem man sich immer nett aus der affaere ziehen kann

• Ja, ich finde Portverlegung doof. Sachliche Argumente dafür gibt's genug - falsches Sicherheitsgefühl, SSH die geringst wahrscheinliche Einfallsstelle - wer da rein kommen kann (wohlgemerkt: Exploit für ein verschlüsseltes Protokoll, das schafft kein Skriptkiddie) ist auch schlau genug, den richtigen Port zu finde - etc.
• Nein, ich habe nie jemandem davon abgeraten, sein System sicher zu konfigurieren - wo willst Du bitteschön das gelesen haben? Im Gegenteil, ich habe ziemlich deutlich gesagt, dass ich das Verlegen des Ports nicht als hinreichende Sicherheitsmaßnahme betrachte.
• Ich persönlich habe sehr gute Gründe, meinen SSH-Port nicht zu verlegen (z. B. dürfen meine User nicht per FTP, sondern nur per SCP/SFTP (chrooted) auf ihre Webverzeichnisse zugreifen - mit pubkey-Auth, versteht sich)
• Was machst Du mit Diensten, deren Port Du nicht einfach verlegen kannst (IMHO ist z. B. ein HTTP-Daemon ein weit größeres Risiko als ein OpenSSH-Server...) - technisch gesehen geht das natürlich, aber ob es sinnvoll ist, einen öffentlichen Webserver auf Port 63024 zu betreiben, sei mal dahingestellt...

Fakt ist, dass der Sicherheitsgewinn durch Ersetzen der User/Passwort-Anmeldung durch Public Key, das Einsperren der User in chroots (in Verbindung mit Grsecurity ziemlich ausbruchsicher), der Zwang zu sicheren Passwörtern und zeitnahes Einspielen von Sicherheitsupdates (t <= 8 Stunden) einen nahezu unendlich viel größeren Beitrag zur Sicherheit eines Systems leistet als das Verlegen eines Ports.

Hallo,

buddaaa wrote:es macht einen server deutlich sicherer bei keine relevanten nachteilen. (...) SSH != 22, fehlenden versionsnummern, nicht-pingbarkeit

ein unsicherer Server wird durch diese Maßnahmen nicht sicherer, er wird bestenfalls später gefunden.

flo wrote:Dein verlegter SSH-Port bringt schlicht und ergreifend gar nichts, wenn irgendeine Lücke einer Webanwendung (...)

Da gibt's für den echten Obscurity-Fan nur eine Lösung: HTTP-Port verlegen. :lol:

Seit ich SMTP auf Port 3375 verlegt habe ist keine einzige Spammail mehr angekommen. :roll:

Gruß, Wolfgang

wgot wrote: Seit ich SMTP auf Port 3375 verlegt habe ist keine einzige Spammail mehr angekommen. :roll:

Ich kenne einen Admin, der sperrt alle aus seinem Netz ausgehenden Verbindungen, die Port 25 zum Ziel haben und lässt als Ausnahme nur seine eigenen Mailserver zu. Und das, obwohl auch andere SMTP-Server als die internen benutzt werden müssen. Dummfug? Nein, ein Admin, der auf RFCs achtet: 465 ist offen und der sollte für das Submitten von Mail benutzt werden.

Legitime ausgehende Mail, die nicht über die eigenen Server geht wird so nicht behindert, es erschwert die Arbeit aber für Spambots, die man sich in einem Windows-Netz mit vielen mobilen Clients immer wieder einfängt.

Ich mache es nicht anders. Ein komplettes, kontrolliertes Netz im Hintergrund zu haben ist aber eine etwas andere Geschichte als die Rootserver, von denen hier die Rede ist.

flo wrote:Es ist ja schön, wenn Du Deine Meinung verteidigst, aber das ändert nunmal wenig am Gehalt der Sache.

Script-Kiddies und Würmer werden getäuscht --> Ja, es bringt etwas.

ok, es bringt etwas. und warum wird hier dann regelmaessig davon abgeraten ?

flo wrote: Dein verlegter SSH-Port bringt schlicht und ergreifend gar nichts, wenn irgendeine Lücke einer Webanwendung zu einem lokalen Exploit mit evtl. anschließenden Root-Rechten führt. Und dies ist mittlerweile (hier) der absolute Standard in den "Server-gehackt"-Threads.

ja und, Dein SSH-key und das gute passwort bringt da genausowenig, was ist also bewiesen damit ? nix!

flo wrote: So, nachdem wir den pauschalen Punkt geklärt haben, kannst Du nun entweder mal die Augen aufmachen und die restlichen Posts hier vernünftig lesen oder den Browser schließen und Dir auf die gute Idee ein Bierchen gönnen.

Und mach mir bitte nicht weis, daß vor "wget"-Zugriffen irgendwelche Versionen überprüft würden - wäre das der Fall, würde ich die nicht ständig in meinem Default-Host finden.

wie waers wenn Du meine posts mal richtig liest, mein beispiel zu den versionsunmmer war folgendes (und hey, Du hast immer noch die chance als erster sachlich auf dieses beispiel einzugehen):

buddaaa wrote: 2. das skript-kind hat einen exploit der nur fuer apache 2.0.32-.35 funktioniert und dummerweise 100.000 versuche braucht, bis er die richtige sprungadresse gefunden hat. natuerlich schreibt er ein skript, das zuerst die apache-version anschaut bevor er die 100.000 versuche startet. der security-by-obscurity-hasser installiert 2 tage lang seine kiste neu, ich bohr in der nase.

flo wrote: Auch der geübte Angreifer wird sich dadurch nicht abschrecken lassen, eher wird er noch neugieriger gemacht.

der geuebte angreifer, der es auf einen bestimmten root-server abgesehen hat ist doch wohl eher selten (sowas gibts eher bei firmen-servern, oder vieleicht wenn ne shop-software mit kreditkarten-nummern laeuft und dann ist die neugier eh schon vorhanden). denen ist doch egal ob sie meinen root-server oder die nachbarn knacken, das sind beides kisten mit ner dicken anbindung und mehr wollen die doch nicht.

jfreund wrote:

• Ja, ich finde Portverlegung doof. Sachliche Argumente dafür gibt's genug - falsches Sicherheitsgefühl, SSH die geringst wahrscheinliche Einfallsstelle - wer da rein kommen kann (wohlgemerkt: Exploit für ein verschlüsseltes Protokoll, das schafft kein Skriptkiddie) ist auch schlau genug, den richtigen Port zu finde - etc.

wir sind doch mittlerweile soweit, das es mindestens gegen skript-kiddies und wuermer hilft, wieso nennst Du es "falsche sicherheitsgefuehl" ?

ein skript-kiddie schafft alles, wofuer es von den aelteren einen fertigen exploit kriegt, also fuehl Dich nicht sicher nur weil jemand erst 13 ist.

ausserdem wird hier generel von port-verlegung abgeraten, nicht nur bei SSH. ist z.b. bei POP3, IMAP und openvpn auch kein problem.

jfreund wrote: [*]Nein, ich habe nie jemandem davon abgeraten, sein System sicher zu konfigurieren - wo willst Du bitteschön das gelesen haben? Im Gegenteil, ich habe ziemlich deutlich gesagt, dass ich das Verlegen des Ports nicht als hinreichende Sicherheitsmaßnahme betrachte.

Du schriebst hier http://www.rootforum.org/forum/viewtopi ... 215#268122

jfreund wrote:Lieber auf dem Standard-Port lassen,

und mal umgekehrt, was ist den der vorteil von SSH auf port 22 ?

jfreund wrote: [*]Ich persönlich habe sehr gute Gründe, meinen SSH-Port nicht zu verlegen (z. B. dürfen meine User nicht per FTP, sondern nur per SCP/SFTP (chrooted) auf ihre Webverzeichnisse zugreifen - mit pubkey-Auth, versteht sich)

ja und, ich kenn keinen SCP-client dem man nicht die portnummer uebergeben kann.

jfreund wrote: [*]Was machst Du mit Diensten, deren Port Du nicht einfach verlegen kannst (IMHO ist z. B. ein HTTP-Daemon ein weit größeres Risiko als ein OpenSSH-Server...) - technisch gesehen geht das natürlich, aber ob es sinnvoll ist, einen öffentlichen Webserver auf Port 63024 zu betreiben, sei mal dahingestellt...

Du wirst es nicht glauben, die lass ich einfach da wo sie sind. und nur weil apache auf 80 laufen muss bin ich trotzdem in der lage meine ssh, pop3 und openvpn zu verlegen.

jfreund wrote:[/list]Fakt ist, dass der Sicherheitsgewinn durch Ersetzen der User/Passwort-Anmeldung durch Public Key, das Einsperren der User in chroots (in Verbindung mit Grsecurity ziemlich ausbruchsicher), der Zwang zu sicheren Passwörtern und zeitnahes Einspielen von Sicherheitsupdates (t <= 8 Stunden) einen nahezu unendlich viel größeren Beitrag zur Sicherheit eines Systems leistet als das Verlegen eines Ports.

jap, aber das man airbag, knautschzone, ABS und ESP hat ist kein grund dagegen noch den sicherheitsgurt anzulegen.

wgot wrote:

buddaaa wrote:es macht einen server deutlich sicherer bei keine relevanten nachteilen. (...) SSH != 22, fehlenden versionsnummern, nicht-pingbarkeit

ein unsicherer Server wird durch diese Maßnahmen nicht sicherer, er wird bestenfalls später gefunden.

das ziel ist, das der server nicht geknackt wird, und diese massnahmen helfen dabei.

wgot wrote:

flo wrote:Dein verlegter SSH-Port bringt schlicht und ergreifend gar nichts, wenn irgendeine Lücke einer Webanwendung (...)

Da gibt's für den echten Obscurity-Fan nur eine Lösung: HTTP-Port verlegen. :lol:

Seit ich SMTP auf Port 3375 verlegt habe ist keine einzige Spammail mehr angekommen. :roll:

ja lustig burschis, wenn man sachlich nicht mehr weiter weiss mal ein bischen uebertreiben. in meinen posts sind noch genug beispiele fuer security by obscurity auf die komischerweise noch niemand eingegangen ist, warum also neue erfinden? wenn die jemand wiederlegt darf er gern ueber mich lachen :)

buddaaa wrote:jap, aber das man airbag, knautschzone, ABS und ESP hat ist kein grund dagegen noch den sicherheitsgurt anzulegen.

Ohne Sicherheitsgurt bist Du bei nem Crash auch mit Airbag und knautschzone tot - insofern hinkt der Vergleich etwas
ABS und ESP hingegen sind dafür da, einen Crash zu verhindern. Der Sicherheitsgurt ist also wohl eher mit einer guten Backup-Strategie zu vergleichen - falls es doch mal knallt.

buddaaa wrote:Du schriebst hier http://www.rootforum.org/forum/viewtopi ... 215#268122

jfreund wrote:Lieber auf dem Standard-Port lassen,

Nur der Vollständigkeit halber reiche ich die zweite Satzhälfte mal nach:

jfreund wrote:dafür aber auf Public Key Authentifizierung umstellen.

Ich habe also vorgeschlagen, eine Methode der Absicherung (Port verlegen) durch eine stärkere (Public Key) zu ersetzen, und nicht, wie von Dir behauptet, lieber das Scheunentor offen zu lassen.

buddaaa wrote:ja und, ich kenn keinen SCP-client dem man nicht die portnummer uebergeben kann.

Und ich einige User, denen SCP ansich schon nicht geheuer ist (und weil der Upload aus den meisten HTML-Editoren nicht funktioniert) und dann genervt woanders hin abwandern würden, wo sie per FTP an ihre Daten ran können. Sicherheit muss mit Usability einhergehen (wie das Linux-Magazin in einer Artikel-Serie wunderbar dargelegt hat) - da ist die Beschränkung auf SCP schon die Schmerzgrenze...

Um jetzt noch einen draufzusetzen: Portknocking würde sogar die Existenz eines SSH-Daemons verschleiern. Nur so als Überlegung... Script-Kiddies und Portscans wären damit draußen 8)

buddaaa wrote:ausserdem wird hier generel von port-verlegung abgeraten, nicht nur bei SSH. ist z.b. bei POP3, IMAP und openvpn auch kein problem.

Ich glaube nicht, daß ich bereit wäre, 300 Installationen von Outlook, AppleMail, Mozilla und Netscape zu überwachen und den knapp 600 Mailboxen (=Usern) zu sagen, welcher Port gerade mal der aktuelle ist.

Laß uns diese Diskussion bitte beenden - Du drehst Dich inhaltslos im Kreis und mir fallen vom Kopfschütteln schon die Haare aus.

flo.