Re: Securing FreeBSD.

On 05/04/2025 08:38, Albert Shih wrote:
> Le 04/04/2025 à 14:56:00-0700, David Christensen a écrit
>
> Hi
>>>> It sounds like you want read-only storage media (?).
>>> Yeah...exactly. The purpose is to recycle some old server to create some
>>> «non erasable» backup in addition to our «normal» backup.
>> Please clarify how you will create the "«non erasable» backup" and how you
>> will use it.
> The initial idea is to
>
>    1/ Put the server in kern.securelevel=2
>    2/ cron + rsync + find . -type f -exec chflags schg {} \; for the data
>
> For the use :
>
>    1/ Pray not have to ;-)
>
>    2/ rsync in the other way ;-)
>
>>> They are two thing I will not consider in the equation :
>>>
>>>     Security problem in FreeBSD.
>> If you wish to defend against security problems in FreeBSD, then I suggest
>> that you run the oldest supported release of FreeBSD -- 13.4-RELEASE.
> Well I say I will «not» consider.
>   
>> If you wish to defend against an intruder who has physical access to the
>> server, then I suggest that you select drives that have self-encryption (in
>> addition to write-protection).
>>
> Yes. I know that. But the assumption is :
>
>    FreeBSD don't have security problem
>    The physical access is safe.
>
>>> well....not possible. Too many To.
>> What is the size of the "«non erasable» backup"?
> Currently I got around 8 To of data to backup (every day) in this «backup safe». And
> the server for this «backup safe» would have «lot of To» (around 450 To).
>
> So no problem to just daily
>
>    mkdir  `date +%Y%M%d`
>    rsync data  `date +%Y%M%d`
>    find  `date +%Y%M%d` -type f -exec chflags schg {}\;
>
> and each 6 months (or before if need a run of freebsd-update) to boot in
> single, change the securelevel and erase manually the oldest backup
>   
>> What devices is it currently stored on?
>>
> Standard HDD.
>
>>> And the data change daily.
>> "non erasable" and "change daily" are contradictory goals.  Please clarify.
> Yeah....I mean the data I need to backup change daily. So it's not humanly
> possible to write that optical device.
>
> We already think about WORM tapes (we have LTO-8 library) but that's is
> very expansive. And the point is to use some old server who run perfectly
> but no longer under warranty to do this «backup safe» because we already
> have standard backup.
>
>>> Same issue. Not possible.
>>>
>>> Regards.
>> What about the IODD external drive enclosures?
>>
>>
> Didn't know that thing. I will check that.
>
A few of thoughts having followed this discussion.

1) If you lock down the backup server completely (no open ports) then it 
would be very hard for it to be compromised.

2) zfs send/receive is often a lot more efficient than rsync, and you 
can keep snapshots on the backup server which is an extra security 
feature. Just have one port open for replication.

3) Sending a zfs dataset to LTO and then removing the tape from the 
drive is very secure. Of course you need to be in the same place as the 
drive. If the dataset deltas are relatively small it's reasonable to do 
this over the Internet but I don't know how much of your data is really 
changed. It's usually less than people thing.

Just in case you're not familiar with zfs send, you can have a complete 
image of your enormous zpool - offline (unplug the disks) and then send 
a delta for everythig that's changed between snapshots. This delta may 
be quite small and easily fit on an LTO, which can then be removed and 
put in a safe place. To get your data back, reconnect the image and 
apply the delta or deltas from tape.