chan

朝生暮死不足笑 但悲百年不足道

chan.ink

【Django】继上次被恶意攻击恢复后再次被攻击

因为这个简单部署的一个测试应用，继续来看问题吧。

——————————————————————–

简单的排查已经轻车熟路了，不再赘述截图等

还是老样子，nginx和uwsgi全部趴下了，我重新启动了他们，但是单纯的重新启动，貌似不会直接恢复网站。还需要排查找到解决办法。

——————————————————————————————-

uwsgi –ini uwsgi.ini

使用这个命令，uwsgi的日志中，显示我用的是3.6.8版本的python，而且这次的报错，跟上次不同，不再是找不到django模块

先不看这个报错了，当务之急，是切到3.9.5，这是我当前的思路，操作

——————————————————————————

uwsgi –ini /www/wwwroot/day16/uwsgi.ini –pythonpath /www/wwwroot/day16/env/bin/python

我延续了上一次操作的记录，不过这显然不对，我最后解决也不是通过这样，而是在uwsgi的ini文件中加入

pythonpath = /www/wwwroot/day16/env/lib/python3.9/site-packages

不过，如今配置都已经正确的放在里面，为什么还是会错呢。

可惜添加了这个配置，后面如何执行uwsgi.ini的时候没有截图。我再来看下怎么弄的。

————————————————————————————————-

uwsgi –ini /www/wwwroot/day16/uwsgi.ini –pythonpath /www/wwwroot/day16/env/lib/python3.9/site-packages

瞎想的。。试试看吧

看下绑定关系

uwsgi –python-version

日志也的确是这样的。我晕。当时是怎么操作的呢。emmm

—————————————————————-

瞎想，难不成他进入了我的虚拟环境删除了相关配置么

进入虚拟环境，看起来一切正常

————————————————————————–

好奇无论去看了之前的uwsgi.log日志

不过有好多代理ip，上次有个用的很多的显示是缅甸，具体是哪里，不好说

返回200，但是没有登录的账户密码信息。是不是登录的不是我的程序，难道他进了我的后台，部署了自己的程序。

但是他后面又一直是302，是传说的让我这个做肉鸡作为跳转的意思么，没太懂

这是最后的记录信息，看起来像是删除了什么东西

总之，他并不是暴力破解登录导致的服务瘫痪。具体做了什么，不太清楚。

————————————————————————————————-

继续看我的问题吧

换个思路，先不想怎么切换python版本的问题，看下当前版本python报错的原因是什么

*** Operational MODE: preforking ***
added /www/wwwroot/day16/env/lib/python3.9/site-packages/ to pythonpath.
added /www/wwwroot/day16/env/lib/python3.9/site-packages/ to pythonpath.
Traceback (most recent call last):
  File "./day16/wsgi.py", line 12, in <module>
    from django.core.wsgi import get_wsgi_application
  File "/www/wwwroot/day16/env/lib/python3.9/site-packages/django/__init__.py", line 1, in <module>
    from django.utils.version import get_version
  File "/www/wwwroot/day16/env/lib/python3.9/site-packages/django/utils/version.py", line 7, in <module>
    from django.utils.regex_helper import _lazy_re_compile
  File "/www/wwwroot/day16/env/lib/python3.9/site-packages/django/utils/regex_helper.py", line 10, in <module>
    from django.utils.functional import SimpleLazyObject
  File "/www/wwwroot/day16/env/lib/python3.9/site-packages/django/utils/functional.py", line 265
    if (_wrapped := self._wrapped) is empty:
                 ^
SyntaxError: invalid syntax

以下贴一下GPT的解答

根据你提供的错误信息，SyntaxError: invalid syntax 出现在 django/utils/functional.py 文件的第 265 行，具体是由于 Python 3.9 不支持使用 :=（即海象运算符）在 Python 3.9 中出现了语法错误。

可能的原因：

  • 你使用的 Django 版本需要 Python 3.10 或更高版本，因为 := 运算符（海象运算符）是在 Python 3.10 中引入的。如果你使用的是 Python 3.9 版本，Django 的某些版本可能会尝试使用该运算符，导致语法错误。

解决方案：

  1. 升级 Python 版本： 如果可能，建议将你的 Python 环境升级到 3.10 或更高版本，这样可以避免出现这种语法错误。 你可以通过以下命令检查当前 Python 版本： python --version 如果 Python 版本过低，考虑将其升级到 3.10 或更高版本。例如，在使用 apt 包管理器的 Debian/Ubuntu 系统上： sudo apt update sudo apt install python3.10 升级后，你需要确保 uWSGI 和你的虚拟环境都使用新的 Python 版本。
  2. 安装兼容的 Django 版本： 如果升级 Python 版本不可行，你也可以通过安装一个兼容 Python 3.9 的 Django 版本来避免这个问题。你可以使用 pip 安装一个适合 Python 3.9 的 Django 版本。 假设你当前使用的是 Django 4.x 或更高版本，你可以降级到 Django 3.x： pip install 'django<4.0' 或者安装一个具体版本（比如 3.2.x）： pip install 'django==3.2'
  3. 检查并更新虚拟环境： 确保虚拟环境中安装了正确版本的依赖。你可以通过以下命令来更新环境中的所有依赖： pip install -r requirements.txt

总结：

  • 升级 Python 版本（建议使用 Python 3.10 或更高版本），或
  • 降级 Django 版本，使其兼容 Python 3.9。

这应该能解决你遇到的语法错误问题。如果你无法升级 Python，降级 Django 到 3.9 兼容的版本是一个快速的解决方案。

———————————————————————————————–

新突破

我将之前的uwsgi.ini移动到其他地方去了

之前的配置如下

[uwsgi]
# Django-related settings
module = day16.wsgi:application

pythonpath = /www/wwwroot/day16/env/lib/python3.9/site-packages


# The base directory (full path)
chdir = /www/wwwroot/day16

# The virtualenv (full path)
home = /www/wwwroot/day16/env
virtualenv =  /www/wwwroot/day16/env

# Process-related settings
master = true
processes = 2

# Socket file path
socket = /www/wwwroot/day16/uwsgi.sock

# Permissions for the socket file
chmod-socket = 660

# Set user and group
uid = nginx
gid = nginx

# Clear environment on exit
vacuum = true

# Daemonize the uWSGI process (log to a file)
daemonize = /www/wwwroot/day16/uwsgi.log

然后，GPT给的看法如下

你的 uWSGI 配置文件看起来已经很接近正确配置了，但有几个地方可能需要调整和检查，确保它完全正常工作。

主要的配置项分析和建议：

1. pythonpath 的配置

你设置了 pythonpath 来指定 site-packages 的路径，但在大多数情况下，uWSGI 会自动从虚拟环境中加载 Python 包。因此，你可以不需要显式指定 pythonpath，尤其是在你已经正确设置了 home 和 virtualenv 的情况下。

建议： 移除 pythonpath，让 uWSGI 自动使用虚拟环境的 site-packages：

# pythonpath = /www/wwwroot/day16/env/lib/python3.9/site-packages

2. virtualenv 和 home 配置

你同时设置了 home 和 virtualenv，虽然这两者都指向了相同的路径。通常来说，home 是用来设置虚拟环境路径的，而 virtualenv 参数则是告诉 uWSGI 使用该虚拟环境。

建议： 只保留 virtualenv 配置，移除 home 配置：

# home = /www/wwwroot/day16/env  # 移除这行
virtualenv = /www/wwwroot/day16/env

保持 virtualenv 即可，uWSGI 会自动识别该路径并使用虚拟环境。

3. module 配置

你已经正确地设置了 Django 的 WSGI 配置模块：

module = day16.wsgi:application

确保 day16.wsgi 中有 application 变量，通常它指向 Django 应用的 WSGI 应用对象。如果你不确定，检查 wsgi.py 文件：

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

4. socket 和 chmod-socket 配置

你指定了 socket 文件和权限：

socket = /www/wwwroot/day16/uwsgi.sock
chmod-socket = 660

确保你的 nginx 配置文件正确地指向该 Unix socket 文件，并且 nginx 用户对该文件具有正确的访问权限。如果不确定，可以先检查文件的权限：

ls -l /www/wwwroot/day16/uwsgi.sock

确保它对 nginx 用户可读写。

5. uid 和 gid 配置

你设置了 uid 和 gid 为 nginx，确保 nginx 用户和组确实存在并且拥有所需的权限。如果这些权限配置正确，则没有问题。

uid = nginx
gid = nginx

6. vacuum 配置

你启用了 vacuum，这会在进程退出时清理相关资源。通常这项配置是推荐的，保持不变即可。

vacuum = true

7. daemonize 配置

你指定了 daemonize，即将 uWSGI 进程放入后台并记录日志：

daemonize = /www/wwwroot/day16/uwsgi.log

确保 uwsgi.log 的路径是可写的，且你有权限创建日志文件。你可以通过以下命令检查：

touch /www/wwwroot/day16/uwsgi.log

如果没有权限，记得为该文件设置适当的权限。

8. processes 配置

你设置了 2 个进程，通常可以根据服务器的 CPU 核数来进行调整。例如，如果你有更多的 CPU 核心，可以增加进程数。

processes = 2

如果你有更多的核心，可以适当调整。

完整优化后的配置：

[uwsgi]
# Django-related settings
module = day16.wsgi:application

# The virtualenv (full path)
virtualenv = /www/wwwroot/day16/env

# The base directory (full path)
chdir = /www/wwwroot/day16

# Process-related settings
master = true
processes = 2

# Socket file path
socket = /www/wwwroot/day16/uwsgi.sock

# Permissions for the socket file
chmod-socket = 660

# Set user and group
uid = nginx
gid = nginx

# Clear environment on exit
vacuum = true

# Daemonize the uWSGI process (log to a file)
daemonize = /www/wwwroot/day16/uwsgi.log

总结：

  • 移除 pythonpath，让 uWSGI 自动从虚拟环境加载 Python 包。
  • 只保留 virtualenv 配置，移除 home。
  • 确保 nginx 配置正确地指向 uwsgi.sock，并且有足够的权限。
  • 检查日志文件的写权限。

这些调整应该能帮助你优化配置并避免潜在的问题。如果你完成这些修改后仍然遇到问题，记得查看 uwsgi.log 进行调试。

于是我按照gpt给我的配置，重新生成了ini文件，然后杀掉了之前的uwsgi进程，重新生成进程

然后再去看uwsgi的日志，跟以前的错误一样了

神奇。

我奇怪的是，为什么之前的可以正常工作呢。。

可见，我对于uwsgi的配置，还是没做到精通和了然于胸，还需精进

———————————————————

昨天家里又亲戚，没怎么看，今天12.15继续排查问题

由于，上次修复问题，没有正真彻底弄清切换到3.9.5python版本的原因，导致现在需要重新理一下

通过对比和灵感，我发现有此处问题

下图为之前可以运行3.9.5的uwsgi日志

下图为当前uwsgi运行有问题的对比日志

对比可以看到，执行的uwsgi位置是不一样的

通过观察，新的虚拟环境下，没有uwsgi命令，而之前的有。猜想可能是没有在指定的虚拟目录下找到，于是找了系统级下的uwsgi

以下是env的

下面为envs虚拟环境安装uwsgi

再去查看

可以看到，现在有了

再去尝试启动看下

可以看到uwsgi的启动位置对了，然后python的版本也对了。

由此，可知，是因为使用的uwsgi版本错误，默认使用了uwsgi的系统级命令，而非指定虚拟环境中的命令（因为对应的虚拟环境中没有uwsgi的命令）,以及，不是在虚拟环境下执行的uwsgi

所以，要正确使用指定环境的uwsgi，需要满足以下两点

1.激活对应的虚拟环境

2.对应的虚拟环境中安装了uwsgi

但是系统仍然报错，需要继续来看

————————————————————————————————————

再看看相关日志，先看下nginx的access.log

1.12.245.182 – – [15/Dec/2024:11:30:02 +0800] “GET /.env.bak HTTP/1.1” 502 157 “-” “Mozilla/5.0 (iPhone; CPU iPhone OS 17_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4.1 Mobile/15E148 Safari/604.1” “-“

请求信息分析

  • IP 地址：1.12.245.182
  • 时间：15/Dec/2024 11:30:02 +0800（2024年12月15日 11:30:02）
  • 请求方法：GET
  • 请求路径：/.env.bak
  • 协议版本：HTTP/1.1
  • 响应状态码：502（Bad Gateway，网关错误）
  • 响应大小：157 字节
  • User-Agent："Mozilla/5.0 (iPhone; CPU iPhone OS 17_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4.1 Mobile/15E148 Safari/604.1"

+0800 代表东八区时间（UTC+8小时），即该时间是在协调世界时（UTC）的基础上加上了8小时。这个时区通常适用于中国、新加坡、马来西亚、菲律宾等国家和地区。

———————————————————————————————–

莫名奇妙又好了。。 2024/12/15/15:06

————————————————————————————————–

相关阅读

  • 谷歌验证器

  • youtube视频下载教程

  • 手游跳转网址

  • 【转载】天涯论坛

  • QQ查询相关

  • QQ人脸冻结换绑手机号办法

  • 淘宝起链接

  • 话费冲QB

评论
还没有评论
    发表评论 说点什么