[Discussion] Em hỏi chút vấn đề về IP fragment |
29/08/2010 21:34:48 (+0700) | #1 | 219364 |
nucteiv
Member
|
0 |
|
|
Joined: 09/12/2008 01:22:01
Messages: 21
Offline
|
|
Em đang có chút thắc mắc về vấn đề IP fragment như sau, nhờ anh em giải đáp giúp:
Trước hết nói qua về IP fragment đã...
- Mục đích IP fragment: trong quá trình truyền trên mạng, vì mỗi đường truyền có MTU khác nhau nên cần phải chia nhỏ các packet và gửi đi, sao cho không vượt quá MTU tương ứng. Tại node nhận, các phần chia nhỏ sẽ được reassemble lại.
- Tình huống: Với một Static packet filter trên Router của một mạng nội bộ, Static packet filter xử lí các fragment này như thế nào? Hầu hết các static packet filter chỉ xem xét fragment có offset = 0, tức fragment đầu tiên, so sánh thông tin phần Header của IP packet với bộ luật của mình. Tất cả các fragment có offset != 0 đều được static packet filter cho qua mà không so sánh gì với bộ luật. Người đưa ra ý kiến này cho rằng, nếu fragment có offset = 0 chứa header của IP packet ban đầu mà bị static firewall chặn lại thì dầu các fragament khác có qua được chăng nữa thì khi vào đến host destination cũng sẽ host đó hủy bỏ do thiếu thông tin (không tái lập lại được packet ban đầu). Nghe cũng hợp lý phải không? Tuy nhiên, thật không may, do RFC của IP rất thoáng trong vấn đề Fragmentation, vì vậy đã có rất nhiều dạng tấn công, gọi chung là IP fragment attack, lợi dụng cách xử lí ở trên để vượt qua static packet filter. (Trích từ RFC)
Tuy nhiên, cũng có những dạng tấn công vào hệ thống dựa vào việc fragment các packet như: Tiny fragment attack, overlaping fragment attack,...
Một cách để hạn chế các tấn công kiểu này là lọc các fragment để kiểm tra cả những non-initial fragment packet như ví dụ sau đây:
Sau đây là một số tình huống xử lý của ACL 100 với các loại packet khác nhau (Ip của web server là 171.16.23.1)
Có ACL như sau:
access-list 100 permit tcp any host 171.16.23.1 eq 80
access-list 100 deny ip any any
Packet mà là một fragment khởi đầu (initial fragment) hoặc là một packet không bị fragment (non-fragment) được gửi tới server trên port 80:
Dòng đầu tiên của ACL chưa cả thông tin về Layer 3-4, khớp với thông tin về Layer 3-4 trong packet, vì thế packet được phép cho qua.
Packet là một fragment khởi đầu hoặc là một packet không bị fragment được gửi tới server trên port 21:
1. Dòng đầu của ACL chưa cả thông tin về Layer 3-4 nhưng thông tin Layer 4 trong ACL không khớp với packet, vì thế dòng ACL tiếp theo sẽ xử lý
2. Dòng thứ 2 của ACL sẽ deny mọi packet, vì thế packet bị chặn lại.
Packet là một fragment packet nhưng không phải gói tin khởi đầu (non-initial fragment) được gửi tới server trên port 80 :
Dòng đầu của ACL chưa thông tin về cả Layer 3-4, thông tin Layer 3 trong ACL khớp với thông tin trong packet, và hành động là permit vì thế gói tin được phép cho qua
Packet là một non-initial fragment được gửi tới server trên port 21 :
Dòng đầu tiên của ACL chưa cả thông tin về Layer 3-4, thông tin Layer 3 trong ACL khớp với thông tin trên packet, không có thông tin về Layer 4 trong packet này, và hành động của ACL là permit, vì thế packet sẽ được phép qua.
Tiếp theo, khi sử dụng thêm tham số fragment để kiểm tra các non-initial fragment packet thì sẽ như sau :
access-list 101 deny ip any host 171.16.23.1 fragments
access-list 101 permit tcp any host 171.16.23.1 eq 80
access-list 101 deny ip any any
Packet là một fragment khởi đầu hoặc là một packet không bị fragment gửi tới server trên port 80:
1. Dòng đầu tiên của ACL chưa thông tin Layer 3 khớp với thông tin Layer 3 trên packet. Hành động của dòng ACL này là deny nhưng vì có từ khóa fragments (kiểm tra các non-initial fragment) nên ACL tiếp theo sẽ xử lý tiếp.
2. Dòng thứ 2 của ACL chưa thông tin về Layer 3-4, khớp với thông tin trên packet, vì thế packet được cho qua
Packet là một fragment khởi đầu hoặc packet không bị fragment gửi tới server trên port 21:
1. Dòng đầu tiên của ACL chưa thông tin Layer 3, khớp với packet nhưng ACL entry cũng có từ khóa fragment, không khớp với packet này vì Fragment Offset = 0, vì thế ACL tiếp theo sẽ xử lý
2. Dòng thứ 2 của ACL chứa thông tin Layer 3-4, trong trường hợp này, thông tin Layer 4 không khớp, vì thế ACL entry tiếp theo sẽ xử lý
3. Dòng thứ 3 của ACL sẽ deny mọi packet, vì thế packet bị chặn lại
Packet là một non-initial fragment gửi tới server trên port 21:
Dòng ACL đầu tiên chỉ chứa thông tin Layer 3, và nó khớp với thông tin trên packet, vì tehes packet bị chặn lại.
Packet là một non-initial fragment gửi tới server trên port 80:
Dòng ACL đầu tiên chưa thông tin Layer 3 khớp với thông tin Layer 3 trong packet. Nhớ rằng mặc dù đây là thành phần của luồng lưu lượng gửi tới server trên port 80, nhưng lại không có thông tin Layer 4 trong non-initial fragment này. Packet sẽ bị từ chối vì thông tin Layer 3 là khớp với ACL. <- Như vậy việc chặn các fragment là có vấn đề không? Vì khi các non-initial fragment gửi tới server trên port 80 bị chặn (mặc dù đây là những phần fragment phía sau của luồng lưu lượng hợp lệ gửi tới server trên port 80) thì sẽ không reassemble được ở node nhận. -> như vậy là không cho phép các lưu lượng mà bị fragment vào trong mạng để tới websever nhưng thực tế là vẫn cần fragment vì trải qua các đường truyền có MTU khác nhau -> Đó chính là điều em đang thắc mắc ? (lọc các non-initial fragment nhưng nếu thế thì các packet mà bị fragment sẽ không được cho phép đi vào sever, mà việc fragment thì vẫn cần thực hiện chứ nhỉ?) |
|
|
|
|
[Discussion] Em hỏi chút vấn đề về IP fragment |
30/08/2010 21:27:33 (+0700) | #2 | 219435 |
eff3
Member
|
0 |
|
|
Joined: 06/07/2010 09:30:32
Messages: 24
Offline
|
|
Túm lại là mình thấy nhận xét rồi câu hỏi của bạn tương đôi mâu thuẫn ...
Mình nghĩ tốt nhất là bạn nói cụ thể ra mấy cái Tiny fragment attack, overlaping fragment attack,... là như thế nào ... rồi mới tính đến chuyện áp dụng mấy cái rules để chặn.
Hoặc nếu mình ko hiểu lầm thì bạn đang thắc mắc làm thế nào để chặn traffic của attack còn legitimate traffic thì cho qua? |
|
|
|
|
[Discussion] Em hỏi chút vấn đề về IP fragment |
30/08/2010 22:40:58 (+0700) | #3 | 219440 |
nucteiv
Member
|
0 |
|
|
Joined: 09/12/2008 01:22:01
Messages: 21
Offline
|
|
eff3 wrote:
Túm lại là mình thấy nhận xét rồi câu hỏi của bạn tương đôi mâu thuẫn ...
Mình nghĩ tốt nhất là bạn nói cụ thể ra mấy cái Tiny fragment attack, overlaping fragment attack,... là như thế nào ... rồi mới tính đến chuyện áp dụng mấy cái rules để chặn.
Hoặc nếu mình ko hiểu lầm thì bạn đang thắc mắc làm thế nào để chặn traffic của attack còn legitimate traffic thì cho qua?
Đúng rồi, í mình thắc mắc là theo như bài trên thì có cả những lưu lượng phù hợp mà đáng nhẽ là được phép (nhưng vì bị fragment nên lại bi deny) như trường hợp dưới đây:
Packet là một non-initial fragment gửi tới server trên port 80:
Dòng ACL đầu tiên chưa thông tin Layer 3 khớp với thông tin Layer 3 trong packet. Nhớ rằng mặc dù đây là thành phần của luồng lưu lượng gửi tới server trên port 80, nhưng lại không có thông tin Layer 4 trong non-initial fragment này. Packet sẽ bị từ chối vì thông tin Layer 3 là khớp với ACL.
-> Vậy thì dùng thêm từ khoá fragment trong ACL kia là có vấn đề với nhưng lưu lượng bị fragment rồi???
Còn Tiny fragment attack, overlaping fragment attack thì mình cũng nắm được cơ chế của nó rồi.
link tham khảo bài viết gốc: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800949b8.shtml#howtomatch
|
|
|
|
|
[Discussion] Em hỏi chút vấn đề về IP fragment |
30/08/2010 23:38:46 (+0700) | #4 | 219442 |
eff3
Member
|
0 |
|
|
Joined: 06/07/2010 09:30:32
Messages: 24
Offline
|
|
nucteiv wrote:
-> Vậy thì dùng thêm từ khoá fragment trong ACL kia là có vấn đề với nhưng lưu lượng bị fragment rồi???
tất nhiên, bình thường sau khi bị fragmented ở đâu đó, thì ip ở đầu nhận sẽ có nhiệm vụ ghép cái đống fragments này lại hoàn chỉnh rồi cắt cái ip header đi rồi gửi phần data (tcp header + data) cho tcp làm việc tiếp theo. Có nghĩa là ở đây mình nghĩ nếu bạn muốn chặn attack bạn chỉ có thông tin ở cái ip header và mấy cái protocols bên ngoài thôi. Còn những thông tin liên quan đến transport layer thì chịu thế nên việc đặt mấy cái điều kiện port trong ACL xem như ko phải là giải pháp hiệu quả
nucteiv wrote:
Còn Tiny fragment attack, overlaping fragment attack thì mình cũng nắm được cơ chế của nó rồi.
bạn có thể tóm tắt qua cho mình xem những kiểu tấn công này dc ko?
|
|
|
|
|
[Discussion] Em hỏi chút vấn đề về IP fragment |
31/08/2010 23:52:56 (+0700) | #5 | 219480 |
nucteiv
Member
|
0 |
|
|
Joined: 09/12/2008 01:22:01
Messages: 21
Offline
|
|
eff3 wrote:
nucteiv wrote:
-> Vậy thì dùng thêm từ khoá fragment trong ACL kia là có vấn đề với nhưng lưu lượng bị fragment rồi???
tất nhiên, bình thường sau khi bị fragmented ở đâu đó, thì ip ở đầu nhận sẽ có nhiệm vụ ghép cái đống fragments này lại hoàn chỉnh rồi cắt cái ip header đi rồi gửi phần data (tcp header + data) cho tcp làm việc tiếp theo. Có nghĩa là ở đây mình nghĩ nếu bạn muốn chặn attack bạn chỉ có thông tin ở cái ip header và mấy cái protocols bên ngoài thôi. Còn những thông tin liên quan đến transport layer thì chịu thế nên việc đặt mấy cái điều kiện port trong ACL xem như ko phải là giải pháp hiệu quả
---> Không, ý mình là nếu gói tin bình thường thì các thông tin về layer 3 và layer 4 sẽ nằm đủ trong initial fragment và nếu lọc là permit thì các gói tin đó sẽ được vào trong. nhưng vấn đề là nếu cũng lọc với từ khoá "fragment" thì các gói tin tiếp theo (các gói non-initial fragment) của luồng ở trên (initial fragment) có thể sẽ bị deny ---> như thế node nhận sẽ không reassembler lại được đủ dữ liệu ban đầu mà bên gửi muốn truyền tới rồi.
vậy mà cisco lại recommend là nên lọc ip fragment là sao nhỉ???
nucteiv wrote:
Còn Tiny fragment attack, overlaping fragment attack thì mình cũng nắm được cơ chế của nó rồi.
bạn có thể tóm tắt qua cho mình xem những kiểu tấn công này dc ko?
[color=red]Mình thấy một bài viết của ai đó trên mạng cũng mô tả khá rõ như sau (xin phép copy cho tiện):
*Tiny Fragment Attack: đây là dạng tấn công bằng cách chia thật nhỏ và (thật khéo) IP packet ban đầu ra thành từng fragment rất nhỏ, sao cho một phần thông tin của TCP header nằm trong IP packet ban đầu nằm trong fragment thứ hai. Do static packet filter chỉ kiểm tra fragment có offset = 0, và với bộ TCP header đã bị chia ra như vậy, khả năng static packet filter lọc sót ra rất lớn. Trong thực tế đã có những công cụ sử dụng Tiny Fragment Attack để vượt qua Static Packet Filter.
*Overlapping Fragment Attack: tại host destination, sau khi nhận đủ các fragment từ một packet ban đầu (bằng cách nhìn vào field MF và tính tổng cộng chiều dài của các fragment đã nhận được), công việc tái lập packet ban đầu sẽ bắt đầu. Rất không may là thuật toán tái lập nằm trong RFC của IP hiện tại cho phép các fragment có thể ghi đè lên nhau. Kẻ tấn công gửi fragment đầu tiên (offset = 0) với đầy đủ thông tin hợp lệ để vượt qua static packet filter, sau đó sẽ dùng các fragment tiếp theo (offset !=0, không bị kiểm tra bởi static packet filter) để ghi đè lên vùng thông tin header của fragment đầu tiên. Ví dụ như kẻ tấn công muốn xâm nhập vào mail server tại host A được bảo vệ bởi một static packet filter F. Ngoài mail server, host A còn đóng vai trò web server, F cho phép kết nối từ ngoài vào web server nhưng cản tất cả kết nối vào mail server. Kẻ tấn công sẽ tạo ra fragment đầu tiên có source port = 12345, và dest port là 80, giả sử fragment này có chiều dài là 30 bytes. Fragment này sẽ được F cho qua. Fragment thứ 2, lẽ ra phải có offset=30, tuy nhiên, kẻ tấn công cố tình chỉnh offset lại bằng 26, và chính 4 byte này đủ để kẻ tấn công có thể overwrite giá trị dest port từ 80 thành 25
[/color] |
|
|
|
|
[Discussion] Em hỏi chút vấn đề về IP fragment |
03/09/2010 23:23:33 (+0700) | #6 | 219634 |
nucteiv
Member
|
0 |
|
|
Joined: 09/12/2008 01:22:01
Messages: 21
Offline
|
|
các bác giúp em chút ý kiến đóng góp với ạ? |
|
|
[Discussion] Em hỏi chút vấn đề về IP fragment |
06/09/2010 07:56:21 (+0700) | #7 | 219991 |
nucteiv
Member
|
0 |
|
|
Joined: 09/12/2008 01:22:01
Messages: 21
Offline
|
|
Chắc dạo này cuối năm các bác bận quá không vào hva mấy thì phải ? |
|
|
Users currently in here |
1 Anonymous
|
|
Powered by JForum - Extended by HVAOnline
hvaonline.net | hvaforum.net | hvazone.net | hvanews.net | vnhacker.org
1999 - 2013 ©
v2012|0504|218|
|
|