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.
Related Q&A from Michael Cobb
Expert Michael Cobb explains how an HTTP referer header affects user privacy and outlines changes that can be made to ensure sensitive data is not ...continue reading
Expert Michael Cobb explains the difference between the REESSE3+ and IDEA block ciphers and explores when each is applicable in an enterprise setting.continue reading
While cookies are critical to delivering personalized Web content, they are a privacy concern. Learn how adding Bloom filters to cookies can help ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.