Có thể ngăn SCP trong khi vẫn cho phép truy cập SSH không?

Sử dụng máy chủ Solaris và Linux và OpenSSH, có thể ngăn người dùng sao chép tệp bằng "scp" trong khi vẫn cho phép truy cập shell bằng "ssh" không?

Tôi nhận ra rằng việc truy cập tệp kiểu "ssh $ server" cat file khó hơn rất nhiều để ngăn chặn, nhưng tôi cần xem về việc dừng "scp" cho người mới bắt đầu.

Không, có cách nào đáng tin cậy để đăng nhập tất cả quyền truy cập SCP ở phía máy chủ syslogkhông?

Trong khi bạn có thể chỉnh sửa /etc/ssh/sshd_configđể trông giống như thế này:

ForceCommand           /bin/sh
PermitOpen             0.0.0.0
AllowTcpForwarding     no
PermitTunnel           no
# Subsystem sftp       /usr/lib/openssh/sftp-server
PermitUserEnvironment  no

Thay vào đó tôi sẽ xác định những gì người dùng có khả năng sử dụng nó cho. Bởi vì nếu chỉ có một vài lệnh mà bạn muốn chúng có quyền truy cập, thay vào đó tôi sẽ loại bỏ khả năng chúng thậm chí gọi một sshshell thông thường .

AllowUsers             root
PermitRootLogin        forced-commands-only

PermitUserEnvironment  no

AllowTcpForwarding     no
PermitTunnel           no

# Subsystem sftp       /usr/lib/openssh/sftp-server
Subsystem smb-reload   /usr/bin/smbcontrol smbd reload-config
Subsystem status       /opt/local/bin/status.sh

ssh root@example -s smb-reload

Nếu bạn thấy rằng bạn thực sự cần phải có khả năng chạy một chiếc vỏ bình thường, điều bạn thực sự có thể hy vọng nhất là làm chậm chúng và làm cho nó trở nên khó khăn hơn.

Như những người khác đã lưu ý, bạn không thể chặn scp (tốt, bạn có thể : rm /usr/bin/scp, nhưng điều đó không thực sự đưa bạn đến bất cứ đâu).

Điều tốt nhất bạn có thể làm là thay đổi shell của người dùng thành shell bị hạn chế (rbash) và chỉ sau đó mới chạy một số lệnh nhất định.

Hãy nhớ rằng, nếu họ có thể đọc tệp, họ có thể sao chép / dán chúng khỏi màn hình. Tệp nhị phân? xxd / uuencode / mmencode đều xoay quanh vấn đề này.

Tôi cũng đề nghị sử dụng kế toán quy trình để giúp bạn theo dõi hoạt động.

Bạn không đạt được gì khi dừng "scp" khi bạn vẫn cho phép các cơ chế truyền tệp bổ sung vô hạn theo nghĩa đen. Không cho phép scp nhưng cho phép các cơ chế sao chép tệp khác là một phương pháp nói dối với kiểm toán viên. Kiểm toán viên thường yêu cầu được nói dối. Thông thường tôi thấy các kiểm toán viên làm việc với các nhà quản lý để thực hiện các sửa lỗi giả, để họ có thể nói điều gì đó như "lệnh chuyển tập tin scp đã bị vô hiệu hóa, do đó không thể sao chép các tập tin từ máy chủ bằng scp".

Bây giờ một cơ chế đăng nhập hợp lý sẽ được tốt đẹp. Có lẽ Audd cuối cùng cũng hoạt động trên Linux. Có lẽ Solaris cuối cùng đã thêm một số cơ chế hoặc dtrace có thể được sử dụng một cách an toàn. Thật hợp lý khi muốn HĐH đăng nhập mỗi khi tệp được truy cập. Tất nhiên không có sự khác biệt giữa "đọc" và "sao chép". Nhưng điều này có thể làm hài lòng một kiểm toán viên và cung cấp bảo mật đáng kể cho hệ thống. Nhật ký của bạn có thể ồn ào đến mức dữ liệu là vô ích hoặc thậm chí bạn buộc phải giữ một dấu vết kiểm toán ngắn một cách lố bịch. (ví dụ: bạn không thể ghi nhật ký mọi lần đọc () - và một ứng dụng làm điều gì đó đáng ngạc nhiên có thể khiến việc đăng nhập mỗi lần mở () trở thành thảm họa).

Tùy thuộc vào những gì SSH cần cho, bạn có thể đạt được mục tiêu này (đối với các tệp không tầm thường) bằng cách sử dụng IPTables để chấm dứt các phiên nếu kích thước gói lớn hơn, ví dụ 1400 byte. Điều này có nghĩa là ssh tương tác sẽ hoạt động chủ yếu, nhưng ngay khi có thứ gì đó cố gửi gói 1500 byte - giống như scp đối với tệp lớn hơn 1499 byte giả sử MTU chuẩn là 1500, nó sẽ chấm dứt kết nối.

Điều này cũng sẽ ngăn chặn cuộc tấn công "catter" mà bạn đề cập.

Thật không may, điều này có nghĩa là bạn có thể gặp sự cố khi chỉnh sửa một số tệp bằng trình soạn thảo văn bản, nếu màn hình cần vẽ nhiều hơn 1400 ký tự hoặc nếu bạn cần gửi một tệp dài hoặc liệt kê một thư mục dài.

Trong trường hợp đơn giản nhất, một lệnh để làm điều này có thể trông giống như

iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff -j DROP

Chúng tôi có thể làm cho công việc này tốt hơn bằng cách kết hợp kiểm tra độ dài gói với ipt_recent, để bạn cho phép số lượng gói hạn chế lớn hơn 1400 byte trong một khung thời gian đã đặt (giả sử 8 gói trên 5 giây) - điều này sẽ cho phép các gói lên đến 12k bị trượt thông qua, nhưng có thể cung cấp cho bạn khả năng tương tác mà bạn sẽ cần để chỉnh sửa các tệp, v.v ... Tất nhiên, bạn có thể điều chỉnh số lượng gói.

Cái này có thể trông giống như

iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
         -m recent --name noscp --rdest --set 
iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
         -m recent --name noscp --rdest --update --seconds 5 --hitcount 8 \
         -j REJECT --reject-with tcp-reset

Các ví dụ quy tắc ở trên chỉ bảo vệ chống lại tải lên scp như scp myfile.data remote.host:~. Để bảo vệ chống lại tải xuống scp, chẳng hạn như scp remote.host:~/myfile.data /local/path, lặp lại các quy tắc trên nhưng thay thế --dportbằng --sport.

Một hacker thông minh có thể khắc phục những hạn chế này bằng cách đặt MTU dưới 1400 trên máy của anh ta (hoặc buộc mtu hoặc tương tự). Ngoài ra, trong khi bạn không thể giới hạn điều này với một số người dùng nhất định, bạn có thể giới hạn nó bằng IP bằng cách sửa đổi các dòng iptables cho phù hợp !!

Chúc mừng, David Go

Đặt cược tốt nhất của bạn không phải là khóa scp, mà là sử dụng hệ thống tệp có ACL để ngăn truy cập đọc. Bạn có thể có thể làm một cái gì đó với SELinux để ngăn các ứng dụng nhất định đọc từ các tệp nhất định.

Số scpvà sshhoạt động trên cùng một cổng và sử dụng cùng một giao thức. Nếu bạn mở một sshphiên, bạn thậm chí có thể chia sẻ kết nối của mình với các cuộc gọi scp tiếp theo bằng các tùy chọn như ControlMaster.

Nếu bạn không muốn mọi người sao chép các tệp cụ thể ra khỏi máy, bạn không nên cấp cho họ bất kỳ loại quyền truy cập vỏ nào vào máy.

Có một cách để sử dụng 'scponly' làm vỏ để vô hiệu hóa ssh tương tác và cho phép scp, nhưng tôi không biết bất cứ điều gì hiện có hoạt động theo cách ngược lại.

Bạn có thể khám phá việc hack vỏ sò để thực hiện điều ngược lại.

Điều này là không thể thực sự sau một chút googling.

Kiểm tra cuộc thảo luận này: http://www.mydatabaseupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-scp-sftp.html

Đối với giá trị của nó, sản phẩm thương mại CryptoAuditor tuyên bố có thể kiểm soát chuyển tập tin qua SSH, bằng cách MITM kết nối và sử dụng kiểm tra gói sâu . Rõ ràng không có giải pháp nào an toàn từ sao chép + dán, uuencode / giải mã, FISH , v.v. Điều hay ho là nó minh bạch (ngoài các lỗi chứng chỉ có thể xảy ra); không có phần mềm đại lý nào để cài đặt ở hai đầu kết nối SSH và không có cổng / proxy để định cấu hình.

Tôi đã không sử dụng sản phẩm, vì vậy YMMV.

Chặn chuyển tập tin mà không loại bỏ rất nhiều tiện ích hệ thống để rời khỏi máy hoàn toàn vô dụng là không thể. Bạn sẽ phải loại bỏ mọi thứ có khả năng hiển thị nội dung tệp thành thiết bị xuất chuẩn và mọi thứ có khả năng viết stdin của nó thành thiết bị xuất chuẩn, và đến lúc bạn loại bỏ tất cả những thứ còn lại thì không còn khả năng cho phép truy cập shell ở tất cả.

Vì vậy, tôi sẽ tập trung vào thay thế đăng nhập của bạn thay vào đó:

Có một chương trình gọi là "tập lệnh" thực tế được bao gồm trong tất cả các bản phân phối và dễ cài đặt trên các chương trình không có. Đó là một trình ghi nhật ký phiên ghi lại tất cả đầu vào và đầu ra từ một vỏ, tùy ý với dữ liệu thời gian để nó có thể được phát lại và trông giống như bạn đang xem qua vai người dùng khi họ thực hiện. (Dù sao đi nữa, 95%, đôi khi nó làm đảo lộn đầu ra khi có liên quan, nhưng không thường xuyên lắm.)

Trang hướng dẫn của nó bao gồm các hướng dẫn để thiết lập nó làm vỏ đăng nhập của hệ thống. Hãy chắc chắn rằng các bản ghi đi đâu đó mà người dùng không thể xóa chúng (thuộc tính hệ thống tập tin chỉ phụ thuộc (có thể giải quyết qua chattr) có thể hữu ích cho việc này. Cũng như ACL hoặc inotify script)

Điều này vẫn không ngăn người dùng sao chép các tệp ra khỏi hệ thống, nhưng nó cho phép bạn xem lại những gì đã được thực hiện bởi người dùng nào và khi nào. Có lẽ không thể bỏ qua, nhưng đường vòng gần như chắc chắn sẽ kết thúc trong nhật ký để bạn ít nhất biết rằng ai đó sẽ không tốt, ngay cả khi họ có thể che giấu chính xác nó là gì.

Tôi tin rằng bạn có thể gỡ cài đặt openssh-client (hoặc tương đương) trên máy chủ.

Tôi nghĩ rằng máy khách scp gọi scp trên máy chủ khi sao chép dữ liệu vì vậy nếu bạn thoát khỏi scp trên máy chủ, thì bạn sẽ ổn thôi.

$ scp bla server:/tmp/
...
debug1: Sending environment.
debug1: Sending env LC_ALL = en_US.utf8
debug1: Sending env LANG = en_US.utf8
debug1: Sending env XMODIFIERS = @im=ibus
debug1: Sending env LANGUAGE = en_US.utf8
debug1: Sending command: scp -v -t /tmp/
bash: scp: command not found
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
lost connection