Skip to main content

PBX Manager URL Masking

Posted by devand_cloud on Fri, 09/28/2012

My company would like to be able to mask the URL of the PBX Manager. What I mean by this is that typically when you are using it, the URL will be something like http://www.somesite.com:10000/asterisk/edit_user_vm.cgi?usr=100 whereas we would like it to only display the http://www.somesite.com portion of the URL.

I'm fairly certain this is possible, but I'm not 100% sure how to do it. I was hoping someone here with some more experience might be able to shed some light on the subject.

Thanks!

Devand MacLean
Cloud-Phone Inc.


Submitted by devand_cloud on Sun, 09/30/2012 Permalink

We had tried using frames previously, but were encountering an issue where when the user would try to log in it would not spit them out an error but it would not let them through. It would just appear to refresh the page, and would not let them log in. Do you know why that might happen?

I also tried creating a symlink between /usr/libexec/webmin/asterisk/ and /usr/libexec/webmin/test/ and browsed to https://www.somesite.com:10000/test/ and it said that the user root was not permitted to use that webmin module. After enabling it inside of the root user's webmin user, I tried again, and it said that our license was not verified. When I attempted to reinstall our license under /test/ it did not accomplish anything, it still said that our license was not verified.

I have been clawing through using apache rewrite rules for the past few days. They are incredibly cryptic, but I'm starting to wrap my head around them. Do you think you might be able to point me in the right direction as to how I could accomplish this with rewriterules?

Thank you!

Submitted by devand_cloud on Sun, 09/30/2012 Permalink

Further to the comment above, what I have tried is adding the following to the end of the file /etc/httpd/conf/httpd.conf

RewriteEngine on
RewriteRule asterisk/(.*)$ /phones/$1 [PT,L]

After restarting the httpd service (/etc/init.d/httpd restart) and browsing to the page https://www.somesite.com:10000/asterisk/index.cgi it still displays the /asterisk/ portion in the browser as opposed to /phones/

I used the htaccess tester at http://htaccess.madewithlove.be/ to validate my ReweriteRule, and it says that with that input URL it should output https://www.somesite.com:10000/phones/index.cgi but it clearly is not. I am obviously missing something, likely something very basic and obvious.

Any ideas?

Submitted by devand_cloud on Fri, 10/05/2012 Permalink

So, I did end up getting it to work. Sort of. I am able to make it so that you can browse to www.somesite.com/pbx/ and it displays the content from www.somesite.com:10000/asterisk/

I used mod_proxy and 2 Apache RewriteRules. I have pasted my additions to the httpd.conf file below

ProxyPass / http://localhost:10000/
ProxyPassReverse / http://localhost:10000/
RewriteEngine on
RewriteRule ^/pbx/(.*)$ /asterisk/$1 [L,PT]
RewriteRule ^/asterisk/(.*)$ /pbx/$1 [R=301,NS,N]

What it does, is if you browse to /asterisk/ (which is where the login page sends you by default after logging in), it redirects you to /pbx/, and then subsequently when you browse to /pbx/, it rewrites it as /asterisk/ to the server. On the last line, the NS option is critical. It tells apache not to follow this rule for any internal subrequests.

The one thing I am not able to do is make it run over https://. In fact, I am not able to make the Apache server serve -anything- over https on this box.

Any suggestions?

Submitted by devand_cloud on Mon, 10/15/2012 Permalink

Well, that part of it might make sense, but I still can't even serve something as simple as https://www.somesite.com/asdf.txt without mod_rewrite or mod_proxy doing anything to it.

The weird thing is that I -am- able to do this with other servers that I have deployed, and I can't seem to find any differences in the two configs.

What I think I could do to work around this (if I could get the server to serve via https://), would be to proxy from the DocumentRoot of https://www.somesite.com/ to http://localhost:10000 and just make it so that the only whitelisted IP is 127.0.0.1

Would that work? And any ideas why I can't serve files over https://? Might it be because I have the "ProxyRequests On" and/or "RewriteEngine On" directives set in my httpd.conf?

Also, from the little I have read on the SSLProxyEngine directive, shouldn't it be possible to proxy between the DocumentRoot of https://www.somesite.com/ and https://localhost:10000?

Submitted by eeman on Tue, 10/16/2012 Permalink

hmm thats an iteresting idea..

lock down webmin to only localhost, turn off encryption, then proxy the whole thing from your SSL engine of apache? Let me know if it works, the logic seems sound.

Submitted by devand_cloud on Mon, 10/22/2012 Permalink

So, I've got it working quite nicely actually. The following directives need to be added (assuming you have your SSL all properly configured). Note, that you can replace "/pbx/" with "/anythingelse/" and it will change the new trailing directory for the pbx manager URL.

I've also added a little to the end of httpd.conf that redirets any requests to http:// to the same URL using https://

Let me know what you think! :)

==// /etc/httpd/conf.d/ssl.conf

RewriteEngine on
RewriteRule ^/pbx/(.*)$ /asterisk/$1 [L,PT]
RewriteRule ^/asterisk/(.*)$ /pbx/$1 [R=301,NS,N]

==// /etc/httpd/conf/httpd.conf

ProxyPass / http://localhost:10000/
ProxyPassReverse / http://localhost:10000/
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteCond %{REMOTE_ADDR} !=^127.0.0.1$
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L,NS]

==// /etc/webmin/miniserv.conf

ssl=0
allow=127.0.0.1

==// /etc.webmin/config

referer=1

Submitted by eeman on Mon, 10/22/2012 Permalink

I'm a results-oriented guy... if its working then I think thats pretty awesome. just curious, where you trying to obsfuscate the fact that you were running asterisk? Its going to show up in the sip messages if someone were to take a real look at the packets.

Submitted by devand_cloud on Mon, 10/22/2012 Permalink

Yes, we are trying to mask the back-end technology. Anyone who knows enough could still figure it out if they tried hard enough for sure, but we were more interested in the average user's experience. The majority if not all of our client base doesn't know enough about SIP (or care enough) to sniff their voice traffic for that information. If they did, they probably wouldn't need our service. ;)