populaere irrtuemer: security by obscurity

[buddaaa]

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.

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

flo.

ich konnts ja erst garnicht glauben als ich eben in einem anderen thread folgendes von Dir fand:

... - alternativ kanns Du auch ein Tool installieren, das eine IP nach Anzahl von falschen PWs sperrt. Oder/und den SSH-Port verlegen.

flo.

und das ganze noch ohne den neuling noch zu weitergehenden sicherheitsmassnahmen zu animieren ;)

[Roger Wilco]

*Sigh* Ihr dreht euch alle so schön im Kreis. Mir wird schon ganz schwindlig. :roll:

Einigen wir uns doch einfach darauf,

• dass einige der hier Anwesenden das Verlegen von bestimmten Diensten vom Well-known Port auf einen anderen Port für sinnvoll halten und andere diese Meinung eben nicht teilen.
• dass es nicht die einzige Sicherheitsmaßnahme bleiben sollte und dass Leute, die augenscheinlich keine Ahnung haben über Vor- und Nachteile aufgeklärt werden müssen.
• dass die Meinungen, wie bei allen Diskussionsthemen für technophile Geeks, weit auseinandergehen und gerne polarisiert wird.

Ansonsten muss ich hier leider dicht machen, da ich keinen Fortschritt mehr in der Diskussion sehe und kein Schlachtfeld für Flamewars pflegen möchte.

[flo]

@Buddaaaaa: Ich bewundere, wie Du es schaffst, in feinster Polemik Dinge außerhalb Ihres Zusammenhangs zu zitieren - der genannte Thread hatte den Titel "SSH Bruteforce TAGE, WOCHENLANG immer schön TESTEN!" - das ändert nichts an meiner Meinung daran, daß es twar mit Sicherheit ganz nett und vielleicht ganz nett sicher ist, die Ports der eigenen Dienste täglich auszuwürfeln. Andererseits unterstelle ich ganz einfach, daß Du der Zielgruppe angehörst, die als erste laut schreit, wenn Firma XY oder Firma MS mal wieder versuchen, einen eigenen Standard zu implementieren. - Für mich EOD.

flo.

[buddaaa]

@Buddaaaaa: Ich bewundere, wie Du es schaffst, in feinster Polemik Dinge außerhalb Ihres Zusammenhangs zu zitieren - der genannte Thread hatte den Titel "SSH Bruteforce TAGE, WOCHENLANG immer schön TESTEN!"

momentmal, Du vergleichst security by obscurity mit "samba auf rootservern" und MS-standards (siehe unten) und wenn ich SSH-portverlegung mit SSH-portverlegung vergleiche ist das zusammenhangslos ?

warum hat den meine SSH-portverlegungs-empfehlung "anfaenger dazu verleitet ihr system nicht richtig abzusichern", und Deine nicht ?

- das ändert nichts an meiner Meinung daran, daß es twar mit Sicherheit ganz nett und vielleicht ganz nett sicher ist, die Ports der eigenen Dienste täglich auszuwürfeln. Andererseits unterstelle ich ganz einfach, daß Du der Zielgruppe angehörst, die als erste laut schreit, wenn Firma XY oder Firma MS mal wieder versuchen, einen eigenen Standard zu implementieren.

bei einer verbindung zweier saetze mit "andererseits" wuerd ich ja schon erwarten das die inhaltlich irgendetwas miteinander zu tun haben :)

[manarak]

Ich muss hier noch meinen Senf dazugeben, weil dieser Punkt von niemandem aufgegriffen wurde:

"aktuell gepatchte" sowie schlecht gewartete Server sind gegebenenfalls beide für bestimmte 0-day Exploits verwundbar, sowie für noch unbekannte Exploits.

Stellt euch jetzt dieses Horrorszenario vor: Euer Server ist vorbildlich gepatcht, und ihr fährt mit eurer Freundin/Ehefrau ins Wochenende. Pünktlich einige Minuten nach Abfahrt taucht zuerst in einem engen Hackerkreis ein neuer Exploit auf, der mit bestimmten Apache-Versionen funktioniert.
Sie fangen an, die Versionen zu scannen...

Ihr seid Montag zurück und erfahrt vom Exploit, und patcht dann.

Frage:
Wieviel höher ist in diesem Fall (Zeitfenster für die Verwundbarkeit und Konzentration der Angreifer auf bestimmte Versionen) die Wahrscheinlichkeit, dass ein Server, der brav seine Versionen rausschickt, gehackt wird, als einer der es nicht tut?

[nyxus]

Stellt euch jetzt dieses Horrorszenario vor:

Falsche Annahme. Echte Rootserver-Admins machen weder Wochenende noch Urlaub!

[aubergine]

Stellt euch jetzt dieses Horrorszenario vor:

Falsche Annahme. Echte Rootserver-Admins machen weder Wochenende noch Urlaub!

Ich hoffe mal das war Ironie, andernfalls solltest du mal bei Ebay nach einer Packung "Leben mit Sinn" ab 1€ Auktion Ausschau halten. 8)

[Joe User]

Stellt euch jetzt dieses Horrorszenario vor:

Falsche Annahme. Echte Rootserver-Admins machen weder Wochenende noch Urlaub!

Ich hoffe mal das war Ironie, andernfalls solltest du mal bei Ebay nach einer Packung "Leben mit Sinn" ab 1€ Auktion Ausschau halten. 8)

Nö, bei "echten" Servern gibt es mehr als einen root, so dass 24/365 sichergestellt ist. Alle anderen müssen sich ihre Freizeit zwischen den Exploits nehmen :twisted:

[captaincrunch]

Mal ganz vom zeitlichen Askpekt abgesehen: mit dem passenden Sicherheitskonzept brauchen dich 0-days wenig bis gar nicht jucken. Wegen meiner kann das Kiddie seinen Exploit loslassen bis es schwarz wird, dank RBAC und Co. wird es sich aber in den allermeisten Fällen die Zähne dran ausbeißen, am o.g. System vorbei z.B. eine Shell zu spawnen.

[nyxus]

Mal ganz vom zeitlichen Askpekt abgesehen: mit dem passenden Sicherheitskonzept brauchen dich 0-days wenig bis gar nicht jucken. Wegen meiner kann das Kiddie seinen Exploit loslassen bis es schwarz wird, dank RBAC und Co. wird es sich aber in den allermeisten Fällen die Zähne dran ausbeißen, am o.g. System vorbei z.B. eine Shell zu spawnen.

Wohl dem der das einsetzen kann. Bisher habe ich auch immer Deine hervorragenden Kernel verwendet, aber seit OpenVZ geht das halt nicht mehr. Dafür läuft auf dem Host-System aber auch nur noch SSH nach aussen.

[soldier601]

Da ich meinen Root Server nur für Gameserver, TS2 und eine Website benötige, finde ich die Methode mit der Portverlegung recht gut. Nur ICH brauche SSH Zugriff, also kann ich auch den Port ändern. Desweiteren benutze ich nur Publickeys, dies ist auch ein riesen Sicherheitsgewinn. Ausserdem werde ich bald noch SSH so einstellen, das es nur Verbindungen von mir über DynDNS zulässt. So habe ich, wenn ich alles zusammenzähle ein Stück Sicherheit gewonnen, und dazu kommt noch das die Logfiles wesentlich leerer sind und ich so eher die wirklich wichtigen Dinge sehe, denn bei 2,5MB logfile in 2 Wochen, wo 90% nur von SSH und nicht erfolgreichen Loginversuchen sind, da fallen einen die wichtigen Dinger nicht mehr so leicht auf. Und natürlich versuche ich meine Software relativ up to date zu halten, sodaß ich abends beruhigt ins Bett gehen kann. Meine Meinung ist, das wenn man sich auskennt man durch Security durch obscurity nur Vorteile hat und das man auch weiss dman keine absolute Sicherheit gewährleisten kann.

MfG
Soldier

[lord_pinhead]

Warum benutzt du nicht einfach Portknocking? Ist einfacher und schneller. Wenn du sowisso nur Keyauth nutzt und Passwort authentifizierung abgeschalten hast, dann ist es doch sowisso wurst wer da verbinden will ;)

[buddaaa]

Wenn du sowisso nur Keyauth nutzt und Passwort authentifizierung abgeschalten hast, dann ist es doch sowisso wurst wer da verbinden will ;)

hach, wo ich gerade diesen thread sehe der immer noch ueber dem forum schwebt muss ich der vollstaendigkeit halber diesen link posten:

http://www.heise.de/security/Tausende-d ... ung/108528

ist immer noch jemand der meinung das keyauth als alleinige massnahme zur SSH-absicherung reicht? :)

[Joe User]

Wenn du sowisso nur Keyauth nutzt und Passwort authentifizierung abgeschalten hast, dann ist es doch sowisso wurst wer da verbinden will ;)

hach, wo ich gerade diesen thread sehe der immer noch ueber dem forum schwebt muss ich der vollstaendigkeit halber diesen link posten:

http://www.heise.de/security/Tausende-d ... ung/108528

ist immer noch jemand der meinung das keyauth als alleinige massnahme zur SSH-absicherung reicht? :)

Ja, denn das "Debian-Debakel", auf dem der Artikel basiert, ist weitestgehend abgehakt...

[Joe User]

Ja, denn das "Debian-Debakel", auf dem der Artikel basiert, ist weitestgehend abgehakt...

Und meine Distri hat es damals gar nicht betroffen.

Zumindest nicht direkt ;)
Meine hat es ebenfalls nicht betroffen...

[buddaaa]

Ja, denn das "Debian-Debakel", auf dem der Artikel basiert, ist weitestgehend abgehakt...

gröhl, und die update-verwaltung hast Du bei allen Deinen kisten abgeschaltet weil jetzt, 5.12.08 alle bekannten loecher gestopft sind und das damit abgehakt ist? :) woher weisst Du denn das nicht morgen das naechste loch in openssh auftaucht und eine weile ausgenutzt wird bevor es ueberhaupt als 0-day bekannt wird?

nur keyauth ist einschichtige sicherheit, das taugt nie.

[Joe User]

Ja, denn das "Debian-Debakel", auf dem der Artikel basiert, ist weitestgehend abgehakt...

gröhl, und die update-verwaltung hast Du bei allen Deinen kisten abgeschaltet

Meine Kisten werden mehrmals wöchentlich und bei Bedarf auch mehrmals täglich aktualisiert, zudem bin ich in der Lage nötigenfalls jederzeit selbst zu patchen, ein grosser Vorteil von Non-Binary-Ditros...

weil jetzt, 5.12.08 alle bekannten loecher gestopft sind und das damit abgehakt ist? :)

Es sind in keiner einzigen Distribution, wie auch bei allen anderen Betriebssystemen und sonstigen Applikationen, alle bekannten Security-Bugs behoben.

woher weisst Du denn das nicht morgen das naechste loch in openssh auftaucht und eine weile ausgenutzt wird bevor es ueberhaupt als 0-day bekannt wird?

Das kann und will ich gar nicht wissen, denn dafür müsste ich mindestens legitime, meist jedoch illegale Wege gehen, um vorzeitig an die nötigen Infos kommen zu können...

nur keyauth ist einschichtige sicherheit, das taugt nie.

Ich habe durchaus noch einige andere Verteidigungslinien, welche allerdings nicht an Dritte mitgeteilt werden. Desweiteren kann ich befallene Systeme jederzeit vom Netz nehmen...

[buddaaa]

Ich habe durchaus noch einige andere Verteidigungslinien, welche allerdings nicht an Dritte mitgeteilt werden.

oh, noch ein freund von security by obscurity, willkommen im club ;) hier um forum gibt es aber echt richtig viele leute die behaupten das auf keyauth umstellen reicht und keiner von denen erwaehnt, dass man noch weitere massnahmen ergreifen sollte, ich galube sogar foren-admins.

Desweiteren kann ich befallene Systeme jederzeit vom Netz nehmen...

naja, man muss es erstmal feststellen und einen redundanten, nichtbefallenen server dafuer haben.

[buddaaa]

nur keyauth ist einschichtige sicherheit, das taugt nie.

Ja nimmst Du Telnet weil openssh so löchrig ist?

schon lustig das telnet bei debian sicherer war als ssh. aber nein, ich benutzt hier verpoente methoden wie einen nicht standard-port und iptables auf dem server zur zugriffsbeschraenkung.

Du machst sowas nicht, ssh auf port 22, offen fuer alle? viel glueck beim naechsten loch.

[buddaaa]

Wärst Du überhaupt in der Lage einen Angriff zu erkennen?
Ausserdem ist Telenet alles andere als sicherer.
Die oben genannte Lücke, wenn man sich mit der Materie besser auskennen würde, ist nicht ohne weiteres aus zu nutzen.
Zumindest nicht so leicht als man sich per telnet Zugang verschaffen kann.

nochmal: ich benutze keinen telnetd, den hast Du in die runde geworfen. trotzdem ist ein alter debian-server mit openssh remote exploitbar, einer mit telnetd nicht.

oh, noch ein freund von security by obscurity, willkommen im club ;) hier um forum gibt es aber echt richtig viele leute die behaupten das auf keyauth umstellen reicht und keiner von denen erwaehnt, dass man noch weitere massnahmen ergreifen sollte, ich galube sogar foren-admins.

Such Dir doch endlich mal ein anderes Forum zum rum trollen!

moment moment. hier im forum tummeln sich eine menge leute die aller welt raten openssh einfach mit keyauth zu benutzen aber den port auf 22 zu lassen und kein iptables zu installieren. ein debian-admin der darauf gehoert haette, haette einen schutzlosen server gehabt. aber hier ist anscheinend niemand willens daraus zu lernen.

Egal welche Massnahmen Du nutzt um Dein System "abzusichern", ist eine Massnahme die allerwichtigste!
Das Erkennen eines Einbruches.

wozu soll ich denn einen angriffsversuch auf meinen SSH-port erkennen wollen? iptables schmeisst das paket weg wenn es nicht von meinen netzen kommt, fertig ist die laube. ich will doch nicht hinterher sehen das jemand eingebrochen hat :)

Und wenn Du in der Lage bist einen unerlaubten Zugriff zuverlässig und rechtzeitig zu erkennen, und Massnahmen zeitnah dagegen ein zu leiten, ja dann brauchst Du nicht mal mehr ein Passwort für den root user.

wie erkennst Du den bitteschoen netzwerkangriffe "zuverlässig und rechtzeitig" ? sitzt Du 24/7 vor Deinem logfiles und schaust was da so an angriffen aus dem internet reinprasselt? und wie willst Du zeitnah reagieren koennen, wenn einer erfolgreich war ist Deine box in ein paar sekunden darnieder. oder benutzt Du ein intrusion prevention system? ganz schlecht, viel mehr code als iptables=anfaelliger solange nicht auf einer extra-buechse.

Dein Gewäsch ist aber ausschliessliche Provokation statt eine vernünftige Diskussion oder gar Ergebnis fundierten Wissens.

sorry, aber von Dir fehlt doch noch ein sachliches argument warum ein server mit ssh auf port 49152 und iptables nicht sicherer ist als einer ohne diese massnahmen. auf den rest meines gewaeschs musst Du nicht antworten, aber hierzu haette ich diesmal gerne was gehoert wenn Du mir schon vorwirfst das ich nicht sachlich diskutiere.

Deines Schreibstil lässt sich sogar ohne weiteres die Quelle der eher lächerlichen Provokation erahnen.

oh gott, bin ich tatsaechlich der letzte klein- und umlautaus-schreiber im netz ? :)

[daemotron]

moment moment. hier im forum tummeln sich eine menge leute die aller welt raten openssh einfach mit keyauth zu benutzen aber den port auf 22 zu lassen und kein iptables zu installieren. ein debian-admin der darauf gehoert haette, haette einen schutzlosen server gehabt. aber hier ist anscheinend niemand willens daraus zu lernen.

Das sind die selben bösen Leute, die schon vom Einsatz von Debian ansich abgeraten haben... *scnr* Mal ernsthaft, die meisten betreiben hier Server, die von dynamisch zugewiesenen IPs aus administriert werden. Also spar uns bitte den Blödsinn vom "ich erlaube nur mein Netz". Du schmeißt hier ständig den Schutz von Netzwerken (mit dem Du offenbar beruflich zu tun hast?) und den Schutz einzeln in der Gegend rumstehender Server durcheinander.

wie erkennst Du den bitteschoen netzwerkangriffe "zuverlässig und rechtzeitig" ? sitzt Du 24/7 vor Deinem logfiles und schaust was da so an angriffen aus dem internet reinprasselt?

Die Frage kommt aber nicht ernsthaft von einem Profi, oder? Wie wäre es mit Intrusion Detection (und da meine ich jetzt nicht Netzwerk-IDSe wie Snort, sondern Überwachung lokaler Aktivitäten, etwa mit BSM oder vergleichbaren Frameworks)

und wie willst Du zeitnah reagieren koennen, wenn einer erfolgreich war ist Deine box in ein paar sekunden darnieder. oder benutzt Du ein intrusion prevention system? ganz schlecht, viel mehr code als iptables=anfaelliger solange nicht auf einer extra-buechse.

Definiere "Intrusion Prevention". Im Grunde genommen sind auch Dropping mit iptables oder die genialen Self-DoS Tools fail2ban und Denyhosts eine Form von Intrusion Prevention (wenn auch eine recht schwache). Meine Meinung hierzu ist eindeutig: Automatismen sind grundsätzlich gefährlich. Hat ein Angreifer die erst mal durchschaut (oder auch nur vermutet, dass sie vorhanden sind), kann er sie mindestens zu einem DoS gegen Dein System verwenden, selbst wenn er ihm sonst gar keinen Schaden hätte zufügen können.

So, und bevor hier noch weiter tote Pferde geritten werden, steige ich hier jetzt ab. In diesem Thread ist alles mehrfach gesagt worden, was es zu dem Thema zu sagen gibt.

[Joe User]

Ich habe durchaus noch einige andere Verteidigungslinien, welche allerdings nicht an Dritte mitgeteilt werden.

oh, noch ein freund von security by obscurity, willkommen im club ;)

Falsch, aber meine exakten Verteidigungsmassnahmen haben nunmal nichts in der breiten Öffentlichkeit zu suchen. Es sind allerdings nahezu alle Massnahmen öffentlich zugänglich, das heisst sie basieren zum grössten Teil auf Open-Source-Software und allgemeiner Best-Practise und zum kleinsten Teil auf individuellen Anpassungen der beiden zuvor genannten Punkte.

hier um forum gibt es aber echt richtig viele leute die behaupten das auf keyauth umstellen reicht

Richtig, für den SSHd reicht es auch, der Rest ist Kosmetik.

und keiner von denen erwaehnt, dass man noch weitere massnahmen ergreifen sollte, ich galube sogar foren-admins.

Wenn es um den SSHd geht, reicht es auch und wenn es um mehr geht, werden auch entsprechend weitere Massnahmen genannt.

Desweiteren kann ich befallene Systeme jederzeit vom Netz nehmen...

naja, man muss es erstmal feststellen und einen redundanten, nichtbefallenen server dafuer haben.

Richtig, man muss es feststellen. Falsch, man benötigt keinen redundanten, nichtbefallenen Server. Man benötigt lediglich saubere Backups der Nutzdaten, mehr nicht.
Grundsätzlich sind befallene Systeme
1. vom Netz zu nehmen,
2. gründlich zu analysieren,
3. neu aufzusetzen.
Zwischen Punkt 2. und 3. ist selbstverständlich das Sicherheitskonzept zu überarbeiten und umzusetzen.

[buddaaa]

nochmal: ich benutze keinen telnetd, den hast Du in die runde geworfen. trotzdem ist ein alter debian-server mit openssh remote exploitbar, einer mit telnetd nicht.

Wer sagte, der telenet wäre sicherer als sshd?

ich, ein alter debian-server mit openssh ist remote exploitbar, einer mit telnetd nicht. trotzdem benutze ich keinen telnet sondern openssh mit verlegtem port und iptables davor.

moment moment. hier im forum tummeln sich eine menge leute die aller welt raten openssh einfach mit keyauth zu benutzen aber den port auf 22 zu lassen und kein iptables zu installieren. ein debian-admin der darauf gehoert haette, haette einen schutzlosen server gehabt. aber hier ist anscheinend niemand willens daraus zu lernen.

Falsch hier wird schon immer propagiert dass ein Schutz nicht nur aus: sondern auch dem ermitteln was gerade passiet besteht.

falsch, hier gibt es jede menge postings in denen einfach nur ssh-keyauth empfohlen wird. zeig mir doch mal ein posting in dem jemandem zum absichern der ssh empfohlen wird "zu ermitteln was gerade passiert".

1. IP Tables wies in der Vergangenheit fatalaere Lücken auf als sshd.

ok, dann zaehlen wir mal remote exploits fuer openssh mit keyauth:

http://www.heise.de/security/Schwache-K ... ung/107808
http://www.openssh.com/txt/iss.adv

und jetzt iptables das nur zum filtern nach source, destination & port benutzt wird (also nicht im half-life-modul o.ae.):

ich kenn keinen exploit, irgendjemand?

hmmm, duerfte auch schwierig sein in den paar bytes tcp+ip-header eine payload unterzubringen, den rest vom packet schaut sich iptables ja garnicht erst an.

2. Du willst hinterher ganz bestimmt sehen, dass jemand eingebrochen ist!
Oder Ist Dein System schon gehackt und Du merkst es nicht einmal?

in diesem thread geht es darum ob port-verlegen und iptables angreifer draussen haelt, eine nachtraegliche einbruchserkennung wuerde ich damit nicht vergleichen, da liegt das kind doch schon im brunnen.

Im prinzip ja, Zeitversatz 2 Minuten bis zu Alarmierung.
Illegaler unbemerkter Einfalls führt zum Switch des Servers und zur abschaltung des Kontaminierten Servers.

ja wie erstrebenswert, und warum vermeidest Du das ganze nicht einfach mit port-verlegen und iptables?

Einer der 20 MAs. hat dann die Arschkarte gezogen und muss die Daten auf dem Logging Server auswerten und im Falle der Fälle eine Strafanzeige stellen.
intrusion prevention system?
Ja nutze ich und es ist nicht unsicherer warum?

kann es sein das Du "intrusion prevention" mit "intrusion detection" verwechselst? das eine sorgt dafuer das garnicht erst eingebrochen wird, das andere arlamiert nachdem es passiert ist. Deine 2 minuten zeigverzug hoeren sich nach letzterem an. port-verlegen und iptables sind "prevention". Du vergleichst hier apefel mit birnen.

... blödes Gesabbel ...

ich glaub Du hast ein problem damit das ich recht hab ;)

Allerdings werden meine System durchaus von externen System gesichert / kontrolliert und die Sicherheitsmechanismen überprüft.
Syslog loggt auch an ein anderes System, das im Bedarfsfall eine betroffene Maschine automatisch herunter fährt und eine andere Node hoch fährt bzw. Life schaltet.
Und damit eine mögliche Lücke einer Distribtuion nicht gleich wieder ausgenutzt wird, läuft darauf ein anderes OS, sind andere Schlüssel hinterlegt und allowusers auf andere Benutzer gesetzt.

Und das Spiel kann man noch deutlich weiter treiben was Ich in meiner grenzenlosen Paranoia durchaus tue ;-) .

und das empfiehlst Du jedem der einen ssh-port auf seiner kiste offen hat? :)

sorry, aber von Dir fehlt doch noch ein sachliches argument warum ein server mit ssh auf port 49152 und iptables nicht sicherer ist als einer ohne diese massnahmen. auf den rest meines gewaeschs musst Du nicht antworten, aber hierzu haette ich diesmal gerne was gehoert wenn Du mir schon vorwirfst das ich nicht sachlich diskutiere.

Auf einem Rootserver läuft meistens mehr als nur sshd.
Die Dienste sollen ja von extern erreichbar sein. Genau diese Dienste Webseiten PHP etc. sind die Ursache vieler Angriffe und erfolgreicher Einbrüche und eben nicht sshd.

es geht hier um die absicherung von ssh und nicht um all die anderen einfallstore und die zwei remote exploits zu ssh stehen weiter oben.

Meinem Honeypot zufolge ist eine der wesentlichen Massnahmen geziehltet Einbrüche sämtliche tools wie fail2ban, knockknock und co auf zu spüren deren Einstellung zu ermitteln oder aus zu schalten. Eine schlechte Webanwendung erlaubt binnen weniger Sekunden genau das zu tun.

Du schweifst ab

Also IP Tables hält einer entsprechender Attacke kaum Stand.

was meinst Du damit?

Zudem hatte wie oben erwähnt IP Tables in der Vergangenheit ebenfalls sehr gravierende Probleme.

siehe oben, beispiele?

Zudem vermittelt mir nmap sehr schnell und zuverlässig, welche Ports z.B. von IP Tables geblockt werden. Sofern Du nicht alle Ports durch IP Tables blocken lässt.
Hat den unschönen nachteil, dass damit immer ein Stück Code zusätzlich auf Anfragen reagiert, dessen Sicherheitsstatus ich genau so wenig kenne als den des sshd. Aber aus der Vergangnheit nidriger einzustufen ist als der von sshd.

das wird durch wiederhohlen nicht wahrer :)

Zudem behebt IPtables leider nicht das Loch des sshd.

von 0,003% der moeglichen IPs kommt man auf meinen ssh-port. das behebt zwar nicht das loch, macht es aber verdammt schwer.

Zudem ist eine IP Tables Einstellung um z.B. von einer festen IP auf den Server zugreifen zu können, für die Mehrheit der DSL Nutzer nicht praktikabel.
Die haben gar keine Feste IP.

hab ich auch nicht, ich schraenke es auf die netze ein, aus denen ich meine IPs vom provider bekomme (aus faulheit, normalerweise behalte ich eine IP monatelang und koennte dann nur diese eine ueber die serielle konsole eintragen).

Ist das jetzt genug für Dich?
Sind "wir" Dich los?

sorry, war nicht sehr ueberzeugend Deine vorstellung :)

Zumindest werde Ich die Diksussion nicht weiter führen.

schade, schick doch wenigstens noch 1,5 iptables-remote-exploits :)

[buddaaa]

moment moment. hier im forum tummeln sich eine menge leute die aller welt raten openssh einfach mit keyauth zu benutzen aber den port auf 22 zu lassen und kein iptables zu installieren. ein debian-admin der darauf gehoert haette, haette einen schutzlosen server gehabt. aber hier ist anscheinend niemand willens daraus zu lernen.

Das sind die selben bösen Leute, die schon vom Einsatz von Debian ansich abgeraten haben... *scnr*

dann halt so:
http://www.openssh.com/txt/iss.adv

Mal ernsthaft, die meisten betreiben hier Server, die von dynamisch zugewiesenen IPs aus administriert werden. Also spar uns bitte den Blödsinn vom "ich erlaube nur mein Netz". Du schmeißt hier ständig den Schutz von Netzwerken (mit dem Du offenbar beruflich zu tun hast?) und den Schutz einzeln in der Gegend rumstehender Server durcheinander.

ich erlaube 2* /16 und 1* /18 aus denen ich bisher vom provider meine IPs bekommen habe, voll der bloedsinn. warum so aggresiv?

wie erkennst Du den bitteschoen netzwerkangriffe "zuverlässig und rechtzeitig" ? sitzt Du 24/7 vor Deinem logfiles und schaust was da so an angriffen aus dem internet reinprasselt?

Die Frage kommt aber nicht ernsthaft von einem Profi, oder? Wie wäre es mit Intrusion Detection (und da meine ich jetzt nicht Netzwerk-IDSe wie Snort, sondern Überwachung lokaler Aktivitäten, etwa mit BSM oder vergleichbaren Frameworks)

=D> =D> =D> Du bist ja ein ganz schlauer, wenn Du mal 2 zeilen weiter gelesen haettest frage ich da nach intrusion detection/prevention. (sorry, ich hab auch mal lust persoenlich zu werden wenn Du schon anfaengst).

und wie willst Du zeitnah reagieren koennen, wenn einer erfolgreich war ist Deine box in ein paar sekunden darnieder. oder benutzt Du ein intrusion prevention system? ganz schlecht, viel mehr code als iptables=anfaelliger solange nicht auf einer extra-buechse.

Definiere "Intrusion Prevention".

schau doch in wikipedia, in unserem fall die netzwerk-variante nicht host-basiert, soweit will man es ja nicht kommen lassen. und netzwerk-intrusion-prevention auf dem server ist anfaelliger als iptables auf dem server.

Im Grunde genommen sind auch Dropping mit iptables oder die genialen Self-DoS Tools fail2ban und Denyhosts eine Form von Intrusion Prevention (wenn auch eine recht schwache). Meine Meinung hierzu ist eindeutig: Automatismen sind grundsätzlich gefährlich. Hat ein Angreifer die erst mal durchschaut (oder auch nur vermutet, dass sie vorhanden sind), kann er sie mindestens zu einem DoS gegen Dein System verwenden, selbst wenn er ihm sonst gar keinen Schaden hätte zufügen können.

warum versucht mir hier eigentlich jeder zu erzaehlen wie doof fail2ban ist obwohl ich damit nix am hut hab? :) bleib doch beim thema und erzaehl mir das ein alter debian-server mit verlegtem ssh-port und iptables nicht deutlich laenger lebt als einer ohne.

So, und bevor hier noch weiter tote Pferde geritten werden, steige ich hier jetzt ab. In diesem Thread ist alles mehrfach gesagt worden, was es zu dem Thema zu sagen gibt.

ein bischen rumstaenkern und dann klein beigeben, schwach

[buddaaa]

Ich habe durchaus noch einige andere Verteidigungslinien, welche allerdings nicht an Dritte mitgeteilt werden.

oh, noch ein freund von security by obscurity, willkommen im club ;)

Falsch, aber meine exakten Verteidigungsmassnahmen haben nunmal nichts in der breiten Öffentlichkeit zu suchen. Es sind allerdings nahezu alle Massnahmen öffentlich zugänglich, das heisst sie basieren zum grössten Teil auf Open-Source-Software und allgemeiner Best-Practise und zum kleinsten Teil auf individuellen Anpassungen der beiden zuvor genannten Punkte.

ach, aber wenn ich den ssh-port in meinem open source opensshd geaendert hab ist das security by obscurity? erklaer mal den unterschied.

hier um forum gibt es aber echt richtig viele leute die behaupten das auf keyauth umstellen reicht

Richtig, für den SSHd reicht es auch, der Rest ist Kosmetik.

ein alter-debian-server, remote exploitbar per openssh, ist Dir also gut genug gesichert? ein x jahren kommt das naechste ssh-loch, alle kisten offen. warum ist das genug?

und keiner von denen erwaehnt, dass man noch weitere massnahmen ergreifen sollte, ich galube sogar foren-admins.

Wenn es um den SSHd geht, reicht es auch und wenn es um mehr geht, werden auch entsprechend weitere Massnahmen genannt.

wieso reicht das, debian-problem plus:
http://www.openssh.com/txt/iss.adv

woher nimmst Du den glauben das nicht noch ein loch kommt?

Desweiteren kann ich befallene Systeme jederzeit vom Netz nehmen...

naja, man muss es erstmal feststellen und einen redundanten, nichtbefallenen server dafuer haben.

Richtig, man muss es feststellen. Falsch, man benötigt keinen redundanten, nichtbefallenen Server. Man benötigt lediglich saubere Backups der Nutzdaten, mehr nicht.

ach so, ich dachte Du praesentierst hier massnahmen die mit iptables und port-verlegung mithalten koennen, naemlich ungestoertem abverkauf der weihnachts-waren im webshop. mit Deiner argumentation kann man ja auch slackware 1.0 benutzen weil man hat ja ein backup :)

Grundsätzlich sind befallene Systeme
1. vom Netz zu nehmen,
2. gründlich zu analysieren,
3. neu aufzusetzen.
Zwischen Punkt 2. und 3. ist selbstverständlich das Sicherheitskonzept zu überarbeiten und umzusetzen.

ja waer es nicht viel toller wenn es garnicht erst soweit kommt? :)