网站被黑客攻击了，该怎么办

关注

原创最新推荐文章于 2026-07-06 08:18:01 发布 509 阅读 AI 写同款· GEO 优化 ›

2021web安全最全学习路线，从入门到入职（含书籍、工具包）本次写的是一篇如何通过针对性系统学习Web安全或者说如何能成为一名渗透测试人员（有疑问或者错误的地方还望大家多多指正）。相信大家每学习一样东西的时候都是存在一种很迷茫的心态（包括我自己），上网找视频找文章找资料学习得零零散散，最后还是浪费时间只得到一身三脚猫功夫。只有成体系的去学习、让自己的知识由点变成面，这样才能变得更强（文末附上书籍和工具包，希望大家查漏补缺，强中强）！ Web 安全主要包括 HTTP 协议、注入漏洞、XSS 漏洞、SSRF 漏洞、CSRF 漏洞、文件处理漏洞、访问控制漏洞、会阅读详情

最好的防御方式就是攻击知己知彼，百战不殆。掌握攻击者的套路才好顶得住攻击。

可能我的读者多少了解过Nginx，我先给不了解的同学简单说一下原理。已经了解的跳到第二节。

3分钟了解`Nginx`

Nginx是一款高性能的Web服务器和反向代理服务器。

它可以用来搭建网站、做应用服务器，能够处理大量的并发连接和请求。

静态内容托管（主要）：可以用来做网页、图片、文件的 “静态”内容托管。
动态内容托管（主要）：将经常访问的动态内容缓存到内存中，提高访问速度和性能。
反向代理（主要）：将客户端的请求发送到后端真实服务器，并将后端服务器的响应返回给客户端。

类似于一个快递收发室，指挥快递（流量）应该投递到哪个买家。

它还能提供一些高级功能：

负载均衡：将客户端的请求分发到多个后端服务器上，从而提高服务的可用性和性能。
SSL/TLS加密传输：通过加密和认证保护数据传输安全。
HTTP/2支持：通过多路复用技术提高并发连接处理能力和页面加载速度。
安全防护：提供多种防护机制，如限制IP访问、请求频率限制、反爬虫等。
动态内容处理：支持FastCGI、uWSGI等协议，与后端应用服务器进行动态内容交互。
日志记录：记录访问日志和错误日志，方便监控和排查问题。
自定义模块开发：支持自定义模块开发，可以根据需求进行二次开发和扩展。

读到这里，我知道很多人脑子都要爆了。现在让我们直入主题。结合以上功能的能做哪些攻击方式。

反向代理攻击

使用Nginx作为反向代理服务器，将攻击流量转发到目标服务器。这样就能隐藏攻击流量的真实地址。

server {
    listen 80;
    server_name www.example.com;
    location / {
        proxy_pass http://backend_server;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

所有访问www.example.com:80的流量全部都会转发到http://backend_server服务器上。
proxy_set_header X-Real-IP $remote_addr; 设置请求头提供真实来源ip。
proxy_set_header Host $host;设置访问的Host。

只要把X-Real-IP改成其他不存在的IP，就可以隐藏自己的真实IP地址，让攻击更难以被追踪和防御。当然相对于客户端来说，只能知道nginx的地址就不知道真实服务器的地址了。

DDoS攻击

DDoS攻击就是借助某些工具瞬间发动大量的请求，让服务器资源耗尽，无法正常响应其他用户的请求，一般也常用于压力测试。介绍一些常用的工具：

ApacheBench (ab)：常用的命令行工具，用于模拟多个并发请求。可以控制请求总数、并发数等参数。
Siege：命令行工具，和上面一样，并且还支持 HTTP 和 HTTPS 协议。
JMeter：一个功能强大的 Java 应用程序，可以用于模拟各种负载情况。JMeter 可以通过图形界面进行配置，支持更多协议和数据格式，包括 HTTP、HTTPS、SOAP、REST 等。

但事实往往比这个残酷，攻击者会做一些病毒，在网络上传播开来，病毒运行时可以直接疯狂访问服务器，或者利用Nginx提供的反向代理和其支持的比如socket、SSL，不断的建立握手请求。

限流、黑名单防御

小熊主要给大家介绍怎么防御。这种病毒感染方式就不说了，我害怕戴银手铐。

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;

    geo $block {
        default 0;
        include /path/to/block_ip.txt;
    }

    server {
        listen 80;

        location / {
            limit_req zone=one burst=10 nodelay;
            if ($block) {
                return 403;
            }
            proxy_pass http://backend;
        }
    }
}

limit_req_zone 定义了一个名为“one”的限制请求速率的区域，该区域的大小为10MB，请求速率限制为每秒5个请求。
limit_req 指定使用名为“one”的限制规则。
geo $block是黑名单，这个文件可以写需要屏蔽的ip。
server块中的location指令使用了limit_req和if表示黑名单的返回403状态码。

负载均衡防御

假设我有两个后端服务器。

http {
  upstream backend {
    # 轮询方式的负载均衡
    server backend1.example.com;
    server backend2.example.com;
  }
...
  server{...}
}

有多种负载均衡方式。

 server {
   ...
    location /api/ {
      # 轮训
      proxy_pass http://backend;
    }

    location /lb/ {
      # IP哈希方式的负载均衡
      ip_hash;
      proxy_pass http://backend;
    }

    location /upstream/ {
      # 根据服务器性能或响应时间进行加权轮询
      upstream backend {
        server backend1.example.com weight=2;
        server backend2.example.com;
      }
      # 对 backend 进行访问
      proxy_pass http://backend;
    }

    location /least_conn/ {
      # 最少连接数的负载均衡
      least_conn;
      proxy_pass http://backend;
    }

    location /random/ {
      # 随机方式的负载均衡
      random;
      proxy_pass http://backend;
    }

    location /sticky/ {
      # 基于客户端IP的哈希方式的负载均衡
      hash $remote_addr consistent;
      server backend1.example.com;
      server backend2.example.com;
    }
  }

很多人学nginx都会对ip_hash和基于客户端IP的哈希方式的负载均衡有疑惑。分不清，我一句话给大家讲清楚。

ip_hash能保证相同来源一定能访问相同的服务器，适用于登录等有状态的场景。在请求量少的时候，容易出现很多ip落在同一服务器上，分布不均衡。
基于客户端ip的hash，是根据客户端 IP 地址计算哈希值，然后将哈希值与后端服务器数量取模。使请求平均分配到不同的服务器上，也能保证同一ip请求落到同一服务器上。但是可以保证各个服务器比较均衡。

我认为使用方式二更好，可能理解有限，欢迎各位读者分享自己的看法！

网络钓鱼攻击

黑客可以使用Nginx伪装成一个合法的网站，诱骗用户输入敏感信息。例如，他们可以使用Nginx构造一个伪造的登录页面，让用户输入用户名和密码，然后将这些信息发送给黑客服务器。

其实就是静态托管+反向代理功能的组合。

server {
    listen       80;
    server_name  example.com;

    # 静态网站托管
    location / {
        root   /var/www/mywebsite/dist;
        index  index.html index.htm;
    }

    # API代理转发
    location /api {
        proxy_pass  http://localhost:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}