Questions? Contact Us


Latest News

Featured News & Events

Server cabinet door alarm

The first step in securing servers is to ensure that they are physically as secure as possible and and then monitored for unauthorized access  Many times when setting up servers in a small office or co-location facility many people have their systems in a locking cabinet within a moderately secured physical building.  However a determined attacker can usually bypass many physical controls so adding as many layers and monitoring helps can help both to thwart an attacker or be used to monitor for authorized equipment access through change management filtering on your monitoring and alerting system.

One problem with the small office or colo environment is there are very few affordable solutions that can be used to monitor for authorized and unauthorized access.  To solve this problem, ZZ Servers has implemented a cabinet monitoring solution that is able to not only monitor for cabinet door entry but also has the ability to have temperature and humidity sensors (which we do not actually do in this initial proof of concept).

The cabinet door alarm is based on a teensy 2.0 USB device that uses digital inputs to determine if magnetic alarm door switches are open or closed and then monitor their status with any standard monitoring system through a USB connection to the Teensy device. The teensy can be ordered from PJRC for $16. The LED, Resistor and remaining components can be purchased from Jameco, Amazon, Home Depot, Radio Shack or any other similar store.

The teensy is connected through USB to a linux server in the cabinet that runs an application to query the status of each sensor. The teensy provides a +5V pin that will be connected to a 10k ohm resistor which is then connected to the GND with one connection to each of 4 input pins for the door sensor and an LED connected to interface 11.

ZZ Servers Homebrew Teensy Cabinet Alarm Layout

The current design is for only 4 alarm switches; but there is no reason the other inputs can't be used. If additional inputs are used then the associated firmware and software programs will need to be updated to reflect the number of interfaces.

This design also expects there to be a closed circuit on all monitored ports otherwise an alarm will be raised. A simple closed loop will work for any alarm switches not installed.

Once the circuit is assembled the firmware needs to be uploaded to the teensy. The firmware used is based on the arduino support for Teensy that can be downloaded.  The steps to setup the Teensy/Arduino development environment are found on the page and need to be followed to allow for proper aduino sketch to be built and loaded onto the teensy flash.

Once the development tools are installed:

  • Start the arduino IDE (found in arduino software extract)

  • Connect the teensy usb interface

  • Set board type to Teensy 2.0 (Tools/Board/Teensy 2.0)

  • Load the code (below)

  • Verify (checkbox in IDE) the code

  • Upload (right arrow in IDE) the HEX firmware

Teensy Firmware:
The firmware has 3 main sections; the Header where the various variables are defined that are used within the program, The setup function which runs when the teensy is powered on (plugged into USB) and then the loop which is executed after setup executing the designed function.

When the teensy boots, it load the setup function which initializes the device allowing for INPUT_PULLUP functionality for the 4 pins used for the alarm. This creates the alert when the switch is opened. The setup then initializes the USB serial device at 38400 8n1 and configures the LED output PIN and makes sure the LED is off.

The loop function is the core of the firmware. This is the function that the teensy executes over and over. In this function the first thing to do is read each of the alarm interfaces and if there is an alert flag it so we can be sure to blink the LED. Next the loop will see if there are any requests on the serial port, which will come from the serial program further down in this post. If there is input from the serial interface, the loop confirms it is a valid request [1,2,3,4] and then prints back on the serial interface a simple message showing the status of the serial ports.

Finally the loop ends by running the BlinkLED function if there is an alarm otherwise if the LED is on be sure to turn it off.

The BlinkLED function works by using a nice variable type provided by the Teensy "elapsedMillis" which creates a timer that is used to trace the time since the variable was created. Using this variable if it has been one second (1000ms) then reset the timer and if the LED is on turn it off, otherwise turn it on.
// Header Section
int ledPin =  11;
int ledon = 0;
int ALARM_1 = 1;
int ALERT_1 = 0;
int ALARM_2 = 2;
int ALERT_2 = 0;
int ALARM_3 = 3;
int ALERT_3 = 0;
int ALARM_4 = 4;
int ALERT_4 = 0;
int alarmnow = 0;
char alarmcheck = ' ';
elapsedMillis sinceAlarm;
//End Header Section

// The setup() method runs once, when the sketch starts
void setup()   {
pinMode(ledPin, OUTPUT);
digitalWrite(ledPin, LOW);

// the loop() method runs over and over again, checking for events
void loop()   {
alarmnow = 0;
alarmcheck = ' ';

ALERT_1 = digitalRead(ALARM_1);
ALERT_2 = digitalRead(ALARM_2);
ALERT_3 = digitalRead(ALARM_3);
ALERT_4 = digitalRead(ALARM_4);

if (ALERT_1 || ALERT_2 || ALERT_3 || ALERT_4) {
alarmnow = 1;

if (Serial.available()) {
alarmcheck =;

switch (alarmcheck) {
case '1':
if (ALERT_1) {
} else {
case '2':
if (ALERT_2) {
} else {
case '3':
if (ALERT_3) {
} else {
case '4':
if (ALERT_4) {
} else {
case ' ':

if (alarmnow) {
} else if (ledon) {
digitalWrite(ledPin, LOW);

void BlinkLED() {
if (sinceAlarm >= 1000) {
sinceAlarm = sinceAlarm - 1000;
if (ledon) {
ledon = 0;
digitalWrite(ledPin, LOW);
} else {
ledon = 1;
digitalWrite(ledPin, HIGH);

Once the firmware is loaded onto the teensy and all the switches are in place the linux system that will interface with the alarm needs to have a udev rule created that will allow the usbSerial interface to function.
Linux UDEV rules

SUBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[789]?", MODE:="0666" KERNEL=="ttyACM*", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="04[789]?", SYMLINK+="ttyUSB00%n", MODE:="0666", ENV{ID_MM_DEVICE_IGNORE}="1"

The host that connects to the ZZ-Teensy-Alarm needs to be able to query to the teensy on the USB Serial device to determine the status of any of the configured alarm switch inputs.  This is accomplished using a C program that will open the USB serial device presented by the teensy and write/read to the running firmware queries on port status.

The alarm-monitor application is a very simple C application. After initializing some variables it performs a quick check on the number of command line arguments, providing help and exiting if it is not correct. Next the application confirms that the query provided on the command line is a valid interface to query. Alarm-monitor then initializes the specified serial device to 38400 8n1 and writes out the query to the teensy serial device. Once the query is written the application will wait for a response for 10 seconds after which the appropriate response is sent back to the user.
Linux Command line zz-teensy-alarm query:

int main(int argc,char** argv)
struct termios tio;
struct termios stdio;
time_t start,now;
int diff;
int tty_fd;
fd_set rdset;
struct flock fl;

unsigned char c=' ';

if (argc0) {
now = time(NULL);
diff = (int)difftime(now,start);

fl.l_type = F_UNLCK;
fcntl(tty_fd, F_SETLK, &fl);

if (diff >= 10) {

The alarm_monitor application can be compiled with gcc:

gcc -o alarm_monitor alarm_monitor.c

alarm_monitor has 2 inputs, the first is the USB device of the ZZ-Teensy-Alarm, the 2nd is the port to be queried (1-4 is hard coded, any additional ports need to be expanded on for alarm_monitor.c and zz_alarm0.ino).


alarm_monitor /dev/ttyUSB000 1

Would query alarm switch 1 and as this example shows returns the alarm #:status where 0 is OK and 1 is switch open (alarm).

There is a 10 second timeout if ZZ-Teensy-Alarm device isn't connected or if there are connectivity issues.  An error code of X:X is returned for any timeout and any query to ports other than 1,2,3,4 return invalid query.

Concept Assembly

The initial design was built using a breadboard and is pictured below:

ZZ Servers Teensy Cabinet Alarm Prototype
ZZ Servers Home Brew Server Alarm Concept

Once the design was tested a standard radio shack project box was acquired along with a few screw down termination jacks.  These were assembled into the following picture

ZZ Cabinet Alarm Prototype - Assembly
ZZ Cabinet Alarm Prototype - Assembly

ZZ Cabinet Alarm Prototype - Assembly
ZZ Cabinet Alarm Prototype - Assembly

The final configuration has the usb cable coming out one side, an led on one side and the screw on terminators ready to be connected to magnetic door switches.

ZZ Cabinet Alarm Prototype - Assembled
ZZ Cabinet Alarm Prototype - Assembled

ZZ Cabinet Alarm Prototype - LED on
ZZ Cabinet Alarm Prototype - LED on

Zabbix Integration

Once the alarm is in place it needs to be monitored. Here at ZZ Servers we leverage Zabbix but any system such as Nagios could work as long as they can execute a script for input.

Zabbix monitoring can monitor the status of each door alarm through the configuration of UserParameters.  A full configuration will follow in a future post with templates for items / alerts but for now below is a sample UserParameter for each of the 4 configured alarm monitors:


UserParameter=cabinetdoor[*],/usr/local/bin/alarm-monitor /dev/ttyUSB000 $1|cut -d: -f 2

Details on how to configure the zabbix template including the appropriate items, triggers and alerts will be posted in my next blog post.

UPDATE: 1/30/2012 - Video of Shmoocon Firetalk -
Managing Partner speaking to College of Charleston...
ZZ Servers Managing Partner to speak at #Shmoocon ...

Related Posts


Tag Cloud

cyber liability insurance Health Insurance Portability cell phone email Business Planning Cybersecurity Business Solutions social engineering cyber monitoring sender policy InterWorx computer security Ubuntu BSides cybersecurity intrusion detection Hackers dss trends backup solutions protect data ipad security dsbl Online Business credit cards stolen TLS Las Vegas search members area ICANN computing in the cloud Web Hosting PCI Service Provider Car Hacking bash Shmoocon vyatta router firewall filter security PCI HIPAA Assigned Names PCI DSS 3.2 Xen IT security INFOSEC kerio mail server health care providers hosting control panel spoofing iphone ZZ Servers Co-Founder Scalable Redundant Cloud Infrastructure Payment Card Industry Credit Cards recovering data PCI Sysadmin two factor authentication Security Small Business arduino caller-id credit card Internet data privacy Compliance Charleston logical security HIPAA Medical Records Disaster Recovery Plan DRP apache ZZ Servers shared server personal information Internet Corporation cyber protection passwords cloud infrastructure business solutions teensy business black friday smartphone data protection Internet infrastructure Vulnerability data breach physical Firetalk network QSA Interworx-CP follow.The HIPAA Privacy Rule change openssl vps safe computing infrastructure David Zendzian physical security permissions log files PCI Hosting compliant hosting blackberry Reports amazon ec2 password CentOs qsa PCI Audit motivation SSL business community DEF CON IT services HIDS Announcement computer networks IT Services Cloud Computing email accounts Windows Positive Customer Impact Accountability Act Linux Server Mangement shared folders embedded multi-factor authentication HIPAA solutions healthcare solutions management pci complliant hosting IT solutions Alarm command line video information technology Medical Solutions Hosting IT Solutions Business Solutions cli Geekend Control Panel malicious software cyber security OSSEC TiaraCon HIPAA Solutions businesses anti virus Home Depot Breach shared secure hosting education National Cyber Security Awareness Month cloud World Backup Day phishing cyber assesment shared hosting Debian windows 7 compliance Email PCI Solutions Health Care Cybersecurity small business Continuous Monitoring Domani Names IT PCI Data Security Standards phishing attacks Zendzian HIPPA PCI Compliance Credit Card Security eCommerce Solutions Presentation VPS Servers PCI compliance vulnerability scanning activesync spam credit card payment support employee training cyber monday Information Technology spf security circles GDPR Cybersecurity exchange business solitions lamp Healthcare Records eCommerce