Too many TCP connections

[shacker]

This is not a database connection question, but a TCP connection problem.

I've got two different Django sites on the same server (which I admin), each with their own similar vhosts and wsgi processes. The server uses ConfigServer firewall  for automatic detection and firewalling of bad behavior. 

On one of the sites,  a small amount of clicking around in the admin will cause that user's IP to be blocked with a message like:

DENY 128.33.33.123 * inout 29m 18s lfd - (CT) IP 128.33.33.123 (US/United States/[hostname]) found to have 670 connections

(IP / hostname changed). Those 670 open connections can be created by simply going to Users in the admin and clicking and saving seven User records in sequence. That's it - firewalled. On the other Django site on the same server, you can do that all day long with no problem.

I can sidestep the problem by changing the CT_LIMIT value in ConfigServer Firewall to a very high value or disabling it, but then I lose the DDOS protection it provides. Rather than work around it, I'd like to figure out what in the world is causing this one site to generate so many TCP connections during normal usage. But not sure where to begin.

Suggestions? Thanks.

[Cal Leeming [Simplicity Media Ltd]]

Only briefly read this email, but it could be due to keep alives not being enabled, along with lots of resources (images, css, js) etc being called.

Let me know if this helps

Cal

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/4U0mn30f9tgJ.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

[shacker]

Hmm, appreciate the feedback, but we don't have KeepAlives enabled on our Django servers and it's never been a problem. And remember, the other Django site on the same server doesn't have the problem. As for serving lots of resources - we're just talking about viewing/saving seven User pages in the Admin before we've built up over 600 open TCP connections. This is a small and very lightly trafficked site - just a little bit of Admin activity triggers this (it's not an end user problem either - I can reproduce it easily).

Thanks.

[Tomas Neme]

shot in the dark: aren't they connections to the database, maybe?

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/django-users/-/CDUJ8AzY-awJ.

> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

--
"The whole of Japan is pure invention. There is no such country, there
are no such people" --Oscar Wilde

|_|0|_|
|_|_|0|
|0|0|0|

(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.

[Baurzhan Ismagulov]

On Fri, Sep 02, 2011 at 12:16:41PM -0700, shacker wrote:
> On one of the sites, a small amount of clicking around in the admin will
> cause that user's IP to be blocked with a message like:

Is the firewall and the web server on the same host? First, I'd check
the destination port with netstat on the server. Then analyze the
requests (e.g., in web server logs -- if the critical mass is destined
for your http port, that is).

> I can sidestep the problem by changing the CT_LIMIT value in ConfigServer
> Firewall to a very high value or disabling it, but then I lose the DDOS
> protection it provides.

Does it address the scenario where the whole bandwidth to the firewall
is consumed by malicious requests?

With kind regards,
--
Baurzhan Ismagulov
http://www.kz-easy.com/

[shacker]

Thanks for all the responses on this. After watching the error logs on the production server I saw tons of infinite redirect loops on calls for admin_media:

"GET /admin_media/js/jqu///////////404.shtml/ HTTP/1.1" 302 -  ...

This wasn't immediately apparent since the admin *seemed* to look and work properly. But that prompted me to poke around in the vhost definition for the admin_media alias, and sure enough, discovered we had two copies of Django installed in the virualenv - one in src and one in lib/pythton2.7/site-packages.  The vhost alias for admin_media was pointing to the wrong version, so some of the admin media worked while some did not. 

Basically, all of those bad requests were opening TCP connections that never got closed... which the firewall's CT_LIMIT feature noticed and blocked. 

To fix, I corrected the admin_media alias in the vhost and deleted the old Django installation.

Thanks again.

[Cal Leeming [Simplicity Media Ltd]]

Lmao, nice.

Glad you got the issue resolved!

--

You received this message because you are subscribed to the Google Groups "Django users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/haoFj0tyzNIJ.