

Hard disagree. It only applies for things you cannot change but should try to accept rather than stressing over it.
If you say “it is what it is,” in reference to things you could change but choose not to, well that’s on you.
Hard disagree. It only applies for things you cannot change but should try to accept rather than stressing over it.
If you say “it is what it is,” in reference to things you could change but choose not to, well that’s on you.
It’s not exactly clear what the main goal is here and it sounds like a bad idea on first glance after reading your last paragraph. But it sounds like you might be looking for mandatory profiles.
But now that I read it again I think you might be conflating users/profiles with sessions. In which case no, this is neither possible nor a good idea. But it still might be okay with mandatory profiles if the device and app works the same from multiple sessions.
Anyway, you might get better answers if you state the full problem, including details on software and device, not just your proposed solution.
Yep this is exactly right. Too many people are unaware that their votes are not anonymous on Lemmy and blocking the public tool only helps the bad guys who already know this. I’ve always thought this was a major weakness in Lemmy but I don’t have a solution myself without some other major drawback.
I think probably votes should be anonymized or batched between servers so that only your instance’s admins can see individual votes and you just have to trust the instances you federate with that they aren’t pulling any shenanigans or otherwise defederate. That’s not an easy problem to solve, but it’s not like it’s not currently possible to manipulate votes with a federated server, it would just be harder to detect. Regardless I think the need for privacy wins here.
The easiest way that doesn’t affect the main network would be to use a travel router. Its WAN IP would be the private IP it gets from the main network (over wireless since that’s your only option). And it would NAT your network onto that IP and then you can do whatever you want on your network.
I’m not sure if that Mikrotik router will do this but it might. You basically need something that can connect to an SSID and use that interface as its WAN interface. The wireless factor here is really limiting your choices. If you had a wired uplink to the main network you could use any router/gateway/firewall you wanted. You could also use an AP in bridge mode to connect to the main network’s SSID and wire it to the WAN port of any router of your choice.
You don’t really need to use VLANs to separate your network from the main network unless you want to share any of the same layer 2 segments (basically wired Ethernet) while keeping it isolated. But it doesn’t really sound like that applies in your scenario. Of course using VLANs within your network would still make sense if that applies (for example, to separate your server traffic from your IoT traffic).
Definitely malware, as everyone has already said.
This is a good answer.
To add, for Linux kernels, the maintainer use a shim EFI package with the distro’s keys (e.g., Canonical’s keys for Ubuntu) which loads the maintainer-signed kernel. And Microsoft signs the shim to keep the chain intact.
I’m Ron Burgundy?
What you should be worried about more than a keylogger is that most 2.4 GHz wireless keyboards can have the keystrokes sniffed through the air. Bluetooth will be encrypted though.
“To read the purported PDF document, victims are persuaded to click a URL containing a list of steps to register their Windows system. The registration link urges them to launch PowerShell as an administrator and copy/paste the displayed code snippet into the terminal, and execute it.”
This is not new, nor is it newsworthy.
Yep that’s how I have Syncthing set up. All global and local discovery disabled, no firewall ports open on the clients, no broadcasting, no relay servers. Just syncing through a central server which maintains versioning and where the backups run. Works like a charm.
As another poster mentioned, QubesOS with anti evil maid will work, but that’s the defense against state actors too and is overkill for this threat model.
BitLocker or any FDE using SecureBoot and PCR 7 will be sufficient for this (with Linux you also need PCRs 8+9 to protect against grub and initramfs attacks). Even if they can replace something in the boot chain with something trusted, it’ll change PCR 7 and you’d be prompted to unlock with a recovery key (don’t blindly enter it without verifying the boot chain and knowing why you’re being prompted).
With Secure Boot alone, the malicious bootloader would still need to be trusted (something like BlackLotus).
Also make sure you have a strong BIOS password and disable boot from USB, PXE, and anything else that isn’t the specific EFI bootloader used by your OS(es).
Yeah this article is complete garbage. Who upvotes this stuff?
Not that it’s my first recommendation for security reasons, and I would never do this in prod, but you can just add the self-signed cert to the local trusted root CA store and it should work fine. No reg changes needed.
If you do this, put it in the store of the user running the client, not LocalMachine. Then you just need to make sure you connect as something in the cert’s SAN list. An IP might work (don’t know since I never try to put IPs in the SAN list), but just use a hosts entry if you can’t modify local DNS.
Edit: after reading the full OP post (sorry), I don’t think it’s necessarily the self-signed cert. If the browser is connecting with https:// and presenting a basic auth prompt, then https is working. It almost sounds like there is a 301/302 redirect back to http after login. Check the Network tab of the browser’s dev pane (F12) to see what is going on.
Wow Forbes cybersecurity reporting is absolute dog shit. So much text to say absolutely nothing useful.
Anyway, this is just an AITM redirection onto a malicious site in the middle that pretends to be the MFA portal and intercept the session cookie.
I use it for providing a text summary of YouTube videos that I can parse quickly. Because everything has to be a gorram video these days.
Yeah you really need a password or TPM PIN protector to protect from cold boot attacks if that is in your threat model.
Bitlocker is extra vulberable because it stores the key in the TPM and requires no password to boot. An attacker can extract the key even if the computer is off when they get it.
This is not true.
You would additionally need to bypass Secure Boot with a separate exploit such as the one in this article (which is mitigated by disabling USB boot) or LogoFAIL to put the TPM PCRs in a state where the keys can be released.
LUKS2 is no different here as either can be TPM-only or require a separate PIN.
This is like the epitome of the XY Problem.
This isn’t Microsoft’s announcement. They announced over a month ago. This also only affects bulk senders sending over 5,000 emails a day inbound to their Hotmail/Outlook.com service.
And if you can’t send DMARC-compliant emails in 2025, frankly you deserve to be blocked.