Using Varnish to protect Apache against slowloris - Revision history

Tykling at 02:36, 11 November 2010

2010-11-11T02:36:15Z

← Older revision		Revision as of 02:36, 11 November 2010
Line 1:		Line 1:
	[[Category:Apache]]		[[Category:Apache]]
	[[Category:Varnish]]		[[Category:Varnish]]
	'''THIS INFORMATION IS MOSTLY OUTDATED SINCE APACHE NOW CONTAINS A MODULE CALLED [http://httpd.apache.org/docs/2.2/mod/mod_reqtimeout.html MOD_REQTIMEOUT] THAT HANDLES THIS PROBLEM.'''		'''THIS INFORMATION IS MOSTLY OUTDATED SINCE APACHE NOW CONTAINS A MODULE CALLED [http://httpd.apache.org/docs/2.2/mod/mod_reqtimeout.html MOD_REQTIMEOUT] THAT HANDLES THIS PROBLEM.''' --[[User:Tykling\|Tykling]] 02:36, 11 November 2010 (UTC)

	In June 2009 a tool called [http://ha.ckers.org/blog/20090617/slowloris-http-dos/ slowloris] was created that makes it trivial for any script kiddie to tie up all the available connections on [http://www.apache.org/ Apache] and other web servers.		In June 2009 a tool called [http://ha.ckers.org/blog/20090617/slowloris-http-dos/ slowloris] was created that makes it trivial for any script kiddie to tie up all the available connections on [http://www.apache.org/ Apache] and other web servers.

Tykling at 02:33, 11 November 2010

2010-11-11T02:33:48Z

← Older revision		Revision as of 02:33, 11 November 2010
Line 1:		Line 1:
	[[Category:Apache]]		[[Category:Apache]]
	[[Category:Varnish]]		[[Category:Varnish]]
	'''THIS INFORMATION IS MOSTLY OUTDATED SINCE APACHE CONTAINS A MODULE CALLED MOD_REQTIMEOUT THAT HANDLES THIS PROBLEM.'''		'''THIS INFORMATION IS MOSTLY OUTDATED SINCE APACHE NOW CONTAINS A MODULE CALLED [http://httpd.apache.org/docs/2.2/mod/mod_reqtimeout.html MOD_REQTIMEOUT] THAT HANDLES THIS PROBLEM.'''

	In June 2009 a tool called [http://ha.ckers.org/blog/20090617/slowloris-http-dos/ slowloris] was created that makes it trivial for any script kiddie to tie up all the available connections on [http://www.apache.org/ Apache] and other web servers.		In June 2009 a tool called [http://ha.ckers.org/blog/20090617/slowloris-http-dos/ slowloris] was created that makes it trivial for any script kiddie to tie up all the available connections on [http://www.apache.org/ Apache] and other web servers.

Tykling at 02:32, 11 November 2010

2010-11-11T02:32:30Z

← Older revision		Revision as of 02:32, 11 November 2010
Line 1:		Line 1:
	[[Category:Apache]]		[[Category:Apache]]
	[[Category:Varnish]]		[[Category:Varnish]]
			'''THIS INFORMATION IS MOSTLY OUTDATED SINCE APACHE CONTAINS A MODULE CALLED MOD_REQTIMEOUT THAT HANDLES THIS PROBLEM.'''

	In June 2009 a tool called [http://ha.ckers.org/blog/20090617/slowloris-http-dos/ slowloris] was created that makes it trivial for any script kiddie to tie up all the available connections on [http://www.apache.org/ Apache] and other web servers.		In June 2009 a tool called [http://ha.ckers.org/blog/20090617/slowloris-http-dos/ slowloris] was created that makes it trivial for any script kiddie to tie up all the available connections on [http://www.apache.org/ Apache] and other web servers.

Tykling at 17:07, 7 July 2009

2009-07-07T17:07:47Z

← Older revision		Revision as of 17:07, 7 July 2009
Line 1:		Line 1:
	[[Category:Apache]]		[[Category:Apache]]
			[[Category:Varnish]]
	In June 2009 a tool called [http://ha.ckers.org/blog/20090617/slowloris-http-dos/ slowloris] was created that makes it trivial for any script kiddie to tie up all the available connections on [http://www.apache.org/ Apache] and other web servers.		In June 2009 a tool called [http://ha.ckers.org/blog/20090617/slowloris-http-dos/ slowloris] was created that makes it trivial for any script kiddie to tie up all the available connections on [http://www.apache.org/ Apache] and other web servers.

Tykling at 14:17, 7 July 2009

2009-07-07T14:17:28Z

← Older revision		Revision as of 14:17, 7 July 2009
Line 110:		Line 110:

	=== Apache client IP 127.0.0.1 problem ===		=== Apache client IP 127.0.0.1 problem ===
	One important thing remains: All requests seen by Apache now look like they come from 127.0.0.1. This needs to be fixed in the logs obviously, so I can look at [http://awstats.sourceforge.net/ awstats] when I have a hangover. But more importantly (or less, depending on the content Apache is serving) the other Apache modules (like mod_php) also see 127.0.0.1 as the client IP. If you are running an application that somehow uses $_SERVER['REMOTE_ADDR'] then the application might run into problems when all clients suddently have the same 127.0.0.1 remote address. If this is of no importance to you, like if you are only serving static HTML content, you ''can'' fix just the logging. On the other hand, fixing the problem completely is easier than just fixing the logging, although it does require the installation of an additional Apache module. Good thing we have ports.		One important thing remains: All requests seen by Apache now look like they come from 127.0.0.1. This needs to be fixed in the logs obviously, so I can look at [http://awstats.sourceforge.net/ awstats] when I have a hangover. But more importantly (or less, depending on the content Apache is serving) the other Apache modules (like mod_php) also see 127.0.0.1 as the client IP. If you are running an application that somehow uses $_SERVER['REMOTE_ADDR'] then the application might run into problems when all clients suddently have the same 127.0.0.1 remote address. If this is of no importance to you, like if you are only serving static HTML content, you ''can'' fix just the logging. On the other hand, fixing the problem completely is easier than just fixing the logging, although it does require the installation of an additional Apache module. Good thing we have ports to make that part easy.

			To recap, you need to do one of two things:
			* Fix the Apache client IP problem with mod_rpaf2 (recommended)
			'''or'''
			* Fix the Apache client IP logging only (not recommended)

			Continue with the relevant section below.

	==== Fixing the Apache client IP problem with mod_rpaf2 (recommended) ====		==== Fixing the Apache client IP problem with mod_rpaf2 (recommended) ====

Tykling: /* Apache client IP 127.0.0.1 problem */

2009-06-24T21:50:18Z

Apache client IP 127.0.0.1 problem

← Older revision		Revision as of 21:50, 24 June 2009
Line 110:		Line 110:

	=== Apache client IP 127.0.0.1 problem ===		=== Apache client IP 127.0.0.1 problem ===
	One important thing remains: All requests seen by Apache now look like they come from 127.0.0.1. This needs to be fixed in the logs obviously, so I can look at awstats when I have a hangover. But more importantly (or less, depending on the content Apache is serving) the other Apache modules (like mod_php) also see 127.0.0.1 as the client IP. If you are running an application that somehow uses $_SERVER['REMOTE_ADDR'] then the application might run into problems when all clients suddently have the same 127.0.0.1 remote address. If this is of no importance to you, like if you are only serving static HTML content, you ''can'' fix just the logging. On the other hand, fixing the problem completely is easier than just fixing the logging, although it does require the installation of an additional Apache module. Good thing we have ports.		One important thing remains: All requests seen by Apache now look like they come from 127.0.0.1. This needs to be fixed in the logs obviously, so I can look at [http://awstats.sourceforge.net/ awstats] when I have a hangover. But more importantly (or less, depending on the content Apache is serving) the other Apache modules (like mod_php) also see 127.0.0.1 as the client IP. If you are running an application that somehow uses $_SERVER['REMOTE_ADDR'] then the application might run into problems when all clients suddently have the same 127.0.0.1 remote address. If this is of no importance to you, like if you are only serving static HTML content, you ''can'' fix just the logging. On the other hand, fixing the problem completely is easier than just fixing the logging, although it does require the installation of an additional Apache module. Good thing we have ports.

	==== Fixing the Apache client IP problem with mod_rpaf2 (recommended) ====		==== Fixing the Apache client IP problem with mod_rpaf2 (recommended) ====

Tykling at 21:38, 24 June 2009

2009-06-24T21:38:48Z

← Older revision		Revision as of 21:38, 24 June 2009
Line 71:		Line 71:
	The varnishd_storage directive tells varnish where to keep it's cache - this doesn't really matter for my purposes since I disabled all caching. But the folder should exists and be owned by www:www to keep Varnish happy (the default user Varnish runs under is the same as the default user for Apache, conveniently).		The varnishd_storage directive tells varnish where to keep it's cache - this doesn't really matter for my purposes since I disabled all caching. But the folder should exists and be owned by www:www to keep Varnish happy (the default user Varnish runs under is the same as the default user for Apache, conveniently).

	=== Configuring Apache ===		== Configuring Apache ==
	A few changes is neccesary in the Apache config to make this work. First I changed the port Apache listens on, so I changed the following things in httpd.conf:		A few changes is neccesary in the Apache config to make this work.

			=== Apache listen port ===
			First I changed the port Apache listens on, so I changed the following things in httpd.conf:
	<pre>		<pre>
	[tykling@harmony ~]$ grep -A 2 varnish /usr/local/etc/apache22/httpd.conf		[tykling@harmony ~]$ grep -A 2 varnish /usr/local/etc/apache22/httpd.conf
Line 105:		Line 108:
	</pre>		</pre>


			=== Apache client IP 127.0.0.1 problem ===
	One important thing remains: All requests seen by Apache now look like they come from 127.0.0.1. This needs to be fixed in the logs obviously, so I can look at awstats when I have a hangover. But more importantly (or less, depending on the content Apache is serving) the other Apache modules (like mod_php) also see 127.0.0.1 as the client IP. If you are running an application that somehow uses $_SERVER['REMOTE_ADDR'] then the application might run into problems when all clients suddently have the same 127.0.0.1 remote address. If this is of no importance to you, like if you are only serving static HTML content, you ''can'' fix just the logging. On the other hand, fixing the problem completely is easier than just fixing the logging, although it does require the installation of an additional Apache module. Good thing we have ports.		One important thing remains: All requests seen by Apache now look like they come from 127.0.0.1. This needs to be fixed in the logs obviously, so I can look at awstats when I have a hangover. But more importantly (or less, depending on the content Apache is serving) the other Apache modules (like mod_php) also see 127.0.0.1 as the client IP. If you are running an application that somehow uses $_SERVER['REMOTE_ADDR'] then the application might run into problems when all clients suddently have the same 127.0.0.1 remote address. If this is of no importance to you, like if you are only serving static HTML content, you ''can'' fix just the logging. On the other hand, fixing the problem completely is easier than just fixing the logging, although it does require the installation of an additional Apache module. Good thing we have ports.

Tykling at 21:36, 24 June 2009

2009-06-24T21:36:57Z

@@ Line 105: / Line 105: @@
 </pre>
-One important thing remains. The Apache logging is currently set to something like this in my Apache configs:
+One important thing remains: All requests seen by Apache now look like they come from 127.0.0.1. This needs to be fixed in the logs obviously, so I can look at awstats when I have a hangover. But more importantly (or less, depending on the content Apache is serving) the other Apache modules (like mod_php) also see 127.0.0.1 as the client IP. If you are running an application that somehow uses $_SERVER['REMOTE_ADDR'] then the application might run into problems when all clients suddently have the same 127.0.0.1 remote address. If this is of no importance to you, like if you are only serving static HTML content, you ''can'' fix just the logging. On the other hand, fixing the problem completely is easier than just fixing the logging, although it does require the installation of an additional Apache module. Good thing we have ports.
 <pre>
 CustomLog "|/usr/local/sbin/cronolog --symlink=/usr/local/www/logs/wiki.tyk.nu-access.log /usr/local/www/logs/wiki.tyk.nu-access-%Y%m%d.log" combined

Tykling at 19:32, 24 June 2009

2009-06-24T19:32:10Z

← Older revision		Revision as of 19:32, 24 June 2009
Line 1:		Line 1:
			[[Category:Apache]]
	In June 2009 a tool called [http://ha.ckers.org/blog/20090617/slowloris-http-dos/ slowloris] was created that makes it trivial for any script kiddie to tie up all the available connections on [http://www.apache.org/ Apache] and other web servers.		In June 2009 a tool called [http://ha.ckers.org/blog/20090617/slowloris-http-dos/ slowloris] was created that makes it trivial for any script kiddie to tie up all the available connections on [http://www.apache.org/ Apache] and other web servers.

Tykling: /* Configuring Varnish */

2009-06-24T19:04:18Z

Configuring Varnish

← Older revision		Revision as of 19:04, 24 June 2009
Line 50:		Line 50:
	#		#
	# Set timeout for all objects to 0 seconds. This defeats the purpose of running a cache,		# Set timeout for all objects to 0 seconds. This defeats the purpose of running a cache,
	# but this is for the added security only. This was the easiest way to preserve logging of all requests.		# but this is for the added security only.
			# This was the easiest way for me to preserve logging of all requests.
	#		#
	sub vcl_fetch {		sub vcl_fetch {