những cổng dành riêng cho các dịch vụ thiết yếu, không có cách nào để thực hiện việc lọc theo loại dịch vụ. Một giải pháp cuối cùng là chúng ta có thể lọc toàn bộ giao vận tới một hoặc một số máy (host) trên mạng nhằm bảo vệ toàn bộ mạng khỏi bị tê liệt. Điều này có thể thực hiện được do phần lớn các cuộc tấn công đều nằm vào một hoặc một số máy cụ thể nào đó. Nếu tấn công hướng tới toàn mạng, lọc theo địa chỉ đích cũng không thể nào thực hiện được. Cài đặt các bộ lọc (phần cứng hay phần mềm) phù hợp sẽ loại bỏ được phần lớn các cuộc tấn công. Tuy nhiên, phương pháp này cần phải thực hiện tại các ISP chuyển tiếp, ít nhất là cách mạng Internet trục ít nhất là một bước (hop) so với mạng của máy bị tấn công. Một bất tiện khác là phương pháp này cần sự hỗ trợ của các chuyên viên công nghệ của các ISP nên tốn khá nhiều thời gian. Để loại bỏ sự bất tiện này, chúng ta có thể xem xét một giải pháp khác, cho phép khách hàng có thể tự bảo vệ mình trong mạng của các ISP. Lọc theo địa chỉ đích Chúng ta xem xét cách lọc theo địa chỉ đích, một cách thức có thể thực hiện được tương đối dễ dàng. Muốn vậy, các ISP phải trao cho các khách hàng các công cụ cần thiết bằng việc tạo một cộng đồng (community) BGP có nhiệm vụ chuyển các giao vận dành cho một phạm vi địa chỉ đã được quảng bá trước tới một giao diện trống (null interface). Khách hàng, cùng với các lệnh thông báo về việc chặn địa chỉ , sẽ thông báo tới cộng đồng "hố đen" này một tuyến (route) /32. Tất cả các route /32 này sau đó sẽ được gửi tới giao diện trống. Route /32 đóng vai trò như một BGP-speak cho một địa chỉ IP đơn và các cộng đồng sẽ được đánh nhãn để chỉ ra rằng cần được "đối xử" một cách đặc biệt nào đó. Trong trường hợp này, "đối xử" đó là cần phải loại bỏ tất cả các giao vận tới địa chỉ IP đã thông báo. Bản đồ tuyến (Route map) trong một hệ thống sử dụng thiết bị của Cisco có thể như sau: ip community-list 13 permit 65000:13 ! route-map customer-in permit 10 match community 13 set ip next-hop 13.13.13.13 ! Route map này sẽ đặt địa chỉ bước kế (next hop) cho tất cả các tuyến gắn với community 65000:13 thành 13.13.13.13 (Một community thường được định danh với một giá trị 32 bit được phân thành 2 phần, trong đó phần đầu thường là chỉ số của Hệ tự quản (Autononous System) của mạng mà cộng đồng đó phụ thuộc). Route map này sẽ được áp dụng đối với mọi phiên BGP của khách hàng. Điều này còn buộc các bộ định tuyến (router) phải kiểm tra tham số cộng đồng trong mọi thông điệp cập nhật định tuyến (routing update) nhận được từ khách hàng và thay đổi địa chỉ đích tương ứng tới địa chỉ đặc biệt 13.13.13.13. Tại tất cả các bộ định tuyến trên mạng, các gói có địa chỉ đích 13.13.13.13 sẽ được chuyển tới giao diện trống và được loại bỏ. ! ip route 13.13.13.13 255.255.255.255 Null0 ! Trong thực tế, bạn có thể sử dụng một địa chỉ khác thay cho địa chỉ 13.13.13.13 như trong thí dụ trên. Khi cài đặt có hiệu lực, tất cả giao vận hướng tới địa chỉ "hố đen" sẽ ngay lập tức bị loại bỏ ngay khi mới tiến vào mạng. Không như các bộ lọc chống DoS khác được áp dụng tại giao diện của khách hàng, các giao vận trước tiên được chuyển tiếp qua mạng của ISP tới router kết nối với khách hàng và loại bỏ ở đó. Lợi ích chính của phương pháp này là khách hàng có thể khởi xướng việc lọc bất cứ lúc nào, không phụ thuộc vào sự phối hợp của ISP (Tất nhiên, khách hàng không được thông báo các địa chỉ không phải của họ với cộng đồng "hố đen", nếu không họ sẽ lọc cả các giao vận thuộc về người khác. Việc lọc phiên BGP của khách hàng đều đặn theo thời gian sẽ đảm bảo điều này) . Lọc theo địa chỉ nguồn với Unicast RDF Bởi việc định tuyến phải sử dụng tới địa chỉ đích, việc lọc theo địa chỉ đích tương đối đơn giản. Lọc theo địa chỉ nguồn cũng không thành vấn đề khó khǎn nếu chúng ta triển khai kiểm tra Chuyển tiếp đường ngược Unicast (unicast reverse path forwarding -uRPF) của Cisco. uRPF sẽ nhận địa chỉ nguồn của các gói tin được chuyển tới cho bộ định tuyến và so sánh nó với thông tin trong bảng CEF, một bản sao của bảng định tuyến sử dụng cho việc chuyển tiếp gói ở tốc độ cao. Các gói tin chuyển tới một giao diện (interface) của bộ định tuyến mà qua giao diện đó, bộ định tuyến không thể đến được địa chỉ nguồn sẽ bị xem không hợp lệ và bị loại bỏ. uRPF làm việc rất tốt đối với các giao diện kết nối với các mạng được định nghĩa chặt chẽ (well defined) và cũng làm việc tốt đối với các mạng ngang hàng (qua đường kết nối riêng hoặc Internet) nhưng nó không thực sự hiệu quả đối với những kết nối tới ISP cung cấp dịch vụ quá cảnh (transit service) bởi những ISP này theo mặc định sẽ phát chuyển mọi gói tin đến từ tất cả các địa chỉ trên mạng. uRPF cũng không thể sử dụng với 2 ISP: một gói tin với một địa chỉ nguỗn ác định có thể được chuyển đến qua bất kỳ ISP nào nhưng bộ định tuyến chỉ xem một ISP là địa chỉ nguồn hợp lệ của gói tin này. Với uRPF và sử dụng cùng một community như thí dụ trên, chúng ta có thể lọc theo địa chỉ nguồn: ! interface Serial0 ip verify unicast reverse-path ! Cộng đồng đảm bảo rằng địa chỉ sẽ được định tuyến tới giao diện trống và các gói tin với địa chỉ nguồn xác định chỉ được chấp nhận trong trường hợp tới từ giao diện trống. Bởi các giao vận tấn công thường tới từ một địa chỉ khác, phương pháp này rất hiệu quả khi uRPF còn được kích hoạt. Còn có một dạng uRPF khác, gọi là uRPF lỏng, không kiểm tra nơi gói tin được chuyển đi mà chỉ xem địa chỉ nguồn có tồn tại trong bảng định tuyến hay không. Loại uRPF này có thể được kích hoạt cho tất cả các giao diện bởi chúng không phá vỡ việc định tuyến bất đối xứng (vấn đề thường gặp đối với 2 ISP) và có thể sử dụng rất hiệu quả trong trường hợp này. Sử dụng hộp lọc (filter box) Một giải pháp khác có thể áp dụng là sử dụng các hộp lọc trên mạng như trong hình dưới đây: Bất cứ khi nào địa chỉ khách hàng bị tấn công, khách hàng sẽ thông báo địa chỉ của mình cho community được xác lập như trong thí dụ đầu tiên. Thay vì thay đổi địa chỉ bước kế thành một địa chỉ không thể tới được, địa chỉ bước kế được đặt là địa chỉ của hộp lọc. Tất cả giao vận tới máy đang bị tấn công sẽ được chuyển tới hộp lọc và chỉ giao vận nào không thoả mãn điều kiện lọc mới được chuyển tiếp tới khách hàng. Một số ưu và nhược điểm của phương pháp này ưu điểm: + Không cần các thao tác NOC + Không giảm hiệu suất vận hành trên mạng + Không cần phần cứng hay giao thức đặc biệt + Khách hàng được quyền kiểm soát hoàn toàn + Khách hàng được tách biệt rõ ràng trong một mạng đang vận hành Nhược điểm: + Không đối phó được với sự giả mạo địa chỉ nguồn trên qui mô liứn + Cần thêm phần cứng Bởi các bộ định tuyến khác nhau trong mạng của ISP sử dụng các điạ chỉ trạm kế khác nhau đối với địa chỉ đang bị tấn công (trong thí dụ trên, bộ định tuyến 1 gưỉ gói tin tới hộp lọc, bộ định tuyến 2 gưi gói tin tới khách hàng) nên cần phải cấu hình lại bản đồ định tuyến (route map) cho các phiên iBGP. Nếu việc cấu hình gặp khó khǎn, giao vận có thể được gửi từ hộp lọc tới khách hàng qua một đường hầm (tunnel). Trên hộp lọc chúng ta sẽ không gặp vấn đề gì khó khǎn khi sử dụng "phương án hố đen" BGP và kiểm tra uRPF để lọc theo địa chỉ nguồn như trong thí dụ trên. Khách hàng có thể có thêm một phiên BGP tới hộp lọc để thông báo về các địa chỉ nguồn cần lọc. Bởi vì chỉ các giao vận tấn công mới được tái định tuyến qua bộ lọc, điều này về cơ bản sẽ tạo nên điều kiện lọc kết hợp cả địa chỉ nguồn và địa chỉ đích. Chúng ta hoàn toàn có thể tạo các điều kiện lọc khác nhau trên bộ lọc. Có thể sử dụng một host có chức nǎng của bộ định tuyến để làm bộ lọc và các điều kiện lọc được thiết lập hay loại bỏ thông qua giao diện Web. Sử dụng kỹ thuật tường lửa kiểm tra trạng thái (stateful fiwalling) Nếu các kỹ thuật trên không thể loại bỏ được vấn đề giả mạo địa chi nguồn, còn có một giải pháp cuối cùng - sử dụng kỹ thuật tường lửa kiểm tra trạng thái. Hộp lọc sẽ giám sát tất cả các phiên TCP và chỉ cho phép các giao vận thuộc về một phiên hợp lệ hoặc xuất phát từ một địa chỉ IP trong phiên hợp lệ được đi qua. Vì gần như không thể hoàn thành thủ tục bắt tay 3 lần (three- way handsake) TCP với một địa chỉ giả mạo, phương pháp này có thể loại bỏ hoàn toàn các giao vận tấn công. Tuy nhiên, giải pháp này không phải dễ dàng triển khai. Rất khó có thể nhận biết được các giao vận hướng ra nào tương ứng với giao vận hướng vào cần phải lọc nếu chỉ sử dụng một hộp lọc duy nhất. Phương án giải quyết cho vấn đề này là sử dụng nhiều firewall kiểm tra trạng thái làm việc kết hợp với nhau. Firewall của khách hàng có thể giám sát các giao vận hướng ra và yêu cầu hộp lọc của ISP chỉ cho phép các giao vận hoàn thành thủ tục bắt tay 3 chiều hợp lệ được đi qua. ======= HcE Gr0up === &ksvthdang(HCE) ASP: Các nguyên tắc bảo mật khi triển khai các ứng dụng Web 1. An toàn trước khả năng bị tấn công XSS (Cross-Site Scripting) Kiểu tấn công XSS điển hình nhất xảy ra khi tin tặc cố tình chèn một đoạn văn bản có chứa script độc hại vào các form nhập dữ liệu. Nội dung nhập vào có thể chứa các thẻ <OBJECT> hoặc <SCRIPT> cùng các đoạn mã hết sức nguy hiểm. Trình duyệt, khi truy nhập site, cho rằng các srcipt này do máy chủ gửi tới, hoàn toàn vô hại nên sẽ chạy nó ở cấp độ bảo mật bình thường, gây ra hậu quả tai hại cho máy tính của người sử dụng . Để bảo vệ khỏi bị tấn công theo kiểu XSS, cần chú ý ít nhất những điểm sau: - Cập nhật thường xuyên các bản sửa lỗi bảo mật mới nhất của IIS và Windows. - Lọc các ký tự đặc biệt do người sử dụng nhập vào như < > " ' % ( ) & + - - Lọc để loại bỏ các ký tự đặc biệt, kết xuất trên cơ sở thông tin nhập vào của người sử dụng. Xem kỹ các dữ liệu từ: - Request.Form Collection - Request.QueryString Conllection - Request Object - Database - Cookie - Các biến Session và Application Để có thể lọc được, cần xác định cụ thể lược đồ mã hoá ký tự trên các trang Web, trong thẻ META, ở phần header. Ví dụ: <head> <META http-equiv="Content-Type" Content="text/html; charset=ISO- 8859-1"> </head> 2. Ứng dụng có thể không cần sử dụng các cookie thường trực Cookie thường trực là những tệp, được các ứng dụng Web gửi tới máy tính người