恶意bot – Petal Bot

早上发现一个站点很奇怪,PV/UV接近1:1

看了一下log, 才发现原来是Petal Bot 在做怪,google 了一下发现petalsearch.com这个搜索引擎貌似是huawei的产品. 

关于这个产品,在huawei的网站上有详细的说明

PetalBot is an automatic program of the Petal search engine. The function of PetalBot is to access both PC and mobile websites and establish an index database which enables users to search the content of your site in Petal search engine. You can identify crawling from Petal by analyzing the User-agent field.

在PC上的UA: Mozilla/5.0 (compatible;PetalBot;+http://aspiegel.com/petalbot)

在mobile上的UA:

Mozilla/5.0(Linux;Android7.0;)

AppleWebKit/537.36(KHTML,likeGecko)

MobileSafari/537.36(compatible;PetalBot;+http://aspiegel.com/petalbot)

常用的ASN是 AS136907 Huawei Cloud Singapore, 可以安心的把这个ASN封掉

CentOS上端口转发方案之HAProxy

端口转发的实际使用场景很多,比如说load balance,比如说流量中转

所谓的端口转发,是发生在网络协议的第四层,TCP/UDP层,也就是IP层面

所以一般来说有这么几个解决方案:

iptables: 系统原生底层的解决方案,配置比较麻烦。但是如果使用CSF来配置iptables,这是非常简单的

HAproxy: 性能比iptables高,配置简单,但是只支持TCP,不支持UDP. 但是如果不玩游戏的话,TCP的端口转发就足够了。

因此这篇文章主要讲述如何使用HAProxy来做流量中转.

底层操作系统是CentOS 7,系统的repo自带haproxy,版本比较老(1.5.18)但是足够用了

安装haproxy:

yum install haproxy

systemctl enable hapoxy

配置haproxy:

cd /etc/haproxy
mv haproxy.cfg haproxy.cfg.bak
vi haproxy.cfg

然后输入下面的配置:

global
ulimit-n 51200
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
user haproxy
group haproxy
daemon

defaults
log global
mode tcp
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
maxconn 20480

frontend v2
bind *:443
default_backend v2

backend v2
server v1 A.A.A.A maxconn 20480

frontend rdp
bind *:3389
default_backend rdp

backend rdp
server r1 B.B.B.B maxconn 20480

上图表示把把这台服务器的443端口的流量转到A.A.A.A的443端口上,把这台服务器的3389端口流量转到B.B.B.B的443端口上

配置好以后,下面只需要开启haproxy服务就好了

systemctl start haproxy

Cloudflare 推荐节点IP

Cloudflare 百度云合作节点IP:

162.159.208.4-162.159.208.103

162.159.209.4-162.159.209.103

162.159.210.4-162.159.210.103

162.159.211.4-162.159.211.103

各线路推荐列表:

电信:推荐走圣何塞,例:104.16.160.* 或者上面的百度云合作 ip。
移动:推荐走移动香港,例:172.64.32.* 141.101.115.* 或者 104.23.240.0-104.23.243.254。
联通:没发布什么好线路,可走圣何塞。例:104.16.160.* 或者 104.23.240.0-104.23.243.254。也可以试一下走亚特兰大 108.162.236.* 。

Smokeping 常用操作

在centos上安装了smokeping 以后,我们可能会经常遇到各种问题

  1. 对target进行修改,修改完以后,我们需要重启smokeping service ,一般情况下是不需要重启httpd,因为smokeping 的主程序会查看config 的timestamp,如果有变化就会重新读取config 配置文件,但是如果你把target 通过include 的方式包含在config当中,那么即使你修改了target文件,但是config 文件的timestamp 仍然不变。经过测试,解决办法有两个: 要么稍微修改一下config 文件,添加或者删除一些无关紧要的文字,要不然就在重启完smokeping以后再重启一下httpd服务
  2. 还有一个经常见的问题就是slave 的图没有数据,这个一般是权限的问题。因为slave 端的数据,是slave 端通过http call,写入master 端的,而master 端完成此项任务的是httpd,因此httpd 要对 data 文件夹下面的target 的文件夹要有写入权限。实现这个目标,可以有多种实现的办法,一种办法是利用getfacl 和 setfacl 来设置apache 对这些目录单独的权限,另外一种办法是把这些文件的group 设置为apache,并且给apache 写入的权限 chmod g+w *
  3. 查看rrd文件里面的是否用数据,例如可以用rrdtool fetch Akamai1~10.10.16.111.rrd AVERAGE 命令查看master端slave提交的rrd文件

现代Linux系统的swap空间

以前的资料上的东西,都是以RAM很小为前提,但是现在的server,RAM动不动就是32G,64G什么的,内存要大不少

下面的内容是从fedora 28的安装文档上看到的。Fedora 28安装指南定义了有关swap 空间分配的思路。需要注意的是,fedora的分配思路可能与其他Linux发行版略有不同,但是和REHL,Centos是一摸一样的,这些建议自从Fedora19以来就没有变过

Fedora的建议:

RAM<=2GB, SWAP = 2X RAM

2GB < RAM < 8GB, SWAP = RAM

8GB < RAM < 64GB, 4G<=SWAP<=0.5XRAM

RAM> 64GB, SWAP>=4GB

但是根据多年专业的运维人员的经验来说,

RAM <= 2GB, SWAP = 2X RAM

2GB < RAM < 8GB, SWAP = RAM

SWAP > 8GB, SWAP = 8GB

MSDN Win10 Ltsc 2019姗姗来迟

等了好长时间的MSDN版本的EN Win10 Ltsc 2019终于来了,可是通过比较完sha-1以后,发现msdn和vlsc的文件是一模一样的,没有任何更改。。。看来阿三还是比较懒的。。。

 

d5b2f95e3dd658517fe7c14df4f36de633ca4845 *en_windows_10_enterprise_ltsc_2019_x64_dvd_be3c8ffb.iso

c0b4704e1336281c98a91438c7df0f14b8f41e46 *cn_windows_10_enterprise_ltsc_2019_x64_dvd_d17070a8.iso

C0B4704E1336281C98A91438C7DF0F14B8F41E46 *SW_DVD5_WIN_ENT_LTSC_2019_64-bit_Chinese_Simplified_MLF_X21-96413.ISO

D5B2F95E3DD658517FE7C14DF4F36DE633CA4845 *SW_DVD5_WIN_ENT_LTSC_2019_64-bit_English_MLF_X21-96425.ISO

由此可见,VLSC和MSDN在1809版本上继续保持一致