The next step after installing the software consists of creating the WebLogic domain. Before we do, as stated in the pre-installation posts, following OA&M best practices, application and user data must be separate from software products. The WebLogic domain could easily be created in the /var hierarchy on Linux or within the home or user directory of the account used for installing WebLogic Server. I typically create it in the home or user directory, and will assume you do the same.
Obviously, to create the domain, we use the Configuration Wizard. As part of the process, there are a few specific configurations or pages of the wizard where I suggest being paranoiac:
- When prompted for the administrator user name and password, use an original user name, not
weblogicorsystem. As for the password, the rules are simple: the wizard expects a password with at least 8 alphanumeric characters, at least one number or special character. - On the Domain Mode Configuration page, select Production Mode to prevent code from being automatically deployed when copied to specific directories.
- On the Select Optional Configuration page, I recommend editing the Administration Server. More specifically, use an original port number for the listen port, not
7001. - I personally prefer to configure the Managed Servers using the WebLogic administration console. You can optionally configure them using the Configuration Wizard. Here again, use original listen port numbers.
Several techniques and tools can be used to determine what ports a server listens to. Regardless, why make things easy?
After the domain is created, the next step is to protect it. Again, I suggest locking down the domain directory. Assuming the domain was created in /home/aUser/user_projects, specifically:
- I ensure that the subdirectory
user_projectsis owned by the dedicated user account and group created as part of the pre-installation of the WebLogic Server. Again, if making a change, it is critical to ensure the update is recursive (i.e. affects the full file system hierarchy, all subdirectories and files this directory includes). - I also remove all permissions for the group and world (or everyone in Windows environments). Only the dedicated user account should have access to the entire subdirectory
user_projectsand all subdirectories and files it includes.
One of the disadvantages of globally or blindly changing ownership and permissions on all files and folders of a WebLogic domain is that it prevents developers from accessing the server logs. Generally speaking, information security introduces restrictions. It does not mean that the results must become impractical to all. I am a huge believer that developers should have access to the server logs. This can be easily remedied by opening up the appropriate directories, creating symbolic links to those directories, replicating the log files (in real-time mode), and many other techniques.
In closing…
Over the past few weeks, I have covered the basics, from pre-installation, installation all the way to configuration. In the next series of post, I will cover beyond basics. As an example, I will talk about how easy it is to gain access to the WebLogic super user given some basic access when an installation is left unprotected.
