【求助】飽受攻擊的APACHE - 第3頁 - PCZONE 討論區

返回   PCZONE 討論區 > ▲ -- 電 腦 軟 體 討 論 區 > -- FreeBSD & Linux 討 論 版


PCZONE 討論區



通知

-- FreeBSD & Linux 討 論 版 因為本站採用 FreeBSD 作業系統,所以自己本身也多學了一些技巧,希望各位在這裡互相討論 Unix 作業系統及程式等相關問題。

明誠科技小峰

檢單一點說,如果你前端沒有其他OS的防火牆,只要我ㄧ直丟TCP的SYN給你,就可以讓你的主機服務停擺,因為CPU資源會吃完.

因為LINUX目前2.4.*的核心就是有這個漏洞,除非更換2.6的核心,不過還沒有STABLE版.不要以為設定好IPTABLE然後漏洞PATCH一下就夠了,公開的作業系統仍舊有很多安全上的問題。包含WIN平台也是一樣的.

回覆
會員

引用:
作者: cheerx
檢單一點說,如果你前端沒有其他OS的防火牆,只要我ㄧ直丟TCP的SYN給你,就可以讓你的主機服務停擺,因為CPU資源會吃完.

因為LINUX目前2.4.*的核心就是有這個漏洞,除非更換2.6的核心,不過還沒有STABLE版.不要以為設定好IPTABLE然後漏洞PATCH一下就夠了,公開的作業系統仍舊有很多安全上的問題。包含WIN332平台也是一樣的.
把Linux kernel中的tcp syn cookies打開如何??....BTW,這個option在v2.2的kernel就有了,只是default是關掉的(一般的distribution可能沒開這個option,要重compile kernel才有 ),而且重compile kernel後還是得自己到/proc內把它打開才有作用 ....
回覆
拉登長官

引用:
作者: wangcm
把Linux kernel中的tcp syn cookies打開如何??....BTW,這個option在v2.2的kernel就有了,只是default是關掉的(一般的distribution可能沒開這個option,要重compile kernel才有 ),而且重compile kernel後還是得自己到/proc內把它打開才有作用 ....
syn cookies 主要是利用 TCP options 裡的 Maximum Segment Size 欄位

在 Linux Kernel TCP/IP stack 的實作上
1. Syn cookies 要等到 Syn Queue 滿了才會開始啟用
2. 一旦開始啟用, 所有的 TCP 封包皆被認定為 "syncookies enabled"

1. 本身沒有問題, 2. 的問題嚴重

因為如果某 TCP 連線實際上並沒有啟用 syn cookies, 但是卻想攻擊
於是他可以產生非常大量的 ACK 封包(亂填 MSS), 當一旦被矇到時,
攻擊者便可以不須要 3 way handshake 而造成 connection established

而且, 攻擊者並不須要產生 SYN 封包, 就可以連線..
如果一個不熟 iptables 的人, 他只檢查 SYN 封包的話, 那麼他就會 pass

http://www.securitytracker.com/alert...v/1002692.html

雖然這是很早以前就發出來的 Security Alerts, 但他提醒, 如果不熟悉
iptables & 底層, 有些東西還是不要開的好

http://cr.yp.to/syncookies.html 這是 Syn Cookies 的介紹
回覆
明誠科技小峰

樓上兩位前輩的發言都很有參考價值,又學到一課了.

仔細做過功課就會發現,如果沒錢買防火牆,還是改用BSD好了.現在隨手可得的LINUX套件,預設就有很多會被K的東西,更不用講一些較早安裝系統,且重來沒有補過架站套件的人.身為管主機的資訊人員,經常的逛逛駭客網站和資安網站實在是很有必要的.
回覆
會員

引用:
作者: dou0228
syn cookies 主要是利用 TCP options 裡的 Maximum Segment Size 欄位

在 Linux Kernel TCP/IP stack 的實作上
1. Syn cookies 要等到 Syn Queue 滿了才會開始啟用
2. 一旦開始啟用, 所有的 TCP 封包皆被認定為 "syncookies enabled"

1. 本身沒有問題, 2. 的問題嚴重

因為如果某 TCP 連線實際上並沒有啟用 syn cookies, 但是卻想攻擊
於是他可以產生非常大量的 ACK 封包(亂填 MSS),當一旦被矇到時,攻擊者便可以不須要 3 way handshake 而造成 connection established

而且, 攻擊者並不須要產生 SYN 封包, 就可以連線..
如果一個不熟 iptables 的人, 他只檢查 SYN 封包的話, 那麼他就會 pass

雖然這是很早以前就發出來的 Security Alerts, 但他提醒, 如果不熟悉
iptables & 底層, 有些東西還是不要開的好

這是 Syn Cookies 的介紹
syn flooding應該是TCP先天上的弱點,而不是特定OS/NIC的缺陷,而您所提"可以產生非常大量的 ACK 封包(亂填 MSS), 當一旦被矇到時,攻擊者便可以不須要 3 way handshake 而造成 connection established"應該是指IP spoofing之類的attack(通常是blind spoofing,與DDoS之類實際建立vaild connection的attack是不同的),但ISP(不論是哪類ISP)是有必要在對user端的ingress端把此類invaild packet先濾掉的(BTW,對以LAN為access media的ISP如學術網路或社區網路等此點有實務上的困難),如此一來應可降低此類attack發生的機會,而且MSS或Ack No被矇到雖說不是不可能,但實務上有能力實作(而且有意願實作)此類attack者為數應該不多吧....

PS:其實在座各位恐怕都離題了,以鵝個人觀點,原發文者最該作的是好好check一下自己的機器(看一下Apache/PHP等等是不是有可以被利用的bug,/tmp或/var/tmp堶惘釣S有不該出現的東東 ) ,是不是被放了啥後門,成了DDoS的跳板,或許其機器的loading根本是由攻擊別人而來,而非被別人攻擊 ....
回覆
拉登長官

引用:
作者: wangcm
syn flooding應該是TCP先天上的弱點,而不是特定OS/NIC的缺陷,而您所提"可以產生非常大量的 ACK 封包(亂填 MSS), 當一旦被矇到時,攻擊者便可以不須要 3 way handshake 而造成 connection established"應該是指IP spoofing之類的attack(通常是blind spoofing,與DDoS之類實際建立vaild connection的attack是不同的),但ISP(不論是哪類ISP)是有必要在對user端的ingress端把此類invaild packet先濾掉的(BTW,對以LAN為access media的ISP如學術網路或社區網路等此點有實務上的困難),如此一來應可降低此類attack發生的機會,而且MSS或Ack No被矇到雖說不是不可能,但實務上有能力實作(而且有意願實作)此類attack者為數應該不多吧....
Syn Flooding 雖說是 TCP 的弱點沒錯, 但是 2.4.x 的 Linux Kernel
有可能在遭受到大量封包湧入時, 造成無法回應的情形, 連 console 都沒有

我要提的是:
1. Linux syn cookies 實作還是有改進的空間
2. 那並不算是 IP spoofing, 就只是利用 syn cookies 這概念而已.
3. 最好的解法當然還是在 ISP 端解決, 只不過 ISP 有時候是出事了才管
4. 我説的 syn cookies 與 iptables 的關係是:
萬一 attacker 真的矇到 MSS, 那麼, 在 iptables 並不會看到 syn 封包
如果 Router/分享器, ... 沒有考慮到, 那麼 attacker 就有可能在不被發
現的情況下, 建立連線( iptables rules passed )
5. 不確定瞭不瞭解 iptables 底層實作的人, 我的建議是, 不要開 syn cookies 自找麻煩
回覆
會員

引用:
作者: dou0228
Syn Flooding 雖說是 TCP 的弱點沒錯, 但是 2.4.x 的 Linux Kernel
有可能在遭受到大量封包湧入時, 造成無法回應的情形, 連 console 都沒有

我要提的是:
1. Linux syn cookies 實作還是有改進的空間
或許linux kernel的syn cookies會帶來其它潛在的風險,所以default是被disable掉的,而且securitytracker的網頁上也有提到應該將其改成per-socket basis....但請問兄台對此類DoS是否有其它對策??

引用:
作者: dou0228
2. 那並不算是 IP spoofing, 就只是利用 syn cookies 這概念而已.
此類attack通常只在IP spoofing時有意義,實際建立vaild connection的DoS是不須要去'矇''Ack no或MSS的,但實際建立vaild connection的DoS是可以由限制單一IP cocurrent connection數的方式降低其影響....BTW,是否可以藉由限制3-way handshake的時間來降低resource被此類semi open DoS吃掉的速度??以目前的環境而言,120sec的確是太長了....

引用:
作者: dou0228
3. 最好的解法當然還是在 ISP 端解決, 只不過 ISP 有時候是出事了才管
ISP default就會把有IP spoofing之嫌的packet濾掉吧.....畢竟除了極少數狀況外這些packet是可以當成garbage直接drop掉的(spoofed src->dst會通,但dst->spoofed src是沒有意義的 ),讓其進backbone只是製造自己的困擾罷了....

引用:
作者: dou0228
4. 我説的 syn cookies 與 iptables 的關係是:
萬一 attacker 真的矇到 MSS, 那麼, 在 iptables 並不會看到 syn 封包
如果 Router/分享器, ... 沒有考慮到, 那麼 attacker 就有可能在不被發
現的情況下, 建立連線( iptables rules passed )
5. 不確定瞭不瞭解 iptables 底層實作的人, 我的建議是, 不要開 syn cookies 自找麻煩
其實只要有作到state inspection的FW應該不至於這麼容易被愚弄就是了,怕就怕只作單純的packet filter時的確會有此類風險,不過鵝個人也沒真的試過syn cookies有哪些好處/壞處,或許原發文者可以試過再把心得貼上來 ....不過原發文者提過他的機器有對別的機器作port scan的狀況(八成是被放後門/木馬了),鵝還是建議他好好check一下自己的機器,免得哪天發生不測再來跳腳可能就來不及了 ....
回覆
拉登長官

原樓主應該先看看被攻擊的時候(apache) 究竟都是些什麼樣的封包
先搞清楚是被攻擊還是發動攻擊 造成速度慢

netstat -anp | egrep -i http | less -Si
用 netstat/less 指令, 把 http 的相關封包/連線狀態列出來
如果發現大量的 SYN_RECV, 則是 Apache 被攻擊, 或者是主機速度不夠快
或者是 Apache 設定沒調整過, 無法承受大量的連線

如果是 SYN_SENT, 那就是 Apache 一直在對外發出連線請求
那就可以猜大概是被植入木馬, 或是 forum 有 bug 被整

-=-=-=-=-=-=-=-=-= 我是分格線 -=-=-=-=-=-=-=-=-=
基本上 Linux Kernel 應該改成 per-socket basis 的沒錯, 可是他沒作
另外一點是, syn flooding 是被攻擊, 能做的大概就是回頭去追來源
另外一個就是盡可能的減低系統 CPU/記憶體的損耗量

通常, 要 syn flooding, 攻擊方會發出 invalid src ip, 這樣 Linux Kernel
收到之後, 回一個 syn-ack, 也不會有人收到

如果攻擊方假造 Yahoo(202.43.195.13) IP 為來源, 那麼受攻擊方回應 syn-ack
給 Yahoo 時, Yahoo 便會回應一個 TCP RST 封包, 這樣受攻擊方, 便會將
原先的 syn semi 120 秒的等待結束掉
此時, 他可以利用一個 syn 封包, 同時攻擊 Yahoo & 原受攻擊電腦
只是, 當 Yahoo 發現, 受攻擊方一直發送 syn-ack 時, 也將被 Yahoo ban 掉

因此, 大部份的 syn flood, 假造的都是不存在的 IP, 這樣就可以拖垮受攻擊端的資源

所以, 受攻擊端可以做的事:
1. 把連線分成兩類, 一個是 established, 成功連線, 另一種則是 syn semi
這樣, 能夠成功建立連線的, 只要直接 pass 就可以了, 但是當我收到那種非法 IP
送過來的 syn 封包, 則可以強制關掉, 不須要等待 120 秒

2. 調整 Linux Kernel 裡, TCP/IP syn semi 等待的時間, 就算從 120 -> 60, 那樣也
省了一半的記憶體損耗

不過, 第一點必須親自寫程式, Linux 並沒有做這件事情, 2. 只要去改幾行程式就可以做到, 千萬別用 iptables 下去檔 syn flood, 那是沒用的, 心理作用而已
就算你 iptables ... -j DROP, CPU 照樣損耗, 120 秒照等不誤

此外, 有些分享器, .. 可能會設計成, 由 "SYN" 封包建立的連線, 才過 Firewall, ...
這樣其實, 也還好, 因為不開 syn cookies, 的確是如此沒錯

而且沒必要每個封包都進去 Firewall 做無謂的事情(做第二次的判斷)
這也就是為什麼, 有些分享器, 我設定了 18:00~08:00 是不可以建立某連線
可是一旦, 使用者在這段時間之外, 就已經建好了連線,
18:00~08:00 那原連線也不會被關掉的原因

此外, Log 的紀錄機制, 也可能連帶的放在 Firewall 相關 rules 上, 所以一旦不過 Firewall
就可能看不到某些 Log

試想, 使用者接了一台 Windows 到 DMZ 上, 並有真實 IP, 並在分享器上只開 Port 80
攻擊者試著用 ack(MSS) 攻擊他的 TCP 138/139, ... 因為並沒有產生 SYN 封包
所以那樣設計的分享器, Firewall 也沒被檢查, 等到攻擊者猜到時, 就糟了(沒紀錄, 怎死的都不知道)
回覆
會員

引用:
作者: dou0228
原樓主應該先看看被攻擊的時候(apache) 究竟都是些什麼樣的封包
先搞清楚是被攻擊還是發動攻擊 造成速度慢

netstat -anp | egrep -i http | less -Si
用 netstat/less 指令, 把 http 的相關封包/連線狀態列出來
如果發現大量的 SYN_RECV, 則是 Apache 被攻擊, 或者是主機速度不夠快
或者是 Apache 設定沒調整過, 無法承受大量的連線

如果是 SYN_SENT, 那就是 Apache 一直在對外發出連線請求
那就可以猜大概是被植入木馬, 或是 forum 有 bug 被整
另外一種狀況可能是一般Web server上會有很多小的http object,要是httpd沒開keep alive的話browser可能會在短時間開大批connection過來(跟html的寫法也有關....BTW,更糟的是某些OS對關connection的處理並不正確,要是server端的fin wait timeout過長的話還會在server端留下大量"semi close"的zombie,鵝就看過有某些OS fin wait有高達2hr的,當然會被那些先天不良的client搞死了 ),server光忙著應付開/關connection就夠瞧了 ....

引用:
作者: dou0228
基本上 Linux Kernel 應該改成 per-socket basis 的沒錯, 可是他沒作
另外一點是, syn flooding 是被攻擊, 能做的大概就是回頭去追來源
即然是spoofed src,去trace其所"宣稱"的src是沒有太大的意義,除非ISP在Ingress端check到有src IP與實際assign給user不同時就送trap,不過這麼作不如直接將其DROP掉 ....

引用:
作者: dou0228
另外一個就是盡可能的減低系統 CPU/記憶體的損耗量

snipped....

因此, 大部份的 syn flood, 假造的都是不存在的 IP, 這樣就可以拖垮受攻擊端的資源

所以, 受攻擊端可以做的事:
1. 把連線分成兩類, 一個是 established, 成功連線, 另一種則是 syn semi
這樣, 能夠成功建立連線的, 只要直接 pass 就可以了, 但是當我收到那種非法 IP
送過來的 syn 封包, 則可以強制關掉, 不須要等待 120 秒
同樣是因為spoofed src,接收端實際上是無從判斷起的(大概不會有攻擊者豬頭到拿private IP或calss D這類不該出現在public internet上的IP當source吧 ),恐怕只有ISP在Ingress端確實檢查src IP的有效性才是治本之道....

引用:
作者: dou0228
2. 調整 Linux Kernel 裡, TCP/IP syn semi 等待的時間, 就算從 120 -> 60, 那樣也
省了一半的記憶體損耗

不過, 第一點必須親自寫程式, Linux 並沒有做這件事情, 2. 只要去改幾行程式就可以做到, 千萬別用 iptables 下去檔 syn flood, 那是沒用的, 心理作用而已
就算你 iptables ... -j DROP, CPU 照樣損耗, 120 秒照等不誤

此外, 有些分享器, .. 可能會設計成, 由 "SYN" 封包建立的連線, 才過 Firewall, ...
這樣其實, 也還好, 因為不開 syn cookies, 的確是如此沒錯

而且沒必要每個封包都進去 Firewall 做無謂的事情(做第二次的判斷)
這也就是為什麼, 有些分享器, 我設定了 18:00~08:00 是不可以建立某連線
可是一旦, 使用者在這段時間之外, 就已經建好了連線,
18:00~08:00 那原連線也不會被關掉的原因

此外, Log 的紀錄機制, 也可能連帶的放在 Firewall 相關 rules 上, 所以一旦不過 Firewall
就可能看不到某些 Log

試想, 使用者接了一台 Windows 到 DMZ 上, 並有真實 IP, 並在分享器上只開 Port 80
攻擊者試著用 ack(MSS) 攻擊他的 TCP 138/139, ... 因為並沒有產生 SYN 封包
所以那樣設計的分享器, Firewall 也沒被檢查, 等到攻擊者猜到時, 就糟了(沒紀錄, 怎死的都不知道)
其實這個問題的根源還是firewall/Web server的config,鵝對TCP/IP的瞭解不算精通,但鵝就看過有些比鵝還搞不清楚TCP/IP是啥的人也在賣firewall,真是有點 ....不過以鵝看過的case,會被動到spoofed src DoS的site通常都是很大的目標(這類site通常會有專職的CSO....BTW,一般小毛頭玩不出這種花樣,大ㄎㄚ者也不至於隨便出手 ),或許問題並不像我們複雜吧....

回覆







 XML   RSS 2.0   RSS 
本站使用 vBulletin 合法版權程式
站務信箱 : [email protected]

本論壇所有文章僅代表留言者個人意見,並不代表本站之立場,討論區以「即時留言」方式運作,故無法完全監察所有即時留言,若您發現文章可能有異議,請 email :[email protected] 處理。