Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 3316 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

HTTP proxy vuln?

EricH
Ok so let me first say that I'm a total n00b at security, so please forgive if I don't include all details.
Home license
7.202
no pf rules allowing any>any
HTTP proxy setup using all defaults

I was running a nessus scan against my internal network, and I found the following on the 8080 proxy port. 


"Proxy accepts CONNECT requests to itself
The proxy allows the users to perform
repeated CONNECT requests to itself.

This allow anybody to saturate the proxy CPU, memory or
file descriptors.

** Note that if the proxy limits the number of connections
** from a single IP (e.g. acl maxconn with Squid), it is
** protected against saturation and you may ignore this alert.

Solution: reconfigure your proxy so that
it refuses CONNECT requests to itself.

Risk factor : Medium

Nessus ID : 17154"


I dug around in webadmin and I can't find anything in which you might be able to close this apparent hole. I noticed that while running the scan I effectively DoS'd the box and once the scan was done everything returned to normal. 
Anyone run into this before?


This thread was automatically locked due to age.
Parents
  • 0
    Ok so let me first say that I'm a total n00b at security, so please forgive if I don't include all details.
    Home license
    7.202
    no pf rules allowing any>any
    HTTP proxy setup using all defaults

    I was running a nessus scan against my internal network, and I found the following on the 8080 proxy port. 


    "Proxy accepts CONNECT requests to itself
    The proxy allows the users to perform
    repeated CONNECT requests to itself.

    This allow anybody to saturate the proxy CPU, memory or
    file descriptors.

    ** Note that if the proxy limits the number of connections
    ** from a single IP (e.g. acl maxconn with Squid), it is
    ** protected against saturation and you may ignore this alert.

    Solution: reconfigure your proxy so that
    it refuses CONNECT requests to itself.

    Risk factor : Medium

    Nessus ID : 17154"


    I dug around in webadmin and I can't find anything in which you might be able to close this apparent hole. I noticed that while running the scan I effectively DoS'd the box and once the scan was done everything returned to normal. 
    Anyone run into this before?


    You can forbid such attacks by blacklisting requests that have a local interface as target. If you interface ip is 1.2.3.4 and the proxy listens on port 8080, add 1.2.3.4:8080 to the Blacklist in the corresponding Filteraction.

    Removing the HTTP Proxy port from the list of allowed target services in Webadmin would work as well.

    Will open a bug tracking entry and think about a solution in the default config though.

    Cheers,

    Sven.
  • 0 in reply to svens
    Sven,
    Thanks for the reply!
    I removed HTTP proxy from the allowed target services, however I'm scheduled to go to work soon and will not be able to test until tonight, bummer. Unfortunately I can't run my testing from work as it would surely result in my unceremonious and immediate boot into the unemployment line.  

    I will post my findings tonight. 

    Being that I was running this test from within my own network leaves me to question if this same problem exists on the external interface as well.
  • 0 in reply to EricH
    Sven,
    Being that I was running this test from within my own network leaves me to question if this same problem exists on the external interface as well.


    It won't, as your External Network shouldn't be in the allowed Network list [;)]. So requests coming from the External Network are already dropped by the packetfilter and will never reach the HTTP Proxy.

    Of course you could do a CONNECT request to your external IP from the Internal Network, but the Proxy won't allow that request because there's no matching Profile configured.

    Cheers,

    Sven.
Reply
  • 0 in reply to EricH
    Sven,
    Being that I was running this test from within my own network leaves me to question if this same problem exists on the external interface as well.


    It won't, as your External Network shouldn't be in the allowed Network list [;)]. So requests coming from the External Network are already dropped by the packetfilter and will never reach the HTTP Proxy.

    Of course you could do a CONNECT request to your external IP from the Internal Network, but the Proxy won't allow that request because there's no matching Profile configured.

    Cheers,

    Sven.
Children