Question: when following this guideline (https://docs.lucee.org/guides/installing-lucee/securing-webinf.html) , how to access the server and web admins? Now we do a Deny access directive in IIS to https://my.domain/lucee/admin/* and hence can access the Admins via these URL's when removing this directive in IIS. We've been advised by a security company performing PEN-tests of our webapps to follow the above mentioned Lucee guideline.

You can use IP restrictions and MOD_REWRITE to block access to all /Lucee/** urls unless its the localhost. https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/creating-rewrite-rules-for-the-url-rewrite-module

And would you only do this for the WEB-admin, or also for the SERVER-admin? In our Tomcat web.xml there are <init-param>'s for both, but both are commented out, so by default the WEB-INF ends up in the webroot.

Yup, it does both.

So currently we only do Request Filtering in IIS to lucee/admin/, that blocks all access to the admins, but then there is the possibility to do other lucee/??? stuff you say?

Yes, you can for instance only block access to Lucee/admin if its from an external IP address, or your gateway, or anything else. Youl would need to setup and bind Lucee to an ip address. It can one on your internal network or localhost. Next, you bind External facing webpages to their own IP Addresses, even if they are internal.

Check, block all incoming traffic from a URL that is internet aware to Lucee files. And for example not is coming from localhost or https://my.subdomain.local/lucee/*

thats great, but you could bind site1 to IPbind-1 (internal ip) and then setup a site in IIS for site1, so your block works for site 1, but site 0 (localhost:8888) still works from the local machine,

OK, and that is instead of moving the WEB-INF folders to outside of the webroot, hence it would not be an issue that they are accessible via the internet. But then remains the question, how to access in browser?

you can set webroot to d:\mywebroot_sec| or whatever. You can setup rules per where you want access to the site, IE if you are on the LAN and need only access from your LAN ADMINIP, you could have a rule that literally blocks all traffic to /lucee from LAN, or if you need access everywhere you could have /LAN open. If you think of each web instance as a IP address bound to a website, you can do what you need with security on a per app - per use case basis.

OK, so that would mean we internally in the server have to create lots of IP-addresses per webserver, now there is just one for the whole server. And with 5 - 30 webapps per webserver that is quite the undertaking!

Not Overly and you can group them by need

Thnx, this is sure one approach that we could and probably should consider. Would also mean that we foresee our webapps to become monstrously popular 🙂. For now I will thank you for your insight and ponder a fast approach as advised by Lucee or a more comprehensive approach as you suggest. We would then need more infrastructure and network people than we currently have 😉. This sure was a lot to take in on the very late Monday afternoon!

work smarter - not harder --ask for more money instead of more people 🙂 This is the basis for the above approach -https://tanzu.vmware.com/content/blog/spinning-up-useful-vms-quickly-with-vagrant-puppet-and-puppet-forge

another option is to just disable the admin using

LUCEE_ADMIN_ENABLED

https://docs.lucee.org/guides/Various/system-properties.html#lucee_admin_enabledluceeadminenabled