11.11.2012

Az árvíz alatt Hatalmas adatáramlást jelent üzenetek formájában, amelyeket mindenféle fórumon és csevegésen elküldenek. Technikai szempontból árvíz az egyik leggyakoribb számítógépes támadások típusai, és célja olyan számú kérés küldése, amelyet a szerver hardvere kénytelen lesz végrehajtani szolgáltatás megtagadása felhasználói szolgáltatások. Ha egy számítógépes támadás-val végezték el egy nagy szám számítógépekkel, akkor .

A DDoS elárasztási támadásoknak többféle típusa létezik, a főbbeket az alábbiakban soroljuk fel:

• SYN-ACK árvíz
• HTTP áradás
• ICMP árvíz
• UDP árvíz

SYN-ACK árvíz

SYN-ACK árvíz- az egyik típus hálózati támadások, amely időegységenként hatalmas számú SYN-kérés elküldésén alapul. Az eredmény a szolgáltatás letiltása lesz, amelynek működése a TCP protokollon alapult. Először a kliens egy SYN jelzőt tartalmazó csomagot küld a szervernek, amelynek jelenléte azt jelzi, hogy a kliens kapcsolatot kíván létesíteni. A szerver viszont válaszcsomagot küld. A SYN jelzőn kívül egy ACK jelzőt is tartalmaz, amely felhívja a kliens figyelmét, hogy a kérést elfogadták, és a kapcsolat megerősítését várják a klienstől. Egy ACK jelzővel ellátott csomaggal válaszol a sikeres kapcsolatról. A szerver az ügyfelektől érkező összes „csatlakozási” kérést egy bizonyos méretű sorban tárolja. A kérések mindaddig sorba állnak, amíg az ügyfél vissza nem adja az ACK jelzőt. A SYN-támadás azon alapul, hogy nem létező forrásból küldenek csomagokat a kiszolgálónak a várakozási sor méretét meghaladó méretben. A szerver egyszerűen nem tud válaszolni egy fiktív címen lévő csomagra. A sor nem csökken, és a szolgáltatás leáll.

HTTP áradás

HTTP áradás- akkor érvényes, ha a szolgáltatás működik együtt adatbázis. A támadás célja vagy web szerver, vagy egy olyan szkriptre, amely együttműködik az adatbázissal. A 80-as portra hatalmas számú GET kérés érkezik, így a webszerver nem tud kellő figyelmet fordítani az eltérő típusú kérésekre. A naplófájlok nőnek, és az adatbázissal való munka lehetetlenné válik.

ICMP árvíz

ICMP árvíz- egyszerű módja áteresztőképesség csökkentéseés terhelés növekedése a veremben hasonló ICMP PING kérések küldésével. Veszélyes, ha kevés figyelmet fordítanak a tűzfalakra, mivel a végtelen ECHO kérésekre válaszoló szerver kudarcra van ítélve. Tehát azonos mennyiségű bejövő és kimenő forgalom esetén csak írja be a szabályokat iptables.

UDP árvíz

UDP árvíz- Egy másik módja sávszélesség zűrzavar, amely egy olyan protokollon alapul, amely nem igényel szinkronizálást az adatok küldése előtt. A támadás a szokásos csomagküldésből fakad a szerver UDP portjára. A csomag átvétele után a szerver elkezdi intenzíven feldolgozni azt. A kliens ezután egyenként küldi el a hibás formátumú Udp-csomagokat. Ennek eredményeként a portok működése leáll, és a rendszer összeomlik.

Alapvetően a meghatározás DDoS támadás típusa gyakran nem kell sok időt tölteni. Elég, ha ismerünk néhány jelet. Ha jelentősen növelte a naplófájlok méretét- Ön foglalkozik HTTP áradás. Ha egy korlátozott hozzáférést biztosít a szolgáltatáshoz az engedélyezett kapcsolatok számának túllépése következtében SYN-ACK árvíz. Ha kimenő és bejövő forgalom megközelítőleg egyenlő- Ön foglalkozik ICMP árvíz. A legfontosabb dolog az, hogy ne feledkezzünk meg a karbantartásról a szerver biztonsága DDoS-ből, és fordítsunk kellő figyelmet rá. A legjobb, ha vigyázunk rá

DoS (rövidítve Denial of Service "szolgáltatásmegtagadás") - hacker támadás egy számítástechnikai rendszeren annak tönkretétele érdekében, vagyis olyan feltételek megteremtése, amelyek mellett a rendszer lelkiismeretes felhasználói nem tudnak hozzáférni a biztosított rendszererőforrásokhoz (szerverekhez), vagy ez a hozzáférés nehézkes.

A DoS / DDoS támadásoknak két típusa van, és a legelterjedtebb az elárasztás gondolatán alapul, vagyis az áldozat elárasztása hatalmas számú csomaggal. Az elárasztás különböző lehet: ICMP elárasztás, SYN elárasztás, UDP elárasztás és HTTP elárasztás. A modern DoS botok az összes ilyen típusú támadást képesek egyszerre használni, ezért érdemes előre gondoskodni a megfelelő védelemről mindegyik ellen.

DoS támadás észlelése

SYN árvíz

A SYN árvíz jelenléte könnyen megállapítható - a "félig nyitott" TCP-kapcsolatok számának megszámlálásával. Normál helyzetben egyáltalán ne legyenek (vagy nagyon kis mennyiségben: maximum 1-3).

DoS védelem

Blokkolja a töredékeket - csomagokat. Mivel a protokoll funkcionális céljából adódóan az ICMP-csomagoknak nagyon kicsiknek kell lenniük, és általában bele kell férniük az MTU-ba, a töredékeik jelenléte általában hibát vagy támadási kísérletet jelez. iptables -A BEMENET -p icmp -f -j DROP

Akadályozza meg a hamisítást az Ön nevében. iptables -A BEMENET -m conntrack --ctstate ÚJ, ÉRVÉNYTELEN -p tcp --tcp-flags SYN,ACK SYN,ACK -j LOG --log-level info --log-prefix "DROP SYN,ACK: " iptables - A BEMENET -m conntrack --ctstate ÚJ, ÉRVÉNYTELEN -p tcp --tcp-flags SYN,ACK SYN,ACK -j REJECT --reject-with tcp-reset

Végül is, ha olyan csomagot kapunk, amelyen a SYN és az ACK jelző van beállítva (csak a SYN csomagra adott válaszban van ilyen jelzőkombináció) egy még nem nyitott kapcsolaton, ez azt jelenti, hogy valaki SYN csomagot küldött egy másik gazdagépnek. a mi nevünkben, és a válasz megérkezett hozzánk. Természetesen a támadónak továbbra is ki kell találnia a sorszámot, de jobb, ha nem adunk neki ilyen esélyt. A fenti szabály szerint a gazdagépünk egy RST-csomaggal válaszol, melynek vétele után a megtámadott gazdagép lezárja a kapcsolatot. Erősen ajánlott egy ilyen szabály hozzáadása a tűzfal konfigurációjához, mert ha egy támadónak sikerül hamisítania az Ön nevében, a nyomvonal Önhöz vezet az epizód kivizsgálásakor.

SYN árvíz

Az egyik gyakori módja nem csak a kommunikációs csatorna blokkolásának, hanem a belépésnek is hálózati verem operációs rendszert olyan állapotba hozni, ahol már nem tud új csatlakozási kéréseket fogadni. Egy nem létező visszatérési címmel rendelkező SYN-csomag küldésével nagyszámú egyidejű TCP-kapcsolat inicializálására tett kísérlet alapján. Többszöri próbálkozás után, hogy elérhetetlen címre küldjön válasz ACK-csomagot, a legtöbb operációs rendszer sorba állít egy létrejött kapcsolatot. És csak az n-edik próbálkozás után szakad meg a kapcsolat. Mivel az ACK-csomagok áramlása nagyon nagy, a sor hamarosan megtelik, és a kernel nem hajlandó új kapcsolatot nyitni. A legokosabb DoS-botok is elemzik a rendszert, mielőtt támadást indítanának, hogy csak a létfontosságú portokra küldjenek kéréseket. Az ilyen támadás azonosítása egyszerű: csak próbáljon meg csatlakozni valamelyik szolgáltatáshoz. A védekező intézkedések általában a következők:

Növelje a "félig nyitott" TCP-kapcsolatok sorát:

# sysctl -w net.ipv4.tcp_max_syn_backlog=1024

A "félig nyitott" kapcsolatok megőrzési idejének csökkentése:

# sysctl -w net.ipv4.tcp_synack_retries=1

A TCP szinkronizálási mechanizmusának engedélyezése:

# sysctl -w net.ipv4.tcp_syncookies=1

UDP árvíz

Sávszélesség-zavarás módszer. Az UDP-csomagok vég nélküli küldésén alapul a különböző UDP szolgáltatások portjaira. Könnyen kiküszöbölhető, ha elvágják az ilyen szolgáltatásokat a külvilágtól, és korlátozzák az időegységre eső kapcsolatok számát.

# Állítson be 5 csatlakozási korlátot a 80-as porton. iptables -A BEMENET -p tcp --syn --dport 80 -m connlimit --connlimit-bove 5 -j REJECT # Csak egy párhuzamos kapcsolat engedélyezése egy IP-ről az smtp iptables-hoz -A FORWARD -p tcp --syn --dport smtp -m connlimit --connlimit-above 1 -j DROP # Állítson be 200 csatlakozási korlátot az 1720-as porton. iptables -A BEMENET -p tcp --syn --dport 1720 -m connlimit --connlimit-bove 200 -j REJECT # udp 5060 $IPT -A INPUT -p udp --dport 5060 -m connlimit --connlimit-above 60 -j NAPLÓ --log-level info --log-prefix "REJECT 5060: " $IPT -A BEMENET -p udp --dport 5060 -m connlimit --connlimit-bove 60 -j REJECT # tcp 1720 $IPT -A INPUT -p tcp --syn --dport 1720 -m connlimit --connlimit-bove 60 -j LOG --log-level info --log-prefix "REJECT 1720: " $IPT -A BEMENET -p tcp --syn --dport 1720 -m connlimit --connlimit-bove 60 -j ELUTASÍTÁS

ICMP árvíz

Az ECHO hálózati torlódás-diagnosztikai protokoll (ping) egy nagyon primitív módszer a sávszélesség korlátozására és a hálózati verem terhelésének létrehozására az ICMP kérések monoton küldésével. Könnyen észlelhető a kétirányú forgalom elemzésével: az ICMP árvízi támadása során szinte azonosak. Az abszolút védelem szinte fájdalommentes módja az ICMP ECHO kérésekre adott válaszok letiltásán alapul:

sysctl net.ipv4.icmp_echo_ignore_all=1

Vagy tűzfallal:

Iptables -A BEMENET -p icmp -j DROP --icmp-type 8

HTTP áradás

Folyamatok száma ps aux | grep apache | wc -l

Kapcsolatok száma a 80-as porton netstat -na | grep ":80" | wc -l

Lista megtekintése IP-címek ahonnan csatlakozási kérelmek készülnek: netstat -na | grep ":80" | rendezés | uniq -c | sort-nr

sysctl

Hamisítás elleni védelem net.ipv4.conf.default.rp_filter = 1

Percenként ellenőrizze a TCP-kapcsolatot. Ha a másik oldalon van egy legális autó, azonnal reagál. Az alapértelmezett érték 2 óra. net.ipv4.tcp_keepalive_time = 60

Próbálja újra tíz másodperc múlva net.ipv4.tcp_keepalive_intvl = 10

A kapcsolat lezárása előtti ellenőrzések száma net.ipv4.tcp_keepalive_probes = 5

Debian: Harc a DDoS ellen

Alapértelmezés szerint a Debian OS és más operációs rendszerek nem képesek támogatni a botnet által létrehozott hatalmas számú kapcsolatot. A TCP/IP-verem megerősítése érdekében a kernelkonfigurációt módosítani kell. Példa egy ilyen konfigurációra:

net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.eth0.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.core.rmem_max = 996777216 net.core.wmem_max = 7ipv 246 .tcp_rmem = 4096 87380 4194304 net.ipv4.tcp_mem= 786432 1048576 996777216 net.ipv4.tcp_wmem = 4096 87380 4194304 net.ipv4.tcp_max_orphans = 2255360 net.core.netdev_max_backlog = 10000 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_keepalive_intvl = 15 net.ipv4.tcp_max_syn_backlog = 2048 net.ipv4.tcp_synack_retries = 1 kernel.msgmnb = 65536 kernel.msgmax = 65536 kernel.shmmax = 494967295 = 494967295 kernel.shmmax = 494967295 nettó

Óvatosan módosítsa a kernel konfigurációját, és indítsa újra a szervert...

FreeBSD: Harc a DDoS ellen

Csökkentjük a SYN-ACK kérésre adott válaszcsomag várakozási idejét (védelem a SYN-áradás ellen):

# sysctl net.inet.tcp.msl=7500

Fekete lyukká változtatjuk a szervert. Tehát a kernel nem küld válaszcsomagokat, amikor nem foglalt portokhoz próbál csatlakozni (csökkenti a gép terhelését DDoS alatt, de véletlenszerű portokon):

# sysctl net.inet.tcp.blackhole=2 # sysctl net.inet.udp.blackhole=1

Az ICMP-üzenetekre adott válaszok számát másodpercenként 50-re korlátozzuk (ICMP-elárasztás elleni védelem):

# sysctl net.inet.icmp.icmplim=50

Növeljük maximális összeget kapcsolatok a szerverrel (védelem minden típusú DDoS ellen):

# sysctl kern.ipc.somaxconn=32768

Bekapcsoljuk a DEVICE_POLLING-t - a hálózati illesztőprogram kernel általi önlekérdezését nagy terhelés esetén (jelentősen csökkenti a rendszer terhelését DDoS alatt "a):

Építse újra a kernelt az "options DEVICE_POLLING" opcióval; Aktiválja a lekérdezési mechanizmust: "sysctl kern.polling.enable=1"; Adjon hozzá egy "kern.polling.enable=1" bejegyzést az /etc/sysctl.conf fájlhoz.

Annak érdekében, hogy ne kerüljön patthelyzet a DDoS-vihar összeomlása során a rendszereken, gondosan fel kell készítenie őket egy ilyen helyzetre:

Minden szervert, amely közvetlen hozzáféréssel rendelkezik a külső hálózathoz, fel kell készíteni egy egyszerű és gyors távoli újraindításra (az sshd megmenti az orosz demokrácia atyját). Nagy plusz lesz egy második, adminisztratív hálózati interfész jelenléte, amelyen keresztül elérheti a szervert, ha a fő csatorna eltömődött.

A szerveren használt szoftvernek mindig naprakésznek kell lennie. Minden lyukat befoltoznak, frissítéseket telepítenek (egyszerű, mint a rendszerindítás, tanácsok, amelyeket sokan nem követnek). Ez megvédi Önt a szolgáltatások hibáit kihasználó DoS támadásoktól.

Minden adminisztratív felhasználásra szánt lehallgató hálózati szolgáltatást tűzfal mögé kell rejteni mindenki elől, aki nem férhet hozzá. Ekkor a támadó nem fogja tudni használni őket DoS támadás vagy nyers erő végrehajtására.

A kiszolgáló (legközelebbi útválasztó) megközelítésére forgalomelemző rendszert kell telepíteni (a NetFlow segítségére), amely lehetővé teszi, hogy időben tájékozódjon a kezdődő támadásról, és időben intézkedjen annak megakadályozására.

A SYN árvíztámadás a szolgáltatásmegtagadási támadás egy formája, amelyben a támadó nagyszámú SYN kérést küld a célrendszer TCP protokollt használó szolgáltatásaihoz. Ez felemészti a szerver erőforrásait, hogy a rendszer még a legális forgalomra sem reagáljon. Ez a támadás bármely TCP-protokollt használó szolgáltatáson megtörténhet, de főleg webszolgáltatáson. Ebben az oktatóanyagban részletesen áttekintjük a SYN árvíztámadások alapjait és a mérséklési lépéseket.

A SYN Flood támadás a Transmission Control Protocol (TCP) egyik jellemzőjét használja ki, amelyet háromirányú kézfogásnak neveznek. A következő lépések a normál háromirányú kézfogás során előfordulnak:

1. A kliens kapcsolatot kér egy SYN (szinkronizálás) üzenet küldésével a szervernek.
2. A szerver nyugtázza ezt a kérést a SYN-ACK visszaküldésével a kliensnek.
3. A kliens ACK-vel válaszol, és a kapcsolat létrejön.

A SYN árvíztámadás úgy működik, hogy nem válaszol a kiszolgálónak a várt ACK kóddal. Ezekkel a félig nyitott kapcsolatokkal a célgépek TCP lemaradása megtelik, és így minden új kapcsolat figyelmen kívül maradhat. Ez azt eredményezi, hogy a jogos felhasználókat is figyelmen kívül hagyják.

Ez a támadás kétféleképpen történhet:

1. Közvetlen támadás

Az ilyen típusú támadások során a támadók gyorsan küldenek SYN-szegmenseket anélkül, hogy meghamisítanák IP-forráscímüket. Az ilyen típusú támadások észlelésekor nagyon könnyű védekezni, mivel egy egyszerű tűzfalszabályt adhatunk a támadó forrás IP-címével rendelkező csomagok blokkolására, amely a támadást indítja.

2. Az IP-cím meghamisítása

Ez a támadás összetettebb formája, mint a közvetlen támadás. Ennél a módszernél a rosszindulatú gép hamisított IP-címekről SYN-kérelmeket küld a célgépnek, aminek következtében a szerver hamisított IP-címre küldi a SYN-ACK üzenetet – amely nem küld ACK-t, mert "tudja", hogy soha SYN-t küldött.

SYN árvízi támadás észlelése

A SYN Flood támadás általános tünete egy webhely látogatója ellen, hogy egy webhely betöltése hosszú ideig tart, vagy betölti az oldal egyes elemeit, de másokat nem. Ha SYN Flood támadást gyanít egy webszerveren, tudsz használja a „SYN_RECEIVED” állapotú webszerver csatlakozási kérelmek ellenőrzésére.

netstat -tonhal | grep:80 | grep SYN_RECV

Ha számos kapcsolatot mutat ezzel az állapottal, akkor a szerver SYN Flood támadás alatt állhat. Ha a támadás közvetlen, egyetlen IP-címről érkező nagyszámú SYN_RECV-csomaggal, megállíthatja ezt a támadást, ha hozzáadja ezt az IP-címet a tűzfalhoz. Ha APF vagy tűzfal van telepítve a kiszolgálón, akkor ezt a következő parancs végrehajtásával érheti el:

apf -d IPADDRESS
csf -dIPADDRESS

A SYN Flood Attack védelme

SYN cookie-k használata

Ez a leghatékonyabb módszer a SYN Flood támadás elleni védekezésre. A SYN cookie-k használata lehetővé teszi a szerver számára, hogy elkerülje a kapcsolatok megszakítását, amikor a SYN-sor megtelik. Ehelyett a szerver úgy viselkedik, mintha a SYN-sort kibővítették volna. A szerver visszaküldi a megfelelő SYN+ACK választ az ügyfélnek, de elveti a SYN sor bejegyzését. Ha a szerver ezt követően ACK választ kap a klienstől, képes a SYN sorbejegyzést a TCP-sorszámba kódolt információk segítségével rekonstruálni.

A SYN cookie-k engedélyezhetők a következő hozzáadásával az /etc/sysctl.conf fájlhoz

net.ipv4.tcp_synccookies=1

A sysctl konfigurációs fájl módosítása után a következő parancsot kell végrehajtania a sysctl beállítások betöltéséhez az /etc/sysctl.conf fájlból

A SYN lemaradási sor növelése

Egy opcionális védekezési technika a SYS hátralékos sor méretének növelése. Az alapértelmezett méret 1024. Ezt úgy teheti meg, hogy hozzáadja a következőt az /etc/sysctl.conf fájlhoz

net.ipv4.tcp_max_syn_backlog=2048

A SYN_ACK újrapróbálkozások csökkentése

A tcp_synack_retries kernelparaméter módosítása azt eredményezi, hogy a kernel korábban bezárja a SYN_RECV állapotú kapcsolatokat. Az alapértelmezett érték 5.

net.ipv4.tcp_synack_retries = 3

SYN_RECV időtúllépés beállítása

A SYN_RECV időtúllépési értékének csökkentése segít csökkenteni a SYN árvízi támadást. Az alapértelmezett érték 60, és ezt le is csökkenthetjük 40-re vagy 45-re. Ezt úgy tehetjük meg, hogy hozzáadjuk a következő sort a sysctl.conf fájlhoz.

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv=45

Az IP-hamisítás megelőzése

A következő sysctl paraméter segít az IP-hamisítás elleni védelemben, amelyet a SYN árvíztámadásokhoz használnak.

net.ipv4.conf.all.rp_filter = 1

Sok hosting cég védelmet nyújt a SYN-támadások ellen olyan tűzfalak telepítésével, amelyek SYN árvízvédelmet alkalmaznak, például a Netscreen vagy az Appsafe.

A DoS/DDoS támadások célja az alapul szolgáló rendelkezésre állási szolgáltatás megzavarása. A DoS/DDoS támadások fő célja, hogy a támadott objektumot kivonják a szolgálatból, és elérhetetlenné tegyék erőforrásait a jogos felhasználók számára. A szolgáltatásmegtagadási támadás kétféleképpen hajtható végre: a biztonsági rések használatával szoftver megtámadta a rendszert, és nagyszámú, speciálisan összeállított hálózati csomag küldésével (özönvíz).

Az első módszer nehezebb, és magasabb szintű képesítést igényel a támadótól. A második módszer a „nyers erő” alkalmazásán alapul. Az ötlet az, hogy a támadó által küldött hatalmas számú csomag feldolgozásával töltsék be a szerver számítási erőforrásait. A szerver ilyen terhelése a legjobb esetben is azt eredményezheti, hogy a szerver nem fogja tudni elfogadni a jogos felhasználóktól érkező kéréseket feldolgozásra, legrosszabb esetben pedig a szerver lefagyásához és leállásához vezethet.

Itt érdemes megjegyezni, hogy a rendszererőforrások terhelését célzó támadások két típusa különböztethető meg: az első esetben a szerver számítási erőforrásait, a másikban pedig a kommunikációs csatorna sávszélességét töltik be. A kifejlesztett technika az első típusú támadások elleni védelemre összpontosít, így tovább feltételezzük, hogy a sávszélesség elegendő ahhoz, hogy a szerver megkapja a hozzá címzett összes forgalmat.

Sok DoS-hez/ DDoS támadások a támadó által küldött csomagok szerver általi feldolgozásának eredményei a támadó számára nem érdekesek. Ez azt jelenti, hogy a támadó hamis IP-címekről hamis állításokat küldhet (ezt a koncepciót hamisításnak nevezik), ami megakadályozza, hogy észleljék, és hatékonyan felléphessen az ilyen támadásokkal.

A sikeres DoS támadás végrehajtásához meglehetősen nagy csatorna sávszélességre van szükség. Ezért a szolgáltatásmegtagadási támadást a legtöbb esetben több gépről hajtják végre egyszerre. A nagyszámú gépet érintő támadást DDoS-nak nevezik. Érdemes megjegyezni, hogy elosztott támadáshoz olyan speciális szoftverrel fertőzött gépek is használhatók, amelyek nem tartoznak a támadóhoz. Az ilyen fertőzött gépeket "zombiknak" nevezik. A "zombik" megszerzésének egyik módja a "trójaiak" tömeges bevezetése a békés felhasználók számítógépére. Miután megkapta a parancsot kívülről, egy ilyen "trójai" az internet-hozzáféréssel rendelkező "békés" számítógépet hamis kérések forrásává változtatja, amelyek célja a szerver erőforrásainak túlterhelése.

A leggyakoribb DoS támadások a következők:

TCP SYN Flood vagy csak TCP SYN

Ping of Death

Nézzük meg közelebbről a TCP SYN (tcp syn flood) támadást, amely a TCP szállítási réteg protokollt használó alkalmazásszolgáltatásokra irányul. Ez a protokoll széles körben elterjedt az információs rendszerekben, mivel garantálja az összes továbbított adat 100%-os kézbesítését. Az interaktív hálózati csomópontok, amelyek ezt a protokollt átvitelként használják, TCP-kapcsolatokat hoznak létre egymás között, amelyeken belül szabályozzák, hogy a címzett megkapja-e a küldő által küldött összes csomagot. Ezt úgy érik el, hogy a fogadó értesíti a feladót, hogy mely csomagokat fogadta. Ha nem minden neki szánt csomag jutott el a címzetthez, akkor a feladó újraküldi azokat. Amint látja, ennek a protokollnak az az előnye, hogy képes kapcsolatot létesíteni. A kapcsolat aktuális állapotával kapcsolatos információk tárolására, különösen a protokoll által használt csomagokban lévő bitjelzők mezőjét használják. 8 bit van lefoglalva ehhez a mezőhöz, de ebből 2 le van foglalva, és jelenleg csak 6 jelző van használatban: URG (sürgős jelző), ACK (nyugtázási jelző), PSH (push function flag), RST (reset flag), SYN (jelző). sync) és FIN (End Flag). Sajnos a szabvány által létrehozott kapcsolatlétesítési mechanizmus nem tökéletes, és a vizsgált támadás csak a hiányosságait használja ki.

Ennek a TCP SYN-támadásnak a fő célja az, hogy túllépje a beállítási állapotban lévő TCP-kapcsolatok számának korlátját. Fontolja meg a TCP-kapcsolat létrehozásának eljárását. Először a kapcsolatot kezdeményező kliens egy TCP-SYN kérést küld a szervernek. Egy ilyen kérés fogadásakor a szerver memóriát foglal le a kapcsolati paraméterek számára egy speciálisan kialakított pufferben. Ezután a SYN+ACK jelzőkkel ellátott csomagot küldi a TCP kliensnek. SYN+ACK csomag fogadásakor a kliensnek nyugtázó csomagot kell küldenie a szervernek, pl. egy csomag az ACK jelzővel. Amikor a szerver megkapja és feldolgozza ezt a csomagot, a kapcsolat létrejön. Fentebb leírtuk

ábrán látható az eljárás. 1.1

Rizs. 1.1

A TCP SYN támadást a következőképpen hajtják végre: a támadó nagyszámú csomagot generál a TCP protokoll beállított SYN jelzőivel. Csomagok fogadásakor a támadott gép memóriát foglal le a kapcsolati paraméterek tárolására, és választ küld – egy SYN + ACK jelzővel ellátott csomagot, és egy ACK jelzővel ellátott csomagot vár. Nyilvánvalóan nem kapja meg a várt választ, és a memória csak a beállított időkorlát lejárta után szabadul fel. Egy idő után a kapcsolatok TCP-paramétereinek tárolására lefoglalt puffer teljesen elfoglalt lesz, aminek következtében a rendszer nem tud új kapcsolatokat létesíteni. Ezt követően mindegyik további kérés tovább növeli a terhet. Az ilyen támadásokra nincs szükség Visszacsatolás a támadóval, és ezért a támadó létrehozhat egy csomagot a küldő tetszőleges IP-címével.

A támadótól érkező visszajelzés hiánya nagy kihívást jelent a TCP-SYN támadások észlelésében és visszaverésében.

Célok kitűzése a fenyegetések elleni védelemre

Jelenleg a szabad irodalomban nem ismertek hatékony módszerek a TCP SYN támadások észlelésére. A modern operációs rendszerek rendelkeznek a megtámadott szerver védelmére szolgáló mechanizmusokkal, például SYN cookie-kkal. Az operációs rendszer automatikusan bekapcsolja a védelmet, ha egyes paraméterek túllépését észleli. Például a Windows 2000 három paraméter értékét figyeli: TcpMaxHalfOpen, TcpMaxHalfOpenRetried, TcpMaxPortsExhausted. Ezeknek a beállításoknak a küszöbértékei alapértelmezett értékek, és a rendszergazda módosíthatja azokat. Ha a kezdeti értékek nem megfelelőek egy adott szerverhez, akkor a rendszergazdának nehéz dolga van a védelem hatékony konfigurálásában. Ezenkívül ez a módszer megfelelő változtatásokat igényel a TCP/IP-verem megvalósításában, amit egyes hálózati szakértők a TCP-protokoll "súlyos megsértésének" tartanak.

Az operációs rendszerbe integrált TCP támadásészlelő eszközök másik hátránya, hogy túlterheltség esetén (ez a processzor- és memóriaerőforrások hiánya) vagy maga a rendszer lefagy, az ellenintézkedések is működésképtelenné válnak.

A mester munkájának célja egy matematikailag megalapozott módszer létrehozása a TCP SYN támadások észlelésére. Ehhez létre kell hozni egy matematikai modellt, amely leírja a TCP-kiszolgáló és az ügyfelek közötti interakciót. Az ilyen modell kezdeti paramétereinek a szerver és a kommunikációs csatorna jellemzőinek kell lenniük, a kimeneti paraméternek pedig a TCP-SYN támadás meglétére vagy hiányára vonatkozó nyilatkozatnak kell lennie.

A javasolt módszertan gyakorlati felhasználása a kritikus erőforrások védelmében vállalati hálózat eszközökre is szükség van a modell bemeneti paramétereinek tényleges értékeinek meghatározásához egy adott szerverhez és a hálózathoz, amelyhez csatlakozik.

1. felelősség kizárása: Bocsásson meg, hogy a cikk meglehetősen gyűrött, és sok témát nem tárgyalunk teljesen. Nyugodtan tegyen fel kérdéseket a megjegyzésekben. Én viszont igyekszem a legtöbbet felfedni érdekes témákat a jövőbeni cikkekben.

2. felelősség kizárása: Sok cikk található a neten "Hogyan védheti meg szerverét a SYN támadásoktól" vagy "Linux DDoS védelem" címmel. Figyelmeztetnem kell, hogy sokukban semmiképpen sem szabad vakon megbízni! Gyakran olyan emberek írják őket, akik nem értik jól, mi történik a támadás során, és őrült dolgokat javasolnak - valaki „optimalizálja” a sysctl-t, hogy még a normál forgalom is leálljon a szerver felé, és a legtöbb a szinkronizálás engedélyezését is javasolja, ami kategorikusan ez lehetetlen a legtöbb valódi támadásnál!

Ennek a cikknek 3 célja van:

Mi az a SYN támadás?

A SYN-áradás vagy SYN-támadás egy szolgáltatásmegtagadási technika, amely a TCP-kiszolgálófolyamatokat futtató gazdagépeket érinti. A támadás azt a tényt használja ki, hogy a TCP eltárolja a munkamenet állapotát, miután megkapta a SYN szegmenst egy olyan porton, amely LISTEN állapotban van. A fő ötlet az, hogy ezt a viselkedést úgy használják ki, hogy a gazdagépet annyira tárolják a hamis félig nyitott munkamenetek számára, hogy már nem marad erőforrása új kapcsolatok létrehozására (RFC4987).

A SYN elárasztását viszonylag nehéz kezelni, ezért olyan népszerű ez a fajta támadás. Miért?

1) Általában véletlenszerű forrású IP-címeket használnak, amelyeket felesleges tiltani, mert minden csomagban újragenerálódnak;
2) A SYN támadás kevés erőforrást fogyaszt a támadó, és sokat az áldozat oldalán;
3) Az ilyen típusú támadások elleni védelem meglehetősen összetett, tele van árnyalatokkal, és időbe telik annak megértése és végrehajtása.

Úgy gondolom, hogy a potenciálisan támadható szervereket (valójában minden nyilvános IP-címmel rendelkező szervert, különösen a webszervereket) előre meg kell védeni a SYN támadásoktól.

1. ábra: SYN támadás

Hogyan hajtják végre a SYN támadásokat?

A támadások végrehajtására gyakran használt segédprogram például a hping3. Használhatja szervere stressztesztjére, mielőtt a támadók megtennék helyetted.

A hping3 egy funkciókban gazdag segédprogram, amely sokféle támadást képes végrehajtani különböző paraméterekkel. Nem adok mesterkurzust a használatáról, csak egy példát mutatok be arra, hogyan ellenőrizheti a szerverét egy kis SYN-támadással szembeni sebezhetőség szempontjából:

# hping3 -S<--fast|--faster|--flood>-p 80 xx.xx.xx.xx

Ebben a példában a 80 (HTTP) a célport. Vessen egy pillantást a többi lehetőségre (hping3 --help), hogy megtudja, miben különböznek egymástól a támadások.

Használja ezt a segédprogramot óvatosan, és csak saját erőforrásai tesztelésére! Hogy őszinte legyek, az internet nagy része ki van téve ezeknek az egyszerű műveleteknek, még akkor is, ha a támadónak lényegesen kisebb csatornája van, mint a támadóé.

Hogyan lehet azonosítani és mérni egy SYN-támadást?

1) SYN támadás során a támadó számos kapcsolatot nyit meg a szerverrel, de soha nem zárja be azokat, és a kapcsolatok továbbra is SYN_RECV állapotban maradnak. Ezeket így lehet kiszámolni:

# netstat -anutp | grep SYN_RECV | wc -l

Ha ez a szám >30, akkor valószínűleg SYN-támadás alatt áll.

2) A vnstat segítségével nyomon követheti az aktuális hálózati terhelést:

# vnstat -l -i eth0

Ez egy nagyon hasznos segédprogram, amely segít megérteni, milyen erős egy támadás.

Nyomja meg az F2 billentyűt, lépjen a "Megjelenítési beállítások" elemre, és válassza a "Cérnaszálak megjelenítése más színben" lehetőséget. Rózsaszínben láthatja a rendszermegszakításokból származó terhelést.

4) Tekintse át a szerver által kapott SYN-eket – mi a közös bennük? A "-c 100" azt mondja a tcpdump-nak, hogy korlátozza magát 100 csomagra.

# tcpdump -i eth0 -nn "tcp port 80" és "tcp == 2" -c 100

Végül ne feledje, hogy sok SYN-támadás nem „egyenletes”, vannak csúcspontjaik és zuhanásaik, amelyeket figyelembe kell venni az elemzési folyamat során.

2. ábra Egy tipikus támadás dinamikája

Először is

NIC, megszakítások, sorok...

Az első dolog, amin dolgozni kell, az a sofőr hálózati kártya. Amikor egy keret megérkezik a hálózati kártyára, rendszermegszakítást kell kezdeményeznie, amely arra utasítja a processzort, hogy függessze fel az aktuális feladatot és dolgozza fel a bejövő forgalom részét. Ha azonban minden egyes képkocka azonnali megszakítást okoz, és „elterelte” a CPU-t az aktuális feladatról, akkor a legegyszerűbb hálózati műveleteknél is észrevehető teljesítményromlás volt megfigyelhető, mint például az FTP-n keresztüli fájlátvitel. Ezért ezek a megszakítások sorba rendeződnek, amely a hálózati kártyán halmozódik fel, és a processzor egyszerre dolgozza fel. Általában ez másodpercenként 250-1000-szer történik, minél ritkábban - minél alacsonyabb a CPU terhelése, annál nagyobb a késleltetés.

Másrészt a legtöbb modern asztali számítógép és szerver több processzormaggal rendelkezik. Mivel mindegyik külön processzorként működik az operációs rendszerhez, egyenletesen tudjuk elosztani közöttük a megszakításokból származó terhelést. Ennek 2 módja van.

1) Az első és ajánlott a hardveres sorok használata. A modern hálózati kártyák több megszakítási sorral rendelkeznek, jellemzően 4-16. Valamilyen oknál fogva Linuxon alapértelmezés szerint gyakran le vannak tiltva. Engedélyeznünk kell őket, majd egyenletesen el kell osztanunk a processzorok között.

2) A második módszer az úgynevezett RPS - Receive Packet Steering. Csinos új mechanizmus kernel, ami automatikusan elosztja a terhelést az összes mag között, nem mindegy, hogy a kártyán több hardveres sor van-e vagy sem. Ezt a módszert csak akkor használja, ha több magja van, mint hardveres várólista (egyébként fontolja meg az SMT/HyperThreading letiltását – támadáskor jól jön).

3. ábra Intel 10Gb NIC

Lépések:

1) Határozza meg a hálózati kártya gyártóját és modelljét (jobb lenne, ha Intel lenne)

# ethtool -i eth0

2) Telepítse legújabb illesztőprogramok. Nyissa meg a hálózati kártya chip gyártójának webhelyét, és töltse le legújabb verzió illesztőprogramok Linuxhoz (az elkészítéséhez az aktuális kernel forrásaira van szükség)

3) Hardveres sorok beállítása. Ehhez a hálózati kártya illesztőprogramjának dokumentációját kell használnia. igb-hez ( Intel illesztőprogramok) 8 sorral és 4 porttal így néz ki:

# rmmod igb
# modprobe igb QueuePairs=1,1,1,1 RSS=8,8,8,8 IntMode=3,3,3,3 InterruptThrottleRate=3000,3000,3000,3000

Az RHEL/CentOS rendszeren futó igb illesztőprogram esetén egyszerűen hozzáadhatja az illesztőprogram-beállítások sorát az /etc/modprobe.conf fájlhoz, és újraindíthatja:

opciók igb QueuePairs=1,1,1,1 RSS=8,8,8,8 IntMode=3,3,3,3 InterruptThrottleRate=3000,3000,3000,3000

4) Ossza el egyenletesen a megszakítási terheléseket a magok között.
Meg kell határozni, hogy a kártya mely megszakítási számokat használja (esetünkben eth0).

# cat /proc/interrupts | grep eth0

Itt láthatja az összes megszakítási számot, amelyet a hálózati kártya használ, és hogy ezek jelenleg hogyan oszlanak el a magok között. Írd le ezeket a számokat. Most meg kell változtatnunk az SMP affinitást, hogy minden megszakításhoz saját magot rendeljünk (1. megszakítás > cpu 1, 2. megszakítás > cpu 2, stb.). Íme, hogyan történik:

# visszhang > /proc/irq/xx/smp_affinity

5) OPCIONÁLIS: Engedélyezze az RPS-t (lehet, hogy nincs rá szükség, lásd fent)

# echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus

Válassza ki a megfelelő eszközt (ha nem eth0) és az összes általa támogatott fogadási sort (rx-0..n).

sysctl

A következő dolog a sysctl. Ez egy szoftveres interfész, amely lehetővé teszi számos rendszerbeállítás menet közbeni konfigurálását. Ebben a cikkben azonban tartózkodni fogunk attól, hogy megvitassuk, hogyan használhatjuk őket a SYN-támadások elleni védelemre - erről már túl sokat írnak az interneten.

Ellentétben azzal, amit a legtöbb "tanácsadó" gondol, NINCS "univerzális optimalizálás", amely mindenkinek megfelelne, aki rendelkezik szerverrel. Minden úgynevezett optimalizálásnak vannak következményei, például megnövekedett memóriafogyasztás vagy csökkent elérhetőség/funkcionalitás. Természetesen bizonyos változtatásokat alkalmazni kell, de ez a téma megérdemel egy külön cikket, bővebb, mint ez.

Az egyetlen dolog, amit fontosnak és gyakran visszaéltnek szeretnék megjegyezni, az az úgynevezett syncookie-k. Röviden, ez egy egész rendszerre kiterjedő mechanizmus a SYN-támadások elleni küzdelemhez, mivel minden egyes SYN-kérésre cookie-kat küld a kapcsolat legitimitásának megerősítésére. A tény az, hogy ez akkor lehet igazán hasznos, ha a támadási arány a szerver effektív sávszélességének 40%-a vagy kevesebb (effektív alatt ezt értem áteresztőképesség, amelyet a szerver valóban képes feldolgozni). Más esetekben a syncookie-k használata a hálózat, a CPU terhelésének növekedéséhez és ezáltal a szolgáltatás megtagadásához vezet.

Személy szerint a legtöbb esetben letiltom a syncookie-kat.

Alapvető biztonsági technikák az iptables-szal

Ne felejtse el "megerősíteni" a tűzfalát: blokkoljon minden bejövő forgalmat, kivéve azt, amire VALÓBAN szükség van a szerveren. Csak megbízható hálózatokról engedélyezze a kezelést.

A legegyszerűbb eset az 1 IP-ről történő támadás címcsere nélkül (hamisítás). Ezekkel könnyű megbirkózni:

# iptables -A BEMENET -p tcp -m állam -- államÚJ -m legutóbbi --frissítés --másodperc 60 --találatok száma 20 -j DROP
# iptables -A BEMENET -p tcp -m állapot --állapot ÚJ -m legutóbbi --set -j ELFOGADÁS

Ezek a szabályok percenként 20-ra korlátozzák a címenkénti SYN-csomagok számát. Csak ne használd állandóan! Letilthatja a jogos forgalmat a NAT mögül.

Sok SYN támadás kiszűrhető „szokatlan” és ismétlődő TCP-fejlécparaméterekkel, amelyek „bűn” segédprogramokat támadnak meg.

Az első ilyen paraméter az MSS (Maximum Segment Size) – az a maximális szegmensméret, amelyet a kapcsolatot kezdeményező gazdagép engedélyezni kíván. A legtöbb támadóeszköz (beleértve a hping-et is) alapértelmezés szerint nem engedélyezi ezt a beállítást. Másrészt még nem láttam olyan legitim klienseket, akik ne telepítenék. A „normál” értékek 536 és 65535 között vannak, használjuk ezt:

# iptables -t mangle -I ELŐREÚTÁS -p tcp -m tcp --dport 80 -m állapot --állapot ÚJ -m tcpmss ! --mss 536:65535 -j DROP

Egyébként a mangle tábla gyorsabb, mint a filter, mert korábban feldolgozzák, de MINDEN forgalom átmegy rajta, és nincs mód az INPUT, OUTPUT és FORWARD szétválasztására.

Egy másik rendkívül hasznos paraméter a TCP ablak mérete. A legtöbb támadó nem generálja minden alkalommal, és a támadás során ugyanaz marad. A szegmensek ablakméret szerinti szűréséhez és blokkolásához szükség van az iptables u32 moduljára. Ha ismeri a támadóablak méretét (például 512), alakítsa át hexadecimálissá (esetünkben 0x200), és futtassa a következő parancsot:

# iptables -t mangle -I ELŐREÚTÁS -d xx.xx.xx.xx -p tcp -m u32 --u32 "6&0xFF=0x6 && 32&0xFFFF=0x200" -j DROP

De légy óvatos! Ne tiltsa le a népszerű operációs rendszerek által használt jól ismert ablakméreteket: 14600, 1892, 65535, 62240, 5840, 32120, 5720, 4128, 8760, 16384, 62920, 64380 és 17820.

Végül megemlítjük a TTL (Time To Live) paramétert. Azt akarom, hogy ez legyen az utolsó paraméter, amelyen az ellenőrzések alapulnak, mivel az értéktartomány kicsi, és szinte biztosan nem a megfelelő személyt fogja blokkolni. De ha sok támadási csomagot lát, és azok csak a TTL-nek felelnek meg, ez segíthet.

# iptables -A ELŐRE -p tcp -m ttl --ttl-eq=55 -m állapot --állapot ÚJ -j DROP

Ha semmi sem segít

Lépjen kapcsolatba a szakemberekkel! Komoly vagyok. Az itt leírtak csak a jéghegy csúcsa. Ne feledje, hogy két védekezési stratégiát kell együtt alkalmazni:

1) A számítási/hálózati erőforrások növelése/optimalizálása nagyobb számú kérés feldolgozásához;
2) A nem kívánt forgalom elkülönítése a legális forgalomtól annak további blokkolása érdekében.

Így 3 oka van arra, hogy külső segítséget kérjen:
1) Nincs elég sávszélessége vagy számítási erőforrása a nem kívánt forgalom és a jogszerű forgalom elkülönítéséhez;
2) A támadás összetett, és a nem kívánt csomagok nem, vagy szinte nem különböznek a legitim csomagoktól. A szakemberek fejlettebb szűrési módszereket és néha drága speciális hardvert és szoftvert használnak.

És végül