Tag: Apache

Securing WordPress A Little Bit

We’ve had quite a lot of source IP’s flooding our web server the past few days. The first couple, I just blocked entirely … but we get a good bit of traffic to my husband’s business domain. That traffic is not exclusively people randomly surfing the Internet — we’ve been getting records in our logs that very specifically look like hacking attempts.

I’ve added a few stanzas into my Apache configuration to block access to “important” files unless the source is my tablet’s IP:

         <Files ~ "wp-config.php">
                Order deny,allow
                deny from all
                Allow from 10.5.5.0/24
        </Files>

        <Files ~ "wp-login.php">
                Order deny,allow
                deny from all
                Allow from 10.5.5.0/24
        </Files>

        <Files ~ "wp-settings.php">
                Order deny,allow
                deny from all
                Allow from 10.5.5.0/24
        </Files>

        <Files ~ "xmlrpc.php">
                Order deny,allow
                deny from all
                Allow from 10.5.5.0/24
        </Files>

       <Directory "/">
                Order allow,deny
                Allow from all
        </Directory>

        <Directory "/var/www/vhtml/lisa/html/wp-admin">
                Order deny,allow
                deny from all
                Allow from 10.5.5.0/24
        </Directory>

Then went into the MySQL database and renamed all of the tables to remove the default prefix:

rename table wp_commentmeta to prefix_commentmeta;
rename table wp_comments to prefix_comments;
rename table wp_links to prefix_links;
rename table wp_ngg_album to prefix_ngg_album;
rename table wp_ngg_gallery to prefix_ngg_gallery;
rename table wp_ngg_pictures to prefix_ngg_pictures;
rename table wp_options to prefix_options;
rename table wp_postmeta to prefix_postmeta;
rename table wp_posts to prefix_posts;
rename table wp_statistics_exclusions to prefix_statistics_exclusions;
rename table wp_statistics_historical to prefix_statistics_historical;
rename table wp_statistics_pages to prefix_statistics_pages;
rename table wp_statistics_search to prefix_statistics_search;
rename table wp_statistics_useronline to prefix_statistics_useronline;
rename table wp_statistics_visit to prefix_statistics_visit;
rename table wp_statistics_visitor to prefix_statistics_visitor;
rename table wp_term_relationships to prefix_term_relationships;
rename table wp_term_taxonomy to prefix_term_taxonomy;
rename table wp_termmeta to prefix_termmeta;
rename table wp_terms to prefix_terms;
rename table wp_usermeta to prefix_usermeta;
rename table wp_users to prefix_users;
rename table wp_wfBadLeechers to prefix_wfBadLeechers;
rename table wp_wfBlocks to prefix_wfBlocks;
rename table wp_wfBlocksAdv to prefix_wfBlocksAdv;
rename table wp_wfConfig to prefix_wfConfig;
rename table wp_wfCrawlers to prefix_wfCrawlers;
rename table wp_wfFileMods to prefix_wfFileMods;
rename table wp_wfHits to prefix_wfHits;
rename table wp_wfHoover to prefix_wfHoover;
rename table wp_wfIssues to prefix_wfIssues;
rename table wp_wfLeechers to prefix_wfLeechers;
rename table wp_wfLockedOut to prefix_wfLockedOut;
rename table wp_wfLocs to prefix_wfLocs;
rename table wp_wfLogins to prefix_wfLogins;
rename table wp_wfNet404s to prefix_wfNet404s;
rename table wp_wfReverseCache to prefix_wfReverseCache;
rename table wp_wfScanners to prefix_wfScanners;
rename table wp_wfStatus to prefix_wfStatus;
rename table wp_wfThrottleLog to prefix_wfThrottleLog;
rename table wp_wfVulnScanners to prefix_wfVulnScanners;

update prefix_usermeta set meta_key = REPLACE(meta_key,'wp_','prefix_');
update prefix_options SET option_name = 'prefix_user_roles' where option_name = 'wp_user_roles';

Modified wp-config.php to use the new prefix:

// $table_prefix  = 'wp_';
$table_prefix  = 'prefix_';

More to tweak, but this is a start!

Reverse Proxying WebSockets to An MQTT Server

If you are trying to reverse proxy OpenHab – that’s over here. This post is about maintaining your own private MQTT server and making it accessible through a reverse proxy.

We want to be able to update our presence automatically (without publishing our location information to the Internet). Scott found a program called OwnTracks that uses an MQTT server – and there’s an MQTT binding from OpenHab that should be able to read in the updates.

We didn’t want to publish our home automation server to the Internet, but we do want to send updates from the cellular data network when we leave home. To accomplish this, I set up a reverse proxy on our Apache server.

The first step is to get an MQTT server up and working — we Installed a mosquitto package from Fedora’s dnf repository

Once it is installed, create a directory for the persistence file & chown the folder to mosquitto uid

Generate a bunch of certs using the ot-tools (git clone https://github.com/owntracks/tools.git). I edited the generate-CA.sh file in the ot-tools/tools/TLS folder prior to running the script. It will more or less work as-is, but modifying the organisation names makes a cert with your name on it. Not that anyone will notice. Or care 🙂 Modifying the IPLIST and HOSTLIST, on the other hand, will get you a cert that actually matches your hostname — which isn’t a problem for something that doesn’t verify host name information, but saves trouble if you get your hostnames to match up.
IPLIST & HOSTLIST
CA_ORG and CA_DN

Then use generate-CA.sh to generate a CA cert & a server cert. Copy these files into /etc/mosquitto/

Edit the config (/etc/mosquitto/mosquitto.conf) – LMGTFY to find settings you want. Specify a location for the persistence file, password file, and add in the websockets listeners (& ssl certs for the secure one)
persistence_file /var/lib/mosquitto/mosquitto.db

password_file /etc/mosquitto/passwd

listener 9001
protocol websockets

listener 9002
protocol websockets
cafile /etc/mosquitto/ca.crt
certfile /etc/mosquitto/mosquittohost.rushworth.us.crt
keyfile /etc/mosquitto/mosquittohost.rushworth.us.key

Add some users
/usr/bin/mosquitto_passwd /etc/mosquitto/passwd WhateverUID

Start mosquitto
mosquitto -c /etc/mosquitto/mosquitto.conf

Monitor mosquitto for the owntracks ‘stuff’
mosquitto_sub -h mosquittohost.rushworth.us -p 1883 -v -t ‘owntracks/#’ -u WhateverUID -P PWDHereToo

Setting up the reverse proxy
The big sticking point I had was that the Apache WebSockets reverse proxy has a problem (https://bz.apache.org/bugzilla/show_bug.cgi?id=55320) which is marked as closed. Fedora has 2.4.23, so I expected it was sorted. However using tshark to capture the traffic showed that the relayed traffic is still being send as clear.

Downloaded the exact same rev from Apache’s web site and checked the mod_proxy_wstunnel.c file for the changes in the bug report and found they were indeed committed. In spite of the fact I *had* 2.4.23, I decided to build it and see if the mod_proxy_wstunnel.so was different.

Make sure you have all the devel libraries (openssl-devel for me … run the config line and it’ll tell you whatever else you need)

Get apr and apr-util from Apache & store to ./srclib then gunzip & untar them. Rename the version-specific folders to just apr and apr-util

Once you have everything, configure and make
./configure –prefix=/usr/local/apache –with-included-apr –enable-alias=shared –enable-authz_host=shared –enable-authz_user=shared –enable-deflate=shared –enable-negotiation=shared –enable-proxy=shared –enable-ssl=shared –enable-reqtimeout=shared –enable-status=shared –enable-auth_basic=shared –enable-dir=shared –enable-authn_file=shared –enable-autoindex=shared –enable-env=shared –enable-php5=shared –enable-authz_default=shared –enable-cgi=shared –enable-setenvif=shared –enable-authz_groupfile=shared –enable-mime=shared –enable-proxy_http=shared –enable-proxy_wstunnel=shared

Rename your mod_proxy_wstunnel.so to something like mod_proxy_wstunnel.so.bak and the grab mod_proxy_wstunnel.so that just got built.

Grab the CA public key & the server public and private keys that were generated earlier & place them whereever you store your SSL certs on your Apache server

Create a new site config for this reverse proxy – SSL doesn’t do host headers so you need a unique port. Clear text you can use a host header. Don’t forget to add listen’s to your httpd.conf and ssl.conf files!

ProxyRequests Off
<VirtualHost #.#.#.#:##>
ServerName mosquitto.rushworth.us
ServerAlias mosquitto
DocumentRoot “/var/www/vhtml/mosquitto”

SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
SetEnv proxy-initial-not-pooled
SetEnv proxy-initial-not-pooled 1

ProxyPreserveHost On
ProxyTimeOut    1800

ProxyPass               /       ws://mosquittohost.rushworth.us:9001/
ProxyPassReverse        /       ws://mosquittohost.rushworth.us:9001/
</VirtualHost>

<VirtualHost #.#.#.#:##>
ServerName mosquitto.rushworth.us
ServerAlias mosquitto
DocumentRoot “/var/www/vhtml/mosquitto”

SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
SetEnv proxy-initial-not-pooled
SetEnv proxy-initial-not-pooled 1

ProxyPreserveHost On
ProxyTimeOut    1800

SSLEngine On
SSLProxyEngine On
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLCertificateFile /etc/httpd/conf/ssl/mosquittohost.rushworth.us.crt        # These are the public and private key components
SSLCertificateKeyFile /etc/httpd/conf/ssl/mosquittohost.rushworth.us.key        #     generated from generate-CA.sh earlier.
SSLCertificateChainFile /etc/httpd/conf/ssl/ca.crt                # This is the public key of the CA generated by generate-CA.sh

ProxyPass               /       wss://mosquittohost.rushworth.us:9002/
ProxyPassReverse        /       wss://mosquittohost.rushworth.us:9002/
</VirtualHost>

Reload apache. Create a DNS hostname internally and externally to direct the hostname to your reverse proxy server.

Configure the client — generate a key for yourself & merge it into a p12 file (make sure your ca cert files are still in the directory – if you *moved* them into /etc/mosquitto … copy them back:
sh generate-CA.sh client lisa
openssl pkcs12 -export -in lisa.crt -inkey lisa.key -name “Lisa’s key” -out lisa.p12
You’ll need to supply a password for the p12 file.

Put the ca.crt (*public* key) file and your p12 file somewhere on your phone (or Google Drive).

Client config – Install Owntracks from Play Store
Preferences – Connection
Mode:    Private MQTT
Host:    hostname & port used in your **SSL** config. Select use WebSockets
Identification:    uid & password created above. Device ID is used as part of the MQTT path (i.e. my lisa device is /owntracks/userid/lisa). Tracker ID is within the data itself
Security:    Use TLS, CA certificate is the ca.crt created above. Client cert is the p12 file – you’ll need to enter the same password used to create the file

If it isn’t working, turn off TLS & change the port to your clear text port. This will allow you to isolate an SSL-specific problem or a more general service issue. Once you know everything is working, you can drop the clear text reverse proxy component.

Voila – reverse proxied WebSockets over to Mosquitto for OwnTracks.

Serving Custom Error Pages From Apache

At work, we are in the process of retiring an old password management web site. We want to direct users to the new site, and I don’t particularly want to handle each possible entry point an individual may have bookmarked. It seemed a lot quicker and easier to just move everything out of the directory and throw up a custom 404 page.

I am certain that I’ve used just “ErrorDocument ### /file.xtn” in Apache configurations to serve custom error pages, but when I set this up in our staging environment … I got the generic 404. Three days of Googling and reading Apache documentation later, and I have a configuration that actually serves a custom page when error 404 is encountered:

        ErrorDocument 404 /customized-404.html
        <Files "customized-404.html">
        <If "-z %{ENV:REDIRECT_STATUS}">
            RedirectMatch 404 ^/customized-404.html$

Voila, a pretty page that doesn’t in any way indicate 404 / not found / etc but rather says “hey, this web site is being retired. please go over yonder to manage your password.”.

Kerberos Authentication and LDAP Authorization In Apache

I’ve been authenticating users of Apache web sites against Active Directory using Kerberos for some time now. Installed krb5-workstation and mod_auth_kerb, configured /etc/krb5.conf for my specific domain, and added some config to the Directory section of the Apache config. Great if you just require valid-user (or require valid-user and then turn around and do some authorization within your web code using something like php_auth_user). Not so great, though, for restricting access to the site outside of web code. And I really didn’t want to code in an authorization function when my web server should be able to do that for me.

I FINALLY got kerberos authentication working in Apache with an LDAP authorization component. Turns out the  mod_auth_kerb version 5.1 that was available from the Yum repository is terribly buggy  – like not usable in this instance buggy. KrbLocalUserMapping did not consistently remove the realm component. I’d hit a site and it would know who I am, click a link and come across as me@REALM.TLD and get access denied errors, click refresh and get in because it knew I was me again. Or not. More than 50% failure rate.I built the 5.4 version from http://modauthkerb.sourceforge.net/ and haven’t had a problem since.

I’m authenticating to Active Directory using the Kerberos module then authorizing against a group housed in an external LDAP directory. You can totally point your LDAP config toward Active Directory & use AD groups instead:

AuthType Kerberos
AuthName “Kerberos AD Test”
KrbAuthoritative off
KrbMethodNegotiate on
KrbMethodK5Passwd on
KrbServiceName HTTP/this.isyour.url.tld@EXAMPLE.COM
KrbAuthRealms EXAMPLE.COM
KrbLocalUserMapping On
Krb5Keytab /path/to/keytabs/keytab.file

AuthBasicAuthoritative On
AuthBasicProvider ldap
AuthLDAPURL “ldaps://ldap.example.com/o=BaseDN?uid?sub?(&(cn=*))”
AuthLDAPBindDN “YOUR SERVICE ACCOUNT HERE”
AuthLDAPBindPassword “YOUR BIND PWD HERE”

AuthLDAPGroupAttribute uniqueMember
AuthLDAPGroupAttributeIsDN on
require ldap-group cn=Website Test,ou=groups,o=BaseDN

 

WooHoo! I hit the site from my domain-member computer, it knows I am LisaR. It then turns around and finds an LDAP user matching uid=LisaR and grabs the user’s fully qualified DN (because AuthLDAPGroupAttributesIsDN is ‘on’ here … if you are using just uids in your member list, that would be off). It then verifies that the fully qualified DN is a member of the Website Test group.

Now I’m trying to figure out how to let the user log in without supplying a realm (not everyone’s in the domain … and they need to be able to log in too. Works fine right now, provided they input their username as uid@REALM.TLD).