明誠科技小峰 | 檢單一點說,如果你前端沒有其他OS的防火牆,只要我ㄧ直丟TCP的SYN給你,就可以讓你的主機服務停擺,因為CPU資源會吃完. 因為LINUX目前2.4.*的核心就是有這個漏洞,除非更換2.6的核心,不過還沒有STABLE版.不要以為設定好IPTABLE然後漏洞PATCH一下就夠了,公開的作業系統仍舊有很多安全上的問題。包含WIN平台也是一樣的. |
回覆 |
會員 | 引用:
| |
回覆 |
拉登長官 | 引用:
在 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的東西,更不用講一些較早安裝系統,且重來沒有補過架站套件的人.身為管主機的資訊人員,經常的逛逛駭客網站和資安網站實在是很有必要的. |
回覆 |
會員 | 引用:
PS:其實在座各位恐怕都離題了,以鵝個人觀點,原發文者最該作的是好好check一下自己的機器(看一下Apache/PHP等等是不是有可以被利用的bug,/tmp或/var/tmp堶惘釣S有不該出現的東東 ) ,是不是被放了啥後門,成了DDoS的跳板,或許其機器的loading根本是由攻擊別人而來,而非被別人攻擊 .... | |
回覆 |
拉登長官 | 引用:
有可能在遭受到大量封包湧入時, 造成無法回應的情形, 連 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 自找麻煩 | |
回覆 |
會員 | 引用:
引用:
引用:
引用:
| ||||
回覆 |
拉登長官 | 原樓主應該先看看被攻擊的時候(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 也沒被檢查, 等到攻擊者猜到時, 就糟了(沒紀錄, 怎死的都不知道) |
回覆 |
會員 | 引用:
引用:
引用:
引用:
| ||||
回覆 |
XML | RSS 2.0 | RSS |
本論壇所有文章僅代表留言者個人意見,並不代表本站之立場,討論區以「即時留言」方式運作,故無法完全監察所有即時留言,若您發現文章可能有異議,請 email :[email protected] 處理。