欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

网络分析能力修行模型

作者:易隐者 发布于:2012-11-14 20:53 Wednesday 分类:网络分析

概述
       数次应业内朋友之邀,为其团队培训网络分析技术,从第一次开始,我就着手架构这个能力修行模型的框架,但还不够完善和成熟。随着我对网络分析技术理解的深入和本身水平的提升以及培训次数的增加,我不断的将其完善,并最终形成现在的雏形。

       根据这个网络分析能力修行模型,初学者可以清晰了解如何入手学习网络分析技术,并按部就班、循序渐进的提升网络分析技术的能力水平。

       所谓“道可顿悟,术需渐修”,但愿此文能够成为诸位网络分析初学者“悟道”的法门。

络运行的本质

       网络运行的本质是什么?是数据报文与协议。 

点击查看原图

       数据报文是网络运行世界里,具有完整信息的、最小的组成单元,而协议则是数据报文在网络内交互必须遵循的规则。因此掌握了这两者,基本上就可以把握网络运行的本质。

       网络分析技术将数据报文和协议完美的结合起来,因此网络分析技术通常也被叫做协议分析、数据包分析或报文分析。那么网络分析到底是如何工作的呢? 

点击查看原图

       网络分析技术是通过捕获网络通讯过程中的数据包(数据包是网络通讯过程中有意义的、最小的组成单元),并通过对捕获到的数据包进行深入的统计和分析,从而洞穿网络各个层面(包括性能、安全、业务以及故障等)运行情况的一种技术。
       通过网络分析技术,我们可以轻松透视网络运行的本质,如果我们的网络分析技术能力非常强,我们的技术水平会远远超出那些只精通于具体设备的工程师们,成为名副其实的网络层面的专家,那么我们如何修行才能提升自己的网络分析技术呢?下面我将通过网络分析能力修行模型展开详细介绍。

网络分析能力修行模型

       我将自己的成长经验总结为下图所示的网络分析能力修行模型: 

点击查看原图

       在这个模型中,围绕网络分析能力的提升,主要包含以下四方面的内容:

 基础

       古语云“千里之行始于足下”、“万丈高楼平地起”。做任何事情都离不开基础,网络分析技术能力的提升同样需要牢固扎实的技术基础作为支撑。

 工具
       古语云“巧妇难为无米之炊”。工具可以帮助我们事半功倍,大大提高我们的工作效率,没有称手的工具,纵然你有一身本领,却难免陷入纷繁复杂的二进制世界难以自拔。

 方法
       古语云“砍柴不照纹,累死砍柴人”。有基础有工具却不得法,虽可解决一些常见问题,但往往是随性而起,难以为继。即使大部分情况下你能成功解决问题,也只能说明你的运气和感觉都还不错,但是你无法将你的运气和感觉传递给你的团队、学生及他人。简言之:无章法,不足道。

 案例
       古语云“纸上得来终觉浅,绝知此事要躬行”。基础牢靠、精通工具、掌握方法,这已经为我们践行网络分析技术做好充分的准备,我们需要在实际工作环境中,把握任何机会,践行自己的网络分析技能,在利用网络分析技术解决问题之后,不断总结,并形成文档;另外一条践行的捷径是讨论学习他人的案例,将他人的经历经验借鉴过来为己所用,在短时间内快速提升自己。总之,多践行,多总结,多学习。

       根据这个网络分析能力修行模型,我将网络分析技术的学习和提升分为四个阶段,如下图所示: 

点击查看原图

第一阶段:打好基础
       这个阶段较为漫长,并且会一直持续伴随整个学习成长的过程。一般而言,这个阶段主要是学习网络基础、各种网络和安全设备的工作原理和机制、不同系统或设备的报文处理流程、TCP/IP协议体系、各常见应用等。在这个阶段,大部分是通过自主学习来获得提升的。

第二阶段:熟悉工具
       在扎实的技术基础上,熟练掌握1-2种网络分析的工具,不会花费太多的时间,但是如想成为高手,必须充分理解各种常见工具的优势特点,学会在不同的情况下,选择性的综合利用这些工具的优势特性,提高我们解决问题的效率。

第三阶段:掌握方法
      掌握网络分析的常规思路,深入理解网络分析方法的原理和使用场景,能够在实际工作环境下,按照网络分析方法和思路展开网络分析工作。

第四阶段:践行案例
       综合利用已学知识和掌握的方法,不断通过实际案例践行网络分析技术,以及对他人案例的学习,让自己的网络分析技术得以快速提升和升华。

       这四个阶段在大的学习和提升方向上是线序的,但这并不是绝对的,比如我们既可以借助他人的案例加固基础知识,又可以在实际案例中提升工具使用的熟练度,也可以利用网络分析工具学习协议体系……

网络分析能力修行模型不同阶段的学习资料

       在我的个人博客蚂蚁网——www.vants.org中,基本涵盖了网络分析能力修行模型中各个阶段学习的内容,下面我将各个阶段的资料做一个统一整理,方便初学者学习参考。

网络分析基础

防火墙的状态检测 http://www.vants.org/?post=24
应用层检测/深度包检测(DPI)http://www.vants.org/?post=23
TCP异常终止(reset报文)http://www.vants.org/?post=22
TCP重传 http://www.vants.org/?post=36
ICMP重组超时 http://www.vants.org/?post=35
TCP SACK选项 http://www.vants.org/?post=74
传输层的响应时间(系统层响应时间/服务器响应时间)http://www.vants.org/?post=115
关于防火墙的arp代理功能对不同格式的arp报文的处理情况的实验 http://www.vants.org/?post=121
ARP代理(Proxy ARP)http://www.vants.org/?post=119
免费ARP(gratuitousARP)http://www.vants.org/?post=118
ARP表的更新和老化http://www.vants.org/?post=120
第三方延时http://www.vants.org/?post=117
应用响应时间(ART)http://www.vants.org/?post=116
ICMP通讯管理性过滤禁止差错报文(type 3,code 13)http://www.vants.org/?post=127
连接数相关知识http://www.vants.org/?post=126
TCP/IP 应用程序的通信连接模式http://www.vants.org/?post=182
TCP保活(TCP keepalive)http://www.vants.org/?post=162
多次RST以及不同场景下的RST报文的差异http://www.vants.org/?post=141
端系统对RST报文的过滤http://www.vants.org/?post=140
经受时延的确认(Delay ACK)http://www.vants.org/?post=114
TCP MSS与PMTUD http://www.vants.org/?post=109
IP分片(IP Fragment) http://www.vants.org/?post=106
TCP 的PUSH标志位http://www.vants.org/?post=102
TCP交互式应用http://www.vants.org/?post=101
基于UDP的应用如何保证应用数据的可靠性http://www.vants.org/?post=99
关于“client push”应用响应时间测量方法的讨论http://www.vants.org/?post=30
iPhone与Multicast DNS        http://www.vants.org/?post=130
非标准TCP三次握手建立连接过程一例http://www.vants.org/?post=91
ACK flood攻击的影响http://www.vants.org/?post=136
基于UDP组播实施分片攻击的可能性http://www.vants.org/?post=98
关于防火墙访问控制的疑问http://www.vants.org/?post=26
TCP/IP 数据包处理路径 http://www.vants.org/?post=188

网络分析工具

常见网络分析工具特色功能简介及其在实际工作中的应用之缘起 http://www.vants.org/?post=43
常见网络分析工具特色功能简介及其在实际工作中的应用之Network Monitor http://www.vants.org/?post=41
常见网络分析工具特色功能简介及其在实际工作中的应用之Omnipeek  http://www.vants.org/?post=66
Wireshark对ping报文的解码显示(BE与LE)http://www.vants.org/?post=133
利用科来与IDS Informer构建网络攻击学习平台http://www.vants.org/?post=31

网络分析方法

疑难故障分析常规流程和思路http://www.vants.org/?post=27
疑难网络故障的分析方法和原理之对比分析法http://www.vants.org/?post=49
疑难网络故障的分析方法和原理之关联分析法http://www.vants.org/?post=51
如何跟踪分析数据经过中间设备后的变化以及这些变化给客户端与服务器带来的影响http://www.vants.org/?post=93
一切皆有可能http://www.vants.org/?post=122
异常流量分析方法——发现-定位-管控http://www.vants.org/?post=185
如何保证中间设备两端捕获的数据包的时间同步性?http://www.vants.org/?post=50

网络分析案例

视频点播服务间歇性中断故障分析案例http://www.vants.org/?post=73
访问搜狐163时主页变为2008年某日主页面故障分析案例http://www.vants.org/?post=89
某学院专网网站打开慢故障分析案例http://www.vants.org/?post=92
FTP登陆故障分析http://www.vants.org/?post=103
某单位经过CA认证的业务应用访问缓慢故障分析案例http://www.vants.org/?post=104
网页打开慢但HTTP下载快故障分析案例http://www.vants.org/?post=128
某业务系统由于连接数限制导致间歇性访问慢故障分析案例http://www.vants.org/?post=125
数据包中出现超长帧的分析http://www.vants.org/?post=184
关于vista系统机器无法通过防火墙上网的故障分析解决案例http://www.vants.org/?post=124
关于服务器端发送FIN报文之前的数秒等待时间行为的分析http://www.vants.org/?post=95
大包传输丢包故障http://www.vants.org/?post=34
两台soho级小路由之间的“正义”之战http://www.vants.org/?post=163
某加密机经天融信防火墙后应用异常故障案例http://www.vants.org/?post=107
负载均衡故障诊断:一个MSS值引发的疑案http://www.vants.org/?post=110
关于网内抓包出现0.33.216.220IP地址问题的分析http://www.vants.org/?post=88
F5负载均衡环境下某应用故障分析案例http://www.vants.org/?post=65
某地税网上申报业务系统故障分析报告http://www.vants.org/?post=58
高新区房产局房产管理业务故障分析解决报告http://www.vants.org/?post=32
某部队部分网段访问总部网站故障分析案例http://www.vants.org/?post=25
IPS在线升级故障分析案例http://www.vants.org/?post=16
使用Omnipeek分析SSH端口攻击案例http://www.vants.org/?post=134
针对随机组播地址的ping攻击案例http://www.vants.org/?post=132
基于UDP 7000端口的DOS攻击案例http://www.vants.org/?post=131
基于UDP 80端口的DOS攻击案例http://www.vants.org/?post=113
可能的数据库密码猜解行为http://www.vants.org/?post=84
PHP漏洞扫描—morfeus fucking scanner  http://www.vants.org/?post=67
web站点cookie安全问题一例http://www.vants.org/?post=64

阅读全文>>

标签: 同步 状态检测 TCP异常终止 团队 IDS Informer 网络分析 数据包分析 协议分析 网络分析能力修行模型

评论(16) 引用(0) 浏览(17523)

【转】iptables的nf_conntrack相关参数引起两个问题

作者:易隐者 发布于:2016-4-23 11:49 Saturday 分类:案例讨论

说在之前】:

      近段时间在处理一个故障时,网上查找相关资料时看到的一篇文章,作者处理故障时的态度和思路堪称技术牛典范,特转发过来分享给大家。

原文作者】:phanx

原文链接】:http://blog.chinaunix.net/uid-7549563-id-4912055.html

原为全文】:

========phanx.com========
Author:   phanx
Updated: 2015-3-23
转载请保留作者信息
=========================

某关键业务系统上频繁出现业务失败,并发生了一次大规模业务中断。
该系统采用两台IBM Power 740运行AIX 6.1+Oracle 11gR2 RAC作为数据库服务器,两台DELL PowerEdge R720作为应用服务器,前端采用F5作为负载均衡设备。
数据库服务器和应用服务器之间有Cisco ASA5585硬件防火墙进行访问控制。
应用服务器上运行自行开发的C程序,通过Oracle Client提供的接口,以长连接的方式访问RAC数据库。
故障时,先检查了数据库服务器的系统负载,发现相对于正常时期,CPU负载偏高,IO负载明显升高,IOPS达到13000左右。
正常时的负载

异常时的负载


检查数据库相关日志,发现有大量的TNS错误:

  1. Fatal NI connect error 12170.
  2. VERSION INFORMATION:  VERSION INFORMATION:
    TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
    TCP/IP NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
    Oracle Bequeath NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production


      VERSION INFORMATION:
    TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
    TCP/IP NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
    Oracle Bequeath NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production


      VERSION INFORMATION:
    TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
    TCP/IP NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
    Oracle Bequeath NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production


      VERSION INFORMATION:
    TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
    TCP/IP NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
    Oracle Bequeath NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
    Mon Feb 23 13:22:16 2015
      Time: 23-Feb-2015 13:22:16




    ***********************************************************************  Time: 23-Feb-2015 13:22:16


      Time: 23-Feb-2015 13:22:16
      Time: 23-Feb-2015 13:22:16
      Tracing not turned on.
      Tracing not turned on.


    Fatal NI connect error 12170.
      Tracing not turned on.
      Tracing not turned on.
      Tns error struct:
      Tns error struct:


      VERSION INFORMATION:
    TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
    TCP/IP NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
    Oracle Bequeath NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
      Tns error struct:
      Tns error struct:
        ns main err code: 12535
        ns main err code: 12535
      Time: 23-Feb-2015 13:22:16
        ns main err code: 12535
        
        ns main err code: 12535
        
      Tracing not turned on.
        
        
      Tns error struct:
    TNS-12535: TNS:operation timed out
    TNS-12535: TNS:operation timed out
    TNS-12535: TNS:operation timed out
        ns secondary err code: 12560
        ns main err code: 12535
    TNS-12535: TNS:operation timed out
        ns secondary err code: 12560
        ns secondary err code: 12560
        nt main err code: 505
        
        ns secondary err code: 12560
        nt main err code: 505
        
        nt main err code: 505
        
        nt main err code: 505
    TNS-12535: TNS:operation timed out
        TNS-00505: Operation timed out


    TNS-00505: Operation timed out
        
        ns secondary err code: 12560
    TNS-00505: Operation timed out
        nt secondary err code: 78
        nt secondary err code: 78
        nt main err code: 505
    TNS-00505: Operation timed out
        nt secondary err code: 78
        nt OS err code: 0
        nt OS err code: 0
        
        nt secondary err code: 78
        nt OS err code: 0
      Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.32.70)(PORT=37975))
    TNS-00505: Operation timed out
        nt OS err code: 0
      Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.32.70)(PORT=25972))
      Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.32.70)(PORT=9108))
        nt secondary err code: 78
      Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.32.70)(PORT=52073))
        nt OS err code: 0
      Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.1.32.70)(PORT=49148))
  3. Mon Feb 23 13:22:16 2015


再检查应用服务器端,发现应用服务进程大量处于Busy状态,无法处理应用数据。再检查应用服务器到数据库的连接情况,发现数据库上报告timeout的连接,在应用服务器上仍然处于ESTABLISHED状态。

  1. [sysadmin@appsrv1 ~]$ netstat -an|grep 10.1.197.15
  2. tcp 0 0 10.1.32.70:37975 10.1.197.15:1521 ESTABLISHED
  3. tcp 0 0 10.1.32.70:25972 10.1.197.15:1521 ESTABLISHED
  4. tcp 0 0 10.1.32.70:9108 10.1.197.15:1521 ESTABLISHED
  5. tcp 0 0 10.1.32.70:52073 10.1.197.15:1521 ESTABLISHED
  6. tcp 0 0 10.1.32.70:49148 10.1.197.15:1521 ESTABLISHED
  7. .
  8. .
  9. .
  10. .

这时候,怀疑是不是ASA阻断了数据库和应用之间的连接。检查ASA配置后发现超时时间设置的是8个小时,这个业务在低谷期也不会出现8小时空闲,并且应用程序会在空闲的时候定期探测数据库长连接是否可用。
因此,觉得不太可能是常见空闲超时导致的连接中断。  继续进行分析,发现数据库里面有较多的direct path read 等待事件。观察应用SQL的执行计划,发现有大量的全表扫描,并且某些SQL的执行时间较长,
超过了60秒
。 很显然这是常见的11g Direct Path Read的副作用,要么让应用开发组去优化SQL,要么关掉11g的针对串行的直接路径读。这样就会缓解系统IO繁忙的情况。这样SQL的执行时间也会降低,如果在
合理的范围内,就不会引发这个故障了。

但是,仅仅是这个原因,应该不会引起TNS Time out的情况,性能不好,SQL执行时间过长,只是让这个问题浮现了出来,并不是这个故障的根本原因。
所以还得继续分析是什么导致应用服务器和数据库服务器之间的已建立连接被单向断掉。

应用组把挂死的服务器进程kill掉后,重启了服务进程,业务暂时是恢复了。
这时候,让应用组找到连接中断时执行的相应的SQL和连接端口,再找到网络组的兄弟帮忙,从Riverbed Cascade上提取了RAC一个节点和其中一个APP的对应端口的通信流,用wireshark打开进行分析。
我们从ARW和ASH报告中发现引起中断的情况中,SQL执行时间都较长,基本达到了5分钟左右。 然后针对这些执行较长的SQL的连接数据流分析,应用服务器在提交SQL执行请求后等待数据库服务器回复。
数据库服务器在执行完以后返回数据给应用服务器时,应用服务器就一直无法接收到数据了,然后数据库服务器就一直重传,直到超时,然后报错TNS Time out。

从这个TCP流上可以清楚看到,appsrv1在12:20.040144的时候提交了SQL执行请求,紧接着收到了racdb1的ACK报文,说明racdb1成功接收了这个请求,并且开始执行。
在15:55.30881的时候,racdb1执行完这个SQL后开始向appsrv1返回结果,SQL执行了215秒左右。这时候,appsrv1没有任何回应。直到最后超时,racdb1发出重置连接的RST报文。

这个情况,总是感觉不对,为什么appsrv1莫名其妙的不响应了呢? appsrv1并没有宕机,网络连接也正常的,百思不得其解。 最后想实在没有办法的话,只能到appsrv1上去抓包看看。
由于appsrv1比较繁忙,在无法确定故障发生的情况下持续抓包的记录数据肯定会相当庞大,并且肯定会对应用服务器造成较大的压力,并且存储空间也是个问题。
这时候,应用组的人报告说偶尔会有一两个服务进程出现挂死的情况。 于是决定去碰碰运气,设好capture条件,只抓取与racdb1的通信,与其余关联应用服务器的包全部过滤掉,抓了5分钟,就已经有20个G的数据了。
这么大的数据,我的4G内存i3小破本子开起来都是个问题,于是找了一台强力的测试服务器,传上去看看。   翻着翻着发现了一些TCP重传,看起来像故障的现象了,但是发现appsrv1对于重传却返回了
ICMP  Host Administratively Prohibited,并不是完全没有反应。 于是再找网络组按照时间段提取数据,发现故障时是一样的,在racdb1重传的时候,appsrv1每个重传都回应了ICMP  Host Administratively Prohibited。

原来,网络组的哥们从Riverbed Cascade里面提取数据流的时候是设定了只提取TCP相关端口的报文,ICMP报文就被漏掉了,没有提取出来。于是,重新提取故障时候的TCP流和相关数据包。


这个时候就可以看到完整的信息了。确实每个重传都有回应的。
TCP流是建立起来的,iptables里面也应该也有正常的流状态信息,为什么会被appsrv1拒绝呢?
继续对appsrv1进行检查,发现 /etc/sysctl.conf里面配置了这么一句

net.netfilter.nf_conntrack_tcp_timeout_established = 300

就是它让iptables对于已建立的连接,300秒若没有活动,那么则清除掉,默认的时间是432000秒(5天)。
问是谁设置的这个参数,答复是应用组在上线前做性能测试时,按照应用供应商的建议修改的。为啥要改,为啥改成这个值也不清楚 
好吧,应该就是它了,改回默认的值 432000 应该就能解决了。同时让应用组的优化优化SQL,就可以写故障报告了。
故事就到这里就完了?    当然不是。 在调整了这个值后,一开始还风平浪静。过了一段时间,应用组又来报告说,又出现了很少的
业务超时,而且有越来越频繁的趋势,从一天一两次到一条一二十次。真是不省心啊。。

继续了解情况,这次仿佛跟数据库服务器没啥关系了,是这个应用服务器到服务器总线应用之间的连接出现了问题。服务总线应用服务器向该应用服务器发起连接的时候,偶尔会被拒绝。
考虑到应用服务器之前有F5来作为负载均衡,先检查了F5上应用服务状态有没有异常,结果良好,F5上对应用的健康探测没有异常。 好吧,还是直接看数据流,为啥会拒绝应用连接。
服务总线应用服务器和该应用服务器之间通信是短连接,有业务调用的时候,由服务总线方发起连接。应用组找到了被拒绝的连接,通过debug日志找到相关端口信息,继续让网络组
提取相关连接数据包。

这里可以看到,在svcbus2向appsrv1发起请求后,同样有应答,但是一分钟后,svcbus2关闭了连接。再过了3分钟appsrv1处理完请求后返回数据给svcbus2的时候就被svcbus2给拒绝掉了,然后同样也是不停重传,最后超时。
应用组说svcbus2上,应用有一个60秒超时的机制,当对端在60秒内没有返回结果就直接关闭这个请求,断掉连接。 
从上面的报文也可以看到,svcbus2发起了FIN报文,但是由于appsrv1没有处理完,所以这个连接关闭是单向的,直到appsrv1处理完成,重传数据超时,连接完全关闭。
这和svcbus2新建连接到appsrv1被拒绝有啥关系呢?我一时也没有想明白。  appsrv1上的iptables对于服务端口应该是一直开放的,不应该拒绝新建的连接啊,除非这个新建的连接有什么特殊的地方。
通过红帽的客户网站,找到了一些相关信息。  
https://access.redhat.com/solutions/73353   iptables randomly drops new connection requests

  • if /proc/net/ipv4/netfilter/ip_conntrack_tcp_loose is set to 1, iptables creates a new connection-tracking entry after receiving any packet, not just packets with the SYN flag set
  • the ip_conntrack_tcp_loose setting is useful in firewalls for keeping already established connections unaffected if the firewall restarts, but this causes issues in the following scenario:
    • a client initiates a new connection with the same source port it used in a previous connection
    • the server already has an iptables connection-tracking entry for the same IP address and port, with states ESTABLISHED and UNREPLIED
    • the default rule gets hit, instead of the desired one
    • the packet is dropped, and the server returns icmp-host-prohibited

https://access.redhat.com/solutions/73273   Why iptables sporadically drops initial connections requests?
This behavior is caused by enabling ip_conntrack_tcp_loose sysctl parameter which enables iptables to create a conntrack entry whenever it sees any packet from any direction and not just SYN packet. 
This is called connection picking and is usually used by the firewalls to ensure that the ongoing end to end sessions remain active if for some reason the firewall gets restarted. But this feature is not needed in standalone servers.

这里面提到了iptables在规则为allow的情况下也会对某些数据包drop的情况。大意就是在默认情况下(/proc/net/ipv4/netfilter/ip_conntrack_tcp_loose 为1时),iptables会对即时是不完整的TCP连接也会记录其状态,这样避免
iptables重启的时候影响已有的连接,但是会影响一些特殊情况。

我们的应用正好就出现了这种特殊情况。当svcbus2因为等待appsrv1应答超时的时候,关闭了连接。而appsrv1上的nf_conntrack表中,当收到svcbus2发送的FIN包是,对于这个连接的记录会变成CLOSE_WAIT状态,然后在60秒后,
条目被清除。 但是,当appsrv1开始回应数据的时候,nf_conntrack表中又出现了这个连接的条目,并且状态是ESTABLISHED [UNREPLIED]。

  1. [root@appsrv1 ~]# grep 51522 /proc/net/nf_conntrack
        ipv4     2 tcp      6 35 CLOSE_WAIT src=10.1.32.70 dst=10.1.41.192 sport=9102 dport=51522 src=10.1.41.192 dst=10.1.32.70 sport=51522 dport=9102 [ASSURED] mark=0 secmark=0 use=2
    .
  2. .
  3. wait more seconds
  4. .
  5. .
  6. [root@appsrv1 ~]# grep 51522 /proc/net/nf_conntrack
  7. ipv4 2 tcp 6 431965 ESTABLISHED src=10.1.32.70 dst=10.1.41.192 sport=9102 dport=51522 [UNREPLIED] src=10.1.41.192 dst=10.1.32.70 sport=51522 dport=9102 mark=0 secmark=0 use=2


这个条目,由于默认的net.netfilter.nf_conntrack_tcp_timeout_established = 432000 的影响,会一直保持5天,直到红色那个值变为0才会被清除。 这就导致了当svcbus2再以相同的源端口51522向appsrv1发起连接的时候,appsrv1的iptables
会拒绝掉这个请求。

那是不是设置net.ipv4.netfilter.ip_conntrack_tcp_loose=0就行了呢,副作用怎么消除呢?
反复想了想,还是不想就这样了,决定看看有没有其它更优的方法。

到测试环境模拟这个故障,服务端口就用TCP 8888,客户机源端口就用TCP 22222

  1. 1.配置服务器的iptables 允许tcp 8888端口.
  2. 2.用python来建立一个监听服务,监听在tcp 8888.
  3. [root@server ~]# python
  4. Python 2.6.6 (r266:84292, Sep 4 2013, 07:46:00)
  5. [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
  6. Type "help", "copyright", "credits" or "license" for more information.
  7. >>> import socket
  8. >>> serversocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  9. >>> serversocket.bind(("0.0.0.0",8888))
  10. >>> serversocket.listen(5)
  11. >>> (clientsocket, address) = serversocket.accept()
  12. 3. 从客户端以tcp 22222为源端口发起连接,并发送请求数据
  13. [root@client ~]# python
  14. Python 2.6.6 (r266:84292, Sep 4 2013, 07:46:00)
  15. [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
  16. Type "help", "copyright", "credits" or "license" for more information.
  17. >>> import socket
  18. >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  19. >>> s.bind(("0.0.0.0",22222))
  20. >>> s.connect(("1.1.1.101",8888))
  21. >>> s.send("request",100)
  22. 在server端检查iptable contrack 的状态
  23. [root@server ~]# grep 103 /proc/net/nf_conntrack
  24. ipv4 2 tcp 6 431949 ESTABLISHED src=1.1.1.103 dst=1.1.1.101 sport=22222 dport=8888 src=1.1.1.101 dst=1.1.1.103 sport=8888 dport=22222 [ASSURED] mark=0 secmark=0 use=2
  25. Wait some seconds, then close the connection on client.
  26. >>> s.close()
  27. >>> exit()
  28. 继续检查server端的iptable contrack 状态
  29. [root@server ~]# grep 103 /proc/net/nf_conntrack
  30. ipv4 2 tcp 6 54 CLOSE_WAIT src=1.1.1.103 dst=1.1.1.101 sport=22222 dport=8888 src=1.1.1.101 dst=1.1.1.103 sport=8888 dport=22222 [ASSURED] mark=0 secmark=0 use=2
  31. [root@server ~]# sleep 55
  32. [root@server ~]# grep 103 /proc/net/nf_conntrack
  33. server端的条目消失了.
  34. 4. 当server端向client发送响应数据的时候
  35. >>> clientsocket.recv(1000)
  36. 'request'
  37. >>> clientsocket.send("respond",100)
  38. 再到server端查看iptable contrack 状态就会发现有 ESTABLISHED[UNREPLIED] 条目.
  39. 但是看TCP 连接的状态却是 CLOSE_WAIT.
  40. [root@server ~]# grep 103 /proc/net/nf_conntrack
  41. ipv4 2 tcp 6 431996 ESTABLISHED src=1.1.1.101 dst=1.1.1.103 sport=8888 dport=22222 [UNREPLIED] src=1.1.1.103 dst=1.1.1.101 sport=22222 dport=8888 mark=0 secmark=0 use=2
  42. [root@server ~]# netstat -ntp|grep 103
  43. tcp 1 7 1.1.1.101:8888 1.1.1.103:22222 CLOSE_WAIT 28978/python
  44. 这个时候,从wireshark上抓包也发现了client拒绝server的响应数据并发送ICMP[host administratively prohibited].
  45. 当server端TCP连接CLOSE_WAIT超时后, 受到net.netfilter.nf_conntrack_tcp_timeout_established参数的控制,nf_contrack表中ESTABLISHED[UNREPLIED] 条目是依然存在的。
  46. [root@server ~]# netstat -ntp|grep 103
  47. [root@server ~]# grep 103 /proc/net/nf_conntrack
  48. ipv4 2 tcp 6 431066 ESTABLISHED src=1.1.1.101 dst=1.1.1.103 sport=8888 dport=22222 [UNREPLIED] src=1.1.1.103 dst=1.1.1.101 sport=22222 dport=8888 mark=0 secmark=0 use=2
  49. 监听端口状态是正常的
  50. [root@server ~]# netstat -nplt|grep 8888
  51. tcp 0 0 0.0.0.0:8888 0.0.0.0:* LISTEN 28978/python
  52. 5. 这个时候,当client再以tcp 22222为源端口向tcp 8888发起连接,server端的iptables就拒绝了这个SYN报文. client端连接报错。
  53. [root@client ~]# python
  54. Python 2.6.6 (r266:84292, Sep 4 2013, 07:46:00)
  55. [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
  56. Type "help", "copyright", "credits" or "license" for more information.
  57. >>> import socket
  58. >>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  59. >>> s.bind(("0.0.0.0",22222))
  60. >>> s.connect(("1.1.1.101",8888))
  61. Traceback (most recent call last):
  62. File "", line 1, in
  63. File "", line 1, in connect
  64. socket.error: [Errno 113] No route to host
  65. >>>

经过这个模拟,也验证了故障的成因,那么要解决问题,就简单了。

有两边可以想办法,一是appsrv1这边,如果让该条目早点过期,那么只要端口重用不是特别快的情况下,这个问题就不会发生。
在不改造应用的情况下,这是一个较好的临时解决方案,但是过期时间设多久,要先要满足前一个问题的SQL最长执行时间,然后观察端口重用的时间有没有短于SQL最长执行时间。

appsrv1这边存在条目的原因是返回数据被拒绝后的TCP重传数据包被iptables nf_conntrack记录,svcbus2又没有响应的TCP回应报文。
那么另外一个方法就是如果能让svcbus2正常响应就解决了。   怎么能正常解决呢?

iptables nf_contrack 还有另外一个参数 net.netfilter.nf_conntrack_tcp_timeout_close_wait。 默认是60秒跟TCP的CLOSE_WAIT 超时时间是一致的。通过试验模拟这个故障发现,如果把这个时间设长,超过TCP CLOSE_WAIT 超时时间
那么在TCP连接关闭后,appsrv1的返回报文还可以到达svcbus2的内核, svcbus2会直接发送TCP RST包将这个连接重置。这样appsrv1上的TCP连接和nf_contrack中的条目都会清除掉。

看模拟的过程。


当 appsrv-test 在svcbus-test发送FIN连接后过了127秒开始发送响应数据,这时候svcbus-test就立刻回应了RST报文,后来svcbus-test半个小时候在重新再用tcp 22222端口向appsrv-test tcp 8888发起连接的时候,问题问题,连接可以正常建立了。
当然这种处理方法应用层会收到错误,要对这个错误进行处理才行。

由于第二种方法还涉及应用代码的调整和测试,因此通过观察发现SQL最长执行时间在15分钟左右,服务总线源端口重用时间大概在4个小时,但是由于重用源端口的时候,目标端口还不一定是appsrv上的对应端口,因此4小时不一定形成冲突。
综合考虑了一下,设置

net.netfilter.nf_conntrack_tcp_timeout_establishe=7200

是一个比较合适的解决方法。调整后,经过近期的观察,没有出现业务失败了。


经验:
系统参数调整要小心,特别是对应用行为不清楚的情况下,要多测试。该业务系统就是没有经过严格的测试,为了赶目标节点匆匆上线继而发生后续故障。
另外,在系统软件部署的时候,管理员使用的文档中没有及时更新,缺乏了对Oracle 11g一些容易引起问题的新特性参数进行调整的要求。当遇到应用
没有充分优化的情况下,由于这个新特性带来的性能加速恶化,也对相关故障产生了间接的影响。 因此及时更新文档,保证系统的参数基线合理显得也很重要。
最后,运维工作纷繁复杂,要静下心来仔细的看,才会发现其中的小细节。

阅读全文>>

标签: iptables,ICMP Host Administratively Prohibited,nf_conntrack

评论(0) 引用(0) 浏览(121)

【转】WireShark黑客发现之旅—肉鸡邮件服务器

作者:易隐者 发布于:2015-7-7 13:01 Tuesday 分类:网络安全

【原文链接】:http://drops.wooyun.org/tips/6944

【原文作者】:聚锋实验室

【原文全文】:

0x00 背景


肉鸡也称傀儡机,是指可以被黑客远程控制的机器。一旦成为肉鸡,就可以被攻击者随意利用,如:窃取资料、再次发起攻击、破坏等等。下面将利用WireShark一起学习一种肉鸡的用途:广告垃圾邮件发送站。

0x01 发现问题


在对某企业服务器群进行安全检测时发现客户一台服务器(10.190.214.130)存在异常,从其通信行为来看应该为一台空闲服务器。 经过一段时间的抓包采集,对数据进行协议统计发现,基本均为SMTP协议。

enter image description here

enter image description here

SMTP协议为邮件为邮件传输协议。正常情况下出现此协议有两种情况:

1、用户发送邮件产生。
2、邮件服务器正常通信产生。

该IP地址属于服务器,所以肯定非个人用户利用PC机发送邮件。

那这是一台邮件服务器?如果是,为什么仅有SMTP协议,POP3、HTTP、IMAP等等呢?

带着疑问我们统计了一下数据的IP、端口等信息:

enter image description here

统计信息表明:所有通信均是与61.158.163.126(河南三门峡)产生的SMTP协议,且服务器(10.190.214.130)开放了TCP25端口,它的的确确是一台邮件服务器。

到这,很多安全分析人员或监控分析软件就止步了。原因是IP合理、逻辑也合理、SMTP协议很少有攻击行为,以为是一次正常的邮件通信行为。那么很可惜,你将错过一次不大不小的安全威胁事件。

职业的敏感告诉我,它不是一台合理的邮件服务器。这个时候需要用到应用层的分析,看一看它的通信行为。继续看看SMTP登陆过程的数据。

enter image description here

从数据看出,邮箱登陆成功,右键Follow TCPStream可以看见完整登陆信息。

enter image description here

334 VXNlcm5hbWU6          // Base64解码为:“Username:”
YWRtaW4=  //用户输入的用户名,Base Base64解码为:“admin”
334 UGFzc3dvcmQ6         //Base64解码为:“Password:”
YWRtaW4=  //用户输入的密码,Base Base64解码为:“admin”
235 Authentication successful.  //认证成功
MAIL FROM:<admin@system.mail
/* <![CDATA[ */!function(){try{var t="currentScript"in document?document.currentScript:function(){for(var t=document.getElementsByTagName("script"),e=t.length;e--;)if(t[e].getAttribute("cf-hash"))return t[e]}();if(t&&t.previousSibling){var e,r,n,i,c=t.previousSibling,a=c.getAttribute("data-cfemail");if(a){for(e="",r=parseInt(a.substr(0,2),16),n=2;a.length-n;n+=2)i=parseInt(a.substr(n,2),16)^r,e+=String.fromCharCode(i);e=document.createTextNode(e),c.parentNode.replaceChild(e,c)}}}catch(u){}}();/* ]]> */>  //邮件发送自……

这段数据表明:61.158.163.126通过SMTP协议,使用用户名admin、密码admin,成功登陆邮件服务器10.190.214.30,邮件服务器的域名为@system.mail,且利用admin@system.mail发送邮件。

一看用户名、密码、邮箱,就发现问题了:

1、admin账号一般不会通过互联网登陆进行管理。

2、“二货”管理员才会把admin账号设为密码。

3、域名@system.mail与客户无任何关系。

很显然,这是一台被控制的邮件服务器—“肉鸡邮件服务器”。

0x02 行为跟踪


发现问题了,下一步跟踪其行为,这个肉鸡服务器到底是干什么的。查看Follow TCPStream完整信息可发现:这是一封由admin@system.mail群发的邮件,收件人包括:www651419067@126.com、wyq0204@yahoo.com.cn、zhaocl1@163.com等10个人(带QQ的邮箱暂时抹掉,原因见最后),邮件内容不多。

enter image description here

enter image description here

为看到完整邮件内容,我们可以点击Save As存为X.eml,用outlook等邮件客户端打开。

enter image description here

一看邮件,所有谜团都解开了。邮件内容就是一封“巧虎”的广告垃圾邮件,该服务器被攻击者控制创建了邮件服务器,用于垃圾邮件发送站。再用同样的方法还原部分其它邮件:

enter image description here

enter image description here

可以看出邮件内容完全一样,从前面图中可看出短时间的监控中SMTP协议有几十次会话,也就说发送了几十次邮件,涉及邮箱几百人。邮件中的域名http://url7.me/HnhV1打开后会跳转至巧虎商品的广告页面。

enter image description here

0x03 分析结论


1、该服务器经简单探测,开放了TCP25/110/445/135/3389/139等大量高危端口,所以被攻击控制是必然。

2、该服务器已被控制创建了肉鸡邮件服务器(WinWebMail),邮件服务器域名为@system.mail,由61.158.163.126(河南省三门峡市)使用admin@system.mail用户登录,通过邮件客户端或专用软件往外发送垃圾邮件。

3、简单百度一下,很多人会经常收到来自admin@system.mail的垃圾邮件,今天终于弄清了它的来龙去脉。

4、垃圾邮件发送不是随便发的,是很有针对性的。巧虎是幼儿产品,从接受邮件的QQ号码中随便选取4位查询资料发现发送对象可能都为年轻的爸爸妈妈。

enter image description here

enter image description here

enter image description here

申明:文章中出现IP、邮箱地址等信息均为安全监控、攻击防范学习交流所用,切勿用于其它用途,否则责任自负。

0x04 后续文章初步设计


对于后续文章内容,初步设计WireShark黑客发现之旅--暴力破解、端口扫描、Web漏洞扫描、Web漏洞利用、仿冒登陆、钓鱼邮件、数据库攻击、邮件系统攻击、基于Web的内网渗透等。但可能会根据时间、搭建实验环境等情况进行略微调整。 (By:Mr.Right、K0r4dji)

阅读全文>>

标签: wireshark 安全分析 垃圾邮件

评论(1) 引用(0) 浏览(1860)

SharkFest'15 Retrospective

作者:易隐者 发布于:2015-7-3 23:31 Friday 分类:网络分析

SharkFest'15 Retrospective

June 22nd - 25th, 2015 
Computer History Museum | Mountain View, California

Packet Challenge

Check back soon for the SharkFest'15 Packet Challenge Answers!

Keynote Presentations

High Impact: How Computer Geeks, Geniuses and Renegades are Changing the World
John C Hollar

Tuesday Classes

Wednesday Classes

Thursday Classes

阅读全文>>

标签: wireshark sharkfest sharkfest2015

评论(0) 引用(0) 浏览(1100)

【转】WireShark黑客发现之旅--开篇

作者:易隐者 发布于:2015-6-20 8:27 Saturday

【原文链接】:http://drops.wooyun.org/tips/6631

【原文作者】:聚锋实验室

【原文全文】:

0x00 先说几句


一看题目,很多朋友就会有疑问:市面上那么多的安全监控分析设备、软件,为什么要用WireShark来发现黑客和攻击行为?我想说的是WireShark目前作为最优秀的网络分析软件,如果用好了,比任何设备、软件都Nice。首先,它识别的协议很多;其次,WireShark其实具备很多分析功能;最主要的,它免费,既能采集又能分析,不丢包、不弃包。

我们虽然也接触了很多监控分析设备,但在分析中始终离不开WireShark的辅助,喜欢它的“诚实”,不忽悠、不遗漏,完完全全从原理上去认识数据。

本系列就是要抛开了各种所谓分析“神器”和检测设备,完全依靠WireShark从通信原理去发现和解密黑客的各种攻击行为。当然,仅是交流学习贴,不当之处请各位大神“轻喷”。

0x01 WireShark的常用功能


介绍WireShark的书籍和文章比较多,本文就不献丑细讲了,一起了解一下部分常用的分析功能。

1、抓包捕获

菜单中选择Capture,选择Interface,然后选择需抓包的网卡。

enter image description here

可以勾选网卡,点击Start开始抓包。如想连续抓包设置文件大小、定义存放位置、过滤性抓包,点击Options进行设置。

enter image description here

2、数据过滤

由于抓包是包含网卡所有业务通信数据,看起来比较杂乱,我们可以根据需求在Filter对话框中输入命令进行过滤。常用过滤包括IP过滤(如:ip.addr==x.x.x.x,ip.src== x.x.x.x,ip.dst== x.x.x.x)、协议过滤(如:HTTP、HTTPS、SMTP、ARP等)、端口过滤(如:tcp.port==21、udp.port==53)、组合过滤(如:ip.addr==x.x.x.x && tcp.port==21、tcp.port==21 or udp.port==53)。更多过滤规则可以在Expression中进行学习查询。

enter image description here

3、协议统计、IP统计、端口统计

协议统计:在菜单中选择Statistics,然后选择Protocol Hierarchy,就可以统计出所在数据包中所含的IP协议、应用层协议。

enter image description here

IP统计:在菜单中选择Statistics,然后选择Conversation,就可以统计出所在数据包中所有通信IP地址,包括IPV4和IPV6。

enter image description here

端口统计:同IP统计,点击TCP可以看到所有TCP会话的IP、端口包括数据包数等信息,且可以根据需求排序、过滤数据。UDP同理。

enter image description here

4、搜索功能

WireShark具备强大的搜索功能,在分析中可快速识别出攻击指纹。Ctrl+F弹出搜索对话框。

Display Filter:显示过滤器,用于查找指定协议所对应的帧。

Hex Value:搜索数据中十六进制字符位置。

String:字符串搜索。Packet list:搜索关键字匹配的Info所在帧的位置。Packet details:搜索关键字匹配的Info所包括数据的位置。Packet bytes:搜索关键字匹配的内容位置。

enter image description here

5、Follow TCP Stream

对于TCP协议,可提取一次会话的TCP流进行分析。点击某帧TCP数据,右键选择Follow TCP Stream,就可以看到本次会话的文本信息,还具备搜索、另存等功能。

enter image description here

6、HTTP头部分析

对于HTTP协议,WireShark可以提取其URL地址信息。

在菜单中选择Statistics,选择HTTP,然后选择Packet Counter(可以过滤IP),就可以统计出HTTP会话中请求、应答包数量。

enter image description here

在菜单中选择Statistics,选择HTTP,然后选择Requests(可以过滤IP),就可以统计出HTTP会话中Request的域名,包括子域名。

enter image description here

在菜单中选择Statistics,选择HTTP,然后选择Load Distribution(可以过滤IP),就可以统计出HTTP会话的IP、域名分布情况,包括返回值。

enter image description here

0x02 WireShark分析攻击行为步骤


利用WireShark分析攻击行为数据,首先得具备一定的网络协议

知识,熟悉常见协议,对协议进行分层(最好分七层)识别分析。(如果不熟悉也没关系,现学现用也足够)。然后,需熟悉常见的攻击行为步骤、意图等等。画了张图,不太完善,仅作参考。

enter image description here

0x03 后续文章初步设计


对于后续文章内容,初步设计WireShark黑客发现之旅--暴力破解、端口扫描、Web漏洞扫描、Web漏洞利用、仿冒登陆、钓鱼邮件、数据库攻击、邮件系统攻击、基于Web的内网渗透等。但可能会根据时间、搭建实验环境等情况进行略微调整。 (By:Mr.Right、K0r4dji)

阅读全文>>

评论(0) 引用(0) 浏览(1689)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1