Tag Archives: HTTPD

Securing DNS and Web Servers

In this introductory article, I will present several methods for helping to secure DNS and Web Servers. I am using BIND 9.9.4 and Apache HTTPD 2.4.6 on CentOS 6.4. BIND and HTTPD are by far the most common DNS and Web Server platforms. I will show how to build the software from source, as well as perform an initial secure configuration. I will presume a minimal installation of CentOS 6.4. If you’re using another Linux or UNIX variant, you will need to adjust the procedures accordingly. This article presumes that the reader is already familiar with DNS and Web Servers, particularly BIND and HTTPD.

Fully hardening these services is a very complex subject and we only touch on the major aspects of configuration below.

Continue reading →

SELinux: Allowing httpd to Listen on Non-Standard Ports

If you attempt to have httpd listen on a non-standard port (we’ll get to what’s “standard” and what isn’t in a moment) on an SELinux enabled host, SELinux will deny the request. Let’s try it out (on a CentOS 6.4 box):

Kaboom! As you can see, the error message is quite clear “(13)Permission denied: make_sock: could not bind to address”. Let’s take a look at the audit logs and see what’s going on:

There are two sets of messages there, one for the IPv4 bind, the other for the IPv6 bind. The AVC message actually makes it clear what’s going on:

type=AVC msg=audit(1371477046.382:20195): avc: denied { name_bind } for pid=16429 comm="httpd" src=8585 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket

You can see that the violation is from source context (scontext) unconfined_u:system_r:httpd_t which is the httpd process, and the target context (tcontext) is system_u:object_r:port_t with target class (tclass) tcp_socket. The denied port (8585 in this case) is also logged in the src field.

SELinux will only allow httpd to bind to ports of type http_port_t. Here, we can see that httpd is attempting to bind to a port of type port_t - which is going to be denied by the policy. We need to define port 8585 as a port of type http_port_t. semanage is the tool for that - and you’ll need the policycoreutils-python package installed:

First, let’s look at which ports are currently defined as type http_port_t:

And add our desired listen port, 8585/tcp to the list:

Looks good. Fire up httpd:

And test with nc or similar:

 

Running Puppet Master under Apache and Passenger - CentOS 6.4

I have been running my puppetmaster using the embedded WEBrick server for a while. I decided it was time to migrate to something a little more robust - namely Apache and Passenger. I loosely followed the documentation available on the Puppet site, although that covers Passenger 3.0.x and I’m using 4.0.x, and the supplied Apache configuration does not work. There were also a few other changes I had to make along the way to suit my configuration requirements. My puppetmaster is running CentOS 6.4.

Continue reading →

WordPress: Avoiding Infinite Recursion with mod_rewrite and mod_fastcgi

Whilst converting tokiwinter.com away from mod_php to mod_fastcgi/PHP-FPM, I experienced the following error:

Enabling LogLevel debug for the VirtualHost showed the following extra detail:

We can see that the rewrites required for WordPress in .htaccess are interfering with the correct operation of mod_fastcgi. The net result - HTTP 500 Internal Server Error for all our clients.

The fix is easy enough - add the following additional rewrite to .htaccess for the WordPress installation:

i.e. if the request URI is a mod_fastcgi request, do not apply any rewrites. My complete .htaccess file in my WordPress VirtualHost is now:

This works for me with the following VirtualHost configuration:

Your mileage may well vary.

How to Load Balance Tomcat with Apache HTTPD and mod_jk

In the following article, I’ll demonstrate how we can use Apache HTTPD to load balance across two Apache Tomcat instances. Whilst in this example the Apache HTTPD load balancer is a single point of failure, we could implement (although outside the scope of this article) a failover HTTPD instance clustered using one of the many available clustering stacks (RHCS, or something more lightweight like keepalived). Then, we’d have a highly-available load balancer.

There are a few ways we can use HTTPD to load balance, via the use of loadable modules. mod_proxy_http is the simplest, and can be used to load balance any service that “speaks” plain HTTP. mod_proxy_ajp is a simple AJP balancer module, with a slight performance increase of mod_proxy_http. However, mod_proxy_ajp is purported to be rather buggy when compared with other similar modules. Hence, we’ll use mod_jk. This is a very active module developed alongside Tomcat, and in many years of working with it I’ve never experienced a major bug or a configuration requirement it couldn’t handle.

Continue reading →

SELinux: Allowing HTTPD to Connect to PHP-FPM

When running PHP-FPM (PHP FastCGI Process Manager), it can be configured to listen on a UNIX socket, or a TCP port. When using the latter on an SELinux enabled system, you will receive HTTP 500 Internal Server Errors if SELinux is not configured correctly.

For example, on my system, I’m using the following directive (in my example.com VirtualHost):

However, the default value of the httpd_can_network_connect SELinux boolean is false, or off. Therefore, httpd is unable to connect to the PHP-FPM pool listening on 127.0.0.1:9000.

You will see AVC denial messages in /var/log/audit/audit.log such as:

To fix this issue, set the httpd_can_network_connect SELinux boolean to true, or on, remembering the -P option so that this change persists across system reboots.

 

Puppet Module: apache2: VirtualHost templates

Module: apache2

Purpose: This module shows how an ERB template can be used to create VirtualHost definitions

File: apache2/manifests/init.pp

Notes: This is the base class. It can just be included within a node definition to install a stock httpd from yum. Also sets up a site-specific define - see comments in file.

File: apache2/manifests/vhost.pp

Notes: Contains the virtual host definition. Supports only port 80 (else we’d need to ensure SELinux had the correct configuration for http_port_t, etc.), and fairly basic VirtualHost configuration. Anything more “fancy” can be implemented using the site-specific define set up in init.pp, or by using a custom $template.

File: apache2/templates/vhost-default.conf.erb

Notes: ERB template for the VirtualHost configuration

 

Apache HTTPD mod_rewrite: one RewriteCond to many RewriteRules

Within Apache HTTPD’s mod_rewrite, RewriteCond only applies one RewriteRule that comes immediately after the RewriteCond itself. It didn’t seem like such a great idea to have to duplicate a lengthy RewriteCond definition half a dozen times for multiple RewriteRules.

Turns out there is a fairly simple trick to achieve exactly what I was looking for: if the RewriteCond is negated and followed by RewriteRule . – [S=n] to skip the following n rules, the RewriteRules in essence are only applied when the singular RewriteCond is true. Like so:

Now the last three rules are skipped if the condition is not true or, in reverse, they are applied if the condition is true. Each pattern is then handled individually, and the [L] rewrite option will cause only the pertinent rule to be applied - processing will stop after the first matched condition.

Apache httpd: How to Use htpasswd to Password Protect Areas of your Site

This doesn’t cover the basics of configuring httpd, etc. You should know how to do that! Also, this is being done on an old RHEL 4 box.

If you’re having trouble with selinux blocking CGI in weird and wonderful ways, disable it:

Anyway … modify /etc/httpd/conf/httpd.conf and add a <Directory> directive for the directory that you wish to protect, e.g. :

It will protect all subdirectories under the directory too. You can obviously just specify a specific directory if you want, but I want to password protect the entire website.

Create a directory for your htpasswd file - do not put this under your DocumentRoot - somewhere under the ServerRoot is good, but I put it in /usr/local/etc/httpd:

Then create the htpasswd file and add your first user

I always chown apache:apache /usr/local/etc/httpd/users and then chmod 400 /usr/local/etc/httpd/users.

The -c is not required when adding further users to the users file

Then, just restart httpd (only needed as we changed the httpd.conf file - you don’t need to restart httpd after just adding/deleting users with htpasswd), and browse!

(or service httpd restart, /etc/init.d/httpd stop && /etc/init.d/httpd start, whatever….)

Done !