I’m always looking for ways I can add layers of encryption and security to my network and I recently came across the DNSCrypt project created by OpenDNS. This toolset and infrastructure encrypts DNS queries from your machine or network so that your ISP can’t snoop on them. I decided to set up dnscrypt-proxy as a forwarder on my home router so that all DNS traffic leaving my network is encrypted.
WordPress (this blog) is constantly being brute forced by bots that scan the internet looking for weak passwords. I wanted to better visualize these attempts. Here’s how I did it with Splunk.
After the massive phish targeting Google accounts this week, I’ve had some people ask me how to make sure their Google account is secure. Luckily, Google has built in some great features that help you assess your account security and keep it safe.
If you suspect someone has hacked your account, just changing your password is not enough. There are ways a hacker can maintain access to your account even after you change your password. Follow the below steps to review the state of your account.
In part 1 we covered the hardware setup of my Raspberry Pi based timelapse camera. Now we tackle the software.
- Configurable image capture interval.
- Images are stored on a USB flash drive for easy retrieval.
- Only takes pictures during the day. Daytime is determined by the awesome sunwait utility that calculates sunrise and sunset based on latitude and longitude.
- The image capture script can be bypassed by flipping a switch connected to GPIO so you can boot into the OS.
- A log is written to keep track of battery voltage over time.
- The script is updated from the USB flash drive on every boot so you don’t need to manually boot into the OS every time you want to tweak the interval. Simply update the script on the flash drive and on second boot, you’ll be running the new code.
The couple scripts are written in bash and are available in my github here: https://github.com/dewoodruff/picam
Timelapse cameras are fun. I’ve done a few timelapse videos (like this one with a really crappy webcam driven by an original Eee PC laptop) and I have some ideas for other long term videos in the future, so I wanted a higher quality, more autonomous setup. My requirements:
- Waterproof so I can strap it to a tree for a few weeks
- Long battery life, so I can strap it to a tree for a few weeks
- Infinitely configurable delay between images depending on my goal for the video
- Easy to retrieve the images from it
- Don’t take pictures over night, because I’m lazy and don’t want to manually weed out black pictures. Sleeping over night means more battery life and less storage used too.
A Raspberry Pi seemed like a perfect platform. They are low power, they have camera module support, they’re small, and they’re cheap. With some extra hardware and scripting I can also turn it off between pictures to save even more power.
Here’s how I built it. Part 1 is the hardware setup and part 2 is the software.
Logrotate is a versatile tool for rotating logs. When logrotate is configured to rotate a set of logs using the ‘compress’ command, by default the gzip utility will be used. gzip is a good utility but you may have a need to use something else. My need is:
- Multi-gigabyte files need to rotate hourly or daily
- Rotation and compression was taking several minutes per file
- My CPUs were mostly idle
My solution was to use the pigz compression utility coupled with logrotate. pigz performs multithreaded gzip compression so some of the idle CPUs could be put to work. Here’s how to do it:
Felix Rusu from lowpowerlab.com has created an amazing library for the Arduino/ATMega platform to use cheap RFM69 wireless modules for wireless transmissions between nodes. For a list of all the features, see his readme: https://github.com/LowPowerLab/RFM69. His Moteino platform and library are perfect for roll-your-own home automation systems, which is just what I am doing!
However, in my mind the library was lacking one critical piece – being able to prevent wireless replay attacks. Using Felix’s library, RFM69 transmissions can be encrypted in hardware, but the receiving node had no way of verifying that the incoming transmission was from a legitimate node and should be processed. If an attacker captured a sensitive packet as it flew through the air, such as one to open your garage door, they could replay it at a time of their choosing and trick your home automation system into opening the door.
TomWS on the lowpowerlab forum and I did some brain storming and he proposed modifications to the base RFM69 library to virtualize some functions, allowing them to be overloaded to create ‘extensions’. Using his modification, I wrote a transmission session key extension.
More after the break…
There are numerous python libraries out there for the 16 port MCP23017 GPIO expander chip that works with the Raspberry Pi, so why yet another one? None of the ones I could find actually implement interrupts via the chip Polling is not ideal for my home monitoring setup. I was already monitoring via interrupts and the onboard GPIO pins using the awesome RPIO module and wanted to continue using interrupts with the expansion chip. So I built my own module, leveraging Adafruit’s I2C library for the nitty gritty backend interface.
- Simple digital input and output via all pins
- Input interrupts
- Interrupt port mirroring is configurable – either INTA and INTB can trigger independently for their respective GPIO port banks, or both INTA and INTB can trigger at the same time regardless of what GPIO pin causes the interrupt
- Configurable interrupt polarity – INT could pull the pin high or push it low
- Each GPIO pin can be configured for interrupts independently to either compare against the previous value or against a default pin value
- A utility method cleanupInterrupts that can be called periodically to clear the interrupt if it somehow gets stuck on
You can find the library on my BitBucket.
Stick around after the break for a breakdown of how to use it.
To me, encryption of data at rest is just as important as encryption of data in transit. You never know if someone is going to break into your house and steal your computer. With so much personal information like financial data and pictures stored on the computer, it could be a major mess to recover from theft of your computer. (Of course, always keep an off-site backup for the really important stuff!)
I chose to migrate from the Solaris based OpenIndiana to Ubuntu. I had grown to love ZFS on OpenIndiana and didn’t want to lose its features. Luckily ZFS on Linux is now ready for prime-time! Unfortunately, ZFS on Linux is a few versions behind the official Oracle ZFS just like all other third part implementations of ZFS and does not support native encryption through the filesystem.
SSL’s primary function on the Internet is to facilitate encryption and trust that allows a web browser to validate the authenticity of a web site. However, SSL works the other way around too – client SSL certificates can be used to authenticate a client to the web server. Think SSH public/private key pairs, if that is familiar to you. In this blog post I will outline the steps to create a certificate authority certificate, sign a server certificate and install it in Apache, and create a client cert in a format used by web browsers.