Normally i do it once a month, but could have easily forgot this summer. So might have hit that 3 month zone.  I just assumed that ( much like DHT ) there were a few well known entry nodes that everyone hits first, it and then collect more for next time once 'in'. 

Ill have to just be more diligent on doing monthly updates. 

Fri Nov 24 2023 08:59:40 EST from darknetuser

Typically, your client should pick a guard node (entry point) and use it for an extended period of time (say, 3 months).

If you take long between Tor sessions, it can be that yout Tor instance has outdated circuitry information and is trying to figure out the current state of the network.

I assume that NGINX native could, but im using an 'easy manage' version, unsure if it will do it, but i will look tonight..   But that said, having the little extra in between, makes me feel a little safer.  Its just frustrating i have extra hoops to  jump thru due to ass-hats.  NGINX is taking care of the name routing for me, not just the SSL.

These days, Traefik is the favorite for that sort of thing ... it plays especially nice with containers.  MetalLB is also a favorite; I've used it often because it can be automatically installed as part of MicroK8S (which I use heavily).

Do you have any actual web sites on your NginX or are you only using it as a reverse proxy?

The machine that runs www.citadel.org is running NginX.  Originally it was just virtualhosting a bunch of its own sites, but now it's also running as a reverse proxy for a few things in containers.

All the sites i have published go thru it. Both for SSL and for incoming name resolution. I only have one IP here at home.  All are separate VMs using its reverse proxy / port forward stuff.  ( not sure how you would run a site ON nginx i thought it was only pass-thru ) Right now, all have front end passwords via nginx to get past first, THEN the app password. ( paranoia .. )

• AI chat 
• AI images 
• Nextcloud ( frustrated discussions earlier about that.. issues with DoS floods )
• Guacacmole 
• The Village was, and if i get around to putting it back up, it will be again. Normally dont have the 2nd password layer on this.
• OpenSim ( using DivaGrid to give it a web interface ) no 2nd layer auth here either.
• JellyFin
• My service desk was, when i was still doing consulting. its gone now. i dont see that coming back.
• Fossil ( tho normally this server is off, dont need it often. but i keep the SSL cert up to date )
• And of course anything im testing with.. 

Tue Jan 02 2024 22:20:18 EST from IGnatius T Foobar

Do you have any actual web sites on your NginX or are you only using it as a reverse proxy?

 

sorry its YT but this is an interesting, and not theoretical but real, discussion about AI worms being propagated via AI reading your mail, then getting false commands ( in effect ) to leak your data, and propagate to your friends.  All via zero-click actions.   ( at least zero click to you.. the AI did the 'click', in effect )

https://www.youtube.com/watch?v=4NZc0rH9gco

What started as a joke at the office, found out i was actually foretelling the future.

On top of passwords, MFA, they are now going to issue USB pass-key devices, i guess keyed to your personnel ID.  ( tho i had those old key generator cards to the joke, its the same concept really just no typing)

Anyone dealt with these things?

If so..

• How rugged are they? Are we going to end up with lots of things breaking and people being screwed, having to drive in to get a replacement or something all the time? ( some cant.. they are across the country or even out of the country )
• I assume they work with windows and OSX just fine, but what about VDI from Linux or ChromeOS or web? ( unsure if VDI wil require it.. just random thoughts )
• What about local VMs, ( KVM in my case ) think just doing a USB pass-thru would be enough or will it detect ts not a 'real' port and freak out?

that is encouraging.  Here *everyone* will get them. Some 40k employees.

The VDI part, not sure if that will be required, but if not, its a way around the rules.  So im willing to bet they will, somehow.

This could fall in a lot of rooms. but after some talking it turns out its due to a security concern. so here it goes..

Been talking to a guy at work, hes trying to share a usb device between multiple VM guests. ( KVM/QEMU ).  Putting aside the issue of sharing a single device between machine and the natural issues you might get, i suggested he just allocate the device to all the VMs and then only access it one at a time, and even tho no guarantee it would not totally freak out.

I guess his end goal is actually to attach the device to one VM, and share it from there, not from the server. Hes leaning to IP sharing ( which i have seen used between physical servers, but never touched ) Asking why, 'security concerns', about pieces of the underlying GPU management stuff being in user-land. Personally, i don't think its THAT huge of a risk and not sure how that would actually help, but to him it is, so that is where we are starting from.

Since im now in way over my head, thought id see if any of you all might have an idea for him.

The last bit of discussion went like this ( now that you have some context ):

____

Mostly security reasons. VirtIO is not inherently unsafe, but there are discussions online about security boundaries in derivative software. Prime example of that is userspace "slicing" of GPUs - also known as VirGL (Proxmox exposes the option of VirGL integration in its menus when creating a VM).

The problem is that VirGL runs in userland and its developers have confirmed that it does not include security boundaries by default, and already assumes that other software has mitigations in place to protect it from theoretical privilege escalation attacks.

The safest solution in this case is to isolate it in a VM which is disconnected from the rest of OpenSwitch (or any other KVM-compatible networking interface) and then strictly use internal RPC mechanisms (for QEMU that's QEMUGuestAgent) to "pass-through" VFIO-like slices of the integrated GPU from the isolated Guest to other VMs.

There is on-going work to port virt-host-user to QEMU to get such functionality working, but it's alpha and seems to be somewhat hacky at the moment. Unfortunately, outside of enterprise RDMA-esque networks, there's almost no support for VFIO devices other than networking gear to be shared over IP/RPC.

_______

"yes, we use SSO"  "You will have to sign up separately for each of our applications and add them into your phone's authentication app"

Then how the F is it SSO then?? Might be MFA, but not SSO.

American water 'security breach' yesterday.  Said no "utility systems" effected but took stuff off line. 

With luck they didnt steal all the stuff from us who have auto debit..  Tho my bank watches for that stuff, and you get a refund, its still a hassle. 

Ouch.

CVE-2024-9486 and CVE-2024-9594: VM images built with Kubernetes Image Builder use default credentials