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.

After having used many open and commercial  monitoring systems, we have settled on Zabbix because of it’s extensive features and expandability (especially with the new integrated API).  That and it doesn’t hurt that it is well designed for expanded enterprises and is OpenSource.

This article was originally posted with details for Zabbix 1.6 and was updated on April 10 to reflect how to set it up under Zabbix 1.8.

OSSEC is a great tool provided by Trend Micro and is also an OpenSource application. OSSEC provides a variety of tools for host based intrusion detection including:  log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.  All of which support several compliance and basic security requirements. OSSEC is deployed in a client-server model with all alerting and active response features being controlled and sent through the central server.

To integrate OSSEC and Zabbix we will be using the active-response feature of OSSEC integrated with zabbix_sender to send the active response alert to the zabbix server.   Configuring for this integration requires a simple script, a quick change to the ossec.conf and the creation of an OSSEC template in the zabbix system.

We will start with the OSSEC changes.  First, we will edit the OSSEC/etc/ossec.conf file, where OSSEC is the path to your OSSEC installation.  In this file you will need to add the following items:

<command>
<name>zabbix-alert</name>
<executable>zabbix-alert.sh</executable>
<timeout_allowed>no</timeout_allowed>
<expect></expect>
</command>

<active-response>
<disabled>no</disabled>
<command>zabbix-alert</command>
<location>server</location>
<level>1</level>
</active-response>

The first <command> item defines the script we will be using for the zabbix-alert.  The <active-response> item defines when the system will use this script.  The defined configuration above has all alerts at and above level “1″ sent to the zabbix-alert command.  This can be modified for higher levels or specific rules or rule groups.  More information on this configuration can be found in the OSSEC manual.

Now the zabbix-alert.sh script needs to be put into the OSSEC/active-response/bin directory (be sure to watch for lines that are wrapped around but shouldn’t be).  You can download the script here: zabbix-alert.sh.

#!/bin/sh
#
# Submits an OSSEC alert as a passive service check result to zabbix.
#
# Author: David M. Zendzian
# ZZ Servers, LLC 2010
#
# Idea from Dave Stycos post: http://groups.google.com/group/ossec-dev/browse_thread/thread/e29c5d71926b8af5
#
# This script is Public Domain, and is provided AS-IS.  There is no
# warranty, and no support given for its contents.
#
# Version 1.0: Apr. 6, 2010
#

DEBUG=”false”
ACTION=$1
USER=$2
IP=$3
ALERTID=$4
RULEID=$5

LOCAL=`dirname $0`;
cd $LOCAL
cd ../
PWD=`pwd`
UNAME=`uname`

# Zabbix Sender
ZabbixSender=”/usr/bin/zabbix_sender”
#ZabbixSender=”/usr/sbin/zabbix_sender”

# Zabbix Server
ZabbixServer=<your zabbix server ip>

# Zabbix Port
ZabbixPort=10051

# All alerts will be processed by Zabbix under this key.
ZabbixKeyName=OSSEC

# Check that zabbix_sender file exists.
if [ ! -w $ZabbixSender ]; then
logger -p local0.err “$0: File $ZabbixSender not found.  Exiting.”
exit 1
fi

# Getting alert time
ALERTTIME=`echo “$ALERTID” | cut -d  “.” -f 1`

# Getting end of alert
ALERTLAST=`echo “$ALERTID” | cut -d  “.” -f 2`

# Getting full alert
ALERTTEXT=`grep -A 10 “$ALERTTIME” $PWD/../logs/alerts/alerts.log | grep -v “.$ALERTLAST: ” -A 10 `

# Extract host (agent) name from alert.
HOSTNAME=`echo “$ALERTTEXT” | sed -n ’1,1s/^.*\:[0-9][0-9]\:[0-9][0-9][^A-Za-z0-9_]*\([-A-Za-z0-9_]*\)\->.*$/\1/p’`

# if hostname alert wasn’t from local host, the host value is “(hostname) ip”, which extracts differently
if [ "$HOSTNAME" = "" ]
then
HOSTNAME=`echo “$ALERTTEXT” | sed -n ’1,1s/^.*\:[0-9][0-9]\:[0-9][0-9] (\([-A-Za-z0-9_]*\)) .*\->.*$/\1/p’`
fi
if [ "$HOSTNAME" = "" ]
then
exit 0
fi

# Extract alert level from alert.
ALERTLVL=`echo “$ALERTTEXT” | sed -n ’2,2s/^.*(level \([0-9]*\).*$/\1/p’`

# Extract description from alert.
ALERTMSG=`echo “$ALERTTEXT” | sed -n ’5,5p’`

# Create Alert message
# Short MSG version
#ZMSG=”$ALERTID | $ALERTLVL | $RULEID – $ALERTMSG”
# Full MSG Version
ZMSG=”AlertID: $ALERTID | User: $USER | IP: $IP | Level: $ALERTLVL | RuleID: $RULEID – $ALERTMSG”

# Send result to zabbix for logging and notification alerts.
$ZabbixSender –zabbix-server $ZabbixServer –port $ZabbixPort –host $HOSTNAME –key $ZabbixKeyName –value “$ZMSG”

if [ "$DEBUG" = "true" ]
then
echo “$ZabbixSender –zabbix-server $ZabbixServer –port $ZabbixPort –host $HOSTNAME –key $ZabbixKeyName –value ‘$ZMSG’” >> /tmp/zabbix-test.log
echo “ACTION: $ACTION” >> /tmp/zabbix-test.log
echo “USER: $USER”
echo “IP: $IP” >> /tmp/zabbix-test.log
echo “ALERTID: $ALERTID” >> /tmp/zabbix-test.log
echo “ALERTLVL: $ALERTLVL” >> /tmp/zabbix-test.log
echo “RULEID: $RULEID” >> /tmp/zabbix-test.log
echo “———————————” >> /tmp/zabbix-test.log
fi

With the script saved, you can restart OSSEC (OSSEC/bin/ossec-control restart) or wait until zabbix is setup then restart.

UPDATE 07-16-2010 – If you are using zabbix-proxies then you need to have the OSSEC alerts for proxy monitored hosts submitted through the proxy server.  This isn’t a problem with the existing script if the proxy server is also monitored through the proxy; just update the server IP to be the proxy not the central zabbix server.  If you monitor your proxy directly from the central zabbix server then the script needs to be updated to support sending proxy hosts though proxy and the host itself directly to zabbix.  The script can be found here; or below.  Again be sure to watch for broken wrapped lines:

#!/bin/sh
#
# Submits an OSSEC alert as a passive service check result to zabbix.
#
# Author: David M. Zendzian
#
# Idea from Dave Stycos post: http://groups.google.com/group/ossec-dev/browse_thread/thread/e29c5d71926b8af5
#
# Updated 7/15/10 – using 2 server hosts in case using proxies and local host is monitored directly by central server and not proxy.
#
# This script is Public Domain, and is provided AS-IS.  There is no
# warranty, and no support given for its contents.
#
# Version 1.1: Jul. 15, 2010
#

DEBUG=”true”
ACTION=$1
USER=$2
IP=$3
ALERTID=$4
RULEID=$5

if [ "$DEBUG" = "true" ]
then
echo “NOTICE: Starting Zabbix sender” >> /tmp/zabbix-test.log
fi

LOCAL=`dirname $0`;
cd $LOCAL
cd ../
PWD=`pwd`
UNAME=`uname`

# Zabbix Sender
ZabbixSender=”/usr/bin/zabbix_sender”
#ZabbixSender=”/usr/sbin/zabbix_sender”

# Zabbix Server
# Set server2 to be the same if all hosts monitored through proxy or the same server; otherwise
# set ZabbixServer to the proxy for non-localhost and then ZabbixServer2 to the host that the
# local proxy uses
ZabbixServer=<Server/Proxy>
ZabbixServer2=<Server for “Localhost”>

# Zabbix Port
ZabbixPort=10051

# All alerts will be processed by Zabbix under this key.
ZabbixKeyName=OSSEC

# Check that zabbix_sender file exists.
if [ ! -w $ZabbixSender ]; then
logger -p local0.err “$0: File $ZabbixSender not found.  Exiting.”
if [ "$DEBUG" = "true" ]
then
echo “ERROR: No Zabbix Sender” >> /tmp/zabbix-test.log
fi
exit 1
fi

# Getting alert time
ALERTTIME=`echo “$ALERTID” | cut -d  “.” -f 1`

# Getting end of alert
ALERTLAST=`echo “$ALERTID” | cut -d  “.” -f 2`

# Getting full alert
ALERTTEXT=`grep -A 10 “$ALERTTIME” $PWD/../logs/alerts/alerts.log | grep -v “.$ALERTLAST: ” -A 10 `

# Extract host (agent) name from alert.
HOSTNAME=`echo “$ALERTTEXT” | sed -n ’1,1s/^.*\:[0-9][0-9]\:[0-9][0-9][^A-Za-z0-9_]*\([-A-Za-z0-9_]*\)\->.*$/\1/p’`

# if hostname alert wasn’t from local host, the host value is “(hostname) ip”, which extracts differently
if [ "$HOSTNAME" = "" ]
then
HOSTNAME=`echo “$ALERTTEXT” | sed -n ’1,1s/^.*\:[0-9][0-9]\:[0-9][0-9] (\([-A-Za-z0-9_]*\)) .*\->.*$/\1/p’`
fi
if [ "$HOSTNAME" = "" ]
then
if [ "$DEBUG" = "true" ]
then
echo “ERROR: No Hostname” >> /tmp/zabbix-test.log
fi
exit 0
fi

# if the local host is a proxy then monitored items submitted through proxy, localhost probably monitored directly from central server (if not change comment this out)
LOCALHOSTNAME=`hostname -s`
if [ "$HOSTNAME" = "$LOCALHOSTNAME" ]
then
ZabbixServer=$ZabbixServer2
fi

if [ "$DEBUG" = "true" ]
then
echo “ZabbixServer: $ZabbixServer” >> /tmp/zabbix-test.log
fi

# Extract alert level from alert.
ALERTLVL=`echo “$ALERTTEXT” | sed -n ’2,2s/^.*(level \([0-9]*\).*$/\1/p’`

# Extract description from alert.
ALERTMSG=`echo “$ALERTTEXT” | sed -n ’5,5p’`

# Create Alert message
ZMSG=”$ALERTID | $ALERTLVL | $RULEID – $ALERTMSG”

# Send result to zabbix for logging and notification alerts.
$ZabbixSender –zabbix-server $ZabbixServer –port $ZabbixPort –host $HOSTNAME –key $ZabbixKeyName –value “$ZMSG”

if [ "$DEBUG" = "true" ]
then
echo “$ZabbixSender –zabbix-server $ZabbixServer –port $ZabbixPort –host $HOSTNAME –key $ZabbixKeyName –value ‘$ZMSG’” >> /tmp/zabbix-test.log
echo “ACTION: $ACTION” >> /tmp/zabbix-test.log
echo “USER: $USER” >> /tmp/zabbix-test.log
echo “IP: $IP” >> /tmp/zabbix-test.log
echo “ALERTID: $ALERTID” >> /tmp/zabbix-test.log
echo “ALERTLVL: $ALERTLVL” >> /tmp/zabbix-test.log
echo “RULEID: $RULEID” >> /tmp/zabbix-test.log
echo “———————————” >> /tmp/zabbix-test.log
fi

exit 0

UPDATE 09-24-2010 – If you happen to use full domain names, the regex for getting the name needs to allow “.”  – The script can be found zabbix-alert-201009; or below.  Again be sure to watch for broken wrapped lines:

#!/bin/sh
#
# Submits an OSSEC alert as a passive service check result to zabbix.
#
# Author: David M. Zendzian
#
# Idea from Dave Stycos post: http://groups.google.com/group/ossec-dev/browse_thread/thread/e29c5d71926b8af5
#
# Updated 7/15/10 – using 2 server hosts in case using proxies and local host is monitored directly by central server and not proxy.
#
# This script is Public Domain, and is provided AS-IS.  There is no
# warranty, and no support given for its contents.
#
# Version 1.1: Jul. 15, 2010
#

DEBUG=”true”
ACTION=$1
USER=$2
IP=$3
ALERTID=$4
RULEID=$5

if [ "$DEBUG" = "true" ]
then
echo “NOTICE: Starting Zabbix sender” >> /tmp/zabbix-test.log
fi

LOCAL=`dirname $0`;
cd $LOCAL
cd ../
PWD=`pwd`
UNAME=`uname`

# Zabbix Sender
ZabbixSender=”/usr/bin/zabbix_sender”
#ZabbixSender=”/usr/sbin/zabbix_sender”

# Zabbix Server
# Set server2 to be the same if all hosts monitored through proxy or the same server; otherwise
# set ZabbixServer to the proxy for non-localhost and then ZabbixServer2 to the host that the
# local proxy uses
ZabbixServer=<Server/Proxy>
ZabbixServer2=<Server for “Localhost”>

# Zabbix Port
ZabbixPort=10051

# All alerts will be processed by Zabbix under this key.
ZabbixKeyName=OSSEC

# Check that zabbix_sender file exists.
if [ ! -w $ZabbixSender ]; then
logger -p local0.err “$0: File $ZabbixSender not found.  Exiting.”
if [ "$DEBUG" = "true" ]
then
echo “ERROR: No Zabbix Sender” >> /tmp/zabbix-test.log
fi
exit 1
fi

# Getting alert time
ALERTTIME=`echo “$ALERTID” | cut -d  “.” -f 1`

# Getting end of alert
ALERTLAST=`echo “$ALERTID” | cut -d  “.” -f 2`

# Getting full alert
ALERTTEXT=`grep -A 10 “$ALERTTIME” $PWD/../logs/alerts/alerts.log | grep -v “.$ALERTLAST: ” -A 10 `

# Extract host (agent) name from alert.
HOSTNAME=`echo “$ALERTTEXT” | sed -n ’1,1s/^.*\:[0-9][0-9]\:[0-9][0-9][^A-Za-z0-9_]*\([-A-Za-z0-9_.]*\)\->.*$/\1/p’`

# if hostname alert wasn’t from local host, the host value is “(hostname) ip”, which extracts differently
if [ "$HOSTNAME" = "" ]
then
HOSTNAME=`echo “$ALERTTEXT” | sed -n ’1,1s/^.*\:[0-9][0-9]\:[0-9][0-9] (\([-A-Za-z0-9_.]*\)) .*\->.*$/\1/p’`
fi
if [ "$HOSTNAME" = "" ]
then
if [ "$DEBUG" = "true" ]
then
echo “ERROR: No Hostname” >> /tmp/zabbix-test.log
fi
exit 0
fi

# if the local host is a proxy then monitored items submitted through proxy, localhost probably monitored directly from central server (if not change comment this out)
LOCALHOSTNAME=`hostname -s`
if [ "$HOSTNAME" = "$LOCALHOSTNAME" ]
then
ZabbixServer=$ZabbixServer2
fi

if [ "$DEBUG" = "true" ]
then
echo “ZabbixServer: $ZabbixServer” >> /tmp/zabbix-test.log
fi

# Extract alert level from alert.
ALERTLVL=`echo “$ALERTTEXT” | sed -n ’2,2s/^.*(level \([0-9]*\).*$/\1/p’`

# Extract description from alert.
ALERTMSG=`echo “$ALERTTEXT” | sed -n ’5,5p’`

# Create Alert message
ZMSG=”$ALERTID | $ALERTLVL | $RULEID – $ALERTMSG”

# Send result to zabbix for logging and notification alerts.
$ZabbixSender –zabbix-server $ZabbixServer –port $ZabbixPort –host $HOSTNAME –key $ZabbixKeyName –value “$ZMSG”

if [ "$DEBUG" = "true" ]
then
echo “$ZabbixSender –zabbix-server $ZabbixServer –port $ZabbixPort –host $HOSTNAME –key $ZabbixKeyName –value ‘$ZMSG’” >> /tmp/zabbix-test.log
echo “ACTION: $ACTION” >> /tmp/zabbix-test.log
echo “USER: $USER” >> /tmp/zabbix-test.log
echo “IP: $IP” >> /tmp/zabbix-test.log
echo “ALERTID: $ALERTID” >> /tmp/zabbix-test.log
echo “ALERTLVL: $ALERTLVL” >> /tmp/zabbix-test.log
echo “RULEID: $RULEID” >> /tmp/zabbix-test.log
echo “———————————” >> /tmp/zabbix-test.log
fi

exit 0

For this integration to work, the host names used in OSSEC need to match the host names defined in Zabbix.  If they do not match, then zabbix_sender results will not make it into the hosts items correctly.

The easiest way to setup zabbix is to setup a template.  This template will define the application, item and triggers for OSSEC and can easily be linked to the hosts you are monitoring.

In zabbix goto Configure/Hosts and select ‘templates’.

Create a new template called OSSEC and be sure to add it to the Templates group.

Zabbix 1.6: Add OSSEC Template

Zabbix 1.8: Add OSSEC Template

With the template created, a new application needs to be created so the OSSEC items have a place to be organized.  Staying in Configuration / Hosts (for Zabbix 1.6 & 1.8), in the drop down on the upper right, select “Applications” and then from the group and host dropdown, select Templates / Template_OSSEC that was just created.  There should be no Applications in the list. If you do not see Template_OSSEC that was just created, go back to templates and edit the OSSEC item and be sure that it is in the “Templates” group.

Click on “Create application” and create “OSSEC Monitor” or whatever you want to call it.

Zabbix 1.6: Create OSSEC Template Application

Zabbix 1.8: Create OSSEC Application

Now we are ready to create the Item & Trigger for the OSSEC data.  In Zabbix 1.6, select “Configuration / Items” and select “Templates / Template_OSSEC” from the group and host selections and then click on “Create Item.”  The important item here is the Key which we will setup as OSSEC and is required to match the ZabbixKeyName in the zabbix-alert.sh script on the OSSEC server.

Zabbix 1.6: Create OSSEC Item

In Zabbix 1.8, remain in the “Configuration / Hosts” menu and in the upper right drop down select “Items”.  Click on “Create Item.”  When the new form is up, click on “Select” for the Host and select Template_OSSEC that we created above.  The same values will be set as with Zabbix 1.6.

Zabbix 1.8: Create OSSEC Item

As you can see, the item is a “Text” type getting data from a Zabbix Trapper event.  The things to not forget here are to enter your OSSEC server(s) in the Allowed Host line and to select the OSSEC Monitor application.

The next step is to create a trigger which will let us know when new data has arrived from OSSEC. Select “Configuration / Triggers” in Zabbix 1.6.

If you are using 1.8 then remain on the “Configuration / Hosts” page and select “Triggers” from the dropdown box on the upper right.

It should default to the Template_OSSEC host, but if it doesn’t then select Templates from groups and the Template_OSSEC host.

There are several ways to monitor the OSSEC text data, but I have selected to alert if there is new data in the last 10 minutes.  As you can see from the screenshot, the expression I used is {Template_OSSEC:OSSEC.nodata(600)}#1.  This works because the nodata(600) will return a 1 if no data is received in the time period specified (600 sec or 10 min).  So if it ever returns anything other than 1, we have new data.  For more information on trigger functions, consult the zabbix manual.

Now click on “Create Trigger” go create the trigger.

Zabbix 1.6: Create OSSEC Zabbix Trigger

Zabbix 1.8: Create OSSEC Zabbix Trigger

I have set the alert severity to “average” but you may want to change that depending on your needs.  The zabbix actions we will define will send all OSSEC alerts so the severity will not really matter.  One thing that is worth examining is to change the OSSEC item value to log instead of text which could allow for log severity and other values that could be used with the OSSEC alert levels; but that project is for another time.

Updated: 4/16/10 – What I have done for alerting based on level is to use the “short” ZMSG message type in the zabbix-alert.sh script and define a trigger such as:

({Template_OSSEC:OSSEC.nodata(600)}#1)&({Template_OSSEC:OSSEC.str( | 1 | )}#1)&({Template_OSSEC:OSSEC.str( | 2 | )}#1)&({Template_OSSEC:OSSEC.str( | 3 | )}#1)

What this trigger does is requires all 4 conditions to be met (&=”AND” between each item test).  The first is that there is new data within the last 10 minutes, the other 3 are requirements that the new data does not contain | 1 | or | 2 | or | 3 |, which would be OSSEC alert levels 1, 2 and 3.  If you use the longer ZMSG then the str values would be like: {Template_OSSEC:OSSEC.str( | Level: 3 | )}#1

Only 2 things left to do and the OSSEC/Zabbix integration is done.  These are to create actions for OSSEC events and to link the OSSEC template to the hosts you are monitoring with OSSEC.

In our local zabbix configuration I have created a “Security Administrator” group that receives IDS and other security events and will be using that to specify who receives the alerts.  You can modify these settings based on your local policy and zabbix configuration.

As you will also see in the following screenshot, I have modified the default message.  This allows me to receive the full data from the OSSEC event through {ITEM.LASTVALUE}.  I have also shortened the message so I can receive the details I want on my SMS alerts which have a smaller size than full emails.

I have tried to enable escalations for OSSEC alerts, however the way that zabbix handles items is that it will only look at the “active” triggers & items, what this means is that when a new OSSEC alert comes in and is added to the items database, the trigger is alerted but after 10 minutes it will “go away”.  There is no way, currently, to have a trigger depend on it’s being “Ack’d” which would be preferred for security, log and other events that just shouldn’t go away until an admin acks what happened.  There is a currently active zabbix feature request requesting this, so please go vote it up so we can see it added in the near future!

Zabbix 1.6: Create OSSEC Action

Zabbix 1.8: Create OSSEC Action

All that is left is to link your hosts to the OSSEC template.  The OSSEC alert submits data to zabbix based on the host names defined in OSSEC.  So once again, please be sure the names used match in both systems.

If you do not know how to link the OSSEC template, simply go to “Configuration / Hosts” and edit the hosts that are monitored by OSSEC.  You need to link every host as the alerts will be coming in directly to each unique host.  The example below is for one of our ossec servers, but the configuration should be the same for all OSSEC monitored hosts.

Zabbix 1.6: Host OSSEC Template Link

Zabbix 1.8: Host OSSEC Template Link

This should be it.  If you have already restarted OSSEC then you just need to create an event it will alert on (logging onto monitored host, creating “segfault” log messages: logger “segfault”, etc).  In my quick test, seen below, I did a failed logon (bad pw) and within a few seconds I had my jabber alert pop up and a sms message arrive on my phone!

If you have any problems, you can set DEBUG=true in the zabbix-alert.sh and it will log out what is being sent to zabbix into /tmp/zabbix-test.log.

If OSSEC is not running active-alerts, you may want to jump on #ossec on the openprojects IRC and get some assistance or search google.

Good luck!

David M. Zendzian | Managing Partner | ZZ Servers
268 Bush St. #4127 | San Francisco, CA 94104

Business Hosting Solutions | PCI | HIPAA
Managed Hosting Specialists

1. Improved efficiency in health care delivery by standardizing electronic data interchange, and
2. Protection of confidentiality and security of health data through setting and enforcing standards.

More specifically, HIPAA called upon the Department of Health and Human Services (HHS) to publish new rules that will ensure:

1. Standardization of electronic patient health, administrative and financial data
2. Unique health identifiers for individuals, employers, health plans and health care providers
3. Security standards protecting the confidentiality and integrity of “individually identifiable health information,” past, present or future.

Compliance requirements include:

• Building initial organizational awareness of HIPAA
• Comprehensive assessment of the organization’s privacy practices, information security systems and procedures, and use of electronic transactions
• Developing an action plan for compliance with each rule
• Developing a technical and management infrastructure to implement the plans
• Implementing a comprehensive implementation action plan, including
• Developing new policies, processes, and procedures to ensure privacy, security and patients’ rights
• Building business associate agreements with business partners to support HIPAA objectives
• Developing a secure technical and physical information infrastructure
• Updating information systems to safeguard protected health information (PHI) and enable use of standard claims and related transactions
• Training of all workforce members
• Developing and maintaining an internal privacy and security management and enforcement infrastructure, including providing a Privacy Officer and a Security Officer

All of these requirements apply to not only the company which owns the PHI, but also any company or contractor they work with who has access to this information. The details on how to meet the HIPAA requirements is up to the individual company, allowing the “market to dictate” the terms and conditions.

Most companies I have worked with spend a considerable amount of time generating the paper documentation they feel will meet the above requirements. That is the most important part of any security policy or plan, knowing what is important (PHI/Card Data/Financial/etc) and defining how the business will properly control that information.

Data-centers, managed service providers and other contracted service providers come into this picture when companies outsource their data-center operations or when you are partnering with a company for data-center services. If you look at the HIPAA requirements, they all can be applied in some form or another to the outsourced provider, but the validation is left up to the contracting business and there is no guidance other than “best practices”.

So what should you look for in a business partner to have that can meet these HIPAA requirements? Before I answer that, I would like to discuss a similar security standard. As you may know from regular occurrence in the news, credit card data is lost and stolen on an increasingly regular basis. To help fight this, the Payment Card Industry has created the PCI Security Standards Council whose charter is to create and maintain specific industry standards and to train qualified assessors on how to validate against those standards. Any business that stores, transmits or processes credit card data is required to abide by these standards. This means even the person with a cellular card swipe machine at the flea market has to meet the same standards as Walmart, Amazon.com, PayPal or other multi-national merchants and banks. Below is a list of 12 sections in the PCI Security Audit Procedure which which you should look for from any service provider or partner you are considering. These sections break down in detail the steps which must be taken to comply with the PCI standard. To get more information, you can download the PCI details here https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf and here https://www.pcisecuritystandards.org/pdfs/pci_audit_procedures_v1-1.pdf

1. Firewalls & Routers
2. Service configuration (note service includes servers/applications/databases/firewalls/etc)
3. Storage of Card data (what is/is not allowed, encryption, secure deletion), Data retention policy
4. Transmission of card data (SSL, VPN, 802.11, etc)
5. Anti-virus
6. Secure Development — ** Change Management **
7. Need-to-know
8. Unique ID for _everyone_ – no shared root, enable, administrator & password requirements
9. Physical Security
10. Logging & Time sync
11. Security Testing (security scanning, pen testing)
12. Policies, Contracts, Security Training, Risk Assessment, Incident Response Policies, Connected Entities (partner connection) management

Additionally, depending on which services you plan on using from a contracted provider or partner, different sections will apply for example:

• If they are going to provide router or firewall services, section 1
• If they are going to provide any servers (virtual or real) then sections 2, 5, 7, 8, 9, 10, 11 & 12 (yes most of it:)
• If they are going to provide development support sections 3, 4 & 6
• If they are going to provide system management support, 2, 3, 4, 5, 7, 8, 10

I mention PCI because unlike the HIPAA requirements, the PCI Standards and process is very clearly defined. While PCI is not perfect, since it was based on ISO17799 it covers a wide range of security issues. If you take the PCI standards and replace PCI with HIPAA or Financial (SOX), then you have a great guideline and audit procedure to work with for your own and your partners security.

So back to the question for this thread. How can you determine if a data-center/service provider meets your needs for the various compliance requirements. To answer this, you need to determine the role the service provider has with relation to your business and your specific data-set requirements.

If you are looking for somewhere to host your entire “business” and then VPN back into your company network, then you have physical, network, policy, procedure and contractual security needs.

If you are looking to have someone provide a more hands-on role then the same requirements are met, but then the providers mechanisms for providing support will then need to be evaluated. This would bring the assessment into the way they store passwords, monitor systems, provide support, troubleshoot, maintain change management, key-management, security monitoring, image management, upgrades, etc.

Giving all of these considerations, as a business you need to determine how you wish to handle the requirements. If you are a large merchant or service provider, you typically get ISO or SAS70 audits. Any data-center should be able to provide that assessment as you are trying to determine who you wish to work with. Keep in mind that with these assessments, the company has hired the auditor to validate a “specific” item, so the audit report will be focused only on that and may not take into consideration other processes or areas within the facility.

If the company has been through a PCI or other audit they should be able to provide some documentation regarding the audit and the controls they have in place that they used to go through the audit.

If they are a service provider (providing services to PCI organizations) and have been through a level 1 audit then they will be listed here: http://usa.visa.com/download/merchants/cisp_list_of_cisp_compliant_service_providers.pdf

Not many ISPs or Data-Centers have been through a level 1 PCI audit as they are usually very costly and if you read through the SAP you will find time consuming in the details that need to be met.

So what can you hope to find in a service partner you are looking to host with:

• A physical location that has good security controls
• 24×7 guard & locked doors
• Sign-in required and only authorized visitors
• at least 3 months camera data (90 days) on all entrances & exits to data-center facility
• Security for the physical servers (do not use shared cages)
• Policies
• Standard configuration documentation for all services you are getting services for (servers, firewalls, load balancers, certificates, etc)
• Network & server security – IDS / IPS / Host IDS / Log Monitoring / Internal & External Scanning / ASV Scanning
• Change Management that includes
• Documentation of impact
• Management sign off – colo should notify of customers of changes (good communication, as it was mentioned in a previous post, most providers that provide HIPAA or other services tend to have more communication with their customers)
• Back out plan / procedure
• Functional testing

If you are looking for more advanced services to ensure that not only is the machine physically secure, but also have you deployed your application architecture properly, then you may want to also be sure the service provider can also provide:

• Firewalls
• Private Networks
• VPN
• Load balancers
• 2 factor authentication
• IDS
• Log Monitoring
• Centralized logging
• Monitoring (Security & Availability)
• Development services
• Code review
• Time services (NTP)
• Senior Security & Architectural staff as well as Sr systems staff

Many of the people I have worked with have needed just about all of the above services when they are either building, expanding or migrating their applications into data-center facilities.

I know I did not stick specifically with the HIPAA question, but hopefully this information will help those are looking for new hosting facilities.

Now for those who are wondering, well do you provide those services? The short answer is yes. However not all are immediately activated “web dashboard” ready services and require a direct relationship with our senior architects and systems folks.

Our San Francisco data-center is through a partnership with ColoServe who provides the physical security and raw bandwidth to our secure cabinets. While the physical center has not been through any Level 1 PCI audits, ZZ servers has been through 2 bi-annual security audits by American Express for one of our customers and the facility has a SAS70 certificate and has the added security of also hosting the 911 systems for the city of San Francisco so our structural, power and data systems are a step above par.

I myself consult with a QSA out of San Meto (http://www.drgsf.com) and perform Level 1 audits and Security Assessment for payment applications as specified by the Payment Applications Best Practices following the PA-DSS (https://www.pcisecuritystandards.org/tech/pa-dss.htm

After spending 20 years building and working with small to large companies and founding 3 previous ISP services I wanted to bring a level of business service to the hosting community. So in founding ZZ Servers with my brother, Peter – a 20 year Navy vet currently spending his last year in the service stationed in Bagdad), we specifically created the infrastructure to be able to provide many if not all of the requirements mentioned above.

We are focused on providing services that are priced to compete with the largest players (rack-space, one and one, etc) but to also have the value added services I discussed in the requirements listings above.

We currently have customers utilizing the following services:

• Co-located servers
• Leased Servers
• Virtual Private Servers
• Private Networks
• Multiple firewalls (internal & external)
• Load Balancers
• Managed monitoring & support
• Centralized Logging & monitoring
• IDS
• VPN
• 2 Factor Authentication with CryptoCard
• Time services (NTP)
• Senior Security & Architectural staff as well as senior systems staff

And we are in the midst of deploying a full change-management system that will be available to any customer using any service which will fully integrated into all hosted services (schedule changes for firewalls or clusters of servers, and track status of each individual change).

We have also just signed an agreement with DRG to provide integrated ASV scanning which will be integrated into our order wizard allowing customers to sign-up and manage their PCI compliant scans and automatically send results to your merchant bank. This service will also include an on line form for creating and submitting the Self Assessment Questionnaire.

We are a small family-run business focused on slow growth and providing tools for both the smaller & larger customers to grow into whatever their business has potential for.

For more details about HIPPA, please visit (http://www.hipaadvisory.com/regs/HIPAAprimer.htm)

Regards,

David