3 Replies Latest reply on Jun 7, 2016 6:53 AM by jasim

    Monitoring forbidden or denied access in undertow

    jasim
    jasim Jun 2, 2016 5:23 AM

      I have configured https with client authentication, access-log and IP filter in undertow under wildfly 10. (I removed http listener too)

      Is is possible to get denied requests logged (either because request coming from not allowed IPs or because of authentication issue like wrong certificate etc.)?

       

      So far, I only saw successful access request logged in access-log. For security reason, it would be interesting to see, the denied requests.


      Undertow configuration:


              <subsystem xmlns="urn:jboss:domain:undertow:3.0">

                  <buffer-cache name="default"/>

                  <server name="default-server">

                      <https-listener name="default-https" verify-client="REQUIRED" security-realm="SSLRealm" socket-binding="https"/>

                      <host name="default-host" alias="localhost">

                          <location name="/" handler="welcome-content"/>

                          <access-log pattern="combined"/>

                          <filter-ref name="server-header"/>

                          <filter-ref name="x-powered-by-header"/>

                          <filter-ref name="ipaccess"/>

                      </host>

                  </server>

                  <servlet-container name="default">

                      <jsp-config/>

                      <websockets/>

                  </servlet-container>

                  <handlers>

                      <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>

                  </handlers>

                  <filters>

                      <response-header name="server-header" header-name="Server" header-value="WildFly/10"/>

                      <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>

                      <expression-filter name="ipaccess" module="io.undertow.core" expression="ip-access-control(default-allow=false, acl={'10.0.0.0 allow'})"/>

                  </filters>

              </subsystem>

        • 1. Re: Monitoring forbidden or denied access in undertow
          ctomc
          ctomc Jun 2, 2016 5:38 AM (in response to jasim)

          not likely.

           

          as in your case where you have client cert auth, which means that authentication is done as part of SSL handshake, which happens before actual "http" request is made to server.

          so if the handshake fails because of wrong certificate, request doesn't even go further down the line to perform anything on server.

           

          maybe you could look at some ssl handshake logging, but that would be config for sslengine if anything.

            • Actions
          • 2. Re: Monitoring forbidden or denied access in undertow
            nickarls
            nickarls Jun 2, 2016 2:41 PM (in response to jasim)

            You might try starting WF with -Djavax.net.debug=all and then try to find a more narrow log level (or logger filter) once you see what you're looking for. "all" is like trying to drink from a fire hose.

             

            There are some pointers in http://stackoverflow.com/questions/23659564/limiting-java-ssl-debug-logging

              • Actions
            • 3. Re: Monitoring forbidden or denied access in undertow
              jasim
              jasim Jun 7, 2016 6:53 AM (in response to jasim)

              Hello Martin,

                finally, it was really a minor issue.

                I had the misfortune to configure keystore-provider=jks instead of "JKS" for the truststore in a security realm. (jks is a possible corresponding value in JSSE, but obviously in in wildfly)

               

                The CLI configuration script works also with keystore-provider=jks, but after activating of verify-client=REQUIRED in the https-listener,

                no connection is possible. At the first glance, it was not obvious that the problem is the wrong truststore configuration, so I get messed around.

                SSL-debugging of server helped, finally.

               

                I removed the superfluous call for keystore-provider as JKS is default after all and it works now.

              Best regards

              Jaro

                • Actions