Git ทำการตรวจสอบ


16

ฉันมีเซิร์ฟเวอร์คอมไพล์ที่ทำงานบน ssh และผู้ใช้แต่ละคนมีบัญชี unix ในระบบ

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

ฉันกังวลว่าผู้ใช้อาจพยายามปลอมตัวเป็นผู้อื่นแม้ว่าพวกเขาจะมีสิทธิ์การอนุญาตเดียวกัน


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

อาจเป็นได้ทั้ง การตั้งค่าปัจจุบันเป็นสิ่งที่อธิบายไว้ในคำถาม (หนึ่งบัญชีผู้ใช้ ssh ต่อผู้ใช้) แต่มันไม่ได้ปรับขนาดได้ดีและฉันอาจต้องการใช้ผู้ใช้คนเดียว / หลายปุ่มในอนาคต ฉันแค่มองหาทางออกที่หลากหลายที่สุดที่จะไม่ล็อคฉันเป็นวิธีการตรวจสอบอย่างใดอย่างหนึ่ง
yannisf

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

คำตอบ:


13

หากคุณกังวลเกี่ยวกับเรื่องนี้คุณสามารถแก้ไขปัญหาได้สองวิธี

  1. ทำให้ผู้ใช้ของคุณเซ็นสัญญาของคุณสนับสนุน GPG
  2. อย่าให้สิทธิ์แก่ผู้ใช้ในการส่งไปยังแหล่งเก็บข้อมูลหลักให้ผู้ใช้ส่งไปยังที่เก็บย่อยของตนเองจากนั้นให้ผู้ใช้ที่เชื่อถือได้นำการเปลี่ยนแปลงมาไว้ในพื้นที่เก็บข้อมูลหลัก นั่นเป็นเหตุผลที่ถ้าคุณดูข้อความบันทึกสำหรับโครงการคอมไพล์บางตัว (เช่นคอมไพล์เอง) คุณจะเห็นว่าเป็นฟิลด์ที่แยกจากกันสำหรับ "ผู้แต่ง" - บุคคลที่สร้างการเปลี่ยนแปลง และ "Committer" - บุคคลที่ทำการยอมรับการเปลี่ยนแปลงในที่เก็บ

1. ข้อเสนอแนะนี้ดูเหมือนจะเหมาะที่สุดสำหรับวัตถุประสงค์ของฉัน ยังมีกลไกที่จะปฏิเสธการกระทำที่ไม่ได้ลงนามในฝั่งเซิร์ฟเวอร์หรือไม่? 2. เท่าที่โซลูชันนี้เกี่ยวข้องผู้ใช้ที่ดึงจาก repo รองจะต้องตรวจสอบอีกครั้งว่าผู้ใช้ไม่ได้ใช้ชื่อผู้ใช้ / อีเมลปลอมแปลง จริงหรือไม่?
yannisf

ระวังแม้ว่าคุณสามารถลงนามผูกพันกับ committer และตัวตนของผู้แต่งที่คุณต้องการเลือก เห็นได้ชัดว่าคุณจะสามารถดูได้ว่าใครเป็นคนปลอม (หรือไม่ดูแลคีย์ส่วนตัวของพวกเขา)
CB Bailey

ดังนั้นข้อแม้ของฉันเกี่ยวกับการมีผู้ใช้ที่เชื่อถือได้กระทำกับที่เก็บหลัก
Abizern

@Abizern: ยุติธรรมเพียงพอ ขณะที่ฉันอ่านมัน (1) และ (2) ของคุณดูเหมือนจะอธิบายตัวเลือกอื่น ๆ
CB Bailey

1
@yannisf เกี่ยวกับคำถามแรกของคุณhook update (run ฝั่งเซิร์ฟเวอร์) อาจตรวจสอบลายเซ็นและมิฉะนั้นปฏิเสธการอัพเดท refs ที่เกี่ยวข้อง ลองดูที่.git/hooks/update.sampleแรงบันดาลใจ กรุณา @ แจ้งให้ฉันทราบหากคุณถามคำถามเกี่ยวกับเรื่องนี้ที่ SO มันจะเป็นที่น่าสนใจสำหรับฉันเช่นกัน
Tobias Kienzler

9

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

การแก้ไข sshd

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

#LogLevel INFO

และเปลี่ยนสิ่งนั้นเป็น

LogLevel VERBOSE

จากนั้นเริ่มบริการ sshd ใหม่ สิ่งนี้จะเพิ่มระดับการบันทึกของ sshd ทีละขั้นตอนซึ่งให้ข้อมูลเพิ่มเติมจำนวนมาก ลองดูตัวอย่างบันทึกการเข้าถึงระยะไกลของฉันหลังจากทำการเปลี่ยนแปลงนั้น

Nov  2 08:37:09 node1 sshd[4859]: Connection from 10.10.10.5 port 50445
Nov  2 08:37:10 node1 sshd[4859]: Found matching RSA key: f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06
Nov  2 08:37:10 node1 sshd[4860]: Postponed publickey for scott from 10.10.10.5 port 50445 ssh2
Nov  2 08:37:10 node1 sshd[4859]: Found matching RSA key: f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06
Nov  2 08:37:10 node1 sshd[4859]: Accepted publickey for scott from 10.10.10.5 port 50445 ssh2
Nov  2 08:37:10 node1 sshd[4859]: pam_unix(sshd:session): session opened for user scott by (uid=0)
Nov  2 08:37:10 node1 sshd[4859]: User child is on pid 4862
Nov  2 08:40:27 node1 sshd[4862]: Connection closed by 10.10.10.5
Nov  2 08:40:27 node1 sshd[4862]: Transferred: sent 30632, received 7024 bytes
Nov  2 08:40:27 node1 sshd[4862]: Closing connection to 10.10.10.5 port 50445
Nov  2 08:40:27 node1 sshd[4859]: pam_unix(sshd:session): session closed for user scott 

สิ่งสำคัญที่ควรสังเกตคือสองเท่า

  1. เราเห็นลายนิ้วมือของกุญแจสาธารณะที่ใช้ตรวจสอบฉัน
  2. เราเห็นเวลาประทับของการออกจากระบบของฉัน

การใช้ LogLevel เริ่มต้น (INFO) sshd จะไม่บันทึกรายการเหล่านั้น การรับลายนิ้วมือของกุญแจเป็นอีกขั้นตอนเดียว คุณต้องประมวลผลauthorized_keysไฟล์ที่เหมาะสมด้วย ssh-keygen เช่นนี้

[root@node1 ssh]# ssh-keygen -l -f /home/scott/.ssh/authorized_keys
4096 f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06 /home/scott/.ssh/authorized_keys (RSA)

ดังนั้นตอนนี้คุณรู้ข้อมูลชิ้นต่อไปนี้แล้ว:

  1. ชื่อผู้ใช้ที่เข้าสู่ระบบ
  2. เวลาที่ผู้ใช้เข้าสู่ระบบ
  3. คีย์สาธารณะใดที่ใช้สำหรับการตรวจสอบสิทธิ์
  4. เวลาที่ผู้ใช้ออกจากระบบ

ตอนนี้เรามีวิธีการแอ็ตทริบิวต์การกระทำของผู้ใช้ในเวลาที่กำหนดสมมติว่าผู้ใช้ทั้งสองไม่ได้เข้าสู่ระบบในเวลาเดียวกันเราสามารถเริ่มดูการเปลี่ยนแปลงที่เกิดขึ้นกับที่เก็บ

การตรวจสอบไดเรกทอรีด้วย Auditd

ดังที่ sysadmin1138 กล่าวว่านี่อาจเป็นกรณีการใช้งานที่ยอดเยี่ยมสำหรับระบบย่อย auditd หากคุณไม่ได้ใช้ distro ที่ใช้ RedHat อาจเป็นอะนาล็อก แต่คุณต้องค้นหามัน การกำหนดค่าสำหรับ auditd ค่อนข้างเข้มข้นและมีตัวเลือกการกำหนดค่าจำนวนมาก ได้รับความคิดของบางส่วนของตัวเลือก, กรุณาตรวจสอบนี้คำถามเกี่ยวกับน้องสาวของเราเว็บไซต์สำหรับผู้เชี่ยวชาญด้านความมั่นคงปลอดภัยสารสนเทศ

ฉันขอแนะนำให้ตั้งค่าสิ่งที่เรียกว่า "watch" ในไดเรกทอรีบนดิสก์ที่มีที่เก็บ git ของคุณ สิ่งนี้จะเป็นการแนะนำให้โมดูลเคอร์เนลรายงานความพยายามในการเรียกใช้การเข้าถึงไฟล์เช่นopen()หรือcreat()บนตัวจัดการไฟล์ที่ชี้ไปยังไฟล์หรือไดเรกทอรีที่เราแสดงรายการ

นี่คือตัวอย่างการกำหนดค่าที่จะทำเช่นนี้และเฉพาะที่นี่ ดังนั้นควรระมัดระวังในการอ่านและทำความเข้าใจกับสิ่งที่มีอยู่ของคุณ/etc/audit/audit.rulesเพื่อรวมการเปลี่ยนแปลงอย่างเหมาะสม

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 1024

-w /path/to/git/repos-p wa

# Disable adding any additional rules - note that adding *new* rules will require a reboot
-e 2

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

2
ดีที่คุณไม่ถามบนเว็บไซต์ระบบการบริหารและผมเป็นผู้ตรวจสอบนิติ .... :)
สกอตต์แพ็ค

5

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

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

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

ในบางจุดคุณต้องเชื่อใจนักพัฒนาของคุณ


3

ssh daemons จำนวนมากสร้างรายการ/var/log/audit.logหรือสิ่งที่คล้ายกันเมื่อได้รับการเชื่อมต่อ ssh การอ้างอิงโยงกับบันทึกนี้ด้วยการบันทึกการเข้าใช้งานควรให้แนวคิดแก่คุณเกี่ยวกับการใช้ ssh-user ในการออกคำสั่ง นี่เป็นขั้นตอนการตรวจสอบที่จะใช้หลังจากข้อเท็จจริงในการตรวจสอบ

การบังคับใช้ ssh-user ที่ถูกต้องให้กับผู้ใช้ git ที่เหมาะสมนั้นเป็นคำตอบอย่างหนึ่งของที่นี่


ยังคงมีการตั้งค่าที่ผู้ใช้เข้าสู่ระบบด้วยผู้ใช้ ssh เดียวกัน แต่ใช้คีย์ (อนุญาต) ที่แตกต่างกัน ทำให้การตรวจสอบทำได้ยากขึ้น
yannisf

@yannisf: ถูกต้องมันเปลี่ยนสิ่งเล็กน้อย ด้วยความโชคดีฉันช่วยตอบสนองความต้องการพิเศษของคุณในการจัดการกับการเข้าถึงบัญชีที่ไม่เกี่ยวข้อง
Scott Pack

0

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.