OpenBSD user Lari Huttunen has a blog post in which he dives into using OpenBSD's rdomain(4) feature to sort work VPNs into separate kernel-level routing tables. This segregates the network traffic in such a way as to prevent traffic in separate routing tables from interacting. With many working from home, insecure work networks have begun to intrude into the home LANs via work-related VPNs. By adding the home network to a work VPN, the LAN becomes merged with work's internal network, usually quite insecure at that. His goal is to keep his personal home devices, especially the IoT items, separate from the now mandatory work-related VPNs on his small-office / home-office network. That way, the work networks can no longer access his appliances.
Problem Statement
Over the years, companies and corporations have become ever more hungry for everything related to their users' geolocation, telemetry, demography, relationsip with one another, interests, convictions, social preferences - you name it. At the same time, users wanting to consume digital services meet a lot of ridiculous restrictions depending on where they live and how they access the Internet. Ecojails, in one form or another are created by multi-national corporations in order to capitalize everything about their users' behavior. In 2020, this has all been exacerbated by everyone suddenly working from home if possible.
Motivation
This is why I wanted to research how identity-based routing could enhance users' privacy in a totally transparent way. I've never been a big fan of VPNs as a security solution, but have come to realize that they have a role to play in privacy. Since soon everything needs to be online to function from a vacuum cleaner to dish washer to toaster, it is increasingly difficult to keep the Internet of Targets at bay. Moreover, our personal telemetry devices feed out a constant stream of information to the ecojail masters, be they Apple, Google, Microsoft, Amazon, Alibaba or Netflix. Taking back control will not be easy and one will evidently need to compromise along the way, but realization is the first step to recovery.
Lari's solution works from tools provided by OpenBSD's base system.
Previously:
(2020) WireGuard Imported Into OpenBSD
(2019) How SSH Key Shielding Works
(2019) Dutch Govt Explains the Risks Behind DNS-Over-HTTPS Move
(2014) OpenSSH No Longer has to Depend on OpenSSL
Related Stories
What has been planned for a long time now, prior to the infamous heartbleed fiasco of OpenSSL (which does not affect SSH at all), is now officially a reality - with the help of some recently adopted crypto from DJ Bernstein. OpenSSH now finally has a compile-time option to no longer depend on OpenSSL, the option `make OPENSSL=no` has now been introduced for a reduced-configuration OpenSSH to be built without OpenSSL.
The result would leave you with no legacy SSH-1 baggage at all, and on the SSH-2 front with only AES-CTR and chacha20+poly1305 ciphers, ECDH/curve25519 key exchange and Ed25519 public keys.
[Editor's Note: This appears to be very much a Work-in-Progress, so might not be available for your distro or via standard repositories.]
Submitted via IRC for chromas
Dutch Govt Explains the Risks Behind DNS-Over-HTTPS Move
The Dutch National Cyber Security Centre (NCSC) explains how DNS-monitoring will get more difficult as modern encrypted DNS transport protocols are getting more popular in a fact sheet published this week.
The fact sheet's audience is represented by system or network admins and security officers who want to move to DNS over TLS (DoT) and DNS over HTTPS (DoH) DNS encryptions protocols that offer increased security and confidentiality.
Both DoH and DoT are designed to allow DNS resolution over encrypted HTTPS connections instead of using the currently common plain text DNS lookups.
Google and Mozilla are both running DoH trials for their browsers, with Chrome to upgrade to a provider's DoH server if it present on a pre-defined whitelist or to a shortlist of fallback providers (i.e., Cleanbrowsing, Cloudflare, DNS.SB, Google, OpenDNS, Quad9) if not.
By only upgrading the DNS resolution to DoH if the users' current DNS provider is supported, Google believes that the users' DNS resolution experience will stay the same.
Mozilla's DoH experiments have already been met with criticism from network admins and Linux distro maintainers after the decision to enable DoH by default and using Cloudflare's DoH server rather than a user's existing DNS provider.
Senior scalability engineer Kristian Köhntopp said that Mozilla is "about to break DNS" seeing that Cloudflare will be used for DNS resolution over the default server assigned by system administrators, leading to leaking visited website addresses inside corporate environments to Cloudflare.
Peter Hessler, an OpenBSD developer, tweeted at the time that OpenBSD disabled DoH in their Firefox package in the current releases and will also disabled it in future ones since "sending all DNS traffic to Cloudflare by default is not a good idea."
On June 21, 2019, support for SSH key shielding was introduced into the OpenBSD tree, from which the OpenSSH releases are derived. SSH key shielding is a measure intended to protect private keys in RAM against attacks that abuse bugs in speculative execution that current CPUs exhibit.[0] This functionality has been part of OpenSSH since the 8.1 release. SSH private keys are now being held in memory in a shielded form; keys are only unshielded when they are used and re‐shielded as soon as they are no longer in active use. When a key is shielded, it is encrypted in memory with AES‐256‐CTR; this is how it works: [...]
https://xorhash.gitlab.io/xhblog/0010.html
http://undeadly.org/cgi?action=article;sid=20200622052207
The WireGuard VPN protocol has been available on OpenBSD as a port for a while, first as the wireguard-go implementation in Go, but later also as the wiresep port in C, both using tun(4) devices, much like OpenVPN and others, which incurs a slight penalty for crossing the kernel/userspace border for each packet.
WireGuard is a layer3 tunnel that can be run in passive mode, only sending packets when something needs to reach the other side (unless you enable heartbeats). It only allows selected modern crypto algorithms and hashes, chosen to be performant on CPUs which lack crypto accelerators, while still being secure. WireGuard packets are sent over UDP, and can run over and transport both IPv4 and IPv6. It handles NAT/port redirects and endpoints changing IP addresses, which is very nice when changing from wired to wifi or vice versa.
Consultant and author Peter N M Hansteen has written up an overview of recent and not so recent changes in OpenBSD that make life better (and may turn up elsewhere too). He covers a few decades of developments that he has found particularly useful and explains why. He covers greylisting, spam filters, OpenSSH, and of course PF.
When I found OpenBSD more than twenty years ago, my main Unix exposure was from working with Linuxes and FreeBSD. What attracted me to OpenBSD and finally had me buy an OpenBSD 2.5 CD set was the strong focus on security and code correctness. When the CD set and the classic wireframe daemon T-shirt finally arrived in the mail, I set about at first to install it on whatever spare hardware I had lying around.
[...] OpenBSD has had traffic shaping available in the ALTQ subsystem since the very early days. ALTQ was rolled into PF at some point, but the code was still marked experimental 15 years after it was written, and most people who tried to use it in anger at the time found the syntax inelegant at best, infuriating or worse at most times.
So Henning Brauer took a keen interest in the problem, and reached the conclusion that all the various traffic shaping algorithms were not in fact needed. They could all except one be reduced to mere configuration options, either as setting priorities on pass or match rules or as variations of the theme of the mother algorithm Hierarchical Fair Service Curve (HFSC for short).
Soon after, another not-small diff was making the rounds. The patch was applied early in the OpenBSD 5.5 cycle, and for the lifetime of that release older ALTQ setups were possible side by side with the new queueing system.
OpenBSD is a complete operating system and originally forked from NetBSD back in 1995 which forked from 386BSD which was ported from 4BSD. It's emphasis is on portability, standardization, correctness, proactive security, and integrated cryptography. The current release, 6.9, is its 50th release.
Previously:
(2020) Using OpenBSD Routing Tables to Segment the Home Network for Privacy
(2020) The OpenBSD Project's 25th Anniversary
(2020) WireGuard Imported Into OpenBSD
(2017) OpenBSD and the Modern Laptop
and many more...
Theologian Dr Corey Stephan has documented his exploration of installing OpenBSD on an old ThinkPad X270. He has posted his rather thorough personal notes which cover the intial setup, such as power management, performance tweaks, Wi-Fi configuration, audio and video, tracking -current, and getting software from the ports tree. He also goes into a bit of his favored tools and workflow.
It is hard not to cherish the partnership of a slightly older ThinkPad and OpenBSD. The ThinkPad X270 and OpenBSD are both minimalist, robust, and customizable. Specifically, the ThinkPad is minimalist with regard to features, robust with regard to physical durability, and customizable with regard to hardware repairability and replaceability. OpenBSD is minimalist with regard to code, robust with regard to security, and customizable with regard to every aspect of the system. Further, since a healthy number of OpenBSD's developers long have used ThinkPads (to the point that I have read some jokes come out of members of their ranks like 'I may use any kind of laptop that I may like, as long as it is a ThinkPad'), the operating system works brilliantly on the laptop — both with their stock settings.
Overall, installing and configuring OpenBSD -current on the ThinkPad X270 was the simplest minimalist installation of any operating system on any hardware that I ever have done, even simpler than Debian GNU/Linux or my beloved FreeBSD (and much simpler than a proprietary, dysfunctional operating system Windows or MacOS). Was the total setup process easier than, say, that of a GNU/Linux distribution that uses the Calamares installer and comes preconfigured with a huge array of GNU/Linux drivers? Well, no, it was not, but that is not the point. OpenBSD is secure, nimble, and customizable in an elegantly simple way that interoperates smoothly with this small ThinkPad for my mobile academic research and writing. Even in this topsy-turvy era in which other popular desktop operating systems are have many design choices for form over function, OpenBSD comes as a serious, professional product that is ready to let me focus on my work.
Previously:
(2021) Recent and Not So Recent Changes in OpenBSD That Make Life Better
(2020) Using OpenBSD Routing Tables to Segment the Home Network for Privacy
(2018) OpenBSD Chief De Raadt Says No Easy Fix For New Intel CPU Bug
and many others.
(Score: 0) by Anonymous Coward on Wednesday December 16 2020, @06:32AM (1 child)
Some folks want to connect their toaster to the internet.
Others simply revel in the Zen [evoke.ie] of toast [liminal.space].
---
Ask not for whom the shill trolls.
(Score: 0) by Anonymous Coward on Wednesday December 16 2020, @06:23PM
Your appliances are talking about behind your back.
(Score: 2, Insightful) by fakefuck39 on Wednesday December 16 2020, @06:42AM (9 children)
seriously, how is my laptop dialing up to the work vpn giving "work" access to my LAN? Oh, it doesn't, because I don't bridge the two networks on the laptop. and if I did, I'd get fired, because *gasp work doesn't want a porn site i open on the local connection to start port scanning servers.
what it looks like is the guy has not been a fan of VPNs. to the extreme he doesn't know what one is. but he doesn't let that lack of knowing what a vpn is, from solving the problems they present. me, I think windmills are evil, because they abuse donkeys by making them spin the wheel to generate useless wind. the wind blows away the white cocaine powder - seriously what's the point of making all that wind. and then the donkey gets high on the coke and dies, and you need a new donkey. this problem can be solved, and a propose the following: an iptables rule to put up a firewall between the wind and the donkey, to cook the cocaine dust into bread, which the donkey could eat as a reward, instead of the banana hanging on a stick in front of him.
(Score: 0) by Anonymous Coward on Wednesday December 16 2020, @08:08AM
If you can teach iptables to cook crack, you're nerdy criminal of the year! Teaching the donkey doesn't count, I've seen animals with less mental capabilitiy and fewer limbs rock up bobos.
What he's complaining about is probably some VPN package the MBAs got sold... My sister's boyfriend had to install some new equipment at their apartment that was apparently necessary for his work VPN.
(Score: 0) by Anonymous Coward on Wednesday December 16 2020, @11:07AM
Keep calm. I know it's annoying but not everybody can be as smart as you are.
(Score: 2, Informative) by Anonymous Coward on Wednesday December 16 2020, @04:07PM (6 children)
If $work$ laptop is connected to your local lan (via wires or wireless) then it is part of that local lan and can:
Now, does $work$ laptop do such things? None of us could know. But it is possible for it to do all of those things. And it can do all of those things all while it is nicely VPN'ed into $work$ at the same time, and unless you are monitoring its traffic, you'd be none the wiser that it is doing such.
The only way to fully protect yourself with a $work$ machine at home is to fully isolate that $work$ machine from your personal lan. In my case, the $work$ laptop, and $works$ hardware VPN box they supply as well, are on an isolated, wired, network segment that connects to a separate Ethernet card in my router (my router is a Linux PC, so dropping in aother ethernet card was easy). Then a few Linux iptables rules to prevent that work-lan ethernet card from seeing, or talking, to the other ethernet cards that do connect to my personal network and the $work$ equipment is fully isolated from my internal network. It can scan, or it can go into promiscious mode all it wants, the only other thing it will see on its network segment is the VPN box. And the VPN box can scan, and monitor, all it likes, all it would ever see is the $work$ laptop and network traffic to/from the $work$ laptop.
(Score: 1) by shrewdsheep on Wednesday December 16 2020, @04:30PM (1 child)
I wouldn't worry about this. Everything is switched nowadays and if still trying to see the traffic, an attacking machine would have to degrade network performance significantly. So it remains 3. to worry about. I do have asocial/ignorant neighbors turning up their WiFi signal such that theirs is stronger than my own (through > 30cm of concrete). This degrades the router WiFi to a point of being unusable. The secondary WiFi is bridged into the main network on which a work Windows machine now has to be. The rest of the network is linux, reasonably configured but not hardened, so I am not worried but still annoyed.
(Score: 1, Informative) by Anonymous Coward on Wednesday December 16 2020, @07:29PM
While true, solely relying on the switch remaining in 'switch mode' sets you up to being open to the arp flood attacks that cause a huge number of switches to flip into 'hub' mode (i.e., broadcast all packets on all ports) from 'switch' mode.
So while I somewhat doubt $work$ would go that far to "monitor" the network, I also did not want to even give the work hardware the option of ever being able to accomplish that exploit.
(Score: 1, Flamebait) by fakefuck39 on Wednesday December 16 2020, @04:36PM (3 children)
lol, another guy who doesn't know what he's talking about. are you the OP's butt buddy?
so your issue is with putting a work laptop on the local lan. zero to do with having it vpn to work. and the way you say you protect your lan... hint. do everything you just described, and remove the vpn box. oh look, same outcome.
(Score: 0) by Anonymous Coward on Wednesday December 16 2020, @07:25PM (2 children)
Another idiot who failed reading comprehension.
Note this part: "and $works$ hardware VPN box".
The "VPN box" is provided by $work$ for use with the work laptop. So yes, removing that box would give the same "outcome", but then the $work$ laptop wouldn't work to connect to $work$ (as the $work$ hardware VPN box is provided by $work$ for use with $work$ laptop to do the VPN operation).
(Score: 2) by fakefuck39 on Thursday December 17 2020, @04:47PM (1 child)
why would I "note" a part that was made up by you just now. work doesn't give you a hardware vpn box. work has a vpn client on the work laptop they give you. you're free to put that laptop in a secured vlan.
let me guess, election fraud - am I right? lots of evidence. very best evidence of election fraud via hardware vpn boxes provided by work.
(Score: 0) by Anonymous Coward on Sunday December 20 2020, @06:09PM
And how do you know that "work" does not hand out a hardware VPN box? Are you capable of mind-reading over SoylentNews?
You don't know who I work for. You don't know what they hand out.
For reference, the hardware VPN box is a Cisco 891FW, details here at Cisco's homepage:
https://www.cisco.com/c/en/us/support/routers/891-integrated-services-router-isr/model.html [cisco.com]
Now, do I think it is silly that they hand this thing out vs. simply using a soft VPN client on the laptop itself, yes. But I don't get to make that call, I just get to use what they decide they want to hand out. And some idiot decided that this physical hardware box checked a check-box on a security compliance form that they must have thought a soft VPN did not check, and now everyone gets one of these things to use at home to connect back in via the work laptop.
(Score: -1, Offtopic) by Anonymous Coward on Wednesday December 16 2020, @08:00PM