Messages posted by: rickb

@vikjava : rất cám ơn bạn, thực ra cái đoạn mình post lên hỏi là đọc và lấy ra từ bài này chứ đâu smilie

@tmd : tcp/ip thì mình cũng có tìm hiểu sơ rồi, mình chỉ thắc mắc khúc "it supplies the length of the received frame" là ko biết nó implement như thế nào thôi, nhưng wa lời bạn giải thích thì mình cũng hiểu được phần nào

Thanx all smilie

p/s : Thực ra cái này liên quan đến network, ko phải security nhưng mình ko biết network thì nên post vào mục nào (mình chỉ thấy mục về bảo mật, exploit, linux .. ) nên đành post vào đây, mong các mod thông cảm

Mình đọc 1 tài liệu về Ethernet, họ nói rằng :

"The length of an Ethernet II frame is not present in the frame itself. It depends on the Ethernet network interface used. When the interface sends a frame to the network device driver, it supplies the length of the received frame"

Khúc đầu thì mình hiểu là frame Ethernet II sẽ ko hiển thị chiều dài của nó, nó phụ thuộc vào NIC được sử dụng để gửi frame. Nhưng đoạn sau mình ko hiểu lắm, ý nghĩa câu "When the interface sends a frame to the network device driver, it supplies the length of the received frame" là gì ?

Ai hiểu xin giải thích giùm
Cám ơn

Thân

Ok, thanx Mr.Khoai & anh conmale đã giúp đỡ, mình sẽ đọc kỹ lại, nếu có gì thắc mắc nữa thì mong mọi người giúp đỡ smilie

Đầu tiên xin rất cảm ơn anh đã trả lời chi tiết các thắc mắc của em

Em đọc đi đọc lại bài trả lời của anh và cũng nắm được phần nào nhưng có lẽ em chậm hiểu nên có 1 đoạn anh viết mà em suy nghĩ mãi vẫn chưa hiểu :

Việc read và write vào filesystem không chỉ đơn thuần là lưu thông tin vừa được read hoặc write để cung cấp cho ai đó nhanh hơn như kiểu caching trên một web proxy. Cụ thể hơn là kernel không hề biết trực tiếp bất cứ điều gì thuộc về applications hoặc dữ liệu thuộc userspace, bởi thế, nó dùng page cache để quản lý chúng (ví dụ, điều tác và cung cấp memory, xác định ưu tiên của các system calls.... ).

Em thực sự chưa hiểu đoạn này lắm, anh nói cached ở đây ko đơn thuần là dạng cache như web proxy, vậy theo anh nó còn có khả năng gì nữa (ngoài khả năng lưu các data read, write để cung cấp lại, giống web proxy) ? Và tại sao đoạn ngay sau đó anh lại đề cập việc "kernel không hề biết trực tiếp bất cứ điều gì thuộc về applications hoặc dữ liệu thuộc userspace, bởi thế, nó dùng page cache để quản lý chúng" ? Em chưa hiểu sự liên quan giữa đoạn này với việc cached mà em thắc mắc ? Anh có thể nói rõ đoạn này ko nhỉ ?

Với lại em đang search mấy tài liệu về kernel để đọc, tài liệu về kernel trên NET thì có rất nhiều mà em thì lại ko rành nên em muốn nhờ anh recomment 1 tài liệu theo anh đáng giá là tốt nhất

1 lần nữa cám ơn anh nhiều
Thân

hi anh conmale,

Sau bài reply của anh, em có 3 thắc mắc

Thứ 1, như vậy theo anh thì tại sao gởi / nhận dữ liệu từ các thiết bị ngoại vi như disk, keyboard, network... thì kernel lại cần Buffer ? Có phải là nó giống như khái niệm Queue trong SMTP Server hay TCP SYN Flood ko nhỉ ? tức là kernel khi gửi data đến thiết bị ngoại vi thì data sẽ được gửi đến queue trước rồi từ queue mới đến thiết bị ngoại vi, tương tự nhận cũng thế. Queue đóng vai trò trung gian ?

Thứ 2, nếu buffer là 1 phần physical memory lấy từ RAM như anh nói, thì như vậy nói là 1 con số (số lượng) nhất định, ko thay đổi giống như RAM, như vậy tại sao nó lại ko có thêm cột total như physical memory mà nó chỉ có 1 cột duy nhất (cột buffers) để show phần mà nó đã sử dụng ? Vì nếu như hiện tại thì khi ta nhìn vào cột Buffers của lệnh free thì ta chỉ biết nó đã sử dụng bao nhiêu physical memory cho việc Buffers nhưng ta ko thể biết được lượng physical memory tối đa được cho cấp cho việc Buffers là bao nhiêu ? Chẳng lẽ là unlimited ? nếu vậy thì hơi ko logic lắm

Thứ 3, theo giải thích của anh về cached thì em hiểu là cột cached chính là kỹ thuật Disk Buffering mà em đã đề cập ở trên, tức là khi user read hay write 1 resource trên disk, nó sẽ copy thêm 1 bản và lưu vào RAM để cache, nếu lát nữa có request đến cùng resource này thì nó chỉ cần lấy từ cache (RAM) ra mà ko cần phải lấy từ disk ra như ban đầu, việc này sẽ tăng performance cho hệ thống vì việc access resource từ RAM nhanh hơn nhiều so với việc access resource từ disk => ko biết em hiểu như vậy là chính xác ko nhỉ ?

Cám ơn anh rất nhiều, đề tài này em có hỏi mấy người nhưng rất ít người hiểu được 1 cách chính xác nên em hơi confuse
Thân

Hix, ko ai có ý kiến gì sao smilie

Theo mình biết, trong Linux cũng như hầu hết các modern OS thì đều có 1 kỹ thuật gọi là Disk Buffering. Tức là khi user read hay write 1 resource trên disk, nó sẽ copy thêm 1 bản và lưu vào RAM để cache, nếu lát nữa có request đến cùng resource này thì nó chỉ cần lấy từ cache (RAM) ra mà ko cần phải lấy từ disk ra như ban đầu, việc này sẽ tăng performance cho hệ thống vì việc access resource từ RAM nhanh hơn nhiều so với việc access resource từ disk

Quay lại vấn đề, trong linux có 1 command để monitor rất kỹ memory là lệnh free, tuy nhiên trong phần output của nó có 2 cột (column) ở cuối khiến mình khá confuse là column "Buffers" và column "Cached", 1 vd về output của lệnh free :

Vậy theo cách bạn column "Buffers" và column "Cached" của lệnh free khác nhau như thế nào ? Cái nào mới đích thực là Disk Buffering ? Và cái còn lại có ỹ nghĩa gì ?

Mình đã thử tham khảo nhiều tài liệu và ebook nhưng mỗi tài liệu lại nói khác nhau (vd trong ebook "Running Linux 4th edition" thì nó bảo column "Buffers" chính là kỹ thuật Disk Buffering tuy nhiên column còn lại thì nó ko giải thích được, n1oi vài chữ hoa loa cho wa, mấy tài liệu khác thì có khi nói Cach mới nơi cache các page memory tức cũng là Disk Buffering ... ) nên mình rất confuse ko biết cái nào chính xác. Ai biết xin giải thích giùm, xin cám ơn
Thân

Thanx Khoai đã trả lời

p/s : Còn ai có cao kiến gì ko nhỉ ? smilie

Mình đang đọc tài liệu có phần đế cập đến Linux Scheduler và lệnh time, nó nói : "real time is the amount of time between when the code started and when it exited. User time and system time are the amount of time spent executing application code versus kernel code, respectively."

Tức là real time trong phần output của lệnh time là thời gian tính từ lúc chương trình bắt đầu chạy cho đến lúc chương trình kết thúc, tương tự user time & system lần lượt là thời gian tính từ lúc bắt đầu -> kết thúc của 1 chương trình ở User mode và kernel mode

Nhưng đoạn sau nó có nói : "A basic knowledge of the Linux scheduler is helpful in interpreting the output, but this tool also is helpful for learning how the scheduler works. For example, the real time of a process typically is larger than the sum of the user and system time. Time spent blocking in a system call does not count against the process, because the scheduler is free to schedule other processes during this time"

Mình ko hiểu tại sao real time lại luôn luôn lớn hơn tổng thời gian user & systime cộng lại ?

Với lại đoạn sau là : "Time spent blocking in a system call does not count against the process, because the scheduler is free to schedule other processes during this time"
Mình cũng ko hiểu đoạn này nó muốn nói gì ?

Ai hiểu xin thích giải thích kỹ giúp mình, cám ơn nhiều
Thân

Thanx prof nhiều nha smilie

Ai còn ý kiến gì nữa ko ? Vì mình đang tìm hiểu về đề tài này nên càng nhiều người góp ý càng tốt smilie

Thực ra topic này chỉ nhắc đến unix nhưng ko liên wan gì nhiều nhưng mình ko biết đặt vào đâu cho thích hợp nên post tạm vào đây, mong các mod thông cảm

Mình đang đọc 1 tài liệu về Storage Networking Protocol thì có 1 đoạn như sau :

The common definition of a file server is an off-the-shelf operating system (like UNIX or Windows) running on a multipurpose hardware platform (like a PC) configured to share files. By contrast, a network attached storage (NAS) filer typically runs a highly optimized (sometimes specialized) operating system on an optimized hardware platform specifically configured to share files. Another distinction is that UNIX and Windows file servers have native file-level protocols, whereas NAS filers do not. NAS filers are multiprotocol by design and typically support all mainstream file-level protocols.

Khúc đầu thì mình hiểu nó muốn phân biệt file server là định nghĩa 1 hardware thông dụng (như PC) chạy 1 OS như unix hay windows để share file, còn NAS là 1 thiết bị chuyên dụng chạy 1 OS chuyên dụng để share file. Nhưng mình ko hiểu sau, nó bảo file server bên unix & win là native file-level protocols, còn NAS hỗ trợ mainstream file-level protocols. Vậy "native file-level protocols" và "mainstream file-level protocols" là gì ? chúng khác nhau như thế nào ?

Ai biết thì giải thích giùm mình (hoặc có tài liệu thì share cho mình đọc cũng được), cám ơn nhiều
Thân

Em đã hiểu rồi, thanx anh conmale nhiều smilie

Mình đang thử triển khai Snort Inline trên Ubuntu 7 Server, về phần cài đặt thì mình đã thành công tuy nhiên khi đọc mấy tutorial thì mình có 1 thắc mắc. Mình search trên google được 2 tut về cài đặt & cấu hình snort inline :
1 là http://linuxgazette.net/117/savage.html
2 là http://www.openmaniak.com/inline.php

Về cơ bản, cả 2 cái đều chỉ cách cài đặt & config giống y chang như nhau ngoại trừ 1 thứ duy nhất là mysql. Tut thứ 1 thì ko cần cài mysql mà chỉ cần build snort và các gói lib cần thiết đi theo thôi (như libdnet, libnet ...), khi build snort thì cũng chỉ cần ./configure make & make install. Còn tut thứ 2 thì bắt phải build mysql, tạo database cho snort, và import cấu trúc db của snort vào db đó, sau đó khi build snort thì phải ./configure --with-mysql để snort inline tích hợp với mysql. Tut thứ 2 thì mình ko có thắc mắc vì mình cũng nghĩ là snort cần phải có 1 db (ko hẳn phải là mysql) để lưu trữ thông tin, signature, alerts ... Nhưng còn tut thứ 1 thì snort inline ko có 1 db nào tích hợp hết, như vậy thì nó lưu trữ thông tin bằng cách nào ? Ở dạng nào ?

Ai biết xin giải thích giùm
Thân

nghienruou01 wrote:

có thể thực hiện TCP hijacking với Man-In-Middle, hoặc Blind Attack hoặc đoán số seq, mình chỉ đề cập Man-In-Middle:

Thực hiện tấn công Man-In-Middle để bắt các packet phát ra từ C( passive sniffer) hay tiếp nhận các packet từ C( active sniffer). Lúc này khi đã có TCP header, attacker tạo spoofed packet với địa chỉ của C, số seq, ack, port... và inject vào TCP session trước khi client C gởi response đến S.

Ngăn response từ C đến S : thứ nhất hủy các packet đi qua máy attacker, thứ hai thực hiện tấn công máy C( DOS chẳng hạn)

Định hướng lại TCP session đến máy attacker( Soure Route trong TCP packet gởi đến Server S)

ps: rất vui học hỏi thêm

Chức năng Source route là trong phần Option của IP header, ko phải trong TCP packet. Với lại chức năng nay hiện nay đã bị hầu hết các router/fw trên thế giới drop nên gần như là vô dụng

Tương tự Spoof IP trong mạng LAN thì được nhưng nếu muốn thực hiện qua Internet thì gần như ko thể vì hầu hết các router biên của ISP vn đều lọc IP Spoofing rồi

Thân

Mr.Khoai wrote:

Chào rickb, anh conmale,

khoai có vài điểm muốn bàn thêm về câu số 3:

- Cái "số Sequence" mà rickb đề cập chỉ là ISN (Initial Sequence Number). Các số TCP Sequence trong một data stream thì có thể biết được từ sequence của segment này và độ lớn của segment.
- Để inject dữ liệu vào một TCP stream thì bạn chỉ cần capture được một gói TCP ở giữa đường. Lúc đó, trong tay bạn có IP + Port, Seq và Ack của cả 2 bên client và server.

Phần câu số 2, khoai không hiểu ý bạn khi đề cập chuyện "victim thiết lập connection sau khi bị man-in-the-middle attack" nghĩa là sao?

khoai

Hi Mr.Khoai,
Câu "victim thiết lập connection sau khi bị man-in-the-middle attack" mà mình đề cập có nghĩa là vd như A là victim, B là hacker và C là Destionation. Trường hợp khi Attacker đã thực hiện hoàn tất 1 cuộc tấn công MIMT (các máy trong mạng này đã bị "đầu độc" ARP Cache) xong xuôi, khi đó A (victim - máy đã bị "đầu độc") bắt đầu thực hiện việc thiết lập TCP connection (vd như duyệt web, check/gửi mail ..) đến C nhưng thật chất là qua B. Khái niệm này giống như khái niệm "Transparent Proxy" vậy, máy trong gõ www.yahoo.com như thực chất là có thể sẽ bị qua 1 con Squid/Iptables Server nào đó. Do đó lúc này Attacker (B) ko cần biết số sequence nữa vì lúc này A thiết lập connection -> B, B "bắt chước" y chang A để connect -> C (chỉ có khác duy nhất là src IP lúc này sẽ là B chứ ko phải A) và chiều reply cũng y như vậy. Như vậy A sẽ "xem" máy B chính là C (destinaton thật của victim) còn đối với C (destination thật sự của A) thì xem máy B như là máy A. Như vậy cả A và C cứ "nghĩ" mình đang trao đổi với đối phương thật (là C đối với A và ngược lại) nhưng thật thực thì ko phải vậy mà là cả 2 đều chỉ trao đổi với B (Attacker).

Ko biết nói vậy Khoai hiểu ko vì trước giờ mình giải thích hay lủng củng lắm, mong thông cảm
Thân

Hehe, em chỉ là người "qua đường" nhưng cũng muốn "chung vui" vì thấy khá hứng thú với 3 câu hỏi của anh conmale, em thì ko cần tài liệu hacking cao siêu gì hết, chỉ cần anh conmale xem xong nếu sai thì xin giải thích cho em rõ giùm ^^

1/ Trong TCP, cờ FIN (Finish) được sử dụng khi 1 bên muốn kết thúc TCP connection 1 cách "polite", và bên gửi FIN phải chắc chắn rằng bên còn lại đã nhận được FIN rồi mới thật sự đóng connection (do vậy trong tcp khi đóng kết nối sử dụng FIN sẽ có 1 bên gặp tình trạng time-out hay còn gọi là time-wait trong giai đoạn cuối cùng của 1 quá trình đóng kết nối), vì thế lúc vừa gửi FIN đi thì connection vẫn tồn tại (data trong TCP Buffer vẫn còn). Còn cờ RST (Reset) là để đóng TCP conntection 1 cách "impolite", tức là bên gửi RST, sau khi gửi RST thì bên đó ko cần quan tâm đển bên còn lại có nhận được hay ko mà nó sẽ đóng connection ngay lập tức (xoá sạch data trong TCP Buffer) sau khi gửi gói RST kia, và bên còn lại khi nhận gói RST cũng "tự hiểu", tự đóng connection mà ko cần thông báo trở lại cho bên gửi RST

2/Theo em, TCP là 1 giao thức reliability (so với UDP), nhưng tính reliability là ở tính toàn vẹn dữ liệu, nhưng toàn vẹn ở đây ko phải là ko bị hacker sửa đổi mà toàn vẹn ở đây là TCP cung cấp cơ chế để kiểm soát luồng dữ liệu (flow data control), do đó ko gây ra việc dữ liệu bị thiếu sót (do nghẽn mạng hay gì gì đó(. Tuy nhiên về mặt Security thì TCP ko hẳn là an toàn. Ở đấy có 2 trường hợp, trường hợp thứ 1 là 1 connection đã được thiếp lập từ trước bởi victim, lúc này attacker sẽ sử dụng kỹ thuật Hjacking (cũng thuộc MIMT) nhưng bởi vì đối với TCP thì số sequence chính là "sinh tử huyệt" của nó do đó trong 1 cuộc tấn công Man In The Middle thì Attack hoàn toàn có thể lấy được số sequence và "nắm quyền" connection đó. Còn đối với trường hợp 2 là victim thiết lập connection sau khi đã bị MIMT thì ko có gì để nói, vì lúc này TCP hay UDP cũng như nhau thôi

3/ Số Sequence và "nguyên tắc" generate chuỗi sequence (tùy thuộc vào cách Implement của từng OS/kernel)

conmale wrote:

Tất nhiên là được.

Dùng djbdns để tạo một domain nào đó cho nội mạng và tất nhiên phải có mx record cho domain này. Mail trong nội mạng sẽ được dùng cho nội mạng. Trên qmail, em tạo một virtual domain nội mạng (như đã tạo từ djbdns) và mail vẫn được chuyển đến đích theo phương thức "defaultdelivery". Em đừng config qmail (./config-fast) gì cả mà chỉ tạo virtual domain mà thôi (xem virtualdomains trong nhóm control của qmail).

Em nghĩ nếu chỉ thiết lập 1 mail server cho nội bộ (ko đi ra NET), và trong nội bộ đó chỉ có duy nhất 1 mail server thì ta ko cần tạo MX Record, ko biết có đúng ko nhỉ ? Vì theo em biết MX Record chỉ được query khi cần có sự giao tiếp giữa 2 SMTP Server

conmale wrote:

Không đúng.

Apache http luôn luôn đóng vai trò là web service. Apache tomcat luôn luôn đóng vai trò là jsp / servlet container. Bởi thế, nếu em hỗ trợ jsp / servlet thì em phải build thêm Tomcat. Nó không phải là web server nên câu hỏi "em cần phải build tới 2 webserver (1 là apache, 2 là apache tomcat) à?" là câu hỏi không hợp lý.

Apache http vẫn có thể config để cung cấp virtual site. Apache tomcat vẫn có thể config để cung cấp virtual servlet engine.

Em nên tìm một cuốn sách về tomcat để đọc kỹ để hiểu rõ hơn về tomcat.

Vâng, cám ơn anh đã giải thích smilie

conmale wrote:

Tomcat chạy... cụ thể cái gì mà nhanh hơn Apache?

- Tomcat (Apache Tomcat) là một servlet / jsp container. Nó có khả năng phục vụ http requests nhưng nó không phải là một web server thuần túy.

- Apache (Apache Httpd) là một web server. Nó được phát triển để làm việc như một web server thuần túy và có thể đảm đương cả công tác của một proxy server.

1) giống nhau căn bản:
- cả hai đều có thể tiếp nhận http requests.
- cả hai đều có concept "virtual sites".
- cả hai đều có thể xử lý cả http và https.

2) khác nhau căn bản:
- Apache Httpd không có khả năng hiểu và biên dịch servlet / jsp.
- Apache Httpd có khả năng điều tác requests / responses tinh vi và hiệu suất hơn Apache Tomcat rất nhiều.
- Apache Httpd có plug-in modules (được viết bằng C là chính) để mở rộng chức năng. Trong khi đó, Apache Tomcat không có tính mở rộng này.
- Apache Httpd không dùng Java lib trong khi Tomcat dùng và cung cấp các thư viện Java cần thiết cho web applications (vì nó đóng vai trò container).

Nói tóm lại, so sánh Apache Httpd và Apache Tomcat giống như so sánh con mèo với con chó (đều có 4 chân nhưng tính chất và tính cách khác nhau) :lol :lol

Nói như anh conmale thì mặc dù Tomcat ko phải web server thuần túy tuy nhiên nó vẫn là 1 webserver vì nó vẫn có khả năng điều tác requests / responses HTTP. Nhưng như vậy nếu em đứng trong vai trò là Hosting Provider, em cần build 1 server và (dùng chức năng virtual sites) để "chia" host ra bán cho nhiều khách hàng thì em cần phải build tới 2 webserver (1 là apache, 2 là apache tomcat) à ? Vì rõ ràng nhu cầu của khác hàng thì rất đa dạng và phong phú, người thì cần java, người thì ko. Nếu chỉ Apache thôi thì ko thể support servlet/jsp cho khách hàng, nhưng nếu chỉ cài Apache Tomcat thôi thì sẽ như anh comnale nói là "Apache Httpd có khả năng điều tác requests / responses tinh vi và hiệu suất hơn Apache Tomcat rất nhiều" và "Apache Httpd có plug-in modules (được viết bằng C là chính) để mở rộng chức năng. Trong khi đó, Apache Tomcat không có tính mở rộng này" .... ?

Em suy nghĩ rất nhiều và cũng đang cố gắng đọc sách nhưng thực sự em vẫn chưa hiễu rõ câu "Stateful firewall có nhiều dạng và nhiều ứng dụng. Nếu nó ứng dụng để kiểm soát cả tầng 7 (của model OSI) thì nó không chỉ dừng lại ở tầng network và transport." của bác conmale, ko bít bác có thể giải thích rõ thêm cho mình ko ? Vì theo em stateful chỉ có thể manage ở tần transport và network thôi vì nếu nó có thể manage lên tới tầng Application thì lúc đó nó là Proxy FW hay Inspection Stateful FW rồi chứ đâu phải Stateful FW đâu anh

Thân

conmale wrote:

Thế nào là "ứng dụng chạy trên các port ko xác định"?

Hầu hết các firewall ngày nay (ngoại trừ một số firewall chuối thì không kể), bất kể stateful hay chỉ packet filter, thì mặc định thường là deny all, allow selected. Bởi thế, nếu packet đi đến một port đã không nằm trong chuỗi "allow selected" nó bị drop ngay từ đầu thì chẳng có gì cần đến stateful nữa cả. Bồ nên hiểu rằng, "stateful" chỉ có nghĩa với các packets được cho phép và thỏa mãn quy định nào đó. Nếu chúng bị drop ngay từ đầu thì đâu có state gì đâu mà xử lý được hay không xử lý được?

Stateful firewall vẫn xử lý các protocol như FTP, IRC, P2P ngon lành. Cái này còn tùy stateful FW mà bồ liên tưởng đến đó là firewall cụ thể do ai sản xuất. Nên xét trên mặt nguyên tắc và tính chất thật sự của một stateful firewall thay vì dựa vào 1 ứng dụng firewall nào đó để đánh giá chung stateful firewall.

Tôi nghĩ bồ chưa hiểu rõ thế nào là stateful firewall. Bồ nên đọc lại thật kỹ bài trả lời trước của tôi vì nếu bồ còn diễn giải và thắc mắc như trên thì có lẽ nhận định của tôi không sai (về mức độ hiểu thế nào là stateful firewall của bồ).

Thân mến.

Ok, em sẽ xem lại kỹ

À, em cũng có 1 sồ ebook về FW nhưng ko rành cái nào nên đọc nhất, anh có thể giới thiệu cho em 1 số tài liệu hay về FW được ko ? Cái em cần học là các loại FW phân theo cơ chế hoạt động như Packet filtering, Stateful, Inspection, Proxy ... chứ ko phải là các loại FW cụ thể như iptables, PIX, ASA, Juniper ...

Thân

Chào anh conmale,

Vấn đề anh đề cập trên là ứng dụng chạy trên các port ko xác định, như vậy thì đúng là Stateful FW ko xử lý được (hoặc xử lý rất kém), vd như các protocol FTP (Passive/Active), IRC, p2p ... Cái này thì em biết rồi nhưng theo em hiểu câu trên có nghĩa là nó muốn nói đến việc đổi port default mà ứng dụng đó bind, vd như default apache bind port 80 như ta hoàn toàn có thể đổi trong file config để nó bind thành port bất kỳ nào mình muốn, trong câu phát biểu em đưa ra trên nó có vd là HTTP port 8001 nên em nghĩ nó đang ám chỉ đến vấn đề này. Như với vấn đề này thì em ko nghĩ nó liên quan đển stateful FW ? Nếu có thì mong anh giải thích thêm ạ

Cám ơn anh nhiều
Thân

Trong 1 slide bài giảng về khoá học Firewall hồi xưa mình học thì nó có đề cập : "Stateful FW sẽ bỏ qua các Traffic nếu các dịch vụ thay đổi port mặc định (vd : HTTP port 8001)"

Mình ko hiểu câu này cho lắm, về việc đổi port các ứng dụng deamon thì mình hoàn toàn nắm rõ nhưng mình ko hiểu tại sao nó lại ảnh hưởng đến Stateful FW ? Bởi vì theo mình biết, Stateful FW chỉ hoạt động ở tầng Network và Transport giống Packet Filtering, nó chỉ "thông minh" hơn Packet Filtering ở điểm có thêm 1 State table để kiểm soát thêm các thành phần của 1 connection như Time out, SYN, FIN ... Như vậy Stateful FW hoàn toàn ko lọc payload của traffic ở tầng application, vậy thì chuyện mình đổi port hay ko thì nó liên quan gì nhỉ ?

Ai biết rõ xin giải thích giùm
Thân smilie

)

Mình thấy hầu hết tất cả distro (FC, Ubuntu, RHEL ...) đều có gói này nhưng ko hiểu mục đích chính của gói này là để làm gì ? Khi nào thì ta cần phải install nó ? Gói linux-kernel-headers với lại gói kernel của Linus Torvalds trên site www.kernel.org khác nhau như thế nào ?

Ai rành xin giải thích kỹ giùm
Thanx

kid_b0d wrote:

Linux bản thân nó đã là một server, còn bản ubuntu thì tớ chưa biết.
Máy bị chết"tạm thời" là do phải xử lý quá nhiều process , bạn chờ vài giây hoặc nếu máy yếu thì bỏ bớt tùy chọn.
NMAP chỉ dùng cho linux, nó được viết bằng C và trong linux hỗ trợ tốt C.

Trả lời 3 câu 3 câu đều sai hết

Thứ 1 bản thân linux chưa phải là 1 server, mà phải do user cài FTP Server hay Web Server hay Database server thì mới thành "Server" được

Thứ 2, trường hợp o0_annie_trang_0o nói ở trên là bạn ấy xài BLUES PORT SCAN, đây là chỉ là 1 program đơn, ko chạy ở mô hình client-server thì làm gì chuyện "bị chết"tạm thời" là do phải xử lý quá nhiều process"

Thứ 3 Nmap có đầy đủ bản cho linux, windows, freebsd .... chứ ko phải chỉ dùng cho Linux

hack2prison wrote:

Nguồn: http://www.securityfocus.com/archive/1/455352/30/0/threaded

Host directory is a product of scriptsfrenzy.com and alstrasoft.com
I check lastest version and maybe infected lower versions. I contacted
vendor 5 times in 2 months but not received any replies.
- FullPath disclosure: http://site.ext/path/ANY_INCORRECT_LINK
Warning: main(/home/user/public_html/include/ANY_INCORRECT_LINK.php):
failed to open stream: No such file or directory in
/home/user/public_html/include/main.php on line 25
- Backup database bypass: http://site.ext/path/admin/backup/db
- Change admin password without login:
http://site.ext/path/admin/config

CÁCH KHAI THÁC
I. Lý thuyết có thực hành.
Chú ý: Dùng firefox
Target: WebHost directory một sản phẩm của scriptsfrenzy.com Trước đây H2P làm việc trên trang đó nhưng họ đã off demo nên ta thực hành trên: http://thewebhostdirectory.co.uk
Do ta coi đây như trang demo nên ta đăng nhập vào admin trước nào:
http://thewebhostdirectory.co.uk/admin Password=test

OK vào rồi đấy. Nghía qua các link quan trọng nhất:
Backup DB: http://thewebhostdirectory.co.uk/admin/backup/db
Config: http://thewebhostdirectory.co.uk/admin/config

Do ta đã đăng nhập với tư các admin nên việc thực hiện công việc backup hay config được là lẽ đương nhiên. Ghi nhớ 2 cái link quan trọng cái đã nhé. Logout ra để đảm bảo ta chỉ là một visitor bình thường.

Vào IE gõ lên address: http://thewebhostdirectory.co.uk/admin/backup/db cái gì vậy? Một file .sql đẹp đẹp mời ta download. Hehe, vậy là không check session rồi, không cần đăng nhập admin cũng có quyền download. Cứ download phát đã, để đó và kiểm tra link quan trọng thứ 2:

http://thewebhostdirectory.co.uk/admin/config nó vào trang đăng nhập. Trong trường hợp này ta đã biết pass thì không nói làm gì nhưng nếu một trang chưa biết pass. Có 2 cách:
1. Mở file backup ra: search WebInterfacePassword ta sẽ thấy 'test' nằm bên cạnh, đó là password admin đấy nhưng ta không dùng cách này, không cần biết password là gì có thể config được không? Thử cách 2 nhé:
2. http://thewebhostdirectory.co.uk/admin đăng nhập vào đi.
Nhấn vào link Config. Nhấn chuột phải vào frame chính, chọn View source. Search: <form method="post"> và thay thành: <form action="http://thewebhostdirectory.co.uk/admin/config" method="post">
Save as lại thành file poc.htm Logout ra để bảo đảm ta chỉ là visitor bình thường. Chạy file poc.htm
Tại ô Web Interface Password: nhập vào pass của bạn nhé. VD tớ nhập: vbf
Submit đi. Nó chạy tới trang login nhập pass bạn vừa change vào (vbf)
Hehehe, đăng nhập vô tư rồi đó.

Chú ý: Không nên dùng cách này để change pass của người ta. Nên dùng cách 1 thôi. Nhưng đây là link thực tập nên anh em có thể change. Tuy nhiên sau đó change lại nguyên pass cũ về cho chủ nhân của nó.

Ku có thể sử dụng password trong database backup được để đăng nhập Host CP. Muốn biết user của host thì dùng: http://thewebhostdirectory.co.uk/cai_gi_cung_duoc
Nó Fullpath disclorure rồi: /home/theweb/public_html/include/cai_gi_cung_duoc.php
Vậy user là theweb

II. Tấn công có ý thức dựa vào bug này (nghĩa là không deface anyone)
Do đây là site WebHost Diectory nên khách hàng của site toàn là các chủ sever/reseller nên ta có thể dùng bug này tấn công các server với một sức mạnh kinh hồn.

Mở cái file database backup ở trên ra tìm đến đoạn:
INSERT INTO `hsl_host` (`hid`,`username`,`pwd`,`email`,`name`,`address`.. ..

Đó chính là thông tin của các chủ server/reseller host đấy. VD:
('100','dano1979','afton1981','submission@ajahosti ng.com'...

thì dano1979 là user name | afton1981 là password | submission@ajahosting.com là email. Hãy khai thác các thông tin này để tấn công nhé, còn làm sao thì đừng có hỏi, tớ chửi cho đấy.

Không phá hoại và deface, hãy làm đúng tinh thần: Hacking for security.

ENDED Copyright by Hack2Prison Thanks for helping from VBF leaders.

Tôi có 1 thắc mắc, đã login vào được phần http://thewebhostdirectory.co.uk/admin (dùng pass test của bác hoặc cách Javascript Inline của Gama) rồi thì sao ko backup thẳng luôn mà phải log out ra rồi tận dụng lỗi website ko check session kỹ để backup database ? Nó đâu có gì khác nhau ?

Thứ 2 là tại sao đổi Code:

<form method="post">

thành: Code:

<form action="http://thewebhostdirectory.co.uk/admin/config" method="post">

thì ta lại có thể login với bất kỳ pass nào mình đưa vào (vd ở trên là vbf) ?

Mình vào chỉ thấy có 2 video à bạn, đâu có 50 video đâu ?

File / Description Add-time Size
Use_20Brutus_20to_20crack_20a_20box_20running_20telnet_.avi

No description saved. 12.03.2007
09:26:30 1744 KB
Found
MITM_20Hijacking.wmv

No description saved. 12.03.2007
09:26:30 54856 KB
Found

mrro wrote:

conmale & JAL: hoàn toàn đồng ý với ý kiến của hai anh. Như em đã nói trong bài viết của mình, phương thức này không phải là silver bullet, có thể giải quyết dứt điểm xFlash. Ưu điểm lớn nhất của nó là có thể phát hiện ra được xFlash bất kể thằng xFlash có thay hình đổi dạng đến cỡ nào (ý em là thế hệ xFlash gửi POST request như hiện nay).

hackernohat: tôi biết rõ ActionScript 3 nguy hiểm cỡ nào và trong bài viết của tôi cũng có đề cập đến điểm này. Phương thức này chỉ có thể chống lại đám xFlash hiện tại thôi, còn nếu kẻ tấn công cố ý khai thác những tính năng mới của ActionScript 3 thì phương thức này sẽ hoàn toàn bó tay. BTW, XMLSocket không phải là tính năng nguy hiểm nhất của ActionScript 3 đâu.

-m

Bác mrro cho mình hỏi cái, bác nói "thế hệ xFlash gửi POST request như hiện nay", thế x-flash hồi trước sử dụng phương phép gì vậy bác ?

Cái này chả liên quan gì đến CPU cả (1 con cũng làm được mà 2 con thì càng tốt, xử lý càng nhanh thôi) mà là do card màn hình (Graphics Card) có support hay ko thôi. Bạn cứ ra ngoài tiệm phần cứng hỏi loại card màn hình nào support 2 (đầu) màn hình là ok

Ok, vậy thì tớ hiểu rồi , vì lúc đầu cứ nghĩ đặc trưng md5 là $1$ chứ ko phải $1 => nếu trừ đi thì chỉ còn 31 ký tự nên ko logic, giờ thì hiểu rồi :lol smilie

Thanx nha