PKI-Tomcat flagging up on security scans

[Jake Reynolds]

Hi,

I'm running ipa-server 4.8.7-13 on Centos 8.3.

My security scanning software is lighting up with a lot of warnings about my FreeIPA
servers - specifically Apache Tomcat vulnerabilities exposed on the PKI-Tomcat ports -
8080/8443. It is detecting v9.0.30, and seemingly has a different list of vulnerabilities
for each version below 9.0.43 that the service is vulnerable to.

Firstly, is the detection accurate? How can I determine the tomcat version in use here? If
the detection is correct, has this dependency been upgraded/is in the process of
upgrading?

Secondly, why are these ports exposed at all? It seems that the server.xml defines AJP
listening on port localhost:8009, which is what Apache forwards requests to. However this
port simply forwards on to 8443 which is listening publicly, and we also have 8080
listening publicly. As far as I can see from documentation connectivity to these endpoints
should not be needed. 

Thirdly, how can I configure pki-tomcat to not listen on these ports? I've tried
editing the connectors in /etc/pki/pki-tomcat/server.xml but the pki-tomcatd service fails
on restart - presumably an ipa service somewhere is configured to connect to the
FQDN/external IP rather than localhost. Error is ` ipa-pki-wait-running: Connection
failed: HTTPConnectionPool(host='my.fqdn.com', port=8080): Max retries exceeded
with url: /ca/admin/ca/getStatus (Caused by NewConnectionErr`.    I'm aware I could
firewall off the ports, but I'd rather they weren't listening in the first place.


The only reference I've been able to find is the bug here
https://github.com/dogtagpki/pki/issues/2748 - but this seems unresolved, and only refers
to installation as oppose to modifying an existing install.  

Thanks!
Jake

[Harry G. Coin]

Unless you want to commit resources to attain 'dev level' on over a
dozen packages, you have to think of Freeipa as having an 'everything
depends on everything' component config file inter-relationship  (one
that can change without a lot of warning between upgrades).  Before
taking on the burden of tweaking a config file then having to check it
every upgrade for un-intended side-effects: I'd consider using an added
firewall to restrict access according to your uses and security needs. 
That way when freeipa changes how the internals relate to one another,
or a subsystem changes what's live and what's deprecated in config files
-- tracking that doesn't become your drama.


On 4/19/21 11:10 AM, Jake Reynolds via FreeIPA-users wrote:
>  Hi,
>
>  I'm running ipa-server 4.8.7-13 on Centos 8.3.
>
>  My security scanning software is lighting up with a lot of warnings about my FreeIPA
> servers - specifically Apache Tomcat vulnerabilities exposed on the PKI-Tomcat ports -
> 8080/8443. It is detecting v9.0.30, and seemingly has a different list of vulnerabilities
> for each version below 9.0.43 that the service is vulnerable to.
>
>  Firstly, is the detection accurate? How can I determine the tomcat version in use here?
> If the detection is correct, has this dependency been upgraded/is in the process of
> upgrading?
>
>  Secondly, why are these ports exposed at all? It seems that the server.xml defines AJP
> listening on port localhost:8009, which is what Apache forwards requests to. However this
> port simply forwards on to 8443 which is listening publicly, and we also have 8080
> listening publicly. As far as I can see from documentation connectivity to these endpoints
> should not be needed. 
>
>  Thirdly, how can I configure pki-tomcat to not listen on these ports? I've tried
> editing the connectors in /etc/pki/pki-tomcat/server.xml but the pki-tomcatd service fails
> on restart - presumably an ipa service somewhere is configured to connect to the
> FQDN/external IP rather than localhost. Error is ` ipa-pki-wait-running: Connection
> failed: HTTPConnectionPool(host='my.fqdn.com', port=8080): Max retries exceeded
> with url: /ca/admin/ca/getStatus (Caused by NewConnectionErr`.    I'm aware I could
> firewall off the ports, but I'd rather they weren't listening in the first place.
>
>
>  The only reference I've been able to find is the bug here
> https://github.com/dogtagpki/pki/issues/2748 - but this seems unresolved, and only refers
> to installation as oppose to modifying an existing install.  
>
>  Thanks!
>  Jake
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Jake Reynolds]

Thanks for the response.

I appreciate the inter-dependency, and a firewall probably is the workaround that I'm
going to use - but it still seems a lazy approach? To just hide/restrict a security
problem rather than fixing the root cause. I was hoping there would be a better approach,
and I expected other users to have had these alerts flagged by vulnerability scanners if
I'm honest.

[Christian Heimes]

On 20/04/2021 10.24, Jake Reynolds via FreeIPA-users wrote:
>  Thanks for the response.
>  
>  I appreciate the inter-dependency, and a firewall probably is the workaround that I'm
> going to use - but it still seems a lazy approach? To just hide/restrict a security
> problem rather than fixing the root cause. I was hoping there would be a better approach,
> and I expected other users to have had these alerts flagged by vulnerability scanners if
> I'm honest.  
We cannot bind the ports of PKI Dogtag's Tomcat instance to
localhost-only. FreeIPA uses HTTPS with client cert authentication to
talk to Dogtag. HTTPS verifies that the hostname matches the hostname in
the certificate. Although only local process talk to local Tomcat
instances, it is not possible to do that over localhost. The FQDN
typically only resolves to public interfaces. We also don't want to
create certificates with "localhost" SAN.

If you don't like to add firewall rules, then you can also use systemd
to block external access to Dogtag's Tomcat service with a service override:

# systemctl edit pki-tomcatd(a)pki-tomcat.service
[Service]
IPAddressAllow="127.0.0.1 ::1"


Christian

-- 
Christian Heimes
Principal Software Engineer, Identity Management and Platform Security

Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill

[Jake Reynolds]

Thanks for the comprehensive reply! I'll follow your suggestion