Advanced Security enhancement in WebSphere application Server V7, V8, and V8.5

Brief introduction

The security of IBM WebSphere application Server is improved in each release. In addition to adding new features to the new version, we are constantly enhancing the default security for our products. By improving the default settings, we continually increase the degree to which the key principle of default security is met. The previous version of this article focuses on the required step steps for WebSphere application Server V6 and that version. In subsequent WebSphere application Server releases, the number of step steps has been significantly reduced, and more importantly, most of the steps reserved have become less critical. The revision of that article focuses on WebSphere application Server V6.1 and updates for V7.0. Because there are significant differences between V6.1 and subsequent versions, these differences complicate the discussion, and all of us feel that the details of removing V6.1 from the content are helpful to newer users. Now, WebSphere application Server 8.0 and version 8.5 have reduced the necessary stepping steps, and some of the additional new features will change (or support additional) demand enhancements. Therefore, it is time to update this article with the latest information.

This article begins with a brief discussion of why security is so important and the difficulty of strengthening the system, and then discusses how to strengthen the WebSphere application Server environment to address a variety of security vulnerabilities. Because this article mainly discusses the enhancement, therefore some information is general, did not carry on the detailed analysis. As much as possible, we provide appropriate resources for the relevant details so that you can further study the related subtopics.

Although the information in this article is based on the IBM WebSphere application Server V8.5 and V8.0, most of the issues discussed also apply to V7.0, but in some cases WebSphere application Server V8.0 the default The security settings have been changed. For a particular version of the problem, we will specifically point out these places. Over time, we made product changes to the main version of WebSphere Application Server, and if you are using a WebSphere application server V6 or lower version, be sure to refer to the archived article if you are using a W Ebsphere application Server V6.1, please refer to previous articles.

Configuration file Notes

If you are familiar with the WebSphere application Server before V8.5, you will know that you must create one or more profiles. The profile may be a application Server (or Base) configuration file, a deployment Manager profile, and so on. In the remainder of this article, these configuration files will be referred to as "full" profiles. This distinction is made to compare these profiles with the new configuration file (Liberty configuration file) in V8.5. This article also provides some recommendations that are specific to the new Liberty configuration file.

Why do I need security?

Thankfully, most readers are aware that security is a key aspect of an enterprise system. However, in order to introduce some common ways to consider security, we will still briefly introduce security.

The basic purpose of security is "to prevent malicious people from entering your system." More precisely, security is a process that uses a variety of techniques to prevent unauthorized users, often called intruders, from unauthorized access to content.

There are many types of intruders: foreign espionage agencies, competitors, hackers, and even your own employees. Each intruder has different motivations, different skills and knowledge, different access points, and different levels of requirements. For example:

Employees may have a motive to attack the company. Employees have very high levels of internal access and system knowledge, but their resources and hacking skills may be limited.

External hackers may be experts in security attacks, but they may not be motivated to attack you.

Foreign espionage agencies may be interested in attacking you (depending on your business) and have extremely rich resources.

Intruders can invade your system for two reasons: to get information they shouldn't have, or to change the normal behavior of the system in some way. In the latter case, by changing the behavior of the system, they can try to perform a transaction that is advantageous to them, or simply to cause the system to crash in some interesting way, causing damage to your organization.

The point is that there are many different types of intruders, many different motivations for intrusions, and many different types of attacks (which we will see later). You must be aware of these when planning for security.

Focus on both internal and external threats

Security measures should not be viewed only as a barrier to "outsiders". This is a simplistic point of view. At present, many organizations focus their security measures exclusively on people outside the organization, who mistakenly believe that only foreign talent is dangerous. This is not actually the case. For large companies, there are often thousands of people who have access to the internal network (many of whom are not employees). These people are likely to become intruders, and because they are internally, it is more convenient for them to access the network. You can often access your company's network by simply plugging your laptop into a cable. Some studies have shown that nearly half of the intrusions are caused by employees within the organization or by contractors (or people involved in them).

Even if you believe that everyone in the network is trustworthy, can you believe that they will never make a mistake? Given the rampant use of e-mail-borne viruses, and the fact that JavaScript-based attacks and other programs can easily get inside the corporate network by plugging in the computer's USB drive and CD, it is foolhardy to assume that the entire internal network is trustworthy--and not to do so.

Security measures should try to protect the system from being attacked by all potential intruders, which is why this article is so long. Security is not just a firewall that protects the system from "external" attacks on network boundaries. It is a set of complex operations and processes designed to enhance system security as much as possible.

Limitations and the realities of the situation

It is important to recognize that there is no fully secure system. Your goal is to protect the system as much as possible under the constraints of your business. When considering security, ideally you should:

Analyze all aspects of the attack.

Consider the risk of each attack.

Determine the likelihood of an attack being successful and causing security to be compromised.

Evaluate the cost of preventing each attack.

When estimating the damage caused by security breaches, don't forget that security breaches can cause system users to lose confidence in the system. As a result, the "cost of security breach" may include very high overhead costs (e.g., loss of investor trust).

Some hacking systems are just for fun, so if you create an environment with a reasonable level of security, intruders will turn to easier targets.

Once you have completed the steps listed above, you can make an appropriate trade-off between risk and cost. Essentially, the goal is to allow intruders to pay more for intrusion systems than they can gain, while ensuring that the business can withstand the costs of running security systems (see sidebar).

In the final analysis, what security level is required is a business decision, not a technical decision. However, as technicians, we must help all parties understand the value and importance of security. Therefore, in addition to protecting internal applications from attacks, the cost of most of the security enhancement steps recommended in this article is fairly low. Most organizations should have the ability to implement them. This article does not cover the more complex and expensive security methods-strong authentication, auditing, and intrusion detection-beyond the capabilities of the WebSphere application Server product.

Security is a big topic, and it is not possible to completely cover all aspects of security in this article. This article does not intend to introduce security, or is not a tutorial on how to protect your system. Instead, it provides an overview or checklist of core technical issues to consider when addressing the security of WebSphere application Server. The information in this article should be combined with larger work to create a secure enterprise.

Social engineering

Since this is a technical article, the focus will be on technical solutions for the protection system, specifically, the WebSphere Application Server section, which focuses on security challenges. However, you should be aware that it is often simpler to use social engineering techniques to harm a system. That is, by tricking a worker in an organization, an attacker can gain access to the system and information in a way that is not local. One conclusion that can be drawn from the social engineering attack technology is that by using social engineering, an attacker could be from within your network. This underscores the previous view that it is not enough to defend against attackers from outside the network alone. Therefore, the discussion here focuses on multiple levels of security. Each level guards against different types of attacks and provides a more effective barrier to attackers.

General system Point of view: detail issues

Before we look at specific recommendations in detail, let's take a moment to outline the underlying technologies for creating a security system. The basic idea is to look at each system boundary or share point and check which participants have access to those boundaries or shared components. In other words, assuming that these boundaries exist (assuming that the subsystem is more trustworthy), how do intruders break through these boundaries? Or, suppose that something is shared, can an intruder share something with an improper means?

Most boundaries are obvious: network connections, process and process communications, file systems, operating system interfaces, and so on, but some boundaries are not easily identifiable. For example, if an application uses J2C resources from a WebSphere application Server, you must consider the possibility of another application trying to access those resources. This is because system boundaries exist between the first application and the WebSphere application server, and between the second application and the WebSphere application server. It is possible that both applications can access this resource (they actually do). This may be unreasonable to share.

In a WebSphere application server environment, the operating system has limited value for the protection of APIs because they are based on process identifiers, which is a very coarse-grained concept because the application server accepts requests from thousands of of users at the same time.

Many well-known techniques can be applied to prevent various forms of attack. For lower-level network-based attacks, encryption and network filtering can be applied. This will deny intruders the right to view or access content they should not see. You can also rely on the mechanism provided by the operating system to protect operating system resources from misuse. For example, you do not want normal user-level code to be able to access the system bus and read internal traffic directly. You can also use most modern operating systems to reliably protect the system APIs (see sidebar). At a higher level, authentication and authorization should be rigorously applied. Each API, each method, and each resource may require some form of authorization. In other words, access to these things must be strictly limited to the requirements. Of course, without reliable authentication, authorization loses its value. What the authentication does is to reliably determine the identity of the caller. The word "reliable" is added here because it is not valuable to be authenticated easily by forgery.

If proper authentication and authorization are not possible, only ingenious designs and procedures can be used to prevent potential problems. This is how we protect j2c resources. Because WebSphere application Server does not provide an authorization mechanism to access J2C resources, we have to apply other technologies to limit the ability of applications to access j2c resources in an improper manner (based on configuration).

As you can imagine, it is very difficult to check all the system boundaries and share components. In addition, the protection system actually needs to take full account of its complexity. The most difficult thing about security might be to create a security system that relies on abstraction. In other words, one of the principles of good abstraction is to hide the concerns of higher-level components. This is a very good practice that people need. Unfortunately, the invaders were not friendly. They don't care about abstractions or good design. Their goal is to do everything possible to hack into the system, so they will look for vulnerabilities in your design. Therefore, in order to verify the security of the system, security must be considered at each level of abstraction: from the highest architectural layer to the lowest detailed implementation layer. Although there are many application scanning tools that can help check code (such as IBM Rational AppScan), even with scanning tools, you still need to manually check all code and design decisions to prevent applications from being attacked. All content needs to be rigorously checked.

The smallest error can also damage the integrity of the entire system. The best example of this is the use of buffer overflow technology to control a system based on C + +. In essence, an intruder passes a string that is greater than the existing buffer. Therefore, the extra information overwrites the part of the running program, causing the runtime to execute instructions that should not have been executed. Notice that in this way the intruder can let the program do almost anything. To identify this attack, as a security architect, you must have an in-depth understanding of how the C + + runtime manages memory and executes the program that is running. Even if you understand the existence of a buffer overflow problem, you must still check each line of code to discover this vulnerability. Currently, we understand this attack, but it can still be successful because individual programmers make very small error decisions that compromise the security of the entire system. Fortunately, this attack does not work in Java, but other minor bugs can still cause the system to be compromised.

It's hard to take a serious look at security.

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/extra/