I bought an ASRock C2750D4I motherboard for my NAS in October 2014. In March 2017, my board was struck by a firmware bug that involves the BMC flash storage being worn out too quickly because of a bug in the watchdog. This is a well-known issue.

Since my board died after more than two years, I was worried whether I could still get it RMA’ed. The shop where I bought the board stated I only had two years warranty.

Luckily, the folks at ASRock were very helpful. I discovered that (also) in The Netherlands you have three years warranty on the C2750D4I.

I received a replacement board from ASRock quickly. As of now, half a year later, the new board is still operating perfectly. I can only say that my RMA experience with ASRock has been positive.

Update 2022: my board died again, this time because of the C2000 bug. ASRock was very considerate in sending me a new board, this many years after I bought it.

The MITRE ATT&CK framework is a great tool for blue teams.

As an exercise, I tried mapping the Stuxnet attack onto the ATT&CK framework. As a source, I used the excellent Symantec Stuxnet paper.

CC-BY-SA.

• I tried cramming it all into one slide, sorry for that. Defense evasion is indeed that big.
• There are multiple ways to do the mapping. There could also be mistakes (caveat emptor). I welcome any bugfixes.
• The credential access row is empty, since from what I read it used the user’s credential token not their actual passwords. The exfiltration row is empty because the paper shows that this instance was primarily meant for infecting the SCADA systems. Of course, the malware was able (via its C&C connection) to have exfiltration modules, but these were not discussed.

PDF version: ATT&CK – Stuxnet.

The combination of btrfs + snapper is a great solution for the Linux desktop. Perhaps even the best thing since sliced bread. Once properly set-up, you can rollback any file that you may accidentally damage at some point. I’ve found it invaluable during software upgrades/migrations (oops, are all your desktop panels gone after upgrading? don’t worry, just roll back) or when running into bugs (oops, the Digikam library got corrupted? don’t worry, just roll back).

Configuring snapper involves letting systemd activate it regularly using systemd timers. This works well, although you may end up having corrupt / incomplete snapshots if your computer crashes in the middle of a snapper operation.

Having broken snapshots will be made known to you in the journal with events such as:
:1: parser error : Document is empty

This message indicates that you have work to do to clean up broken snapshots. The following Bash oneliner may help you do this:

IFS=$'\n';
for x in $(grep -hr SUBVOLUME /etc/snapper/configs | cut -d '"' -f 2); do
  for y in "$x/.snapshots/"*; do
    z="$y/info.xml";
    if ! [ -s "$z" ]; then echo "***$y***"; ls -lah "$y";
      read -p "Delete? (y/n)" R; if ! [ "$R" = "y" ]; then continue; fi;
      set -x; btrfs subvol del "$y/snapshot"; rm -rf "$y"; set +x;
fi; done; done; unset IFS

• I’ve broken the oneliner over multiple lines for this post, but just merge them together for use in a shell.
• This is just a oneliner and not a real program. The way I do it here, is not the recommended way to loop in Bash though it should work fine for this use case (the alternative, using read + while, won’t work here due to a nested read). Refactoring would make it more complex, at which point I’d suggest to just make it a Python program.
• It needs to run as root.
• As always, have back-ups. Caveat emptor.