- Physical Security
- Inherent Security of MARS Appliances
- Security Management Network
- MARS Communications Requirements
- Network Security Recommendations
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Inherent Security of MARS Appliances
Management access to all MARS appliances is through Secure Socket Layer (SSL)–encrypted web access (HTTPS) and Secure Shell (SSH). These protocols, using TCP/443 and TCP/22, respectively, are inherently secure because they use encryption, authentication, and authorization. Unencrypted protocols that serve similar functions, such as HTTP and Telnet, are both disabled on the MARS appliance and cannot be enabled.
MARS appliances are hardened Linux servers that run a variety of services, including Oracle, Apache HTTP Server, and more. With each software update, the various services and drivers on MARS are updated with new versions or patches to mitigate against any newly discovered vulnerabilities. Additionally, unnecessary or unused services are disabled to prevent them from being potential weaknesses in the security of the appliances.
This hardening of the operating system provides a good starting level of security. However, it is not enough. You need to take into consideration the sensitivity of the information contained on the MARS appliances when considering how secure the appliances should be. You should have a well-defined written plan for preventing MARS from being used as an attack vector on your network. This includes placing the appliance in a part of your network that is protected from the rest of the network by a firewall and an IDS.
Without protecting MARS with a firewall and IDS or intrusion prevention system (IPS), a hacker can try to find vulnerabilities, either in the management protocols or in other protocols that are used to monitor security or network devices. The additional protections provided by the firewall or IDS/IPS allow you to limit the exposure to attacks while also creating an audit trail of attempted attacks.
As an example, consider SSH, the command-line method of administering MARS remotely. In the past, a number of vulnerabilities have appeared in the OpenSSH application, which provides this service for MARS. No known vulnerabilities exist in the SSH service that MARS uses at this time. However, at some time in the future, a new vulnerability might be found. For this reason, it makes sense to restrict the capability of computers to establish an SSH connection to MARS unless they are connected to a specific network or set of networks at your location. A stateful inspection firewall is the ideal device for providing these limits. A network IDS or IPS that is regularly updated with new signatures can detect when someone is attempting to use a known vulnerability to compromise the MARS appliance.
Another example, also using SSH, involves a brute-force password attack against the MARS appliance. In this attack, an attacker repeatedly uses a dictionary of passwords, using a script, to attempt to crack the password that administers the MARS appliance. MARS is especially vulnerable to this type of attack because the administrator's username is a well-known value—pnadmin—and this is the only username that can use SSH. This example is mitigated using the same methods as the first example. First, placing MARS on a protected network, with a stateful inspection firewall separating it from the rest of your network, allows you to limit connection attempts to a limited number of devices or networks on your company's network. Additionally, a network IDS or IPS can detect multiple login attempts, whether by SSH or web-based. The detection by an IDS can notify the appropriate personnel, or an IPS can prevent further attempts.