What every IT person needs to know about OpenBSD Part 3: That packet filter(blog.apnic.net)
blog.apnic.net
What every IT person needs to know about OpenBSD Part 3: That packet filter
https://blog.apnic.net/2021/11/11/openbsd-part-3-that-packet-filter/
49 comments
Maybe one day I'll need access from somewhere without my key.
Worth the risk? Probably not.
Worth the risk? Probably not.
Two possible answers to that:
(a) Since you should be storing your private key on a Yubikey/Nitrokey type device, take it with you wherever you go. To be clear, I'm not advocating doing remote admin tasks from an untrusted computer, but in a desperate situation you could do it from a semi-trusted device with a Yubikey/Nitrokey since it won't be possible to extract the private key (and you can set mandatory Touch + PIN policy on the key to prevent malicious software using the hardware token in the background without your explicit consent). and/or
(b) Implement an SSH CA and use that to generate short-lived emergency keys (e.g. https://smallstep.com/blog/ssh-emergency-access/), someone "back home" could send you a short-lived key in a secure manner.good point, seems the risk IS worth it for a lot of ppl
does a bot know or care your ssh server instance accepts no usernames/passwords? trapping abusive clients that make too many connections for whatever reason is good practice and pf makes it ridiculously easy.
SSH keys are just long passwords.
An SSH password is sent to the server, the server will get the exact password.
An SSH private key is not sent to the server.
Exactly, so even if the server is compromised you're not giving it the means to authenticate as you. I think this is a huge plus.
Maybe, but it conceptually it doesn't have to be like that. Often, the password is not sent directly, but its hash is sent (sometimes hashed multiple times), so that the same property is true.
If you send a hash, the hash itself effectively becomes the password. If the server is compromised or the hash is intercepted, the attacker has everything they need to authenticate as you.
With private/public key pairs, the same scenario would result in the attacker only obtaining your public key, which is useless without the private key.
With private/public key pairs, the same scenario would result in the attacker only obtaining your public key, which is useless without the private key.
You are correct and I was sloppy in explaining it properly.
In general however, I believe that there is no inherit advantage of certificates over passwords, except for the key-size obviously. Everything else is just convention/standards.
Please see the following page that explains better what I meant when I said that the password should be hashed: https://en.wikipedia.org/wiki/Hash_chain
Using such a mechanism (including salts / challenges) will prevent an attacker using the hash as the password.
In general however, I believe that there is no inherit advantage of certificates over passwords, except for the key-size obviously. Everything else is just convention/standards.
Please see the following page that explains better what I meant when I said that the password should be hashed: https://en.wikipedia.org/wiki/Hash_chain
Using such a mechanism (including salts / challenges) will prevent an attacker using the hash as the password.
> SSH keys are just long passwords.
They're really not, they are private/public key pairs.
Now, sure, if you have a public key, and a guess at a private key - you can check if said guessed private key can derive the public key - but unless you know something no one else does - there's no practical way to enumerate and guess the key space.
But a password may be arbitrarily short and eg a random password of 8 mixed-case letters, numbers and some symbol is "just" log2((26*2+10+10)^8) ~ 50 bits (rounded up). Now that's probably not feasible to brute force on-line (without anyone noticing) - but quite feasible off line (if you're patient - but you don't have to be immortal).
They're really not, they are private/public key pairs.
Now, sure, if you have a public key, and a guess at a private key - you can check if said guessed private key can derive the public key - but unless you know something no one else does - there's no practical way to enumerate and guess the key space.
But a password may be arbitrarily short and eg a random password of 8 mixed-case letters, numbers and some symbol is "just" log2((26*2+10+10)^8) ~ 50 bits (rounded up). Now that's probably not feasible to brute force on-line (without anyone noticing) - but quite feasible off line (if you're patient - but you don't have to be immortal).
That is why I said "long password". Once it takes over 1000 years to brute force a password, you should have much bigger problems to worry about. On average someone will click on a link in a spam e-mail, or fall for another phishing attack much more frequently than once a 1000 years.
He’s not talking about ssh keys, but ssh certs. As provided off the shelf by bless (Netflix), vault, step-ca, etc. they remove the burden of managing keys. For example you can give a single command a short-lived ssh cert that is only valid as long as the command takes to run and then expires.
For clarity, yes I did say certs. But even good old SSH keys are a million miles better than passwords.
I guess I should have said "Public Key Authentication" since that would be more reflective of a desirable baseline SSHD configuration.
I guess I should have said "Public Key Authentication" since that would be more reflective of a desirable baseline SSHD configuration.
SSH certificates can sign a key with an expiration, thats a bit different to a password.
Unfortunately since BSDs don't support the most popular way to build apps these days, a microservice architecture backed by Docker and Kubernetes, I don't think they will get much traction.
Does anyone know of some large /complex architectures using BSDs?
Does anyone know of some large /complex architectures using BSDs?
MacOS is partly a freebsd derivate, Netflix-cdn runs on freebsd, bigiron controlplane (junos,ios) is often netbsd based, enterprise storage (netapp) also ... there was a list on wikipedia iirc (canot find atm)
You know what's funny? Your comment exactly highlight why the BSD family has completely lost the OS war: this thread is about OpenBSD, and now you're commenting with Mac OS, FreeBSD and NetBSD, which have diverged from one another almost 30 years ago (just 20 years ago for MacOS X)!
you are right, but parents question was about the BSDs in general.
"the most popular way to build apps these days for certain projects" -- there i fixed that for ya.
been building web apps for 20 years and what you describe as most popular was never the best choice for my clients. (and i hope to keep it that way)
been building web apps for 20 years and what you describe as most popular was never the best choice for my clients. (and i hope to keep it that way)
BSD has jails which is a superior solution. Not as hyped, sadly.
And let's not forget:
https://bastillebsd.org/
and
https://pot.pizzamig.dev/
https://bastillebsd.org/
and
https://pot.pizzamig.dev/
superiority and hype aside, jails is not compatible with docker and thus no answer to the demands of the industy or OP
I used pf + carp on OpenBSD in 2004. It was really awesome to failover from 1 firewall to the other without losing tcp + udp states for all the servers and clients behind the cluster. pf is really powerful. pf on OpenBSD even more! Another nice features is to tweak some tcp options per rules. Let's say you want to fast expires tcp port 443 connections to your cdn servers but, still keep normal tcp timeouts for the rest. Nice article
[deleted]
Be aware that OpenBSD can, will, and often has, made breaking changes to their packet filter/firewall rule syntax. Keep that in mind if you decide to rely on this for a firewall that's remote and not practical to access but requires patch maintenance without OOB access.
It’s unlikely patches will cause syntax changes.
Upgrading between versions might, but that requires you to manually run sysupgrade anyway, at which point you probably should be reading the release notes, which should mention it.
Do you have any examples where it happened without being mentioned in release notes, or without a version bump?
Upgrading between versions might, but that requires you to manually run sysupgrade anyway, at which point you probably should be reading the release notes, which should mention it.
Do you have any examples where it happened without being mentioned in release notes, or without a version bump?
The most recent change, which user likes to complain about every chance they get, is that some invalid port ranges are now rejected instead of being incorrectly accepted.
https://www.openbsd.org/faq/upgrade69.html
https://www.openbsd.org/faq/upgrade69.html
GP didn't say that they make breaking changes without documenting them, that would be horrific. The point is that they apparently make breaking changes, which is quite a nuisance. I'd rather avoid software that doesn't attempt backwards-compatibility between major releases. It can be done.
They do not break it every release. The last one I had to be concerned about was 6.8->6.9 and I remember one breaker before that (the queue thing?). You have six months to make mostly minor changes to pf.conf before you are out of support. They release every six months and patch the last release.
The changes aren't made for the heck of it, they make a more consistent system overall with new knowledge.
The changes aren't made for the heck of it, they make a more consistent system overall with new knowledge.
> They do not break it every release
No one in the comment chain claimed otherwise. Breaking changes every rand() * (6 months) is not much better than breaking changes every 1 * (6 months). It still means you have to validate your firewall configs once or twice a year and randomly need to push these changes to network appliances with the same cadence. A key benefit of application stability is not having to constantly read release notes and check if your use case is affected by the changes.
> You have six months to make mostly minor changes to pf.conf before you are out of support. They release every six months and patch the last release.
Yes, they have a schedule for rolling out breaking changes. This is a maintenance burden.
> The changes aren't made for the heck of it, they make a more consistent system overall with new knowledge.
The same is true of many breaking changes in applications and APIs broadly. A cleanly designed system does not magically make the ensuing maintenance burden disappear. We probably all agree that OpenBSD and pf are well designed but we should not ignore its costs.
No one in the comment chain claimed otherwise. Breaking changes every rand() * (6 months) is not much better than breaking changes every 1 * (6 months). It still means you have to validate your firewall configs once or twice a year and randomly need to push these changes to network appliances with the same cadence. A key benefit of application stability is not having to constantly read release notes and check if your use case is affected by the changes.
> You have six months to make mostly minor changes to pf.conf before you are out of support. They release every six months and patch the last release.
Yes, they have a schedule for rolling out breaking changes. This is a maintenance burden.
> The changes aren't made for the heck of it, they make a more consistent system overall with new knowledge.
The same is true of many breaking changes in applications and APIs broadly. A cleanly designed system does not magically make the ensuing maintenance burden disappear. We probably all agree that OpenBSD and pf are well designed but we should not ignore its costs.
all software that strives for quality and not keep old rotten stuff has deprecation cycles (python, django, etc) and i vastly prefer that to "i'll never have to touch a config file again". openbsd's deprecation cycle is just shorter than the rest of the industry. their manpower and donations are way more limited as well.
But it doesn't have QoS, right? Sure, shaping is all well and good, but this really all there is to it in OpenBSD.
I was shocked that a server OS this old could be this immature on something this basic.
It pretty much excludes it from being a serious router/firewall.
I was shocked that a server OS this old could be this immature on something this basic.
It pretty much excludes it from being a serious router/firewall.
I am not sure what is meant by this. It certainly seems to have QoS in the form of the queue directive. It works for me for limiting buffer bloat on my VDSL model upstream. The defaults work well for my VOIP stuff so that all I have is this in my pf.conf:
Added: Relevant articles:
* https://dataswamp.org/~solene/2021-08-30-openbsd-qos-lan.htm... * https://www.pauladamsmith.com/blog/2018/07/fixing-bufferbloa...
queue outq on re1 flows 1024 bandwidth 3000K max 3000K qlimit 1024 default
Added: Relevant articles:
* https://dataswamp.org/~solene/2021-08-30-openbsd-qos-lan.htm... * https://www.pauladamsmith.com/blog/2018/07/fixing-bufferbloa...
Like I said, this is a very superficial view of QoS.
And I'm surprised OpenBSD only did the bare minimum.
And I'm surprised OpenBSD only did the bare minimum.
as said, the "flows" keyword actually summons fq_codel to the task which represents the state of the art in sane-by-default QoS implementations.
Not sure what exactly you mean by QoS, but there is the `prio` keyword, which lets you put packets into priority queues.
However, I tried it a while back and couldn’t actually make it do anything useful, but that might have been me misconfiguring it.
However, I tried it a while back and couldn’t actually make it do anything useful, but that might have been me misconfiguring it.
you can filter packets by TOS bits and queue them the way you want
OpenBSD is pretty good by default. Traffic with different TOS is separately queued with reasonable priority defaults. So you normally don't have to do anything.
I was a bit surprised that my VOIP stuff was just working when I moved my router from Linux to OpenBSD and had to go looking to figure out why.
I was a bit surprised that my VOIP stuff was just working when I moved my router from Linux to OpenBSD and had to go looking to figure out why.
state of the art is to put packets into separate queues based on the 4-tuple (src,dst,port) then dequeue them fairly based on packet- and queuesize
You can drag that annoying colorful star off screen on mobile btw.
Every IT person doesn't need to know about OpenBSD at all. Clickbait title.
I'm an IT person, know nothing about OpenBSD (except that it's an OS), and am doing just fine.
I'm an IT person, know nothing about OpenBSD (except that it's an OS), and am doing just fine.
I'm sorry for you, sometimes being interested in more then you use for daily work can greatly improve you work.
hypertele-Xii didn’t say anything about whether or not they were personally interested in the subject matter. He/she was complaining about the click-bait title that would be more likely to discourage them from reading the article. The vast majority of web articles titled “… you need to know” are junk. I wouldn’t have read the article only I saw it was from APNIC.
Agreed, and you made an excellent call there.
If network ops is your bag, then yeah, maybe you "ought to" know about what's in the article.
Otherwise -- it's just pure FOMO-based clickbait.
If network ops is your bag, then yeah, maybe you "ought to" know about what's in the article.
Otherwise -- it's just pure FOMO-based clickbait.
The lengthly part that talks about defeating SSH dictionary attacks through some fancy PF rules.
Why, in 2021, is anybody still writing articles talking about using passwords with SSH and saying the way to counter password attacks on SSH is to write firewall rules ?
SSH Certificates are the only method anybody should be implementing these days. Its not difficult to setup or maintain, its nothing put pure laziness that people don't do it.
I would have thought someone writing on an APNIC blog would know better.