სისადმინის ბლოგი

საიტების უმრავლესობა არ ტყდება SQL Injection, XSS, XMLRPC, ან HTTP სერვერის ბაგების გამო, ისინი ტყდება მარტივი გადასინჯვის მეთოდით ftp სერვერზე, ssh-ზე (“ტუპოი პერებორით”). სცენარი მარტივია: ირჩევა სამიზნე საიტები, ეშვება პაროლების გადასინჯვის პროგრამა  “შემტევის” ლოკალურ კომპიუტერზე ან რომელიმე გატეხილ სერვზე, ციკლი აგენერირებს მომხმარებლის სახელებს და პაროლებს და სინჯავს -უგზავნის მათ სამიზნე სერვერს სანამ არ მოხდება პაროლის დამთხვევა. ეს ციკლი შეძლება რამოდენიმე დღე გრძელდებოდეს წამში 10 ან მეტი გადასინჯვის ინტრევალით.

ქართული web რეალობა: ტყდება რამოდენიმე საიტი, მერე კიდევ მათი გარკვეული რაოდენობა, შემდეგ კიდევ რამოდენიმე და ცოტა ხანში ირკვევა, რომ გატეხილა ჰოსტინგი და არა უშუალოდ საიტები. ამის შემდეგ “შემტევს” ანუ ადამიანს ვინც ეს მარტივი ციკლი გაუშვა აქვს ტოტალური კონტროლი ყველა საიტზე რაც ამ ჰოსტინგზეა განთავსებული. მარტივი და ეფექტური გამოსავალი ასეთ სიტუაციში არის iptables გამოყენება. Iptables -ს საშუალებით შეგვიძლია შევზღუდოთ კავშირების რაოდენობა დროის მიხედვით (შეტევის მცდელობების რაოდენობა). ჩავწეროთ ლოგებში შეტევის მცდელობები და სამუდამოდ ავკრძალოთ წვდომა შემტევის IP მისამართი(ები)დან.

პოსტი  მოიცავს  iptables და  (r)syslog სერვერის  კონფიგურაციას RHEL/Centos/Fedora/ დისტრიბუტივებისთვის, მაგრამ  აღნიშნული კონფუგურაციის მორგება თავისუფლად არის შესაძლებელი ნებისმიერი წარმოშობის  ლინუქსისთვის.

ყურადღება iptables სცენარი:

iptables -N SSH_CHECK
iptables -N SSH_ATTACKED
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -j SSH_CHECK
iptables -A SSH_CHECK -m recent --set --name SSH
iptables -A SSH_CHECK -m recent --update --seconds 60 --hitcount 4 --name SSH -j SSH_ATTACKED
iptables -A SSH_CHECK -j ACCEPT
iptables -A SSH_ATTACKED -j LOG --log-prefix "SSH Attack Detected:" --log-level 7
iptables -A SSH_ATTACKED -j DROP

განვიხილოთ დეტაულრად:

1.  ვქმნით ორ ახალ iptable ჯაჭვს (chain) სახელად SSH_CHEK და SSH_ATTACKED.

 iptables -N SSH_CHECK

2.  ვამოწმებთ ყოველ ახალ კავშირს, რომელიც გაივლის შემდეგ წეს და თუ ემთხვევა 22-ე პორტს და  ახალი TCP კავშირია – ვარდება SSH_CHEK ჯაჭვში.

 iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_CHECK

3. iptables გვაძლევს საშუალებას შევქმნათ დროებითი ცხრილები (recent match) და დავაფიქსიროთ ერთნაირი source IP-ები, რომლითაც შეგვეძლება მათი “დაჭერა” და შემდეგ მათთვის წესების გაწერაც. კონკრეტული ბრძანებით ჩვენს დროებით ცხრილს ვანიჭებთ სახელს “SSH“.

 iptables -A SSH_CHECK -m recent --set --name SSH

4. ქვედა ბრძანებით ვაყალიბებთ შემდეგ პირობას/წესს: თუ SSH დროებით ცხრილში მყოფი IP დაამყარებს სამ ახალ კავშირს – გადავა ჯაჭვში “SSH_ATTACKED” 1 წუთის განმავლობაში.

 iptables -A SSH_CHECK -m recent --update --seconds 60 --hitcount 4 --name SSH -j SSH_ATTACKED

5. თუ SSH_CHECK ჯაჭვში არსებული კავშირი(ები) არ ემთხვევა წინა წესს მაშინ კავშირი 22-ე პორტზე დაშვებულია.

 iptables -A SSH_CHECK -j ACCEPT

6. ვალოგირებთ კავშირებს რომლებიც მოხვდნენ SSH_ATTACKED ჯაჭვში, ვუგზავნით მათ (r)syslog სერვერს პრიორიტეტით 7 (ლოგირებას განვიხილავთ ქვევით):

 iptables -A SSH_ATTACKED -j LOG --log-prefix "SSH Attack Detected:" --log-level 7

7. ვაჭრით მთლიანად SSH_ATTACKED ჯაჭვში არსებულ კვაშირებს და ვბლოკავთ ახალ კავშირს იგივე IP მისამართიდან 60 წამის განმავლობაში.

 iptables -A SSH_ATTACKED -j DROP

ამის შემდეგ ვინახავთ ცვლილებებს ბრძანებით:

 service iptables save

გადავტვირთოთ სერვისი ბრაძანებით:

 service iptables restart

iptable მუშაობს სტრიქონის რიგითობის მიხედვით, განვიხილოთ შემდეგი მაგალითი:
1.  iptables -A INPUT -p tcp -m state -m tcp –dport 22 –state NEW -j DROP
2.  iptables -A INPUT -p tcp -m state -m tcp –dport 22 –state NEW -j ACCEPT
მოცემულ შემთხვევაში პირველი წესი ბლოკავს 22-ე პორტს და მეორე წესი აღებს აღნიშნულს
ამ შემთხვევაში 22-ე პორტზე შემოსული მოთხოვნა ჯერ გაივლის პირველ წესს და აღარ გადავა მომდევნო წესზე, რადგან იგი პირველივე წესზე დაიბლოკება, იმისთვის რომ ჩვენმა SSH წესმა (chain SSH_CHECK) გამართულად იმუშაოს საჭიროა ის იყოს რიგობრივად უფრო მაღლა ვიდრე “ACCEPT 22 ” (ეს წესი ნაგულისხმევად არსებოსბს iptables-ში, რათა თქვენ შეძლოთ ssh ით სერვერზე შესვლა).

სურათზე მეტი თვალსაჩონოებისთვის ნაჩვენებია webmin პროგრამული უზრუნველყოფის ეკრანის ანაბეჭდი (აღნიშნული  საშუალებას გვაძლევს გრაფიკულ რეჟიმში სინტაქსის ცოდნის გარეშე ვმართოთ iptables წესები.)

ლოგირება

რაც შეეხება ლოგირებას, მნიშვნელობა არა აქვს რა log სერვერს იყენებთ, (კონკრეტული შემთხვევა აღწერილი იქნება rsyslog სერევრიუს მაგალითზე) iptables-მა გადასცა შეტყობინებები  სისტემის ბირთვს (kernel) პრიორიტეტით 7  , აღნუიშნული პრიორიტეტი, სტანდარტულ კონფიგურაციაში არ  არის გამიჯნული და გაწერილია როგორც ნაგულისხმევი (kern.*) , ჩვენ ორი არჩევანი გვაქ :  ჩავწეროთ kern.7-ზე შემოსული ლოგები და მათ შორის iptables შეტყობინებები /var/log/firewall.log ფაილში ან დავიჭიროთ ლოგის პრეფიქსის მიხედვით  და ცალკეული iptables წესისთვის ინდივიდუალური ლოგ ფაილები შევქმნათ.

პირველის შემთხვევაში ლოგ ფაილში მოხვდება არამარტო iptables შეტყობინებები არამედ ყველა ის სერვისიბი/დემონები რომლებიც აგზავნაინ შეტყობინებებს პრიორიტეტით  7. შედეგად მივიღებთ ფართო დიაპაზონის ლოგ ფაილს სადაც კითხვადობა იქნება გაძლნელებული.

 kern.7  /var/log/firewall.log

მეორე პარამეტრი უფრო მოხერხებულია გვაძლევს რა “წმინდა ლოგებს ” :) ამიტომ ჩვენი არჩევანიც მასზე შეჩერდება. სტანდარტულად (r)syslog კონფიგურაციის ფაილი ინახება /etc/rsyslog.conf ვარედაქტირებთ ფაილს და ბოლოში ვამატებთ:

 :msg, contains, "SSH Attack Detected" -/var/log/iptables-ssh.log
& ~

ვინახავთ და ვტვირთავთ ლოგ სერვერს ცვლილებების მისაღებად:

service rsyslog restart

მოვახდინოთ ssh შეტევის სიმულაცია მეზობელი კომპიუტერიდან რომლის IP მისამართი დავუშვათ არის: 192.168.1.4 (1 წუთის განმავლობაში 4 ჯერ სცადეთ დაკავშირება თქვენ სერევრთან აღნიშნული IP დან SSH ზე არასწორი პაროლით). მეოთხე ცდა წარუმატრებელი იქნება თქვენთვის და ვეღარ შეძლებთ დაკავშირებას სერვერთან 1 წუთის განმავლობაში, დროა შეამოწმოთ /var/log/iptables-ssh.log ფაილი, მას ექნება მსგავსი შიგთავსი:

Oct 15 15:15:33 sysadmin.softgen.ge kernel: SSH Attack Detected:IN=lo OUT= MAC=D8:D3:85:7E:8F:B7
SRC=192.168.1.4 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=10378 DF PROTO=TCP
SPT=50061 DPT=22 WINDOW=32792 RES=0x00 SYN URGP=0

სასჯელ აღსრულება

ვბლოკავთ შემტევის IP  მისამართ(ებს) სამუდამოდ :)

iptables -A INPUT -s 192.168.1.4 -j DROP

ზემოთ აღნიშნული გადაწყვეტილება:  1) მნიშვნელოვანად ამცირებს  მსხვერპლად ყოფნის საფრთხეს;  2) გვაძლევს ინფორმაციას  შემტევზე; 3) შეგვიძლია სერევრის  სრული ისზოლირება შეტევებისაგან.