No matter what I do, I cannot lock down the server admin

dev support
#1

I’m sorry for coming in here with such a basic question but I am at the end of my rope with this. Nothing I do seems to have any effect whatsoever.

I’m on Windows and using IIS. I ran the Lucee installer and also chose to install AJP and mod_cfml. This was all successful. My CFML pages process, I can see the BonCode handler mappings in IIS, and I can access and configure Lucee via the server admin. Everything’s working.

Except, no matter what I do, I can’t disable access to the server admin. What I want is for the admin to only be accessible from localhost, all other connections should be blocked. I’m aware there is a setting in BonCodeAJP13.settings:

<EnableRemoteAdmin>False</EnableRemoteAdmin>

But it is set to ‘false’ and the server admin is still remotely accessible. I thought I had it when I realized I’d been editing the BonCodeAJP13.settings file located in C:\lucee\AJP13 but when I configured the same file in C:\Windows it still didn’t work. I also tried Apache Location directives, but those didn’t work either. Maybe I put them in the wrong files or specified the wrong path. I restart the Apache Tomcat service every time I change a config, so it’s not that. I can’t block it in IIS because the requests to myLucee.com:8888 go straight to Tomcat and IIS never has a chance to process them. For some reason, even setting up an inbound rule on the windows firewall to block port 8888 didn’t work.

I can’t imagine it’s actually this difficult to do something so simple. Can anyone show me what boneheaded thing I’m doing that’s screwing this up?

OS: Windows Server 2016 x64
Java Version: 11.0.7
Tomcat Version: 9.0.35
IIS Version: 10.0.14393.0
Lucee Version: 5.3.6.61

#2

Start by confirming what actual copy of the boncode settings XML file is in use. Add this to the end of a local url

?BonCodeConnectorVersion=true

and Boncode will highjack the request and output the exact location of the config file it’s using. Then, after editing the file, make sure you restart IIS to pick up the changes.

I’m not super familiar with that specific setting of Boncode. I would recommend looking into the “hidden” segments setting in IIS to block the /lucee/admin paths. Then, if you want to hit the admin, you can use the HTTP port of your Tomcat listener to “bypass” IIS/Boncode.

#3

Thanks for your help. The output I got is:

BonCodeAJP Connector Version 1.0.41
using setting file in C:\Windows\BonCodeAJP13.settings

So that looks good. I confirmed EnableRemoteAdmin is set to false in that file.

However, when I visit http://myLucee.com:8888/lucee/admin/server.cfm from a different machine, I still see the login page. I can’t use any IIS setting to block this because this request is never seen by IIS. Only Tomcat is listening on 8888, not IIS.

#4

Wait, that’s your problem! Boncode is a “plugin” if you will to IIS and it only has the ability to affect request that come into IIS’s HTTP/S port and are proxied back to Tomcat. When you hit Tomcat directly, you are correct that IIS never “sees” the request, which also means Boncode never “sees” the request, which means Boncode’s settings are not going to help you here.

If you don’t want Tomcat’s HTTP port to be accessible outside of this machine, then

  • Block it with a firewall or…
  • Change Tomcat’s server.xml to bind only to localhost.
2 Likes
#5

Yes! I knew there had to be some dumb thing I wasn’t getting. Just changed server.xml so it binds only to localhost and now I can only access the server admin locally. Thank you so much for your help

1 Like
#6

Locking down at the firewall is the best approach in my view. Block everything by default and then only open those ports/services you need to be accessed from outside.

Even though you’ve solved the problem I would look at why your rule wasn’t effective, otherwise you could be exposed in other ways you’re not aware of.

#7

I had an issue with IIS when a rule was being processed first with it set to stop processing other rules, so IIS never got to the rule to block admin access.
Maybe the firewall rules work in a similar way?