in that case I would simply drop a apache reverse proxypass virtualhost in /etc/httpd/conf.d/myproxyCannonNeeded.conf
Hi @stephdl,
Thank you for your reply.
On my main server, the one connected directly to the internet that redirects to LOCAL, already contains entries for each redirection in /etc/httpd/conf.d/virtualhosts.conf
.
On the main server, do you mean:
- Create a file that comes alphabetically before
virtualhosts.conf
- Copy the redirection sections from
virtualhosts.conf
to the new created file. - In the new created file, add the nocanon directive parameter at the end of the
ProxyPass
lines.
Correct me if I’m wrong:
- When the
httpd
daemon will look for the redirectedport/ServerName
, it will take the directives from the new file as it comes beforevirtualhosts.conf
?
Michel-André
yes it should work, cp and paste in a new configuration file your proxy and remove the old one of the cockpit UI
I do not know, you have to provide a full valid httpd configuration in your new configuration file, if needed then yes
Salut @stephdl,
I redirect 8008 and 8448 ports and for them there are no entries in /etc/httpd/conf.d/virtualhosts.conf
.
I think that I should not delete them in Cockpit UI.
Michel-André
no idea sorry I do not understand
Open a new topic and display your full proxypass configuration and what you want to modify
Hi @stephdl,
- I started LOCAL VM.
- On main server, I copied
/etc/httpd/conf.d/virtualhosts.conf
to/etc/httpd/conf.d/u_nocanon.conf
. - I kept the original
virtualhosts.conf
as is. - In
u_nocanon.conf
I deleted all sections not related to the redirections.
I addednocanon
afterretry=30
in all sections. - On main server, I restarted
httpd
. - On LOCAL VM, I restarted
httpd
andmatrix-synapse.
- I logged into my LOCAL Chat server with Firefox.
- I logged into matrix.org with Chrome.
- On my LOCAL Chat server, I created an encrypted public Room.
- On my connection to matrix.org, I Search for the created Room on LOCAL Chat server => Join.
- My connection to matrix.org joined the Room on LOCAL Chat server without problem (which is a Première).
- Exchange a few chats between my Chat and matrix.org => both were fast to display the exchanges.
CONCLUSION:
It is the web redirections that canonicalise (replacing the characters) %40
, the %3A
, etc…
QUESTION:
Is it possible to do the same with this directive parameter as you did with X-Forwarded-Proto
?
Might be quite tricky as it is a parameter and not a full directive… But since you are adding max=3
and retry=30
parameters only in redirection sections, can you also add nocanon
?
Michel-André
Hello michel, yes we added new feature to proxypass, but I am not sure for the nocanon
, because it might be risky as the apache documentation said, but you are right to ask for it because developers sometimes are in their ivory tower.
We added for now the X-Forwarded-Proto
and soon the AllowEncodedSlashes NoDecode
but for now without UI checkbox. Maybe with UI we could add another one to enable nocanon
because I know nocanon
works with AllowEncodedSlashes NoDecode
.
In my dream night I would like to change a bit the UI and allow more complex proxypass feature, for now we just allow to do a reverse proxy from /
to another http URL, and I would like to be able to this in the UI if needed
<VirtualHost *:443>
ServerName collabora.domain.com
SSLEngine on
# Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode
# keep the host
ProxyPreserveHost On
# static html, js, images, etc. served from loolwsd
# loleaflet is the client part of LibreOffice Online
ProxyPass /loleaflet http://127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse /loleaflet http://127.0.0.1:9980/loleaflet
# WOPI discovery URL
ProxyPass /hosting/discovery http://127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse /hosting/discovery http://127.0.0.1:9980/hosting/discovery
# Main websocket
ProxyPassMatch "/lool/(.*)/ws$" ws://127.0.0.1:9980/lool/$1/ws nocanon
# Admin Console websocket
ProxyPass /lool/adminws ws://127.0.0.1:9980/lool/adminws
# Download as, Fullscreen presentation and Image upload operations
ProxyPass /lool http://127.0.0.1:9980/lool
ProxyPassReverse /lool http://127.0.0.1:9980/lool
# Endpoint with information about availability of various features
ProxyPass /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities retry=0
ProxyPassReverse /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities
</VirtualHost>
a textarea should be able to help us to make this
/loleaflet http://127.0.0.1:9980/loleaflet
/hosting/discovery http://127.0.0.1:9980/hosting/discovery
/lool http://127.0.0.1:9980/lool
/hosting/capabilities http://127.0.0.1:9980/hosting/capabilities
Salut @stephdl
I googled for “URL-based attacks” and it is mainly for mail Phishing.
With ClamAV, Fail2ban, etc, I think the dangerousity is quite low. Also, on all stations, I have Avast and Spybot.
But mainly as I am using NethServer, I think it is almost irrelevant.
Michel-André
I think it is more a security concern in the application backend because the url are given to the proxy without more verifications. At least this is what the apache documentation says
I agree: adding always nocanon
is a bad security practice.
Sorry but I disagree on this. The UI should focus on user task, not on exposing all possible configurations. If the user needs more control on a specific proxy pass there are 2 alternatives:
- add a template-custom (hard)
- drop a configuration file inside
/etc/http/conf.d
(easy)
I’m always against overloading the UI with complex and too-specific features.
Since the beginning NethServer 7 attempts to integrate with the upstream Apache configuration in a seamless way: it should be easy to add a third-party webapp integration by just following its Apache guidelines for CentOS.
That means, to integrate a third-party webapp with a complex setup (like Collabora):
- drop the .conf file (copied from the guidelines) in /etc/httpd/conf.d/
- add it to custom backup inclusions: /etc/backup-config.d/custom.include
If your dream becomes true and we overload the UI, the procedure for the sysadmin becomes
- fully understand the Apache app guidelines
- fully understand the complex UI (uh, what does this option actually do?)
- logically map the above knowledges
- configure the complex UI
And the procedure for the developer becomes a nightmare
- fully understand every Apache feature
- implement the UI in a coherent way
- document what it does, so experts and non-experts can understand
- give more and more details when support requests come
- …
Hi @giacomo
My problem was with Redirections.
Template-custom:
Which one for the Redirection inside virtualhosts.conf
?
You have to find the file dealing with retry=30
then add nocanon
.
This paramenter will then affect all new virtualhost
creations and maybe it’s not what it’s wanted.
With a file in conf.d
:
This is not easy with Redirection. You have to copy /etc/httpd/conf.d/virtualhosts.conf
to /etc/httpd/conf.d/u_nocanon.conf
, delete some sections, then add nocanon and restart httpd
. This will affect only the already created redirections.
I would like to know exactly what is the risk here with nocanon
.
The LOCAL server will receive the same exact packet as the NS proxy server and will process it the same way. If it’s dangerous for the LOCAL server, it’s also as dangerous for the proxy server.
If it’s the destination app, then it’s the same app running on the LOCAL server.
The problem with phishing is between the chair and the mouse, not with the OS…
If it’s on the UI, then it is possible to add “Security risk” beside the check box.
Also, there is the help button which can display an explaination.
It’s not an easy task but it should be possible to do something.
Michel-André
hello michel-andré, please read this
you will see that you have a risk to use nocanon and the developers of this project are aware of that
Salut @stephdl,
It doesn’t explain why, only adding:
Sonatype server products do not rely on reverse proxies to filter out suspect URLs containing path info with encoded values, so it is OK to use “noncanon” with Nexus Repository Manager.
It’s nocanon
not 'noncanon"… and what is that “Nexus Repository Manager” ?
The real threat is nowhere to be found.
If the Matrix-Synapse FEDERATION is using it, there should be a reason and maybe they check it the same way as Sonatype…
Michel-André
It is a typo…read the apache fragment
I retested matrix synapse successfully with reverse proxy and created /etc/httpd/conf.d/a_synapse.conf
on the “main” Nethserver to reverse proxy both, port 443 and 8448 with nocanon option to the local VM (1.2.3.4 in this example). You also need to open port 8448 on the “Main” Nethserver by creating a service “synapse” with TCP port 8448 and access for red and green. This way no reverse proxy in cockpit is needed.
/etc/httpd/conf.d/a_synapse.conf
:
<VirtualHost *:443>
SSLEngine on
ServerName matrix.yourdomain.org
AllowEncodedSlashes NoDecode
ProxyPass /_matrix https://1.2.3.4/_matrix nocanon
ProxyPassReverse /_matrix https://1.2.3.4/_matrix
</VirtualHost>
Listen 8448
<VirtualHost *:8448>
SSLEngine on
AllowEncodedSlashes NoDecode
ProxyPass /_matrix https://1.2.3.4/_matrix nocanon
ProxyPassReverse /_matrix https://1.2.3.4/_matrix
</VirtualHost>
Hi @mrmarkuz,
Amazing solution!
Questions:
- “Main” server is the server connected directly to the internet and used as a gateway byLOCAL network?
- "local VM’ is a VM running on some hardware on the LOCAL network and not on the “Main” server?
- “yourdomain.org” is not the domain name of the “Main” server ?
- No DNS name or Alias of “local VM” on “Main” server?
- No port redirection on “Main” server to “local VM” port?
- “1.2.3.4” is a private IP on the LOCAL network and not a public one?
- What about port 8008 which is suppose to be the default listening port for Matrix-Synapse, the
ProxyPass
line wil take care of it? - What about the TLS certificate related to “local VM”: none on ‘Main’ server, only one on the “local VM” ?
- Is there something on “Main” server for the email to “local VM”?
- What is the content of
.well-known
? - You restarted
httpd
on the “Main” server to clear its cache and read the newa_synapse.conf
file? - You created a Room on this LOCAL Chat and search for it from another one and it joined without problem?
I am really astonished at this amazing solution,
Michel-André
There’s a pfsense firewall in front, port forwarding to the “Main” NethServer but from there it’s a similar case.
Yes, in my case it’s a VMWare VM.
No, yourdomain.org
is the domain name of the “Main” server in my case. I think it’s not relevant in our case as we’re working with custom named reverse proxies.
As it’s my test VM I have a local DNS entry for testserver.domain.local. I think it’s not needed because we use yourdomain.org
.
No port forwarding, just reverse proxy.
Yes, 1.2.3.4 is the private IP of the local VM, sorry for confusion…
Yes, it does, by reverse proxying traffic to the local VM.
No, I have a working LE cert on both but only the LE cert on the main server is used.
No.
It’s unchanged on both main server and local vm, acme-challenge only.
[root@server2 ~]# ls /var/www/html/.well-known/
acme-challenge
Yes, maybe reload would be enough too.
Yes, for searching/joining the room I needed to enter the full room name including domain but joining wasn’t an issue at all. Invitation worked too from and to the local VM.