#4431 [RFE] Harden the httpd instance front ending ipa-server
Opened 8 years ago by pviktori. Modified 4 years ago

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1117050

We should make it possible to harden the httpd instance front ending ipa-server. Specifically it would be nice to add -FollowSymLinks to the configuration.

We should also remove unneeded Apache modules.

Additional requests:

Change the root file system directory directive in httpd.conf from this:

<Directory />
    Options FollowSymLinks
    AllowOverride None
</Directory>

to this:

<Directory />
    Options None
    AllowOverride None
    Order deny,allow
    Deny from all
</Directory>

and thus deny access to the root of the FS.



Remove autoindex module.

If needed, also update the SSL ciphers, just like we did with 389-ds-base in #4395. [2016-01-08: separate ticket created: #5589]


How do you know what modules are needed?

Care needs to be taken to not cause any existing applications to break.

According to Joe Orton (httpd maintainer), the best way to run a hardened httpd is a custom systemd service running a separate Apache instance with custom configuration.

Do we want to go this way for IPA? I think it would make sense.

Triaged this week:

  • Joe Orton advised to implement custom httpd systemd service. Not as easy at it may seem, would make httpd configuration much more difficult, upgrades would also not be easy. I would keep in needs triage until Dmitri, Simo, Petr and others return
  • abbra: we already require that IPA frontend is not shared with other web services on the machine, so what would be a gain?
  • simo: I actually use custom httpd service files for development and it is not such a big deal, what is the concern of providing ipa.specific systemd files?
  • npmccallum: deploying custom httpd configuration + adding a conflict with standard httpd may be the cleanest solution
  • rcritten & abbra: Separate httpd config is not a good idea, would send bad message that multiple httpd services can be run and supported
  • mkosek: still, many people run other software on the server, even if just for PoC use case, we should not break them. It may be best if we could just override default configuration with a drop-in configuration file and keep using the default httpd instance.

Let us discuss further in 4.2 time frame.

I tried to strip down the modules to the lest required subset that would still allow IPA httpd to start and to have functional CLI&Web UI&Certificate operation redirections - this is the list:

# egrep "^LoadModule" /etc/httpd/conf/*.conf /etc/httpd/conf.d/*
/etc/httpd/conf/httpd.conf:LoadModule authz_host_module modules/mod_authz_host.so
/etc/httpd/conf/httpd.conf:LoadModule authz_user_module modules/mod_authz_user.so
/etc/httpd/conf/httpd.conf:LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
/etc/httpd/conf/httpd.conf:LoadModule log_config_module modules/mod_log_config.so
/etc/httpd/conf/httpd.conf:LoadModule setenvif_module modules/mod_setenvif.so
/etc/httpd/conf/httpd.conf:LoadModule mime_module modules/mod_mime.so
/etc/httpd/conf/httpd.conf:LoadModule autoindex_module modules/mod_autoindex.so
/etc/httpd/conf/httpd.conf:LoadModule negotiation_module modules/mod_negotiation.so
/etc/httpd/conf/httpd.conf:LoadModule dir_module modules/mod_dir.so
/etc/httpd/conf/httpd.conf:LoadModule alias_module modules/mod_alias.so
/etc/httpd/conf/httpd.conf:LoadModule rewrite_module modules/mod_rewrite.so
/etc/httpd/conf/httpd.conf:LoadModule proxy_module modules/mod_proxy.so
/etc/httpd/conf/httpd.conf:LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
/etc/httpd/conf.d/auth_kerb.conf:LoadModule auth_kerb_module modules/mod_auth_kerb.so
/etc/httpd/conf.d/nss.conf:LoadModule nss_module modules/libmodnss.so
/etc/httpd/conf.d/wsgi.conf:LoadModule wsgi_module modules/mod_wsgi.so

Moving to 4.3, we are too close to 4.2 deadline to be able to handle stretch RFEs.

Related: #5555 (Installer should warn about http_proxy).

Related: #5589 (Update the default mod_nss cipher suite)

freeipa-users member requested disabling HTTP TRACE/TRACK methods (source).

Related page: https://www.owasp.org/index.php/Cross_Site_Tracing

Metadata Update from @pviktori:
- Issue assigned to someone
- Issue set to the milestone: FreeIPA 4.5 backlog

5 years ago

Metadata Update from @pvoborni:
- Issue assigned to frenaud (was: someone)
- Issue close_status updated to: None
- Issue set to the milestone: FreeIPA 4.5 (was: FreeIPA 4.5 backlog)

5 years ago

LInks to the Stigs from all the attached BZs:

Metadata Update from @mbasti:
- Issue set to the milestone: FreeIPA 4.5.1 (was: FreeIPA 4.5)

5 years ago

Metadata Update from @pvoborni:
- Issue set to the milestone: FreeIPA 4.7 (was: FreeIPA 4.5.1)

5 years ago

As @mkosek asked:

freeipa-users member requested disabling HTTP TRACE/TRACK methods (source).

Will this be included with this hardening update?

Is there a very rough time estimate on when this may be available? I am getting pressure for this to be fixed in our environment.

Not really. It doesn't look like this is going to make it into 4.7.0.

This is likely to be supplanted by https://pagure.io/freeipa/issue/6992 which is also unlikely to make 4.7.0.

Metadata Update from @rcritten:
- Issue set to the milestone: FreeIPA 4.7.1 (was: FreeIPA 4.7)

4 years ago

FreeIPA 4.7 has been released, moving to FreeIPA 4.7.1 milestone

Login to comment on this ticket.

Metadata