Re: Apache Tomcat 9 | Tomcat starting issue

2021-08-24 Thread Piyush Sharma 
On Mon, Aug 23, 2021 at 8:29 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Piyush,
>
> On 8/22/21 03:54, Piyush Sharma wrote:
> > On Fri, Aug 20, 2021 at 10:40 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> Piyush,
> >>
> >> On 8/20/21 06:36, Piyush Sharma wrote:
> 
>  Hello,
> 
>  I am using Apache Tomcat 9.0.46 version on docker container.
> 
>  There is a problem, where the base path was wrongly set by automation
>  script due to which it starts for few seconds, listen port 8080 and
> then
>  stop, due to that container exit after sometime.
> 
> >>>
> >>> Now how can we debug such issue, which shows any error / problem in
> >> tomcat
>  configuration.
> 
>  I tried with "jpda start" or "debug" options, but that didn't help me.
> >> Is
>  there any option to debug tomcat related issues or problems.
> 
>  "catalina.sh configtest" will show any error in xml or properties but
> >> will
>  not help to debug tomcat startup problem.
> 
>  *Note:* I am just deploying with the helloworld war file. nothing much
> >> in
>  code as of now.
> >>
> >> Maybe just fix your automation script to use the right path?
> >>
> >> It's hard to understand what the problem is given the information you
> >> have presented.
> >>
> >> -chris
> >>
> >>
> > Thanks Chris
> >
> > I have removed automation and harded everything and created a new docker
> > image.
> > Now when I try to start the container, it starts for a few seconds and
> > stops (port 8080 listens for a while). Nothing in logs.
> >
> > $ catalina.sh run  (tried with "jpda start" or "debug" options as well)
> > $ ps aux |grep java --> show the process for few seconds
> > $ netstat -ntpl |grep 8080 --> shows the port for few seconds
> >
> > I am wondering if I can debug such issues, when it starts for a few
> seconds
> > and then stops. Is there any memory , config file or any other issues?
> >
> > Any debug option whether tomcat
>
> What do the logs say?
>
> -chris
>
>

Hello Chris,

After starting the container in debug mode, I noticed Exit Code 137 which
seems to be OOM (out of memory) issue. Due to which container exit /
terminate.

Is there any other reason for Exit Code 137 ? as I am just starting hello
world application and given 2 GB RAM.



-
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 

*Thanks & Regards,*

*Piyush M Sharma*
My Linux Blog 

http://in.linkedin.com/in/linuxboy

Re: 200 response and redirect for ".../test.jsp"

2021-08-24 Thread Mark Eggers 

Folks,

On 8/24/2021 3:55 PM, Christopher Schultz wrote:

James,

On 8/24/21 17:20, James H. H. Lampert wrote:
I could have sworn I asked about this over a year ago, but I can't 
find any record of having done so.


We've got a low-priority complaint about a security scan looking for 
"test.jsp" on one of our installations, expecting a 404 response, and 
instead getting a 200 response and a redirect to our own error page.


Just a sanity check: this *is* a problem with our ROOT context, not 
with Tomcat itself, right? And it has to be solved within our ROOT 
context, right?


My guess is that the vuln scanner assumes that "GET test.jsp" returning 
a 200 response means "it's got something bad in there". They are 
probably thinking about a *specific* test.jsp file, but you just happen 
to have one, probably as part of your application.


If you haven't deployed any of Tomcat's "example", "docs", or ROOT 
applications (meaning, the ROOT webapp that hosts Tomcat's documentation 
and stuff), then yes, this complaint is being aimed at your application.


You should probably be able to find test.jsp on your disk, or in your 
WAR file if for some reason you aren't exploding WAR files on deployment.


Go read the source for that file and maybe it will give you some insight 
as to where it came from.


-chris


If I understand correctly, the security scanning looks for something 
like this:


/appname/../test.jsp

How that triggers a 200, then generates an application error page I'm 
not certain.


In your application, do you have an  specified for 404 errors?

In your ROOT application (if different from your regular application) do 
you have an  specified?


What my $work environment has are application-specific error pages per 
application, and a generic error page for the ROOT application, which is 
just a placeholder.


Going to /appname/../test.jsp in my $work environment ends up at ROOT, 
which generates a 404 and the generic error page since there is no 
test.jsp page.


My $work environment has front end Apache HTTPD servers connected to 
multiple Tomcats via mod_jk. This may influence the results.


Security scans by various clients of $work have not complained about the 
above setup.


. . . just my two cents
/mde/



OpenPGP_signature
Description: OpenPGP digital signature

RE: UserDatabaseRealm and DIGEST

2021-08-24 Thread jonmcalexander 
Chris,

> -Original Message-
> From: Christopher Schultz 
> Sent: Tuesday, August 24, 2021 5:52 PM
> To: users@tomcat.apache.org
> Subject: Re: UserDatabaseRealm and DIGEST
> 
> Jon,
> 
> On 8/24/21 12:53, jonmcalexan...@wellsfargo.com.INVALID wrote:
> >> -Original Message-
> >> From: Mark Thomas 
> >> Sent: Tuesday, August 24, 2021 11:41 AM
> >> To: users@tomcat.apache.org
> >> Subject: Re: UserDatabaseRealm and DIGEST
> >>
> >> On 24/08/2021 17:28, jonmcalexan...@wellsfargo.com.INVALID wrote:
> >>> Ok, so I've been reading thru the documentation on DIGEST but not
> >> entirely sure I have it right. What is the best practice for DIGEST
> >> and what algorithms are allowed, such as is sha-256 allowed?
> >>
> >> First, a question of clarification.
> >>
> >> Do you mean HTTP DIGEST authentication or do you mean storing
> >> password hashes rather than the actual passwords in the
> UserDatabaseRealm?
> >>
> >> Mark >
> > I mean the Password Hashes rather than the actual password for the
> UserDatabaseRealm.
> 
> You can use any algorithm that Java's MessageDigest supports.
> 
> I would recommend against using "Digest" credential storage and instead use
> something more secure such as PBKDF2, which Tomcat also supports.
> 
> You might find this informative:
> https://urldefense.com/v3/__https://tomcat.apache.org/presentations.htm
> l*latest-credential-
> security__;Iw!!F9svGWnIaVPGSwU!7c3eGMZdJEU_EmV4XmOqEiivhaDIfji3A
> sGbXN4DAVlFM-pSfYgsX93DDHm6520mF1wBLNc$
> 
> -chris
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

In this case I am wanting to know the proper way to use DIGEST as we have some 
folks with vendor applications that Use Tomcat that insist on using the 
UserDatabaseRealm. I agree that using LDAP or something other is the better way 
to go. We typically do NOT allow the use of the UserDatabaseRealm unless the 
passwords are hashed with DIGEST. I just want to make sure that when we check 
for compliance, we are approving the various means.

Thanks,



Dream * Excel * Explore * Inspire
Jon McAlexander
Infrastructure Engineer
Asst Vice President

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

Re: 200 response and redirect for ".../test.jsp"

2021-08-24 Thread Christopher Schultz 

James,

On 8/24/21 17:20, James H. H. Lampert wrote:
I could have sworn I asked about this over a year ago, but I can't find 
any record of having done so.


We've got a low-priority complaint about a security scan looking for 
"test.jsp" on one of our installations, expecting a 404 response, and 
instead getting a 200 response and a redirect to our own error page.


Just a sanity check: this *is* a problem with our ROOT context, not with 
Tomcat itself, right? And it has to be solved within our ROOT context, 
right?


My guess is that the vuln scanner assumes that "GET test.jsp" returning 
a 200 response means "it's got something bad in there". They are 
probably thinking about a *specific* test.jsp file, but you just happen 
to have one, probably as part of your application.


If you haven't deployed any of Tomcat's "example", "docs", or ROOT 
applications (meaning, the ROOT webapp that hosts Tomcat's documentation 
and stuff), then yes, this complaint is being aimed at your application.


You should probably be able to find test.jsp on your disk, or in your 
WAR file if for some reason you aren't exploding WAR files on deployment.


Go read the source for that file and maybe it will give you some insight 
as to where it came from.


-chris

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

Re: UserDatabaseRealm and DIGEST

2021-08-24 Thread Christopher Schultz 

Jon,

On 8/24/21 12:53, jonmcalexan...@wellsfargo.com.INVALID wrote:

-Original Message-
From: Mark Thomas 
Sent: Tuesday, August 24, 2021 11:41 AM
To: users@tomcat.apache.org
Subject: Re: UserDatabaseRealm and DIGEST

On 24/08/2021 17:28, jonmcalexan...@wellsfargo.com.INVALID wrote:

Ok, so I've been reading thru the documentation on DIGEST but not

entirely sure I have it right. What is the best practice for DIGEST and what
algorithms are allowed, such as is sha-256 allowed?

First, a question of clarification.

Do you mean HTTP DIGEST authentication or do you mean storing password
hashes rather than the actual passwords in the UserDatabaseRealm?

Mark >

I mean the Password Hashes rather than the actual password for the 
UserDatabaseRealm.


You can use any algorithm that Java's MessageDigest supports.

I would recommend against using "Digest" credential storage and instead 
use something more secure such as PBKDF2, which Tomcat also supports.


You might find this informative:
https://tomcat.apache.org/presentations.html#latest-credential-security

-chris

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

200 response and redirect for ".../test.jsp"

2021-08-24 Thread James H. H. Lampert 
I could have sworn I asked about this over a year ago, but I can't find 
any record of having done so.


We've got a low-priority complaint about a security scan looking for 
"test.jsp" on one of our installations, expecting a 404 response, and 
instead getting a 200 response and a redirect to our own error page.


Just a sanity check: this *is* a problem with our ROOT context, not with 
Tomcat itself, right? And it has to be solved within our ROOT context, 
right?


--
JHHL

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

RE: UserDatabaseRealm and DIGEST

2021-08-24 Thread jonmcalexander 
> -Original Message-
> From: Mark Thomas 
> Sent: Tuesday, August 24, 2021 11:41 AM
> To: users@tomcat.apache.org
> Subject: Re: UserDatabaseRealm and DIGEST
> 
> On 24/08/2021 17:28, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > Ok, so I've been reading thru the documentation on DIGEST but not
> entirely sure I have it right. What is the best practice for DIGEST and what
> algorithms are allowed, such as is sha-256 allowed?
> 
> First, a question of clarification.
> 
> Do you mean HTTP DIGEST authentication or do you mean storing password
> hashes rather than the actual passwords in the UserDatabaseRealm?
> 
> Mark
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

I mean the Password Hashes rather than the actual password for the 
UserDatabaseRealm. 

Thank you,

Jon McAlexander

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

Re: UserDatabaseRealm and DIGEST

2021-08-24 Thread Mark Thomas 

On 24/08/2021 17:28, jonmcalexan...@wellsfargo.com.INVALID wrote:

Ok, so I've been reading thru the documentation on DIGEST but not entirely sure 
I have it right. What is the best practice for DIGEST and what algorithms are 
allowed, such as is sha-256 allowed?


First, a question of clarification.

Do you mean HTTP DIGEST authentication or do you mean storing password 
hashes rather than the actual passwords in the UserDatabaseRealm?


Mark


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

UserDatabaseRealm and DIGEST

2021-08-24 Thread jonmcalexander 
Ok, so I've been reading thru the documentation on DIGEST but not entirely sure 
I have it right. What is the best practice for DIGEST and what algorithms are 
allowed, such as is sha-256 allowed?

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Infrastructure Engineer
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com

Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 
12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 
12/30/2020, 12/31/2020
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.