[SAC] ProjectsVM Upgrade Problem

Fri Feb 10 12:22:14 EST 2012

Thanks Chris,
great work.

Cheers,
Arnulf

On 02/10/2012 05:25 AM, christopher.schmidt at nokia.com wrote:
> Sorry, I'm behind on this, but it looks like something in the upgrade
> opened up the projects server as an open proxy, no? All of those requests
> are people using the OSGeo server as a proxy (typically for spam).
> 
> Typically, this happens when something is using a proxypass setting that
> is improperly configured, and allowing connections through that shouldn't
> be.
> 
> Specifically:
> 
> crschmidt at projects:/etc/apache2/mods-enabled$ diff -u /backup_projects_etc/apache2/mods-enabled/proxy.conf  proxy.conf
> --- /backup_projects_etc/apache2/mods-enabled/proxy.conf	2011-01-21 10:53:56.000000000 -0800
> +++ proxy.conf	2012-02-02 06:30:21.000000000 -0800
> @@ -1,20 +1,26 @@
>  <IfModule mod_proxy.c>
> -        #turning ProxyRequests on and allowing proxying from all may allow
> -        #spammers to use your proxy to send email.
>  
> -        ProxyRequests Off
> +# If you want to use apache2 as a forward proxy, uncomment the
> +# 'ProxyRequests On' line and the <Proxy *> block below.
> +# WARNING: Be careful to restrict access inside the <Proxy *> block.
> +# Open proxy servers are dangerous both to your network and to the
> +# Internet at large.
> +#
> +# If you only want to use apache2 as a reverse proxy/gateway in
> +# front of some web application server, you DON'T need
> +# 'ProxyRequests On'.
> +ProxyRequests On
> 
> 
> I have backed up the 'new' proxy.conf (after upgrade) to /backup_projects_etc/new_proxy.conf,
> and moved /backup_projects_etc/apache2/mods-enabled/proxy.conf into its place,
> and restarted Apache. In the short term, we should expect to continue to
> *get* these proxy requests until people realize that we're no longer 
> serving as an open proxy for spammers to use -- typically, this traffic
> will die down in 1-2 days, but they should consume very few resources now,
> because they should always be 403 Forbidden instead of actually working.
> 
> To address some of Martin's later comments:
>  - Yes, this is causing very little load on the system -- this is because
>    the traffic is not actually *using* the projects server for anything
>    other than a bandwidth pipe, all the actual activity is just proxying 
>    bytes.
>  - This default configuration from Debian is, in my opinion, So Completely
>    broken -- it basically makes any machine trying to use proxying a 
>    completely open proxy to the internet, which is So Very Wrong. 
> 
> Some example requests that are no longer able to use OSGeo as an open proxy:
> 
> 114.42.67.26 - - [10/Feb/2012:05:20:32 -0800] "CONNECT 203.188.197.119:25 HTTP/1.0" 405 477 "-" "-"
> 31.131.142.212 - - [10/Feb/2012:05:20:32 -0800] "GET http://www.kotakuclub.com/forum/index.php HTTP/1.0" 404 416 "http://www.kotakuclub.com/forum/index.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; FDM)"
> 
> 
>  - The fact that these were pointing to docs.geotools.org was just a side
>    effect of that being the default domain, though I'm sure
>    most people realized this.
> 
>  - The slow loading of the site was not caused by 'high load', but
>    by limited child workers due to all connections being sucked up
>    by people outside OSGeo using us as a proxy.
> 
> I've also temporarily bumped up the minspareservers, while we're
> still getting over the hump until we move off the 'spam through this'
> lists -- this will keep a slightly larger pool to handle bursts around.
> 
> While investigating this, I also found that the 'tilecache' config
> (/backup_projects_etc/apache2/sites-available/tilecache) was not enabled,
> which was resulting in double requests because of default configurations 
> of some OpenLayers applications. I re-enabled it -- I don't know if it being
> disabled was on purpose or not. If this was the wrong thing to do,
> let me know, and we can find another way to handle this. 
> 
> Overall, I hope this will help clarify the state we were in, how
> we got there (bad debian defaults; bad sysadminning on my part most likely
> for not documenting my change to the default configuration), why we
> got in that situation, what affect it had, and how I fixed it.
> 
> Let me know if this is unclear, and I can try to clarify.
> 
> -- Chris
> 
> 
> 
> On Feb 9, 2012, at 4:02 AM, ext Martin Spott wrote:
> 
>> On Thu, Feb 09, 2012 at 09:55:00AM +0100, Markus Neteler wrote:
>>
>>> As posted several times, the server is bombed with requests. Nothing
>>> strange at all.
>>> We have 200 workers or so and they are all saturated. That's why the performance
>>> is (too) low. I played shortly with 256 workers but then reduced again.
>>>
>>> Of course we have to solve this!
>>
>> Definitely.  Anyhow, developing a solution which may run unattended for
>> a while without doing more harm than good isn't *that* simple  ;-)
>> .... and I'm unaware of readily available solutions working right out
>> of the box.
>>
>> Cheers,
>> 	Martin.
>> -- 
>> Unix _IS_ user friendly - it's just selective about who its friends are !
>> --------------------------------------------------------------------------
>> _______________________________________________
>> Sac mailing list
>> Sac at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/sac
> 
> _______________________________________________
> Sac mailing list
> Sac at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/sac

-- 
President, OSGeo
http://www.osgeo.org