alphafalcon

Die API wäre dann vermutlich nicht besser, aber mein Gefühl bei einem Dienstleister (?), der zu faul / planlos ist, seine Webservices auf Standardports ansprechbar zu machen ist nicht gut. Das riecht nach "da hat der Praktikant mal was mit nem Framework auf gebastelt und das ist jetzt produktiv"

Ist mehr ein Gesamteindruck-Bauchgefühl als eine ganz stringente Herleitung, aber ich kann OPs Bedenken durchaus nachvollziehen.

Insbesondere, weil es halt mit "Port auf" nicht getan ist. Da wollen dann noch SSL-Inspection und der Rest vom Regelwerk angepasst werden.

Ah, nicht ganz so komfortabel wie bei der Wii, aber durchaus nützlich scheint mir. Danke für die Erklärung!

Mein erster Gedanke bei "unpatchbar" war die Wii, mit einem Bug in der Signaturprüfung im ROM, hat die Switch ein ähnliches "Feature"?

Profitorientierte Unternehmen orientieren sich an Profit?

Überraschtes Pikachu.jpg

Spaß macht es, wenn Dinge funktionieren.
Ich betreibe meinen k3s Cluster um Kubernetes (etwas) zu verstehen, aber auch weil es für mich besser managebar ist als Docker im Swarm-Modus.
Dazu kommen ein paar technische Features, die Docker AFAIK nicht kann, wie zB Network Policies.
Mein Torrent+VPN-Pod hat eine Network-Policy, die ausgehende Connections nur zum VPN-Gateway erlaubt. Alles andere wird vom Cluster geblockt.

Trotzdem ist es gelegentlich zäh, weil es für wirklich große Umgebungen gebaut ist.

"Mal schnell" einen neuen Service hochziehen ist nicht. Deployment, Services, Ingress, PersistenVolumes definieren und miteinander vertüdeln. Eigentlich sollte man ohne Helm gar nicht erst anfangen.

Eigene Images wie in einem docker-compose File inline zu definieren geht nicht, dafür bräuchte man eine eigene Registry, und einen Prozess der das Image dorthin pusht.

Du hast die quer parkenden Fahrräder auf der "Straße" vergessen /s

You're asolutely right, IP addresses are kind of a grey area since the are needed for lot of troubleshooting and debugging.
Nevertheless, you can always strive to reduce the stored data.
For your application, you wouldn't even need to store the historic IP adresses, just a rough geo-location and maybe a mobile/landline/whatever-flag and comparing the current login attempt to that. Even saves you some performance by not repeating the geo-lookups everytime.
Implement your failed-login counter separately by account and source IP and you've got decent security without linking an account to an IP.

Because collecting data that is not strictly necessary is almost always a bad move. IP addresses might be relatively harmless, but might link you to other activities.

You personally might be okay with reddit knowing your IP addresses, but some people might get into trouble.

Take the insane anti-abortion laws in some US states. If an IP address from those states accesses pro-choice subreddits, that might be enough for law enforcement to start harassing someone.

You dynamically request "a port" from the vpn gateway and it returns your port number.
As long as your nat-pmp-client keeps refreshing the port, it should stay the same. The timeout is rather low (60s afaik) so it probably wouldn't survive restarts.

There's a docker image that automates this for qbittorrent, but it shouldn't be overly complicated to adapt the script to other clients, if they can be configured via an API.

Dyndns hat kein prinzipiell es Problem mit IPv6. Der entscheidende Unterschied ist, dass du nicht mehr die IP-Adresse vom Router verwenden kannst, weil jeder Host eine eigene globale Adresse hat. Auf dem Router muss dann aber trotzdem die Firewall aufgemacht werden.

Very neat idea, but I'd explicitly add strong encryption to that method, cars do get broken into.

I'd encrypt every off-site backup, but a car is a bit more exposed than a rented safe box.

Ja, es ist dann alles nur noch so sicher wie das Bitwarden-Masterpasswort.

Es hat aber auch einen gewissen Vorteil, wenn man die Notfallzugriff-Funktion von Bitwarden nutzt, hat der andere auch wirklich Zugriff auf alles.