host 命令的一些基本用法

查看A记录,例: 查看baidu.com 对应的多个ip (dns 轮询)
>host baidu.com
baidu.com has address 202.108.22.46
baidu.com has address 220.181.38.84

查看别名,例:
>host -t cname gongyi.sina.com.cn
gongyi.sina.com.cn is an alias for ad.sina.com.cn.

查看mx记录,例:
>host -t mx sina.cn
sina.cn mail is handled by 10 sinamx.vip.sina.com.cn.
sina.cn mail is handled by 20 mx2.vip.sina.com.cn.

是否递归, -r 不递归 ,否则递归

-r  : 在第一个dns server中没有查到,但不负责去存在的dns上查,只是返回存在该记录的dns
[root@ljj ~]# host -r -v phpor.cn        
Trying "phpor.cn"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8681
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;phpor.cn.                      IN      A

;; AUTHORITY SECTION:
phpor.cn.               17253   IN      NS      ns.dns.net.cn.
phpor.cn.               17253   IN      NS      ns7.dns.net.cn.

;; ADDITIONAL SECTION:
ns7.dns.net.cn.         1812    IN      A       61.135.129.16
ns.dns.net.cn.          1812    IN      A       61.135.129.2

Received 101 bytes from 10.210.12.10#53 in 34 ms

不使用-r 选项,返回一个查询结果,并且返回2个存在该记录的dns及其ip地址
[root@ljj ~]# host  -v phpor.cn  
Trying "phpor.cn"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48013
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;phpor.cn.                      IN      A

;; ANSWER SECTION:
phpor.cn.               3600    IN      A       61.236.150.132

;; AUTHORITY SECTION:
phpor.cn.               17206   IN      NS      ns.dns.net.cn.
phpor.cn.               17206   IN      NS      ns7.dns.net.cn.

;; ADDITIONAL SECTION:
ns7.dns.net.cn.         1765    IN      A       61.135.129.16
ns.dns.net.cn.          1765    IN      A       61.135.129.2

Received 117 bytes from 10.210.12.10#53 in 42 ms

现在再使用-r 也能取到phpor.cn的ip地址了,因为最近的那个dns已经缓存了该记录,(成为非授权的,即:not authoritative)
[root@ljj ~]#host -r -v phpor.cn
Trying "phpor.cn"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4402
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;phpor.cn.                      IN      A

;; ANSWER SECTION:
phpor.cn.               3326    IN      A       61.236.150.132

;; AUTHORITY SECTION:
phpor.cn.               16932   IN      NS      ns.dns.net.cn.
phpor.cn.               16932   IN      NS      ns7.dns.net.cn.

;; ADDITIONAL SECTION:
ns7.dns.net.cn.         1491    IN      A       61.135.129.16
ns.dns.net.cn.          1491    IN      A       61.135.129.2

Received 117 bytes from 10.210.12.10#53 in 44 ms
[root@ljj ~]#

注意: host 命令不参考hosts文件

Linux 通过iptables 实现 NAT 实例

1. 网络状况

10.54.38.18 可以提供apache服务 【下面简称18】

10.218.19.92 一个Linux服务器【下面简称92】

10.218.19.204 我自己的Windows工作用机【下面简称204】

2. 实现目标

在204上输入,10.218.19.92:8018 可以访问18上80端口提供的www服务

3. 实现方法

只需在92上做如下操作即可:
# 允许IP转发
echo "1" > /proc/sys/net/ipv4/ip_forward
# 对于目的地址是10.218.19.92(自己) 端口是8018 的包,修改目的地址为10.54.38.18:80
iptables -t nat -A PREROUTING -d 10.218.19.92 -p tcp -m tcp –dport 8018 -j DNAT –to-destination 10.54.38.18:80
# 源地址是10.218.19.204的包修改源ip为自己eth0的ip地址
iptables -t nat -A POSTROUTING -s 10.218.19.204 -o eth0 -j MASQUERADE

注意: 你的iptables 要有DNAT模块

Iris 网络抓包、解包工具

下载地址: http://www.cngr.cn/dir/207/219/2006121115903.html

使用帮助:

实战网络数据包拦截分析工具Iris
文/郑志勇
Iris是一款最常用的,功能强大的数据包拦截分析工具,可用于拦截通过网络传输的各类TCP/IP/UDP/ICMP数据包,同时可对拦截的数据包进行分析,了解网络协议的结构和组成,方便监控通过网络传输的数据、检测木马程序等。
一、安装配置
由于Iris可能被别有用心的人非法使用,所以绝大多数的软件下载站点并不提供该软件的下载,软件只能在一些网络安全网站上找到,建议直接到软件开发公司eEye Digital Security的主页处下载,下载地址是
http://www.eeye.com/html/Products/Iris/Download.html。目前的最新版本是4.0.6,未注册只能使用15天。
程序安装比较简单,一路Next就可以了。第一次运行需要配置一些参数。
(1)Capture(捕获) 设置数据包捕获的运行及显示方式,此项可不设置。
(2)Decode(解码)  设置数据包解码参数,此项可不设置。
(3)Adapters(网卡) 设置要捕获数据包的网卡,此项是必须要做的。如果你的机器只有一块网卡,直接单击网卡名,再单击“应用”按钮即可。如果你的机器有两块以上的网卡,就要根据具体的情况选择了。下面举个简单的例子:
假设单位内所有的机器都通过一台服务器接入Internet,服务器有两块网卡,一块和Internet连接,一块作为内网连接,所有的内网机器的数据包都将通过该网卡,为了监视内部网络数据包,就必须选择内部网卡作为Iris的工作网卡。要了解你的网卡类型和名称可通过右击“网上邻居”,选择“属性”进行查看。
(4)Guard(警告) 设置报警声及过滤特征,此项可不设置。
(5)Miscellaneous(混合) 设置数据包缓冲区的大小及其他,此项可不设置。
二、 形势分析
Iris启动运行界面比较复杂,到处是按钮和图标,从哪里下手是初学者最先遇到的问题。要想充分发挥Iris的功能,第一步就是首先要了解目前网络的使用情况,可通过下面步骤进行:
1.运行Iris。
2.打开菜单“Capture/Start(捕获/开始)”,或单击菜单下的绿色三角形工具按钮。
3.单击右边的“Capture(捕获)”工具按钮,可以看到Iris正在辛勤工作,不断地捕获数据包。
4.工作一段时间后(建议捕获2000个数据包),打开菜单“Capture/Stop(捕获/停止)”或单击菜单下的红色正方形工具按钮停止捕获数据。此时,你可以看到大量的数据包在列表,看不懂没关系,先放在那里。
5.使用Iris的Decode(解码)功能分析一下数据。单击右边的“Decode”工具按钮,可以发现Iris已经把所有正在上网的机器都在“Hosta  activity(活动的计算机)”中列出来了。
图一  查看活动的计算机
查看网络上有哪些电脑正在运行,也可以通过菜单下的“Address Book(地址簿)”来实现,不过需要花费很长时间,不建议使用。
三、 分析“敌”情
掌握了目前有哪些电脑在上网是第一步,下面来看看用户在做什么?单击“Hosta activity”右上角“+”,可以展开“Hosta activity”下的所有资料。此时你就可以发现Iris自动帮你分析出用户正在使用网络服务的类型,有HTTP,MSN Messenger,SMTP , FTP 等一一列出!在单击其中一项,看看右下角的窗口里有什么,里面还有具体的内容哦!哈哈!在看新闻,有意思!我也看看,单击窗口上的“GO”按钮即可,不过有时单击“GO”按钮只是下载页面的其中一个文件,要想了解整个页面的情况,可以在窗口中查找“Referer: ”后面跟的就是网址。来告诉他一下,单击窗口上的小人按钮,马上发个信息给他,请礼貌用语哦!还有许多数据包Iris无法分析,没关系一个个地往下移,看看。哈!他在玩联众游戏!当然发现这些,就要靠平时的经验积累了,例如:玩不同的网络游戏都有什么不同的文字提示、哪些服务要使用哪些端口号、不同服务使用的是什么协议之类都要熟悉。只有这样才能更好的使用Iris。
图二  分析结果
四、重点突破
掌握了网络总体情况,下面就可以针对具体的用户进行数据分析了,下面以分析MSN Messenger的数据传递过程为例,介绍一下具体的操作过程。
1.了解使用Msn Messager的机器的IP地址。通过前面的分析很容易发现哪些机器使用MSN Messenger将其IP地址记录下来。
2.设置Filters(过滤),设置Filters的目的在于,拦截和所要达到的目标不相干的数据包,只允许想要的数据包通过,方便对数据分析。
3.单击右边的“Filters”工具按钮,即可设置过滤的条件。
可以选择过滤的方式有:Hardware filter(硬件过滤)、Layer2,3(数据链路层网络层过滤)、Words(单词过滤)、Mac address(Mac 地址)、IP address(IP 地址)、Ports(端口)、Advance(高级)七种形式。如果你了解相关知识,可以很容易设置。如果不了解,就不用设置过滤,Iris提供的数据非常直观,慢慢看也没有关系。
4.要分析MSN Messenger的数据传递过程,只要设置IP address(IP 地址)、Ports(端口)即可,在“Edit filters settings(编辑过滤设置)”窗口中,单击“IP address(IP地址)”按钮,“Mode(模式)”选择为“Include(包含)”,“Address 1”中输入要分析的机器的IP地址,“Dir(方向)”选择双向箭头,“Address 2”不必设置。最后单击“应用”按钮。
5.在“Edit filters settings”窗口中,单击“Ports”按钮,模式选择为“Include”,在Known ports(已知端口)中,找到“MSN Messenger”后双击,单击“确定”退出设置界面。
6.下面就可以打开菜单“Capture/Start”,开始捕获数据包。
只要目标机器打开MSN开始聊天,你就可以发现Iris不断地捕获到数据,停止捕获后就可以分析数据包了。
使用同样的办法,还可以对特定的机器的SMTP协议,POP3协议等等各种协议的数据进行捕获和分析以便了解用户网络的使用并进行管理和维护。
五、保卫战
利用Iris的数据包捕获功能,还可以把它作为简易的木马检测工具来使用(不过确实大材小用了),具体的操作步骤和分析MSN Messenger的数据传递过程有些类似,不同的是,不需要设置Ports,这样就能够发现所有进出你计算机的数据包,可以通过检查数据包的合法性,来判断是否已经中了木马!
同时还可以单击右边的“Guard”(警告)工具按钮,随时提醒是否有其它电脑连接你的计算机。一旦发现其它电脑连接你的计算机,Iris自动发出警报声,并记录下对方的地址,提供给使用者分析。
最后要说的是Iris能够分析每个网络数据包的组成及含义,它本身就是一个非常生动的TCP/IP协议教程,对Internet编程爱好者来说,死啃TCP/IP协议教程是非常辛苦的事,但如果你使用了Iris,可以将抽象的协议标准和实际应用紧密联系在一起,可达到事半功倍的效果。
(编者注:由于Iris功能强大,请不要将本软件用于非法目的,如非法获取他人密码,监控他人电脑等。由于软件特殊,恕不提供。) 

相关文章:
用协议分析工具学习TCP/IP(二):http://tech.ccidnet.com/art/1084/20040205/88746_1.html
ICMP协议概述:http://hi.baidu.com/kizz1986/blog/item/1c977387ad9f802bc75cc351.html

Linux下软件发布技巧

Linux现在能够被越来越多的人认识及使用,在很大程度上可以归结为其具有强大的C编译器——gcc、便于交流的环境——Internet,以及雄厚的师资——有数不清的程序员在开发数不清的代码。
  
  有了Linux和Internet,我们可以很容易地在世界范围内发布软件作品,与他人交流开发心得与技巧。当我们完成了自己的软件作品,怎么样才能让其他人以快捷、方便的方式与自己分享成果、理解开发思想呢?这就是我们要讨论的Linux下软件打包和发布的方法。
  
  在Linux尚未流行之前,Linux下软件打包和发布应用仅仅停留在程序员中,因此软件分发基本都使用源代码方式,便于大家相互学习和交流。随着大量普通用户和商业应用的参与,源代码方式就显得过于繁琐,对用户要求太高,而且耗费时间,所以编译好的二进制文件发布方式开始流行起来。这就是Linux下两种主要的软件发布方式:源代码方式和二进制方式。源代码方式通常是将源文件以tar、tgz格式打包,解包后进行配置、编译和安装;二进制方式以Red Hat公司的RPM(Red Hat Package Manager)格式最广泛,它可以完成所有的步骤,自动将软件安装到系统中。
  
  tgz源代码方式
  
  使用这种源代码方式发布的软件,一般需要进行下列步骤:
  
  1.解开压缩文件,如tar、gz、bz2或tgz。
  
  2.执行./configure [–options] 进行软件的配置。
  
  3.执行make、make install等命令编译代码,并安装到系统中。
  
  因此,如果要发布软件,就需要生成可供配置的configure文件和进行编译安装的Makefile。
  
  下面以一个简单的例子来说明。假设要发布一个标准的hello程序,它打出“Hello, world!”的文字,该源程序命名为hello.c。在这个目录下(注意只有源文件hello.c,不需要编译hello.o或者hello),首先执行命令autoscan:
  
  $autoscan
  
  这样会生成configure.scan文件,它包含了系统配置的基本选项。作为一个简单的例子,其中很多东西是不需要的,所以可以修改这个文件,让它仅仅包含下面几行:
  
  AC_INIT(hello.c)
  AM_INIT_AUTOMAKE(hello, 0.1)
  AC_PROG_CC
  AC_OUTPUT(Makefile)
  
  然后把这个文件复制为configure.in,作为配置的输入文件。
  
  由于使用了m4宏(AM_INIT… 语句),必须运行aclocal命令生成相应的宏文件:
  
  $aclocal
  
  在当前目录中会产生aclocal.m4文件。
  
  然后执行autoconf,以生成configure执行脚本:
  
  $autoconf
  
  这样关于配置的部分就完成了,下面是和编译生成有关的。
  
  我们需要手工编辑一个文本文件——Makefile.am,内容如下:
  
  AUTOMAKE_OPTIONS=foreign
  bin_PROGRAMS=hello
  hello_SOURCES=hello.c
  
  这个文件应该很好理解,foreign告诉系统这是一个普通的应用软件,该程序名称为hello,而hello程序包含的源程序(SOURCES)只有hello.c这个文件。接着执行:
  
  $automake –add-missing
  
  automake会自动生成所有必须的文件,包括Makefile.in等重要文件。
  
  最后进行压缩、打包,整个工作就完成了。
  
  获得这个压缩包的用户只需要进行前面提到的三个安装步骤,就可以顺利地得到hello应用程序了。
  
  RPM二进制方式
  
  正如前面介绍的,使用源代码方式发布软件无论是对作者还是用户都比较麻烦。于是,Red Hat公司开发出一种直接安装编译好的二进制文件方式,并可根据不同的平台发布不同的版本。用户只需要一个命令,就可以完成所有要安装的步骤,十分适合普通用户使用。那么,如何把自己的软件制作成RPM包呢?
  
  下面以Red Hat Linux为例,在默认情况下,和RPM包相关的目录是/usr/src/redhat/下的SOURCES、SPECS和RPMS。其中SOURCES目录存放需要制作的源代码文件,一般是tgz格式压缩;SPECS目录存放编写的spec文件,这些文件指示RPM制作工具如何进行打包工作;而RPMS下有i386、i586、noarch等子目录,分别对应不同的体系结构,如Intel 80386、586处理器等,noarch则是通用的,制作完成的RPM包就存放在这些目录中。
  
  仍然以前面的hello为例,直接将hello.c压缩成hello.tgz格式:
  
  $tar cfvz hello.tgz hello.c
  
  然后把hello.tgz拷贝到/usr/src/redhat/SOURCES下,并在/usr/src/redhat/SPECS/下编写一个简单的hello.spec文件,内容如下:
  
  Name: hello program
  Summary: My first linux software
  Version: 0.1
  Release: 1
  Copyright: OpenSource
  Group: Extensions/Chinese
  Source: hello.tgz
  Packager: NetSnake
  %description
  This is a example software, just for see README for detail,
  NetSnake, some day.
  %changelog
  *Fri Dec 27 2002 NetSnake
  -build for the first time.
  %prep
  %setup
  %build
  make hello
  %install
  install -m 755 hello /usr/local/bin/hello
  %files
  %doc README
  /usr/local/bin/hello
  
  这个spec文件是整个制作过程的关键,它控制着整个软件包的制作流程,因此我们需要仔细分析一下。
  
  前面的Name、Summary等都是关于软件性质、版本等的说明,可以看作是一个概述和总揽,其中Version和Release将会影响到生成软件包的名称。例如这里版本是0.1,发布是1,那么做出来的RPM包就是hello-0.1-1.i386.rpm。而Group指的是在X-Window下生成快捷方式的位置,Chinese就是在“中文”下生成子目录。然后就进入了具体的制作流程,所有以“%”开头的宏语句都表示制作流程中的一步。
  
  由此不难看出,制作过程大概需要这样几步:
  
  ◆ %description是对整个软件的注释,比如写一些粗略的功能说明,可以分成若干行;
  
  ◆ %prep和%setup可以认为是预处理阶段,对于小软件来说没什么实质性用途;
  
  ◆ 接下来就是%build阶段,这时候会将所有打包文件解开,并根据实际情况将源文件编译为二进制文件(make hello);
  
  ◆ Build完成之后是%install,这个步骤通过%config、%file、%doc等宏将编译好的软件、文档、配置文件等安装到指定的位置;
  
  ◆ 最后是所有被安装到系统中的文件列表。
  
  这就是整个RPM包安装过程。它与Makefile比较起来要简单得很多,因为它将所有操作集中到一个文件中,非常有利于整理和纠错。
  
  接下来就需要执行,以生成自己的RPM软件包:
  
  $rpm -ba hello.spec
  
  需要注意的是,在新版本的Red Hat 8.0 下,制作RPM包的命令已经完全从rpm命令中分离出来,成为了一个单独的rpmbuild,所以应该是rpmbuild -ba hello.spec。
  
  如果不用-target=[i486][i586]…指定体系结构,默认会是i386,这样,会在/usr/src/redhat/RPMS/i386/下生成hello-xx-xxx.i386.rpm文件。
  
  总的来说,源代码方式的缺点是用户安装比较麻烦,而且容易出现各种错误;优点是可控制性强、灵活。RPM方式刚好相反,用户安装简单,易于使用,但是基本不能按照自己的意思对软件进行配置。这两种发布方法各有千秋,具体选择哪种发布方式可以根据自己的需要确定。

tcpreplay 工具详解【中文】

工具的名称就能猜到工具的作用,就是重放TCP的报文,但是这个工具究竟功能如何,是不是仅仅局限于在一个网卡上回放报文,这篇说明书主要介绍tcprelay的一些与测试有关的使用,在介绍tcpreplay命令的使用之前,先要介绍与之密切相关的一个命令:tcpprep,中文直译就是tcp准备的意思,它的作用可以参见官方网站的介绍说明:

tcpprep is the pcap pre-processor for tcpreplay and tcprewrite. The purpose of tcpprep is to create a cache file which is used to "split" traffic into two sides (often called primary/secondary or client/server). If you are intending to use tcpreplay with two NIC’s, then tcpprep is what decides which interface each packet will use. By using a seperate process to generate cache files, tcpreplay can send packets at a much higher rate then if it had to do the calculations to split traffic itself.

个人翻译:(建议大家看man文件,阅读3次就能够比较好的理解了)

 

P:<list> – Must be one of the listed packets where the list corresponds to the packet number in the capture file.

Ex: -xP:1-5,9,15 would only send packets 1 through 5, 9 and 15.

根据参数后的参数值(报文编号)发送指定的报文。可以在ethereal中确认报文的编号,然后把需要的报文发送。可以用于排除ARP报文。

F:"<filter>" – BPF filter. See the tcpdump(8) man page for syntax.

未知,以后补充。

-X <match> Send all the packets except those specified

可选参数,就是-x参数的取反,参数内容也是一样。

-v Verbose

可选参数,显示trpprep生成cache文件的处理过程,就是一些信息的即时打印。

-V Version

显示版本号。
Tcpprep使用小结

再构造cache文件的过程中我用的比较多的选项参数就-v、-P、-xB、-xP,一般都是client和server的模式,其它两种模式没有实验过,暂时还不知道怎么使用,bridge模式我使用过一次,结果发现报文是从一个网卡送出。

对于tcp和udp协议都做了测试,是可以支持的,icmp还没有成功。对于网络上的BT报文,只要你有pcap文件,也是可以构造cache文件来模拟完全真实的BT流量。

目前的使用就是这么多,感觉还是很有用的,tcpreplay的参数有一部分是和tcpprep重复,下面的帮助文件说明就不详细说明了,但是特殊有好用的参数会使用蓝色字体标记出来给予重视。存在的不足是还没有学会在nat模式下重放报文,现在所有的报文重放都是在透明模式下完成的。
Tcpreplay帮助文件说明

Usage: tcpreplay [args] <file(s)>

-A "<args>" Pass arguments to tcpdump decoder (use w/ -v)

可选参数,在使用tcpdump风格打印输出信息时,同时再调用tcpdump中的参数,默认已经带有“-n,-l”,所以一般看到的都是ip地址,而没有主机名的打印,注意这个是在tcpreplay使用了-v参数时,才能使用,不带-v不会报错,但是没有实际意义。格式:-vA “nnt”表示以tcpdump风格输出报文信息,并且不打印时间戳、主机名、端口服务名称。注意不要使用-c参数来指定打印的数据报文的个数,这样发送出去的报文也会变少。

-b Bridge two broadcast domains in sniffer mode

可选参数,没有用过

-c <cachefile> Split traffic via cache file

双网卡回放报文必选参数,后面紧跟cache文件名,该文件为tcpprep根据对应的pcap文件构造出来。

-C <CIDR1,CIDR2,…> Split traffic by matching src IP

可选参数,

-D Data dump mode (set this BEFORE -w and -W)

可选参数,把应用层的数据,使用dump mode写入到指定文件中去,和-w、-W参数一起使用。

-e <ip1:ip2> Specify IP endpoint rewriting

可选参数,指定端点的ip,即把发送报文的和接收的报文的ip都修改称对应的参数值中指定的ip,但是这样发送的出的报文不会区分client和server,还没有发现使用的地方。

-f <configfile> Specify configuration file

可选参数,指定配置文件,目前不会使用。

-F Fix IP, TCP, UDP and ICMP checksums

可选参数,在发送报文时,自动纠正错误的校验和。对测试DUT的校验和检验还是有用的。

-h Help

显示帮助文件。

-i <nic> Primary interface to send traffic out of

双网卡回放报文必选参数,指定主接口。

-I <mac> Rewrite dest MAC on primary interface

可选参数,重写主网卡发送出报文的目的MAC地址。

-j <nic> Secondary interface to send traffic out of

双网卡回放报文必选参数,指定从接口。

-J <mac> Rewrite dest MAC on secondary interface

可选参数,重写从网卡发送出报文的目的MAC地址。

-k <mac> Rewrite source MAC on primary interface

可选参数,重写主网卡发送报文的源MAC地址。

-K <mac> Rewrite source MAC on secondary interface

可选参数,重写从网卡发送报文的源MAC地址。

-l <loop> Specify number of times to loop

可选参数,指定循环的次数,测试过程发现不是那么好用,有待确认。

-L <limit> Specify the maximum number of packets to send

可选参数,指定最大的发包数量。可以在确认连接的调试时使用。

-m <multiple> Set replay speed to given multiple

可选参数,指定一个倍数值,就是必默认发送速率要快多少倍的速率发送报文。加大发送的速率后,对于DUT可能意味着有更多的并发连接和连接数,特别是对于BT报文的重放,因为连接的超时是固定的,如果速率增大的话,留在session表中的连接数量增大,还可以通过修改连接的超时时间来达到该目的。

-M Disable sending martian IP packets

可选参数,表示不发送“火星”的ip报文,man文件中的定义是0/8、172/8、255/8。

-n Not nosy mode (not promisc in sniff/bridge mode)

可选参数,在使用-S参数,不对混杂模式进行侦听。没有测试过。

-N <CIDR1:CIDR2,…> Rewrite IP’s via pseudo-NAT

可选参数,通过伪造的NAT,重写IP地址。这个参数应该有很重要的应用,目前没有测试使用。

-O One output mode

可选参数,没有测试使用

-p <packetrate> Set replay speed to given rate (packets/sec)

可选参数,指定每秒发送报文的个数,指定该参数,其它速率相关的参数被忽略,最后的打印信息不会有速率和每秒发送报文的统计。

-P Print PID

可选参数,表示在输出信息中打印PID的信息,用于单用户或单帐户模式下暂停和重启程序。

-r <rate> Set replay speed to given rate (Mbps)

可选参数,指定发送的速率。目前-m/-r/-p这3个参数的相互关系还需要确认。

-R Set replay speed to as fast as possible

可选参数,让报文线速发送。

-s <seed> Randomize src/dst IP addresses w/ given seed

可选参数,

-S <snaplen> Sniff interface(s) and set the snaplen length

可选参数,

-t <mtu> Override MTU (defaults to 1500)

可选参数,指定MTU,标准的10/100M网卡的默认值是1500。

-T Truncate packets > MTU so they can be sent

可选参数,截去报文中MTU大于标准值的部分再发送出去,默认是不发送,skip掉。目前还有疑问,为什么会产生MTU大于1500字节的包,在BT报文中,这种包比较常见。

-u pad|trunc Pad/Truncate packets which are larger than the snaplen

可选参数,后面的参数值二选一,snaplen是指保留数据包的长度,这里的trunc参数值和MTU没有任何关系,不要混淆。

-v Verbose: print packet decodes for each packet sent

可选参数,没发送一个报文都以tcpdump的风格打印出对应的信息。

-V Version

查看版本号。

-w <file> Write (primary) packets or data to file

可选参数,将主网卡发送的报文写入一个文件中,参数后紧跟文件名。

-W <file> Write secondary packets or data to file

可选参数,将从网卡发送的报文写入一个文件中,参数后紧跟文件名。

-x <match> Only send the packets specified

可选参数,发送匹配参数值的报文,这里各个参数具体的含义和tcpprep中的一样,

S:<CIDR1>,… – Src IP must match specified CIDR(s)

在CIDR模式下必须匹配源IP,格式:-xS:100.1.1.0/24,10.10.10.0/26。多个用逗号隔开,参数个数没有试过,3个没有问题。

D:<CIDR1>,… – Dst IP must match specified CIDR(s)

在CIDR模式下必须匹配目的IP,格式同上。

B:<CIDR1>,… – Both src and dst addresses must match

必须同时匹配源和目的IP,格式同上。

E:<CIDR1>,… – Either src or dst address must match

匹配源或目的IP,格式同上。

P:<list> – Must be one of the listed packets where the list corresponds to the packet number in the capture file.

Ex: -xP:1-5,9,15 would only send packets 1 through 5, 9 and 15.

根据参数后的参数值(报文编号)发送指定的报文。可以在ethereal中确认报文的编号,然后把需要的报文发送。可以用于排除ARP报文。

F:"<filter>" – BPF filter. See the tcpdump(8) man page for syntax.

未知,以后补充。

-X <match> Send all the packets except those specified

可选参数,-x的参数内容取反。参数内容一样。

-1 Send one packet per key press

可选参数,参数内容就是阿拉伯数字1,这个参数对于确定连接的建立,相当好用,根据按回车键发送报文,可以将报文一个一个发送,来判断连接的状态。也可以用于故障定位。

-2 <datafile> Layer 2 data

可选参数,在2层加入数据。

-4 <PORT1:PORT2,…> Rewrite port numbers

可选参数,重写端口号,对于测试特殊端口的应用比较实用。

<file1> <file2> … File list to replay

可选参数,没有实验过。
配置实例

1、 重放在客户端ftp连接的报文

a、 在客户端使用ethereal抓包,存为ftp.pcap文件

b、 将ftp.pcap文件进行tcpprep操作,制作cache文件。

[root@A ~]# tcpprep -an client -i ftp.pcap -o ftp.cache –v

c、 将DUT设备的两个接口和PC的两个接口使用网线连接,使用tcpreplay重放报文。注意防火墙的配置为网桥(透明)模式。

[root@A ~]# tcpreplay -c ftp.cache -i eth0 -j eth1 ftp.pcap -R –v

-R参数表示全速发送,-v显示打印信息。

2、 重放在客户端BT连接的报文

a、 在实验室BT下载一些台湾的娱乐节目和热门的大片,使用ethereal抓包,存为bt.pcap文件。注意pcap文件大小的控制,对pc的内存要求比较高,我保存了一个600多M的pcap文件用了40多分钟,大家有需要可以直接从实验室copy。

b、 将bt.pcap文件进行tcpprep操作,制作cache文件。

[root@A ~]# tcpprep -an client -i bt.pcap -o bt.cache -C "100M BT Packet" –v

制作cache文件,在cache文件中写入“100M BT Packet”的注释。

c、 使用tcpreplay重放报文。

[root@A ~]# tcpreplay -c bt.cache -i eth0 -j eth1 bt.pcap -v –R

3、 重放tftp服务器上抓到的报文

a、 在tftp服务器上使用ethereal抓包,存为tftp.pcap文件。

b、 将pcap文件进行tcpprep的操作,制作cache文件。

[root@A ~]# tcpprep -an server -i tftp.pcap -o tftp.cache –v

注意:我在测试的时候犯了一个错误,使用DUT的tftp升级来做实验,同时穿过DUT重放报文,结果在网卡发送报文的后,DUT的mac地址做了的回应,导致交互过程没有穿过DUT,这个问题比较搞笑,上午弄了半天才发现原因,开始还以为udp的连接不能重放。

c、 使用tcpreplay重放报文。

[root@A ~]# tcpreplay -c tftp.cache -i eth0 -j eth1 tftp.pcap –v
Tcpprep和Tcprepaly的原理

对于原理部分,目前还没有看过代码,王海斌同学打算先看过源码后,再在windows上调试一个tcpreplay的程序供测试使用。具体的实现原理日后补充。

 

tcpprep是一个在tcpreplaytcprewrite3.0.beta11版本才有,这里不讨论)之前使用的pcap文件的处理程序。使用tcpprep的目的就是建立一个cache文件,用于分离通信流量中的两方(通常叫做 主要的/次要的 或者 客户端/服务器)。如果你正打算在两块网卡上使用tcpreplay的话,那么tcpprep就是用来决定每一个报文(packet)从哪一个接口发出。通过使用这样一个分离的程序来建立一个cache文件,tcpreplay就可以根据这个cache文件通过自身的计算来分离流量,高速率的发送报文。

目前王海斌看过代码后,对cache文件的作用解释,主要是加速报文的发送,cache文件中存放着pcap文件中每个帧的编号和时间戳等信息,以达到tcpreplay回放时可以更加快速的发送报文的目的。

其实我们要使用tcpreplay的功能的话,肯定就是它的重放功能,而重放的话肯定是一个客户端和服务器的交互过程,例如ftptftpsqlnetrtspmms等应用层协议的交互过程,我们只要有正确和足够的pcap文件,只需要制作cache文件,使用tcpreplay的命令,就不需要每次都搭建一个真实的测试环境来测试DUT对该协议的支持程度。所以在介绍tcpreplay之前先介绍tcpprep这个命令的使用。tcprewrite提供的功能暂时不做研究。

Tcpprep帮助文件说明

    由于时间问题,这次不能对man文件一一做解释,这个说明文档主要是对-h打印出来的命令参数作一个说明,结合几个实际的例子来说明tcpprep的使用。强烈建议大家去官方网站去阅读他们提供的文档,http://tcpreplay.synfin.net/trac/我这里有打印的内容,有兴趣的可以拿去看一下。

    Usage: tcpprep [-a -n <mode> -N <type> | -c <cidr> | -p | -r <regex>]

                -o <out> -i <in> <args>

 

                 -a <st1:city w:st="on"><st1:place w:st="on">Split</st1:place></st1:city> traffic in Auto Mode<o:p></o:p>

一般情况下都需要该参数,表示按模式自动分离的通讯流量生成cache文件,这个参数一半都和-n参数一起使用,表示自动分离采取的拓扑模式,来决定采取那种模式分离通讯流量的双方。

-c CIDR1,CIDR2,…      Split traffic in CIDR Mode

可选参数,表示分离流量时采用CIDR(无类别域间路由选择)模式。格式:tcpprep  -ac <st1:chsdate w:st="on" isrocdate="False" islunardate="False" day="30" month="12" year="1899">10.10.0</st1:chsdate>.0/24,表示把源地址匹配10.10.0.0/24网段的报文全部由主网卡发送,剩下的报文由从网卡发送出来,这里还有一点需要补充,就是tcpreplay在重放报文时对两个网卡的定义很明确,一个主网卡(primary interface),一个是从网卡(secondary interface),不同的模式,两块网卡的属性不一样。该参数不能和-r,-a一起使用。<o:p></o:p>

-C <comment>            Embed comment in tcpprep cache file

可选参数,表示在cache文件中嵌入注释内容,可以用于注释说明cache文件的内容,注意使用时参数位置,不要放在最后,我测试时放在-o参数值的后面就报错,放到-i参数之前就可以。生成cache文件后使用-P可以查看写入的内容。

-h                      Help

显示帮助文件。

-i <capfile>            Input capture file to process

生成cache文件的必带参数,后面紧跟pcap文件名,表示这个pcap文件需要处理。

-m <minmask>            Minimum mask length in Auto/Router mode

可选参数,在选用router模式时使用,表示最小掩码,默认是302个有效ip地址)。

-M <maxmask>            Maximum mask length in Auto/Router mode

可选参数,在选用router模式时使用,表示最大掩码,默认是81600万个ip地址)。

-n <auto mode>          Use specified algorithm in Auto Mode

生成cache文件的必带参数,后面紧跟模式名称,可选项有(bridge|router|client|server),目前<st1:chsdate w:st="on" isrocdate="False" islunardate="False" day="30" month="12" year="1899">2.3.5</st1:chsdate>版本只支持这4种模式。模式的选择很关键,例如在客户端使用ftp软件下载文件,那么你在客户端抓到的报文生成的pcap文件,那么就选用client模式,在服务器端抓到的报文生成的pcap文件就选用server模式。只有模式选对了,才能正确的分离流量从正确的接口发出正确的报文。注意:Server端的报文由主网卡发送出去,Client端的报文由从网卡发送出去。怎么确定主从网卡由tcpreplay的命令(-i –j两个参数)来决定。

-N client|server        Classify non-IP traffic as client/server

可选参数,表示非IP的流量(例如ARP报文)从哪个接口送出,因为很多的tcpprcp支持的模式中,都依赖于IP头部中的IP地址信息来决定报文是从client端还是从server端发送出去。但是并不是所有的报文都是IPv4结构的,所以这种情况下,tcpprep不能确定这些非IPv4类型的报文应该从哪个接口发送出去,所以,默认的配置就是从client的接口发送出去。如果你硬要正确的分离出非IPv4报文的话,可以使用MAC address模式(–mac)。3.0版本才支持。

-o <outputfile>         Output cache file name

生成cache文件的必带参数,后面紧跟cache文件名,表示这个输出的cache文件以这个名字命名。

-p                     <st1:place w:st="on"><st1:city w:st="on">Split</st1:city></st1:place> traffic based on destination port

    可选参数,基于目的端口来分离通讯流量,它区分的依据是认为0-1023端口都是服务器的端发出的报文,其它的端口都是客户端发出的报文,具体的端口对应的/etc/services文件里的的内容。使用的格式:-p /etc/services,可以根据自己的需要来制作一个文件也可以。

-P <file>               Print comment in tcpprep file

    可选参数,查看cache文件的内容。

-r <regex>             <st1:place w:st="on"><st1:city w:st="on">Split</st1:city></st1:place> traffic in Regex Mode

    可选参数,表示使用Regex模式分离通讯流量,有点类似于CIDR模式,但是它匹配的是服务器的源IPman文件提示不能和-a-c参数一起使用,但是我使用了也没有报错,格式:-r "(192)"-r "(192|172)\…..*",具体应用还有待实验。

-R <ratio>              Specify a ratio to use in Auto Mode

    可选参数,一个比例值,这个比例值的意义是服务器端发起的连接数和客户端发起的连接数的比例,这个值大于2的话就视为server端。这个英文原意我也不是太肯定,大家可以参考一下原文:

The ratio of server connections to client connections  necessary to  be classified as a server in auto mode.  A system is classified as a server if [# server connections] >= ([# client connections] * [ratio]).  Default is: 2.0

-s <file>               Specify service ports in /etc/services format

    可选参数,在man文件中没有对该参数的解释,估计就是按/etc/services文件里的格式来定义服务的端口,没有太多的研究意义。

-x <match>              Only send the packets specified

    重要的可选参数,表示按照参数定义的需求来定义发送报文。后面还有具体的参数,因为在我们的抓包过程中,可能会由于网络环境原因,抓到了许多我们不需要回放的报文,我们就可以根据这个参数决定我们需要回放哪些报文内容。具体的参数意思如下:

    S:<CIDR1>,… – Src IP must match specified CIDR(s)

    CIDR模式下必须匹配源IP,格式-xS:100.1.1.0/24,<st1:chsdate w:st="on" year="1899" month="12" day="30" islunardate="False" isrocdate="False">10.10.10</st1:chsdate>.0/26多个用逗号隔开,参数个数没有试过,3个没有问题。

D:<CIDR1>,… – Dst IP must match specified CIDR(s)

CIDR模式下必须匹配目的IP,格式同上。

B:<CIDR1>,… – Both src and dst addresses must match

必须同时匹配源和目的IP,格式同上。

E:<CIDR1>,… – Either src or dst address must match

匹配源或目的IP,格式同上。

sendip 命令详解【中文】

在从事网络产品尤其是网络安全产品开发时,我们一直面临着一个问题,就是对产品的 UDP报文的构造
先看man文件中显示支持可以构造的UDP报文字段有哪些,然后在参数后直接说明该字段的含义。构造报文首先要求对报文的各个字段非常熟悉,所以先看一下UDP首部的图表:

UDP首部:
0 15 16 31
    

        

            

            

        

        

            

            

        

        

            

        

    

            

16位源端口号

            

            

16位目的端口号

            

            

16位UDP长度

            

            

16位UDP检验和

            

            

数据(若有)

            

sendip_表3
Arguments for module ./udp.so:
-us x UDP source port
构造UDP报文的源端口,默认为0。
-ud x UDP destination port
构造UDP报文的目的端口,默认为0。
-ul x UDP packet length
构造UDP报文的报文长度,这个值可以任意输入,测试在接收端抓包的结果显示是参数值,但是ethereal会自动分析出实际的报文长度。默认是正确的长度,8个字节。
-uc x UDP checksum
构造checksum的值,覆盖了首部和数据字段。可以用于测试DUT设备是不是检验UDP报文的checksum值。这里有点需要注意,在测试的过程中,发现如果length字段不正确,网卡在收到报文后不会检查checksum,如果length是正确的,checksum才会被认出来不正确,从ethereal的抓包来看是这样的。默认是正确的checksum。
实例:
[root@FC5 ~]# sendip -v -p ipv4 -is 192.168.96.7 -id 192.168.96.1 -p udp -us 8000 -ud 4000 192.168.96.1 –d asdfasdf
发送一个源地址为192.168.96.7,源端口为8000的udp包,到目的为192.168.96.1,目的端口为4000设备上,数据包的内容是asdfasdf,如果要直接引用一个文件的内容的话可以使用-f参数,后面写文件的路径即可。

<h2>ICMP报文的构造</h2>

先看man文件中显示支持可以构造的ICMP报文字段有哪些,然后在参数后直接说明该字段的含义。构造报文首先要求对报文的各个字段非常熟悉,所以先看一下UDP首部的图表:
ICMP结构:
0 15 16 31
    

        

            

            

            

        

        

            

        

    

            

8位类型

            

            

8位代码

            

            

16位检验和

            

            

其它一些细节信息内容

            

sendip_表4
Arguments for module ./icmp.so:
-ct x ICMP message type
构造ICMP报文类型,一个字节。内容比较多,最常见的类型如下:
0 表示Echo Reply
3 表示Eestination Unreachable
这个又分很多类型,这里不作分析,具体可以参见资料。
4 Source Quench
5 Redirect
8 Echo
10 Router Selection
11 Time Exceeded
13 Timestamp
-cd x ICMP code
构造代码字段,取值范围0-255,超过255后变为0,默认配置为0。
-cc x ICMP checksum
构造checksum字段,2个字节。默认是正确内容。
[root@FC5 ~]# sendip -v -p ipv4 -is 192.168.96.253 192.168.96.202 -p icmp -ct 3
发送一个源地址为192.168.96.253的类行为3的icmp报文给192.168.96.202这个地址。

小结:

这篇文档主要是介绍sendip的报文构造方式,而sendip的缺陷就在于它不能连续的发送报文,所以这里提供一个简单的perl脚本,来循环的发送数据包,虽说不能形成flood的效果,但是对于测试可以达到数量控制的目的,有助于自动化脚本的测试,提高测试的效率。
#!/usr/bin/perl -w
$i=1;
while ($i<2)
{
for($j=0;$j<=65;++$j)
{
system "sendip -v -d r64 -p ipv4 -iv 4 -ih 5 -il 20 -ifm 1 -if 0 -iy 8 -is 13.1.1.2 -id 192.168.98.173 -p udp -us $j -ud $j -ul 56 192.168.98.173";
system "sendip -v -d r64 -p ipv4 -iv 4 -ih 5 -il 20 -ifm 0 -if 0x3 -iy 8 -is 13.1.1.2 -id 192.168.98.173 -p udp -us $j -ud $j -ul 56 192.168.98.173";
system "sendip -v -d r64 -p ipv4 -iv 4 -ih 5 -il 65535 -ifm 1 -if 10 -iy 4 -is 13.1.1.2 -id 192.168.98.173 -p tcp -ts $j -td $j -tt 8 192.168.98.173";
}
++$i
}
//i代表循环的次数,j代表端口,本来是65535,我修改了一下,可以根据需要来调整次数和//端口范围,这个脚本感谢吴梦洁的提供,我只是做了注释和修改。

TCP/IP 协议栈进行稳定性或安全性测试,确保开发产品在遇到各种不规则的错误的IP 包时仍可正常稳定高效地工作,我们知道,在正常的网络环境中,很难产生错误的IP 包,也很难产生我们想要的错误的IP 包,为此,要完成对产品的测试,我们必须自己来制造各种各样错误的IP 包,本篇的目的就是介绍如何利用各种发包工具来制造自己想要的错误的IP 包。SENDIP 是一个LINUX 下的命令行工具,可以通过命令行参数的方式发送各种格式的IP 包,它有大量的命令行参数来规定各种协议的头格式,目前可支持NTP, BGP, RIP, RIPng,TCP, UDP, ICMP 或raw IPv4 和IPv6 包格式,并且可以随意在包中添加数据。

<h2>帮助文件说明</h2>

Usage: sendip [-v] [-d data] [-h] [-f datafile] [-p module] [module options] hostname
-d data add this data as a string to the end of the packet
Data can be:
rN to generate N random(ish) data bytes;
0x or 0X followed by hex digits;
0 followed by octal digits;
any other stream of bytes
-f datafile read packet data from file
-h print this message
-p module load the specified module (see below)
-v be verbose
参数含义:
-v: 详细模式,即打印出你发送报文的内容,类似于debug模式,建议配置该参数,可以清楚的看到发送的报文内容是否正确。
-d: 添加data字段的内容,有option字段的话放在options字段之后,任意添加。也可以一次用文件导入,不过参数是下面的-f。
-h: 显示上面的帮助文件。
-f: 在data字段添加参数后所指的文件里的内容,参数后跟的内容就是一个文件名。
-p: 指定发送报文的类型,选项就是帮助提示中的ipv4 ipv6 icmp tcp udp bgp rip ntp的8种类型,注意各个协议之间的搭配使用,例如ntp是用udp传输,而rip是用tcp传输。这个参数可以复用来更加精确的确定一个报文的类型和各个字段,例如:-p ipv4 –p tcp –p rip是可以一起用的。该参数必须配置。
hostname: 直接输入ip地址即可,也可以是主机名,但是之前要把主机名和对应的ip写入到/etc/hosts的文件中。该参数必须配置。注意不需要输入hostname这个字段,要不是ip,要不是主机名。
配置完以上参数后就可以发送报文了,但是具体报文的各个字段都是default配置,并没有达到自己要构造报文的目的。下面以ipv4、udp、tcp、icmp为例根据man文件的内容来说明各个字段的构造方法,ipv6、rip、bgp和ntp希望后面有时间再补充。

ipv4报文的构造

先看man文件中显示支持可以构造的IPV4报文字段有哪些,然后在参数后直接说明该字段的含义。构造报文首先要求对报文的各个字段非常熟悉,所以先看一下IP首部的图表:
IP首部:
0 15 16 31
    

        

            

            

            

            

        

        

            

            

            

        

        

            

            

            

        

        

            

        

        

            

        

        

            

        

        

            

        

    

            

4位版 本

            

            

首部长 度

            

            

8位

            

服务类型(TOS)

            

            

16位

            

总长度(字节)

            

            

16位

            

标识

            

            

3位标志

            

            

13位

            

片偏移

            

            

8位

            

生存时间TTL

            

            

8位

            

协议

            

            

16位

            

首部检验和

            

            

32位

            

源IP地址

            

            

32位

            

目的IP地址

            

            

32位

            

选项(若有)

            

            

数据

            

            

sendip_表1
上面是一个简单的图示,具体各个字段可以参见高文宇的《IP协议》文档。
Arguments for module ./ipv4.so:
-is x Source IP address (see README)
构造源IP地址,任意构造。判断不是很严格,可以输入错误,它会自动补充或用255.255.255.255来代替,例如输入1.1.则用255.255.255.255来代替;如果输入1.1则会自动补齐中间的两位,显示为1.0.0.1;如果输入1.1.1则会自动填充为1.1.0.1。目的IP地址也是一样。源IP默认为127.0.0.1。
-id x Desitnation IP address
构造目的IP地址,这里其实可以不用写,因为hostname为一个必带的参数字段,最后的目的地址是匹配hostname参数后的内容。注意,这里的ip和hostname的内容要求一样,不然sendip发出了报文(它发出的报文目的地址是-id参数后的地址),但是id和hostname所带参数内容所指的主机的网卡并收不到报文。默认以-id后的参数为准。
-ih x IP header length (see README)
构造header(首部)长度,这里所指的是32-bit的word的个数,就是以4个字节为单位元,你定义的结果要乘以4,要求最小为5(5×4=20bytes),最大为15(15×4=60bytes)。如果构造首部不是20bytes的报文,网卡收到的时候ethereal只解析到mac地址,它不认为是一个完整的IP报文。默认是20字节。
-iv x IP version (you almost definately don’t want to change this)
构造IP版本,这个可以任意,0到15任意选择,超过15发出的报文IP version为0。默认为4。
-iy x IP type of service
构造服务类型,这里先说明一下Type of service(PreDTRCx)的各个标志位的意义:
Precedence(000-111)
D(1 = minimize delay)
T(1 = maximize throughout)
R(1 = maximize reliability)
C(1 = minimize cost)
x(reservd and set to 0)
服务类型的前3位设置分组的优先级,数值越大,则分组越重要。接下来的3位分别表示延迟、吞吐率和可靠性,如果为0则表示常规服务,如果为1则表示短延迟、高吞吐率和高可靠性。最后两位没有使用。sendip并不能细致到定义每一个bit位的数值,默认是全0。
-il x Total IP packet length (see README)
构造IP报文的总长度,这里的总长度是包括数据字段的,就是说如果没有数据字段,这里的值应该和首部长度字段的值是一样的。最大值为65535(二进制16个1),但是注意配置这个值的意义不大,用ethereal抓到这个报文时显示的值还是一个正确的值,这个报文本来有多大就是多大。默认是根据报文内容来确定,是一个正确的值。
-ii x IP packet ID (see README)
构造IP报文的标识号,这个时随机的,没有太多意义,不知道是不是会在校验的时候用到。默认是随机构造。在IP协议中的作用是标识报文,例如一个分片后的IP报文,它的ID肯定是一样的。取值的范围是1-65535,不在这个范围的话,程序会随机构造一个id号。
-ifr x IP reservced flag (see README)
保留的标志位。默认为0,选项为0、1、r。
-ifd x IP don’t fragment flag (see README)
构造强制不分片标志位,默认为0,选项为0、1、r。
-ifm x IP more fragments flag (see README)
构造分片标志位,这个标志位只有在报文需要分片时才置为1,默认为0,选项为0、1、r。
-if x IP fragment offset
构造需要分片的报文的位偏移,默认发送的报文没有分片的话就是0。
-it x IP time to live
生存时间值,修改的意义不大,默认配置为255。
-ip x IP protocol
协议字段,判断哪个协议使用了IP封装来传输,例如ICMP为0x01,TCP为0x06,UDP为0x11。
-ic x IP checksum (see README)
构造首部校验和字段,只覆盖首部,不包括数据字段。默认是正确的校验和,看不出什么规律来,应该是有一种算法。测试时可以随意构造一个错误的checksum,看DUT是不是检测checksum这个字段。但是验证的过程中发现配置后没有作用,并没有修改。测试了icmp的包倒是修改了,不知道是不是软件的bug。
注意:以下内容都是选项字段,之前没有了解过的话,可能会觉得有些陌生,为了更好的了解这些字段的意思,可以先用ping这个简单的命令来进行一些实践操作,理解其中的一些字段的含义。
实例
1、返回一个时戳,表示到达目的地址的时间,在reply的回应包中可以看到。
C:\>ping -s 1 192.168.100.18
Pinging 192.168.100.18 with 32 bytes of data:
Reply from 192.168.100.18: bytes=32 time<1ms TTL=63
Timestamp: 192.168.100.18 : 9612956
2、记录路由,表示在ping包到达目的地址时经过的路由设备,需要设备的支持。
C:\>ping -r 1 192.168.100.18 -n 1
Pinging 192.168.100.18 with 32 bytes of data:
Reply from 192.168.100.18: bytes=32 time<1ms TTL=63
Route: 192.168.100.18
Ping statistics for 192.168.100.18:
-r表示记录路由的跳数,注意这个参数值只能是1-9,原因是因为记录路由这个选项需要3个字节的开销,后面每跟一个ip地址需要4个字节,而选项字段的最大值为40个字节。这个参数的作用被之后的tracert命令代替。
-n 表示发多少个ping包。
3、严格源路由和记录路由,表示不但要记录路由,还要求到达目的地址必须要经过指定的路由地址。
C:\>ping -k 192.168.96.2 192.168.98.1 192.168.100.18
表示到达192.168.100.18时,先必须经过192.168.96.2和192.168.98.1这两个路由设备,再到达目的ip。
现在逐一来看各个参数的含义:
-ionum x
根据《TCP/IP详解》卷2第9章,并没有这个选项字段,这里应该是软件自己为了控制选项字段的长度而设计的。这里先说明一些选项字段的基础知识:
选项字段必须是4字节的整数倍,原因很简单,因为IP header length是以4字节为一个单位元;
IP选项字段可能包含0个或多个单独选项,选项有两种类型,单字节和多字节,如下图:
sendip_图1(这里贴不上来,想办法中)
所有选项1都以字节类型(type)字段开始。在多字段选项中,类型字段后面紧接着一个长度(len)字段,其它的字节是数据(data)。许多选项数据字段的第一个字节是1字节的位移(offset)字段,指向数据字段内的某个字节。长度(len)字节的计算覆盖了类型、长度、和数据字段。类型(type)被继续分成了3个子字段:1bit备份(copied)、2bit类(class)字段和5bit数字(number)字段。
现在来看各个选贤字段的定义和使用方法。默认这个参数后的长度值总是正确的,默认没有选项字段。
-ioeol IP option: end of list
1字节,表示选项表的结尾,就是一个选项字段的结束标识符。
-ionop IP option: no-op
1字节,没有任何意义,表示无操作,碰到这个字段可以忽略。
-iorr x
长度可变,作用是记录路由。格式是pointer:addr1:addr2,这里的pointer其实就是一个具体的offset值,是一个十六进制的值,我测试最小值是十进制的10(这里只能用十进制表示,10刚好对应的是0x16)。使用可以参照这个命令行:
[root@FC5 ~]# sendip -v -p ipv4 -is 192.168.96.111 -id 192.168.96.202 -iorr 10:192.168.96.1 192.168.96.202 -d asf
这里要说明一点为什么要加一个asf的3个字节的数据字段,因为在测试的时候,我在被发送报文的pc端抓包发现如果ethereal分析显示total length这个值不对的话,它就不会分析其它字段,这样会导致不能清楚看到option字段,不知道是不是正确构造了报文,所以在构造报文时还需要注意这个小窍门,ethereal分析后还少几个字节就加几个字符。这样你就可以看到你刚才发送的option字段里的内容了。
-iots x
长度可变,作用是时戳。格式是pointer:overflow:flag:(ip1:)ts1:(ip2:)ts2,pointer表示位偏移,overflow表示??,flag是标识位(0表示记录时间戳、1表示记录地址和时间戳、3表示只在预先指定的系统记录时间戳,其它保留)。注意只有flag位置1时才有ip1、ip2的参数。
[root@FC5 ~]# sendip -v -p ipv4 -is 192.168.96.222 -iots 11:4:1:192.168.96.1:11:
192.168.9.8:90 192.168.96.202
11是位偏移,4表示??,1表示记录地址和时间戳,后面就是一个ip对应一个时间戳。
构造这样的报文主要可以用于测试DUT是不是检查option字段,如果检查,是不是检查时间戳等信息。
-iolsr x
长度可变,表示宽松源路由和记录路由(LSRR)。格式很简单了,上面ping的实例如果运行后抓包看过以后,就发现这个是按照标准的格式来定义的。
[root@FC5 ~]# sendip -v -p ipv4 -is 192.168.96.253 -iolsr 10:192.168.96.1 192.168.96.202 -d 1
-iosid x
4个字节,构造identifier(标识符),取值范围0-65535,超过该范围自动变为0。我测试的结果显示前2个字节总是0x8804,后面2个字节就是输入的参数值。
-iossr x
长度可变,表示严格源路由和记录路由(SSRR),格式同-iolsr。

<h2>TCP报文的构造</h2>

先看man文件中显示支持可以构造的TCP报文字段有哪些,然后在参数后直接说明该字段的含义。构造报文首先要求对报文的各个字段非常熟悉,所以先看一下TCP首部的图表:
TCP首部:
0 15 16 31
    

        

            

            

        

        

            

        

        

            

        

        

            

            

            

            

            

            

            

            

            

        

        

            

            

        

        

            

        

        

            

        

        

            

            

            

            

            

            

            

            

            

        

    

            

16位源端口号

            

            

16位目的端口号

            

            

32位序列号

            

            

32位确认号

            

            

4位

            

首部

            

长度

            

            

6位

            

保留

            

            

U

            

R

            

G

            

            

ACK

            

            

P

            

S

            

H

            

            

RST

            

            

SYN

            

            

FIN

            

            

16位窗口大小

            

            

16位TCP检验和

            

            

16位紧急指针

            

            

选项(若有)

            

            

数据(若有)

            

sendip_表2
Arguments for module ./tcp.so:
-ts x TCP source port
构造TCP的源端口,默认为0。
-td x TCP destination port
构造TCP的目的端口,默认为0。
-tn x TCP sequence number
构造TCP的序列号,默认为随机。
-ta x TCP ack number
构造TCP的应答号,默认为0。
-tt x TCP data offset
构造TCP的首部长度,默认是正确值,标准是20字节,最大60字节。
-tr x TCP header reserved field EXCLUDING ECN and CWR bits
TCP头部保留位。
-tfe x TCP ECN(Explicit Congestion Notification)bit (rfc2481)
TCP标志位中保留的ECN字段,默认为0,选项为0、1或r。
-tfc x TCP CWR(Congestion Window Reduced)bit (rfc2481)
TCP标志位中保留的CWR字段,默认为0,选项为0、1或r。
注意:ECN和CWR
-tfu x TCP URG bit
构造TCP标志位中的URG,表示紧急指针有效。当紧急指针(Urgent Pointer)字段有内容时有效。默认为0,选项为0、1或r。
-tfa x TCP ACK bit
构造TCP标志位中的ACK,表示确认ack number有效。默认为0,选项为0、1或r。
-tfp x TCP PSH bit
构造TCP标志位中的PSH,表示接收方应该尽快将这个报文段交给应用层。默认为0,选项为0、1或r。
-tfr x TCP RST bit
构造TCP标志位中的RST,表示需要重建连接,断开目前的连接。默认为0,选项为0、1或r。
-tfs x TCP SYN bit
构造TCP标志位中的SYN,表示使用同步序号用来发起一个连接。默认为1,选项为0、1或r。
-tff x TCP FIN bit
构造TCP标志位中的FIN,表示完成了发送任务。默认为0,选项为0、1或r。
-tw x TCP window size
构造TCP的期望接收的窗口大小值,默认为65535字节。
-tc x TCP checksum
构造TCP的checksum,检验和覆盖了整个TCP的报文段。默认为正确值。可以用于测试DUT设备是不是检验TCP报文的checksum值。
-tu x TCP urgent pointer
构造紧急指针,所谓紧急指针是一个正的位偏移量,和序号字段中的值相加可以得出紧急数据最后一个字节的序号。默认配置为0。注意这个值只有在-tfu置1时才有效,默认情况下如果有-tu参数,-tfu会自动为1,但是强制把-tfu置为1的话会导致-tu的参数无效。
-tonum x
TCP option as string of hex bytes (length is always correct)
选项字段的长度,但是标准字段没有这个选项。默认是没有选项字段的内容。
-toeol TCP option: end of list
选项字段结束的标识符。
-tonop TCP option: no op
没有任何意义,表示无操作,碰到这个字段可以忽略。
-tomss x
表示最长报文大小,每个连接方通常都在通信的第一个报文段中指明这个选项。
-towscale x
TCP option: window scale (rfc1323)
-tosackok
TCP option: allow selective ack (rfc2018)
-tosack x
TCP option: selective ack (rfc2018), format is l_edge1:r_edge1,l_edge2:r_edge2…
-tots x
TCP option: timestamp (rfc1323), format is tsval:tsecr
关于一些不常见的tcp选项字段的含义,以后继续补充。

mysql的“Client does not support authentication protocol requested by server” 问题

从mysql4 到mysql5 一般会遇到这个问题:
Client does not support authentication protocol requested by server; consider upgrading MySQL client

这可以看作是一个客户端的问题,也可以看作是一个服务器端的问题,因为更新客户端可以解决这个问题,修改服务器设置也可以解决这个问题;

1. 在Linux上升级了mysql服务器后,链接mysql服务器就出现了这个问题,以为是多么致命的问题,就升级了客户端,原来用的动态链接库是libmysqlclient.so.10 ,换成libmysqlclient.so.14就可以了

2. 后来发现同样版本的mysql服务器,一个服务器用libmysqlclient.so.10 不能连接,一个用libmysqlclient.so.10 就能连接,感觉不是客户端的问题了,网上查了一下,其实在服务器端简单设置一下就行了,下面是抄人家的,但是我也是验证过了的,我的mysql版本,5.0.14

mysql> SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd');

官方说明:http://dev.mysql.com/doc/refman/5.0/en/old-client.html