Sao bạn ko tìm tài liệu gì đó trên mạng mang về mà xem , sao cứ nhất thiết phải là bài thảo luận cua thangdiablo và conmale nhỉ , những kiến thức của các anh ấy thì cũng xuất phát từ sách vở mà ra  

Chào các bạn, ở box này bác conmale đang có 1 topic rất hay: Ký sự các vụ DOS HVA. Trong quá trình phân tích, bác có đưa ra khá nhiều khái niệm mới mẻ về TCP/IP, protocol stack… Việc nghiên cứu kỹ TCP/IP là yêu cầu bắt buộc đối với những người muốn đi sâu vào lĩnh vực networking. Các vị tiền bối đi trước đã bảo với tớ rằng: “Tất cả những khó khăn em gặp đều có thể giải quyết được nếu như em nắm vững TCP/IP và hiểu rõ bản chất của nó”. Các bạn có thể kiểm chứng câu nói này qua các bài viết của bác conmale.
Topic này không phải là để dạy dỗ, hay là tutorial gì. Các vấn đề về TCP/IP có lẽ các bạn nên tự tìm hiểu, nghiên cứu. Chủ đề này tớ sẽ post các câu hỏi, các vấn đề còn vướng mắc và khó hiểu trong quá trình tớ tìm hiểu TCP/IP. Và hi vọng là các bạn sẽ tham gia nhiệt tình.

Hôm nay tớ xin khai trương bằng mục Checksum, bao gồm: 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. gửi nóàOkie, đem cái chuỗi này bỏ vào field Checksum của IP datagram đ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 vứtà gói tin bị lỗi àgửi đi. Còn nếu như có 1 bit nào đấy bằng 0 luôn, không báo gì về cho 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ú ý:


có thể sẽ có IP Header nếu có thêm các thông tin trong phần Option trường hợp độ dài của IP Header sẽ không 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 Reiceiveràtính checksum sẽ bao gồm luôn cả phần data trong gói tin đó có thể phát 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 thằngàđường truyền. Nếu như Checksum nhận được tòan là bit 0 cả sender đã không tính 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ó

Hix, dài quá, nhưng đây là những gì em hiểu về Checksum. Em àxin các bác bổ sung ý kiến và liên hệ các trường hợp thực tế(nếu có) cái này thì em còn kém lắm. À còn nữa, em muốn hỏi trong 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 à ?



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.




QUOTE


Hix, dài quá, nhưng đây là những gì em hiểu về Checksum. Em xin các bác bổ sung ý kiến và liên hệ các trường hợp thực tế(nếu có) à cái này thì em còn kém lắm. À còn nữa, em muốn hỏi trong 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 à ?






Không, 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.




QUOTE


Hum nì đọc wa cái Evasion attack, hè hè, bít thêm được 1 cái nữa. Thằng NIDS không cóa cơ chế tính checksum -> gặp evasion attack gần như là bó tay, chặn không hết nổi . Kiểu này lại phải xài đến HIDS xem ra mới ngăn chặn được phần nào bọn Evasion attack nì nhỉ?





snort lo được chuyện evasion. Tuy nhiên phải thiết kế signature cho "chiến", không thì rất dễ bị false positive.

Ngoài ra trên application layers thì có nhiều tools khác có thể thể giúp hạn chế evasion. Ví dụ, mod_security cho apache thực hiện chuyện này khá ngon và độc hơn nữa là nó có thể dùng snort signatures (đã được chuyển hóa) để trị "evasive".



QUOTE


Hum nì cóa câu hỏi tiếp ạ. Vẫn là các field trong IP Header
greencool.gif (có chỗ nào hỏi hết ) greenbiggrin.gif .
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( greenbiggrin.gif )
- 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ó ???





Tự hỏi rồi tự giải thích hết rồi còn trả lời gì nữa?

"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 đó.




QUOTE


Ở bên trên là ý nghĩa(+ thắc mắc greenbiggrin.gif ) 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 greenbiggrin.gif. 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 ạ ?)





Đúng nhưng thiếu một tí. 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.




QUOTE


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 greenbiggrin.gif) 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)





Tại sao ngày nay người ta lại không dùng TOS field này nữa? Có chớ, 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.

Thay bằng cái mới?. 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.




QUOTE


Không biết là có hỏi nhiều quá không ? greenbiggrin.gif





Hì hì, lấy cái "cân" cân thử hỏi thế là nhiều hay ít


QUOTE


- 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.






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
 

Em xin phép bổ sung chút xíu về ftp : Khi truyền data thì mt = 1, còn khi control - truyền commands thì md = 1

Hì hì, bồ bổ sung thêm cũng đúng nhưng tớ nói là: protocol như ftp cho data chẳng hạn có nghĩa là tớ nhấn mạnh chỉ cho ftp data để xoáy vào TOS mt=1


Tôi bổ sung thêm đôi điều để các bạn tiện đừong thảo luận .

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


( Còn tiếp , bận qúa chưa viết thêm đưoc dù còn nhiều điều muốn viết lắm , xin cảm phiền )
Note : Đã sửa lại phần "Header checksum" cho thật rõ và chính xác :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 ) . Chỉ có trưòng Checksum trong TCP segment ( packet ) mới sử dụng để kiểm tra cả header và Data



Chào cả nhà,

Mình xin bổ sung thêm về bài của bác PXMMRF.




QUOTE


-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 )






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




QUOTE


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

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ớ"






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.



UOTE

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 IP chứa ICMP packet trong body của nó (gói tin iCMP này mang thông điêp " packet reassembly time 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 Link layer ( hay Ethernet Layer ) , rồi chui tiếp vào IP layer , rồi đến Transort Layer , thưc hiên môt qúa trình Encapsulation và cứ qua mỗi môt lớp ( Layer ) thì gói tin bị "bóc dầ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ân vâ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ồn tạ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 .



Cách đây khoảng 1 tuần, khi HVA chưa bị down bất chợt, prof có bàn luận với bác PXMMRF về TCP/IP.

Có thể tóm tắt nội dung cuộc thảo luận như sau:

Vấn đề vẫn còn đang tranh cãi là về vị trí của ICMP. Prof cho rằng nó vẫn còn là một bộ phận của IP, bác PXMMRF thì lấy dẫn chứng tài liệu của eEyE để chứng minh ICMP nằm ở TCP. Sau đó, bác conmale có lấy RFC ra để khẳng định ICMP không ở TCP.

Sau đó bác conmale có đưa ra cao kiến là chuyển sang thảo luận về điểm yếu của TCP/IP.

Ngay sau đó, đ/c mrro đã nêu ra điểm yếu đầu tiên của TCP/IP ở chỗ TCP/IP không được mã hoá và đưa ra giải pháp IPSec.

Em thấy chuyển sang bàn luận về điểm yếu của TCP/IP rất hay, nên quyết định post bài này.

Do trình độ và thời gian hạn chế, Prof xin chỉ đi xâu vào một số điểm yếu, có thời gian Prof sẽ bàn luận tiếp. Hi vọng nhận được sự góp ý, trao đổi của các bác.

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.


Trong bài dưới đây, Prof bổ sung thêm một điểm yếu nữa về ISN, không biết đây có phải là điểm yếu mà bác conmale định có thời gian sẽ viết hay không?

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ồ.

Vậy bằng cách nào để khắc phục điểm yếu này? Xin hẹn trong các bài viết sau.



Rất sẵn sàng. Trong khi chờ đợi mọi người, em post thêm một điểm yếu nữa vậy. Còn về cách khắc phục các điểm yếu này chắc phải....sau tết thôi. Lười quá

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).

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?!
 

cho em hỏi làm sao ở tầng transport biết gói tin đó phải truyền bằng udp hay tcp.