使用Django的FreeTDS导致SQL Server上的拒绝服务

时间:2017-04-24 21:40:34

标签: python sql-server django freetds

这是一个相当奇怪的行为来自应用程序的未知部分。

我的设置:

  • Django的
  • freetds的
  • 的unixODBC
  • 的django-pyodbc-天青
  • MS SQL

应用程序将在看似随机的时间(通常为2-3分钟)内工作,然后将停止响应,SQL Server也将如此。其他应用程序甚至与其他帐户无法对数据库进行任何请求。

我在django应用程序的 ready()中的显式请求数为1,以获取一些初始数据。

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会记录一些请求,但没有什么异常(很多BatchStarted / BatchFinished)。

Wireshark看到在应用程序和数据库之间移动的疯狂数据包(我们正在谈论+250用于简单的SELECT)。这里我举了一些TCP的例子但是+ 95%的数据包是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] 

我知道应用程序是DoS的原因,因为关闭它会立即恢复对每个人的访问权限。

使用以下方式列出活动连接时

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

仅列出一个连接。

没有任何类型的循环可以为此提供简单的解释。

1 个答案:

答案 0 :(得分:1)

我们发现使用Pool时出现问题,无论我们是否在函数内部使用数据库连接,创建多个子处理都会导致问题。为了解决这个问题,在分配过程之前只需connection.close()