Nội dung
- Lỗ hổng bảo mật SSL quan trọng - Cập nhật hệ thống của bạn - Kiểm tra số version của bạn - Thu hồi và cấp lại Chứng chỉ / Key SSL của bạn - Xem xét bổ sung từ quan điểm của khách hàng - Kết luận

Thứ ba, 08/04/2014 | 00:00 GMT+7

Cách bảo vệ server của bạn chống lại lỗ hổng bảo mật OpenSSL.

Lỗ hổng bảo mật SSL quan trọng

Vào thứ Hai, ngày 7 tháng 4 năm 2014, một lỗ hổng OpenSSL đã được tiết lộ, được gọi là một trong những lỗ hổng bảo mật tồi tệ nhất trong lịch sử internet gần đây. Lỗi, được gọi là lỗi Heartbleed, đã được giới thiệu trong version OpenSSL 1.0.1. Nó đã xuất hiện trong tự nhiên từ tháng 3 năm 2012 và được vá bằng OpenSSL version 1.0.1g phát hành vào ngày 7 tháng 4 năm 2014. Sự cố, được gắn thẻ CVE-2014-0160, được mô tả chi tiết ở đây .

Lỗi này cho phép bất kỳ kẻ tấn công nào đọc bộ nhớ của server dễ bị tấn công, nghĩa là bất kỳ khóa nào đã được sử dụng trên server có version OpenSSL dễ bị tấn công sẽ bị coi là bị xâm phạm. Các bản phân phối đã cập nhật các gói của họ và đẩy ra các bản cập nhật, nhưng user cần phải kéo các gói mới nhất xuống và thu hồi bất kỳ khóa nào trước đó dựa trên các version không an toàn.

Ta sẽ hướng dẫn bạn cách cập nhật hệ thống của bạn bằng version OpenSSL an toàn, thu hồi mọi certificate SSL không an toàn và kiểm tra xem bạn có dễ bị tấn công hay không.

Cập nhật hệ thống của bạn

Các gương DigitalOcean đang được cập nhật để bao gồm các version mới nhất của gói OpenSSL vì chúng được cung cấp bởi các nhà đóng gói phân phối. Cách dễ nhất để cập nhật các gói của bạn là cập nhật toàn bộ hệ thống của bạn.

Trên Ubuntu và Debian, bạn có thể cập nhật bằng lệnh :

sudo apt-get update
sudo apt-get dist-upgrade

Nếu bạn chỉ muốn nâng cấp các gói bị ảnh hưởng và không cập nhật toàn bộ hệ thống (chỉ được khuyến khích nếu bạn có lý do để tin rằng việc nâng cấp lên các thành phần khác sẽ phá vỡ hệ thống của bạn), bạn có thể nâng cấp có chọn lọc các gói OpenSSL bằng lệnh :

sudo apt-get install --only-upgrade openssl
sudo apt-get install --only-upgrade libssl1.0.0

Điều này sẽ nâng cấp các gói dễ bị tấn công trong khi để phần còn lại của hệ thống ở trạng thái chưa được nâng cấp.

Trên CentOS và Fedora, bạn có thể nhập mã này để cập nhật toàn bộ hệ thống:

yum update

Nếu bạn chỉ muốn nâng cấp gói bị ảnh hưởng, thay vào đó bạn có thể sử dụng lệnh này:

yum update openssl

, điều này chỉ được khuyến khích nếu bạn có lý do cụ thể cho việc không cập nhật hệ thống hoàn chỉnh.

Tại thời điểm viết bài này (04/08/14), Fedora 19 chưa có version mới nhất trong repository ổn định. Bạn có thể đợi bản cập nhật được chấp nhận, nhưng bạn cũng có thể tiếp tục và xây dựng gói theo cách thủ công. Điều này có lẽ đáng giá khi xem xét mức độ nghiêm trọng của lỗi.

Đối với hệ thống 64 bit:

yum -y install koji
koji download-build --arch=x86_64 openssl-1.0.1e-37.fc19.1
yum localinstall openssl-1.0.1e-37.fc19.1.x86_64.rpm

Bạn có thể làm tương tự đối với hệ thống 32-bit của Fedora 19 bằng lệnh :

yum -y install koji
koji download-build --arch=i686 openssl-1.0.1e-37.fc19.1
yum localinstall openssl-1.0.1e-37.fc19.1.i686.rpm

Trên Arch Linux, các gói có thể được cập nhật bằng lệnh :

sudo pacman -Syu

Hệ thống Arch Linux có thể trở nên rất không ổn định nếu bạn cập nhật các gói một cách chọn lọc, vì vậy ta khuyên bạn chỉ nên cập nhật gói OpenSSL.

Điều này sẽ kéo tất cả các bản cập nhật gần đây, bao gồm OpenSSL nếu máy nhân bản mà bạn được trỏ đến đã lấy các gói mới nhất. Bạn sẽ thấy openssl hoặc một số biến thể trong danh sách các gói nâng cấp của bạn .

Sau khi hoàn tất, bạn nên khởi động lại máy đảm bảo server của bạn không sử dụng version cũ được tải trong bộ nhớ. Bạn có thể thực hiện bằng cách phát hành:

sudo shutdown -r now

Kiểm tra số version của bạn

Bạn nên kiểm tra version OpenSSL sau khi cập nhật hệ thống của bạn .

Mặc dù version OpenSSL 1.0.1g là bản sửa lỗi chính thức của sự cố này, nhưng version khắc phục sự cố này cho các bản phân phối và bản phát hành khác nhau có thể khác nhau. Một số bản phát hành và bản phân phối đã vá các version cũ hơn của họ để khắc phục sự cố, thay vì phát hành một version hoàn toàn mới vào một hệ sinh thái ổn định, cũ hơn.

Vì lý do này, cách tốt nhất là kiểm tra trình cài đặt gói của nhà phân phối của bạn, vì lệnh openssl version có thể không phản ánh thông tin ta cần.

Phiên bản sửa chữa và phát hành Debian và Ubuntu

Đối với hệ thống Debian và Ubuntu, bạn nhận được version hiện tại của gói OpenSSL bằng lệnh :

dpkg -l | grep "openssl"

Bạn sẽ nhận được kết quả như thế này:

ii  openssl                            1.0.1e-2+deb7u6               amd64        Secure Socket Layer (SSL) binary and related cryptographic tools

Đối với user Debian, bản phát hành Debian mà bạn đang chạy sẽ xác định version chính xác cho bản sửa lỗi. Nếu version OpenSSL của bạn ít nhất là mới nhất như version được liệt kê ở đây cho bản phân phối của bạn, bạn sẽ được bảo vệ:

Debian 6 (Squeeze) : Không bị ảnh hưởng (Được vận chuyển với version cũ hơn trước lỗ hổng bảo mật)
Debian 7 (Wheezy) : 1.0.1e-2 + deb7u6
Thử nghiệm Debian (Jessie) : 1.0.1g-1
Debian không ổn định (Sid) : 1.0.1g-1

Đối với user Ubuntu, version chính xác, được vá cũng phụ thuộc vào bản phát hành. Sử dụng danh sách này để xem version an toàn tối thiểu cho bản phát hành của bạn:

Ubuntu 10.04 : Không bị ảnh hưởng (Được vận chuyển với version cũ hơn trước lỗ hổng bảo mật)
Ubuntu 12.04 : 1.0.1-4ubuntu5.12
Ubuntu 12.10 : 1.0.1c-3ubuntu2.7
Ubuntu 13.04 : ĐÃ ĐẠT ĐƯỢC HỖ TRỢ CUỐI CÙNG, NÊN NÂNG CẤP
Ubuntu 13.10 : 1.0.1e-3ubuntu1.2

Nếu bạn đang sử dụng một trong các bản phân phối được hỗ trợ, hãy đảm bảo version OpenSSL của bạn được cập nhật. Nếu bản phân phối của bạn không được hỗ trợ nữa (Ubuntu 13.04), bạn nên chuyển sang hệ điều hành được hỗ trợ do mức độ nghiêm trọng của lỗi này.

Các version sửa chữa và phát hành CentOS và Fedora

Đối với hệ thống CentOS và Fedora, bạn có thể truy vấn version của gói OpenSSL được cài đặt trên hệ thống của bạn bằng lệnh :

rpm -q -a | grep "openssl"

Bạn sẽ nhận được kết quả giống như sau:

openssl-1.0.1e-16.el6_5.7.x86_64

Đối với CentOS, đây là các bản phát hành và các version OpenSSL tối thiểu phải được áp dụng để bảo vệ các tương tác SSL trong tương lai. Ta sẽ đưa kiến trúc ra cuối trong danh sách của ta :

CentOS 5 : Không bị ảnh hưởng (Được vận chuyển với version cũ hơn trước lỗ hổng bảo mật)
CentOS 6 : openssl-1.0.1e-16.el6.5.7

Đối với user Fedora, bạn có thể kiểm tra xem version gói của bạn ít nhất là mới nhất như version được liệt kê bên dưới. , tôi đã xóa kiến trúc bên dưới vì điều này áp dụng cho cả bản phát hành 32 bit và 64 bit:

Fedora 17 : Không bị ảnh hưởng (Được vận chuyển với version cũ hơn trước lỗ hổng bảo mật)
Fedora 19 : openssl-1.0.1e-37.fc19.1

Lưu ý : Hãy chú ý đến số version Fedora. Dấu “.1” cho bạn biết liệu nó có được vá hay không. Nếu gói của bạn không có “.1” ở cuối, bạn vẫn dễ bị tấn công!

Phiên bản sửa lỗi Arch Linux

Nếu bạn đang chạy Arch Linux, việc xác nhận dễ dàng hơn nhiều vì không có nhiều bản phát hành.

Bạn có thể kiểm tra version OpenSSL mà bạn đã cài đặt:

pacman -Q | grep "openssl"

Bạn sẽ nhận được kết quả giống như sau:

openssl 1.0.1.g-1

Nếu version đã cài đặt của bạn là version này hoặc cao hơn, bạn không sao.

Thu hồi và cấp lại Chứng chỉ / Key SSL của bạn

Nếu bạn đã mua certificate SSL từ một nhà cung cấp và bạn đã cập nhật các gói OpenSSL trên server của bạn , bạn cần thu hồi các khóa cũ của bạn và bạn sẽ phải phát hành lại các khóa mới. Đây là một quá trình được gọi là "rekeying".

Quá trình này phụ thuộc rất nhiều vào dịch vụ SSL đã cấp certificate ban đầu của bạn, nhưng bạn nên tìm kiếm trên giao diện quản trị của họ để tìm tùy chọn tương tự như “rekey” hoặc “reissue key”. Hầu hết các tổ chức phát hành SSL sẽ thu hồi khóa cũ của bạn khi bạn khóa lại, nhưng bạn thường cũng có thể thực hiện việc này một cách rõ ràng bằng giao diện quản trị của họ.

Thực hiện theo các hướng dẫn mà nhà cung cấp SSL cung cấp cho bạn. Họ có thể cung cấp cho bạn những hướng dẫn rất cụ thể về cách tạo lại CSR hoặc có thể không.

Nếu họ không cung cấp cho bạn các lệnh openssl cụ thể mà họ muốn bạn sử dụng, bạn có thể tạo SSL CSR mới của bạn bằng lệnh nội dung như thế này. , hãy thêm sudo nếu bạn chưa root:

<pre>
openssl req -new -newkey rsa: 2048 -nodes -keyout <span class = “highlight”> hostname </span> .key -out <span class = “highlight”> hostname </span> .csr
</pre>

Bạn cần sao chép CSR đã tạo của bạn vào giao diện web của nhà cung cấp sau khi tạo để khóa lại server của bạn. Sau đó, bạn cần download certificate mới từ giao diện web.

Bạn sẽ phải cài đặt các khóa mới vào cùng vị trí mà các khóa và certificate cũ của bạn đã được lưu giữ. Đường dẫn bạn cần sử dụng cho certificate và khóa của bạn sẽ khác nhau tùy theo phân phối và cách bạn cấu hình web server của bạn . Ví dụ: một số được lưu trong /etc/ssl/certs trong khi những cái khác có thể được giữ ở các vị trí do web server của bạn cung cấp.

Ví dụ: nếu bạn đang sử dụng web server Apache, bạn sẽ thấy một dòng trong file cấu hình Apache chính, file server ảo hoặc file cấu hình có nguồn root riêng trỏ đến vị trí nơi nó tìm kiếm thông tin SSL của bạn:

SSLEngine on
SSLCertificateFile /path/to/your_domain.crt
SSLCertificateKeyFile /path/to/your_key.key
SSLCertificateChainFile /path/to/CA.crt

Chúng có thể trông khác nhau, nhưng chúng sẽ chỉ cho bạn đúng hướng để tìm vị trí certificate SSL của bạn.

Nếu bạn đang sử dụng Nginx, bạn sẽ tìm thấy các lệnh tương tự trỏ đến khóa và certificate SSL của server của bạn. Họ có thể trông giống như sau:

server {
    . . .
    ssl_certificate /path/to/your_domain.crt;
    ssl_certificate_key /path/to/your_key.key;
    . . .
}

Một tùy chọn khác là kiểm tra tài liệu của bản phân phối hoặc kiểm tra hệ thống file của server để tìm nơi lưu trữ các certificate của bạn.

Khi hoàn tất, bạn nên khởi động lại web server của bạn để sử dụng các khóa mới. Phương pháp thực hiện điều này sẽ khác nhau tùy theo phân phối và server .

Trên Debian hoặc Ubuntu, bạn có thể khởi động lại web server của bạn bằng lệnh :

sudo service apache2 restart    # For Apache web server
sudo service nginx restart      # For Nginx web server

Trên CentOS hoặc Fedora, bạn có thể khởi động lại bằng lệnh :

sudo service httpd restart      # For Apache web server
sudo service nginx restart      # For Nginx web server

Đối với Arch Linux, bạn nên sử dụng một số thứ như:

sudo systemctl restart httpd.service
sudo systemctl restart nginx.service

Điều này sẽ cho phép web server của bạn nhận các thay đổi certificate mới của bạn.

Xem xét bổ sung từ quan điểm của khách hàng

Do tính chất phổ biến của lỗi này, bạn cũng nên xem xét các vấn đề khác. Là người tiêu dùng các dịch vụ web và trang web, bạn cũng nên phản ứng nhanh chóng để cố gắng giảm thiểu thiệt hại có thể xảy ra đối với account và thông tin của bạn.

Bạn nên xem xét mọi thông tin liên lạc mà bạn đã bảo mật bằng SSL trước đó đã bị xâm phạm bởi lỗi này. Điều này nghĩa là bất kỳ loại tương tác nào với các trang web an toàn đều có thể bị rình mò.

Bước đầu tiên tốt là thay đổi password của bạn trên mọi trang web mà bạn sử dụng, sau khi bạn xác minh họ đã cập nhật version OpenSSL để vá lỗ hổng này. Nếu bạn thay đổi password trước khi trang web từ xa vá version SSL của họ, password mới của bạn cũng dễ bị tấn công như password cũ của bạn.

Một cân nhắc có tầm quan trọng cao là bảo mật bất kỳ version VPN nào mà bạn đã cài đặt . Có một số cách khác nhau mà kết nối VPN được thực hiện, nhưng SSL là một trong những cách phổ biến nhất. Ví dụ: OpenVPN sử dụng SSL. Mọi certificate cần thiết để kết nối với server của bạn nên được tạo lại đảm bảo rằng chúng được bảo mật.

Một biện pháp tốt khác là xóa tất cả các khóa phiên và cookie. Điều này nghĩa là tạo lại khóa API, xóa cookie được lưu trữ trong trình duyệt của bạn, v.v. Đây có thể là một sự bất tiện lớn, nhưng chi phí để không vượt qua những khó khăn này bây giờ là account của bạn về cơ bản rộng mở và giao tiếp với các server từ xa không đã cập nhật OpenSSL của họ nên được coi là không an toàn hơn văn bản thuần túy.

Kết luận

Đây là một lỗi cực kỳ lớn mà user và administrator không thể bỏ qua hoặc loại bỏ. Bạn nên cập nhật bất kỳ server nào mà bạn có quyền kiểm soát ngay lập tức và thông báo cho user của bạn về các lỗ hổng để họ có thể kiểm soát thiệt hại từ đầu của họ.

Bằng cách vá hệ thống của bạn và cập nhật certificate SSL, bạn sẽ được bảo vệ khỏi lỗ hổng bảo mật này, với quyền là server lưu trữ, cho các giao tiếp trong tương lai.

<div class = “author”> Bởi Justin Ellingwood </div>

Tags:

Các tin liên quan

Cách cấu hình mail server bằng Postfix, Dovecot, MySQL và SpamAssassin
2014-04-01
Cách cấu hình mail server bằng Postfix, Dovecot, MySQL và SpamAssassin
2014-04-01
Cách cấu hình công cụ để sử dụng IPv6 trên VPS Linux
2014-04-01
Cách điều chỉnh cấu hình SSH Daemon của bạn trên VPS Linux
2014-03-26
Cách xác thực người dùng với server SSH bằng Monkeysphere trên VPS Ubuntu
2014-03-24
Cách xác thực danh tính server SSH với Monkeysphere trên VPS Ubuntu
2014-03-24
Cách thiết lập DNSSEC trên server DNS BIND ủy quyền
2014-03-19
Cách thiết lập DNSSEC trên server DNS BIND ủy quyền
2014-03-19
Cách cài đặt TrueCrypt (CLI) trên Linux
2014-03-17
Cách sử dụng Công cụ IPRoute2 để quản lý cấu hình mạng trên VPS Linux
2014-03-11