Oct 282018

There is a new build of SoloBSD 11.2-STABLE-1028 based on the latest HardenedBSD stable branch version v1100056.7.

Changelog v1100056.7


  • cpdup
  • dmidecode
  • e2fsprogs
  • ipmitool
  • nano
  • rsync
  • smartmontools
  • tmux
  • htop
  • mksh
  • ksh93
  • oksh

Now with heal-harddrive.sh script included from Martin Sugioarto. Check Instructions of use.


Be aware that running it on a drive containing a filesystem will DESTROY data, metadata and perhaps even the entire filesystem.

You can grab it from Here (ISO) (182.1 Mb) or Here (img) (219 Mb)

root password: solobsd

Oct 132018

Ok, since I am reading Michael Lucas’ FreeBSD Mastery: Storage Essentials I decided to get my hands dirty and learn about GELI and disk encryption. Here are my notes:

First of all, you need a new device to encrypt, you can encrypt existing devices, but you need to backup data first. I assume too that you have GELI up and running.

  • Randomizing the device.
          We want our device to be filled by randomness, so we apply three teaspoons of it:
           dd if=/dev/random of=/dev/ada0p1 bs=1m

I went the easy way and encrypted without a key file, this is NOT RECOMMENDED, so create your key file. (You can find how in the book 🙂 )

  • Initializing the provider.
           geli init -s 4096 /dev/ada1p1

You will receive the next message:

Metadata backup can be found in /var/backups/ad1p1.eli and can be restored with the following command:

geli restore /var/backups/ada1p1.eli /dev/ada1p1
  • Activate the device.
geli attach /dev/ada1p1

Ok now you have your device ready, let’s create a new filesystem on it and mount it:

newfs -j /dev/ada1p1.eli
 mount /dev/ada1p1.eli /mnt/

Done? Ok now unmount and detach it.

umount /mnt
 geli detach ada1p1.eli


Oct 132018

Si alguna vez has tenido problemas con pkg y al momento de instalar cualquier paquete te topas con un error parecido al siguiente:

Fetching cyrus-sasl-2.1.26_12.txz: 100%  467 KiB 478.5kB/s    00:01
pkg: cached package cyrus-sasl-2.1.26_12: size mismatch, fetching from remote
Fetching cyrus-sasl-2.1.26_12.txz: 100%  467 KiB 478.5kB/s    00:01
pkg: cached package cyrus-sasl-2.1.26_12: size mismatch, cannot continue

Solamente debes ejecutar:

pkg update -f

Y asunto arreglado!

Oct 132018

En marzo de 2016 estuve charlando con Shawn Webb en el canal de IRC #HardenedBSD, acerca del entonces nuevo soporte para PIE + RELRO + BIND NOW + compatibilidad W^X en Firefox para HardenedBSD y esto es lo que me comentó:

lattera SoloBSD: also, I hope you enjoy PIE + RELRO + BIND NOW + W^X compat firefox like I am 😉
SoloBSD what all of those things do?
SoloBSD PIE is Position-Independent Executable
SoloBSD I almost got that
SoloBSD so it is randomly running in memory space right?
lattera PIE means that the application itself will be loaded in a random spot in memory
lattera RELRO means that the relocation section will be marked as read-only
lattera BIND NOW means that the runtime linker will resolve all symbols (like functions, variables, etc.) immediately, before running the application
SoloBSD RELRO —-> cause sometimes is maked as r/w
SoloBSD right?
lattera if an application doesn’t use RELRO, the part in memory where the relocation entries are located will be marked as RW
SoloBSD so what can go wrong there?
lattera W^X compat means that its javascript interpreter won’t create RWX memory mappings
SoloBSD someone can write there?
lattera yeah, there’s a part of the application called the PLT/GOT
lattera and that part is abused by attackers
SoloBSD got it
lattera if it’s marked as RW, then an attacker can redirect function calls
lattera so when you think your application is calling printf(), it’s really calling evil_printf()
SoloBSD ohhh interesting, and the same goes for W^X, right?
lattera kinda/sorta, but not really
lattera if a memory mapping is marked as RWX, then an attacker could write arbitrary code into that mapping and execute it
lattera W^X means “exclusively write or execute, but not both”
lattera so if a memory mapping is marked as writable, it can’t be marked as executable
lattera and if a memory mapping is marked as executable, it can’t be marked as writable
SoloBSD got that now
SoloBSD ok question on PIE, correct me if I’m wrong, which is likely possible, from the HBSD Internals lecture:
SoloBSD OpenBSD does the same, but we already know where the memory stack lives, right? which doesn’t happen with HBSD
lattera OpenBSD has enabled PIE for all of base, something which we haven’t done, yet
lattera we have PIE enabled for certain applications like ssh and sshd
lattera and HardenedBSD is the only BSD with true stack randomization, if I remember right
lattera meaning we randomize the top of the stack address
SoloBSD and that’s why we love it, right?????
SoloBSD 🙂
lattera we still also utilize a random stack gap, too, to provide more entropy

Espero sirva para entender un poco más cómo funciona todo esto en HardenedBSD.

Oct 132018

Esto lo probé en mi máquina con OpenBSD 5.6, no lo he probado en versiones actuales. Tenía un disco duro con una partición ext4 que usaba cuando tenía instalado CentOS y después OpenSUSE. Con OpenBSD la cosa sería más o menos así:

mount -oro -t ext2fs /dev/wd1i /mnt/backup

Para hacerlo permanente en /etc/fstab/ ponemos:

/dev/wd1i /mnt/backup ext2fs ro,nodev,nosuid 0 0

Listo! Ahora la partición estará disponible en cuanto arranque el sistema.