Weibin Yao | 27 Dec 03:25 2010
Picon

Re: DDoS protection module suggestion

ken107 at 2010-12-26 17:49 wrote:
> My friend's website promoting freedom of speech in communist Vietnam has
> recently been brought down by a 400k+ IP DDOS launched affirmatively by
> a government-sponsored cyber army.  I've been asked for some ideas, and
> have had some experienced warding off some minor DDOS on my own
> non-political website.
>
> Anyway, I've read this great discussion thread and came up with an idea
> that I think might work, especially for us individual webmasters who
> can't afford large distributed networks that can absorb such massive
> attacks.  It is as follows, please let me know your thoughts:
>
> 1. Use iptables to redirect all traffic to reCaptcha validation page
> - reCaptcha generation is handled by Google's distributed network
> designed to withstand DDOS
> - the reCaptcha validation page is therefore a static page and does not
> weigh down your server's processing power
>
> 2. Once validated, the IP is added to iptables Allow list, and the user
> is redirected back to homepage
> - entries that have been idle for some time should be removed from the
> list
>
>   
You also can use my nginx_secure_cookie_module(https: 
//github.com/yaoweibin/nginx_secure_cookie_module)to add some secure 
cookie after reCaptcha validation.
> Posted at Nginx Forum: http://forum.nginx.org/read.php?2,147105,161145#msg-161145
>
>
(Continue reading)

Jaap van Arragon | 27 Dec 09:06 2010

Fair Module

Hello,

Is there a possibility to check if the HttpUpstreamFairModule is installed right on our Nginx setup?

When we make a new setup to test the fair module it doesn’t load balance. We are using the fair module in combination with ip hash to keep the sessions alive.

We’ve tested it from several ip spaces but we always are thrown to the same web server.

Config upstream:

upstream testvip {
        fair default; #default weighted least-connection round robin
        #ip_hash;
        server xxx.xxx.xxx.xxx max_fails=5 fail_timeout=20s weight=3;
        server xxx.xxx.xxx.xxx max_fails=5 fail_timeout=20s weight=1 ;
    } #end upstream

Any ideas?

Thank you

Grt
Jaap
_______________________________________________
nginx mailing list
nginx@...
http://nginx.org/mailman/listinfo/nginx
Piotr Sikora | 27 Dec 10:08 2010

Re: Fair Module

Fair ModuleHi,

> Is there a possibility to check if the HttpUpstreamFairModule is installed 
> right on our Nginx setup?

You can check compile-time options with "nginx -V". They should contain 
something like "--add-module=/path/to/fair" if you've got "upstream_fair" 
installed... But you've got it, otherwise nginx would complain about unknown 
"fair" directive.

> We are using the fair module in combination with ip hash to keep the 
> sessions alive.

You can't do that. Load balancers ("ip_hash" & "fair") are exclusive, so you 
can't combine them.

> We’ve tested it from several ip spaces but we always are thrown to the 
> same web server.
>
> Config upstream:
>
> upstream testvip {
>         fair default; #default weighted least-connection round robin
>         #ip_hash;
>         server xxx.xxx.xxx.xxx max_fails=5 fail_timeout=20s weight=3;
>         server xxx.xxx.xxx.xxx max_fails=5 fail_timeout=20s weight=1 ;
>     } #end upstream
>
> Any ideas?

I don't recall details (maybe Grzegorz will chime in), but I believe that 
"upstream_fair" will try to return idle backend before falling back to 
least-connection round robin, which means that in limited testing 
environment with single connection, you would be always redirected to your 
first backend.

Best regards,
Piotr Sikora < piotr.sikora <at> frickle.com >

_______________________________________________
nginx mailing list
nginx <at> nginx.org
http://nginx.org/mailman/listinfo/nginx
Sylvain Rabot | 27 Dec 13:21 2010

underscores_in_headers not functioning when using default option for listen directive

Hi,

We are using nginx 0.7.68 and we encountered a small problem with the
underscores_in_headers directive.

Use case, 2 servers section :

server {
	listen 80 default;
	server_name *.domain.com;

	...
}

server {
	listen 80;
	server_name titi.domain-b.com;
	underscores_in_headers on;

	...
}

In that case the underscores_in_headers directive of the second server
is not taken care of. To make it work we have to either remove 'default'
option from the listen directive of the first server or add
'underscores_in_headers on' in the first server as well.

Regards.

--

-- 
Sylvain <sylvain.rabot@...>

_______________________________________________
nginx mailing list
nginx@...
http://nginx.org/mailman/listinfo/nginx

Maxim Dounin | 27 Dec 14:41 2010
Picon

Re: ipv4 & ipv6 Virtual Hosting - address in use

Hello!

On Sun, Dec 26, 2010 at 03:36:16PM -0500, petteyg359 wrote:

> ipv6only=on seems to behave the opposite of what it should. I have a
> default_server listening on all interfaces. It works fine using
> listen [::]:80 default_server;
> listen 80 default_server;
> 
> but if I do
> listen [::]:80 default_server ipv6only=on;
> listen 80 default_server;
> 
> then I get a bunch of errors about already bound addresses on startup.
> net.ipv6.bindv6only is set to 1.

Works ok here.

You may want to provide more details, i.e. exact nginx version you
are using, full config which triggers the problem and OS details.

Maxim Dounin

_______________________________________________
nginx mailing list
nginx@...
http://nginx.org/mailman/listinfo/nginx

Maxim Dounin | 27 Dec 14:48 2010
Picon

Re: underscores_in_headers not functioning when using default option for listen directive

Hello!

On Mon, Dec 27, 2010 at 01:21:14PM +0100, Sylvain Rabot wrote:

> Hi,
> 
> We are using nginx 0.7.68 and we encountered a small problem with the
> underscores_in_headers directive.
> 
> Use case, 2 servers section :
> 
> server {
> 	listen 80 default;
> 	server_name *.domain.com;
> 
> 	...
> }
> 
> server {
> 	listen 80;
> 	server_name titi.domain-b.com;
> 	underscores_in_headers on;
> 
> 	...
> }
> 
> In that case the underscores_in_headers directive of the second server
> is not taken care of.

This is expected.  Header parsing happens in context of default 
server, before server_name matching (as server_name matching 
requires parsing Host header).

> To make it work we have to either remove 'default'
> option from the listen directive of the first server or add
> 'underscores_in_headers on' in the first server as well.

Just removing "default" from the first server won't help, as first 
defined server (for the listen socket in question) will be 
implicitly selected as default anyway.  Otherwise correct.

Maxim Dounin

_______________________________________________
nginx mailing list
nginx@...
http://nginx.org/mailman/listinfo/nginx

letgohome | 27 Dec 15:06 2010
Picon

Re: How to configure without extension on nginx

IE is successful , the test file is download with chrome, why?

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,161032,161427#msg-161427

_______________________________________________
nginx mailing list
nginx@...
http://nginx.org/mailman/listinfo/nginx

Sylvain Rabot | 27 Dec 15:38 2010

Re: underscores_in_headers not functioning when using default option for listen directive

On Mon, 2010-12-27 at 15:48 +0200, Maxim Dounin wrote:
> Hello!
> 
> On Mon, Dec 27, 2010 at 01:21:14PM +0100, Sylvain Rabot wrote:
> 
> > Hi,
> > 
> > We are using nginx 0.7.68 and we encountered a small problem with the
> > underscores_in_headers directive.
> > 
> > Use case, 2 servers section :
> > 
> > server {
> > 	listen 80 default;
> > 	server_name *.domain.com;
> > 
> > 	...
> > }
> > 
> > server {
> > 	listen 80;
> > 	server_name titi.domain-b.com;
> > 	underscores_in_headers on;
> > 
> > 	...
> > }
> > 
> > In that case the underscores_in_headers directive of the second server
> > is not taken care of.
> 
> This is expected.  Header parsing happens in context of default 
> server, before server_name matching (as server_name matching 
> requires parsing Host header).

It makes sense. So shouldn't this directive be in the 'http'
configuration section only ?

> 
> > To make it work we have to either remove 'default'
> > option from the listen directive of the first server or add
> > 'underscores_in_headers on' in the first server as well.
> 
> Just removing "default" from the first server won't help, as first 
> defined server (for the listen socket in question) will be 
> implicitly selected as default anyway.  Otherwise correct.
> 
> Maxim Dounin

--

-- 
Sylvain <sylvain.rabot@...>

_______________________________________________
nginx mailing list
nginx@...
http://nginx.org/mailman/listinfo/nginx

Maxim Dounin | 27 Dec 16:18 2010
Picon

Re: underscores_in_headers not functioning when using default option for listen directive

Hello!

On Mon, Dec 27, 2010 at 03:38:10PM +0100, Sylvain Rabot wrote:

> On Mon, 2010-12-27 at 15:48 +0200, Maxim Dounin wrote:
> > Hello!
> > 
> > On Mon, Dec 27, 2010 at 01:21:14PM +0100, Sylvain Rabot wrote:
> > 
> > > Hi,
> > > 
> > > We are using nginx 0.7.68 and we encountered a small problem with the
> > > underscores_in_headers directive.
> > > 
> > > Use case, 2 servers section :
> > > 
> > > server {
> > > 	listen 80 default;
> > > 	server_name *.domain.com;
> > > 
> > > 	...
> > > }
> > > 
> > > server {
> > > 	listen 80;
> > > 	server_name titi.domain-b.com;
> > > 	underscores_in_headers on;
> > > 
> > > 	...
> > > }
> > > 
> > > In that case the underscores_in_headers directive of the second server
> > > is not taken care of.
> > 
> > This is expected.  Header parsing happens in context of default 
> > server, before server_name matching (as server_name matching 
> > requires parsing Host header).
> 
> It makes sense. So shouldn't this directive be in the 'http'
> configuration section only ?

No, it's still usable at server{} level for separate listen sockets 
(i.e. non-virtual servers).  Consider the following example:

server {
    listen 127.0.0.1:80;
    underscores_in_headers on;
    ...
}

server {
    listen 80;
    ...
}

Maxim Dounin

_______________________________________________
nginx mailing list
nginx@...
http://nginx.org/mailman/listinfo/nginx

petteyg359 | 27 Dec 16:55 2010
Picon

Re: ipv4 & ipv6 Virtual Hosting - address in use

Linux 2.6.34-gentoo-r12 x86_64 Intel(R) Core(TM) i7 CPU 930  <at>  2.80GHz
GenuineIntel GNU/Linux
 # nginx -V
nginx version: nginx/0.8.53
TLS SNI support enabled
configure arguments: --prefix=/usr --sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error_log --pid-path=/var/run/nginx.pid
--lock-path=/var/lock/nginx.lock --user=nginx --group=nginx
--with-cc-opt=-I/usr/include --with-ld-opt=-L/usr/lib
--http-log-path=/var/log/nginx/access_log
--http-client-body-temp-path=/var/tmp/nginx/client
--http-proxy-temp-path=/var/tmp/nginx/proxy
--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi
--http-scgi-temp-path=/var/tmp/nginx/scgi
--http-uwsgi-temp-path=/var/tmp/nginx/uwsgi --with-ipv6 --with-pcre
--without-http_autoindex_module --without-http_browser_module
--without-http_charset_module --without-http_geo_module
--without-http_map_module --without-http_memcached_module
--without-http_referer_module --without-http_ssi_module
--without-http_split_clients_module --without-http_userid_module
--with-http_realip_module --with-http_ssl_module
--without-mail_imap_module --without-mail_pop3_module
--without-mail_smtp_module

server {
listen [::]:80 default_server;
listen 80 default_server;
return 444;
}
#According to docs, this config should fail, because without
ipv6only=on,
#this line should automatically listen on ipv4 interfaces also.
 # netstat -lp | grep nginx
tcp        0      0 *:http                  *:*                    
LISTEN      31704/nginx.conf
tcp6       0      0 [::]:http               [::]:*                 
LISTEN      31704/nginx.conf

server {
listen [::]:80 default_server ipv6only=on;
return 444;
}
#I remove the listen 80 line, and add ipv6only=on
 # /etc/init.d/nginx start
 * Checking nginx' configuration ...
the configuration file /etc/nginx/nginx.conf syntax is ok
configuration file /etc/nginx/nginx.conf test is successful             

                                                       [ ok ]
 * Starting nginx ...
[emerg]: bind() to [2a01:4f8:130:9101::3]:80 failed (98: Address already
in use)
[emerg]: bind() to [2a01:4f8:130:9101::3]:80 failed (98: Address already
in use)
[emerg]: bind() to [2a01:4f8:130:9101::3]:80 failed (98: Address already
in use)
[emerg]: bind() to [2a01:4f8:130:9101::3]:80 failed (98: Address already
in use)
[emerg]: bind() to [2a01:4f8:130:9101::3]:80 failed (98: Address already
in use)
[emerg]: still could not bind()
 * start-stop-daemon: failed to start `/usr/sbin/nginx'
 * Failed to start nginx                                                

                                                       [ !! ]
 * ERROR: nginx failed to start

Not only does it not work as described, it seems to be trying to bind a
specific address multiple times, and maybe succeeding the first time,
because there's nothing else running on any interface port 80, so it
fails since it can't successfully bind the same address a second time.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,154862,161461#msg-161461

_______________________________________________
nginx mailing list
nginx@...
http://nginx.org/mailman/listinfo/nginx


Gmane