The issue with that is Guacamole provides no method for
authenticating against NIS so that does me no good. I don't want to
change 20 machines over from NIS to LDAP just to get this to work. Many
of the clients are not terribly Linux savvy, adding an additional layer
is NOT beneficial from a business standpoint. It would just frustrate
users and drive them elsewhere.
I am a one person company maintaining 500 clients, I don't want to
have to maintain multiple authentication databases, there just are not
enough hours in the day.
I don't care what program does the authentication as long as it can
work from the existing database and the user doesn't have to remember
more login tokens because frankly some of them have problems just
remembering a password. This is not the only way users connect. They
also connect via rdp, vnc, ssh, and x2go, but by all those methods, the
host received the IP address of the originating machine and thus
fail2ban can work with them.\
If I knew Java it probably would not be a big deal to write an
authentication interface that talks to pwauth the same way Apache does,
but I don't.
If I even had a way to attach the guacamole session to the login
session of the host so that when the host fails I could go back and find
what IP address guacamole received and then write a fail2ban jail for
that it would be a pain but potentially doable. Then again in the past
when there was no auth it didn't materialize as a huge issue even though
it could have been perhaps because it was just unusual enough that the
script kiddies didn't have prebuilt tools or perhaps too slow to make it
practical. But if it ever becomes sufficiently popular, someone will
write the tools.
Frustrating, so close but so far away. If apache could have done
the auth, that would have been great because IT can use the same NIS
database AND it gets the connecting IP so it can log the failed logins.
I do not understand why the authentication works with web apps it serves
directly but not with a proxy.
On 8/6/23 00:16, Michael Jumper wrote:
The headers that you've been working with here will only affect
whether Tomcat and Guacamole see you as coming from your actual IP
address instead of the address of the proxy in front of Tomcat.
The destination remote desktop will always see the connecting client
address as that of the Guacamole server. If you wish to prevent brute
force auth attempts, the way to do that would be to configure fail2ban
on the *Guacamole* server such that repeated failing attempts to
authenticate with *Guacamole* will be blocked at the firewall level.
One of the primary benefits of deploying Guacamole in front of a set
of servers is to leverage Guacamole as a security layer in front of
those servers. I would not recommend instead relying on the
destination servers themselves to provide this. The authentication
systems of those servers should only come into play after Guacamole
has established that the user attempting to connect is authorized.
Ideally, the destination servers would be configured to accept
connections only from the Guacamole server.
- Mike
On 8/5/2023 7:00 PM, Robert Dinse wrote:
I apologize, someone replied to this and I accidentally deleted
your reply, but you asked what IP was tomcat logging, and if I'm
looking in the right place, in catalina.out:
catalina.out:[2023-08-04 17:35:02] [info] 17:35:02.572
[http-nio-8080-exec-8] INFO o.a.g.event.EventLoggingListener - User
"public" (authenticated by "default") successfully authenticated from
[50.251.249.49, 127.0.0.1]
In localhost_access_log.2023-08-04.txt.gz:
localhost_access_log.2023-08-04.txt.
These are both in /var/log/tomcat9.
50.251.249.49 is actually the IP address I am originating
from but when I connect to a host, the host sees the connection
coming from 204.122.16.20 which is that of the web server. I
personally do not understand how it could possibly pass the
originating IP address to the host it's connecting to since it is
originating the connection from the web server.
On 8/4/23 18:12, Robert Dinse wrote
I still haven't gotten Apache external authentication to work
properly. I did manage to get mod_authnz_external to peacefully
co-exist with mod_suphp, the secret was to compile
mod_authnz_external and dynamically load it rather than compiling it
statically into httpd, which would have been my preference. But,
for some reason it will work with a static web page or PHP
application, but not a proxy, but that's another issue.
For now I am just trying to get the Apache to pass the IP of
the connecting customer through to Tomcat, have it pass it through
to the guacamole process so that when a user connects to a host, the
host sees the IP the user is originating from and not the IP of the
web server. I was referred to this webpage for instructions:
https://guacamole.apache.org/doc/gug/reverse-proxy.html#setting-up-the-remote-ip-valve
And so I've setup the <host> section in Tomcat9 as follows:
The website shows to add this valve to the <host> section of
the server.xml file:
<ValveclassName="org.apache.catalina.valves.RemoteIpValve"
internalProxies="127.0.0.1"
remoteIpHeader="x-forwarded-for"
remoteIpProxiesHeader="x-forwarded-by"
protocolHeader="x-forwarded-proto"/> Here is what the <host> section
of my servers.xml looks like: <Host name="localhost"
appBase="webapps" unpackWARs="true" autoDeploy="true"> <!--
SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html --> <!-- <Valve
className="org.apache.catalina.authenticator.SingleSignOn" /> -->
<!-- Access log processes all example. Documentation at:
/docs/config/valve.html Note: The pattern used is equivalent to
using pattern="common" --> <Valve
className="org.apache.catalina.valves.AccessLogValve" directory="
logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u
%t "%r" %s %b" /> <Valve
className="org.apache.catalina.valves.RemoteIpValve"
internalProxies="127.0.0.1" remoteIpHeader="x-forwarded-for"
remoteIpProxiesHeader="x-forwarded-by"
protocolHeader="x-forwarded-proto" /> </Host> Note that guacamole is
the only application I have running under tomcat9. I have another
Java application running (yacy) but it is not containerized. Then it
shows for the Apache:
<Location/guacamole/> Orderallow,deny Allowfromall
ProxyPasshttp://HOSTNAME:8080/guacamole/flushpackets=on
ProxyPassReversehttp://HOSTNAME:8080/guacamole/ </Location> I
already had this except for HOSTNAME I had "localhost", then it also
shows proxying guacamole with websocket, and says it will reduce
network latency. Well already it was fast enough to watch videos on
a proxy connection, but why not, so I added:
<Location/new-path/websocket-tunnel> Orderallow,deny
Allowfromall
ProxyPassws://localhost:8080/guacamole/websocket-tunnel
ProxyPassReversews://localhost:8080/guacamole/websocket-tunnel
</Location>
Like this, if I go to the URL and login to a host, the IP the
hosts sees is that of the web server and not the IP I am originating
from.
With respect authentication, if I wrap these proxy statements
with access statements I get a 404 error with '/#/' as the URL
If I remove the proxy statements and substitute some simple
HTML it works as expected, prompts for login and password, and if
correct displays the code.
If I type the wrong username and password, it rejects the
attempt.
This was basically the auth code I was using:
SetExternalAuthMethod pwauth pipe
AddExternalAuth pwauth /usr/sbin/pwauth
AuthType Basic
AuthName "Authentication Required"
AuthExternal pwauth
Require valid-user
AuthExternal authnz_external
AuthBasicProvider external
If I can get it to pass IP correctly then auth isn't required
because fail2ban will pick up and ban offending IPs trying to
brute-force passwords so right now that is my focus.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
