Re: [External] org.apache.catalina.valves.RemoteAddrValve

2024-04-04 Thread Robert Egan
You need to read up on "regular expressions" (or "regex").

In a regular expression, a lowercase "d" is a single decimal digit. A "+"
means one or more of them. A period means ANY character (which is why you
have to escape it when you mean "period"). A backward slash means to treat
the character immediately after it normally and not as a special character.
So "\d" would mean the literal letter "d".

There's more rules, but they're well documented all over the internet, so I
won't elaborate.

Robert Egan


On Thu, Apr 4, 2024 at 2:01 PM Eric Fetzer  wrote:

> Thanks for the quick response Robert!  So I tried escaping the periods and
> putting the \d+ for the * but it didn't work.  Is the \d+ incorrect in
> substitution for *?
>
> On Thu, Apr 4, 2024 at 11:53 AM Robert Egan 
> wrote:
>
> > It looks like you need to escape your periods, like you did for 127\.
> > etc...
> > 1\.3\.5
> > Robert Egan
> >
> > On Thu, Apr 4, 2024 at 1:44 PM Eric Fetzer 
> wrote:
> >
> > > Hi All,
> > >
> > > When I originally set up my tomcat instance, I added the following to
> > allow
> > > manager access under /opt/tomcat/webapps/manager/META-INF/context.xml:
> > >
> > >  > >  allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*" />
> > >
> > > That worked wonderfully.  Now I'm trying to add another IP range by
> > > changing it to:
> > >
> > >  > >  allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*|2.4.6.*"
> > />
> > >
> > > This is not working.  I tried to use 2\.4\.6\.\d+ as well but that
> didn't
> > > work either.  I've verified I can get to port 8080 from the IP
> locations.
> > > Any idea what I'm doing wrong or do you have a means to troubleshoot
> > this?
> > >
> > > Thanks,
> > > Eric
> > >
> >
>


Re: [External] org.apache.catalina.valves.RemoteAddrValve

2024-04-04 Thread Robert Egan
It looks like you need to escape your periods, like you did for 127\. etc...
1\.3\.5
Robert Egan

On Thu, Apr 4, 2024 at 1:44 PM Eric Fetzer  wrote:

> Hi All,
>
> When I originally set up my tomcat instance, I added the following to allow
> manager access under /opt/tomcat/webapps/manager/META-INF/context.xml:
>
>   allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*" />
>
> That worked wonderfully.  Now I'm trying to add another IP range by
> changing it to:
>
>   allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|1.3.5.*|2.4.6.*" />
>
> This is not working.  I tried to use 2\.4\.6\.\d+ as well but that didn't
> work either.  I've verified I can get to port 8080 from the IP locations.
> Any idea what I'm doing wrong or do you have a means to troubleshoot this?
>
> Thanks,
> Eric
>


Re: [External] Re: Client Certificates

2023-07-20 Thread Robert Egan
I suspect the problem is occurring before I can see the certificate,
because the only way the request even reaches my filter is when the
 is set to auth="none".

I have been pulled away from this project for now, but thanks for the
answers.


Robert Egan
--
*VSolvit LLC*, *CMMI (Level 3), ISO 9001, ISO 2-1, ISO 27001*
*1305 Executive Blvd. Ste. 160 | Chesapeake | VA | 23320*
*(617) 455-1425*
www.vsolvit.com

*VSolvit (We*Solve*it) *is an award winning technology services company
that specializes in the areas of Geographic Information Systems and IT
application development / database integration.

*Cyber-security ~ Cloud Computing ~ GIS ~ Business Intelligence ~ Data
Warehousing.*

*CONFIDENTIALITY NOTICE:* This communication, including attachments, is for
the exclusive use of addressee and may contain proprietary, confidential or
privileged information. If you are not the intended recipient, any use,
copying, disclosure, dissemination or distribution is strictly prohibited.
If you are not the intended recipient, please notify the sender immediately
by return email and delete this communication and destroy all copies.


On Mon, Jul 17, 2023 at 3:45 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Tim,
>
> On 7/17/23 10:58, Timothy Ward wrote:
> > Here is a filter that I am using to get the client certificates, the
> issue
> > I'm having is passing them along via the headers so they can be picked up
> > as CGI Environment Variables down the road.  This does get me the
> > certificate information though.  Just ignor the mutableRequest stuff as
> > that is what I was trying to use to put the information in the
> > RequestHeader, so there is another java file that does that.
>
> Robert can also probably ignore the comment about "CGI Environment
> Variables" because all that is handled by the Servlet Container (Tomcat)
> by placing the certificate and chain under this request attribute key:
>
>  javax.servlet.request.X509Certificate
>
> Robert, if you read the Servlet API (it's not awful! I promise!) you'll
> see what other things get put in there when client-certs are in use.
>
> > import java.io.IOException;
> >
> > import javax.servlet.FilterChain;
> > import javax.servlet.FilterConfig;
> > import javax.servlet.ServletException;
> > import javax.servlet.ServletRequest;
> > import javax.servlet.ServletResponse;
> > import javax.servlet.http.HttpServletRequest;
> > import javax.servlet.http.HttpServletResponse;
> >
> > import java.security.cert.Certificate;
> > import java.security.cert.X509Certificate;
> >
> > //import MutableHttpServletRequest;
> >
> > public class SecurityFilter implements javax.servlet.Filter
> > {
> >   @Override public void destroy()
> >   {
> >   }
> >
> >   @Override public void doFilter(ServletRequest request, ServletResponse
> > response, FilterChain chain) throws IOException, ServletException
> >{
> > System.out.println("doFilter-Start.");
> > HttpServletRequest req = (HttpServletRequest) request;
> > //MutableHttpServletRequest mutableRequest = new
> > MutableHttpServletRequest(req);
> >
> > X509Certificate[] certs = (X509Certificate[])
> > req.getAttribute("javax.servlet.request.X509Certificate");
> >
> >
> >
>  
> System.out.println("doFilter-SSL_CLIENT_S_DN="+certs[0].getSubjectX500Principal().getName());
>
> I would highly recommend some null-checking in here /just in case/ but
> this is basically what you (Robert) are looking for.
>
> >
>  
> System.out.println("doFilter-SSL_CERTIFICATES_FOUND="+Integer.toString(certs.length));
> > //mutableRequest.putHeader("SSL_CLIENT_S_DN",
> > certs[0].getSubjectX500Principal().getName());
> > //mutableRequest.putHeader("SSL_CERTIFICATES_FOUND",
> > Integer.toString(certs.length));
> > //chain.doFilter(mutableRequest, response);
> > System.out.println("doFilter-Done.");
> >}
> >
> >   @Override public void init(FilterConfig filterConfig) throws
> > ServletException
> >{
> >}
> > }
>
> -chris
>
> > On Mon, Jul 17, 2023 at 10:38 AM Robert Egan 
> > wrote:
> >
> >> I would like to write a filter that accesses a client certificate
> attached
> >> to the servlet request without using a proxy server. And after three
> weeks
> >> of searching, I'm beginning to feel like it is not possible. Because
> every
> >> article I've found assumes the request was forwarded from a proxy
> server.
> >>

Client Certificates

2023-07-17 Thread Robert Egan
I would like to write a filter that accesses a client certificate attached
to the servlet request without using a proxy server. And after three weeks
of searching, I'm beginning to feel like it is not possible. Because every
article I've found assumes the request was forwarded from a proxy server.

So my questions are: Is it even possible? If it is, can someone point me in
the right direction? Also, if it is possible, but strongly discouraged for
security reasons, let me know that as well. I am not adverse to using a
proxy server, especially if it is considered a "best practice".

Thanks in advance
Robert Egan
--
*VSolvit LLC*, *CMMI (Level 3), ISO 9001, ISO 2-1, ISO 27001*
*1305 Executive Blvd. Ste. 160 | Chesapeake | VA | 23320*
*(617) 455-1425*
www.vsolvit.com

*VSolvit (We*Solve*it) *is an award winning technology services company
that specializes in the areas of Geographic Information Systems and IT
application development / database integration.

*Cyber-security ~ Cloud Computing ~ GIS ~ Business Intelligence ~ Data
Warehousing.*

*CONFIDENTIALITY NOTICE:* This communication, including attachments, is for
the exclusive use of addressee and may contain proprietary, confidential or
privileged information. If you are not the intended recipient, any use,
copying, disclosure, dissemination or distribution is strictly prohibited.
If you are not the intended recipient, please notify the sender immediately
by return email and delete this communication and destroy all copies.