??xml version="1.0" encoding="utf-8" standalone="yes"?>人妻精品久久久久中文字幕69 ,久久亚洲日韩精品一区二区三区,久久综合国产乱子伦精品免费http://www.shnenglu.com/jjbird/category/706.html奇奇的空?/description>zh-cnTue, 20 May 2008 08:00:51 GMTTue, 20 May 2008 08:00:51 GMT60|络l典命o?|管必备)http://www.shnenglu.com/jjbird/articles/11652.html奇奇奇奇Thu, 24 Aug 2006 07:47:00 GMThttp://www.shnenglu.com/jjbird/articles/11652.htmlhttp://www.shnenglu.com/jjbird/comments/11652.htmlhttp://www.shnenglu.com/jjbird/articles/11652.html#Feedback0http://www.shnenglu.com/jjbird/comments/commentRss/11652.htmlhttp://www.shnenglu.com/jjbird/services/trackbacks/11652.html阅读全文

奇奇 2006-08-24 15:47 发表评论
]]>
Windows2000可执行文件一?/title><link>http://www.shnenglu.com/jjbird/articles/11651.html</link><dc:creator>奇奇</dc:creator><author>奇奇</author><pubDate>Thu, 24 Aug 2006 07:39:00 GMT</pubDate><guid>http://www.shnenglu.com/jjbird/articles/11651.html</guid><wfw:comment>http://www.shnenglu.com/jjbird/comments/11651.html</wfw:comment><comments>http://www.shnenglu.com/jjbird/articles/11651.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.shnenglu.com/jjbird/comments/commentRss/11651.html</wfw:commentRss><trackback:ping>http://www.shnenglu.com/jjbird/services/trackbacks/11651.html</trackback:ping><description><![CDATA[     摘要: 文g名称 ...  <a href='http://www.shnenglu.com/jjbird/articles/11651.html'>阅读全文</a><img src ="http://www.shnenglu.com/jjbird/aggbug/11651.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.shnenglu.com/jjbird/" target="_blank">奇奇</a> 2006-08-24 15:39 <a href="http://www.shnenglu.com/jjbird/articles/11651.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>安全研究:|络监听技术概?/title><link>http://www.shnenglu.com/jjbird/articles/6246.html</link><dc:creator>奇奇</dc:creator><author>奇奇</author><pubDate>Tue, 25 Apr 2006 07:35:00 GMT</pubDate><guid>http://www.shnenglu.com/jjbird/articles/6246.html</guid><wfw:comment>http://www.shnenglu.com/jjbird/comments/6246.html</wfw:comment><comments>http://www.shnenglu.com/jjbird/articles/6246.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.shnenglu.com/jjbird/comments/commentRss/6246.html</wfw:commentRss><trackback:ping>http://www.shnenglu.com/jjbird/services/trackbacks/6246.html</trackback:ping><description><![CDATA[ |络监听Q在|络安全上一直是一个比较敏感的话题Q作ZU发展比较成熟的技术,监听在协助网l管理员监测|络传输数据Q排除网l故障等斚wh不可替代的作用,因而一直倍受|络理员的青睐。然而,在另一斚w|络监听也给以太|安全带来了极大的隐患,许多的网l入侵往往都伴随着以太|内|络监听行ؓQ从而造成口oqQ敏感数据被截获{等q锁性安全事件? <p>  |络监听在安全领域引起h们普遍注意是?4q开始的Q在那一q?月间Q相l发生了几次大的安全事gQ一个不知名的h在众多的L和骨q网l设备上安装了网l监听YӞ利用它对国骨干互联|和军方|窃取了过100Q?00个有效的用户名和口o。上qC件可能是互联|上最早期的大规模的网l监听事件了Q它使早期网l监听从"C"走向了公开Qƈq速的在大众中普及开来?/p><p>  关于|络监听常常会有一些有意思的问题Q如Q?我现在有q在|上的计机了,我也有了H听的Y件了Q那么我能不能窃听到微Y(或者美国国防部Q新网{等)的密码?</p><p>  又如Q我是公司的局域网理员,我知道hub很不安全Q用hubq种|络l构公司的计算计互qv来,会ɾ|络监听变得非常ҎQ那么我们就换掉hubQ用交换机Q不p解决口oqq种安全问题了么Q?/p><p>  q是两个很有意思的问题Q我们在q里先不做回{,怿读者看完全文后会有自己正确的答案?/p><p>  一些基本概念:</p><p>  首先Q我们知道,一台接在以太网内的计算Zؓ了和其他Lq行通讯Q在g上是需要网卡,在Y件上是需要网卡驱动程序的。而每块网卡在出厂旉?/p><p>  一个唯一的不与世界上M一块网卡重复的g地址Q称为mac地址。同Ӟ当网l中两台L在实现tcp/ip通讯Ӟ|卡q必ȝ定一个唯一的ip地址。下面用一个常见的unix命oifconfig来看一看作者本人的一台正常工作的机器的网卡:</p><p>  [yiming@server/root]# ifconfig -a<br />  hme0: flags=863 mtu 1500<br />  inet 192.168.1.35 netmask ffffffe0<br />  ether 8:0:20:c8:fe:15</p><p>  从这个命令的输出中我们可以看C面讲到的q些概念Q如W二行的192.168.1.35是ip 地址Q第三行?:0:20:c8:fe:15是mac地址。请注意W一行的BROADCASTQMULTICASTQ这是什么意思?一般而言Q网卡有几种接收数据帧的状态,如unicastQbroadcastQmulticastQpromiscuous{,unicast是指|卡在工作时接收目的地址是本机硬件地址的数据。Broadcast是指接收所有类型ؓq播报文的数据。Multicast是指接收特定的组播报文。Promiscuous则是通常说的h模式Q是指对报文中的目的g地址不加M查,全部接收的工作模式。对照这几个概念Q看看上面的命o输出Q我们可以看刎ͼ正常的网卡应该只是接收发往自n的数据报文,q播和组播报文,请大家记住这个概c?/p><p>  对网l用者来_览|页Q收发邮件等都是很^常,很简便的工作Q其实在后台q些工作是依靠tcp/ip协议族实现的Q大家知道有两个主要的网l体p:OSI参考模型和TCP/IP参考模型,OSI模型即ؓ通常说的7层协议,它由下向上分别ؓ物理层、数据链路层、网l层、传输层、会话层、表C层、应用层Q而tcp/ip模型中去掉了会话层和表示层后Q由剩下?层构成了互联|的基础Q在|络的后台默默的工作着?/p><p>  下面我们不妨从tcp/ip模型的角度来看数据包在局域网内发送的q程Q当数据由应用层自上而下的传递时Q在|络层Ş成ip数据报,再向下到达数据链路层Q由数据链\层将ip数据报分割ؓ数据帧,增加以太|包_再向下一层发送。需要注意的是,以太|的包头中包含着本机和目标设备的mac地址Q也卻I链\层的数据帧发送时Q是依靠48bits的以太网地址而非ip地址来确认的Q以太网的网卡设备驱动程序不会关心ip数据报中的目的ip地址Q它所需要的仅仅是mac地址。目标ip的mac地址又是如何获得的呢Q发端主Z向以太网上的每个L发送一份包含目的地的ip地址的以太网数据?UCؓarp数据?Qƈ期望目的L回复Q从而得到目的主机对应的mac地址Qƈ这个mac地址存入自己的一个arp~存内?/p><p>  当局域网内的L都通过HUB{方式连接时Q一般都UCؓ׃n式的q接Q这U共享式的连接有一个很明显的特点:是HUB会将接收到的所有数据向HUB上的每个端口转发Q也是说当LҎmac地址q行数据包发送时Q尽发送端L告知了目标主机的地址Q但qƈ不意味着在一个网l内的其他主机听不到发送端和接收端之间的通讯Q只是在正常状况下其他主Z忽略q些通讯报文而已Q如果这些主Z愿意忽略q些报文Q网卡被讄为promiscuous状态的话,那么Q对于这C机的|络接口而言QQ何在q个局域网内传输的信息都是可以被听到的?/p><p>  例子Q?br />  我们不妨举一个例子来看看Q我们现在有A,B两台LQ通过hub相连在一个以太网内,现在AZ的一个用h要访问B机提供的WWW服务Q那么当AZ的用户在览器中键入B的ip地址Q得到B机提供的web服务Ӟ?层结构的角度上来看都发生了什么呢Q?/p><p>  1Q首先,当A上的用户在浏览器中键入B机的地址Q发出浏览请求后QA机的应用层得到请求,要求讉KIP地址为B的主机,</p><p>  2Q应用层于是请求发送到7层结构中的下一层传输层Q由传输层实现利用tcp对ip建立q接?/p><p>  3Q传输层数据报交到下一层网l层Q由|络层来选\</p><p>  4Q由于AQB两机在一个共享网l中QIP路由选择很简单:IP数据报直接由源主机发送到目的L?/p><p>  5Q由于AQB两机在一个共享网l中Q所以A机必d32bit的IP地址转换?8bit的以太网地址Q请注意q一工作是由arp来完成的?/p><p>  6Q链路层的arp通过工作在物理层的hub向以太网上的每个L发送一份包含目的地的ip地址的以太网数据帧,在这份请求报文中xQ谁是B机IP地址的拥有者,请将你的g地址告诉我?/p><p>  7Q在同一个以太网中的每台机器都会"接收"(h意这一点!)到这个报文,但正常状态下除了B机外其他L应该会忽略这个报文,而B机网卡驱动程序识别出是在L自己的ip地址Q于是回送一个arp应答Q告知自qip地址和mac地址?/p><p>  8QA机的|卡驱动E序接收CB机的数据帧,知道了B机的mac地址Q于是以后的数据利用q个已知的MAC地址作ؓ目的地址q行发送。同在一个局域网内的L虽然也能"?到这个数据Q但是都保持静默Q不会接收这个不属于它的数据帧?/p><p>  上面是一U正常的情况Q如果网卡被讄Zؓh模式(promiscuous)Q那么第8步就会发生变化,q台L会默不作声的听C太网内传输的所有信息,也就是说Q窃听也因此实CQ这会给局域网安全带来极大的安全问题,一台系l一旦被入Rq进入网l监听状态,那么无论是本是局域网内的各种传输数据都会面被窃听的巨大可能性。实现网l监听的工具Q?/p><p>  上面我们看到Q一切的关键在于网卡被讄为؜杂模式的状态,q种工作复杂吗?不幸的是Q这U工作ƈ不复杂,目前有太多的工具可以做到q一炏V?/p><p>  自网l监听这一技术诞生以来,产生了大量的可工作在各种q_上相兌Yg工具Q其中有商用的,也有free的。在google上用sniffer tools作ؓ关键字,可以扑ֈ非常多?/p><p>  作者在q里列D一些作者喜Ƣ的软gQ供有兴的读者参考用?/p><p>  Windowsq_下的Q?/p><p>  Windump <br />  Windump是最l典的unixq_上的tcpdump的windowUL版,和tcpdump几乎完全兼容Q采用命令行方式q行Q对用惯tcpdump的h来讲会非帔R手。目前版本是3.5.2Q可q行在Windows 95/98/ME/Windows NT/2000/XPq_?</p><p>  Iris <br />  Eeye公司的一ƾ付费YӞ有试用期Q完全图形化界面Q可以很方便的定制各U截h制语句,Ҏh据包q行分析Q还原等。对理员来讲很Ҏ上手Q入门和高U管理员都可以从q个工具上得到自己想要得东西。运行在Windows 95/98/ME/Windows NT/2000/XPq_?</p><p>  unixq_下的Q?/p><p>  tcpdump <br />  不多_最l典的工P被大量的*nixpȝ采用Q无需多言?</p><p>  ngrep <br />  和tcpdumpcMQ但与tcpdump最大的不同之处在于Q借助于这个工P理员可以很方便的把截获目标定制在用户名Q口令等感兴的关键字上?</p><p>  snort <br />  目前很红火的免费的idspȝQ除了用作ids以外Q被用来sniffer也非怸错,可以借助工具或是依靠自n能力完全q原被截L数据?</p><p>  Dsniff <br />  作者设计的出发Ҏ用这个东西进行网l渗透测试,包括一套小巧好用的工P主要目标攑֜口oQ用戯问资源等敏感资料上,非常有特Ԍ工具包中的arpspoofQmacof{工具可以o人满意的捕获交换机环境下的主机敏感数据?</p><p>  Ettercap <br />  和dsniff在某些方面有怼之处Q也可以很方便的工作在交换机环境下提C:国内用户讉Kq个站点需要用代理服务器?</p><p>  Sniffit <br />  被广泛用的|络监听软gQ截获重点在用户的输出?|络监听的具体实玎ͼ</p><p>  在系l管理员看来Q网l监听的主要用途是q行数据包分析,通过|络监听软gQ管理员可以观测分析实时l由的数据包Q从而快速的q行|络故障定位?/p><p>  我们可以举个例子Q?server是邮件服务器Q下面带了很多的client用户Q邮件服务器收发邮g工作正常Q但下面的client用户L抱怨发邮g时连接到邮g服务器后要等待很久的旉才能开始发送工作,问题出在哪里呢?</p><p>  在server上用tcpdumpҎ自其中的一个client的数据包q行捕获分析Q看看结果如何?</p><p>  server#tcpdump host client<br />  tcpdump: listening on hme0<br />  19:04:30.040578 client.1065 > server.smtp: S 1087965815:1087965815(0) <br />  win 64240 (DF)<br />  19:04:30.040613 server.smtp > client.1065: S 99285900:99285900(0) <br />  ack 1087965816 win 10136 (DF)<br />  19:04:30.040960 client.1065 > server.smtp: . <br />  ack 1 win 64240 (DF)</p><p><br />  clientq接服务器的25端口Q三ơ握手正常,没有问题Q我们再往下看</p><p>  19:04:30.048862 server.33152 > client.113: S 99370916:99370916(0) win 8760 (DF)<br />  19:04:33.411006 server.33152 > client.113: S 99370916:99370916(0) win 8760 (DF)<br />  19:04:40.161052 server.33152 > client.113: S 99370916:99370916(0) win 8760 (DF)<br />  19:04:56.061130 server.33152 > client.113: R 99370917:99370917(0) win 8760 (DF)<br />  19:04:56.070108 server.smtp > client.1065: <br />  P 1:109(108) ack 1 win 10136 (DF)</p><p><br />  q里有问题了Q我们看到server端试图连接client?13认证端口Q然而client端ƈ不会d应它Qserver端从19?4?0U到19?4?6U尝?ơ,Ҏ26U后Q才攑ּ认证试Q主动reset了client端的113端口Q开始push后面的数据,而正是在q个q程中所p的时_使用户发送邮件时产生了O长的{待。?br />   问题扑ֈ了,下面的工作就好办了,通过修改服务器端的Y仉|,使它不再q行113端口的认证,看看q个问题解决了么Q不用问client用户Q再抓包如下Q?/p><p>  server# tcpdump host client<br />  tcpdump: listening on hme0<br />  19:06:45.775516 client.1066 > server.smtp: <br />  S 1119047365:1119047365(0) win 64240 (DF)<br />  19:06:45.775546 server.smtp > client.1066: <br />  S 116566929:116566929(0) ack 1119047366 win 10136 (DF)<br />  19:06:45.775776 client.1066 > server.smtp: <br />  . ack 1 win 64240 (DF)<br />  19:06:45.789316 server.smtp > client.1066: <br />  P 1:109(108) ack 1 win 10136 (DF)<br />  19:06:45.796767 client.1066 > server.smtp: <br />  P 1:11(10) ack 109 win 64132 (DF)<br />  我们看到Qserver不再q行113端口的认证尝试,直接push数据Q问题应该解冻I到client试验Q果然gq现象消失!</p><p>  p个试验,我们可以看到Q网l监听手D,对网l的pȝ理员是非常有h值的?/p><p>  然而,对入侵者呢Q与理员感兴趣的是Ҏ据包q行分析不同Q入侵者,感兴的是数据包的内容,其是̎P口o{敏感内宏V?/p><p>  我们模仿入R者在L上跑一个上面提到的sniffit软gQ监听本机发出去的所有telnet数据Q如下:</p><p>  server#./sniffit -A . -p 23 -s server</p><p><br />  同时Q我们模仿一个用户yimingd一台client机器Q?/p><p>  server@yiming#telnet client<br />  Trying 192.168.1.1...<br />  Connected to 192.168.1.1<br />  Escape character is '^]'.</p><p>  login: yiming<br />  Password:<br />  Sun Microsystems Inc. SunOS 5.7 Generic October 1998<br />  $ ls<br />  bak lost+found project wangguan<br />  libcap nms snmp wglist<br />  $ pwd<br />  /yiming<br />  $</p><p><br />  我们看到q个用户telnet到client机器Q输入̎号口令,执行了lsQpwd命oQ?/p><p>  此时看看sniffit的记录文件记录了什么,</p><p>  server# more server.32780-client.23<br />  ........... ..!.."..'.......h.7....#..$....VT100....'.........yiming..Power^man!..ls ..pwd..</p><p>  我们看到了̎号yimingQ密码Power^man!Q还有登录后操作的命令。请注意一点,yimingq个用户管讄了非常复杂的密码Q但对网l监听而言Q是没有丝毫意义的?/p><p>  其实除了截获telnet密码q样的功能外Q专用的|络监听软g从密码到邮gQ浏览的|页{内容,无所不包Q但׃本文不是介绍|络监听软g用途的Q因此这里不详细叙述各种监听软g的用方法,有兴的读者可以参照各个Y件的readme{文Ӟ很简单?br />  |络监听的防范方法:</p><p>  上面我们介绍了可以用来进行网l监听的软gQ那么对q种不受Ƣ迎的行为,有没有一些防范手D呢Q?/p><p>  上面我们知道Qsniffer是发生在以太|内的,那么Q很明显Q首先就要确保以太网的整体安全性,因ؓsniffer行ؓ要想发生Q一个最重要的前提条件就是以太网内部的一台有漏洞的主ȝQ只有利用被ȝ的主机,才能q行snifferQ去攉以太|内敏感的数据信息?/p><p>  其次Q采用加密手D也是一个很好的办法Q因为如果sniffer抓取到的数据都是以密文传输的Q那对入侵者即使抓取到了传输的数据信息Q意义也是不大的-比如作ؓtelnetQftp{安全替代品目前采用ssh2q是安全的。这是目前相对而言使用较多的手D之一Q在实际应用中往往是指替换掉不安全的采用明文传输数据的服务Q如在server端用ssh,openssh{替换unixpȝ自带的telnet,ftp,rshQ在client端用securecrt,sshtransfer替代telnet,ftp{?/p><p>  除了加密外,使用交换机目前也是一个应用比较多的方式,不同于工作在W一层的hub,交换机是工作在二层,也就是说数据链\层的Q以CISCO的交换机ZQ交换机在工作时l护着一张ARP的数据库Q在q个库中记录着交换机每个端口绑定的MAC地址Q当有数据报发送到交换ZӞ交换Z数据报的目的MAC地址与自q护的数据库内的端口对照,然后数据报发送到"相应?端口上,注意Q不同于HUB的报文广播方式,交换{发的报文是一一对应的。对二层讑֤而言Q仅有两U情况会发送广播报文,一是数据报的目的MAC地址不在交换机维护的数据库中Q此时报文向所有端口{发,二是报文本n是q播报文。由此,我们可以看到Q这在很大程度上解决了网l监听的困扰。但是有一点要注意Q随着dsniffQettercap{Y件的出现Q交换机的安全性已l面临着严峻的考验Q我们将在后面对q种技术进行介l?/p><p>  此外Q对安全性要求比较高的公司可以考虑kerberosQkerberos是一Uؓ|络通信提供可信W三Ҏ务的面向开攄l的认证机制Q它提供了一U强加密机制使client端和server即在非安全的网l连接环境中也能认彼此的n份,而且在双斚w过w䆾认证后,后箋的所有通讯也是被加密的。在实现中也卛_立可信的W三Ҏ务器保留与之通讯的系l的密钥数据库,仅kerberos和与之通讯的系l本w拥有私?private key)Q然后通过private key以及认证时创建的session key来实现可信的|络通讯q接?/p><p><strong>  网l监听的手段</strong></p><p>  对发生在局域网的其他主Z的监听,一直以来,都缺乏很好的方法。这是由于生网l监听行为的L在工作时L不做声的攉数据包,几乎不会d发出M信息。但目前|上已经有了一些解册个问题的思\和品:</p><p>  1Q反应时?<br />  向怀疑有|络监听行ؓ的网l发送大量垃圾数据包Q根据各个主机回应的情况q行判断Q正常的pȝ回应的时间应该没有太明显的变化,而处于؜杂模式的pȝ׃对大量的垃圾信息照单全收Q所以很有可能回应时间会发生较大的变化?<br />  2Q观dns <br />  许多的网l监听Y仉会尝试进行地址反向解析Q在怀疑有|络监听发生时可以在dnspȝ上观有没有明显增多的解析请求?</p><p>  3Q利用ping模式q行监测 </p><p><br />  上面我们说过Q当一C入؜杂模式时Q以太网的网卡会所有不属于他的数据照单全收。按照这个思\Q我们就可以q样来操作:假设我们怀疑的L的硬件地址?0:30:6E:00:9B:B9,它的ip地址?92.168.1.1,那么我们现在伪造出q样的一Uicmp数据包:g地址是不与局域网内Q何一C机相同的00:30:6E:00:9B:9B,目的地址?92.168.1.1不变Q我们可以设想一下这U数据包在局域网内传输会发生什么现象:M正常的主Z查这个数据包Q比较数据包的硬件地址Q和自己的不同,于是不会理会q个数据包,而处于网l监听模式的L呢?׃它的|卡现在是在h模式的,所以它不会d比这个数据包的硬件地址Q而是这个数据包直接传到上层Q上层检查数据包的ip地址Q符合自qipQ于是会对对q个ping的包做出回应。这P一台处于网l监听模式的Lp发现了?</p><p>  q种ҎQ在10phtq个黑客l织的antisniff产品中有很好的体现。可参见Q?   <a >http://www.securitysoftwaretech.com/antisniff/download.html</a></p><p>  4Q利用arp数据包进行监?<br />  除了使用pingq行监测外,目前比较成熟的有利用arp方式q行监测的。这U模式是上述ping方式的一U变体,它用arp数据包替代了上述的icmp数据包。向局域网内的L发送非q播方式的arp包,如果局域网内的某个L响应了这个arphQ那 么我们就可以判断它很可能是处于|络监听模式了,q是目前相对而言比较好的监测模式?</p><p>  q种方式Q在neped和PromiScanq两个品中有所体现。可分别参见Q?<a href="http://www.apostols.org/?>http://www.apostols.org/?/a><a >http://www.securityfriday.com/ToolDownload/PromiScan/promiscan_doc.html</a></p><p>  值得注意的是Q现在互联网上流传着一些基于上面这两种技术的脚本和程序,它们宣称自己能准捕捉到局域网内所有进行网l监听的LQ目前来Ԍq种说法基本上是不可靠的Q因Zq技术在实现中,除了要考虑|卡的硬件过滤外Q还需要考虑C同操作系l可能生的软gqo。因然理Z|卡处于h模式的系l应该接收所有的数据包,但实际上不同的操作系l甚至相同的操作pȝ的不同版本在tcp/ip的实C都有自己的一些特点,有可能不会接收这些理Z应该接收的数据包?/p><p>  除了上述几种方式外,q有一些其他的方式Q如Q检hub灯,但相比局限性就更大了,只能作ؓ上述模式的补充?/p><p>  相对而言Q对发生在本机的|络监听Q是可以利用一些工兯Y件来发现的,比较单,q里我们不介l,有兴的读者可以参考cert{网站?/p><p><br />  安全的交换机Q?/p><p>  文章到这里结束了吗?没有Q我们还漏掉了一个很重要的监听手D?交换环境下面的网l听Q这是个很有必要谈及的话题,W者作为网l管理员参加了许多的工程决策Q吃惊的发现许多的公叔Rq停留在交换机是局域网安全的彻底解决之道的概念上?/p><p>  应该认识到这个概忉|个传_是的Q在以前Q的是q样的,但随着上面介绍的dsniff{Y件的诞生Q所谓交换机的安全已l成Z个传说了?/p><p>  本文前面的部分介l了交换机工作的原理Q不同于HUB的共享式报文方式Q交换机转发的报文是一一对应的,由此看来Q交换环境下再采用传l的׃n式局域网下网l监听是不可行了Q由于报文是一一对应转发的,普通的|络监听软g此时无法监听C换环境下其它LM有h值的数据?/p><p>  交换机是安全的?</p><p>  不,q有一些别的方法,比如利用arpQ本文一开始就提到了局域网内主机数据包的传送完成不是依靠ip地址Q而是依靠arp扑ևip地址对应的mac地址实现的。而我们知道arp协议是不可靠和无q接的,通常即L没有发出arphQ也会接受发l它的arp回应Qƈ回应的mac和ip对应关系攑օ自己的arp~存中?/p><p>  那么如果能利用这个特性,在这个环节中做些文章Q还是可以截h据包的?/p><p>  Arp理论的实?/p><p><br />  作者这里推荐一个不错的上述理论产物QdsniffQ这个Y件包中包括了filesnarf?mailsnarf、msgsnarf、urlsnarf、dnsspoof、macof {诸多很有特色的lgQ可以捕Ll中的各U敏感数据,但这些不是今天感兴趣的主题,我们只看其中一个组ӞarpspoofQ这个组件就是上qarp理论的一个实践,它的工作原理是这LQ发起arpspoof的主机向目标L发送伪造的arp应答包,骗取目标pȝ更新arp表,目标系l的|关的mac地址修改为发起arpspoof的主机mac地址Q数据包都l由发varpspoof的主机,q样即ɾpȝq接在交换机上,也不会媄响对数据包的攫取Q由此就L的通过交换机实C|络监听?/p><p>  举例如下Q?<br />  La和bq接在交换机的同一个vlan上, <br />  A机的ip地址Q?92.168.1.37 <br />  B机的ip地址Q?92.168.1.35Qmac地址为:08-00-20-c8-fe-15 <br />  |关的ip地址Q?92.168.1.33Qmac地址为:00-90-6d-f2-24-00 </p><p>  首先在aZ看看a机的arp?/p><p>  C:\ >arp -a<br />  Interface: 192.168.1.37<br />  Internet Address Physical Address Type<br />  192.168.1.33 00-90-6d-f2-24-00 dynamic</p><p><br />  我们看到aZ保留着|关的ip地址192.168.1.33和对应的mac地址00-90-6d-f2-24-00</p><p>  我们在BZ执行arpspoofQ将目标指向a机,宣称自己为网养I如下Q?/p><p>  HOSTB# arpspoof -t 192.168.1.37 192.168.1.33<br />  8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15<br />  8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15<br />  8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15<br />  8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15<br />  8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15<br />  8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15<br />  8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15<br />  8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15<br />  8:0:20:c8:fe:15 0:50:ba:1a:f:c0 0806 42: arp reply 192.168.1.33 is-at 8:0:20:c8:fe:15</p><p><br />  可以看到b机持l向a发送arp回应包,宣称|关192.168.1.33的mac地址是自己!此时Q我们在aZ看看arp表的内容Q?/p><p>  C:\>arp -a<br />  Interface: 192.168.1.37<br />  Internet Address Physical Address Type<br />  192.168.1.33 08-00-20-c8-fe-15 dynamic</p><p><br />  哈!a机的arp表已l改变了Q网关的mac地址被更Cؓ?b机的mac地址Q这P当有数据包发送时Qa机理所当然的会发到它arp表中|关对应的mac地址08-00-20-c8-fe-15Q然而这个地方的b机正在等待着Q悄然无声的冒充|关收发着a机的数据包?/p><p>  有一点要说明的是Qؓ了让a正常使用|络Qb必须打开数据转发.<br />  linux中可以?/p><p>  sysctl -w net.ipv4.ip_forward = 1</p><p>  bsdpȝ可以使用</p><p>  sysctl -w net.inet.ip.forwarding =1</p><p><br />  solarispȝ可以使用</p><p>  ndd -set /dev/ip ip_forwarding 1</p><p>  除了q样打开内核的支持外Q也可以选用外部的fragrouter{{发YӞ如此Q就能确保a机正常工作了?/p><p>  此外Qettercap的作者指出,内核?.4.x的linuxpȝ在arp实现中,考虑Carpƺ骗Q不会接受未l请求的arp回应Q因此直接向q种pȝ发送arp reply也是无效的,不过Q有意思的是虽然它不会接受未经h的arp replyQ但是只要接收到arp的requestQ它׃更新自己的arp~存Q;)Q如此就好办了,发送一个伪造的arp request卛_Q不q,作者在自己实验时没有发现这个问题,作者内ؓ2.4.7的系l接受了直接的arp replyQƈ更新了自qarp表?/p><p>  如果一切配|正常的话,被重定向的a机是不会有什么明昄感觉的,|络照常是通畅的,只是在后台数据都l了一个小圈子Q不是直接到|关,而是先经由b机,再由b{发到|关Q因为数据包都经q了b机,那么在bZ起一个网l监听YӞa机的所有数据必然会被监听到。交换环境下的监听由此实玎ͼ</p><p>  除此之外Qdsniffq提供了macof{没交换机arp表等q行监听的模式,q里׃介绍了,有兴的读者可以自己查阅相兌料?/p><p>  Arp方式监听的防?/p><p><br />  对付采用arp方式的监听也是个比较手的问题,有几个不是非常理想的对策?/p><p>  首先q是上面提到的加密,可能的让局域网内的传输的数据都是秘文的Q这个可能相Ҏ理想的防范方法,但实施v来可能有一点困难。有一点要注意Qssh1是不安全的,我们提到的dsniff和ettercap都可以对ssh1实施中间人的监听?/p><p>  另外Q还可以考虑指定静态arpQ如大多数unixpȝ支持arpd指定的ip和mac地址对应文gQ首先编辑内容ؓip和mac地址对照的文Ӟ然后使用命oQarp -f /path/to/ipandmacmapfiled文gQ这样就指定了静态的arp地址Q即使接收到arp replyQ也不会更新自己的arp~存Q从而arpspoof丧失作用。windowspȝ没有-fq个参数Q但?s参数Q用命o行指定ip和mac地址对照关系Q如arp -s 192.168.1.33 00-90-6d-f2-24-00Q可惜除了xp外,其它的版本的windowq_即ɘq样做,当接收到伪造的arp reply后,依然会更新自qarp~存Q用新的mac地址替换掉老的mac地址Q所以无法对抗arpspoof。而且采用静态arp有一个缺憾,是如果|络很大的话Q工作量会非常的大?br />  Arp方式监听的检?br />  首先是借助ip地址和mac地址对应的工P如arpwatchQ安装了arpwatch的系l在发生mac地址变化时会在系l的日志文g中看到如下提C?/p><p>  Apr 21 23:05:00 192.168.1.35 arpwatch: flip flop 192.168.1.33 0:90:6d:f2:24:0 (8:0:20:c8:fe:15)<br />  Apr 21 23:05:02 192.168.1.35 arpwatch: flip flop 192.168.1.33 8:0:20:c8:fe:15 (0:90:6d:f2:24:0)<br />  Apr 21 23:05:03 192.168.1.35 arpwatch: flip flop 192.168.1.33 0:90:6d:f2:24:0 (8:0:20:c8:fe:15)</p><p><br />  从提CZ可以看出arpwatch到了网关mac地址发生了改变?/p><p>  其次借助于一些入侉|系l,如snortQ亦可以起到的一定的作用。在snort的配|文件中打开arpspoof的preprocessor开兛_ƈq行配置卛_?/p><p>  作者本验发玎ͼ如果采用本地解析Ӟ观测局域网本地的dns服务器的反解是一个好的办法,因ؓ发varpspoof的主Z不间断的试正反解析冒充的网关ipQ发送数量非常多的重复解析数据包Q当怀疑有arpspoof时很Ҏ被发玎ͼ如下Q?/p><p>  nameserver# tcpdump -n -s 0 port 53<br />  tcpdump: listening on hme0<br />  23:19:22.489417 192.168.1.35.41797 > 192.168.1.68.53: <br />  32611+ PTR? 33.224.102.202.in-addr.arpa. (45) (DF)<br />  23:19:22.490467 192.168.1.35.41798 > 192.168.1.68.53: <br />  32611+ PTR? 33.224.102.202.in-addr.arpa. (45) (DF)</p><p><br />  l束语:<br />  上面我们介绍了网l监听技术的几个主要斚wQ包括网l监听的主要技术细节,具体实现Q检方法等。此外还介绍了一U非传统的监听方式,通过本文Q希望读者能对网l监听生一些认识?/p><p>  参考资?</p><p>  Richard stevens: 《TCP/IP Illustrated, Volume 1: The Protocols?/p><p><br />  Dsniff|站Q?<a >http://www.monkey.org/~dugsong/dsniff/</a></p><p><br />  Attacks Against SSH 1 And SSL的讨论: <a >http://slashdot.org/articles/00/12/18/0759236.shtml</a></p><p><br />  ettercap|站Q?<a >http://ettercap.sourceforge.net/</a></p><img src ="http://www.shnenglu.com/jjbird/aggbug/6246.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.shnenglu.com/jjbird/" target="_blank">奇奇</a> 2006-04-25 15:35 <a href="http://www.shnenglu.com/jjbird/articles/6246.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss> <footer> <div class="friendship-link"> <p>лǵվܻԴȤ</p> <a href="http://www.shnenglu.com/" title="精品视频久久久久">精品视频久久久久</a> <div class="friend-links"> </div> </div> </footer> <a href="http://www.dituibangbang.cn" target="_blank">Ļþþ</a>| <a href="http://www.bdgk.net.cn" target="_blank">þ99Ʒþþþþ</a>| <a href="http://www.wanrengou.cn" target="_blank">þþƷа</a>| <a href="http://www.swwpb.cn" target="_blank">˾þô߽ۺӰԺҳ</a>| <a href="http://www.51uhq.cn" target="_blank">Ļһþ</a>| <a href="http://www.126yi.cn" target="_blank">þþƵ</a>| <a href="http://www.benzclub.com.cn" target="_blank">þƵ</a>| <a href="http://www.837666.cn" target="_blank">˾þô߽</a>| <a href="http://www.qp576.cn" target="_blank">69Ʒþþþ9999</a>| <a href="http://www.86bzpp.cn" target="_blank">2021Ʒҹþ </a>| <a href="http://www.liuy88.cn" target="_blank">99ȳ˾ƷѾþ</a>| <a href="http://www.top-cc.cn" target="_blank">޹պŷۺϾþ</a>| <a href="http://www.srxug.cn" target="_blank">69þþƷһ</a>| <a href="http://www.iaicy.cn" target="_blank">þ޾Ʒϵַ</a>| <a href="http://www.soba30.cn" target="_blank">˾þþùۿëƬ</a>| <a href="http://www.niena.cn" target="_blank">ŷҹͽþþ</a>| <a href="http://www.safaen.cn" target="_blank">Ʒþۺ</a>| <a href="http://www.6kk.org.cn" target="_blank">ŷ˼Ծþ</a>| <a href="http://www.bxauomc.cn" target="_blank">ҹƷþþþþžŵӰ</a>| <a href="http://www.vnaiman.cn" target="_blank">Ļɫ͵͵þ </a>| <a href="http://www.leyuzhe.cn" target="_blank">þþƷ˘AV </a>| <a href="http://www.uugp.cn" target="_blank">þҹɫƷŷ</a>| <a href="http://www.laopaiwaihui.cn" target="_blank">þ޹ӰԺվ</a>| <a href="http://www.secwatch.com.cn" target="_blank">ҹƷþþþ </a>| <a href="http://www.fx40.cn" target="_blank">ĻȾþþþþþ</a>| <a href="http://www.yunfu2.cn" target="_blank">þҹɫƷ</a>| <a href="http://www.lepinw.cn" target="_blank">Ʒþþþ龫Ʒ</a>| <a href="http://www.vtqqv.cn" target="_blank">Ʒþ</a>| <a href="http://www.moisky.com.cn" target="_blank">ŷƷþþþþþο</a>| <a href="http://www.west126.cn" target="_blank">͵þþþƷר </a>| <a href="http://www.zhangyiping.cn" target="_blank">뾫ƷþѼ</a>| <a href="http://www.pudlv.cn" target="_blank">þþùƷһ</a>| <a href="http://www.s5wow.cn" target="_blank">þˬˬƬAV </a>| <a href="http://www.sme369.cn" target="_blank">ɫþþۺľþav </a>| <a href="http://www.moisky.com.cn" target="_blank">ŮƷþþ</a>| <a href="http://www.jiangyuyun.cn" target="_blank">þۺۺϾþ97ɫ</a>| <a href="http://www.lenticular3d.cn" target="_blank">þ96Ʒþþ</a>| <a href="http://www.jsykszn.cn" target="_blank">þþƵ</a>| <a href="http://www.15961662156.cn" target="_blank">ŷ޹Ʒþѿ</a>| <a href="http://www.bkkg.net.cn" target="_blank">Ʒþþþþ</a>| <a href="http://www.renliu123.cn" target="_blank">ƷþþӰ</a>| <script> (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })(); </script> </body>