安全领域工具

Nmap、Netcat、Hping3

 

在网络安全领域，Nmap、Netcat、Hping3都是安全工程师必备的工具。Nmap主要作为端口扫描器，侦查目标机的端口及服务状态；而Netcat则整合了网络中各种常用功能（如后门、文件传输、端口扫描、端口转发等等），能辅助完成丰富的操作；Hping3主要作为特定的TCPIP数据包产生与解析的工具，当然也可用于Ping操作。

 

参考资料:

  1. http://www.2cto.com/Article/201210/158961.html
  2. nmap使用： http://www.2cto.com/Article/201210/158960.html
  3. hping原理、安装、使用详解介绍： http://blog.itechol.com/space-33-do-blog-id-5772.html
  4. 利用hping3和伪造IP地址执行DOS攻击： http://sec.chinabyte.com/222/13522222.shtml
  5. hping3命令详解： http://man.linuxde.net/hping3

systemtap初体验

写在前面：

systemtap依赖的debuginfo可以从这里（http://debuginfo.centos.org/6/x86_64/）找到，如果幸运的话，你可以直接yum install kernel-debuginfo kernel-debuginfo-common来安装;

不过，正确的安装姿势应该是：

  1. yum update kernel-*      （没有这个将可能出现很多不必要的麻烦）
  2. reboot
  3. yum install systemstap
  4. stap-prep

话说systemtap是一个非常强悍的linux调试工具，但是似乎并不是特别的常用，今天尝试用了一下，确实有一些心得。

安装：

然后就有systap命令了，弄个脚本试试跑跑吧：

有错误了：

大致如上，可能版本号有所差异；好歹有提示，那就照做；不过，可能你确实已经安装了对应版本的kernel-devel; 你们不防rpm -ql kernel-devel 看看安装到哪里了，如果是 /usr/src/kernels/2.6.32-431.el6.x86_64 那么不妨执行：

 

其实可以这样：

该命令可以帮你安装需要的依赖，主要是kernel-devel 和 kernel-debuginfo； 关键是要安装指定的版本，版本错了不行，如果使用的是本地的yum源，可能找不到指定的版本号的包，这样可以修改为使用官方的yum源，这可能是一个比较慢的过程，因为kernel-debuginfo 大小可能超过1G；单从这个来看，该工具的使用成本还是不小的; 也很有可能你配置了debuginfo的yum源，但是没有enable，可以在yum时候临时enable一下，eg：

安装完后再次执行：

果然有hello world输出，再来一个 profile.stp：

使用场景

  1. 看看哪个进程在查询dns
    dns.stp:

参考资料：

关于限速

出于各种需要，经常需要限速

  1. 针对进程限速
  2. 针对ip、port限速
  3. 针对一组进程限速
  4. 模拟低速环境
  5. 程序上实现限速
  6. 针对下载限速
  7. 针对上传限速

真实需求：

调用第三方接口发邮件，经常会有很大的附件，当发送大量这类邮件时，就会将带宽占满。（第三方出口带宽还挺大）

 

限速工具：

  1. tc
    1. tc只能控制发送的速率，不能控制收包的速率（来了就收呗，干嘛要限速）
  2. iptables
  3. iptables + tc
  4. pv (pipe view)
  5. chrome开发者工具直接限速
  6. 程序自身支持限速 ，如：curl
  7. 通过特定编程语言实现
    1. PHP： https://github.com/bandwidth-throttle/bandwidth-throttle  （利用了stream_filter_append ）
    2. PHP: https://packagist.org/search/?tags=rate%20limit
    3. Go： https://github.com/juju/ratelimit

通过nginx限速

nginx可以做http代理、tcp代理，而程序上设置代理也都比较方便，如果能在nginx上限速，会比较通用一些，目前发现有2个nginx限速模块：

  1. http://nginx.org/en/docs/http/ngx_http_limit_req_module.html   限制单个IP每秒最大请求数
  2. http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html   限制单个IP每秒最大并发

但是目前还没有一个限制流量的模块

（注：这些模块提供的时间段为‘秒’是不够灵活的，应该允许指定n秒，参考限速方面知识的其他参数）

通过apache限速

apache是一个老牌的web server，模块很多，果然有限速模块：

  1. http://bwmod.sourceforge.net/   这是是实现带宽限制的
  2. http://dembol.org/blog/mod_cband/   这个支持对单个虚拟主机限速，主要用于卖服务的
  3. http://www.zdziarski.com/blog/?page_id=442   这个类似于nginx的那两个模块
  4. http://dominia.org/djao/limitipconn.html 这个只是限制连接数的
  5. http://www.topology.org/src/bwshare/README.html

 

参考： http://serverfault.com/questions/540743/how-to-rate-limit-apache-server-on-ip-basis

注意： 一般来讲，这些模块都是针对下行进行限速，很少对上行也限速的；如果对上行也要限速，则未必好使。对于代理的情况呢？

通过haproxy限速

参考文章： http://blog.serverfault.com/2010/08/26/1016491873/

        haproxy 是代理，不是隧道，如果仅仅作为一个限速的隧道或许还不行

注意：有些限制策略是超过限制就加入黑名单，并且直接返回错误（或许这不是你想要的）

通过squid限速

参考： http://wiki.squid-cache.org/Features/DelayPools

squid.conf 中添加：

测试发现： 这个限速也是针对下行的限速，上行不限速

自定义proxy

goproxy( https://github.com/elazarl/goproxy ) 是一个开发proxy的golang库，在此基础上开发自定义功能的proxy是很方便的

关于iptables限速

  1. 至少两条规则
    1. 允许的速度
    2. 默认的丢弃
  2. 问题
    1. 如果发快了，则系统调用不是被阻塞，而是“Operation not permitted”， 这可能导致进程逻辑异常，尤其是tcp三次握手时候，可能会导致连接失败

其他：

关于phpmailer的发邮件限速：

php 的curl限速：

http://php.net/manual/en/function.curl-setopt.php

CURLOPT_MAX_RECV_SPEED_LARGE

CURLOPT_MAX_SEND_SPEED_LARGE

 

http://m.blog.csdn.net/tianyaleixiaowu/article/details/74942405

PHP finally block aborts on autoload

参考： http://stackoverflow.com/questions/26204315/php-finally-block-aborts-on-autoload

Person.php

 

main.php

解决办法：

  1. 升级PHP
  2. 提前加载，如： class_exists(“Person”); 但是，如果Person相关方法执行起来需要自动加载其它类，依然失败，所以，此法基本不可行
  3. 不使用finally

 

docker run 之 -it 选项

docker run -it 的这个选项是啥意思？

一半来讲，如果启动的1号进程是 /bin/bash （或者类似程序）的话， -i 是交互的意思，如果没有 -i 选项，/bin/bash 不需要交互就没事干，会立即退出，然后容器就会退出； -t是分配终端，如果没有-t ，则 docker attach 进去的话，就没法和/bin/bash 进行交互，当然，如果你压根儿不知道attach或者压根儿没用过attach的话，你可能永远不知道这个-t有啥用；

所以说， -it 选项是和 /bin/bash    attach 有直接关系

ssh 慢的问题

解决办法： https://injustfiveminutes.com/2013/03/13/fixing-ssh-login-long-delay/

ssh时候，服务器端可能需要进行域名解析，这个过程可能会比较慢，抓包如下：

 

strace 的部分结果：

查问题的过程：

  1. 问题定位到： dns查询时，一个请求同时查询A记录和AAAA记录而服务器端只返回一个响应所致
    可能是dns不靠谱，也可能是协议定义有缺陷
  2. 一般来讲，dns查询是有底层的libnss实现的，直接使用host 来查询应该也是相同效果吧？ 结果不是
    host 查询时发现，A记录和AAAA记录虽然都查询了，但是是两次请求完成的； 看来二者用的库可能不一样
  3. google search “ sshd dns resolve ipv6” 发现文章： https://injustfiveminutes.com/2013/03/13/fixing-ssh-login-long-delay/
    可以通过在/etc/resolve.conf中添加

    来使得A和AAAA分作两次请求； 问题解决
  4. 一般来讲，我们只要使得ssh配置UseDNS no就可以了，但是，我们这里的情况是登录时使用了ldap（通过域名访问）认证，所以，域名解析就避不开了
  5. 遗留问题： 为什么client一次请求查询A和AAAA时，client不能和server好好配合呢？

其他参考： http://xxrenzhe.blog.51cto.com/4036116/1340103

记录salt的一个问题

现象：

cpu使用 接近100%

strace 跟踪结果

 

进程调用栈：

 

从调用栈来看，就算有bug也是libzmq的bug

 

关于redis短连接问题

场景：

PHP通过phpredis(https://github.com/phpredis/phpredis)循环执行如下操作：

 

 

发现connect会出现大量超过1s的情况，甚至超过3s；但是，如下图抓包所示：两次请求之间间隔了3s才发送syn请求，并且没有失败，也就是说，并非syn丢包所致，而是因为某种原因导致根本没有发送syn包；但是外部表现却是connect花费了很多时间（3s）；

所以，从此推断，连接超时未必就一定是网络的问题，你们究竟会是什么原因导致client端3s后才发送syn的呢？

 

阅读源码发现： redis的connect用的是php提供的connect方法：php_stream_xport_create

其实，fsockopen用的也是该方法，如此的话，不放通过如下脚本直接测试connect：

结果如下：

  1. connect超过1s的还挺不少的
  2. 前面300多次的时候连续出了好几次超过1s的，你们怎么会从374到13489一直没出错呢？而且，运行程序的时候也能感觉到，从第374到第13489花费时间很短的，难道这个区间根本没有发生真正的连接？ strace 跟踪统计发现，确实connect了，就是说，一般情况下，connect是很快的
  3. 该问题可能发生在PHP中，也可能发生在glibc中，也可能发生在系统层面，排查办法：
    1. 写一个C的，如果不出现问题，那么就是PHP的问题；如果依然如此，很可能是系统问题