sudo xavfsizligi

Root va sudo maqolasida sudo qanday ishlashi, su dan nimasi bilan farq qilishi va sudoers siyosatini visudo bilan qanday xavfsiz o'qish va tahrirlash ko'rib chiqilgan edi. Bu maqola shu poydevorga tayanadi va bir pog'ona chuqurroq boradi. Unda sudo siyosati vaqt o'tishi bilan "hammada ALL bor" holatiga tushib qolmasligini qanday ta’minlash, sudo'dan foydalanish hodisalarga javob beruvchi mutaxassis (incident responder) topa oladigan joyda haqiqatan yozib borilishini qanday kafolatlash va sudo'ga o'z-o'zidan attack surface sifatida qanday qarash ko'rib chiqiladi. Chunki root huquqini beradigan dasturning o'zi ham versiya raqami bor, ba’zan esa CVE’si ham chiqadigan dasturiy ta’minot.

Nimalarni o'rganasiz

Bu maqola oxirida siz quyidagilarni qila olasiz:

• sudoers qoidalarini Cmnd_Alias bilan cheklash va faqat binary nomini cheklash nega yetarli emasligini tushuntirish;
• yuqori imtiyozli buyruq aslida nima qilganini qayta tiklash uchun sudo'ning I/O logging funksiyasini yoqish va o'qish;
• credential timestamp va autentifikatsiya talablarini tasodifan emas, ongli ravishda sozlash;
• sudo ning o'zini yangilab turish nega sudo xavfsizligining bir qismi ekanini aniq tarixiy misol bilan tushuntirish;
• har bir serverni qo'lda tahrirlash o'rniga ko'plab serverlarga bir xil sudo siyosatini tarqatish.

Qoidalarni Cmnd_Alias bilan cheklash

Bitta buyruq bilan cheklangan sudoers qoidasi ALL dan xavfsizroq. Lekin ko'plab qoidalarda takrorlanadigan bir-biriga bog'liq buyruqlar to'plamini ko'rib chiqish qiyinlashadi va unda nozik xato qilib qo'yish oson. Cmnd_Alias ularni bitta nom ostiga guruhlaydi:

sudo visudo -f /etc/sudoers.d/deploy-app

Cmnd_Alias APP_CTL = /usr/bin/systemctl restart myapp, /usr/bin/systemctl status myapp
deploy ALL=(root) NOPASSWD: APP_CTL

Bu o'qilishi va audit qilinishi bo'yicha yaxshilanish, o'z-o'zidan yangi xavfsizlik chegarasi emas. Lekin u xavfsizlik uchun juda aniq ma’noda muhim: o'qish oson bo'lgan siyosat to'g'ri ko'rib chiqiladi, bir qarashda hech kim tushuna olmaydigan siyosat esa ko'r-ko'rona tasdiqlanadi.

Haqiqatda nima bo'lganini yozib borish: I/O logging

Standart holatda sudo buyruq ishga tushgani va kim nomidan ishga tushganini log'ga yozadi, lekin buyruq aslida nima chiqarganini yoki qanday kirish ma’lumotlarini olganini yozmaydi. Keng yoki sezgir kirish huquqiga ega akkauntlar uchun bu bo'shliq hodisa paytida muhim bo'ladi: deploy sudo bash ni ishga tushirganini bilish o'sha shell ichida nima bo'lgani haqida deyarli hech narsa aytmaydi. Defaults log_input,log_output bu bo'shliqni yopadi:

sudo visudo -f /etc/sudoers.d/io-logging

Defaults log_input,log_output
Defaults iolog_dir=/var/log/sudo-io/%{user}

sudo -l

Matching Defaults entries for <username> on prod-01:
    log_input, log_output, iolog_dir=/var/log/sudo-io/%{user}

Yoqilgandan keyin sessiyaning to'liq kirish va chiqish ma’lumotlarini qayta ijro etish (replay) mumkin:

sudo sudoreplay -l | tail -n 3

Jul 29 09:41:02 2026 : deploy : TTY=pts/0 ; CWD=/home/deploy ; USER=root ; TSID=000001

sudo sudoreplay 000001

sudoreplay yozib olingan sessiyani aynan qanday bo'lgan bo'lsa, shunday — har bir tugma bosilishigacha — qayta ijro etadi. Bu voqeadan keyin operatorning yelkasi ortida turib kuzatishga eng yaqin narsa.

Credential timestamp’ni sozlash

Standart holatda foydalanuvchi sudo ga muvaffaqiyatli autentifikatsiyadan o'tgach, bu autentifikatsiya bir necha daqiqaga keshlanadi (timestamp_timeout, ko'pchilik distributivlarda standart qiymati 15). Shunda bitta terminaldagi takroriy sudo buyruqlarining har biri parol so'ramaydi. Bu qulaylik va xavfsizlik o'rtasidagi murosa bo'lib, uni standart holatda qoldirish o'rniga ongli ravishda sozlagan ma’qul:

Defaults timestamp_timeout=5

Qisqaroq oyna operator joyidan ketib qolganda qarovsiz, allaqachon autentifikatsiyadan o'tgan terminalning ishlaydigan root shell bo'lib qolish vaqtini kamaytiradi. 0 esa har bir chaqiruvda parol talab qiladi. use_pty — I/O logging bilan birga yoqishga arziydigan tegishli sozlama:

Defaults use_pty

use_pty buyruqni sudo ning o'zi boshqaradigan pseudo-terminal ichida ishlashga majbur qiladi. Bu log_input/log_output faqat buyruqning yakuniy chiqishini emas, interaktiv sessiyalarni ishonchli yozib olishi uchun zaruriy shart.

sudo ning o'zini yangilab turish

sudo — ishonchsiz kirish ma’lumotlarini tahlil qiladigan setuid-root binary. Bu uni shunchaki siyosat fayli emas, o'z-o'zidan hujum nishoniga aylantiradi. CVE-2021-3156 ("Baron Samedit") — sudo ning buyruq qatorini tahlil qilish qismidagi heap’ga asoslangan buffer overflow. U har qanday mahalliy foydalanuvchiga, jumladan umuman sudoers yozuvi bo'lmagan foydalanuvchiga ham, root’gacha imtiyozini oshirishga imkon bergan va topilgunga qadar kod bazasida taxminan o'n yil davomida aniqlanmay qolgan. Hech qanday sudoers siyosati, qanchalik puxta cheklangan bo'lmasin, sudo ning o'zidagi nuqsondan himoya qilmaydi.

sudo --version
apt list --upgradable 2>/dev/null | grep -i sudo

O'rnatilgan sudo versiyasini distributivning xavfsizlik e’lonlari (advisories) bilan solishtirish va sudo yangilanishlari avtomatik xavfsizlik yangilanishlaridan chiqarib tashlanmaganiga ishonch hosil qilish (Production’da yangilanishlar maqolasida ko'rib chiqilgan) siyosat fayli kabi "sudo xavfsizligi"ning bir qismi.

Ko'plab serverlarda siyosatni markazlashtirish

/etc/sudoers.d/ ni har bir serverda alohida qo'lda tahrirlash — siyosat chalkashib keta boshlaydigan nuqta. Bir host tuzatishni oladi, boshqalari olmaydi va qaysi biri asosiy ekanini hech kim eslay olmaydi. Ikki keng tarqalgan yondashuv bor:

• Konfiguratsiyani boshqarish (Ansible, Puppet, Salt) — /etc/sudoers.d/ ostidagi sudoers drop-in fayllari versiyalar nazorati ostidagi manbadan tarqatiladi. Shunda git log qaysi ruxsatni kim va qachon o'zgartirganini aniq ko'rsatadi.
• LDAP bilan sudo (sudo-ldap) — sudo qoidalari mahalliy fayllarda emas, markaziy LDAP katalogida saqlanadi va har bir host qoidalarni tekshirish paytida bir xil siyosatni o'qiydi. Bitta foydalanuvchining roli o'zgarsa, barcha serverlar birdaniga yangilanadi va hostlar bo'yicha chalkashlik bo'lishi mumkin emas.

Har ikki yondashuv ham "har bir serverni yangilashni unutmadikmi" savolini qo'lda bajariladigan checklist o'rniga hal qilingan masalaga aylantiradi. sudoreplay va markazlashgan log jo'natish (Xavfsizlik loglarini tahlil qilish maqolasida ko'rib chiqiladi) bilan birgalikda esa "bu akkaunt yuqori imtiyozlar bilan nima qilgan" degan savolga har bir host bo'yicha alohida emas, butun park bo'yicha javob beradi.

Amaliy vaziyat: o'sib ketgan siyosatni audit qilish

Muammo. Serverda bir necha yil davomida sudoers yozuvlari to'planib qolgan va ularning qaysilari hali ham kerakligini hech kim aniq bilmaydi.

Hech narsani o'zgartirmasdan hozir berilgan hamma narsani ro'yxatga chiqarish:

sudo grep -rH '' /etc/sudoers.d/ 2>/dev/null | grep -v '^#'

/etc/sudoers.d/deploy-app:deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp
/etc/sudoers.d/old-contractor:contractor ALL=(ALL) NOPASSWD: ALL
/etc/sudoers.d/backup-job:backup-svc ALL=(root) NOPASSWD: /usr/local/bin/run-backup.sh

Har bir akkaunt hali ham faolligini tekshirish:

getent passwd contractor

contractor:x:1004:1004::/home/contractor:/usr/sbin/nologin

contractor akkauntining shell’i allaqachon nologin. Demak, sudoers yozuvi pudratchi ketgandan keyin qolib ketgan ortiqcha yuk. Undan ham yomoni, bu umuman kerak bo'lmagan akkaunt uchun ALL=(ALL) NOPASSWD: ALL yozuvi.

Eskirgan yozuvni olib tashlash va qolgan siyosatni tekshirish:

sudo rm /etc/sudoers.d/old-contractor
sudo visudo -c

/etc/sudoers: parsed OK
/etc/sudoers.d/deploy-app: parsed OK
/etc/sudoers.d/backup-job: parsed OK

Xulosa. visudo -c olib tashlashdan keyin qolgan siyosat sintaktik jihatdan to'g'ri ekanini tasdiqlaydi. Lekin sintaksisning to'g'riligi ruxsat hali ham kerakmi yoki yo'qmi, bu haqda hech narsa aytmaydi. Bu qaror har bir yozuvni haqiqatan hali ham ishlatilayotgan akkauntlar va vazifalar bilan solishtirib chiqishni talab qiladi. Aynan shunday ko'rib chiqish kimdir tasodifan payqagandagina emas, jadval bo'yicha bo'lishi kerak.

Keng tarqalgan xatolar

• "Bitta binary bilan cheklangan"ni "xavfsiz" deb hisoblash. Yuqorida ko'rib chiqilganidek, o'zi boshqa dasturlarni ishga tushira oladigan cheklangan buyruq cheklov yopishi kerak bo'lgan o'sha eshikni qayta ochib qo'yadi.
• I/O logging'ni yoqib, uni hech qachon ko'rib chiqmaslik. Ko'rib chiqish jarayonisiz to'planadigan log'lar hodisadan keyin sud-tergov (forensic) qiymatiga ega bo'ladi, lekin hodisaning oldini olish uchun hech narsa qilmaydi. I/O logging'ni davriy ko'rib chiqish bilan yoki hech bo'lmaganda sudoreplay bilan tekshirishga arziydigan sessiyalar haqida ogohlantirish bilan birga ishlatish bu bo'shliqni yopadi.
• NOPASSWD yozuvlari yo'q sudoers fayli o'z-o'zidan xavfsiz deb hisoblash. Parol talab qilish tasodifiy suiiste’molni sekinlashtiradi, lekin akkauntning o'z paroli yoki SSH kaliti allaqachon buzib kirilgan sessiyaga qarshi hech narsa qilmaydi. sudo xavfsizligi va akkaunt xavfsizligi — bir-biriga bog'liq, lekin bir xil bo'lmagan masalalar.
• O'rnatilgan sudo versiyasini hech qachon tekshirmaslik. Har qanday setuid binary kabi, yangilanmagan sudo sudoers siyosati qanchalik puxta yozilganidan qat’i nazar, o'z-o'zidan zaiflik.

Mashqlar

1. Lab tizimida Cmnd_Alias yordamida bitta zararsiz buyruq bilan cheklangan sudoers qoidasini yarating va sudo -l bilan faqat shu buyruqqa ruxsat berilganini tekshiring.
2. O'z akkauntingiz uchun Defaults log_input,log_output ni yoqing, qisqa interaktiv sudo bash sessiyasini o'tkazing va uni sudoreplay bilan qayta ijro eting.
3. Kirish huquqingiz bor tizimda o'rnatilgan sudo versiyasini tekshiring va distributivning changelog'i yoki e’lonlar lentasidan u hammaga ma’lum biror CVE uchun tuzatishlarni o'z ichiga oladimi, aniqlang.
4. 50 ta serverdan iborat park uchun /etc/sudoers.d/ ni har birida qo'lda tahrirlash, hatto har bir alohida tahrir to'g'ri bo'lsa ham, nega xavfsizlik uchun xavf ekanini tushuntiring.

Xulosa

sudo xavfsizligi to'g'ri yozilgan sudoers faylidan kengroq tushuncha. Qoidalar Cmnd_Alias kabi vositalar bilan cheklanishi va ruxsat berilgan buyruqning o'zi nima qila olishiga qarab tekshirilishi kerak. Sezgir sessiyalar uchun I/O logging va sudoreplay foydali, credential keshlash ongli ravishda sozlanishi, sudo ning o'zi yangilanib turishi, ko'plab serverlardagi siyosat esa har bir hostni alohida tahrirlash o'rniga yagona haqiqat manbasiga ega bo'lishi kerak. Keyingi maqola, PAM asoslari, sudo — shuningdek su, login va sshd — shaxsni haqiqiy tekshirishni topshiradigan autentifikatsiya framework’ini ko'rib chiqadi.

Manbalar

• sudo.ws: Sudo Manual
• sudo.ws: sudoreplay Manual
• NVD: CVE-2021-3156
• GTFOBins