From nobody Sun Apr 6 10:11:24 2025 X-Original-To: freebsd-questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZVp6350Qwz5tJ23 for ; Sun, 06 Apr 2025 10:11:39 +0000 (UTC) (envelope-from freebsd-doc@fjl.co.uk) Received: from bs1.fjl.org.uk (bs1.fjl.org.uk [84.45.41.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4ZVp631GMHz3pnD for ; Sun, 06 Apr 2025 10:11:39 +0000 (UTC) (envelope-from freebsd-doc@fjl.co.uk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-doc@fjl.co.uk designates 84.45.41.196 as permitted sender) smtp.mailfrom=freebsd-doc@fjl.co.uk Received: from [192.168.1.109] (host86-173-148-176.range86-173.btcentralplus.com [86.173.148.176]) (authenticated bits=0) by bs1.fjl.org.uk (8.14.4/8.14.4) with ESMTP id 536ABcuw025245 for ; Sun, 6 Apr 2025 11:11:38 +0100 (BST) (envelope-from freebsd-doc@fjl.co.uk) Content-Type: multipart/alternative; boundary="------------NGddJx8oVvcrvOltLmvHNOVe" Message-ID: Date: Sun, 6 Apr 2025 11:11:24 +0100 List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-questions@freebsd.org Sender: owner-freebsd-questions@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Frank Leonhardt Subject: Re: Securing FreeBSD. To: freebsd-questions@freebsd.org References: <419a92a3-6d5b-44cb-8edf-6e65373ae72d@holgerdanske.com> Content-Language: en-GB In-Reply-To: X-Spamd-Result: default: False [1.67 / 15.00]; RBL_SENDERSCORE_REPUT_9(-1.00)[84.45.41.196:from]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_SPAM_MEDIUM(0.99)[0.994]; NEURAL_SPAM_SHORT(0.68)[0.676]; R_SPF_ALLOW(-0.20)[+ip4:84.45.41.196:c]; ONCE_RECEIVED(0.20)[]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:25577, ipnet:84.45.0.0/17, country:GB]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[fjl.co.uk]; MLMMJ_DEST(0.00)[freebsd-questions@freebsd.org] X-Rspamd-Queue-Id: 4ZVp631GMHz3pnD X-Spamd-Bar: + 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
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--