If a phone is lost or stolen, your natural reaction may be to change your password. This is not a good idea, because changing the password will make it impossible to do a “remote wipe” of the phone. Fortunately, Kerio Connect offers a solution called “remote wipe”. A “remote wipe” will erase all data on the phone completely resetting all accounts, and in the case of most phones, erasing all apps and completely resetting the phone. Remote wipe is much more effective than changing a password because it protects the user’s privacy, and should be used instead. More information regarding the remote wipe feature can be found at ZZ Servers.

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

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

In the past, it was though Linux servers were safe from viruses but recently hackers have been taking advantage of this false sense of security. Some researchers point out that 70% of attacks on Linux honeypots were infected with a 6 year old virus (RST-B)* and used as command and control points for botnets.

ZZ Servers now offers affordable F-Prot anti-virus software for Windows, Linux, Exchange, BSD and Solaris. Protect your servers, desktops and critical infrastructure today. Contact ZZ Servers at 800-796-3574 or email support@zzservers.com to arrange for installation of anti-virus software today.

*RST-B is a backdoor malware runs on Linux/UNIX platforms and infects ELF files in the current and /bin directories. This Linux backdoor and virus compromises system security by allowing remote users to manipulate and access infected machines. If executed as root, it will start processes listening on two network interfaces which provide a remote root shell.

One such example would be Amazon EC2.  In a recent discussion at amazonwebservices.com forum and slashdot.org users were discussing a desire to move to Amazon EC2 and maintain PCI compliance.  While not surprising, at least there was a concrete answer to were Amazon stands with regards to its role in its customer’s compliance.  In an email from Taimur Rashid, an account manager at Amazon Web Services, he states “We do not and will not provide a written agreement attesting compliance and assuming responsibility for cardholder data.”

PCI requires all merchants maintain a written agreement between the merchant and service provider that outlines responsibility for cardholder data.  “Requirement 12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.” Without this simple agreement, you cannot be compliant.

In addition to not allowing a written agreement, Amazon also will not allow on site audits required for Level 1 and now Level 2 merchants.  Cindy S from Amazon Web Services states “If you have a data breach, you automatically need to become level 1 compliant which requires on-site auditing; that is something we cannot extend to our customers.”

Based on the 2 statements above, Amazon EC2/S3 is currently not capable of providing the level of service required for PCI compliance on any level.  If you are a merchant and require PCI compliance, avoid the cloud and find a reputable service provider which specializes in PCI compliance such as GSI, Rackspace or ZZ Servers.

This breech at Batteries.com shows that a merchant does not need to be large like Heartland to be targeted by hackers.

For more information regarding this breech, visit the Batteries.com security and fraud prevention page.

In an update shortly after Webhostingtalk came back online, Dennis Johnson, an iNET Community Coordinator sent out a detailed post explaining all that was then known about the breech with a firm statement that “Absolutely no credit card or PayPal data was exposed.”

Today Inet Interactive, the owners of Webhosting talk relased the news no one wanted to hear.

ANNOUNCEMENT – 1:25pm est 04/07/09

This morning, the hacker who attacked WHT initiated further communication. He provided evidence that credit card information on one of our database servers was, in fact, compromised during that attack.

While it is surprising that a hacker who has done that much damage would contact the victim, especially with this level of damage but there were apparent motives.  What is currently being done is even more shocking.  A post at Web Host Industry Review mentions the hacker may have been motivated after the hack to release the cardholder data to the web because they “had downloaded and looked through the database files, and raised some concerns about the manner in which the credit card information was being stored.’ and that the file allegedly includes stored CVV/CVC information.

Now, I don’t belive mentioning PCI compliance here will be necessary but it is quite obvious that based on the details so far, the data was not stored in a PCI compliant manner.

One of the largest and possibly most hard hitting change is how the the certification process is placing an increasing amount of scrutiny on level 3 and 4 merchants. If you process credit cards and have not received any notification from your merchant bank regarding PCI DSS compliance, you will soon.

I will not attempt to cover all of the details of the new standard but will say if your company handles any cardholder data, it is important to get your infrastructure into compliance with PCI DSS.

PCI DSS 1.2 specifies 12 requirements for compliance, organized into 6 logically related groups, which are called “control objectives.”

The control objectives and their requirements are:

• Build and Maintain a Secure Network
  1. Requirement 1: Install and maintain a firewall configuration to protect cardholder data
  2. Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
• Protect Cardholder Data
  1. Requirement 3: Protect stored cardholder data
  2. Requirement 4: Encrypt transmission of cardholder data across open, public networks
• Maintain a Vulnerability Management Program
  1. Requirement 5: Use and regularly update anti-virus software
  2. Requirement 6: Develop and maintain secure systems and applications
• Implement Strong Access Control Measures
  1. Requirement 7: Restrict access to cardholder data by business need-to-know
  2. Requirement 8: Assign a unique ID to each person with computer access
  3. Requirement 9: Restrict physical access to cardholder data
• Regularly Monitor and Test Networks
  1. Requirement 10: Track and monitor all access to network resources and cardholder data
  2. Requirement 11: Regularly test security systems and processes
• Maintain an Information Security Policy
  1. Requirement 12: Maintain a policy that addresses information security

Each control objective contains additional details on what is required to meet the objective and requires a detailed study to fully understand them and their impact on your existing infrastructure. Smaller companies have the option to use a self-certification questionnaire but even this can be difficult and time consuming.

ZZ Servers has fully qualified security assessors and partnerships with PCI ASV/QSA’s for all levels PCI certification, required security scans and full level 1 PCI audit validation. Contact us today so we can can assist with your adaption of PCI DSS in your environment and ensure your full compliance with these comprehensive regulations. Let us help you prepare and prevent the damaging costs of a data breach.

Peter Zendzian
Managing Partner
ZZ Servers, LLC
www.zzservers.com
800-796-3574

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.

With the advent of multiple core processors and Xen, it is possible to virtualize an entire data center and fit 50 or more independent servers into one Xen server.  There are a number of third-party tools or known as management consoles have been developed to facilitate the common tasks of administering a Xen host, such as configuring, starting, monitoring and stopping of Xen guests. Examples include Enomalism, Xen Tools, Google’s Ganeti, MLN, HyperVM, FluidVM, ConVirt (formerly XenMan) and Red Hat’s Virtual Machine Manager, virt-manager.  Unfortunately, all of them fall short in one area or another in a distributed, secure and automated environment.

I will not get into how each of these management programs work but with few exceptions, they require complex installations into the Domain-0 or privileged domain and require incoming connections to it, or require a local desktop tool.  While this is convenient, it is not completely secure and can potentially lead to vulnerabilities.  If Domain-0 is ever compromised, all other guest domains running in it are vulnerable as well.  As a basic for security, the following should be required:

1. Run the smallest number of necessary services on Domain-0.

2. Use a firewall to restrict the traffic Domain-0.

3. Do not allow users to access Domain-0.

4. Do not allow any incoming connections to Domain-0.

So, How do you manage a Xen server remotely if you cannot directly access Domain-0 you say?  The answer is almost too simple, Domain-0 will use outgoing connections to a remote server.  This not only allows the server to be more secure, it can potentially reduce memory and load requirements of the management domain.

Currently, we have working scripts that can provision and manage guest domains as well as send statistics to a remote server.  These scripts are only just beginning but are currently working in a production environment.  Each are released using GPL licensing in hopes that others will gain some use and provide feedback so we can make managing xen servers easier and more secure.