Web servers and application servers have a lot in common, but they do perform different jobs. What specific defenses does each require?
Requires Free Membership to View
SearchSecurity.com members gain immediate and unlimited access to breaking industry news, virus alerts, new hacker threats, highly focused security newsletters, and more -- all at no cost. Join me on SearchSecurity.com today!
Michael S. Mimoso, Editorial Director
Web servers and application servers do have a lot in common, and, in fact, their roles are becoming less distinct. XML Web services, for example, allow a Web server to process an XML payload and respond in much the same way as application servers have in the past. In turn, application servers generally include a Web server component; you could therefore consider a Web server as almost a subset of an application server.
For these reasons, a lot of the pre-deployment processes for both types of servers will be the same. Hardening the server OS, applying patches, disabling or removing unnecessary services, verifying usernames and logins, and enabling detailed logging are standard practices for both. Hardening a Web server is generally easier as it is, or should be, configured as a single function system.
An application server model tends to be more complex, since it hosts a component API to expose business logic and business processes used by third-party applications through any number of protocols and ports. The information traveling back and forth between an application server and its client is not restricted to simple display markup. Instead, the information is program logic in the form of data and method calls. This logic is reusable between applications; an ecommerce site and a cash register could both call the same service as a customer checks out, for example.
Although a Web server model, specifically its delegation, is simple in comparison -- when a request comes in, it is simply passed to the program best able to handle it -- code running on either type of server needs to be reviewed and vulnerability assessments undertaken. When either server is deployed, penetration tests should be completed in order to evaluate whether your server or applications have any potential vulnerabilities resulting from poor or improper system configuration, hardware or software flaws, or weaknesses in the perimeter defenses protecting them.
This brings me to the main difference in defenses for the two types of server: the placement of your application server. It is normal practice to place the Web server in the DMZ and the application server inside the inner firewall. This is so all incoming Internet HTTP traffic can be first processed and terminated by the Web server in the DMZ zone. Communication ports and traffic with the application server can then be tightly controlled, preferably with all communication being encrypted and authenticated.
If you were to place the application server in the same DMZ as the Web server, far more software and services have to be installed on the machines, with probably more ports on the inner firewall needing to be opened. This largely undermines the value of the DMZ. The fact that your application server probably interacts with your production and internal networks also makes it more prone to internal attacks. You therefore need to ensure both physical and logical protection is in place. Your administrators will need a good understanding of what the application server services do and how they do it to ensure the right controls are in place and configured appropriately.
For these reasons, a lot of the pre-deployment processes for both types of servers will be the same. Hardening the server OS, applying patches, disabling or removing unnecessary services, verifying usernames and logins, and enabling detailed logging are standard practices for both. Hardening a Web server is generally easier as it is, or should be, configured as a single function system.
An application server model tends to be more complex, since it hosts a component API to expose business logic and business processes used by third-party applications through any number of protocols and ports. The information traveling back and forth between an application server and its client is not restricted to simple display markup. Instead, the information is program logic in the form of data and method calls. This logic is reusable between applications; an ecommerce site and a cash register could both call the same service as a customer checks out, for example.
Although a Web server model, specifically its delegation, is simple in comparison -- when a request comes in, it is simply passed to the program best able to handle it -- code running on either type of server needs to be reviewed and vulnerability assessments undertaken. When either server is deployed, penetration tests should be completed in order to evaluate whether your server or applications have any potential vulnerabilities resulting from poor or improper system configuration, hardware or software flaws, or weaknesses in the perimeter defenses protecting them.
This brings me to the main difference in defenses for the two types of server: the placement of your application server. It is normal practice to place the Web server in the DMZ and the application server inside the inner firewall. This is so all incoming Internet HTTP traffic can be first processed and terminated by the Web server in the DMZ zone. Communication ports and traffic with the application server can then be tightly controlled, preferably with all communication being encrypted and authenticated.
If you were to place the application server in the same DMZ as the Web server, far more software and services have to be installed on the machines, with probably more ports on the inner firewall needing to be opened. This largely undermines the value of the DMZ. The fact that your application server probably interacts with your production and internal networks also makes it more prone to internal attacks. You therefore need to ensure both physical and logical protection is in place. Your administrators will need a good understanding of what the application server services do and how they do it to ensure the right controls are in place and configured appropriately.
This was first published in February 2009