populaere irrtuemer: security by obscurity

[buddaaa]

Internet Security Systems Security Advisory
June 26, 2002

Mmmmmh war kaum gestern....

ja, und das debian-problem war gestern.

Code: Select all

Date:   Thu Jun 7 14:27:31 2007 -0700

http://kernel.org/pub/linux/kernel/v2.6 ... g-2.6.21.4

Ip Tables ist schon seit Jahren richtig Stabil.

Du musst lesen, das problem ist in conntrack_sctp, das betrifft keinen der dieses modul nicht geladen hat und entsprechende regeln definiert. na, noch ein versuch?

Lassen wirs dabei.

ja, man muss wissen wan man verloren hat. ich fuehre noch 2:0 ;)

Wäre ich Admin, hätte ich mal mit Iptables und Deinem potentiellen IP Kreis gespielt.

diskussion verloren und dann auf was anderes umsatteln, wie ;) aber koenntest Du gerne machen. wenn Du es tatsaechlich schaffst an meinen ssh-port ranzukommen triffst Du auf TAMTARATAM: einen opensshd der genauso sicher ist wie Deiner.

[daemotron]

ja, man muss wissen wan man verloren hat. ich fuehre noch 2:0 ;)

Code: Select all

<°)))o><

*plonk*

[buddaaa]

ja, man muss wissen wan man verloren hat. ich fuehre noch 2:0 ;)

Nein man muss wissen wann es keinen Sinn mehr macht weiter zu diskutieren weil die Diskussion zu keinen fruchtbaren Ergebnis führen wird.

also wir haben 2 real exisitierende remote-exploits fuer openssh in den letzten 6 jahren. ein portwechsel hat null sicherheitsrisiko, iptables als reiner packetfilter kein nachgewiesenes. alles andere was ich hier bisher an massnahmen gehoert habe greift erst wenn das skriptkind eine rootshell hat, taugt also nicht. trotzdem wird hier immer noch empfohlen ssh ohne iptables auf dem standard-port laufen zu lassen. ich sehe da nur ein fruchtbares ergebnis: portwechsel und iptables auf dem server ist sinnvoll, wer etwas anderes empfiehlt steht auf kamikaze.

2:0 ja bestimmt stellt sich nur noch die Frage worin.
In Security Belangen auf jeden Fall nicht.

na 2:0 in remote exploits im lieblingsprodukt des anderen.

[Joe User]

Bis die Scriptkiddies an funktionierende Exploits kommen, haben die Devs und Distributoren längst Updates veröffentlicht. Wer diese Updates nicht innerhalb der ersten drei Tage nach Erscheinen eingespielt hat, hat ein ganz anderes Problem als Scriptkiddies. Bleiben also diejenigen die wissen was sie tun und somit mit den ersten POCs und/oder Exploits umgehen können. Diese Leute lassen sich durch verlegte Standardports und IPTables nicht beeindrucken...

Das Einzige wozu das Verlegen des Standardports taugt, ist das Reduzieren des auth.log, zu mehr nicht.

Vielleicht solltest Du mal Deinen SSHd ohne IPTables wieder auf den Standardport lauschen lassen und Dir mal das auth.log ansehen, dann weisst Du auch, was die Scriptkiddies wirklich versuchen und müsstest hier nicht über non-reale Theorien spekulieren...

[buddaaa]

alles andere was ich hier bisher an massnahmen gehoert habe greift erst wenn das skriptkind eine rootshell hat, taugt also nicht.

Falsch! Du kast keinen Hauch einer Ahnung von IDS und IPS und deren Wirkungsweise.

hast Du nicht oben geschrieben, dass Dein system erst mit 2 minuten verzug anspringt? mehr brauch ich doch nicht wissen. ansonsten kannst Du ja mal ross und reiter benennen, ich hab wirklich nicht den hauch einer ahnung was Du da benutzt weil Du's immer nur umschreibst.

Oder gar von Sicherheitskonzepten im allgemeinen.

ja der satz musste ja noch kommen weil er so schoen austauschbar ist. uebrigens: ein IDS/IPS erhoeht die sicherheit nicht, man braucht immer ein konzept! hoert sich voll schlau an, oder? :) soll ichs nochmal mit offenem quellcode oder update-managment bringen? :)

den satz kannst Du bringen wenn jemand behauptet mit einer einzigen massnahme sein system sicher zu kriegen, das ist hier nicht der fall.

Ansonsten wäre Dir die Effizenz der längst genannten Alternativen so klar, dass IPTables gar nicht mehr in Frage kommt.

selbst wenn Du da ein echt duftes system hast (was ich immer noch nicht glaube, 2 minuten verzoegerung?) spricht immer noch nichts dagegen iptables zusaetzlich zu verwenden, oder ist Dir mittlerweile der remote-exploit dazu eingefallen? in Deinem einen posting bist Du ja mehrfach auf der schlimmen historie von iptables vs. openssh rumgeritten, das wird doch eine grundlage gehabt haben, oder?

[buddaaa]

Bis die Scriptkiddies an funktionierende Exploits kommen, haben die Devs und Distributoren längst Updates veröffentlicht. Wer diese Updates nicht innerhalb der ersten drei Tage nach Erscheinen eingespielt hat, hat ein ganz anderes Problem als Scriptkiddies. Bleiben also diejenigen die wissen was sie tun und somit mit den ersten POCs und/oder Exploits umgehen können. Diese Leute lassen sich durch verlegte Standardports und IPTables nicht beeindrucken...

ach, wie kommen die denn an meinem iptables vorbei? da bin ich ja mal gespannt. ich kenne da nur methoden die so aufwaendig sind, dass man mit seinem ssh-exploit in der zeit 1000 andere server knackt.

[quote="Joe User"
Das Einzige wozu das Verlegen des Standardports taugt, ist das Reduzieren des auth.log, zu mehr nicht.
[/quote]

also wenn ich die wahl hab ob ich mit 65536 packeten 65536 server auch port 22 scanne oder einen auf allen ports nehme ich doch die 65536 server (in der annahme das jemand nicht in meinen server will sondern nur irgendeinen zum spammen braucht). ich hatte seit ewigkeiten keinen fullport-scan mehr in den logs.

Vielleicht solltest Du mal Deinen SSHd ohne IPTables wieder auf den Standardport lauschen lassen und Dir mal das auth.log ansehen, dann weisst Du auch, was die Scriptkiddies wirklich versuchen und müsstest hier nicht über non-reale Theorien spekulieren...

gibt ja auch zahlen dazu:
http://www.rootforum.org/forum/viewtopi ... 25#p268484

also 14 statt 20 ernsthafte angriffe durch portverlegung.

[buddaaa]

Nachschlag:

http://www.ccc.de/faq/security

Den Chaos Computer Club sollte jeder kennen. Volker Birk, der unter anderem auch schon die "Personal Firewalls" AK IP Filter unter die Lupe genommen war quasi mal mein Nachbar. Seine Arbeiten und Vortträge sofern ich dazu gekommen bin habe Ich bisher mit sehr viel Interesse verfolgt und studiert.

Das sollte jeder andere, der einen IP Blocker als Schutz und für Sicher hält auch tun.

emmm, nur um loszuwerden das Du einen nachbarn vom ccc hattest gibst Du hier einen link zu pfws auf windows desktops zum besten? :) ich denke die unterschiede zu einem linux-server kennst Du auch.

und der gute bringt ja auch noch den klassiker:

In keinem Fall wird durch das einfache installieren von Software die Sicherheit eines Systems erhöht, Sicherheit erfordert immer ein Konzept.

herrlich :)

[buddaaa]

Mir ist der Sinn Deiner Argumentation nicht ganz klar.
Mir liet viel daran andere Leute vor trügersicher Sicherheit und Irrtümer zu bewahren.
Dir scheint mehr an Provokation zu liegen.

ok, dann zeig mir doch mal ein posting von Dir mit einer empfehlung, mit der ein debian-admin vor einem halben jahr seine kiste nicht sofort geknackt bekommen haette. meine beiden tips dazu kennst Du.

Mag vielleicht sein, dass dir das Worte verdrehen liegt. Wenn aber Deine Intension nicht die des Trollen ist wäre ja vielleicht eine Mitarbeit in diesem Artikel:
http://www.rootforum.org/wiki/howto/all ... sicherheit
denkbar, dann kannst Du die eingesetzte Energie zielgerichtet umsetzen und uns von Deiner Kenntnis überzeugen.

Du meinst den: http://www.rootforum.org/wiki/security/allgemein ?

also in wikipedia soll man die diskussion auf der diskussion-seite fuehren und nicht im artikel. was wuerde denn passieren wenn ich port-verlegung und iptables in den artikel reinschreibe? ein ewiges hin und her.

und da ist ja auch snort, kennste den hier:
http://www.heise.de/security/Luecke-in- ... dung/85557

und das wird nicht der letzte remote exploit fuer snort sein weil snort ewig komplex ist und jede menge code durchlaufen wird um die packete zu analysieren. iptables schaut sich erstmal nur 2*32bit und 2*16bit an. da kann man nicht viel falsch machen und schadcode passt auch keiner rein.

Wenn da aber von Dir nicht mehr ausser IPTables kommt um den ssh abzusichern, brauche wir keine weitere Diskussion mehr führen.

jetzt sag doch endlich mal wie Du die kiste absichen wuerdest! in http://www.rootforum.org/wiki/security/allgemein find ich nix sinnvolles dazu.

Dann bist und bleibst Du schlicht weg ein Troll vor dessen falschen und gefährlichen Ansichten man andere nur dringend warnen kann.

jetzt zeig mir doch endlich das iptables als reiner packetfilter gefaehrlich ist. los, nur ein remote exploit. iptables hat doch diese schlimme historie ;)

Diskussions Ende.

(Ich schätze mal, dass Du es nicht nötig hast da mit zu machen das Trollen aber weiter vor ziehst.)

ich kann die abschnitte uever port-verlegung und iptables gerne anpassen, habe aber das dumpfe gefuehl, dass Du es wieder rueckgaengig machen wuerdest ;)

[buddaaa]

hast Du nicht oben geschrieben, dass Dein system erst mit 2 minuten verzug anspringt? mehr brauch ich doch nicht wissen. ansonsten kannst Du ja mal ross und reiter benennen, ich hab wirklich nicht den hauch einer ahnung was Du da benutzt weil Du's immer nur umschreibst.

Falsch, bei einer erkannten Attacke erfolgt die Alarmierung mit einem Zeitversatz bis zu 2 Minuten.
Bei einem erkannten Einbruch reagiert das System sofort.

ja und wie wird der einbruch denn erkannt. red doch mal tacheles. der boese kommt ueber einen remote exploit in ssh auf Deine kiste, und dann?

Die URL zu einem meiner Server ist bekannt. Du hast die Fähigkeit und das Know How?

ne, spielt das irgendeine rolle? kommst Du bei mir rein wenn ich Dir meine IP nenne?

Eine Hürde gibt es aber.
SSH lauscht nicht auf eine öffentlich bekannten IP. ;-)

ja noch ein freund von security by obscurity, willkommen im club. Dir ist aber schon klar, dass dies nur eine truegrische und gefaehrliche sicherheit ist weil man mit nmap ratzfatz alle IPs eines providers abklappern kann :)

herrlich, jetzt erklaer mir mal den unterschied warum das verlegen auf eine andere portnummer security by obscurity ist und auf eine andere IP nicht? :) bin sehr gespannt.

Wir können aber auch gerne gemeinsam an einer durchdachten und guten Grundabsicherung eines Rootservers arbeiten und es hier als Dokument veröffentlichen.
Basierend auf minimalen Einsatz von Software und Scripten, bei max. Absicherung.
Die Ergebnisse wissenschaftlich fundiert erarbeitet und entsprechend bewertet.
Also auf eine fruchtbare Zusammenarbeit.

hab ich im prinzip nichts dagegen, nur muessen wir uns vorher einig werden ;)

[buddaaa]

Wiviel stehts jetzt eigentlich ? :D

ich wuerd sagen 3:0 fuer mich weil Du immer noch keinen remote exploit fuer iptables als packetfilter gebracht hast, mittlerweile zu den 2 von ssh noch der eine von snort dazugekommen ist.

[buddaaa]

hab ich im prinzip nichts dagegen, nur muessen wir uns vorher einig werden ;)

Tja, also dann auf Zeige mir den Inhalt der Datei:

/buddaaa/has/hacked/me/notice-for-buddaaa.txt

Erläutere genau, wie Du vor gegangen bist.
Und zwar so, dass jeder in der Lage ist, genau das nach zu machen.
Wir sind uns doch schon einig.
Das nenne Ich eine wissenschaftliche Arbeit.
Eine Behauptung aufstellen,
eine Lösung dazu finden und die Lösung beweisen.

Dann Zeige ich Dir, wie man eine aktuelle IPTables Version noch immer mit einer gekonnten DDos zum überlaufen bring und damit ggf. Schadcode einschleusst.

Du misst hier irgendwie mit zweierlei mass. Du hast in einem Deiner postings mehrfach mit der schlimmen historie von iptables argumentiert und damit Du dafuer endlich einen einzigen beweis lieferst muss ich Deine kiste knacken, mich damit strafbar machen, mich hier im forum stellen und die methode offenlegen (dafuer nehmen andere geld ;).

schick doch einfach einen einzigen link zu einer schwachstelle in iptables als normaler packetfilter. das kann doch nicht zuviel verlangt sein.

Aber zumindest auch in der aktuellen Versionen mit einer gekonnten Dos Attacke auf einen gefilterten Port, den Server mit wenig Aufwand lahm legt.
Und zwar so, dass Du kaum in der Lage bist, genau diese Attacken raus zu bekommen bzw. nachzuweisen.
Diese Lücken, nachweisbar wie Deine 2 0Day Exploits über das changelog von IPTables. min. 4 mal in den letzten 6 Jahren vorhanden.

ja schoene behauptung, mach mal genauere angaben.

Nur mit einem Unterschied, dass die letzte bekannte sshd Lücke nicht binnen weniger Sekunden ausgenutzt werden konnte, den Gegenbeweis lieferst Du mir bitte noch nach.

http://www.securityfocus.com/bid/5093/discuss

und bei der debian-geschichte stehts in dem heise-link.

Genau so detailiert, wie Du beschreibst, wie Du auf mein System gekommen bist und den Inhalt der genannten Datei hier veröffentlicht hast.
Die alten Versionen von IPTables liessen sich sehr simple mit gefälschten Packeten und einem Überfluten von Paketen abschiessen bzw. die Betroffene System mit sich selber beschäftigen lassen.
Dafür war weder eine besondere Anbindung > 1 Mbit, geschweigedenn ein besonderer Rechner (ein 2,4 GHz Celeron und 512 MB Ram reichten für mehrere Systeme) , notwendig.
Jeder der Weiss, wie man syncookies versendet, könnte eine alte iptables Version attackieren und den Server uasser gefecht setzen.

dos ist noch kein remote exploit, ansonsten: gib doch mal einen beleg dazu.

Ich habe nie behauptet, dass der sshd auf nur eine IP horchen zu lassen sicherer sei. Wie kommst Du darauf?
Wo habe ich das behauptet?

da (alter quote):

Eine Hürde gibt es aber.
SSH lauscht nicht auf eine öffentlich bekannten IP. ;-)
Ist aber öffentlich und über Port 22 erreichbar. Wenn Du willst, lasse ich ssh auf * wieder lauschen sollst ja auch eine realistische Chance haben.

(ende alter quote)

Wird Zeit, dass Du Dein Können unter Beweis stellst.
So lange Du es nicht nachweisen kannst, dass der sshd Lücken hat, nehme Ich dir auch nicht ab, dass Du es nachweisen kannst, dass iptables keine hat bzw. sicherer ist.

ja was ist das denn, Dein fax ist staerker als mein handy ;) wenn ich hier einen 0-day-exploit fuer openssh im wert von x-tausend euro poste glaubst Du mir, das iptables sicher ist?' wo ist denn bitte der zusammenhang? ist das "wissenschaftlich arbeiten" :)

Und so lange glaube Ich Dir auch einfach nicht.
Was im übrigen dann andere besser auch nicht tun.

genau, glaubt nur leuten die 0-day-remote-exploits fuer openssh posten! keine macht fuer niemand! :)

Folgendes Erwarte ich nun von Dir:
1. Liefere den Nachweis, dass die letzte SSHD Lücke binnen weniger Sekunden ausgenutzt werden konnte.
2. Den Inhalt der bei mir hinterlegten Datei.
3. Das genau vorgehen, des oben notwendigen Einbruches, damit man es unter Laborbedingungen reproduzieren kann.

Du hast noch keinen Punkt erreicht.
Du gehst also nicht als Sieger aus dem Ring.
0:0
Hast Du min. eine der oben genanten Aufgaben ernstzunehmend erledigt, Also Punkt 2 oder 3, dann erkenne Ich Dir den Titel des Siegers an.

also wir diskutieren hier wochenlang rum und Du erkennst mich erst als sieger an, wenn ich irgendwas mache, was nichts mit der diskussion zu tun hat und strafbar ist? faellt Dir da nicht selber was auf? genau, damit hast Du Dich aus der diskussion inhaltlich schon verabschiedet, stehst am rand und willst aber nur verloren haben wenn die hoelle gefriert.

Wie sehen es die andere? Hat er dann gewonnen?

oh wie suess, jetzt sollen Dir die anderen beispringen :) ich glaube fuer die wissenschaftliche methode "das iptables sicherer ist als openssh wenn ein foren-mitglied einem anderen den server knackt" findest Du nicht viel zustimmung :)

Punkt 1 ist nur eine Fleissarbeit, die aber schon zeigt, dass es dir um Sicherheit und nicht ums Trollen geht.
Wovon Ich nach wie vor Überzeugt bin, dass Du trollst.

siehe oben

Der Beweis,
Du redest davon, dass man Debian in wenigen Sekunden per SSH Exploit angreifen konnte?
Falsch der SSHD war sicher. Es war möglich den sshd auf Debian lahm zu legen.
http://www.heise.de/security/Update-fue ... ung/116198
Also das gleiche im Prinzip, wie mit iptables mit dem Unterschied, dass man hier den ganzen Server lahm legt.

sorry, von dem problem war nie die rede.

Was war der andere Exploit von ssh?
Achja, die nicht mehr ganz so zufälligen Zufallszahlen beim generieren des ssh keys.

genau, das:
http://www.heise.de/security/Schwache-K ... ung/107808

heise.de: "Denn die Chancen sind vergleichsweise gut, allein durch Ausprobieren einen Schlüssel für einen Root-Zugang zu erraten."

also kein einfacher DOS wie bei Deiner angeblichen iptables-schwachstelle zu der es immer noch keinen link gibt.

und weil Du anscheinend zu leicht durcheinander kommst mit den ganzen exploits und auch nicht in alten postings nachschauen magst, hier nochmal:
http://www.securityfocus.com/bid/5093

Gute Nacht. Du hast Deine Aufgabe bekommen.

schaumal, ich hab noch zwei exploits fuer snort gefunden:
http://www.cve.mitre.org/cgi-bin/cvenam ... -2003-0209
http://www.cve.mitre.org/cgi-bin/cvenam ... -2003-0033

5:0 ;)

[Joe User]

So, damit endlich wieder Ruhe einkehrt: Bei den mitlerweile bekannten sicherheitskritischen Design-Fehlern in TCP selbst ist es eh in wenigen Monaten egal, ob die darüberliegenden Softwareschichten anfällig sind oder nicht. Da helfen dann weder IPTables noch SSH-Key-Auth oder sonstiger Schnick-Schnack, denn die effektiven Angriffe werden darunter, zum Teil bereits auf Hardwareebene und somit nahezu transparent durchgeführt. Die ersten Labortests waren ja bereits erfolgreich, also gibt es auch recht schnell die ersten "Studien am lebenden Objekt"...

[EdRoxter]

Hast du mal ein paar Quellen dazu?

[Joe User]

Auf dem TCP-DoS Problem lässt sich bereits aufbauen und es gibt weitere Design-Fehler in TCP und Co über die sich bisher nur sehr wenige Spezialisten Gedanken machen und deren Erkenntnisse wir in den nächsten Jahren nach und nach erfahren werden. Langsam wird "back to the roots" auch im Security-Sektor begriffen und an den Ursachen gearbeitet, statt nur die Phänomene zu bekämpfen...

[buddaaa]

Hast jetzt aber lange gebraucht Arnim.

boar, jetzt musst Du Dich schon daran hochziehen das ich zwischen den jahren keine zeit/lust hatte zu Deiner heissen luft mal fakten einzufordern ;)

Hast Du den Artikel um die ssh Problematik auch gelesen?

welchen von den dreien meinst Du denn?

Bleiben wir doch mal beim Inhalt von:
/buddaaa/has/hacked/me/notice-for-buddaaa.txt

also ich hatte in meinem letzten posting erklaert das das nix mit dem thema zu tun hat, ich mich strafbar machen wuerde und andere leute fuer so eine diesntleistung echt viel geld nehmen. was davon verstehst Du nicht?

aber loesen wir es mal einfach: ich kann Deinen server nicht knacken, wirklich nicht, ich schwoers. aber in einem endlichen zeitraum wird wieder eine sicherheitsluecke in openssh gefunden werden. und dann ist es besser seinen port verlegt zu haben (meinetwegen auch auf eine andere IP wenn einem diese obskure methode lieber ist) und iptables davor zu haben.

Du kennst ja noch mehr Angriffsmöglichkeiten .....

ey, was Du Dir alles zusammenreimst :)

PS. wo bleibt denn Dein Nachweis, dass IPTables "sicherer" ist als ssh bzw in Kombination die sicherheit erhöht?

iptables als reine packetfilter ist bisher 100% sicher, es gab dafuer noch nie einen remote-exploit (obwohl Du das immer behauptest kam ja noch kein beleg von Dir). fuer openssh schon 2. qed.

Ich mach mir das ganz ganz einfach.
Beide Dienste sind aus meiner Sicht unsicher.
Ein Einfallstor kann ich aber sehr gut im Blick behalten.

Du machst dabei den grossen fehler jede software als gleich unsicher zu betrachten. iptables als reiner packetfilter schaut sich zwei 32bit zahlen (IPs) , zwei 16bit zahlen (ports) und noch ein paar flag-bits an. es ist praktisch unmoeglich damit eine payload zu transportieren. openssh ist dagegen ungleich komplexer. verschiedene authentifikations-moeglichkeiten, abhaengigkeit von /dev/random, komplexe krypto-algorithmen, ... mach mal "ssh -vv x.x.x.x", dann siehst Du was ich meine und zwei luecken sind ja schon aufgetaucht.

[buddaaa]

So, damit endlich wieder Ruhe einkehrt: Bei den mitlerweile bekannten sicherheitskritischen Design-Fehlern in TCP selbst ist es eh in wenigen Monaten egal, ob die darüberliegenden Softwareschichten anfällig sind oder nicht. Da helfen dann weder IPTables noch SSH-Key-Auth oder sonstiger Schnick-Schnack, denn die effektiven Angriffe werden darunter, zum Teil bereits auf Hardwareebene und somit nahezu transparent durchgeführt. Die ersten Labortests waren ja bereits erfolgreich, also gibt es auch recht schnell die ersten "Studien am lebenden Objekt"...

was hilft das hier im thread? da gibt's irgendwann eine loesung fuer und dann wird es immer noch ssh und iptables geben. ausserdem waere mir neu das da mehr geht als DOS, wir reden von exploits. also ich jedenfalls von ssh- und snort-exploits, fuer iptables als packetfilter findet sich ja keiner ;)

aber endlich mal ein neues universal-argument was man in jede diskussion werfen kann, wie "massnahme xy ist noch kein sicherheits-konzept" und "Du kannst meinen server nicht kancken, Du kannst meinen server nicht kancken, Du kannst meinen server nicht kancken, ..." ;)

[Joe User]

So, damit endlich wieder Ruhe einkehrt: Bei den mitlerweile bekannten sicherheitskritischen Design-Fehlern in TCP selbst ist es eh in wenigen Monaten egal, ob die darüberliegenden Softwareschichten anfällig sind oder nicht. Da helfen dann weder IPTables noch SSH-Key-Auth oder sonstiger Schnick-Schnack, denn die effektiven Angriffe werden darunter, zum Teil bereits auf Hardwareebene und somit nahezu transparent durchgeführt. Die ersten Labortests waren ja bereits erfolgreich, also gibt es auch recht schnell die ersten "Studien am lebenden Objekt"...

was hilft das hier im thread? da gibt's irgendwann eine loesung fuer und dann wird es immer noch ssh und iptables geben. ausserdem waere mir neu das da mehr geht als DOS, wir reden von exploits.

Es gibt mehr Bugs in TCP als nur diesen und es wird auch noch einige Exploits für diese Bugs geben. Es interessieren sich ja erst seit kurzem ein paar Leute für diese Problematik, aber das wird sich in den nächsten Monaten und Jahren ändern. Dann werden wir Exploits sehen, von denen wir heute nur träumen können. Und selbst der aktuelle TCP-DoS-Bug lässt sich garantiert für mehr als nur DoS nutzen, andernfalls würden nicht alle TCP-Stack-Hersteller koordiniert an einem Strang ziehen. Nur weil etwas nicht im Heise-Ticker auftaucht, heisst es noch längst nicht, dass es nicht existiert. Manche Dinge muss/soll/will die breite Masse gar nicht wissen...

aber endlich mal ein neues universal-argument was man in jede diskussion werfen kann

Falsch, es ist leider kein Universalargument, sondern bittere Realität, welche Du und viele Andere gar nicht begreifen können/wollen...


Schonmal darüber nachgedacht, weshalb das ABS Deines Autos und alle anderen sicherheitskritischen Systeme nicht per TCP und Co kommunizieren (dürfen)?

[buddaaa]

Es gibt mehr Bugs in TCP als nur diesen und es wird auch noch einige Exploits für diese Bugs geben. Es interessieren sich ja erst seit kurzem ein paar Leute für diese Problematik, aber das wird sich in den nächsten Monaten und Jahren ändern. Dann werden wir Exploits sehen, von denen wir heute nur träumen können. Und selbst der aktuelle TCP-DoS-Bug lässt sich garantiert für mehr als nur DoS nutzen, andernfalls würden nicht alle TCP-Stack-Hersteller koordiniert an einem Strang ziehen.

es hat zwar nichts mit dem thread hier zu tun aber: quatsch, mit dem bug kann man jedes system mit einem offenen port lahmlegen, und das soll nicht reichen um ihn moeglichst schnell zu fixen? und die koordinierung ist sicherlich sinnvoll das sich linux und windows nachher noch unterhalten koennen.

Nur weil etwas nicht im Heise-Ticker auftaucht, heisst es noch längst nicht, dass es nicht existiert. Manche Dinge muss/soll/will die breite Masse gar nicht wissen...

ach, und Du weisst es, darfst es aber mal wieder nicht sagen :)

Falsch, es ist leider kein Universalargument, sondern bittere Realität, welche Du und viele Andere gar nicht begreifen können/wollen...

ok, wenn es kein universalargument ist dann kannst Du mir ja erklaeren was es mit security by obscurity und iptables auf servern zu tun hat? na? bin sehr gespannt.

auf ein argument passend zum thread wart ich ja immer noch: wie die profis an iptables vorbeikommen mit einem root-server angemessenen aufwand. da hast Du leider vergessen zu antworten:

http://www.rootforum.org/forum/viewtopi ... 75#p308358

Schonmal darüber nachgedacht, weshalb das ABS Deines Autos und alle anderen sicherheitskritischen Systeme nicht per TCP und Co kommunizieren (dürfen)?

klar, weil zwischen ABS-sensor und steuerung kein aufgeblasenes routing-protokoll mit 2^32 moeglichen adressen noetig ist sondern eine schnelle direktverbindung? :)

[buddaaa]

Interessant in diesem Zusammenhang ist allerdings auch, dass ein nicht unbedeutender Elektronik Konzern seit Anfang 2007 eifrig an einer neuen Implementierung von TCP und IP
forscht. Es handelt sich zwar offiziell um eine Optimierung im Netzsegment der mobilen Telekommunikation, nachdem aber das Entwicklerteam mitte 2008 plötzlich verdoppelt wurde. Und das, ohne dass es bei der Projektplanung sowie Projektfortschritt erkennbare Gründe gegeben hätte. Machen diese "Gerüchte" durchaus Sinn.

sorry, macht doch einen eigenen thread fuer TCP-probleme auf und hier bleiben wir bei security by obscurity.

ich warte noch auf ein paar antworten von Dir, insbesondere warum port-verlegen auf eine andere portnummer security by obscurity ist aber auf eine andere IP nicht :) oder doch mal eine iptables-schwachstelle mit ner anderen quelle als anekdoten?

[Joe User]

ach, und Du weisst es, darfst es aber mal wieder nicht sagen :)

Schonmal was von NDAs, Verschwiegenheitserklärungen oder Geschäftsgeheimnissen gehört? Es gibt nunmal Dinge, die nicht jeder wissen darf...

[Joe User]

Es gibt mehr Bugs in TCP als nur diesen und es wird auch noch einige Exploits für diese Bugs geben. Es interessieren sich ja erst seit kurzem ein paar Leute für diese Problematik, aber das wird sich in den nächsten Monaten und Jahren ändern. Dann werden wir Exploits sehen, von denen wir heute nur träumen können. Und selbst der aktuelle TCP-DoS-Bug lässt sich garantiert für mehr als nur DoS nutzen, andernfalls würden nicht alle TCP-Stack-Hersteller koordiniert an einem Strang ziehen.

es hat zwar nichts mit dem thread hier zu tun aber: quatsch, mit dem bug kann man jedes system mit einem offenen port lahmlegen, und das soll nicht reichen um ihn moeglichst schnell zu fixen? und die koordinierung ist sicherlich sinnvoll das sich linux und windows nachher noch unterhalten koennen.

Was hat das nun mit linux vs windows zu tun? Du hast die Problematik nicht verstanden oder willst sie nicht verstehen...

Falsch, es ist leider kein Universalargument, sondern bittere Realität, welche Du und viele Andere gar nicht begreifen können/wollen...

ok, wenn es kein universalargument ist dann kannst Du mir ja erklaeren was es mit security by obscurity und iptables auf servern zu tun hat? na? bin sehr gespannt.

Ganz einfach: Du fühlst Dich dank IPTables sicher(er), obwohl Du es definitiv nicht bist -> s-b-o

auf ein argument passend zum thread wart ich ja immer noch: wie die profis an iptables vorbeikommen mit einem root-server angemessenen aufwand. da hast Du leider vergessen zu antworten:

Indem man schlicht unterhalb von IPTables ansetzt, fertig. Wie das geht, kannst Du in ein paar Jahren bei Heise und Co nachlesen...

Schonmal darüber nachgedacht, weshalb das ABS Deines Autos und alle anderen sicherheitskritischen Systeme nicht per TCP und Co kommunizieren (dürfen)?

klar, weil zwischen ABS-sensor und steuerung kein aufgeblasenes routing-protokoll mit 2^32 moeglichen adressen noetig ist sondern eine schnelle direktverbindung? :)

Falsch.

[buddaaa]

ach, und Du weisst es, darfst es aber mal wieder nicht sagen :)

Schonmal was von NDAs, Verschwiegenheitserklärungen oder Geschäftsgeheimnissen gehört? Es gibt nunmal Dinge, die nicht jeder wissen darf...

und TCP-exploits sind also ein geschaeftgeheimnis von Dir? oder hast Du ein NDA dazu unterschrieben? nur mal interessehalber weil ich kann mir irgendwie nicht vorstellen das jemand, bei dem das der fall ist, hier im forum einen komplett anderen thread versucht auf das thema zu lenken um sich dann hinter sein NDA zurueckzuziehen :)

[buddaaa]

Es gibt mehr Bugs in TCP als nur diesen und es wird auch noch einige Exploits für diese Bugs geben. Es interessieren sich ja erst seit kurzem ein paar Leute für diese Problematik, aber das wird sich in den nächsten Monaten und Jahren ändern. Dann werden wir Exploits sehen, von denen wir heute nur träumen können. Und selbst der aktuelle TCP-DoS-Bug lässt sich garantiert für mehr als nur DoS nutzen, andernfalls würden nicht alle TCP-Stack-Hersteller koordiniert an einem Strang ziehen.

es hat zwar nichts mit dem thread hier zu tun aber: quatsch, mit dem bug kann man jedes system mit einem offenen port lahmlegen, und das soll nicht reichen um ihn moeglichst schnell zu fixen? und die koordinierung ist sicherlich sinnvoll das sich linux und windows nachher noch unterhalten koennen.

Was hat das nun mit linux vs windows zu tun? Du hast die Problematik nicht verstanden oder willst sie nicht verstehen...

ok, ich frag nochmal direkt: ist ein bug mit dem man jedes TCP-system mit offenem port lahmlegen nicht grund genug um schnell und koordiniert an einer loesung zu suchen? und die loesung interoprabel zu testen das nach dem grossen patchday verschiedene betriebssysteme noch miteinander klarkommen?

und wenn Du mehr fakten zu dem thema kennst und nur wegen NDA und geschaeftsgeheimnis nicht mehr verraten darfst, warum spekulierst Du dann eigentlich: "Und selbst der aktuelle TCP-DoS-Bug lässt sich garantiert für mehr als nur DoS nutzen, andernfalls würden nicht alle TCP-Stack-Hersteller koordiniert an einem Strang ziehen." :)

Falsch, es ist leider kein Universalargument, sondern bittere Realität, welche Du und viele Andere gar nicht begreifen können/wollen...

ok, wenn es kein universalargument ist dann kannst Du mir ja erklaeren was es mit security by obscurity und iptables auf servern zu tun hat? na? bin sehr gespannt.

Ganz einfach: Du fühlst Dich dank IPTables sicher(er), obwohl Du es definitiv nicht bist -> s-b-o

... wegen der kommenden TCP-exploits. dann trifft das auch auf intrusion detection, patch managment, sichere passwoerter, verschluesselung und alles andere zu ausser seinen server abzuschalten. es ist also doch ein universal-argument.

auf ein argument passend zum thread wart ich ja immer noch: wie die profis an iptables vorbeikommen mit einem root-server angemessenen aufwand. da hast Du leider vergessen zu antworten:

Indem man schlicht unterhalb von IPTables ansetzt, fertig. Wie das geht, kannst Du in ein paar Jahren bei Heise und Co nachlesen...

mal wieder reine spekulation, aber alles was ich bisher zu den neuen TCP-schwachstellen gelesen habe setzt mindestens einen 3-way-handshake vorraus. zu dem kommt es aber nicht wenn iptables alle pakete an den port verwirft.

Schonmal darüber nachgedacht, weshalb das ABS Deines Autos und alle anderen sicherheitskritischen Systeme nicht per TCP und Co kommunizieren (dürfen)?

klar, weil zwischen ABS-sensor und steuerung kein aufgeblasenes routing-protokoll mit 2^32 moeglichen adressen noetig ist sondern eine schnelle direktverbindung? :)

Falsch.

ok, selbst wenn das jemand basteln wuerde, wuerde er aus anderen gruenden eher UDP als TCP fuers ABS nehmen. was bringt die wiederhohlte uebertragung nach einem timeout bei TCP wenn der wagen schon am baum haengt.

[Joe User]

ach, und Du weisst es, darfst es aber mal wieder nicht sagen :)

Schonmal was von NDAs, Verschwiegenheitserklärungen oder Geschäftsgeheimnissen gehört? Es gibt nunmal Dinge, die nicht jeder wissen darf...

und TCP-exploits sind also ein geschaeftgeheimnis von Dir? oder hast Du ein NDA dazu unterschrieben? nur mal interessehalber weil ich kann mir irgendwie nicht vorstellen das jemand, bei dem das der fall ist, hier im forum einen komplett anderen thread versucht auf das thema zu lenken um sich dann hinter sein NDA zurueckzuziehen :)

In diesem speziellen Fall greifen mehrere allgemeine Verschwiegenheitserklärungen zu mehreren Geschäftspartnern. Soetwas ist in vielen Branchen üblich und wird selbst dann eingehalten, wenn es nicht schriftlich vereinbart wurde. Schliesslich will man keine aktuellen oder zukünftigen Geschäftspartner verlieren...

[buddaaa]

In diesem speziellen Fall greifen mehrere allgemeine Verschwiegenheitserklärungen zu mehreren Geschäftspartnern. Soetwas ist in vielen Branchen üblich und wird selbst dann eingehalten, wenn es nicht schriftlich vereinbart wurde. Schliesslich will man keine aktuellen oder zukünftigen Geschäftspartner verlieren...

ja und warum faengst Du das thema dann ueberhaupt zusammenhangslos an?