Thảo Luận TCP/IP - .:: HVAOnline ::.

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận mạng và thiết bị mạng

Thảo Luận TCP/IP

[Question] Thảo Luận TCP/IP	17/07/2006 03:21:45 (+0700) \| #1 \| 7259

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Messages: 812
Offline

Bài này ở HVA cũ là “Tập hợp các câu hỏi liên quan đến TCP/IP”,bài này tôi thấy rất giá trị nên post lại lên để ai chưa biết còn có cái tham khảo

forabetterlife

IP Checksum
IP Checksum và Checksum của các protocol khác(TCP, UDP, ICMP…). Dưới đây tớ sẽ trình bày cách hiểu của tớ về 2 loại checksum này, nếu như tớ hiểu sai thì ai đó correct giùm cái nhá.

Như bạn đã biết, ở mỗi layer trong TCP/IP model người ta đều xây dựng một cơ chế kiểm sóat lỗi, mục đích là để kiểm tra xem packet có bị thay đổi trong quá trình truyền tin hay không?(tớ xin bỏ qua Ethernet checksum nhá :p).
Bạn xài tcpdump hay Ethereal gì đó, capture 1 UDP packet chẳng hạn. Rùi, nhảy zô IP Header, sẽ dòm thấy 1 field là: Checksum. Field này có kích thước là: 16bits.
Cách tính IP checksum:
Đầu tiên là ở phía sender. Bạn xem IP Header như là một chuỗi các bit 0, 1. Rùi, bây giờ chia cái chuỗi này ra theo từng “đọan”, mỗi đọan dài 16 bits.
Ví dụ: tớ có 1 chuỗi 0,1 thế này: 0110011001100110 0101010101010101 0000111100001111
Thực hiện phép cộng(nhị phân) ba từ này lại với nhau, được kết quả là: A = 100101011001010
Okie, bây giờ lấy phần bù của chuỗi A(cách lấy phần bù, chuyển bit 0 thành bit 1, bit 1 thành bit 0) ta được chuỗi B như sau: 0011010100110101. Okie, đem cái chuỗi này bỏ vào field Checksum của IP gửi nó đi.datagram

Ở phía receiver:
Thằng receiver sau khi nhận được datagram này sẽ tính lại checksum theo cách y như trên(khi tính tổng sẽ có 1 số hạng là Checksum do sender tính). Nếu như được kết quả là 16 bits 1 thì Header của IP datagram này không bị thay đổi gì so với khi gửi đi. Còn nếu vứt luôn, không báo gì về cho gói tin bị lỗi như có 1 bit nào đấy bằng 0 thằng sender biết cả .
Như vậy, bạn có thể thấy là mục đích của IP Checksum là kiểm tra xem Header của IP datagram có bị lỗi trong quá trình truyền hay không ?(khi tính toán ta chỉ quan tâm đến Header, không ngó ngàng gì tới phần data cả )

Chú ý:
IP Header nếu có thêm các thông có thể sẽ có trường hợp độ dài của IP Header sẽ khôngtin trong phần Option chia hết cho 16(ta cần chia thành các chuỗi 16 bits mà). Trong trường hợp này, thằng IP layer sẽ tự thêm vào các pad byte(tất cả các bit đều set bằng 0) để làm sao kích thước của IP Header đủ chia hết cho 16.
Đối với Checksum của các protocol khác như TCP, UDP, ICMP thì có khác. Sự khác biệt ở đây là: Khi tính Reiceiver có thể phátchecksum sẽ bao gồm luôn cả phần data trong gói tin đó hiện được lỗi trong phần data(cái này là hơn thằng IP Checksum đây)

Lấy ví dụ UDP Checksum:
UDP Checksum bao gồm: pseudo-header, UDP Header , data và pad-byte(nếu cần thiết)

Pseudo-header là gì?
Nó gồm một số field lấy từ IP header lên: bao gồm 32-bit source IP address, 32-bit destination address, 8 unused-bit(8 bit 0), 8-bit protocol, 16-bit UDP length.

Mục đích của pseudo-header để làm gì?
Phần này em mong các bác chỉ giáo, em xin trình bày cách hiểu của em. 2 cái trường IP là để check lại xem gói tin này có đến đúng đích hay chưa? Trường Protocol là để kiểm tra lại xem thằng IP layer nó phân phát gói tin lên đúng protocol hay chưa? (Cái này ông Richard bảo là double-check)
Cách tính UDP Checksum thì cũng tương tự như trên. Nếu như Receiver tính ra checksum mà có 1 bit 0 thì gói tin đã bị lỗi trên đường truyền. thằng sender đã không tínhNếu như Checksum nhận được tòan là bit 0 cả Checksum trước khi gửi đi.

Chú ý:
- UDP Checksum là không bắt buộc nhưng đừng dại gì mà disable nó
- TCP Checksum là bắt buộc phải có

forabetterlife

Question
Em xin các bác bổ sung ý kiến và liên hệ các trường hợp cái này thì em còn kém lắm. À còn nữa, em muốn hỏi trongthực tế(nếu có) trường hợp UDP Checksum. Packet sang đến IP layer của thằng Receiver rùi, thế khi thằng Receiver tính lại checksum vẫn phải thêm thằng Pseudo-header vào nữa à ?

Anh CONMALE

Phần mở rộng
Khi gói tin được chuyển lên layer phía trên IP layer và được demultiplexed thì ở tầng này phải lo chuyện gởi lại gói tin bị lỗi checksum (restransmision), tùy theo ứng dụng của các giao thức.
Cả TCP và UDP đều dùng pseudo-header (đầu giả ) và dùng chung một thuật toán để tính checksum.
Answer
UDP checksum là "end-to-end" checksum. UDP check được thằng sender tính, nhưng lại được thằng receiver xác nhận. Cho nên không có bước thằng "receiver tính lại checksum". Có 3 chuyện xảy ra:
- nếu checksum được gởi đi là 0 ==> thằng gởi đã không tính checksum, không có chuyện gì đáng nói.
- nếu checksum được gởi đi là 1 hết ==> thằng gởi đã tính checksum, checksum ok, không có chuyện gì làm thêm
- nếu checksum được gởi đi không phải là 0 (thằng gởi đã tính checksum) nhưng có giá trị 0 trong 16 bits này ==> checksum error, thằng nhận chỉ cần biết thế này là đủ và nó lặng lẽ ném gói tin ấy vào thùng rác.

Checksum là phương tiện để đo lường tính trung thực của gói tin và cái gì cũng có cái giá của nó cả, càng xác định tính trung thực thì càng tạo ra "overhead" --> càng chậm. Sở dĩ TCP bắt buộc phải có checksum vì nó muốn bảo đảm gói tin gởi nhận hoàn toàn trung thực. Nếu có sự cố, nó gởi lại lần nữa, và lần nữa nếu cần, cho đến khi đầu nhận nhận được gói tin trung thực. Bởi vậy, TCP "chắc ăn" hơn nhưng chậm hơn UDP rất nhiều ở điểm này. Trong môi trường lý tưởng như một nội mạng có thiết bị hoàn chỉnh, có topology vững vàng, kết cấu hợp lý thì vấn đề checksum có lẽ ít cần thiết. Tuy nhiên networking ngày nay không còn biên giới hạn hẹp nữa nên cái "môi trường lý tưởng" này càng ngày càng trở nên không thể được. Đây là lý do tại sao IP header của IPv6 không còn checksum field nữa.

All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children"

[Question] Re: Thảo Luận TCP/IP	17/07/2006 03:22:51 (+0700) \| #2 \| 7260

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Messages: 812
Offline

forabetterlife

Question
Câu hỏi của em xoay quanh trường Type-of-service(TOS). Trong IP Header TOS có độ dài là 8 bits
- 3 bit đầu tiên là 3 bit ưu tiên(precedence). Em còn nhiều chỗ thắc mắc ở 3 bits này đây.
Các câu hỏi:
+ Giá trị của từng bit thế nào ? Ý nghĩa là gì ?

- 1 unused bit: cái này không xài, để dành tương lai cần thì xài( )
- 4 bits TOS
+ Minimize delay(ưu tiên độ trễ)
+ Maximize througput (ưu tiên thông lượng)
+ Maximize reliability(ưu tiên độ tin cậy)
+ Minimize monetary cost --> bit này thì em chịu, không hiểu nó để làm gì, trong cái table của Richard có đưa ra thằng NNTP nó set bit này bằng 1, nhưng em vẫn chưa hiểu được ý nghĩa của nó ???

Ở bên trên là ý nghĩa(+ thắc mắc ) của từng bit . Bây giờ em gom lại về TOS field luôn.

Ý nghĩa của TOS field là gì?
Theo em được biết, hùi xưa mạng Internet nó hơi yếu . Router không thể xử lý 1 lúc quá nhiều packet --> phải dòm vào cái TOS field để xác định độ ưu tiên, xử lý thằng nào trước thằng nào sau ??? (Không biết có gì sai không ạ ?)

Tại sao ngày nay người ta lại không dùng TOS field này nữa ? Hình như là chỉ có một số ứng dụng đặc biệt vẫn xài cái này(em chỉ biết qua loa đến thế chứ chưa biết là thằng nào xài ) Em vác Ethereal capture thử cũng không "chộp" được IP packet nào có TOS field này cả ??? Nó thay bằng cái mới rồi(cái mới này thì em chưa tìm hiểu thêm)
Các câu hỏi của em sẽ focus vào những cái sau:
- Cách thức hoạt động ? -> hiểu bản chất
- Ứng dụng thực tế thế nào ? --> biết để mà dùng
- Bị attacker lợi dụng để làm gì ? như thế nào ? --> biết để mà tránh

Anh Conmale

Answer
"Minimize delay" --> giảm thiểu độ chậm trễ.

"Minimize monetary cost" --> "giảm thiểu phí tổn". Có những dịch vụ không quan trọng về tính khẩn cấp, có chậm một tí cũng chẳng sao, có chiếm ít băng thông của không ảnh hưởng gì ví dụ như NNTP. Protocol NNTP này là Usenet News và tin tức có vào news client chậm một tí cũng không sao. Nói chung những dịch vụ được xếp loại "thứ yếu" thì có thể dùng TOS là "mmc".

Lý do tại sao protocol như telnet lại được khuyến khích dùng "md"? tại vì cần bảo đảm những diễn tiến xảy ra trên remote machine được cấp báo ngay trên local machine để tạo tính "real time interaction".

Lý do tại sao protocol như ftp cho data chẳng hạn lại được khuyến khích dùng "mt"? tại vì cần phải đẩy dữ liệu đi càng nhanh càng tốt để kết thúc giai đoạn tải dữ liệu trong thời gian ngắn nhất.

Nói chung TOS dùng theo nhu cầu nhất định nào đó.TOS được thiết kế nhưng thực tế ứng dụng không hoàn toàn đi theo đường lối chung. Có quá nhiều OS và quá nhiều ứng dụng không tuân thủ theo RFC (M$ là một trong những điển hình của việc không tuân thủ RFC). Hơn nữa, packets cần phải đi xuyên qua routers chớ không chỉ quanh quẩn trong một subnet và nhiều router không ứng dụng TOS thì cũng bó tay. Lý do tại sao router không muốn ứng dụng TOS? bởi vì nó tạo nên sự phức tạp đáng kể cho việc tạo nhiều routing tables thích ứng. Thêm một lý do khác là tùy routing protocol nào được dùng nữa; trong một mạng mình có thể hoàn toàn quản lý, mình có thể chọn lựa loại routing protocol một cách đồng bộ thì chuyện tạo những routing tables đáp ứng tuy mất thời gian nhưng vẫn có thể làm được. Nếu packets đi xuyên qua nhiều network khác nhau và mỗi router có một policy khác nhau, dùng loại routing protocol khác nhau thì... càng bó tay.

Router, hay nói chính xác hơn là routing protocol có nhiều loại, nhiều đặc tính cũng như hạn chế khác nhau. Không phải loại routing protocol nào cũng "thèm" để ý đến TOS và cũng không phải routing protocol nào cũng "không thể xử lý một lúc quá nhiều packets" . Trên thực tế, các ứng dụng cho routing rất phức tạp (và càng ngày càng phức tạp hơn) trong việc xử lý (chọn những factors để quyết định cho routing). Thật ra các routing protocol "hiện đại" ngày nay càng ngày càng "thông minh" trong việc xử lý routing và đưa vào nhiều yếu tố cho việc quyết định routing chớ không chỉ đơn giản "dòm" cái TOS và... "đẩy" packet đi. Nếu bồ thích, nên "ngâm" thêm các routing protocols thì sẽ thấy.
TOS vẫn được dùng trong các thủ thuật traffic shaping. Tuy nhiên, chúng chỉ có giá trị trong giới hạn mình có thể quản lý được. Trong phạm vi cho phép, bồ vẫn có thể dùng TOS để tạo các chế độ routing theo nhu cầu vào theo ưu tiên mình chọn. Ví dụ, bồ có 2 cổng đi ra Internet, một cổng băng thông lớn, một cổng băng thông nhỏ. Bồ có thể dùng TOS để xây dựng routing tables để ép các loại trafìc không cần nhanh đi xuyên qua đường băng thông nhỏ như SMTP, NTP chẳng hạn và các protocol khác như HTTP, FTP đi qua đường băng thông lớn. Hơn thế nữa, bồ có thể "ép" traffic đi từ mỗi host có giới hạn nhất định nào đó để tránh tình trạng nghẽn tắt.

Bồ dùng Ethereal để capture thử traffic trong LAN hay traffic từ Internet? Nếu traffic đi từ Internet thì hầu như bồ chỉ thấy có giá trị TOS là 0x0 mà thôi vì hầu hết các routers không ứng dụng TOS vì quá mất thời gian. Nếu bồ sniff trong LAN và các traffic này không được ấn định cụ thể giá trị TOS thì lúc nào bồ cũng chỉ có thể thấy TOS là 0. . Chừng nào IPv4 còn được dùng thì tính chất của nền tảng giao thức của nó vẫn là như vậy. Ngày nay băng thông càng ngày càng cải thiện nên chuyện TOS không còn được đặt nặng nữa. Trong giới nghiên cứu mạng có hai nhánh chính:
- hỗ trợ cho quan điểm áp đặt TOS ở protocol level
- hỗ trợ cho quan điểm xem nhẹ TOS mà chỉ chú trọng khối lượng băng thông để phục vụ

Đám thứ nhất cho rằng protocol không nên bị phụ thuộc vào chất lượng băng thông và các nhà sản xuất phải tuân thủ theo quy định, đám này là đám idealist. Đám thứ nhì thì cho rằng việc phát triển băng thông sẽ giải quyết vấn đề chất lượng tiêu dùng nhanh chóng và hiệu quả hơn là đi ngược lại nền tảng TOS của protocol, đám này là đám realist. Cả hai đám đều có cái lý của họ vì họ xét vấn đề từ hai hướng khác nhau.
Theo rfc 791 thì 3 bits đầu của TOS (từ 0 đến 2) có giá trị như sau:

111 - Network Control --> ưu tiên 7
110 - Internetwork Control --> ưu tiên 6
101 - CRITIC/ECP --> ưu tiên 5
100 - Flash Override --> ưu tiên 4
011 - Flash --> ưu tiên 3
010 - Immediate --> ưu tiên 2
001 - Priority --> ưu tiên 1
000 - Routine --> ưu tiên 0

Những directive trên có tính chất như sau (dựa theo tài liệu giải thích của DOD - US Department of Defense):

111 - network control dự tưởng dùng cho môi trường một nội mạng riêng. Ứng dụng và điều tác này tùy vào chế độ từng mạng riêng này.

110 - Internetwork Control dự tưởng dùng cho gateway điều tác các hosts tạo nên các gói tin nằm sau gateway này.

101 - CRITIC/ECP viết tắt của "Critical and Emergency Call Processing" và dự tưởng chỉ nên dùng trong điều kiện khẩn cấp và đã được cho phép dùng. Ví dụ như ứng dụng cho các đơn vị cao cấp của chính phủ.

100 - Flash Override dự tưởng dành riêng cho các thông điệp liên hệ đến các trường hợp tối khẩn như thiên tai, địa chấn.... hoặc được dùng trong trường hợp tối đặc biệt như phóng vũ khí nguyên tử.

011 - Flash Flash (Z) dự tưởng dành riêng cho chiến trận trong trường hợp cực kỳ khẩn cấp.

010 - Immediate dự tưởng được dùng trong những hoàn cảnh mang tính nguy hại đến bảo mật quốc gia, quân đội đồng minh hoặc dân chúng.

001 - Priority dự tưởng được dùng cho các thông điệp mang tính khẩn hoặc hàm chứa thông tin cần thiết cho những công tác đang diễn tiến.

000 - Routine dự tưởng được dùng cho những thông điệp thích đáng để truyền tải xuyên qua phương tiện dùng các thiết bị điện tử.

Thực tế giá trị precedence không được dùng. diffserv (Differentiated Services) được dùng trong việc ấn định ưu tiên cho packets. Xem thêm ở: http://www.ietf.org/html.charters/diffserv-charter.html

All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children"

[Question] Re: Thảo Luận TCP/IP	17/07/2006 03:23:51 (+0700) \| #3 \| 7261

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Messages: 812
Offline

Bác PXMMRF

Chúng ta đang bàn về TCP/IP . Thưc ra IP/TCP là môt bộ giao thức ( suite ) không phải là môt giao thức , vì nó gồm giao thức IP ( Internet protocol ) và giao thức TCP ( Transmission Control Protocol )

Chính vì vây nếu ta nói về môt Packet của IP/TCP thì có thể không chính xác . Bởi vì có IP packet và có TCP packet và chúng không hoàn toàn giống nhau về cấu trúc

1-IP packets( datagrams )
Như chúng ta đã biết , giao thức IP là giao thức quan trọng nhất hay có thể nói là giao thức " thống trị " trong lớp mạng ( network layer ). Network layer ( lớp mạng ) ở đây là đựoc hiểu là Network layer trong 4 lớp ( Four Layers ) của bộ giao thức IP/TCP , bao gồm

-Link layer ( Lớp Liên kết )
-Network Layer ( Lớp mạng hay Lớp Internet )
- Transport Layer ( Lớp chuyển vân )
- Application Layer ( Lớp ứng dụng )
( Chúng ta chú ý không nhầm lẫn sơ đồ 4 lớp của IP/TCP nói trên với sơ đồ OSI )

Network Layer ( trong IP/TCP ) có nhiệm vụ chuyển các gói tin dữ liệu trong không gian mạng , từ node ( nút mạng ) này đến node khác . IP đóng vai trò quan trọng hay thống trị như nói ở trên vi nó qui định các thức đóng gói các dữ liệu đươc truyền trên mạng ( hay còn gọi là network traffic )vào trong các gói tin IP ( IP datagrams ) và qui định các nguyên tắc chuyển các datagrams này trong không gian mạng - Trong giao thức IP ngừoi ta ít dùng từ packet mà thường dùng datagram , dù ý nghĩa của hai từ là giống nhau - như là ở miền Bắc gọi là "tất ", còn trong Nam gọi là "vớ"

Môt IP header và body ( tức là một IPdatagram ) gồm có các phần ( hay còn gọi là trừong -Field ) sau :
- 4-bit version
(chỉ rõ version nào đươc dùng , hiên đang thừong dùng nhất version 4 )
-4-bit Header Length
( chỉ rõ chiều dài của header )
-8- bit Service
( chỉ rõ mức service - level of service - mà các datagram áp dụng )
-16 -bit total length ( in bytes )
( chỉ rõ toàn bộ chiều dài của datagram - gói tin - tính luôn cả header )
- 16-bit Identification
( Xác đinh tính duy nhất cho mỗi gói tin đựoc chuyển đi từ môt host - không lầm lẫn với các gói tin khác - ,
thí dụ Identification có giá trị 0x5850 )
--Flags
( tạm dich là "danh hiêu "của datagram. Thực tế chỉ có 3 loại Flag . Loại đầu ít dùng hay không dùng . Hai loại sau thừong dùng : DF và MF . Flags đóng vai trò quản lý cách thức phân đoạn ( fragment ) môt datagram
trong đó DF có nghĩa là " Không phân đoạn" ( Don't fragment )còn MF - phân đoạn hay More fragment
- 13-bit Fragment Offset
( chỉ rõ cho đến khi datagram này đươc gửi đi thì đã có bao nhiêu đơn vị -unit- đã đựoc gửi đi [rồi ] tính từ datagram đầu tiên -
- 8-bit TTL ( time to live ) .
( chỉ rõ datagram có "đủ sức ' vựot qua được bao nhiêu router trứoc khi nó tự hủy trên mạng - cũng có nghĩa là thời gian mà nó đựoc tồn tại trên mạng là bao lâu - thừong TTL có giá trị max là 255 )
-8-bit Protocol
( ở đây chính xác là Encapsulated Protocol - Encapsulation là cách thức môt ứng dụng ( Application ) khi đựoc truyền trên mạng áp dụng IP/TCP thì nó sẽ đựoc chuyển qua từng lớp ( layer ) của môt chồng lớp ( stack ) của giao thức như thế nào . Thừong áp dụng TCP Encapsulation Xin chú ý môt datagram đi qua mỗi lớp lại đựoc bổ sung , đươc gắn thêm môt số thông tin vào dữ liệu của nó , bằng cách thêm môt header hay có khi là môt footer , chứ không phải " đi như thế nào về như thế ấy " đâu nhé . Sẽ có môt bài viết cụ thể thêm về Encapsulation
-16-bit Header checksum
Như chúng ta đã bàn nhiều ở trên . Header checksum sử dụng để kiểm tra xem header có bị hư hỏng ( corrupted , thiếu sót gì không )
-32-bit Destination Address
Đia chỉ IP nơi gói tin datagram đưoc chuyển đến ( gồm 4 octet - mỗi octet có 8 bit )
-32-bit Source Address
Đia chỉ IP nơi gói tin datagram đưoc chuyển đi ( gồm 4 octet - mỗi octet có 8 bit )
-Option
Khi cần sẽ bổ sung thêm thông tin phụ trợ vào phần , trường ( field ) này
thí dụ record route , timestamp,loose source routing .... . Nhưng thừong thì phần ( trường ) này ít dùng, vì nhiều routers không chấp nhân option này ( sợ bị chèn malicious script trong datagram )
-Data
Các thông tin dữ liêu của datagram . Đây mới là nôi dung chính của datagram

Prof

Link Layer trong TCP/IP family còn gọi là Network Access Layer.
IP là một giao thức kiểu không liên kết (connectionless) có nghĩa là không cần có giai đoạn thiết lập liên kết trước khi truyền dữ liệu. Đơn vị dữ liệu dùng trong IP được gọi là datagram.
Một datagram là một gói dữ liệu độc lập, khác với các gói dữ liệu khác, đó là bản thân datagram đã đầy đủ thông tin bao gồm thông tin chọn đường từ nguồn tới đích, bởi vì không có một kênh thiết lập riêng do đó IP được gọi là thủ tục không liên kết.

QUOTE

--Flags
( tạm dich là "danh hiêu "của datagram. Thực tế chỉ có 3 loại Flag . Loại đầu ít dùng hay không dùng . Hai loại sau thừong dùng : DF và MF . Flags đóng vai trò quản lý cách thức phân đoạn ( fragment ) môt datagram
trong đó DF có nghĩa là " Không phân đoạn" ( Don't fragment )còn MF - phân đoạn hay More fragment
- 13-bit Fragment Offset
( chỉ rõ cho đến khi datagram này đươc gửi đi thì đã có bao nhiêu đơn vị -unit- đã đựoc gửi đi [rồi ] tính từ datagram đầu tiên -

+ Flags (3 bit). Trong đó bit 0, chưa được sử dụng, luôn lấy giá trị 0.
+ Fragment Offset (13 bits): chỉ vị trí của đoạn (fragment) ở trong datagram, tính theo đơn vị 64 bits, có nghĩa là mỗi đoạn (trừ đoạn cuối) phải chứa một vùng dữ liệu có độ dài là bội số của 64 bits.

Cụ thể như sau:

Mục đích của IP là cố gắng để đưa được gói dữ liệu tới hệ thống đích càng nhanh càng tốt. Các thiết bị mạng, ví dụ router, xử lý gói IP và xác định đường đi để đến được đích. Nếu gói dữ liệu mà một router nhận được quá lớn để có thể kiểm soát, khi đó nó sẽ được chia thành các gói nhỏ hơn, gọi là đoạn (fragment). Nhiệm vụ kết nối các đoạn này lại với nhau là nhiệm vụ của điểm đích. Cờ phân đoạn (Flag và fragment offset) trong IP header được sử dụng để phân đoạn và ghép nối.

Ngay khi đến, điểm đích nhận được đoạn đầu tiên, nó khởi động một bộ đếm gọi là bộ đếm ghép nối. Điểm đích phải nhận toàn bộ các đoạn từ gói IP ban đầu trước khi vượt ngưỡng thời gian cho phép (timeout). Nếu đã vượt ngưỡng thời gian mà điểm đích không nhận đủ tất cả các đoạn, một bản tin ICMP được khởi tạo và gửi cho điểm nguồn.

Hai trường này có vai trò rất quan trọng, đặc biệt trong chức năng kiểm soát nội dung (content-filter) của các firewall. Ta hoàn toàn có thể làm được chức năng này bằng cách dựa vào 2 trường trên để gom tất cả các mảnh lại và áp các luật lọc lên phần payload của nó.

QUOTE

-16-bit Header checksum
Như chúng ta đã bàn nhiều ở trên . Header checksum sử dụng để kiểm tra xem datagram có bị hư hỏng ( corrupted 0 , thiếu sót gì không )

chứa mã kiểm soát lỗi 16 bits theo phương pháp CRC, chỉ cho vùng header chứ ko phải cho toàn bộ datagram vì datagram = IP header + data.

QUOTE

-Data
Các thông tin dữ liêu của datagram . Đây mới là nôi dung chính của datagram

là vùng dữ liệu, có độ dài là bội số của 8 bits, và tối đa là 65535 bytes

All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children"

[Question] Re: Thảo Luận TCP/IP	17/07/2006 03:25:34 (+0700) \| #4 \| 7263

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Messages: 812
Offline

Bác PXMMRF

Link Layer trong TCP/IP family còn gọi là Network Access Layer.

Đúng như vậy Link Layer còn đựoc gọi là Network Access Layer. . Link layer thừong bao gồm các driver của cơ cấu hệ điều hành ( operating system device driver ) và card giao tiếp mạng . Vì vậy Link Layer có nhiệm vụ quản lý các phần cứng của hệ thống, mà các phần cứng này giao tiếp vật lý với mạng Internet .
Tuy nhiên cũng như các lớp phía trên nó ( Internet layer hay Network Layer , Transport Layer ..) , các gói tin tại Link layer cũng có 2 phần là header và body . Thí dụ trong trừong hơp hệ thống có Ethernet card , thì
ngừoi ta thừong gọi Link layer là Ethernet Layer và môt gói tin tồn tại trong Ethernet layer sẽ có 2 phần là :

Ethernet header và Ethernet body .

Ethernet Header có ( mang )môt số thông tin khá quan trọng như :

- Xác đinh gói tin (từ trên mạng gửi đến hệ thống nhân ) là loại gì : Nó ( chúng ) là IP packet hay là non-IP packet ( đựoc tạo lập bởi các giao thức không phải là giao thức IP , thí dụ NetBEUI , AppleTalk , Novell. Decnet hay IPX .. vân vân )

-Địa chỉ Ethernet ( Ethernet address ) của máy nguồn đầu tiên ( origin source machine ) hay đia chỉ của

Router cuối cùng trên đừong đi của gói tin từ máy nguồn đến đich .
- Đia chỉ Ethernet đến ( đich ) của gói tin
Địa chỉ Ethernet ( Ethernet address ) thừong đựoc biết như là MAC ( Media access control ) address

Tuy nhiên khó hay không thể áp dụng việc loc gói tin ( Packet filtering)
tại Ethernet layer này , mặc dù Packet Filtering Firewall về cơ bản dựa vào việc kiểm soát và xác định các header của gói tin tại từng Layer .

Sơ qua như vậy để ta thấy rõ thêm về Link Layer

QUOTE
Flags (3 bit). Trong đó bit 0, chưa được sử dụng, luôn lấy giá trị 0.
+ Fragment Offset (13 bits): chỉ vị trí của đoạn (fragment) ở trong datagram, tính theo đơn vị 64 bits, có

nghĩa là mỗi đoạn (trừ đoạn cuối) phải chứa một vùng dữ liệu có độ dài là bội số của 64 bits.
Cụ thể như sau:

Mục đích của IP là cố gắng để đưa được gói dữ liệu tới hệ thống đích càng nhanh càng tốt. Các thiết bị mạng, ví dụ router, xử lý gói IP và xác định đường đi để đến được đích. Nếu gói dữ liệu mà một router nhận được quá lớn để có thể kiểm soát, khi đó nó sẽ được chia thành các gói nhỏ hơn, gọi là đoạn (fragment). Nhiệm vụ kết nối các đoạn này lại với nhau là nhiệm vụ của điểm đích. Cờ phân đoạn (Flag và fragment offset) trong IP header được sử dụng để phân đoạn và ghép nối.

Ngay khi đến, điểm đích nhận được đoạn đầu tiên, nó khởi động một bộ đếm gọi là bộ đếm ghép nối. Điểm đích phải nhận toàn bộ các đoạn từ gói IP ban đầu trước khi vượt ngưỡng thời gian cho phép (timeout).

Nếu đã vượt ngưỡng thời gian mà điểm đích không nhận đủ tất cả các đoạn, một bản tin ICMP được khởi tạo và gửi cho điểm nguồn.

Hai trường này có vai trò rất quan trọng, đặc biệt trong chức năng kiểm soát nội dung (content-filter) của các firewall. Ta hoàn toàn có thể làm được chức năng này bằng cách dựa vào 2 trường trên để gom tất cả các mảnh lại và áp các luật lọc lên phần payload của nó.
Một trong những tính năng của IP là nó có khả năng chia môt gói tin lớn thành các gói tin nhỏ hơn . Sở di phải phân chia như vây vì gói tin lớn không vựot qua đựoc môt số cơ cấu nối mạng ( network link ), do các cơ cấu nối mạng này giới hạn cỡ gói tin (packet size ) có thể đi qua nó. Qúa trình phân chia như trên gọi là qúa trình phân đoạn gói tin (fragmentation ) và các gói tin nhỏ đựoc gọi là fragments . Các fragments
lưu chuyển trên mạng và không thay đổi trạng thái cho tới khi chúng đựoc kết hơp lại ( reassembled ) với nhau để tạo lại môt gói tin hoàn chỉnh (như lúc đầu trứoc khi phân đoạn ) tại máy đích ( destination machine )..
Flag ( trong header của IP datagram -packet ) xác định qúa trình phân đoạn đã đựoc IP tiến hành như thế nào đối với gói tin có header tương ứng . Vì vây Flags là môt "cờ hiệu " chứ không phải " cờ lệnh ' đối với IP tại Network Layer . Nó ( Flag) chỉ đựoc coi là môt "cờ lệnh " khi gói tin mang " Flag " này đi đến các routers nằm trên đừong tới máy đich . Thừong thì bất cứ môt router nào cũng có thể tư quyết đinh và thưc hiện môt quá trình phân đoạn gói tin qua nó . Nhưng môt gói tin ,có môt Flag (DF) trong IP header của nó , sẽ ngăn cản ( hay "ra lệnh" cho router không làm ) qúa trình phân đoạn tại router . Nhưng ....môt router " muốn " phân đoạn môt gói tin lại bị ngăn cấm do sư hiên diện môt "cờ lệnh " (Flag ) trong IP
header của gói tin , thì router sẽ .....nhất định phải hủy bỏ ( reject ) gói tin này , kết nối trên mạng sẽ đứt , ngừng trệ . Điều đó chẳng hay chút nào , thà rằng hay hơn là tiến hành phân đoạn gói tin từ trứoc, khi gửi nó từ máy lên mạng .
Kết nối trên mạng với các gói tin lớn không bị phân đoạn ( unfragmented ) hiêu qủa hơn nhiều so với trừong hơp phân đoạn gói tin . Viêc gửi đi các gói tin phân đoạn làm giảm tốc độ kết nối môt cách đáng kể . Chưa kể đến những trừong hơp mà môt qúa trình , thí dụ môt cuôc tấn công ( attack ) chỉ chứa đưng trong , hay nói cách khác là chỉ thưc hiên với mỗi môt gói tin nhỏ dung lựong 276 bytes , như trừong hơp I-worm SQL Slammer , thì viêc phân đoạn ( nếu làm như vây )gói tin SQL Slammer , qủa là qúa buồn cừoi
Vấn đề khó khăn là biết xác định cho cỡ gói tin lớn thế nào là vừa đối với môt mạng nào đó ??Vấn đề này đã đựoc giải quyết với sư ra đời hệ thống MTU trong nhưng năm gần đây . MTU ( maximum transmission unit tên đầy đủ path maximum transmission unit ) giúp xác đinh cỡ lớn nhất mà môt gói tin có thể đạt đến khi đựoc truyền qua môt mạng cụ thể .Trở lại vấn đề fragmentation . Khi qúa trình kết hơp các gói tin nhỏ phân đoạn ( fragments ) lại với nhau tại máy đich không thể thưc hiên đưoc thì máy đich sẽ gửi môt thông điêp ICMP ( ICMP message ) với nôi dung đại thể hay tương tư là " packet reassembly time expired " và gửi trả lại máy nguồn

Ở đây nói thêm là giao thức ICMP cũng như TCP , " tồn tại' ở Transport layer , ICMP đựoc sử dụng để hỗ trợ và thông báo tình trạng của IP( IP status ) .Cũng như TCP packet hay UDP paket ,ICMP packet đựoc " chứa "trong body của IP packet .Khi gói tin IPchứaICMP packet trong body của nó (gói tin iCMP này mang thông điêp " packet reassemblytime expired "như nói trên đây ) đến máy nguồn thì trứoc hết nó cũng phải chui vào Linklayer ( hay Ethernet Layer ) , rồi chui tiếp vào IP layer , rồi đến Transort Layer , thưchiên môt qúa trình Encapsulation và cứ qua mỗi môt lớp ( Layer ) thì gói tin bị "bócdần"từng header tương ứng .
Tôi không hiểu môt Internet user sẽ có cảm nghĩ gì khi nhân đựoc môt thông điệp ICMP nói trên . Nhưng đối với môt hacker thì đó là môt thông điệp tuyệt vời báo rằng qúa trình tấn công vào máy đích dùng DoS chẳng hạn , lơi dụng yếu điểm của quá trình phân đoạn
đã khợi sự thành công tốt đẹp .
Vâng qúa trình hay nói đơn giản là việc phân đoạn đã và ngày càng lộ ra những yếu điểm chết ngừoi,mà các hacker siêu hạng đang từng bứoc lơi dụng . Nào là các cuộc tấn công DoS vào máy đích đầy hiệu qủa dù máy đich có " đủ" Firewall" loại tốt". Nào là cách overlapping fragment làm rối loạn hệ điều hành và dễ dàng làm hệ thống sụp đổ...vânvân. Tôi sẽ có dịp viết kỹ thêm về vấn đề này .

QUOTE
là vùng dữ liệu, có độ dài là bội số của 8 bits, và tối đa là 65535 bytes.
Thưc ra môt gói tin có hai phần là header và body . Data chì là môt nôi dung trong body của gói tin , vì trong body còn có những header của các lớp ( Layer) trứoc đó mà gói tin đã từng chuyển vân qua .Khi mô tả cấu trúc và thành phần của môt gói tin thì phải xác đinh rõ là gói tin dang tồntại ở lóp nào ( Layer nào ) và gói tin ấy là gói tin đang đi vào hay đang đi ra khỏi hệ thống , không kể đến gói tin mang nhưng data gì và đựoc khơi tạo từ môt protocol nào .

All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children"

[Question] Re: Thảo Luận TCP/IP	17/07/2006 03:27:52 (+0700) \| #5 \| 7264

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Messages: 812
Offline

Prof

Điểm yếu của TCP/IP
TCP/IP Weak points

TCP/IP ra đời vào những năm đầu của thập kỉ 80, thời điểm mà vấn đề về an toàn bảo mật thông tin chưa được quan tâm đúng mức cả về phía thiết kế lẫn những attacker, hay nói cách khác nó chưa phải là vấn đề chính được quan tâm. Tuy nhiên, thực tế đã cho thấy những năm sau đó, việc thiếu tính bảo mật an toàn cho TCP/IP đã trở thành một vấn đề nghiêm trọng. Việc TCP/IP ngày càng trở nên phổ biến đã khiến cho nó phơi bày ra những điểm yếu hết sức nguy hiểm.

Trong bài viết này Prof không có tham vọng trình bày hết các điểm yếu của họ giao thức TCP/IP, mà chỉ liệt kê những điểm yếu có thể coi là nổi tiếng của cả TCP/IP và một số giao thức khác đi kèm với TCP/IP (ở đây RIP là một ví dụ).

1. TCP “SYN” Attack (SYN Flooding)
2. IP spoofing

Về điểm yếu 1, Prof nghĩ nhiều người đã biết, nên chọn điểm yếu 2 để trình bày. Điểm yếu này rất thú vị, nó được kế thừa, và "biến tướng" bởi một số phương pháp tấn công phổ biến hiện nay.
IP spoofing là một kiểu tấn công mà trong đó kẻ tấn công sẽ giả vờ gửi dữ liệu từ một địa chỉ không phải là của chúng. Tầng IP sẽ mặc định rằng địa chỉ IP nguồn của bất kỳ gói tin nào mà nó nhận được cũng chính là địa chỉ IP của hệ thống đã thực hiện việc gửi gói tin này, không có sự xác thực nào cả. Rất nhiều giao thức ở mức trên IP và các ứng dụng cũng không thực hiện xác thực điều này. Do vậy, một người nào đó hoàn toàn có thể giả mạo địa chỉ IP nguồn của một gói tin để đạt được quyền ưu tiên mà trước đó không được phép.
Để khai thác triệt để điểm yếu này, kẻ tấn công cần phải sử dụng giá trị TCP sequence number hợp lệ nếu muốn thiết lập một kết nối TCP với máy bị tấn công (hầu hết các dịch vụ thông dụng như Telnet, FTP, và r-command đều dựa trên TCP).
Trong header của TCP có 2 trường quan trọng cần phải nhắc tới, đó là:
Sequence Number (32 bits): số hiệu của byte đầu tiên của segment trừ khi bit SYN được thiết lập. Nếu bit SYN được thiết lập thì Sequence Number là số hiệu tuần tự khởi đầu (ISN) và byte dữ liệu đầu tiên là ISN+1. Tham số này có vai trò như tham số N(S) trong giao thức HDLC.
Acknowledgment Number (32 bits): số hiệu của segment tiếp theo mà trạm nguồn đang chờ để nhận. Ngầm ý báo nhận tốt (các) segment mà trạm đích đã gửi cho trạm nguồn – Tham số này có vai trò như tham số N® trong giao thức HDLC.
Về giao thức HDLC, có thể tham khảo tổng quan tại:
http://www.freesoft.org/CIE/Topics/122.htm
Cũng xin nhắc lại “một chút” cơ chế bắt tay 3 chiều của TCP để hiểu rõ vai trò của 2 trường này.
Như ta đã biết, TCP sử dụng cơ chế bắt tay 3 chiều để thiết lập kết nối giữa 2 máy muốn trao đổi dữ liệu. Khi một host A nào đó muốn “mở” một kết nối tới host B, thì trước tiên A phải gửi một segment khởi tạo (initial segment) tới B. Segment này chứa một giá trị quan trọng, gọi là ISN (Initial Sequence Number) cho phép B sử dụng để gửi dữ liệu cho A. Segment khởi tạo này được xác định bởi bit SYN được set lên 1 trong TCP header. Và nếu bit SYN được thiết lập thì trường Sequence Number sẽ chứa giá trị ISN này. Trong các trường hợp khác (khi bit SYN không được thiết lập), trường Sequence Number sẽ làm nhiệm vụ bình thường, như đã chỉ ra ở trên. Sau đó, nếu không có gì đặc biệt, phía B sẽ gửi thông tin SYN+ACK cho A, và A sẽ gửi lại một ACK hoàn tất việc bắt tay với B.
Tuy nhiên, gói tin ACK cuối cùng này, phải chứa số ISN của host B, bằng không thì kết nối sẽ không được thiết lập. Mặt khác, giá trị ISN trong gói tin SYN+ACK được gửi cho host A, kẻ tấn công bằng cách nào đó phải lấy được giá trị này, khi đó attacker này có thể hoàn tất việc thiết lập kết nối và kiểm soát việc giao tiếp với host B này.
3. Connection Hijacking (CH)
Là một “biến thể” của dạng IP spoofing, cho phép một host có thể tham gia vào giữa một kết nối giữa 2 host nào đó. Với kiểu tấn công IP spoofing có thể gặp trở ngại nếu một hệ thống nào đó được trang bị thêm mức bảo mật, chẳng hạn như xác thực bằng cơ chế xác thực username/password của UNIX, Kerberos… Nhưng với kiểu tấn công này, attacker hoàn toàn có thể vượt qua được quá trình xác thực giữa 2 host và sau đó nắm lấy phần kiểm soát kết nối giữa 2 host này.
CH khai thác trạng thái không đồng bộ (desynchronized state) trong TCP/IP. Khi số hiệu sequence number trong gói tin nhận được không giống với số hiệu trước đó, kết nối này sẽ ở trạng thái gọi là “desynchronized state”. Tuỳ thuộc vào số hiệu squence number thực sự nhận được, tầng TCP hoặc loại bỏ hoặc đưa gói tin này vào một buffer. Ở đây có một khả năng xảy ra, bởi vì TCP sử dụng cách thức cửa sổ trượt (sliding window) để đảm bảo việc truyền thông ngay cả trong trường hợp một gói tin nào đó bị thất lạc hay đến “trễ”. Vì thế, nếu gói tin nhận được không hợp lệ, nhưng vẫn trong phạm vi của cửa sổ trượt, gói tin này sẽ vẫn được lưu lại với giả thiết là gói tin hợp lệ sau đó sẽ đến (các cơ chế TCP khác nhau đều có cơ chế bảo đảm các gói tin đang ở trạng thái chờ cuối cùng cũng sẽ đến đích). Nếu gói tin nhận được nằm ngoài phạm vi của cửa sổ hiện hành thì nó sẽ bị huỷ.
Như vậy, khi 2 trạm tiến hành giao dịch với nhau mà đang ở trạng thái “desynchronized”, thì chúng sẽ bỏ qua tất cả các gói tin đến từ chúng. Kẻ tấn công sẽ lợi dụng điều này để chèn vào một gói tin giả mạo với số thứ tự (sequence number) hợp lệ. Trong trường hợp này, rõ ràng kẻ tấn công phải định vị được phiên truyền thông giữa 2 trạm để họ có thể “bắt” được các thông tin nhạy cảm trên, để từ đó lặp lại các gói tin đã được gửi. Vấn đề cỗi lõi của cách tấn công này là phải tạo ra trạng thái bất đồng bộ (desynchronized state).
Có 2 cách: đó là tạo ra trong quá trình bắt tay, và cách còn lại là tham gia vào giữa một kết nối đã được thiết lập. Về chi tiết cách tạo trạng thái bất đồng bộ nằm ngoài phạm vi bài viết này. Xin hẹn trong một bài viết khác.
Tuy nhiên, cũng xin lưu ý một điểm là khi một trạm nhận các gói tin với các squence number không phù hợp, nó sẽ reply cho trạm nguồn một gói tin ACK trong đó chứa squence number mà nó đang chờ nhận. Nhưng trạm nguồn này sẽ bỏ qua các ACK packet vì chúng chứa các giá trị sequence number không hợp lệ! Trạm nguồn này sau đó gửi ACK packet của nó để thông báo với sender. Như vậy, một số lượng lớn các ACK packet được sinh ra trong cách tấn công này. “Dấu hiệu” này có thể dùng để nhận biết kiểu tấn công connection hijacking.
4. Routing (RIP) Attack
Mặc dù không “chính thức” là một thành phần của TCP/IP, nhưng RIP (Routing Information Protocol) thường được coi là một thành phần “thiết yếu” trong TCP/IP network [RFC1058]. Một cách tổng quát, vai trò của RIP dùng để cung cấp các thông tin về đường đi trong các mạng, chẳng hạn như cung cấp thông tin về đường đi ngắn nhất, và quảng bá thông tin về đường đi từ mạng nội bộ tới các mạng khác. Giống như TCP/IP, RIP không xây dựng cơ chế xác thực, và các thông tin được cung cấp trong RIP packet thường được sử dụng mà không có sự kiểm tra nào. Việc tấn công vào RIP không giống với các cách tấn công thông thường bởi vì nó sẽ thay đổi đích đến của dữ liệu. Ví dụ, một kẻ tấn công có thể giả mạo một gói tin RIP, thông báo máy của attacker là đường đi nhanh nhất ra mạng ngoài. Khi đó, tất cả các gói tin gửi từ mạng đó sẽ bị điều hướng qua máy của attacker. Tại đây chúng có thể bị thay đổi, hay lấy cắp nội dung.
5. ICMP Attack
Tiêu biểu là kiểu tấn công Ping of Death nổi tiếng một thời, được áp dụng cho các HĐH Windows 95, WinNT 3.1.
6. Thiếu tính định danh duy nhất
Trước kia, một địa chỉ IP được dùng để định danh một host trên mạng. Tuy nhiên, do TCP/IP ngày càng trở nên phổ biến, dẫn đến không gian địa chỉ IP ngày càng trở nên bị thu hẹp. Đó là chưa kể đến các Firewall, Proxy server, Network Address Translator ngày càng trở nên phức tạp hơn để có thể sử dụng IP Address làm định danh để quản lý, chuyển đổi các địa chỉ IP giữa mạng nội bộ & mạng ngoài. Các host khác nhau có thể cùng chung một địa chỉ IP, hoặc các địa chỉ IP khác nhau có thể thuộc về cùng một host nào đó.
Vì thế, địa chỉ IP có thể sẽ không còn được dùng để định danh duy nhất một host nữa, thậm chí chỉ trong một khoảng thời gian ngắn nữa thôi.
Sequence Guessing
Có thể coi đây là một trường hợp con của IP Spoofing về bản chất, nhưng khác về cách thức thực hiện.
Do trường squence number trong TCP header là một số 32 bit nên việc đoán đúng giá trị ISN là rất khó và chậm. Tuy nhiên, nếu số hiệu ISN của một connection nào đó được chỉ định bằng một phương pháp nào đó có thể thuận lợi cho việc đoán trước, thì việc dự đoán sẽ trở nên dễ dàng hơn. Điểm yếu này được phát hiện đầu tiên vào năm 1985, khi Robert Morris mô tả cách dự đoán ISN trong phiên bản BSD 4.2. Trong BSD 4.2, giá trị ISN cho một kết nối được khai báo dưới dạng một biến đếm toàn cục. Theo đó, bộ đếm này sẽ tăng thêm 128 sau mỗi giây, và tăng thêm 64 sau mỗi một kết nối mới (chẳng hạn như bất cứ khi nào một giá trị ISN được khai báo).
Bằng cách ban đầu thiết lập một kết nối thật sự tới máy nạn nhân (victim), kẻ tấn công có thể xác định trạng thái hiện tại của bộ đếm của hệ thống. Sau đó, attacker sẽ biết được giá trị ISN kế tiếp được khai báo bởi victim sẽ tương tự như giá trị ISN đã xác định trước đó, cộng thêm 64.
Tuy nhiên, khi victim nhận được các gói tin giả mạo hoàn thành việc nhận gói tin SYN, nó sẽ gửi một gói tin SYN+ACK cho trạm bị giả mạo. Khi đó, trạm này sẽ loại bỏ gói tin SYN+ACK, vì nó chưa bao giờ khởi tạo một connection. Nó sẽ gửi một lệnh reset (RST) để thông báo tình trạng này, và kết nối của attacker sẽ bị bỏ qua.
Để tránh tình trạng này, kẻ tấn công có thể sử dụng cách tấn công SYN như đã nói ở bài trước để *làm ngập lụt* host mà nó đang mạo nhận. Khi đó, gói tin SYN+ACK được gửi bởi victim tới nó sẽ bị bỏ qua, cùng với bất kỳ gói tin nào khác vì bản thân nó lúc này đang ở tình trạng *ngập lụt*. Và bây giờ, attacker có toàn quyền để hoàn thành kết nối của nó với victim mà không sợ bị RESET giữa chừng.
Việc thường xuyên tăng bộ đếm ISN, như một số hệ điều hành khác đang thực hiện, dường như cũng không trợ giúp được gì nhiều trong việc hạn chế kẻ tấn công đoán được giá trị ISN. Ngay cả khi bộ đếm được tăng 250.000 lần trong một giây (như đề xuất trong chuẩn TCP), attacker vẫn có thể ước lượng được giá trị ISN. Bằng cách liên tục lặp lại việc dự đoán, kẻ tấn công có thể thiết lập được kết nối với một giá trị ISN hợp lệ chỉ trong một vài giờ đồng hồ.
ARP spoofing
Một trong những mối đe doạ được coi là lớn nhất đối với một mạng máy tính đó là một *kẻ lừa đảo* nằm trong hệ thống mạng của chúng ta giả vờ *thủ vai* như một trạm được tin cậy (trusted host). Một khi kẻ đó giả mạo thành công một trạm khác trong mạng để tham gia vào quá trình trao đổi thông tin thì hậu quả của nó thật khó mà lường hết được. Loạt bài trên Prof đã đề cập đến một số cách thức giả mạo dựa trên điểm yếu vốn có của TCP/IP. Trong bài này, Prof xin nêu thêm một kiểu tấn công phổ biến nữa, đó là ARP spoofing, dựa trên phân tích điểm yếu của giao thức ARP. ARP spoofing giới hạn phạm vi hoạt động trong một mạng cục bộ và khai thác cách các địa chỉ IP được chuyển đổi sang địa chỉ MAC.
Như ta đã biết, khi một IP datagram được gửi đi từ trạm này sang trạm khác trong cùng một mạng vật lý, địa chỉ IP của trạm đích phải được chuyển đổi sang địa chỉ MAC. Giao thức ARP sẽ giúp ta làm việc chuyển đổi này.
Khi một trạm muốn biết địa chỉ vật lý của trạm khác, nó sẽ gửi broadcast cho toàn mạng một frame có nội dung như sau:
CODE

01:20:14.833350 arp who-has 192.168.0.66 tell 192.168.0.62

Đây được gọi là một ARP request. Vì nó được gửi tới địa chỉ broadcast nên tất cả các Ethernet device trên một mạng cục bộ có thể nhận được request này. Trạm nào có địa chỉ IP phù hợp với ARP request thì nó sẽ trả lời bằng cách gửi một ARP reply:
CODE

01:20:14.833421 arp reply 192.168.0.66 is-at 0:0:d1:1f:3f:f1

Vì bản thân ARP request đã chứa địa chỉ vật lý của sender trong Ethernet frame nên receiver nhận được ARP request này hoàn toàn có thể trả lời cho sender mà không cần phải tạo một ARP request nữa. Tuy nhiên, điểm yếu lớn nhất của giao thức ARP là ở chỗ nó làm một stateless protocol, có nghĩa là nó sẽ không theo dõi các frame trả lời cho các request mà nó đã gửi, và vì thế sẽ chấp nhận các ARP reply mà trước đó không có request. Nếu một kẻ nào đó muốn lấy cắp thông tin từ một trạm khác, attacker sẽ gửi các ARP reply giả mạo phù hợp một địa chỉ IP nào đó đã chọn trước với địa chỉ MAC của chúng. Trạm nhận được các ARP reply giả mạo này không thể phân biệt được nó là ARP reply hợp lệ hay không, và bắt đầu gửi dữ liệu tới địa chỉ MAC của attacker(!).
Một điểm yếu nữa của giao thức ARP đó là bảng thông tin ARP được lưu trữ cục bộ tại mỗi trạm trong một mạng. Điều này nhằm mục đích tăng tốc độ truyền dữ liệu bởi vì địa chỉ MAC sẽ không cần phải kiểm tra mỗi lần một thiết bị này muốn liên lạc với một thiết bị khác. Một kẻ tấn công muốn tiếp tục giả mạo một địa chỉ IP nào đó, nó cần phải làm *ngập lụt* trạm đó với các ARP reply ghi đè lên các ARP hợp lệ từ trạm nguồn. Kiểu tấn công này thường được biết đến với cái tên ARP cache poisoning.
Có nhiều tool sử dụng kỹ thuật này để *thu bắt* thông tin trên các mạng dùng switch hoặc thực hiện kiểu tấn công *man-in-the-middle*, có thể đơn cử tool Ettercap. Tham khảo tại:
http://ettercap.sourceforge.net/
Để chặn luồng thông tin giữa 2 trạm A và B, trạm C sẽ đầu độc (poison) ARP cache của trạm A, làm cho nó *nhầm tưởng* là địa chỉ IP của trạm B giống với địa chỉ MAC của trạm C (chứ không phải là địa chỉ MAC của B). Sau đó C sẽ *poison* bộ cache của B, làm cho nó nhầm tưởng địa chỉ IP của trạm A tương ứng với địa chỉ MAC của C (chứ không phải địa chỉ MAC của A).

All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children"

[Question] Re: Thảo Luận TCP/IP	17/07/2006 03:29:04 (+0700) \| #6 \| 7266

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Messages: 812
Offline

Khắc phục điểm yếu
Problem with Authentication
Việc hoàn toàn thiếu tính xác thực cho các gói tin IP là điểm yếu chung nhất đối với TCP/IP.
Với việc không có cơ chế xác thực dẫn đến không có một sự bảo đảm nào cho biết gói tin này có xuất phát từ nguồn gốc thật sự của nó hay không. Đây chính là bản chất của tất cả các phương pháp tấn công giả mạo địa chỉ IP và cũng là điểm yếu chính của vấn đề bảo mật IP.
Preventing Sequence Guessing
Để một host A giả mạo thành công một host B trong việc thiết lập kết nối với host C, A phải có khả năng lấy được giá trị của trường sequence number mà C gửi trả lại (cho B). Có nhiều cách để thu được giá trị này, nhưng cách đơn giản nhất là đoán giá trị trường squence number sẽ được sử dụng. Nếu như ta có thể ngăn chặn được việc đoán giá trị tiếp theo của trường sequence number sử dụng trong một kết nối dựa trên số hiệu sequence number đã sử dụng trong một kết nối trước đó thì coi như ta có thể giải quyết được vấn đề này.
Ta sẽ lấy hệ thống của Berkeley để phân tích; phương pháp tăng bộ đếm của họ đã được trình bày ở trên: đó là tăng biến đếm chứa giá trị sequence lên một hằng số A sau mỗi giây và cũng tăng giá trị sequence lên với một hằng số (có giá trị bằng nửa A) đối với mỗi một kết nối đã ở trạng thái thiết lập. Tuy nhiên hệ thống của Berkeley không tuân theo các đặc tả của TCP yêu cầu bộ đếm cần phải được tăng khoảng 250.000 lần mỗi giây. Có lẽ nếu họ tuân theo các đặc tả của giao thức thì biết đâu có thể đã chống được kiểu tấn công sequence guessing.
Chúng ta cùng *ngâm cứu* xem liệu một bộ đếm được thay đổi liên tục với tần số 250.000 lần có giúp được gì cho vấn đề này. Để đơn giản, ta bỏ qua trường hợp các kết nối khác đang connect tới và giả thiết rằng tần số thay đổi bộ đếm này là không đổi.
Theo đặc tả thì giá trị ISN sẽ lặp lại sau 4.55 giờ. Vì giá trị trường TTL nhỏ hơn nhiều so với khoảng thời gian 4.55 giờ nên sẽ không gặp phải trường hợp trên mạng tồn tại hơn một segment có cùng giá trị squence number.
Muốn thu được giá trị sequence number hiện thời của một kết nối, trạm tấn công cần phải gửi một gói tin SYN và nhận gói tin phúc đáp. Gói tin giả mạo đầu tiên này (sẽ được dùng cho việc sinh giá trị squence number tiếp theo) có thể ngay lập tức tiếp theo sau gói tin phúc đáp của server cho gói tin SYN *thật*. Giá trị sequence number sử dụng trong gói tin phúc đáp của server được xác định duy nhất bằng khoảng thời gian từ lúc tạo thông điệp cho đến lúc server xác nhận thông điệp này. Nhưng con số này hoàn toàn là khoảng thời gian đi và về giữa attacker và server. Vì thế, nếu kẻ mạo danh tính toán (dự đoán) chính xác được khoảng thời gian này thì nếu có thay đổi bộ đếm trong phạm vi 4 phần triệu giây (khoảng thời gian chuẩn của đặc tả TCP qui định cho bộ sinh giá trị ISN) cũng không thể chống lại kiểu tấn công này. (Xem thêm RFC793, mục 3.3)
Như vậy, có thể thấy rằng việc áp dụng các đặc tả của giao thức TCP cũng chưa chắc đã ổn thoả. Vậy chúng ta phải làm gì? Theo Steve M.Bellovin, tác giả cuốn Firewalls & Internet Security, Second Edition, Addison Wesley, đưa ra đề nghị rằng chúng ta sẽ sử dụng một bộ sinh số ngẫu nhiên, với hi vọng sẽ làm cho việc phân tích giá trị sequence number sẽ khó khăn hơn. Bellovin cũng khuyến nghị sử dụng thuật toán mã hoá DES thay vì đơn thuần chỉ sử dụng bộ sinh số ngẫu nhiên để tăng mức độ khó cho việc dự đoán việc tăng giá trị sequence number. Dĩ nhiên là tất cả các phương pháp sinh số ngẫu nhiên đều cần phải được phân tích tỉ mỉ và nếu không có gì đặc biệt, một khi có được một phương pháp *đủ mạnh*, thì lúc đó ta sẽ có những giá trị squence khó đoán. Nói thế nào đi nữa, tốt nhất khi lựa chọn giải pháp ta nên tránh việc sử dụng những bộ sinh số sequence number đơn giản, dễ đoán là tốt nhất.
Sử dụng Firewall
Firewall có thể coi là một công cụ hữu hiệu trong việc phòng chống các kiểu tấn công giả mạo trên. Khoan nói đến các *proxy service* thông thường được nói đến như các firewall (mức ứng dụng), chúng ta sẽ tập trung vào những điểm mạnh của firewall được kế thừa từ các kỹ thuật lọc gói tin cơ bản.
Nhiệm vụ quan trọng của firewall nhằm chống lại kiểu tấn công giả mạo là chúng vạch ra ranh giới rõ ràng vùng bên ngoài (outside) firewall và bên trong (inside) firewall; những gì thuộc vùng inside phải qua cổng *inside* trên firewall, và những gì thuộc vùng outside phải đi vào qua cổng *outside*. Điều này có nghĩa là bộ lọc gói tin được cài đặt trong firewall sẽ làm nhiệm vụ lọc bỏ các gói tin bị coi là nguy hiểm. Giả sử bộ lọc này *nhận thấy* có một gói tin có nguồn gốc từ outside nhưng lại có địa chỉ IP nằm trong vùng inside. Đó đích thị là một gói tin giả mạo và cần phải lọc bỏ. Tương tự, nếu một gói tin nào đó có nguồn gôcs không thuộc vùng inside mà firewall quản lý, nó cũng có thể bị lọc bỏ ngay lập tức. Nói cách khác, kiểu lọc này phân chia mạng Internet ra thành các vùng nhỏ hơn mà trong đó không có vùng nào có thể giả mạo lẫn nhau được. Tuy nhiên, việc giả mạo trong nội bộ vùng inside thì firewall không thể ngăn chặn được.
Sử dụng TCP wrappers
Một phương pháp khác để *gia cố* cho điểm yếu về mặt xác thực của TCP/IP là sử dụng các chương trình TCP wrapper. TCP wrapper là một chương trình nhỏ chạy dưới dạng service và thường được khởi động bởi inet daemon. Ví dụ, nếu cài đặt TCP wrapper, khi một người dùng nào đó có ý định sử dụng rlogin thì chương trình rlogin chuẩn sẽ không chạy ngay; mà đầu tiên, một wrapper nhỏ sẽ chạy trước để thực hiện một vài chức năng *security* và nếu mọi việc sau đó được kiểm tra ổn thoả, chương trình rlogin mới thực sự hoạt động.
Bạn có thể download TCP Wrappers theo địa chỉ sau: ftp://ftp.cerias.purdue.edu/pub/tools/uni...pers_7.6.tar.gz
Lợi ích căn bản nhất thu được từ việc cài đặt các wrapper là chúng ta có thể ghi lại thông tin nhật ký như: ai đang yêu cầu dịch vụ gì, và theo dõi các hành vi đáng ngờ nào đó…Hiện tại, các TCP wrapper không chỉ đơn thuần chặn các user bất hợp pháp mà còn có thể truy vấn thêm thông tin về các user này để thu thập thêm thông tin nếu cần.
Các TCP wrapper chắc chắn không phải là một tấm lá chắn vững chắc; và thậm chí chúng không giúp ích được nhiều trong việc ngăn chặn các trường hợp giả mạo địa chỉ IP. Song xét về khía cạnh bảo đảm an toàn an ninh, chúng ít nhiều cung cấp một *rào cản* để chống lại những biến thể chung về vấn đề giả mạo và góp phần tạo thêm một khoảng cách bằng việc gia tăng thêm quá trình kiểm tra được chèn vào những nơi mà chúng có thể không được mong đợi.
Add-On authentication (Kerberos)
Một phương pháp khác để giảm thiểu khả năng giả mạo của kẻ tấn công là thêm quá trình xác thực ở tầng Application. Dĩ nhiên nếu chỉ thêm phần xác thực đơn thuần thì chưa đủ nếu không thêm phần mã hoá; mặt khác, sau quá trình xác thực mức ứng dụng, kiểu tấn công bắt cóc phiên (hijacking) vẫn có thể xảy ra. Rất may là vấn đề này có thể được giải quyết bởi hệ thống xác thực Kerberos (Kerberos Authentication System). Hệ thống Kerberos sử dụng mô hình client/server và cung cấp cơ chế xác thực user-to-server hơn là kiểu xác thực host-to-host đơn thuần. Một khi được cài đặt, hệ thống Kerberos sử dụng khoá phiên (session key) để mã hoá quá trình truyền của bất kỳ dịch vụ nào mà người dùng đó yêu cầu. Kẻ tấn công sẽ không thể giả mạo quá trình truyền tin nếu không biết khoá phiên này. Do khoá phiên được sinh ra dựa trên khoá mật (secret key) - là khoá mà chỉ người dùng thực sự và server được tin cậy (trusted server) biết đến nên việc lấy được khoá mật sẽ rất khó. Tuy nhiên, sẽ rất khó quản lý nếu như mỗi trạm trên mạng cần phải biết thông tin về khoá của tất cả các trạm khác nên cần thiết phải tồn tại một trusted host (nằm ở một nơi nào đó trên mạng), gọi là trung tâm phân phối khoá (Key Distribution Center - KDC) quản lý khoá cho tất cả các trạm trên mạng, hoặc một phần của một mạng nào đó. Theo đó, khi một trạm mới online, chỉ có KDC và trạm này cần phải cấu hình với khoá của nó; khoá có thể được phân phối một cách vật lý hoặc bằng các phương tiện bảo mật khác.
Ngoài ra, hệ thống Kerberos còn có khả năng chống lại kiểu tấn công phát lại (replay attack). Mặc dù còn một số vấn đề liên quan đến việc sử dụng hệ thống Kerberos để xác thực giữa 2 trạm làm việc nhưng nhìn chung Kerberos được xem như một phương pháp tăng cường an ninh hiệu quả cho các mạng máy tính.
Bài viết này không nhằm mục đích đi xâu vào hệ thống Kerberos. Muốn tìm hiểu chi tiết, bạn có thể tham khảo thêm về Kerberos tại:
http://web.mit.edu/kerberos/www/
http://acs.ucsd.edu/info/kerberos.php
Mã hoá từng gói tin IP (SKIP)
Thay vì phải trao đổi khoá phiên trong quá trình truyền tin như chúng ta đã bàn ở phần nói về Kerberos cho một phiên sử dụng dịch vụ telnet chẳng hạn, chúng ta có thể lựa chọn giải pháp mã hoá tất cả các gói tin IP tại tất cả các thời điểm ở tầng IP. Tất nhiên là giải pháp mã hoá này phải thống nhất theo một cách nào đó để phía đích có thể giải mã chúng một cách thành công. Hiện tại có một giải pháp thực hiện mã hoá mức *gói tin* (packet-level) được gọi là Simple Key Management for IP (SKIP). SKIP giả thiết rằng mỗi bên tham gia quá trình truyền tin đều có một khóa công khai (public key) dùng để tạo nhiều khoá giữa 2 phía. Ý tưởng cơ bản của thuật toán này là đóng gói packet-key (khoá để giải mã gói tin này) vào bên trong gói tin, và mã hoá nó với một khoá đã được thoả thuận giữa 2 bên (shared key). SKIP cũng cung cấp một phương thức trao đổi shared key giữa 2 phía. Vì phương pháp này không dựa trên từng phiên làm việc nên nó có thể áp dụng cho tất cả các loại truyền thông dựa trên TCP/IP.

Tham khảo thêm về SKIP tại:
http://www.tik.ee.ethz.ch/~skip/SKIP.html
http://www.garykessler.net/library/crypto.html
Detect ARP Spoofing
Để phát hiện kiểu tấn công này, ta có thể sử dụng chương trình Arpwatch, download tại:
http://www.mirrors.wiretapped.net/security...oring/arpwatch/
Chương trình này theo dõi thông tin vào/ra dưới chế độ promiscuous và ghi lại các cặp địa chỉ MAC/IP trong một khoảng thời gian nào đó. Khi thấy có hành vi bất thường, chẳng hạn như có sự thay đổi một trong các cặp MAC/IP mà nó đang theo dõi, chương trình sẽ gửi một cảnh báo tới syslog. Chương trình hoạt động hiệu quả đối với các mạng dùng HUB, vì một trạm hoàn toàn có thể theo dõi hoạt động của toàn mạng. Tuy nhiên, do cơ chế của ARP chỉ reply lại một gói tin duy nhất cho trạm cần gửi, nên chương trình này sẽ không hoạt động trong các mạng dùng switch.
Kết luận
TCP/IP, cho tới thời điểm hiện nay, đã cho thấy nó thiếu sự bảo mật nghiêm trọng. Một số kiểu tấn công như SYN flooding, IP Spoofing, Connection Hijacking, … đã chỉ ra rằng việc thiếu tính bảo mật này đã dẫn đến việc ra đời và phát triển của hàng loạt các công cụ và kỹ thuật khai thác nhằm vào các điểm yếu của TCP/IP. Việc *khắc phục* các lỗ hổng này là hoàn toàn có thể thực hiện được (với một số giải pháp đã trình bày như TCP Wrapper, Kerberos, SKIP…) nhưng nhìn chung chúng chưa được phổ biến rộng rãi, có thể máy tính của bạn đã cài đặt chúng nhưng chắc gì trạm mà bạn muốn trao đổi thông tin đã cài đặt những giải pháp trên. Như vậy, hầu như việc truyền thông trên Internet hiện nay vẫn chưa đủ mức an toàn cần thiết. Phải chăng đã đến lúc cần phải có một bộ giao thức mới, IPv6 chẳng hạn, để *fix* những thứ mà bản thân IPv4 không thể giải quyết được?!

All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children"

[Question] Re: Thảo Luận TCP/IP	17/07/2006 03:33:44 (+0700) \| #7 \| 7269

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Messages: 812
Offline

Bác Thangdiablo

To:forabetterlife

Như bạn đã biết, ở mỗi layer trong TCP/IP model người ta đều xây dựng một cơ chế kiểm sóat lỗi, mục đích là để kiểm tra xem packet có bị thay đổi trong quá trình truyền tin hay không?(tớ xin bỏ qua Ethernet checksum nhá :p).
Bạn xài tcpdump hay Ethereal gì đó, capture 1 UDP packet chẳng hạn. Rùi, nhảy zô IP Header, sẽ dòm thấy 1 field là: Checksum. Field này có kích thước là: 16bits.
Cách tính IP checksum:
Đầu tiên là ở phía sender. Bạn xem IP Header như là một chuỗi các bit 0, 1. Rùi, bây giờ chia cái chuỗi này ra theo từng “đọan”, mỗi đọan dài 16 bits.
Ví dụ: tớ có 1 chuỗi 0,1 thế này: 0110011001100110 0101010101010101 0000111100001111
Thực hiện phép cộng(nhị phân) ba từ này lại với nhau, được kết quả là: A = 100101011001010
Okie, bây giờ lấy phần bù của chuỗi A(cách lấy phần bù, chuyển bit 0 thành bit 1, bit 1 thành bit 0) ta được chuỗi B như sau: 0011010100110101. Okie, đem cái chuỗi này bỏ vào field Checksum của IP datagram gửi nó đi.

Ở phía receiver:
Thằng receiver sau khi nhận được datagram này sẽ tính lại checksum theo cách y như trên(khi tính tổng sẽ có 1 số hạng là Checksum do sender tính). Nếu như được kết quả là 16 bits 1 thì Header của IP datagram này không bị thay đổi gì so với khi gửi đi. Còn nếu như có 1 bit vứt luôn, không báo gì về cho thằng sender gói tin bị lỗi nào đấy bằng 0 biết cả .
Như vậy, bạn có thể thấy là mục đích của IP Checksum là kiểm tra xem Header của IP datagram có bị lỗi trong quá trình truyền hay không ?(khi tính toán ta chỉ quan tâm đến Header, không ngó ngàng gì tới phần data cả )

Cả đoạn bạn viết tớ hầu như không có ý kiến gì cả.Duy chỉ có câu này kiến tở hơi suy ghĩ 1 chút

Như vậy, bạn có thể thấy là mục đích của IP Checksum là kiểm tra xem Header của IP datagram có bị lỗi trong quá trình truyền hay không ?
Tớ cũng đã từng đọc 1 số tài liệu nói về checksum của IP.

Theo như tớ hiểu thì IP checksum không có nhiệm vụ kiểm tra lỗi trong quá trình truyền tải.Mà thực chất checsum của IP được gửi đi 1 cách rất thô thiển và nó chỉ có tác dụng là kiểm tra tính hợp lệ của gói IP.Nếu sau khi kiểm tra và so sánh checksum.Nếu hợp lệ thì nó sẽ nhận còn không nó sẽ deny.
Điều này cho thấy rằng Ip checksum không hề có chức năng sắp xếp các gói tin theo đúng thứ tụ , kiểm tra lỗi của các gói tin và kiểm soát các gói tin(sequencing,detection and fix erro) trong quá trình truyền tín hiệu.
Mà người làm nhiệm vụ này là thằng bạn thân của IP ..đó là giao thức ICP.

All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children"

[Question] Re: Thảo Luận TCP/IP	17/07/2006 03:36:55 (+0700) \| #8 \| 7271

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Messages: 812
Offline

Dưới đây là một vài câu hỏi,thảo luận và trả lời của một số bạn

Bạn Srono

: Em hiểu là cái checksum của IP datagram nó chỉ check cái IP header thôi chứ không tính data phía sau. Tại vì TCP, UDP, ICMP... đều có check sum riêng để check header và data của tụi nó rồi. Checksum này tính dựa trên header, thằng sender sẽ tính và fill cái field này rồi send đi. Khi receiver nhận được datagram này, nó tính lại và so sánh với checksum có sẵn -> quyết định bỏ hay không.
-> Theo em, như thế có nghĩa nó vẫn có tác dụng tìm được lỗi lúc truyền tải chứ (nhưng chỉ ở IP header thôi).
Nhưng khi nó discard ip datagram, thì cũng không có error message nào được tạo ra cả. Do đó xử lý thế nào là phụ thuộc vào bon phía trên (detect cái bị mất, yêu cầu gửi lại...).

Bạn Dabu:

Về vấn đề UDP thì , phần checksum có hơi vài điều khó hiểu , ví dụ để tính checksum UDP thì nó sẽ thêm vào một đầu giả (gồm 12octet(octet -8 bit) - một vài sách nói octet-là 4 bit thì sao , em không hiểu chổ này ???), có các trường IP source addess, IP destination address , zero , protocol , UDP length .
Trong đó vùng protocol = 17 cho UDP packet ,
Vùng UDP length chỉ chiều dài của cả phần header UDP và phần data của UDP .
Đặc biệt vùng zero là vùng toàn bit 0 phải không ?
Đầu giả UDP thì sẽ được gán vào UDP packet , sau đó nó tính checksum cho toàn bộ UDP packet + đầu giả này .
Nhưng trong quá trình truyền đi thì nó sẽ không đóng gói phần đầu này mà chỉ truyền UDP packet đi thôi .
Ở phía nhận thì khi nhận được UDP packet thì nó sẽ kết hợp với IP source address và IP destination và các vùng như trên để tính lại checksum phải không ? Nếu đúng thì nó sẽ chấp nhận gói packet này , không thì sẽ bị discard .
VẬy trong giao thức UDP thì nó cũng phải kết hợp với IP datagram để tính checksum cho UDP ???
va^ỵ vấn đề được nêu ra trong mô hình OSI thì các lớp làm nhiệm vụ độc lập nhau ? còn đúng nữa không ?
Trong khi pác prof đang tìm software tìm MAC của mạng LAN . Em xin trình bày các ý kiến tích lũy chung quanh về MAC .
MAC viết tắt bởi Medium Address Control Address , là địa chỉ dùng trong một mạng nội bộ (LAN) có 48 bit , được chia thành 12 octet (octet-4 bit ) thể hiện dưới dạng thập lục phân .
Đây là địa chỉ broadcast của mạng nội bộ : ff:ff:ff:ff:ff:ff : tức là khi ta muốn quảng bá thông tin của mình trên toàn mạng .
Khi các đầu cuối trong mạng vào trạng thái thực thi thì các thiết bị đầu cuối cùng trong mạng LAN sẽ tìm các địa chỉ MAC và địa chỉ IP tương ứng với địa chỉ MAC đó . Các request , reponse dùng các ARP packet để thông tin nhau .
Khi một đầu cuối trong mạng LAN được 'bật ' thì nó sẽ gửi một request hỏi địa chỉ IP tương ứng của địa chỉ MAC này là thế nào ? , nó sẽ broadcast trên toàn subnet , nếu các đầu cuối làm nhiệm vụ phân bổ các IP tương ứng (ví dụ như server DNS) thì nó sẽ trả lời lại là địa chỉ MAC này sẽ có địa chỉ IP như thế này .
Một điểm lưu ý là các request sẽ 'tự do' yêu cầu một response mà không cần một chỉ thị đặt biệt nào ? nên các attacker có thể giả mạo một request có địa chỉ IP giả hay địa chỉ MAC giả để broadcast đề tìm các thông tin mong muốn cho attacker .
Em không hiểu khái niệm LISTEN trên mạng .Có phải nó đang LISTEN trên card mạng của thiết bị đầu cuối đó không ? Các packet đi qua nó có thể bị capture phải không ?

Bạn Linet

Theo mình hiểu như thế này:

Khi A muốn trao đổi với B. A chưa biết IP của B, thì A sẽ gửi thông tin ARP request broadcast toàn mạng. Các máy trong cùng mạng đều nhận được gói tin broadcast này.

Xét ở mức vật lý, thì các "dao động sóng" ( thực ra đây là các tín hiệu tương tự đã được chuyển đổi từ tín hiệu số để có thể truyền trên các thiết bị, cable ). Ở đây thực ra các 'dao động' này được chuyển từ A đến thiết bị trung tâm ( hub, switch ), rồi các 'dao động' này được phát phân tán ra các host có nối vào thiết bị trung tâm này.
Như vậy các 'gói tin' đều đến được các host trong cùng mạng ( xác định bới thiết bị trung tâm ), sau khi gói tin broadcast này đi lên Layer vật lý, rồi đến layer datalink ( mà trong TCP/IP gọi chung là Network Access Layer ... ko biết nhầm ko nhỉ ). Sau đó nó sẽ làm phép so sánh xem địa chỉ MAC đích của gói tin này có trùng với địa chỉ MAC của mình không, nếu trùng nó sẽ cho gói tin đi tiếp lên IP layer xử lý lấy ra địa chỉ IP để đóng gói lại gửi cho máy yêu cầu, còn nếu ko trùng nó sẽ discard.
Còn việc capture thì thế nào nhỉ ? Mình cũng ko rõ có tool nào capture ngay từ data link layer không.

Bạn Prof

QUOTE
Về vấn đề UDP thì , phần checksum có hơi vài điều khó hiểu , ví dụ để tính checksum UDP thì nó sẽ thêm vào một đầu giả (gồm 12octet(octet -8 bit) - một vài sách nói octet-là 4 bit thì sao , em không hiểu chổ này ???), có các trường IP source addess, IP destination address , zero , protocol , UDP length .
Trong đó vùng protocol = 17 cho UDP packet ,
Vùng UDP length chỉ chiều dài của cả phần header UDP và phần data của UDP .

1 octet = 1 byte = 8 bits.
1 nibble = 1/2 octet = 4 bits.
Nếu có sách nào đó nói 1 octet = 4 bit thì tớ nghĩ là sai rồi.

QUOTE
Đặc biệt vùng zero là vùng toàn bit 0 phải không ?

Theo tớ hiểu thì trường zero trong UDP pseudo header được dùng cho mục đích *để dành* (reserve) (cho trường protocol chăng?) nên tạm thời chứa các giá trị 0.

QUOTE
MAC viết tắt bởi Medium Address Control Address , là địa chỉ dùng trong một mạng nội bộ (LAN) có 48 bit , được chia thành 12 octet (octet-4 bit ) thể hiện dưới dạng thập lục phân .

Tớ bổ sung thêm đôi điều nhé.
Trước hết, địa chỉ MAC còn được gọi với nhiều tên khác nhau: như hardware/NIC/built-in/Ethernet/Data Link address. Cấu trúc địa chỉ MAC này gồm 6 bytes (hay 6 octets) và thường được biểu diễn dưới dạng 12 chữ số hệ 16 (hecxa); 3 bytes đầu của địa chỉ MAC chứa mã của hãng sản xuất network card, còn được gọi là OUI (Organizationally Unique Identifier); 3 bytes tiếp theo là một số serial xác định duy nhất địa chỉ MAC này.

Ví dụ: 00:00:0C:12:34:56
Phần OUI: 00:00:0C (mã của hãng Cisco)
Phần serial: 12:34:56

QUOTE
Đây là địa chỉ broadcast của mạng nội bộ : ff:ff:ff:ff:ff:ff : tức là khi ta muốn quảng bá thông tin của mình trên toàn mạng .

Địa chỉ FF:FF:FF:FF:FF:FF chính xác được gọi là Ethernet broadcast address, hay còn gọi là địa chỉ quảng bá của tầng 2 - mô hình OSI. Địa chỉ quảng bá của tầng network, theo qui ước là: 255.255.255.255.
Phần còn lại, bạn linet đã giải đáp cho bạn rồi.

Còn việc capture thì thế nào nhỉ ? Mình cũng ko rõ có tool nào capture ngay từ data link layer không.

Bạn thử tcpdump, ethereal hay ettercap chưa?

All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children"

[Question] Re: Thảo Luận TCP/IP	17/07/2006 03:39:46 (+0700) \| #9 \| 7274

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Messages: 812
Offline

Và còn nữa nhưng khi tôi đọc đi đọc lại thì những nội dung này trùng lặp với những nội dung trên nên ko kèm vào đây
Hì hì,dưới đây là phần thêm mắm thêm muối của tui về địa chỉ Mac Address 1 chút,vì cả bài này trc kia chưa có dịp chọt vào
MAC address: 48 bit (6 byte, 3 byte đầu: IEEE , 3 byte sau: Vendor )

- Các topology khác nhau có cách định địa chỉ vật lý khác nhau

- Định những giá trị giúp các lớp bên trên nhận biết gói tin thuộc protocol nào (LLC – logical link control)

- Kiểm tra lỗi của frame (không sửa lỗi)

- Chuẩn Ethernet có 4 loại frame:
• Ethernet II
• IEEE 802.3
• IEEE 802.2 SAP
• IEEE 802.2 SNAP

Khởi đầu chuẩn 802.3 dùng 2 byte ngay sau “source address“để chứa chiều dài của frame (length field). Chuẩn này được phát triển bởi Novell nên Novell giả định protocol ở lớp trên là IPX ! (trong frame không cần giá trị giúp nhận biết protocol lớp trên vì đã được ngầm định là IPX).

Trái lại chuẩn Ethernet II dùng 2 byte này để nhận biết protocol lớp trên (type field).
Vậy bằng cách nào Ethernet II xác định được chiều dài của frame? Thật ra chiều dài của frame đã xác định ngay khi NIC controller capture được frame (nhờ vào cơ chế truyền frame: giữa 2 frame truyền có thời gian nghỉ tối thiển là 9.6micro giây, và dãy preamble – tham khảo thêm “Bên Trong Mạng Máy Tính” – Peter Norton).

Để frame 802.3 có thể truyền tải các protocol không phải IPX, IEEE (Institute of Electrical and Electronics Engineers ) đã định nghĩa thêm 2 tiêu chuẩn 802.2 SAP và 802.2 SNAP
• 802.2 SAP: dùng giá trị SAP (service access point) để nhận biết protocol lớp trên, ví dụ: SAP=0xE0:IPX, SAP=0x06: TCP/IP …
• 802.2. SNAP dùng giá trị “type” để nhận biết protocol lớp trên.

5-4-3 rule:
Tối đa 5 segment
Tối đa 4 repeater
Tối đa 3 segment có PC

All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children"

Go to:

Users currently in here
1 Anonymous