Who: ShmooCon/NovaInfosecPortal.com
What: ShmooCon 2012 FireTalks
When: 1/27 to 1/28/2011
Where: Washington Hilton Hotel (1919 Connecticut Avenue, NW Washington, DC 20009)

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.

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.

• Extract Arduino Software
• Install 49-teensy.rules in /etc/udev/rules.d (see below for contents of this file)
• Download & Run teensy duino installer. Examples/samples are not needed unless doing future development

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.
zz_alarm0.ino

// 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(ALARM_1, INPUT_PULLUP);
     pinMode(ALARM_2, INPUT_PULLUP);
     pinMode(ALARM_3, INPUT_PULLUP);
     pinMode(ALARM_4, INPUT_PULLUP);
     Serial.begin(38400);
     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 = Serial.read();
     }

     switch (alarmcheck) {
          case '1':
               if (ALERT_1) {
                    Serial.println("1:1");
               } else {
                    Serial.println("1:0");
               }
               break;
          case '2':
               if (ALERT_2) {
                    Serial.println("2:1");
               } else {
                    Serial.println("2:0");
               }
               break;
          case '3':
               if (ALERT_3) {
                    Serial.println("3:1");
               } else {
                    Serial.println("3:0");
               }
               break;
          case '4':
               if (ALERT_4) {
                    Serial.println("4:1");
               } else {
                    Serial.println("4:0");
               }
               break;
          case ' ':
               break;
          default:
               Serial.println("X:1");
               break;
     }

     if (alarmnow) {
          BlinkLED();
     } 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
/etc/udev/rules/49-teensy.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:
alarm-monitor.c

#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
#include <time.h>
 
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 (argc<3) {
          printf("%s /dev/ttyUSB000 [1|2|3|4]\n\n",argv[0]);
          exit(1);
        }
 
        switch (argv[2][0]) {
          case '1':
            break;
          case '2':
            break;
          case '3':
            break;
          case '4':
            break;
          default:
            printf("Can only query alarms 1, 2, 3 or 4\n\n");
            exit(1);
            break;
        }

        fl.l_type   = F_WRLCK;  /* F_RDLCK, F_WRLCK, F_UNLCK    */
        fl.l_whence = SEEK_SET; /* SEEK_SET, SEEK_CUR, SEEK_END */
        fl.l_start  = 0;        /* Offset from l_whence         */
        fl.l_len    = 0;        /* length, 0 = to EOF           */
        fl.l_pid    = getpid(); /* our PID                      */

        tty_fd=open(argv[1], O_RDWR | O_NONBLOCK);
        fcntl(tty_fd, F_SETLKW, &fl);

        memset(&tio,0,sizeof(tio));
        tio.c_iflag=0;
        tio.c_oflag=0;
        // 8n1, see termios.h for more information
        tio.c_cflag=CS8|CREAD|CLOCAL;           
        tio.c_lflag=0;
        tio.c_cc[VMIN]=1;
        tio.c_cc[VTIME]=5;
 
        cfsetospeed(&tio,B38400);            
        cfsetispeed(&tio,B38400);           
 
        tcsetattr(tty_fd,TCSANOW,&tio);
  
        write(tty_fd,argv[2],1);

        start = time(NULL);
        now = time(NULL);
        diff = (int)difftime(now,start);
        while ((c != '\n') && (diff < 10)) {
          if (read(tty_fd,&c,1)>0) {
            write(STDOUT_FILENO,&c,1);
          }
          now = time(NULL);
          diff = (int)difftime(now,start);
        }

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

        if (diff >= 10) {
          printf("X:X\n");
          exit(1);
        }
        exit(0);
}

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).

EX:

alarm_monitor /dev/ttyUSB000 1
1:0

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

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

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 - 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:

/etc/zabbix/zabbix_agentd.conf

UserParameter=CB001.0001F,/usr/local/bin/alarm-monitor /dev/ttyUSB000 1|cut -d”:” -f 2
UserParameter=CB001.0001B,/usr/local/bin/alarm-monitor /dev/ttyUSB000 2|cut -d”:” -f 2
UserParameter=CB001.0002F,/usr/local/bin/alarm-monitor /dev/ttyUSB000 3|cut -d”:” -f 2
UserParameter=CB001.0002B,/usr/local/bin/alarm-monitor /dev/ttyUSB000 4|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.

This doesn’t mean the router should be your firewall, firewalls serve a different purpose for segmentation.  The border router has only the outside & inside; no real segmentation but at the same time the best place to block a wide variety of traffic at a single point.

We here at ZZ Servers leverage the best technology for a situation and as such utilize the vyatta router for our core routing devices (well custom hardware but running vyatta).  There is extensive documentation on vyatta filtering but it is mainly focused on the filtering of traffic into and out of the router directly.  The little there is on the traffic going “through” the device was focused on the vyatta box in a small office or home environment performing NAT and other “gateway” services.

When your router is a border gateway vs a network gateway the configuration is a little different and can be expanded to provide easy ways to block traffic.

The vyatta documentation is exceptional and a great starting point to getting a new system online and configuring as a NAT gateway so I will focus only on the filtering configuration needed for restricting access to / from and through the router as it simply routes traffic between networks.

From the vyatta firewall documentation the “The Vyatta firewall features IPv4/IPv6 stateful packet inspection to intercept and inspect network activity and allow or deny the attampt. Vyatta advanced firewall capabilities include stateful failover, zone and time-based firewalling, P2P filtering and more.”

It is the zone features that we will be working with for ingress and egress filter for traffic going through our border router.  The vyatta documentation best describes it’s approach to interface and “zone” filtering:

Ordinary firewall rule sets are applied on a per-interface basis to act as a packet filter for the interface. In zone-based firewall, interfaces are grouped into security “zones,” where each interface in the zone has the same security level.

Packet-filtering policies are applied to traffic flowing between zones. Traffic flowing traffic flowing between interfaces lying in the same zone is not filtered and flows freely, as the interfaces share the same security level.

When configuring the router for zone based routing there are a few notes highlighted in the vyatta documentation:

• An interface can be associated with only one zone.
• An interface belonging to a zone cannot have a per-interface firewall rule set applied and vice versa.
• Traffic between interfaces not belonging to any zone flows unfiltered and per-interface firewall rule sets can be applied to those interfaces.
• By default, all traffic to a zone is dropped unless explicitly allowed by a filtering policy for a from_zone.
• Filtering policies are unidirectional: they are defined as a “zone pair” defining the zone from which traffic is sourced (the from_zone) and the zone to which traffic is destined (the to_zone). In Figure 1-6, these unidirectional policies can be seen as follows:
  • From Private to DMZ
  • From Public to DMZ
  • From Private to Public
  • From DMZ to Public
  • From Public to Private
  • From DMZ to Private

The  configuration used in the example presented in this post has a router with 2 interfaces one “Internet” and the other “ZZ Servers” (or your inside; name yours as you will) with the internet on eth0 and zzservers on eth1.

The network segments for this vyatta configuration are then set to:

• ZZ Servers – The ZZ Servers public (internet) networks
• Internet – The Internet (outside ZZ Servers)
• Local – The local vyatta router

With these segments the vyatta zones will be configured as follows:

• Internet / Routed Network Traffic
  • Internet -> ZZ Servers
  • ZZ Servers -> Internet
• Traffic directly to or from the router
  • Internet -> Local
  • Local -> Internet
  • ZZ Servers -> Local
  • Local -> ZZ Servers

With the zones defined and router configured, the steps needed to configure the filtering include:

• Define various groups used
• Set rules from Internet directly to router
• Set rules from router to Internet
• Set rules from ZZ Servers directly to router
• Set rules from router to ZZ Servers
• Set rules for Internet to ZZ Servers
• Set rules for ZZ Servers to Internet

The differences between the router ingress & egress rules and the network rules is the direct rules will only allow what is specifically allowed and then deny all and the rules for the flow of traffic between the Internet and ZZ Servers will by default route (allow) all traffic and then deny only what we specify.

The first step is to enter the vyatta configuration mode and edit the firewall configuration, starting with the groups used in the rules.

The groups include:

• REJECTED-SERVERS: Will contain a list of IP addresses blocked from passing through to or from ZZ Servers and the Internet.
• REJECTED-NETWORKS: Will contain a list network segments blocked from passing through to or from ZZ Servers and the Internet.
• REJECTED-PORTS: Will contain a list of connection ports from passing  through to or from ZZ Servers and the Internet.
• SSH-FROM: Contains a list of IP addresses allowed to connect to the device
• SMB: Contains a list of ports used in SMB traffic (to block and not log the annoying microsoft broadcast traffic); NOTE – only blocking on direct access to/from device, not from passing through to or from ZZ Servers & the Internet.

configure
edit firewall

# Rejected Servers Group
set group address-group REJECT-SERVERS description “Block IP List”

# Rejected Networks Group
set group network-group REJECT-NETWORKS description “Block Network List”

# Rejected Ports Group
set group port-group REJECT-PORTS description “Block Port List”

# SSH Allowed Hosts List
set group address-group SSH-FROM description “IPs allowed to SSH into router”
set group address-group SSH-FROM address <management ip 1>
set group address-group SSH-FROM address <management ip 2>

# SMB Ports to drop and not log
set group port-group SMB description “SMB Ports to block and not log from ZZ Windows customers to local router”
set group port-group SMB port 67
set group port-group SMB port 135
set group port-group SMB port 137
set group port-group SMB port 138
set group port-group SMB port 139

Now with the groups defined the next thing is to setup the rules to filter traffic from the internet directly into the router.  The rule syntax is similar to a Cisco configuration; but significantly different as it sits on top of iptables which has extensive capabilities beyond basic filtering that will not be explored here.

We will not be doing anything fancy with this configuration; only defining what is and is not allowed.

The rules for ingress and egress directly on the router are very similar in structure:

• Set default policy to Deny, dropping any unauthorized connection
• Allow established and related connections
• Drop all invalid states
• Drop and do not log SMB broadcasts
• Accept ICMP
• Accept VRRP
• Accept BGP
• Accept HEARTBEAT
• Accept SSH
• Deny and log everything else

BGP packets are broadcast from peers with source port 179 and sent to peers on source port 179
HEARTBEAT packets are broadcast from peers to destination port 694.

With both BGP & HEARTBEAT I have setup source & destination port filters.  From my tests so far these may be adjusted; I’ve just not tested all situations so it may not need both sets of source & destination filters, so any feedback is welcome.

# Default deny
set name internet-local default-action drop

# Accept established & related
set name internet-local rule 1 action accept
set name internet-local rule 1 state established enable
set name internet-local rule 1 state related enable
set name internet-local rule 2 action drop
set name internet-local rule 2 log enable
set name internet-local rule 2 state invalid enable

# Drop and do not log Customer SMB
set name internet-local rule 3 action drop
set name internet-local rule 3 log disable
set name internet-local rule 3 destination group port-group SMB

# Allow inbound ICMP
set name internet-local rule 4 action accept
set name internet-local rule 4 protocol icmp

# Allow inbound VRRP
set name internet-local rule 5 action accept
set name internet-local rule 5 protocol vrrp

# Allow inbound BGP
set name internet-local rule 6 action accept
set name internet-local rule 6 port 179
set name internet-local rule 6 protocol tcp

# Allow inbound BGP
set name internet-local rule 7 action accept
set name internet-local rule 7 source port 179
set name internet-local rule 7 protocol tcp

# Allow inbound HEARTBEAT
set name internet-local rule 8 action accept
set name internet-local rule 8 destination port 694
set name internet-local rule 8 protocol udp

# Allow inbound HEARTBEAT
set name internet-local rule 9 action accept
set name internet-local rule 9 source port 694
set name internet-local rule 9 protocol udp

# Allow inbound SSH
set name internet-local rule 10 action accept
set name internet-local rule 10 log enable
set name internet-local rule 10 source group address-group SSH-FROM
set name internet-local rule 10 destination port 22
set name internet-local rule 10 protocol tcp

# Logging rule
set name internet-local rule 9999 action drop
set name internet-local rule 9999 log enable

The router to internet egress filters are similar but add additional rules for outbound upgrades, dns and ntp all of which could use groups for more specific filters.

• Set default policy to Deny, dropping any unauthorized connection
• Allow established and related connections
• Drop all invalid states
• Accept ICMP
• Accept VRRP
• Accept BGP
• Accept HEARTBEAT
• Accept DNS
• Accept NTP
• Upgrade rules
• Deny and log everything else

# Default deny
set name local-internet default-action drop

# Accept established & related
set name local-internet rule 1 action accept
set name local-internet rule 1 state established enable
set name local-internet rule 1 state related enable
set name local-internet rule 2 action drop
set name local-internet rule 2 log enable
set name local-internet rule 2 state invalid enable

# Allow outbound ICMP
set name local-internet rule 4 action accept
set name local-internet rule 4 protocol icmp

# Allow outbound VRRP
set name local-internet rule 5 action accept
set name local-internet rule 5 protocol vrrp

# Allow outbound BGP
set name local-internet rule 6 action accept
set name local-internet rule 6 destination port 179
set name local-internet rule 6 protocol tcp

# Allow outbound BGP
set name local-internet rule 7 action accept
set name local-internet rule 7 source port 179
set name local-internet rule 7 protocol tcp

# Allow outbound HEARTBEAT
set name local-internet rule 8 action accept
set name local-internet rule 8 destination port 694
set name local-internet rule 8 protocol udp

# Allow outbound HEARTBEAT
set name local-internet rule 9 action accept
set name local-internet rule 9 source port 694
set name local-internet rule 9 protocol udp

# Accept outbound DNS requests
set name local-internet rule 10 action accept
set name local-internet rule 10 destination port 53
set name local-internet rule 10 protocol tcp_udp

# Accept outbound NTP
set name local-internet rule 15 action accept
set name local-internet rule 15 destination port 123
set name local-internet rule 15 protocol tcp_udp

# Allow upgrade – only during valid changes
#set name local-internet rule 69 action accept
#set name local-internet rule 69 log enable
#set name local-internet rule 69 destination port 80
#set name local-internet rule 69 protocol tcp

# Logging rule
set name local-internet rule 9999 action drop
set name local-internet rule 9999 log enable

The rules between the router & the internal (ZZ Servers) public networks are basically the same as the internet rules.

• Set default policy to Deny, dropping any unauthorized connection
• Allow established and related connections
• Drop all invalid states
• Drop and do not log SMB broadcasts
• Accept ICMP
• Accept VRRP
• Accept BGP
• Accept HEARTBEAT
• Accept SSH
• Deny and log everything else

# Default Deny
set name zzservers-local default-action drop

# Accept established and related
set name zzservers-local rule 1 action accept
set name zzservers-local rule 1 state established enable
set name zzservers-local rule 1 state related enable
set name zzservers-local rule 2 action drop
set name zzservers-local rule 2 log enable
set name zzservers-local rule 2 state invalid enable

# Drop and do not log Customer SMB
set name zzservers-local rule 3 action drop
set name zzservers-local rule 3 log disable
set name zzservers-local rule 3 destination group port-group SMB
set name zzservers-local rule 3 protocol udp

# Allow inbound ICMP
set name zzservers-local rule 4 action accept
set name zzservers-local rule 4 protocol icmp

# Allow inbound VRRP
set name zzservers-local rule 5 action accept
set name zzservers-local rule 5 protocol vrrp

# Allow inbound BGP
set name zzservers-local rule 6 action accept
set name zzservers-local rule 6 destination port 179
set name zzservers-local rule 6 protocol tcp

# Allow inbound BGP
set name zzservers-local rule 7 action accept
set name zzservers-local rule 7 source port 179
set name zzservers-local rule 7 protocol tcp

# Allow inbound HEARTBEAT
set name zzservers-local rule 8 action accept
set name zzservers-local rule 8 destination port 694
set name zzservers-local rule 8 protocol udp

# Allow inbound HEARTBEAT
set name zzservers-local rule 9 action accept
set name zzservers-local rule 9 source port 694
set name zzservers-local rule 9 protocol udp

# Allow inbound SSH
set name zzservers-local rule 10 action accept
set name zzservers-local rule 10 log enable
set name zzservers-local rule 10 source group address-group SSH-FROM
set name zzservers-local rule 10 destination port 22
set name zzservers-local rule 10 protocol tcp

# Logging rule
set name zzservers-local rule 9999 action drop
set name zzservers-local rule 9999 log enable

And the final rules for direct access from the router are the rules from the local interface to zzservers.

• Set default policy to Deny, dropping any unauthorized connection
• Allow established and related connections
• Drop all invalid states
• Accept ICMP
• Accept VRRP
• Accept BGP
• Accept HEARTBEAT
• Accept DNS
• Deny and log everything else

# Default Deny
set name local-zzservers default-action drop

# Accept established and related
set name local-zzservers rule 1 action accept
set name local-zzservers rule 1 state established enable
set name local-zzservers rule 1 state related enable
set name local-zzservers rule 2 action drop
set name local-zzservers rule 2 log enable
set name local-zzservers rule 2 state invalid enable

# Allow outbound ICMP
set name local-zzservers rule 4 action accept
set name local-zzservers rule 4 protocol icmp

# Allow outbound VRRP
set name local-zzservers rule 5 action accept
set name local-zzservers rule 5 protocol vrrp

# Allow outbound BGP
set name local-zzservers rule 6 action accept
set name local-zzservers rule 6 destination port 179
set name local-zzservers rule 6 protocol tcp

# Allow outbound BGP
set name local-zzservers rule 7 action accept
set name local-zzservers rule 7 source port 179
set name local-zzservers rule 7 protocol tcp

# Allow outbound HEARTBEAT
set name local-zzservers rule 8 action accept
set name local-zzservers rule 8 destination port 694
set name local-zzservers rule 8 protocol udp

# Allow outbound HEARTBEAT
set name local-zzservers rule 9 action accept
set name local-zzservers rule 9 source port 694
set name local-zzservers rule 9 protocol udp

# Allow outbound dns lookups
set name local-zzservers rule 10 action accept
set name local-zzservers rule 10 destination port 53
set name local-zzservers rule 10 protocol tcp_udp

# Allow upgrades – only during valid change
#set name local-zzservers rule 69 action accept
#set name local-zzservers rule 69 log enable
#set name local-zzservers rule 69 destination port 80
#set name local-zzservers rule 69 protocol tcp# Logging rule
set name local-zzservers rule 9999 action drop
set name local-zzservers rule 9999 log enable

Now the rules are defined for inbound and outbound directly to and from the router.  The final set of rules to build are the rules for the traffic that flows “through” the router between the Internet & ZZ Servers.  There will again be 2 sets of rules for the ingress and egress packets.

The routing rules are different from the other rules in that they:

• Default allow all packets
• Block Servers specified in REJECT-SERVERS
• Block IP address ranges specified in REJECT-NETWORKS
• Block Ports specified in REJECT-PORTS

# Default route all packets
set name internet-zzservers default-action accept

# Deny and reject blocked servers / networks / ports
set name internet-zzservers rule 10 action reject
set name internet-zzservers rule 10 log enable
set name internet-zzservers rule 10 source group address-group REJECT-SERVERS
set name internet-zzservers rule 11 action reject
set name internet-zzservers rule 11 log enable
set name internet-zzservers rule 11 destination group address-group REJECT-SERVERS
set name internet-zzservers rule 15 action reject
set name internet-zzservers rule 15 log enable
set name internet-zzservers rule 15 source group network-group REJECT-NETWORKS
set name internet-zzservers rule 16 action reject
set name internet-zzservers rule 16 log enable
set name internet-zzservers rule 16 destination group network-group REJECT-NETWORKS
set name internet-zzservers rule 20 action reject
set name internet-zzservers rule 20 log enable
set name internet-zzservers rule 20 source group port-group REJECT-PORTS
set name internet-zzservers rule 21 action reject
set name internet-zzservers rule 21 log enable
set name internet-zzservers rule 21 destination group port-group REJECT-PORTS

The final set of rules are the same as internet-zzsevers but for traffic going out from zzservers-internet.

# Default route all packets
set name zzservers-internet default-action accept
# Deny and reject blocked servers / networks / ports
set name zzservers-internet rule 10 action reject
set name zzservers-internet rule 10 log enable
set name zzservers-internet rule 10 source group address-group REJECT-SERVERS
set name zzservers-internet rule 11 action reject
set name zzservers-internet rule 11 log enable
set name zzservers-internet rule 11 destination group address-group REJECT-SERVERS
set name zzservers-internet rule 15 action reject
set name zzservers-internet rule 15 log enable
set name zzservers-internet rule 15 source group network-group REJECT-NETWORKS
set name zzservers-internet rule 16 action reject
set name zzservers-internet rule 16 log enable
set name zzservers-internet rule 16 destination group network-group REJECT-NETWORKS
set name zzservers-internet rule 20 action reject
set name zzservers-internet rule 20 log enable
set name zzservers-internet rule 20 source group port-group REJECT-PORTS
set name zzservers-internet rule 21 action reject
set name zzservers-internet rule 21 log enable
set name zzservers-internet rule 21 destination group port-group REJECT-PORTS

With all of the filters now defined the final detail is to assign the segments (internet/zzservers/local) the appropriate devices.

You first will exit the firewall editor and edit the “zone-policy”

exit

edit zone-policy

Within the zone-policy we will configure:

• Default policy for all zones (internet/zzservers/local) to be to drop
• Identify the internet with eth0
• Identify the zz servers network with eth1
• Map the various rules to the appropriate policies
• Exit / Save and commit

# Set the default policy for zone internet to drop
set zone internet default-action drop
# For internet zone, traffic from zzservers to internet uses firewall filter zzservers-internet
set zone internet from zzservers firewall name zzservers-internet
# For internet zone, traffic from local router to internet  uses firewall filter local-internet
set zone internet from local firewall name local-internet
# Set internet zone assignment to eth0
set zone internet interface eth0

# Set the default policy for zzservers zone to drop
set zone zzservers default-action drop
# For zzservers zone, traffic from internet to zzservers uses firewall filter internet-zzservers
set zone zzservers from internet firewall name internet-zzservers
# For zzservers zone, traffic from local router to zzservers uses firewall filter local-zzservers
set zone zzservers from local firewall name local-zzservers
# Set zzservers interface eth1
set zone zzservers interface eth1

# Set the default policy for local zone to drop
set zone local default-action drop
# For local zone, traffic from internet to the local router uses firewall  filter internet-local
set zone local from internet firewall name internet-local
# For local zone, traffic from zzservers to the local router uses firewall filter zzservers-local
set zone local from zzservers firewall name zzservers-local
set zone local local-zone

exit
save
commit

With the rules now in place it is easy to block inappropriate traffic by adding the specific host/ip/port to the correct group.  The commands to add / remove items from the defined groups are as follows:

To add new IPs to the REJECT-IPS group and cause them to be rejected from the ZZ network, logon to the router and use the following command:

• configure
• set firewall group address-group REJECT-SERVERS address <ip to reject>
• commit
• save

To remove an IP address use a similar command replacing “set” with “delete”:

• configure
• delete firewall group address-group REJECT-SERVERS address <ip to remove>
• commit
• save

To reject subnets or ports use same syntax but change REJECT-SERVERS to REJECT-NETWORKS or REJECT-PORTS

The configuration generated by this example is attached below.  Good luck and remember, security should be a layered risk based approach and be sure to use all of the resources available to you.

vyatta-zone-firewall

References:
Vyatta
Vyatta is revolutionizing the networking industry by delivering a software-based, open-source, network operating system that is portable to standard x86 hardware as well as common virtualization and cloud computing platforms. By deploying Vyatta, users benefit from a flexible enterprise-class routing and security feature set capable of scaling from DSL to 20Gbps performance at a fraction of the cost of proprietary solutions. Thousands of physical and virtual infrastructures around the world, from small enterprise to Fortune 500, are connected and protected by Vyatta software and appliances.

Vyatta Community Edition
The free community Vyatta Core software(VC) is an award-winning open source network operating system providing advanced IPv4 and IPv6 routing, stateful firewalling, IPSec and SSL OpenVPN, intrusion prevention, and more. When you add Vyatta to a standard x86 hardware system, you can create an enterprise grade network appliance that easily scales from DSL to 10Gbps. Vyatta is also optimized to run in VMware, Citrix XenServer, Xen, KVM, and other hypervisors, providing networking and security services to virtual machines and cloud computing environments. Vyatta has been downloaded over 600,000 times, has a community of hundreds of thousands of registered users and counts dozens of fortune 500 businesses among its commercial customers.

Vyatta Documentation
Firewall (IPv4, IPv6, Zone-based Firewall) – Vyatta_Firewall_R6.1_v02.pdf

ZZ Servers
ZZ Servers was founded in 2006 by brothers Peter and David Zendzian to provide business and enterprise level hosted network environments at affordable prices. Our commitment to a high level of customer service and belief in personalized customer service for every client is an integral component of our business philosophy. Our goal is to work collaboratively with industry professionals, our clients and consumers to provide not just a source for affordable and secure hosted network infrastructures but also provide a friendly family oriented customer support experience.

ZZ Servers delivers a comprehensive collection of hosting services to organizations of all sizes. Our hosting services are at the core of our security and and management services and have been engineered for industry regulations including PCI, GLBA, SOX, HIPPA and ISO 27002.

We understand for your business to remain competitive and profitable, it needs to be on-line. We offer web hosting options that are custom tailored to fit your specific business needs. From our ultra affordable shared web hosting to state of the art geographically redundant solutions, we can meet your needs.

CentOS has numerous advantages over some of the other clone projects including an active and growing user community, quickly rebuilt, tested, and QA’ed errata packages, an extensive mirror network, developers who are contactable and responsive, multiple free support avenues including IRC Chat, Mailing Lists, Forums, a dynamic FAQ.

The following operating systems are now available for all VPS hosting packages:

• Debian 4.0 (Etch)
• Debian 5.0 (Lenny)
• Ubuntu 7.04 (Feisty Fawn)
• Ubuntu 8.04 LTS (Hardy Heron)
• CentOS 5.1

Currently all of our operating system versions come as a bare install.  What that means is we do not pre-install anything other than what it takes to get your server up and running.  Not is this method more secure, it allows you to configure the server exactly how you need it.

This vulnerability only affects operating systems which (like Ubuntu) are based on Debian. However, other systems can be indirectly affected if weak keys are imported into them. We consider this an extremely serious vulnerability, and urge all users to act immediately to secure their systems.

The following Ubuntu releases are affected:

• Ubuntu 7.04
• Ubuntu 7.10
• Ubuntu 8.04 LTS
• Debian Etch 4.0
• Debian Lenny 5.0

For more details visit these links:

• Ubuntu: http://www.ubuntu.com/usn/usn-612-2
• Debian: http://www.debian.org/security/2008/dsa-1571

We consider this an extremely serious vulnerability, and urge all users to act immediately to secure their systems.

- rw- r– r– other information about the file Filename

The initial – signifies that this is a file (not a directory). The next three characters refer to the file permissions for the file owner, in many cases the person who created the file. The values rw- signify that the owner has read and write (modify) permission but not execute permission. Had these values been r-x the owner would be able to read and execute the file (program) but not modify it. The second set of values r– signify that the members of the group associated with this file have read but not write or execute permission. The third set of values also r– signify that other users have read but not write or execute permission.

Permissions are often handled numerically. The r has a value of 4, the w has a value of 2, and the x has a value of 1. In all cases the lack of permission has the value 0. So rw- has the value 6 and r– has the value 4. In the above example the permissions may be expressed as 644. The full set of permissions for everyone is expressed as 777 (not usually a good idea).

Note that the root user’s permissions aren’t listed. This shouldn’t be surprising because root has essentially complete permissions. But even root’s doesn’t have execute permissions for a file it creates. This permission must be added in a separate step. Why? This two-step procedure has important security implications. Let’s say that someone, perhaps root, has received an email that contains a virus-infested executable program. The program cannot be executed without the explicit permission of root or the recipient. If the user doesn’t know what to do the virus won’t be launched.

Linux defines permissions for directories that are similar to but not exactly the same as the file permissions. A read permission on a directory means that its contents may be listed. A write permission on a directory means that the user can modify its contents, by adding, deleting, or renaming files. An execute permission on a directory means that it may be accessed, in other words made the current working directory.

Permissions may be changed via the chmod command as in the example chmod 770 Junque which gives read, write, and execute permissions to the file owner and members of the ownership group but no permissions to anyone else. Not everyone likes working with these numbers. The symbolic mode uses letters and the plus and minus signs to change permissions.

The following command removes the write permission from the user (owner) of the Perm file chmod u-w Perm. To add the execute permission for others, people who do not belong to the group that owns the file apply the command chmod o+x Perm This command only makes sense if the Perm file is executable. Furthermore, under most circumstances the file owner and his or her group will have more permissions that the others. Linux doesn’t always check to see that your command really makes sense. Do you think that Windows is more intelligent in this respect?

The chown command is used to change the ownership of a file or a directory. The chgrp command is used to change the group ownership of files and directories. These commands might be used when a project passes from the development to the testing stage. Needless to say only the system administrator can execute these commands.

Of course there is more to Linux permissions and groups but we have covered the basics. The next article in this series discusses inodes, a topic that is sorely missing from the Windows bag of tricks.

Levi Reiss has authored or co-authored ten books on computers and the Internet. He loves the occasional glass of wine as exemplified by his wine websites including http://www.theworldwidewine.com. He teaches Linux and Windows operating systems plus other computer courses at an Ontario French-language community college. Visit his new website http://www.linux4windows.com which teaches you how to download and run Damn Small Linux on Windows computers, even if they are "obsolete."

Article Source: http://EzineArticles.com

arch

Outputs the processor architecture.

$ arch

i686

cat

Outputs the contents of a file.

$ cat lorem.txt

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

cd

Change the working directory.

$ cd /bin

chgrp

Change group ownership of files.

$ chgrp games moo.txt

chmod

Change access permissions of files.

$ chmod +x helloworld

chown

Change file owner and group.

# chown root lorem.txt

cksum

Print CRC checksum and byte counts of each file.

$ cksum lorem.txt moo.txt

3570240675 453 lorem.txt

4294967295 0 moo.txt

cp

Copies a file.

$ cp lorem.txt copy_of_lorem.txt

date

Outputs the current date and time.

$ date

Sat Mar 3 12:07:09 GMT 2007

df

Reports the amount of disk space used and available on filesystems.

$ df

Filesystem 1K-blocks Used Available Use% Mounted on<br>

/dev/simfs 39845888 218048 39627840 1% /

dir

List directory contents.

$ dir

copy_of_lorem.txt lorem.txt moo.txt www

du

Estimate file space usage.

$ du -h /bin

7.8M /bin

echo

Display a line of text.

$ echo foobar

foobar

exit

Cause the shell to exit.

$ exit

fgrep

Print lines matching a pattern in a file.

$ fgrep “irure dolor” lorem.txt

commodo consequat. Duis aute irure dolor in reprehenderit in voluptate

find

Search for files in a directory hierarchy.

$ find hello*

hello_world

hello_world.c

free

Display amount of free and used memory in the system.

$ free

total used free shared buffers cached

Mem: 8299892 8287708 12184 0 2641772 1731236

Low: 3581300 3572764 8536

High: 4718592 4714944 3648

-/+ buffers/cache: 3914700 4385192

Swap: 8193140 2335664 5857476

grep

Print lines matching a pattern.

$ grep -i apple fruitlist.txt

apple

groups

Outputs the user groups of which your account belongs to.

$ groups

games users

head

Output the first part of files.

$ head -2 lorem.txt

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod

tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim

hostname

Outputs the machines hostname on the network.

$ hostname

anapnea.net

id

Outputs user id, group id, and groups of your account.

$ id

uid=1478(smallfoot) gid=100(users) groups=35(games),100(users)

kill

End a process.

$ kill -9 18298

-bash: kill: (18298) – Operation not permitted

killall

Kill processes by name.

$ killall irssi

irssi(18298): Operation not permitted

irssi(13372): Operation not permitted

irssi(22048): Operation not permitted

irssi: no process killed

last

Show listing of last logged in users.

$ last -n 3

alice pts/6 192.0.34.166 Fri May 18 16:17 still logged in

bob pts/2 64.233.183.103 Fri May 18 16:17 still logged in

clare pts/6 72.5.124.61 Fri May 18 15:54 – 15:55 (00:01)

ldd

Print shared library dependencies.

$ ldd /bin/bash

libncurses.so.5 => /lib/libncurses.so.5 (0×40023000)

libdl.so.2 => /lib/libdl.so.2 (0×40065000)

libc.so.6 => /lib/libc.so.6 (0×40069000)

/lib/ld-linux.so.2 (0×40000000)

ln

Make links between files.

$ ln -s data.txt symlink.txt

logname

Print user’s login name.

$ logname

smallfoot

ls

List directory contents.

$ ls

copy_of_lorem.txt lorem.txt moo.txt www

man

Opens the manual page for a software or function.

$ man bash

md5sum

Outputs the MD5 hash sum of a file.

$ md5sum lorem.txt

56da9e37259af34345895883e6fd1a27 lorem.txt

mkdir

Makes a directory.

$ mkdir foobar

mv

Moves a file.

$ mv lorem.txt ipsum.txt

nl

Number lines of files.

$ nl lorem.txt

1 Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod

2 tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim

3 veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea

4 commodo consequat. Duis aute irure dolor in reprehenderit in voluptate

5 velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint

6 occaecat cupidatat non proident, sunt in culpa qui officia deserunt

7 mollit anim id est laborum.

nm

List symbols from object files.

$ nm hello_world

080494a0 D _DYNAMIC

0804956c D _GLOBAL_OFFSET_TABLE_

08048474 R _IO_stdin_used

w _Jv_RegisterClasses

08049490 d __CTOR_END__

0804948c d __CTOR_LIST__

08049498 d __DTOR_END__

…

od

Dump files in octal and other formats.

$ od -t x /bin/sh

2376640 00098020 000054d4 00000000 00000000

2376660 00000020 00000000 000000c7 00000008

2376700 00000003 080e6500 0009d4f4 00004ae8

…

pidof

Find the process ID of a running program.

$ pidof fetchmail

22392

ping

Pings a host.

$ ping -c 2 127.0.0.1

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.

64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.048 ms

64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.052 ms

— 127.0.0.1 ping statistics —

2 packets transmitted, 2 received, 0% packet loss, time 999ms

rtt min/avg/max/mdev = 0.048/0.050/0.052/0.002 ms

ps

Outputs running processes.

$ ps

PID TTY TIME CMD

21542 pts/12 00:00:00 bash

27706 pts/12 00:00:00 ps

pstree

Display a tree of processes.

$ pstree

init-+-2*[BitchX]

|-3*[bash---sleep]

|-fetchmail

|-screen-+-bash—irssi

| `-bash—ctorrent

|-screen-+-bash—lisp.run

| |-bash—vi

| |-2*[bash]

| `-bash—lynx

|-2*[screen---bash---irssi]

|-screen—irssi

|-screen—bash

|-screen-+-bash

| `-irssi

|-skjerm—irssi

|-sshd-+-5*[sshd---sshd---bash---irssi]

| |-8*[sshd---sshd---bash]

| |-sshd—sshd—bash—screen

| |-sshd—sshd

| `-sshd—sshd—bash—pstree

`-syslog-ng

pwd

Outputs the name of current working directory.

$ pwd

/home/smallfoot

rm

Removes a file or directory.

$ rm lorem.txt

rmdir

Removes a directory.

$ rmdir foobar

sed

Stream editor for filtering and transforming text.

$ echo “My cat’s name is Bob” | sed -e ‘s/Bob/Mittens/g’

My cat’s name is Mittens

sha1sum

Outputs the SHA1 hash sum of a file.

$ sha1sum lorem.txt

c942ddebd142ec8bacac9213d48096e74bab4957 lorem.txt

shutdown

Bring the system down in a secure way. All logged-in users are notified that the system is going down.

$ shutdown now

size

List section sizes and total size.

$ size /bin/bash

text data bss dec hex filename

621233 22712 19176 663121 a1e51 /bin/bash

stat

Outputs file status.

$ stat lorem.txt

File: `lorem.txt’

Size: 453 Blocks: 8 IO Block: 4096 regular file

Device: 77h/119d Inode: 27312217 Links: 1

Access: (0644/-rw-r–r–) Uid: ( 1478/smallfoot) Gid: ( 100/ users)

Access: 2007-03-03 12:24:39.000000000 +0000

Modify: 2007-03-03 12:24:39.000000000 +0000

Change: 2007-03-03 12:24:39.000000000 +0000

strings

Print the strings of printable characters in files.

$ strings hello_world

/lib/ld-linux.so.2

_Jv_RegisterClasses

__gmon_start__

libc.so.6

puts

_IO_stdin_used

__libc_start_main

GLIBC_2.0

PTRh%

[^_]

Hello World!

tail

Output the last part of files.

$ tail -2 lorem.txt

occaecat cupidatat non proident, sunt in culpa qui officia deserunt

mollit anim id est laborum.

talk

Talk to another user.

$ talk bob Lookout for the dopefish!

touch

Change a file’s access and modification timestamps. If file does not exist, create it.

$ touch lorem.txt

tty

Outputs the name of the current terminal.

$ tty

/dev/pts/16

uname

Outputs operating system, hostname, kernel version, date and timp, and processor.

$ uname -a

Linux anapnea.net 2.6.9 #1 SMP Wed Jul 19 16:24:18 MSD 2006 i686 Intel(R) Xeon(TM) CPU 2.80GHz GenuineIntel GNU/Linux

uptime

Outputs the system uptime.

$ uptime

14:50:26 up 7 days, 17:52, 18 users, load average: 0.08, 0.02, 0.01

users

Print the user names of users currently logged in to the current host.

$ users

alice bob charlie eve

vdir

List directory contents.

$ vdir

total 8

-rw-r–r– 1 smallfoot users 453 Mar 3 12:32 copy_of_lorem.txt

-rw-r–r– 1 smallfoot users 453 Mar 3 12:24 lorem.txt

-rw-r–r– 1 smallfoot users 0 Mar 3 12:32 moo.txt

lrwxr-xr-x 1 root root 18 Feb 27 19:33 www -> /var/www/smallfoot

w

Show who is logged on and what they are doing.

$ w

12:14:30 up 5 days, 15:16, 19 users, load average: 0.00, 0.00, 0.00

USER TTY LOGIN@ IDLE JCPU PCPU WHAT

charlie pts/0 Fri21 3:26m 2.52s 2.52s irssi

alice pts/2 Wed17 30:21m 0.00s 0.00s -bash

emma pts/4 11:37 36:57 0.00s 0.00s -bash

frank pts/5 11:48 11:03 0.00s 0.00s -bash

smallfoo pts/12 12:01 0.00s 0.04s 0.01s w

wall

Send a message to everybody’s terminal.

$ wall next week we change the server for a new one

wc

Counts lines in a file.

$ wc -l lorem.txt

7 lorem.txt

whatis

Search the whatis database for complete words.

$ whatis bash

bash (1) – GNU Bourne-Again SHell

bash [builtins] (1) – bash built-in commands, see bash(1)

who

Outputs who is currently logged into the system.

$ who

charlie pts/0 Mar 2 21:37 (xtreme-11-65.acme.com)

alice pts/2 Feb 28 17:48 (147.21.16.3)

emma pts/4 Mar 3 11:37 (32.84-48-181.uac.com)

frank pts/5 Mar 3 11:48 (port-212-202-233-2.foobar.org)

smallfoot pts/12 Mar 3 12:01 (c-12776f4.cust.example.net)

whereis

Locate the binary, source, and manual page files for a command.

$ whereis bash

bash: /bin/bash /etc/bash /usr/share/man/man1/bash.1.gz

whoami

Outputs your username / the name of your account.

$ whoami

smallfoot

find <PATH> -print | xargs grep "<CONTENT>"

or

find <PATH> -type f -exec grep -H "<CONTENT>" \;