Is your WebLogic console available to anyone on the Internet? A quick Google search might be eye-opening:
If you try this search you’ll see approximately two pages of exposed consoles. A colleague I showed this to pondered: “How many still use weblogic/weblogic?” Good question. Scary, too.
Simon Vans-Colina wrote “Competitive Intelligence Gathering with Google” wherein he discusses two ways of gleaning which server a site is using. He demonstrated how to search for stacktraces which give very obvious clues as well as the console searching technique shown above.
It’s also important to realize that the results from the search above only found the unfortunate sites whose links were published in some way for Google to find them. Regardless of the search results, someone could go directly to your site and slap a “/console” on the end of your domain to see what happens.
These problems aren’t new and they’re not limited to WebLogic, of course. Any server software that exposes a web-based administration application is fair game. Blogging apps, CMS’s, you name it — they all expose an admin app. If you’re lucky, your application will provide some way to restrict access to the administrative functionality. This post is about securing WebLogic’s console.
You have two choices if you don’t want your server caught with its pants down:
- Disable the console application
- Use the administration port
Disabling the console application is a bit extreme. If you do that you can only administer your server with weblogic.Admin, WLST, or a custom JMX client. That all seems a bit too inconvenient so the second option is the way to go and will be described below.
Enabling the administration port prevents the masses from accessing your console while giving you access to the same. It’s the best of both worlds. With the administration port enabled:
- The console is only accessible over a non-standard port (which should not be available from outside your firewall)
- You have to use SSL
- You get a dedicated administration listen thread
- Administrative requests over any port other than the admin port are rejected
So, by using the admin port you protect your console and get several other nice side-effects. The admin port will not be on port 80 or 443 and will thus not be available outside your firewall. Technically, you could open the admin port on the firewall but then you’re back in the same boat. Also, anybody who tries to do an administrative request over any other port will find their request rejected.
Another feature is that your interaction with the console has to be over SSL which protects your data as it transits the wire. And really, who doesn’t love SSL? (Aside: When is the last time you heard of data compromise via an SSL attack? Pretty rare, indeed.)
Finally, using the admin port gets you a dedicated listen thread. What’s the big deal? Let’s say that you have 40 listen threads and the admin port is not enabled. A bug or poor resource utilization causes all 40 threads to be blocked or otherwise unavailable. If you want to get into the console and see what’s going on or fix the problem you’d be out of luck because there’s no thread available to do your work. That’s not good.
The outlook is sunnier when you’ve enabled the admin port, though. Now you have 40 normal listen threads and a dedicated admin thread. If all 40 normal threads are hung you still have a responsive thread for doing your investigation. Of course, you can also look at the separate thread benefit from the opposite perspective: An admin poking around on the console won’t consume a thread intended for satisfying user requests.
Now you’re clamoring for the admin port, right? Let’s set it up.
A prerequisite is that you need to set up SSL normally which is well-documented by BEA. After that, access the console and do the following:
- Click on the first node under Domain Structure (it’s your domain name)
- Click Lock & Edit
- Select the Enable Administration port checkbox
- Specify the administration port
- Click Save
- Click Activate Changes
No restart is required and you’re automatically switched to using the admin port. By the way, the same page allows you to disable the console or change its context path.
Now that you’re using the admin port, if you attempt to access the console over the standard listen ports you’ll be greeted with
Console/Management requests can only be made through an administration channel
Unfortunately, this is also a fingerprint of WebLogic but at least your console is hidden behind your firewall. You can mitigate this fingerprinting to a degree by changing the context path for the console. For example, I changed mine to SecurityThroughObscurity and I would thus access the console via
assuming 7777 is my admin port. Now, going to http://localhost/console will provide the inquisitive user with a nice 404–Not Found page.
The choice of “SecurityThroughObscurity” was obviously tongue-in-cheek but it does highlight the fact that changing the context path is not securing anything but it is making it harder to find. Every little bit helps, I guess.
There are some things of which you need to be aware if you’re running a cluster. See Administration Port and Administrative Channel for more information.
P.S. Don’t forget to change BOTH your username and password. People are on to weblogic/weblogic, I’m afraid…