nhanth87 wrote:

Nếu dùng && thì sau khi lệnh 1 kết thúc sẽ chạy tiếp lệnh thứ 2.
 

Vẫn sai. 

Có một giải thích rất súc tích:

http://www.linfo.org/kernel_space.html 

time perl -e 'log(2.0) foreach(0..0x100000)'
real 0.40
user 0.20
sys 0.00 

trong đó iowait (iowait = network i/o + memory i/o + disk i/o) chỉ dao động từ 3-4%, user (các thao tác thuộc user space, Oracle process nằm ở đây) 

IDS / IPS không thể detect được sniff vì nó là một hành động ở dạng thụ động (passive). Cách duy nhất là kiểm tra NIC nào đang dùng để sniff xem nó có ở tình trạng promiscuous hay không. Tuy nhiên, rất khó detect tình trạng này. Hơn nữa, sniffer ngày nay có thể sniff nhưng không cần thiết phải chuyển sang promiscuous mới sniff được.

Cách tránh sniff tốt nhất là dùng VLAN trunking và dùng SSL những nơi cần bảo vệ thông tin nhạy cảm.

Thân mến.  

chào bạn,
1. nói tiếp về số 1 ở trên. Tui vẫn cho câu phát biểu của mình không sai. Có thể rephrase lại nó như thế này: "1 layer không biết những thứ được xác định ở layer khác và function ở layer khác". Như tui đã nói ở trên, việc IP header có 1 field là Protocol chỉ giúp cho nó biết chính xác cái PROTOCOL HANDLER để tiếp tục forward những gì còn lại, sau khi nó đã làm xong nhiệm vụ là decapsulate cái ip header. Đó là ý của tui, còn tui nghĩ nếu bạn interpret ý của tui như bài vừa post thì bạn cần đọc lại bài trên của tui.
Mà nói thiệt, không cần refer tui tới 1 tool như hping, nếu muốn tui có khả năng viết 1 tool để craft 1 raw packet như hping. Còn việc protocol ID nào được kernel process, cũng nói với bạn luôn, khỏi test mất công: hầu hết kernel chỉ auto process normal packet có Protocol field value là 1 (ICMP), 2 (IGMP), 6 (TCP), và 17 (UDP) và drop mọi packet khác, trừ phi bạn obtain thẳng raw data từ datalink layer rồi tự process nó, xây dựng custom procol handler để process mấy cái datagram có Protocol field value khác. Đây là điều mà mấy route processor trong mỗi router làm để process routing packets.

Tui quote lại câu mà bạn cho là bạn hiểu đúng ý tui:

như tôi đã nói tôi khẳng định 100% như đã nói ở trên là nếu TCP/IP ko dựa vào trường Protocol, ehternet type hay port thì nó ko tài nào xử lý được gói tin nữa 

Tui không hề tuyên bố như thế trong bất cứ post nào của tui trong thread này, bạn có thể dẫn chứng ra nếu tìm thấy. Tui nói là 1 layer chỉ làm đúng chức năng của nó, không cần biết chức năng của layer khác là như thế nào. Network layer sử dụng Protocol field để tiếp tục forward cái decapsulated payload sang cho đúng cái protocol handler, không có nghĩa là nó CÓ KHẢ NĂNG hiểu và làm được những gì cái protocol handler đó sẽ làm.
Bạn có lẽ nhầm lẫn ở chỗ này, việc bạn biết được số điện thoại của nhà mình không làm cho bạn biết được phương thức đánh số của nhà cung cấp (xin lỗi, poor example).

2.

"Bạn bảo TCP/IP Stack chẳng xử lý gì cả vì chẳng biết gì để xử lý ? Nope, HTTP Protocol là gì ? Nó là giao thức nằm trong bộ TCP/IP ở tầng App, nó chính cái cái biêt cách xử lý như thế nào với 1 gói tin có Dst port là 80" 

Câu này thì tui để mọi người đánh giá. Bạn đi từ sai lầm này đến sai lầm khác. HTTP có thể sử dụng TCP như là underlying transport protocol, nhưng chẳng có ai cấm việc bạn thay thế TCP/IP bằng IPX/SPX để carry HTTP traffic, HTTP KHÔNG THỂ nhìn thấy cái gì thực sự carry traffic của nó ở lớp dưới. Need proofs ? google thử xem có tồn tại IPX web server không thì biết.
Một điều nữa là việc "xử lý gói tin có DST port 80" không thuộc thẩm quyền của HTTP. HTTP quy ước là quy ước các quy tắc xử lý "nội dung" của gói tin, không phải xử lý TCP info liên quan tới cái gói tin đó. Nói thẳng ra: HTTP biết gì về SYN, ACK, FIN flag, port của gói tin ? Nó có cơ hội nhìn thấy đâu mà xử lý ? Xử lý ở đây là xử lý data nhận được từ kernel IO subsystem hoàn thành tác vụ của nó và notify kernel để copy data từ kernel-space lên user-space.

Bạn đọc hết cái HTTP rfc xem nó có chữ nào là chữ port không ?
http://www.w3.org/Protocols/rfc2616/rfc2616.html

Không tin nữa thì bạn kiếm quách 1 web server code mà nhìn cái core function của nó xem chỗ nào nó hiểu và xử lý Transport layer info. Thứ duy nhất có số 80 chắc chỉ là lúc nó declare server socket. Còn việc thực sự xử lý các network IO liên quan tới socket này không còn thuộc chức năng của web server nữa.

4. Tui cũng đã xác nhận là tui misread bạn vì bạn refer tới TCP/IP MODEL, tui lại hiểu là bạn refer tới TCP/IP layer thuộc về OSI MODEL. Hy vọng bạn cũng do some favor và đọc lại ý của tui. Việc bạn refer tui tới những tài liệu, website "nổi tiếng" thì tui cám ơn bạn, mặc dù thực sự không helpful lắm với tui vì tui đã đọc 3 cái đó từ đời tám hoánh nào rồi.

Liên quan tới Cisco, do bạn đề cập nó trước, và make 1 assumption là tui đã từng học CCNA nên lậm OSI. Sorry bạn, nhưng cá nhân tui, dù dốt, nhưng cũng đã có cơ hội thảo luận với không ít người tài giỏi khác, nhưng tui không quan tâm tới cái background của họ, tui cũng không bao giờ hỏi, hoặc giả định rằng kiến thức của họ từ cái nguồn nào ra. Việc bạn đã tiếp xúc với bao nhiêu người có CCIE tui cũng chẳng quan tâm, tui quan tâm duy nhất tới cái khía cạnh bạn đưa ra ở topic này, còn bạn học ở đâu để đưa ra thì tui mackeno. Mà nói thiệt với bạn nhé, tui chẳng cần phải nhờ tới 1 "chuyên gia" Cisco để thảo luận với bạn, nếu bạn cứ tiếp tục diễn đạt mức hiểu của bạn về networking như vậy.

Về thái độ thảo luận, hy vọng bạn có thể làm được điều này
- Nếu cho rằng tui đã nói cái gì, vui lòng quote chính xác lại, và diễn dịch lời nói của tui theo cách hiểu của bạn. Điều này giúp tui biết được tui và bạn không đồng ý ở điểm nào trong lời nói của tui, tui sẽ sửa nếu quan điểm của bạn đúng.
- Không nên cho rằng người nào tham gia thảo luận đều là "thắc mắc chỗ nào chứ nói".
- Không nên assume bất cứ điều gì về technical background của người ta.
- Không nên bảo người ta phải nhờ tới "chuyên gia" để tiếp tục thảo luận với mình, bạn hơi tự cao đấy.

Cuối cùng là tui refer bạn đọc về OS concept, về kernel subsystems, để xem bao nhiêu thứ được dùng trong khi implement OSI 7 layers, để biết tới lớp nào thì kernel perform context switch từ userspace sang kernelspace khi handle data to/from network. Bạn học OSI mà không hiểu lớp nào đang được phần nào của kernel handle thì cũng như học vẹt, chả tác dụng gì đâu.

Tui bắt đầu cảm thấy đủ với việc tiếp tục thảo luận trong topic này. 

2. Bạn nhầm lẫn: 1 protocol có thể trải dài nhiều layer, nhưng 1 layer không thể hiểu những quy định của layer khác. ARP/RARP có thể có những specification nằm ở 2 layer, nhưng nếu nói vậy rồi cho rằng datalink layer hiểu về những thứ defined ở network layer là trật lất. Nói thẳng ra luôn, trong 1 OS, phần IP trong TCP/IP kernel stack làm gì ? một là logical addressing, 2 là packet routing. Trong những thứ đó, datalink hiểu gì ? Chẳng hiểu gì hết.

- Ví dụ của bạn về sự tồn tại của field 'Protocol' trong IP header không chứng minh được là Network layer HIỂU về những thứ xác định ở Transport layer, nó ở đó chỉ với mục đích là để TCP/IP stack biết đường mà forward cái datagram đó lên đúng cái protocol handler tương ứng. Việc interpret và process data không thuộc về chức năng của nó nữa, nên tui nói nó không hiểu về các định nghĩa của lớp trên là không sai.

- Riêng về ví dụ port của bạn, cũng nói luôn với bạn rằng trong chức năng của TCP/IP stack, TCP không biết/không cần biết những app nào sẽ handle cái data này, những gì nó làm khi nhân được data là tách header ra, notify kernel là data available for reading trong cái socket receive buffer của cái socket descriptor nào đang associate với port đó, ngay bản thân việc read cái data từ cái socket buffer cũng chẳng còn thuộc về phần chức năng của TCP nữa, mà thuộc về IO và virtual file subsystem, chứ đừng nói tới việc TCP biết app nào đã request để open cái descriptor đó, và expect data kiểu gì. Bạn đừng gom luôn chức năng nhiều kernel subsytems lại với nhau và cho rằng đó là chức năng riêng của TCP chứ. Bạn sai khi cho rằng TCP/IP stack xử lý cái header "tiếp theo" sau TCP header. Nó chẳng xử lý gì cả vì chẳng biết gì để xử lý.

3. Tui đồng ý ở điểm này, sở dĩ có sự tranh luận ở bài trên vì tui nghĩ bạn đang refer tới 2 layer thuộc OSI model. my bad ! btw, có lẽ bạn không cần phải mở mang cho tui về các mailling list, tui frequent những maillist như vậy từ lâu lắm rồi.

4. Những giao thức vừa kể không phải là hỗ trợ thêm, mà chúng predate OSI, chúng không còn được sử dụng nhiều vì thiếu những đặc điểm của OSI, đặc điểm quan trọng nhất có lẽ là không phân biệt rõ ràng giới hạn chức năng của 1 layer, dẫn đến khó khăn cho 3rd-party vendor khi develop 1 product để interoperate với 1 product trước đó. Nếu bạn vẫn cho rằng OSI không make clear separation giữa các layer, chứng tỏ bạn vẫn chưa nắm được nguyên nhân ra đời của OSI. Bạn nghiên cứu về networking bao lâu để nói như vậy ?

1. Còn riêng về việc bạn muốn biết tui học networking ở đâu thì xin trả lời sơ sơ, tui self-trained, chả có cisco ciskiet nào cả, và cũng self-employed luôn. Cũng nhân tiện xin bạn rút lại những lời cho rằng dân học cisco thì lặm OSI, bởi vì theo tui biết, cisco là biggest vendor về networking hardwares, và nó nếu cisco không hỗ trợ nhiều networking model thì chắc cũng chẳng ai hỗ trợ nhiều cả. Đừng nên claim cái gì mà mình không biết, kẻo dân học cisco chính gốc lại vào gây chuyện đấy. 

1. Tui không rõ bạn nghĩ chữ ngôn ngữ như thế nào nên mới hỏi lại. Tui không make any statement rằng bạn không hiểu chữ ngôn ngữ. Protocol thiếu nhiều đặc tính của 1 ngôn ngữ nếu nói về khía cạnh linguistic, chính xác hơn nó được định nghĩa là tập hợp những "quy ước" về giao tiếp.

2. Ở khái niệm "đường dây mạng" KHÔNG tồn tại khái niệm packet. OSI make clear separation giữa các layer mới nhau, layer này hoàn toàn không biết và không cần thiết phải biết tới những gì định nghĩa ở layer khác. Khái niệm "đường dây mạng" của bạn nằm ở tầng mấy của OSI ? Khái niệm packet nằm ở tầng mấy của OSI ? Nên nói "packet đi trên đường dây mạng là tín hiệu điện" liệu có chính xác ? Nếu bạn đã không phân biệt rõ ở chỗ này, dĩ nhiên bạn sẽ không phân biệt rõ giữa cái gì khái niệm 1 packet và khái niệm 1 "view" của nó, bởi vì 2 khái niệm này nằm ở 2 tầng khác biệt nhau của OSI.

Do vậy, ý tui muốn phản bác với bạn nằm ở câu này trong bài post trên của bạn: "Bộ có packet nào ko phải là mã hexa à". Bởi vì ở đây, bạn cho rằng 1 packet (khái niệm ở Network layer) và cái nội dung in vào mắt mình (Application layer) làm một. Và do đó tui make 1 statement là "Hoàn toàn có thể code 1 sniffer để hiển thị NỘI DUNG của packet dưới dạng khác hex".

Và ý cuối cùng của bạn cũng có cái đáng để nói:
- Có vẻ bạn cho rằng TCP/IP là bộ network protocol duy nhất. Điều này bạn xem lại nhé, tui đưa thêm vài thứ cho bạn tham khảo: APPLETALK, DECNET, thậm chí là NETBEUI, tất cả đều là network protocol suite.
- OSI chứa TCP/IP, TCP/IP là 1 phần của OSI, nói cái này là "hoạt động thực sự", cái kia là "chuẩn" để tham khảo là sai, cả 2 đều là chuẩn.

edited: tui vừa post xong thì hình như bạn edit lại post của mình, nên tui quote tiếp phần này

vietwow wrote:

Còn hexa ở trên là do các chương tình sniffer & analyer Ethereal hiển thị. Như vậy thì việc hiển thị hexa hay decinmal hay ASCII là do chương trình sniff sử dụng quy định chứ ko phải là do "packet content" như bạn nói
 

- Phần tô đậm là bạn lặp lại ý của mình ở trên, vui lòng xem lại
- Vui lòng xem lại luôn là tui nói ở đâu trong bài post trước là "packet content là hex" ? Người nói ý đó là bạn, khi cho rằng "Bộ có packet nào ko phải là mã hexa à " và tui phản bác lại chính ý đó. 

to vietwow: đúng là tớ chả biết gì về TCP/IP cả, mong bạn chỉ dạy ).  

bạn tìm hiểu tcp/ip kỹ chưa mà khuyên người ta ?
1. Theo ngữ cảnh của bạn, "ngôn ngữ" là gì ?
2. packet chẳng mắc mớ gì tới hex hay cái gì gì hết. packet PAYLOAD được hiển thị ở dạng hex thì khả dĩ (bởi vì packet không chỉ gồm nội dung, vậy những thứ liên quan tới header có được ethreal hiển thị dạng hex không ?, rõ ràng là không!). Khái niệm packet được define ở OSI Network layer, hex/bin/dec là cách application interpret cái view của mình tùy theo packet content. Ethereal display packet payload ở dạng hex, không có nghĩa là không có ai có quyền code cái packet sniffer hiển thị thông tin sniff được ở dạng bin, octal hay cái gì khác.
 

Theo tôi packet trên ko phải được mã hoá mà chẳng qua đây là "ngôn ngữ" của protocol YM nói chuyện với nhau thôi, để hiểu được ngữ nghĩa của chúng thì bạn phải đọc thật kỹ RFC của các giao thức YM  

==> mã hexa lù lù thế kia, ngôn ngữ nào ở đây

 

==> bạn vietwow đọc kĩ lại câu hỏi rồi hãy trả lời nhé. Hình nhứ nó đi quá xa với chủ đề ban đầu.

to: phanminh bác nohat nói đúng đó. Tuy nhiên bổ sung thêm cho bác nohat gì thì gì, cũng nên cài gói gcc vào cho nó yên tâm (kể cả server/desktop/development), update phần mềm cho nó tiện  

Không có khái niệm gói chuẩn trong linux, chỉ có khái niệm gói thường dùng mà thôi.
Có lẽ cái mà bạn hỏi là các gói nào thường dùng trong distro của bạn. Cái này thì còn tùy distro ( phiên bản phát hành ) và bạn dùng *nix cho mục đích gì. Vì các gói của linux là so much nên bạn chỉ nên tìm hiểu trong phạm vi yêu cầu của mình như là bạn dùng *nix làm Desktop thì có các gói:
GUI ( KDE hay Gnome )
OpenOffice ( bộ ứng dụng office )
Wine ( bộ giả lập để chạy các ứng dụng của windows )
.v.v.

làm server có:
GCC ( bộ trình biên dịch vì các gói cho server thường ở dạng mã nguồn )
Apache
Mysql
PHP
iptables ( firewall )
snort ( IDS - hê thống phát hiện thâm nhập )
.v.v.

Mọi thứ còn tùy vào bạn, *nix rất rất khác windows.
 

Vâng, em nhầm, em cứ nghĩ là cứ port 80 thì đc xử lí bởi HTTP server trên server. Hìhì, server có thể quy định cổng 80 là do process nào xử lý cũng đc nhỉ.
Cái gói TCP này source port là 2506 và Destination Port là 80. Có phải phần data kia đã được Y!M client mã hóa ko ạ, và có thể dùng công cụ nào để giải mã nó ra dạng text bình thường ạ 

mong các bác xóa mù cho em về linux cái,em cài bản Mandrake linux 9.2 nói chung là ngon lành nghe nhạc từ cd được. cắm HDD khác vào cũng chẳng thấy đâu, vào mạng thì không được, hai nữa là không thể tìm thấy ổ cd-rom đâu, cắm usb vào thì chẳng thấy gì cả, bó tay không biết làm gì, mong các bác chỉ giúp em, 

vietwow chạy apache phiên bản mấy vậy? Tớ thử trên apache 2.0.59 và 2.2.4 đều không bị sự cố này. 

403 - Forbidden
You don't have permission to access /
Tức là nó cấm không cho vào ) muốn vào nó thì bro thử cách sau

Tìm dòng
DocumentRoot "/usr/local/apache2/htdocs"

Thay thế thành
DocumentRoot "/home/votui/public_html"

Thêm vào dòng sau
<Directory "/home/votui/public_html">
Order allow,deny
Allow from all
</Directory>

votui : tên tài khoản của tôi
/home/votui/public_html : đường dẫn này chứa ứng dụng web, bro có thể thay đổi sao cho phù hợp với ứng dụng web cho phù hợp với nhau

Nhớ reset apache khi điều chỉnh cấu hình tập tin cấu hình của Apache xong .
#/usr/local/apache2/bin/apachectl restart

Bro thay đổi dòng trên là nó OK thôi, ngoài ra bro xem lại phần .htaccess nhé
Nếu không có mod_limitipconn thì chỉ có hai phần trên thôi .
Thân 

Hi hi khi tôi làm quen với Linux tôi bắt đầu với Fedora Core 4 sau đó vì tôi có 1 server chỵ Centos cho nên tôi bắt buột tôi cài đặt CentOS .

Tôi làm quen với CentOS gần 6 tháng nay và đang trả lời cho bạn củng sử dụng GNOME trên Centos 4.4 Final

GNOME 2.8.0
Distrubution : Centos
Build Date : 09/04/2005 

Nếu không tin bro download CentOS về và cài thử xem .
Trong quá trình boot hệ điều hành nếu bro nhấn Enter thì quá trình cài đặt sẽ là GUI
Còn nếu như bro gõ linux text thì bro sẽ cài đặt bằng text mode

Không tin thử xem )  

k9t02 wrote:

ý. CentOS có GUI vậy làm sao dùng được GUI của nó, mình install login là dùng command không àh, củng khó khăn cho mình lắm, bác giúp chuyển qua GUI dùm nhe,thanks bác nhiều  

Khi bro cài đặt nó ở màn hình khởi động nếu nhấn Enter vậy là cài đặt GUI, nếu muốn cài đặt text mode thì gõ linux text

Dùng command không thì built gnome mặc định sau khi cài đặt CentOS thì gnome nó là version 2.8.0 (cái này chưa thử chuyển đổi từ text chuyển sang gui bao giờ) hoặc đơn giản cài đặt lại . )  

OpenLDAP != AD 2003.

Cách config đơn giản đây: http://www.openldap.org/doc/admin23/quickstart.html