Archive

Last modified by Administrator on 2022/01/30 10:10

Blog - posts for April 2014

Apr 30 2014

Apr 30, 2014,

Checking DNS

While looking around to check if I might potentially be contributing to the DNS amplification problem, CERT pointed me at a pretty nifty site that checks a lot of other potential DNS issues: DNSInspect. It checks several different aspects related to nameservers (and a few besides), and generates a report that tells you what works, what doesn't, and what could potentially use some shoring up. It really likes IPv6 (although it doesn't hold it against you), but all in all, performs a considerable number of checks, including some I wasn't aware of (like that your MX records should be A records, and not, for example, CNAMEs). I highly recommend checking it out if you're setting up a domain.

Posted by Mitchell · Categories: · Permalink · Comments (0)

Apr 27 2014

Apr 27, 2014,

Backup and running

The past few weeks have been pretty hectic, so I haven't had as much time to work on things as I'd prefer.

An important part of having a production-grade system is, naturally, having backups. it's remarkably possible to put together a semi-decent system with a little bit of effort. Some requirements:

  • Cross-platform support
    • I have Linux and Windows systems with data I need to back up.
  • Secure
    • No single system should have the ability to read the backups of all other systems.
  • Redundant
    • As much as possible, the backup system should tolerate failure.
  • Free
    • Okay, so I'm cheap. But this is a purely personal setup, so I'd like to minimize my investment (especially since a lot of the available options easily run over several thousand dollars!).

The layered system I've put together looks like this:

  • Backup system: Greyhole
    • A Linux-based system that attempts to mimic Windows Home Server's Drive Extender capabilities. The advantage it provides is JBOD exported as a single logical volume, while not having to worry excessively about what happens when a single disk fails (you lose the contents of that disk, but the contents on other volumes remain intact). Honestly, it's a hack, but if it works....
  • As a basic level of access control, different Samba accounts for the various systems should restrict access for one system to another's backups.
  • Linux engine: tar through GnuPG
    • Piping tar through GnuPG allows for a simple system while keeping the encryption/decryption key on the client system.
    • Maintaining database consistency is incumbent on me.
  • Windows engine: Windows backup through TrueCrypt
    • Windows Server's built-in backup works well, in that it ensures that databases stay consistent (in particular those for Active Directory and Exchange). But it doesn't support encryption. Setting up a TrueCrypt volume for Windows to mount alleviates this issue, and allows for retaining the encryption/decryption key on the client system.
  • Secondary backup system: CrashPlan
    • Having "on-site" backups is great, but having "off-site" backups is also important. CrashPlan works well as a peer-to-peer backup system, allowing the backups to be duplicated elsewhere.

Putting together the Windows piece is actually a little bit more complex, due to the fact that although TrueCrypt declares itself as a local drive, it doesn't support all of the operations that Windows expects to be able to perform on a local drive, as a result failing with a not-so-helpful "Catastrophic failure" error message, with Event Viewer showing an error code of either 2147549183 or 8000FFFF (hex). There is a workaround described on Super User, but what's described doesn't lend itself well to automation. I've pulled together a batch script that handles everything reasonably well:

backup.bat
rem Cleanup from previous runs.
net share backup /delete
"C:\Program Files\TrueCrypt\TrueCrypt.exe" /q /s /dy
net use z: /delete

rem Get variables to minimize customization.
for /f %%a in ('hostname') do set hostname=%%a
for /f %%a in ('whoami') do set whoami=%%a

rem Mount the network mount.
net use z: NETHOST\%hostname% "NETHOST_PW" /user:NETHOST_USER

rem Mount the TrueCrypt volume.
"C:\Program Files\TrueCrypt\TrueCrypt.exe" /q /v z:\%hostname%.tc /ly /a /p "TRUECRYPT_PW"

rem Share the network drive.
net share backup=y: /grant:%whoami%,full

rem Run the backup.
wbadmin start backup -backupTarget:
%hostname%\backup -include:c: -systemState -allCritical -quiet

rem Sleep for 30 seconds to wait for the share to stop being used.
timeout 30

rem Remove the network drive.
net share backup /delete

rem Unmount the TrueCrypt volume.
"C:\Program Files\TrueCrypt\TrueCrypt.exe" /q /s /dy

rem Cleanup this run.
net use z: /delete

Naturally, make the following substitutions:

  • NETHOST
    • The backup server that hosts the TrueCrypt volumes (accessed via SMB).
  • NETHOST_USER/NETHOST_PW
    • The username and password for the backup server.
  • TCPASSWORD
    • The password for the TrueCrypt volume.

A few assumptions made for general deployability:

  • This script uses drives Y: and Z:. Change as needed.
  • Each TrueCrypt volume goes to its own folder based upon the host's name (in case you want to have NETHOST_USER be per-host).
  • Each TrueCrypt volume is named after the host's name.
  • I chose not to rely on the administrative Y$ share, as it's not guaranteed to be available, and reliability >>> shorter code in this case.
Posted by Mitchell · Categories: · Permalink · Comments (0)