Lựa chọn an toàn cho máy chủ web có tính năng nối mạng internet bằng Java là gì?

Question

Tôi cần triển khai máy chủ có thể truy cập công khai từ internet. Các máy chủ có một nhiệm vụ rất đơn giản:

• Chấp nhận POSTS hình thức từ những người dùng qua HTTPS (dưới dạng HTML thực tế là trên một trang web khác nhau)
• Viết lại những bài dạng như JSON
• Gửi nó đến một máy chủ nội bộ qua kết nối HTTPS riêng biệt, với đa máy chủ không vượt quá
• Chờ trả lời bằng JSON, có chứa thành công hoặc lý do lỗi
• Trả lại chuyển hướng '303' từ URI thành công hoặc URI lỗi, đặt lý do lỗi làm thông số truy vấn

Các tải máy chủ này thường chịu được tối thiểu, nhưng vì không có hạn chế truy cập, máy chủ có thể rõ ràng là bị tấn công bởi hệ điều hành DOS, vv

Tuy nhiên, vấn đề thực sự ở đây là an ninh là hoàn toàn tối quan trọng cho máy chủ - máy chủ có liên quan đến các giao dịch thanh toán với khối lượng đủ lớn để làm cho nó trở thành mục tiêu mong muốn cho việc bẻ khóa. Máy chủ nằm phía sau IPS, nhưng nếu không kết nối trực tiếp với internet và sẽ chấm dứt kết nối HTTPS từ trình duyệt của người dùng cuối trực tiếp mà không cần bất kỳ proxy proxy hoặc bộ gia tốc SSL can thiệp nào.

Vì vậy, câu hỏi của tôi là, máy chủ web Java nào sẽ là lựa chọn an toàn nhất cho một mục đích như vậy? Hoặc, theo cách khác, nếu bạn thực sự nghĩ rằng các yêu cầu như vậy không nên được nhận trực tiếp bởi Java, nhưng bằng lighttpd hoặc một cái gì đó khác, bạn có thể đề xuất một cái gì đó khác. Nhưng chỉ khi nó có thể đáp ứng các yêu cầu nêu trên.

---

Một câu trả lời thật sự tốt đẹp sẽ chạm vào những vấn đề này:

• an ninh có liên quan của OpenSSL vs Java lựa chọn thay thế crypto vs (tất cả đã có lỗ hổng)
• an ninh có liên quan các tính năng Java VM (chẳng hạn như lỗ hổng phân tích cú pháp XML gần đây)
• Bảo mật liên quan đến phân tích cú pháp tiêu đề HTTP của máy chủ web (hầu như tất cả dường như đã có lỗ hổng ở đó)
• nén tùy chọn (zlib đã có lỗ hổng và mod_deflate có lỗ hổng riêng biệt trên đó)

Answer 1

Tôi muốn cho rằng mối quan tâm chính của bạn phải tuân thủ các thực tiễn bảo mật tốt nhất và giữ cho phần mềm của bạn được cập nhật hơn là phần mềm nào bạn chọn. Nó chỉ là về không thể dự đoán lỗ hổng trong tương lai. Và phần mềm với rất nhiều lỗ hổng trước đây không nhất thiết có nghĩa là nó ít an toàn hơn, có khả năng nó được nhắm mục tiêu thường xuyên hơn và do đó được cố định thường xuyên hơn. Về vấn đề đó bạn muốn phần mềm được cập nhật thường xuyên và bạn có một cách dễ dàng để thường xuyên nhận được những cập nhật đó.

Tôi muốn đề xuất Tomcat và làm theo các bước từ Improving Apache Tomcat Security. Tomcat có lợi ích là nguồn mở và phổ biến, vì vậy nó nhận được rất nhiều sự chú ý và sửa lỗi nhanh chóng.Nhiều cuộc tấn công chống lại những thứ bạn thậm chí không cần, vì vậy hãy vô hiệu hóa mọi thứ bạn có thể. Định cấu hình web.xml của bạn để chỉ chấp nhận đường dẫn URL bạn mong đợi và đưa ra lỗi cho mọi thứ khác.

Có vẻ như bạn không cần Apache HTTPD trước vùng chứa web. Đó có lẽ là tốt nhất để giảm số lượng các vectơ tấn công và yêu cầu web đi trực tiếp vào vùng chứa web. Không thể biết được HTTPD hoặc Java nào sẽ có nhiều lỗ hổng hơn được phát hiện cho SSL và gzip. Tuy nhiên, nếu bạn chỉ sử dụng Java thì ít nhất bạn cũng không mở cho phần còn lại của những gì có thể được tìm thấy cho HTTPD, so với một tập hợp giới hạn các mối quan tâm thực hiện nguyên gốc đối với Java.

Đảm bảo Java và vùng chứa web của bạn được cập nhật. Mạng và hệ điều hành cứng cũng nên được nghiên cứu, nếu chúng chưa được. Bạn cũng có thể muốn xem xét quét hàng ngày các lỗ hổng trên web để luôn cập nhật các mối đe dọa mới.

Answer 2

Hầu hết các máy chủ đều có khả năng đó. Tomcat là một lựa chọn hiển nhiên. Tomcat đằng sau Apache cũng rất phổ biến. Nếu sử dụng JavaEE - bất kỳ máy chủ ứng dụng nào cũng sẽ hoạt động.

Answer 3

Nếu bạn cần một cái gì đó đơn giản và một mục đích duy nhất, tôi sẽ thử Grizzly - ít mã hơn, ít lỗi hơn. Nó có một số lớp SSLConfig để thiết lập HTTPS, tôi đã không sử dụng nó.