FreeBSD: Bài học về những cấu hình mặc định kém cỏi

Bài viết dưới đây chia sẻ một số thay đổi mà tôi thường áp dụng cho một cài đặt FreeBSD thuần túy (vanilla install) nhằm mục đích gia cố bảo mật (security hardening). Ngoài ra, một số thay đổi để tăng hiệu suất mạng hoặc khiến hệ thống hoạt động hợp lý hơn cũng được đưa vào. Bài viết chỉ bao gồm những thay đổi cơ bản mà một quản trị viên hệ thống (sysadmin) có thể thực hiện trên hệ thống đang chạy.

Tuy nhiên, đây cũng có thể coi là một bài bình luận về tình trạng bảo mật trong hệ sinh thái phát triển của FreeBSD, làm nổi bật sự kháng cự mạnh mẽ của他们对 sự thay đổi và sự không sẵn lòng thay thế những mã nguồn cũ kỹ (cruft) bằng các giải pháp hiện đại.

Vấn đề với OpenSSH và các bản vá lỗi

Có khá nhiều quyết định sai lầm đã được đưa ra trong lĩnh vực bảo mật. Một ví dụ điển hình là việc họ kiên quyết duy trì bộ bản vá HPN-SSH và bật nó theo mặc định trong một thời gian dài.

Bạn có thể hỏi: "Vậy được thôi, nhưng bản vá đó có vấn đề gì?"

OpenSSH đã tăng giới hạn kênh đủ để hỗ trợ kết nối gigabit xuyên quốc gia mà không làm chậm hệ thống từ nhiều năm trước. Đối với đa số người dùng, điều này có nghĩa là các bản vá HPN là sự phức tạp không cần thiết với lợi ích rất ít hoặc không có. Hơn nữa, chúng thường khiến FreeBSD bị chậm trễ trong việc cập nhật phiên bản OpenSSH mới vì phải backport và tái cấu hình thủ công bộ bản vá này.

Khi cuối cùng FreeBSD vô hiệu hóa HPN trong các bản build OpenSSH, lý do dường như là do lỗi biên dịch chứ không phải vì lý do bảo mật.

Hỗ trợ cho tcp_wrappers đã bị từ chối từ lâu trong OpenSSH chính thức (upstream), nhưng FreeBSD vẫn vá nó vào và bật mặc định cho tất cả mọi người. Điều tương tự cũng xảy ra với các khóa máy chủ DSA yếu, họ bật lại để tương thích với các máy khách cũ. FreeBSD thậm chí còn kích hoạt lại các thuật toán mã hóa (cipher) không an toàn trong bản build của họ sau khi bị upstream vô hiệu hóa, dường như tính tương thích ngược quan trọng hơn sự an toàn của người dùng.

Nếu chúng ta không loại bỏ dần các tùy chọn không an toàn ở đâu đó trong hệ sinh thái, chúng ta sẽ rơi vào tình huống giống như OpenSSL. Áp lực phải được đặt ra ở đâu đó. Một người có thể là thành viên của đội ngũ đó, hoặc chống lại họ. Trong trường hợp này, FreeBSD là đội ngũ đang cố gắng gia tăng rủi ro.

Họ đã thực hiện các thay đổi cục bộ đối với bản build OpenSSH và các tệp cấu hình mặc định của nó, khiến người dùng của họ bị lộ lọt khi các nền tảng khác không bị ảnh hưởng.

May mắn thay, khá dễ dàng để cài đặt OpenSSH từ ports với tất cả các "tính chất FreeBSD" được gỡ bỏ. Port openssh-portable của họ có một bộ tùy chọn lớn mà bạn có thể bật/tắt.

Ngoài các sửa đổi được đề cập ở trên, hai bản vá khác phổ biến với người dùng FreeBSD là AES-CTR đa luồng (threaded) và cipher "NONE".

• Threaded AES-CTR: Như tên gọi, nó đưa luồng (threads) vào mã. Các nhà phát triển OpenSSH đã công khai nói rằng luồng quá rủi ro và sẽ không được thêm vào. Hơn nữa, nó phần nào lỗi thời do AES-NI trong các CPU hiện đại và việc ChaCha20-Poly1305 (cipher mặc định hiện tại) còn nhanh hơn khi tính đến mã xác thực tin nhắn (MAC).
• NONE cipher: Về cơ bản là một tính năng sai (misfeature), loại bỏ các bit mã hóa và chỉ giữ tính toàn vẹn dữ liệu. Nó cho phép người dùng dễ dàng "tự bắn vào chân mình". Sự đánh đổi về hiệu suất không thực sự xứng đáng, vì các nút thắt cổ chai bạn có thể gặp phải liên quan nhiều hơn đến MAC rather than chi phí mã hóa thực tế.

Tôi khuyên bạn nên vô hiệu hóa tất cả các tùy chọn port. Đa số người dùng không cần rủi ro thêm từ bất kỳ bản vá không chuẩn nào.

Sendmail và các tệp tin hệ thống cũ kỹ

Để làm mọi việc tồi tệ hơn, FreeBSD đôi khi nhập các bản cập nhật Sendmail mà không hề đề cập đến các bản sửa lỗi bảo mật đi kèm. Như bạn có thể đoán, điều này có nghĩa là không có bản tư vấn nào được công bố, và hầu hết người dùng không nhận được các bản sửa lỗi đó trong một thời gian dài.

Tôi nghĩ hầu hết người dùng sẽ đồng ý rằng chương trình cũ này chủ yếu chỉ là phiền phức. Một máy chủ thư hoàn chỉnh, đặc biệt là một cái đã đầy lỗ hổng từ những năm 90, không nên nằm trong hệ thống cơ sở (base system) theo ý kiến của tôi. Một cái gì đó đơn giản để giao thư cục bộ là đủ.

Nếu bạn thực sự chạy máy chủ thư, có những lựa chọn tốt hơn như Postfix hoặc OpenSMTPD. Nếu bạn chỉ cần gửi thư qua bên thứ ba như gmail, msmtp là một lựa chọn thay thế nhẹ nhàng khác. Cả ba đều có trong ports.

Dù có danh tiếng tồi tệ của Sendmail, FreeBSD vẫn giữ nó xung quanh và bật theo mặc định hơn 27 năm cho đến khi bản phát hành 14.0 của họ ra mắt.

Bảo mật trong Quản lý Gói (Ports và Pkg)

Một vấn đề lớn khác là việc cả hệ thống ports và pkg đều thực hiện rất nhiều việc với quyền root khi hoàn toàn không cần thiết. Tôi đã đưa vấn đề này lên với một thành viên của nhóm bảo mật ports và ông ta chỉ lờ đi. Chỉ vì portsnap (công cụ lựa chọn của họ lúc bấy giờ) kiểm tra các snapshot nó lấy về bằng khóa công khai, ông ta cho rằng không có gì đáng lo ngại. Việc tải về diễn ra qua văn bản thuần túy (plaintext) dưới quyền root hoàn toàn bị bỏ qua.

Việc xác minh các tệp nó lấy về thực sự là một điều tốt... nếu điều đó được thực hiện trước các hoạt động nguy hiểm hơn... nhưng nó không phải vậy. Kiểm tra tính toàn vẹn dữ liệu được thực hiện rất muộn trong quá trình, tạo ra nhiều cơ hội cho việc khai thác các công cụ khác được gọi bởi script shell, tất cả đều chạy dưới quyền root và lấy dữ liệu không đáng tin cậy từ internet.

Cả portsnap (may mắn đã bị gỡ bỏ) và freebsd-update đều có một lỗi thiết kế nghiêm trọng ở đây có thể dễ dàng sửa chữa. Có lẽ họ có sự tự tin tuyệt đối vào việc các công cụ này không có lỗi (bug-free), nhưng tôi cố gắng thực tế hơn một chút.

Và hóa ra tôi đã đúng. Phiên bản ngắn gọn cơ bản là "bất kỳ ai sử dụng các công cụ này đều có thể bị xâm nhập từ xa ở cấp độ root."

Hãy xem tóm tắt những gì diễn ra trong quá trình xây dựng ports:

1. Lấy và cập nhật cây ports.
2. Lấy mã nguồn của phần mềm.
3. Xác minh checksum của tệp(tin).
4. Giải nén nguồn tarball.
5. Chạy script cấu hình, áp dụng bản vá cục bộ, và xây dựng ứng dụng.
6. Tạo gói từ các tệp đã xây dựng.
7. Cài đặt gói vào hệ thống của bạn (nếu muốn).

Vậy bao nhiêu trong số này thực sự cần phải làm dưới quyền root? Chỉ cái cuối cùng. Và bao nhiêu cái trong số này được thực hiện dưới quyền root theo mặc định trong FreeBSD? Tất cả.

Có thể mọi người không nhận thức được rủi ro khi thực sự xây dựng tất cả các công cụ của bên thứ ba với đặc quyền root. Bạn đã đọc từng dòng của hơn 25.000 script cấu hình đó chưa? Tôi đã thấy một số script cấu hình chạy ping để "gọi về nhà" và mọi loại việc lạ lùng khác. Vì mọi thứ đều chạy dưới quyền root, chỉ cần một lệnh độc hại được giấu trong script xây dựng ở đâu đó là có thể xâm phạm hoàn toàn máy chủ nếu bạn sử dụng ports trong cấu hình mặc định của nó.

Thay thế các dịch vụ mặc định

NTPd: Tại sao phiên bản ntpd đó lại tệ đến thế? Nói một cách đơn giản, mã ntpd được viết chủ yếu bởi những người mê thời gian và các nhà khoa học thay vì những người thực sự chạy các dịch vụ hướng mạng. Điều đó có nghĩa là nó rất chính xác, nhưng rất dễ mắc các lỗi không liên quan đến việc giữ giờ.

May mắn thay, câu trả lời là có: Có một số daemon NTP thay thế để lựa chọn. Một lựa chọn khác, cái tôi sử dụng, là OpenNTPD. OpenNTPD có lịch sử bảo mật xuất sắc và cú pháp cấu hình đơn giản.

Tường lửa (Firewall):

• IPFW: Tường lửa gốc. Kết quả là những gì bạn có thể mong đợi từ các tiêu chuẩn mã hóa thông thường của họ. Một trong các quản trị viên máy chủ của dự án FreeBSD thậm chí đã nói rằng ông thà đưa các hộp OpenBSD vào cụm của họ còn hơn là sử dụng IPFW.
• PF: Tường lửa OpenBSD được port sang FreeBSD. Thật không may, phiên bản PF họ sử dụng chưa được đồng bộ hóa với upstream kể từ năm 2009. Sau vài năm để cho mã PF cũ mục nát trong cây của họ, FreeBSD đã quyết định đi ngược lại mong muốn của người dùng về một bản cập nhật và thay vào đó cam kết một bản vá xâm lấn cao về cơ bản khóa họ ra khỏi việc đồng bộ hóa với mã của OpenBSD mãi mãi. Do đó, PF của FreeBSD bị thiếu một lượng lớn các bản sửa lỗi và cải tiến (bao gồm cả các bản sửa lỗi bảo mật từ hơn một thập kỷ trước).

Cấu hình hạt nhân (sysctl) và gia cố

Dưới đây là một số cài đặt sysctl quan trọng cần xem xét để cải thiện bảo mật:

• kern.elf32.aslr.enable và kern.elf64.aslr.enable: Bật ngẫu nhiên hóa không gian địa chỉ (ASLR). FreeBSD không bật ASLR theo mặc định.
• kern.elf32.allow_wx và kern.elf64.allow_wx: Cho phép các trang được ánh xạ đồng thời có khả năng ghi và thực thi. Bạn nên tắt cái này.
• security.bsd.see_other_uids và security.bsd.see_other_gids: Kiểm soát xem các quá trình không có đặc quyền có thể xem các quá trình/khách thể của người dùng khác hay không.
• net.inet.tcp.blackhole và net.inet.udp.blackhole: Không gửi phản hồi RST hoặc các thông báo port không thể tiếp cận, giúp ẩn dấu vết của hệ thống.

Việc yêu cầu mọi người dùng phải thực hiện nhiều nghiên cứu và cấu hình chỉ để hệ thống an toàn hơn một chút thực sự là một sự bất cập.

Văn hóa phát triển và minh bạch

FreeBSD đang thiếu nghiêm trọng các kỹ thuật giảm thiểu khai thác hiện đại, chỉ có ASLR cơ bản (trong nhánh phát triển) vào năm 2019. Nó bị tắt theo mặc định, tất nhiên, cho đến cuối năm 2021. Để so sánh, Windows giới thiệu ASLR vào năm 2007. Linux vào năm 2005 và OpenBSD vào năm 2003.

Nhưng câu chuyện ASLR không chỉ có vậy. Các vấn đề thực hiện trong mã của FreeBSD đã khiến kỹ thuật giảm thiểu muộn màng hai thập kỷ này trở nên vô hiệu về mặt hiệu quả. Một nhà nghiên cứu bảo mật đã viết: "Việc khai thác các hệ thống FreeBSD ngày nay thực sự trông không khác biệt nhiều so với năm 1998."

Có một sự thiếu hụt nghiêm trọng về minh bạch trong chính sách công bố của nhóm bảo mật, để lại người dùng của họ dễ bị tấn công trong thời gian dài. Nhiều lỗ hổng đã biết vẫn chưa được vá trong FreeBSD trong nhiều tháng.

Thậm chí còn tồn tại một văn hóa "commit trước - thảo luận sau" thường dẫn đến nhiều kịch tính, tranh cãi dài trên danh sách thư, các vấn đề bảo mật và các nhà phát triển rời bỏ dự án vì các cam kết mang tính chính trị.

Kết luận

Việc kháng cự từ nhóm bảo mật để loại bỏ các tùy chọn cũ kỹ khiến tôi tự hỏi liệu họ có nên được gọi là Nhóm Tương thích Ngược (The Backwards Compatibility Team) thay thế không. Theo quan điểm của tôi, nhóm bảo mật ngày nay dường như đang làm điều hoàn toàn ngược lại với một số nhiệm vụ đó.

Tôi thực sự muốn thấy một số điều được đánh giá lại vì sự an toàn của người dùng. Hãy khắc phục các vấn đề thay vì giao những thiết lập mặc định kém cỏi mà người dùng phải tự dọn dẹp. Nếu bạn quan tâm đến bảo mật khi sử dụng FreeBSD, hãy chuẩn bị để dành nhiều thời gian để cấu hình và "làm sạch" hệ thống của mình.