Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

240
Vistas
FreeTDS con Django causando denegación de servicio en SQL Server

Es un comportamiento bastante extraño que proviene de una parte desconocida de la aplicación.

Mi configuración:

  • Django
  • TDS gratis
  • Unixodbc
  • Django-pyodbc-azure
  • msql

La aplicación funcionará durante una cantidad de tiempo aparentemente aleatoria (generalmente de 2 a 3 minutos), luego dejará de responder y también lo hará el servidor SQL. Otras aplicaciones, incluso con otras cuentas, no pueden realizar ninguna solicitud a la base de datos.

El número de solicitudes explícitas de mi parte es 1 en ready() de la aplicación django para obtener algunos datos iniciales.

 def ready(self): from django.conf import settings from app.models import SomeModel try: settings.SomeModel_ID = SomeModel.objects.filter(identifier=settings.SomeIdentifier)[0].pk except: settings.SomeModel_ID = SomeModel.objects.create(identifier=settings.SomeIdentifier).pk

SQL Server Tracer registrará algunas solicitudes, pero nada inusual (bastante BatchStarted/BatchFinished).

Wireshark verá una cantidad increíble de paquetes moviéndose entre la aplicación y la base de datos (estamos hablando de +250 para un simple SELECCIONAR). Aquí tomé un ejemplo con algo de TCP pero +95% para los paquetes son TDS.

 5422 36.248815392 10.10.10.66 -> 10.10.10.103 TDS 183 TLS exchange 5423 36.249013989 10.10.10.103 -> 10.10.10.66 TDS 135 TLS exchange 5424 36.249427950 10.10.10.66 -> 10.10.10.103 TDS 135 TLS exchange 5425 36.250678349 10.10.10.103 -> 10.10.10.66 TCP 1514 [TCP segment of a reassembled PDU] 5426 36.250703683 10.10.10.103 -> 10.10.10.66 TDS 607 TLS exchange 5427 36.250856893 10.10.10.66 -> 10.10.10.103 TCP 66 1433 → 39348 [ACK] Seq=2816 Ack=5937 Win=131584 Len=0 TSval=148074754 TSecr=605610420 5428 36.253444263 10.10.10.66 -> 10.10.10.103 TDS 4215 TLS exchange 5429 36.253462203 10.10.10.103 -> 10.10.10.66 TCP 66 39348 → 1433 [ACK] Seq=5937 Ack=6965 Win=45440 Len=0 TSval=605610421 TSecr=148074754 5430 36.255551301 10.10.10.66 -> 10.10.10.103 TDS 4215 TLS exchange 5431 36.255572551 10.10.10.103 -> 10.10.10.66 TCP 66 39348 → 1433 [ACK]

Sé que la aplicación es la causa del DoS porque cerrarla restaura el acceso a la base de datos para todos al instante.

Al enumerar la conexión activa usando:

 SELECT DB_NAME(dbid) AS DBName, COUNT(dbid) AS NumberOfConnections, loginame FROM sys.sysprocesses GROUP BY dbid, loginame ORDER BY DB_NAME(dbid)

Solo se muestra una conexión.

No hay bucle de ningún tipo que ofrezca una explicación fácil para esto.

over 4 years ago · Santiago Trujillo
1 Respuestas
Responde la pregunta

0

Descubrimos que el problema ocurría al usar un grupo, independientemente de si usamos la conexión db dentro de la función, la creación de múltiples procesamientos secundarios estaba causando el problema. Para resolverlo, simplemente connection.close() antes de bifurcar el proceso.

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda