2023-11-24 07:56 from Nurb432
TOR Question: Do the official entry points change every so often?
Reason i ask is i dont get on often, but did this morning just to get
updates ( using the bundled Firefox thingie, not a service or
anything, and all default settings ) and it refused to connect.
Everything was timing out affording to the log. Wondering if my ISP
was doing something, tried the snowflake bridge, again, timeout.
Tried another bridge set ( obfs ) and it did connect, then updated..
Now it works without bridges.
I would have thought that as long as the project itself was alive,
the main entry points would be stable?
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.
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 darknetuserTypically, 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 FoobarDo 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
2024-03-13 09:19 from Nurb432
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
I will check it later.
BTW, when I share a YT link, I do it as an invidious link so YT does not profit. Eternal war to google!
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,
Cool, so the "we have video of you watching pr0n and we're going to send it to all your contacts" spam/scam can now be followed through without any action on the victim's part.
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?
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?
Top tier personal here (myself included) gets one.
The ones we have are encased in cheap cases but so far none has broken in years. This is good because backing credentials up and restoring them is a bitch with these things - in practice you generate new credentials for the user.
So far the ones we have are Linux, FreeBSD and OpenBSD compatible. USB-passthrough would do the trick. I don't know about remote desktops. Some of these things need to issue low level instructions.
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.