安安 - tcp
type: channel
link: https://blog.90.vc/tag/tcp/
items: linux防御DDOS相关
items: HTTP 代理原理及实现（一）

linux防御DDOS相关
type: item
date: 2018-11-01T10:01:00+00:00
description: 一 . iptables限制单个IP并发TCP连接。1.1 限制单个IP并发TCP连接的方法适应于保护Linux上的各种TCP服务，使用iptables 中patch-o-matic中iplimit补丁来实现，对各种TCP服务比较通用。配置Linux核心，使用2.4.20，并使用www.netfilter.org 中patch-o-matic中的 base补丁中的iplimit。编译配置安装新核心。 使用www.netfilter.org 的 iptables 1.2.8，安装到系统中。 不过，现在一般kernel都是2.6以上了，iptables都是v1.3.5，此问题不用担心。1.2 实现细节：限制连往本机的web服务，1个C段的IP的并发连接不超过100个，超过的被拒绝： iptables -I INPUT -p tcp --dport 80 -m iplimit --iplimit-above 100 --iplimit-mask 24 -j REJECT延伸例子：限制连往本机的telnet单个IP并发连接为2个，超过的连接被拒绝： iptables -I INPUT -p tcp --dport 23 -m iplimit --iplimit-above 2 -j REJECT1.3 防止同步包洪水（Sync Flood） iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT也可以写作 iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT–limit 1/s 限制syn并发数每秒1次，可以根据自己的需要修改防止各种端口扫描 iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPTPing洪水攻击（Ping of Death） iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT二 . 内核优化通过修改内核参数或使用TCP Cookie技术只能在一定程度上减轻SYN Flood攻击的影响，但是加大了服务器的负担，但是可以减缓被拒绝攻击，实现细节：#sysctl -a | grep syn net.ipv4.tcp_max_syn_backlog = 1024 net.ipv4.tcp_syncookies = 0 net.ipv4.tcp_synack_retries = 5 net.ipv4.tcp_syn_retries = 5tcp_max_syn_backlog是SYN队列的长度，tcp_syncookies是一个开关，是否打开SYN Cookie功能，该功能可以防止部分SYN攻击。tcp_synack_retries和tcp_syn_retries定义SYN的重试次数。加大SYN队列长度可以容纳更多等待连接的网络连接数，打开SYN Cookie功能可以阻止部分SYN攻击，降低重试次数也有一定效果。调整上述设置的方法是：增加SYN队列长度到2048： sysctl -w net.ipv4.tcp_max_syn_backlog=2048打开SYN COOKIE功能： sysctl -w net.ipv4.tcp_syncookies=1降低重试次数：sysctl -w net.ipv4.tcp_synack_retries=3 sysctl -w net.ipv4.tcp_syn_retries=3

HTTP 代理原理及实现（一）
type: item
date: 2018-11-01T05:44:00+00:00
description: Web 代理是一种存在于网络中间的实体，提供各式各样的功能。现代网络系统中，Web 代理无处不在。我之前有关 HTTP 的博文中，多次提到了代理对 HTTP 请求及响应的影响。今天这篇文章，我打算谈谈 HTTP 代理本身的一些原理，以及如何用 Node.js 快速实现代理。HTTP 代理存在两种形式，分别简单介绍如下：第一种是 RFC 7230 - HTTP/1.1: Message Syntax and Routing（即修订后的 RFC 2616，HTTP/1.1 协议的第一部分）描述的普通代理。这种代理扮演的是「中间人」角色，对于连接到它的客户端来说，它是服务端；对于要连接的服务端来说，它是客户端。它就负责在两端之间来回传送 HTTP 报文。第二种是 Tunneling TCP based protocols through Web proxy servers（通过 Web 代理服务器用隧道方式传输基于 TCP 的协议）描述的隧道代理。它通过 HTTP 协议正文部分（Body）完成通讯，以 HTTP 的方式实现任意基于 TCP 的应用层协议代理。这种代理使用 HTTP 的 CONNECT 方法建立连接，但 CONNECT 最开始并不是 RFC 2616 - HTTP/1.1 的一部分，直到 2014 年发布的 HTTP/1.1 修订版中，才增加了对 CONNECT 及隧道代理的描述，详见 RFC 7231 - HTTP/1.1: Semantics and Content。实际上这种代理早就被广泛实现。本文描述的第一种代理，对应《HTTP 权威指南》一书中第六章「代理」；第二种代理，对应第八章「集成点：网关、隧道及中继」中的 8.5 小节「隧道」。普通代理第一种 Web 代理原理特别简单：HTTP 客户端向代理发送请求报文，代理服务器需要正确地处理请求和连接（例如正确处理 Connection: keep-alive），同时向服务器发送请求，并将收到的响应转发给客户端。下面这张图片来自于《HTTP 权威指南》，直观地展示了上述行为：假如我通过代理访问 A 网站，对于 A 来说，它会把代理当做客户端，完全察觉不到真正客户端的存在，这实现了隐藏客户端 IP 的目的。当然代理也可以修改 HTTP 请求头部，通过 X-Forwarded-IP 这样的自定义头部告诉服务端真正的客户端 IP。但服务器无法验证这个自定义头部真的是由代理添加，还是客户端修改了请求头，所以从 HTTP 头部字段获取 IP 时，需要格外小心。这部分内容可以参考我之前的《HTTP 请求头中的 X-Forwarded-For》这篇文章。给浏览器显式的指定代理，需要手动修改浏览器或操作系统相关设置，或者指定 PAC（Proxy Auto-Configuration，自动配置代理）文件自动设置，还有些浏览器支持 WPAD（Web Proxy Autodiscovery Protocol，Web 代理自动发现协议）。显式指定浏览器代理这种方式一般称之为正向代理，浏览器启用正向代理后，会对 HTTP 请求报文做一些修改，来规避老旧代理服务器的一些问题，这部分内容可以参考我之前的《Http 请求头中的 Proxy-Connection》这篇文章。还有一种情况是访问 A 网站时，实际上访问的是代理，代理收到请求报文后，再向真正提供服务的服务器发起请求，并将响应转发给浏览器。这种情况一般被称之为反向代理，它可以用来隐藏服务器 IP 及端口。一般使用反向代理后，需要通过修改 DNS 让域名解析到代理服务器 IP，这时浏览器无法察觉到真正服务器的存在，当然也就不需要修改配置了。反向代理是 Web 系统最为常见的一种部署方式，例如本博客就是使用 Nginx 的 proxy_pass 功能将浏览器请求转发到背后的 Node.js 服务。了解完第一种代理的基本原理后，我们用 Node.js 实现一下它。只包含核心逻辑的代码如下：var http = require('http'); var net = require('net'); var url = require('url'); function request(cReq, cRes) { var u = url.parse(cReq.url); var options = { hostname : u.hostname, port : u.port || 80, path : u.path, method : cReq.method, headers : cReq.headers }; var pReq = http.request(options, function(pRes) { cRes.writeHead(pRes.s…