Messages posted by: vietwow

Theo mình biết khái niệm pipe trong linux là sự connect giữa 2 tiến trình (process) giúp các tiến trình có thể "giao tiếp" với nhau, vd :

ls | grep abc

thì chạy tiến trình ls rồi kết nối tiền trình ls với tiến trình grep để lấy output của lệnh ls đưa và input của lệnh grep

Tuy nhiên mình nghe 1 người bạn nói trong linux còn có 1 khái niệm pipe file khác với vd | trên, pipe file có chữ s nằm ở đầu thuộc tính (srwxrwxrwx) và có đặc tính là ko thể nào view được (mình thử cat, more.. đều ko được, nó báo là : cat: mysql.sock: No such device or address)

Vậy cho mình hỏi ý nghĩa của những file này để làm gì ? khi nào thì cần tạo ra nó ? tại sao nó lại ko thể view được ? nếu mình muốn tìm hiểu no chứa cái gì thì phải làm sao ?

Ai biết xin giúp, cám ơn

Mình sẽ không biết cho đến khi mình ping. Em đọc kỹ lại đi.

Đâu hẳn là chỉ có ping mới biết được đâu anh smilie

) em nghĩ chỉ cần nó có "giao tiếp" với máy khác là biết được gòi :wink:

mudzot wrote:

Không phải lúc nào tỉ lệ ARP cũng lên cao khi đang có arp poisoning, vì chỉ cần gửi gói arp reply định kỳ 30s đến 1 phút là đủ, không cần flood (hình như Cain&Abel có option này). Thực tế trong mạng LAN vài chục máy hoạt động bình thường thì tỉ lệ arp nhiều hơn thế.
Cái bất thường ở đây là không gửi arp request mà lại nhận đc reply. Vậy giải pháp để phát hiện mình có bị poisoned không là tự sniff mình xem có đều đặn nhận arp reply từ 1 máy nào đó không.
Giải pháp chung cho toàn mạng để phát hiện các "táy máy" về MAC/IP mà tớ dùng cũng chỉ là arpwatch thôi.

Thứ 1, ARP poisoning ít nhất là phải "phun" ít nhất là 1 gói ARP Relay với tốc độc 30s/packet (vì phải tấn công ít nhất là 1 máy chứ smilie

) ), mà chỉ cần tấn công với tốc độ vậy thì lượng ARP cũng đủ để thấy "bất thường" rồi, vì trên thực tế lượng ARP là khá ít do cơ chế ARP dùng cache nên đâu phải lúc nào nó cũng request.

Thứ 2 là tấn công ARP Poisoning hiếm khi nào attacker chỉ tấn công 1 ai đó, thường là họ poison cả network vì thế khả năng lượng ARP cao là thường xảy ra, còn việc chỉ nhận arp reply mà ko có request tuy là bất thường nhưng đều đó khó kiểm chứng, chả lẽ mỗi lần bạn ra dv hay ở cty đều phải bật sniff lên rồi ngồi phân tích mà ko làm gì khác à smilie

)

Tôi đặt trường hợp sau khi một attacker kết thúc quá trình sniff hệ thống LAN thì việc sniff của attacker này có để lại dấu vết gì không ?
Có cơ hội nào phát hiện +bằng chứng về việc hệ thống của mình bị sniff không ?

Theo như mình biết, nếu ngay sau khi attacker kết thúc quá trình tấn công (tức attacker ngưng "phun" ARP replay để poison) thì vẫn còn chút hy vọng để phát hiện đó là xem cache ARP của router, vì nếu chưa đến 30s thì cache vẫn chưa xoá , do đó cái cache bị đầu độc vẫn còn => MAC mà mình đầu độc chính là MAC của attacker. Còn nếu sau 1 khoảng thời gian mà ARP cache bị xoá thì mình pó tay, chưa tìm được giải pháp smilie

)

thangdiablo wrote:

Thanks anh em !
Tớ thấy một vấn đề nữa .
Mặc dù Web Server Cty tớ có hỗ trợ SSL .
Email Server thì có hỗ trợ SSL và SPA . Vậy mà khi tớ sniff thử thì vẫn thấy password toàn cleartext .
Tất nhiên tool của tớ có hỗ trợ ARP-HTTPS . Không lẽ SSL cũng thiếu an toàn đến vậy cơ à ?

SSL hoàn toàn có thể bị sniff (đã chứng minh trên thực tế) & kết quả sẽ là plain-text nhưng để thực hiện thì ko đơn giản lắm, phải biết kết hợp 1 số tool & sửa đổi 1 số thứ, vì thế tôi chưa tin lắm việc có 1 tool có thể sniff hầu hết SSLcủa các service, tôi nghĩ 1 là SSL công ty bạn config chưa chính xác 100%, 2 là dv SSL của software mà cty bạn xài khá phổ biến nên tool này được build sẵn việc Sniff

Nếu máy "kia" đã cài VNC rồi thì check bên "máy kia" xem port của VNC đã được mở chưa ? Nếu chưa thì có nhiều khả năng như máy đó có cài firewall hoặc do bạn setup/config VNC chưa chính xác nên cài rồi nhưng nó ko work. Nếu ok luôn thì check xem máy dùng để connect xem có firewall ko ?

thangdiablo wrote:

Giờ tôi thấy cách chống tạm thời đơn giản nhất chỉ có set arp static giữa máy tôi và defautgateway cảu Router.
Công ty tôi dùng hệ thống VoIP nên việc bị nghe lén rất dễ xảy ra . Nên sáng nào vào Công Ty công việc đầu tiên cũng là set static arp giữa PC của tôi và Router .

Nhưng có 1 vấn đề tôi vẫn thắc mắc là làm sao ? Dùng tool gì cụ thể và biểu hiện gì để mình có thể xác minh 1 arp là hợp lệ hay không hợp lệ .

Như tôi đã nói ở trên, nếu là qui mô cty và bạn có quyền đối với network trong cty đó thì bạn nên sử dụng các chương trình như ARP Watch hoặc những chương trình có chức năng tương tự. Còn các switch như bạn gamma95 nói thì nó chẳng qua cũng hoạt động giống mấy chương trình ARP Watch nhưng do nó hoạt động ngay trên switch nên có khả năng phòng ngừa cho toàn network thôi, phương thức của nó là tại lúc network hoạt động ổn định nó sẽ lưu bảng CAM đầy đủ vào bộ nhớ sau đó nó sẽ monitor trên tất cả các port , xem các gói ARP nào mà thông ko "phù hợp" thì sẽ drop, "ko phù hợp" ở đây có nghĩa là vd port 1 tương với PC A, nhưng Switch lại thấy 1 packet xuất phát từ port A nhưng nội dung reply lại là map 1 địa IP khác đến địa chỉ MAC của nó, switch nhận biết việc này chỉ đơn giản bằng cách là so sánh với bảng CAM lúc ban đầu nó backup ra

Nếu ko sử dụng những chương trình tự động này mà muốn nhận biết 1 cuộc tấn công ARP Poisoning thì chịu khó lâu lâu capture packet, nếu thấy lượng ARP xuất hiện nhiều liên tục thì 90% đó là ARP Poisoning. Còn ko thì cũng còn 1 cách cuối cùng là ...... học thuộc lòng MAC của con gateway, arp -a lên thấy khác thì chính là đang bị tấn cọng :lol smilie

hì, ok, mình cũng ko muốn đi xa vấn đề, chỉ đơn giản là tranh luận thôi, chẳng qua mình chỉ muốn khẳng định đơn giản là Sniff 1 chiều vẫn gọi là sniff còn sniff sao để đạt được kết quả (như lấy được info đáng giá) lại là chuyện khác

Nếu máy C không tiến hành poison luôn máy B thì cuộc tấn công này có gọi là sniff không? Khi đó, bạn có chắc là có sniff được thông tin gì đáng giá từ máy A?

Nếu bác hỏi vậy thì tôi xin trả lời là có, đây gọi là sniff.

Mr.Khoai wrote:

ví dụ: Khi A browse http://mail.yahoo.com chẳng hạn. Bạn đã poison ARP, khiến cho thay vì gửi đến default gw thì lại gửi đến máy C. Lúc đó, máy A có nhận được trang log-in để type username và password đâu? Và như vậy, cho dù bạn thấy được nhiều request của máy A (do retransmission) thì bạn cũng chả có được thông tin gì quan trọng cả

khoai

Hì hì, bác khoai có vẻ như hiểu hơi lệch khái niệm về sniff. Theo mình hiểu, sniff nghĩa là "bắt" traffic lưu thông trong mạng, ko phải là để "bắt" user/pass, userpass cũng chỉ là thông tin nằm trong các packet thôi. Tại sao cứ phải "bắt" được user/pass mới là có giá trị ? vd bác nêu ra ở trên là ko sai nhưng nó tùy vào context thôi. Thế tôi vd như máy victim resuest lên 1 trang mà đã lưu cookie trước đó, trong cookie đó chứa user & pass, thế chẳng phải chỉ cần A request lần đầu là ta đã có pass à ? 1 VD khác, khi client connect ssh sử dụng private key để kết nối server, thế chẳng phải chỉ lần đầu tiên sniff là ta có được key rồi à ?

Mr.Khoai wrote:

Gửi vietwow: Tất nhiên sniff traffic bằng cách chuyển NIC sang promiscuous mode thì không cần phải làm gì sau đó cả, nhưng muốn sniff dùng ARP poisoning thì sau đó phải poison luôn máy B và forward cái packet đó về máy B--> Man In the Middle attack. C đứng giữa và kiêm chức chuyển thông tin cho 2 máy A và B. Nếu máy C không thể poison luôn B, traffic từ A -> B sẽ bị dừng lại ở C. Như vậy, C chỉ đang sniff traffic của chính mình mà thôi.

Cách phát hiện promiscuous mode, khoai đã có viết một bài về vấn đề này. Cách chống ARP poisoning: Có lẽ chỉ còn cách như vietwow nói: dùng IDS hay các công cụ kiểm tra traffice của mạng. Nếu thấy có tình trạng khả nghi thì có thể cho đó là ARP poisoning. Nhưng vấn đề được đặt ra là: Sau khi biết có ARP poisoning, ta phải làm gì nữa?

khoai

To Khoai : tớ chỉ đang nói đến cách chốn ARP Poisoning chứ đã nói đến MIMT attack đâu smilie

) . Theo tớ thấy cậu dùng máy A, B & C để phân tích 1 cuộc tấn công MIMT thì quá phức tạp, dễ gây hiểu lầm cho người đọc. Thế này nhé, nếu hacker chỉ muốn drop tất cả traffic của máy A thì máy của Hacker chỉ cần poison máy A là đủ (lúc này đường traffic đi sẽ là Máy A --> Hacker), cón nếu muốn thực hiện hành vi forward như 1 "gateway" thì Hacker cần phải poison 2 mục tiêu đó là máy A & Gateway, poison máy A để luốn traffic đi từ máy A đến Hacker, còn poison gateway là để cho chiều ngược lại, để sau khi hacker nhận được traffic máy A, forward đi đến gateway như tình trạng bình thường, và ở chiều ngược lại, lúc này gateway bị poison nên sẽ "trả" traffic cho Hacker chứ ko phải máy A, rồi sau đó Hacker lại tiếp tục forward traffic đến máy A để "dựng" lên 1 tình trạng bình thường

Nếu máy C không thể poison luôn B, traffic từ A -> B sẽ bị dừng lại ở C. Như vậy, C chỉ đang sniff traffic của chính mình mà thôi.

Có lẽ cậu bị nhầm lẫn 1 chút, để tớ giải thích kỹ lại nha. máy B ở đây của cậu tương đương với Gateway tớ nói ở trên, còn máy C là Hacker. Nếu Hacker ko thể poison máy Gateway thì Hacker vẫn toàn có thể sniff được traffic máy A, chỉ là ko thể sniff theo chiều ngược lại như tớ nói ở trên. Điều này tớ đã thực hiện & kiểm chứng thành công nhiều lần rồi

thangdiablo wrote:

Thông thường cách ứng xử của các tool sniff sau khi nghe được luồng thông tin là forward nó đi giống như lộ trình ban đầu .
Vậy theo vietwow làm cách nào để mình nhận biết được mình đang bị sniff ?

Không phải là thông thường, mà là do người sử dụng tool sniff ko biết sử dụng hoặc ko để ý thôi smilie

) chứ tool sniff nào cũng cho chọn "hướng đi" của luồng traffic

Đối mạng hub để phát hiện sniff gần như là ko thể (nếu có thì khả năng chính xác cũng ko cao), còn mạng sniff thì dùng những tool như ARP Watch, Ethereal .... noí chung là các tool có khả năng capture & phân tích packet bởi vì như nói ở trên, trong 1 mạng switch muốn sniff thì phải sử dụng kỹ thuật ARP Poisoning mà kỹ thuật này đòi hỏi phải "phun" khá nhiều packet ARP trong mạng để "đầu độc" các máy khác, vì thế dùng các tool phân tích packet, nếu thấy lượng traffic ARP "đáng kể" xuất hiện thì khả năng bị sniff là rất cao

thangdiablo wrote:

Vậy theo zeno có cách nào để chống bị ARP posioning ?

Và sau khi trạm C lắng nghe được tất cả những luồng traffic từ A-B và ngược lại thì nó vẫn phải gửi những frame đó tới đúng địa chỉ chứ !?
Vì sau khi trạm A giao tiếp với trạm B rồi " nhầm tưởng " MAC của trạm B là MAC của trạm C. Lúc này trạm A sẽ gửi toàn bộ frame của mình sang trạm C .
Vậy thì sau khi trạm C tiếp nhận toàn bộ luồng thông tin của trạm A nó sẽ có động thái gì kế tiếp ?
Gửi sang B !? Và tiếp tục quá trình nhận ngược lại !?

Cách chốn ARP Poisoining là gán ARP Static (giải pháp cho cá nhân) hoặc dùng các chương trình như ARP Watch (giải pháp cho các network cty/doanh nghiệp)

Sau khi trạm C tiếp nhận toàn bộ luồng thông tin của trạm A, nó có toàn quyền quyết định, động thái của nó chỉ là quyết định do người tấn cống (trạm C) ra lệnh, người tấn công có thể drop packet, edit packet & forward, hoặc chỉ đơn thuần là forward

Hihi, tại em nghĩ box tài liệu chỉ để share tài liệu thôi

Mình đang cần tìm tài liệu sâu & chi tiết về system resources, cơ chế quản lý memory, virtual memory, Paped File , kernel-mode process, user-mode process, handles, threads, Commit Charge, Buffer, cache .... trong Windows. Nói chung là đi sâu về Kernel trong Windows. Hiện mình đang đọc MSDN nhưng nó chỉ nói 1 vài phần với lại nó hơi thiên về lập trình nên mình ko thích lắm. Ai có thì xin share giúp

Thanx

Mình sử dụng CentOS 4.3, khi mình test các cron trên thì đã có đả động gì tới crond đâu, mình chỉ soạn trong cron tab, save lại, chờ đúng giờ đã đặt và nó hoạt động tốt thôi, chỉ bị cái khi khởi động máy và shutdown thì file soạn nằm trong /tmp bị xóa mất. Ai bít thì help mình nha

Thanx

Mình set 1 crontab cho copy 1 file vào lúc 5h chiều hàng ngày như sau :
Trong shell gõ crontab -e, nó hiện ra giao diện vi
sau đó mình chèn syntax vào, save lại (thực ra là nó sẽ tạo 1 file có tên là crontab.XXXXVlVMhs nằm trong thư mục /tmp), sau đó chờ đến 5h chiều test thì thấy crontab chạy rất ok nhưng có điều khi restart hay tắt máy thì file crontab này của mình bị biến mất (phải chăng do thư mục /tmp được clear sạch mỗi khi reboot ?). Vậy có cách nào tạo 1 crontab mà ko bị xóa đi khi reboot hay shutdown máy ko ?

Ai bít xin giúp đỡ
Thanx

Hì, giải thích của anh rất rõ ràng, nhưng còn 1 ý ở trên em hỏi ở trên đó là như vậy có phải tất cả các connection hợp lệ đều sẽ được mark ASSURED, còn các connection "bất thường" từ TCP Scan của nmap, hay SYN DoS ... thì sẽ ko được mark ASSURED (do nó chỉ gởi SYN đi) đúng ko anh ?

- Sau khi connection đã ESTABLISHED, không có gì bảo đảm là nó được ASSURED ngoại trừ:

a. Cho TCP: server (phía netfilter) phải nhận được gói ACK có giá trị từ đầu bên kia (đúng sequence, thuộc về ESTABLISHED connection).

ACK đúng seq number (phía server phải nhận) mà anh nói là ACK của packet đầu tiên sau quá trình bắt tay 3 bước (tức là packet thứ 4 trong 1 TCP stream) phải ko anh ?

Và nếu theo anh nói vậy thì tất cả các connection hợp lệ đều sẽ được mark ASSURED, còn các connection "bất thường" từ TCP Scan của nmap, hay SYN DoS ... thì sẽ ko được mark ASSURED đúng ko anh ?

Hihi, nếu anh ko ngại thì cho em hỏi 1 câu cuối luôn : Theo tài liệu em đọc thì "các connection sau khi ESTABLISHED thì nó sẽ được mark là ASSURED để ko bị xoá đi trong bảng connection tracking khi bảng connection tracking đạt đến giá trị lớn nhất và refresh lại". Cái này thì em hiểu, nhưng em ko hiểu câu sau của nó là : "1 TCP Connection có thể ở trạng thái ESTABLISHED nhưng ko được mark ASSURED. Trường hợp này xảy ra nếu ta dùng tcp-window-tracking patch và ip_conntrack_tcp_loose >=1"

Vậy tóm lại 1 connection khi nào thì được mark ASSURED và khi nào thì ko được mark ASSURED ? Và Iptables dựa vào đặc điểm nào của connection để quyết định có mark ASSURED cho connection đó hay ko ?

Hy vọng được anh giải đáp, hỏi nhiều wá nên em hơi ngại nhưng mấy cái này thực sự làm em thắc mắc trong quá trình học cũng như đọc tài liệu smilie

-))

Thanx anh, em đã hiểu. Mà tại sao anh lại nói MAS phù hợp cho dynamic public IP nhỉ? em nghĩ nó phù hợp cho những ai có 1 Public IP mà lại có nhiều máy muốn "đi ra ngoài" chứ, sao lại liên quan đến việc dynamic hay ko dynamic nhỉ ? smilie

)

À, sẵn anh cho em hỏi thêm là khi xem State Table trong /proc/net/ip_conntrack, có các connection ở tình trạng ETABLISHED, nhưng em thắc mắc là 1 connection bắt đâu chuyển sang ESTABLISHED ngay sau khi client nhận được SYN/ACK (tức là sau bước thứ 2 trong quá trình bắt tay) hay là sau khi thực hiện đầu đủ 3 bước của quá trình bắt tay nhỉ ?

SNAT, DNAT và Masquerade thì em bít rồi ạ. Khi có gói liệu với IP nguồn là 1 Private IP đến router, router sẽ đổi IP nguồn thành Public IP sau đó mới gởi ra ngoài. Quá trình này gọi là SNAT (Source-NAT, NAT nguồn). Ngược lại, khi có một gói từ liệu từ gởi từ ngoài vào với IP đích là Public IP, router sẽ căn cứ vào bảng NAT động hiện tại để đổi địa chỉ đích Public IP này thành địa chỉ đích mới là Private IP. Quá trình này gọi là DNAT. Còn Masquerade là khái niệm khi ta có duy nhất 1 Public IP mà lại có nhiều Private IP muốn ra ngoài thì ta phải dùng Masquerade, tất cả các máy nội bộ đều dùng chung 1 Public IP đó tuy nhiên trong bảng NAT động sẽ "gán" cho mỗi máy nội bộ này 1 port riêng tương ứng để khi quay về, router nhìn vào port này trong bảng NAT động này mà bít gói tin đó sẽ được đưa đến máy nào

Em chỉ thắc mắc là NAT nó nằm trong những chain nào ? (tức là sẽ khi xử lý ở những công đoạn nào). VD như đối với table FILTER thì sẽ nằm trong chain INPUT (công đoạn khi packet đi vào máy), FORWARD (công đoạn khi packet được chuyển tiếp) và OUTPUT (công đoạn khi packet đi ra khỏi máy)

Thân

Theo mình đọc trong tài liệu http://www.acsu.buffalo.edu/~dudek/linux/iptables/img8.html thì nó bảo table NAT gồm 3 chain là PREROUTING, POSTROUTING và OUTPUT còn theo 1 tài liệu trung tâm mình đang học thì nói là table NAT gồm 3 chain : DNAT, SNAT, MASQUERADE

Vậy cái nào là đúng nhỉ ? Ai bít thì giải thích giúp mình smilie

)

Cám ơn
Thân

Anh comanle đâu rùi nhỉ, anh đã coi qua file capture của em chưa >_<

Cám ơn mọi người và anh conmale đã giúp đỡ

To anh conmale : đây là 1 session HTTP mà em capture được :

http://203.171.31.150/~vietwow/http.cap

Em dùng chức "Follow TCP Stream" thì trong header có phần "Connection: Keep-Alive" => theo như anh nói ở trên thì ở trường hợp này server dùng persistent connections => các request / response đi về trong cùng 1 socket nhưng trong phiên này thì lại có nhiều socket được mở (1999, 2000, 2001 ....) :? smilie

1 lần nữa cám ơn mọi người đã giúp đỡ vì qua bài viết này mình đã thu thập được khá nhiều kiến thức :wink:

Khi tìm hiểu về giao thức HTTP và đọc bài ký sự DDOS của anh conmale, mình có 1 thắc mắc là tại sao khi client truy cập đến webserver thì cần nhiều connection (trong bài viết của anh conmale thì tính ra trung bình là 4 connection). Theo như trong bài viết anh conmale nói thì :

một HTTP POST có payload đến trên 2 ngàn bytes thì nó phải đòi mở thêm connection để "đẩy" dữ kiện đến HVA server càng nhanh càng tốt

Và theo việc phân tích ethereal 1 session HTTP thì đúng là vậy nhưng mình vẫn ko hiểu vì theo mình bít HTTP dùng giao thức TCP để vận chuyển nên dù có gửi 1 (hoặc nhiều) packet lớn đến đâu thì nó cũng biết cách phân chia thành nhiều packet ra mà truyền & đồng thời cũng kiểm soát chúng 1 cách chặt chẽ. Vì thế theo mình nghĩ 1 người truy cập đến 1 trang web tại 1 thời điểm thì chỉ cần 1 connection là đủ, trừ khi anh ta tắt trang web đi (gửi RST) và vào lại lần nữa (gửi SYN mới) thì mới cần tạo 1 connection mới. Và nếu 1 HTTP session cần nhiều connection như vậy thì có giá trị nào trong module TCP/IP để giới hạn số lượng connection trong 1 HTTP session hay ko ? hay là 1 session HTTP muốn tạo bao nhiêu connection cũng được ?

Ai hiểu rõ xin giải thích giúp mình với
Thanx :wink:

Mình đọc 1 số tài liệu nó nói rằng Timing Attack là 1 loại side channel attack. Hacker sẽ thoả hiệp với cryptosystem bằng cách phân tích thời gian để thực thi 1 thuật toán mã hoá. Hacker chủ yếu sẽ dựa vào lỗ hổng của các thuật toán mã hoá và kèm theo 1 số thông tin như : crypto system design, CPU của hệ thống, các algorithms được sử dụng ...

Tuy nhiên mình vẫn chưa hình dung được 1 cách rõ ràng về phương thức của loại tấn công này, ai bít thì giải thích giúp mình nhé

Thanx smilie

)

Mình restart apache lại thì nó báo lỗi về php :

[root@server init.d]# /etc/init.d/httpd restart
Stopping httpd: [ OK ]
Starting httpd: PHP Warning: Unknown(): Unable to load dynamic library './php_mbstring.dll' - ./php_mbstring.dll: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: Unknown(): Unable to load dynamic library './php_domxml.dll' - ./php_domxml.dll: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: Unknown(): Unable to load dynamic library './php_xmlrpc.dll' - ./php_xmlrpc.dll: cannot open shared object file: No such file or directory in Unknown on line 0

Ko bít lỗi này có nghiêm trọng ko ? Vì mình thấy restart xong vẫn chạy ok, chưa có dấu hiệu gì hết :?) Ai bít xin chỉ giúp

Thanx

Cám ơn anh conmale đã giúp em nhận thức rõ hơn, mặc dù lĩnh vực này chưa phát triển ở vn nhưng em vẫn sẽ cố gắng hết mình để tìm hiểu smilie

)

Anh conmale đâu rồi nhỉ smilie

( trả lời giúp em với

Dạ, mục đích việc nghiên cứu này trước tiên là nâng cao kiến thức của em vì từ lâu em vốn đã rất yêu thích lĩnh vực này smilie

thứ 2 là em nghĩ là trong tương lai em sẽ "đụng" 1 số project về lĩnh vực này nên bắt đầu từ bây giờ có lẽ là vừa kịp :wink:

Hiện giờ thì em chỉ biết 1 số công đoạn của Incident Response/Computer Forensic và em cũng đang luyện tập nó hằng ngày đó là phân tích packet và phân tích log. Bên cạnh đó "kinh nghiệm" và "kỹ năng quan sát" cũng cực kỳ quan trọng nên em cũng theo dõi hẳng ngày "nhật ký" của thằng SANS để học hỏi 1 số kinh nghiệm. Ngoài ra em ko bít nên tìm hiểu thêm về những gì smilie

(

Mình đang muốn tìm hiểu & nghiên cứu về Incident Response - Network Forensic. Tuy đã đọc qua 1 số article về lĩnh vực này trên securityfocus nhưng vẫn còn khá "lờ mờ" nên ko bít bắt đầu từ đâu. Nếu ai rành thì xin giới thiệu giùm 1 số tài liệu hay về lĩnh vực này giùm

Thanx :wink: