Date: Sun, 6 Apr 2025 11:11:24 +0100 From: Frank Leonhardt <freebsd-doc@fjl.co.uk> To: freebsd-questions@freebsd.org Subject: Re: Securing FreeBSD. Message-ID: <a9b56020-9004-48d3-8f61-a9b02e58bbdf@fjl.co.uk> In-Reply-To: <Z_Dd918DyCHhq1Hb@io.chezmoi.fr> References: <Z_ATQA2k-3umIaLo@io.chezmoi.fr> <bb89a12f-0d73-411f-a34f-8a8224c30744@holgerdanske.com> <Z_A6pmQPuZU5lTEW@io.chezmoi.fr> <419a92a3-6d5b-44cb-8edf-6e65373ae72d@holgerdanske.com> <Z_Dd918DyCHhq1Hb@io.chezmoi.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------NGddJx8oVvcrvOltLmvHNOVe
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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.
--------------NGddJx8oVvcrvOltLmvHNOVe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 05/04/2025 08:38, Albert Shih wrote:<br>
</div>
<blockquote type="cite" cite="mid:Z_Dd918DyCHhq1Hb@io.chezmoi.fr">
<pre class="moz-quote-pre" wrap="">Le 04/04/2025 à 14:56:00-0700, David Christensen a écrit
Hi
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">It sounds like you want read-only storage media (?).
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Yeah...exactly. The purpose is to recycle some old server to create some
«non erasable» backup in addition to our «normal» backup.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Please clarify how you will create the "«non erasable» backup" and how you
will use it.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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 ;-)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">They are two thing I will not consider in the equation :
Security problem in FreeBSD.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Well I say I will «not» consider.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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).
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Yes. I know that. But the assumption is :
FreeBSD don't have security problem
The physical access is safe.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">well....not possible. Too many To.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">What is the size of the "«non erasable» backup"?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">What devices is it currently stored on?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Standard HDD.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">And the data change daily.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">"non erasable" and "change daily" are contradictory goals. Please clarify.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Same issue. Not possible.
Regards.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">What about the IODD external drive enclosures?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Didn't know that thing. I will check that.
</pre>
</blockquote>
<p>A few of thoughts having followed this discussion.<span
style="white-space: pre-wrap">
</span></p>
<p><span style="white-space: pre-wrap">1) If you lock down the backup server completely (no open ports) then it would be very hard for it to be compromised.</span></p>
<p><span style="white-space: pre-wrap">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.</span></p>
<p><span style="white-space: pre-wrap">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.</span></p>
<p><span style="white-space: pre-wrap">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.</span></p>
<p><span style="white-space: pre-wrap">
</span></p>
<p><span style="white-space: pre-wrap">
</span></p>
</body>
</html>
--------------NGddJx8oVvcrvOltLmvHNOVe--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a9b56020-9004-48d3-8f61-a9b02e58bbdf>