Uploaded image for project: 'Dev - Nexus Repo'
  1. Dev - Nexus Repo
  2. NEXUS-14990

deleting quarantined assets may not successfully notify IQ server using HTTP DELETE when blocked by security software

    Details

    • Type: Improvement
    • Status: New
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.5.2
    • Fix Version/s: None
    • Component/s: Firewall, IQ Integration
    • Labels:
      None

      Description

      Construct a policy in IQ server with FAIL action on Repository stage.

      Add an HTTP proxy server in Nexus Repository Manager that returns 200 status code, Content-Type: text/html, and a custom Server header value in response to DELETE requests to /rest/integration/repositories/*, but actually prevents that request from ever reaching IQ server. This can be simulated using Charles proxy and breakpoints.

      Connect IQ server and Nexus Repository Manager together and enable quarantine ( Firewall ) on a proxy repository.

      Make a proxy repository request which successfully quarantines an asset requested through the Nexus proxy repository.

      Now delete the asset in Nexus repository manager. Internally this means IQ server will need to know about the deletion. It 'hears' about it because Nexus Repository Manager will send a HTTP DELETE request to IQ server.

      If the HTTP Proxy Server that repository manager uses interferes with DELETE requests outbound, then the response may be returned with status code 200, even though IQ server never received the request.

      We have seen this scenario with Symantec Web Server security filtering for one.

      Detection

      Set the log level to DEBUG for the org.apache.http logger inside Nexus repository Manager.
      Delete the asset.
      Examine the nexus.log, specifically for the outbound delete request to IQ server and the response headers coming back - example:

      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 >> DELETE http://iq.example.com:8070/rest/integration/repositories/C60FBC65-0D112FF5-97FC86AB-A45A8E1F-3B3884E5/central/components/org/apache/struts/struts-core/1.3.10/struts-core-1.3.10.jar HTTP/1.1
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 >> X-CSRF-TOKEN: CSRF-REQUEST-TOKEN
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 >> Accept-Encoding: gzip,deflate
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 >> Connection: Close
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 >> Host: iq.example.com:8070
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 >> Proxy-Connection: Keep-Alive
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 >> User-Agent: Nexus/3.5.2-01 (PRO; Windows Server 2012 R2; 6.3; amd64; 1.8.0_102)
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 >> Cookie: CLM-CSRF-TOKEN=CSRF-REQUEST-TOKEN
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 >> Authorization: Basic YWRtaW46YWRtaW4xMjM=
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 << HTTP/1.0 200 OK
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 << Date: Tue, 26 Sep 2017 11:57:56 GMT
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 << Server: SWS-3.0.1.76
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 << Content-Type: text/html
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 << Content-Length: 1312
      2017-09-26 07:57:56,838-0400 DEBUG [fte-3-thread-12] admin org.apache.http.headers - http-outgoing-35 << Pragma: No-Cache
      

      Unexpected are:

      • status code is 200 which is the same code IQ server would return, so repository manager thinks it successfully told IQ server about this deletion, but the 200 is actually coming from the HTTP Proxy Server
      • Server response header is not from IQ server, but SWS ( Symantec Web Security)
      • content type is HTML, IQ server does not respond with HTML content type to that call
      • examining the IQ server request.log shows no inbound DELETE request being received

      Workaround

      • Add the IQ server to the HTTP Proxy server non-proxy hosts to bypass the aggressive Network firewall manipulating HTTP DELETE requests outbound.
      • modify the HTTP Proxy servers aggressive policy to ALLOW outbound HTTP DELETE requests

      Expected

      There are situations where applications are forced to NOT bypass the configured HTTP proxy server when accessing other servers due to company policy and the Repository manager administrator is not in control of HTTP traffic policies it may enforce.

      Ideas to help mitigate this failure when designing application interactions are:

      • respond with and expect a 204 for successful HTTP DELETE requests instead of 200 to avoid being tricked 200 indicates success
      • examine the content type of the response in addition to status code
      • return JSON body indicating success instead of empty 200 response
      • return response headers specific to IQ server ( X- ) that help verify the response came from IQ server and not some other server - understanding the Server header is NOT a good candidate to check value of as it commonly gets rewritten by reverse proxies

      Also:

      When a failure is detected, print the response headers at default log levels to more quickly prove the request never reached the intended server - this avoids the burden of enabling additional logging to detect what server interfered with the outbound request.

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            plynch Peter Lynch
            Last Updated By:
            Joe Tom Joe Tom
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:

                tigCommentSecurity.panel-title