By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.
Dig Deeper on Web Server Threats and Countermeasures
Related Q&A from Michael Cobb
Open source NoSQL MongoDB database faced 30,000 insecure instances. Expert Michael Cobb explains the misconfiguration that led to this, and how to ...continue reading
A new Veracode report offers details on common mobile application security risks. Expert Michael Cobb explains these flaws, and what developers can ...continue reading
Juniper firewall products were found to have two backdoor vulnerabilities. Expert Michael Cobb explains how a cryptographic algorithm and hardcoded ...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.