ในอดีต สิทธิ์ sudo อยู่ภายใต้เนื้อหาของไฟล์จาก /etc/sudoers.d и visudoและการอนุญาตที่สำคัญได้ดำเนินการโดยใช้ ~/.ssh/authorized_keys. อย่างไรก็ตาม เมื่อโครงสร้างพื้นฐานเติบโตขึ้น ก็มีความปรารถนาที่จะจัดการสิทธิ์เหล่านี้จากส่วนกลาง วันนี้อาจมีหลายทางเลือกในการแก้ปัญหา:
- ระบบการจัดการการกำหนดค่า - พ่อครัว, หุ่นเชิด, เบิ้ล, เกลือ
- Active Directory + ssd
- การบิดเบือนต่างๆ ในรูปแบบของสคริปต์และการแก้ไขไฟล์ด้วยตนเอง
ในความเห็นส่วนตัวของฉัน ตัวเลือกที่ดีที่สุดสำหรับการจัดการแบบรวมศูนย์ยังคงเป็นการรวมกัน Active Directory + ssd. ข้อดีของแนวทางนี้คือ:
- ไดเร็กทอรีผู้ใช้แบบรวมศูนย์เดียวอย่างแท้จริง
- การกระจายสิทธิ sudo ลงมาเพื่อเพิ่มผู้ใช้ในกลุ่มความปลอดภัยเฉพาะ
- ในกรณีของระบบ Linux ต่างๆ จำเป็นต้องตรวจสอบเพิ่มเติมเพื่อกำหนดระบบปฏิบัติการเมื่อใช้ระบบกำหนดค่า
ชุดโปรแกรมวันนี้จะเน้นไปที่การเชื่อมต่อโดยเฉพาะ Active Directory + ssd เพื่อการจัดการสิทธิ์ sudo และการจัดเก็บ SSH คีย์ในพื้นที่เก็บข้อมูลเดียว
ดังนั้น ห้องโถงจึงตกอยู่ในความเงียบอันตึงเครียด ผู้ควบคุมวงยกกระบองขึ้น และวงออเคสตราก็เตรียมพร้อม
ไป.
ได้รับ:
— โดเมน Active Directory testopf.local บน Windows Server 2012 R2
- โฮสต์ Linux ที่ใช้ Centos 7
— กำหนดค่าการอนุญาตโดยใช้ ssd
โซลูชันทั้งสองทำการเปลี่ยนแปลงสคีมา Active Directoryดังนั้นเราจึงตรวจสอบทุกอย่างในสภาพแวดล้อมการทดสอบ จากนั้นทำการเปลี่ยนแปลงโครงสร้างพื้นฐานการทำงานเท่านั้น ฉันต้องการทราบว่าการเปลี่ยนแปลงทั้งหมดมีการกำหนดเป้าหมาย และในความเป็นจริง เพิ่มเฉพาะแอตทริบิวต์และคลาสที่จำเป็นเท่านั้น
การดำเนินการ 1: การควบคุม sudo บทบาทผ่าน Active Directory.
เพื่อขยายวงจร Active Directory คุณต้องดาวน์โหลดรุ่นล่าสุด — 1.8.27 ณ วันนี้ แตกไฟล์และคัดลอกไฟล์ สคีมา ActiveDirectory จากไดเร็กทอรี ./doc ไปยังตัวควบคุมโดเมน จากบรรทัดคำสั่งที่มีสิทธิ์ผู้ดูแลระบบจากไดเร็กทอรีที่คัดลอกไฟล์ ให้รัน:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(อย่าลืมแทนที่ค่าของคุณ)
เปิด adsiedit.msc และเชื่อมต่อกับบริบทเริ่มต้น:
สร้างส่วนที่รากของโดเมน sudoers. (ชนชั้นกระฎุมพีอ้างว่าปีศาจอยู่ในหน่วยนี้ ssd ค้นหารายการ sudoRole วัตถุ อย่างไรก็ตาม หลังจากเปิดการดีบักโดยละเอียดและศึกษาบันทึก พบว่ามีการค้นหาทั่วทั้งแผนผังไดเร็กทอรีทั้งหมด)
เราสร้างวัตถุแรกที่เป็นของคลาสในส่วน sudoRole. สามารถเลือกชื่อได้ตามใจชอบ เนื่องจากใช้เพื่อระบุตัวตนที่สะดวกเท่านั้น
ในบรรดาแอตทริบิวต์ที่เป็นไปได้จากส่วนขยายสคีมา แอตทริบิวต์หลักมีดังต่อไปนี้:
- คำสั่ง sudo — กำหนดคำสั่งที่ได้รับอนุญาตให้ดำเนินการบนโฮสต์
- sudoHost — กำหนดว่าบทบาทนี้ใช้กับโฮสต์ใด สามารถระบุเป็น ทั้งหมดและสำหรับโฮสต์แต่ละรายตามชื่อ นอกจากนี้ยังสามารถใช้หน้ากากได้
- sudoUser — ระบุว่าผู้ใช้รายใดได้รับอนุญาตให้ดำเนินการ sudo.
หากคุณระบุกลุ่มความปลอดภัย ให้เพิ่มเครื่องหมาย “%” ที่ตอนต้นของชื่อ หากมีช่องว่างในชื่อกลุ่มก็ไม่มีอะไรต้องกังวล เมื่อพิจารณาจากบันทึกแล้ว งานในการหลบหนีจะถูกยึดครองโดยกลไก ssd.
รูปที่ 1. อ็อบเจ็กต์ sudoRole ในส่วนย่อย sudoers ในรูทของไดเร็กทอรี
รูปที่ 2 การเป็นสมาชิกในกลุ่มความปลอดภัยที่ระบุในวัตถุ sudoRole
การตั้งค่าต่อไปนี้เสร็จสิ้นบนฝั่ง Linux
ในไฟล์ /etc/nsswitch.conf เพิ่มบรรทัดต่อท้ายไฟล์:
sudoers: files sssในไฟล์ /etc/sssd/sssd.conf ในส่วน [sssd] เพิ่มบริการ sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
หลังจากการดำเนินการทั้งหมด คุณจะต้องล้างแคช sssd daemon การอัปเดตอัตโนมัติจะเกิดขึ้นทุก ๆ 6 ชั่วโมง แต่ทำไมเราต้องรอนานนักเมื่อเราต้องการตอนนี้
sss_cache -Eมักเกิดขึ้นว่าการล้างแคชไม่ได้ช่วยอะไร จากนั้นเราหยุดบริการ ทำความสะอาดฐานข้อมูล และเริ่มบริการ
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
เราเชื่อมต่อในฐานะผู้ใช้รายแรกและตรวจสอบว่ามีอะไรให้เขาใช้งานได้ภายใต้ sudo:
su user1
[user1@testsshad log]$ id
uid=1109801141(user1) gid=1109800513(domain users) groups=1109800513(domain users),1109801132(admins_)
[user1@testsshad log]$ sudo -l
[sudo] password for user1:
Matching Defaults entries for user1 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user1 may run the following commands on testsshad:
(root) /usr/bin/ls, /usr/bin/catเราทำเช่นเดียวกันกับผู้ใช้คนที่สองของเรา:
su user2
[user2@testsshad log]$ id
uid=1109801142(user2) gid=1109800513(domain users) groups=1109800513(domain users),1109801138(sudo_root)
[user2@testsshad log]$ sudo -l
Matching Defaults entries for user2 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user2 may run the following commands on testsshad:
(root) ALL
วิธีการนี้ช่วยให้คุณสามารถกำหนดบทบาท sudo สำหรับกลุ่มผู้ใช้ที่แตกต่างกันได้จากส่วนกลาง
การจัดเก็บและการใช้คีย์ ssh ใน Active Directory
ด้วยการขยายโครงร่างเล็กน้อย คุณสามารถจัดเก็บคีย์ ssh ไว้ในคุณลักษณะผู้ใช้ Active Directory และใช้เมื่ออนุญาตบนโฮสต์ Linux
ต้องกำหนดค่าการอนุญาตผ่าน sssd
เพิ่มแอตทริบิวต์ที่จำเป็นโดยใช้สคริปต์ PowerShell
AddsshPublicKeyAttribute.ps1ฟังก์ชัน New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$อะไหล่=@()
$Parts+=[UInt64]::Parse($guid.SubString(0,4), “AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(4,4), “AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(9,4), “AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(14,4), “AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(19,4), “AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(24,6), “AllowHexSpecifier”)
$Parts+=[UInt64]::Parse($guid.SubString(30,6), “AllowHexSpecifier”)
$oid=[String]::Format(«{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}»,$prefix,$Parts[0],
$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6])
$oid
}
$schemaPath = (รับ-ADRootDSE).schemaNamingContext
$oid = ใหม่-AttributeID
$แอตทริบิวต์ = @{
lDAPDisplayName = 'sshPublicKey';
คุณลักษณะ ID = $oid;
oMSyntax = 22;
แอตทริบิวต์ไวยากรณ์ = "2.5.5.5";
isSingleValued = $จริง;
adminDescription = 'รหัสสาธารณะของผู้ใช้สำหรับการเข้าสู่ระบบ SSH';
}
ใหม่-ADObject - ชื่อ sshPublicKey - ประเภทแอตทริบิวต์ Schema - เส้นทาง $schemapath - แอตทริบิวต์อื่น ๆ $
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | ชุด-ADObject - เพิ่ม @{mayContain = 'sshPublicKey'}
หลังจากเพิ่มแอตทริบิวต์ คุณต้องเริ่มบริการโดเมน Active Directory ใหม่
มาดูผู้ใช้ Active Directory กันดีกว่า เราจะสร้างคู่คีย์สำหรับการเชื่อมต่อ ssh โดยใช้วิธีใดก็ได้ที่สะดวกสำหรับคุณ
เราเปิดตัว PuttyGen กดปุ่ม "สร้าง" แล้วเลื่อนเมาส์อย่างเมามันภายในพื้นที่ว่าง
เมื่อเสร็จสิ้นกระบวนการ เราสามารถบันทึกคีย์สาธารณะและคีย์ส่วนตัว อัปโหลดคีย์สาธารณะไปยังแอตทริบิวต์ผู้ใช้ Active Directory และเพลิดเพลินไปกับกระบวนการ อย่างไรก็ตาม ต้องใช้กุญแจสาธารณะจาก "รหัสสาธารณะสำหรับการวางลงในไฟล์ OpenSSH authorize_keys:"
เพิ่มคีย์ให้กับแอตทริบิวต์ผู้ใช้
ตัวเลือก 1 - GUI:
ตัวเลือก 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
ดังนั้นเราจึงมี: ผู้ใช้ที่มีการกรอกแอตทริบิวต์ sshPublicKey ซึ่งเป็นไคลเอ็นต์ Putty ที่กำหนดค่าไว้สำหรับการอนุญาตโดยใช้คีย์ ยังมีจุดเล็กๆ อีกจุดหนึ่ง: วิธีบังคับให้ sshd daemon แยกคีย์สาธารณะที่เราต้องการจากคุณลักษณะของผู้ใช้ สคริปต์ขนาดเล็กที่พบในอินเทอร์เน็ตชนชั้นกลางสามารถรับมือกับสิ่งนี้ได้สำเร็จ
cat /usr/local/bin/fetchSSHKeysFromLDAP
#!/bin/sh
ldapsearch -h testmdt.testopf.local -xb "dc=testopf,dc=local" '(sAMAccountName='"${1%@*}"')' -D [email protected] -w superSecretPassword 'sshPublicKey' | sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/n *//g;s/sshPublicKey: //gp'เราตั้งค่าการอนุญาตเป็น 0500 สำหรับรูท
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
ในตัวอย่างนี้ บัญชีผู้ดูแลระบบถูกใช้เพื่อผูกกับไดเร็กทอรี ในเงื่อนไขการต่อสู้จะต้องมีบัญชีแยกต่างหากพร้อมสิทธิ์ขั้นต่ำ
โดยส่วนตัวแล้วฉันสับสนมากกับช่วงเวลาของรหัสผ่านในรูปแบบบริสุทธิ์ในสคริปต์ แม้ว่าจะมีการกำหนดสิทธิ์ไว้ก็ตาม
ตัวเลือกโซลูชัน:
- ฉันบันทึกรหัสผ่านในไฟล์แยกต่างหาก:
echo -n Supersecretpassword > /usr/local/etc/secretpass - ฉันตั้งค่าการอนุญาตไฟล์เป็น 0500 สำหรับรูท
chmod 0500 /usr/local/etc/secretpass - การเปลี่ยนพารามิเตอร์การเรียกทำงาน ldapsearch: พารามิเตอร์ -w superSecretPassword ฉันเปลี่ยนมันเป็น -y /usr/local/etc/secretpass
คอร์ดสุดท้ายในชุดวันนี้คือการแก้ไข sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
เป็นผลให้เราได้รับลำดับต่อไปนี้พร้อมการกำหนดค่าการอนุญาตคีย์ในไคลเอนต์ ssh:
- ผู้ใช้เชื่อมต่อกับเซิร์ฟเวอร์โดยระบุการเข้าสู่ระบบของเขา
- sshd daemon จะแยกค่าคีย์สาธารณะจากคุณลักษณะผู้ใช้ใน Active Directory ผ่านสคริปต์ และดำเนินการให้สิทธิ์โดยใช้คีย์ดังกล่าว
- sssd daemon จะพิสูจน์ตัวตนผู้ใช้เพิ่มเติมตามความเป็นสมาชิกกลุ่ม ความสนใจ! หากไม่มีการกำหนดค่า ผู้ใช้โดเมนจะสามารถเข้าถึงโฮสต์ได้
- เมื่อคุณพยายาม sudo sssd daemon จะค้นหาบทบาทใน Active Directory หากมีบทบาทอยู่ คุณลักษณะของผู้ใช้และความเป็นสมาชิกกลุ่มจะถูกตรวจสอบ (หากกำหนดค่า sudoRoles ให้ใช้กลุ่มผู้ใช้)
ผลที่ได้
ดังนั้นคีย์จะถูกเก็บไว้ในแอตทริบิวต์ผู้ใช้ Active Directory สิทธิ์ sudo - ในทำนองเดียวกันการเข้าถึงโฮสต์ Linux ด้วยบัญชีโดเมนจะดำเนินการโดยการตรวจสอบความเป็นสมาชิกในกลุ่ม Active Directory
คลื่นลูกสุดท้ายของกระบองของผู้ควบคุมวง - และห้องโถงก็ค้างในความเงียบด้วยความเคารพ
ทรัพยากรที่ใช้ในการเขียน:
ที่มา: will.com