久久综合伊人噜噜色,日本三级香港三级人妇电影精品,亚洲中文色资源,国产高清一区二区三区人妖

    1. <sub id="9pxky"></sub>
    2. <small id="9pxky"></small>

           找回密碼
           注冊

          QQ登錄

          只需一步,快速開始

          IP欺騙的技術(shù)

          [復(fù)制鏈接]
          1#
          發(fā)表于 2011-1-13 17:01:50 | 只看該作者 |倒序瀏覽 |閱讀模式
          。
          ) n5 V8 k' e+ LIP欺騙的技術(shù)比較復(fù)雜,不是簡單地照貓畫老虎就能掌握,但作為常規(guī)攻擊手段,有必要理解其原理,至少有利于自己的安全防范,易守難攻嘛。 ! j, Y/ j( ]9 z! {- h
          - `& C) Q& b5 K# Y8 Z
          假設(shè)B上的客戶運行rlogin與A上的rlogind通信: * {( F1 k2 Y- T" o
          / D$ V% ~6 G) u2 H; O
          1. B發(fā)送帶有SYN標(biāo)志的數(shù)據(jù)段通知A需要建立TCP連接。并將TCP報頭中的sequence number設(shè)置成自己本次連接的初始值ISN。
            _. S; H& f" C& D* M  T( @6 B8 m: }2 w$ s1 F, H2 Y2 ]' \0 M% g7 v
          2. A回傳給B一個帶有SYS+ACK標(biāo)志的數(shù)據(jù)段,告之自己的ISN,并確認(rèn)B發(fā)送來的第一個數(shù)據(jù)段,將acknowledge number設(shè)置成B的ISN+1。 7 n0 [" J0 {6 q+ Q, K& g
          + _. x$ Q! {7 V/ [
          3. B確認(rèn)收到的A的數(shù)據(jù)段,將acknowledge number設(shè)置成A的ISN+1。
          + a* C8 [6 Y* w: i2 W+ k$ C' n
          / f: S2 k0 z6 @B ---- SYN ----> A 1 q* K, S1 \4 I# X' r# r9 o  d
          B <---- SYN+ACK A
          0 \3 T3 }, J; Z" e, R$ z5 c- `B ---- ACK ----> A
          # \7 X% d0 Y/ V. T5 c; ~! \+ h( _6 L, @/ \) B2 p
          TCP使用的sequence number是一個32位的計數(shù)器,從0-4294967295。TCP為每一個連接選擇一個初始序號ISN,為了防止因為延遲、重傳等擾亂三次握手,ISN不能隨便選取,不同系統(tǒng)有不同算法。理解TCP如何分配ISN以及ISN隨時間變化的規(guī)律,對于成功地進(jìn)行IP欺騙攻擊很重要。
          7 b- ], t) P& ^4 G
          $ v$ Y3 W) d& ~8 Z. L* O4 D基于遠(yuǎn)程過程調(diào)用RPC的命令,比如rlogin、rcp、rsh等等,根據(jù)/etc/hosts.equiv以及$HOME/.rhosts文件進(jìn)行安全校驗,其實質(zhì)是僅僅根據(jù)信源IP地址進(jìn)行用戶身份確認(rèn),以便允許或拒絕用戶RPC。關(guān)于上述兩個文件請man,不喜歡看英文就去Unix版看看我以前灌過的一瓢水。
          & c" f' n  D' b# A" ~) d$ D1 O% H; ~6 q" ^2 N5 |
          IP欺騙攻擊的描述:
          1 G; e/ }! K( H" _7 g
          * U  ~9 H3 b( u9 Y0 R; {1. 假設(shè)Z企圖攻擊A,而A信任B,所謂信任指/etc/hosts.equiv和$HOME/.rhosts中有相關(guān)設(shè)置。注意,如何才能知道A信任B呢?沒有什么確切的辦法。我的建議就是平時注意搜集蛛絲 ) F6 l2 N: }- t+ f
          馬跡,厚積薄發(fā)。一次成功的攻擊其實主要不是因為技術(shù)上的高明,而是因為信息搜集的廣泛翔實。動用了自以為很有成就感的技術(shù),卻不比人家酒桌上的巧妙提問,攻擊只以成功為終極目標(biāo),不在乎手段。
          & s9 l, M0 v3 j( _8 I
          3 |, J- h+ R4 \# M9 D0 n! O2. 假設(shè)Z已經(jīng)知道了被信任的B,應(yīng)該想辦法使B的網(wǎng)絡(luò)功能暫時癱瘓,以免對攻擊造成干擾。著名的SYN flood常常是一次IP欺騙攻擊的前奏。請看一個并發(fā)服務(wù)器的框架: 5 Q( O( Y3 z4 J. a- I2 D  ]
          ; [2 o7 s- p* l
          int initsockid, newsockid;
          + C- w' i% O) F1 Uif ((initsockid = socket(...)) <0) { 8 j+ u; E7 F2 u" E8 }& }8 [
          error("can't create socket"); % y% w; A- B2 \1 y  n1 P
          } ; f9 m4 H* S1 z( m& n2 j9 N
          if (bind(initsockid, ...) <0) { 2 K8 k$ {; c: ?7 i( t4 t8 K; F3 w+ X
          error("bind error"); 6 X/ n% A% x# p, K9 V5 s6 Z
          }
          , Y) \/ P; C( z  t$ `0 Gif (listen(initsockid, 5) <0) {
          % ]4 @( H5 v0 w% B" [1 |6 berror("listen error"); ( h; W& r' L, M2 C* [
          }
          7 F" K9 M" [, Hfor (;;) {
          + g5 M1 S9 {' q6 d6 n3 u: Wnewsockid = accept(initsockid, ...); /* 阻塞 */ 8 M- x; E$ A  j
          if (newsockid <0) {
          ( B# V/ {0 U; `error("accept error"); 6 q3 D) O7 I* i
          } 2 b" z! |; w1 F1 C
          if (fork() == 0) { /* 子進(jìn)程 */ 0 G" g: a4 `; b: ?
          close(initsockid);
          . ]$ E& W/ C  ~+ Z4 Y- xdo(newsockid); /* 處理客戶方請求 */ $ O3 j$ c! X& u( d' j3 I, [+ M
          exit(0); * S) ~5 H8 }% g
          }
          # p" U- u. X. N: T1 rclose(newsockid);
          ; e" D; E( I0 q2 @+ Y% N9 M}   a4 B# H) x, L/ F3 W( o  i0 d" ]

          ! }/ L/ Y. J4 Z) Flisten函數(shù)中第二個參數(shù)是5,意思是在initsockid上允許的最大連接請求數(shù)目。如果某個時刻initsockid上的連接請求數(shù)目已經(jīng)達(dá)到5,后續(xù)到達(dá)initsockid的連接請求將被TCP丟棄。注意一旦連接通過三次握手建立完成,accept調(diào)用已經(jīng)處理這個連接,則TCP連接請求隊列空出一個位置。所以這個5不是指initsockid上只能接受5個連接請求。SYN flood正是一種Denial of Service,導(dǎo)致B的網(wǎng)絡(luò)功能暫 碧被盡?nbsp;
          # a# K5 \1 o: K. _& ~( J' y
          , n2 J5 G  \; z3 OZ向B發(fā)送多個帶有SYN標(biāo)志的數(shù)據(jù)段請求連接,注意將信源IP地址換成一個不存在的主機(jī)X;B向子虛烏有的X發(fā)送SYN+ACK數(shù)據(jù)段,但沒有任何來自X的ACK出現(xiàn)。B的IP層會報告B的TCP層,X不可達(dá),但B的TCP層對此不予理睬,認(rèn)為只是暫時的。于是B在這個initsockid上再也不能接收正常的連接請求。 0 `  g( W6 s: B/ {9 @' [& M
          # V  @& j' Q# L) c# u& K) d
          Z(X) ---- SYN ----> B
          3 L, s8 p. p$ F4 {" T* p3 \8 [* NZ(X) ---- SYN ----> B 0 P9 ?  f9 _; I. d4 U. L/ G# x
          Z(X) ---- SYN ----> B * j% j5 X5 v* ~6 a0 q( G3 K( L  w
          Z(X) ---- SYN ----> B & N, V8 K; O* J: E8 p& _! N! X
          Z(X) ---- SYN ----> B 1 Y! y  O2 [" s& v
          ...... 3 G+ b: X4 \" A9 }- i5 R" z+ a; }
          X <---- SYN+ACK B
          % _/ e- O0 B8 f6 j2 i8 uX <---- SYN+ACK B 4 P) i5 n3 ?& L  D. T6 Z  y
          X <---- SYN+ACK B
          * p& k) X% z9 _1 o1 tX <---- SYN+ACK B 6 Q, m; }# I# b! J3 {
          X <---- SYN+ACK B 7 E" @+ }3 z) o; g3 @% o4 N
          ......   @, N( T/ b& V0 k
          # }, ?- G, @, v6 J; a" o* ^5 {% ~
          作者認(rèn)為這樣就使得B網(wǎng)絡(luò)功能暫時癱瘓,可我覺得好象不對頭。因為B雖然在initsockid上無法接收TCP連接請求,但可以在another initsockid上接收,這種SYN flood應(yīng)該只對特定的   r7 Y% Z8 ?# l7 I9 i" c/ l; K' [
          服務(wù)(端口),不應(yīng)該影響到全局。當(dāng)然如果不斷地發(fā)送連接請求,就和用ping發(fā)洪水包一個道理,使得B的TCP/IP忙于處理負(fù)載增大。至于SYN flood,回頭有機(jī)會我單獨灌一瓢有關(guān)DoS的。如何使B的網(wǎng)絡(luò)功能暫 碧被居 很多辦法,根據(jù)具體情況而定,不再贅述。 9 K  L  t) m5 O5 p" b! n+ T# g  i
          , |7 l  I7 l# H: e5 Q
          3. Z必須確定A當(dāng)前的ISN。首先連向25端口(SMTP是沒有安全校驗機(jī)制的),與1中類似,不過這次需要記錄A的ISN,以及Z到A的大致的RTT(round trip time)。這個步驟要重復(fù)多次以便求出 + H* k6 v% L# w9 U  J  v. `
          RTT的平均值?,F(xiàn)在Z知道了A的ISN基值和增加規(guī)律(比如每秒增加128000,每次連接增加64000),也知道了從Z到A需要RTT/2的時間。必須立即進(jìn)入攻擊,否則在這之間有其他主機(jī)與A連接, 1 a# n0 L8 C4 f- n
          ISN將比預(yù)料的多出64000。   |, Q+ L1 `5 @5 l  }9 h& K

          7 F6 l/ N# v3 A) h/ a4. Z向A發(fā)送帶有SYN標(biāo)志的數(shù)據(jù)段請求連接,只是信源IP改成了B,注意是針對TCP513端口(rlogin)。A向B回送SYN+ACK數(shù)據(jù)段,B已經(jīng)無法響應(yīng)(憑什么?按照作者在2中所說,估計還達(dá)不到這個效果,因為Z必然要模仿B發(fā)起connect調(diào)用,connect調(diào)用會完成全相關(guān),自動指定本地socket地址和端口,可事實上B很可能并沒有這樣一個端口等待接收數(shù)據(jù)。除非Z模仿B發(fā)起
          - i+ p& ^! L5 H$ O  r連接請求時打破常規(guī),主動在客戶端調(diào)用bind函數(shù),明確完成全相關(guān),這樣必然知道A會向B的某個端口回送,在2中也針對這個端口攻擊B??墒侨绻@樣,完全不用攻擊B,bind的時候   j2 G! }% d6 X% V( }
          指定一個B上根本不存在的端口即可。我也是想了又想,還沒來得及看看老外的源代碼,不妥之處有待商榷??傊X得作者好象在蒙我們,他自己也沒有實踐成功過吧。),B的TCP層只是 ' i/ n4 \2 g- e6 _: Y$ `9 M
          簡單地丟棄A的回送數(shù)據(jù)段。
          5 s0 I7 ], M+ T
          6 B  y" c. s9 j1 b  r% ^) v: {5. Z暫停一小會兒,讓A有足夠時間發(fā)送SYN+ACK,因為Z看不到這個包。然后Z再次偽裝成B向A發(fā)送ACK,此時發(fā)送的數(shù)據(jù)段帶有Z預(yù)測的A的ISN+1。如果預(yù)測準(zhǔn)確,連接建立,數(shù)據(jù)傳送開始。問題在于即使連接建立,A仍然會向B發(fā)送數(shù)據(jù),而不是Z,Z仍然無法看到A發(fā)往B的數(shù)據(jù)段,Z必須蒙著頭按照rlogin協(xié)議標(biāo)準(zhǔn)假冒B向A發(fā)送類似 "cat + + >> ~/.rhosts" 這樣的命令,于是攻擊完成。如果預(yù)測不準(zhǔn)確,A將發(fā)送一個帶有RST標(biāo)志的數(shù)據(jù)段異常終止連接,Z只有從頭再來。
          # o% x$ P0 d& Y- E% T1 N5 A! C6 V: x# i; ]7 b+ B: b0 ^! @
          Z(B) ---- SYN ----> A
          3 |$ p( ?5 l+ ?, y. q5 o, U+ {B <---- SYN+ACK A
          ; H8 f$ \) H7 u3 I3 }0 D3 U) c0 @Z(B) ---- ACK ----> A
          2 B; _( |. W! g1 s, a  U8 R1 |4 lZ(B) ---- PSH ----> A & Q1 J1 }" w& u. w0 _% |$ e; V
          ...... 9 V0 w8 G8 [* `8 D; Z
          , h# y/ G: m) W
          6. IP欺騙攻擊利用了RPC服務(wù)器僅僅依賴于信源IP地址進(jìn)行安全校驗的特性,建議閱讀rlogind的源代碼。攻擊最困難的地方在于預(yù)測A的ISN。作者認(rèn)為攻擊難度雖然大,但成功的可能性
          5 r8 H7 O7 R6 E" j. m也很大,不是很理解,似乎有點矛盾。考慮這種情況,入侵者控制了一臺由A到B之間的路由器,假設(shè)Z就是這臺路由器,那么A回送到B的數(shù)據(jù)段,現(xiàn)在Z是可以看到的,顯然攻擊難度
          - W, \+ {! f$ F2 [* Y7 ?; m驟然下降了許多。否則Z必須精確地預(yù)見可能從A發(fā)往B的信息,以及A期待來自B的什么應(yīng)答信息,這要求攻擊者對協(xié)議本身相當(dāng)熟悉。同時需要明白,這種攻擊根本不可能在交互狀態(tài)下完
          1 X, q# c0 B" S. @" x, j成,必須寫程序完成。當(dāng)然在準(zhǔn)備階段可以用netxray之類的工具進(jìn)行協(xié)議分析。
          % A5 O5 h" X4 S  u5 M5 W
          ; \$ T" w) [  b) G1 S1 F7. 如果Z不是路由器,能否考慮組合使用ICMP重定向以及ARP欺騙等技術(shù)?沒有仔細(xì)分析過,只是隨便猜測而已。并且與A、B、Z之間具體的網(wǎng)絡(luò)拓?fù)溆忻芮嘘P(guān)系,在某些情況下顯然大幅度
          ( o( x; T4 a7 U- u' d) Y# r  Z! L降低了攻擊難度。注意IP欺騙攻擊理論上是從廣域網(wǎng)上發(fā)起的,不局限于局域網(wǎng),這也正是這種攻擊的魅力所在。利用IP欺騙攻擊得到一個A上的shell,對于許多高級入侵者,得到目標(biāo)主
          & H1 z6 k9 d+ j& U* m: o' ^8 Y! |機(jī)的shell,離root權(quán)限就不遠(yuǎn)了,最容易想到的當(dāng)然是接下來進(jìn)行buffer overflow攻擊。
          * f9 S3 R7 a- A8 N" f8 B4 {
          1 {2 n7 \2 R2 x8. 也許有人要問,為什么Z不能直接把自己的IP設(shè)置成B的?這個問題很不好回答,要具體分析網(wǎng)絡(luò)拓?fù)?,?dāng)然也存在ARP沖突、出不了網(wǎng)關(guān)等問題。那么在IP欺騙攻擊過程中是否存在ARP沖突問題。回想我前面貼過的ARP欺騙攻擊,如果B的ARP Cache沒有受到影響,就不會出現(xiàn)ARP沖突。如果Z向A發(fā)送數(shù)據(jù)段時,企圖解析A的MAC地址或者路由器的MAC地址,必然會發(fā)送ARP請求包,但這個ARP請求包中源IP以及源MAC都是Z的,自然不會引起ARP沖突。而ARP Cache只會被ARP包改變,不受IP包的影響,所以可以肯定地說,IP欺騙攻擊過程中不存在ARP沖突。相反,如果Z修改了自己的IP,這種ARP沖突就有可能出現(xiàn),示具體情況而言。攻擊中連帶B一起攻擊了,其目的無非是防止B干擾了攻擊過程,如果B本身已經(jīng)down掉,那是再好不過(是嗎?)。 0 p/ m7 C8 l; ^  F" s! l

          - [! c6 |1 k+ s$ t1 ^, x& I# u0 t* H9. fakeip曾經(jīng)沸沸揚揚了一下,我對之進(jìn)行端口掃描,發(fā)現(xiàn)其tcp端口113是接收入連接的。和IP欺騙等沒有直接聯(lián)系,和安全校驗是有關(guān)系的。當(dāng)然,這個東西并不如其名所暗示,對IP層沒有任何動作。 # i7 B8 b  l3 M& W. }/ S5 a
          ' j0 d5 J5 B3 ~+ Y
          10. 關(guān)于預(yù)測ISN,我想到另一個問題。就是如何以第三方身份切斷A與B之間的TCP連接,實際上也是預(yù)測sequence number的問題。嘗試過,也很困難。如果Z是A與B之間的路由器,就不用說了;或者Z動用了別的技術(shù)可以監(jiān)聽到A與B之間的通信,也容易些;否則預(yù)測太難。作者在3中提到連接A的25端口,可我想不明白的是513端口的ISN和25端口有什么關(guān)系?看來需要看看TCP/IP內(nèi)部實現(xiàn)的源代碼。 $ V+ Q( _; @! |& b. b3 M
            O, a* e; T' g% A* u
          未雨綢繆 : c/ J% p5 O, m: ?1 R% {

          0 a$ t; [* t6 w7 C4 H雖然IP欺騙攻擊有著相當(dāng)難度,但我們應(yīng)該清醒地意識到,這種攻擊非常廣泛,入侵往往由這里開始。預(yù)防這種攻擊還是比較容易的,比如刪除所有的/etc/hosts.equiv、$HOME/.rhosts文件,修改/etc/inetd.conf文件,使得RPC機(jī)制無法運做,還可以殺掉portmapper等等。設(shè)置路由器,過濾來自外部而信源地址卻是內(nèi)部IP的報文。cisio公司的產(chǎn)品就有這種功能。不過路由器只防得了外部入侵,內(nèi)部入侵呢?
          # U/ L) o& W& l; A/ o5 u
          5 U2 {  S* O- W( y$ ]( _7 g6 K) ITCP的ISN選擇不是隨機(jī)的,增加也不是隨機(jī)的,這使攻擊者有規(guī)可循,可以修改與ISN相關(guān)的代碼,選擇好的算法,使得攻擊者難以找到規(guī)律。估計Linux下容易做到,那solaris、irix、hp-unix還有aix呢?sigh
          ( Y7 t% S) f( W, S, h! p/ E/ v$ [, b3 i/ k5 J4 N# p9 c9 K
          雖然作者紙上談兵,但總算讓我們了解了一下IP欺騙攻擊,我實驗過預(yù)測sequence number,不是ISN,企圖切斷一個TCP連接,感覺難度很大。作者建議要找到規(guī)律,不要盲目預(yù)測,這需要時間和耐心?,F(xiàn)在越發(fā)明白什么是那種鍥而不舍永遠(yuǎn)追求的精神,我們所向往的傳奇故事背后有著如此沉默的艱辛和毅力,但愿我們學(xué)會的是這個,而不是浮華與喧囂。一個現(xiàn)成的bug足以讓你取得root權(quán)限,可你在做什么,你是否明白?我們太膚淺了......
          7 ^: a8 |. u! I/ T) U
          淺了......
          您需要登錄后才可以回帖 登錄 | 注冊

          本版積分規(guī)則

          QQ|本地廣告聯(lián)系: QQ:905790666 TEL:13176190456|Archiver|手機(jī)版|小黑屋|汶上信息港 ( 魯ICP備19052200號-1 )

          GMT+8, 2025-4-16 09:31

          Powered by Discuz! X3.5

          © 2001-2025 Discuz! Team.

          快速回復(fù) 返回頂部 返回列表