Hổ phù của thời đại số

Thời phong kiến, để điều động binh mã, người xưa không dùng lời nói hay mật khẩu miệng. Họ đã sáng tạo ra Hổ Phù, một cơ chế xác thực dựa trên vật sở hữu (Possession-based Authentication) đi trước thời đại cả ngàn năm.

Hổ Phù – Hufu – Tiger Tally

Hổ Phù là một miếng đồng hình con hổ được xẻ làm đôi, lệnh điều binh chỉ có hiệu lực khi hai nửa này được ghép lại và khớp nhau hoàn toàn.

Cơ chế này giải quyết triệt để điểm yếu của con người: Trí nhớ và Lòng tin. Lời nói có thể bị nghe lén, mật khẩu có thể bị ép cung mà khai ra, nhưng Hổ Phù thì không thể làm giả nếu không có mảnh gốc.

Ngày nay, SSH Key chính là chiếc Hổ Phù đó. Nó chuyển giao niềm tin từ những chuỗi ký tự vô hình (Password) sang một vật chứng hữu hình (Key file).

1. Điểm yếu của Password

Vấn đề lớn nhất của Password không nằm ở việc người dùng hay đặt là 123456 hay password@123. Vấn đề thực sự nằm ở cơ chế Shared Secret (Bí mật chia sẻ).

Để chứng minh danh tính với Server, bạn buộc phải gửi bí mật đó đi (transmit). Dù bạn có mã hóa đường truyền bằng SSL/TLS, thì tại điểm đích (Server), bí mật đó phải được giải mã để đối chiếu. Cơ chế này giống như việc bạn đứng trước cổng thành và phải hét to mật khẩu cho lính canh nghe.

• Nếu lính canh (Server) bị mua chuộc hoặc bị mạo danh (Man-in-the-middle), bạn mất chìa khóa.
• Nếu có kẻ nghe trộm được tiếng hét đó (Replay attack), hắn có thể giả làm bạn vào ngày hôm sau.

Hơn nữa, Password là “Something you know”. Đặc điểm của tri thức là nó có thể bị sao chép vô hạn mà chủ nhân không hề hay biết. Nếu ai đó nhìn trộm bạn gõ phím, họ đã có được bản sao của chìa khóa. Ngược lại, Hổ Phù là “Something you have”. Mất cái miếng đồng đó là biết ngay, vì nó không còn nằm trên tay mình nữa.

Đối với anh em SysAdmin, việc mở port 22 với Password Authentication chẳng khác nào mở tiệc mời botnet. Hãy thử tail -f /var/log/auth.log (hoặc /var/log/secure) trên một server mới tạo xem. Chỉ sau vài phút, bạn sẽ thấy hàng nghìn con bot từ khắp nơi trên thế giới đang thi nhau “thử vận may” (Brute-force).

Dù chúng có đoán sai cả triệu lần, CPU của server vẫn phải tốn tài nguyên để xử lý cái Access Denied đó. Đó là một sự lãng phí tài nguyên và rủi ro bảo mật không đáng có.

2. Sự ra đời của SSH

Trước năm 1995, các SysAdmin thời đó quản lý server từ xa thông qua các giao thức như Telnet, rlogin hay rsh.

Mọi thứ bạn gõ, bao gồm cả username và password, đều được gửi đi dưới dạng văn bản thô qua mạng. Nếu coi Internet là một đường ống nước bằng kính trong suốt, thì ai đứng ngoài cũng có thể nhìn thấy dòng nước (dữ liệu) đang chảy bên trong màu gì. Một hacker chỉ cần tcpdump trên đường truyền là gom được cả rổ mật khẩu.

Mọi thứ thay đổi vào mùa hè năm 1995 tại Đại học Công nghệ Helsinki (Phần Lan). Hệ thống mạng của trường bị tấn công bằng kỹ thuật password sniffing.

Để đối phó, một nhà nghiên cứu tên là Tatu Ylönen đã tự tay viết một giao thức mới để thay thế Telnet. Ông đặt tên nó là Secure Shell, viết tắt là SSH.

Thay vì cố gắng che chắn đường ống (điều bất khả thi), SSH xử lý dữ liệu ngay tại hai đầu mút (Endpoints). Trước khi thả dữ liệu vào ống, SSH dùng thuật toán để “xáo trộn” nó thành một mớ ký tự hỗn độn. Sang đến đầu kia, chìa khóa giải mã sẽ sắp xếp lại mớ hỗn độn đó thành thông tin có nghĩa. Dù hacker có ghé mắt vào đường ống ở giữa, thứ họ nhận được chỉ là một chuỗi ký tự ngẫu nhiên (ciphertext) vô giá trị.

Một chi tiết thú vị về Port 22: Khi Tatu thiết kế SSH, ông muốn nó thay thế Telnet (chạy ở port 23) và FTP (chạy ở port 21). Ông nhìn vào danh sách port chuẩn của IANA và thấy con số 22 vẫn còn trống. Port 22 nằm kẹp giữa 21 và 23, như một tuyên ngôn ngầm rằng SSH sinh ra để thế chỗ cho cả hai giao thức kém bảo mật kia. Tatu gửi email cho IANA xin cấp port 22, và phần còn lại là lịch sử.

Chỉ sau vài tháng ra mắt, SSH đã lan rộng khắp thế giới, trở thành “tiêu chuẩn de facto” cho việc quản trị server từ xa, đẩy Telnet vào viện bảo tàng công nghệ.

3. SSH Key Authentication

Cha đẻ của SSH, Tatu Ylönen, ngay từ đầu đã nhận thấy Password là một mắt xích yếu. Vì vậy, SSH Key (dựa trên thuật toán RSA thời đó) đã được tích hợp ngay trong kiến trúc cốt lõi của SSHv1.

Về mặt kỹ thuật, SSH Key Authentication là ứng dụng của mật mã khóa công khai (Public-key cryptography), cụ thể là cơ chế Chữ ký số (Digital Signature).

Khác với Password (bạn gửi bí mật đi để so khớp), SSH Key hoạt động theo nguyên tắc: Server nắm giữ ổ khóa (Public Key), Client nắm giữ con dấu (Private Key).

Quy trình xác thực diễn ra như sau:

1. Đề nghị (Proposal): Client gửi Public Key ID lên Server và bảo: “Tôi muốn đăng nhập bằng Key này”.
   
2. Kiểm tra (Check): Server lục trong file ~/.ssh/authorized_keys. Nếu thấy Public Key đó tồn tại, nó chấp nhận đi tiếp.
   
3. Thử thách (Challenge): Server tạo ra một chuỗi dữ liệu ngẫu nhiên (nonce), gộp với Session ID hiện tại và gửi yêu cầu: “Hãy dùng Private Key của anh để ký (sign) vào gói tin này”.
   
4. Ký số (Signing): Client dùng Private Key của mình để tạo ra một chữ ký số (Digital Signature) trên dữ liệu đó và gửi trả lại cho Server. Lưu ý: Client chỉ gửi chữ ký, không gửi Private Key.
   
5. Xác minh (Verification): Server dùng Public Key (đang có sẵn) để kiểm tra xem chữ ký kia có đúng là được tạo ra bởi Private Key tương ứng hay không. Nếu toán học trả về kết quả khớp, phiên đăng nhập được thiết lập.

Điểm mấu chốt về bảo mật: Trong toàn bộ quá trình này, Private Key không bao giờ rời khỏi máy tính của Client. Nó không bao giờ được truyền qua mạng, dù là dưới dạng mã hóa.

Kẻ tấn công đứng giữa (Man-in-the-middle) dù có bắt được toàn bộ gói tin trao đổi, thứ hắn có chỉ là: một lời đề nghị, một thử thách ngẫu nhiên, và một chữ ký số chỉ có giá trị duy nhất cho phiên làm việc đó (one-time use). Hắn không thể tái sử dụng chữ ký này cho phiên khác (Replay Attack), cũng không thể suy ngược ra Private Key từ chữ ký.

Đây là lý do tại sao SSH Key được coi là an toàn hơn Password về mặt kiến trúc: Nó loại bỏ hoàn toàn khả năng bị lộ bí mật trong quá trình truyền tải.

4. Best Practices

SSH Key an toàn hơn Password nếu dùng đúng cách. Dưới đây là vài nguyên tắc để anh em SysAdmin ngủ ngon hơn.

4.1. Tại sao luôn phải đặt Passphrase?

Thời chiến quốc, nước Triệu bị quân Tần vây hãm, Tín Lăng Quân muốn cứu nhưng không có quyền điều binh. Binh quyền nằm ở chiếc Hổ Phù trong tay vua Ngụy. Tín Lăng Quân bèn nhờ Như Cơ trộm chiếc Hổ Phù từ trong phòng ngủ của vua. Kết quả: Tín Lăng Quân lấy được 8 vạn quân và giải vây cho nước Triệu.

Trong thế giới số, Như Cơ chính là Malware, là Poisoned Package, hoặc một pha Social Engineering ngọt ngào mà bạn vô tình dính bẫy.

Bài học ở đây là: Cơ chế của Hổ Phù (hay SSH Key) là dựa trên vật sở hữu. Ai cầm vật đó, người đó có quyền. Laptop của bạn chính là “phòng ngủ của vua”. Nếu bạn mất laptop, hoặc máy dính virus, hacker sẽ copy được file Private Key.

• Nếu không có Passphrase: Hacker đăng nhập được ngay. Bạn mất server.
  
• Nếu có Passphrase: Hacker chỉ lấy được một file mã hóa. Không có mật khẩu giải mã thì cái file đó vô dụng.

Passphrase biến cơ chế bảo mật từ 1 lớp (thứ bạn có) thành 2 lớp (thứ bạn có + thứ bạn biết). Đừng lười một bước nhỏ mà để lại mối nguy tiềm tàng về lâu dài.

4.2. Chọn RSA hay Ed25519?

Hãy tưởng tượng RSA giống như những bộ giáp sắt (Plate Armor) của hiệp sĩ Châu Âu trung cổ. Thời gian đầu, nó rất kiên cố. Nhưng khi vũ khí tấn công (năng lực tính toán của máy tính) ngày càng mạnh lên, người ta buộc phải đắp ngày càng nhiều sắt lên bộ giáp đó để giữ an toàn. Key size phải tăng từ 1024 lên 2048, rồi 4096 bit. Hậu quả là nó trở nên nặng nề, cồng kềnh và chậm chạp.

Ngược lại, Ed25519 (dựa trên Đường cong Elliptic) giống như kỵ binh Mông Cổ: Không mặc giáp nặng, di chuyển cực nhanh và độ sát thương cực cao. Đế chế Mông Cổ đã chứng minh rằng sự cơ động và kỹ thuật (thuật toán tốt hơn) sẽ chiến thắng sức mạnh cơ bắp thuần túy.

Về mặt kỹ thuật:

• RSA 4096: Là một sớ văn bản dài dằng dặc, copy-paste rất dễ thiếu đầu hụt đuôi.
  
• Ed25519: Ngắn gọn chỉ bằng một dòng tweet (68 ký tự), nhưng độ bảo mật tương đương RSA 3072 bit trở lên, và tốc độ ký/giải mã nhanh hơn gấp nhiều lần.

Vì vậy thay vì vác bộ giáp sắt 4096 thì hãy trang bị sự tinh gọn của Ed25519:

ssh-keygen -t ed25519 -C "[email protected]"

4.3. Một key hay nhiều key?

Trong giới SysAdmin tồn tại một cuộc tranh luận không hồi kết về việc nên dùng bao nhiêu key là đủ. Có hai phe thường thấy:

Phe chúa nhẫn: “One Ring to rule them all” (Một chìa cho tất cả) Bạn tạo đúng 1 cặp key, và copy Public Key đó lên tất cả 100 con server bạn quản lý, từ Github cá nhân, VPS test cho đến hệ thống Core Banking của công ty.

• Ưu điểm: Cực nhàn. File ~/.ssh/config ngắn gọn. Đi đâu cũng chỉ cần 1 file identity.
  
• Nhược điểm: Đây là Single Point of Failure (Điểm chết duy nhất). Nếu laptop bạn bị hack và lộ Private Key (lại còn quên đặt passphrase), hacker sẽ có quyền truy cập vào toàn bộ hạ tầng của bạn. Bạn mất tất cả trong một nốt nhạc. Việc đi revoke (thu hồi) key trên 100 con server là một cơn ác mộng.

Phe 3 đầu 6 tay: Mỗi Server một Key Bạn quản lý 50 server, bạn tạo 50 cặp key khác nhau.

• Ưu điểm: Cực kỳ an toàn (Compartmentalization). Mất chìa khóa phòng kho thì chỉ mất đồ trong kho, phòng ngủ vẫn an toàn.
  
• Nhược điểm: Bạn sẽ chết chìm trong đống file key. Quản lý, backup và config alias cho 50 cái key này sẽ ngốn hết thời gian làm việc của bạn.

Giải pháp: Phân chia theo Ngữ cảnh (Security Domains). Đây là con đường trung đạo giúp bạn trung hòa cả ưu nhược điểm của 2 phe trên. Hãy tạo key dựa trên Identity (Danh tính) và Mức độ rủi ro:

1. Key Cá nhân (Personal): Dùng cho Github cá nhân, VPS học tập, blog riêng. (Rủi ro thấp).
   
2. Key Công việc (Work): Dùng cho hạ tầng công ty, Gitlab công ty. (Rủi ro cao, cần bảo vệ nghiêm ngặt). Nếu bạn làm cho nhiều công ty khác nhau thì mỗi công ty một key.
3. Key Khách (Guest/Temp): Dùng cho các server của khách hàng freelance, làm xong dự án là xóa hoặc cold-backup trên một ổ cứng không kết nối mạng.

Bằng cách này, bạn quản lý key vừa nhàn vừa cách ly được hiểm họa giữa các môi trường khác nhau khi lỡ làm lộ key.

4.4. Nên chmod key thế nào?

Nếu đã từng tìm hiểu về Blockchain, bạn sẽ biết sức mạnh của nó nằm ở tính Bất biến (Immutability). Một khi Block đã được đóng gói và thêm vào chuỗi, nó trở thành vĩnh cửu. Không ai có quyền quay lại sửa đổi lịch sử giao dịch trong Block đó. Sửa một bit, mã Hash thay đổi, toàn bộ chuỗi sẽ coi Block đó là giả mạo.

Hãy áp dụng tư duy đó cho Private Key của bạn:

chmod 400 ~/.ssh/id_ed25519

400 = Read-only. Chỉ mình bạn được đọc. Không ai (kể cả chính bạn) được phép chỉnh sửa nếu không chủ động cấp quyền lại.

Cách chmod này tuân thủ nguyên tắc Least Privilege (Quyền hạn tối thiểu): Nếu một vật không cần quyền Ghi để hoạt động, hãy tước bỏ quyền Ghi của nó. Việc để ngỏ quyền Ghi (Write permission) cho một file bất biến là một lỗ hổng logic, tạo cơ hội cho những thay đổi ngoài ý muốn hoặc sự can thiệp của mã độc.

Kết

Suy cho cùng, Hổ Phù hay SSH Key cũng chỉ là công cụ. Vào tay tướng tài thì cứu nước, vào tay kẻ lơ là thì mất nước. Hy vọng bài viết này giúp anh em giữ chặt được cái “Hổ Phù” của mình. Nếu có gì thiếu sót, mong nhận được comment góp ý bên dưới!