Schrott des Monats?

[volker68]

In den Release-Notes von PC-BSD 1.2 bin ich über den Satz gestolpert, daß das System nun von DenyHosts geschützt wird. In totaler Unwissenheit, was DenyHosts ist, habe ich mir das mal angesehen...

Im Grunde genommen ist das das Gleiche, wie ich es selber schonmal mit einem borne-Script und `pf' auf einzelnen Maschinen gemacht habe. Das sshd-Log wird nach fehlerhaften Logins durchsucht und bei Überschreitung von vordefinierten Limits wird die IP-Adresse (via hosts.deny bzw. meine Lösung ging über pf-Tables) gesperrt.

Soweit so gut, aber DenyHosts tauscht dann noch Listen mit IP-Adressen über einen zentralen Server aus, sodaß einmal bei einem System gesperrte IP-Adressen bei allen Systemen gesperrt werden, die DenyHosts verwenden.

Was denkt Ihr darüber? Könnte das nicht für ein paar lustige Spielchen taugen, wie mit RBL? Wen wollen wir denn morgen aus dem Internet kicken? Gibt es echt noch Leute, die 1) solchen Schrott programmieren und 2) die sowas gut finden?

Eine moderne Form von zentralistischer (technokratisierter) Zensur - nicht nach meinem Geschmack.

 

[asg]

Gnaa, soll das heissen das jeder Client mit PCBSD die gesperrten IPs mit einem Server abgleicht und neue IPs dort meldet?
Wie sinnfrei.
Ich regle das mit pf+tables und expiretable. Da werden dann Einträge die älter als eine Stunde sind wieder automatisch gelöscht. Könnte ja eine Dial-in sein oder sonstiges was man nicht sperren möchte.

 

[-Daemon-]

Ich hab was im PC-BSD-Forum gefunden: zum Thema gefunden. Wenn ich das jetzt richtig verstanden habe gleicht PC-BSD nichts mit einem zentralen Server ab.
Ausserdem ist das ganze ja nicht zwingend (kann man - wie aus obigem Link ersichtlich - abstellen), allerdings weiss ich nicht ob das default ist oder erst durch den Benutzer aktiviert werden muss...

Es gibt sicherlich andere, elegantere und bessere Loesungen. Seht es aber mal so: das ist erst der Anfang - da wird sicherlich noch dran gefeilt. Vielleicht merken sie auch irgendwann das es auch anderst geht...

Ach ja: Man findet es auch in den ports unter security/denyhosts

Edit: DenyHosts Seite bei sourceforge

 

[Daniel Seuffert]

Hm, irgendwie war mir noch so, als sei der pf der beste Paketfilter seit der Erfindung von geschnittenem Brot... Man könnte zu sowas kommen: http://www.bgnett.no/~peter/pf/en/bruteforce.html

Naja, ich bin schon still und schleich mich, mehr soag i ned...

 

[SierraX]

Nach Art der Scharfschuetzen weiss eigentlich auch jeder ernstzunehmende Angreifer, das nach 1-2 Angriffen die Position (in dem Fall, die IP Adresse und ggf die MAC) gewechselt werden muss.
Also wuerde ein abgeglichener Server nur kurzzeitig sinn machen weil es mit der Zeit auch echte Komunikationsversuche unterbinden wuerde. Und damit waere dann ja ggf ein anderes Ziel des Angreifers erfuellt DOS auf einem oder noch besser mehreren Rechnern

 

[kili]

Wenn ich das jetzt richtig verstanden habe gleicht PC-BSD nichts mit einem zentralen Server ab.

Dieses DenyHosts-Dings scheint nicht per default angeschaltet zu sein. Gut. Aber es wird installiert. Schlecht. Ganz schlecht. Wie Daniel schon schrieb, gibt es deutliche effektivere Moeglichkeiten, das Rauschen in den Logfiles zu vermindern, und eben das (Rauschunterdrueckung) kann der einzige Zweck solcher Massnahmen sein. An Sicherheit bringt das rein gar nichts.

Und dieses seltsame Synchronisation-Feature bei DenyHosts schreit geradezu nach einem DoS-Angriff. Einfach fuer eine Adresse per XMLRPC-Schnittstelle ein paar tausend Eintraege auf dem DenyHosts-Server generieren, und schon duerfte der Besitzer dieser Adresse nicht mehr auf seine Rechner kommen, falls sie denn DenyHosts mit Synchronisation verwenden.

Es gibt sicherlich andere, elegantere und bessere Loesungen. Seht es aber mal so: das ist erst der Anfang - da wird sicherlich noch dran gefeilt.

Du meinst, es koennte noch schlimmer werden, als es schon ist? Was kommt als naechstes? Eine ping-Blacklist?

 

[Daniel Seuffert]

Man sollte sich einfach vor der Einführung von irgendwelchen Features fragen, wer die Zielgruppe ist und wozu Feature X denn dienen sollte. Man gibt vor ein einfach zu installierendes FreeBSD für den Desktop-user machen zu wollen und greift dann zu solchen Sachen. Das ist halt grad mal komplett am Thema vorbei, ungefähr genauso wie Apache-pbi-files und dergleichen.

Mir scheint generell, daß da einige PC-BSD-Mannen keinen Plan haben, wohin die Reise gehen soll, es gibt Anzeichen genug dafür. Dafür gibt es PC-BSD-Jubelperser zuhauf, die gesunden Menschenverstand durch schlechte Manieren und vollkommen BSD-fremde attitude nebst Hype kompensieren wollen. Wer mal auf den Threadersteller geblickt hat bemerkt "antik" als Propagandist des ganzen. DesktopBSD-Menschen kennen diesen Namen allzugut. So gut, daß er quasi eine persona non grata im DesktopBSD-Forum geworden ist. Mehr sag ich nicht dazu, nachlesen kann im Zweifel jeder selber.

 

[volker68]

Wer mal auf den Threadersteller geblickt hat bemerkt "antik" als Propagandist des ganzen. DesktopBSD-Menschen kennen diesen Namen allzugut.

Was hast Du bitte jetzt für ein Problem? Und woher soll irgendwer meinen Namen kennen? Ich habe mich jahrelang nur in Mailinglisten rumgetrieben (die nichts mit DesktopBSD zu tun haben).

BTW, für den Fall, daß es jemanden interessieren sollte: Ich halte die DesktopBSD Variante für die saubere und besser durchdachte Version. Leider ist das Team nur recht langsam, aber was bringt einem Schnelligkeit, wenn alles nur zusammengebastelt ist?

Daniel, Du solltest Dir vielleicht erstmal überlegen, wen und warum Du hier defamierst. Wir beide kennen uns garantiert nicht und ich weiß nicht, woher Du Dir die Frechheit nimmst, hier gegen mich Stimmung zu machen. Ich habe mich vor einiger Zeit entschieden, ein bißchen an die Community "zurückzugeben", indem ich ab und an End-User Support mache - das ist meine einzige Motivation, hier im Forum vorbeizuschauen. Wenn ich mich dann aber mit solchen (defamierenden) Äußerungen, wie von Dir rumschlagen muß, dann halt nicht. Ich grübele nur, woher Du Dir diese Frechheiten nimmst.

 

[Yamagi]

Ich glaube, dass es nicht um dich ging, sondern um denjenigen, der diesen Thread hier gestartet hatte: http://forums.pcbsd.org/viewtopic.php?t=3972&sid=e6060e282a92f798dbb0f54c236621b4

 

[d4mi4n]

volker: er meint antik, den typ im desktopbsdforum, der immer irgendwie auf das pcbsd forum verweisen muss

 

[volker68]

Danke für die Aufklärung. Ich war schon mittelmäßig säuerlich, da kontextlos vom Threadstarter geredet wurde und der war nunmal ich. Ansonsten hätte man den Kontext noch erwähnen müssen.

Das mag nur ein Mißverständnis sein, aber sauer bin/war ich trotzdem und das war vollkommen unnötig und vermeidbar, wenn man auch sagt, was man meint (und sich nicht irgendeinen Blödsinn bezieht, der gar nicht angeführt wird).

 

[Daniel Seuffert]

Sorry Volker, da war klar und eindeutig antik gemeint, niemand sonst. Du mußt das in der Eile völlig falsch gelesen haben. d4mi4n hat das ja schon etwas ausgeführt in sehr diplomatischem Ton und Yamagi hat genau den richtigern thread wiederholt.

 

[fader]

Ich verstehe wirklich nicht, was diese ganze Aufregung um diese Angriffe soll. Seit Anbeginn des Internets werden offene Dienste ausgelotet und sind Ziel von Angriffen. Auch Bruteforce. Nun passiert das fuer ssh und alle werden unruhig. Zu der ganzen Sachen fallen mir 3 Dinge ein:

1) Wenn mich diese Angriffe wirklich *ernsthaft* unruhig werden lassen, dann ist das ein sicheres Zeichen, dass mit meinem Sicherheitskonzept etwas nicht stimmt. Habe ich ein schwaches Passwort? Haben meine Nutzer ein schwaches Passwort? Gewissheit schafft da z.B. jack the ripper (Passwortcracker feinster Machart) in Verbindung mit der Openwall Wordlist. Der knackt so ziemlich jedes leicht zu erratende Passwort unterhalb von 5min. Generell: Passwort Policy ueberpruefen. Laenge, Sonderzeichenanteil usw usw. Kein solcher Bruteforceangriff probiert irgendwas durch in der Art von "x+2_Mtfk!". Eher wird man vom Blitz erschlagen, als dass irgendwer so ein Passwort durch Raten herausfindet.

2) "Aber sie muellen mir ja das Logfile zu". Leute, mal ernsthaft - ein Logfile ist keine Prosa. Die soll man nicht als Gute Nacht Geschichte lesen oder sowas. Die liest man auch nicht plain sondern gefiltert. Wer sich hier ernsthaft Sorgen um Logflood macht: Hint! Handlungsbedarf!

3) "Aber das ist Traffic". Schon mal jemand gemessen, was das pro Tag ausmacht? Das ist einfach nur laecherlich. Grundrauschen! Vermutlich uebersteigt der durch hysterische Hilferufe und halbdurchdachte Gegenmassnahmen produzierte Traffic sogar den, den diese paar gescheiterten Logins erzeugen. Wer bei den paar vielleicht schlimmstenfalls mal 100MB/Tag bereits hektisch auf das Trafficlimit des Providers schauen muss, der sollte sich darueber klar werden, dass ein kurzer udp Flood das zigfache innerhalb von ein paar Minuten erzeugen kann (um nur mal _eine_ Moeglichkeit aufzuzeigen).

Zur Nuetzlichkeit dieser verteilten Gegenwehr auch noch 2 Punkte:

- Wunderbar ausnutzbar als DoS. Einfacher kann mans den Jungs fast gar nicht mehr machen.

- Wer sich sowas installiert, wird vermutlich ohnehin obigen Punkt 1 erfuellt haben und ist damit gar nicht mehr von diesen Angriffen bedroht. Wenn er das nicht getan hat muss er sich fragen lassen, wieso er die Zeit in so eine unsinnige Sache investiert, anstatt lieber mal sein System abzusichern und die Zugangskennungen auf Loecher zu checken.

Fazit: huth'sche Frickelei. Pure Logkosmetik. Tatsaechlicher Sicherheitsgewinn nahe Null. Tatsaechliche Ursache (schwache Accounts) wird gar nicht angegangen.

Mal noch ein provokativer Nachtrag: Wenn ich mir bei der ssh nicht so richtig sicher bin, wieso habe ichs denn dann die ganze Zeit, als es diese Angriffe noch nicht in dieser Offensichtlichkeit gab, betrieben? Die ganze Zeit wars ok aber jetzt probiert da tatsaechlich mal einer durch - huh! Nu wirds gefaehrlich?

 

[fader]

Man sollte sich einfach vor der Einführung von irgendwelchen Features fragen, wer die Zielgruppe ist und wozu Feature X denn dienen sollte.

Etwa die gleiche Zielgruppe, der man hartnaeckig das Aendern des ssh ports als geniale Sicherheitsmassnahme ans Herz legt, hehe. Dass da noch keiner drauf gekommen ist: wir aendern einfach alles Diensteports und schon gibts nie wieder erfolgreiche Angriffe.

 

[0815Chaot]

Naja, dann könnte man doch glatt auf die Idee kommen, auf Port 22 einen "Fake-SSH" zu betreiben. Also einen, der einfach immer behauptet, die Authentifizierung sei fehlgeschlagen. Den tatsächlichen SSH läßt man dann auf Port 1234 oder so laufen. Damit wären die Script-Kiddies wohl erstmal beschäftigt. Ich fänd's jedenfalls lustig, da ein paar Ressourcen zu binden.

Der Fake-SSH sollte natürlich die Benutzernamen und Paßwörter in ein Log schreiben - das wäre bestimmt eine schöne Gute-Nacht-Lektüre, sich einfach mal anzusehen, was manche sich so an Benutzernamen und Paßwörtern ausdenken.

Vielleicht irgendein PC-BSD-Fritze hier in der Nähe, der Interesse an meiner Implementierung hätte?

 

[Daniel Seuffert]

Die Zielgruppe von PC-BSD war zumindest mal der einfache Desktop-Nutzer, der auf einfache Weise ein FreeBSD installieren, updaten und konfigurieren sollte. Was ein typischer Desktop-user von so einer Geschichte haben sollte bleibt meinem schwachen Verstand leider verborgen...

Ansonsten kann ich mich dem brillianten post von fader nur anschließen.

 

[fader]

Naja, dann könnte man doch glatt auf die Idee kommen, auf Port 22 einen "Fake-SSH" zu betreiben. Also einen, der einfach immer behauptet, die Authentifizierung sei fehlgeschlagen. Den tatsächlichen SSH läßt man dann auf Port 1234 oder so laufen. Damit wären die Script-Kiddies wohl erstmal beschäftigt. Ich fänd's jedenfalls lustig, da ein paar Ressourcen zu binden.

Teergrube bringt da wenig, weil der Angreifer keine eigenen Ressourcen aufwendet, sondern "geknackte" Systeme scannen laesst. Ausserdem ist mir der Unterschied nicht klar, zwischen einem korrekt abgesicherten sshd, welcher tatsaechlich alle Versuche ablehnt und einem fake-sshd, welcher nur so tut. Warum soll ich einen fake sshd bauen, der genau das gleiche tut wie der richtige sshd? Eine Moeglichkeit, die Logins nach ein paar gescheiterten Versuchen zu verzoegern ist uebrigens in sshd bereits implementiert.

Der Fake-SSH sollte natürlich die Benutzernamen und Paßwörter in ein Log schreiben - das wäre bestimmt eine schöne Gute-Nacht-Lektüre, sich einfach mal anzusehen, was manche sich so an Benutzernamen und Paßwörtern ausdenken.

Naja, ein Honeypot ... die Informationen werden allerdings wirklich nur zum Einschlafen geeignet sein: 123456, 1q2w3e4r usw. In jedem Sicherheitsguide zum Thema Passworte seit den 80ern nachzulesen. Siehe auch:

http://www.ossec.net/ossec-list/2006-March/msg00004.html

Wie ich bereits schrieb: *Wirklich* sichere Passworte probieren die gar nicht erst, weil die, im Gegensatz offenbar so manchen Admins, kapiert haben, dass das voellig aussichtslos ist.

Wenn man _wirklich_ etwas gegen unsichere Systeme tun woellte bei PC-BSD, dann wuerde man per default eine harte Passwortpolicy mit installieren.

Nachtrag: Auch hier noch der Disclaimer: Ich weiss nicht, ob das nicht vielleicht bereits in PC-BSD so ist oder was auch immer. Bezug hier nur die vorangegangene Diskussion. Mit PC-BSD kenne ich mich absolut nicht aus.

 

[fader]

Die Zielgruppe von PC-BSD war zumindest mal der einfache Desktop-Nutzer, der auf einfache Weise ein FreeBSD installieren, updaten und konfigurieren sollte. Was ein typischer Desktop-user von so einer Geschichte haben sollte bleibt meinem schwachen Verstand leider verborgen...

Naja, das ist eben immer und immer wieder die gleiche Stelle, an der das Konzept "EDV ohne Lernkurve" ins Wanken geraet. Man versucht einerseits, dem Nutzer so wenig wie moeglich Probleme vor den Erfolg zu setzen. Die Benutzung soll einfach sein. Bis dahin im Grunde verstaendlich und richtig. Man kommt dann aber eben irgendwo an einen Punkt, wo man eigentlich nicht umhin koennte, dem Nutzer *doch* eine gewisse Anstrengung abzuverlangen. Und genau da begeht man leider immer wieder den Fehler, von kommerziellen Riesen wie Microsoft unter Zugzwang gesetzt, dem Nutzer diese Anstrengung auch noch irgendwie ersparen zu wollen. Und genau *da* geht die Fehlentwicklung los.

Ich kann in ein Auto zwar eine automatische Schaltung einbauen - die Vorfahrtsregeln muss der Fahrer aber begreifen. Da es bei Computern, im Gegensatz zum Strassenverkehr, nicht um Menschenleben geht, hat sich eine solche Erkenntnis dort leider noch nicht durchgesetzt.

Disclaimer: Die Aussagen beziehen sich nicht speziell auf das PC-BSD Projekt, von dem ich uebrigens auch gar keine Ahnung habe. Ich habe niemals ein PC-BSD gesehen noch mich irgendwie damit beschaeftigt. Nicht dass es wieder boeses Blut gibt.

 

[//*Brainfuck*\\]

Naja, das ist eben immer und immer wieder die gleiche Stelle, an der das Konzept "EDV ohne Lernkurve" ins Wanken geraet. Man versucht einerseits, dem Nutzer so wenig wie moeglich Probleme vor den Erfolg zu setzen. Die Benutzung soll einfach sein. Bis dahin im Grunde verstaendlich und richtig. Man kommt dann aber eben irgendwo an einen Punkt, wo man eigentlich nicht umhin koennte, dem Nutzer *doch* eine gewisse Anstrengung abzuverlangen. Und genau da begeht man leider immer wieder den Fehler, von kommerziellen Riesen wie Microsoft unter Zugzwang gesetzt, dem Nutzer diese Anstrengung auch noch irgendwie ersparen zu wollen. Und genau *da* geht die Fehlentwicklung los.

Ich kann in ein Auto zwar eine automatische Schaltung einbauen - die Vorfahrtsregeln muss der Fahrer aber begreifen. Da es bei Computern, im Gegensatz zum Strassenverkehr, nicht um Menschenleben geht, hat sich eine solche Erkenntnis dort leider noch nicht durchgesetzt.

Disclaimer: Die Aussagen beziehen sich nicht speziell auf das PC-BSD Projekt, von dem ich uebrigens auch gar keine Ahnung habe. Ich habe niemals ein PC-BSD gesehen noch mich irgendwie damit beschaeftigt. Nicht dass es wieder boeses Blut gibt.

Moin fader,

so habe ich das ganze eigentlich noch nie betrachtet, aber Deine Argumentation hat viel für sich.
Kann Dir eigentlich nur in all Deinen Post's im vollen Umfang zustimmen und diese in meine Überlegungen zu Konzepten einfliessen lassen.
Vielen Dank das bringt mich Doch sehr weiter und hilft mir Entscheidungen noch besser abzuwägen.

adieu Rudolf

 

[volker68]

Der Fake-SSH sollte natürlich die Benutzernamen und Paßwörter in ein Log schreiben - das wäre bestimmt eine schöne Gute-Nacht-Lektüre, sich einfach mal anzusehen, was manche sich so an Benutzernamen und Paßwörtern ausdenken.

Das kann ich Dir auch ohne Fake-sshd sagen. Hier mal ein Beispiel, das etwas über 1/2 Jahr alt ist (und mir damals ins Auge gesprungen ist):

> Dec 7 17:12:11 GwOsl sshd[82876]: Illegal user deutch from 64.36.77.114
> > Dec 7 17:12:15 GwOsl sshd[82878]: Illegal user german from 64.36.77.114
> > Dec 7 17:12:20 GwOsl sshd[82880]: Illegal user hitler from 64.36.77.114
> > Dec 7 17:12:25 GwOsl sshd[82882]: Illegal user deutchland from 64.36.77.114

Diese Unsitte, Daemon-Prozesse einfach auf andere Ports umzuhängen, finde ich grauenvoll. Sowas machen nach meiner Erfahrung nur Bastler mit Langerweile. Wenn demnächst mal wieder ein remote-exploit für Apache auftaucht, was dann? Müssen wir dann immer raten, auf welchem Port ein Webmaster uns Web-Seiten zur Verfügung stellt, wenn Port 80 nicht geht? Oder müssen unsere SMTP-Clients demnächst mal auf tcp/25, tcp/250, tcp/2500 ausliefern? Die Port-Standardisierung hat ja eigentlich doch irgendwie einen Sinn.