Flooding, DDoS saldırılarını gerçekleştirmenin en basit ve en yaygın yoludur. Bir Linux sunucusunu SYN seli'nden koruma: temel bilgiler ve yöntemler Her şey başarısız olursa

syn-flood saldırısı - pratik

Alexander Antipov

Bazı sağlayıcılar (ve zaman geçtikçe daha fazla sayıda ortaya çıkıyor) müşterilerinin trafiğini gönderenin adresinin sahtekarlığına karşı filtreliyor. Sahtekarlık olasılığının C sınıfı alt ağ ile sınırlı olması ihtimali yüksektir.Ayrıca, bağlantı isteğinde adresi belirtilen ana bilgisayar, sunucu yanıtlarına yanıt vermemelidir - en kolay yol, C sınıfı alt ağda olmayan bir adres seçmektir. makine. Pratik uygulamada, özellikle koordineli bir saldırı için evrensel bir araç oluştururken, bu iki özelliği dikkate almanız ve saldırıyı yalnızca alt ağınızdan ve yanıt vermeyen adreslerden gerçekleştirmeniz gerekir. Diğer bir sorun ise saldırı gerçekleştirmek için yönetici ayrıcalıklarına sahip olmanız gerektiğidir.

Saldırganın kontrolü dışındaki sorunlar.

Yazılım uygulaması.

Standart ham soketlere ek olarak Nerf'ten D0minat0r, Linux altında SYN Flood'u uygulamanın çok güzel bir yolunu buldu; diğer Unix benzeri soketlerde test edilmedi ve Win'de çalışmıyor. Linux, root'un bir soketi, yerel ana bilgisayara ait olmayan adresler de dahil olmak üzere herhangi bir adrese bağlamasına izin verir. Bundan sonra, bu soket için connect() işlevini çağırabilirsiniz ve yerel ana bilgisayar, soketin bulunduğu adresten bir SYN paketi gönderecektir. Soket engellemesiz moddaysa, connect() işleminden hemen sonra close() öğesini çağırabilir ve işlemi tekrarlayabilirsiniz.

Bu işletim sisteminde ham paketler oluşturmanın imkansızlığı hakkındaki yaygın efsane nedeniyle Windows uygulamaları daha az yaygındır. Aslında win98, IP başlığına kadar ham seviye soketlerini destekler ve win2k ve XP de başlığı destekler (IP_HDRINCL seçeneği), yani. Saldırının win2k ve XP altında uygulanması Unix'tekinden sadece birkaç satırda farklılık gösteriyor. Benim tarafımdan win2k'de test edilen bitmiş uygulama bir zamanlar www.nerf.ru'daydı, ancak barındırmayı değiştirdikten, bu gruptan ve formattsev'den ayrıldıktan sonra kayboldu. Hala elinde olan varsa lütfen benimle iletişime geçin, ben de yayınlarım.

SYN taşmasına karşı işletim sistemi koruma mekanizmaları.

a) Standart gergin. Yarı açık bağlantılar bir süre geçtikten sonra arabellekten atılır. Arabellek tükendiğinde, istemci bağlantı istekleri C1/C2 olasılığıyla geçecektir; burada C1, istemciden gelen SYN paketlerinin sayısıdır, C2 ise diğer herkesten (saldırgan dahil) gelen SYN paketlerinin sayısıdır. Saldırganın kanalında saniyede 6 paketlik bir yük olsa bile C1/C2 yaklaşık 1/100'dür, yani. Hizmet %99 oranında kesintiye uğradı.

b) Sınırsız yarı açık bağlantı arabelleği. Saldırganın kanalındaki 100 Mb/sn'lik yük ve yaklaşık bir dakikalık zaman aşımı ile yarı açık bağlantı kuyruğu yaklaşık 1 Gb bellek kaplayacaktır ve bu büyük sunucular için ölümcül değildir. Yan etki: Saldırıya uğrayan sunucu, saldırganın trafiğinden 3 kat daha fazla trafikle yanıt verir (4x DDoS olduğu söylenir), bu da kanalın bant genişliğini tüketebilir. Ancak kanal genişliğinin tüketilmesi mümkün değilse, saldırıya karşı koruma mutlak olacak, tek bir istemci bağlantısı bile reddedilmeyecektir.

c) En eski yarı açık bağlantıların temizlenmesi. Arabellek taştığında, en eski yarı açık bağlantı buradan kaldırılır. Yan etkisi: Bir saldırı sırasında arabellek t zamanında dolarsa, istemci saldırı sırasında bağlanamayacaktır; bağlantı onay süresi t'den büyükse isteği de reddedilecektir. Örneğin, bir saldırganın 4 Mbit/sn kanal yükü ve 512 arabellek uzunluğu (Win2K için önerilen değer) için t süresi yaklaşık 50 msn'dir ve bu, sunucuya çevirmeli bağlantıdan bağlanmaya yönelik tüm girişimleri reddetmesi garanti edilir ve çoğu kiralık hatlardan. Tampon boyutunu artırarak koruma önceki seçeneğe düşürülebilir.

d) SYN ÇEREZİ. Arabellek tükendikten sonra, ara belleğe sığmayan bilgiler, onu talep ettiği varsayılan istemciye gönderilir. İstemci gerçekse bilgiyi geri döndürür; sahte ise kaybolur ve mekanizma TCP üzerinden RFC çerçevesinde uygulanır, yani. bu teknolojiye aşina olmayan müşteriler tarafından da desteklenmektedir. SYN COOKIE'ye sahip bir işletim sistemi, yarı açık bağlantıların arabelleğinin boyutundan bağımsız olarak SYN-flood saldırılarına karşı tamamen savunmasızdır. Yan etki: "büyük pencerelerin" yasaklanması.

Özet: SYN-flood saldırısının geçerliliği sona ermiştir ve bugün en iyi ihtimalle kanal kapasitesini aşmak için düzenli bir sel saldırısı olarak kullanılabilir.

DoS (kısaltılmış Hizmet Reddi), bir bilgisayar sistemini başarısızlığa uğratmak, yani sistemin iyi niyetli kullanıcılarının sağlanan sistem kaynaklarına (sunuculara) erişemeyeceği koşullar yaratmak amacıyla yapılan bir bilgisayar korsanı saldırısıdır veya bu erişim zordur.

İki tür DoS/DDoS saldırısı vardır ve bunlardan en yaygın olanı sel, yani kurbanı çok sayıda paketle bunaltma fikrine dayanır. Farklı seller vardır: ICMP seli, SYN seli, UDP seli ve HTTP seli. Modern DoS botları bu tür saldırıların tümünü aynı anda kullanabilir, bu nedenle bunların her birine karşı yeterli korumaya önceden dikkat etmelisiniz.

DoS saldırı tespiti

SYN seli

SYN Flood'un varlığı, "yarı açık" TCP bağlantılarının sayısı sayılarak kolaylıkla belirlenebilir. Normal durumda hiç olmaması (veya çok az miktarda: maksimum 1-3) olması gerekir.

DoS saldırılarına karşı koruma

Paket parçalarını engeller. Protokolün işlevsel amacı nedeniyle ICMP paketlerinin çok küçük olması ve MTU'ya normal şekilde sığması gerektiğinden, bunların parçalarının varlığı genellikle bir hataya veya saldırı girişimine işaret eder. iptables -A GİRİŞ -p icmp -f -j DAMLA

Sizin adınıza sahteciliği yasaklayın. iptables -A GİRİŞ -m conntrack --ctstate YENİ, GEÇERSİZ -p tcp --tcp-flags SYN,ACK SYN,ACK -j LOG --log düzeyi bilgisi --log-prefix "DROP SYN,ACK: " iptables - A INPUT -m conntrack --ctstate YENİ, GEÇERSİZ -p tcp --tcp-flags SYN,ACK SYN,ACK -j REJECT --tcp-reset ile reddet

Sonuçta, henüz açık olmayan bir bağlantı üzerinden SYN ve ACK bayrakları ayarlanmış bir paket alırsak (yalnızca bir SYN paketine verilen yanıtta bu bayrak kombinasyonu bulunur), bu, birinin bizim adımıza başka bir ana bilgisayara SYN paketi gönderdiği anlamına gelir. , yanıt bize geldi. Elbette saldırganın yine de sıra numarasını tahmin etmesi gerekiyor, ancak ona böyle bir şans vermemek daha iyidir. Yukarıdaki kurala göre, sunucumuz bir RST paketi ile yanıt verecek ve saldırıya uğrayan sunucu bu paketi aldıktan sonra bağlantıyı kapatacaktır. Güvenlik duvarı yapılandırmanıza böyle bir kural eklemeniz şiddetle tavsiye edilir, çünkü bir saldırgan sizin adınıza bir kimlik sahtekarlığı saldırısı gerçekleştirmeyi başarırsa soruşturma size yol açacaktır.

SYN seli

Yalnızca iletişim kanalını tıkamanın değil, aynı zamanda işletim sisteminin ağ yığınını artık yeni bağlantı isteklerini kabul edemeyecek bir duruma getirmenin yaygın yollarından biri. Var olmayan bir dönüş adresine sahip bir SYN paketi göndererek çok sayıda eşzamanlı TCP bağlantısını başlatma girişimine dayanmaktadır. Ulaşılamayan bir adrese yanıt ACK paketi göndermek için yapılan birkaç denemeden sonra çoğu işletim sistemi kurulamayan bağlantıyı kuyruğa alır. Ve ancak n'inci denemeden sonra bağlantı kapatılır. ACK paketlerinin akışı çok büyük olduğundan kuyruk kısa sürede dolar ve çekirdek yeni bir bağlantı açma girişimlerini reddeder. En akıllı DoS botları ayrıca, yalnızca açık hayati bağlantı noktalarına istek göndermek için bir saldırı başlatmadan önce sistemi analiz eder. Böyle bir saldırıyı tespit etmek kolaydır: hizmetlerden birine bağlanmayı denemeniz yeterlidir. Savunma önlemleri genellikle şunları içerir:

"Yarı açık" TCP bağlantılarının kuyruğunun arttırılması:

“Yarı açık” bağlantıların bekleme süresinin azaltılması:

TCP senkronizasyon çerezleri mekanizmasının etkinleştirilmesi:

UDP seli

Bant genişliği taşması yöntemi. UDP paketlerinin çeşitli UDP hizmetlerinin bağlantı noktalarına sonsuz gönderilmesine dayanmaktadır. Bu tür hizmetlerin dış dünyadan kesilmesi ve birim zaman başına bağlantı sayısına bir sınır getirilmesiyle kolayca ortadan kaldırılabilir.

#80 numaralı porta 5 bağlantı limiti belirledik. iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 5 -j REJECT # Bir IP'den smtp'ye yalnızca bir eşzamanlı bağlantıya izin ver iptables -A İLERİ -p tcp --syn --dport smtp -m connlimit --connlimit-above 1 -j DROP #1720 numaralı bağlantı noktasında 200 bağlantı sınırı belirleyin. iptables -A GİRİŞ -p tcp --syn --dport 1720 -m bağlantı sınırı --bağlantı sınırı 200'ün üzerinde -j REJECT # udp 5060 $IPT -A GİRİŞ -p udp --dport 5060 -m bağlantı sınırı --bağlantı sınırı 60'ın üzerinde -j LOG --log-seviyesi bilgisi --log-prefix "REJECT 5060: " $IPT -A GİRİŞ -p udp --dport 5060 -m connlimit --connlimit-60'ın üstünde -j REJECT # tcp 1720 $IPT -A GİRİŞ -p tcp --syn --dport 1720 -m bağlantı sınırı --bağlantı sınırı 60'ın üstünde -j LOG --log düzeyi bilgisi --log-prefix "REJECT 1720: " $IPT -A INPUT -p tcp --syn --dport 1720 -m bağlantı sınırı --bağlantı sınırı-60'ın üzerinde -j REDDET

ICMP seli

ICMP ECHO ağ tıkanıklığı tanılama protokolü (ping) isteklerinin monoton şekilde gönderilmesi yoluyla bant genişliğini tıkayan ve ağ yığınında yük oluşturmaya yönelik çok ilkel bir yöntem. Her iki yöndeki trafik akışları analiz edilerek kolayca tespit edilir: ICMP sel saldırısı sırasında bunlar neredeyse aynıdır. Neredeyse acısız bir mutlak koruma yöntemi, ICMP ECHO isteklerine verilen yanıtların devre dışı bırakılmasına dayanır:

Sysctl net.ipv4.icmp_echo_ignore_all=1

Veya bir güvenlik duvarı kullanarak:

Iptables -A GİRİŞ -p icmp -j DROP --icmp-type 8

HTTP seli

ps aux işlemlerinin sayısı | grep apache | tuvalet -l

Bağlantı noktası 80'deki bağlantı sayısı netstat -na | grep ":80\ " | tuvalet -l

Bağlantı isteklerinin geldiği IP adreslerinin listesini görüntüleyin: netstat -na | grep ":80\ " | sıralama | benzersiz -c | sıralama -nr

sistem

Sahteciliğe karşı net.ipv4.conf.default.rp_filter = 1

TCP bağlantısını her dakika kontrol edin. Karşı tarafta yasal bir araç varsa anında tepki verecektir. Varsayılan değer 2 saattir. net.ipv4.tcp_keepalive_time = 60

On saniye sonra tekrar deneyin net.ipv4.tcp_keepalive_intvl = 10

Net.ipv4.tcp_keepalive_probes bağlantısını kapatmadan önceki kontrol sayısı = 5

Debian: DDoS ile mücadele

Varsayılan olarak Debian ve diğer işletim sistemleri, bir botnet tarafından oluşturulan çok sayıda bağlantıyı destekleyemez. TCP/IP yığınını güçlendirmek için çekirdek ayarlarında değişiklik yapmak gerekir. Bu konfigürasyonun bir örneği:

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 = 996777216 net.ipv4 .tcp_rmem = 4096 87380 4194304 net.ipv4.tcp_mem= 786432 1048576 996777216 net.ipv4.tcp_wmem = 4096 87380 4194304 net.ipv4.tcp_max_orphans = 225536 0 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 kernel.shmall = 268435456 net. core.somaxconn= 16096

Çekirdek yapılandırmasını dikkatlice değiştirin ve sunucuyu yeniden başlatın...

FreeBSD: DDoS ile mücadele

Bir SYN-ACK isteğine yanıt paketi için bekleme süresini kısaltıyoruz (SYN taşmasına karşı koruma):

Sunucuyu kara deliğe dönüştürmek. Bu şekilde çekirdek, boş bağlantı noktalarına bağlanmaya çalışırken yanıt paketleri göndermez (rastgele bağlantı noktalarında DDoS sırasında makinedeki yükü azaltır):

ICMP mesajlarına verilen yanıt sayısını saniyede 50 ile sınırlandırıyoruz (ICMP taşmasına karşı koruma):

Sunucuya maksimum bağlantı sayısını artırıyoruz (her türlü DDoS'ye karşı koruma):

DEVICE_POLLING'i etkinleştiriyoruz - ağ sürücüsünün yüksek yüklerde çekirdek tarafından bağımsız olarak yoklanması (DDoS sırasında sistem üzerindeki yükü önemli ölçüde azaltır):

Çekirdeği “options DEVICE_POLLING” seçeneğiyle yeniden oluşturuyoruz; Yoklama mekanizmasını etkinleştirin: “sysctl kern.polling.enable=1”; /etc/sysctl.conf dosyasına “kern.polling.enable=1” girişini ekleyin.

Sistemlerinize bir DDoS fırtınası çarptığında umutsuz bir duruma düşmemek için onları böyle bir duruma dikkatle hazırlamanız gerekir:

Harici ağa doğrudan erişimi olan tüm sunucular, basit ve hızlı bir uzaktan yeniden başlatma için hazırlanmalıdır (sshd, Rus demokrasisinin babasını kurtaracaktır). Büyük bir avantaj, ana kanalın tıkanması durumunda sunucuya erişebileceğiniz ikinci bir yönetimsel ağ arayüzünün varlığı olacaktır.

Sunucuda kullanılan yazılımların her zaman güncel olması gerekmektedir. Tüm delikler yamandı, güncellemeler kuruldu (bir önyükleme kadar basit, çoğu kişinin uymadığı tavsiye). Bu sizi hizmetlerdeki hatalardan yararlanan DoS saldırılarına karşı koruyacaktır.

İdari kullanıma yönelik tüm dinleme ağı hizmetleri, bunlara erişimi olmayan hiç kimseden bir güvenlik duvarının arkasına gizlenmelidir. Bu durumda saldırgan bunları DoS saldırısı veya kaba kuvvet gerçekleştirmek için kullanamayacaktır.

Sunucuya (en yakın yönlendirici) yaklaşırken, yeni başlayan bir saldırı hakkında derhal bilgi edinmenize ve bunu önlemek için zamanında önlemler almanıza olanak tanıyan bir trafik analiz sistemi kurulmalıdır (kurtarmaya NetFlow).

Aslında SYN Flood saldırılarına karşı korunmaktan bahsedeceğiz:

Çok popüler bir DoS saldırısı, sunucunuza çok sayıda SYN paketi göndermeyi içerir. Bu durumda TCP iletişiminin kurulumu tamamlanmaz. Yarı açık bağlantı istekleri kuyruğu hızla doluyor ve normal bağlantıların kurulması engelleniyor. Bağlantının kesilmesi gerekmediğinden, böyle bir saldırı, saldıran makineden büyük kaynaklar gerektirmez, dolayısıyla uygulanması ve kontrolü kolaydır.

Bir SYN saldırısını tespit etmek kolaydır; netstat komutu yarı açık bağlantıların büyük bir listesini oluşturur:

Netstat -n --tcp | grep SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:1084 SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:1228 SYN_RECV tcp 0 0 xxx .xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:2652 SYN_RECV tcp 0 0 xxx.xxx.xxx.xxx:80 yyy.yyy.yyy.yyy:3446 SYN_RECV

Netstat -n --tcp | grep SYN_RECV | tuvalet -l 238

İlk önce parametreyi kontrol edelim tcp_syncookies- 1'e eşit olmalıdır:

Kedi /proc/sys/net/ipv4/tcp_syncookies 1

Bunu böyle bırakalım. Varsayılan olarak bu seçenek her zaman yeni dağıtımlarda etkindir.

Eğer tcp_syncookies seçeneği ayarlanmışsa (yalnızca çekirdek CONFIG_SYNCOOKIES ile oluşturulduğunda kullanılabilir), o zaman çekirdek, kuyruk dolana kadar TCP SYN paketlerini normal şekilde işler. Kuyruk dolduğunda SYN çerezleri mekanizması etkinleştirilir.

SYN çerezleri SYN kuyruğunu hiçbir şekilde kullanmaz. Bunun yerine, çekirdek her SYN paketine normal bir SYN|ACK olarak yanıt verir, ancak kaynak ve hedef IP adresleri ve bağlantı noktalarının yanı sıra paketin gönderilme zamanına dayalı olarak özel olarak oluşturulmuş bir sayı içerecektir. Saldırgan bu paketleri hiçbir zaman alamayacak ve dolayısıyla bunlara yanıt vermeyecektir. Normal bir bağlantı sırasında, bir sayı içeren üçüncü bir paket gönderilecek ve sunucu bunun SYN çerezine bir yanıt olup olmadığını kontrol edecek ve eğer öyleyse, SYN kuyruğunda karşılık gelen bir giriş olmasa bile bağlantıya izin verecektir. .

SYN çerezleri mekanizmasını etkinleştirmek, SYN taşkın saldırılarıyla mücadele etmenin çok basit bir yoludur. Bu, çerez oluşturma ve uzlaştırma ihtiyacı nedeniyle biraz daha fazla CPU kullanımı gerektirir. Alternatif çözüm tüm bağlantı isteklerini reddetmek olduğundan SYN çerezleri iyi bir seçimdir.

Ayrıca yarı açık bağlantıların kuyruğunu da artırmanız gerekir - tcp_max_syn_backlog(Debian Lenny'nin varsayılan olarak 1024 bağlantısı vardır):

Kedi /proc/sys/net/ipv4/tcp_max_syn_backlog 1024

Arttırmak:

Yankı "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog

Ayrıca bağlantı bekleme süresini de azaltabiliriz tcp_synack_rettry:

1 baytlık tam sayı değeri tcp_synack_retries, pasif TCP bağlantıları için SYNACK paketlerinin kaç kez yeniden deneneceğini belirtir. Deneme sayısı 255'i geçmemelidir. Bağlantı denemeleri için varsayılan değer olan 5, yaklaşık 180 saniyeye karşılık gelir.

1'e düşürün (bu yaklaşık 9 saniyedir):

Yankı "1" > /proc/sys/net/ipv4/tcp_synack_retries

tcp_fin_timeout

tcp_fin_timeout dosyasındaki tamsayı, soketin yerel taraf tarafından kapatıldıktan sonra ne kadar süre FIN-WAIT-2 durumunda kalacağını belirler. Eş bu bağlantıyı hiçbir zaman kapatamayabilir, bu nedenle zaman aşımı süresi dolduktan sonra kendi inisiyatifiyle kapatılmalıdır. Varsayılan zaman aşımı 60 saniyedir. 2.2 serisi çekirdekler genellikle 180 saniyelik bir değer kullanırdı ve bu değeri kaydedebilirsiniz, ancak meşgul WEB sunucularında yarı bozuk ölü bağlantıları sürdürerek çok fazla bellek israf etme riskiyle karşı karşıya olduğunuzu unutmayın. FIN-WAIT-2 durumundaki yuvalar, 1,5 KB'tan fazla bellek tüketmedikleri için FIN-WAIT-1'e göre daha az tehlikelidir ancak daha uzun süre dayanabilirler.

30 olarak değiştirin:

Yankı "30" > /proc/sys/net/ipv4/tcp_fin_timeout

tcp_keepalive_probes

tcp_keepalive_probes tamsayı değişkeni, bağlantının kapalı kabul edilmesinden önce gönderilen canlı tutma araştırmalarının sayısını belirtir. Varsayılan olarak 9 örnek iletilir.

Yankı "5" > /proc/sys/net/ipv4/tcp_keepalive_probes

tcp_keepalive_intvl

Tamsayı değişkeni tcp_keepalive_intvl örnekleme aralığını belirtir. tcp_keepalive_probes * tcp_keepalive_intvl ürünü, herhangi bir yanıt olmaması durumunda bağlantının kapatılacağı süreyi belirler. Varsayılan aralık 75 saniyedir; yani yanıt gelmemesi durumunda bağlantının kesilmesi için gereken süre yaklaşık 11 dakika olacaktır.

15'e ayarlayalım:

Yankı "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl

netdev_max_backlog

Bu, arayüzün paketleri çekirdeğin işleyebileceğinden daha hızlı alması durumunda işlenmek üzere kuyruğa alınacak maksimum paket sayısını belirtir.

Kedi /proc/sys/net/core/netdev_max_backlog 1000

Arttırmak:

Yankı "20000" > /proc/sys/net/core/netdev_max_backlog

somaxconn

Bağlantıları bekleyen maksimum açık yuva sayısı.

Kedi 1024

Arttırmak:

Yankı "20000" > /proc/sys/net/core/somaxconn

Çekirdek parametrelerinde yapılan bu tür değişiklikler yeniden başlatmanın ardından kaydedilmeyeceğinden şunu ekliyoruz: /etc/rc.local:

Echo "20000" > /proc/sys/net/ipv4/tcp_max_syn_backlog echo "1" > /proc/sys/net/ipv4/tcp_synack_retries echo "30" > /proc/sys/net/ipv4/tcp_fin_timeout echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl echo "20000" > /proc/sys/net/core/netdev_max_backlog echo "20000" > /proc/sys/ net/çekirdek/somaxconn

Ek olarak iptables'da birim zaman başına SYN paketi sayısına da bir sınır ekleyebilirsiniz:

Iptables -N syn_flood iptables -A GİRİŞ -p tcp --syn -j syn_flood iptables -A syn_flood -m limit --limit 500/s --limit-burst 1500 -j RETURN iptables -A syn_flood -j DROP

Yeni SYN paketlerinin sayısı saniyede maksimum 500'dür, 1500 eşiğinin aşılması durumunda yeni paketler engellenir:

Daha açık bir ifadeyle bu kriter, birim zaman başına belirli sayıda paketin (yani “çıkış” hızı) geçtiği bir çıkışı olan belirli bir kap olarak düşünülebilir. “Sızıntı” oranı tam olarak --limit değeriyle belirlenir. --limit-burst değeri toplam "kapasite hacmini" belirtir. Şimdi --limit 3/dakika --limit-burst 5 kuralını hayal edelim, sonra 5 paket geldikten sonra (çok kısa bir süre içinde) kapasite "dolacak" ve sonraki her paket kapasitenin "" dolmasına neden olacak. taşma” yani kriterin “tetiklenmesi”. 20 saniye sonra tanktaki “seviye” düşecek (-limit değerine göre) yani tankın “taşmasına” neden olmadan başka bir paketi kabul etmeye hazır hale gelecektir. kriteri tetikliyor.

Sahte SYN, paket başlıklarının, gerçek gönderenin yerini keyfi veya var olmayan bir IP adresini alacak şekilde taklit edildiği bir saldırıdır.

Sorumluluk reddi beyanları

Sorumluluk reddi beyanı #1

Sorumluluk reddi beyanı #2

Sorumluluk reddi beyanı #3

Biraz mekanik ve Vikipedi

İlk olarak TCP, çoğu uygulama protokolünün üzerinde yer aldığı en çok kullanılan taşıma protokollerinden biridir. İkinci olarak, uygulanmasını nispeten karmaşık ve kaynak yoğun hale getiren bir dizi özel özelliğe sahiptir (bağlantıların açıkça onaylanmış başlangıç ​​ve bitişi, akış kontrolü vb.).

Makalenin bağlamında, TCP bağlantısı kurma mekanizmasını (üç yönlü el sıkışma) düşünmek ilginçtir. İlk yaklaşım olarak, istemci-sunucu düzeyinde durum şöyle görünür: İstemci sunucuya bir SYN paketi gönderir ve buna SYN+ACK yanıt verir. İstemci, sunucunun SYN'sine bir ACK ile yanıt verir ve bağlantı kurulan bağlantıya girer. durum.

SYN saldırısı – açık bir sunucu bağlantı noktasına, şu veya bu nedenle gerçek bir bağlantı kurulmasına yol açmayan bir yığın SYN paketi göndermek; bu, bağlantı kuyruğunu aşan “yarı açık bağlantılar” oluşturulmasını gerektirir ve bu durum, sonraki istemcilere hizmeti reddetmek için sunucu. Ayrıca TCP RFC, sunucuyu gelen her SYN'ye yanıt vermeye zorlar ve bu da hem sunucu kaynaklarını hem de veri iletim kanalını etkiler. Ancak, eğer daha önce herhangi bir DDoS saldırısıyla karşılaştıysanız, yukarıda ben olmadan ne anlatıldığını biliyorsunuzdur. Özel önerilere geçelim.

Sahada tek başına

Birinci– sunucuya erişmeniz gerekiyor (evet, özellikle saldırı büyük ölçekli ve/veya uzun süreli ise bu da zor olabilir - sunucu tüm arabellekleri tüketmiştir veya %100 CPU yüküne sahiptir). Genellikle bunu yapmak için, saldırıya uğrayan hizmeti bir güvenlik duvarı ile kapatmak veya basitçe kapatmak yeterlidir - hizmet (ancak, bir saldırı tespit edilirse, bunun her durumda yapılması gerekir, sadece mümkünse). sunucuda başka bir şey yapın).

Saniye– Saldırıyla ilgili ilk bilgiyi alın. Gelen trafiği zaten izlediyseniz - olmasa da harika - güvenlik duvarını açın / hizmeti yükseltin ve tam olarak neye saldırıldığını ve saldırının saniye başına paket cinsinden boyutunun ne olduğunu bulmak için eski güzel tcpdump ve netstat'ı kullanın. Yol boyunca, hizmetinizin tipik hedef kitlesine dahil olup olmadıklarına bakılmaksızın, toplu isteklerin geldiği ağları hızlı bir şekilde görüntüleyebilirsiniz. Bütün bunlar gelecekte faydalı olacaktır.

Üçüncü– Saldırıya uğrayan IP adresinin bulunduğu arayüzde yalnızca bir tane kalmalı. Her takma ad sistem performansını düşürecektir. Bu farklı sistemler için farklı rakamlarla ifade ediliyor ama bu rakamlar ciddi, her bir takma ad saniyede 2-3 bin ek pakete mal olabiliyor.

Dördüncü– saldırıya uğrayan adrese gelen trafik için herhangi bir güvenlik duvarı kullanıyorsanız, engelleme dışındaki tüm kurallar devre dışı bırakılmalıdır – örneğin, sahte bir SYN saldırısında, PF'den gelen SYN proxy'sinin size yardımcı olma olasılığı sıfıra düşer ve CPU bu durumda olur. çok ciddiye alacaktır.

Beşinci– sistemin kurulması. Burada mucize olmayacak, çalıların arasında hazırlanmış sürücüler ve özel olarak satın alınmış ağ kartları şeklinde bir piyanoya ihtiyaç duyuyorlar ve bir SYN saldırısı alma yeteneğini ciddi şekilde etkileyen yalnızca iki genel öneri uzun zamandır herkes tarafından biliniyor:
- Kesinti işlemeyi sunucu işlemcileri arasında yaymak;
- Senkronizasyon çerezlerini etkinleştirin ve senkronizasyon önbelleğini devre dışı bırakın.

Sistem ayarının geri kalanı, saldırı koşullarında belirleyici olması pek mümkün olmayan ek 5-10 bin paketin sıkıştırılmasına yardımcı olacaktır. Herkes için yararlı olması durumunda, en genel yapılandırmayı burada bulabilirsiniz (çekirdeğin veya özel sürücülerin yeniden oluşturulmasını gerektiren seçenekleri etkinleştirmeden):

Net.isr.direct=1 kern.ipc.nmbclusters=400000 net.inet.tcp.nolocaltimewait=1 net.inet.tcp.recvspace=16384 net.inet.tcp.sendspace=32768 net.inet.tcp.msl=5000 net.inet.tcp.blackhole=1 net.inet.ip.intr_queue_maxlen=3000 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.log_redirect=1 net.inet.ip .redirect=0 net.inet.icmp.maskrepl=1 net.inet.tcp.syncookies_only=1 net.route.netisr_maxqlen=4096 kern.ipc.maxsockbuf=83886080 net.inet.ip.intr_queue_maxlen=10240
Bu yönergelere göre yapılandırılmış masaüstü düzeyinde bir sistem:

İlk# netstat -w1 -h -d giriş (Toplam) çıkış paketleri hatalar idrop'lar baytlar paketler hatalar baytlar toplamalar düşer 260K 0 0 15M 230K 0 13M 0 0
Aşağıdaki önerilere göre yapılandırılmış bir IBM System x3630 M3 düzeyinde sistem:

İkinci# netstat -w1 -h -d giriş (Toplam) çıkış paketleri hatalar idrop'lar baytlar paketler hatalar baytlar toplamalar düşer 477K 0 0 36M 457K 0 25M 0 0
Bir sonraki başlıkta size işletim sisteminin ve makinelerin detaylı konfigürasyonlarını ve aslında bunlara nasıl ulaştığımızı anlatmaya çalışacağım.

Hadi bir şey yapalım

Burada küçük bir ara vermeye değer - çoğu barındırma şirketi, eğer yardım ederlerse, bir saldırıya karşı mücadelede yardım etme konusunda son derece isteksiz olacaktır ve bunun için onları suçlamak zordur. Ancak en azından saldırı hakkında veri sağlarlar; koruma sağlayıcılarla çalışmanız gerekiyorsa, bu, saldırı sırasında topladığınız bilgilerle birleştiğinde hayatı çok daha kolaylaştıracaktır.

Anlayan bir ev sahibine rastlarsanız (ki bu gerçekten çok nadir) – daha sonra aşağıdaki algoritmaya göre çalışırız - paralel ve blok, blok ve paralel:
Birden fazla ağ kartımız varsa (değilse, lütfen bunları yükleyin) - bunları LACP moduna açıyoruz (bunun için ana bilgisayarın anahtarında benzer seçenekleri etkinleştirmemiz gerekecek) - bu aslında performansta bir buçuk artış sağlayacaktır (Sürecin bazı inceliklerine daha sonra bakacağız - içindeki enginliği kucaklamak için. Konu bir türlü yürümüyor) Aşağıdaki performansa ulaşıyoruz:

İkinci# netstat -w1 -h -d giriş (Toplam) çıkış paketleri errs idrops bayt paketler errs bayt colls düşer 1,2M 16K 0 65M 1,1M 0 59M 0 0
Lütfen kullanılmayan tüm bağlantı noktalarını ve protokolleri engelleyin; bir SYN saldırısı kolaylıkla bir UDP saldırısıyla değiştirilebilir.
Hemen hemen her barındırma şirketi bu eylemleri gerçekleştirebilir. Ancak ciddi bir şirketle çalışacak kadar şanslıysanız, projenizin hedef kitlesinin çoğunun yaşamadığı bir bölgeden (örneğin Çin) gelen trafiğin engellenmesini isteyin - bu genellikle ağınızın omurga sağlayıcıları için bir kara delik olduğunu duyurmak anlamına gelir belli bir bölgede. Kural olarak, ucuzluğu ve kitlesel dağıtımı nedeniyle bir SYN saldırısı Asya'dan gerçekleştirilir ve bu nedenle böyle bir duyuru, saldırıya karşı mücadelede ciddi şekilde yardımcı olabilir veya olasılığını tamamen ortadan kaldırabilir.

Yukarıda açıklanan önlemlere ek olarak, GeoDNS benzeri bir hizmetin kullanılmasını önerebiliriz - belirli koşullar altında (örneğin, saldırı bir etki alanında gerçekleştirilir), bu, belirli ağlar için bir kara delik duyurulmasına benzer şekilde çalışacaktır.

Nihayet

GÜNCELLEME. Devamı yazılıyor ve yakında burada yayınlanacak. Bizimle kal!

SYN taşması saldırısı, bir saldırganın hedef sistemin TCP protokolünü kullanan hizmetlerine çok sayıda SYN isteği gönderdiği bir hizmet reddi saldırısı biçimidir. Bu, sistemin yasal trafiğe bile yanıt vermemesine neden olacak şekilde sunucu kaynaklarını tüketir. Bu saldırı, TCP protokolünü kullanan herhangi bir hizmette, ancak esas olarak web hizmetinde gerçekleşebilir. Bu eğitimde SYN taşkın saldırılarının temellerini ve azaltma adımlarını ayrıntılı olarak ele alacağız.

SYN Flood saldırısı, İletim Kontrol Protokolünün (TCP) 3 yönlü el sıkışma adı verilen bir uygulama özelliğinden yararlanır. Normal bir 3'lü el sıkışmada şu adımlar izlenir:

1. İstemci, sunucuya bir SYN (senkronizasyon) mesajı göndererek bağlantı ister.
2. Sunucu, istemciye SYN-ACK göndererek bu isteği onaylar.
3. İstemci ACK ile yanıt verir ve bağlantı kurulur.

SYN Flood saldırısı, sunucuya beklenen ACK koduyla yanıt vermeyerek çalışır. Bu yarı açık bağlantılarla, hedef makinenin TCP biriktirme listesi dolacak ve dolayısıyla tüm yeni bağlantılar göz ardı edilebilecektir. Bu, meşru kullanıcıların da göz ardı edilmesine neden olacaktır.

Bu saldırı iki şekilde gerçekleşebilir:

1. Doğrudan Saldırı

Bu tür saldırılarda saldırganlar IP kaynak adreslerini yanıltmadan hızlı bir şekilde SYN segmentleri gönderir. Bu tür bir saldırı tespit edildiğinde savunmak çok kolaydır, çünkü saldırıyı gerçekleştirecek olan saldırganın kaynak IP adresine sahip paketleri engellemek için basit bir güvenlik duvarı kuralı ekleyebiliriz.

2. IP Adresi Sahteciliğinin Kullanılması

Bu, doğrudan saldırıya göre daha karmaşık bir saldırı şeklidir. Bu yöntemde, kötü amaçlı makine, sahte IP adreslerinden hedef makineye SYN istek akınları göndererek sunucunun sahte bir IP adresine SYN-ACK göndermesine neden olur; sunucu, ACK göndermeyeceğini çünkü asla göndermeyeceğini "bilir". bir SYN gönderdi.

SYN Flood Saldırısını Tespit Etme

Bir web sitesi ziyaretçisine yönelik SYN Flood saldırısının genel belirtisi, bir sitenin yüklenmesinin uzun sürmesi veya bir sayfanın bazı öğelerini yüklerken diğerlerini yüklememesidir. Bir web sunucusuna SYN Flood saldırısından şüpheleniyorsanız “SYN_RECEIVED” durumunda olan web sunucusu bağlantı isteklerini kontrol etmek için kullanabilirsiniz.

netstat -ton balığı | gr:80 | grep SYN_RECV

Bu durumda çok sayıda bağlantı gösteriliyorsa sunucu SYN Flood saldırısı altında olabilir. Saldırı tek bir IP adresinden çok sayıda SYN_RECV paketi ile doğrudan yapılıyorsa, o IP adresini güvenlik duvarına ekleyerek bu saldırıyı durdurabilirsiniz. Sunucunuzda APF veya güvenlik duvarı yüklüyse, bunu aşağıdaki komutu yürüterek gerçekleştirebilirsiniz:

apf –d IP ADRESİ
csf –d IP ADRESİ

SYN Flood Saldırısını Savunmak

SYN çerezlerini kullanma

SYN Flood saldırısından korunmanın en etkili yöntemi budur. SYN çerezlerinin kullanımı, sunucunun SYN kuyruğu dolduğunda bağlantıların kesilmesini önlemesine olanak tanır. Bunun yerine sunucu, SYN kuyruğu büyütülmüş gibi davranır. Sunucu, istemciye uygun SYN+ACK yanıtını geri gönderir ancak SYN kuyruğu girişini atar. Sunucu daha sonra istemciden bir ACK yanıtı alırsa, TCP sıra numarasında kodlanan bilgileri kullanarak SYN kuyruk girişini yeniden oluşturabilir.

SYN çerezleri /etc/sysctl.conf dosyasına aşağıdakiler eklenerek etkinleştirilebilir

net.ipv4.tcp_syncookies = 1

Sysctl yapılandırma dosyasını değiştirdikten sonra /etc/sysctl.conf dosyasından sysctl ayarlarını yüklemek için aşağıdaki komutu uygulamanız gerekir.

SYN biriktirme kuyruğunu artırma

İsteğe bağlı bir savunma tekniği, SYS biriktirme kuyruğu boyutunu artırmaktır. Varsayılan boyut 1024'tür. Bu, /etc/sysctl.conf dosyasına aşağıdakileri ekleyerek yapılabilir.

net.ipv4.tcp_max_syn_backlog = 2048

SYN_ACK yeniden denemelerinin azaltılması

Çekirdek parametresinde tcp_synack_retries ayarının değiştirilmesi, çekirdeğin SYN_RECV durum bağlantılarını daha erken kapatmasına neden olur. Varsayılan değer 5'tir.

net.ipv4.tcp_synack_retries = 3

SYN_RECV zaman aşımını ayarlama

SYN_RECV için zaman aşımı değerinin düşürülmesi, SYN taşması saldırısının azaltılmasına yardımcı olacaktır. Varsayılan değer 60 olup bunu 40 ya da 45’e düşürebiliriz. Bu işlemi sysctl.conf dosyasına aşağıdaki satırı ekleyerek yapabiliriz.

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv=45

IP sahtekarlığını önleme

Aşağıdaki sysctl parametresi, SYN saldırıları için kullanılan IP sahtekarlığına karşı korunmaya yardımcı olacaktır.

net.ipv4.conf.all.rp_filter = 1

Birçok barındırma şirketi, Netscreen veya Appsafe gibi SYN taşması savunmasını kullanan güvenlik duvarlarını dağıtarak SYN saldırılarına karşı koruma sağlar.