Nghiên cứu về giao thức ssh, cấu hình trên openssh

tiếp telnet thông qua SSH, tất cả dữ liệu sẽ tự động được mã hoá và kiểm tra định danh và bạn có thể xác nhận dùng SSH tin cậy. SSH hỗ trợ 3 kiểu chuyển tiếp: +TCP port forwarding: SSH dùng TCP/IP làm cơ chế truyền, thường dùng port 22 trên máy server khi nó mã hoá và giải mã lưu lượng đi trên mạng. Ở đây chúng ta nói đến một đặc điểm mã hoá và giải mã lưu lựong TCP/IP thuộc về ứng dụng khác, trên cổng TCP khác dùng SSH. Tiến trình này gọi là port forwarding, nó có tính trong suốt cao va khá mạnh. Telnet, SMTP, NNTP, IMAP và những giao thức không an toàn khác chạy TCP có thể được bảo đảm bằng việc chuyển tiếp kết nối thông qua SSH. Port forwarding đôi khi được gọi là tunneling bởi vì kết nối SSH cung cấp một “đường hầm” xuyên qua để kết nối TCP khác có thể đi qua. Giả sử bạn có một máy H ở nhà đang chạy IMAP và bạn muốn kết nối đến một IMAP server trên máy S để đọc và gửi mail. Bình thường thì việc kết nối này không đảm bảo an toàn, tài khoản và mật khẩu mail của bạn được truyền đi dưới dạng clear text giữa chương trình mail của bạn và server. Đối với SSH port forwarding, bạn có thể định tuyến lại trong suốt kết nối IMAP ( tìm cổng TCP 143 trên server S) để truyền đi thông qua SSH, mã hoá bảo đảm dữ liệu truyền đi trên kết nối. Máy IMAP server phải chạy một SSH server cho port forwarding để cung cấp việc bảo đảm đó. Tuy nhiên, SSH port forwarding chỉ hoạt động trên giao thức TCP và không làm việc được trên các giao thức khác như UDP hay AppleTalk + forwarding X là một hệ thống window phổ biến đối với các trạm làm việc Unix, một trong những đặc điểm tốt nhất của nó là tính trong suốt. Sử dụng X bạn có thể chạy ứng dụng X từ xa để mở các cửa sổ của chúng trên màn hình hiển thị cục bộ của bạn +Agent forwarding SSH client có thể làm việc với một SSH agent trên cùng một máy. Sử dụng mọt đặc trưng gọi là agent forwarding, client cũng có thể liên lạc với các agent trên những máy từ xa. Điều thuận lợi là nó cho phép client trên nhiều máy làm việc với một agent và có thể tránh vấn đề liên quan đến tường lửa. 3.2.Kiến trúc chung của một hệ thống SSH SSH có khoảng một bộ 12 thuộc tính riêng lẻ, các thành phần tác động lẫn nhau cho ra các nét đặc trưng riêng. SSH cũng có khoá (keys), phiên (sessions) và những thứ ngộ nghĩnh khác. Ở đây chúng ta qui định một bản tóm tắt tổng quan của tất cả các thành phần, ví thế bạn có thể bắt đầu thấy được bức tranh lớn về SSH như sau: Server Một chương trình cho phép đi vào kết nối SSH với một bộ máy, trình bày xác thực, cấp phép, … Trong hầu hết SSH bổ sung của Unix thì server thường là sshd. Client Một chương trình kết nối đến SSH server và đưa ra yêu cầu như là “log me in” hoặc “copy this file”. Trong SSH1, SSH2 và OpenSSH, client chủ yếu là ssh và scp. Session Một phiên kết nối giữa một client và một server. Nó bắt đầu sau khi client xác thực thành công đến một server và kết thúc khi kết nối chấm dứt. Session có thể được tương tác với nhau hoặc có thể là một chuyến riêng. Key Một lượng dữ liệu tương đối nhỏ, thông thường từ mười đến một hoặc hai ngàn bit. Tính hữu ích của việc sử dụng thuật toán ràng buộc khoá hoạt động trong vài cách để giữ khoá: trong mã hoá, nó chắc chắn rằng chỉ người nào đó giữ khoá (hoặc một ai có liên quan) có thể giải mã thông điệp, trong xác thực, nó cho phép bạn kiểm tra trễ rằng người giữ khoá thực sự đã kí hiệu vào thông điệp. Có hai loại khóa: khoá đối xứng hoặc khoá bí mật và khoá bất đối xứng hoặc khóa công khai. Một khoá bất đối xứng hoặc khoá công khai có hai phần: thành phần công khai và thàn phần bí mật. SSH đề cập đến 4 kiểu của khoá như phần tóm tắt trong bảng 3-1 và diễn tả dưới đây. User key Là một thực thể tồn tại lâu dài, là khoá bất đối xứng sử dụng bởi client như một sự chứng minh nhận dạng của user ( một người dùng đơn lẻ có thể có nhiều khoá) Host key Là một thực thể tồn tại lâu dài, là khoá bất đối xứng sử dụng bới server như sự chứng minh nhận dạng của nó, cũng như được dùng bởi client khi chứng minh nhận dạng host của nó như một phần xác thực đáng tin. Nếu một bộ máy chạy một SSH server đơn, host key cũng là cái duy nhất để nhận dạng bộ máy đó. Nếu bộ máy chạy nhiều SSH server, mỗi cái có thể có một host key khác nhau hoặc có thể dùng chung. Chúng thường bị lộn với server key. Server key Tồn tại tạm thời, là khoá bất đối xứng dùng trong giao thức SSH-1. Nó đựợc tái tạo bởi server theo chu kỳ thường xuyên ( mặc định là mỗi giờ) và bảo vệ session key. Thường bị lộn với host key. Khoá này thì không bao giờ được lưu trên đĩa và thành phần bí mật của nó không bao giờ được truyền qua kết nối ở bất cứ dạng nào, nó cung cấp “perfect forward secrecy” cho phiên SSH-1 Session key Là một giá trị phát sinh ngẫu nhiên, là khoá đối xứng cho việc mã hoá truyền thông giữa một SSH client và SSH server. Nó được chia ra làm 2 thành phần cho client và server trong một loại bảo bật trong suốt quá trình thiết lập kết nối SSH để kẻ xấu không phát hiện được nó. Key generator Một chương trình tạo ra những loại khoá lâu dài( user key và host key) cho SSH. SSH1, SSH2 và OpenSSH có chương trình ssh-keygen Known hosts database Là một chồng host key. Client và server dựa vào cơ sở dữ liệu này để xác thực lẫn nhau. Agent A program that caches user keys in memory, so users needn't keep retyping their passphrases. The agent responds to requests for key-related operations, such as signing an authenticator, but it doesn't disclose the keys themselves. It is a convenience feature. SSH1, SSH2, and OpenSSH have the agent ssh-agent, and the program ssh-add loads and unloads the key cache. Một chương trình lưu user key trong bộ nhớ. Agent trả lời cho yêu cầu đối với khoá quan hệ hoạt động như là kí hiệu một giấy xác thực nhưng nó không tự phơi bày khoá của chúng. Nó là một đặc điểm rất có ích. SSH1, SSH2 và OpenSSH có agent ssh-agent và chương trình ssh-add để xếp vào và lấy ra khoá được lưu. Signer Một chương trình kí hiệu gói chứng thực hostbased. Random seed A pool of random data used by SSH components to initialize software pseudo-random number generators. Một dãy dữ liệu ngẫu nhiên đựoc dùng bởi các thành phần SSH để khởi chạy phần mềm sinh số ngẫu nhiên Configuration file Một chồng thiết lập để biến đổi hành vi của một SSH client hoặc SSH server. Không phải tất cả thành phần đều được đòi hỏi trong một bản bổ sung của SSH. Dĩ nhiên những server, client và khoá là bắt buộc nhưng nhiều bản bổ sung không có agent và thậm chí vài bản không có bộ sinh khoá. 3.3.Bên trong SSH-2 : Giao thức SSH-2 được chia làm 4 bộ phận chính, được diễn tả như 4 giao thức riêng rẽ trong nhiều tài liệu IETF khác nhau. Theo thông thường, chúng được sắp xếp cùng với nhau để cung cấp thiết lập các dịch vụ mà hầu hết người dùng kết hợp chúng thành một SSH-2 đầy đủ. -Giao thức lớp vận chuyển SSH (SSH-TRANS) -Giao thức xác thực SSH (SSH-AUTH) -Giao thức kết nối SSH (SSH-CONN) -Giao thức truyền file SSH (SSH-SFTP) Hình 3-2 phác thảo việc phân chia công việc giữa các giao thức, và chúng quan hệ với nhau như thế nào, những chương trình ứng dụng và mạng. Những chữ nghiêng là phần mở rộng giao thức. SSH-2 đươc thiết kế để mở rộng và modul hoá. Tất cả các giao thức lõi định nghĩa miêu tả các dịch vụ mà chúng cung cấp và chúng phải phù hợp nhưng cho phép nhiều cơ chế có thể làm việc, cũng như là một cach để dễ dàng thêm vào một cơ chế mới. Tất cả những tham số chủ yếu của kết nối SSH đều có thể được thương lượng, bao gồm những thuật toán và phương thức sử dụng trong: §Trao đổi khoá phiên §Xác thực server §Bảo toàn và bí mật dữ liệu §Xác thực người dùng §Nén dữ liệu Client và server thương lượng việc sử dụng một thiết lập phổ biến, cho phép thao tác rộng giữa các phần bổ sung khác nhau. Trong hầu hết các loại, giao thức định nghĩa ít nhất một phương thức để đẩy mạnh thao tác giữa các phần xa hơn. Nên nhớ rằng điều này chỉ có nghĩa một việc tuân theo được thực hiện đòi hỏi hỗ trợ phương thức trong đoạn mã của nó ; bất cứ một phương thức ngoại lệ nào cũng có thể bị tăt bởi người quản trị trong một điều kiện đặc biệt nào đó. Vì thế, trên thực tế việc chứng thực khoá công khai đòi được hỏi bởi SSH-AUTH không có nghĩa là nó luôn luôn có sẵn cho client từ bất cứ máy nào chạy SSH server, nó chỉ có nghĩa là nó phải có sẵn và có thể được bật lên nếu cần. 3.3.1.Tóm tăt cơ chế hoạt động của SSH-2 Một phiên làm việc của SSH-2 trải qua 4 bước chủ yếu như sau: + Thiết lập kết nối ban đầu (SSH-TRANS) + Tiến hành xác thực lẫn nhau (SSH-AUTH) + Mở phiên kết nối để thực hiện các dịch vụ (SSH-CONN) + Chạy các dịch vụ ứng dụng SSH ( có thể là SSH-SFTP) SSH-TRANS là khối xây dựng cơ bản cung cấp kết nối ban đầu, ghi chép giao thức, xác thực server, mã hoá cơ bản và các dịch vụ bảo toàn. Sau khi thiết lập một kết nối SSH-TRANS, client có một kết nối đơn, đảm bảo, luồng truyền byte full-duplex đến một xác nhận tương đương. Kế đến, client có thể dùng SSH-AUTH thông qua kết nối SSH-TRANS đến xác thực của chính nó với server. SSH-AUTH định nghĩa một cái khung đối với việc nhiều cơ chế xác thực có thể được sử dụng, sữa chữa mọi thứ như là định dạng và những yêu cầu khác của xác thực,những điều kiện để thành công hoặc có thể bị lỗi và làm thế nào client học được những phương thức có sẵn. Có thể là một phương thức bất kỳ nào đó được thi hành, và giao thức cho phép trao đổi tuỳ ý một phần của bất kỳ cơ chế riêng nào để phần mở rộng giao thức dễ định nghĩa để kết hợp chặt chẽ với bất cứ phương thức xác thức mong muốn nào trong tương lai. SSH-AUTH chỉ yêu cầu một phương thức: khoá công cộng với thuật toán DSS. Xa hơn nữa, nó định nghĩa hai phương thức: mật khẩu và dựa trên host. Một số phương thức đã được định nghĩa trong nhiều bản thảo Internet khác nhau và vài bản đã được chấp nhận rộng rãi. Sau khi xác thực, SSH client yêu cầu giao thức SSH-CONN để cung cấp một sự đa dạng của các dịch vụ thông qua một kênh đơn cung cấp bởi SSH-TRANS. Điều này bao gồm mọi thứ cần để hỗ trợ nhiều phiên tương tác và phiên không tương tác: những luồng đa thành phần khác nhau (hoặc channel) ngang qua kết nối bên dưới, quản lý X, TCP và agent forwarding, truyền tín hiệu thông qua kết nối, nén dữ liệu và thực thi chương trình từ xa. Cuối cùng, một ứng dụng có thể sử dụng SSH-SFTP qua một kênh SSH-CONN để cung cấp truyền file và các chức năng thao tác hệ thống tập tin từ xa. 3.3.2.Giao thức lớp vận chuyển SSH (SSH-TRANS) 3.3.2.1.Tiến trình tạo kết nối Để minh hoạ, chúng ta lấy một ví dụ một Client SSH chạy trên một máy Macintosh sẽ đọc cấu hình file của nó và sau đó tạo một kết nối TCP đến phía bên đầu xa ( ví dụ đến host.foo.net) như sau: $ ssh -vv host.foo.net OpenSSH_3.6.1p1+CAN-2003-0693, SSH protocols 1.5/2.0, OpenSSL 0x0090702fdebug1: Reading configuration data /Users/res/.ssh/config debug1: Applying options for com debug1: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to host.foo.net [10.1.1.1] port 22. debug1: Connection established. 3.3.2.2.Tiến trình chọn lựa phiên bản giao thức Càng sớm càng tốt khi server chấp nhận kết nối, giao thức SSH bắt đầu. Server thông báo phiên bản giao thức của nó bằng một chuỗi văn bản:Debug1: Remote protocol version 2.0, remote software version 4.1.0.34 SSH Secure Shell Bạn có thể thấy chuỗi này trong kết nối đơn giản của bạn đến server như telnet: $ telnet host.foo.net 22 Trying 10.1.1.1... Connected to host.foo.net Escape character is '^]'. SSH-2.0-4.1.0.34 SSH Secure Shell ^] telnet> quit Connection closed. Định dạng của thông báo là: SSH-- Trong trường hợp này, server dùng giao thức SSH-2 và phần mềm 4.1.0.34 của SSH từ công ty bảo mật truyền thông (SSH Communication Security). Mặc dù trường chú thích có thể bao gồm mọi thứ nhưng SSH server thường chỉ đưa vào đó tên và phiên bản sản phẩm. Điều này rất có ích để client thường nhận biết chính xác server dùng sản phẩm và phiên bản gì để làm việc cho đúng và tránh lỗi hoặc không tương thích với nhau.Phiên bản giao thức số “1.99” có ý nghĩa đặc biêt: nó hỗ trợ cả hai giao thức SSH-1 và SSH-2.Tiếp theo, OpenSH phân tích lời chú thích: debug1: no match: 4.1.0.34 SSH Secure Shell debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.6.1p1+CAN-2003-0693 nhưng không tìm thấy một cái hợp với danh sách của nó thì nó biết là có vấn đề. Nó chọn SSH-2 (chỉ chọn trong ví dụ này) và gửi chuỗi phiên bản của nó đến server giống như cách mà server đã gửi. Nếu client và server đồng ý phiên bản của chúng đã tương thích thì tiến trình kết nối tiếp tục, nếu không thì cả hai có thể kết thúc kết nối. 3.3.2.3.Tiến trình thương lượng tham số Đã thiết lập kết nối và đồng ý trên một phiên bản, nhiệm vụ đầu tiên của SSH-TRANS là chuẩn bị các thuộc tính bảo mật cơ bản của SSH: oTính bí mật (privacy) oTính toàn vẹn (integrity) oXác thực server oNén dữ liệu Nhưng đầu tiên, hai bên phải đồng ý các thông số phiên, bao gồm các phương thức để đạt được các thuộc tính. Tiến trình diễn ra trong gian đoạn này gọi là tiến trình trao đổi khoá. Debug1: SSH2_MSG_KEXINIT sent Debug1: SSH2_MSG_KEXINIT receive Client gửi thông báo KEXINIT (khởi tạo tao đổi khoá) của nó và nhận một cái tữ server. Ở đây có sự chọn lựa nó đưa cho server: debug2: kex_parse_kexinit: gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==, gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==, diffie-hellman-group-exchange-sha1, diffie-hellman-group1-sha1 Thuật toán trao đổi khoá mà client hỗ trợ là: diffie-hellman-group1-sha1 Thuật toán này được định nghĩa và yêu cầu bởi SSH-TRANS, chỉ rõ cho biết là dùng thủ tục Diffie-Hellman để thoả thuận khoá cùng với những tham số cụ thể khác (Oakley Group 2 và thuật toán băm SHA-1) diffie-hellman-group-exchange-sha1 Tương tự, nhưng cho phép client chọn từ một danh sách các nhóm tham số, địa chỉ liên quan về những khả năng có thể bị tấn công dựa trên một nhóm được bố trí trước, định nghĩa trong tài liệu phác thảo IETF “secsh-dh-group-exchange” gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g== gss-group1-sha1-A/vxljAEU54gt9a48EiANQ== Những các tên trông kỳ quặc là được mã hóa Base64 - chúng hiển thị hai giá trị khác nhau của xác thực Kerberos, trao đổi Diffe-Hellman. Một cơ sở hạ tầng Kerberos có sẵn cung cấp xác thực server tự động và linh hoạt mà không cần xác nhận SSH host key và file known-host riêng. Xác thực Kerberos được cung cấp bởi GSSAPI và những tên phía sau là mã hóa Base64 của hàm băm MD5. Trong điều kiện tóm tắt của thỏa thuận, một thuật toán trao đổi khoá SSH có hai đầu ra : oMột share secret, K oMột “exchange hash”, H K là tham số bí mật chính đối với phiên: SSH-TRANS định nghĩa một phương thức đối với secret K từ những nguồn gốc khoá khác nhau và những tham số mã hoá khác cần thiết cho việc mã hoá cụ thể và thuật toán toàn vẹn dữ liệu được sử dụng trong kết nối SSH. Exchange hash H thì không bí mật, mặc dù nó không cần thiết để lộ ra và nó là duy nhất trong mỗi phiên . Trao đổi khoá cũng diễn ra trên xác thực server để đề phòng việc giả mạo và tấn công man-in-the-middle và có thể được lặp lại trong một kết nối để thay thế một cái cũ hoặc xác thực lại server. Tiếp theo, client cung cấp một kiểu SSH host key mà nó có thể cháp nhận : debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,null Trong trường hợp này, nó cung cấp RSA, DSA và null đối với trường hợp không có khoá. Nó bao gồm cả null bởi vì nó hỗ trợ Kerberos cho xác thực host. Nếu dùng trao đổi khoá Kerberos thì không có SSH host key nào cần thiết đối với việc xác thực server.Sau đó, client liệt kê những thuật toán mã hoá dữ liệu mà nó hỗ trợ : debug2:kex_parse_kexinit:aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour, aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se Dữ liệu chính thì không bao giờ được mã hoá trực tiếp với phương thức khoá công khai như RSA hoặc DSA bởi vì chúng làm qua chậm. Thay vào đó, chúng ta sử dụng một thuật toán khoá đối xứng như trong danh sách phia trên để bảo vệ khoá phiên đối với việc mã hoá bằng phương thức khoá công khai nếu thích hợp. Kế đến, client hiển thị danh sách các thuật toán toàn vẹn dữ liệu mà nó có sẵn: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160, hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 Thuật toán toàn vẹn được ứng dụng để mỗi thông điệp được gửi bởi giao thức hồ sơ SSH cùng với một chuỗi số và một khoá phiên toạ ra một mã xác nhận thông điệp (MAC:message authentication code) được thêm vào mỗi thông điệp. Bên nhận có thể dùngg MAC và bản sao chép khoá phiên của nó để kiểm tra thông điệp không bị biến đổi trên đường truyền, không bị truyền lặp lại và không phải là do một phiên khác gửi tới, đó là những thuộc tính của toàn vẹn dữ liệu.Cuối cùng, client cho biết kỹ thuật nén dữ liệu mà nó hỗ trợ: debug2: kex_parse_kexinit: none,zlib Sau khi gửi thông điệp thoả thuận của nó, client cũng nhận từ server danh sách các tham số mà server hỗ trợ: debug2: kex_parse_kexinit: diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss,x509v3-sign-rsa debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc, blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib Kế đến, mỗi bên chọn các thuật toán tương ứng từ các thuật toán hõ trợ của bên kia: debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none Trong trường hợp này, việc chọn lựa trên cả hai bên là giống nhau. Tuy nhiên, chúng không cần thiết phải giống. Việc mỗi bên chọn lựa một thuật toán hay một khoá độc lập với nhau cũng không có hại gì. 3.3.2.4.Tiến trình trao đổi khoá và xác thực server Tại thời điểm này, chúng sẵn sàng để đưa ra danh sách trao đổi khoá: debug2: dh_gen_key: priv key bits set: 131/256 debug2: bits set: 510/1024 debug1: sending SSH2_MSG_KEXDH_INITClient chọn mọt thuật toán trao đổi khoá từ bộ thông báo của server, trong trường hợp này thì server chỉ đưa ra có một cái. Nó sinh ra một khoá tạm thời như một phần của thuật toán Diffe-Hellman và gửi thông điệp khởi tạo của trao đổi diffie-hellman-group1-sha1, cùng lúc đó server biết được phương thức mà hai bên sử dụng và bắt đầu trao đổi.Tiếp theo, client đợi và server gửi thông điệp KEXDH_INIT của chúng: debug1: expecting SSH2_MSG_KEXDH_REPLY debug1: Host 'host.foo.net' is known and matches the DSA host key. debug1: Found key in /Users/res/.ssh/known_hosts:169 debug2: bits set: 526/1024 debug1: ssh_dss_verify: signature correct Bao gồm trong phần trả lời của server là khoá công khai SSH của nó, cùng với một chữ kí cung cấp khoá bí mật tương ứng mà nó giữ. Dĩ nhiên cữ kí sẽ được kiểm tra nhưng không có ý nghĩa quan trọng, bước quan trọng ở đây là kiểm tra định danh khoá công khai của server. Trong ví dụ này, client tìm một bản kết hợp tên foo.host.net với khoá được cung cấp bởi server.SSH-2 hỗ trợ hệ thống PKI (Public Key Infrastructure) để kiểm tra khoá công khai, định nghĩa một số kiểu khoá bao gồm gắn với giấy xác thực : 3.3.3.Giao thức chứng thực SSH (SSH_AUTH) 3.3.3.1.Tiến trình yêu cầu chứng thực Quá trình chứng thực được client bắt đầu bằng yêu cầu chứng thực và server hồi đáp lại. Một yêu cầu chứng thực bao gồm những phần như sau: §Username U: là định danh giấy phép của client. § Tên dịch vụ S: những việc mà client yêu cầu được truy cập, bắt đầu hoạt động thông qua kết nối SSH-TRANS sau khi chứng thực thành công. Có thể có nhiều dịch vụ có sẵn nhưng thông thường chỉ có một “ssh-connection” yêu cầu truy cập đến những dịch vụ cung cấp khác nhau thông qua giao thức SSH-CONN: đăng nhập, thi hành lệnh từ xa, chuyển tiếp cổng và tất cả những thứ khác mà người sử dụng muốn làm với SSH. §Tên phương thức M, và phương thức dữ liệu cụ thể D : phương thức xác thực cụ thể được dùng trong yêu cầu là “pasword” hoặc “publickey” và phương thức dữ liệu cụ thể truyền bất cứ thứ gì cần thiết để bắt đầu trao đổi chứng thực rõ ràng, ví dụ, một mật khẩu được kiểm tra bởi server. Như là tên khoá trao đổi trong SSH-TRANS thì tên có cú pháp “@domain” có thể được dùng bởi bất cứ ai để thực hiện phương thức cục bộ, trong khi những tên không có @ phải được đăng kí tên toàn bộ các phương thức chứng thực SSH.Mỗi khi phương thức chứng thực bắt đầu, nó có thể bao gồm bất kỳ một số kiểu thông điệp chi tiết nào khác mà nó cần. Hoặc trong trường hợp đơn giản, dữ liệu mang bởi yêu cầu ban đầu cũng đã đủ và server có thể hồi đáp đúng như thể. Trong bất cứ trường hợp nào, sau khi yêu cầu và sau vài phương thức thông điệp theo sau đó thì server cấp phát một hồi đáp chứng thực. 3.3.3.2.Tiến trình hồi đáp chứng thực Một hồi đáp chứng thực có hai trạng thái: Thành công và thất bại. Một thông báo thành công không mang dữ liệu nào khác ngoài thông báo là xác thực đã thành công và dịch vụ yêu cầu đã được bắt đầu. Thêm nữa, thông báo SSH-TRANS được client gửi được định nghĩa cùng với giao thức của dịch vụ và SSH-AUTH được chạy .Một thông báo lỗi có sẽ có cấu trúc hư sau: §Một danh sách các phương thức chứng thực có thể tiếp tục §Một cờ “ partial success”Nếu cờ partial success không bật lên thì thông báo đó có nghĩa là những phương thức chứng thực trước đó đã bị lỗi. Nếu cờ partical được bật lên thì thông báo có nghĩa là phương thức đã thành công, tuy nhiên, server yêu cầu phải bổ sung những phương thức còn bị lỗi khác cho thành công trươc khi đồng ý cho truy cập. 3.3.3.3.Chứng thực khoá công khai Một yêu cầu chứng thực khoá công khai mang phương thức có tên là “publickey” và có thể có nhiều dạng khác nhau phụ thuộc vào một cờ được thiết lập. Một dạng của phương thức này là: §flag = FALSE §Tên thuật toán §Dữ liệu khoá Thuật toán khoá công khai có thể dùng là những thuật toán thiết lập trong SSH-TRANS và định dạng dữ liệu khoá phụ thuộc vào kiểu khoá như ssh-dss hay ssh-rsa.Với cờ thiết lập là FALSE, thông báo này chỉ đơn thuần là kiểm tra xác thực: nó yêu cầu server kiểm tra khoá này có được xác thực để truy cập như mong muốn của tài khoản hay không, nếu được thì gửi lại một thông báo cho biết. Nếu khoá không được xác thực, hồi đáp có giá trị FALSE đơn giản.Sau khi xác nhận khoá và gửi thông báo thành công, server cho biết đã chấp nhận truy cập và kết thúc phiên SSH-AUTH. 3.3.3.4.Xác thực password Phương thức mật khẩu thì rất đơn giản: nó tên là “password”. Phương thức này chỉ có trong một số bản bố sung của SSH2. Sau khi kiểm tra các tham số thích hợp, server sẽ gửi thông báo chấp nhận truy cập của client và nếu có giao thức này thì server sẽ gửi kết hợp password với thông báo đó để xác thực với client. 3.3.3.5.Xác thực dựa trên host (hostbased) Cũng là một phương thức của một số bản bổ sung. Phương thức này dùng để server xác thực client mà nó đã nhận yêu cầu có đúng hay không dựa trên tên máy. Giả sử rằng bạn ở máy A gửi yêu cầu đến server nhưng không đi trực tiếp đến server mà trên đường truyền phải đi qua máy B thì server không kiểm tra máy B mà sẽ kiểm tra xem có phải bên gửi yêu cầu truy cập đến nó có phải là máy A hay không. 3.3.4.Giao thức kết nối SSH-CONN Khi yêu cầu xác thực thành công, client se có một dịch vụ tên “ssh-con” nhưng nó không hiển thị trên client mà hiển thị trên server như sau:debug1: userauth-request for user res service ssh-connection method publickeyServer bắt đầu chạy dịch vụ và hai bên đi đến giao thức kết nối SSH 3.3.4.1.Kênh (channels) Dịch vụ cơ bản SSH-CONN cung cấp là multilexing. SSH-CONN điều khiển một kênh đơn, bảo đảm, luồng byte đôi được cung cấp bởi SSH-TRANS và cho phép client tạo những kênh luận lý SSH-CONN khác chạy qua nó. Kênh được nhận dạng bằng số kênh và có thể được tạo hoặc huỷ bỏ bởi client hoặc server. Kênh là một điều khiển lưu lượng riêng lẻ và mỗi kênh có một kiểu kênh được định nghĩa theo mục đích sử dụng. Kiểu được định nghĩa như sau:§session: Đơn thuần chỉ là mở một kênh phiên chứ không bắt đầu chạy một chuơng trình.Một phiên SSH-CONN có thể có nhiều kênh phiên, hỗ trợ đồng thời, ví dụ cùng chạy giao thức truyền file và thực thi chương trình trên một phiên SSH-CONN.§x11: một kết nối X11 client.§orward-tcpip: một kết nối bên trong để chuyển tiếp một cổng ở xa. Khi một kết nối đến trên một cổng TCP chuyển tiếp ở xa, server sẽ mở kênh này trở lại client để mang kết nối.§direct-tcpip: một kết nối TCP bên ngoài. Kết nối trực tiếp này đến mở một kết nối TCP ở một socket định sẵn và thêm kênh đến kết nối đó. Socket có thể dùng một tên miền hoặc địa chỉ IP 3.3.4.2.Yêu cầu (request) Thêm vào một dãy kênh hoạt động- mở, đóng, gủi dữ liệu, gửi dữ liệu khẩn cấp,…SSH-CONN định nghĩa một thiết lập cho yêu cầu với tính đầy đủ hoặc chỉ là một kênh bộ phận. Một yêu cầu đầy đủ ảnh hưởng đến toàn bộ trạng thái của kết nối trong khi một yêu cầu kênh (bộ phận) chỉ được mở một kênh cụ thể.Yêu cầu dầy đủ là:§tcpip-forward: yêu cầu một cổng chuyển tiếp TCP đằng xa cancel-tcpip-forward: huỷ bỏ một chuyển tiếp từ xa§pty-req: chỉ định một pty, bao gồm kích cỡ cửa sổ và kiểu thiết bị đầu cuối.§x11-req: cài đặt chuyển tiếp x11§env: thiết lập một biến điều kiện. § shell, exec, subsystem: chạy tiện ích tài mặc định của tài khoản, một chương trình tuỳ ý, hoặc một dịch vụ đơn giản.§ window-change: thay đổi kích thước cửa sổ thiết bị đầu cuối§xon-xoff: dùng điều khiển bên client §signal: gửi một tín hiệu đặc biệt đến một tiến trình ở xa.§exit-signal: trả về một tín hiệu kết thúc chương trình.Khi SSH-CONN chạy, client gửi yêu cầu và mở một kênh phiên. Sau đó gửi một số yêu cầu muốn thực hiện thông qua các kênh…Bây giờ thì client đã đăng nhập thành công vào máy chủ SHH từ xa. 3.4.Bên trong SSH-1 SSH-1 cũng tương tự như SSH-2 nhưng có một số điểm khác,chúng ta sẽ so sánh những đặc điểm đó với SSH-2 để hình dung SSH-1:v non-modular: SSH-1 được định nghĩa như một giao thức nguyên đơn, còn SSH-2 được thiết kế modul hoá.vless negotiation: SSH-1 có nhiều tham số cố định, thực ra, chỉ có kích thước mã hoá là được thương lượng. Thuật toán nhận dạng, kiểu khoá host, phương thức trao đổi khoá,…tất cả đều cố định.vad hoc naming: SSH-1 không có cú pháp định nghĩa tên linh hoạt như SSH-2 và không có phần mở rộng bổ sung rõ ràng.vSingle authentication: Quá trình xác thực user của SSH-1 chỉ cho phép một phương thức hoạt động thành công, Server không thể yêu cầu nhiều phương thức.vRhostsRSA authentication: Xác thực RhostsRSA của SSH-1 tương tự như xác thực dựa trên host về cơ bản là có giới hạn khi sử dụng địa chỉ mạng làm định danh máy client.vLess flexible remote forwarding: SSH-1 chỉ rõ chuyển tiếp từ xa chỉ trên một cổng, vì thế không thể đưa nhiều địa chỉ khác nhau đến một server.vweaker integrity checking: SSH-1 sử dụng phương thức kiểm tra toàn vẹn không mạnh lắm, đó là thuật toán CRC-32.verver keys: Tiến trình trao đổi khoá cố định của SSH-1 giao cho một khoá bất đối xứng gọi là server key, server key là một cặp khoá public/private tạm thời, sau một giờ lại được phục hồi và sử dụng để cung cấp tính kín đáo chuyển tiếp cho khoá phiên. Kín đáo chuyển tiếp nghĩa là thậm chí việc bảo mật thời gian dài như khoá bí mật host hoặc user được thoả hiệp trễ, không dùng mã hoá phiên SSH trong các bước trước đó, sử dụng một khoá này thì nó không bao giờ được ghi lên đĩa. Thuật toán Diffe-Hellman dùng trong tất cả ứua trình trao đổi khoá của SSH-2 cung cấp tính bí mật chuyển tiếp bởi chính nó vì thế không cần server key.vweak key exchange: Tiến trình trao đổi khoá SSH-1 bảo mật không cao vì chỉ một mình client chọn khoá phiên và gửi đến server. 3.5.Giới thiệu các thuật toán sử dụng trong SSH 3.5.1.Những thuật toán khoá công khai 3.5.1.1Rivest-Shamir-Adleman (RSA) Thuật toán khóa public RSA là kiểu tính toán không đối xứng được sử dụng rộng rãi nhất. Nó bắt nguồn từ sự phân tích thành thừa số của nhiều số nguyên là tích của 2 số nguyên tố gần bằng nhau. Sự phân tích thành thừa số được tin dùng rộng rãi vì sự phức tạp, mặc dù chưa được chứng minh. RSA có thể được dùng cả cho việc mã hóa và chữ ký. Đến tháng 9 năm 2000, RSA được yêu cầu cấp bằng sáng chế tại Mỹ bởi Public Key Partners Inc (PKP) , 1 công ty mà RSA Security Inc là 1 đối tác. Khi bằng sáng chế có hiệu lực, PKP muốn kiểm soát việc sử dụng thuật toán RAS ở Mỹ, và việc sử dụng trái phép là phạm luật. Đến giữa những năm 1990, RSA Security cung cấp miễn phí RSAref, với bản quyền cho phép ngành giáo dục và thương mại sử dụng (cũng như phần mềm được bán ra phi lợi nhuận). Từ đó RSA trở nên phổ biến, RSAref không còn tồn tại. Giao thức SSH-1 chỉ sử dụng RSA. SSH-2 có thể sử dụng nhiều thuật toán public-key, nhưng mặc định chỉ là thuật toán DSA . Nhóm SECSH đã thêm thuật toán RAS vào SSH-2 không lâu sau khi sáng chế hết hiệu lực. 3.5.1.2Thuật toán chữ kí số (DSA) Thuật toán chữ ký số được phát triển bởi cơ quan an ninh quốc gia Mỹ (NSA) và được công bố bởi viện tiêu chuẩn và công nghệ quốc gia Hoa Kỳ và trở thành chuẩn chữ ký số (DSS). DSS được đưa ra như là một chuẩn xử lý thông tin liên bang, FIPS-186 vào tháng 5 năm 1994. Nó là một thuật toán public-key phụ thuộc vào phương pháp Schnorr và ElGamal, dựa vào độ khó của việc tính toán riêng rẽ các logarit trong một trường có giới hạn. Nó được thiết kế là một chữ ký không dùng cho mã hóa, mặc dù bản bổ xung đầy đủ có thể thực thi dễ dàng với cả 2 loại mã hóa RSA và ElGarmal. DSA cũng bị cuốn vào 1 cuộc tranh cãi kể từ khi nó ra đời. Ban đầu, NIST cho rằng họ đã thiết kế ra DSA, nhưng sau đó họ tiết lộ là NSA đã tạo ra nó. Rất nhiều câu hỏi xoay quanh NSA. Researcher Gus Simmons phát hiện ra 1 phần trong DSA cho phép tạo lỗ hổng rò rỉ thông tin, ví dụ các bit khóa bí mật kèm theo mỗi chữ ký. Khi thuật toán được dùng trong trong các thẻ thông minh trong chương trình Capstone của chính phủ, nhiều người vẫn còn nghi ngờ. Cuối cùng NIST dành DSA miễn phí cho mọi người dùng. Đến sau cùng, nó được sáng chế bởi David Kravitz (sáng chế #5,231,668), sau đó một nhân viên của NSA đã chuyển sáng chế này cho chính phủ Mỹ. Tuy nhiên, cũng có những yêu cầu, rằng DSA xâm phạm bằng sáng chế, bao gồm cả sáng chế Shnorr. Cho đến giờ vẫn chưa có sự thay đổi nào từ tòa án. Giao thức SSH-2 cần phải sử dụng DSA để xác nhận host. 3.5.1.3Thuật toán thoả thuận khoá Diffie-Hellman Thuật toán Diffie-Hellman được giới thiệu lần đầu tiên trong thư viện mở, được sáng tạo bởi Whitfield Diffie, Martin Hellman va Ralph Merkle vào năm 1976, được cấp bằng sáng chế năm 1977 (phát hành vào năm 1980, số #4,200,770) giờ thì bằng sáng chế đã hết hạn. Cũng giống như DSA, nó dựa vào sự rời rạc của bài toán logarit, nó cho phép 2 bên lấy được 1 khóa chia sẻ an toàn trên 1 kênh mở. Các phần trao đổi các thông điệp với nhau, sau cùng chúng chia sẻ 1 khóa bí mật. 1 kẻ rình mò không thể lấy được thông tin từ quá trình này. Giao thức SSH-2 cần phải dùng thuật toán Diffie-Hellman trong phương thức trao đổi khóa. 3.5.2.Những thuật toán khoá bí mật 3.5.2.1.Thuật toán mã hoá dữ liệu bí mật quốc tế (IDE) IDEA được thiết kế năm 1990 bởi Xuejis Lai và James Massey và trải qua nhiều lần sửa chữa, cải tiến và đổi tên trước khi có dạng như hiện nay. Mặc dù tương đối mới nhưng nó là thuật toán bảo mật khá tốt. 3.5.2.2.Chuẩn mã hoá tiên tiến (AES) Năm 1997, NIST bắt đầu một chương trình thay thế thuật toán mã hoá đối xứng chuẩn đang có là DES. Thuật toán này được thiết kế bởi Joan Daemen và Vincent Rijmen và ban đầu nó được gọi là Rijndael và sau trở thành Advanced Encryption Standard (AES). AES là một thuật toán mã hoá khối bí mật với chiều dài khoá có thể là 128, 192, hoăc 256 bits. 3.5.2.3.Chuẩn mã hoá dữ liệu (DES) Chuẩn mã hoá dữ liệu là bản cũ của thuật toán mã hoá bí mật và bây giờ nó được thay thế bằng AES. DES được thiết kế bởi các nhà nghiên cứu của IBM vào đầu những năm 1970 với cái tên la Lucifer 3.5.2.4.Trible-DES (3DES) Trible DES hoặc 3DES là một dạng khác của DES dùng để tăng tính bảo mật bằng việc tăng chiều dài khoá. Làm tăng tính bảo mật của thuật toán DES bằng việc mã hoá nhiều 3 lần những khoá độc lập. Là thuật toán mã hoá dạng plantext với sự lặp lại thuật toán DES 3 lần. Chiều dài khoá của 3DES là 112 bit lớn hơn nhều so với 56 bit của DES. 3.5.2.5.ARCFFOUR (RC4) Ron Rivest thiết kế thuật mã hoá RC4 năm 1987 cho bảo mật dữ liệu RSA. Lúc đó nó có tên là RSADSI. Năm 1994, nó được biết đến với tên RC4 hay ARCFOUR. RC4 thì mã hoá rất nhanh nhưng không bảo mật bằng những thuật toán khác. Nó sử dụng kích thước khoá biến đổi. SSH-1 áp dụng RC4 với chiều dài khoá 128 bit. 3.5.2.6.Blowfish Blowfish được thiết kế bởi Bruce Schneier năm 1993, nó từng bước thay thế thuật toán DES. Nó nhanh hơn DES và IDEA nhiều nhưng không bằng RC4, Blowfish là một thuật toán mã hoá miễn phí không đăng kí bản quyền. Chiều dài khoá của Blowfish thay đổi từ 32 đến 448 bit. SSH-2 sử dụng Blowfish với chiều dài khoá là 128 bit 3.5.2.7.Twofish Twofish là một thuật toán mã hoá được Bruce Schneier thiết kế cùng với J.Kelsey, D.Wagner, C.Hall và N. Ferguson. Nó được đón nhận năm 1998 và thay thế DES ở Mỹ. Đây cũng là một thuật toán mã hoá miễn phí cho mọi người. Twofish mã hoá với chiều dài khoá 128, 192, hoặc 256 bít. SSH-2 sử dụng 256 bit. Nó rất nhanh và cũng có tính bảo mật khá cao. 3.5.2.8.CAST CAST được thiết kế vào đầu những năm 1990 bởi Carlisle Adams và Stafforf Tavares. CAST sử dụng chiều dài khoá 128 hoặc 256 bit. Trong SSH-2, CAST được sử dụng với chiều dài khoá là 128 bit 3.5.3.Những hàm băm 3.5.3.1.CRC-32 Thuật toán 32-bit Redundancy Check (CRC-32) được định nghĩa trong ISO 3309, là một hàm băm không mã hoá đối với việc dò tìm lỗi thay đổi dữ liệu. Giao thức SSH-1 sử dụng CRC-32 cho việc kiểm tra toàn vẹn dữ liệu và đề phòng hình thức tấn công “insertion attack” (tấn công bằng cách chèn mã độc vào dữ liệu). 3.5.3.2.MD5 MD5 (Message Digest algorithm number 5) là một thuật mã hoá mạnh, là thuật toán băm 128 bit được thiết kế bởi Ron Rivest năm 1991, MD5 cũng là một thuật toán công cộng không đăng kí bản quyền. 3.5.3.3.SHA-1 SHA-1 (Secure Hash Algorithm 1) được thiết kết bởi NSA và NIST . Cũng giống như MD5, nó được cải tiến từ MD4 nhưng cải tiếp theo một cách khác. Nó cung cấp hàm băm 160 bit. Xét về bảo mật thì nó mạnh hơn MD5 vì giá trị băm dài hơn. SSH-2 sử dụng SHA-1 để băm MAC còn SSH-1 thì sử dụng MD5. 3.5.3.4.RIPEMD-160 RIPEMD-160 là một bản khác của MD4, đựợc phát triển bởi Hans Dobbertin, Antôn Boselaers và Bart Preneel trong một phần của dự án RIPE truyền thông Châu Âu từ tháng 6 năm 1987 đến tháng 12 năm 1995. RIPEMD-160 không được định nghĩa trong giao thức SSH nhưng nó được dùng trong bản bổ sung OpenSSH, RIPEMD-160 cũng là một thuật toán phiễn phí cho mọi người. 3.5.3.5.Thuật toán nén: Zlib Zlib là thuật toán nén dữ kiệu duy nhất được định nghĩa cho SSH. 3.6.Các mối đe doạ mà SSH có thể đánh trả Cũng giống như bất kỳ công cụ bảo mất nào, SSH có những mối đe dọa chống lại các ảnh hưởng của nó và các chương trình khác không định địa chỉ. Chúng ta sẽ thảo luận về hình thức này đầu tiên. 3.6.1.Eavesdropping Một eavesdropper là một người rình mò trên mạng, có thể biết được giao thông mạng mà không làm ảnh hưởng đến đường truyền. Hình thức mã hóa của SSH chống lại eavesdropping. Nội dung của một session SSH , ngay cả khi bị chặn, cũng không thể bị giải mã bởi một “kẻ rình mò”. 3.6.2.Dịch vụ đặt tên và giả mạo IP Nếu một kẻ tấn công phá hoại dịch vụ đặt tên (DNS, NIS, …), các chương trình liên quan đến mạng có thể bị ép buộc kết nối đến máy tính khác. Cũng tương tự, một kẻ tấn công có thể giả mạo một host bằng cách đánh cắp địa chỉ IP đang dùng. Trong các trường hợp khác, bạn cũng sẽ gặp rắc rối: các chương trình trên máy khách có thể kết nối sai đến máy chủ, đánh cắp mật khẩu mà bạn cung cấp. Trình bảo vệ SSH chống lại kiểu tấn công này bằng cách kiểm tra mã hóa và nhận dạng máy chủ. Khi cài đặt một session, máy khách SSH kiểm tra tính hợp lệ khóa của máy chủ dựa vào danh sách cục bộ kết hợp với tên máy chủ và các địa chỉ cùng với khóa của chúng. Nếu khóa mà Host cung cấp không đúng với trong danh sách, SSH sẽ cảnh báo. Tính năng này có thể bị vô hiệu hóa trong một số ít các thiết lập an ninh khi mà các thông báo cảnh báo gây khó chịu. Giao thức SSH-2 cho phép bao gồm chứng nhận PKI cùng với các khóa. Trong tương lai, chúng ta hi vọng sự bổ xung tính năng này vào các sản phẩm SSH cùng với nhiều sự triển khai phổ biến của PKI sẽ xóa đi gánh nặng quản trị khóa và giảm bớt sự cần thiết cho sự thỏa hiệp an ninh nói riêng này. 3.6.3.Chiếm đoạt kết nối Một kẻ tấn công lanh lợi không chỉ có thể theo dõi được giao thông mạng, mà còn có thể xen vào, chiếm đoạt một kết nối TCP, đánh cắp nó theo nghĩa đen từ một điểm cuối hợp pháp. Đây là các tai hại rõ ràng: dù cho phương thức xác nhận của bạn có tốt như thế nào đi nữa, kẻ tấn công có thể đơn giản là đợi cho đến khi bạn đăng nhập, sau đó đánh cắp kết nối và chèn các lệnh bất chính của hắn vào trong session của bạn. SSH không thể chống lại kiểu chiếm quyền điều khiển này, từ đó trở đi đây trở thành điểm yếu trong TCP hoạt động bên dưới SSH. Tuy nhiên, SSH đáp trả không hiệu quả (trừ kiểu tấn công từ chối dịch vụ). Trình kiểm tra tính toàn vẹn của SSH phát hiện một session có bị sửa đổi hay không, và ngắt kết nối ngay lập tức mà không sử dụng bất kỳ dữ liệu bị sửa đổi nào. 3.6.4.Các kiểu tấn công Man-in-the-Middle Kiểu tấn công người dùng ở giữa là kiểu tấn công chủ động đặc biệt không dễ bị phát hiện và được mô tả trong phần 3-5. Một đối thủ ngồi giữa bạn và người ngang hàng thực sự (ví dụ giữa máy khách SSH và máy chủ), chặn tất cả sự qua lại và thay đổi hoặc xóa những thông báo. Hãy tưởng tượng rằng bạn cố gắng kết nối đến một máy chủ SSH, nhưng Mary “hiểm độc” chặn kết nối của bạn. Cô ấy cư xử giống như một máy chủ SSH, dù cho bạn không để ý, cô ấy kết thúc chia sẻ khóa session với bạn. Đồng thời, cô ấy cũng bắt đầu tạo kết nối của chính cô ấy đến máy chủ mong đợi của bạn, thu về được khóa session riêng biệt với máy chủ. Cô ấy có thể đăng nhập giống như bạn bởi vì bạn sử dụng password hợp lệ và vì vậy cũng là đưa cho co ấy password của bạn. Bạn và máy chủ đều nghĩ là đang kết nối đến nhau, nhưng thực tế thì cả 2 đang kết nối đến Mary. Sau đó cô ấy chỉ cần ngồi giữa, truyền dữ liệu ngược lại và tới lui giữa bạn và máy chủ (giải mã một bên với một khóa và mã hóa lại với cái khác dùng để truyền lại). Tất nhiên, cô ấy có thể đọc mọi thứ đi qua và sửa lại theo ý muốn. SSH chống lại kiểu tấn công này theo 2 cách. Đầu tiên là xác nhận máy chủ. Nếu Mary không chặn bên trong máy chủ, cô ấy không thể mạo nhận, bởi vì cô ấy không có khóa riêng của máy chủ. Lưu ý rằng, để sự bảo vệ này hoạt động, trên thực tế máy khách phải kiểm tra khóa public mà máy chủ cung cấp dựa vào danh sách host mà nó biết, nếu không thì sẽ không có bảo đảm rằng máy chủ là thật. Nếu bạn kết nối lần đầu tiên đến một máy chủ mới và để cho SSH chấp nhận khóa của host, thực tế là bạn đang mở ra 1 kiểu tấn công “Người ở giữa”. Tuy nhiên, cứ cho rằng bạn không bị lừa vào lúc này, nhưng các kết nối trong tương lai đến máy chủ này chỉ an toàn cho đến khi khóa host server bị đánh cắp. Khả năng bảo vệ SSH thứ 2 là qua phương thức người dùng xác thực. Phương pháp password hiển nhiên là dễ bị tấn công, nhưng khóa public và sự xác thực dựa trên máy chủ sẽ chống lại kiểu các tấn công MITM. Mary không thể phát hiện ra khóa session một cách dễ dàng thông qua việc trao đổi khóa, cô ấy phải thực hiện một cuộc tấn công chủ động để trao đổi riêng biệt với mỗi bên, thu về các khóa riêng biệt của riêng cô ấy với máy khách và máy chủ. Trong cả 2 giao thức SSH-1 và SSH-2, sự trao đổi khóa được thiết kế sao cho nếu cô ấy thực hiện điều này, thì sự nhận dạng session ở mỗi phía sẽ khác nhau. (Điều này không có ở giao thức SSH-1 cũ). Nếu bạn không xác nhận tên/khóa của máy chủ tương ứng, Mary vẫn có thể thực hiện kiểu tấn công “người ở giữa”, thậm chí dù cô ấy không thể đăng nhập như chính bạn ở phía máy chủ. Cô ấy có thể đăng nhập vào tài khoản của cô ấy hoặc của người khác mà cô ấy đã lấy được. Với sự lanh lợi, cô ấy vẫn sẽ có thể đánh lừa bạn đủ lâu để phá hoại. 3.7. Các mối đe doạ mà SSH không thể ngăn cản SSH không phải là giải pháp an ninh tổng thể. Bây giờ chúng tôi sẽ giới thiệu vài ví dụ về các cách tấn công mà SSH không được thiết kế để chống lại. 3.7.1. Phá mật khẩu SSH cải tiến quá trình an toàn mật khẩu bằng cách mã hóa nó khi truyền qua mạng. Tuy nhiên, mật khẩu vẫn là điểm yếu của quá trình xác thực, bạn phải cẩn thận với điều này. Bạn phải chọn một mật khẩu an toàn, dễ nhớ đối với bạn nhưng lại khó đoán với người khác. Bạn phải tránh bị đánh cắp mật khẩu, tốt nhất là chỉ một mình bạn biết cách truy cập vào tài khoản của mình. Vì vậy, hãy cẩn thận, gã ngồi kế bên bạn có thể sẽ bí mật nhìn trộm khi bạn gõ bàn phím. Máy tính mà bạn sử dụng có thể bị cài chương trình ghi lại các cú gõ phím và chuyển về “Trung Tâm”. Và sau đó, một gã với giọng nói “dễ thương” gọi điện đến từ 1 công ty về Công Nghệ Thông Tin, yêu cầu mật khẩu của bạn để “sửa lại tài khoản” có thể sẽ là người tống tiền. Cần cân nhắc về sự xác thực của khóa public khi nó bao gồm 2 nhân tố: một mật khẩu sẽ không hữu dụng khi không có tập tin khóa riêng, vì vậy một kẻ tấn công cần phải “trộm” cả 2. Tất nhiên, SSH client trong máy tính mà bạn đang dùng có thể bị lừa lưu lại khóa sau khi bạn vô tình cung cấp mật khẩu để giải mã nó. Nếu bạn lo lắng điều đó, bạn không nên sử dụng máy tính lạ. Trong tương lai, ta hi vọng rằng các thẻ smartcard được mã hóa và các máy đọc thể sẽ có mặt ở khắp nơi và được hỗ trợ bởi SSH, vì vậy bạn có thể mang theo khóa bên mình một cách thuận tiện và sử dụng chúng ở các máy tính khác mà không còn lo bị lộ khóa. Nếu phải sử dụng “sự xác minh mật khẩu” vì tính tiện lợi của nó, cần cân nhắc về việc sử dụng mật khẩu theo kiểu một lần như là S/Key để giảm bớt rủi ro. 3.7.2. IP và các kiểu tấn công TCP SSH hoạt động trên nền TCP, vì vậy nó dễ trở thành điểm yếu để tấn công vào TCP và IP. Các đảm bảo về tính riêng tư, tính toàn vẹn, và tính xác thực của SSH sẽ hạn chế rủi ro đối với các cuộc tấn công từ chối dịch vụ. TCP/IP chịu được các sự cố mạng như là sự tắc nghẽn và hỏng các liên kết. Nếu kẻ thù tấn công vào một Router, IP có thể định tuyến xung quanh nó. Tuy nhiên, nó không được thiết kế để chống lại các gói dữ liệu ảo mà kẻ thù đưa vào trong mạng. TCP IP điều khiển các thông báo không được xác thực. Và trong kết quả trả về, TCP/IP có 1 số các điểm yếu cố hữu có thể khai thác được, như là : SYN flood: SYN có nghĩa là “đồng bộ hóa”, và là thuộc tính của gói dữ liệu TCP. Trong trường hợp này, nó đề cập tới gói dữ liệu ban đầu được gửi đến để bắt đấu thiết lập 1 kết nối TCP. Gói này thường được bên nhận dùng vào việc chuẩn bị tài nguyên cho kết nối đang đến. Nếu kẻ tấn công gửi số lượng lớn các gói này, ngăn xếp của TCP có thể bị đầy và không thể chấp nhận các kết nối hợp pháp. TCP RST, ICMP không thật Các kiểu gói khác của TCP là RST, dùng cho việc “khởi động lại”. Một trong 2 bên của kết nối TCP có thể gửi 1 gói RST tại một thời điểm bất kỳ, là nguyên nhân làm hỏng kết nối. Các gói RST có thể bị can thiệp 1 cách dễ dàng trong một mạng, lập tức làm ngắt kết nối TCP. Cũng tương tự, đó là ICMP, giao thức điều khiển thông báo trên mạng internet. ICMP cho phép các IP host và bộ định tuyến giao tiếp thông tin về tình trạng mạng và host có thể tới được. Nhưng lại 1 lần nữa, không có sự xác thực, vì vậy can thiệp vào các gói ICMP ảo có thể gây ảnh hưởng mạnh mẽ. Ví dụ, các thông báo ICMP chỉ ra rằng một host riêng biệt hoặc cổng TCP không thể kết nối được, giả mạo các gói này để làm hỏng kết nối. Các thông báo ICMP cũng giao tiếp với thông tin về lộ trình (gửi qua lại và tìm ra bộ định tuyến); giả mạo các thông báo này có thể làm cho các dữ liệu nhạy cảm được truyền đi không định hướng và làm tổn hại hệ thống. TCP bất đồng bộ và chiếm quyền Bằng cách vận dụng khéo léo giao thức TCP, một kẻ tấn công có thể bất đồng bộ hóa 2 phía của 1 kết nối TCP. Trong tình trạng như vậy, có thể chèn vào các gói được chấp nhận như là 1 phần hợp lệ của kết nối, cho phép kẻ tấn công đưa các thông tin tùy ý vào luồng dữ liệu TCP. SSH không thể chống lại các kiểu tấn công bẻ gãy hoặc chống lại thiết lập kết nối TCP. Nhưng mặt khác, mã hóa của SSH và sự xác thực host có hiệu quả chống lại các kiểu tấn công bao gồm cả việc định tuyến sai. Cũng như vậy, tấn công theo kiểu đánh cắp hoặc thay thế dữ liệu TCP sẽ thất bại, bởi vì SSH phát hiện được, nhưng chúng cũng bẻ gãy kết nối SSH, bởi vì SSH phản hồi lại các lỗi bằng cách kết thúc phiên làm việc. 3.7.3. Phân tích đường truyền Ngay cả khi kẻ tấn công không thể đọc được đường truyền mạng của bạn, hắn có thể thu luợm được 1 lượng lớn thông tin hữu dụng đơn giản bằng cách theo dõi – ghi lại dữ liệu, địa chỉ nguồn và nơi đến và cả thời gian. Sự gia tăng đột ngột đường truyền với 1 công ty khác có thể gợi ý rằng thỏa thuận kinh doanh đã bị chết. Mẫu lưu thông cũng có thể cho biết kế hoạch dự phòng hoặc thời điểm trong ngày dễ bị tấn công nhất để tấn công từ chối dịch vụ. SSH không bị tấn công phân tích lưu lượng dựa vào địa chỉ mà kết nối SSH dẽ bị nhận dạng khi chúng đi đến một cổng được nhiều người biết và giao thức SSH có thể bị tấn công phân tích lưu lượng thông qua port. 3.7.4. Convert Channels (kênh biến đổi) Một Convert channel là một hình thức của tấn công dựa vào thông tin tín hiệu trong một kiểu bất ngờ và không được quan sát trước. Giả sử một ngày nào đó, người quản trị tắt email và thông báo khẩn cấp là mọi user không được chat. Trong trường hợp đó, những user muốn chat với nhau thì phải đưa thông báo cho mỗi user khác bằng cách dán chúng lên bảng thông báo của công ty, nơi mà các user kiểm tra hằng ngày để nhận thông báo mới. Cơ chế truyền thông bất ngờ này là một covert channel. SSH không cố gắng để loại trừ convert channel. Phân tích và điều khiển chúng là một phần chung của một hệ thống bảo mật cao, như là thiết kế để điều khiển an toàn thông tin tại những mức bảo mật khkác nhau trong cùng một hệ thống. 3.7.5. Sự cẩu thả Các tiện ích bảo mật không bảo mật mọi thứ, chúng chỉ giúp người ta làm theo cách này hoặc cách khác. Phương pháp mã hoá tốt đến đâu thì cũng không thể bảo mật được khi bạn làm lộ mật mã do sự cẩu thả. SSH là một tiện ích tốt nhưng nó phải là một phần của một quá trình bảo mật toàn bộ chứ không phải chỉ cài đặt SSH vào rồi nghĩ là hệ thống của bạn đã được an toàn. CHƯƠNG 4: CẤU HÌNH SSH TRÊN CISCO ROUTER Cấu hình SSH trên Cisco Router Cisco đã triển khai SSH vào trong các thiết bị của mình và như một biện pháp để thay thế Telnet. Việc sử dụng Telnet để truy cập và quản trị các thiết bị là không an toàn, và nhiều thông tin có thể bị đánh cắp và dẫn đến một số nguy hiểm có thể xảy ra đối với hệ thống. Cisco đã bắt đầu quan tâm và triển khai vào các thiết bị với SSH-2. Nhà sản xuất cũng cung cấp SSH-1 bởi IPSec sẽ được triển khai trên phiên bản này và cho phép người quản trị truy cập vào các thiết bị một cách an toàn. Thiết lập SSH tương tự như quá trình cho phép Router sử dụng “digital certificates” (xác thực số) trong IPSec. Trước khi bắt đầu chúng ta phải được xác thực bởi Router. Nó không mất quá 30 phút để chúng ta có thể xử lý được những sự cố liên quan đến việc cấu hình này. Một việc đầu tiên là chúng ta phải tạo ra cặp khoá public/private. Trước khi thực hiện thì chúng ta phải cấu hình Router với domain bằng lệnh sau: (config)#ip domain-name abccompany.com (config)#crypto key generate rsa Dòng đầu tiên để Router sẽ là thành viên trong domain abccompany.com trong khi dòng thứ hai sẽ bắt đầu tạo ra một cặp khoá public/private. Khi thực hiện, chúng ta sẽ phải khai báo độ dài của cặp khoá mà chúng ta sử dụng. Và buộc chúng phải có cùng độ lớn trên client và trên Router. Độ lớn của các khoá nó sẽ tự động tạo ví dụ như trên Router 2500, một khoá 512 bit sẽ được tạo ra trong khoảng 45 giây một lần. Dưới đây là các câu lệnh để quản trị SSH (config)#ip time-out 30 (config)#ip ssh authentication-retires 2 (config-line)#transport input ssh Dòng đầu tiên giới hạn thời gian khi không được thực hiện trong bao nhiêu phút sẽ bị ngắt kết nối. Chúng ta có thể thiết lập thời gian đó ngắn hơn. Nhưng thiết lập phần này để yên tâm kết nối sẽ vẫn được đảm bảo trong thời gian đủ để giải lao. Dòng lệnh thứ hai giới hạn số lần cố gắng xác thực của người dùng. Dòng lệnh thứ ba sẽ làm việc với mode VTY, giới hạn các dạng kết nối và cổng VTY nào để nhận các thông tin. Và trong dòng lệnh này ý nhĩa là chỉ cho phép cổng VTY chỉ cho phép các phiên làm việc với SSH. Lưu ý chỉ sử dụng được SSH khi IOS của Router có khả năng mã hoá “encryption capable”. Router phải có khả năng về các quá trình truyền tin mã hoá dạng DES hay 3DES. Rất nhiều SSH client có khả năng mã hoá dữ liệu sử dụng các thuật toán mã hoá khác nhau. Nhưng Router của Cisco chỉ có thể mã hoá các phiên làm việc SSH sử dụng DES và 3DES. KẾT LUẬN Các ứng dụng sử dụng giao thức SSH hoạt động tốt và có tính bảo mật cao. Một ưu điểm khác nữa là hầu hết chúng đều miễn phí nên rất thuận tiện để có được một hệ thống bảo mật với SSH. Có rất nhiều các phần mềm client và server khác nhau đều hỗ trợ tốt cho các hệ điều hành hiện đang được sử dụng rộng rãi như Window, Linux, Macintosh. Tuy nhiên, SSH cũng còn khá mới mẻ đối với các hệ thống mạng ở Việt Nam, một phần là do vấn đề ngôn ngữ. Hơn nữa, tuy các ứng dụng SSH phần lớn là miễn phí nhưng chỉ là miễn phí với các bản client và một số bản server chạy trên nền Linux, còn các bản server chạy trên Window thì thường là bản thương mại nên cũng khó khăn khi muốn có một hệ thống mạng có ứng dụng bảo mật SSH trên nền Window vốn rất quen thuộc với mọi người từ lâu nay. Từ nhận xét đó, Tôi có ý tưởng sẽ nghiên cứu xây dựng một phần mềm Remote Login dựa trên giao thức SSH có giao diện bằng tiếng Việt và có thể chạy trên Window cả bản client lẫn bản server. Hi vọng sau khi nghiên cứu, xây dựng, sản phẩm sẽ có một phần đóng góp vào nghành công nghệ thông tin nước ta. Tài liệu tham khảo [1]OReilly.Network.Security.Hacks.eBook-DDU [2]OReilly.SSH.The.Secure.Shell.The.Definitive.Guide. 2nd.Edition.May.2005.eBook-DDU [3]OReilly.Network.Security.Tools.Apr.2005.eBook-LiB [4] Cryptography and Network Security [5]SCS : [6] Từ điển bách khoa toàn thư mở Wikipedia: [7] RFC 4254 [8] [9] [10]