Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.
> > -- Forwarded message -- > From: Kevin Chadwick > To: misc@openbsd.org > Cc: > Bcc: > Date: Sun, 14 Jun 2020 13:58:39 + > Subject: Thoughts or links on optimally secure defaults for pf.conf and > fstab, whilst aiming to minimise support issues. > We are basing the server part of our products on OpenBSD. > > We care more about reducing support issues than say performance. > > We will have batteries but I hope to deploy some kind of root partition > redundancy, for upgrades. > > However, Is sync or softdep a better default for the best chance of avoiding > manual fsck/support issues? Hello, I just recently got to use OpenBSD (before FreeBSD, before that Linux) and what I found out about recently is FuguIta [1], it seems to be a OpenBSD Live System, where you can create an encrypted partition and save state data to it (etc, var, etc.), then read that back after boot into memory, with that you could have memory only solution going, which, as they say on their website, can work with as little as 64MB of ram (without X use). Now I imagen if you distribute your software on top of OpenBSD, you could manage to use FuguIta to create your own install system, as you control the hardware, you can configure the boot without user interaction (on their website they describe how to create your own system. So, If I needed more resilience against power outtages, I would give fuguIta a try, but of course it depends on your configuration and the software you are running / service you are providing. Best Rai [1] http://fuguita.org
Re: Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.
On 2020-06-14, Kevin Chadwick wrote: > We are basing the server part of our products on OpenBSD. > > We care more about reducing support issues than say performance. > > We will have batteries but I hope to deploy some kind of root partition > redundancy, for upgrades. You'll need to cope with /usr for upgrades too, OpenBSD breaks binary compatibility fairly often (mostly system call changes - at a guess roughly every 2-3 releases - and some other things like the arm and aarch64 abi change last autumn). You can't expect an old kernel to work with new userland and vice-versa. > However, Is sync or softdep a better default for the best chance of avoiding > manual fsck/support issues? Probably softdep, but it brings its own issues. Transient storage io faults (disk slow to respond) which might correct themselves without softdep often cause the machine to crash with softdep, and it has to store the filesystem changes in memory before it writes them out, which can be a problem if memory is already tight. > Turns out the issue that I had on pkg_add/ftp, that seemed to be eliminated by > switching to 3g was somehow, a short lived reprieve and was more to do with > re-assembly settings that had worked for me flawlessly, for years on a > landline. > > I believe scrub had no-df before and I am now using without issue, so far. > > set reassemble yes no-df > match scrub (random-id max-mss 1389) > > Should I drop the no-df from set reassemble? Any other recommendations > welcome? If you have mixed MTUs (e.g. forwarding packets from an ethernet interface over some ppp/vpn/encapsulated links which can't handle 1500 byte packets) then for some traffic (connecting to sites with broken firewalls that block all ICMP) you may need no-df on the scrub rule. >From the description in pf.conf(5) no-df on "set reassemble" is something else, can't say I've ever needed to use that. > Any thoughts or links on the most secure pf.conf that remains being compatible > with any network? "block" :)
Re: Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.
On 2020-06-14 13:58, Kevin Chadwick wrote: > set reassemble yes no-df > match scrub (random-id max-mss 1389) > > Should I drop the no-df from set reassemble? Any other recommendations > welcome? To be clear. Previously, with scrub (no-df... the set reassemble line was missing/default.
Thoughts or links on optimally secure defaults for pf.conf and fstab, whilst aiming to minimise support issues.
We are basing the server part of our products on OpenBSD. We care more about reducing support issues than say performance. We will have batteries but I hope to deploy some kind of root partition redundancy, for upgrades. However, Is sync or softdep a better default for the best chance of avoiding manual fsck/support issues? Turns out the issue that I had on pkg_add/ftp, that seemed to be eliminated by switching to 3g was somehow, a short lived reprieve and was more to do with re-assembly settings that had worked for me flawlessly, for years on a landline. I believe scrub had no-df before and I am now using without issue, so far. set reassemble yes no-df match scrub (random-id max-mss 1389) Should I drop the no-df from set reassemble? Any other recommendations welcome? Any thoughts or links on the most secure pf.conf that remains being compatible with any network? Thank You
