CS – 558 paper report
Name : George Christou
Scalability , Fidelity and Containment in the Potemkin Virtual
Honeyfarm
Internet malware is a pressing concern due to the rapid evolution of large scale worms ,
viruses and botnets.
Large scale host exploitation is responsible for :
1) *SPAM
2) *Denial of service
3) *Phishing
4) *Piracy
5) *Identity theft
In addition commodity software exploits are used in order to create botnets that are used
leased and sold for illegal purposes
Tactical Counter measures are like spam filters and DoS defences can be employed but in
order to combat the underlying infestation requires the understanding of the means and
methods used to compromise and control the botnet.
The principal tools for that tasks are the honeypots , which are network connected systems
that are unprotected and carefully monitored in order to detect and analyze intrusions and
provide data that are used to generate antivirus signatures , disinfection procedures . Also
they can give information that can be used for criminal prosecution. A large number of
honeypots is called a honeyfarm.
Honeypot systems designs oscillate between scalability and fidelity.
Low interaction : Can monitor a large fraction of a subnet but they have low fidelity and
don’t execute any code.
High interaction : Emulate an entire system but require more resources and can’t scale well.
Another challenge of honeypot design is the containment policy i.e. prevent the
compromised honeypots from attacking third party systems.
The purpose of Potemkin Honeyfarm architecture is Large scale and High fidelity.
This is accomplished by dynamically binding physical resources only for the short periods of
time necessary to emulate the execution behavior. Thus exploiting net idleness and physical
memory coherence.
 Based on a specialized network gateway
 Xen virtual machine monitor
At network layer , flows are dispatched to a collection of honeyfarm servers then new VMs
are dynamically instatiated for each destination IPs
Fast boot is achieved by flash cloning in which wee clone an existing running vm instance
and delta virtualization i.e. copy a memory page only if its changed otherwise it’s the same
for all instances.
Large – scale honeyfarms require a containment policy.
After compromisation a honeypot may attempt to attack a third party . A weak
containment may accelerate a network worm. On the other hand strict policies may blind
the honeyfarm e.g. botnets need to phone home.
Potemkin policy:
When outbound traffic cannot be safely forwarded to the internet the gateway reflects it
back to the honeyfarm , which will adopt the destination . Avoidance of resource starvation
wrings for careful reflection.
The main component is the gateway router :
 Directs inbound traffic to individual honeyfarm servers
 Manages resources in the long – term
 Responsible for outbound traffic containment policy
 Interface for detection and analysis
In order to acquire inbound traffic , the honeyfarm may act as last-hop via BGP
advertisation. The main drawback of this approach is that it renders the location visible to
anyone with trace route
Another solution is to configure external routers to tunnel packets destined for a particular
address range back to the gateway.
Packets destined to inactive IPAs are sent to non overloaded servers either randomly , or
with using infection probability or even better via a type map i.e. providing the illusion that
the IP hosts a particular software configuration . The latter is ideal for pre-scanned attacks.
Limitations and challenges :
Honeypot detection
 Attackers may attempt to explicitly detect that they are running in a honeypot
environment and evade detection.
 Attackers can detect virtualized honeypots
Denial of service:
 Blanketing the honeyfarms address space with seemingly distinct attacks may cause
physical resource starvation.
 Modifying large number of pages can violate copy on write.