IP-Bindung macht Debianforum unbenutzbar.

[wanne]

Ich hatte das Thema schon vor einiger Zeit mal angesprochen. Aber mit den neueren Anschlüssen bekommt das jetzt noch mal mehr Relevanz. Mittlerweile rotieren IP Adressen oft pro Verbindung (IPv4-CGNAT-Loadbalancing) oder sehr häufig (IPv6 privacy-extentions) Ich komme mittlerweile oftmals sogar einige Versuche fürs einloggen. Und egal wie sinnvoll man die genannten Technologien hält. Genau für den Zweck sind Cookies gemacht worden. Das die Session eben nicht an IP und Port hängt, die sich halt prinzipiell ändern können. Das nachträglich wieder rückgängig zu machen indem man die Session an die IP bindet finde ich ungeschickt.
Vor allem auch ich den Sicherheitsgewinn für mindestens Zweifelhaft halte, zumal immer noch nur ein plausibles Szenario gehört habe wo das hilft. (Und nein: Angreifer ist irgendwie ans Cookie gekommen ist eben kein echtes Szenario.) Und das ließe sich beseitigen, wenn man die URL-Parameter-SID abchafft.
Ja der angemeldet bleiben Button kann einiges auffangen. Er hat aber dann wirklich den Sicherheitsnachteil, dass man nicht vergessen sollte sich auszuloggen und außerdem vergesse ich in 2 von 3 Fällen eh ihn anzuklicken, da er per default aus ist.
Deswegen nochmal die Frage, ob man das abstellen kann. Und wie man an TID 186149 sehen kann, bin ich nicht der einzige, dem das so geht. (Das es eventuell 10 andere gibt für die das kein Problem ist, mag sein. Aber ich finde das Debianforum sollte für möglichst alle da sein.)

[cosinus]

Er hat aber dann wirklich den Sicherheitsnachteil, dass man nicht vergessen sollte sich auszuloggen und außerdem vergesse ich in 2 von 3 Fällen eh ihn anzuklicken, da er per default aus ist.

Stellst du den Firefox nicht so ein, dass er beim Beenden Cookies und Cache löscht?

[Meillo]

Ich finde es gut, dass du uns schreibst, was dich an der Bedienung des Forums stoert. Vielleicht laesst es sich aendern.

Die Frage ist hierbei sicherlich, was phpBB mitbringt. Wenn es um das Setzen einer Konfigurationsoption geht, dann ist Sebastian sicherlich aufgeschlossen. Wenn wir aber den Quellcode aendern oder ein Plugin installieren muessten, dann muss der Nutzen gross genug sein, um den Aufwand, das ueber die Zeit zu betreuen, auszugleichen. Bislang versuchen wir ja die Anpassungen moeglichst klein zu halten.

Weiss jemand, was phpBB diesbezueglich mitbringt?

[uname]

Also ich weiß nicht wie das Debianforum funktionieren soll. Aber wenn ich mir die Browser-Entwicklertools mit F12 anschaue, finde ich unter Webspeicher Cookies.

Stellst du den Firefox nicht so ein, dass er beim Beenden Cookies und Cache löscht?

Das mache ich auch so. Leider werden gerade die Anwender mit diesem hohen Sicherheitsbewusstsein dadurch immer wieder mit den sinnlosen Cookie-Bannern bestraft.

[wanne]

Leider werden gerade die Anwender mit diesem hohen Sicherheitsbewusstsein dadurch immer wieder mit den sinnlosen Cookie-Bannern bestraft.

Leider ist das vermutlich der Grund warum SID in URL an bleiben muss.
Damit braucht man keine Cookies ohne, dass man dem Banner zugestimmt hat.
Auf der anderen Seite setzt das Form die Cookies sowieso. Auch wenn man nicht zustimmt.

Die Frage ist hierbei sicherlich, was phpBB mitbringt. Wenn es um das Setzen einer Konfigurationsoption geht, dann ist Sebastian sicherlich aufgeschlossen.

Das ist nicht das defaultverhalten von phpBB sondern müsste explizit so in den Einstellungen gesetzt worden sein.
Müsste da zurücksetzen lassen:

Code: Alles auswählen

Security Settings - Session IP Validation

Es wird auch in diversen Beträgen im phpBB Forum davon abgeraten das anzuschalten:
https://www.phpbb.com/community/viewtopic.php?t=1588645
https://www.phpbb.com/community/viewtopic.php?t=2478346

[wanne]

Wie gesagt. Das wurde schon mal diskutiert:
viewtopic.php?p=1030251#p1030251

Stellst du den Firefox nicht so ein, dass er beim Beenden Cookies und Cache löscht?

Und genau deswegen nervt es mich so, dass ich jedes mal den angemeldet-Button anklicken muss.

[cosinus]

Leider werden gerade die Anwender mit diesem hohen Sicherheitsbewusstsein dadurch immer wieder mit den sinnlosen Cookie-Bannern bestraft.

Dafür gibt es https://addons.mozilla.org/en-US/firefo ... utcookies/

[feltel]

Das Forum ist momentan so eingestellt, das die ersten drei Oktets der IP validiert werden. Du bzw. Dein Gateway muss also nicht mal immer die gleiche IP haben. Mir ist in diesem Zusammenhang noch nichts problematisch untergekommen. Gut, an einem DS-Lite-Anschluss habe ich noch nicht gehangen. Wechselt dort auch innerhalb einer Einwahl die IP des Ausstiegs ins Internet beim Provider? Welchen Sinn sollte das machen? Die werden den Traffic eines Users doch nicht dynamisch hin und her routen?

[cosinus]

Das Forum ist momentan so eingestellt, das die ersten drei Oktets der IP validiert werden.

Und wie läuft das hier mit IPv6?

[wanne]

Wechselt dort auch innerhalb einer Einwahl die IP des Ausstiegs ins Internet beim Provider? Welchen Sinn sollte das machen? Die werden den Traffic eines Users doch nicht dynamisch hin und her routen?

NAT braucht unter Linux immer noch über linear viel Rechenleistung. Wenn du also 3 mal ein drittel der Verbindungen handelst, ist das schneller. Also verteilst du deinen Traffic anhand des sourceports auf 3 nats mit unterschiedlichen IPs. Und da browser üblicherweise gleich mehrere Verbindungen auf machen hast du dann pro Request ne andee Source-IP In dem von mir verlinkten Beiträgen meinen die sogar, dass die oft genug nicht mal aus dem selben Subnetz kommen, weil man sich den Adressspace wild zusammen gekauft hat.
Sollte aber kein Problem sein, wenn du IPv6 kannst, da da ja kein NAT benötigt wird.
Ich habe hauptsächlich probleme im UNI-VPN die haben ein volles /16. Können also einigermaßen verschwenderisch mit den IPs umgehen. Aber halt nicht für jeden Mitarbeiter/Student ne eigene haben.

[uname]

Mittlerweile rotieren IP Adressen oft pro Verbindung (IPv4-CGNAT-Loadbalancing) oder sehr häufig (IPv6 privacy-extentions)

Kannst du mal genauer erklären, warum du oder ihr das so habt? Also ich kenne größere Umfelder mit Tausenden von Benutzern und dort ist das nicht der Fall. Hast du vielleicht die Möglichkeit einen HTTP-Proxy zu nutzen, um das Problem zu umgehen oder ist eher der Proxy das eigentliche Problem.

[feltel]

Und wie läuft das hier mit IPv6?

Da gibts soweit ich das überblicke das Feature seitens phpBB nicht.

[unitra]

...Und da browser üblicherweise gleich mehrere Verbindungen auf machen hast du dann pro Request ne andee Source-IP In dem von mir verlinkten Beiträgen meinen die sogar, dass die oft genug nicht mal aus dem selben Subnetz kommen, weil man sich den Adressspace wild zusammen gekauft hat.
Sollte aber kein Problem sein, wenn du IPv6 kannst, da da ja kein NAT benötigt wird.
Ich habe hauptsächlich probleme im UNI-VPN die haben ein volles /16. Können also einigermaßen verschwenderisch mit den IPs umgehen. Aber halt nicht für jeden Mitarbeiter/Student ne eigene haben.

Frage bei Deinem Arbeitgeber (UNI) mal nach ob es mögliche wäre eine eigene IPv4 deiner persönlichen Workstation zuzuwweisen.

Nächste Frage wäre ob man die Security Extensions dann auch benötigt wenn sie so viele Probleme bereiten. IPv6 Privacy Extensions werden an dem Knoten der die IPv6 Adresse bekommt, konfiguriert. Das könnte man abschalten. Einfach beim ServiceDesk/HelpDesk der Universität nachfragen ob man das umkonfigurieren könnte. Und wenn dual-stack betrieben wird (IPv4 und IPv6 gleichzeitig) dann kommt das "Happy Eyeballs RFC" d.h. IPv6 hat Priorität vor IPv4. Ich glaube nicht dass IPv6 Privacy Extensions mandatory sind bei dem Arbeitgeber, das wäre das erste mal wo ich das höre dass das zwingend notwendig ist. Ich schliesse es nicht aus, aber das ist schon ein kaputt designed Netzwerk aus meiner Perspektive. Meine persönliche Meinung hier dazu.
Also die Kombination aus Carrier Grade NAT und IPv6 Security Extensions ist toxisch. Da ist dann keine Ende zu Ende Verbindung möglich. Auf der anderen Seite, "sicher", "anonym", und eben kaputt.

HTTP Proxy wäre auch meine nächster Vorschlag, das wurde aber schon geschrieben. einfach beim Helpdesk nachfragen ob es einen gibt und ob man den nutzen könnte. Wegen der benannten Verbindungsprobleme, kann nicht sein dass Du der Einzige bist bei deinem Arbeitgeber der diese Probleme hat.

[Meillo]

Die Vorschlaege gehen gerade alle in die Richtung, dass wanne etwas an seinem Setup aendern soll. Fuer mich ist aber noch nicht klar geworden, was der Vorteil ist, die derzeitige Einstellung beizubehalten. Koennten wir sie nicht im Forum aendern, damit die User nichts aendern muessen? Ich wuerde es gerne verstehen.

[uname]

Mittlerweile rotieren IP Adressen oft pro Verbindung (IPv4-CGNAT-Loadbalancing) oder sehr häufig (IPv6 privacy-extentions)

Und wenn dual-stack betrieben wird (IPv4 und IPv6 gleichzeitig) dann kommt das "Happy Eyeballs RFC" d.h. IPv6 hat Priorität vor IPv4. Ich glaube nicht dass IPv6 Privacy Extensions mandatory sind bei dem Arbeitgeber, das wäre das erste mal wo ich das höre dass das zwingend notwendig ist.

Da fällt mir gerade noch als Idee ein, evtl. IPv6 im Browser zu deaktivieren. Wenn es hilft lag es wohl am IPv6-Zeug. Wenn es nicht hilft, kann man IPv6 als Ursache ausschließen.

Das Forum ist momentan so eingestellt, das die ersten drei Oktets der IP validiert werden.

Bei Verwendung von Cookies erscheint mir das sinnfrei.

Koennten wir sie nicht im Forum aendern, damit die User nichts aendern muessen? Ich wuerde es gerne verstehen.

Sehe ich genauso. Besser die Ursache beheben als das Symptom.

[feltel]

Koennten wir sie nicht im Forum aendern, damit die User nichts aendern muessen? Ich wuerde es gerne verstehen.

Ja klar ist das durch uns hier änderbar. Das "Problem" dabei ist jedoch, das wir eine Schicht in der Sicherheits-"Zwiebel" aufgeben, nämlich der Check, ob ein Session-Cookie auch von der IP-Adresse genutzt wird, für die es gesetzt wurde. Ohne diese Einstellung könnte ein Cookie abgegriffen werden (wie auch immer) und von jeder beliebigen IP genutzt werden.

[Meillo]

Koennten wir sie nicht im Forum aendern, damit die User nichts aendern muessen? Ich wuerde es gerne verstehen.

Ja klar ist das durch uns hier änderbar. Das "Problem" dabei ist jedoch, das wir eine Schicht in der Sicherheits-"Zwiebel" aufgeben, nämlich der Check, ob ein Session-Cookie auch von der IP-Adresse genutzt wird, für die es gesetzt wurde. Ohne diese Einstellung könnte ein Cookie abgegriffen werden (wie auch immer) und von jeder beliebigen IP genutzt werden.

Danke fuer die Erklaerung. Jetzt verstehe ich das.

@wanne: Wie siehst du das? Sicherheit ist dir doch wichtig. Du meintest, dass es Gruende gegen diese Sicherheitseinstellung gaebe. Kannst du vielleicht nochmal darlegen, warum du es sinnvoll oder akzeptabel findest, auf diese Sicherheitskomponente zu verzichten.

[uname]

Ja klar ist das durch uns hier änderbar. Das "Problem" dabei ist jedoch, das wir eine Schicht in der Sicherheits-"Zwiebel" aufgeben, nämlich der Check, ob ein Session-Cookie auch von der IP-Adresse genutzt wird, für die es gesetzt wurde. Ohne diese Einstellung könnte ein Cookie abgegriffen werden (wie auch immer) und von jeder beliebigen IP genutzt werden.

Ich habe mal im Browser in den Entwickler-Tools (F12) geschaut. Die Cookies vom Debianforum sind ein Jahr gültig. Da hat ein Angreifer natürlich viel Zeit die Sitzung zu übernehmen. Bei anderen Webseiten sind die Cookies teilweise nur ein Tag und andere ein halbes Jahr gültig. Einige Cookies laufen aber auch nie ab.

Ich lasse immer alle Cookies beim Beenden des Browsers löschen. Aber könnte man den Zeitraum nicht runtersetzen auf z. B. ein Tag und dafür die Sache mit der IP-Adresse weglassen?

Ich habe hierzu leider nur einen phpbb Beitrag aus 2009 - 2012 gefunden.

[wanne]

wenn sie so viele Probleme bereiten. […] IPv6 Privacy Extensions werden an dem Knoten der die IPv6 Adresse bekommt, konfiguriert. Das könnte man abschalten.

Habe ich eh aus. Aber es sind ja nicht viele Probleme. Sondern ein Forum, das nicht tut. Und auch wenn im Standard steht, dass die per default aus sein sollen und von den Anwendungen eingeschaltet werden können, ist die Realität, dass gefühlt alle Betriebssysteme abseits von Debian und Rocky/Red Hat sie per default an haben. Ich finde eine Website sollte da einfach tun. Und nicht die Sicherheit runter drehen müssen, damit das Forum tut.

HTTP Proxy wäre auch meine nächster Vorschlag,

Ja nutze ich schon länger. Aber halt ein hässliches Workaround.

Ich schliesse es nicht aus, aber das ist schon ein kaputt designed Netzwerk aus meiner Perspektive.

Ne. Das Forum ist IMHO Kaputt wenn es annimmt, dass die IP immer gleich bleibt.

Also die Kombination aus Carrier Grade NAT und IPv6 Security Extensions ist toxisch. Da ist dann keine Ende zu Ende Verbindung möglich. Auf der anderen Seite, "sicher", "anonym", und eben kaputt.

Ubuntu nutzt für den Browser privacy extentions und für Server-Anwendungen nicht. IMHO ist das sinnvoll. CGNAT ist natürlich trotzdem kaputt.

Aber könnte man den Zeitraum nicht runtersetzen auf z. B. ein Tag und dafür die Sache mit der IP-Adresse weglassen?

Fände ich sinnvoll. Stört aber natürlich die, die wirklich über Jahre ohne Anmeldung rein kommen wollen.

Wegen der benannten Verbindungsprobleme, kann nicht sein dass Du der Einzige bist bei deinem Arbeitgeber der diese Probleme hat.

Wie gesagt: Hier hat sich noch jemand anders beschwert und im phpBB-Forum hab ich auch 2 Beiträge verlinkt die auf Probleme verweisen. Und wie gesagt. Es ist nicht nur CGNAT sondern eben auch IPv6 und Handy-Internet... Klar, wenn man sagt Unsere Nutzer haben halt Debian hinter einem Telekomanschluss zu nutzen. Und alles andere ist deren ihr Problem. Aber ich finde dann kann man das mit Internet auch lassen. Warum nicht direkt zu BTX gehen.

Also ich kenne größere Umfelder mit Tausenden von Benutzern und dort ist das nicht der Fall.

In den meisten Unternehmen liegt am Ende eh ein Gigabit-Anschluss und für den hat jeder mini-PC genug Rechenleistung für NAT. Aber ich weiß von einem größeren Autozulieferer hier in der Nähe, dass die Firewall halt nur die halbe bis ein drittel der Bandbreite des Internetanschlusse schafft. Enterprise-Firewalls sind ganz gerne mal ganz schön schwachbrünstig. Könnte man da locker noch mit Hardware erschlagen aber ist da halt so. Universitäten hängen aber dann gerne mal an mehreren hundert Gigabit. Die bekommst du mit einem einzelnen NAT schwer bedient. Kannst du dann sekmentieren und deine Infrastruktur 20 mal vorhalten, Vielnutzern dedizierte IPs geben oder halt über mehrer IPs balancen oder eine Mischung aus allem machen.

@wanne: Wie siehst du das? Sicherheit ist dir doch wichtig. […] Kannst du vielleicht nochmal darlegen, warum du es sinnvoll oder akzeptabel findest, auf diese Sicherheitskomponente zu verzichten.

Ja. Sicherheit. Aber nicht Gängelung ohne Sinn. Hab das gleiche Thema oft bei Firewallblocks für UDP Ja: Youtube stellt automatisch auf TCP um, wenn UDP nicht tut, den DNS-Server kann man auf den Lokalen setzen, OpenVPN kann auch im TCP-Mode laufen und für VoIP kann man Zoom statt SIP nutzten... Man kommt problemlos ohne aus.
Aber in der Realität sind die Leute die UDP nutzen halt welche, die ein VPN, Videotelefonie oder schnelleres Youtube nutzen wollen. Während die Angreifer praktisch ausnahmslos TCP nutzen. Warum wird dann ausgerechnet UDP gesperrt.
Same hier:

Vor allem auch ich den Sicherheitsgewinn für mindestens Zweifelhaft halte, zumal immer noch nur ein plausibles Szenario gehört habe wo das hilft.

Ja. Irgend ein Nutzer kann den Developer Mode an machen und da sein Cookie kopieren und irgend wo posten. Aber realistisch. Jeder der ein Cookie abfangen kann muss sowieso vorher in der Lage gewesen sein, die IP auf die des Absenders oder zumindest des gleichen Netzwerks zu faken. Zumal wenn eh die Nutzer eh schon zu Methoden wie Proxys oder NAT gezwungen werden, die massenhaft Usern ermöglichen, die gleiche IP zu nutzen.

[uname]

Vor allem auch ich den Sicherheitsgewinn für mindestens Zweifelhaft halte, zumal immer noch nur ein plausibles Szenario gehört habe wo das hilft.

Ja. Irgend ein Nutzer kann den Developer Mode an machen und da sein Cookie kopieren und irgend wo posten. Aber realistisch. Jeder der ein Cookie abfangen kann muss sowieso vorher in der Lage gewesen sein, die IP auf die des Absenders oder zumindest des gleichen Netzwerks zu faken. Zumal wenn eh die Nutzer eh schon zu Methoden wie Proxys oder NAT gezwungen werden, die massenhaft Usern ermöglichen, die gleiche IP zu nutzen.

Ich sehe auch nicht den wirklichen Sicherheitsgewinn. Die Cookies liegen auf dem Client und werden vom Server verwaltet. Die Kommunikation ist TLS. Wenn jemand an die Cookies kommt, wird eine Einschränkung auf ein IP-Subnetz auch nicht mehr viel helfen. Da hat der Anwender oder das Forum ganz andere Probleme.

[schorsch_76]

Naja, der eigentliche Sinn der SID und des Cookies ist es ja die zustandlose HTTP(S) Kommunikation mit einem Zustand zu verbinden der über die SID in der DB liegt und auch den Benutzer beinhaltet. Mein Verständnis warum man das an die IP binden will/wollte war das dieser Zustand nur dem Browser an dieser IP zugeordnet ist um einen maximalen Sicherheitsgewinn zu erzielen. Die neuen SID sind ja deutlich länger als früher und eine SID zu erraten dürfte praktisch unmöglich sein (hoffe ich zumindest)

Die IPv6 Privacy Extensions sind das keine Security Extensions. Sie rotieren wie die IPv6 Adresse. Diese Privacy Extensions entfernen die EUI64 aus dem unteren 64 Bit der v6 Adresse. Ist nur bei einem Rechner im Netz keine Privacy Extension aktiv kann das alle Rechner im Netz trackbar machen. (Siehe https://arxiv.org/pdf/2203.08946.pdf). Die Adressen haben eine Dauer wie lange sie gültig sind. Sie könne aber auch eine unbegrenzte Lebenszeit haben. Wird die Hälfte der Lebenszeit erreicht, wird i.d.R. eine neue Adresse versuch anzufordern. Diese Lebenszeit lässt sich vom dnsmasq,radvd etc. einstellen.

Code: Alles auswählen

4:  eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2003:d8:xxxx:xxx:8809:b15b:3d98:51f3/64 scope global temporary tentative dynamic 
       valid_lft 7199sec preferred_lft 1700sec
    inet6 2003:d8:xxxx:xxx:7435:c5ff:fef4:2a5/64 scope global tentative dynamic mngtmpaddr 
       valid_lft 7199sec preferred_lft 1700sec

Hier ist die Adresse mit und ohne Privacy Extensions. Aus der EUI64 lässt sich eben die MAC rekonstruieren und damit tracken selbst über neue Prefixes hinweg. Die EUI64 bleibt gleich. Wenn privext (aka use_tempaddr im Kernel) 2, dann nimmt der Kernel bevorzugt die Private Adresse und die EUI64 kann bsp. für Serveranwendungen verwendet werden.

Code: Alles auswählen

use_tempaddr - INTEGER
	Preference for Privacy Extensions (RFC3041).
	  <= 0 : disable Privacy Extensions
	  == 1 : enable Privacy Extensions, but prefer public
	         addresses over temporary addresses.
	  >  1 : enable Privacy Extensions and prefer temporary
	         addresses over public addresses.
	Default:  0 (for most devices)
		 -1 (for point-to-point devices and loopback devices)

https://www.kernel.org/doc/Documentatio ... sysctl.txt

Eine Netzwerkkarte kann viele v6 Adressen haben. Das ist per Spezifikation erlaubt. Der Rechner kann "entscheiden" welche er verwenden will bei einer TCP Kommunikation. Sind der Karte mehrere Adressen zugewiesen, wird das wie eine wechselnde Adresse im Server erscheinen.

Aber wie feltel geschrieben hat, ist der Check nicht bei v6 aktiv.....

Ich wollte das nur zur Verdeutlichung zusammenfassen da ich hier das Gefühl beim Lesen hatte, das einige Grundlagen nicht allen Teilnehmern bekannt sind/waren.

Address lifetime

Each IPv6 address that is bound to an interface has a fixed lifetime. Lifetimes are infinite, unless configured to a shorter period. There are two lifetimes that govern the state of an address: the preferred lifetime and the valid lifetime.[43] Lifetimes can be configured in routers that provide the values used for autoconfiguration, or specified when manually configuring addresses on interfaces.

When an address is assigned to an interface it gets the status "preferred", which it holds during its preferred-lifetime. After that lifetime expires the status becomes "deprecated" and no new connections should be made using this address. The address becomes "invalid" after its valid-lifetime also expires; the address is removed from the interface and may be assigned somewhere else on the Internet.

Note: In most cases, the lifetime does not expire because new Router Advertisements (RAs) refresh the timers. But if there are no more RAs, eventually the preferred lifetime elapses and the address becomes "deprecated".

https://en.wikipedia.org/wiki/IPv6_address

[cosinus]

Eine Netzwerkkarte kann viele v6 Adressen haben. Das ist per Spezifikation erlaubt. Der Rechner kann "entscheiden" welche er verwenden will bei einer TCP Kommunikation. Sind der Karte mehrere Adressen zugewiesen, wird das wie eine wechselnde Adresse im Server erscheinen.

Ist zwar für das Debianforum nicht relevant, aber dennoch möchte ich mal betonen, dass das ne Einstellungssache ist und auf das OS ankommt, was default ist und was nicht. Bei Debian hab ich schon sehr oft beobachtet, dass man die Privacy Extensions wirklich manuell aktivieren muss. Ansonsten hat man als Interface Identifier immer das, was man aus der MAC-Adresse nach EUI64 bildet.

Bei Windows sind hingegen die Privacy Extenstions per default aktiv, da nimmt es für ausgehende Verbindungen automatisch die sog. temporäre IPv6-Adresse, die nicht nur gewürfelt ist, sondern sich auch regelmäßig ändert.

[wanne]

Die IPv6 Privacy Extensions sind das keine Security Extensions.

Ja. Aber es wird extrem schwer die IP-Adresse zu raten. Gegen echte Angriffe hilft es nicht wirklich. Gegen Massenscans nach versehentlich laufen gelassenen Diensten ohne oder mit Standardpasswötern (ähnlich wie NAT) aber schon. Am Ende ist der Schutz der Privatsphäre aber eben auch ein Sicherheitsmerkmal.

Aber wie feltel geschrieben hat, ist der Check nicht bei v6 aktiv.....

Wenn ich das richtig verstanden habe ist er im Gegenteil sogar härter: Statt nur auf den vorderen Teil wird auf die gesamte Adresse gematched.

Bei Debian hab ich schon sehr oft beobachtet, dass man die Privacy Extensions wirklich manuell aktivieren muss. […] Bei Windows sind hingegen die Privacy Extenstions per default aktiv, da nimmt es für ausgehende Verbindungen automatisch die sog. temporäre IPv6-Adresse, die nicht nur gewürfelt ist, sondern sich auch regelmäßig ändert.

Ja: Wie gesagt Debian und Red Hat sind die einzigen mir bekannten OSe, die sie per default aus haben. (Und sich damit so verhalten wie das in der RFC steht.) Tippe, dass das an deren großen Anzahl von Server-Nutzern liegt.

[wanne]

Definitiv auch IPv6 gerade wieder 15 Minuten Beitrag verfasst Session gekillt. Beitrag weg.

[cosinus]

Definitiv auch IPv6 gerade wieder 15 Minuten Beitrag verfasst Session gekillt. Beitrag weg.

Aber unser Admin hat was anderes gesagt?