Đồ án tốt nghiệp · Dublin City University · 2024—2025
Tường lửa SMS cho 5G
Tin nhắn văn bản vẫn đang chuyển mã dùng một lần, cảnh báo ngân hàng và liên kết khôi phục tài khoản — điều đó khiến SMS trở thành một trong những bề mặt bị tấn công nhiều nhất trong mạng di động. Đây là một tường lửa kiểm tra SMS ngay bên trong lõi 5G, chặn smishing theo thời gian thực, và được xây dựng cũng như đo đạc trên một mô phỏng hoạt động được của chính mạng lưới mà nó sẽ nằm trong đó.
- OMNeT++ / C++
- Flask
- DistilBERT
- PostgreSQL
- Google Cloud Run
- React
- Thời gian
- 2024 — 2025
- Bối cảnh
- Đồ án tốt nghiệp, Cử nhân Khoa học Máy tính
- Trường
- Dublin City University
- Triển khai
- Google Cloud Run, được dẫn động bởi mô phỏng OMNeT++
- 81,8/s
- Bản tin duy trì được
- 1.100 ms
- Phân vị 95
- <100 ms
- Suy luận của mô hình
- 0%
- Tỷ lệ lỗi
Với tám thực thể Message Processor ở hồ sơ lưu lượng cao, không có yêu cầu nào thất bại.
Độ trễ xấu nhất ở tải đỉnh, giảm từ 2.800 ms khi chỉ có một thực thể.
Thời gian phân loại DistilBERT trung bình trả về từ Cloud Run.
Trên mọi hồ sơ tải và mọi cấu hình dịch vụ đã thử nghiệm.
01Vấn đề
SMS thì cũ, được tin tưởng, và vẫn là lối vào dễ nhất
Gần như mọi tài khoản bạn có đều có thể tiếp cận qua một tin nhắn. Mã dùng một lần, thông báo giao hàng, cảnh báo ngân hàng, đặt lại mật khẩu — tất cả đến qua một giao thức thiết kế từ thập niên 1980, không xác thực người gửi và không có cách nào tự thân để phân biệt một ngân hàng với kẻ giả danh ngân hàng.
Kẻ tấn công biết rõ điều đó. Smishing — lừa đảo qua SMS — hiệu quả vì bản tin rơi vào đúng luồng hội thoại với những bản tin thật, trên một thiết bị người ta tin tưởng mà không cần suy nghĩ. Khi 5G đưa nhắn tin sang hạ tầng nền IP và nâng khối lượng mà mạng phải gánh, bề mặt ấy chỉ càng rộng ra.
Những công cụ mà nhà mạng thường dùng cho vấn đề này đều tĩnh: các mẫu khớp cố định và danh sách chặn duy trì thủ công. Chúng chặn được chiến dịch của hôm qua. Chúng không chặn được một bản tin chưa từng xuất hiện, do một người biết rõ bộ lọc đang tìm gì viết ra.
Dự án này đặt câu hỏi: một bộ lọc dựng riêng cho bài toán đó trông sẽ ra sao? Một bộ lọc kiểm tra bản tin ngay trong lõi 5G, kết hợp các phép kiểm tra tất định rẻ tiền với một mô hình ngôn ngữ hiểu được cách diễn đạt, mà vẫn chuyển một bản tin hợp lệ đủ nhanh để không ai nhận ra nó đã bị đọc.
Smishing
Lừa đảo gửi bằng tin nhắn, lợi dụng niềm tin mà người ta đặt vào hộp thư tin nhắn của mình.
Mồi nhử khẩn cấp
Bản tin được dựng để ép bấm ngay: tài khoản bị khoá, thanh toán thất bại, đơn hàng bị giữ.
Ngập lụt SMS
Các đợt bùng phát tần suất cao từ một người gửi, dùng cho chiến dịch thư rác hoặc để vắt kiệt tài nguyên mạng.
URL độc hại
Liên kết rút gọn hoặc nhái tên dẫn tới trang thu thập thông tin đăng nhập.
- UE
- gNodeB
- AMF
- Tường lửa
- SMSF
- UDM
02Thử xem
Cho một bản tin chạy qua chuỗi quyết định
Tường lửa ra quyết định qua năm chặng. Ba chặng đầu chạy song song và có thể chặn đứng bản tin ngay; chỉ những gì vượt qua mới được chấm điểm, và chỉ điểm đủ cao mới tới được mô hình ngôn ngữ. Toàn bộ phần dưới đây chạy chính logic thật đó ngay trong trình duyệt của bạn.
Mẫu
Đã gửi trong cửa sổ: 0/8
Gửi liên tiếp từ cùng một số để kích hoạt quy tắc chống ngập lụt.
Chọn một mẫu hoặc tự viết bản tin của bạn, rồi kiểm tra nó.
- 01—
Lọc theo quy tắc
MSISDN trong danh sách chặn và tiền tố quốc gia hoặc mạng bị chặn, đọc từ bộ quy tắc trong bộ nhớ đệm.
- 02—
Phát hiện ngập lụt
Số bản tin mỗi người gửi trong một cửa sổ trượt. Vượt ngưỡng sẽ mở giai đoạn hạ nhiệt, trong đó mọi bản tin đều bị loại.
- 03—
Tra cứu an toàn URL
Mọi URL trong nội dung đều được trích ra và đối chiếu với Google Safe Browsing.
- 04—
Bộ chấm điểm từ ngữ
Từ khoá có trọng số, cộng thêm điểm phạt cho chuỗi chữ số dài và bản tin ngắn bất thường.
- 05—
Bộ phân loại DistilBERT
Mô hình DistilBERT tinh chỉnh trên bộ dữ liệu SMS Spam Collection, chỉ được gọi tới khi vượt ngưỡng điểm.
03Kiến trúc
Ba lớp, nối với nhau bằng một lời gọi HTTP
Hệ thống tách thành ba lớp, mỗi lớp tự mở rộng, tự triển khai và tự hỏng độc lập. Một lõi 5G mô phỏng mang lưu lượng. Một nhóm vi dịch vụ trên đám mây quyết định phải làm gì với nó. Một bảng điều khiển phía nhà mạng định nghĩa quy tắc và theo dõi kết quả.
Ràng buộc duy nhất giữa mạng và bộ máy quyết định là một lời gọi HTTP đồng bộ. Đó là chủ ý: mô-đun tường lửa bên trong mạng không biết gì về chấm điểm, học máy hay cơ sở dữ liệu. Nó đặt một câu hỏi rồi hành động theo câu trả lời, nhờ vậy có thể viết lại hoặc triển khai lại bất kỳ dịch vụ đám mây nào mà mạng không hề hay biết.
Quy tắc đi theo chiều ngược lại, và không bao giờ đi đồng bộ. Quản trị viên sửa chúng tại chỗ, đồng bộ lên Cloud SQL qua một dịch vụ trung gian, rồi chúng được xuất ra JSON vào một bucket lưu trữ mà Message Processor định kỳ lấy về. Không có gì trên đường đi của bản tin phải chờ một cơ sở dữ liệu.
Lõi 5G mô phỏng
01
Các mô-đun OMNeT++ tự viết bằng C++ và NED, hiện thực đúng những chức năng mạng mà một SMS thực sự đi qua, kèm một liên kết IPX để bản tin có thể vượt ranh giới giữa các nhà mạng.
- UE
- gNodeB
- AMF
- Firewall
- SMSF
- UDM
- IPX
Lớp quyết định trên đám mây
02
Các dịch vụ Flask trên Google Cloud Run: Message Processor ra mọi quyết định, bộ phân loại DistilBERT mà nó chuyển lên, và một dịch vụ trung gian đồng bộ quy tắc cùng trả về nhật ký. Trạng thái nằm ở Cloud SQL và một bộ đệm quy tắc trên Cloud Storage.
- MessageProcessor
- DistilBERT service
- RuleLogInterface
- Cloud SQL
- GCS rule cache
Lớp quản trị của nhà mạng
03
Bảng điều khiển Django và React đóng gói container, nơi quy tắc được viết và rà soát trước khi lên thật, với Redis và Celery hứng luồng nhật ký để việc thu nhận không bao giờ làm nghẽn giao diện.
- Django
- React
- PostgreSQL
- Redis
- Celery
04Mạng lưới
Một lõi 5G dựng ra để bị tấn công
Muốn thử tường lửa thì cần lưu lượng, mà lưu lượng thì cần một mạng. Thay vì giả lập hời hợt, chúng tôi dựng hẳn một mô hình hoạt động được của mặt phẳng điều khiển 5G trong OMNeT++ — từng mô-đun viết từ đầu bằng C++ và NED, bám theo định nghĩa chức năng trong 3GPP TS 23.501 và TS 33.501.
Bản tin đi đúng đường thật. Một máy đầu cuối đăng ký vào mạng, bảng định tuyến ghi lại nó đang nằm sau trạm gốc và chức năng truy nhập nào, rồi một SMS lần lượt đi qua mạng truy nhập vô tuyến, chức năng truy nhập, tường lửa, chức năng SMS và chức năng quản lý dữ liệu trước khi quay xuống người nhận.
Hai nhà mạng được mô hình hoá và nối với nhau qua các nút liên kết IPX, để việc chuyển phát giữa hai nhà mạng cũng được thử nghiệm song song với lưu lượng nội mạng — tức trường hợp bản tin đến từ một mạng bạn không kiểm soát, vốn là nơi phần lớn hành vi lạm dụng bắt nguồn.
Cấu hình mạng, định tuyến và lịch gửi bản tin đều điều khiển bằng tệp CSV và .ini. Thêm mười hai máy đầu cuối, thêm nhà mạng thứ hai hay một mẫu thư rác mới đều là thay đổi cấu hình, không phải biên dịch lại.
- UE (Actor)
- Một máy đầu cuối, tham số hoá bằng IMSI, MSISDN và phân vùng mạng vô tuyến mà nó đang gắn vào. Gửi và nhận theo lịch đọc từ tệp.
- gNodeB
- Trạm gốc 5G. Xác định bản tin đến từ máy đầu cuối hay từ lõi dựa vào tên cổng chứ không theo chỉ số, nhờ vậy có thể đổi cấu hình mạng mà không đụng tới mã nguồn.
- AMF
- Quản lý truy nhập và di động. Tra xem người nhận nằm sau trạm gốc nào rồi chuyển tiếp bản tin, hoặc đẩy nó vào tường lửa để kiểm tra.
- Tường lửa
- Một proxy giữa lõi mạng và đám mây. Chuyển bản tin sang JSON, gửi đi bằng libcurl, rồi hoặc chuyển tiếp tới chức năng SMS hoặc loại bỏ.
- SMSF
- Chức năng SMS. Chuyển phát nội mạng qua ngả chức năng truy nhập, hoặc giao bản tin cho IPX để định tuyến liên mạng.
- UDM
- Quản lý dữ liệu hợp nhất. Giữ hồ sơ thuê bao và xác nhận đường định tuyến trước khi chuyển phát cuối cùng.
- IPX
- Điểm liên kết giữa các nhà mạng. Chuyển tiếp bản tin qua ranh giới mạng và giao lưu lượng đi vào cho tường lửa của nhà mạng tiếp nhận.
Bắt C++ nói chuyện với một dịch vụ đám mây
OMNeT++ không có sẵn client HTTP. Mô-đun tường lửa dùng libcurl gửi một POST đồng bộ tới Message Processor trên Google Cloud, tự tay dựng chuỗi JSON, rồi bóc kết luận ra khỏi phản hồi trước khi quyết định chuyển tiếp hay loại bỏ. Đó là một mẩu mã kết dính chẳng lấy gì làm hào nhoáng, và cũng chính là thứ biến một mô phỏng thành bài kiểm thử đầu-cuối cho các dịch vụ đang chạy thật.
05Bộ máy quyết định
Việc rẻ làm trước, mô hình chỉ vào cuộc khi xứng đáng
Mọi bản tin tới Message Processor đều phải được trả lời ngay trong cùng một yêu cầu. Ràng buộc đó định hình toàn bộ thiết kế: phần việc đắt đỏ phải hiếm khi xảy ra, và bất cứ thứ gì có thể chạy song song thì không nên chạy tuần tự.
Ba phép kiểm tra độc lập được phát đi cùng lúc trên một pool luồng, và lệnh chặn đầu tiên thắng cuộc — nếu người gửi vốn đã nằm trong danh sách chặn thì chẳng có lý do gì phải đợi tra cứu URL xong. Chỉ bản tin vượt qua cả ba mới được chấm điểm, và chỉ bản tin đạt ngưỡng mới được gửi tới mô hình ngôn ngữ. Trên thực tế, phần lớn lưu lượng không bao giờ chạm tới nó.
Cách thực thi cố ý khoan dung. Một vi phạm đơn lẻ không đẩy ai vào danh sách chặn: các lần cảnh cáo được đếm theo từng loại, và chỉ người gửi vượt ngưỡng mới bị đưa vào danh sách chặn tự động — đồng thời được ghi thẳng vào bộ đệm quy tắc trong bộ nhớ, để có hiệu lực ngay ở bản tin kế tiếp chứ không phải đợi lần làm mới sau.
- Lọc song song. Khớp quy tắc, phát hiện ngập lụt và tra cứu URL chạy đồng thời trên một pool luồng, trả kết quả ngay khi bất kỳ phép nào nói rằng phải chặn.
- Chấm điểm từ ngữ. Từ khoá có trọng số, chỉnh được từ bảng điều khiển theo thang một đến mười, cộng thêm điểm phạt cho chuỗi chữ số dài và bản tin ngắn bất thường. Hai mươi điểm là chuyển lên mô hình.
- Chuyển lên mô hình. Mô hình DistilBERT tinh chỉnh trên bộ dữ liệu SMS Spam Collection, đặt riêng thành một dịch vụ Flask để có thể mở rộng — và hỏng — độc lập.
- Hệ thống cảnh cáo. Vi phạm đếm theo từng loại. Vượt ngưỡng thì người gửi bị đưa vào danh sách chặn và bộ đệm quy tắc đang chạy được cập nhật ngay lập tức.
- Giới hạn tần suất. Một cửa sổ trượt theo từng người gửi kèm giai đoạn hạ nhiệt sau đó, giữ trong bộ nhớ sau các bộ đếm an toàn với đa luồng, không cần bộ giới hạn ngoài nào trên đường xử lý yêu cầu.
- Bộ đệm quy tắc. Quy tắc được tải từ bucket lưu trữ lúc khởi động và làm mới mỗi mười phút, giữ lại bộ quy tắc tốt gần nhất nếu lần tải thất bại.
- Phần đuôi không chặn. Ghi cơ sở dữ liệu và gửi webhook đều được đẩy sang pool luồng sau khi kết luận đã trả về, nên một bên tiêu thụ chậm không thể làm chậm việc xử lý bản tin.
- Pool kết nối. Một pool dùng chung tối đa bốn mươi kết nối PostgreSQL, bổ sung sau khi các bản dựng đầu làm cạn máy chủ vì mở một kết nối cho mỗi bản tin.
06Kết quả
Nó làm được gì khi chịu tải
Thử tải dùng Locust nhắm vào các dịch vụ đã triển khai, trên hai hồ sơ lưu lượng và vài cấu hình dịch vụ khác nhau. Báo cáo lấy phân vị 95 thay vì trung bình: cái đáng quan tâm là bản tin tệ nhất, không phải bản tin trung bình.
50 người dùng đồng thời, tăng 10/s
Thông lượng
req/s · ↑
- ×120.020.0
- ×237.737.7
- ×459.259.2
- ×881.881.8
Số thực thể Message Processor
Độ trễ phân vị 95
ms · ↓
- ×12,8002,800
- ×21,9001,900
- ×41,8001,800
- ×81,1001,100
Số thực thể Message Processor
| Thực thể MP | Dịch vụ AI | Thông lượng (yc/s) | Độ trễ p95 (ms) | Lỗi |
|---|---|---|---|---|
| ×1 | 1 × 2 vCPU | 20.0 | 2,800 | 0% |
| ×2 | 1 × 2 vCPU | 37.7 | 1,900 | 0% |
| ×4 | 2 × 4 vCPU | 59.2 | 1,800 | 0% |
| ×8 | 2 × 4 vCPU | 81.8 | 1,100 | 0% |
- Nút thắt không nằm ở mô hình. Giả định ban đầu là bộ phân loại sẽ là điểm nghẽn. Số liệu từ đám mây cho thấy ngược lại: dịch vụ AI chưa bao giờ chạm hạn mức thực thể ngay cả khi bùng tải, trong khi Message Processor thì bão hoà. Giới hạn nằm ở khâu tiếp nhận, đánh giá quy tắc và định tuyến.
- Mở rộng gần như tuyến tính. Tăng từ bốn lên tám thực thể Message Processor, giữ nguyên dịch vụ AI, đã nâng thông lượng thêm 39% và cắt hơn 35% độ trễ phân vị 95.
- Vẫn chính xác dưới áp lực. Không có yêu cầu nào thất bại ở bất kỳ cấu hình nào, trên cả hai hồ sơ. Không có gì bị mất chỉ vì một dịch vụ phía sau chậm.
- Từ đó rút ra cách định cỡ. Khi chịu tải, thêm bản sao Message Processor có lợi hơn thêm bản sao mô hình — cho tới khi chính mô hình bão hoà, điều mà các bài kiểm thử này chưa bao giờ tạo ra được.
07Khả năng chịu lỗi
Mọi thành phần phụ thuộc đều được phép hỏng
Một tường lửa ngừng cho bản tin đi qua chỉ vì cơ sở dữ liệu không trả lời thì chính nó đã trở thành sự cố. Mỗi thành phần phụ thuộc đều được gán một hành vi khi hỏng rõ ràng, và việc chuyển phát bản tin không phụ thuộc vào bất kỳ thành phần nào trong số đó.
| Nếu cái này hỏng | Hệ thống sẽ làm thế này |
|---|---|
| Kho quy tắc không truy cập được | Quay về dùng bộ quy tắc đã lưu đệm gần nhất trong bộ nhớ. Việc xử lý tiếp tục như thường; không mất quy tắc nào, chỉ là lần làm mới bị hoãn. |
| Không kết nối được Cloud SQL | Quyết định vẫn được đưa ra từ bộ quy tắc trong bộ nhớ và trả về bình thường. Việc ghi nhật ký thất bại trong im lặng và chỉ được ghi nhận là lỗi, thay vì chặn kết luận. |
| Bộ phân loại AI ngoại tuyến | Bỏ qua bước chuyển lên mô hình và cho bản tin đi tiếp chỉ dựa trên điểm số. Sự kiện được ghi lại để về sau còn thấy được khoảng trống đó. |
| Không gọi được điểm nhận webhook | Việc gửi theo kiểu "bắn rồi quên" trên một luồng nền. Lỗi chuyển phát được ghi lại; bảng điều khiển tụt lại phía sau, còn tường lửa thì không. |
| Một người gửi làm ngập mạng | Cửa sổ trượt chặn người gửi vi phạm ngay tại tường lửa, trước khi bản tin chạm tới các chức năng truy nhập, SMS hay quản lý dữ liệu — giữ lưu lượng ngập lụt hoàn toàn bên ngoài lõi mạng. |
08Vận hành
Phần mà nhà mạng thực sự dùng đến
Một tường lửa chỉ tốt ngang với khả năng nhìn thấy nó đã làm gì và thay đổi việc nó sẽ làm tiếp. Bảng quản trị là một ứng dụng Django và React đóng gói container: Django phục vụ API và giữ bộ quy tắc chính thức, React hiển thị, còn Redis với Celery nằm giữa khâu thu nhận và khâu xử lý nhật ký để một đợt bùng lưu lượng xếp hàng chứ không làm nghẽn.
Quy tắc được sửa tại chỗ và rà soát trước khi đi bất cứ đâu. Một lần đồng bộ sẽ đẩy bộ quy tắc hiện tại — kể cả các mục xoá mềm, để việc xoá cũng có phiên bản chứ không biến mất lặng lẽ — lên Cloud SQL qua dịch vụ trung gian, và một bước triển khai riêng sẽ nạp lại Message Processor.
Nhật ký về liên tục qua webhook, kèm nút lấy thủ công dự phòng nếu luồng bị gián đoạn. Mỗi bản ghi đều lưu chặng đã quyết định kết quả, quy tắc bị vi phạm, điểm số và dự đoán của mô hình, nhờ vậy mọi lần chặn đều truy ngược được về lý do của nó.
- Bảng nhật ký trực tiếp. Mọi bản tin đã xử lý kèm chặng, quy tắc bị vi phạm, điểm số và dự đoán của mô hình, lọc được theo quốc gia, trạng thái, lý do và quy tắc.
- Các chặng xử lý. Bảng phân tách theo từng bản tin, cho thấy thành phần nào đã ra quyết định và đi tới đó bằng cách nào.
- Bản đồ địa lý. Lượng bị chặn theo từng quốc gia trên bản đồ tương tác, nhật ký bên dưới chỉ cách một cú nhấp.
- Phân tích từ ngữ. Những từ nào xuất hiện trong lưu lượng bị chặn và tỷ lệ chặn trên cho qua của mỗi từ — vòng phản hồi để tinh chỉnh trọng số.
- Quản lý quy tắc. Ngưỡng thư rác, từ có trọng số và các mạng theo quốc gia bị chặn, với thao tác đồng bộ và triển khai tách bạch rõ ràng.
- Biểu đồ xu hướng. Lượng bản tin theo giờ, tỷ lệ chặn theo thời gian, diễn biến điểm số và tần suất khớp quy tắc.
09Kỹ thuật
Cái gì đã hỏng, và cái gì đã sửa được
Phần thú vị của một công trình hiếm khi nằm ở bản thiết kế. Đây là những vấn đề chỉ lộ ra khi hệ thống đã chạy, và mỗi vấn đề đã thay đổi điều gì.
01
Cạn kết nối cơ sở dữ liệu
Vấn đề
Các bản dựng đầu mở một kết nối PostgreSQL mới cho mỗi bản tin. Khi chịu tải, máy chủ chạm giới hạn kết nối và việc xử lý đứng hẳn: hết thời gian chờ, lỗi, không còn thông lượng.
Cách khắc phục
Một pool dùng chung tối đa bốn mươi kết nối tái sử dụng. Việc cạn kết nối không còn khả năng xảy ra và hành vi dưới tải đồng thời trở nên đoán trước được.
02
Webhook làm nghẽn đường xử lý yêu cầu
Vấn đề
Việc gửi webhook và ghi nhật ký vào cơ sở dữ liệu chạy ngay trong luồng xử lý bản tin. Chỉ một điểm nhận bên ngoài chậm là làm trễ mọi bản tin xếp hàng phía sau.
Cách khắc phục
Cả hai chuyển sang một pool luồng và được phát đi sau khi kết luận đã trả về. Lỗi được ghi lại, và không có gì trên đường đi của bản tin phải chờ nó.
03
BERT quá nặng để phục vụ
Vấn đề
Bộ phân loại đầu tiên dùng bert-base-uncased. Mức chiếm bộ nhớ và thời gian suy luận khiến nó không dùng được cho lọc thời gian thực trên hạ tầng không máy chủ.
Cách khắc phục
Chuyển sang distilbert-base-uncased và giới hạn đầu vào ở 25 token, vừa vặn với độ dài một SMS. Suy luận tụt xuống dưới 100 ms mà chất lượng phân loại vẫn giữ được.
04
Quy tắc bị truy vấn cho từng bản tin
Vấn đề
Mỗi bản tin lại kích hoạt một truy vấn cơ sở dữ liệu để lấy bộ quy tắc hiện hành. Việc đó cộng thêm độ trễ vào mọi yêu cầu và tạo tải lên cơ sở dữ liệu tỷ lệ thuận với lưu lượng.
Cách khắc phục
Quy tắc được xuất ra JSON vào một bucket lưu trữ, nạp vào bộ nhớ lúc khởi động và làm mới mỗi mười phút. Tải lên cơ sở dữ liệu thôi tăng theo lưu lượng.
05
Sai một lần là vào danh sách chặn
Vấn đề
Bất kỳ vi phạm đơn lẻ nào cũng lập tức đưa người gửi vào danh sách chặn. Một dương tính giả, hay một bản tin sơ ý, là cắt vĩnh viễn một thuê bao hợp lệ.
Cách khắc phục
Một hệ thống cảnh cáo đếm vi phạm theo từng loại và chỉ chặn khi vượt ngưỡng. Việc thực thi vẫn nghiêm mà không trở nên giòn gãy.
06
Cập nhật danh sách chặn mất mười phút mới thấy
Vấn đề
Người gửi bị hệ thống cảnh cáo đưa vào danh sách chặn thì được ghi xuống cơ sở dữ liệu, nhưng bộ đệm quy tắc trong bộ nhớ không hay biết cho tới lần làm mới định kỳ kế tiếp. Suốt tối đa mười phút, một người gửi đã bị chặn vẫn có thể tiếp tục gửi.
Cách khắc phục
Vi phạm giờ đây được ghi vào cả bộ đệm đang chạy lẫn cơ sở dữ liệu, khép lại khoảng trống giữa lúc vi phạm và lúc thực thi.
07
Mô phỏng vỡ mỗi lần đổi cấu hình mạng
Vấn đề
Mô-đun chức năng truy nhập và trạm gốc định tuyến theo chỉ số cổng viết cứng. Đổi số máy đầu cuối hay số trạm gốc trong tệp .ini là gây mất bản tin trong im lặng hoặc sập hẳn.
Cách khắc phục
Định tuyến phân giải cổng theo tên thay vì theo vị trí. Mô phỏng co giãn được với mọi cấu hình mạng mà không phải sửa mã, và chính điều đó mới làm cho các kịch bản nhiều nhà mạng quy mô lớn hơn trở nên khả thi.
08
Bộ mô phỏng không biết nói HTTP
Vấn đề
OMNeT++ không hỗ trợ HTTP, trong khi bộ máy quyết định lại nằm trên Google Cloud sau một API REST. Không có cầu nối thì mô phỏng chỉ có thể thử nghiệm một bản thay thế giả.
Cách khắc phục
Một client libcurl đặt ngay trong mô-đun tường lửa, tự dựng JSON và bóc kết luận ra khỏi phản hồi. Mô phỏng điều khiển đúng những dịch vụ thật đã triển khai.
10Tiếp theo
Những gì nó còn chưa làm được
Hệ thống đã đạt được những gì nó đặt ra. Đây là các giới hạn chúng tôi sẽ bắt tay vào tiếp, và chúng được ghi lại như giới hạn chứ không phải phát hiện ra như bất ngờ.
- Độ tin cậy, không chỉ là nhãn. Bộ phân loại trả về thư rác hoặc hợp lệ. Trả thêm điểm tin cậy cùng những token dẫn tới kết luận sẽ cho phép cách ly các bản tin ở ranh giới thay vì phán quyết dứt khoát.
- Lan truyền quy tắc có phiên bản. Thay việc làm mới mười phút một lần bằng các tệp quy tắc có phiên bản, chuyển sang phiên bản mới vào lúc lưu lượng thấp thay vì theo đồng hồ hẹn giờ.
- Cảnh cáo biết phai dần. Cảnh cáo hiện là vĩnh viễn cho tới khi đặt lại. Đánh trọng số theo mức nghiêm trọng và cho phai dần theo thời gian sẽ mô hình hoá uy tín tốt hơn một bộ đếm phẳng.
- Chấm điểm tinh hơn. Bộ chấm điểm hiện khớp từng từ đơn lẻ. Dùng n-gram hoặc trọng số TF-IDF sẽ bắt được những cách diễn đạt mà từ riêng lẻ bỏ sót, mà không phải đổi gì khác trong chuỗi xử lý.
- Huấn luyện lại trên lưu lượng thật. Mô hình mới chỉ được tinh chỉnh một lần trên bộ dữ liệu công khai. Huấn luyện lại định kỳ trên lưu lượng quan sát được là bước tiếp theo hiển nhiên, và phần ghi nhật ký vốn đã thu đủ những gì cần thiết.
- Kiểm thử tích hợp tự động. Kiểm thử đơn vị và kiểm thử hệ thống đã tự động hoá; phần tích hợp giữa các dịch vụ đã triển khai thì làm thủ công. Viết kịch bản cho nó không khó, chỉ là chưa kịp làm vì thời gian.
Công nghệ
Xây dựng bằng
Mô phỏng
- OMNeT++
- INET
- Simu5G
- C++
- NED
- libcurl
Dịch vụ
- Python
- Flask
- Django
- React
- Celery
- Redis
Học máy
- DistilBERT
- Hugging Face Transformers
- PyTorch
Hạ tầng
- Google Cloud Run
- Cloud SQL
- Cloud Storage
- PostgreSQL
- Docker
- GitLab CI/CD
Ghi nhận
Nhóm thực hiện và tài liệu
Thực hiện như đồ án tốt nghiệp của nhóm hai người cho chương trình Cử nhân Khoa học Máy tính tại Dublin City University, cùng làm chung trên cả phần mô phỏng, các dịch vụ đám mây và bảng điều khiển.
- Cùng thực hiện
- Jack Keenan
- Giảng viên hướng dẫn
- GS. Mohammed Amine Togou
- Trường
- Dublin City University, 2024—2025
- Tiêu chuẩn
- 3GPP TS 23.501, TS 24.501, TS 33.501
- Bộ dữ liệu
- SMS Spam Collection (Kaggle), dùng để tinh chỉnh bộ phân loại
- Tài liệu
- Đặc tả chức năng, đặc tả kỹ thuật, tài liệu kiểm thử và hướng dẫn sử dụng — cung cấp khi có yêu cầu.