Sự phức tạp nội tại của cơ sở hạ tầng máy chủ web được kết nối với nhau và không đồng nhất, có thể bao gồm hàng trăm ứng dụng web, làm cho việc quản lý và xem xét cấu hình trở thành một bước cơ bản trong thử nghiệm và triển khai mọi ứng dụng. Chỉ cần một lỗ hổng duy nhất có thể làm suy yếu tính bảo mật của toàn bộ cơ sở hạ tầng và ngay cả những vấn đề nhỏ và dường như không quan trọng cũng có thể phát triển thành rủi ro nghiêm trọng đối với một ứng dụng khác trên cùng một máy chủ. Để giải quyết những vấn đề này, điều quan trọng nhất là thực hiện đánh giá sâu về cấu hình và các vấn đề bảo mật đã biết, sau khi đã lập bản đồ toàn bộ kiến trúc.
Các bài viết liên quan:
Quản lý cấu hình thích hợp của cơ sở hạ tầng máy chủ web là rất quan trọng để bảo vệ tính bảo mật của chính ứng dụng. Nếu các phần tử như phần mềm máy chủ web, máy chủ cơ sở dữ liệu phía sau hoặc máy chủ xác thực không được xem xét và bảo mật đúng cách, chúng có thể gây ra các rủi ro không mong muốn hoặc tạo ra các lỗ hổng mới có thể xâm phạm chính ứng dụng.
Ví dụ: lỗ hổng máy chủ web cho phép kẻ tấn công từ xa tiết lộ mã nguồn của chính ứng dụng (lỗ hổng đã phát sinh một số lần trong cả máy chủ web hoặc máy chủ ứng dụng) có thể xâm phạm ứng dụng, vì người dùng ẩn danh có thể sử dụng thông tin được tiết lộ trong mã nguồn để tận dụng các cuộc tấn công chống lại ứng dụng hoặc người dùng của nó.
Các bước sau cần được thực hiện để kiểm tra cơ sở hạ tầng quản lý cấu hình:
- Các yếu tố khác nhau tạo nên cơ sở hạ tầng cần được xác định để hiểu cách chúng tương tác với ứng dụng web và cách chúng ảnh hưởng đến bảo mật của ứng dụng đó.
- Tất cả các yếu tố của cơ sở hạ tầng cần được xem xét để đảm bảo rằng chúng không chứa bất kỳ lỗ hổng bảo mật nào đã biết.
- Cần phải xem xét lại các công cụ quản trị được sử dụng để duy trì tất cả các yếu tố khác nhau.
- Các hệ thống xác thực, cần được xem xét để đảm bảo rằng chúng phục vụ các nhu cầu của ứng dụng và chúng không thể bị người dùng bên ngoài thao túng để tận dụng quyền truy cập.
- Danh sách các cổng đã xác định được yêu cầu cho ứng dụng nên được duy trì và giữ dưới sự kiểm soát thay đổi.
Sau khi đã lập bản đồ các phần tử khác nhau tạo nên cơ sở hạ tầng (xem Mạng bản đồ và Kiến trúc ứng dụng), có thể xem lại cấu hình của từng phần tử được thành lập và kiểm tra mọi lỗ hổng đã biết.
Mục tiêu kiểm tra Network Infrastructure Configuration
Xem lại cấu hình của các ứng dụng được đặt trên mạng và xác nhận rằng chúng không dễ bị tấn công.
Xác thực rằng các khung và hệ thống đã sử dụng là an toàn và không dễ bị tấn công bởi các lỗ hổng đã biết do phần mềm không bị lỗi hoặc cài đặt và thông tin xác thực mặc định.
Làm thế nào để kiểm tra Network Infrastructure Configuration
Các lỗ hổng máy chủ đã biết
Các lỗ hổng được tìm thấy trong các khu vực khác nhau của kiến trúc ứng dụng, có thể là trong máy chủ web hoặc trong cơ sở dữ liệu phía sau, có thể làm tổn hại nghiêm trọng đến bản thân ứng dụng. Ví dụ: hãy xem xét lỗ hổng máy chủ cho phép người dùng từ xa, chưa được xác thực tải tệp lên máy chủ web hoặc thậm chí để thay thế tệp. Lỗ hổng này có thể làm tổn hại đến ứng dụng, vì người dùng giả mạo có thể thay thế chính ứng dụng đó hoặc giới thiệu mã có thể ảnh hưởng đến các máy chủ phía sau, vì mã ứng dụng của nó sẽ được chạy giống như bất kỳ ứng dụng nào khác.
Việc xem xét các lỗ hổng của máy chủ có thể khó thực hiện nếu việc kiểm tra cần được thực hiện thông qua kiểm tra thâm nhập mù. Trong những trường hợp này, các lỗ hổng cần được kiểm tra từ một trang web từ xa, thường là sử dụng một công cụ tự động. Tuy nhiên, việc kiểm tra một số lỗ hổng có thể có kết quả không thể đoán trước được trên máy chủ web và việc kiểm tra những người khác (như những người trực tiếp tham gia vào các cuộc tấn công từ chối dịch vụ) có thể không thực hiện được do dịch vụ ngừng hoạt động nếu quá trình kiểm tra thành công.
Một số công cụ tự động sẽ gắn cờ các lỗ hổng dựa trên phiên bản máy chủ web được truy xuất. Điều này dẫn đến cả dương tính giả và âm tính giả. Mặt khác, nếu phiên bản máy chủ web đã bị xóa hoặc bị che bởi quản trị viên địa phương, công cụ quét sẽ không gắn cờ máy chủ là dễ bị tấn công ngay cả khi nó có. Mặt khác, nếu nhà cung cấp cung cấp phần mềm không cập nhật phiên bản máy chủ web khi các lỗ hổng được khắc phục, công cụ quét sẽ gắn cờ các lỗ hổng không tồn tại. Trường hợp thứ hai thực sự rất phổ biến khi một số nhà cung cấp hệ điều hành hỗ trợ các bản vá lỗ hổng bảo mật cho phần mềm mà họ cung cấp trong hệ điều hành, nhưng không tải lên đầy đủ phiên bản phần mềm mới nhất. Điều này xảy ra trong hầu hết các bản phân phối GNU / Linux như Debian, Red Hat hoặc SuSE. Trong hầu hết các trường hợp, việc quét lỗ hổng bảo mật của một kiến trúc ứng dụng sẽ chỉ tìm thấy các lỗ hổng liên quan đến các phần tử “bị lộ” của kiến trúc (chẳng hạn như máy chủ web) và thường sẽ không thể tìm thấy các lỗ hổng liên quan đến các phần tử không được tiếp xúc trực tiếp, chẳng hạn như xác thực trở lại kết thúc, mặt sau
cơ sở dữ liệu kết thúc hoặc đảo ngược proxy đang được sử dụng.
Cuối cùng, không phải tất cả các nhà cung cấp phần mềm đều tiết lộ các lỗ hổng một cách công khai, và do đó những điểm yếu này không được đăng ký trong các cơ sở dữ liệu về lỗ hổng được biết đến công khai [2]. Thông tin này chỉ được tiết lộ cho khách hàng hoặc được công bố thông qua các bản sửa lỗi không có tư vấn đi kèm. Điều này làm giảm tính hữu ích của các công cụ quét lỗ hổng bảo mật. Thông thường, khả năng bao phủ lỗ hổng bảo mật của các công cụ này sẽ rất tốt đối với các sản phẩm thông thường (chẳng hạn như máy chủ web Apache, Máy chủ thông tin Internet của Microsoft hoặc IBM’s Lotus Domino) nhưng sẽ thiếu đối với các sản phẩm ít được biết đến hơn.
Đây là lý do tại sao việc xem xét các lỗ hổng được thực hiện tốt nhất khi người kiểm tra được cung cấp thông tin nội bộ của phần mềm được sử dụng, bao gồm các phiên bản và bản phát hành được sử dụng và các bản vá được áp dụng cho phần mềm. Với thông tin này, người kiểm tra có thể lấy thông tin từ chính nhà cung cấp và phân tích những lỗ hổng nào có thể có trong kiến trúc và cách chúng có thể ảnh hưởng đến chính ứng dụng. Khi có thể, các lỗ hổng này có thể được kiểm tra để xác định ảnh hưởng thực sự của chúng và để phát hiện xem có thể có bất kỳ yếu tố bên ngoài nào (chẳng hạn như hệ thống phát hiện hoặc ngăn chặn xâm nhập) có thể làm giảm hoặc phủ nhận khả năng khai thác thành công hay không. Người kiểm tra thậm chí có thể xác định, thông qua việc xem xét cấu hình, lỗ hổng bảo mật thậm chí không xuất hiện, vì nó ảnh hưởng đến một thành phần phần mềm không được sử dụng.
Cũng cần lưu ý rằng các nhà cung cấp đôi khi sẽ âm thầm sửa chữa các lỗ hổng và cung cấp các bản sửa lỗi với các bản phát hành phần mềm mới. Các nhà cung cấp khác nhau sẽ có các chu kỳ phát hành khác nhau để xác định hỗ trợ mà họ có thể cung cấp cho các bản phát hành cũ hơn. Người thử nghiệm có thông tin chi tiết về các phiên bản phần mềm được kiến trúc sử dụng có thể phân tích rủi ro liên quan đến việc sử dụng các bản phát hành phần mềm cũ có thể không được hỗ trợ trong thời gian ngắn hoặc đã không được hỗ trợ. Điều này rất quan trọng, vì nếu một lỗ hổng bảo mật xuất hiện trong một phiên bản phần mềm cũ không còn được hỗ trợ, thì nhân viên hệ thống có thể không trực tiếp nhận biết được. Sẽ không có bản vá nào được cung cấp cho nó và các cố vấn có thể không liệt kê phiên bản đó là dễ bị tấn công vì nó không còn được hỗ trợ. Ngay cả trong trường hợp họ biết rằng lỗ hổng bảo mật đang tồn tại và hệ thống dễ bị tấn công, họ sẽ cần phải nâng cấp toàn bộ lên bản phát hành phần mềm mới, điều này có thể gây ra thời gian chết đáng kể trong kiến trúc ứng dụng hoặc có thể buộc ứng dụng phải được khôi phục lại. -có mã do không tương thích với phiên bản phần mềm mới nhất.
Công cụ quản trị
Bất kỳ cơ sở hạ tầng máy chủ web nào cũng yêu cầu sự tồn tại của các công cụ quản trị để duy trì và cập nhật thông tin được ứng dụng sử dụng. Thông tin này bao gồm nội dung tĩnh (trang web, tệp đồ họa), mã nguồn ứng dụng, cơ sở dữ liệu xác thực người dùng, v.v. Các công cụ quản trị sẽ khác nhau tùy thuộc vào trang web, công nghệ hoặc phần mềm được sử dụng. Ví dụ: một số máy chủ web sẽ được quản lý bằng giao diện quản trị, bản thân nó là máy chủ web (chẳng hạn như máy chủ web iPlanet) hoặc sẽ được quản lý bằng tệp cấu hình văn bản thuần túy (trong trường hợp Apache [3]) hoặc sử dụng hệ điều hành Các công cụ GUI (khi sử dụng máy chủ IIS của Microsoft hoặc ASP.Net).
Trong hầu hết các trường hợp, cấu hình máy chủ sẽ được xử lý bằng các công cụ bảo trì tệp khác nhau được máy chủ web sử dụng, được quản lý thông qua máy chủ FTP, WebDAV, hệ thống tệp mạng (NFS, CIFS) hoặc các cơ chế khác. Rõ ràng, hệ điều hành của các phần tử tạo nên kiến trúc ứng dụng cũng sẽ được quản lý bằng các công cụ khác. Các ứng dụng cũng có thể có các giao diện quản trị được nhúng trong đó được sử dụng để quản lý dữ liệu ứng dụng (người dùng, nội dung, v.v.).
Sau khi đã ánh xạ các giao diện quản trị được sử dụng để quản lý các phần khác nhau của kiến trúc, điều quan trọng là phải xem lại chúng vì nếu kẻ tấn công giành được quyền truy cập vào bất kỳ giao diện nào trong số chúng thì chúng có thể xâm phạm hoặc làm hỏng kiến trúc ứng dụng. Để làm được điều này, điều quan trọng là:
- Xác định các cơ chế kiểm soát quyền truy cập vào các giao diện này và tính nhạy cảm liên quan của chúng. Thông tin này có thể có sẵn trực tuyến.
- Thay đổi tên người dùng và mật khẩu mặc định.
Một số công ty chọn không quản lý tất cả các khía cạnh của ứng dụng máy chủ web của họ, nhưng có thể yêu cầu các bên khác quản lý nội dung do ứng dụng web cung cấp. Công ty bên ngoài này có thể chỉ cung cấp các phần nội dung (cập nhật tin tức hoặc quảng cáo) hoặc có thể quản lý hoàn toàn máy chủ web (bao gồm nội dung và mã). Thông thường người ta thường tìm thấy các giao diện quản trị có sẵn từ Internet trong những trường hợp này, vì sử dụng Internet rẻ hơn so với việc cung cấp một đường truyền chuyên dụng sẽ kết nối công ty bên ngoài với cơ sở hạ tầng ứng dụng thông qua giao diện chỉ dành cho quản lý. Trong tình huống này, điều rất quan trọng là phải kiểm tra xem các giao diện quản trị có thể dễ bị tấn công hay không.
