ასეთ მნიშვნელობას მიიღებთ თუ firebug-ით ნახახავთ GET / მოთხოვნის პასუხს.

მეხუთე სქტრიონზე ავღწეროთ 80 პორტი, წეს დავარქვათ “http“, შემდეგ დაგვჭირდება წვდომის გასაწერად. ავღწეროთ cache_peer,მივანიჭოთ შიდა მისამართი და გავუკეთოთ ჭდე “name“, ამ შემთხვევაში windows_srvs და linux_srvs. შემდეგ ავღწეროთ რომელი საიტები შედის linux_sites-ის ჯგუფში, ჩვენს შემთხვევაში ეს არის ცალკე ფაილი, საიტები შეგვიძლია ნებისმიერ დროს დავამატოთ აღნიშნულ ფაილში (/etc/squid/linux_sites), ისე, რომ სქვიდის კონფიგურაციას არ შევეხოთ ახალი საიტის დამატებისას, ამის შემდეგ როდესაც საიტები, http პორტი და საწყისი სერვერები აღწერილი გვაქ, ვწერთ მარტივ წესს:

cache_peer_access linux_srvs allow http linux_sites

, ამ წესის მიხედვით ის საიტები, როემლებიც გვიწერია /etc/squid/linux_sites – ფაილში მოხვდება მხოლოდ linux_srvs -სერვერზე, რომლის IP მისამართია: 192.168.1.11. ანალოგირად ვაკთებთ windows-საიტებისთვის.

http_port 91.212.213.2:80 accel defaultsite=accel.anydomain.ge vhost

visible_hostname accel.anydomain.ge



acl http myport 80 # �� ���������� ������ myport-� �� ���������� �������.



cache_peer 192.168.1.10  parent 80 0 no-query originserver login=PASS name=windows_srvs

cache_peer 192.168.1.11  parent 80 0 no-query originserver login=PASS name=linux_srvs



acl linux_sites dstdomain url_regex -i "/etc/squid/linux_sites"

cache_peer_access linux_srvs allow http linux_sites



acl win_sites dstdomain url_regex -i "/etc/squid/win_sites"

cache_peer_access windows_srvs allow http win_sites

ყურადღება: ამ პოსტში განხილული იყო მხოლოდ HTTP ტრაფიკის გამიჯვნა საწყისი სერვერების მიხედვით, თუ თქვენ აპირებთ HTTPS ტრაფიკის “დაპროსქსვას” ამ შემთხვევაში გაითვალისწინეთ, რომ ორივე სერტიფიკატი (public & private) უნდა დაყენედეს რევერს პროქსიზე, სხვანაირად უბრალოდ არ იმუშავებს.

პ.ს. https-ის თემას დავუბრონდებით მომდევნო პოსტებსში.

ეს შეტევა დაფუძვნებულია TCP კავშირის დამყარების პრინციპზე, როდესაც თქვენ შედიხართ ბროუზერით ვებ-გვერდზე – თქვენ აგზავნით SYN (synchronize) პაკეტს სერვერზე, სერვერი კი ამ დროს იმყოფება Listening რეჟიმში და უსმენს კონკრეტულ პორტს, როდესაც სერვერი მიიღებს თქვენს SYN პაკეტს ის პასუხობს SYN-ACK (synchronize acknowledged) პაკეტით და გიგზავნით ისევ თქვენ, რაც ნიშნავს, რომ მოთხოვნა სინქრონიზაციაზე მიღებულია, ამის შემდეგ თქვენ აგზავნით პროცედურის დამასრულებელ პაკეტს – ACK (acknowledge) სერვერთან და ნანატრი TCP კავშირი დგება თქვენს და დაშორებულ სერვერს შორის, სინამდვილეში ეს ისე სწრაფად ხდება, რომ თქვენ გაანალიზებას ვერ ასწრებთ გვერდი ისე იტვირთება თქვენს ბოუზერში. სწორედ ამას ეწოდება “TCP 3-Way Handshake” კავშირი ან ქართულად “სამგზის კავშირი” :), ამ სამგიზს კავშირიდან თითოეული პროცესი ექვემდებარება გარკვეულ კრიტრერიუმებს მაგ: განსაზღვრულია კავშირის ვადა (time-out).

1. client——-syn——->>web server
2. client<<—syn-ack—–web server
3. client——-syn——>> web server

SYN შეტევებში არსებობს  2 ტიპის შეტევა syn-flooding, როდესაც სერვერს ვალოდინებთ პასუხის გაცემაზე და syn-spoofing ამ დროს პასუხის მიღებისას “ვემალებით” სერვერს. ანუ ვცვლით სორს მისამართს და აგონიაში მყოფი სერვერი აგზავნის პაკეტებს არარსებულ იპ მისამართებზე.

I syn-flooding (direct attack)

განვიხილოთ ჩვეულებრივი syn-flood-ის სცენარი. (შედარებით მარტივი განსახორციელებელია)
წარმოიდგინეთ რა მოხდება თუ გავუგზავნით სერვერს  SYN პაკეტს შემდეგ სერევრი გამოგიგზავნით  SYN-ACK -ს და თქვენ აღარ გაუგზავნით დამასრულებელ ACK, ამ დროს ამოქმედდება პარამეტრი fin_timeout რომელიც დაელოდება მინიჭებულ მიშვნელობას მაგ 60 და 60 წამის გასვლის შემდეგ დახურავს ნახევრად ღია კავშირს. აქ კიდევ ერთი ფაქტორია დასაზუსტებელი, კავშირის დამყარების დროს ხდება ამ კავშირის მიერ TCP ბუფერის მეხსიერების რაღაც გარკველული ნაწილის დაკავება. ეხლა უფრო კონკრეტულად შეგვიძლია წარმოვიდგინოთ თუ რა მოხდება როდესაც უამრავ ასეთ ნახევრად-ღია კავშირებს დავამყარებთ? საბოლოოდ გადაივსება backlog, somaxconn, max_syn_backlog  კერნელის პარამეტრები და სერვერი ახალი კავშირის მოთხოვნებს (connection requests) ან რიგში ჩააყენებს (TIME_WAIT) ან სერთოდ ვერ უპასუხებს (Connect TIME_OUT() ).
მაგ: შემტევი ჯუმბერი და მისი მეგობრები აგზავნიან სერვერთან ძალიან დიდი რაოდენობით SYN კავშირებს სანამ არ გადაივსება კერნელის პარამეტრი backlog -ი (ეს პარამეტრი უზრუნველყოფს “ნახევრად-ღია” half-opened კავშირების რიგში ჩაყენებას), როდესაც backlog სავსეა (მას მეხსიერების რაღაც ზომა აქვს გამოყოფილი და ეს პარამეტრი “ტუნინგს” ექვემდებარება და ამას ქვევით განვიხილავთ ) ის სერვერი ვეღარ უმკლავდება ახალ კავშირებს თუნდაც ნორმალურს, შემდეგ უკვე გააჩნია სერვერის კონფიგურაციას, შესაძლებელია კერნელის ქრეშიც, httpd პროცესის გარდაცვალება, ან საიტის დროებით გაჩერება სანამ ნახევრად-ღია კავშირებს ვადა არ გაუვა.

II syn-spoofing

როგორც ზემოთ ავღნიშნეთ ამ დროს სერვერს ეგზავნება syn პაკეტი არარსებული იპ მისამართიდან და სერვერიც ცდილობას უპასუხოს ამ მისამართს, მაგრამ მათ შორის ეს ინტიმური კავშირი არასდროს დამყარდება. ასე რომ კიდევ გარკვეული დროის მონაკვეთი და გარკვეული რესურსის დაკავებით წინ მიიწევს შემტევი ჯუმბერი სანამ სერვერზე არ მოხდება რესურსების გადავსება და შემდეგ მისი თანმხლები პროცესები. ეს არის ყველაზე პრობლემური შეტევა და საკამოდ რთულად განსახორციელებელიც, არსებობს რამოდენიმე მათემატიკური პრობლემა პრობლემა TCP პაკეტის ფორმირებაში და სწორედ ეს არის სორსის “სპუfინგის” არსებობსის გამართლება. თუმცა გამოსავალი ყველაფრიდან არსებოს, syn-spoofing-ის შემთხვევაში ცოტა რთულია software firewall სთხოვო დაგიცვას :) ეფექტურ გამოსავლად შეიძლება ჩაითვალოს უკუღმართი პროქსი :D არ დაიბნეთ revers-proxy -ის თარგმანი გავიფიქრე ხმამაღლა. თუ გავითვალისწინებთ იმას, რომ რევერს პროქსის შეუძლია TCP კავშირი შუაზე “გახლიჩოს”  და ერთი კავშირისგან მიიღოს ორი, ანუ კლიენტს ცალკე კავშირით ელაპარაკოს და სერვერს ცალკე TCP კავშირით; გამოდის, რომ იტისკება პქოქსი – და რა ვებ სერვერი, ეს ნორმალურია TCP კავშირების ჩავვარდნაზე პროქსის 90 პროცენტით ნაკლები რესური ეხარჯება ვიდრე დაუშვად HTTPD სერვერს თავისი თრედებით, შვილობილი პროცესებით და ზარმაცი პროგრამერების გამო მიბმული php ზოოპარკით.
თვალი გადაავლედ შემდეგ მაგალითს და მიხვდებით რა სასარგებლო საქმის გაკეთება შეუძლია რევერს პროქსის content caching ის გარდა, სერვერამდე ვერ აღწევს ვერცერთი spoofed პაკეტი:

attcker—–spoofed-syn———->>proxy
|უსასრულობა|<<—-syn-ack—–proxy——-syn——->>web server
———————————————proxy<<—syn-ack—–web server
———————————————proxy——-ack——->>web server

პრინციპში ჩემი აზრით რევერს პროქსი ყველა ვარიანტში გამართლებული საშუალებაა ვებისთვის.

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

როგორ გავიგო შეტევა ?

გავიგოთ კავშირების რაოდენობა 80-ე პორტზე, განურჩევლად მისი მდგომარეობისა:

 netstat -n | grep :80 | wc -l

გავიგოთ SYN_RECV მდგომარეობაში მყოფი კავშირების რაოდენობა, ეს მნიშვნელოვანია ამ მდგომარეობაში არ უნდა იყვეს ბევრი კავშირი, მაგ:  1000  კლიენტის ერთდროული შემოსვლის დროს ეს პარამეტრი არ უნდა იყვეს 10 ზე მეტი 1 წთ განმავლობაში.

 netstat -n -p | grep SYN_RECV | wc -l 

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

 watch -n0 "netstat -n -p | grep SYN_RECV | wc -l" 

თუ გვინდა ვნახოთ, რომელ IP მისამართს რამდენი კავშირი აქვს გახსნილი სერვერთან აკრიფეთ შემდეგი:

 netstat -ntu | tail -n +3 | awk '{print $5}' | sed -e 's/::ffff://g' \
|cut -d: -f1 | sort | uniq -c | sort -n 

ყურადღება მიაქციეთ თითოეულ IP მისამართზე კავშირების რაიოდენობას, არ უნდა იყვეს საეჭვოზე მეტი, როგორც მარცხნივ სურათზეა ნაჩვენები, 1 IP მისამართისთვის 5610 კავშირი ძალიან ბევრია, თუ თქვენ ვებ გვერდს არ სტუმრობს, რომელიღაც პატარა ჩინური კორპორციის პროქსი სერვერი, რომლის უკან 5000 შრომისმოყვარე ცინელს, რატომღაც ერთდროულად გაუჩნდა თქვენი ვებ გვერდის მონახულების სურვილი. :P

SYN cookies (დაცვა ბირთვის დონეზე)

არსებობს რამოდენიმე დაცვა 2.6.xx კერნელში, რომლებიც გვიცავს ასეთი შეტევებისგან მაგალითად ერთ-ერთი SYN cookies. მისი იდეა მდგომარეობს შემდეგში: როდესაც კლინტი აგზავნის SYN პაკეტს სერვერთან, სერვერი უგავნის SYN + cookies, ანუ პლიუს კიდევ ერთ cookies პაკეტს, და გაგზავნისთანავე წყვეტს კავშირს კლინტთან, შედეგად აღარ არსებობს ნახევრად ღია კავშირები სერვერზე) ანუ აღარ ელოდება შემდეგ საფეხურებს კილინტისგან კავშირის დასამყარებლად. დამატებითი cookies პაკეტი წარმოადგენს, კლინტის მისამართს, კლინტის პორტს, კლინტის თანმიმდევრობას*, სერვერის მისამართს, სერვერის პორტს და + საიდუმლო ჰეშს.

თუ ამის შემდეგ კლინტი გამოაგზავნის ACK პაკეტს, სერვერი თავიდან გამოითვლის cookies მიმდევრობებს  და შეადრებს ემთხვევა თუ არა ძველ გაგაზავნილ SYN-ACK მოთხოვნას. თუ ემთხვევა კავშირი დადგება. რეალურად როგოც ჟღეს ისე ვერ ამართლებს ეს მეთოდი, ამ გამოთვლებსაც ჭირდება cpu რესურსები, და დრო, ბევრ Linux დისტროში ეს პარამეტრი გამორთულია, მაგრამ Feddora 1x -ში ნაგულისხმევად ჩართულია, თუ გადაწყვეტთ ამ პარამეტრის ჩართვას, მოახდინეთ შემდეგი ცვლილებები:

echo "1" > /proc/sys/net/ipv4/tcp_syncookies 

#დროებითი ჩართვა,

ან დაამატეთ ჩანაწერი /etc/sysctl.conf #მუდმივი ჩართვა
net.ipv4.tcp_syncookies = 1

თავდაცვა I -  network tuning

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

1.ნახევრად ღია კავშირების რაოდენობის გაზრდა;
2.ESTABLISHED მდგომარეობაში მყოფი კავშირებსი გაზრდა;
3.ნახევრად-ღია კავშირების ადრე დახურვა; (time-out შემცირება);
4.ლოკალური პორტების დიაპაზონის გაზრდა;
5.TCP ნაკადის მეხსიერბეის ბუფერის გაზრდა;

ვხსნით საყვარელ ტექსტურ რედაქტორში ფაილს: /etc/sysctl.conf
შეგვყავს ქვემოთ ჩამოთვლილი პარამეტრები, ვანიჭებთ სასურველ მნიშვნელობას ან ვტოვებთ უცვლელად.
(ეს პარამეტრები ოპტიმიზირებულია სერვერისთვის, რომლის მეხსიერბა არის 8GB და CPU არის 8-ბირთვიანი)

net.ipv4.ip_local_port_range = 1024 61000
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.ipv4.tcp_fin_timeout = 40
net.core.netdev_max_backlog = 5000
net.core.somaxconn = 10000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_max_syn_backlog = 6144
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_sack = 0
net.ipv4.tcp_syncookies = 0

ვინახავთ და თუ არ გვსურს გადატვირთვა ვუშვებთ ბრძანებას:
sysctl -p
ამის შემდეგ ახალი მნიშვნელობები შევა ძალაში.

თავდაცვა II -  iptables rules

syn-flooding  პირდაპირი შეტევების  დროს,  როდესაც რეალური სორსიდან ცდილობენ შეტევას ამ შეთხვევაში ძალიან ეფექტურია  iptables  თავისი recent და hashlimit მოდულებით, იდეა შემდეგია: თუ შემტევი დაამაყარებს 200 კავშირს სერვერთან ერთი წამის განმავლობაში, მაქსიმალური საწყისი პაკეტების რაოდენობა, რომლებიც დაემთხვევა ამ წესს და ტოლი იქნება 4-ის  დაიდროპება 15 წუთის განმავლობაში, ასევე დალოგირდება შემტევის IP მისამართები.

iptables -N LOGDROP
iptables -A LOGDROP -j LOG --log-prefix "SYN Flood Detected:"  --log-level 7
iptables -A LOGDROP -j DROP
iptables -A INPUT -i eth0  -m recent --name blacklist --rcheck --seconds 900 -j DROP
iptables -A INPUT -i eth0 -p tcp --syn  -m hashlimit  --hashlimit 200/sec \
--hashlimit-burst 4 --hashlimit-htable-expire 300000 --hashlimit-mode srcip \
--hashlimit-name testlimit -j ACCEPT
iptables -A INPUT -i eth0 -m recent --name blacklist --set -j LOGDROP

ამ დროს იბლიოკება მხოლოდ ის IP მისამართები საიდანაც შეტევის მცდელობები იყო განხორციელებული, ჩვეულებრივი IP  მისამართებისთვის სერვერი განაგრძობს მომსახურებას შეუფერხებლად.

დასკვნა

რეალურად თავდაცვის პირველი სცენარიდან გამომდინარე ჩვენ ვზრდით ქსელის გამტარუნარიანობას სერვერზე და შესაბამისად საჭიროა უფრიო მეტი შემტევი რესურსი სერვერის გასაჩერებლად, მეორე ვარიანტი არის თავდაცვა პროგრამული ფაირვოლის დონეზე, რომლიც იმახსოვრებს შემტევის მისამართებს და ბლოკავს მათ გარკვეული ვადით. იყო კიდევ მესამე ვარიანტი – რევერს პროქსი, რომელიც არანაკლებე ეფექტურია spoofing -ის დროს, არ შეიძლება ვინმემ ზუსტად თქვას რომელი ვარინატი ჯობია, ისინი ერთმანეთს არ გამორიცხავენ – შესაძლელებლია სამივე ვარიანტის კომბინაცია და თუ ეს ყველაფერი მძლავს ქსელურ აპარატურასთანა ჰარმონიაში ასეთ შემთხვევაში თქვენ შეგიძლიათ უფრო ეფექტურად გაუმკლავდეთ ამგავარ შეტევებს და გქონდეთ ნაკლები downtime-ი.

Public key cryptography ეს არის ასიმეტრიული ალგორითმების ნაკრები (ცალმხრივი შიფრაციის მათემატიკური მოდელები). გასული საუკუნის 70-იან  წლებში აქტიურად დაიწყო ამ ალგორითმების ციფრულ სამყაროში ინტეგრაცია და დღეისთვის ინფორმაციის დაშიფვრის ყველაზე გავრცელებულ და გამართლებულ მეთოდად ითვლება.  Public key cryptography ყოველთვის შედგება წყვილი, საჯარო და პირადი (public & private) გასაღებებისგან.

როგორი იქნებოდა public key cryptography-ის გამოყენება ჩვეულებრივ ცხოვრებაში? წარმოვიდგინოთ მაგალითი: გამოჩენილი ამერიკელი “წყვილის” ელისის და ბობის მაგალითზე ( Alice & Bob. ამ “წყვილის” სამეცნიერიო ტესტირებაში გამოყენება იმდენად გავრცელებულია, რომ ქართული ანალოგის შექმნა ზედმეტი იქნებოდა).

ელისი უგზავნის ბობს წერილს, რომელსაც ათავსებს ყუთში და ადებს თავის ბოქლომს (public), რომლის გასაღებიც მხოლოდ ელისს გააჩნია, ყუთს კი უგზავნის ბობს ფოსტის მეშვეობით. როდესაც ბობი მიიღებს ყუთს ისიც დაადებს თავის ბოქლომს  და უკან გაუგზავნის ელისს. როდესაც ელისი მიიღებს ყუთს ორი ბოქლომით, მოხსნის თავის ბოქლომს და კვლავ გადაუგზავნის ბობს. ბოლოს კი როდესაც ბობი მიიღებს ყუთს მხოლოდ თავისი ბოქლომით, მას შეუძლია გახსნას ის თავისი გასაღებით და წაკითხოს წერილი ელისისგან.  ამ “ჰეფი ენდს” ალტერნატიული ფინალიც ააქვს რომელსაც ქვია: მელორი, ანუ  ამ სცენარის ერთადერთი სისუტე      – მესამე პირი რომელიც შეიძლება ბობს და ელისს შორის ჩადგეს.  დიახ, დიახ, ბოროტ მელორის შეუძლია ჩადგეს გასაღებების დაგზავნის შუამავლად მაგ: ელისი>>მელორი>>ბობი და  ბობი>>მელორი >>ელისი. ისე რომ ელისმა და ბობმა ეს ვერ გაიგონ .  მელორის ასეთ  სქციელს ეწოდება  Man-in-the-middle attack, თუმცა შესაძლებელია ამის თავიდან აცილება certificate authority იგივე (CA) გამოყენებით (მესამე მხარე რომლიც გადაამოწმებს გამგზავნის და მიმღების იდენტურობას). საჯარო გასაღებებს კიდევ რამოდენიმე სისუსტე გააჩნია, მაგრამ ისინი ისეთი უმნიშვნელო და უწყინარია რომ ამ პოსტში არ განვიხილათ.

ძირითადი მახასიათებლები:

1. public key cryptography ყოველთვის შედგება წყვილი გასაღებებისგან: public, private (საჯარო, პირადი)
2. public key ყველასთვის ხელმისაწვდომია.
3. private key ხელმისაწვდიომია მხოლოდ მფლობელისთვის.
4. public key დაშიფრული ინფორმაციის გაშიფვრა შეუძლია მხოლოდ მის შესაბამის private key-ს და პირიქით.
5. public key მათემატიკურად დაკავშირებულია private key-სთან, მაგარამ პირველიდან მეორეს მღება შეუძლებელია.

ქვემთ მოცემულ სურათში განვიხილოთ შიფრაციის სქემა:

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

აქვე ვგებულობთ, რომ შეტყობინების დაშიფვრა აგრეთვე შესაძლებელი ყოფილა პირადი გასაღებით, რომლის გახსნა მხოლოდ საჯარო გასაღებს შეუძლია. შესაბამისად ბობი ბანალურ მიმართვაზე ბანალურ პასუხს ღებულობს და ორივე ბედნიერია.

გამოყენება

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

ნაგულისხმევად ssh ავტორიზაციის ფაილები და პარამეტრები ინახება მიმდინარე მომხმარებლის დირექტორიაში ~/.ssh , თუ ეს მისამართი თქვენთან არ არსებობს არაუშავს ssh-keygen უტილიტა მას თავისთ დააგენერირებს და საჭირო წვდომის უფლებებსაც მიანიჭებს. დავაყენეოთ openssh კლიენტი და სერვერი ან განვაახლოთ თუ უკვე გვაქვს და დავაგენერიროთ public key წყვილი:

yum -y install openssh openssh-clients openssh-server
ls -l  ~/.ssh
yes | ssh-keygen -t rsa

გამოვა შეტყობინება: “Enter passphrase (empty for no passphrase):”  ვაწვებით ენთერს. პაროლი არ გვჭირდება.

ოპერაციის დასრულების შემდეგ გამოვა რაღაც ამდაგვარი  ბინარულ – აბტრაქციონისტური შემოქმედება და გვახარებს წყვილი გასაღების გენერირებას.

The key fingerprint is:
f3:96:01:e8:6f:64:01:53:27:d2:58:a1:0b:a6:2c:e1 user@hostname.ge
The key’s randomart image is:

ვნახოთ რა შექმნა წინა ბრძანებამ:

ls -la ~/.ssh
drwx------  2 user group 4096 2011-02-04 16:19 .
drwx------ 28 user group 4096 2011-02-04 15:14 ..
-rw-------  1 user group 1675 2011-02-04 02:18 id_rsa
-rw-r--r--  1 user group  393 2011-02-04 02:18 id_rsa.pub
-rw-r--r--  1 user group  391 2011-02-04 16:19 known_hosts

ვნახავთ ორ ახალ ფაილს:  id_rsa  და  id_rsa.pub

ყურადრება: ფაილი id_rsa წარმოადგენს თქვენს პირად გასაღებს! მის სხვისთვის გაზიერება იგივეა რაც პაროლის გაზიარება,  ან სეიფის გასაღების გაზიარება, ამიტომ მაქსილამურად დაცული იქონიეთ.  ვაკოპირებთ id_rsa.pub სამიზნე  კომპზე (სამიზნე კომპზეც უნდა იყვეს დირექტორია  ~/.ssh)

scp ~/.ssh/id_rsa.pub user@hostname.ge:.ssh/authorized_keys2

თქვენს შემთხვევაში hostname.ge შეიძლება იყვეს სერვერის IP. ეხლა შევცვალოთ შემდეგი პარამეტრები  /etc/ssh/sshd_config, _ში უსაფრთხოების გაძლიერების მიზნით, ვეძებთ შემდეგ სტრიქონებს კონფიგ ფაილში ვუშლით კომენტარებს (კომენტარი = #) და ვუცვლით მნიშვნელობებს შემდეგზე:

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
PrintMotd no
UseLogin no
UseDNS no

გადავტვირთოდ sshd სერვისი სერვერზე :

ssh root@hostname.ge "service sshd restart"

თუ თქვენ ჯეეეერ ვერაფერს მიხვდით მაშინ მოსინჯეთ სერვერზე შესვლა შემდეგნაირად :) :

ssh hostname.ge

დიახ! თქვენ უკვე აღარ გჭირდებათ მომხმარებლის სახელის და პაროლის შეყვანა ავტორიზაციის გასავლელად.

Linux ოპერაციულ სისტემებში შესაძლებელია partition-ის შემდგომში “დანაყოფი” (დროა ქართულადაც ვიცოდეთ ამ სიტყვების მნიშვნელობები :z ) მოხერხებული-ადვილი-გრაფიკული მართვა, მაგ. ზომის გაზრდა/შემცირება, parttition tables შექმნა, შემოწმება შეცდომებზე და სხვა მრავალი სასარგებლო ოპერაციის გაკეთება commandline-ის გარეშე, მააგრამ linux ჯერ-ჯერობით რჩება სერვერ ოპერაციულ სისტემად და შესაბამისად ხშირად სერვერებზე გრაფიკული გარსი არ არის გაშვებული (99.99% არც არის საჭირო).

პოსტი მოიცავს ნებისმიერი linux ოპერაციულ სისტემის ქვეშ მყოფი ext3/ext4 დისკების გაზრდა/შემცირებას, რომლებიც არ არის LVM/LVM2 ან RAID შემადგენლობაში და არის სტანდარტული partittion-ები.

გაფრთხილება: აუცილებლად “<<დაა-backup-ეთ>>” პაციენტი. ბექაფის გარეშე აღნიშნული ოპერაციის ჩატარებამ შეიძლება მიგვიყვანის სავალალო შედეგებამდე. ბექაფის არსებობის შემთხვევაში თამამად გადავდივართ შემდეგ საფეხურებზე.

პრობლემა: გვაქ ლინუქს სერვერი რომელზეც გადაგვევსო /var (თქვენს შემთხვევაში ეს შეიძლება იყოს ნებისმიერი /,  /opt, /u01, /xxx, ან /home) დანაყოფი რომელიც დამონტაჟებულია (არ დაიბნეთ mounts ვგულისხმობ) /dev/sdd1 დისკზე, რომლის მოცულობა არის 30 გბ. მაგ: /dev/sdd1 /var

საჭირო ინსტრუმენტები: fdisk, tune2fs, e2fsck, resize2fs, fsck (სტანდარტულად ეს ბრძანებები ნაგულისხმევად განისვენებს /sbin დირექტორიაში ყველა linux დისტრიბუტივზე.)

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

1.   ვაკეთებთ დისკის დემონტაჟს, (unmount partition),

umount /dev/sdd1

ხშირია შემთხვევები როდესაც დისკი დაკავებულია და დემონტაჟი წარუმატებლად სრულდება, გამოდის ამდაგვარი შეტყობინება: “Device or resource busy” ასეთ შემთხვევაში შესაძლებელია -l სვიჩის გამოყენება და დემონტაჟის ძალებით გაკეთება (force).

umount -l /dev/sdd1

ყურადღება! არავითარ შემთხვევაში არ შეეცადოთ იმ დანაყოფის დემონტაჟს რომელზეც წერს მონაცემთა ბაზები (MySQL, Oracle, PostgreSQL, etc). ამ შემთხვევაში თქვენ შეიძლება დაკარგოთ ინფორმაცია, ან დააზიანოთ მონაცემთა ბაზის სტრუქტურა (მონაცემთა ბაზებს შეუძლიათ data-ფაილის ექსკლუზიურ რეჟიმში გახსნა/წაკითხვა, იყენებენ სისტემურ გამოძახებებს (syscall) მაგალითთად fopen() ფუნქციას პარამეტრად გადეცემა O_EXCL და ფაილი გაიხსნება ექსკლუზიაურად. ექსკლუზიური გახნს კი იმას ნიშნავს რომ სანამ ფაილი არ “დაიხურება” fclose(), დანაყოფის დემონტაჟს აზრი არ ააქვს, მოხდება მხოლოდ “ფსევდო დემონტაჟი” სინამდვილეში ფაილური სისტემა კვლავ დაკავებული იქნება I/O ოპერაციებით). ჩვენ არ გვაწყობს არანაირი I/O აქტივობა ჩვენს დიკზე, როდესაც დავიწყებთ მისი მოცულობის გაზრდა/შემცირებას, ამიტომ საკუეთესო გამოსავალი იქნება თუ ჩვენ ჩავიტვირთებით singe-user რეჟიმში (ამ დროს არ არსებობს ქსელი, არ იტვირთება დემონები/სერვისები და სისტემაში შესასვლედად არ არის საჭირო ავტორიზაცია). თუ გვინდა root დანაყოფის ( / ) გაზრდა ამ შემთხვევაში ვიტვირთებით რომელიმე linux-based ჩამტვირთავი დისკიდან (რადგანაც ჩართულ სსისტემას თავის თავის დემონტაჟს ვერ მოვთხოვთ, არა ეს შესაძელბელეია, მაგრამ ამ შემთხვევაში მიუწვდომელი იქნება /sbin დირექტორია და შესაბამისად საჭირო ბრძანებებს ვეღარ გამოვიძახებთ). ასეთები კი ბევრია და თავისუფლად გადავდივართ შემდეგ საფეხურზე.

2.   ვამოწმებთ ფაილური სისტემის შეცდომებზე არსებულ დანაყოფს:

fsck -n /dev/sdd1

3.   ვშლით ჟურნალს ფაილური სისტემიდან და ვაქცევთ მას მარტივ ext2 ფაილურ სისტემად (ext3/4 ფაილური სისტემების ext2-გან განსხვავებით გააჩნიათ ჟურნალირების საშუალება, მაგრამ ჟურნალირებად ფაილურ სისტემაზე ამგვარ ცვლილებებს ვერ მოვახდენთ, ამიტომ დროებით ვუთიშავთ მას ამ ფუნქციას).

tune2fs -O ^has_journal /dev/sdd1

4.   ვხსნით მთელ დისკს fdisk უტილიტით /dev/sdd  (და არა ცალკეულ დანაყოფს sdd1.)

fdisk /dev/sdd

გამოვა ინტერაქტიული მენიუ:

Command (m for help): 

4.1.   დააჭირეთ p ღილაკს, გამოიტანს ინფორმაციას დისკზე და გვაჩვენებს მის დანაყოფებს (ეს კარგი პრაქტიკაა, კიდევ ერთხელ გადახედავთ, რომ დანაყოფები არ აგერიოთ)

Command (m for help): p

4.2.   ვშლით დანაყოფს, ჩვენს შემთხვევაში ეს არის /dev/sdd1, ეს ავტომატურად მონიშნულია ამიტომ უბრალოდ დააჭირეთ d-ს და შემდეგ enter-ს) არ ინერვიულოთ ამ დროს არ წაიშლება თქვენი ინფორმაცია, უბრალოდ წაიშლება ძველი partition table.

Command (m for help): d

გამოვა შეტყობინება:

>Selected partition 1

4.3.   ვქმინით ახალ partition table’ს – n.

Command (m for help): n 

4.4.   ვირჩევთ პირველად დანაყოფს (Primary Partition).

Command (m for help): p

4.5.   Linux-ში შეგვიძლია 1 დისკზე გვქონდეს 4 პირველადი დანაყოფი, ჩვენ არ გვაქ არცერთი /dev/sdd დისკისთვის  ამიტომ ვირჩვთ 1-ს.

Command (m for help): 1

4.6.   ამის შემდეგ გამოვა ორი ინტერაქტიული კითხვა სადაც გვკითხავს პირველი და ბოლო ცილინდრის მნიშვნელობებს, ეს ნაგულისხმევი მნიშვნელობებია და ამიტომ მათ მნიშვნელობას არ ვცვლით, უბრალოდ 2-ჯერ დააჭირეთ enter-ს.

Partition number (1-4): <Enter>
Last cylinder, +cylinders or +size{K,M,G} (1-xxxx, default xxxx): <Enter>

4.7.   ჩვენ შევქმენით ახალი partition table, რომელმაც უკვე იცის თუ რა ზომის იქნება ახალი დანაყოფი (შეიცვალა ბოლო ცილინდრის მნიშვნელობა),
შევინახოთ ცვლილებები – w.

Command (m for help): w

5.   ვამოწმებთ ახალ ext2 ფაილურ სისტემას შეცდომებზე:

e2fsck -f /dev/sdd1

6.   ვზრდით/ვამცირებთ ფაილური სისტემის ზომას, resize2fs-ის საშუალებით შეგვიძლია გავზარდოთ ან შევამციროთ ფაილური სისტემის ზომა ონლაინ რეჟიმში, შეგვიძლია პარამეტრად გადავცეთ სასურველი ზომა, მაგრამ თუ ზომა მითითებული არ იქმნება ჩვენს მიერ ამ შემთხვევაში resize2fs ნაგულსხმევად აიღებს მაქსიმალურ მნიშვნელონბას partition table -დან, (ეს ჩვენ უკვე გავაკეთეთ fdisk-ის გამოყენებით), რაც ძალიან მოსახერხეხბელია.

resize2fs /dev/sdd1

7.   კვლავ ვამოწმებთ ზომაშეცვლილ დანაყოფს

fsck -n /dev/sdd1

8.   შემდეგი ბრძანებით ჩავურთავთ ჟურნალირებას და მივიღებთ ისევ სრულყოფილი ext3/4 დანაყოფს.

tune2fs -j /dev/sdd1

სასურველია გადავტვირთოთ OS 4-ე საფეხურის დასრულებისთანავე და შემდეგ გადავიდეთ დანარჩენ საფეხურებზე, მთლიანი პროცედურის დამთავრების შემდეგ აკრიფეთ შემდეგი ბრძანება ზომის ცვლილების სანახავად:

df -h /dev/sdd1

ქართული 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) შეგვიძლია სერევრის  სრული ისზოლირება შეტევებისაგან.