CGGX_ANNX
Senior Member
Vâng bác, bác có thể nghịch ngợm bên bảng RAW mà không cần chỉnh sửa gì các rules bên bảng Filter của bác.
Tuy nhiên thường thì bác không cần rules gì ở cái bảng RAW này đâu. Các rules thí dụ ở trang kia chỉ là thí dụ cho bác tham khảo mà thôi, chứ nó cũng không làm cho router của bác an toàn hơn. Những packet mà bị các rules RAW ví dụ đó drop, thì khi bác gỡ hết các rules RAW đó đi, cũng sẽ bị hoặc là các rules filter bình thường drop, hoặc bị ignore hoàn toàn, hoặc không gây tác dụng hại nào được ngoài việc chiếm CPU xử lý. Tức là không có các rules này không có nghĩa là router và mạng của bác tự dưng bị lỗ hổng to tướng kẻ xấu có thể xâm nhập được. Nên nếu bác có copy chúng vào thì bình thường bác nên bật cái dòng rules này lên
để nó accept packet ngay lập tức và ignore các rules RAW bên dưới, chuyển sang xử lý bởi cái rules Mangle, NAT, và Filter bình thường. Khi nào rỗi muốn thử nghiệm các rules bên dưới thì lại để disabled=yes ở cái rule này (disable nó để không skip nữa).
Bác hãy tưởng tượng là phần lớn thời gian khi bác sử dụng internet với router của bác và download, upload dữ liệu, thì các packet mà router bác cần xử lý gần như hầu hết là các packet được xếp vào cái nhóm có connection-state=established. Thí dụ khi bác download 1 file bộ phim 14GB, cứ xét các packet nhận được đi, và cứ coi là mỗi packet chứa được 1400 bytes dữ liệu, thì có nghĩa là để download bộ phim đó router của bác phải xử lý 10 triệu packet đến.
Trong trường hợp Fasttrack KHÔNG HOẠT ĐỘNG, nếu không có rules RAW nào, chỉ có các rules Filter và NAT thông thường thì thực chất chỉ có packet đầu tiên (hoặc có thể là thêm vài packet nữa) là phải chạy qua chuỗi rules của bác (vì connection-state=new) và được accept, còn lại toàn bộ 10 triệu packets còn lại chỉ việc chạy qua connection tracking, sau đó match ngay với rule accept ở bên trên của chain. Các packets này thậm chí không cần phải chạy qua các rules NAT như các packet đầu nữa, vì trong cái connection entry đã có thông tin phải sửa cổng và địa chỉ nguồn/gốc như nào rồi. Như vậy là hầu như toàn bộ các packet chỉ cần được xử lý bởi connection tracking và 1 rule filter accept.
Nếu bác có các rules ở bảng RAW thì cả 10 triệu packet đó đều phải chạy qua rules ở bảng đó để xử lý. Nếu bác copy cả lũ rules kia thì thậm chí phải chạy qua hết một lô rules em đánh dấu màu đỏ ở đây, cho đến tận rules gạch chân màu xanh mới được xử lý tiếp (là accept cho đi tiếp vì nó đến từ interface WAN):
10 triệu lần như thế. Tốn kém CPU vô ích vì đa số các packets khi sử dụng bình thường đều được router accept.
Khi FASTTRACK có hoạt động, và connection hiện thời đáp ứng được yêu cầu của fasttrack (1 trong các yêu cầu là phải là loại packet UDP hoặc TCP) thì sẽ không đến mức thảm hại như thế, tức là đống rules RAW không phải xử lý cả 10 triệu packets. Lý do là thường những packet connection-state=etablished đầu tiên sẽ được chạy qua rules fasttrack, rules này sẽ đánh dấu connection hiện thời là connection fasttrack, và sau đó hầu hết các packet tiếp theo sẽ skip được toàn bộ các rules tường lửa, kể cả rules RAW. Tuy nhiên không phải tất cả các packet đều được fasttrack, ngoài các packet không phải UDP và TCP, sẽ vẫn có các packet của connection đã đánh dấu fasttrack được cho đi qua tường lửa, theo MikroTik là để giữ cái connection entry nó không bị mất. Ở cái screenshot lần trước bác post này:
Bác có thể thấy có 36.5 triệu packets với 38.4GB đi được bằng đường fasttrack, tuy nhiên bên dưới vẫn cần có 583 nghìn packets với 180MB và connection-state=established phải đi qua các rules bình thường. Đống packets này cũng phải đi qua đống rules RAW. Như vậy với 10 triệu packet cũng sẽ có vài trăm nghìn packet phải đi qua bảng RAW.
Thông thường router của bác drop packet phần lớn thời gian do gặp packet lỗi (state invalid, thường do các packet liên quan khác bị loss). Họa hoằn lắm mới là bị "tấn công" do kẻ xấu nào đó bên ngoài internet thử quét cổng xem cổng nào mở, hay thử kết nối vào những cổng kiểu 22 (SSH) và thử login. Nếu điều này có xảy ra đi chẳng nữa thì thông thường cũng chỉ vài nghìn packet một giây. Nếu không có rules ở bảng RAW chặn chúng thì thông thường các packets "xấu" này sẽ phải chạy qua connection tracking, sau đó chạy qua hầu hết các rules tường lửa của bác, để rồi bị rơi vào cái rules "drop all" ở dưới cùng của chain. Tất nhiên là chiếm CPU, nhưng thực ra không ăn thua gì so với 10 triệu cái packet lúc download kia của bác. Cứ cho là bác bị scan cổng 1 vòng (65 nghìn cổng) hay kẻ xấu thử connect vài nghìn lần vào cổng abc, cũng không thấm gì so với việc bật nhiều rules ở bảng RAW và ép tất cả các packets phải chạy qua chúng. Nếu không tin bác thử mở bảng filter ra, xem cái đống rules drop của bác nó drop được bao nhiêu packet với bytes rồi, và so sánh với số packet và bytes đã được cái fasttrack counter ở trên, hoặc rule accept established,related,untracked ở dưới đếm được.
Bảng RAW có ích khi nào? Khi bác bị DoS/DDoS. Thông thường chẳng ai hơi đâu đi DoS bác làm gì. Nhưng bác có thể dùng bảng RAW khi phát hiện router bỗng dưng chậm như rùa vì có ai đó đang gửi mấy chục ngàn packet UDP hay TCP SYN một giây vào cổng abc của bác mà không quan tâm đến response chẳng hạn. Router của bác sẽ bị tốn tài nguyên vì phải xử lý chúng qua connection tracking và cho chúng chạy qua các rules filter trước khi drop chúng. Khi phát hiện bị DoS kiểu này thì việc bác nên làm là xác định địa chỉ IP gốc của đống packet, hoặc xác định cổng đang bị tấn công, và add nhanh một rule drop tạm vào bảng RAW để lọc nhanh đống packet đó. Lúc này rule RAW đó sẽ rất hiệu quả vì nó drop ngay được dựa trên src-address hoặc dst-port, thông tin có sẵn trong header packet, mà không cần phải xử lý tiếp chúng. Hết bị tấn công rồi thì bỏ đống rules raw đi.
Ngoài ra như ở post trước em viết, rule ở bảng RAW nếu có action=notrack còn có thể giúp các packet đã match được với rule đó bỏ qua được connection tracking và đa số rules còn lại của tường lửa, coi như được accept nhanh khi không cần các tính năng connection-tracking mang lại. Ở đây thì còn phụ thuộc vào việc các packet loại này có xuất hiện nhiều so với các packet bình thường không. Vì ở đây các packet loại này được xử lý nhanh, nhưng các packet khác còn lại sẽ tự dưng bị dính thêm 1 rule tường lửa phải đi qua, nên có thể hiệu quả ngược lại so với mong muốn.
Tóm lại, hàng ngày đa số traffic của bác là traffic được accept, và là traffic tiếp theo của 1 connection có sẵn (connection-state=established). Thế nên bác nên tối ưu hóa trường hợp này. Đấy là lý do vì sao RouterOS phải có cái rule đặc cách fasttrack, hoặc vì sao các rules accept packet loại này phải để lên trên cùng của các chain (để nhanh chóng skip được các rules còn lại). Các rules ở bảng filter như của bác ở trên đủ bảo vệ an toàn cho router và các thiết bị đăng sau nó rồi. Bác chỉ cần dùng đến bảng RAW khi bị tấn công bởi DoS. Còn không thì bảng RAW chỉ làm chậm traffic bình thường đi mà thôi (nếu các rules RAW không có khả năng accept ngay lập tức các packet hay xuất hiện nhất, mà như bác thấy ở hình trên, cái đống rules thí dụ đó không làm được điều này).
Last edited:
(
Thanks thím đã nhiệt tình giải thích cặn kẽ 
