เป็นไปได้ไหมที่จะป้องกัน SCP ในขณะที่ยังอนุญาตให้เข้าถึง SSH ได้

การใช้เซิร์ฟเวอร์ Solaris และ Linux และ OpenSSH เป็นไปได้หรือไม่ที่จะป้องกันไม่ให้ผู้ใช้คัดลอกไฟล์โดยใช้ "scp" ในขณะที่ยังอนุญาตให้เชลล์เข้าถึงด้วย "ssh"

ฉันรู้ว่าการเข้าถึงไฟล์ประเภท 'ssh $ server "cat file" นั้นยากกว่าการป้องกัน แต่ฉันต้องดูเกี่ยวกับการหยุด "scp" สำหรับ starters

หากไม่เป็นเช่นนั้นมีวิธีบันทึกการเข้าถึง SCP ทั้งหมดอย่างน่าเชื่อถือบนฝั่งเซิร์ฟเวอร์syslogหรือไม่?

ในขณะที่คุณสามารถแก้ไขของคุณ/etc/ssh/sshd_configให้มีลักษณะดังนี้:

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

ฉันจะพิจารณาว่าผู้ใช้มีแนวโน้มที่จะใช้แทน เพราะหากมีคำสั่งเพียงไม่กี่คำที่คุณต้องการให้พวกเขาเข้าถึงได้ฉันจะลบความสามารถออกเพื่อเรียกใช้sshเชลล์ปกติ

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

หากคุณพบว่าคุณจำเป็นต้องเรียกใช้กระสุนปกติจริง ๆ สิ่งที่คุณคาดหวังมากที่สุดคือการทำให้มันช้าลงและทำให้มันยากขึ้น

ดังที่คนอื่น ๆ สังเกตไว้คุณไม่สามารถบล็อก scp (ได้คุณทำได้: rm /usr/bin/scpแต่นั่นไม่ได้ทำให้คุณไปไหน)

วิธีที่ดีที่สุดที่คุณสามารถทำได้คือเปลี่ยนเชลล์ของผู้ใช้เป็นเชลล์ที่ จำกัด (rbash) จากนั้นเรียกใช้คำสั่งบางอย่างเท่านั้น

โปรดจำไว้ว่าหากพวกเขาสามารถอ่านไฟล์พวกเขาสามารถคัดลอก / วางออกจากหน้าจอ ไฟล์ไบนารีหรือไม่ xxd / uuencode / mmencode ทั้งหมดได้รับรอบนี้

ฉันขอแนะนำให้ใช้การบัญชีกระบวนการเพื่อช่วยคุณติดตามกิจกรรม

คุณไม่ได้รับอะไรเลยโดยการหยุด "scp" เมื่อคุณยังคงอนุญาตให้มีกลไกการถ่ายโอนไฟล์เพิ่มเติมที่ไม่สิ้นสุด ไม่อนุญาตให้ใช้ scp แต่ให้กลไกการคัดลอกไฟล์อื่น ๆ เป็นวิธีการโกหกต่อผู้ตรวจสอบบัญชี บ่อยครั้งที่ผู้ตรวจสอบขอให้โกหก ฉันมักจะเห็นผู้ตรวจสอบที่ทำงานกับผู้จัดการเพื่อทำการแก้ไขปลอมเพื่อให้พวกเขาสามารถระบุบางสิ่งเช่น "คำสั่งการถ่ายโอนไฟล์ scp ถูกปิดใช้งานเพื่อให้ไฟล์ไม่สามารถคัดลอกจากเซิร์ฟเวอร์โดยใช้ scp"

ตอนนี้กลไกการบันทึกที่เหมาะสมจะดี บางที auditd ทำงานได้บน Linux ในที่สุด บางทีในที่สุด Solaris อาจเพิ่มกลไกบางอย่างหรือ dtrace สามารถใช้ได้อย่างปลอดภัย มีเหตุผลที่ต้องการให้ระบบปฏิบัติการบันทึกทุกครั้งที่มีการเข้าถึงไฟล์ แน่นอนว่า "การอ่าน" และ "การคัดลอก" ไม่แตกต่างกัน แต่สิ่งนี้สามารถสร้างความพึงพอใจให้กับผู้สอบบัญชีและให้ความปลอดภัยกับระบบอย่างมีนัยสำคัญ บันทึกของคุณอาจมีเสียงดังว่าข้อมูลไม่มีประโยชน์หรือแม้กระทั่งว่าคุณถูกบังคับให้ติดตามตรวจสอบระยะสั้นอย่างน่าขัน (เช่นคุณไม่สามารถบันทึกการอ่านทุกครั้ง () - และแอปพลิเคชันหนึ่งที่ทำสิ่งที่น่าแปลกใจสามารถทำการบันทึกทุกครั้งที่เปิด () ความเสียหาย)

ขึ้นอยู่กับสิ่งที่ SSH ต้องการสำหรับคุณอาจจะสามารถบรรลุเป้าหมายนี้ (สำหรับคนที่ไม่สำคัญ) โดยใช้ IPTables เพื่อยุติเซสชันหากขนาดของแพ็คเก็ตใหญ่กว่านั้นควรบอกว่า 1,400 ไบต์ ซึ่งหมายความว่า ssh แบบอินเทอร์แอคทีฟส่วนใหญ่จะทำงานได้ แต่ทันทีที่บางสิ่งบางอย่างพยายามส่งแพ็กเก็ต 1500 ไบต์ - เช่นเดียวกับ scp ควรสำหรับไฟล์ที่มีขนาดใหญ่กว่านั้น 1,499 ไบต์จะถือว่า MTU มาตรฐานที่ 1500 จะยุติการเชื่อมต่อ

วิธีนี้จะป้องกันการ "โจมตี" ที่คุณกล่าวถึง

น่าเสียดายที่นี่หมายความว่าคุณอาจมีปัญหาในการแก้ไขไฟล์ด้วยตัวแก้ไขข้อความหากหน้าจอต้องการวาดมากกว่า 1400 ตัวอักษรหรือหากคุณต้องการใช้ไฟล์ขนาดยาวหรือทำรายชื่อไดเรกตอรีแบบยาว

ในกรณีที่ง่ายที่สุดคำสั่งให้ทำเช่นนี้อาจมีลักษณะคล้าย

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

เราสามารถทำให้การทำงานนี้ดีขึ้นโดยการรวมการตรวจสอบความยาวของแพ็กเก็ตกับ ipt_recent ดังนั้นคุณจึงอนุญาตให้มีจำนวนแพ็คเก็ตที่ใหญ่กว่านั้น จำกัด 1,400 ไบต์ภายในระยะเวลาที่กำหนด (8 แพ็คเก็ตต่อ 5 วินาที) - ผ่าน แต่อาจให้การโต้ตอบที่คุณต้องการสำหรับการแก้ไขไฟล์ ฯลฯ แน่นอนว่าคุณสามารถปรับแต่งจำนวนของแพ็คเก็ตได้

นี่อาจดูเหมือนอะไร

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

ตัวอย่างกฎด้านบนป้องกันการอัปโหลด scp เช่นscp myfile.data remote.host:~เท่านั้น นอกจากนี้การป้องกันการดาวน์โหลด SCP เช่นscp remote.host:~/myfile.data /local/pathทำซ้ำกฎดังกล่าวข้างต้น แต่แทนที่ด้วย--dport--sport

แฮ็กเกอร์ที่ฉลาดแกมโกงสามารถแก้ไขข้อ จำกัด เหล่านี้ได้โดยตั้งค่า MTU ให้ต่ำกว่า 1,400 หน่วยในเครื่องของเขา (หรือบังคับให้ mtu หรือคล้ายกัน) นอกจากนี้ในขณะที่คุณไม่สามารถ จำกัด สิ่งนี้ให้กับผู้ใช้บางคนคุณสามารถ จำกัด โดยใช้ IP โดยการแก้ไขบรรทัด iptables ตามความเหมาะสม !!

ไชโยเดวิดโก

ทางออกที่ดีที่สุดของคุณคือไม่ต้องล็อค scp แต่ใช้ระบบไฟล์ที่มี ACL เพื่อป้องกันการเข้าถึงการอ่าน คุณอาจทำอะไรกับ SELinux เพื่อป้องกันไม่ให้แอปพลิเคชันอ่านไฟล์บางไฟล์ได้

ไม่ scpและsshทำงานบนพอร์ตเดียวกันและใช้โปรโตคอลเดียวกัน ถ้าคุณเปิดsshเซสชั่นคุณยังสามารถแชร์การเชื่อมต่อของคุณกับโทร SCP ControlMasterภายหลังโดยใช้ตัวเลือกเช่น

หากคุณไม่ต้องการให้ผู้อื่นคัดลอกไฟล์บางไฟล์ออกจากเครื่องคุณไม่ควรให้สิทธิ์การเข้าถึงแบบเชลล์กับเครื่อง

มีวิธีใช้ 'scponly' เป็นเชลล์เพื่อปิดการใช้งาน ssh แบบอินเทอร์แอคทีฟและอนุญาตให้ใช้ scp แต่ฉันไม่ทราบถึงสิ่งที่มีอยู่ที่ทำงานในลักษณะย้อนกลับ

คุณอาจสำรวจแฮ็คเชลล์ scponly เพื่อทำสิ่งที่ตรงกันข้ามให้สำเร็จ

เรื่องนี้เป็นไปไม่ได้จริง ๆ หลังจากใช้เวลาทำ Google

ตรวจสอบการสนทนานี้: http://www.mydatabaseupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-sc--pfts.html

สำหรับสิ่งที่เป็นมูลค่าการค้าสินค้าCryptoAuditorการเรียกร้องเพื่อให้สามารถควบคุมการถ่ายโอนไฟล์ผ่าน SSH โดยMITMไอเอ็นจีในการเชื่อมต่อและการใช้ลึกแพ็คเก็ตการตรวจสอบ เห็นได้ชัดว่าไม่มีวิธีแก้ปัญหาปลอดภัยจากการคัดลอก + วาง uuencode / ถอดรหัสปลาฯลฯ สิ่งที่ดีคือมันโปร่งใส (นอกเหนือจากข้อผิดพลาดใบรับรองที่น่าจะเป็น) ไม่มีซอฟต์แวร์ตัวแทนที่จะติดตั้งที่ปลายทั้งสองด้านของการเชื่อมต่อ SSH และไม่มีพอร์ทัล / พร็อกซีที่จะกำหนดค่า

ฉันไม่ได้ใช้ผลิตภัณฑ์ดังนั้น YMMV

การบล็อกการถ่ายโอนไฟล์โดยไม่ลบยูทิลิตีของระบบมากมายจนทำให้เครื่องไม่มีประโยชน์อย่างสมบูรณ์เป็นไปไม่ได้ คุณต้องกำจัดทุกสิ่งที่สามารถแสดงเนื้อหาไฟล์ไปยัง stdout และทุกอย่างที่สามารถเขียน stdin ไปยัง stdout และเมื่อคุณลบเนื้อหาทั้งหมดที่เหลืออยู่เพียงเล็กน้อยซึ่งไม่มีจุดอนุญาตให้เข้าถึงเชลล์ได้ เลย

ดังนั้นฉันจะมุ่งเน้นไปที่ทางเลือกการบันทึกของคุณแทน:

มีโปรแกรมที่เรียกว่า "สคริปต์" ซึ่งรวมอยู่ใน distro ทุกอันและควรติดตั้งได้ง่ายในที่ที่ไม่มี เป็นตัวบันทึกเซสชันที่บันทึกอินพุตและเอาต์พุตทั้งหมดจากเชลล์หรือเลือกที่จะใช้ข้อมูลเวลาเพื่อให้สามารถเล่นซ้ำได้และดูเหมือนว่าคุณกำลังดูไหล่ของผู้ใช้เมื่อพวกเขาทำ (95% ต่อไปมันเป็นบางครั้งทำให้ยุ่งเหยิงเอาท์พุทเมื่อ ncurses มีส่วนเกี่ยวข้อง แต่ไม่บ่อยมาก)

หน้า man ประกอบด้วยคำแนะนำในการตั้งค่าเป็น login shell ของระบบ ตรวจสอบให้แน่ใจว่าบันทึกไปที่ใดที่ผู้ใช้ไม่สามารถลบออกได้ (แอตทริบิวต์ของระบบไฟล์ผนวกเท่านั้น (ที่สามารถตั้งค่าผ่าน chattr) จะมีประโยชน์สำหรับสิ่งนี้เช่นเดียวกับ ACLs หรือสคริปต์ที่ไม่ระบุสคริปต์)

สิ่งนี้ยังไม่ได้ป้องกันผู้ใช้จากการคัดลอกไฟล์ออกจากระบบ แต่จะช่วยให้คุณตรวจสอบสิ่งที่ผู้ใช้และเมื่อทำ อาจเป็นไปไม่ได้ที่จะข้ามไป แต่บายพาสเกือบจะจบลงด้วยการบันทึกดังนั้นอย่างน้อยคุณก็รู้ว่ามีบางคนไม่ดีแม้ว่าพวกเขาจะซ่อนตัวได้อย่างแม่นยำ

ฉันเชื่อว่าคุณสามารถถอนการติดตั้ง openssh-clients (หรือเทียบเท่า) บนเซิร์ฟเวอร์

ฉันคิดว่าไคลเอนต์ scp จะเรียกใช้ scp บนเซิร์ฟเวอร์เมื่อคัดลอกข้อมูลไปดังนั้นถ้าคุณกำจัด scp บนเซิร์ฟเวอร์คุณควรจะปรับ

$ 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