What every IT person needs to know about OpenBSD Part 3: That packet filter
blog.apnic.net
blog.apnic.net
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.
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.
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.
I guess I should have said "Public Key Authentication" since that would be more reflective of a desirable baseline SSHD configuration.
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).
Worth the risk? Probably not.
(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.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 changes aren't made for the heck of it, they make a more consistent system overall with new knowledge.
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.
I'm an IT person, know nothing about OpenBSD (except that it's an OS), and am doing just fine.
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.
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.
However, I tried it a while back and couldn’t actually make it do anything useful, but that might have been me misconfiguring it.
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...
And I'm surprised OpenBSD only did the bare minimum.
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.
Does anyone know of some large /complex architectures using BSDs?
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)