Re: Apache verses Guacamole

2023-08-02 Thread Nick Couchman
Robert,
Sorry if you already answered this and I missed the answer, but did
you verify that you've configured the Remote IP Valve in Tomcat, as
documented in the Proxying chapter of the manual? This should give you
the correct iP in Guacamole:

https://guacamole.apache.org/doc/gug/reverse-proxy.html#setting-up-the-remote-ip-valve

-Nick

On Wed, Aug 2, 2023 at 4:32 AM Robert Dinse  wrote:
>
>
>   I have considered LDAP, just the scope of converting so many
> machines is more than a little intimidating for one person.  I do not
> have a staff, just me.
>
>   I am trying to create one of two scenarios:
>
>   1) A customer using guacamole can login to it with the same
> credentials he uses for servers, e-mail, x2go, vnc, etc.
>
>   2) A customer logs in via apache and bypasses authentication at
> guacamole.  In this case apache logs failures, and I realize tomcat can
> as well but I have a jail for apache and not for tomcat and I don't do
> well at creating regular expressions as interpreted by fail2ban which
> has a lot of it's own unique matching rules. I've done it successfully
> before but I'm getting old and would rather not go bald.
>
>   3) If neither of the above solutions can be made to work, then the
> customer goes straight into the host selection page but with the IP he
> is originating at, not the IP of the web server, so that failed logins
> are collected and repeat offending IPs blocked and really of the three
> this is the most convenient for the customer and the preferred one but
> since I don't know how to make tomcat pass through the originating IP
> it's problematic. If I could get this to work though it has some
> marketing advantage, as I could configure a virtual domain with a local
> non-routable IP address that the web server can talk to but that's it,
> and configure Ubuntu with a guest account (where nothing is saved after
> the session), the local address limiting the ability to get out on the
> net and use it for DOS attacks, etc.  I think it would be a cool
> marketing ploy.
>
> On 8/2/23 01:08, Ivanmarcus wrote:
> > Thanks Robert, FWIW I was responding to your earlier post which said:
> >
> > "If I can figure out how to get tomcat to pass the IP to guacamole so
> > when someone logs into a server via guacamole it correctly logs the
> > originator IP and failed logins that will work also but I am utterly
> > unfamiliar with tomcat"
> >
> > Which I took to mean you wanted the connection data that's already
> > provided in the referenced log? You could of course run a fail2ban
> > recipe for Tomcat.
> >
> > So while I have probably got the wrong end of your meaning I do
> > understand that you're still trying to deal with the noauth issue ..
> > to that end I don't suppose you've thought about LDAP as a common
> > system across your various options? Guacamole has an option for that
> > (https://guacamole.apache.org/doc/gug/ldap-auth.html), and although
> > I've not had occasion to use it myself I understand various people are
> > doing so successfully.
> >
> >
> > -
> > To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
> > For additional commands, e-mail: user-h...@guacamole.apache.org
>
> -
> To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
> For additional commands, e-mail: user-h...@guacamole.apache.org
>

-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org



Re: Apache verses Guacamole

2023-08-02 Thread Robert Dinse



 I have considered LDAP, just the scope of converting so many 
machines is more than a little intimidating for one person.  I do not 
have a staff, just me.


 I am trying to create one of two scenarios:

 1) A customer using guacamole can login to it with the same 
credentials he uses for servers, e-mail, x2go, vnc, etc.


 2) A customer logs in via apache and bypasses authentication at 
guacamole.  In this case apache logs failures, and I realize tomcat can 
as well but I have a jail for apache and not for tomcat and I don't do 
well at creating regular expressions as interpreted by fail2ban which 
has a lot of it's own unique matching rules. I've done it successfully 
before but I'm getting old and would rather not go bald.


 3) If neither of the above solutions can be made to work, then the 
customer goes straight into the host selection page but with the IP he 
is originating at, not the IP of the web server, so that failed logins 
are collected and repeat offending IPs blocked and really of the three 
this is the most convenient for the customer and the preferred one but 
since I don't know how to make tomcat pass through the originating IP 
it's problematic. If I could get this to work though it has some 
marketing advantage, as I could configure a virtual domain with a local 
non-routable IP address that the web server can talk to but that's it, 
and configure Ubuntu with a guest account (where nothing is saved after 
the session), the local address limiting the ability to get out on the 
net and use it for DOS attacks, etc.  I think it would be a cool 
marketing ploy.


On 8/2/23 01:08, Ivanmarcus wrote:

Thanks Robert, FWIW I was responding to your earlier post which said:

"If I can figure out how to get tomcat to pass the IP to guacamole so 
when someone logs into a server via guacamole it correctly logs the 
originator IP and failed logins that will work also but I am utterly 
unfamiliar with tomcat"


Which I took to mean you wanted the connection data that's already 
provided in the referenced log? You could of course run a fail2ban 
recipe for Tomcat.


So while I have probably got the wrong end of your meaning I do 
understand that you're still trying to deal with the noauth issue .. 
to that end I don't suppose you've thought about LDAP as a common 
system across your various options? Guacamole has an option for that 
(https://guacamole.apache.org/doc/gug/ldap-auth.html), and although 
I've not had occasion to use it myself I understand various people are 
doing so successfully.



-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org



Re: Apache verses Guacamole

2023-08-02 Thread Ivanmarcus

Thanks Robert, FWIW I was responding to your earlier post which said:

"If I can figure out how to get tomcat to pass the IP to guacamole so 
when someone logs into a server via guacamole it correctly logs the 
originator IP and failed logins that will work also but I am utterly 
unfamiliar with tomcat"


Which I took to mean you wanted the connection data that's already 
provided in the referenced log? You could of course run a fail2ban 
recipe for Tomcat.


So while I have probably got the wrong end of your meaning I do 
understand that you're still trying to deal with the noauth issue .. to 
that end I don't suppose you've thought about LDAP as a common system 
across your various options? Guacamole has an option for that 
(https://guacamole.apache.org/doc/gug/ldap-auth.html), and although I've 
not had occasion to use it myself I understand various people are doing 
so successfully.



-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org



Re: Apache verses Guacamole

2023-08-02 Thread Robert Dinse



 The site handles approximately half a million hits per day. I've 
been offering Linux shell access since 1992, and prior to that SunOS and 
SCO Xenix, so I'm familiar with the security issues.  The servers are 
all individually firewalled and fail2ban watches for password brute 
force hacking.  I'm trying to extend those protections through 
guacamole, that's the current challenge.  That's why I want to force a 
login at the apache level, a failure of login at guacamole level is only 
marginally helpful.  I mean yes, one can stop people from hitting it, 
but they can get to the servers via ssh, rdp, vnc, and x2go, so the 
attack really needs to be stopped at the server level not at a gateway 
because there are many paths of attack.


On 8/2/23 00:40, Ivanmarcus wrote:

Robert,

Just in case it helps; the connecting IP and login attempts are 
typically recorded in the Tomcat log. An example here is from a test 
Ubuntu 22.04 with Tomcat 9, the logfile is located at 
/var/log/tomcat9/catalina.out and you'll see I've tried twice, once 
with incorrect p/w, then the right one:


[2023-08-02 07:27:20] [info] 07:27:20.815 [http-nio-8080-exec-7] WARN 
o.a.g.r.auth.AuthenticationService - Authentication attempt from 
192.168.1.111 for user "admin" failed.
[2023-08-02 07:28:09] [info] 07:28:09.889 [http-nio-8080-exec-9] INFO 
o.a.g.r.auth.AuthenticationService - User "admin" successfully 
authenticated from 192.168.1.111.


Also, I'm not sure if the domain you mentioned is live but it might 
pay to obfuscate this on the mailing list. Amongst other things it'll 
end up in the archives and be there for all to see...




-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org



Re: Apache verses Guacamole

2023-08-02 Thread Ivanmarcus

Robert,

Just in case it helps; the connecting IP and login attempts are 
typically recorded in the Tomcat log. An example here is from a test 
Ubuntu 22.04 with Tomcat 9, the logfile is located at 
/var/log/tomcat9/catalina.out and you'll see I've tried twice, once with 
incorrect p/w, then the right one:


[2023-08-02 07:27:20] [info] 07:27:20.815 [http-nio-8080-exec-7] WARN 
o.a.g.r.auth.AuthenticationService - Authentication attempt from 
192.168.1.111 for user "admin" failed.
[2023-08-02 07:28:09] [info] 07:28:09.889 [http-nio-8080-exec-9] INFO 
o.a.g.r.auth.AuthenticationService - User "admin" successfully 
authenticated from 192.168.1.111.


Also, I'm not sure if the domain you mentioned is live but it might pay 
to obfuscate this on the mailing list. Amongst other things it'll end up 
in the archives and be there for all to see...




-
To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org
For additional commands, e-mail: user-h...@guacamole.apache.org