Strangers using my proxy!

papabear,

Astaro's HTTP proxy isn't intended to act as a reverse proxy - this seems to be a no go.

Greetings
cyclops
  

>Astaro's HTTP proxy isn't intended to act as a reverse proxy - this seems to be a no go.

Well, it is actually possible  

  The problem is that if you read the manual and the AST-default squid.conf-default, everything indicates that there will be no problem. The squid.conf-default has tokens like "http_accel_with_proxy on", which *is* a reverse proxy and an ordinary proxy, working together.

Now, when you get to the "ACCESS CONTROL" part of squid.conf-default, it says: "network cache access is set with packet filter, not squid ACLs". OK I said, the guys know what they are doing (and they usually do!), so I left the squid.conf and went to the "packet filter" in AST, where I blocked access to the defined service "SQUID" (port 8080) from "any", after having giving my private network the access. Now, everything should be in order. To get a reversed proxy working for normal access to the proxied webserver(s), is has to use port 80, so I guess it has to be acting in transparent mode(?) - anyway, that's what I like the best, so that's what I chose.

Then you (still in the HTTP-proxy-config) have to select the net(s) allowed to use the proxy. At first I chose only the internal net, but with this confiration the reversed proxy didn't work at all. Off course, I thought to my self - if you want the outside net to use the proxy, you have to include the outside net in "allowed nets" - and this showed up to be true ;-)  Now everything worked, and I had only used the AST-manager (not moved one comma by hand), so I was convinsed that no security holes were present.

Well, as we know now: I was wrong! Every single service I had allowed in the proxy was allowed for everybody from the outside. Biggest problem now is that I allowed SMTP, so my system has been abused for spammail for about 14 hours, until I was aware of the problem at stopped the proxy, and now I'm in all sorts of spam-lists  [:$]et out of.

For the record: This is not to make any blame to the AST-team, just to inform about a possibility to an unwanted AST-setup.

Now, here is my workaround, that I suppose the AST-team could make use of the next (or next ;-) version (well, maybe they can do better, but this one is for starters).

AST reversed proxy with HTTP-cache HOW-TO:
=============================
(squish.conf-default):
# My web-server:
acl acceeratedhost dst xxx.xxx.xxx.xxx/255.255.255.255

# Every other host:
acl otherhosts dst 0.0.0.0/0.0.0.0

# My secure nets:
acl mynet_1 src 192.168.1.0/255.255.255.0
acl mynet_2 src 192.168.2.0/255.255.255.0

# My VPN:
acl tunnel src 10.xxx.xxx.0/255.255.255.0

http_access allow acceleratedhost all
http_access allow mynet_1 otherhosts
http_access allow mynet_2 otherhosts
http_access allow tunnel otherhosts

http_access allow mynet_1
http_access allow mynet_2
http_access allow tunnel
http_access deny all

===============================

That's it and that's that.

I guess there will be more sophisticated ways of doing the squid.conf-default, but this one works  [:)]

PapaBear    

>Astaro's HTTP proxy isn't intended to act as a reverse proxy - this seems to be a no go.

Well, it is actually possible  

  The problem is that if you read the manual and the AST-default squid.conf-default, everything indicates that there will be no problem. The squid.conf-default has tokens like "http_accel_with_proxy on", which *is* a reverse proxy and an ordinary proxy, working together.

Now, when you get to the "ACCESS CONTROL" part of squid.conf-default, it says: "network cache access is set with packet filter, not squid ACLs". OK I said, the guys know what they are doing (and they usually do!), so I left the squid.conf and went to the "packet filter" in AST, where I blocked access to the defined service "SQUID" (port 8080) from "any", after having giving my private network the access. Now, everything should be in order. To get a reversed proxy working for normal access to the proxied webserver(s), is has to use port 80, so I guess it has to be acting in transparent mode(?) - anyway, that's what I like the best, so that's what I chose.

Then you (still in the HTTP-proxy-config) have to select the net(s) allowed to use the proxy. At first I chose only the internal net, but with this confiration the reversed proxy didn't work at all. Off course, I thought to my self - if you want the outside net to use the proxy, you have to include the outside net in "allowed nets" - and this showed up to be true ;-)  Now everything worked, and I had only used the AST-manager (not moved one comma by hand), so I was convinsed that no security holes were present.

Well, as we know now: I was wrong! Every single service I had allowed in the proxy was allowed for everybody from the outside. Biggest problem now is that I allowed SMTP, so my system has been abused for spammail for about 14 hours, until I was aware of the problem at stopped the proxy, and now I'm in all sorts of spam-lists  [:$]et out of.

For the record: This is not to make any blame to the AST-team, just to inform about a possibility to an unwanted AST-setup.

Now, here is my workaround, that I suppose the AST-team could make use of the next (or next ;-) version (well, maybe they can do better, but this one is for starters).

AST reversed proxy with HTTP-cache HOW-TO:
=============================
(squish.conf-default):
# My web-server:
acl acceeratedhost dst xxx.xxx.xxx.xxx/255.255.255.255

# Every other host:
acl otherhosts dst 0.0.0.0/0.0.0.0

# My secure nets:
acl mynet_1 src 192.168.1.0/255.255.255.0
acl mynet_2 src 192.168.2.0/255.255.255.0

# My VPN:
acl tunnel src 10.xxx.xxx.0/255.255.255.0

http_access allow acceleratedhost all
http_access allow mynet_1 otherhosts
http_access allow mynet_2 otherhosts
http_access allow tunnel otherhosts

http_access allow mynet_1
http_access allow mynet_2
http_access allow tunnel
http_access deny all

===============================

That's it and that's that.

I guess there will be more sophisticated ways of doing the squid.conf-default, but this one works  [:)]

PapaBear    

papabear,

I have to relativize it is a no go with WebAdmin    [;)]
Thanks a lot for the detailed instruction !

Greetings
cyclops