2024年你不知道的tcp半连接、全连接知识都在这了,2024年最新不愧是Alibaba技术官
在实际的渗透测试过程中,面对复杂多变的网络环境,当常用工具不能满足实际需求的时候,往往需要对现有工具进行扩展,或者编写符合我们要求的工具、自动化脚本,这个时候就需要具备一定的编程能力。从上面的模拟结果,可以得知,当服务端并发处理大量请求时,如果 TCP 全连接队列过小,就容易溢出。上面看到的 241307times ,表示全连接队列溢出的次数,注意这个是累计值。我们共执行了两次 ss 命令,从上面
如何自学黑客&网络安全
黑客零基础入门学习路线&规划
初级黑客
1、网络安全理论知识(2天)
①了解行业相关背景,前景,确定发展方向。
②学习网络安全相关法律法规。
③网络安全运营的概念。
④等保简介、等保规定、流程和规范。(非常重要)
2、渗透测试基础(一周)
①渗透测试的流程、分类、标准
②信息收集技术:主动/被动信息搜集、Nmap工具、Google Hacking
③漏洞扫描、漏洞利用、原理,利用方法、工具(MSF)、绕过IDS和反病毒侦察
④主机攻防演练:MS17-010、MS08-067、MS10-046、MS12-20等
3、操作系统基础(一周)
①Windows系统常见功能和命令
②Kali Linux系统常见功能和命令
③操作系统安全(系统入侵排查/系统加固基础)
4、计算机网络基础(一周)
①计算机网络基础、协议和架构
②网络通信原理、OSI模型、数据转发流程
③常见协议解析(HTTP、TCP/IP、ARP等)
④网络攻击技术与网络安全防御技术
⑤Web漏洞原理与防御:主动/被动攻击、DDOS攻击、CVE漏洞复现
5、数据库基础操作(2天)
①数据库基础
②SQL语言基础
③数据库安全加固
6、Web渗透(1周)
①HTML、CSS和JavaScript简介
②OWASP Top10
③Web漏洞扫描工具
④Web渗透工具:Nmap、BurpSuite、SQLMap、其他(菜刀、漏扫等)
恭喜你,如果学到这里,你基本可以从事一份网络安全相关的工作,比如渗透测试、Web 渗透、安全服务、安全分析等岗位;如果等保模块学的好,还可以从事等保工程师。薪资区间6k-15k
到此为止,大概1个月的时间。你已经成为了一名“脚本小子”。那么你还想往下探索吗?
如果你想要入坑黑客&网络安全,笔者给大家准备了一份:282G全网最全的网络安全资料包评论区留言即可领取!
7、脚本编程(初级/中级/高级)
在网络安全领域。是否具备编程能力是“脚本小子”和真正黑客的本质区别。在实际的渗透测试过程中,面对复杂多变的网络环境,当常用工具不能满足实际需求的时候,往往需要对现有工具进行扩展,或者编写符合我们要求的工具、自动化脚本,这个时候就需要具备一定的编程能力。在分秒必争的CTF竞赛中,想要高效地使用自制的脚本工具来实现各种目的,更是需要拥有编程能力.
如果你零基础入门,笔者建议选择脚本语言Python/PHP/Go/Java中的一种,对常用库进行编程学习;搭建开发环境和选择IDE,PHP环境推荐Wamp和XAMPP, IDE强烈推荐Sublime;·Python编程学习,学习内容包含:语法、正则、文件、 网络、多线程等常用库,推荐《Python核心编程》,不要看完;·用Python编写漏洞的exp,然后写一个简单的网络爬虫;·PHP基本语法学习并书写一个简单的博客系统;熟悉MVC架构,并试着学习一个PHP框架或者Python框架 (可选);·了解Bootstrap的布局或者CSS。
8、超级黑客
这部分内容对零基础的同学来说还比较遥远,就不展开细说了,附上学习路线。
网络安全工程师企业级学习路线

如图片过大被平台压缩导致看不清的话,评论区点赞和评论区留言获取吧。我都会回复的
视频配套资料&国内外网安书籍、文档&工具
当然除了有配套的视频,同时也为大家整理了各种文档和书籍资料&工具,并且已经帮大家分好类了。

一些笔者自己买的、其他平台白嫖不到的视频教程。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
# 从客户端执行
# -t 6 表示启动6个测试线程
# -c 30000 表示3万个连接
# -d 60s 表示持续压测60s
wrk -t 6 -c 30000 -d 60s http://10.0.0.62
在服务端用ss命令查阅TCP全连接队列的情况:
# 服务端查阅tcp全连接队列的情况
[root@rs01 ~]# ss -lnt | grep 80
LISTEN 75 128 *:80 *:*
LISTEN 0 128 [::]:80 [::]:*
[root@rs02 ~]# ss -lnt | grep 80
LISTEN 129 128 *:80 *:*
LISTEN 0 128 [::]:80 [::]:*
我们共执行了两次 ss 命令,从上面的输出结果可以发现,当前 TCP 全连接队列达到了 129 个,超过了最大 TCP 全连接队列。
当超过了 TCP 最大全连接队列,服务端则会丢掉后续进来的 TCP 连接,丢掉的 TCP 连接的个数会被统计起来,我们可以使用 netstat -s 命令来查看:
[root@rs02 ~]# netstat -s | grep overflowed
241307 times the listen queue of a socket overflowed
上面看到的 241307times ,表示全连接队列溢出的次数,注意这个是累计值。可以隔几秒钟执行一次,如果这个数字一直在增加的话肯定全连接队列满了。
从上面的模拟结果,可以得知,当服务端并发处理大量请求时,如果 TCP 全连接队列过小,就容易溢出。发生 TCP 全连接队列溢出的时候,后续的请求就会被丢弃,这样就会出现服务端请求数量上不去的现象。
实际上,丢弃连接只是 Linux 的默认行为,我们还可以选择向客户端发送 RST 复位报文,告诉客户端连接已经建立失败。
[root@rs01 ~]# cat /proc/sys/net/ipv4/tcp_abort_on_overflow
0
tcp_abort_on_overflow 共有两个值分别是 0 和 1,其分别表示:
- 0 :如果全连接队列满了,那么 server 扔掉 client 发过来的 ack ;
- 1 :如果全连接队列满了,server 发送一个
reset包给 client,表示废掉这个握手过程和这个连接;
如果要想知道客户端连接不上服务端,是不是服务端 TCP 全连接队列满的原因,那么可以把 tcp_abort_on_overflow 设置为 1,这时如果在客户端异常中可以看到很多 connection reset by peer 的错误,那么就可以证明是由于服务端 TCP 全连接队列溢出的问题。就像下面这样:
[root@cloudstudy jason]# git clone https://github.com/wg/wrk.git wrk
Cloning into 'wrk'...
fatal: unable to access 'https://github.com/wg/wrk.git/': TCP connection reset by peer
当然这种错误不是一定会遇到。日常工作中如果没有特殊需求,我们建议设置为0.
如何增大TCP全连接队列
当发现 TCP 全连接队列发生溢出的时候,我们就需要增大该队列的大小,以便可以应对客户端大量的请求。
TCP 全连接队列足最大值取决于 somaxconn 和 backlog 之间的最小值,也就是min(somaxconn, backlog),实际上内核代码就是这么实现的:
// net/socket.c
SYSCALL\_DEFINE2(listen, int, fd, int, backlog)
{
......
// /proc/sys/net/core/somaxconn
somaxconn = sock\_net(sock->sk)->core.sysctl_somaxconn;
// 取到全连接队列的大小:min(somaxconn, backlog)
if ((unsigned int)backlog > somaxconn)
backlog = somaxconn; //backlog和somaxconn取其中的最小值
......
}
somaxconn是 Linux 内核的参数,默认值是 128,可以通过/proc/sys/net/core/somaxconn来设置其值;backlog是listen(int sockfd, int backlog)函数中的 backlog 大小,Nginx 默认值是 511,可以通过修改nginx的配置文件设置其大小;
前面模拟测试中,我的测试环境:
- somaxconn 是默认值 128;
- Nginx 的 backlog 是默认值 511
所以测试环境的 TCP 全连接队列最大值为 min(128, 511),也就是 128.
现在我们重新压测,把 TCP 全连接队列搞大,把 somaxconn 设置成 5000:
[root@rs01 ~]# echo 5000 > /proc/sys/net/core/somaxconn
接着把 Nginx 的 backlog 也同样设置成 5000:
# /etc/nginx/nginx.conf
server {
listen 80 default backlog=5000;
listen [::]:80;
......
# 重启nginx后查看:
[root@rs01 ~]# systemctl restart nginx
[root@rs01 ~]# ss -lnt | grep 80
LISTEN 0 5000 *:80 *:*
LISTEN 0 511 [::]:80 [::]:*
从执行结果,可以发现 TCP 全连接最大值为 5000。
再次压测:
wrk -t 6 -c 30000 -d 60s http://10.0.0.62
服务端执行 ss 命令,查看 TCP 全连接队列使用情况:
[root@rs01 ~]# ss -lnt | grep 80
LISTEN 204 5000 *:80 *:*
LISTEN 0 511 [::]:80 [::]:*
从上面的执行结果,可以发现全连接队列使用增长的很快,但是一直都没有超过最大值,所以就不会溢出:
[root@rs01 ~]# netstat -s | grep overflowed
181404 times the listen queue of a socket overflowed
# 181404是没调整之前的丢弃情况,现在看只要数据没有变化就说明队列没有继续溢出。
说明 TCP 全连接队列最大值从 128 增大到 5000 后,服务端抗住了 3 万连接并发请求,也没有发生全连接队列溢出的现象了。
**总结:**如果持续不断地有连接因为 TCP 全连接队列溢出被丢弃,就应该调大 backlog 以及 somaxconn 参数。
实战半连接队列
继续使用上面的环境:
客户端:centos7.9 10.0.0.11
服务端:centos7.9 10.0.0.62 hostname:rs01
nginx 端口80
工具:hping3
TCP 半连接队列的长度,不能像全连接队列那样可以用 ss 命令查看。我们只能根据半连接的特点,通过处于SYN_RECV状态的TCP连接来查看:
[root@rs01 ~]# ss -antp | grep SYN-RECV | wc -l
0
模拟半连接状态,那就是客户端一直发送tcp syn包,但是不回复第三次握手的ACK。那服务端就会有大量的SYN_RECV状态的连接。这就是所谓的SYN泛洪攻击、DDos攻击。
# 先关闭tcp_syncookies
[root@rs01 ~]# echo 0 > /proc/sys/net/ipv4/tcp_syncookies
# 客户端发起SYN泛洪攻击
# -S 表示采用SYN半连接方法
# -p 指定攻击的端口号
# --flood 泛洪攻击,尽可能快的发送数据包
[root@cloudstudy ~]# hping3 -S -p 80 --flood 10.0.0.62
# 到服务端去查看
[root@rs01 ~]# ss -antp | grep SYN-RECV | wc -l
2
我这返回的结果是2,如果你返回的结果是一个比较大的值,比如256,并且通过如下命令看到累计值在增加:
[root@rs01 ~]# netstat -s | grep "SYNs to LISTEN"
185752 SYNs to LISTEN sockets dropped
如果上面返回的累计值在不断增加,就说明半连接队列已经满了。
给大家的福利
零基础入门
对于从来没有接触过网络安全的同学,我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线,大家跟着这个大的方向学习准没问题。

同时每个成长路线对应的板块都有配套的视频提供:

因篇幅有限,仅展示部分资料
网络安全面试题

绿盟护网行动

还有大家最喜欢的黑客技术

网络安全源码合集+工具包


所有资料共282G,朋友们如果有需要全套《网络安全入门+黑客进阶学习资源包》,可以扫描下方二维码领取(如遇扫码问题,可以在评论区留言领取哦)~
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
更多推荐



所有评论(0)