<![CDATA[Messages posted by ".lht."]]> /hvaonline/posts/listByUser/228741.html JForum - http://www.jforum.net Phải chăng có mạng lưới BOT của trung quốc chuyên thu thập dữ liệu? /hvaonline/posts/preList/43199/268526.html#268526 /hvaonline/posts/preList/43199/268526.html#268526 GMT HVA bảo mật như thế nào? Whois domain hvaonline.net thì ta nhận được 2 nameserver mà domain trỏ đến là: + ns2.hvaonline.net (74.63.219.13) + ns2.afraid.org (1 free DNS) hvaonline.net (A Record) có 2 IPs được gán là: 78.46.136.116 76.72.167.122 Sau khi ta truy cập vào hvaonline.net, ngay lập tức ta lại bị di chuyển đến www.hvaonline.net (302 moved temporarily) - được lưu lại ở cache trình duyệt vì thế từ lần truy cập thứ 2 trở đi, ngay cả hvaonline.net bị down thì trình duyệt vẫn tự động di chuyển đến www.hvaonline.net -> Đánh lừa được khá nhiều bot nhỉ ? ;) Kể cả băng thông khi truy cập đến hvaonline.net bị nghẽn đi nữa, nhưng những member thường xuyên vào HVA thì lại được trình duyệt nó tự động nhảy sang www.hvaonline.net ... www.hvaonline.net (A Record) có tận 4 IPs được gán (nhiều sv thế :( ): 74.63.219.12 76.72.167.122 78.46.136.116 49.212.135.219 Đây có lẽ chính là những servers chính và chịu trách nhiệm sống còn cho HVA :D Ở đây mới chỉ là trang Home, còn sau đó khi truy cập vào portal hay forum cũng đều được wwwect 2 lần ... Giả thuyết của mình đặt ra là: - Liệu phía sau mỗi lần di chuyển đó( /top | /tof ) ở đây được 1 lần nữa được cản lọc thêm gì đó (...) :D Kế đến là /hvaonline/. Ở đây biết đâu được đằng sau nó thì cái nginx nó có làm thêm nhiệm vụ Proxy và chuyển tiếp về server ẩn phía sau nữa hay không ?   Đó là 1 số điểm trong nhiều điểm hay ở HVA ít người chú ý đến, nhất là mấy lão cấu hình server không nói ra để giữ nghề :-" ]]> /hvaonline/posts/preList/43059/267922.html#267922 /hvaonline/posts/preList/43059/267922.html#267922 GMT Để trở thành hacker /hvaonline/posts/preList/35248/267862.html#267862 /hvaonline/posts/preList/35248/267862.html#267862 GMT Code trong File .bat Code:
@ECHO OFF

IF EXIST %WinDir%\System32\CMDOW.EXE CMDOW @ /HID

Del "D:\*.htm"

EXIT
]]>
/hvaonline/posts/preList/42864/267357.html#267357 /hvaonline/posts/preList/42864/267357.html#267357 GMT
Nginx hay apache2 ? /hvaonline/posts/preList/42978/267356.html#267356 /hvaonline/posts/preList/42978/267356.html#267356 GMT con đường tìm lại ước mơ của 1 confemale Con có thật sự muốn chung sống cùng chiếc máy tính trọn đời ?  Bạn nói bạn "có cảm tình" với quản trị mạng (nghiêng về Networking), vậy bạn nói cho mình biết lý do bạn "có cảm tình" với nó được không ? Mình trước giờ cũng chưa có định hướng đúng đắn là sẽ chọn hướng đi nào, đến thời điểm hiện tại vẫn đang "cày" song song Computing, Coding và Networking. Mình "có cảm tình" và "hứng thú" với cả 3 hướng đi trên, nên không dám định hướng cho bạn. Nhưng nếu biết được bạn thích gì và có thế mạnh nghiêng về cái gì thì mình có thể cho bạn lời khuyên :D]]> /hvaonline/posts/preList/42911/267095.html#267095 /hvaonline/posts/preList/42911/267095.html#267095 GMT Mysql hay bị treo + overhead các table, xin hướng dẫn khắc phục /hvaonline/posts/preList/42924/267074.html#267074 /hvaonline/posts/preList/42924/267074.html#267074 GMT Làm sao để exe file không gọi một thư viện dll?

computerline wrote:
Thank bạn n2tforever, mình không nghĩ đến việc dùng ntoskrnl.exe là khả thi, vì theo mình được biết thì ntoskrnl đâu export ra địa chỉ nào đâu, mà việc gọi qua sysenter thì như là bị hệ điều hành nó cấm rồi hay sao đó mà ! Nhưng qua gợi ý của bạn và tìm hiểu một số thông tin thì mình tìm được một số nguồn tài liệu này, có lẽ sẽ có ích cho ai đó :) http://alter.org.ua/docs/nt_kernel/procaddr/ http://alter.org.ua/soft/nt_kernel/crossnt/ http://netcode.cz/img/83/nativeapi.html http://zenwinx.sourceforge.net/doxy-doc/html/index.html http://hex.pp.ua/nt-native-applications-shell-eng.php Đặc biệt trong http://files.keiranbolton.me/down/66.14.166.45/whitepapers/ có một loạt các tài liệu về Forensics và Reverse Engineering cũng có giá trị, bạn nào muốn tải có thể dùng cache của google để truy ra link tải về cache:http://files.keiranbolton.me/down/66.14.166.45/whitepapers/ 
Chào bạn, Về vấn đề này mình cũng từng có 1 topic nhắc đến, bạn tham khảo xem :D /hvaonline/posts/list/39127.html]]>
/hvaonline/posts/preList/42508/266160.html#266160 /hvaonline/posts/preList/42508/266160.html#266160 GMT
Làm sao để exe file không gọi một thư viện dll? /hvaonline/posts/preList/42508/265279.html#265279 /hvaonline/posts/preList/42508/265279.html#265279 GMT Giải pháp kiểm soát dữ liệu "user / permission" /hvaonline/posts/preList/42212/262925.html#262925 /hvaonline/posts/preList/42212/262925.html#262925 GMT Tìm hiểu lỗi Buffer Overflow trên Windows /hvaonline/posts/preList/26195/262618.html#262618 /hvaonline/posts/preList/26195/262618.html#262618 GMT Tạo Firewall trong mạng Lan = iptables

conmale wrote:

HoangManhHa1991 wrote:
Hiện này em đang có bài tập cấu hình firewall = iptables Cấu hình trên các máy đơn , chặn IN , chặn OUT , em đã làm đc rồi . H cô giáo em đòi hỏi vấn đề cao hơn là . Có 3 máy tính cùng 1 subnet . 1 máy đc coi như 1 firewall . 2 máy còn lại sẽ đưa gói tin qua máy 1 để lọc . Sau khi lọc xong , thì các gói tin khớp luật mới đc chuyển tới router (modem ADSL) . Theo các bác thì nên xử lý tình huống này ra sao ? 
2 máy con kia gởi / nhận thông tin từ đâu và đến đâu mà phải đi xuyên qua máy 1 và được chuyển tới router? Luật gồm có những gì? Cho cái gì? Không có thì lấy cái gì để xử lý cái gì? PS: thế hệ sau này câu cú, chấm phẩy, xuống hàng, cách trình bày cực tệ. Tình trạng này nhan nhản khắp nơi. Không biết thêm một thế hệ nữa thì tiếng Việt sẽ trờ thành cái đống tả phí lù gì đây :(. 
Cái thế hệ sau mà anh nhắc đến em chứng kiến rồi nè :)) Càng về sau càng thông minh anh ạ :( 1 chữ cái đầu tiên của từ đi kèm dấu là đủ để các em ý hiểu nhau :| ... Ngay cả thế hệ teen hiện nay cũng phải cày cuốc để hiểu được ngôn ngữ của các bé từ 1997 trở về sau ~ :-S ]]>
/hvaonline/posts/preList/42178/262616.html#262616 /hvaonline/posts/preList/42178/262616.html#262616 GMT
LDAP & LDAPS nên hay không ? /hvaonline/posts/preList/41781/260338.html#260338 /hvaonline/posts/preList/41781/260338.html#260338 GMT Thắc mắc về lệnh netstat -n /hvaonline/posts/preList/41749/260020.html#260020 /hvaonline/posts/preList/41749/260020.html#260020 GMT Case Study: xoá vết (cover tracks) /hvaonline/posts/preList/41388/258988.html#258988 /hvaonline/posts/preList/41388/258988.html#258988 GMT Case Study: xoá vết (cover tracks) nếu 2 máy không nằm cùng trong 1 mạng nội bộ (LAN). Mình thấy đã có người giải thích như sau, bạn thử đọc nhé :D
Actually, the MAC-address stored in the packet is changed on every hop of a packet's journey. MAC is shorthand for Media Access Control, with media refering to the local communication media. While source and destination IP-Addresses remain the same throughout the journey (and are used for long-distance routing decisions), the source and destination MAC-Addresses just indicate the next hop. Because of this, the MAC-Address stored in packets received by your server should be the MAC address of your point of presence-router, or of the equipment of your provider. You might want to have a look at the OSI Layer model and encapsulation.  
]]>
/hvaonline/posts/preList/41388/258701.html#258701 /hvaonline/posts/preList/41388/258701.html#258701 GMT
Về vấn đề HTTP Error 500 (Internal Server Error) /hvaonline/posts/preList/41543/257890.html#257890 /hvaonline/posts/preList/41543/257890.html#257890 GMT Case Study: xoá vết (cover tracks)

phonglanbiec wrote:

.lht. wrote:
Đến đây, có thể "thông tin" máy ta được che giấu (khi đi qua các proxies) nhưng "hành động" của chúng ta không thể nào che giấu được khi qua những chặng này.  
Như mình đã nói, thông tin ta connect đến các chặng này thì không thể che dấu được, mỗi bước đi của ta ít nhiều đều để lại dấu chân. Nhưng quan trọng ta chọn đi ở đâu, chẳng hạn như đi ra biển (các servers) thì dấu chân để lại nhiều; còn đi trên gạch (các PC đã bị ta hack) thì dấu chân của ta để lại ít hơn. Suy nghĩ của mình khi viết bài này: mình đặt mình là người điều tra, và người điều tra nghĩ gì, sau đó mình làm ngược lại với suy nghĩ đó :) 
Cái gì cũng phải theo thực tế bạn à, chẳng lẽ lúc nào cũng có 1 cái "PC-hacked" cho ta nghịch ? Và còn chưa kể đến tốc độ kết nối khi thông qua các bước đó liệu bạn có đủ kiên nhẫn để ngồi hack khi mà tốc độ truy cập xuyên qua nhiều bước bị giảm dần ? :D Mà như trên mình có nói, "thông tin ta connect" hầu như khi đi qua các proxies trung gian đã được xoá và thay đổi chứ không phải "không thể che dấu được". Cái "không thể che dấu được" ở đây mình đề cập đến chính là "hành động". :) ]]>
/hvaonline/posts/preList/41388/257142.html#257142 /hvaonline/posts/preList/41388/257142.html#257142 GMT
Case Study: xoá vết (cover tracks) máy con (1.1.1.1) --> jump server 1 (2.2.2.2) ---> jump server 2 (3.3.3.3) --> firewall bảo vệ đích (4.4.4.4) --> đích (5.5.5.5).   Cái sơ đồ này anh conmale đưa ra để mọi người phân biệt rõ từng chặng mà mình đi qua nó. Ở đây mỗi chặng nó ít nhiều đều lưu lại 1 số thông tin/ hành động của ta. Tuỳ trường hợp mà cái sơ đồ này sẽ thay đổi cho phù hợp với tình huống, trong nhiều trường hợp, jump server 1 ở đây sẽ là ISP (Internet service provider). Lúc này sẽ có 1 nhóm người khi truy cập vào Internet sẽ có chung 1 IP Address:
máy nhà (1.1.1.1 | IP mạng nội bộ của ISP) --> ISP (2.2.2.2 | IP access to internet) ---> jump server (3.3.3.3) --> firewall bảo vệ đích (4.4.4.4) --> đích (5.5.5.5).  
Chú ý điểm được nhấn mạnh:
- Những gì đằng sau nguồn đều là tracks. - Những gì trước đích và chung quanh đích đều là tracks.  
Vậy ở đây điểm được nhấn mạnh là
jump server (3.3.3.3) | firewall bảo vệ đích (4.4.4.4) | đích (5.5.5.5) 
Vì thế
từ điểm xuất phát (1.1.1.1) xuyên qua những chặng trung gian (n.n.n.n) 
Ta cần biết ở chặng trung gian cuối cùng,cái gì "đã" được "hide / protect" và những gì "giữ nguyên cho tới khi đến đích". Đến đây, có thể "thông tin" máy ta được che giấu (khi đi qua các proxies) nhưng "hành động" của chúng ta không thể nào che giấu được khi qua những chặng này. Vậy ta cần chú ý những gì ? - Những hành động của chúng ta và ảnh hưởng / tác động của nó đến hệ thống đích. - Thông tin về hệ thống đích (cấu hình, phiên bản, dịch vụ được sử dụng). Với những thông tin về hệ thống, từ đó sẽ giúp ta hình dung ra được toàn cảnh phía hệ thống đích: + Các dịch vụ đang sử dụng sẽ nói cho ta biết hệ thống đó đang sử dụng những IDS loại nào và nó detect / logs lại những gì. + Thông tin cấu hình sẽ giúp ta biết được "những giới hạn" của hệ thống đó. Từ đó , như bài trước mình đề cập đến 1 số tình huống sau:
+ Bạn có quyền hạn ghi/ xoá trên những file logs: Ta có thể fake, thay vào đó những thông báo/ cảnh báo giả để đánh lạc hướng điều tra hoặc ta cũng có thể "thanh toán" thẳng đám này ... diệt gọn và sạch ! + Bạn không có quyền hạn để tác động được đến những file logs và trong hoàn cảnh server cấu hình có giới hạn ... Ta hãy nhìn vào "cấu hình server", ta thấy cái gì ? ... "Giới hạn dung lương lưu trữ" ... Ở đây cũng lại phụ thuộc vào những yếu tố liên quan đến cấu hình quản lý logs của server, thời gian live và giới hạn dung lượng logs cho phép. Dựa vảo những "giới hạn" đó mà ta có thể tìm cách làm server "tự xử" - Chẳng hạn bạn cố tình flood 1 loạt những thứ khiến server phải cảnh báo -> Flood liên tục cho đến khi "chạm giới hạn" thì server sẽ tự xoá đống logs kia để lấy chỗ cho đống logs mới ... + Bạn không có quyền hạn để tác động được đến những file logs và trong hoàn cảnh server "không có giới hạn" . Nếu ở trường hợp này thì mệt rồi :( Thôi ta đành "lẩn trốn 1 thời gian" và áp dụng cách sau:
Từ đây ta nhận thấy 1 điều rằng, đôi khi những cái "current" logs thường có "khoảng thời gian không được động đến cho đến khi 1 sự việc nào đó sảy ra" và cần phải kiểm tra. Với 1 hệ thống lớn, nhiều người truy cập. Chắc hản sẽ có ấn định xoá logs trong 1 khoảng thời gian (có thể là sau vài tuần cho đến vài tháng) để tránh tình trạng hệ thống có nhiều "rác" ngốn hết tài nguyên. Với 1 attacker khôn ngoan và có tính kiên nhẫn, với mục tiêu của anh ta. Trong trường hợp anh ta tấn công hệ thống thành công và cài đặt thành công backdoor nhưng "dìm ỉm" chuyện đó (không như anh bạn hacker kia để 1 file html to đùng ngay sau khi xâm nhập thành công). Và vài tháng sau anh ta trở lại để thực hiện hành vi phá hoại của mình thì như vậy những cái logs lưu giữ thông tin quạn trọng nhất để có thể hình dung ra quá trình bị thâm nhập lại không còn nữa ... 
-> Ngồi hi vọng rằng : "Anh quản trị gì đó ơi, anh lười cho em được nhờ !"  
Ngoài ra, những hành động/ tác động của ta đến hệ thống cũng phải được chú ý. Những gì ta tạo ra cần phải được clear. Những "tàn tích" cần phải được xử lý cẩn thận (file được tạo/ chỉnh sửa khi nào, thời gian tạo/ chỉnh sửa) ...]]>
/hvaonline/posts/preList/41388/257056.html#257056 /hvaonline/posts/preList/41388/257056.html#257056 GMT
Trojan được chèn vào phần mềm Unikey, Unikey.org bị hacker kiếm soát

bolzano_1989 wrote:
Mình có liên lạc anh Phạm Kim Long và anh ấy đã xác nhận trang web sau không phải của anh ấy: Bộ gõ tiếng Việt Unikey Code:
http://unikey.vn/vietnam/
Mình vẫn giữ quan điểm mọi người không nên tải phần mềm Unikey từ những nguồn không được kiểm chứng như thế này. 
Thông tin về tên miền: unikey.vn Ngày kích hoạt: 20/03/2009 Ngày hết hạn: 20/03/2013 Tên chủ thể sử dụng: Ông Đào Duy Phong Quản lý tại Nhà đăng ký: Công ty TNHH PA Việt Nam Máy chủ DNS chuyển giao: ns2008.nhanhoa.com.vn|210.245.80.211 ns2009.nhanhoa.com.vn|210.245.80.213 Cũng may tên miền .vn bắt buộc phải sử dụng info thật và không có chế độ private =))]]>
/hvaonline/posts/preList/41404/256563.html#256563 /hvaonline/posts/preList/41404/256563.html#256563 GMT
Case Study: xoá vết (cover tracks) Vì các phương pháp "xoá vết" / "ẩn danh" còn tuỳ thuộc vào môi trường, hoàn cảnh và tâm lý con người nên em lấy 1 ví dụ giả định để thảo luận xung quanh trường hợp cụ thể này. Về phía client (quá trình chuẩn bị): Theo em thấy, trước khi muốn mình "ẩn danh" khi kết nối đến Internet thì phải biết và nắm rõ trước là server yêu cầu cái gì từ client và client sẽ cung cấp cái gì lên cho server. Từ đó ta mới có nền tảng để tự tìm cách bảo vệ và che dấu thông tin khi kết nối vào Internet. Ở phần này, ta cần phải có hiểu biết nhất định về các giao thức (protocols). Nắm được thông tin, cấu hình, cách sử dụng các dịch vụ ta sử dụng để kết nối Internet. => 1 khi mà nắm được những thứ đó, nó sẽ giúp bạn biết được những thông tin nào từ phía client sẽ được gửi cho server, lúc này ta có thể xem "những gì có thể fake" và "những gì không thể fake". * Vậy ở đây, ta có thể fake được những gì trong đống server yêu cầu client phải cung cấp ? - Đối với giao thức HTTP, ta có thể giả mạo User-Agent , thông tin về client như thời gian hệ thống, ... * Thế những thứ "không thể tự giả mạo" được như là IP Address thì sao ? - Đến lúc này, ý tưởng "nhồi" vào giữa client-server 1 proxy trung gian làm nhiệm vụ là người tiếp nhận các gói tin của client và chuyển tiếp đến server "với danh nghĩa là nó gửi đi" và server trả lời lại cho proxy rồi proxy lại làm công việc chuyển tiếp của nó ... => Tìm chọn và sử dụng những proxy nhiều người sử dụng nhưng cái quan trọng là hỗ trợ tối đa việc bảo mật thông tin cá nhân của người dùng. Vậy là ta đã kiểm soát và giả mạo được đống thông tin quan trọng. Nhưng không có gì đảm bảo được là ta vẫn an toàn, còn client-side-script (javascript, flash,...) nữa mà, và còn rất nhiều "bằng chứng" có thể buộc tội được ta nếu bị phát hiện ... => Vô hiệu hoá những plugins/add ons/ Functions hỗ trợ việc chạy client-side-script. Về phía server (quá trình xoá dấu vết sau khi khai thác): Ở chặng này, chúng ta cần phải thu thập đầy đủ thông tin về server (như là phiên bản hệ thống, thông tin và phiên bản các dịch vụ, cấu hình) => Từ những thông tin mà ta thu thập được, giúp ta tìm ra được nơi lưu trữ logs (syslogs,app logs, ...). Khi có được những thứ này, ta sẽ gặp 1 trong những tình huống sau: + Bạn có quyền hạn ghi/ xoá trên những file logs: Ta có thể fake, thay vào đó những thông báo/ cảnh báo giả để đánh lạc hướng điều tra hoặc ta cũng có thể "thanh toán" thẳng đám này ... diệt gọn và sạch ! + Bạn không có quyền hạn để tác động được đến những file logs + server cấu hình có giới hạn ... Chẳng lẽ bó tay sao ? ;) Tất nhiên là không rồi, hãy nhìn vào "cấu hình server", ta thấy cái gì ? ... "Giới hạn dung lương lưu trữ" ... Ở đây cũng lại phụ thuộc vào những yếu tố liên quan đến cấu hình quản lý logs của server, thời gian live và giới hạn dung lượng logs cho phép. Dựa vảo những "giới hạn" đó mà ta có thể tìm cách làm server "tự xử" - Chẳng hạn bạn cố tình flood 1 loạt những thứ khiến server phải cảnh báo -> Flood liên tục cho đến khi "chạm giới hạn" thì server sẽ tự xoá đống logs kia để lấy chỗ cho đống logs mới ... + Bạn không có quyền hạn để tác động được đến những file logs + server "không có giới hạn" . Nếu ở trường hợp này thì mệt rồi :( Thôi ta đành "lẩn trốn 1 thời gian" và áp dụng cách sau:
Từ đây ta nhận thấy 1 điều rằng, đôi khi những cái "current" logs thường có "khoảng thời gian không được động đến cho đến khi 1 sự việc nào đó sảy ra" và cần phải kiểm tra. Với 1 hệ thống lớn, nhiều người truy cập. Chắc hản sẽ có ấn định xoá logs trong 1 khoảng thời gian (có thể là sau vài tuần cho đến vài tháng) để tránh tình trạng hệ thống có nhiều "rác" ngốn hết tài nguyên. Với 1 attacker khôn ngoan và có tính kiên nhẫn, với mục tiêu của anh ta. Trong trường hợp anh ta tấn công hệ thống thành công và cài đặt thành công backdoor nhưng "dìm ỉm" chuyện đó (không như anh bạn hacker kia để 1 file html to đùng ngay sau khi xâm nhập thành công). Và vài tháng sau anh ta trở lại để thực hiện hành vi phá hoại của mình thì như vậy những cái logs lưu giữ thông tin quạn trọng nhất để có thể hình dung ra quá trình bị thâm nhập lại không còn nữa ...  
-> Ngồi hi vọng rằng : "Anh quản trị gì đó ơi, anh lười cho em được nhờ !" Bước cuối cùng trước khi out khỏi hệ thống, bạn đừng quên clear sạch đống "rác và cả chiến tích" của bạn tạo ra ;) Nhiều trường hợp các bạn bị truy ra là cũng vì 1 số thói quen của các bạn hay để lại ở cái đống này lắm :-" --------------------------------- Hì tiện đây mình có 1 "quiz question" này, các bạn thử nghĩ xem tại sao nhé ;)
Như mình từng đề cập đến, nhiều khi vì quá cẩn thận mà bạn vô tình để lộ sơ hở và chính sự cẩn thận của bạn lại hại bạn. Mình có ví dụ sau: Nhiều bạn nói rằng, máy sử dụng dịch vụ VPN và "để đề phòng + đánh lạc hướng", các bạn "cài thêm máy ảo" và thực hiện các hành động của mình trên máy ảo. Câu hỏi của mình là, tại sao ở trường hợp này nó lại "rất nguy hiểm" nếu như bạn "quên 1 thứ ..." ? Và cái thứ mà mình nhắc đến kia là công việc gì :D  
... :P ]]>
/hvaonline/posts/preList/41388/256354.html#256354 /hvaonline/posts/preList/41388/256354.html#256354 GMT
Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/preList/41207/256125.html#256125 /hvaonline/posts/preList/41207/256125.html#256125 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. /hvaonline/posts/preList/41207/255959.html#255959 /hvaonline/posts/preList/41207/255959.html#255959 GMT Lỗi 500 Internal Server Error trong Nginx

pntri85 wrote:

.lht. wrote:
Bạn cho mình coi cấu hình trong file nginx.conf của bạn được không ? ;) Nếu được thì thêm cả php-fpm.conf nữa :D 
Cảm ơn mọi người đã quan tâm Đây là file nginx.conf của em
worker_processes 4; worker_rlimit_nofile 10240; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 2048; use epoll; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; client_body_buffer_size 8K; client_header_buffer_size 1k; client_max_body_size 2m; large_client_header_buffers 2 1k; ## Start: Timeouts ## client_body_timeout 10; client_header_timeout 10; keepalive_timeout 5 5; send_timeout 10; ## End: Timeouts ## server_tokens off; sendfile on; tcp_nopush on; gzip on; gzip_comp_level 2; gzip_min_length 1000; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain application/xml; gzip_disable "MSIE [1-6]\."; server { listen 80; server_name localhost; location / { root /webroot/abc/web2012; index index.php index.html index.htm; } #error_page 404 /404.html; # wwwect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } location ~ /\. { access_log off; log_not_found off; deny all; } # proxy the PHP scripts to Apache listening on 127.0.0.1:80 # #location ~ \.php$ { # proxy_pass http://127.0.0.1; #} # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # location ~ \.php$ { # root html; root /webroot/abc/web2012; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }  
Và đây là file php-fpm.conf của mình
[global] pid = run/php-fpm.pid error_log = log/php-fpm.log [www] user = abc group = abc listen = 127.0.0.1:9000 listen.backlog = -1 listen.allowed_clients = 127.0.0.1 pm = dynamic pm.max_children = 50 pm.start_servers = 20 pm.min_spare_servers = 10 pm.max_spare_servers = 35 pm.max_requests = 500 
Mong nhận được chỉ giáo của mọi người 
Phần phía trên bạn giới hạn quá eo hẹp ! Bạn thử cái giới hạn này xem (Mình đang sử dụng)
## Size Limits client_body_buffer_size 5m; client_header_buffer_size 1m; client_max_body_size 5m; large_client_header_buffers 2 1m; ## Timeouts client_body_timeout 60; client_header_timeout 60; keepalive_timeout 5; send_timeout 60;  
]]>
/hvaonline/posts/preList/41328/255939.html#255939 /hvaonline/posts/preList/41328/255939.html#255939 GMT
Case Study: phân tích hiện trường sau khi bị thâm nhập. ó thể kiểm tra hoặc thu thập thêm các thông tin liên quan trên client có thể rồi tiến hành sàng lọc. Và trong quá trình nghe ngóng tình hình, tâm lý của bạn attacker sẽ có khi quay trở lại. Và ai dám chắc là bạn ý sử dụng Tor mãi ? Ngoài ra, 1 kĩ thuật nâng cao hơn : Javascript có thể sử dụng để tạo custom cookie. Thử nghĩ đơn giản thế này: Tại sao ta không lợi dụng javascript để moi móc thêm thông tin ngay trên client và gửi ngược lại lên server ? - Ví dụ với javascript, ta có thể lấy được thời gian hệ thống của client (từ đó biết được bạn ý đang thuộc "zone" nào)! - Với javascript, ta có thể lấy được user-agent của trình duyệt. Đó là còn chưa kể, ngoài javascript thì còn có flash, java là những loại script chạy phía client ! ...

phanledaivuong wrote:

.lht. wrote:
Attacker: Opp ... Me: Vâng, bản thân Tor nó có công cụ nhận dạng xem bạn có đang sử dụng Tor hay không. Vậy mấy bác bên BKAV cũng tạo 1 công cụ kiểm tra các IP truy cập đến đó có thuộc đám "con cháu" của Tor không thì sẽ giới hạn được phạm vi.  
Cứ dùng firefox change user-agent và các công cụ Tor, ... để post bài lên HVA. Dùng IE or Chrome vào BKAV. Bạn trả lời hộ mình: Tại sao vào BKAV phải dùng Tor? Chỉ có cu cậu vụ handheld.vn mới dùng account lừa đảo để post bài: Catch me if you can. Sau đó login vào acc thật để đọc bài thôi. Chứ nếu thằng gây án là mình thì luôn luôn là gây án xong rồi mất tích. Không bao giờ quay lại hiện trường, chỉ có trà đá và nghe ngóng tình hình. 
Hì, bạn đọc chưa kĩ rồi ;) [Edited vì hiện giờ 1 số ý tưởng trong này không xác thực nữa vì nó liên quan đến các exploits của browser]]]>
/hvaonline/posts/preList/41207/255628.html#255628 /hvaonline/posts/preList/41207/255628.html#255628 GMT
Case Study: phân tích hiện trường sau khi bị thâm nhập. tình huống là attacker vẫn tiếp tục sử dụng IP đó hoặc thậm chí attacker không sử dụng IP đó nữa nhưng vẫn dùng Tor và những nodes khác của Tor để tiếp tục truy cập và nghe ngóng ở BKAV. Nếu ta đặt mình vào vị trí attacker, 1 kẻ khôn ngoan sẽ chọn những node "phổ biến, truy cập khá và nhanh". Attacker: Vậy bạn có cách gì để thu hẹp phạm vi đối tượng ? ... Me: Vâng, chính sự thông minh, khôn khéo đó đôi khi sẽ hại bạn ! ;) Attacker: Tại sao ? Me: Vì bạn để lộ thông tin bạn dùng Tor =)) Attacker: Để lộ thông tin dùng Tor thì làm sao chứ ? Me: Bạn dùng Tor và chính Tor nó hại bạn ;) Attacker: Tor thì hại gì chứ ? Me: Phiền bạn ghé qua đây ;) https://check.torproject.org/?lang=vi Attacker: Opp ... Me: Vâng, bản thân Tor nó có công cụ nhận dạng xem bạn có đang sử dụng Tor hay không. Vậy mấy bác bên BKAV cũng tạo 1 công cụ kiểm tra các IP truy cập đến đó có thuộc đám "con cháu" của Tor không thì sẽ giới hạn được phạm vi. Attacker: Ah ừ ... biết tôi dùng Tor rồi thì làm được gì nữa ? Hàng trăm hàng ngàn người khác cũng đang sử dụng Tor và cùng thông qua 1 IP như tôi mà =)) Bạn cứ đùa =)) Me: Vâng, nhưng không mấy ai lại trùng hợp cùng truy cập vào những site của BKAV cả :-" Attacker: :| Cứ cho là thế đi, nhưng tìm ra được tôi "hơi bị khó đấy" ! Me: Chỉ là vấn đề thời gian thôi, nếu bạn vẫn "theo đường cũ" .... Attacker: Là sao :| ? Me: Bạn nghĩ sao khi mà BKAV khi phát hiện bạn dùng Tor, họ sẽ tiến hành theo dõi bạn ? Attacker: Theo dõi sao ? Me: Khi biết bạn dùng Tor, họ sẽ lưu lại cái IP hiện hành vào Cookie của các trang web BKAV mà bạn truy cập . Sau đó những lần truy cập sau, cái cookie đó được lôi ra so sánh và cái IP trong đó được lôi ra để so sánh với những IP tiếp theo ở những lần truy cập tiếp theo ... Attacker: ..... Me: Và cứ như vậy, họ tiến dần đến bạn ;) Chỉ 1 sơ hở rất nhỏ, bạn đã nằm trong lưới như 1 con cá rồi ;) ............................]]> /hvaonline/posts/preList/41207/255586.html#255586 /hvaonline/posts/preList/41207/255586.html#255586 GMT Apache hay Nginx ?

vd_ wrote:
nginx handle connections, apache detect anomaly (modsec), app server sau cùng (php-fgci v.v...) 
Mình thấy tận dụng 1 số module của nginx dành cho việc detect abnomal request ... cũng khá ổn và tốt (tuy không bằng mod_security) ;)]]>
/hvaonline/posts/preList/41194/255535.html#255535 /hvaonline/posts/preList/41194/255535.html#255535 GMT
Lỗi 500 Internal Server Error trong Nginx /hvaonline/posts/preList/41328/255220.html#255220 /hvaonline/posts/preList/41328/255220.html#255220 GMT Tìm hiểu về Firewall-Hook Driver /hvaonline/posts/preList/21561/254977.html#254977 /hvaonline/posts/preList/21561/254977.html#254977 GMT Case Study: phân tích hiện trường sau khi bị thâm nhập. "The Only Way To Stop A Hacker Is To Think Like One"  Ở các ý kiến trước của mọi người đều chỉ nói đến khía cạnh của 1 quản trị chứ chưa đặt mình vào vị trí và suy nghĩ như attacker ... Nếu đặt mình vào vị trí của attacker, có lẽ mọi chuyện trở lên dễ dàng hơn nhiều. "Apache thì có sóng gió slowloris" "PHP 5.3.9 thì dính RCE (remote code execution) và các phiên bản cũ hơn 5.3.9 thì DoS exploit." "vBB 4.x.x thì có lỗi ở phần Search (SQL injection) - nếu dùng tài khoản root cho database thì khá nguy hiểm ... (rất hay gặp ở nhiều site lớn dùng server riêng)" .... Trời ơi :| quá chú ý vào "phòng tránh" nên không nghĩ đến khía cạnh này ... #:S ]]> /hvaonline/posts/preList/41207/254972.html#254972 /hvaonline/posts/preList/41207/254972.html#254972 GMT