Friday, January 3, 2020

ქსელური უსაფრთხოების ბანალური შეცდომები

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

 

მონაცემების ქსელში ღია სახით გადაცემა

ერთ-ერთი ყველაზე ხშირი და ამავე დროს ელემენტარული შეცდომაა. ჯერ კიდევ არსებობს უამრავი პროტოკოლი, რომელიც ღია დაუშიფრავი სახით გადასცემს ქსელში ინფორმაციას (HTTP,  LDAP, Telnet, საფოსტო პროტოკოლები შიფრაციის გარეშე). ღია არხით გადაიცემა მათ შორის მომხმარებელთა იუზერები და პაროლები და სხვა საიდუმლო ინფორმაციაც, რომლიც წაკითხვა ბოროტმოქმედისთვის ძალზედ ადვილია.  ღიად ინფორმაციას შეიძლება გადასცემდეს:
                ვებ-სერვერი - ამ შემთხვევაში საჭიროა HTTP-დან HTTPS-ზე გადასვლა. კომპანიის შიდა რესურსებისთვის დასაშვებია გამოიყენოთ თქვენს მიერვე ხელმოწერილი სერტიფიკატები, რომლებიც შემოწმდებიან სერტიფიკაციის შიდა სისტემის მიერ.  საზოგადოებისთვის ხელმისაწვდომი საიტებისთვის ჯობია გამოიყენოთ სანდო ცენტრების მიერ გამოშვებული სერტიფიკატები.
                LDAP .  LDAP პროტოკოლის გამოყენებისას ჯობია გამოიყენოთ აუთენტიფიკაცია Kerberos-ის მეშვეობით. ასევე ჩართოთ LDAPS და კლიენტები მომართოთ TLS-ის გამოყენებაზე LDAP სერვერისთვის მიმართვის დროს.  მაიკროსოფტმა საკმაოდ დეტალური ინსტრუქცია მოამზადა ამ საკითხზე.
                საფოსტო კლიენტები. კლიენტების (და სერვერების) პარამეტრებში TLS-ის დაყენება. სტანდარტული POP3, IMAP, SMTP პორტების გამოყენების ნაცვლად გამოიყენეთ დაცული პორტები თქვენი პროვაიდერის ინსტრუქციების თანახმად. თუ რაღაც მიზეზების გამო პროვაიდერი არ გაძლევთ ასეთ შესაძლებლობას ჯობია დაფიქრდეთ მის შეცვლაზე.
                Telnet.  აქ ყველაფერი მარტივია. ტელნეტის გამოყენებაზე საერთოდ უნდა თქვათ უარი და გადახვიდეთ SSH-ზე
                FTP. FTP-ს საჭიროების შემთხვევაში უნდა  გადახვიდეთ FTPS - ეს არის FTP  SSL პროტოკოლის გამოყენებით. სიტუაცია სერტიფიკატებთან აქ იგივეა, როგორიც ვებ-სერვერების შემთხვევაში. თუ FTP სერვერზე პარალელურად ssh წვდომაც გაქვთ შეგიძლიათ  გამოიყენოთ SFTP, რომელიც ზუსტად რომ ssh არხს იყენებს. შესაბამისად ნაკლები კონფიგურაცია მოგიწევთ

რემოუთ წვდომის უტილიტების გამოყენება

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

LLNMR და NetBios

ეს ორი პროტოკოლი საშუალებას აძლევს ბოროტმოქმედს ჩაატაროს MITM (man in the middle) შეტევა. საქმე იმაშია რომ აღნიშნული პროტოკოლები იძლევიან საშუალებას DNS სერვერის გარეშეც კომპიუტერებმა ბროადქასთ რექვესტების მეშვეობით დაარეზოლვონ „მეზობელი“ კომპიუტერები. შიდა ქსელში აღმოჩენილი ბოროტმოქმედი უპასუხებს ბროადქასტ რეკვესტს და გადაამისამართებს შესაბამის მოთხოვნებს თავის კონტროლირებად სერვერზე. ასეთი გზით ბოროტმოქმედს პრაქტიკულად ნებისმიერი ინფორმაციის მიღება შეუძლია.
LLNMR გათიშვა შეიძლება პოლიტიკით Turn Off Multicast Name Resolution, რომელც განლაგებულია Computer Configuration -> Administrative Templates -> Network -> DNS Client. პოლიტიკის ამუშავებისთვის მინი მნიშვნელობა უნდა იყოს:  Enabled
Netbios -ის გასათიშად  გამოიყენეთ dhcpmgmt.msc. Server Options: ჩანართ Advanced -> Microsoft Windows 2000 Options -> Microsoft Disable Netbios Option.  დააყენეთ მნიშვნელობა 0x2.


NetBios -ის გათიშვა შეიძლება ასევე Powershell-ის სკტიპტის მეშვეობით ჯგუფური პოლიტიკების დამხარებით. სკრიპტი ასე გამოიყერება:
$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose}

როგორც ხედავთ NetBios გათიშვა შეიძლება უშუალოდ  რეესტრიდანაც:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces -ში NetbiosOptions 2-ზე გადაყვანით.

სანამ ამ ორი პროტოკოლის გლობალურ გათიშვას გადაწყვეტთ დარწმუნდით რომ კორპორატიული სოფტიდან არც ერთი არაა დამოკიდებული ამ პროტოკოლებზე. გარდა ამისა თუ ქსელში ჯერ კიდევ შემორჩენილია Windows XP ან Windows 2000 ჯობია ეს პროტოკოლები არ გათიშოთ. (ჯერ აღნიშნული კომპიუტერების შეცვლა იქნება უპირველესი ამოცანა)

ქსელის კონფიგურაციის შეცდომები

საბნეტებს შორის ზედმეტად მაღალი ნდობის შემთხვევაში ბოროტმოქმედმა საკმარისია ერთ-ერთი მაინც ჩაიგდოს ხელში, რომ მთელი ქსელი და სერვერები კონტროლზე აიყვანოს.  საბნეტებს შორის შესაძლებელია ACL (access control list) პოლიტიკების გაწერა (მართალია ამისთვის ტპ-ლინკის დონის აპარატურა არ გამოგადგებათ).
შიდა რესურსების წვდომა გარე DNS სერვერებთან საჭიროების გარეშე. თუ ქსელში არსებობს შიდა DNS სერვერი  და დომენური სახელების სისტემა მნიშნველოვანია რომ შესაბამისი ინფორმაცია დამუშავდეს მხოლოდ შიგნით და ამ მიზნებისთვის არ იყოს ხელმისაწვდომი public DNS სერვერები.
და რა თქმა უნდა საჭიროების გარეშე გახსნილი ქსელური პორტები და სერვისები. აქაც ჯობია იმოქმედოთ თეთრი სიის პოლიტიკით. გახსნილი პორტები და სერვისები სახელდობრ უნდა იყოს აღწერილი, ყველაფერი დანარჩენი კი დახურული
სასურველია იუზერებს აუკრძალოთ თავისი ქსელური პარამეტრების შეცვლა შემდეგი პოლიტიკით: User Configuration -> Administrative Templates -> Network -> Network Connections.

ტრაფიკის დამალვა

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

No comments:

Post a Comment