Thứ Sáu, 31 tháng 3, 2017

SYSTEM PERFORMANCE CASE STUDY: SLOW DISKS IN DATABASE (1)

Scott hiện là một sysadmin cho một công ty vừa. Anh ấy vừa nhận được một yêu cầu hỗ trợ (support ticket) từ đội database cho vấn đề đĩa cứng chạy chậm (slow disk) trên một trong các server của họ.
Bước đầu tiên là Scott cần tìm hiểu thêm về tình huống này, tổng hợp các thông tin để làm báo cáo cho đội database. Nội dung trong ticket chỉ nói là disk chạy chậm nhưng không cho biết gì thêm rằng điều này có liên quan tới database đang nằm trên đó hay không. Do vậy, Scott liền phản hồi lại bằng các câu hỏi sau:
1) Server này có đang gặp vấn đề hiệu năng (performance) của database không? Nếu có thì các thông số nào làm minh chứng và tại sao lại phán đoán là do slow disk gây nên?
2) Slow disk xảy ra trong bao lâu rồi?
3) Database gần đây có thay đổi gì không?
Đây là câu trả lời mà Scott nhận được từ đội database: “Chúng tôi có một log để ghi nhận các truy vấn (query) mất trên 1 giây để hoàn tất. Trước giờ khá là ổn nhưng suốt một tuần qua thì chúng tôi nhận thấy trong một giờ có tới hàng chục query bị chậm như vậy. AcmeMon thể hiện rằng các disk đang hoạt động bận rộn.
Qua đó Scott thấy đúng là performance của database đang có vấn đề nhưng nguyên nhân từ disk mới chỉ là nghi vấn mà thôi. Rõ ràng Scott cần kiểm tra disk ngay nhưng cũng không nên bỏ qua các resource khác (RAM, CPU, network) mà có thể là “root cause” của vấn đề.
Ở trên có nhắc tới AcmeMon, đây là một hệ thống mà công ty của Scott sử dụng để giám sát server với các chức năng cơ bản. Nó cung cấp các biểu đồ (graph) thể hiện lược sử performance của server dựa trên các thông số đầu vào có được từ các công cụ của hệ điều hành như mpstat, iostat, v.v… Scott liền đăng nhập vào AcmeMon để tìm hiểu kỹ hơn.
Scott bắt đầu với một phương thức được gọi là USE (Utilization – Saturation – Error) để giúp kiểm tra nhanh xem resource nào đang là điểm bottleneck. Đúng như thông tin từ đội database, utilization (viết tắt là util) của các disk đang ở mức khá cao, chừng 80%, trong khi đó các resource khác (CPU, network) có util thấp hơn nhiều. Dữ liệu trong quá khứ (historical data) cũng cho biết rằng disk util tăng dần trong suốt tuần qua, trong khi CPU util thì giữ ở mức ổn định. AcmeMon không cung cấp các thông kê còn lại cho saturation (mức độ “extra workload” mà resource không thể đáp ứng ngay được và tạm thời phải đưa vào queue) và error. Vì vậy mà để hoàn tất quy trình USE thì Scott buộc phải đăng nhập vào server database để có thể chạy thêm một số dòng lệnh.
Anh ấy kiểm tra bộ counter cho disk error từ /proc; chúng toàn là zero cả, OK ổn. Tiếp đó Scott chạy iostat với chu kỳ là 1 giây và quan sát các thông số utilization và saturation theo thời gian thực. AcmeMon báo cáo là 80% util nhưng với chu kỳ là 1 phút. Còn ở mức 1 giây, Scott thấy là disk util dao động khá lớn, có lúc chạm ngưỡng 100% và khiến cho tình trạng saturation xảy ra và làm tăng disk I/O latency.
Để có thể xác tín thêm là chính slow disk đang làm database xử lý query chậm, Scott chạy một script được viết dựa trên cơ chế “dynamic tracing” để mỗi khi database được deschedule bởi OS kernel thì liền ghi nhận lại các mốc thời gian (timestamp) với các “database stack trace” tương ứng. Kết quả cho thấy mỗi khi database xử lý một query mà cần đọc dữ liệu từ file system thì thường bị ngưng lại trong nhiều mili giây. Chừng này chứng cứ có lẽ đã đủ với Scott.
Câu hỏi kế đến là: tại sao lại có tình trạng slow disk này? Là do disk bị trục trặc hay do đâu? Thống kê cho thấy slow disk đi cùng với high disk load (xảy ra khi lượng I/O request hoặc I/O size lớn). Scott thực hiện nhận dạng “workload pattern” để hiểu thêm về chỗ này, sử dụng iostat để đo lường IOPS, throughput, average I/O latency, read/write ratio. Từ những tham số này, anh ấy cũng tính được average I/O size và ước tính “access pattern”: random hay sequential. Nếu cần chi tiết hơn, Scott có thể sử dụng thêm các công cụ khác để theo dõi ở mức disk I/O; tuy nhiên, tới lúc này thì anh ấy thỏa mãn với trường hợp bị chậm là do high load disk chứ bản thân disk đó không có vấn đề.
Scott bắt đầu cập nhật cho ticket các chi tiết mà anh ấy đã kiểm tra và kèm theo đó là ảnh chụp màn hình của những dòng lệnh được dùng. Thế nhưng cái gì đã gây ra high load cho disk? Scott tiếp tục với luồng suy đoán đơn giản: có phải là do workload đẩy xuống cho database tăng không? Đội database nói rằng không phải, vì tần suất query (AcmeMon không thu thập số liệu này) hồi giờ vẫn ổn định và điều này khớp với thông tin ban đầu có được là CPU util cũng ổn định.
Scott nghĩ tới các khả năng khác mà có thể gây ra high disk I/O load nhưng không làm tăng CPU util và đã đem vấn đề này ra trao đổi với các đồng nghiệp của anh ấy. Một trong số họ gợi ý rằng thử kiểm tra xem hiện trạng phân mảnh dữ liệu (fragmentation) thế nào, điều này dễ xảy ra khi file system đã tới ngưỡng 100% capacity và vì thế làm cho việc đọc/ghi lên disk trở nên chậm chạp hơn. Nhưng rất tiếc, Scott thấy rằng capacity của disk chỉ mới đạt 30% mà thôi.
Scott biết rằng mình có thể tiến hành phân tích kỹ hơn để hiểu chính xác điều gì đang xảy ra nhưng cho là làm như vậy sẽ tốn thì giờ quá. Do vậy, anh ấy gắng nghĩ về các lý giải khác đơn giản hơn mà có thể kiểm tra được ngay dựa trên hiểu biết của bản thân về kernel I/O stack. Anh nhớ lại là đã từng có tình huống disk I/O kiểu này phát sinh khi có nhiều “miss page cache” trong file system.
OK, Scott liền kiểm tra tỉ lệ hit cache của filesystem và thấy là đạt 91%. Con số này tương đối cao nhưng anh ấy lại không có dữ liệu lược sử để có sự so sánh. Scott đăng nhập tiếp vào các server database khác với cùng workload tương đương và thấy là tỉ lệ hit cache của chúng đều hơn 97%. Anh ấy cũng nhận thấy rằng cache size của file system trên server bị slow disk là lớn hơn nhiều so với các server kia.
Dò xét trên đã chuyển trọng tâm của vấn đề sang cache size của file system và memory usage của server, Scott nhận ra là còn một thứ đã bị bỏ qua: có một dự án phát triển ứng dụng mới ở dạng prototype đang tiêu hao nhiều memory mặc dù nó chưa được chạy trong môi trường production. Lượng memory này bị chiếm dụng từ phần vốn dành cho page cache dẫn tới tỉ lệ hit giảm, do vậy mà làm tăng disk I/O và hệ quả là ảnh hưởng tới database production đang chạy.
Scott liên hệ với đội phát triển ứng dụng và đề nghị họ tắt cái prototype kia đi và chuyển nó sang một server khác. Tới đây thì mọi thứ đã trở nên sáng tỏ hơn, sau hành động trên, AcmeMon báo disk util đã giảm khi mà file system cache đã lấy lại kích thước ban đầu dành cho nó. Slow query gần về zero và ticket coi như đã được giải quyết.

Thứ Năm, 30 tháng 3, 2017

HTTP Request Và HTTP Response

PHẠM HỒNG PHIHTTP là giao thức được thiết kế theo kiểu client – server, giao tiếp giữa client và server dựa vào một cặp request – response, client đưa ra các request và server trả lời các request này. Bài viết sẽ giúp các bạn tìm hiểu về hai loại thông điệp HTTP Request và HTTP Response của giao thức HTTP.

Giới thiệu

Tìm hiểu về hai loại thông điệp HTTP Request và HTTP Response của giao thức HTTP.

Tiền đề bài viết

Bài viết nhằm củng cố kiến thức của tôi cũng như giới thiệu với các bạn chưa biết về vấn đề này.

Đối tượng hướng đến

Bài viết dành cho những người muốn tìm hiểu sâu hơn về mạng máy tính nói chung và giao thức HTTP nói riêng. 

HTTP Message

Như chúng ta đã biết, HTTP là giao thức được thiết kế theo kiểu client – server, giao tiếp giữa client và server dựa vào một cặp request – response, client đưa ra các request và server trả lời các request này.

HTTP Request

Để bắt đầu trao đổi dữ liệu, phía client khởi tạo một HTTP session bằng cách mở một kết nối TCP đến HTTP server sau đó gửi request đến server này. Request có thể được tạo bằng nhiều cách, trực tiếp khi người dùng nhấp vào một liên kết trên trình duyệt hoặc gián tiếp, ví dụ như một video được đính kèm trong một website và việc request đến website này sẽ dẫn đến một request tới video ấy.
ss_1
Ví dụ một HTTP Request
Bắt đầu của HTTP Request sẽ là dòng Request-Line bao gồm 3 thông tin đó là:
  • Method: là phương thức mà HTTP Request này sử dụng, thường là GET, POST, ngoài ra còn một số phương thức khác như HEAD, PUT, DELETE, OPTION, CONNECT. Trong ví dụ trên là GET
  • URI: là địa chỉ định danh của tài nguyên. Trong tường hợp này URI là / - tức request cho tài nguyên gốc, nếu request không yêu cầu một tài nguyên cụ thể, URI có thể là dấu *.
  • HTTP version: là phiên bản HTTP đang sử dụng, ở đây là HTTP 1.1.
Tiếp theo là các trường request-header, cho phép client gửi thêm các thông tin bổ sung về thông điệp HTTP request và về chính client. Một số trường thông dụng như:
  • Accept: loại nội dung có thể nhận được từ thông điệp response. Ví dụ: text/plain, text/html…
  • Accept-Encoding: các kiểu nén được chấp nhận. Ví dụ: gzip, deflate, xz, exi…
  • Connection: tùy chọn điều khiển cho kết nối hiện thời. Ví dụ: keep-alive, Upgrade…
  • Cookie: thông tin HTTP Cookie từ server.
  • User-Agent: thông tin về user agent của người dùng.

Phương thức GET và POST

Hai phương thức được sử dụng nhiều nhất trong HTTP request là GET và POST
Với GET, câu truy vấn sẽ được đính kèm vào đường dẫn của HTTP request. Ví dụ: /?username=”abc”&password=”def”
Một số đặc điểm của phương thức GET:
  • GET request có thể được cached, bookmark và lưu trong lịch sử của trình duyệt.
  • GET request bị giới hạn về chiều dài, do chiều dài của URL là có hạn.
  • GET request không nên dùng với dữ liệu quan trọng, chỉ dùng để nhận dữ liệu.
Ngược lại, với POST thì câu truy vấn sẽ được gửi trong phần message body của HTTP request, một số đặc điểm của POST như:
  • POST không thể, cached, bookmark hay lưu trong lịch sử trình duyệt.
  • POST không bị giới hạn về độ dài.
Các phương thức khác
Ngoài GET và POST, HTTP request còn có thể có một số phương thức khác như:
  • HEAD:; giống như GET nhưng chỉ gửi về HTTP header.
  • PUT: tải lên một mô tả về URI định trước.
  • DELETE: xóa một tài nguyên định trước.
  • OPTIONS: trả về phương thức HTTP mà server hỗ trợ.
  • CONNECT: chuyển kết nối của HTTP request thành một kết nối HTTP tunnel.

HTTP Response

Cấu trúc HTTP response gần giống với HTTP request, chỉ khác nhau là thay vì Request-Line, thì HTTP có response có Status-Line. Và giống như Request-Line, Status-Line cũng có ba phần như sau:
  • HTTP-version: phiên bản HTTP cao nhất mà server hỗ trợ.
  • Status-Code: mã kết quả trả về.
  • Reason-Phrase: mô tả về Status-Code.
ss_2
Ví dụ một HTTP Response

HTTP Status Codes

Một số loại Status-Code thông dụng mà server trả về cho client như sau:
1xx: information Message: các status code này chỉ có tính chất tạm thời, client có thể không quan tâm.
2xx Successful: khi đã xử lý thành công request của client, server trả về status dạng này:
  • 200 OK: request thành công.
  • 202 Accepted: request đã được nhận, nhưng không có kết quả nào trả về, thông báo cho client tiếp tục chờ đợi.
  • 204 No Content: request đã được xử lý nhưng không có thành phần nào được trả về.
  • 205 Reset: giống như 204 nhưng mã này còn yêu câu client reset lại document view.
  • 206 Partial Content: server chỉ gửi về một phần dữ liệu, phụ thuộc vào giá trị range header của client đã gửi.
3xx Redirection: server thông báo cho client phải thực hiện thêm thao tác để hoàn tất request:
  • 301 Moved Permanently: tài nguyên đã được chuyển hoàn toàn tới địa chỉ Location trong HTTP response.
  • 303 See other: tài nguyên đã được chuyển tạm thời tới địa chỉ Location trong HTTP response.
  • 304 Not Modified: tài nguyên không thay đổi từ lần cuối client request, nên client có thể sử dụng đã lưu trong cache.
4xx Client error: lỗi của client:
  • 400 Bad Request: request không đúng dạng, cú pháp.
  • 401 Unauthorized: client chưa xác thực.
  • 403 Forbidden: client không có quyền truy cập.
  • 404 Not Found: không tìm thấy tài nguyên.
  • 405 Method Not Allowed: phương thức không được server hỗ trợ.
5xx Server Error: lỗi của server:
  • 500 Internal Server Error: có lỗi trong quá trình xử lý của server.
  • 501 Not Implemented: server không hỗ trợ chức năng client yêu cầu.
  • 503: Service Unavailable: Server bị quá tải, hoặc bị lỗi xử lý.
Link tham khảo:
https://passionery.blogspot.com/2014/01/http-header-la-gi.html#.U5mQOI2Szfg

Hướng dẫn block User Agent với Ngin

Khi sử dụng Nginx, bạn có thể dễ dàng block request GET / POST bất kỳ dựa theo User Agent.
gun
Mình tìm hiểu phương pháp này khi website thường xuyên bị spam mail với nhiều IP khác nhau, tuy nhiên điểm chung là header của chúng giống hệt nhau. Nginx block rất hiệu quả.
Ngoài ra, bạn có thể ứng dụng để block Bot, Spider, chống crawl…

Hướng dẫn block User Agent với Nginx

Mở file cấu hình tên miền (nếu dùng HocVPS Script file cấu hình ở đường dẫn /etc/nginx/conf.d/), trong section server, hãy thêm đoạn code if sau:
server {
    listen       80 default_server;

    root         /home/hocvps.com/public_html;
    index index.php index.html index.htm;
    server_name hocvps.com;

    # case sensitive matching
    if ($http_user_agent ~ (Antivirx|Arian)) {
        return 403;
    }

    # case insensitive matching
    if ($http_user_agent ~* (netcrawl|npbot|malicious)) {
        return 403;
    }

    ....
}
Sau đó nhớ restart lại Nginx.
Tùy bạn lựa chọn:
  • case sensitive matching: phân biệt chữ in hoa, chữ in thường
  • case insensitive matching: không phân biệt in hoa, in thường
Để tìm được header cần filter, tất nhiên bạn sẽ phải phân tích file access.log trước.
Để test kết quả bạn có thể dùng lệnh wget kèm theo option --user-agent, ví dụ:
wget --spider --user-agent "malicious bot" http://domain.com
Đây là đoạn code mình dùng để block request spam comment các bạn có  thể tham khảo thêm:
    #Block Spam comment
    location ~* /wp-comments-post\.php$ {
        if ($http_user_agent ~* "x11; linux i686; rv:17" ) {
            return 403;
        }
    }
Chúc bạn thành công.

Thứ Tư, 29 tháng 3, 2017


Giám sát an ninh mạng - hay là làm thế nào để ngăn chặn một cuộc tấn công DDoS trong 20'
Để bắt đầu thì tôi xin chia sẻ một câu chuyện. Cách đây không lâu, web site của một khách hàng bị tấn công từ chối dịch vụ DDoS. Vào lúc cao trào của vụ tấn công, có hơn 10.000 IP đến từ khắp nơi trên thế giới liên tục gửi hàng ngàn yêu cầu mỗi giây đến hệ thống của khách hàng này. Hình ảnh (slide số 4) mà quý vị đang thấy trên màn hình gồm có 2 phần nhỏ. Phần ở trên là lưu lượng dữ liệu ra vào hệ thống lúc bình thường, không bị tấn công. Phần ở dưới là lưu lượng dữ liệu ra vào hệ thống của ngay tại thời điểm đang bị tấn công dữ dội.
Như quý vị cũng thấy, chỉ trong vòng 10′, từ lúc 16h10 đến 16h20, lượng dữ liệu ra vào đã tăng đột biến lên gấp gần 10 lần lúc bình thường. Nhưng đồng thời, chỉ trong vòng chưa tới 20′, chúng tôi đã kiểm soát được vụ tấn công này, và đưa toàn bộ hệ thống trở lại tình trạng bình thường. Chúng tôi làm được như vậy tất cả là nhờ vào việc đã áp dụng tốt các công nghệ và nguyên tắc của giám sát an ninh mạng.
Nếu quý vị từng phải xử lý một vụ tấn công DDoS, tôi tin chắc có một câu hỏi mà quý vị đã phải tự hỏi nhiều lần: chuyện gì đang diễn ra vậy? Tại sao hệ thống của tôi đang chạy ngon lành tự dưng lại cứng đơ, khách hàng không sử dụng được nữa?
Bản thân tôi cho rằng đây là câu hỏi tối quan trọng mà bất kỳ ai làm việc trong lĩnh vực an ninh mạng đều phải tự hỏi và phải có câu trả lời xác đáng. Ngay tại thời điểm này đây, ngay khi quý vị đang ngồi ở đây nghe tôi trình bày, quý vị có biết ai đang làm gì ở đâu như thế nào trên hệ thống của quý vị hay không?
Tại sao câu hỏi đó quan trọng? Tại sao quý vị cần phải biết được ai đang làm gì ở đâu như thế nào trên hệ thống của quý vị? Đơn giản vì chúng ta không thể bảo vệ một hệ thống nếu chúng ta không biết được trạng thái của hệ thống đó. Và chúng ta chỉ có thể biết được trạng thái của một hệ thống bằng cách theo dõi nó thường xuyên. Nói cách khác, chúng ta phải biết được tất cả các hoạt động đã và đang diễn ra trên hệ thống.
Thử nhìn vào hoạt động của một khách sạn. Để đảm bảo an ninh, người ta phải đặt camera theo dõi ở khắp nơi. Các camera này chắc hẳn sẽ đưa hình ảnh về một địa điểm tập trung, nơi có các chuyên viên theo dõi 24/7 để kịp thời phát hiện và đối phó với các sự cố an ninh.
Tương tự như thế, muốn đảm bảo an ninh thông tin chúng ta cũng phải tiến hành theo dõi 24/7. Nhưng trong thực tế, theo quan sát của tôi, rất ít tổ chức ở VN có một hệ thống giám sát an ninh như thế. Để bảo vệ hệ thống mạng của mình, các doanh nghiệp và các tổ chức công thường triển khai các thiết bị như tường lửa, phần mềm chống và diệt virus, thiết bị phát hiện xâm nhập, thiết bị ngăn chặn xâm nhập. Rõ ràng họ nghĩ rằng, các thiết bị này đảm bảo an ninh mạng cho họ nên họ mới đầu từ nhiều tiền của để triển khai chúng.
Thật tế hầu hết những người giữ quyền quyết định đầu tư cho an toàn thông tin thường hay hành động theo thị trường. Ví dụ như cách đây vài năm, tường lửa là mốt. Ai cũng đầu tư làm hệ thống tường lửa nên chúng ta cũng phải làm tường lửa. Sau đó, các giải pháp phát hiện xâm nhập lên ngôi. Bây giờ cái gì đang là trào lưu quý vị biết không? ISO 27001.
Lãnh đạo doanh nghiệp thấy các các doanh nghiệp khác triển khai ISO 27001 nên họ cũng muốn doanh nghiệp của họ phải đạt được chuẩn này. Tôi không nói rằng tường lửa, thiết bị phát hiện xâm nhập hay đạt được các chuẩn như ISO 27001 và ITIL là không có tác dụng, nhưng câu hỏi chúng ta cần phải tự hỏi là: tại sao sau khi triển khai quá trời thứ đắt tiền và tốn thời gian như thế, chúng ta vẫn bị xâm nhập, chúng ta vẫn bị tấn công? Liệu ISO 27001 hay tường lửa có giúp bạn khắc phục được một vụ tấn công từ chối dịch vụ trong vòng 20′? Rồi khi đã bị xâm nhập, có thiết bị đắt tiền hay tiêu chuẩn nào giúp quý vị biết được hệ thống của quý vị bị xâm nhập khi nào, tại sao và như thế nào hay không?
Chỉ có con người mới có khả năng làm việc đó. Đây là điều tôi muốn nhấn mạnh, các thiết bị hay các tiêu chuẩn sẽ trở nên vô tác dụng nếu chúng ta không có con người thường xuyên theo dõi, giám sát hệ thống. Nghĩa là, chúng ta cần các chuyên gia giám sát hệ thống có chuyên môn cao.
Tại sao chúng ta cần phải có chuyên gia, tại sao tự bản thân các thiết bị hay các tiêu chuẩn không thể bảo vệ hệ thống mạng? Bởi vì những kẻ tấn công rất thông minh, không thể dự đoán và rất có thể có động lực cao nhất là khi thương mại điện tử phát triển như bây giờ. Máy móc và quy trình không thể ngăn chặn được họ, chắc chắn là như thế. Máy móc chắc chắn sẽ thua khi chiến đấu với não người. Đó là lý do chúng ta cần con người, cần những chuyên gia, để biến an ninh mạng thành một cuộc chiến cân sức hơn giữa người và người, thay vì giữa máy và người.
Câu hỏi đặt ra là các chuyên gia an ninh mạng cần gì để có thể phát hiện và xử lý các sự cố an ninh mạng cũng như xây dựng các kế hoạch phòng thủ? Câu trả lời chỉ có một: tất cả dữ liệu mà chúng ta có thể thu thập được trên hệ thống mạng trong khi sự cố xảy ra!
Quý vị còn nhớ ví dụ của tôi v/v làm sao để bảo vệ an ninh cho một khách sạn? Người quản lý cố gắng thu thập tất cả các dữ liệu, ở đây là hình ảnh và âm thanh, bằng các camera đặt khắp nơi trong khách sạn, và họ cần có các chuyên gia lành nghề để phân tích các hình ảnh này để kịp thời xử lý các sự cố. Họ có hệ thống chống và phát hiện cháy, họ có hệ thống chống trộm, nhưng những máy móc đó chỉ là công cụ, phần việc chính vẫn phải do con người, là các chuyên gia thực hiện.
Tóm lại, để đảm bảo an ninh, chúng ta cần phải theo dõi giám sát hệ thống mạng 24/7, và để làm chuyện đó chúng ta cần có các chuyên gia và các chuyên gia cần dữ liệu để thực hiện công việc của họ. Giám sát an ninh mạng chính là phương thức giúp chúng ta có thể thực hiện việc này một cách tối ưu nhất. Vậy giám sát an ninh mạng là gì?
Thuật ngữ giám sát an ninh mạng được chính thức định nghĩa vào năm 2002 và về cơ bản nó gồm 3 bước: thu thập dữ liệu, phân tích dữ liệu và leo thang thông tin.
Để thu thập dữ liệu, chúng ta sẽ sử dụng các phần mềm hay giải pháp có sẵn trên thị trường để thu thập dữ liệu ghi dấu hoạt động của các máy chủ, thiết bị mạng, phần mềm ứng dụng, cơ sở dữ liệu…Nguyên tắc của thu thập dữ liệu là thu thập càng nhiều càng tốt, với mục tiêu là chúng ta phải có đầy đủ thông tin về trạng thái, log file của tất cả các thành phần trong hệ thống cần phải bảo vệ. Bởi vì có muôn hình vạn trạng các loại tấn công và sự cố ATTT, chúng ta không thể biết trước dữ liệu nào là cần thiết để có thể phát hiện và ngăn chặn loại tấn công nào. Nên kinh nghiệm của tôi là nếu mà luật pháp và công nghệ cho phép, cứ thu thập hết tất cả dữ liệu mà quý vị có thể. Nguyên tắc “thà giết lầm còn hơn bỏ sót” có thể áp dụng ở đây.
Nếu phần mềm có thể giúp chúng ta làm công việc thu thập dữ liệu, thì để phân tích dữ liệu và ra quyết định, như đã nói ở trên, chúng ta cần có chuyên gia, bởi chỉ có chuyên gia mới có thể hiểu rõ ngữ cảnh của dữ liệu mà phần mềm đã thu thập được. Ngữ cảnh là tối quan trọng. Một dữ liệu được thu thập trong ngữ cảnh A có thể sẽ có ý nghĩa rất khác với cùng dữ liệu đó nếu nó thuộc về ngữ cảnh B. Ví dụ như một ngày đẹp trời hệ thống thu thập dữ liệu cảnh báo rằng một số file chương trình trên một máy chủ quan trọng đã bị thay đổi. Nếu như xét ngữ cảnh A là máy chủ đó đang được nâng cấp phần mềm, thì thông tin này không có nhiều ý nghĩa. Nhưng nếu như ở ngoài ngữ cảnh A đó, nói cách khác, không có một yêu cầu thay đổi phần mềm nào đang được áp dụng cho máy chủ đó cả, thì rõ ràng rất có thể máy chủ đó đã bị xâm nhập. Và chỉ có những chuyên gia mới có thể cung cấp được những ngữ cảnh như thế.
Quy trình giúp cho chúng ta leo thang thông tin. Leo thang thông tin là việc các chuyên gia báo cáo lên trên cho những người có quyền quyết định những vấn đề mà họ cho là quan trọng, cần phải điều tra thêm. Những người có quyền quyết định là những người có đủ thẩm quyền, trách nhiệm và năng lực để quyết định cách đối phó với các sự cố ANTT tiềm tàng. Không có leo thang thông tin, công việc của các chuyên gia sẽ trở thành vô ích. Tại sao phải phân tích để phát hiện các sự cố ANTT tiềm tàng nếu như chẳng có ai chịu trách nhiệm cho việc xử lý chúng?
Quay trở lại với câu chuyện vụ tấn công từ chối dịch vụ mà tôi chia sẻ ban đầu. Hệ thống giám sát an ninh mạng của chúng tôi thu thập tất cả dữ liệu liên quan đến hoạt động của các thiết bị như tường lửa, máy chủ proxy, máy chủ web, các ứng dụng web chạy trên các máy chủ web. Dựa vào nguồn dữ liệu phong phú này, các chuyên gia của chúng tôi đã không mất quá nhiều thời gian để phân tích và nhận ra các dấu hiệu bất thường trên hệ thống. Họ leo thang thông tin bằng cách thông báo cho tôi, và tôi quyết định kích hoạt quá trình đối phó với sự cố ANTT, ở đây là đối phó khi bị tấn công từ chối dịch vụ.
Về mặt kỹ thuật, chúng tôi đã cài đặt sẵn các biện pháp kiểm soát tự động trên hệ thống giám sát an ninh mạng, nên các chuyên gia của tôi chỉ phải theo dõi vụ tấn công xem có diễn tiến gì bất thường hay không mà không phải thực hiện thêm bất kỳ thao tác nào. Về mặt hành chính, tôi thông báo cho lãnh đạo doanh nghiệp và các đơn vị như Trung Tâm Chăm Sóc Khách hàng, Trung tâm Vận hành Data Center cũng như mở kênh liên lạc với các ISP để nhờ họ trợ giúp nếu như đường truyền bị quá tải. Như quý vị đã thấy trong một slide ở phía trước, chỉ chưa tới 20′, vừa ngay sau lần kích hoạt hệ thống phòng thủ đầu tiên, vụ tấn công đã được kiểm soát thành công. Hệ thống giám sát an ninh mạng cũng giúp chúng tôi làm các báo cáo để gửi lãnh đạo cũng như gửi các cơ quan điều tra nhờ hỗ trợ truy tìm thủ phạm.
Toàn bộ phương thức giám sát an ninh mạng chỉ đơn giản như thế. Đến đây là chúng ta xong phần 1 của bài trình bày này. Tiếp theo tôi sẽ chia sẻ một số thông tin về hệ thống cũng như công tác giám sát an ninh mạng.
Về mặt kỹ thuật, chúng tôi không mất quá nhiều thời gian cho việc thiết kế hệ thống và lựa chọn giải pháp, bởi vì ngay từ đầu chúng tôi đã xác định đây là một lĩnh vực tương đối mới mẻ, thành ra một giải pháp hoàn chỉnh sẽ không có trên thị trường. Thay vào đó, giống như phát triển phần mềm theo nguyên lý agile, chúng tôi làm vừa làm vừa điều chỉnh.
Chúng tôi khởi đầu bằng việc xây dựng một hệ thống log tập trung. Như đã nói ở trên, đây là công đoạn thu thập dữ liệu. Trong quá trình làm, chúng tôi nhận thấy hầu hết các ứng dụng chạy trên nền UNIX hay các thiết bị mạng đều hỗ trợ sẵn chuẩn syslog, thành ra chúng tôi quyết định chọn phần mềm mã nguồn mở syslog-ng làm công cụ chính để thu thập log.
Tuy nhiên có hai vấn đề: các máy chủ Windows mặc định không hỗ trợ syslog; và một số ứng dụng do chúng tôi tự phát triển hay mua ngoài cũng không hỗ trợ syslog. Đối với vấn đề thứ nhất, chúng tôi cài đặt thêm một phần mềm cho các máy chủ Windows, để đẩy các sự trên trên đó về hệ thống log của chúng tôi. Đối với vấn đề thứ hai, việc đầu tiên chúng tôi làm là xây dựng một quy định về log của các ứng dụng. Trong quy định này chúng tôi yêu cầu tất cả các ứng dụng muốn được cấp quyền chạy trên hệ thống của chúng tôi thì phải thỏa mãn các tiêu chí về log các sự kiện. Chúng tôi cũng hướng dẫn và cung cấp thư viện phần mềm mẫu để các lập trình viên có thể tích hợp vào phần mềm có sẵn của họ.
Syslog-ng là một phần mềm mã nguồn mở tuyệt vời. Nó hoạt động cực kỳ ổn định, bền vững. Trong suốt hơn 3 năm triển khai hệ thống này, chúng tôi chưa bao giờ gặp sự cố ở phần mềm này. Nhưng syslog-ng cũng chỉ làm tốt nhiệm vụ thu thập dữ liệu, làm sao phân tích dữ liệu đó? Trên thị trường lúc bấy giờ có khá nhiều công cụ giúp giải quyết vấn đề này. Chúng tôi lần lượt thử nghiệm các công cụ này, và rồi chúng tôi phát hiện ra Splunk. Chúng tôi hay gọi phần mềm này là “Splunk toàn năng”. Một công cụ phân tích dữ liệu trên cả tuyệt vời!

Splunk rất hay, nhưng nếu không có các chuyên gia có kỹ năng phân tích dữ liệu để khai thác Splunk thì hệ thống cũng sẽ không đem lại nhiều ích lợi. Cái hay của Splunk là ở chỗ nó đã làm cho công việc phân tích log tưởng như nhàm chán trở nên cực kỳ thú vị. Chỉ trong một thời gian ngắn, nhân viên của tôi đã bị Splunk mê hoặc. Cái tên “Splunk toàn năng” cũng là do anh ấy đặt cho Splunk. Thành ra chúng tôi cũng không mất quá nhiều thời gian để huấn luyện, bởi vì tự bản thân giải pháp nó đã đủ thú vị để cuốn hút con người chủ động tìm hiểu nó.

Điều tối quan trọng nhất đối với một hệ thống giám sát an ninh là khả năng phân tích một lượng dữ liệu lớn một cách nhanh chóng. Splunk làm rất tốt việc này. Tuy vậy trên thị trường vẫn có các giải pháp khác hoàn toàn miễn phí như tôi liệt kê ở trên. Bản thân tôi cho rằng Hadoop + Scribe + Hive là một hướng nghiên cứu nhiều tiềm năng.

Với hệ thống này, bây giờ chúng tôi có thể an tâm rằng tôi có thể biết được chuyện gì đang diễn ra trên hệ thống mạng của các khách hàng của chúng tôi ngay tại thời điểm tôi đang viết những dòng này.

Về phía lãnh đạo doanh nghiệp, họ cũng an tâm khi biết rằng, chúng tôi có thể phát hiện, truy vết và đối phó lại với bất kỳ sự cố ANTT nào diễn ra trên hệ thống của họ. Thực tế là từ khi triển khai giải pháp này, chúng tôi giải quyết được 100% các sự cố an toàn thông tin trên hệ thống của các khách hàng của chúng tôi.

Ngoài ra hệ thống này còn giúp chúng tôi phát hiện và xử lý hơn phân nửa các sự cố an toàn thông tin. Có rất nhiều tình huống, nếu không có sự hỗ trợ của hệ thống này, chúng tôi sẽ không thể giải quyết được vấn đề. Lại quay lại với câu chuyện bị tấn công DDoS ở trên.

Nhắc lại, một khách hàng của chúng tôi từng bị tấn công DDoS trên diện rộng vào hệ thống máy chủ Internet Banking. Ở thời điểm cao trào, có hơn 10000 IP gửi hàng ngàn request/s đến máy chủ của họ. Làm thế nào để nhanh chóng lấy ra được danh sách 10000 IP này, ngăn chặn chúng trên hệ thống firewall, mà không chặn nhầm khách hàng? Làm thế nào để có thể tự động hóa quá trình trên, chẳng hạn như cứ mỗi 15′ sẽ lấy ra danh sách các IP đang tấn công, cập nhật bộ lọc của tường lửa?

Với hệ thống này, chúng tôi chỉ cần soạn thảo một đoạn script ngắn để lấy ra danh sách IP đang gửi hơn 100 request/s rồi cài đặt chương trình để tự động cập nhật bộ lọc của firewall mỗi 15′. Một vấn đề tưởng như nan giải có thể giải quyết nhanh gọn lẹ và rất rẻ.

Các giải pháp chống DDoS sẽ có 2 thành phần chính: phát hiện và đánh chặn. Các giải pháp có sẵn trên thị trường như các thiết bị của các hãng lớn hay các giải pháp mở như Iptables + Snort inline thường cố gắng phân tích các packet/request để phân loại chúng theo thời gian thực. Nghĩa là khi có một packet/request đi vào, các giải pháp này sẽ cố gắng xác định xem packet đó có phải là một phần của vụ tấn công hay không, nếu phải thì thực hiện đánh chặn.

Sự khác biệt của giải pháp của chúng tôi so với các giải pháp chống DDoS đang có trên thị trường là chúng tôi không cố gắng phân loại và ngăn chặn các packet/request theo thời gian thực. Thay vào đó, chúng tôi tách phần phát hiện ra khỏi hệ thống phòng thủ, và thực hiện phần phát hiện hoàn toàn offline bằng cách sử dụng thông tin từ hệ thống NSM.

Cụ thể, thông tin từ hệ thống đánh chặn cũng như các nguồn khác như web server, proxy hay firewall sẽ được đưa vào hệ thống phân tích để chạy offline, rồi kết quả phân tích này sẽ được cập nhật ngược trở lại cho hệ thống đánh chặn. Với cách làm này, giải pháp của chúng tôi có thể đáp ứng được lượng tải rất lớn vì chúng tôi không phải tốn quá nhiều resource để phân tích on-the-fly một packet hay request như các giải pháp khác.

Về các hướng phát triển trong thời gian tới, tôi thấy một ứng dụng hay ho khác của hệ thống giám sát an ninh mạng là nó giúp chúng tôi có thể đo lường được mức độ an toàn của hệ thống. Có một nguyên tắc lâu đời của quản lý là: chúng ta không thể quản lý những gì chúng ta không thể đo đạc. Do đó để quản lý được an toàn thông tin, chúng ta phải biến an toàn thông tin thành những thông số có thể đo đạc và so sánh được. Đây là một hướng tiếp cận an toàn thông tin từ góc nhìn của người quản lý mà chúng tôi muốn áp dụng cho các khách hàng trong thời gian sắp tới.

Tính năng Transparent HugePage trong RHEL6 và ảnh hưởng

Transparent HugePage là gì?

Transparent HugePage (THP) là một tính năng của Linux Kernel và được mặc định "bật" trong RHEL6. Tính năng này có đặc thù gì mà RHEL lại mặc định bật tính năng này lên?
Để hiểu được THP, ta quay lại tìm hiểu cách Linux quản lý bộ nhớ. Bộ nhớ trên Linux được chia làm các pages. Mỗi pages có kích thước 4096 bytes. CPUs có một đơn vị phần cứng chuyên chịu trách nhiệm quản lý bộ nhớ gọi là Memory Management Unit (MMU). Bộ phận này quản lý bảng danh sách các pages, mỗi phần tử được tham chiếu qua một page table entry
Có 2 cách tăng danh sách bộ nhớ quản lý được:
  • Tăng kích thước bảng danh sách pages
  • Tăng kích thước mỗi pages
RHEL THP giải quyết việc quản lý bộ nhớ theo cách 2. Kích thước mỗi page thay vì 4KB sẽ tăng lên từ 2MB đến 1GB. Nhờ vậy chỉ với số lượng entry nhỏ, bộ nhớ quản lý được có thể trải ra hàng TB. Ngoài ra HugePage có đặc điểm: HugePage một khi được khởi tạo lúc khởi động sẽ không bao giờ được swap xuống đĩa cứng.

Tại sao dùng Transparent HugePage?

HugePage cũng giúp bảng quản lý page của MMU có ít entry hơn, giảm overhead của việc quản lý bảng này. Ngoài ra do đặc thù của HugePage là không bị swap ra đĩa cứng, swap daemon (kswapd) không cần phải quan tâm đến những page này. Kernel không phải tìm pages này. Như vậy, số lượng pages giảm đồng nghĩa với việc các thao tác với bộ nhớ sẽ giảm, đồng thời giảm bottleneck tại bộ nhớ

Người bị hại bởi HugePage

Transparent HugePage có vẻ là tính năng cải thiện hiệu năng đáng kể và có lẽ vì lý do đó mà RHEL 6 bật chức năng này từ đầu. Tuy nhiên, nếu tìm thử trên google bạn sẽ thấy số lượng "người bị hại" bởi tính năng này cũng không kém. Redis khuyên nên tắt chức năng HugePage để giảm latency. Bật HugePage làm giảm hiệu năng của Riak và Elasticsearch. Các vendor cung cấp giải pháp BigData hadoop như Cloudera cũng khuyến cáo nên tắt chức năng này. Sổ tay cấu hình hệ thống của nhiều sysadmins cũng ghi chú là nên tắt chức năng nàyviết

HugePage có lợi khi nào?

Nhìn danh sách các middleware yêu cầu tắt THP mình đã tự hỏi là ứng dụng kiểu nào thì sẽ có lợi từ chức năng này. Mình thử google và ra một số báo cáo cho thấy là hiệu năng có tăng lên sau khi dùng THP. Báo cáo của IBM cho thấy dùng RHEL6 với THP bật giúp tăng hiệu năng máy chủ WebSphere
alt text
Theo như báo cáo thì hiệu năng tăng khoảng 5%.
Không phải là Linux, nhưng một hãng sản xuất Load-Balancing đã quan sát sự tăng đáng kể của hiệu năng trong sản phẩm của họ bằng cách bật super huge pages (1GB pages!)
Tìm thử thấy có cả nghiên cứu ảnh hưởng tích cực của THP đến OpenMP.
Xem ra THP không hẳn đã hại người :D

Cách tắt chức năng Transparent HugePage

Dù thế nào thì trên trang chính thức của Redhat, họ cũng có viết là:
However, THP is not recommended for database workloads.
Do vậy nếu máy tính đang chạy một trong các ứng dụng bị hại thì ta nên tắt THP. Cách tắt như sau:
Trên RHEL (Redhat Linux, CentOS, Scientific Linux ...)
$ echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
$ echo 'echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag' >> /etc/rc.local
Trên Ubuntu/Debian, OEL, SLES
$ echo never > /sys/kernel/mm/transparent_hugepage/defrag
$ echo 'echo never > /sys/kernel/mm/transparent_hugepage/defrag' >> /etc/rc.local

How to verify DDOS attack with netstat command on Linux Terminal

Your server appearing pretty slow could be many things from wrong configs, scripts and dodgy hardware – but sometimes it could be because someone is flooding your server with traffic known as DoS ( Denial of Service ) or DDoS ( Distributed Denial of Service ).
Denial-of-service attack (DoS attack) or Distributed Denial-of-service attack (DDoS attack) is an attempt to make a machine or network resource unavailable to its intended users. This attack generally target sites or services hosted on high-profile web servers such as banks, credit card payment gateways, and even root nameservers. DoS attacks are implemented by either forcing the targeted computer to reset, or consuming its resources so that it can no longer provide its services or obstructs the communication media between the users and the victim so that they can no longer communicate adequately.
In this small article you’ll see how to check if your server is under attack from the Linux Terminal with the netstat command



From the man page of netstat “netstat – Print network connections, routing tables, interface statistics, masquerade connections, and multicast memberships”
Some examples with explanation
netstat -na
This display all active Internet connections to the server and only established connections are included.
netstat -an | grep :80 | sort
Show only active Internet connections to the server on port 80, this is the http port and so it’s useful if you have a web server, and sort the results. Useful in detecting a single flood by allowing you to recognize many connections coming from one IP.
netstat -n -p|grep SYN_REC | wc -l
This command is useful to find out how many active SYNC_REC are occurring on the server. The number should be pretty low, preferably less than 5. On DoS attack incidents or mail bombs, the number can jump to pretty high. However, the value always depends on system, so a high value may be average on another server.
netstat -n -p | grep SYN_REC | sort -u
List out the all IP addresses involved instead of just count.
netstat -n -p | grep SYN_REC | awk '{print $5}' | awk -F: '{print $1}'
List all the unique IP addresses of the node that are sending SYN_REC connection status.
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
Use netstat command to calculate and count the number of connections each IP address makes to the server.
netstat -anp |grep 'tcp|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
List count of number of connections the IPs are connected to the server using TCP or UDP protocol.
netstat -ntu | grep ESTAB | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr
Check on ESTABLISHED connections instead of all connections, and displays the connections count for each IP.
netstat -plan|grep :80|awk {'print $5'}|cut -d: -f 1|sort|uniq -c|sort -nk 1
Show and list IP address and its connection count that connect to port 80 on the server. Port 80 is used mainly by HTTP web page request.

How to mitigate a DOS attack

Once that you have found the IP that are attacking your server you can use the following commands to block their connection to your server:
iptables -A INPUT 1 -s $IPADRESS -j DROP/REJECT
Please note that you have to replace $IPADRESS with the IP numbers that you have found with netstat.
After firing the above command, KILL all httpd connections to clean your system and than restart httpd service by
using the following commands:
killall -KILL httpd
 
service httpd start           #For Red Hat systems 
/etc/init/d/apache2 restart   #For Debian systems