chmod 777 - ლინუქსის ნებართვები - უკანა კარის შეტევა

Chmod 777 არ არის გამოსწორება: როგორ გადაიქცა არასწორად კონფიგურირებული სკრიპტი უკანა კარად

სარჩევი

აუცილებლად წასაკითხი პოსტები

საინტერესო უახლესი პოსტები

ჰუკი: დღე, როდესაც Pipeline გატეხილი (Chmod 777)

როდესაც საქმე ეხება CI/CD უსაფრთხოების თვალსაზრისით, რამდენიმე შეცდომაა ისეთივე საშიში, როგორც chmod 777-ის გაშვება. მისი არასწორად გამოყენება არღვევს Linux-ის ნებართვებს, აქვეითებს დამცავ მექანიზმებს და ხსნის კარს პოტენციური „უკანა კარის“ შეტევისთვის. ის ასე იწყება: CI/CD pipeline წითელია, გუნდი დაბლოკილია და ტერმინალი საშინელებას აფურთხებს:

nginx

Წვდომა აკრძალულია

ძირეული მიზეზის პოვნის ნაცვლად, დეველოპერი ბირთვულ ვარიანტს მიმართავს:

⚠️ დაუცველობის მაგალითი: ყველას ანიჭებს სრულ წვდომას. არ გაუშვათ წარმოებაში.
chmod 777 deploy.sh

მშენებლობა ამოქმედდება. წნევა იკლებს. ყველა სამსახურს უბრუნდება. თუმცა, ფონზე, ამ ერთმა ბრძანებამ გვერდი აუარა Linux-ის ნებართვების მიერ მოწოდებულ ყველა დამცავ ზომას, რითაც შექმნა საფუძველი უკანა კარის შეტევისთვის, რომელსაც შეეძლო მთელი სისტემის კომპრომეტირება.

chmod 777-ის რეალური გავლენა Linux-ის ნებართვებზე

Linux-ის ნებართვები Unix-ის მსგავს სისტემებში ფაილის დონის უსაფრთხოების საფუძველია. ისინი განსაზღვრავენ, ვის შეუძლია ფაილის წაკითხვა, ჩაწერა ან შესრულება. ყველა ფაილს აქვს:

  • სამი ტიპის ნებართვა: წაკითხვა (რ), დაწერე (ვ)და შეასრულეთ (x).
  • სამი ნებართვის ჯგუფი: მფლობელი, ჯგუფი და სხვები.

როდესაც თქვენ აწარმოებს ჩმოდ 777, თქვენ სამივე ჯგუფს ანიჭებთ წაკითხვის, ჩაწერის და შესრულების ნებართვებს. ეს იგივეა, რაც სახლში ყველა კარის ღიად დატოვება, არა მხოლოდ მეგობრებისთვის, არამედ უცნობებისთვის და ნებისმიერი გამვლელისთვის.

უსაფრთხო დემონსტრირება:

იზოლირებულ დეველოპერულ მანქანებში ეს შეიძლება უვნებლად მოგეჩვენოთ. თუმცა, საერთო ბილდინგის აგენტებში, კონტეინერიზებულ გარემოში ან მრავალმომხმარებლიან Linux სისტემებში, ჩმოდ 777 ყველა ფაილს, რომელსაც ეხება, ხელყოფის ღია მოწვევად აქცევს, რაც იდეალურ გარემოს წარმოადგენს უკანა კარის შეტევისთვის.

შეტევის ვექტორი: chmod 777-დან Backdoor-ის შეტევამდე

აი, როგორ ჩმოდ 777 შეიძლება უკანა კარად გადაიქცეს თავდასხმა:

  1. დეველოპერი ადგენს ჩმოდ 777 განლაგებაზე ან შექმნის სკრიპტზე ნებართვების შეცდომის გამოსასწორებლად
  2. ფაილი ხდება მსოფლიოში ჩასაწერი; ნებისმიერ მომხმარებელს ან პროცესს შეუძლია მისი შეცვლა.
  3. თავდამსხმელი სკრიპტში მავნე კოდს ათავსებს
  4. ის CI/CD pipeline ასრულებს შეცვლილ სკრიპტს, ასრულებს თავდამსხმელის დატვირთვას გაზრდილი პრივილეგიებით.

⚠️ დაუცველობის მაგალითი: არ გაუშვათ წარმოებაში. აქ გამოიყენება სარისკო ნებართვების საილუსტრაციოდ.
chmod 777 build.sh

მარტივი შეტევის მიმდინარეობა:

როდესაც ეს განსაკუთრებით საშიში ხდება:

  • საერთო აშენების აგენტები რამდენიმე გუნდთან ან პროექტთან ერთად
  • ჰოსტის ტომების დამონტაჟება Docker-ის ან Kubernetes-ის პოდებში
  • ღია კოდის საცავები სადაც კონტრიბუტორებს შეუძლიათ ცვლილებების განხორციელებით ან გაერთიანებით

როგორც კი ეს ჯაჭვი დაიწყება, უკანა კარის შეტევამ შეიძლება გადაიზარდოს წარმოებაში, გაჟონოს ავტორიზაციის მონაცემები, შეცვალოს არტეფაქტები ან გახსნას მუდმივი წვდომის წერტილები.

შემთხვევის შესწავლა: არასწორად კონფიგურირებული სკრიპტის მეშვეობით Backdoor-ის შეტევა

მოდით, ძირითად საკითხებამდე შევაჯამოთ:

  1. დეველოპერი მუშაობს chmod 777 build.sh გვერდის ავლა CI/CD შეცდომა
  2. იმავე გარემოში სხვა მომხმარებელი ან მავნე პროცესი არედაქტირებს სკრიპტს
  3. ის pipeline ასრულებს კომპრომეტირებულ სკრიპტს CI/CD სერვისის ანგარიშის ნებართვები
  4. თუ ამ პროცესის განმავლობაში განახლდება დაუცველი ღია კოდის პაკეტი, უკანა შეტევა შეიძლება გავრცელდეს წარმოებაში.

ეს არის, თუ როგორ ჩმოდ 777 პლუს Linux-ის შეუფერხებელმა ნებართვებმა შეიძლება თავდამსხმელებს თავისუფალი წვდომა მისცეს თქვენი განლაგების პროცესზე.

რატომ იყენებენ დეველოპერები კვლავ chmod 777-ს (და რატომ არის ეს ხაფანგი)

ამ ხაფანგში გამოცდილი დეველოპერებიც კი ვარდებიან, რადგან ჩმოდ 777 სწრაფი გამოსწორების შთაბეჭდილებას ტოვებს, როდესაც:

  • არტეფაქტების შეფუთვა ნებართვის უარყოფის შეცდომებს იწვევს
  • Shell სკრიპტები Docker-ში ვერ ხერხდება, რადგან ისინი შესრულებადი არ არის.
  • გაზიარებულ ტომებში არსებული ჟურნალის ფაილების ჩაწერა შეუძლებელია.

მაგრამ აი, რაშია საქმე: შენმღერიან ჩმოდ 777 უგულებელყოფს ძირეულ მიზეზს, უგულებელყოფს Linux-ის ნებართვების კონტროლს და არღვევს მინიმალური პრივილეგიების პრინციპს. დაბრკოლების მოხსნის ნაცვლად, ის იწვევს უკანა კარის შეტევას.

chmod 777-ის უსაფრთხო ალტერნატივები

If ჩმოდ 777 ბირთვული ვარიანტია, ეს არის ქირურგიული დარტყმები:

dockerfile საუკეთესო პრაქტიკა:

dockerfile

GitHub მოქმედებები მაგალითად:

ეს სისტემები სათანადოდ აღასრულებს Linux-ის ნებართვებს, ბლოკავს არაავტორიზებული ცვლილებების განხორციელებას და ამცირებს უკანა შეტევის რისკს.

როგორ ამოვიცნოთ და თავიდან ავიცილოთ chmod 777 არასწორი კონფიგურაციები

Pre-commit ეტაპი

  • წასვლა hooks უარი თქვას commitშემცველი ჩმოდ 777:

აწყობის ეტაპი

  • ინტეგრირება SAST დაუცველი ბრძანებების მონიშვნა
  • CI სამუშაოების წარუმატებლობა, თუ მოვძებნოთ აღმოაჩენს მსოფლიოში ჩასაწერ ფაილებს

გაშვების ეტაპი

გლობალური ჩაწერის წვდომის მქონე ფაილების სკანირება:

სიის შიფრები:

პოლიტიკის აღსრულება

  • Linux-ის დაშვებული ნებართვების დასადგენად გამოიყენეთ Policy-as-Code
  • გაგზავნეთ შეტყობინებები სარისკო განლაგებების ამოქმედებამდე

როდესაც ამ შემოწმებებს ავტომატიზირებთ, თქვენ ამცირებთ შანსს, რომ ჩმოდ 777 ოდესმე მიაღწევს წარმოებას და ამასთან ერთად, არსებობს უკანა კარის შეტევის შანსი.

DevSecOps და კულტურა: chmod 777-ის წყაროსთან თავიდან აცილება

უსაფრთხოების ინტეგრირება DevSecOps კულტურა უფრო ეფექტურია, ვიდრე მისი მოგვიანებით გამოსწორება:

  1. პოლიტიკა, როგორც კოდი, უსაფრთხო Linux-ის ნებართვების აღსასრულებლად ყველაში pipeline
  2. სკრიპტების მიმოხილვები, რომლებიც მოიცავს განლაგების სკრიპტების ნებართვის შემოწმებას
  3. უსაფრთხო შაბლონები Docker-ისთვის, Kubernetes-ისთვის და CI/CD კონფიგურაციები

ტრენინგი იმის შესახებ, თუ როგორ ჩმოდ 777 ქმნის ვექტორს უკანა კარის შეტევებისთვის.

რატომ არ არის chmod 777 არასდროს გამოსწორება?

Chmod 777 ეს არ არის მოკლე გზა; ეს რისკის მულტიპლიკატორია. ის უგულებელყოფს Linux-ის ფრთხილად შემუშავებულ ნებართვებს, ხსნის დამცავ მექანიზმებს და გზას უხსნის უკანა კარის შეტევას, რომელსაც შეუძლია კომპრომეტირება მოახდინოს. CI/CD pipelineდა წარმოების სისტემები.

გამოსწორება მხოლოდ ბრძანებების შეცვლა არ არის; ეს არის უსაფრთხო ნებართვების მიღება, შემოწმებების ავტომატიზაცია და თქვენს სისტემაში ყველაზე ნაკლებად პრივილეგირებული აზროვნების ჩანერგვა. DevSecOps პროცესი. ინსტრუმენტები, როგორიცაა ქსიგენი შეუძლია დაგეხმაროთ დაუცველი კონფიგურაციებისა და მსოფლიოში ჩასაწერი ფაილების აღმოჩენაში მათი წარმოებამდე, რაც უზრუნველყოფს უსაფრთხოების ბადეს მიწოდების შენელების გარეშე.

sca-tools-software-composition-analysis-tools
თქვენი პროგრამული უზრუნველყოფის რისკების პრიორიტეტიზაცია, გამოსწორება და დაცვა
მიიღეთ თქვენი უფასო ანგარიში.
საკრედიტო ბარათი არ არის საჭირო.

უზრუნველყავით თქვენი პროგრამული უზრუნველყოფის შემუშავება და მიწოდება

Xygeni Product Suite-თან ერთად