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
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.
(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.
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.
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.
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.
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.
If you "click on a link" you won't type in your secret key (barring insecure ssh-agent set up) - but you might type in your password - for example sending it to a proxying ssh daemon despite a warning about changed host keys.
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.
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.
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.
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.
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.
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.
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:
queue outq on re1 flows 1024 bandwidth 3000K max 3000K qlimit 1024 default
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.
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?
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)!
