Open-AudIT

The idea of substituting %host_url% automatically is great! There is a situation when it fails, though: when openaudit runs on a server that sits behind a reverse proxy, the substituted host name is the internal name, not the externally visible one. Example:

externally visible openaudit URL:

http://server.mysite.com/openaudit/...

This server forwards all requests as a reverse proxy to:

http://openauditserver.internal.site/openaudit/...

which of course is only valid within the local domain.

In this case, %host_url% is not proxied back the way it should be. The downloaded vbs file will use the internal openaudit.internal.site host name instead of the external one.

...sadly I cant replicate the issue, because I dont have a reverse proxy setup, however I might be able to suggest a couple of workarounds.

1) Set up separate DNS A record to point to the correct location, or
2) Set the local proxy settings to "Do Not Proxy" for the "domain" server.mysite.com (this can probably be set modifying your proxy.pac file (if your proxy supports this) or wpad.dat if you use DHCP to fix the proxy settings... or domain policy ...or manually in the browser connection settings).

Hope this helps.

_________________
Andrew

[size=85]OA Server: Windows XP/ XAMPP, Mandriva/Apache, Ubuntu
Auditing: 300+ Wstns, 20+ Srvrs, Thin clients, Linux boxes, Routers, etc
OS's: Windows XP , W2K Srvr, W2K3 Srvr, W2K8, Vista, Windows 7, Linuxes (and a Mac at home)
LDAP: Active Directory[/size]

Thanks for the suggestions, but unfortunately neither will work. Both would (presumably) work for a forward proxy, but not for a reverse proxy.

A forward proxy is used for traffic FROM a private network TO the public Internet. "Do not proxy" means that certain sites are internal and should stay within the private network.

A reverse proxy is basically the reverse; it is used for traffic FROM the public Internet TO the private network - very similar to how you would punch holes into a firewall, except quite a bit more elaborate. In addition, a reverse proxy can analyze the URL and, based on the directory part of the URL, send the request to one of several internal servers. So "Do not proxy" is meaningless here; it would just mean "don't let traffic reach the open-audit server at all".

Similarly, a separate DNS A record breaks because there is not ONE server behind the proxy (it also breaks for various other reasons).

In my setup, I have several servers behind an external front-end server (the reverse proxy). The reverse proxy is facing the Internet.

If you visit http://myreverseproxy.mysite.com/openaudit, the reverse proxy will figure out (based on the directory /openaudit) that it needs to send the HTTP request on to http://openauditserver.mysite.local/openaudit.
If you visit http://myreverseproxy.mysite.com/webmail, the reverse proxy will figure out that it needs to send the HTTP request on to http://mailserver.mysite.local/webmail . And so on.

Theoretically, one could also create a similar reverse proxy to make http://www.mysite.com send all traffic to, say, http://www.cnn.com. That would obviously be pretty nefarious

Reverse proxying is used frequently in larger sites for load balancing, to organize the sites, for better security (the actual Web servers don't have to be exposed on the Internet at all), but it is also notoriously tricky. The reverse proxy needs to rewrite every single occurrence of a URL, all links, etc. Sites, conversely, should be written reverse-proxy-friendly. That is, URLs need to be structured in a way that the reverse proxy can actually find and replace it. That's where the %host_url% apparently breaks down; I'm not sure (yet) why the reverse proxy doesn't find it.

I'm not sure if the issue *can* be solved automatically by open-audit alone, but it would be nice if the URL could be made "visible" to the reverse proxy. I'll have to do further research before I can say what it would take to do that.

My research actually uncovered a second bug in the same area: the generated URL is always http:// (hardcoded) even if the server requires https.

Fortunately, Apache's mod_proxy will add a couple headers to the request that give you all the necessary information. It is possible that other reverse proxies use different headers, so this solution may not be universal:

HTTP_FRONT_END_HTTPS=On
HTTP_X_FORWARDED_FOR=192.168.15.1
HTTP_X_FORWARDED_HOST=external.mysite.com
HTTP_X_FORWARDED_SERVER=external.mysite.com

(standard header)
HTTP_HOST=internal.mysite.local

Currently, %host_url% relies on HTTP_HOST for the substitution and hardcodes http:// .

Instead, to make it work with the reverse proxy, first check if HTTP_X_FORWARDED_HOST is set. If so, use that in place of HTTP_HOST. Also use HTTP_FRONT_END_HTTPS to set https: instead of http: (I don't know off the top of my head how to detect SSL without a reverse proxy in between; I don't have that setup available to test with).

Oops. Of course these aren't actually HTTP headers, but rather the keys in the $_SERVER array.

And, by the way - I've been reporting a lot of bugs over the last couple of days, but I also want to express kudos; Open-AudIT is actually an awesome product. I was particularly impressed that setting up the LDAP logon took me all but five minutes - nothing else I ever installed was that quick to integrate!

[quote="kkeane"]... but I also want to express kudos; Open-AudIT is actually an awesome product. I was particularly impressed that setting up the LDAP logon took me all but five minutes - nothing else I ever installed was that quick to integrate!

_________________
Andrew

[size=85]OA Server: Windows XP/ XAMPP, Mandriva/Apache, Ubuntu
Auditing: 300+ Wstns, 20+ Srvrs, Thin clients, Linux boxes, Routers, etc
OS's: Windows XP , W2K Srvr, W2K3 Srvr, W2K8, Vista, Windows 7, Linuxes (and a Mac at home)
LDAP: Active Directory[/size]