ქსელები და სერვერები · მონიტორინგი და Linux
როგორ მიგვიყვანა ქსელის რუკაზე შემთხვევითმა გაფრთხილებამ ქსელური შტორმის გამოძიებამდე და უცნობი ადმინისტრატორის აღმოჩენამდე
მაშინ ქსელის მონიტორინგის პორტალზე მუშაობას ახლახან ვიწყებდი. ერთ-ერთი პირველი შემოწმება ცენტრალური ქსელური მოწყობილობის პროცესორის დატვირთვას ადევნებდა თვალს: როცა ის ზღვარს გადააჭარბებდა, რუკაზე მოწყობილობის გვერდით წითელი ძახილის ნიშანი ჩნდებოდა.
მეტი არაფერი ხდებოდა. მონიტორინგი ასეთ გაფრთხილებებს ჯერ ინციდენტებად არ ინახავდა და არავის აცნობებდა. დატვირთვა შეიძლებოდა რამდენიმე წუთით აწეულიყო და შემდეგ გამოკითხვამდე დამშვიდებულიყო, ნიშანი კი უკვალოდ ქრებოდა. ერთხელ, რუკაზე მუშაობისას, ის სრულიად შემთხვევით შევნიშნე. სწორედ აქედან დაიწყო გამოძიება.
გადატვირთვის დროს
რამდენიმე წუთის შემდეგ
მოვლენების ჟურნალიცარიელია
პირობითი სქემა და გამოგონილი დატვირთვის მნიშვნელობა. მონიტორინგის ადრეულ ვერსიაში გაფრთხილება მხოლოდ ეკრანზე არსებობდა: როგორც კი დატვირთვა ნორმას უბრუნდებოდა, მისგან არაფერი რჩებოდა.
შემოწმებამ აჩვენა, რომ უჩვეულო ტრაფიკი ერთი კლიენტის სეგმენტიდან მოდიოდა. შტორმი ტალღებად მოდიოდა: აფეთქება, სიმშვიდე, ისევ აფეთქება. ტალღებს შორის ყველაფერი ნორმალურად ჩანდა, ამიტომ ნიშნის გამოტოვება ადვილი იყო.
ქსელური შტორმი სადარბაზოს საერთო ჩატს ჰგავს, სადაც ვიღაც ერთსა და იმავე შეტყობინებას ისევ და ისევ აგზავნის, ხოლო ყველა, ვინც მას მიიღებს, ისიც ყველას უგზავნის. ერთ წუთში ჩატის კითხვა შეუძლებელი ხდება, საჭირო შეტყობინებები კი ნაკადში იკარგება. ქსელში შეტყობინებების ნაცვლად პაკეტებია, რომლებიც ერთდროულად ყველასთვისაა განკუთვნილი. ყველა მოწყობილობა ვალდებულია მიიღოს და დაამუშაოს ისინი, ცენტრალური მოწყობილობა კი პროცესორს სასარგებლო საქმის ნაცვლად ნაგავზე ხარჯავს.
მასშტაბი სექტემბრის ერთმა შემოწმებამ კარგად აჩვენა. სეგმენტისკენ მიმავალი პორტი შუალედური შეზღუდვებით ცოტა ხნით ჩაირთო და დაახლოებით სამ წამში მასში 3 478 763 პაკეტი შემოვიდა. მათგან კონკრეტულ მიმღებს მხოლოდ 64 ეკუთვნოდა, დანარჩენი ფართომაუწყებლობითი და ჯგუფური გზავნილები იყო.
ვეძებდი ქსელის ცენტრიდან კიდისკენ. გზაზე ყველა მოწყობილობაზე ვამოწმებდი, რომელ პორტში შემოდის ყველაზე დიდი ნაკადი და რომლიდან გადის შემდეგ, ხოლო მეზობლების მონაცემებით ვარკვევდი, რა არის ამ პორტზე მიერთებული. ჯაჭვი აგრეგაციის კომუტატორის პორტზე დასრულდა, რომლის მიღმაც კლიენტის ქსელი იწყებოდა — მმართველი კომპანიისა, საკუთარი აღჭურვილობით.
გაფრთხილების ზღვარი
ტალღების ფორმა პირობითია და მხოლოდ შტორმის ხასიათს აჩვენებს. ნამდვილი ციფრები ქვემოთ, ბარათებშია.
ჩვენი მხრიდან არ ჩანდა, როგორ იყო კლიენტის ქსელი შიგნით მოწყობილი. ამიტომ პირველ რიგში ეს პორტი გამოირთო და შტორმმა დანარჩენ ქსელამდე მიღწევა შეწყვიტა. სეგმენტი გათიშული რჩებოდა, სანამ თავად კლიენტის მოწყობილობაზე გარკვევის შესაძლებლობა არ გაჩნდა.
სექტემბერში საცდელმა ჩართვამ აჩვენა, რომ შტორმი ისევ ადგილზე იყო. შუალედურმა შეზღუდვებმა ის ვერ შეაჩერა: დაახლოებით სამ წამში კომუტატორის მართვის სესიაც კი აირია, და წინასწარ გახსნილმა საავარიო კავშირმა პორტი მაშინვე გამორთო. ამის შემდეგ პორტის უბრალოდ ხელახლა ჩართვა აღარ შეიძლებოდა.
ამის შემდეგ პორტი მხოლოდ კარანტინში ირთვებოდა: ერთი სამსახურებრივი ქსელი, დაახლოებით 512 კბიტ/წმ სიჩქარე, დაახლოებით ას პაკეტზე მეტი არა წამში თითოეული სახის გზავნილისთვის, ფილტრი სამი ცნობილი მოწყობილობისთვის, მზა საავარიო სესია და ტაიმერი, რომელიც პორტს თავად გამორთავდა. ჯერ 6–40 წამიანი ფანჯრები, შემდეგ 15 და 30 წუთიანი. ერთ 40-წამიან ფანჯარაში პორტზე 85 975 პაკეტი მოვიდა, ქსელში კი შემდეგ არაფერი გავიდა.
კლიენტის MikroTik-ს, საიდანაც შტორმი მოდიოდა, მმართველი კომპანიის მხრიდან სხვა სისტემური ადმინისტრატორი ემსახურებოდა. შემდეგ ერთად ვარკვევდით: მე ჩვენს პორტზე კარანტინს ვინარჩუნებდი და წვდომის ფანჯრებს ვხსნიდი, ის კი თავად მოწყობილობასა და მის ქსელზე იყო პასუხისმგებელი.
კარანტინში მარშრუტიზატორმა ბოლოს და ბოლოს უპასუხა: ping დანაკარგის გარეშე გადიოდა, SSH პაროლს ითხოვდა. მაგრამ შესვლა ვერ მოხერხდა — ცნობილი პაროლები არ გამოდგა. შემდგომი შერჩევა აღარ განვაგრძე: მოწყობილობა სხვისია და მასზე გადაწყვეტილება მისმა მფლობელმა უნდა მიიღოს. შემდეგი ფანჯარა, ახალი პაროლით, ვადაზე ადრე დავხურე: დაცვის შემოწმება დადგენილ დროში ვერ დასრულდა, უმცირესი ეჭვის დროს კი პორტი გამორთული უნდა დარჩეს.
საბოლოოდ შევთანხმდით, რომ მოწყობილობა ქარხნულ პარამეტრებზე დაბრუნებულიყო. სამუშაოების დროს კლიენტის ქსელი სხვა პორტზე დროებითი როუტერით ჩაირთო. ქარხნულ პარამეტრებზე დაბრუნებამდე MikroTik-ის მომხმარებლების სიაში აღმოჩნდა ანგარიში System სრული უფლებებით — მოწყობილობაზე პასუხისმგებელთაგან ის არავის შეუქმნია. მისით ბოლო შესვლა 2026 წლის 1 მაისით იყო აღნიშნული — მეორე დღეს მას შემდეგ, რაც შტორმი პირველად დაფიქსირდა.
ქარხნულ პარამეტრებზე დაბრუნების შემდეგ კლიენტის ადმინისტრატორმა MikroTik ხელახლა ააწყო, ჩვენი პორტი კი ახალი მიერთებების ცალკე ქსელში გადავიდა, სადაც მოწყობილობა მისამართს ავტომატურად იღებს და ძველ პარამეტრებს თან არ იყოლიებს. დაკვირვების განმავლობაში შტორმი აღარ დაბრუნებულა. მეორე დღეს ინტერნეტი ახალი გზით ამუშავდა და დროებითი როუტერი გამოირთო.
მარშრუტიზატორის მართვის სტილიზებული ფანჯარა: მომხმარებლების სია, მათ შორის უცნობი ანგარიში System ჯგუფში full სრული უფლებებით.
სტილიზებული ფრაგმენტი გამოგონილ მონაცემებზე. ნამდვილ მოწყობილობას მხოლოდ სახელი System და ჯგუფი full ემთხვევა; სახელები, დრო და კომენტარები გამოგონილია.
როგორ დაიწყო ყველაფერი, ზუსტად ვერ გავარკვიეთ. გაურკვეველი დარჩა, იყო თუ არა შტორმი და ანგარიში System ერთმანეთთან დაკავშირებული. ცნობა იმის შესახებ, რომ System ქარხნულ პარამეტრებზე დაბრუნების შემდეგ ისევ გაჩნდა, არ არსებობს.
როუტერი ნათურებიან ყუთს ჰგავს, მაგრამ შიგნით მას ოპერაციული სისტემა, პროგრამები და ანგარიშები აქვს — თითქმის ისე, როგორც კომპიუტერს. სადაც პროგრამებია, იქ შეცდომებიცაა, რომელთა გამოყენებითაც უცხო ადამიანს შეუძლია შეაღწიოს ან იმაზე მეტი უფლება მიიღოს, ვიდრე ეკუთვნის. ამიტომ ასეთი მოწყობილობებიც უნდა განახლდეს და მათი მართვა მთელი ინტერნეტისთვის არ უნდა იყოს ღია.
2026 წლის შემოდგომაზე MikroTik-მა RouterOS-ის რამდენიმე მოწყვლადობის გამოსწორება ერთად გამოუშვა. მათ შორის იყო SSH-ის შეცდომები, რომლებიც ერთად მოწყობილობაზე სრული კონტროლის მოპოვების საშუალებას იძლეოდა. CERT Polska-მ 5 სექტემბერს ნამდვილი შეტევების შესახებ გამოაცხადა, სულ მცირე 2 სექტემბრიდან: გატეხილ როუტერებზე თავდამსხმელები საკუთარ ანგარიშს ქმნიდნენ. სექტემბრის ბოლოს ამერიკულმა სააგენტო CISA-მ გამოაქვეყნა გაფრთხილება კიდევ ერთი კრიტიკული მოწყვლადობის შესახებ — ვებ-მართვის ინტერფეისში.
ჩვენი მოვლენები გაზაფხულზე მოხდა, ამ პუბლიკაციებამდე რამდენიმე თვით ადრე, ამიტომ მათი რომელიმე კონკრეტული მოწყვლადობისთვის მიწერა არასწორი იქნებოდა. როგორ აღმოჩნდა System მოწყობილობაზე, უცნობია. მაგრამ ეს ისტორია კარგად აჩვენებს, რატომ მოითხოვს ქსელურ მოწყობილობაზე უცხო ანგარიში ქარხნულ პარამეტრებზე დაბრუნებას და არა ერთი ხაზის წაშლას: წინასწარ არ იცი, კიდევ რა შეცვალეს.
წყაროები: MikroTik — უსაფრთხოების ბიულეტენები · CERT Polska, 2026 წლის 5 სექტემბერი · CISA ICSA-26-272-06, 2026 წლის 29 სექტემბერი
პირველი მონიტორინგი მხოლოდ მიმდინარე მდგომარეობას აჩვენებდა: რა ხდება ამ წუთში. ტალღებად მომავალი შტორმისთვის ეს ცოტაა. გაფრთხილება დატვირთვასთან ერთად ქრებოდა და თუ ამ დროს რუკას არავინ უყურებდა, თითქოს პრობლემა არც ყოფილა. ნიშანი შემთხვევით დავინახე — ესე იგი, შეიძლებოდა ვერც დამენახა.
აქედან გასაგები გახდა, რომ მონიტორინგს მეხსიერება სჭირდება. მოვლენა უნდა შეინახოს მაშინაც, როცა ყველაფერი უკვე დამშვიდდა: როდის დაიწყო, რამდენ ხანს გაგრძელდა, განმეორდა თუ არა. ამის შესახებ ადამიანს უნდა ეცნობოს, აღდგენის შემდეგ კი უნდა შემოწმდეს, რომ ყველაფერი მართლაც ნორმას დაუბრუნდა.
პორტალი თანდათან იზრდებოდა. გამოძიებისთანავე აღჭურვილობამ თავად დაიწყო პროცესორის დატვირთვისა და ტრაფიკის სურათების შენახვა, როცა ისინი ზღვარს გადააჭარბებდნენ — რომ შემდეგი ტალღა ხელით არ ყოფილიყო დასაჭერი. შემდეგ გაჩნდა ისტორიის მქონე ინციდენტები: განმეორებული პრობლემა არსებულ ინციდენტს აბრუნებს და ახლებს არ აჩენს. შემდეგ — შეტყობინებები ინჟინერს MAX-ში, ცალკე შეტყობინება აღდგენისას, ავტომატური დახურვა მხოლოდ მდგრადი ნორმალური მუშაობის შემდეგ და გარე შემოწმება, რომელიც შეგვატყობინებს, თუ თავად პორტალია მიუწვდომელი. ხატულებიანი მარტივი რუკა სისტემად იქცა, რომლითაც შეიძლება აღადგინო, რა და როდის მოხდა.
მაშინ: მხოლოდ ახლა
ახლა: მოვლენა ისტორიით
პროცესორის მაღალი დატვირთვა · ქსელის ცენტრი
დღე-ღამეში სამი აფეთქება ისტორიაში შენახულია
დრო, ხანგრძლივობა და განმეორებების რაოდენობა გამოგონილია; ბარათი აჩვენებს, რა ინახება ახლა მოვლენის შესახებ.
სამუშაოს მეორე ნაწილი Linux-სერვერებია, რომლებზეც პორტალი, ბილინგი და ფონური ამოცანები მუშაობს. აქაც მსგავსი ხაფანგია: სერვერი ping-ს პასუხობს, SSH-ით უპრობლემოდ შედიხარ, ამასობაში კი რომელიმე სერვისი ან განრიგით გაშვებული ამოცანა ისე არ მუშაობს, როგორც საჭიროა.
პორტალში ერთ-ერთი მოწყობილობის ბარათზე პორტების მდგომარეობის ნაცვლად ზოგჯერ რამდენიმე წუთით კითხვის ნიშნები ჩნდებოდა. ამასთან მოწყობილობა კავშირზე იყო, ხოლო ამოცანა, რომელიც პორტების მდგომარეობას აგროვებს, ყოველ ჯერზე წარმატებით სრულდებოდა.
ამოცანა განრიგში ყოველ ოთხ წუთში ერთხელ იდგა, საათის მეოთხე წუთიდან დაწყებული: 04, 08 და ასე 56-მდე. 56-ე წუთის შემდეგ მომდევნო გაშვება მხოლოდ შემდეგი საათის 04 წუთზე იყო — თითქმის რვა წუთი და არა ოთხი. პორტების მონაცემები ხუთი წუთის განმავლობაში ითვლება ახლად, ამიტომ საათში ერთხელ ისინი ძველდებოდა, თუმცა არც ერთი გაშვება შეცდომით არ სრულდებოდა.
ეს გაშვებების ისტორიამ გამოააშკარავა: ორ მეზობელ გაშვებას შორის 479,7 წამი გავიდა. გამოსწორება განრიგის ერთი ხაზი იყო: გაშვებები 01, 05 … 57 წუთებზე გადავიდა და ბიჯი ზუსტად ოთხი წუთი გახდა, საათის საზღვარზეც. სიახლის ვადა არ გამიზრდია. ამოცანა მხოლოდ მას შემდეგ დავხურე, რაც ნამდვილმა გადასვლამ 11:57 → 12:01 მოძველებული მონაცემების გარეშე ჩაიარა.
შკალა წუთებშია, მასშტაბი პირობითია. რვა წუთი და ხუთწუთიანი სიახლე ამ შემთხვევის ნამდვილი მნიშვნელობებია.
ვირტუალიზაციის სერვერების ახალ ვერსიამდე განახლებამ გეგმის მიხედვით ჩაიარა: კვანძები გადაიტვირთა, ვირტუალური მანქანები ჩაირთო, SSH პასუხობდა. ბილინგი კი არ მუშაობდა. ახალმა ვერსიამ მისი ვირტუალური მანქანა სხვა ტიპის ვირტუალური „აპარატურით“ გაუშვა, ბილინგის ლიცენზია კი აპარატურაზეა მიბმული — და სისტემამ მანქანა უცხოდ ჩათვალა. ლიცენზია უარყოფილ იქნა, ხოლო სერვისები, რომლებიც ავტორიზაციასა და ტრაფიკის აღრიცხვას ამუშავებს, ისევ და ისევ ლიცენზიის ერთი და იმავე შეცდომით სრულდებოდა. გაშვების სისტემა მათ ხელახლა რთავდა, ისინი კი ისევ ვარდებოდა.
კიდევ ერთხელ გადატვირთვას აზრი არ ჰქონდა: მიზეზი ადგილზე რჩებოდა და ყოველი ახალი გაშვება ისევე სრულდებოდა. თავად მიზეზის გამოსწორებამ უშველა. ამ მანქანისთვის ვირტუალური აპარატურის წინა ტიპი დავაფიქსირე, სალიცენზიო ჩანაწერი სამუშაოებამდე გაკეთებული ბაზის ლოკალური ასლიდან აღვადგინე და ბილინგის მთავარი სერვისი ერთხელ გადავტვირთე. ლიცენზია მიღებულ იქნა და აბონენტების სესიები ისევ აღირიცხებოდა. იმ დღეს ავტორიზაცია და ტრაფიკის აღრიცხვა დაახლოებით ერთი საათი არ მუშაობდა.
ამ ისტორიას გაგრძელებაც ჰქონდა: აღდგენის შემდეგ ზოგიერთ აბონენტს ბილინგში გაჭედილი სესიების გამო დაკავშირება არ შეეძლო. ამაზე ცალკე განხილვაა →
რას ვამოწმებ განახლების შემდეგ
ყველაფერი პატარა წითელი ნიშნით დაიწყო, რომელიც რამდენიმე წუთში უკვალოდ გაქრებოდა. იმ წამს რომ რუკისთვის არ შემეხედა, შტორმი კიდევ რაღაც ხანს ტალღებად მოვიდოდა, კლიენტის როუტერზე უცნაური ანგარიში კი, შესაძლოა, შეუმჩნეველი დარჩენილიყო.
მას შემდეგ მონიტორინგს სხვაგვარად ვუყურებ. მიმდინარე მდგომარეობის ჩვენება მხოლოდ დასაწყისია. მთავარია მოვლენის შენახვა, ადამიანისთვის შეტყობინება და იმის შემოწმება, რომ აღდგენის შემდეგ ყველაფერი მართლაც მუშაობს. იმ შემთხვევით ნიშანს დღემდე ვიხსენებ, როცა პორტალში ახალ შემოწმებას ვამატებ.