Managing WebLogic Server and Deployed Applications in DMZ and Other Complicated Network Setups [Article]

Version 10

    By Martin Heinzl


    November 2014




    WebLogic Server is the cornerstone and foundation of the Oracle Fusion Middleware product family. It comes out of the box with a general configuration that should satisfy most applications.  But there are a number of special environments, like DMZ setups, that require additional configuration, communication and security; WebLogic Server setups in a DMZ are exposed to much higher risk and security constraints than other installations.


    This article will focus on possible DMZ setups. Please note that other setups (such as multi-homed hosts and network gateways) might have similar requirements. Normally, the best approach is to never locate WebLogic Server in the DMZ, using instead (reverse) proxies like Apache to filter calls, answer static requests directly and forward dynamic requests to application server instances running in a protected networks segment.  While this is not always possible for several reasons, let us assume for the purposes of this article that these scenarios are in place.



    WebLogic setup options


    First: WebLogic options that support those environments. DMZ setups usually feature different networks installed with different network cards and access points on each host in order to prevent Internet network traffic from accessing the internal network directly and from accessing information stored on backend systems or databases. You should also set up another network for administration in order to decouple application communication and administrative communication; this, too, prevents the administration consoles from being accessed from external networks. Depending on the network layout and security requirements, it is also possible to locate the admin servers in a more secure network segment, which adds additional security. Please see the following diagrams for two possible setups.




    Figure 1


    Figure 1 shows a setup in which the admin server is also located in the DMZ. Administration and cluster communication are separated using different networks from Internet and intranet communication and also from the DB LAN.





    Figure 2

    Figure 2 shows a setup in which the admin server is not located in the DMZ but in the intranet; administration and cluster communication are also separated.

    WebLogic provides four main concepts that can be used to set up such environments: administration channel, network channel, virtual hosts, and connection filters.



    Administration Channel


    The administration channel is a special communication feature that tells WebLogic to open a specific port or a completely separated channel (address and port) for administration communication. Using an administration channel has many advantages with respect to security. The greatest benefit is that the admin console will be reachable only over a non-standard port. If the administration channel is activated, the administration channel will listen on a different port than the user communication—making this port much more difficult to guess. If you also change the context path (e.g., "adminportal" instead of "console"), it will be very hard for users to access the console. In addition, another port, or even another network listener and other port, will allow the admin to set different firewall rules. Another advantage is that the administrative communication is always secured, because SSL is required as soon as an administration channel is activated (HTTPS, IIOPS, or T3S). So: with an admin port you can separate your administrative communication from your application communication.


    # switch to the admin server
    # create a new network channel
    # change to the new network channel
    # very important:  select the protocol "admin"
    # set the administration port
    # define that SSL must be used
    # disable client side certificates as this is hardly used anyway
    # set the listener address for the admin channel
    # change to the first managed server
    # create a new network channel
    # change to the new network channel
    # change also protocol to admin and define the port
    # define SSL settings 
    # et the listener address


    Network Channel


    By default, all communication going into a WebLogic server uses the same communication IP/port. In complex networks or critical environments (such as DMZ, NAT hosts, etc.), this default behavior is definitely not sufficient. WebLogic can listen to different network endpoints, allowing administrators to restrict communications to certain ports/networks; these resources are called "channels." A network channel is a configuration item in WebLogic that defines the communication endpoint of a network connection. This usually includes the protocol used, and the IP address and port that WebLogic has to use for the network listener. It might also include additional properties, such as login timeout, tunneling support, SSL (in case of secure lines), and certificate enforcement. Note that WebLogic supports different channel protocols, including administrative and cluster communication.


    Here is an example of how to create an https channel:


    # change to the server
    # create the https channel
    # change to the channel and configure https
    # configure SSL and certificate usage 


    Virtual Hosts


    Virtual hosting allows you to define a number of host names that servers or clusters respond to. When you use virtual hosting you use DNS to specify one or more host names that map to the IP address of a WebLogic instance or cluster, and you specify which web applications are served by the virtual host. If used in a cluster, load balancing allows better use of the hardware due to distribution, load balancing and fail-over.


    The following example script shows how to setup a virtual host:


    # go to root
    # create a new virtual host instance
    # go to the new virtual host
    # set the possible host names
    String('')], String))
    # define which network channel this virtual should monitor for incoming requests
    # we can also define log settings for this virtual host in order to separate logs
    # of the different servers
    # go to the virtual host in order to define the targets
    # define the target(s) for this virtual host


    Virtual hosts offer another targeting point in WebLogic for web applications. Especially in the DMZ or other security critical systems, this allows finer grained targeting of web applications.  It also enables administrators to co-deploy different web applications but target them to different virtual hosts.


    Connection Filters


    Servers are usually protected by firewalls. The main benefit of firewalls is that they can reject unwanted connections based on rules. Rules can be based on source IP/DNS/port, target DNS/IP/port, protocol, etc. It is highly recommended to use these firewall features—especially for administrative communication—wherever possible. However, many systems have no firewall between the user and the server (intranet), and some resources (e.g., administrative communication, services with sensible or confidential data) must be also protected in those networks.


    If no firewalls are available, WebLogic offers a concept called "connection filter."  Connection filters provide network layer access control and allow the server(s) to block unwanted communication based on different criteria.


    # switch to the domain security configuration mbean (note NOT realm)
    # enable the connection filter
    # set the filter implementation - in this case the default
    # set the rules as array of strings
    ([String(' 7001 allow t3s https'),
    String(' 7001 allow'),
    String(' 7001 deny t3 http')], 



    Application Setup and Deployment


    Setting up WebLogic domains is the foundation of running applications—but an application can consist of different application parts. Simple applications might consist only of a web application or webservice, and these are easy to deploy; there are also more complicated applications available which might not have been designed originally to run inside a DMZ.


    Consider the following types of applications:


    1. A simple application consisting of one webservice or webapp.
    2. An application that consists of a business webapp/webservice and a web application to administer this application. Note: it is possible to deploy them as different deployments—Web Application Archive (WAR ) or Enterprise Archive (EAR) files. Obviously, the admin application must NOT be accessible over the external network (i.e., the Internet) by clients.
    3. An application that consists of an external webapp/webservice and also a web application to administer this application. Due to shared local resources like Enterprise JavaBeans (EJBs), both applications must be bundled into the same EAR. The admin app must NOT be accessible over the external network by clients.
    4. Commonly, an application consists of a web application that can be used by external clients as well as a feeder application (e.g., direct EJB calls, t3/iiop or Message Drive Bean/Java Message Service), which must be used (say, once a day or so) to feed data into the application.


    All of these deployments need different deployment options. The standard deployment will allow access to the application using the default network channel. For the DMZ, this is not a good configuration in most cases due to the wide support of protocols by the default channel. Therefore, WebLogic supports a number of options that can be used here, primary of which is targeting deployments to virtual hosts.  The requirements for all the above examples require a proper setup of network channels and virtual hosts. Complete deployments can be targeted to a virtual host only.


    For scenarios 3 and 4 (above), WebLogic lets you use the sub-deployment features to target only parts of an EAR to virtual hosts, making it possible to target different web parts of enterprise applications to different virtual host targets.


    The magic comes with the combination of network channels and virtual hosts: WebLogic enables a deployer to target a web application (which can also be part of an EAR) not only to a cluster or a managed server, but also to a virtual host only.


    The following example considers a special application that consists (among other components) of different web applications that must be accessible from different networks. A common scenario is that an application consists of the real application component but also has a management/configuration component that must not be accessible from the user network  (e.g., the administration network and public Internet inside the DMZ).




    Figure 3


    To configure this in WebLogic, the following steps must be performed:


    1. Create the network channel VHChannel1
    2. Create virtual host 1 and link it to VHChannel1
    3. Create network channel VHChannel2
    4. Create virtual host 2 and link it to VHChannel2
    5. Deploy the application and target only webapplication_1 to virtualhost_1 and target only webapplication_2 to virtualhost_2. It is important that these two web applications do not have any other target; otherwise, they would be also accessible from other network connections.


    Here is a sample WLST script to setup network channel and virtual hosts:


    # change to the managed-server where you want to create the services
    # create the first channel and allow only the http protocol
    # create the second channel and allow only the http protocol


    After the channels and virtual hosts have been created, we need to target the application components.  Rather than illustrate the relatively simple process of deploying an application, the following scripts show the more unusual process of re-targeting the components of an already deployed application.


    For the following example, assume that the application has already been deployed. In order to re-target components, we have to switch in to the application deployments subtree and create a sub-deployment MBean entry. This entry can then be targeted to the virtual host.


    # switch to the application deployment MBean
    # create the first subdeployment for web application 1
    # switch to the newly created subdeployment
    # target this component to the virtual host 1 only
    set('Targets',jarray.array([ObjectName('com.bea:Name=VirtualHost-1,Type=VirtualHost')], ObjectName))
    # go back to the application structure root and create the second subdeployment
    # switch to this subdeployment
    # target it to the second virtual host only
    set('Targets',jarray.array([ObjectName('com.bea:Name=VirtualHost-2,Type=VirtualHost')], ObjectName))


    Security Considerations


    Of course, the above configurations are only part of the overall picture. It is very important—especially for DMZ-like systems, but also for all others—to secure the system. While security is a very large and complex topic of its own, the main points to consider (apart from the admin channel described above) include securing the file system, using different operating system users for installations and domain configurations to avoid code changes through malware in your application, securing the rest of the operating system, using java.policy security for code level security, and securing your resources like JDBC, JNDI, JMS and others using WebLogic policies. Disabling insecure protocols on all custom network channels is another configuration action that should be performed. Make sure that applications cannot change property files or even application files, and that passwords—especially the WebLogic admin passwords—are changed regularly.


    Monitoring and Other Topics


    Application-specific monitoring is important, but so is monitoring invalid login attempts, not allowed access to files, directories or java code. There are many more items to consider as soon as cluster communication, session synchronization, unicast/multicast restriction or even synchronization between different DMZs (like primary, secondary DMZ in different datacenter) is required for the application.




    When required, WebLogic can be used in risk-rated environments like DMZ. To support these environments, a number of WebLogic features can be used to configure and set up the environment, deploy and target the applications, and implement a high level of security. Fine-grained targeting allows the controlled deployment of applications or applications parts. (Note: these features are of course available to all environments and not only to the DMZ.) This article has discussed some of the important WebLogic concepts and has shown how to setup WebLogic so that a reliable and secure infrastructure setup is possible.





    This article includes excerpts from Advanced WebLogic Server Automation with WLST and JMX (with permission from the publisher).


    About the Author


    Martin Heinzl is a principal consultant with over 15 years experience in middleware, system architecture and enterprise systems. His main focus is on the architecture, integration, operation and security of distributed systems based on J2EE, CORBA and Java. He is currently a member of the team of experts behind the global middleware application hosting platform of a global bank.  A member of the Oracle customer advisory board for WebLogic in EMEA. He is also the author of Advanced WebLogic Server Automation with WLST and JMX (Rampant TechPress, 2014).



    This article represents the expertise, findings, and opinion of the author.  It has been published by Oracle in this space as part of a larger effort to encourage the exchange of such information within this Community, and to promote evaluation and commentary by peers. This article has not been reviewed by the relevant Oracle product team for compliance with Oracle's standards and practices, and its publication should not be interpreted as an endorsement by Oracle of the statements expressed therein.