2 Replies Latest reply on May 17, 2017 6:19 AM by d_aloy

    Web Server replied traffic triggered attack


      Hi all,


      Our IPS is placing behind linux web server for the main purpose to protect incoming threats into the web server. However, somehow we saw the web server replied traffics to client triggers IPS alerts, most of it is HTTP related attacks such as "HTTP: Microsoft Windows HTTP Services Integer Underflow Vulnerability".

      By analyzing from the attack log details as below, we quite sure it is a web server replied traffic

      Source : Web Server IP

      Port : 80

      Destination : Client IP

      Port : <some random port more than 1024>


      We are quite unsure how should we handle this situation given that outgoing web reply traffic seems like should not causing security impact to our web server than incoming web request traffic.

      Plus, the replied traffic triggers windows based attack , but our web server is linux based.

      Hope to have some recommendation from here.

      Thank you.

        • 1. Re: Web Server replied traffic triggered attack

          Hi Dotax,


          Unless you have integrated your NSM with EPO it will not be able to determine what OS the Source is running.


          You should follow the process described in KB55743 to report this to the support team.


          How to submit Network Security Platform false positives and incorrect detections to Technical Support



          It may just be triggering on traffic that could be vulnerable to these attacks.



          • 2. Re: Web Server replied traffic triggered attack

            Hi Dotax


            This signature requires HTTP response to be enabled on the sensor in order to trigger. If you look at the attack description, there are 2 signatures:


            condition 1

            http-rsp-chunk-read-body-length > 0x80000000 ( unsigned )



            condition 1

            http-req-user-agent-header matches "WinHTTP" ( case-sensitive )

            [AND] http-rsp-header matches "\x0a\x50\x6f\x43\x0d\x0a" ( case-sensitive )

            [AND] http-rsp-header matches "\x66\x66\x63\x30\x30\x30" ( case-sensitive )


            If you look at the triggered alerts, it should tell you which is the signature triggering - and I am guessing is sig#1 as it is just looking at the response body length.


            If that is the case then you should be able to tune out the signature for the specific linux web servers, either using policies or ignore rules.






            1 of 1 people found this helpful