Marco Moock <mm+solani@dorfdsl.de> wrote:
> Am 02.05.2024 schrieb Marcel Mueller <news.5.maazl@spamgourmet.org>:
>
>> Und wenn es um die Sicherung öffentlich erreichbarer Accounts geht,
>> dann wären in 5 Minuten alle existierenden Accounts gesperrt, weil
>> irgendein Depp versucht es immer mal. Das wäre quasi ein sehr
>> einfacher Angriffsverktor für eine DOS-Attacke.
>
> Daher macht man das auch nicht pro Account sondern pro IP-Adresse/Netz.
> Dann ist der Kollateralschaden sehr begrenzt und wer meint, sich mit so
> Leuten ein Netz teilen zu müssen, hat halt ein Problem. Mit IPv6 gibt
> es kein CGNAT & anderen Mist mehr und man kann sehr genau den
> Verursacher abstrafen.

TLDR: Deine Idee ist einfach, offensichtlich ... und falsch ;-)

LOL *kicher* *gacker* *auf-dem-Boden-roll* ...

NAT wird selbst bei IPv6 noch praktiziert, gerne aus ... eher fragwürdigen
Gründen, aber es ist im Einsatz. Und speziell CGNAT kann man auch prima
bei IPv6 einsetzen zu Zwecken der Umsatzsteigerung: wer eine aus dem
Internet erreichbare IP will, darf halt extra zahlen.

Und gerade bei grösseren Netzen die intern bewusst nicht routebaren
IP-Bereich einsetzen hat man halt immer mehrere/viele Nutzer hinter
einer/einer Handvoll von egress IP(s).

Besonders lustig wird das, wenn Spielkinder und eigene Mitarbeiter
im selben Netz sind (Hotel, Event, ...) und man die entsprechende
Egress-Adresse der Spielkinder wegen sperrt.

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

Am 02.05.2024 schrieb Alexander Schreiber <als@usenet.thangorodrim.de>:

> Marco Moock <mm+solani@dorfdsl.de> wrote:
> > Am 02.05.2024 schrieb Marcel Mueller <news.5.maazl@spamgourmet.org>:
> >
> >> Und wenn es um die Sicherung öffentlich erreichbarer Accounts geht,
> >> dann wären in 5 Minuten alle existierenden Accounts gesperrt, weil
> >> irgendein Depp versucht es immer mal. Das wäre quasi ein sehr
> >> einfacher Angriffsverktor für eine DOS-Attacke.
> >
> > Daher macht man das auch nicht pro Account sondern pro
> > IP-Adresse/Netz. Dann ist der Kollateralschaden sehr begrenzt und
> > wer meint, sich mit so Leuten ein Netz teilen zu müssen, hat halt
> > ein Problem. Mit IPv6 gibt es kein CGNAT & anderen Mist mehr und
> > man kann sehr genau den Verursacher abstrafen.
>
> TLDR: Deine Idee ist einfach, offensichtlich ... und falsch ;-)
>
>
> LOL *kicher* *gacker* *auf-dem-Boden-roll* ...
>
> NAT wird selbst bei IPv6 noch praktiziert, gerne aus ... eher
> fragwürdigen Gründen, aber es ist im Einsatz.

Manche Leute wollen das so, dann müssen die mit den Nachteilen halt
leben.

Hast du denn dafür auch Beispiele aus der Praxis, bitte von Leute, die
IPv6 verstehen und nicht von Leuten, die ihre IPv4-Infrastruktur
nachbilden wollen?
Bitte ohne dummes Gegacker oder Gelache.

> Und speziell CGNAT kann man auch prima bei IPv6 einsetzen zu Zwecken
> der Umsatzsteigerung: wer eine aus dem Internet erreichbare IP will,
> darf halt extra zahlen.

Sollen die dann bitte machen, wenn Kunden das so wollen. Ich schließe
mit solchen Unternehmen keine Verträge ab.

> Und gerade bei grösseren Netzen die intern bewusst nicht routebaren
> IP-Bereich einsetzen hat man halt immer mehrere/viele Nutzer hinter
> einer/einer Handvoll von egress IP(s).

Wenn man den Bockmist machen will, bitte. Dann muss man halt damit
leben, dass man a) von außen nicht mehr ohne Logs zuordnen kann,
welches System das Paket geschickt hat und b) sind dann alle Teilnehmer
von Rate-Limits und IP-Sperren betroffen.
Wer das will, bitte.

> Besonders lustig wird das, wenn Spielkinder und eigene Mitarbeiter
> im selben Netz sind (Hotel, Event, ...) und man die entsprechende
> Egress-Adresse der Spielkinder wegen sperrt.

Genau deswegen macht man so einen Bockmist auch nicht bei IPv6.
Dann treten die genannten Probleme nicht auf.

Ich habe sowas bisher auch nicht in freier Wildbahn gesehen.
Wenn es da IPv6 gibt, dann per GUA und SPI-Firewall.

Alexander Schreiber <als@usenet.thangorodrim.de> wrote:
>NAT wird selbst bei IPv6 noch praktiziert, gerne aus ... eher fragwürdigen
>Gründen, aber es ist im Einsatz. Und speziell CGNAT kann man auch prima
>bei IPv6 einsetzen zu Zwecken der Umsatzsteigerung: wer eine aus dem
>Internet erreichbare IP will, darf halt extra zahlen.

Das bekommt man freilich aber auch mit einfacheren Mitteln hin als mit
NAT.

>Und gerade bei grösseren Netzen die intern bewusst nicht routebaren
>IP-Bereich einsetzen hat man halt immer mehrere/viele Nutzer hinter
>einer/einer Handvoll von egress IP(s).

Aber solche Netze setzen doch üblicherweise Application Level Gateways
ein. Heute heißt das dann zwar Next Generation Firewall, aber
irgendwas ist ja immer.

>Besonders lustig wird das, wenn Spielkinder und eigene Mitarbeiter
>im selben Netz sind (Hotel, Event, ...) und man die entsprechende
>Egress-Adresse der Spielkinder wegen sperrt.

Ich war neulich in einem vermieteten Büroraum (mit anhängender
Werkstatt, da ist jede Woche ein anderer Mieter drin), aus dessen WLAN
keine VPN-Verbindungen möglich waren, weil ein Bluecoat-Dings im
Datenweg war.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

On 5/2/24 17:09, Marc Haber wrote:
>
> Ich war neulich in einem vermieteten Büroraum (mit anhängender
> Werkstatt, da ist jede Woche ein anderer Mieter drin), aus dessen WLAN
> keine VPN-Verbindungen möglich waren, weil ein Bluecoat-Dings im
> Datenweg war.

Würde da ein SSH-Tunnel helfen?

Ansonsten... Beim OS das 'HV'-Flag im Netzwerkstack setzen. Dann werden
Hochgeschwindigkeitspakete versendet die solche Firewalls einfach
durchschlagen. ;)

Gerrit

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>On 5/2/24 17:09, Marc Haber wrote:
>> Ich war neulich in einem vermieteten Büroraum (mit anhängender
>> Werkstatt, da ist jede Woche ein anderer Mieter drin), aus dessen WLAN
>> keine VPN-Verbindungen möglich waren, weil ein Bluecoat-Dings im
>> Datenweg war.
>
>Würde da ein SSH-Tunnel helfen?

ssh ging natürlich auch nicht durch, SSL-VPNs auch nicht.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

On 5/2/24 20:13, Marc Haber wrote:
> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>> On 5/2/24 17:09, Marc Haber wrote:
>>> Ich war neulich in einem vermieteten Büroraum (mit anhängender
>>> Werkstatt, da ist jede Woche ein anderer Mieter drin), aus dessen WLAN
>>> keine VPN-Verbindungen möglich waren, weil ein Bluecoat-Dings im
>>> Datenweg war.
>>
>> Würde da ein SSH-Tunnel helfen?
>
> ssh ging natürlich auch nicht durch, SSL-VPNs auch nicht.

Was ging denn noch durch?

Gerrit

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>On 5/2/24 20:13, Marc Haber wrote:
>> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>>> On 5/2/24 17:09, Marc Haber wrote:
>>>> Ich war neulich in einem vermieteten Büroraum (mit anhängender
>>>> Werkstatt, da ist jede Woche ein anderer Mieter drin), aus dessen WLAN
>>>> keine VPN-Verbindungen möglich waren, weil ein Bluecoat-Dings im
>>>> Datenweg war.
>>>
>>> Würde da ein SSH-Tunnel helfen?
>>
>> ssh ging natürlich auch nicht durch, SSL-VPNs auch nicht.
>
>Was ging denn noch durch?

http und aufgebrochenes und inspiziertes https.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> http und aufgebrochenes und inspiziertes https.

Ui, vor allem letzteres kann echt ungut werden. Für einen
Hochsicherheitsbereich kann ich sowas ja noch verstehen, nur leider wird
sowas oft bei ganz banalen Szenarien gemacht, wo halt der Chef eines
Mittelbetriebs seine Blechdosenfertigung oder Lackieranlage von
chinesischen Hackern ganz besonders bedroht sieht

/ralph

On 5/3/24 10:22, Marc Haber wrote:
> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>> On 5/2/24 20:13, Marc Haber wrote:
>>> Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>>>> On 5/2/24 17:09, Marc Haber wrote:
>>>>> Ich war neulich in einem vermieteten Büroraum (mit anhängender
>>>>> Werkstatt, da ist jede Woche ein anderer Mieter drin), aus dessen WLAN
>>>>> keine VPN-Verbindungen möglich waren, weil ein Bluecoat-Dings im
>>>>> Datenweg war.
>>>>
>>>> Würde da ein SSH-Tunnel helfen?
>>>
>>> ssh ging natürlich auch nicht durch, SSL-VPNs auch nicht.
>>
>> Was ging denn noch durch?
>
> http und aufgebrochenes und inspiziertes https.

Also muss man nur SSH in http oder https verstecken und hat gewonnen.
Soll heissen, für die Box muss es wie http aussehen, für die Gegenseite
hingegen nicht.

Gerrit

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
> On 5/2/24 17:09, Marc Haber wrote:
>>
>> Ich war neulich in einem vermieteten Büroraum (mit anhängender
>> Werkstatt, da ist jede Woche ein anderer Mieter drin), aus dessen WLAN
>> keine VPN-Verbindungen möglich waren, weil ein Bluecoat-Dings im
>> Datenweg war.
>
> Würde da ein SSH-Tunnel helfen?

BTTT[0]. Nope. Die Bluecoat-Kasterln bei einem vorherigen Arbeitgeber
haben auch protocol inspection gemacht, sshd auf 443/tcp lauschen
zu lassen brachte keinen Erfolg.

Man liest sich,
Alex.
[0] Been There, Tried That.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

Marco Moock <mm+solani@dorfdsl.de> wrote:
> Am 02.05.2024 schrieb Alexander Schreiber <als@usenet.thangorodrim.de>:
>
>> Marco Moock <mm+solani@dorfdsl.de> wrote:
>> > Am 02.05.2024 schrieb Marcel Mueller <news.5.maazl@spamgourmet.org>:
>> >
>> >> Und wenn es um die Sicherung öffentlich erreichbarer Accounts geht,
>> >> dann wären in 5 Minuten alle existierenden Accounts gesperrt, weil
>> >> irgendein Depp versucht es immer mal. Das wäre quasi ein sehr
>> >> einfacher Angriffsverktor für eine DOS-Attacke.
>> >
>> > Daher macht man das auch nicht pro Account sondern pro
>> > IP-Adresse/Netz. Dann ist der Kollateralschaden sehr begrenzt und
>> > wer meint, sich mit so Leuten ein Netz teilen zu müssen, hat halt
>> > ein Problem. Mit IPv6 gibt es kein CGNAT & anderen Mist mehr und
>> > man kann sehr genau den Verursacher abstrafen.
>>
>> TLDR: Deine Idee ist einfach, offensichtlich ... und falsch ;-)
>>
>>
>> LOL *kicher* *gacker* *auf-dem-Boden-roll* ...
>>
>> NAT wird selbst bei IPv6 noch praktiziert, gerne aus ... eher
>> fragwürdigen Gründen, aber es ist im Einsatz.
>
> Manche Leute wollen das so, dann müssen die mit den Nachteilen halt
> leben.
>
> Hast du denn dafür auch Beispiele aus der Praxis, bitte von Leute, die
> IPv6 verstehen und nicht von Leuten, die ihre IPv4-Infrastruktur
> nachbilden wollen?
> Bitte ohne dummes Gegacker oder Gelache.
>
>> Und speziell CGNAT kann man auch prima bei IPv6 einsetzen zu Zwecken
>> der Umsatzsteigerung: wer eine aus dem Internet erreichbare IP will,
>> darf halt extra zahlen.
>
> Sollen die dann bitte machen, wenn Kunden das so wollen. Ich schließe
> mit solchen Unternehmen keine Verträge ab.

Oh, Du hast keinen Mobiltelefon-Vertrag? Ok, das spart Stress. Gerade
die Telcos sind nämlich für ihre oft recht .. interessanten Netzwerk-
strukturen berüchtigt.

>
>> Und gerade bei grösseren Netzen die intern bewusst nicht routebaren
>> IP-Bereich einsetzen hat man halt immer mehrere/viele Nutzer hinter
>> einer/einer Handvoll von egress IP(s).
>
> Wenn man den Bockmist machen will, bitte. Dann muss man halt damit
> leben, dass man a) von außen nicht mehr ohne Logs zuordnen kann,
> welches System das Paket geschickt hat

Kannst Du Dir vorstellen, dass man das als Betreiber eines z.B.
Firmennetzes gar nicht _will_? Mal abgesehen davon, nicht jede
hinreichend grosse Firma hat ein /16 oder grösser rumoxidieren
oder kann auf IPv6-only setzen, es gibt immer irgendwo noch irgend-
welchen Legacy-Kram.

> und b) sind dann alle Teilnehmer von Rate-Limits und IP-Sperren betroffen.
> Wer das will, bitte.

Die Reaktionen dürften von "*gähn*" bei Ottos privater Webseite bis zu
"Ruf mal bei der Rechtsabteilung an" bei Vertragspartnern reichen.

>> Besonders lustig wird das, wenn Spielkinder und eigene Mitarbeiter
>> im selben Netz sind (Hotel, Event, ...) und man die entsprechende
>> Egress-Adresse der Spielkinder wegen sperrt.
>
> Genau deswegen macht man so einen Bockmist auch nicht bei IPv6.
> Dann treten die genannten Probleme nicht auf.

Gerade bei Hotel WiFi habe ich beim WiFi oft nur IPv4 gefunden, RC1918
üblicherweise, also NAT Gateway nach aussen.

Bei Events kommt es halt auf die Kompetenz des Infrastrukturbetreibers
an.

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

Alexander Schreiber <als@usenet.thangorodrim.de> wrote:
>Kannst Du Dir vorstellen, dass man das als Betreiber eines z.B.
>Firmennetzes gar nicht _will_? Mal abgesehen davon, nicht jede
>hinreichend grosse Firma hat ein /16 oder grösser rumoxidieren
>oder kann auf IPv6-only setzen, es gibt immer irgendwo noch irgend-
>welchen Legacy-Kram.

Wer etwas verhindern will sucht Gründe, wer etwas haben will sucht
Wege. Mit dieser Denke werden wir IPv4 nie dorthin bekommen, wo es
hingehört: In einen Legacy-Kellerraum.

Irgendwelche IPv4-Only-Systeme als Ausrede zu verwenden die 90 % des
Netzes, die als IPv6 Only oder IPv6 Mostly problemlos laufen würden,
ist eine sehr kurzfristige Denke. Dual Stack sind zwei Netze, die
Extra Aufwände machen.

IPv4 muss weg. Im bei weiten überwiegenden Teil der Unternehmensnetze
könnte man das dieses Jahr noch haben wenn man es nur machen würde.

Und ja, Docker, Kubernetes und die Dummheit der Hyperscaler-Clouds
haben uns da um Jahre, wenn nicht um Jahrzehnte zurückgeworfen.

>Gerade bei Hotel WiFi habe ich beim WiFi oft nur IPv4 gefunden, RC1918
>üblicherweise, also NAT Gateway nach aussen.
>
>Bei Events kommt es halt auf die Kompetenz des Infrastrukturbetreibers
>an.

Auch bei Hotel-Wifi kommt es auf die Kompetenz des
Infrastrukturbetreibers an. Am besten sind noch kleine Läden mit einer
Fritzbox, da gibt es das IPv6 einfach dazu.

Je mehr Enterprise, desto mehr Legacy IP.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Irgendwelche IPv4-Only-Systeme als Ausrede zu verwenden die 90 % des
> Netzes, die als IPv6 Only oder IPv6 Mostly problemlos laufen würden,
> ist eine sehr kurzfristige Denke. Dual Stack sind zwei Netze, die
> Extra Aufwände machen.

Ich kämpfe diesbezüglich gerade mit dem folgenden Szenario daheim:

Ich habe sehr vieles an IoT-Hardware die nur IPv4-fähig ist, die auch
nicht leicht zu ersetzen ist (Shelly-Devices hinter Lichtschaltern,
ESP32-basiert).

Sonst läuft außer einem alten Drucker alles unter v6, und der alte
Drucker läßt sich im NAT64-Gateway schmerzlos mit einem auf v4 gemappten
Prefix ansprechen, ohne jedes Problem. D.h. Legacy v4 sind relevant nur die
Shellys.

Was aber problematisch ist ist Home Assistant: Die wollen *ein* flaches
Netzwerk haben. Und natürlich soll HA mit den Shelly-Geräten
kommunizieren. Das flache Netzwerk wollen sie unter anderem für mDNS und
diverse andere Device-Discovery-Mechanismen. Du kannst HA in ein
typisches Heim-WLAN stellen, und es wird dir allein 20 oder 30 Geräte finden,
ungefragt, einfach weil die Discovery-Funktionen so gut sind. Die könnte
man brechen, wenn man in VLANs/Subnetze aufspaltet. Die Interna von HA
sind diesbezüglich auch sehr kompliziert (einige Container, ein
Hypervisor, Netzwerk wird irgendwie wild gemappt).

HA ganz ins v4-Netz zu geben geht natürlich auch nicht, weil er z.B.
auch die Unterhaltungselektronik sehen soll, die von den v6-Handys
bedient werden.

Ich hab einstweilen HA ein zweites Interface gegeben (ein Fuß im
v4-Legacy-Netz, ein Fuß im non-Legacy-v6+NAT64+DNS64. Aber beim kleinsten Problem
mit HA werd ich ein bißchen paranoid, dass es an meinem non-standard
Setup liegt, weil ich native v6+NAT64 und v4 in getrennten Netzen hab.

Ich hab auch *ein* flaches "mostly v6" (mit dieser DHCP-Option, die
aktuelle Clients bittet v4 zu ignorieren)-Netz probiert, das hat bei mir
ausgerechnet bei den Chromecasts (Google scheint die Treibende Kraft
hinter "mostly v6" zu sein) nicht funktioniert.

Auf den Windows, Linux, MacOS, Android-Clients läuft NAT64+DNS64
übrigens völlig völlig schmerzlos und transparent bei mir. Die
Android-Clients beschweren sich nach dem Verbinden ins WLAN kurz (halbe
Sekunde oder so) dass sie keine IP kriegen, dann akzepiteren sie, dass
sie v6 only sind.

> IPv4 muss weg. Im bei weiten überwiegenden Teil der Unternehmensnetze
> könnte man das dieses Jahr noch haben wenn man es nur machen würde.

Ja. Definitiv.

> Und ja, Docker, Kubernetes und die Dummheit der Hyperscaler-Clouds
> haben uns da um Jahre, wenn nicht um Jahrzehnte zurückgeworfen.

Yup. Und die ESP32.

/ralph

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Alexander Schreiber <als@usenet.thangorodrim.de> wrote:
>>Kannst Du Dir vorstellen, dass man das als Betreiber eines z.B.
>>Firmennetzes gar nicht _will_? Mal abgesehen davon, nicht jede
>>hinreichend grosse Firma hat ein /16 oder grösser rumoxidieren
>>oder kann auf IPv6-only setzen, es gibt immer irgendwo noch irgend-
>>welchen Legacy-Kram.
>
> Wer etwas verhindern will sucht Gründe, wer etwas haben will sucht
> Wege. Mit dieser Denke werden wir IPv4 nie dorthin bekommen, wo es
> hingehört: In einen Legacy-Kellerraum.

"IPv6 ist das Protokoll der Zukunft, nicht der Gegenwart." wird leider
viel zu oft aktiv so gelebt.

> Irgendwelche IPv4-Only-Systeme als Ausrede zu verwenden die 90 % des
> Netzes, die als IPv6 Only oder IPv6 Mostly problemlos laufen würden,
> ist eine sehr kurzfristige Denke. Dual Stack sind zwei Netze, die
> Extra Aufwände machen.
>
> IPv4 muss weg. Im bei weiten überwiegenden Teil der Unternehmensnetze
> könnte man das dieses Jahr noch haben wenn man es nur machen würde.

Das Problem sind auf der einen Seite irgendwelche alten Enterprise-
kamellen, auf der anderen Seite obscurer Spezialkram u.a. aus der
building automation Ecke. Die Office-Netze könnte man locker auf
IPv6 umstellen.

>>Gerade bei Hotel WiFi habe ich beim WiFi oft nur IPv4 gefunden, RC1918
>>üblicherweise, also NAT Gateway nach aussen.
>>
>>Bei Events kommt es halt auf die Kompetenz des Infrastrukturbetreibers
>>an.
>
> Auch bei Hotel-Wifi kommt es auf die Kompetenz des
> Infrastrukturbetreibers an. Am besten sind noch kleine Läden mit einer
> Fritzbox, da gibt es das IPv6 einfach dazu.
>
> Je mehr Enterprise, desto mehr Legacy IP.

Wie wahr. Da finden sich gar grauslige Konstrukte, besonders bei den
grossen Hotelketten.

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

On Thu, 02 May 2024 20:13:21 +0200
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:

> >Würde da ein SSH-Tunnel helfen?
>
> ssh ging natürlich auch nicht durch, SSL-VPNs auch nicht.

Dafür gibt es SSH over HTTPS.

Falk D.

--
Falk Dµebbert <falk@duebbert.com>

On Fri, 3 May 2024 09:01:24 -0000 (UTC)
Ralph Aichinger <ralph@pi.h5.or.at> wrote:

>
> Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> > http und aufgebrochenes und inspiziertes https.
>
> Ui, vor allem letzteres kann echt ungut werden. Für einen
> Hochsicherheitsbereich kann ich sowas ja noch verstehen,

Ist aber selbst bei den kleinen Checkpoints und Fortinet Standard und
wir richten überall ein, wo auf unbekannte IPs zugegriffen werden darf.

Falk D.

--
Falk Dµebbert <falk@duebbert.com>

Falk Dµebbert <falk@duebbert.com> wrote:
>On Fri, 3 May 2024 09:01:24 -0000 (UTC)
>Ralph Aichinger <ralph@pi.h5.or.at> wrote:
>> Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>> > http und aufgebrochenes und inspiziertes https.
>>
>> Ui, vor allem letzteres kann echt ungut werden. Für einen
>> Hochsicherheitsbereich kann ich sowas ja noch verstehen,
>
>Ist aber selbst bei den kleinen Checkpoints und Fortinet Standard und
>wir richten überall ein, wo auf unbekannte IPs zugegriffen werden darf.

Ich finde das schlimm. Wenn ich auch einsehe dass die Kunden das
wollen. Ist halt Securitytheater wie die Welt es will.

--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Falk Dµebbert <falk@duebbert.com> wrote:
>On Thu, 02 May 2024 20:13:21 +0200
>Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>
>> >Würde da ein SSH-Tunnel helfen?
>>
>> ssh ging natürlich auch nicht durch, SSL-VPNs auch nicht.
>
>Dafür gibt es SSH over HTTPS.

oder den "Ein" Schalter am LTE-Router. Aber dafür mietet man keinen
Raum mit WLAN.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

On 5/7/24 17:20, Falk Dµebbert wrote:
> On Thu, 02 May 2024 20:13:21 +0200
> Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>
>>> Würde da ein SSH-Tunnel helfen?
>>
>> ssh ging natürlich auch nicht durch, SSL-VPNs auch nicht.
>
> Dafür gibt es SSH over HTTPS.

Oder man schaltet im TCP-Stack die Hochgeschwindigkeitspakete frei. Die
sind in der Lage die Firewall zu durchschlagen. Und schon hat man wieder
vollen Netzzugriff.

Vorsicht! Kann zum Austritt des magischen Rauches in der Firewall führen!

;)

Gerrit

On Tue, 07 May 2024 22:12:54 +0200
Marc Haber <mh+usenetspam1118@zugschl.us> wrote:

> >> Ui, vor allem letzteres kann echt ungut werden. Für einen
> >> Hochsicherheitsbereich kann ich sowas ja noch verstehen,
> >
> >Ist aber selbst bei den kleinen Checkpoints und Fortinet Standard und
> >wir richten überall ein, wo auf unbekannte IPs zugegriffen werden
> >darf.
>
> Ich finde das schlimm. Wenn ich auch einsehe dass die Kunden das
> wollen. Ist halt Securitytheater wie die Welt es will.

Das ist weniger wollen als müssen. Aktuell habe ich viele Themen mit
AI-Detektion im Rennen. Die Content-Inspection wird damit noch
aufwendiger. TLS1.3 Dosenöffner sind nur ein Aspekt.

Teilweise wird der Video-Feed von z.B. Youtube oder Videokonferenzen
noch mal extrahiert um die GANS-Detektoren drüberzujagen. Dabei schickt
man die durchaus noch mal in eine Cloud und ggf. wieder zurück.

Falk D.

--
Falk Dµebbert <falk@duebbert.com>

Falk Dµebbert <falk@duebbert.com> wrote:
>Das ist weniger wollen als müssen. Aktuell habe ich viele Themen mit
>AI-Detektion im Rennen. Die Content-Inspection wird damit noch
>aufwendiger. TLS1.3 Dosenöffner sind nur ein Aspekt.
>
>Teilweise wird der Video-Feed von z.B. Youtube oder Videokonferenzen
>noch mal extrahiert um die GANS-Detektoren drüberzujagen. Dabei schickt
>man die durchaus noch mal in eine Cloud und ggf. wieder zurück.

Diesen Job würde ich keine Woche aushalten.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Falk Dµebbert <falk@duebbert.com> wrote:
> Teilweise wird der Video-Feed von z.B. Youtube oder Videokonferenzen
> noch mal extrahiert um die GANS-Detektoren drüberzujagen. Dabei schickt

Mir wird gerade dezent übel. Es ist doch mittlerweile üblich
Vorstellungsgespräche mit durchaus in den "höchstpersönlichen" Bereich
gehörigen Informationen (z.B. Krankheiten, biographische Ereignisse die
man vielleicht weniger explizit in den Lebenslauf schreibt) in
Videocalls zu führen.

"What could possibly go wrong"

/ralph

Ralph Aichinger <ralph@pi.h5.or.at> wrote:
>Falk Dµebbert <falk@duebbert.com> wrote:
>> Teilweise wird der Video-Feed von z.B. Youtube oder Videokonferenzen
>> noch mal extrahiert um die GANS-Detektoren drüberzujagen. Dabei schickt
>
>Mir wird gerade dezent übel. Es ist doch mittlerweile üblich
>Vorstellungsgespräche mit durchaus in den "höchstpersönlichen" Bereich
>gehörigen Informationen (z.B. Krankheiten, biographische Ereignisse die
>man vielleicht weniger explizit in den Lebenslauf schreibt) in
>Videocalls zu führen.

Und wenn man sich nicht gerade auf einen Job in der IT-Security
bewirbt, will man auch nicht mit "bitte bestätigen Sie mir kurz, dass
niemand, auch keine KI, und auch keiner Ihrer Dienstleister, außer
Ihnen dieses Gespräch mithört" anfangen.

Grüße
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

On 08.05.24 13:42, Ralph Aichinger wrote:
> Falk Dµebbert <falk@duebbert.com> wrote:
>> Teilweise wird der Video-Feed von z.B. Youtube oder Videokonferenzen
>> noch mal extrahiert um die GANS-Detektoren drüberzujagen. Dabei schickt
>
> Mir wird gerade dezent übel. Es ist doch mittlerweile üblich
> Vorstellungsgespräche mit durchaus in den "höchstpersönlichen" Bereich
> gehörigen Informationen (z.B. Krankheiten, biographische Ereignisse die
> man vielleicht weniger explizit in den Lebenslauf schreibt) in
> Videocalls zu führen.

Solche Sachen gehören in kein Vorstellungsgespräch!

Josef

Marc Haber, 2024-05-05 08:17:

> Alexander Schreiber <als@usenet.thangorodrim.de> wrote:
>> Kannst Du Dir vorstellen, dass man das als Betreiber eines z.B.
>> Firmennetzes gar nicht _will_? Mal abgesehen davon, nicht jede
>> hinreichend grosse Firma hat ein /16 oder grösser rumoxidieren
>> oder kann auf IPv6-only setzen, es gibt immer irgendwo noch irgend-
>> welchen Legacy-Kram.
>
> Wer etwas verhindern will sucht Gründe, wer etwas haben will sucht
> Wege. Mit dieser Denke werden wir IPv4 nie dorthin bekommen, wo es
> hingehört: In einen Legacy-Kellerraum.
>
> Irgendwelche IPv4-Only-Systeme als Ausrede zu verwenden die 90 % des
> Netzes, die als IPv6 Only oder IPv6 Mostly problemlos laufen würden,
> ist eine sehr kurzfristige Denke. Dual Stack sind zwei Netze, die
> Extra Aufwände machen.

Wenn die IPv4-only-Systeme nicht einfach ersetzbar sind, ist es eben so.

Ich schmeiße sicher ein halbes Dutzend Geräte weg, nur weil Tasmota kein
IPv6-only beherrscht:

<https://tasmota.github.io/docs/IPv6/>

"Tasmota does not support IPv6 only networks, and it will yield to a
crash after some time (may be fixed in the future)."

> IPv4 muss weg. Im bei weiten überwiegenden Teil der Unternehmensnetze
> könnte man das dieses Jahr noch haben wenn man es nur machen würde.

Yep.

> Und ja, Docker, Kubernetes und die Dummheit der Hyperscaler-Clouds
> haben uns da um Jahre, wenn nicht um Jahrzehnte zurückgeworfen.

Immerhin beherrscht Docker mittlerweile IPv6, wenn auch noch
"experimentell".

--
Arno Welzel
https://arnowelzel.de