Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 2863 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

Squid proxy used as a spam relay???

pablito
I have an issue with a 3.214 box.  When I enable Squid proxy I start seeing frequent proxy requests from a few outside servers that then connect to SMTP ports of many servers.
Proxy is set to only allow the internal network.  Transparent or Standard both seem to allow these outside servers to bounce email off Squid.  Most of the connections are coming from one server today: 216.137.3.3 as well as a couple of others (64.xxx).
I then put in a rule to block port 8080 to the external interface and I start seeing frequent violations.
After a while the violations stop.  If I enable proxy again the violations will eventually begin again (but not for some hours).
BTW, SMTP proxy is not turned on and I don't see anything unusual to/from the real SMTP server (besides the usual cracker crap).  And, I have to use Proxy ARP to use the 5 routable IPs I have from the ISP.  And FYI, the one routable IP that is the real SMTP server also runs the latest Apache and I don't see anything unusual there except those pesky worms and Formail attempts.


This thread was automatically locked due to age.
Parents
  • 0
    Known problem, big hole, big problem. Bug reported - details as soon as bugfix is out. 

    Please send me a mail (volker.tanger@discon.de) for preliminary bugreport and workarounds. Your Astaro's Squid quite probably was/is being abused as mail relay.
     
     [size="1"][ 20 January 2003, 03:25: Message edited by: vtanger ][/size]
  • 0 in reply to vtanger
    Greetings!

    A quite well known (i.e. ancient) type of proxy vulnerability was found in the https proxy of Astaro Security Linux firewall (which is a chrooted yet plain squid btw.) This general problem has been known to be an issue with nearly all HTTP proxies for ages (e.g. 
    http://www.squid-cache.org/Doc/FAQ/FAQ-10.html#ss10.14).

    The vulnerability can be exploited using the CONNECT method to connect to a different server, e.g. an internal mailserver as port usage is completely unrestricted by the Astaro proxy.

    Example:
    code:
    	you = 6.6.6.666
    	Astaro = 1.1.1.1  (http proxy at port 8080)
    	Internal Mailserver = 2.2.2.2

    	connect with "telnet 1.1.1.1 8080" to Astaro proxy and enter
    	CONNECT 2.2.2.2:25 / HTTP/1.0

    	response: mail server banner - and running SMTP session e.g.
    	to send SPAM from.
    You can connect to any TCP port on any machine the proxy can connect to. Telnet, SMTP, POP, etc.

    Solution:

    Install patch 3.215 - there you can restrict the ports you allow access to. I'd suggest ports 21 70 80 443 563 210 1025-65535 which stand for FTP, Gopher, HTTP, HTTPS, HTTPS(seldom), WAIS and nonprivileged services (e.g. passive FTP)
     
     [size="1"][ 20 January 2003, 03:28: Message edited by: vtanger ][/size]
Reply
  • 0 in reply to vtanger
    Greetings!

    A quite well known (i.e. ancient) type of proxy vulnerability was found in the https proxy of Astaro Security Linux firewall (which is a chrooted yet plain squid btw.) This general problem has been known to be an issue with nearly all HTTP proxies for ages (e.g. 
    http://www.squid-cache.org/Doc/FAQ/FAQ-10.html#ss10.14).

    The vulnerability can be exploited using the CONNECT method to connect to a different server, e.g. an internal mailserver as port usage is completely unrestricted by the Astaro proxy.

    Example:
    code:
    	you = 6.6.6.666
    	Astaro = 1.1.1.1  (http proxy at port 8080)
    	Internal Mailserver = 2.2.2.2

    	connect with "telnet 1.1.1.1 8080" to Astaro proxy and enter
    	CONNECT 2.2.2.2:25 / HTTP/1.0

    	response: mail server banner - and running SMTP session e.g.
    	to send SPAM from.
    You can connect to any TCP port on any machine the proxy can connect to. Telnet, SMTP, POP, etc.

    Solution:

    Install patch 3.215 - there you can restrict the ports you allow access to. I'd suggest ports 21 70 80 443 563 210 1025-65535 which stand for FTP, Gopher, HTTP, HTTPS, HTTPS(seldom), WAIS and nonprivileged services (e.g. passive FTP)
     
     [size="1"][ 20 January 2003, 03:28: Message edited by: vtanger ][/size]
Children
  • 0 in reply to vtanger
    Hi there guys, 

    I am a little bit confused and/or miss a point,
    but how can somebody connect to your proxy and use it as a mail relay, if you configured your allowed networks to 'internal LAN', nobody would be so negligent to add 'Any' to allowed networks,or?

    We use 'User Authentication' to restrict web surfing.
    As far as I know using squid as mail relay could not happen, if you use authentication, even if anybody is allowed to connect to the proxy, correct?

    It might not bet very pretty, that every internal user can use the proxy to connect to the outside, but hey, my internal user have 'internal LAN' 'Any' 'Any' 'Allow', so who cares anyway.  [;)] 

    In my opinion this is not a 'big hole' neither a 'vulnerability' just a tolerant configuration.
    But everybody should decide for himself.

    kind regards
    pet
  • 0 in reply to Peter Miller
    Oh yes, I've seen too many things. Proxies open to anyone even count as harmless here.

    And yes, if you have "internal - any - any" and only  allow internals to access the proxy, then you have nothing lost. IMHO such an open policy is at least discussable for business applications. 

    OTOH if you have to restrict your "specialists" (i.e. stubborn users) to mandatory use of HTTP via anti-virus, SMTP via the virus-protected gateway, and especially no P2P software, then you'll have a policy too open with the unrestricted proxy.
  • 0 in reply to vtanger
    Thanks for fixing this nasty hole in Squid.  Even though I had Transparent/Allow only for the internal net I was attacked from the outside and was used as a spam relay for half a day.  That was enough to get on a few blacklists and am still fixing the after effects.

    I put in a specific squid blocking filter on the outside interface and that stopped it until the latest updates fixed the hole itself.  I'll keep the filter in place.

    Clearly the "what isn't specificaly allowed is denied" policy isn't enough these days.  I filter for the most common attacks and junk like NetBios, KaZza, Squid, etc.