Như đã trình bày ở phần trên với các chức năng mong muốn của hệ thống phòng chống phòng chống tấn công từ chối dịch vụ. Tác giả đề xuất hệ thống sẽ hoạt động như một hệ thống proxy đứng trước website. Để dùng được hệ thống thì người chủ website sẽ cấu hình địa chỉ dns của web trỏ vào hệ thống. Các request khi đến website sẽ được lọc thông qua hệ thống chống tấn công từ chối dịch vụ. Hệ thống chỉ cho các request bình thường đến hệ thống website đằng sau, còn các request đến từ botnet hoặc người tấn công sẽ bị chặn và không thể đến được web đằng sau. Cách làm như này sẽ khiến website khó có thể bị quá tải hơn, cách thứ triển khai dễ hơn rất nhiều.
Cũng theo như các yêu cầu từ phần trên hệ thống sẽ phải gồm các module chính: module sinh cookie xác thực, module xác thực qua javascript, module xác thực qua catpcha, module limit requests, module xác thực bot của các trang tìm kiếm. Trong đó yêu cầu với từng module như sau:
Module tạo cookie xác thực: các thứ tạo cookie xác thực phải có yêu cầu là chỉ phía trên server mới có thể tạo được cookie xác thực được. Quá trình tạo cookie phải tốn ít tài nguyên nhất có thể không dùng các thuật toán mã hoá quá phực tạp dẫn đến hệ thống phải chịu tải lớn khi bị tấn công từ chối dịch vụ. Cơ chế xác thực cookie xem có hợp lệ không phải đơn giản. Module này sẽ được dùng cho 2 module xác thực còn lại để xác thực người dùng hợp lệ.
Module xác thực qua javascript: Module dùng để người dùng có thể nhận được cookie xác thực tạo ra từ module trước. Mã dùng trong module này phải tương thích với tất cả các trình duyệt phổ biến. Mã cũng phải có kích thước nhỏ và đơn giản để tránh tốn quá nhiều băng thông của hệ thống.
Module xác thực qua catpcha: captcha xử dụng phải đủ tốt để không bị vượt qua bởi các công cụ nhận biết chữ viết phổ biến trên mạng. Việc tạo và xác thực captcha cũng phải tốn ít tài nguyên của hệ thống nhằm tránh chính hệ thống chống tấn công từ chối dịch vụ lại bị quá tải khi bị tấn công từ chối dịch vụ.
Module limit request: Module phải dễ cấu hình, hỗ trợ cấu hình limit đơn giản và theo nhiều yêu cầu khác nhau. Hỗ trợ việc xác thực phù hợp với những mức limit khác nhau. Module limit khi chạy phải dùng ít tài nguyên của hệ thống: không tốn quá nhiều tài nguyên xử lý của bộ vi xử lý và ram.
Module xác thực bot của các công tụ tìm kiếm: phải đảm bảo yêu cầu xác thực chính xác các bot tìm kiếm, không có hiện tượng xác thực nhầm nhằm tránh việc bot tìm kiếm không thể lấy được thông tin từ website sẽ ảnh hưởng rất nhiều hoạt động của website. Hệ thống cũng phải đạt yêu cầu là việc kiểm tra xác thực phải tốn rất ít tài nguyên của hệ thống và cũng phải rất đơn giản để mở rộng nếu có thể.
Hình 5. Cách thức triển khai hệ thống.
2.1.2. Mô hình hoạt động của hệ thống.
Như đã trình bày ở phần trên về cách triển khai và các module cần thiết của hệ thống tác giả xây dựng hệ thống với các hoạt động như sơ đồ logic sau đây:
Hình 6. Sơ đồ logic của hệ thống.
Quá trình xử lý một request từ người dùng gửi lên thông quan hệ thống chống tấn công từ chối dịch vụ như sau:
Khi một request gửi lên hệ thống sẽ kiểm tra request đó có phải đến từ bot của trình duyệt không bằng cách kiểm tra useragent trong headers của request xem có trình với các useragent mà bot của trình duyệt dùng không. Nếu request đó là đến từ bot tìm kiếm thì sẽ chuyển qua module xác thực bot tìm kiếm phù hợp. Nếu không thì sẽ chuyển qua module xác thực người dùng để xác thực tính hợp lệ của người dùng đó.
Xác thực bot từ các công cụ tìm kiếm: dùng phương pháp như đã nói ở phần 1.2.2.2 để xác thực xem bot có hợp lệ hay không. Ở phần này hệ thống sẽ dự vào giá trị useragent để xác thực bot theo module phù hợp nhất. Nếu bot được xác thị thì sẽ cho phép request đến website của người dùng. Còn nếu bot không được xác thực ( request giả đạng là bot của các công cụ tìm kiếm để qua mặt tường lửa) thì sẽ cấm không cho truy cập tiếp vào web.
Xác thực người dùng: bước đầu tiên để xác thực người dùng là hệ thống sẽ lấy thông tin về việc xác thực người dùng thông qua các đặc điểm riêng của từng người dùng một như địa chỉ ip và useragent …. Nếu đã có thông tin xác thực rằng người dùng cần được xác thực bằng phương thức nào cụ thể thì sẽ đưa thẳng người dùng đến phần xác thực đó. Nếu không có thông tin về việc cần xác thực thì sẽ đi đến phần tiếp. Module xác thực người dùng bao gồm hai module được xây dựng chính: xác thực thông qua javascript và xác thực thông qua captcha. Mức xác thực thông quan captcha chỉ được áp dụng khi người dùng vượt quá giới hạn request ở mức cao hơn hoặc đã không vượt qua được mức xác thực bằng javascript rất nhiều lần. Để xác thực người dùng hệ thống dùng một cookie được sinh ra theo các thông tin riêng của từng người dùng một. Cách thức xác nhận request là khi mỗi request lên hệ thống sẽ sinh ra cookie tương ứng với mỗi người dùng request nếu request của người dùng chưa có cookie xác thực thì sẽ dùng hai module xác thực ở trên để tạo cookie cho người dùng. Nếu người dùng đã có cookie xác thực thì kiểm tra xem cookie đó có giống với cookie mà hệ thống đã tạo ra không, nếu không trùng thì dùng hai module xác thực để tạo cookie cho người dùng, nếu cookie này trùng khớp
thì cho phép request đi qua hệ thống chống tấn công từ chối dịch vụ để đi vào website.
Về phần xác thực người dùng được chia thành hai module như đã nêu trên và được thiết kế để nhằm mục đích xác thực request hợp lệ và bất hợp lệ một cách hiệu quả nhất.
Xác thực người dùng thông qua javascript: như đã nói ở phần 1.2.2.1 thì thường các công cụ tấn công cũng như kể cả botnet thì do cách thiết kế sao cho có thể tấn công vào website một cách nhanh chóng và hiện quả nhất thường chỉ dùng các là tạo ra request sao cho giống với trình duyệt nhất có thể. Phần lớn các công cụ hầu như không có cơ chế xử lý javascript như trình duyệt thật do việc này đòi hỏi tài nguyên rất lớn. Thêm vào đó với việc các thư viện mô phỏng trình duyệt cũng không hoạt động đúng một 100% và phải chỉnh sửa rất nhiều khi một số website dùng cách thức giảm thiểu tốc độc request bằng javascript như để hàm sleep trong mã javascript. Do đó việc dùng javascript để phân biệt người dùng hợp lệ với các request từ người tấn công là khá hiệu quả. Ngoài ra các trình duyệt hiện tại tất cả đều hỗ trợ javascript và ta có thể thiết kế được cách xác thực sao cho người dùng khi vào website không hề hay biết mình bị xác thực. Điều này đảm bảo cho tính trong suốt cũng như tính tương thích của hệ thống chống tấn công từ chối dịch vụ như ta đã nêu ở phần 1.2.1. Phần này đơn giản nhất là dùng mã javascript để tạo cookie xác thực cho người dùng sau đó reload lại trang web, quá trình này sẽ gần như không thể nhận ra được bởi người dùng và thời gian cho quá trình xác thực sẽ rất ngắn.
Xác thực thông qua captcha: như đã nói ở trên việc xác thực bằng javascript tuy rất hiệu quả nhưng một số trường hợp các công cụ tấn công đặc biệt được đầu tư thời gian phát triển có thể dùng nhiều biệt pháp khác nhau để vượt qua được cách xác thực này. Trong thời điểm những năm 2013 mã độc được thiết kế để tấn công một loạt website của Việt Nam đã dùng cách tài trang web thông qua trình duyệt mặc định của windows là internet explorer sau đó lấy cookie từ request này để dùng cho các request tấn công sau. Với cách thức này người tấn công đã qua mặt
được cơ chế bảo vệ bằng javascript của một số website đang dùng hồi đó kể cả vnexpress khi họ dùng một module là roboo để chặn tấn công ddos. Captcha đã được dùng trong rất nhiều năm qua, mục đích đầu tiên của captcha thường là dùng cho các trang có thông tin người dùng. Các website có thông tin người dùng cần loại bỏ những thông tin được tạo ra không phải con người như các thông tin đăng ký, bảo vệ các trang đăng nhập vào hệ thống. Captcha được thiết kế thông thường mà một nội dung nào đó được thể hiện dưới dạng hình ảnh hoặc âm thanh mà chỉ có con người có thể nhận biết được, máy rất khó hoặc không thể nhận biết được. Với cách này việc phân biệt người và máy rất đơn giản và đạt được hiệu quả rất cao, kể cả với các công nghệ mới nhất bây giờ như deep learning cũng khó có thể qua mặt được cách nhận dạng này. Với module xác thực người dùng thông qua captcha này để có được cookie xác thực người dùng phải gửi lại được captcha hợp lệ lên hệ thống. Nếu captcha không hợp lệ thì phải gửi lại đến khi đúng thì thôi. Tuy hiệu quả rất cao nhưng do khi xác thực người dùng bằng captcha thì phương thức xác thực này không thực sự trong suốt với người dùng, do đó phương thức này chỉ dùng khi người dùng có quá nhiều đặc điểm giống với request tấn công từ chối dịch vụ.
2.2. Xây dựng hệ thống ngăn chặn tấn công từ chối dịch vụ.2.2.1. Lựa chọn công nghệ. 2.2.1. Lựa chọn công nghệ.
Với các chức năng cần thiết của hệ thống như đã nói ở trên cộng với thời gian giới hạn tác giả lựa chọn một proxy mã nguồn mở là nginx. Nginx là một proxy mã nguồn mở với cộng đồng rất lớn khả năng mở rộng cũng như cấu hình rất đơn giản. Ta có thể viết thêm module với nhiều ngôn ngữ khác nhau như c, perl, lua. Các đặc điểm nổi trội của nginx là:
- Xử lý các file tĩnh và file index, tự động đánh index
- Tăng tốc reverse proxy với việc caching, cân bằng tải (load banlancing), khả năng chịu lỗi (fault tolerance)
- Hỗ trợ tăng tốc caching với FastCGI, SCGI, uwsgi
- Giới hạn số kết nối, yêu cầu từ một địa chỉ IP
- Kiểm soát truy cập bởi: địa chỉ IP, mật khẩu (HTTP basic authentication) và từ các yêu cầu con (subrequest)
Khi muốn thêm các tính năng nào đó ta có thể viết thêm module mới rất dễ dàng theo ý muốn. Thêm vào đó do đặc điểm là mã nguồn mởi nên nginx cũng có rất nhiều các bản khác nhau được các nhà phát triển khác phát triển thêm dựa trên mã nguồn gốc với nhiều đặc điểm tốt hơn. Các module của nginx ban đầu có thể viết bằng c hoặc perl, các module viết bằng c thông thường sẽ chạy rất nhanh nhưng khó viết còn các module viết bằng perl thì dễ viết hơn rất nhiều nhưng tốc độ chạy chậm. Sau khi nghiêm cứu toàn bộ các phiên bản khác nhau được phát triển từ nginx tác giả lựa chọn openresty là phiên bản được dùng để phát triển hệ thống chống tấn công từ chối dịch vụ của mình.
Openresty là một phiên bản được phát triển từ nginx, phiên bản này hỗ trợ rất mạnh việt viết module bằng ngôn ngữ cấp cao lua. Hỗ trợ chạy luajit để đảm bảo tốc dộ gần tương đương với các module viết bằng c. Hỗ trợ rất nhiều thư viện cũng như function ngay từ đầu để ta các thể phát triển thêm vào các chức năng như ý muốn. Thêm vào đó openresty được phân phối hoàn toàn miễn phí cộng với cộng đồng người dùng và phát triển tương đối lớn nên khi phát triển hệ thống chống tấn công từ chối dịch vụ sẽ không gặp phải trở ngại về mặt kỹ thuật lớn nào. Với những đặc điểm như trên thì openresty chính là công nghệ rất phù hợp để có thể phát triển được hệ thống với nhiều tính năng, khả năng mở rộng, khả năng đáp ứng nhất có thể.
2.2.2. Xây dựng các thành phần của hệ thống.2.2.2.1. Cài đặt môi trường. 2.2.2.1. Cài đặt môi trường.
Do yêu cầu về chịu tải cũng như việc tương thích với mã nguồn của openresty nên môi trường dùng để chạy hệ thống chống tấn công từ chối dịch vụ sẽ là linux. Sau khi tham khảo rất nhiều phiên bản linux khác nhau tác giả chọn phiên bản centos 6 là một phiên bản được dùng rộng rãi và rất ổn định trong thời điểm hiện tại. Centos được hỗ trợ từ cộng đồng rất lớn và được chạy trên nhiều hệ thống lớn nên khi đưa hệ thống ra chạy thực tế sẽ không gặp phải các lỗi không lường
trước được. Thêm vào đó centos các thư viện gần như đã có sẵn lên sẽ không mất thời gian cho việc cài đặt thư viện cũng như các thành phần cần thiết. Như đã nói ở trên hệ thống sẽ được xây dựng trên nền openresty và ngôn ngữ để lập trình sẽ là lua.
Cài đặt openresty:
#cài đặt repo của epel
rpm -ivh https://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
#cập nhật gói yum update
#cài đặt các gói cần thiết để biên dịch
yum install readline-devel pcre-devel openssl-devel gcc perl wget #download openresty wget https://openresty.org/download/openresty-1.11.2.1.tar.gz #giải nén và biên dịch tar -xvf openresty-1.11.2.1.tar.gz cd openresty-1.11.2.1 ./configure make make install
#openresty được cài vào thư mục /usr/local/openresty
Cài đặt các thư viện lua cần thiết để phát triển hệ thống:
#cài dặt gói cần thiết
yum install git lua-devel unzip #cài đặt luarocks
git clone git://github.com/keplerproject/luarocks.git ./configure
make build make install
#cài đặt các gói cần thiết cho các module
luarocks install luasec OPENSSL_LIBDIR=/usr/lib64/ luarocks install lua-cjson
luarocks install luasocket
#các thư viện sẽ dược cài vào thư mục /usr/local/lib/lua/5.1 #lấy các thư viện cần thiết để phát triển
git clone https://github.com/openresty/lua-resty-limit-traffic
git clone https://github.com/openresty/lua-resty-cookie
git clone https://github.com/openresty/lua-resty-string
git clone https://github.com/hamishforbes/lua-resty-iputils
2.2.2.2. Module tạo cookie xác thực.
Phần quan trọng nhất của module xác thực người dùng là phần tạo cookie xác thực như các yêu cầu đã nói ở phần 2.1.1. Phần cookie xác thực người dùng trong hệ thống sẽ được xây dựng bằng cách:
Bước 1: lấy thời gian hiện tại của hệ thống sau đó chia lấy phần nguyên với một khoảng thời gian xác định gọi là thời gian hợp lệ của cookie.
Bước 2: lấy các giá trị đặc trưng của người dùng ở đây là địa chỉ ip và useragent của request.
Bước 3: Cộng một chuỗi secret mà chỉ server mới có với hai thông tin lấy được ở bước 1 và bước 2 sau đó dùng mã hoá băm với dữ liệu này. Cookie authen cuối cùng sẽ là một chuỗi có độ dài bằng độ dài của thuật toán băm tương ứng. Thuật toán này được triển ra ra code như sau.
local current_time = os.time()
local authen_data = ngx.var.remote_addr .. useragent
local secret = authen_data .. current_time - (current_time % cookie_windows) local sha256 = resty_sha256:new()
sha256:update(key) sha256:update(secret)
local digest = str.to_hex(sha256:final())
Phần này dùng thư viện lua-resty-string của openresty. Trong đó key là chuỗi bí mật chỉ có server có. Cookie xác thực này có những đặc điểm phù hợp với yêu cầu đã được trình bày như:
- Gần như không thể giả được cookie xác thực trừ khi biết được chuỗi bít mật của server.
- Do dùng mã hoá băm nên người tấn công cũng khó có thể đoán được các yếu tố nào dùng để xác thực.
- Cookie chỉ được xác thực trong một khoảng thời gian xác định nên tránh được việc người tấn công dùng mã giả trình duyệt để lấy cookie sau đó dùng cookie này cho các request tấn công từ chối dịch vụ sau.
- Mã hoá băm sha256 có mức độ an toàn tương đối tốt và thời gian chạy