Basic question. Is Tomcat part of the chain that servers normal CF pages, or is it only used for the admin UI?

Every request to CF goes through the Servlet container.

So in theory we should be watching for Tomcat security issues too?

Yes

Would Adobe talk about those too?

This is why I prefer a stack where all these pieces are independent and can be updated as necessary to deal with CVEs -- instead of having one big ball of JRE + web server (Adobe-modified Tomcat -- not even stock, public Tomcat!) + CFML engine where you can't upgrade any of the parts without Adobe officially updating stuff...

Understood. We (read: I) don't have the expertise to be confident of correct and secure implementation at that level, and I don't have the cycles to dig into it enough to trust our organization's security to me doing it. In this area, I'm a textbook case of leaning on Adobe to provide the core framework, for better and worse. I know that earns me your undying scorn 😉 but it is what it is. I'm good at what I do, which isn't mostly that, so far anyway.

Nah, no scorn. I've just always been in a position where I didn't have to rely on Adobe fixing stuff quickly and making sure updates actually worked -- which is my real issue with the way they manage the stack.

Not unrelated, the lockdown guide says the auto lockdown tool blocks /jakarta, but I get 404.5 errors like above on every page when I do that manually in IIS. Can someone explain why that's happening, and what the best strategy is here?

@Dave Merrill did you mean to post those last two as a thread under your Application.cfc/IIS blocking question in the main channel?

@seancorfield Yes, it's an example of what I don't understand about the full CF stack. But it's not JUST an illustration, I do actually need to get things working correctly, but still as secure as we can make them. For now I've removed the filtering of /jakarta, things work, but I don't understand why I had to remove it, or why the lockdown guide says to block it.

FWIW, I've never heard of suggestions to block

/jakarta

requests and none of the Tomcat security guides I've seen mention that. Your best bet would be to ask in #adobe what those requests are for and why they're enabled in the first place (given the lockdown guide says to block them).

Thanks @seancorfield. @Mark Takata (Adobe) @priyank_adobe Hate to ping you about this, but I kind of need to know what's happening here. • Page 35 of the CF 2021 Lockdown Guide definitely includes /jakarta in the list of URLs it says the Auto-Lockdown Tool will block. Any anyone confirm if that's actually true? • Can anyone explain to me why manually doing that in IIS causes 404.5 errors on every page in the site? • Can anyone tell me anything about how to block /jakarta and still have the site working? • Can anyone tell me what the security issue is that blocking /jakarta helps with, and how serious it is?

I... I don't think its supposed to be doing that. @foundeo any insight here?

The reason to block /jakarta is that there are isapi_redirect.log files and config files in that folder - the jakarta IIS connector should block those by default, but there can be cases where they are not blocked (if you renamed them for example)… however you can’t block /jakarta/isapi_redirect.dll or else it will prevent your site from working, I’m guessing thats your 404 error… so what you can do is block /jakarta but allow /jakarta/isapi_redirect.dll

The jakarta virtual directory is a thing on the windows version of the tomcat connector, Adobe didn’t invent or add this, it is just not there on linux so that is why it is not mentioned in most tomcat guides

And this is specific to the AJP proxy on Windows? Can IIS do plain HTTP proxy? That would be equivalent to how I've always configured Apache/Nginx on Linux (avoiding AJP).

yeah, it is for the AJP IIS connector for tomcat. IIS can do a plain http proxy as well, you have to add on a module to do it but it is fairly easy to do… The problem is that it becomes difficult if you have multiple virtual hosts, which is why Adobe favors the AJP route

Ah, a good reason to run Apache or Nginx instead of IIS then 🙂

yeah it can still be a pain on apache / nginx because you need some way of mapping web root to a virtual host. You can mess with server.xml to get this working, or you can get around this by doing multiple instances (one instance for each domain) either way it is way more painful than just using the AJP connector.

Thanks Pete.

yeah, good point Dave — it does say just before that in section 5.7.3 that you must ensure the dll file extension is allowed in /jakarta, but it would probably be a good idea to highlight that /jakarta/isapi_redirect.dll is required to be allowed if /jakarta is blocked