Category Archives: apache

Increasing the name width in Apache auto indexing

apache

Truncated names in Apache auto indexing aren’t helpful at all. With people running displays at 5k, there’s little reason to have this as the default behaviour. Alas, it still is and probably will be until the end of time. That said, it’s easy to get around this.

In out-of-the-box Apache install, uncomment the following line:

Include etc/apache24/extra/httpd-autoindex.conf

In that file, look for the following line:

IndexOptions FancyIndexing HTMLTable VersionSort

We want to add the NameWidth option, as so:

IndexOptions FancyIndexing HTMLTable VersionSort NameWidth=*

Restart your browser and reload the page and you’ll notice a much improved experience.

PHP IPAM installation issues and how to fix or avoid them

apache, php

The issues I had was during the install process were with broken CSS, a jQuery error, a couple missing PHP modules, broken Captcha images and unusable complex passwords.

The broken CSS and jQuery errors were a result of my client’s web server SSLSessionCache configuration was incorrect (missing) and their intermediate certificate was also corrupt. I fixed both of these issues and it fixed the CSS and jQuery errors. If you have these issues, it isn’t likely an PHPIPAM problem, but a problem with your server config.

The second issue was post install:

Warning: file(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in functions/classes/class.Tools.php on line 1694

The very simple fix for this is to make sure the PHP curl module is installed. It’s not listed as a required module on the PHP IPAM installation guide, but it definitely is.

In addition, my Captcha images were broken. I had GD installed, but I didn’t have the PHP GD module installed. Easily fixed by installing the PHP GD module and a quick web server restart.

Finally, if you are like me and use ridiculously complex passwords generated by a cloud-based secret server, such as Encryptr, LastPass, Thycotic, 1Password, etc, it should be noted that while you can use a password up to 128 characters long, per the DB schema, you cannot use special characters, or at least some special characters. I had to use the ‘functions/scripts/reset-admin-password.php’ feature a few times. When using an invalid password you are not provided with any warnings; it simply accepts it, so this issue may not be obvious at first.

All these issues are trivial and easily fixed or circumvented. The PHPIPAM software is amazing and please do not let this post discourage you from installing it.

Update: I found another PHP module that is required post-installation that isn’t mentioned on the PHP IPAM website, which is the ctype module. It addresses this issue:

Fatal error: Call to undefined function ctype_digit() in functions/PEAR/Net/IPv4.php on line 242

HTTPS configuration made easy

apache, ssl/tls

I know a lot of people struggle with configuring SSL on their web server. A quick trip to Qualys SSL Labs to see the “Recent Worst” validates that. However, there’s a tool that can easily bring your web server up to the best current operating practice.

Check out the Mozilla SSL Configuration Generator. However, before hastily you cut and paste the generated code, take a few minutes to understand the implications between choosing “Modern”, “Intermediate” and “Old”. Modern, which is what this website uses, has the fewest supported browsers but the best security. Old has the most supported browsers and the laxest security; using Old is a terribly bad idea and should really never be done. For many, Intermediate is a nice balance of both browser support and security.

The recommendations from the code generator change often and your should check back regularly to make sure you are still running the best current configuration.

There are also many hints, tips and tricks available at Qualys.

Until recently, there has been little motivation to encrypt websites that do not necessarily need it. However, that has changed. Let’s Encrypt has just disrupted the industry by offering free SSL certificates to anyone. Let’s Encrypt is overseen by the Internet Security Research Group, a California public benefit corporation, whose benevolent agenda includes securing the Internet at large. Bravo! We will post about using Let’s Encrypt in the near future.

If you now have a certificate from Let’s Encrypt and some very secure configuration, it’s now time to force your users to use HTTPS/443, while maintaining backwards compatibility so that users clicking on Google search results won’t receive a server timeout message when connecting to your now legacy HTTP/80. Check out our earlier post on how best to do this.

Additionally, make sure your SSL certificate is SHA-2, or all the above security implementations could be for naught. All Let’s Encrypt certificates are SHA-2/SHA-256. Read this Ars Technica article and this SSLs.com blog post for more information on transitioning to SHA-2. All certificates issued after January 1st, 2016 are required to be SHA-2. Never hurts to double check this however. Most certificate authorities are now also reissuing your old, but still valid certificates, as SHA-2 at no charge.

There’s a very quick check you can do to check whether your certificate is SHA-1 or SHA-2 available at shaaaaaaaaaaaaa.com. Happy to report that this website received the ever-so-desirable “Nice” rating.

Updating OpenSSL for Apache without breaking your base OpenSSL install on FreeBSD 9.2-RELEASE

apache, freebsd, mysql, php, , , , ,

After two very frustrating days, I have finally been able to perform what used to be a fairly routine thing for me, which is creating a FAMP server using FreeBSD, Apache 2.2.x, MySQL 5.x.x and PHP 5.5.x.

Several issues arose out of my attempts.

My first attempt was installing Apache 2.4.9, MySQL 5.6.17 and PHP 5.5.12 on FreeBSD 10.0-RELEASE-p3 (AMD64). This was my first time installing anything greater than MySQL 5.1.x. ‘./configure’ has been replaced with ‘cmake .’; other than that, all things ordinary. This was also my first time installing Apache 2.4.x and there are several new steps involved. The first is that you now have to manually install Apache’s portable runtime library and associated utilities. Piece of cake. Grabbed those from the APR website and installed without issue. Apache installed. But now the trouble. I was able to ‘./configure’ and ‘make’ PHP without issue, but during the ‘make install’ I ran into an issue.

# make install
Installing PHP SAPI module: apache2handler
/usr/local/httpd/build/instdso.sh SH_LIBTOOL='/usr/local/apr/build-1/libtool' libphp5.la /usr/local/httpd/modules
/usr/local/apr/build-1/libtool --mode=install cp libphp5.la /usr/local/httpd/modules/
libtool: install: cp .libs/libphp5.lai /usr/local/httpd/modules/libphp5.la
libtool: install: cp .libs/libphp5.a /usr/local/httpd/modules/libphp5.a
libtool: install: chmod 644 /usr/local/httpd/modules/libphp5.a
libtool: install: ranlib /usr/local/httpd/modules/libphp5.a
libtool: install: warning: remember to run `libtool --finish /usr/local/src/php-5.5.5/libs'
Warning! dlname not found in /usr/local/httpd/modules/libphp5.la.
Assuming installing a .so rather than a libtool archive.
chmod 755 /usr/local/httpd/modules/libphp5.so
chmod: /usr/local/httpd/modules/libphp5.so: No such file or directory
apxs:Error: Command failed with rc=65536

Keep in mind, this was a brand new, entirely fresh FreeBSD 10.0-RELEASE install with ‘freebsd-update’ run bringing it to -p3. Nothing else had been done on this box except the MySQL and Apache installs.

I found it very strange that in that small bunch of code, two separate libtools were referenced. Foolishly, I didn’t check my working server to compare. In any case, ‘/usr/local/apr/build-1/libtool’ and the libtool included with the PHP source were both referenced. For good measure, I even installed libtool using ‘pkg install’. Nothing worked and libphp5.so failed to be created. Not being a software developer, I went to Google looking for the answer but came up short. A few suggestions were to use the .bz2 version instead of the .tgz version, use ports and one person even pointed the finger at the AMD64 build of FreeBSD. I briefly attempted to install a known working version of libphp5.so from another one of my servers but that just created more issues. I moved on.

I reloaded the OS from scratch and tried again. Same result. I’m a sucker for punishment.

I then reinstalled the OS using FreeBSD 9.2-RELEASE. As before, I ran ‘freebsd-update’ first thing and brought it up to -6p. I compiled MySQL using the new steps I had learned earlier. Same with Apache, except I used 2.2.27 this time to simplify things; go with what you know. Then the true test, PHP 5.5.12, which also installed no problem. Added a few times to httpd.conf and started the server. Problem. I telneted to port 80 to see what version or OpenSSL I was using and it came back as 0.9.8y. This version isn’t vulnerable to the heartbleed vulnerability, but it does lack TLSv1.1 and TLSv1.2 support, which I need, if only to give my clients a greater sense of security. So I search Google for “freebsd upgrade openssl” and a few articles come up, including one I had recently visited. I went back, performed the needful using ports and OpenSSL was upgraded. Sort of. The base OpenSSL install has its binaries in /usr/bin, libraries in /usr/lib and config file in /etc. The port install puts the binaries in /usr/local/bin, the libraries in /usr/local/lib and the config file in /usr/local/etc/ssl. So I have two completely autonomous OpenSSL installs at this point. Typing ‘which openssl’ shows /usr/bin/openssl which is version 0.9.8y. ‘/usr/local/bin/openssl version’ shows 1.0.1g. Again, 0.9.8y is not vulnerable to heartbleed, but it is insufficient for my needs. After further reading, a few people suggested to remove the old binary and symlink /usr/local/bin/openssl to /usr/bin/openssl and also symlink the configuration files. This seemed to work, so I rebuilt Apache again thinking that version 1.0.1g would show up. But it didn’t. Knowing that this was a new install and that I would probably blow it away once I found a working formula, I started deleting things, symlinking things, moving things, etc. I reminded myself of my father-in-law who while looking to free up space on his internal HDD, he deleted his windows system files with the rational of “I’ve never used those, I can delete them.” A mess I made. Server trashed. Blank slate.

Again, I started with FreeBSD 9.2-RELEASE. I immediately updated using freebsd-update to -p6. I then downloaded and installed OpenSSL 1.0.1g from the OpenSSL website. I then confirmed that my base and secondary install were as expected:

# /usr/bin/openssl version         
OpenSSL 0.9.8y 5 Feb 2013

Good.

# /usr/local/ssl/bin/openssl version
OpenSSL 1.0.1g 7 Apr 2014

Great.

When it came to compiling Apache, I had to compile mod_ssl as a static module. In the process, a few of the core modules were also made static, so I had a mishmash of static and dynamic. I had to comment out a few of the LoadModule statements in the httpd.conf, but in the end, everything works as it should.

[root@server01 ~]# telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
HTTP/1.1 / GET

HTTP/1.1 501 Method Not Implemented
Date: Wed, 28 May 2014 23:07:36 GMT
Server: Apache/2.2.27 (Unix) DAV/2 PHP/5.5.12 mod_ssl/2.2.27 OpenSSL/1.0.1g
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Length: 220
Connection: close
Content-Type: text/html; charset=iso-8859-1

Success! I now have a server running exactly the way I want and I have no compromised any of the base OpenSSL files, or anything that was built against them. While I think this was a fairly good way to accomplish this task, there are probably even better ways to do it. However, my Googling efforts did not lead me to those.

Another other method, which some will say is more elegant, would have been to install from pkg or ports. However, I disagree. Since I compiled my first web server twenty years ago to present day, I have always been an advocate of compiling critical services from source. If all you ever do is type ‘pkg install apache22’ how do you learn to troubleshoot when something goes wrong? How do you know how to fine tune your installation when you need to compile in sockets, or curl, or other libraries and modules? I prefer infinite control.

Forcing users to use HTTPS the simple and secure way

apache, unix

Very simple Apache configuration using mod_rewrite.

<VirtualHost 1.2.3.4:80 [2001:4800::2]:80>
DocumentRoot /home/someuser/websites/whatever.com/html
ServerName whatever.com
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</VirtualHost>

Do not forget to create the SSL entry as well:

<VirtualHost 1.2.3.4:443 [2001:4800::2]:443>
DocumentRoot /home/someuser/websites/whatever.com/html
ServerName whatever.com
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
SSLEngine on
SSLProtocol -ALL +TLSv1 +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder On
SSLCipherSuite "YOURPREFEREDSUITE"
SSLCompression off
SSLCertificateFile /home/someuser/ssl/whatever.com.crt
SSLCertificateKeyFile /home/someuser/ssl/whatever.com.key
SSLCertificateChainFile /home/someuser/ssl/gd_bundle.crt
</VirtualHost>