Web3 Armored Stack Security

The Web3 Enterprise Cloud

AS Logo
Our Armored Stack Technologies team specializes in the design and deployment of computer systems, including web applications, WANs, security systems, and global ecommerce systems for enterprise clients in the manufacturing, software development, healthcare, aerospace, and global financial services, amongst others.
Bringing dozens of years of combined security experience, we have invented the most secure LAMP stack replacement commercially available, the implications of which are the following:


  • Web3 Maximum-Armor Secure Hosting:  The most secure commercial hosting facilities in North America
    (Austin, TX / Princeton, NJ / Toronto, Canada)
  • Web3 ArmoredStack Appliance: The most secure server appliance commercially available on the market
  • Web3 Securecommerce: The most secure ecommerce server commercially available on the market
  • WordPressArmor:  The most secure WordPress architecture available in the North America
  • Custom ArmoredStack Integration
Not being satisfied with general compliance or security best practices, which are often set at the lowest bar, our Armored Stack Technologies team began a six year process of development efforts on our patent pending ArmoredStack technology.  The Armored Stack Technologies team analyzed hundreds of thousands of attacks and survived many millions more over multiple years with not a single compromise.  In fact, the patent-pending ArmoredStack technology is the only server security technology that we are aware of (to date) that has never been compromised.  ArmoredStack is also the basis for WordPressArmor which will go live in Q3 and our Web3securecommerce product.


Why the Armored Stack?

Armored Stack Jails

Armored Stack Jails


Armored Stack Technologies introduces the Armored StackTM – the optimal way to protect dynamic web applications from hostile adversaries.

The Armored Stack Technologies team analyzed hundreds of thousands of attacks and survived many millions more over multiple years and found that the vast majority of exploits could be defended against simply by modifying how the web server, operating system, and database worked in concert with one another. Without modifying code, the Armored StackTM can dramatically improve the security posture and even in many cases, completely secure otherwise vulnerable application code.

The Armored Stack Technologies research team spent more than six years architecting earlier versions of the Armored StackTM framework.

In the process of research and development, Armored Stack Technologies successfully defended dozens of applications from a constant barrage of both completely automated and highly customized 0-day attacks launched from thousands of determined adversaries around the world without ever suffering a single compromise. More amazingly, this was possible even though the underlying websites that were being attacked were themselves known to be out of date and vulnerable to exploitation.

Over a year of additional work was put into the Armored StackTM design, to significantly improve the security and usability of the environment. Out of this process came an extremely armored and highly flexible framework for hosting web applications and dynamic content.

Operating Systems

The patent pending Armored StackTM utilizes the UNIX derivative, FreeBSD, which offers mature patch management, chrooted jails*, and an advanced networking stack. FreeBSD is often the operating system of choice for companies who need stability and performance in their devices, such as NetApp, Juniper Networks, EMC and others. FreeBSD is even the basis for MacOS. Armored Stack Technologies prefers FreeBSD because it allows an extremely fine granular control over the network and allows the Armored StackTM to create advanced host security/integrity. The Armored StackTM can also run Linux binaries as well, for customers who are married to the Linux OS, or require some minutia regarding slightly different command syntax.

The Armored StackTM heavily utilizes host based firewall for the parent operating system, virtual switching, and VLANs to create an N-Tier stack* without requiring more than one physical host. Alternatively hosts can be dedicated to single tasks where compliance or higher performance is required. This isolates and protects individual websites, administrative traffic, and database traffic from packet sniffing or gaining access to restricted administrative ports while still enabling full site functionality.
The Armored StackTM uses an extremely stripped down kernel, which makes it fast and secure. No unnecessary services are running, no games, no printer drivers or any of the usual superfluous services often found on production servers, leaving less attack surface area exposed, increasing processor and RAM availability, and making it easier to maintain.


The Armored Stack TM takes advantage of the concept of chrooted jails which are currently exclusive to the FreeBSD operating system. A jail under FreeBSD, unlike a chroot under Linux, actually provides a high level of security and is essentially a lightweight virtual machine. The Armored Stack TM operates within approximately 20MB of memory (which on an average computer with 8GB of memory is miniscule as compared to the memory footprint of a typical virtual machine). This lightweight functionality allows the Armored Stack TM to run many of these jails on a single host.

The Armored Stack TM utilizes a series of jails to protect and isolate the application from itself.
In the most common configuration there is a series of three segregated jails: an admin (administrative) jail, a public jail and a database jail. The administrative jail is used by website administrators. The public jail is assessable by users. The database jail is where the database resides. Websites sit on their own VLAN to create an N-Tier architecture on a single device.

Each jail is stripped down to its bare minimum of necessary files and binaries, to reduce attack surface area and maintenance. Further, the kernel and system binaries are mounted into each jail from a single source in a read-only configuration, reducing the risk of rootkits within the jails and improving maintenance time. Public jails mount files from the administrative jail in a read-only configuration, but are still allowed to log and contact the database, giving them the ability to stay dynamic, without jeopardizing the source code integrity due to an application compromise. Administrative jails can be in a one-to-one or one-to-many configuration, controlling the content and source code of multiple public jails at once.
Public jails are by default denied egress traffic, to reduce the likelihood of automated data exfiltration, the ability for malicious code to contact command and control networks, and to eliminate remote file include attacks as a class of exploit. This feature can be disabled, enabled or partially enabled to allow outbound access only to pre-determined destination IP addresses and ports.

Because the Armored Stack TM cross-mounts administrative jails into public jails, it can enable additional features to be built into the site. For instance, database controls, user-aware administrative protections, and administrative only write access can all be controlled based on source IP or VPN access.

As an example, a hacker who was able to compromise poorly written application code may be able to submit a credit card to the database, or overwrite existing cards on file, but they would not be able to read any cards. However, in that example the administrators could still have full access to read credit card information from the administrative jail – all without any modifications to the code.

In typical hosting environments the fact that the web user owns the source code is both critical to administrative site functionality and it is also a huge weakness if there are any holes in the application code. However, within the Armored StackTM, as the information is cross mounted, the code is automatically associated with a UID that does not exist within the public jail, allowing the code to have no owner, and therefore making it invulnerable to being overwritten by the web user. However, administratively, the site stays the same, and is still accessible and the source can still be modified at will – again, with no modifications to the code.


Although the development process itself is often overlooked, Armored Stack Technologies highly encourages mature development practices, thereby reducing bugs and improving both stability and website utilization. Due to the nature of lightweight jails it is possible to run many of these jails on a single host. Assuming physical isolation is not mandatory due to compliance requirements, Armored Stack Technologies’ preferred configuration is a series of three jails (one administrative, one public and one database) for production, and additional jails as needed for staging and development. An additional jail is often recommended for a CVS/SVN repository for when multiple developers are being used.
Development can often be a slipshod process and often introduces buggy/unstable code. Therefore testing in production is highly discouraged. That is why a mirror of the Armored StackTM is ideal for mature development organizations. Once the code has been stabilized in the development environment, it can be pushed into staging to ensure that all dependencies and stability requirements are thoroughly tested before the last stage – pushing to production. The lightweight nature of jails provides this level of maturity without additional hardware in all but the most extreme cases.

Web Server

Apache has been a staple of web masters since 1995. Unfortunately the default configuration of Apache has begun to show its cracks as the web advances far beyond the original design choices. The Armored Stack TM provides a highly customized default image of Apache, to improve performance, stability and security features. First, Armored Stack Technologies stripped Apache of all unnecessary modules, and created a core configuration that was designed to be flexible but unnecessary to change, instead encouraging webmasters to utilize extensible virtual hosts that are mirrored into individual public jails.

The Armored Stack TM fills the gap in Apache’s default configuration by automatically suggesting the best options to use. The Armored Stack TM focuses on everything from denial of service, and proper logging, to optional HTTP headers which can help to thwart entire classes of attacks. The Armored Stack Technologies team is even working on additional customizations to Apache itself, which will enable even stricter controls to protect web applications from denial of service even in the event of a successful compromise of the website’s code.

Logging and Compliance

Armored Stack Technologies is an unyielding believer in the virtues of logging and verifying forensically-secured logs. Armored Stack TM is designed so that all accesses to the public jails are logged. However, public jails are by default marked as read-only, meaning that no logs can be written to the jail. Instead they are sent through a write-only socket which is syslogged either to the parent operating system in the case of OSSEC or other host-admin logs, or to the administrative jail, in the case of web server logs.

Logs can be utilized by an attacker in a number of dangerous ways. They can often contain useful information, like referring URLs, source IP addresses of other users, cookies which can be used for session riding, and so on. They can also include search strings, credit card numbers, usernames, passwords and other highly sensitive information. Further, logs can be leveraged in local file include attacks. Lastly, attackers often modify logs to cover their tracks so that they aren’t identified in the post-compromise forensics process. Therefore the Armored StackTM simply does not allow the attacker to see or modify any logs prior to compromise by logging them outside of the public jail.

Because these logs can be monitored outside of the jail, and because the parent can monitor all aspects of the jail, compliance becomes an extremely simple process. The parent operating system can analyze the logs and the site configuration looking for anomalies, and take any action deemed necessary in real time, or when correlated together via SEIM tools. Verifying configuration and alerting when it is modified can dramatically speed up the process of and improve the chances of staying compliant.

Scroll to Top