Squid-ის უარების დიაგნოსტიკა SELinux-ის ქვეშ
შესრულების შეცვლამდე გამოყავით Squid-ის წვდომის წესები, ფაილური სისტემის ნებართვები, პორტის იარლიყები და ჰოსტის უსაფრთხოების პოლიტიკის უარები.
Squid-ის მიერ გენერირებული HTTP წვდომის უარი და ოპერაციული სისტემის “Permission denied” სხვადასხვა საზღვარზე ხდება. დაადგინეთ, ხსნიდა Squid ფაილს, აბამდა სოკეტს, უკავშირდებოდა გარეთ თუ უარყოფდა კლიენტის მოთხოვნას.
დააკავშირეთ აუდიტის მოვლენა
SELinux სისტემებზე შეუსაბამეთ სერვისის შეცდომა მის აუდიტის ჩანაწერს. წყაროს დომენი, სამიზნის ტიპი, ობიექტის კლასი და უარყოფილი ნებართვა გვიჩვენებს, რომელი ოპერაცია დაბლოკა პოლიტიკამ. Unix-ის სწორი მფლობელობა არ ადასტურებს, რომ უსაფრთხოების იარლიყი შესაბამისია.
მორგებულ მოსმენის პორტს შეიძლება დასჭირდეს შესაბამისი პორტის იარლიყი. გადატანილ ჟურნალის ან ქეშის საქაღალდეს შეიძლება დასჭირდეს ფაილების იარლიყირება. Squid-ის ჟურნალის ბილიკის ჩავარდნისას, სანამ იარლიყს დააბრალებთ, შეამოწმეთ ასევე საქაღალდეების გავლა და ჩამწერის ნებართვები. უჩვეულო გამავალი სერვისის ნებართვა კიდევ სხვა ოპერაციაა; Red Hat-ის Squid SELinux მაგალითები ამ შემთხვევებს განასხვავებს.
გამოიყენეთ დაყენებული დისტრიბუტივის პოლიტიკა და ადმინისტრირების სახელმძღვანელო. პაკეტის ბილიკები, იარლიყები და შეზღუდვა შეიძლება განსხვავდებოდეს იმიჯებს შორის. AppArmor-ის მქონე სისტემებზე შეისწავლეთ მისი პროფილი SELinux ბრძანებების გამოყენების ნაცვლად.
შეასწორეთ მტკიცებულებებით მითითებული პოლიტიკა ან მდებარეობა, ჰოსტზე შესრულების შენარჩუნებით. Squid-ის საკუთარი კლიენტის ავთენტიფიკაცია და წვდომის წესები კვლავ მოქმედებს ჰოსტის პოლიტიკის პრობლემის გამოსწორების შემდეგ.