แพคเกจที่เก็บข้อมูลของ linux distro ปลอดภัยหรือไม่?

14

ฉันรู้ว่า distro ส่วนใหญ่มีฟังก์ชั่นที่เก็บบางชนิดซึ่งสามารถดาวน์โหลดแพคเกจใหม่หลังการติดตั้ง Distros ใดที่ทำสิ่งนี้ในวิธีที่ปลอดภัยและซึ่งไม่ได้ทำในลักษณะที่ปลอดภัย

ฉันกำลังคิดเกี่ยวกับเวกเตอร์ของการโจมตีอย่างเช่นคนที่อยู่ตรงกลางและมีปัญหาเช่นการละเมิดความปลอดภัยบนทั้งเซิร์ฟเวอร์เมตาเซิร์ฟเวอร์ที่เก็บข้อมูลและไฟล์ที่เก็บมิเรอร์

ฉันได้ยินมาว่าทั้ง Slackware และ Arch linux มีช่องโหว่มากเพราะขาดการลงนามในแพ็คเกจ มันเป็นเรื่องจริงเหรอ? มีลินุกซ์รายใหญ่รายอื่น ๆ ที่มีช่องโหว่สำหรับการโจมตีแบบคนกลางหรือไม่?

security distros repository

— ค่าการกลั่น
แหล่งที่มา

หากเว็บไซต์ของ distro เป็น cleartext http หรือ ftp และ distro นั้นได้รับเป็น iso จากการเชื่อมต่อนี้และการเชื่อมต่อฐานนี้คือ MITM'ed กว่าการลงนามแพคเกจ 'post-mortem' ในแพคเกจโปรแกรมปรับปรุงที่ดีมากแค่ไหน?

— n611x007

7

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

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

สิ่งนี้ไม่ได้หยุดแพ็คเกจที่ถูกบุกรุกไม่ให้เข้าไปในพื้นที่เก็บข้อมูลของ distro แต่ distros ส่วนใหญ่มีวิธีอื่นในการบรรเทาปัญหานั้นและแม้แต่แพ็คเกจที่ลงนามแล้วก็ไม่รับประกันว่าจะไม่มีปัญหา สิ่งที่จะทำคือยับยั้งเวกเตอร์การโจมตีแบบ Man-in-the-middle เป้าหมาย ด้วยการใช้แหล่งข้อมูลแยกต่างหากและการดาวน์โหลดในช่องสัญญาณที่แยกต่างหากคุณจะสามารถฆ่าแพคเกจที่ถูกบุกรุกได้อย่างง่ายดาย

— คาเลบ
แหล่งที่มา

1

มีแพ็คเกจสำหรับ Arch ที่เรียกpaccheckว่าทำสิ่งนี้เปรียบเทียบแพ็คเกจกับมิรเรอร์ต่าง ๆ ก่อนการติดตั้งและเตือนถึงความแตกต่าง

— Wolf

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

— n611x007

10

แพ็กเกจ Debian ได้รับการตรวจสอบและ checksums จะถูกลงนามโดยคีย์ใน Debian keyring aptผู้จัดการแพคเกจเพื่อให้แน่ใจว่าแพคเกจที่ดาวน์โหลดมามีการตรวจสอบที่ถูกต้องและตรวจสอบว่าไฟล์ได้ลงนามอย่างถูกต้อง

— jmtd
แหล่งที่มา

5

แพ็คเกจ Fedora ได้รับการลงนามและตรวจสอบแล้ว แม้แต่ที่เก็บของบุคคลที่สามเช่นrpmfusion ก็ลงนามในแพ็คเกจของพวกเขา

Yum (ผู้จัดการแพ็คเกจ) ต้องการแฟล็กพิเศษ ( --nogpgcheck) เพื่อติดตั้งแพ็คเกจที่ยังไม่ได้ลงชื่อ

— Kanak
แหล่งที่มา

และแพคเกจ downsteam ก็เช่น Red Hat และ CentOS

— fpmurphy

3

แพ็คเกจ Arch Linux ทั้งหมดใช้ผลรวม md5 หรือ sha1 เพื่อตรวจสอบว่าบิตทั้งหมดอยู่ในตำแหน่ง มันขึ้นอยู่กับผู้ดูแลแพ็คเกจเพื่อเลือกอัลกอริทึมการแปลงแป้นพิมพ์ แพ็คเกจที่ติดตั้งจาก AUR (มักเป็นไฟล์ข้อความ PKGBUILD ขนาดเล็ก) ควรได้รับการตรวจสอบโดย installee ก่อนที่จะถูกติดตั้ง ที่เก็บที่มีแพ็กเกจไบนารีอย่างเป็นทางการจะถูกควบคุมโดยผู้ใช้ที่เชื่อถือได้ (TUs)

อัปเดต : Arch ได้แนะนำแพคเกจการเซ็นชื่อด้วย Pacman 4

— อเล็กซานเด
แหล่งที่มา

2

จริงทั้งหมด แต่แพคเกจไม่ได้ลงนามดังนั้นจึงยังคงเสี่ยงต่อการถูกโจมตีแบบ mitm และ mirror อย่างไรก็ตามความเป็นไปได้จากระยะไกล มันเป็นคุณสมบัติที่ขอมานานและเหตุผลหลักที่ทำให้ฉันหยุดการใช้ Arch อย่างไม่เต็มใจ ที่กล่าวว่ามีการอภิปรายอย่างต่อเนื่องเกี่ยวกับเรื่องนี้ในฟอรัม Arch และ Pacman และวิกิ - เป็นปัญหายากที่จะแก้ไข นอกเหนือจากปัญหานี้ Arch ยังเป็นเครื่องกลั่นที่ยอดเยี่ยม

— Eli Heady

@Eli: ฉันไม่ได้อภิปรายความจริงเกี่ยวกับเรื่องนี้ - ฉันไม่มีความคิดเกี่ยวกับสถานการณ์ของประเทศ - แต่มันจะไม่เป็นตลาดที่บางเฉียบที่จะโจมตี จริงอยู่ที่ Arch เป็นผู้ที่ได้รับความนิยมมาก แต่ความชั่วร้ายเหล่านี้ไม่ได้บอกกล่าวล่วงหน้าเลยว่าสามารถทำให้เจ้าชู้ได้หรือไม่?

— boehj

1

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

— Eli Heady

คุณสามารถติดตั้ง Arch จาก CD / DVD และจากนั้นเพียงตรวจสอบให้แน่ใจว่าผลรวม md5 / sha1 ของแพคเกจไบนารีสอดคล้องกับผลรวมจากหลายมิเรอร์ก่อนการติดตั้งคล้ายกับสิ่งที่ Caleb แนะนำ ไม่เคยมีความปลอดภัย 100% ในทุกกรณีแม้ว่าฉันจะเห็นจุดของการลงนามในแพคเกจและหวังว่า Arch จะได้รับมัน

— Alexander

ดังนั้นวิธีการที่จะประสบความสำเร็จในการตรวจสอบการส่งมอบในวิธีที่ปลอดภัยที่ cleartext http หรือ ftp? การตรวจสอบลายเซ็นควรจะอยู่ในสถานที่โดยวิธีการมันเกิดขึ้นในซุ้มประตูว่า?

— n611x007

1

ใครบอกว่า Slackware ไม่มีการเซ็นชื่อแพ็คเกจ?

แพคเกจ Slackware มีการลงนามด้วยกุญแจสาธารณะของ Slackware .ascดังนั้นแพคเกจทุกคนมีลายเซ็นของที่มีนามสกุล ไม่เพียง แต่แพ็คเกจเท่านั้น แต่ยังมีไฟล์อื่น ๆ ที่ลงชื่อด้วยเช่นCHECKSUMS.MD5ได้รับการลงนามเช่น รายการนี้มีรายการเช็คซัมของแพ็คเกจ

Distro มีเครื่องมืออย่างเป็นทางการที่เรียกว่าslackpkgการดาวน์โหลด / ติดตั้งแพคเกจจากมิเรอร์ หลังจากอัพเดตฐานข้อมูล repo ภายในเครื่องด้วยslackpkg updateเครื่องมือตรวจสอบความถูกต้องของลายเซ็นของไฟล์ MD5 ใหม่และรายการเปลี่ยนแปลง ฯลฯ

หลังจากดาวน์โหลดแพ็คเกจ (แต่ก่อนติดตั้ง) ลายเซ็นและ MD5 ของแพ็คเกจจะถูกตรวจสอบ

หนึ่งสามารถรับกุญแจสาธารณะด้วย slackpkg update gpgหรือเพียงแค่นำเข้าจากซีดีติดตั้งด้วยgpg --import GPG-KEY

มีเครื่องมือที่ไม่เป็นทางการอื่น ๆslapt-getสำหรับ Slackware รองรับการตรวจสอบ GPG ด้วย! slackpkgในลักษณะที่คล้ายกันเป็น

— คนขี้เกียจ
แหล่งที่มา

-2

OpenBSD โดยและไกล โครงการทั้งหมดนี้มีการรักษาความปลอดภัยโดยเฉพาะทีมยังวางแพตช์ 5000+ ลงในอาปาเช่เดิมเพราะพวกเขาไม่รู้สึกว่ามันปลอดภัยพอที่จะใช้ นี่คือผ่าน pkg_add แต่ฉันไม่เคยมีปัญหากับมัน

— baweaver
แหล่งที่มา

4

คุณไม่ได้ตอบคำถาม: โดยเฉพาะเกี่ยวกับการตรวจสอบลายเซ็นของแพ็คเกจที่ดาวน์โหลด (และพอร์ตในกรณีของ * BSD)

— Gilles 'หยุดความชั่วร้าย'

1

ฉันเห็นด้วยกับ @Gilles; OpenBSD เป็นระบบปฏิบัติการที่ยอดเยี่ยม แต่ @grm ถามเกี่ยวกับความปลอดภัยในการแจกจ่ายแพ็คเกจ Linux

— livingstaccato