RootForum Community

buddaaa wrote:

Joe User wrote:

buddaaa wrote:

Joe User wrote: 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?

Das unkoordinierte Fixen des von Dir angesprochenen Bugs führt nicht zu Inkompatibilitäten zwischen den Systemen, andernfalls könnte heute keines der millionen noch ungefixten System mit den gefixten kommunizieren. Dies kann also nicht der Grund für die Zusammenarbeit gewesen sein...

buddaaa wrote:und wenn Du mehr fakten zu dem thema kennst und nur wegen NDA und geschaeftsgeheimnis nicht mehr verraten darfst, warum spekulierst Du dann eigentlich:

Vielleicht, weil ich nur spekulativ überhaupt öffentlich darüber sprechen/schreiben darf? Manche Dinge sind halt komplexer als Du Dir vorstellen kannst...

buddaaa wrote:

Joe User wrote:

buddaaa wrote: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.

Nochmal: Du wirst erst in ein paar Jahren nachlesen können, worüber ich heute nur "spekulieren" darf.

buddaaa wrote:

Joe User wrote:

buddaaa wrote:

Joe User wrote: 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.

Das Falsch bezog sich auf die Direktverbindung, die gibt es beim http://en.wikipedia.org/wiki/Controller_Area_Network nämlich nicht...

buddaaa wrote:

Joe User wrote: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?

Vielleicht, um Dich mal zum Nachdenken über Dein Liebesverhältnis zu IPTables zu bewegen?

Joe User wrote: Das unkoordinierte Fixen des von Dir angesprochenen Bugs führt nicht zu Inkompatibilitäten zwischen den Systemen, andernfalls könnte heute keines der millionen noch ungefixten System mit den gefixten kommunizieren. Dies kann also nicht der Grund für die Zusammenarbeit gewesen sein...

... ja dann lassen wir das thema doch wenn es eh immer damit endet das Du nix sagen darfst :)

Joe User wrote:

buddaaa wrote:und wenn Du mehr fakten zu dem thema kennst und nur wegen NDA und geschaeftsgeheimnis nicht mehr verraten darfst, warum spekulierst Du dann eigentlich:

Vielleicht, weil ich nur spekulativ überhaupt öffentlich darüber sprechen/schreiben darf?

stellt sich wieder die frage warum Du zusammenhangslos mit dem thema angefangen hast.

Joe User wrote: Manche Dinge sind halt komplexer als Du Dir vorstellen kannst...

woher weisst Du denn was ich mir vorstellen kann? :)

Joe User wrote:

buddaaa wrote: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.

Nochmal: Du wirst erst in ein paar Jahren nachlesen können, worüber ich heute nur "spekulieren" darf.

dann waeren wir aber bei schwachstellen bei denen der IP-header eines einzelnen pakets zum ausnutzen reicht. ich glaub Dir nicht "und in ein paar jahren sehen wir weiter."

Joe User wrote: Das Falsch bezog sich auf die Direktverbindung, die gibt es beim http://en.wikipedia.org/wiki/Controller_Area_Network nämlich nicht...

dann sind wir uns ja einige das es andere gruende als sicherheitsbedenken gibt um TCP nicht fuer ABS einzusetzen.

Joe User wrote:

buddaaa wrote:

Joe User wrote: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?

Vielleicht, um Dich mal zum Nachdenken über Dein Liebesverhältnis zu IPTables zu bewegen?

ja wenn die beiden themen irgendwas miteinander zu tun haetten koennte ich das ja nachvollziehen :)

Q: "ist es sinnvoll iptables auf einem server zu installieren?"
A: "nein, weil in ein paar monaten/jahren werden ein paar TCP-schwachstellen veroeffentlicht!!"

??? muss ich das verstehen?

hey matzewe01,

Du bist ja auch noch da, ist der mittlerweile der unterschied zwischen ssh-verlagern auf einen andere port-nummer und eine andere IP eingefallen? :)

matzewe01 wrote: sag mal, müsste eigentlich das jemand wie Buddaaa nicht von Haus aus wissen?
Ich bin jetzt seit zig Jahen (länger als Du vermutlich) im Geschäft und ich kann mich eigentlich nicht daran erinnern, dass jemals in einem meiner Verträge der Passus der Geheimhaltung gefehlt hätte. Ich wüsste ad hoc auch niemand, der solche sensiblen internas ausplaudern dürfte.

Man könnte ja nun spekulieren....

Könnte es sein, dass der Buddaaa mit der Thematik beruflich nichts zu tun hat und in solchen Bereichen also auch keine Erfahrng oder gar spezielle Qualifikation erworben hat.
Denn wäre dem der Fall, wüsste er wie es in solchen Gefilden läuft, und wie schnell man als *Petze* in dieser Branche keinen Job mehr bekommt.
Wie so oft ist die Welt sehr klein.

schenkelklopf :) es ist echt lustig das Du zum thema nichts mehr zu sagen hast und regelmaessig auf die persoenliche schiene wechselst. und die vorstellung das ich irgendeinen job nicht kriegen wuerde weil ich mich in einem forum irgendwelchen pseudonymen ihre geheimnistuerei nicht abkaufe ist gelinde gesagt laecherlich :)

also was mich echt treffen wuerde waere infos ueber einen remote exploit von iptables als packetfilter, egal wie alt.

aber zurueck zum thema:
- es gab bisher keine exploits fuer iptables als packetfilter und es ist extrem unwahrscheinlich das es je welche geben wird, deswegen kann man es beruhigt auf seinem server installieren (vorsicht ist nur bei den exotischen modulen geboten)
- den ssh-port zu verlegen macht ein system sicherer (und das ist noetig weil fuer ssh gab es schon 2 remote exploits)
- irgendwelche TCP-schwachstellen aendern daran nichts

Hmmm - wurde nicht gesagt dass IPTables SSH sicherer macht ?

Will nur sagen - phpMyAdmin nicht direkt in den Webroot zu installieren sondern in /gut_versteckt/ macht phpMyAdmin selbst und das System nicht sicherer, denn schlechte Software wird durch den Versuch sie zu verstecken auch nicht besser.
Wenn nun die jeweilige Software unsicher ist, hilft Port verbiegen und Firewall auch nichts, denn am eigentlichen Problem ändert sich nichts.
Und mit fail2ban und ähnlichen Systemen die nach 2-3 Versuchen eine IP sperren, dass mag helfen gegen jemanden der blind gesamte IP Ranges scannt von einem gehackten Server, kommt der Scan aus einem Bot Netz mit ein paar tausend Rechnern kann jeder einzelne Bot 2-3 Ports übernehmen und schon bringt fail2ban + IP Sperre nichts mehr.

Wenn ich die Tür von meinem Auto nicht abschließe, dafür das Auto aber nicht im Parkhaus sondern hinter einem Werbeplakat parke damit es niemand sieht, bekomme ich trotzdem nichts von meiner Versicherung wenn das Auto weg ist.

Auf SSH bezogen, wenn Upgrades zeitnah eingespielt werden braucht man keinen Port verbiegen, falls nicht hat man ohnehin andere Probleme als eine ausgefeilte Firewall Konfiguration. Die gezeigten Sicherheitslücken von SSH - ob Standard Port oder nicht - funktionieren trotzdem.

rudelgurke wrote:Hmmm - wurde nicht gesagt dass IPTables SSH sicherer macht ?

nein, hier im forum macht iptables ein system sogar unsicherer. als beleg dient eine luecke in modul fuer SCTP (schonmal gehoert? ich auch nicht):
http://www.rootforum.org/forum/viewtopi ... 77&t=46097

rudelgurke wrote: Will nur sagen - phpMyAdmin nicht direkt in den Webroot zu installieren sondern in /gut_versteckt/ macht phpMyAdmin selbst und das System nicht sicherer, denn schlechte Software wird durch den Versuch sie zu verstecken auch nicht besser.

natuerlich macht es das system sicherer. wenn ein script-kind einen unbekannten exploit fuer eine applikation hat, glaubst Du es knackt mit seinen resourcen 100 server oder versucht genau bei Deiner kiste /gut_versteckt/ zu finden? dazu muesste es mindestens eine zweite schwachstelle ausnutzen um die applikation ueberhaupt zu finden, das lohnt den aufwand nicht.

rudelgurke wrote: Wenn nun die jeweilige Software unsicher ist, hilft Port verbiegen und Firewall auch nichts, denn am eigentlichen Problem ändert sich nichts.

portverlegen reduziert die ernsthaften angriffe in dem beispiel von 20 auf 14:
http://www.rootforum.org/forum/viewtopi ... 25#p268484

ist vielleicht die zeit die Du zum patchen brauchst, oder schaffst Du es immer innerhalb von ein paar tagen? urlaub, krankeit, zero-day, ... ?

und warum soll eine firewall nichts nutzen, wie kommst Du denn vorbei?

rudelgurke wrote: Auf SSH bezogen, wenn Upgrades zeitnah eingespielt werden braucht man keinen Port verbiegen,

falsch, nehmen wir an Du hast einen suse-server und installierst alle patches kanst Du trotzdem davon erwischt werden:
http://www.heise.de/security/Schwache-K ... ung/107808

und es kann mir keiner erzaehlen, dass das jeder durchschnitts-admin mit ubuntu-laptop sofort schnallt. also port verlegen und iptables drauf und zeit schinden.

rudelgurke wrote: Die gezeigten Sicherheitslücken von SSH - ob Standard Port oder nicht - funktionieren trotzdem.

ja, aber 6 von 20 angreifern machen sich nicht die arbeit, siehe oben.

matzewe01 wrote: Buddaaa kam dann mit der Theorie an, dass er mit IPTables z.B. 97 % der Angreifer ausschliessen würde, wenn er die Regeln auf den von seinem Provider lokal eingegrenzten IP Range stellt.

matze hat's nicht so mit den zahlen, 99,997%:
http://www.rootforum.org/forum/viewtopi ... 75#p308284

matzewe01 wrote: Wenn nun einer aus "seiner" unmittelbaren Umgebung, Bekannter aus einem Verein etc. Ihm an den Karren fahren will, ist er immer noch auf gleichem Weg angreifbar.
Würde ein Virus diese Lücke nutzen und durch dessen Verbreitung auch in seinem regionalen Umkreis aufschlagen, hätte er keinen Schutz mehr nach seiner "Theorie".

hurra, selbst matze gibt zu das nur leute aus der region meinen ssh-port angreifen koennen :) woher sie auch immer wissen, das mein iptables so konfiguriert ist. und wenn sie am iptables vorbei sind ist mein opensshd genauso sicher wie jeder andere.

matzewe01 wrote: Als Ergänzung zu Deinem Beispiel bringe ich folgendes:

Das eingrenzen mit IPTables, gleicht in etwa der Absicherung meiner Wohnung, indem ich die Hauseingangstüre so verkleinere, dass nur noch Kinder und Kleinwüchsige ins Haus gelangen können.

ja, matze und die lieben zahlen. die 0,003% die an meinen ssh-port kommen entsprechen eher allen kleinwuechsigen kindern mit einer warze auf der nase :)

matzewe01 wrote: Ich bin weiterhin angreifbar, auch wenn jetzt nicht 2 Leute gleichzeitig ins Haus rennen können.

falsches beispiel, ich hab keine beschraenkung der zugriffsversuche pro zeiteinheit.

matzewe01 wrote: Und wenn Ich mich genau auf diesen Schutz verlasse, habe ich einen fatalen Fehler begangen.

das stimmt, aber ich habe nie behauptet das eine einzige schutzmassnahme ausreicht. im gegensatz zu den befuerwortern von ssh auf port 22 ohne iptables.

matzewe01 wrote: Denn der Einbruch ist nur eine Frage der Zeit. Was jederzeit passieren kann egal aus welcher Quelle.

cooler spruch von jemandem der selber seinen ssh-port auf eine andere IP verlegt hat und sich dann freut das angreifer "keine chance mehr haben" ;)

matzewe01 wrote: Der einzige Fall in dem eine Absicherung durch IPtables berechtigt und anwendbar ist, wäre wenn man mysql auf einen 2. Host Replizieren muss und dieser über eine feste IP kommt. Auch ein Hopp zu mehreren Servern wäre ein denkbares Szenario, in welchem an explizit den Zugriff auf einzelne IPs Reduzieren kann, in deren Einfluss man selbst steht.

da hat er recht, aber 0,003% der moeglichen IPs reicht mir auch an sicherheit.

matzewe01 wrote: -> IP Spoofing mal als möglichen Angriff in die Runde geworfen.

halte ich fuer unrealistisch. funktioniert nur bei udp-diensten wenn der angriff in ein einzelnes paket passt oder wenn das rueckrouting sichergestellt ist, d.h. jemand braeuchte kontrolle ueber die netzwerk-komponenten beim root-server-betrieber.

matzewe01 wrote: Und zusätzlich die Funktions von IPTables als Schutzmechanismus prüfen.

=D>

buddaaa wrote:natuerlich macht es das system sicherer. wenn ein script-kind einen unbekannten exploit fuer eine applikation hat, glaubst Du es knackt mit seinen resourcen 100 server oder versucht genau bei Deiner kiste /gut_versteckt/ zu finden? dazu muesste es mindestens eine zweite schwachstelle ausnutzen um die applikation ueberhaupt zu finden, das lohnt den aufwand nicht.

Scheint als reden wir aneinander vorbei. Der Punkt ist dass, wenn ich unsichere Software einsetze, der Einsatz hier der Knackpunkt ist.

buddaaa wrote:portverlegen reduziert die ernsthaften angriffe in dem beispiel von 20 auf 14:
http://www.rootforum.org/forum/viewtopi ... 25#p268484

Wie mit dem SuSe Beispiel gezeigt wurde, reicht schon 1 ernsthafter Angriff - da kann ich stolz in meine Logs schauen und mich den ganzen Tag freuen über meine tolle Firewall Konfiguration und den verlegten Port - 1 ernsthafter Angriff und schon habe ich ein Problem.
Und wenn wie von ernsthaften Angriffen sprechen, ein verlegter Port hält solche Leute auch kaum auf.

buddaaa wrote:ist vielleicht die zeit die Du zum patchen brauchst, oder schaffst Du es immer innerhalb von ein paar tagen? urlaub, krankeit, zero-day, ... ?

Entweder ich habe einen Server der 24 Stunden am Tag am Netz hängt und übernehme die Verantwortung, oder ich schalte das Ding ab wenn ich den Urlaub fahre oder krank bin.
Wenn ich im Urlaub oder krank oder sonstwie verhindert bin, muss ein anderer fachkundiger Kollege die Administration übernehmen.
Oder bleibt dein Server unbeaufsichtigt wenn du in den Urlaub fährst ?

buddaaa wrote:und es kann mir keiner erzaehlen, dass das jeder durchschnitts-admin mit ubuntu-laptop sofort schnallt. also port verlegen und iptables drauf und zeit schinden.

Dann sollte dieser Durchschnittsadmin seine Zeit wohl eher damit verbringen, sich in die Materie einzuarbeiten als seine Zeit damit zu verklempern nach 5x erfolglosen "selbst ausgesperrt" eine funktionieren Firewall Konfiguration aufgestellt zu haben.
Wenn er dann soweit ist, kann er immer noch eine Pix oder was ihm beliebt davor schalten.

Indem ich via Firewall die IP Range auf die meines Providers begrenze, nun - ich kenne nich alle Kunden meines Providers persönlich, noch kann ich sagen ob deren Rechner wirklich sauber sind und nicht als Bot agieren.

Hier im Forum gibt es bereits eine ordentliche SSH Konfiguration als Beispiel - Key Auth, Root Login abschalten und via AllowUsers weiter eingrenzen.

Mit SELinux / MAC usw. usw. usw. geht's dann weiter - für mich persönlich ist meine Zeit darin besser investiert - wenn du dass anders macht, kein Problem.

rudelgurke wrote:

buddaaa wrote:natuerlich macht es das system sicherer. wenn ein script-kind einen unbekannten exploit fuer eine applikation hat, glaubst Du es knackt mit seinen resourcen 100 server oder versucht genau bei Deiner kiste /gut_versteckt/ zu finden? dazu muesste es mindestens eine zweite schwachstelle ausnutzen um die applikation ueberhaupt zu finden, das lohnt den aufwand nicht.

Scheint als reden wir aneinander vorbei. Der Punkt ist dass, wenn ich unsichere Software einsetze, der Einsatz hier der Knackpunkt ist.

wenn jemand phpmyadmin einsetzt ist das system mit installation in /gut_versteckt auf jeden fall sicherer weil ein angreifer mindestens 2 exploits braucht um das system zu knacken (im vergleich dazu bringt port-verlegen nicht so viel. da reicht weiter der eine exploit fuer den versteckten dienst, es steigt nur der aufwand zum finden per nmap.)

rudelgurke wrote:

buddaaa wrote:portverlegen reduziert die ernsthaften angriffe in dem beispiel von 20 auf 14:
http://www.rootforum.org/forum/viewtopi ... 25#p268484

Wie mit dem SuSe Beispiel gezeigt wurde, reicht schon 1 ernsthafter Angriff - da kann ich stolz in meine Logs schauen und mich den ganzen Tag freuen über meine tolle Firewall Konfiguration und den verlegten Port - 1 ernsthafter Angriff und schon habe ich ein Problem.

nochmal die frage: wie kommt jemand an meinem iptables vorbei das nur 0,003% der IPs durchlaesst? das wird hier regelmaessig behauptet und nie antwortet jemand auf meine frage.

rudelgurke wrote: Und wenn wie von ernsthaften Angriffen sprechen, ein verlegter Port hält solche Leute auch kaum auf.

der verlegte port haelt 6 von 20 angriffen ab und die kommen ja nicht alle gleichzeitig.

rudelgurke wrote:

buddaaa wrote:ist vielleicht die zeit die Du zum patchen brauchst, oder schaffst Du es immer innerhalb von ein paar tagen? urlaub, krankeit, zero-day, ... ?

Entweder ich habe einen Server der 24 Stunden am Tag am Netz hängt und übernehme die Verantwortung, oder ich schalte das Ding ab wenn ich den Urlaub fahre oder krank bin.
Wenn ich im Urlaub oder krank oder sonstwie verhindert bin, muss ein anderer fachkundiger Kollege die Administration übernehmen.

ja so die theorie, dann gibt es noch das richtige leben. was schaetzt Du denn bei wieviel prozent der root-server-betriebern das der fall ist? wer denkt bei krankheit oder unfall zuerst an den root-server? klar, wer keine vertretung hat wenn er mal nicht kann hat probleme, aber mit iptables vor der ssh hat er eins weniger. warum soll man also drauf verzichten?

rudelgurke wrote: Oder bleibt dein Server unbeaufsichtigt wenn du in den Urlaub fährst ?

ich schau im urlaub ab und zu selber, aber die frequenz ist deutlich niedriger.

rudelgurke wrote:

buddaaa wrote:und es kann mir keiner erzaehlen, dass das jeder durchschnitts-admin mit ubuntu-laptop sofort schnallt. also port verlegen und iptables drauf und zeit schinden.

Dann sollte dieser Durchschnittsadmin seine Zeit wohl eher damit verbringen, sich in die Materie einzuarbeiten ...

siehste, eben hat noch sshd mit key-auth und regelmaessig updaten gereicht, schon kommt beim debian-problem noch das sehr aufmerksame lesen von security-news dazu. was der perfektionist im bilderbuch ja sowieso macht, aber fuer den durchschnittsadmin find ich iptables weniger aufwendig und sicherer.

rudelgurke wrote: als seine Zeit damit zu verklempern nach 5x erfolglosen "selbst ausgesperrt" eine funktionieren Firewall Konfiguration aufgestellt zu haben.

dafuer gibts tools oder fertige skripte, man kann sich in die materie einarbeiten wie Du selber sagst und fuers aussperren gibt es manchmal eine serielle konsole. kein ding der unmoeglichkeit.

rudelgurke wrote: Wenn er dann soweit ist, kann er immer noch eine Pix oder was ihm beliebt davor schalten.

kostet geld, kann kaputt gehen und bei wie vielen root-server-providern kann ich eine eigene FW bestellen?

rudelgurke wrote: Indem ich via Firewall die IP Range auf die meines Providers begrenze, nun - ich kenne nich alle Kunden meines Providers persönlich, noch kann ich sagen ob deren Rechner wirklich sauber sind und nicht als Bot agieren.

genau, um den ssh-port meines servers zu finden muss jemand mit einem groesseren bot-netz einen full-port-scan von jedem einzelnen bot auf alle IPs der root-server-netze machen. nicht sehr realistisch, ich hatte ca. vor 3 jahren den letzten full-port-scan auf meinem server.

rudelgurke wrote: Hier im Forum gibt es bereits eine ordentliche SSH Konfiguration als Beispiel - Key Auth, Root Login abschalten und via AllowUsers weiter eingrenzen.m.

Mit SELinux / MAC usw. usw. usw. geht's dann weiter - für mich persönlich ist meine Zeit darin besser investiert - wenn du dass anders macht, kein Problem.

Du hast wieder das regelmaessige und aufmerksame lesen der security-news vergessen, mit ubuntu-laptop haette das alles nichts genutzt. und zeig mir ein posting vor dem debian-problem wo jemand darauf hingewiesen hat (oder auch danach ausser diesem). es heisst hier immer "sshd mit keyauth und sicher isses".

und noch ein beispiel wo die tips da oben auch nicht reichen: admin installiert ende 2006 einen suse server, steigt anfang 2007 bei seinem laptop von ubuntu auf suse um und kriegt seinen server 2008 geknackt. alle tips von rudelgurke befolgt, nur vergessen seinen alten key in authorized_keys zu loeschen. passiert dem perfekten admin natuerlich nicht, in der realitaet schon. iptables auf provider-netze schindet viel zeit das es ihm vielleicht noch auffaellt, iptables auf feste IP ist fast nicht zu knacken.

oh, matze ist irgendwie immer noch dabei. erklaer doch endlich mal warum ssh verlegen auf einen anderen port gefaehrlich ist und beim verlegen auf eine andere IP der angreifer keine chance mehr hat ;) oder erzaehl doch nochmal warum snort ungefaehrlicher ist als iptables :) oder wie Du iptables einen rootkit unterschiebst :) Du weisst schon warum Du das nicht mehr lesen willst, ich sollte mir mal einen zweitaccount zulegen :)

matzewe01 wrote:

rudelgurke wrote: Wie mit dem SuSe Beispiel gezeigt wurde, reicht schon 1 ernsthafter Angriff - da kann ich stolz in meine Logs schauen und mich den ganzen Tag freuen über meine tolle Firewall Konfiguration und den verlegten Port - 1 ernsthafter Angriff und schon habe ich ein Problem.
Und wenn wie von ernsthaften Angriffen sprechen, ein verlegter Port hält solche Leute auch kaum auf.

Da wir alle nicht über eine hellseherische Fähigkeit verfügen, kann dieser jederzeit und von jedem Host dieser Welt kommen.
Davon muss man aus gehen.

matze, das austauschbares sicherheitsargument "keine absolute sicherheit" hatten wir bereits. Du installierst keine applikationen bei Dir weil Du immer davon ausgehen musst, dass jemand einen unbekannten exploit dafuer hat :)

matzewe01 wrote: Somit hilft kein gefummele mit IPTables oder fail2ban um einen zeitlichen Vorteil raus zu schlagen.

was willst Du eigentlich immer wieder mit fail2ban?

Zu der Beschränkung von IP's ist eine kleine Lektüre zu empfehlen:

http://bsdly.blogspot.com/2008/12/into- ... gates.html

Distributed SSH Attacks

Wie schon gesagt - solange dein IPtables nicht gerade von 0.0.0.0 - 255.255.255.255 die IP's blockt bringt es rein garnichts.
Vielleicht werden von 10.000.000 Rechnern 9.500.000 ausgesperrt, bleiben immer noch 500.000 Rechner übrig.

Ja ich weiß - IPtables läuft unter Open- bzw. FreeBSD ohnehin nicht und der typische Ubuntu Admin wird dass ohnehin nicht nehmen usw. usw.

Zum SuSe Problem mit dem SSH Key - da hätte auch kein IPtables geholfen - schwache Keys oder Key Passphrasen. Wenn sowas "vergessen" wird, geht in der Planungsphase etwas schief und falsche Planung kann man nicht durch technische Möglichkeiten versuchen zu kompensieren.

Oder dürfen deine User Joomla installieren, nur damit man mal sehen kann wie schön mod_security oder ein gehärtetes PHP arbeiten ?

rudelgurke wrote:Zu der Beschränkung von IP's ist eine kleine Lektüre zu empfehlen:

http://bsdly.blogspot.com/2008/12/into- ... gates.html

Distributed SSH Attacks

Wie schon gesagt - solange dein IPtables nicht gerade von 0.0.0.0 - 255.255.255.255 die IP's blockt bringt es rein garnichts.
Vielleicht werden von 10.000.000 Rechnern 9.500.000 ausgesperrt, bleiben immer noch 500.000 Rechner übrig.

der herr im blog schreibt von 695 host die sich an der attacke beteiligen, damit waere die chance an meinen ssh-port zu kommen schon auf 2% gestiegen, wow. und hast Du Dir schon seine empfohlene gegenmassnahme per pf angeschaut? ;)

rudelgurke wrote: Zum SuSe Problem mit dem SSH Key - da hätte auch kein IPtables geholfen - schwache Keys oder Key Passphrasen.

warum nicht? schaumal wie viele leute mit den rootforum-ssh-tips auf die schnauze gefallen sind:
http://www.heise.de/security/Tausende-d ... ung/108528

da ist man doch froh wenn's noch die zusaetzliche huerde gibt das der angreifer mehrer tausend bots braucht die alle einen full-port-scan machen muessten. insbesondere wen wie in diesem fall "vor dem bahnhof 1000 gleich teure fahrraeder mit duenneren schloessern stehen."

rudelgurke wrote: Wenn sowas "vergessen" wird, geht in der Planungsphase etwas schief und falsche Planung kann man nicht durch technische Möglichkeiten versuchen zu kompensieren.

aber klar, ich bau ein system einfach so auf, dass es nicht bei einem einzigen problem schon verloren ist. ssh auf port 22 offen fuer alle ist ein single point of failure, wie kann man sowas ernsthaft vorschlagen wenn es sinnvolle alternativen gibt.

und wie bitte planst Du nie zu vergessen einen key aus der authorized_keys zu loeschen? also ich bin nicht perfekt.

rudelgurke wrote: Oder dürfen deine User Joomla installieren, nur damit man mal sehen kann wie schön mod_security oder ein gehärtetes PHP arbeiten ?

und Du hast kein gehaertetes php weil nur sichere applikationen auf Deinen server duerfen? siehste: mehrschichtige sicherheit ist ne feine sache, warum nicht auch fuer openssh?

matzewe01 wrote:

buddaaa wrote:da ist man doch froh wenn's noch die zusaetzliche huerde gibt das der angreifer mehrer tausend bots braucht die alle einen full-port-scan machen muessten. insbesondere wen wie in diesem fall "vor dem bahnhof 1000 gleich teure fahrraeder mit duenneren schloessern stehen."

Der Aufwand ist doch inzwischen gar nicht mehr nötig :D
IP-Tables lässt sich immer noch abschiessen und die TCP Lücken machen auch grad Ihre Runde.

Deine lustige behauptung das iptables abschiessbar ist hast Du jetzt oft genug von Dir gegeben. verkauf diese nur Dir bekannte 0-day-sicherheitsluecke doch z.b. an astaro, die geben Dir sicher ein nettes suemmchen dafuer :)

und auch zum hundertstens mal: wo ist der zusammenhang zwischen TCP-luecken und iptables?

matzewe01 wrote: Und selbst wen diese Probleme nicht existieren würden, brächte Dir dieser ominöse IP Tables Schutz nach wie vor nichts.
*gähn*

und auch zum hundertstens mal: wie kommt man denn an iptables vorbei?

matzewe01 wrote: Ja mag sein, das damit einige Systeme nach rootforum.org/ " unvollständigen Empfehlung" gehackt worden wären.
Mit Deiner Empfehlung wären die gleichen Systeme auch gehackt worden, nur mit dem Trugschluss, das Sie nun noch sicherer wären.

ja wie denn?

matzewe01 wrote: Nach rootforum.org/ Empfehlung (vollständig inkl. Verstand) hätten
1. die Debian User, Debian gar nicht eingesetzt.

interessant, schau Dir mal die unterforen zu den betriebssystemen an, bei debian/ubuntu sind die meisten beitraege und es haengt kein sticky-thread drueber mit "nehmt kein debian!". und seit wann ist es die offizielle rootforum-emfpehlung kein debian einzusetzen, das stand vielleicht mal ein paar threads, hab ich selber nie irgendwo gelesen. oder stehts in Deinem wiki-artikel: http://www.rootforum.org/wiki/security/allgemein ? nein, auch nicht. und zeig mir einen einzigen thread vor dem debian-debakel der davon abraet debian oder ubuntu auf dem heim-PC einzusetzen, weil das war ja das gefaehrliche.

matzewe01 wrote: 2. Nach bekanntwerden der Lücke zeitnah gepatcht.
3. ggf. sogar sshd gestoppt bis ein Patch verfügbar ist.

durchgefallen, server geknackt. der admin hatte vor einem jahr noch ubuntu auf dem laptop und vergessen die authorized_keys aufzuraeumen.

uebrigens, in Deinem wiki-artikel wird das patchen nur im nebensatz erwaehnt, sollte fuer anfaenger vielleicht noch deutlicher sein :) und von dienst anhalten steht da auch nichts.

matzewe01 wrote: Alle andere hätten auf den Sicherheitsbuddaaa vertraut und wären erst recht und trotz Sicherheitswunder IPTables gehackt worden.
So ist das Leben halt.

allerliebst was Du mir mal wieder unterstellt, zeig mir ein posting von mir wo ich behauptet das iptables als alleinige massnahme reicht. zeig mir ein posting wo ich sicherheitsupdates als ueberfluessig betrachte. ja, gibts nicht, komisch, warum schreibst Du dann so'n murks?

matzewe01 wrote: Was aber absolut bezeichnend ist,
Als diese S4Y Hosts gehackt wurden, waren schon Patches verfügbar, dass man rechtzeitig genug vorher gewarnt wurde muss Ich ja nicht auch noch erwähnen oder? Ein sorgsamer Admin hätte einen Einbruch verhindern können. Aber da shen wir mal wieder, welches Klientel inzwischen solche Rootserver betreibt.
Jene, die keinen 24*7 aufrecht erhalten können und auch keine Verständnis für diese Notwendigkeit haben.

staun, was Du schon wieder alles weisst, das waren wirklich nur S4Y-server? scheint eher Du willst richtung S4Y-bashing ablenken :) schreib doch lieber mal ueber den unterschied zwischen ssh-verlagerung auf einen anderen port vs. andere IP ;) oder ob Du wirklich snort auf Deinem server hast ? ;) oder mal eine quelle fuer Deine regelmaessigen behauptungen iptables waere unsicher ;)

matzewe01 wrote:Die Quelle ist der sourcecode.

sehr praezise quelle, wir treffen uns dann in berlin am briefkasten :)

matzewe01 wrote: Und so lange der Bug nicht gefixt ist.

leider nicht nebenbei gefixt, so lange halte ich mich auch schlicht weg dabei zurück.

ich glaub Dir kein wort.

matzewe01 wrote: Warum sollte Ich einem "Anbieter" eines dienstes mit voller Absicht an die Karre fahren?

wovon redest Du? verkauf den bug an astaro, die geben ihn den iptables leuten und lassen ihn fixen, wem hast Du an den karren gefahren?

matzewe01 wrote: Ich lade Dich zum Security Audit in der LMU ein.
Darfst mich auch in Dortmund besuchen kommen.

hahaha, eine neue sinnlose bedingung fuer mich damit Du endlich mal tacheles redest :)

matzewe01 wrote: Da zeige Ich dir
1. wie das Umgehen von IP Tables geht.

und Du meinst die switche bei den providern sind genauso schlecht konfiguriert wie die im labor?

matzewe01 wrote: 2. Welche Lücken der TCP IP Implementierung genutzt werden können um z.B. IP Tables zu umgehen.

ja und, dafuer gaebe es irgendwann einen fix.

matzewe01 wrote: 3. Wie man Snort richtig einsetzt, sodass dessen "Lücken" nicht ausgenutzt werden können.

schreib das doch in Deine wiki-seite wo Du snort empfiehlst, alle die es daraufhin installieren ohne Deine mal wieder geheimnisvolle methode haben naemlich ein problem, und zwar ein nachweisliches im gegensatz zu iptables.

matzewe01 wrote: BTW:
Dann darfst du auch gerne eine Referat vor gesammelter Mannschaft halten, warum Deine Implementierung von IPTables immer noch besser sein soll.
Mit Nachweis im Labor. Den Gegenbeweis bleibe ich Dir nicht schuldig.

hallo, dies ist ein forum und nicht keine blind-date-seite. ich hab keinen bock Dich zu besuchen, Du kannst hier einfach wie alle anderen auch per internet beweise liefern.

matzewe01 wrote: Apropo, auf meinem System ist gerade der Stand mit der von Dir genannten Lücke eingespielt.
Bis heute bleibst Du den Beweis aus, dass Du Sicherheitlöcher tatsächlich ausnutzen kannst.

ja ich frag Dich jetzt ja auch nur zum fuenften mal wo ich behauptet habe, das ich das kann :)

matzewe01 wrote: Und so lange wir nicht auf Augenhöhe miteinander reden, werde ich Dir auch nicht auf die Nase binden, wie man ein System z.B. per IPTables hackt / umgeht.
Das verbietet mir meine "Hacker Ehre" sofern man das so sehen mag.

Ist es denn wirklich Deine Erwartungshaltung, dass ich hier öffentlich, bzw. Dir persönlich inkl. Quellcode ein Tool vor die Füsse werfe mit dem Du andere attackieren kannst? Mit Verlaub: "Bei dir stimmt doch etwas in der Oberstube nicht, oder?"

was phantasierst Du den da schon wieder zusammen? ich verlange doch nicht mehr als irgendeinen beleg, webseite, cve-nummer, ... fuer Deine heisse luft.

oder noch einfacher und sogar mit Deiner "ehre" vertraeglich: liefer doch mal belege fuer die schlimme historie von iptables als reiner paketfilter. alte luecken, laengst bekannt und gefixt. muss kein tool sein, einfach nur webseiten wo die beschrieben sind. gibt es doch jede menge wie Du behauptet hast. ich such Dir gerne Dein posting raus dazu.

matzewe01 wrote: (Sogar Studenten aus dem 2. Semester waren in der Lage mein System zu hacken. Warum kannst Du den Inhalt der bereits erwähnten Datei nach wie vor nicht nennen?)
Komm einfach zum nächsten Security Audit. Ausgeschrieben in der Uni.

Du willst es echt nicht zu kapieren, gelle. tut es hier in der diskussion inhaltlich irgendwas zur sache ob ich Dein system hacken kann oder ueber wassen laufen kann? wird jemals ein paper veroeffentlicht werden mit dem inhalt "security by obscurity ist toll weil buddaaa das system von matzewe01 knacken konnte" ?

solange Du keinen einzigen beleg fuer Deine behauptungen lieferst nehme ich Dich halt einfach nicht ernst.

hey, und wo ist nochmal der unterschied zwischen ssh auf einen anderen port verlegen vs. anderen ip-nummer? (sorry, ist einfach zu lustig ;)

matzewe01 wrote:

buddaaa wrote:
solange Du keinen einzigen beleg fuer Deine behauptungen lieferst nehme ich Dich halt einfach nicht ernst.

hey, und wo ist nochmal der unterschied zwischen ssh auf einen anderen port verlegen vs. anderen ip-nummer? (sorry, ist einfach zu lustig ;)

Also doch ein Troll.

Schade für Dich ;-)
Machs gut.

warum lieferst Du denn nicht einfach einen beleg oder erklaerst warum andere ip besser als anderer port ist :)

also nach gaengiger definition bist Du eher der troll. Du lieferst behauptung ohne belege (iptables war unsicher, iptables ist unsicher), willst belege nur bringen wenn man sich strafbar macht (Deinen server knacken) oder nach dortmund faehrt, lenkst regelmaessig vom thema ab (fail2ban, auto-TCP, S4Y, ...) und unterstellst mir regelmaessig irgendwelche behauptungen.

und sorry, jemand der das verlegen der ssh auf eine andere portnummer als gefaehrliche security by obscurity bezeichnet, das verlegen auf eine andere IP-adresse aber selber praktiziert und als sicher bezeichnet koennte doch wirklich mal stellung dazu beziehen ;)

matzewe01 wrote:

buddaaa wrote: warum lieferst Du denn nicht einfach einen beleg oder erklaerst warum andere ip besser als anderer port ist :)

Dir geht es doch gar nicht darum, die Sache zu klären.

ja wie, nur weil ich mich nicht strafbar machen will und Deinen server hacke oder nicht nach muenchen fahre? :) was ist den noch zu klaeren? remote exploits in ssh 2, snort 3, iptables 0, port verlegen 0. wenn's im fussball so steht hauen die fans in der 80 minuten aus dem stadion ab um sich das gedraenge zu sparen ;)

matzewe01 wrote: Uni Dortmund, LMU München wo liegt das Problem jeweils einmal im Monat findet das Security Audit statt.
Aber darum geht es Dir gar nicht.

ne, natuerlich nicht, wie kommst Du denn darauf das ich in der gegend rumfahren will? :) wir leben im jahr 2009, es gibt das internet, hallo. schick doch einfach irgendeinen beleg fuer Deine behauptungen.

Dein angebot ist ja auch kein beweis das iptables ein system unsicherer macht. das "umgehen von iptables" ist nicht vergleichbar mit einem remote exploit. iptables ist nur eine zusaetzliche sicherheitsschicht, wer die umgeht muss immer noch den dienst knacken. mit einem remote exploit fuer ssh oder snort ist die arbeit erledigt.

matzewe01 wrote: Andere IP, bringt soviel wie anderer Port, nichts.
Immer noch das Problem, dass diese Kleinigkeit nicht von Dir verstanden wird.

und warum machst Du es dann und hast Du das damals als "huerde" bezeichnet "die einem keine chance laesst" ? :) (wuerde auch nicht sagen das es nichts bringt. wenn jemand genau Deinen server angreifen will und die IP in einem anderen netz ist muss man schon zeit investieren. dann vielleicht noch die uptime verbergen und keinen ungewoehnlichen TCP-fingerprint haben ... ).

matzewe01 wrote: Lass Dich mal untersuchen oder nutzte die bisher unnötig vergeudete Zeit des Trollens um Deine geistige Kapazität zu trainieren.
Schaden kanns nicht.

och, suess, matzewe01 muss schoen wieder persoenlich werden. schaumal: ich bin in der lage cve-nummern im internet zu meinen behauptungen zu finden, Du nicht ;)

matzewe01 wrote: Das Angebot gilt natürlich auch den anderen Mitglieder hier im Forum, am nächsten Security Audit teil zu nehmen.
Über mehr müssen wir nun wirklich nicht mehr diskutieren.

Tschüss.

genau, geht hin und wenn man da ueberraschenderweise gezeigt kriegt wie iptables als paketfilter ein system unsicherer macht meldet Euch, bin noch interessiert am ersten beleg.

buddaaa wrote: genau, geht hin und wenn man da ueberraschenderweise gezeigt kriegt wie iptables als paketfilter ein system unsicherer macht meldet Euch, bin noch interessiert am ersten beleg.

http://www.heise.de/newsticker/meldung/ ... 03849.html

Naja dann mal wieder die Change_logs sehr aufschlussreich.
http://www.netfilter.org/projects/iptab ... s-1.4.12.1

Es gab und gibt im Zusammenspiel zwischen Kernel und IPv6 regelmässig Bugfixes.

Und wenn ich mir überlege, dass hier Fehler behoben wurden, dann gab es ganz simpel ausgedrückt wohl sowas wie eine Fehlfunktion ;-)

Nur um eine diskussion mal wieder auf zu frischen wo gerade jemand
iptables Regeln eingestellt hat und quasi fragt: Und? Ist das gut so?
wenn man nicht weiss, warum man was tut, ist es i.d.R. nicht gut.