Gospel. Culture. Technology. Music.

Tag: Apache

Log4J Examples in the Wild

Using my honeypot server, I’ve been able to capture some examples of Log4J attempts against it. What this is showing is that the ModSecurity rules in place, at least in this subset of anecdotal examples, are able to block the various attempts, up to this point.

Setting up ModSecurity with NGINX and Log4J rules: https://davidwesterfield.net/2021/12/log4j-and-modsecurity/

Setting up ModSecurity with Apache and Log4J rules: https://davidwesterfield.net/2021/12/log4j-apache-and-modsecurity/

Log4J, Apache and ModSecurity

(I’ll be updating this post as more rules are available to stop new vulnerabilities.)

Credit to Christian Folini at coreruleset.org for providing the rule.

A major vulnerability has been discovered in Java web apps basic logging function called Log4J/Log4Shell. The best remedy for this is to update Log4j itself, or update the web app platform running Log4j with a newer version provided by the vendor. But that may take a while in many instances to fully implement.

Hadoop Big Data Twitter Sentiment Analysis

This is fascinating to watch:

ModSecurity and NGINX Compilation Error in Ubuntu

I had a failure recently when trying to compile ModSecurity as a standalone module for use within NGINX that seemed to be pretty consistent with what others were experiencing, from the limited number of sites that seemed to have information on this particular problem. I knew it was possible to set this up, but I also knew I was missing something.

After scanning the internet for a solution and getting some pointers from Ryan Barnett at Trustwave’s SpiderLabs, I finally found what I was looking for to get this to work.

I went through this http://www.modsecurity.org/projects/modsecurity/nginx/ and kept receiving this error:

configure: looking for Apache module support via DSO through APXS
configure: error: couldn’t find APXS

… even after I went through and made sure I had all these prerequisites installed (thanks for pointing me here Ryan): https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Prerequisites.

So then I was stuck, until I just searched why anyone gets this error at all and discovered this: http://knowledge-republic.com/CRM/2981/ubuntu/ubuntu-missing-apxs-fo-compile-apache-module/

In addition to the prerequisites noted in the last link, you must install apache2-prefork-dev instead of, or in addition to, apache2-threaded-dev in order to utilize the APXS extension tool.

Once I did that, I compiled the module successfully and was able to continue on with the rest.

I’m still waiting for an easy-to-add ModSecurity module for NGINX that I can just pull down using apt-get. 😉

OpenVPN Sharing a TCP Port with SSL on NGINX and Apache?

I’m absolutely baffled there isn’t more information out there about this. It seems like web managers and techs would be all over this, but there’s barely any information out there on this. I had a hard time finding documentation on OpenVPN’s site itself!

As one guy stated here (the post where I finally understood how this works) it’s not really “sharing” the port per se, but OpenVPN is deciphering between HTTP/S traffic and OpenVPN traffic and then forwarding web traffic over to another port, defined below. That’s crucial to understand.

Before I start, I want to note this doesn’t have to be done on an SSL port, as I understand it. I’m just using that as an example because it seems to be the most logical way to make it work if this is your configuration (you know, an SSL VPN going to an SSL port).

It should also be noted in this configuration example that OpenVPN, using the port-share parameter, is actually doing the listening on TCP port 443 and acting as a proxy itself that forwards non-OpenVPN traffic to the NGINX SSL port which we’ll layout below. You cannot do this utilizing UDP, that I know of.

So here’s what you do.

1) Set your NGINX or Apache listening ports. Set your NGINX standard http port 80 and SSL listening port to something OTHER than 443 … so, for arguments’ sake, let’s set it to 4443.

So it would look like this for Apache and NGINX:

For Apache, in the main httpd.conf (Windows) or in ports.conf (Ubuntu/Linux):

Listen 4443

For NGINX, in /etc/nginx/sites-available/defaults:

server {
        listen   4443;

        location / {
                root  /web/etc/blah;

Once implemented, restart your respective service, Apache or NGINX.

2) Next, you’re going to set your OpenVPN server parameters. Set your listening port to 443 from its standard 1194 and add the port-share parameter to point to the Apache or NGINX port created above. The config should look as follows now:

port 443
port-share 4443
proto tcp

OpenVPN will now be ready to accept connections over 443 and route the appropriate https/SSL traffic to Apache or NGINX.

3) Change your firewall settings. Leave your TCP port 80 rule pointing directly to Apache or NGINX. Then point your SSL rule to TCP port 443 running on your OpenVPN server. OpenVPN will now catch the traffic directed at it and decipher between OpenVPN traffic and HTTPS traffic.

4) Change the configuration in your OpenVPN clients. Point your OpenVPN clients to TCP port 443 instead of the port you were using before:

remote domain.name.com 443


remote [IP ADDRESS] 443

Hope it works. Cheers!

PHP Code for Remote IP Address Detection on a Web Page

I wrote this code today to return the IP address of a remote host when either the host hits the web server directly or accesses it through a web proxy (as in my situation). Thought someone might find it useful.

function writeIPAddress() {
if (isset($_SERVER[‘HTTP_X_FORWARDED_FOR’]) == ”) {

else {

Then, if you want to return the IP address as text on the page, simply do this:

echo writeIPAddress();

In addition, if you want to return the reverse DNS address of the IP, do this:

echo @gethostbyaddr(writeIPAddress());

Apache Web Server Setup as a Reverse Web Proxy

Well, I’ve finally changed up my website architecture using Apache 2.0.55 to where it essentially looks like this: client browser connects to HTTP port 80 (or HTTPS port 443) through the internet to the outside of my firewall > the firewall NATs the connection to the web proxy ports (undisclosed) > the web proxy connects to one of several internal web servers I’ve specified it to connect to > the queried web server then renders the page back through the web proxy and then back to the client through the internet. Basically, with this new design in place, I can offload SSL processes to the web proxy (separate server) and it will take the encryption load off of my web servers (thus making it much more efficient on processing). I can also proxy any internal network appliance web interface (such as SHOUTCast servers, webcam servers, wireless access point servers, etc.) through the web proxy, and on top of that I can encrypt it all using AES-256 (when using Firefox), as well as password out specific sites at the Apache web server level. Some really sweet technology …

Powered by WordPress & Theme by Anders Norén