脚本编程

CCKiller:Linux轻量级CC攻击防御工具,秒级检查、自动拉黑和释放

张戈博客很久以前分享过一个CC攻击的防御脚本,写得不怎么样,不过被51CTO意外转载了。博客从此走上了经常被人拿来练手的不归之路。 当然,还是有不少朋友在生产环境使用,并且会留言询问相关问题。根据这些问题的需求,我花了一些时间重新写了一个比较满意的轻量级CC攻击防御脚本,我给它取了一个比较形象的名字:CCKiller,译为CC终结者。 一、功能申明 分享之前我必须先申明一下,众所周知,DDoS攻击指的是分布式拒绝服务。而CC攻击只是DDoS攻击的一种,本文所阐述的CC攻击,指的是单个IP达到我们设定好的阈值并发请求,而非海量IP的低并发攻击!对于个人低配服务器,除了使用CDN来防护,至少我是没有想到如何抵挡海量IP攻击的!因为每个IP都模拟正常的用户浏览器请求,并不会触发防御阈值,同时来1000个,甚至上万个,个人低配服务器的带宽在第一时间就会被占满,就无法继续提供服务了。 当然,用脚本也是无法防御DDoS大流量攻击的,因为所有机房的防御带宽是有限的,当攻击的流量超过了机房的防御带宽,要么机房把你的服务器IP拉黑洞,要么就一起死。因此,如果你的服务器正遭受大流量攻击,比如几十G上百G,一般机房或CDN节点都是扛不住的,脚本也无能为力了,赶紧换高防服务器吧! 二、功能介绍 通过以上申明,也就大致给CCKiller一个定位:CCKiller是用于个人低配服务器的轻量级CC攻击防御,可以抵挡单个IP产生的高并发攻击。 目前设计的功能特性如下: ①、秒级检查 很多人写的防御脚本都是使用了Linux系统的计划任务crontab来定时检查的。而crontab的最细颗粒是1分钟,也就是说脚本最快也只能1分钟检查一次。对于一些强迫症来说就会很不爽。 所以,我还是按照以前分享的思路,利用while循环实现秒级检查,实现更细的颗粒。当然,CCKiller更是被我写成了系统服务,更加灵活稳定。 ②、拉黑时长 CCKiller可以设置拉黑时长,默认为10分钟。当发现有恶意请求时,会自动拉黑目标IP,并在拉黑时长结束后自动释放,这个功能算是对我之前写的脚本的一个大的改进。 ③、并发阈值 CCKiller 可以设定单个IP的最高请求数,如果某个IP同时请求数超过了设定的阈值,就会被暂时拉黑一段时间。 ④、邮件发送 这个功能没啥好说的,意义并不大。而且发送成功率和服务器的环境也有很大关系。 ⑤、并发显示 安装后,直接运行cckiller会列出当前系统的请求排行,可以清晰的看到当前请求IP和并发数。使用-s参数还可以继续定制需求,比如 cckiller -s 10 就能显示当前并发数排行前10名的IP。 ⑥、手动拉黑 支持手动拉黑,执行后会立即检查,将并发请求超过n的IP拉黑一段时间,比如 cckiller -k 100 就会将目前超过100个请求的IP拉黑一段时间,如果没有则不会执行任何拉黑操作。 三、工具安装 ①、在线安装 由于我可能经常会更新一些功能,或修复一些BUG,所以仅提供在线安装,以保证脚本是最新的。 安装非常简单,执行如下命令就能进入配置步骤了: 2017-12-13 补充:Ubuntu 系统请参考joviqiao的版本=>传送门 2017-09-06 补充:CCKiller 代码早已提交到Github,有网友问到,就来补充说明下 =>传送门。 ②、工具配置 因为每个服务器的情况可能不一样,所以有一个自定义配置的过程。 执行上述安装命令后,将会进入自选配置部分,如图: 提示否使用脚本默认配置,如果选择是(y),那么显示默认配置,并询问是否继续: 默认配置如下: The Time interval : 20 s       #每20s检查一次系统请求情况 The Forbidden Time: 600 s  #拉黑时长设为10分钟 Adminstrator Email: [email protected]   #邮件对象设置为[email protected](即关闭邮件发送) Connections Allow: 100      #单个IP并发限制为100 如果不符合你的需求,你可以使用 ctrl + c 组合键终止脚本,或者先继续安装,因为工具设计了配置修改的功能,所以无需着急。 如果不使用默认配置(n),则会要你输入参数来自定义配置: 如图,我将参数依次定义为每10秒进行检查,拉黑时长为300秒,发件人设置为博客邮箱,并发限制设置为60,回车后会弹出一个提示,让你检查,如果没问题你直接回车就会安装并启动: ③、服务控制 安装后,会将cckiller注册成系统服务,这时你就可以使用service来控制cckiller了。 使用标准的service定义,支持 start | stop | restart | status 四个参数。所以,你可以使用 service cckiller stop来停止cckiller,也可以使用service cckiller status来查看状态。  ④、集成命令 成功安装后,系统还会多出一个cckiller的命令,这个命令现有功能如下: cckiller -h可以调出帮助信息:...
阅读全文
脚本编程

Windows下bat批处理脚本使用telnet批量检测远程端口小记

多年没写过批处理了,来新公司的第一个case却是需要写一个bat脚本,批量更新采集agent的配置文件,其中就涉及到远程IP的端口检测。 本以为会和Linux一样可以简单判断: 结果发现Windows下面telnet退出并没有执行结果的返回值: 一、借助工具 于是我优先开启懒人法则,找其他替代工具。果然,在Windows老娘家找到了: Portqry:https://support.microsoft.com/en-us/kb/310099/zh-cn 确实可以使用,不过检测速度不敢恭维,通与不通都很慢!鉴于手头没有更好的解决办法,就先试试看,贴一下我写的Portqry相关demo: Ps:check是一个被call调用的模块,里面的一些变量就不做介绍了。 于是兴冲冲的封装成exe,给IDC(server2003系统)执行,结果第一台就悲剧了!远程桌面直接断开了: 然后再也连不上了,要他们去机房看了下,结果告诉我系统没了!!??太震精了有木有?一个简单的文本操作脚本,居然把系统干掉了么?而且脚本中都不存在任何删除命令。。。 要那边提供了一下启动错误信息,原来是系统引导坏了: 个人分析了一下,应该是Portqry这个工具导致系统蓝屏关机,进而导致引导损坏! 尼玛,娘家人介绍时说好的“性格”良好呢? 唉,看来这个工具是不敢使用了,俗话说林子大了什么系统都有嘞! 二、另辟蹊径 既然工具不敢用了,还是继续折腾代码吧!周末睡觉前突然灵感一闪,想起了tasklist判断窗口名称这个“失传绝技”,于是把刚关闭的本子又打开,终于在GF的不断抱怨之下搞定了这个问题。 ①、窗口判断 思路比较简单:使用start命令在新窗口执行telnet -e 和 exit命令,如果端口畅通,那么新开的窗口将会立即关闭,而不通的窗口则会保持近半分钟左右,且窗口名称类似 telnet 192.168.1.1,这半分钟时间足够脚本来判断通还是不通了。 于是将上面check部分修改如下: 样就解决了Windows下telnet探测远程端口的问题了,而且检测速度比微软哪个portqry快多了,果然思路比技术更重要,只要有想法,任何技术都不应该成为瓶颈! ②、进程判断【最新补充】 当使用窗口判断的方案下发各大机房实施的时候,又一个问题出现了!窗口判断在某些版本的Windows下是行不通的,比如英文版下的命令提示符窗口名称和中文版的就不一样,所以这个方案也是不完善的! 于是,继续抓耳挠腮,想出了第二个方案:通过判断telnet进程数量来判断网络是否畅通。 方案思路: a. 先判断脚本执行之前是否存在 telnet.exe 的进程,如果存在则统计数量 b. 和窗口判断一样,利用start命令在新的cmd命令提示符中执行 telnet 命令 c. 延迟几秒后统计系统中存在的telnet.exe进程数(存在的telnet表示是不通的) d. 和最开始统计的 telnet 进程数比对计算,就知道有几个IP是不通的了 示例代码:   很明显,这样就可以知道我测试了所有IP当中有几个是不通的了。遗憾的是无法知道是哪个IP不通。不过在手头的这个case当中是不需要具体不通的IP的,只要知道通的IP是否达标就行。 好了,终于把这个问题给解决了。显然,任何时候都需要给出多个方案,而不是自满于一个方案。否则出问题就会焦头烂额了。当然,再次说明了想法比技术更重要。
阅读全文
脚本编程

Linux下的mongodb服务脚本,以备不时之需

前些天,一位开发同事找到我,说他测试环境的 mongodb 经常挂掉,要我写一个监控或复活的脚本。我觉得很奇怪,测试环境又没啥负载,经常挂掉肯定有非常规原因。 跑过去看了一下日志,发现存在stop记录,我就纳闷了,没人操作他还会自己stop。这明显不是挂掉了,于是到history中看了下同事的启动命令: 原来如此!因为他没有用nohup启动,所以只要他的终端离线或者关闭,mongodb就会自动退出了!解决办法很简单,如下启动即可: 这样敲命令也着实苦逼,所以从网上找了一个mongodb服务脚本就舒服多了: 将代码保存到 /etc/init.d/mongodb,然后使用 chmod +x /etc/init.d/mongodb 添加执行权限。 现在,就可以使用 service 命令来控制mongodb了: 非常简单,贴到博客记录一下,以备不时之需。
阅读全文
脚本编程

SEO技巧:Shell脚本自动提交网站404死链到搜索引擎

最近在折腾博客主题,通常来说大多数人认为换主题会影响SEO,实际上只要你把工作都做到位了,是没有任何问题的。比如,换主题后你得仔细检查标题和描述等内容是否发生改变、换主题后是否带来了大量的404页面等。当然,更细微的可能是换主题之后,网站的内链网络也发生了微妙的改变,但是整体的影响较小。 总之,张戈博客这次更换主题基本上没有看到明显的SEO影响,反而出现几个新的关键词。好了,题外话到此结束,下面分享一下从Nginx日志分析并生成能提交到搜索引擎的死链文件的Shell脚本。 一、前因后果 今天在看百度站长平台的抓取频次的时候,发现最近抓取次数有所下滑,并且平均响应时间也有所上升,感觉和最近频繁折腾主题以及访问量增加有所关系: 这个问题倒是好解决,等主题稳定了,页面静态缓存文件也就不会频繁被手工删除,整个网站的抓取响应时间应该就能回到正常水平。 再往下看,却发现网站抓取中出现的404数据也呈上升趋势: 实际上,张戈博客以前是手动提交过死链文件的,但后来没时间也就没去搭理更新了。看来这个工作还得重新做起来,并且实现自动化才行了。 二、Shell脚本 说做就做,简单的写了个 Shell 脚本就搞定了! 脚本名称:网站死链生成脚本 脚本功能:每天定时分析网站前一天的 nginx 日志, 然后提取状态码为404并且UA为百度蜘蛛的抓取路径,并写入到网站根目录下的 death.txt 文件,用于提交百度死链。 脚本代码: 使用说明: ①、脚本适用于每天都做了日志切割的Nginx,没有做的朋友可以参考博客之前的文章: nginx日志切割及7天前的历史日志删除脚本 ②、将代码保存为 shell 脚本,比如 deathlink.sh,然后如下建立任务计划: ③、执行后,将在网站根目录生成死链文件:death.txt,可以浏览器访问看看内容,比如: https://zhang.ge/death.txt ④、前往立即前往提交这个死链文件即可: 这样一来,系统会每天执行脚本,将昨天的百度蜘蛛爬到的404路径保存到网站根目录下的 death.txt,以备百度死链抓取工具前来抓取。 效果截图: 下面贴上这几天死链抓取(百度定时抓取,无需人工干预)及处理情况,效果还是非常明显的: 值得说明的是,这些死链记录是累加的,已保存的死链数据,就算百度蜘蛛不爬了也会继续保存,需要人工清理,不过一般不清理也没啥问题。 注意事项: ①、如果你的 nginx服务 并没有配置相应的 access 日志,请自行在 server 下添加所需网站的 access 日志,否则脚本无法使用; ②、脚本适用的access日志格式如下:   如果和你的不一样,则需要修改脚本中的awk指定的域(即$9、$15以及$7)。 三、其他拓展 ①、如果你之前没有做过 Nginx 日志切割,那么可以直接用下面这个脚本来一次性搞定: ②、其他WEB服务器,比如 Apache 或 IIS,只要参考脚本思路,修改成实际的路径或日志字段,同样可以写一个相同功能的 Shell 或 Batch 脚本,有需求的朋友自己去研究折腾吧! 好了,本文暂时就分享这么多,希望对你有所帮助!
阅读全文
脚本编程

zabbix agentd客户端插件Shell一键自动安装脚本

这次生产环境上线了多台Linux服务器,需要全部纳入Zabbix监控范畴,一台一台的去装Zabbix Agentd插件那就太苦逼了,所幸Zabbix客户端插件是支持绿色安装的,就写了个简单的一键安装脚本,然后配合 Secure CRT 的多窗口交互命令一次性就可以搞定了。 正常启动Zabbix客户端服务其实只需要2个文件: zabbix_agentd 和 zabbix_agentd.conf,需要特别说明的是:zabbix_agentd 最好是和 Zabbix_Server 一同编译所得,保证版本和配置文件的路径是一致的,否则可能无法使用Linux系统的 service 服务启动模式。 一、准备工作 Zabbix 主机肯定搭建了WEB服务,所以正好可以将所需放置到WEB目录,方便下载。 客户端插件 zabbix_agentd 位于 Zabbix 安装目录下的 sbin 目录,比如:/usr/local/zabbix/sbin/zabbix_agentd 服务控制脚本 zabbix_agentd 位于 zabbix 源码编译目录下的 misc/init.d/fedora/core/zabbix_agentd 我们要做的就是将这些文件拷贝到 WEB目录即可,比如 /var/www/html/zabbix_agent/ ,根据系统版本的不同,我们可以准备64和32位的 zabbix_agentd,方便后续不同系统下的安装。 拷贝后,手工验证下文件是否可以下载: 客户端插件:http://192.168.1.40/zabbix_agent/64/zabbix_agentd 服务控制脚本:http://192.168.1.40/zabbix_agent/init.d/zabbix_agentd 二、编写脚本 ①、将以下代码保存为 zabbix_agentd.sh ,上传到第一步中的 zabbix_agent 目录。 ②、Service 服务控制脚本 为了方便没找到 zabbix agent 服务控制脚本的朋友,额外提供服务控制代码。将代码保存为zabbix_agentd,上传到第一步的 zabbixz_agent/init.d/ 目录备用。 三、使用方法 登录到客户端系统,运行如下命令即可一键安装: ①、使用默认 zabbix_server 的IP地址: ②、后面添加IP参数可指定到其他 zabbix_server 或 zabbix_proxy: Secure CRT多会话交互执行: 其他说明:此脚本中的 zabbix_agentd 编译路径(prefix)为 /usr/local/zabbix,如果编译的时候不是这个路径,则需要根据实际情况修改脚本里面相关路径,否则注册的zabbix_agentd服务将无法启动,就只能通过命令行启动了!
阅读全文
脚本编程

SendCloud邮件队列状态和已使用额度的Python监控脚本

公司最近用上了 SendCloud 的邮件代发服务,于是就有了各种监控需求。比如每天发信额度是不是要超标了或是邮件是否堵塞了等等。最近经常接触 python,所以这次也一样,继续学习使用 python 来完成各种脚本需求。 SendCloud 提供了很多对外查询的 API,只要 Get 或 Post 传递用户名和 KEY 即可获得想要的各种数据,比如最简单的【已使用额度】就可以在用户信息 json 接口查询。 文档地址:http://sendcloud.sohu.com/doc/email/user_info/ 调用形式如下: 返回示例如下: 其中的 usedQuata 就是我所要监控的当前使用额度了。 先用我目前比较熟悉的 php 写一个脚本试试: 这样就可以输出当前的使用额度了,然后放到 zabbix 配置文件中即可 ,记得要使用 php 调用哦。 下面再试试我还不太熟悉的 python,目的很简单,在提高性能的同时学习一下自己的弱项,代码很稚嫩估计内行一看就知道是新手写的,仅供参考。。。 脚本执行形式: 涉及到了网页抓取,期间少不了百度搜索python抓取网站的一些函数和用法,于是继续写了一个监控网页 HTTP 状态码的监控脚本,权当是学习之作: 几次接触下来,python 给我的感觉就是不但功能强大,而且简单易懂。基本都可以依葫芦画瓢实现你想要的各种功能。当然,本文分享的几个脚本都是用于 zabbix 监控的,如何添加请参考博客上一篇文章。 另外,SendCloud 的可监控项目非常多,比如今天发了多少邮件,成功了多少,被拦截了多少,无效邮件有多少等等。基本上,官方都提供了相应的查询接口,所以只要参考本文的脚本和思路,相信就能完成你想要的监控脚本。
阅读全文