[Güvenlik Eğitimi] SYN Flood saldırıları, SYN çerez savunması ve Linux/FreeBSD için çekirdek parametre değişikliği

HackerBu arzu edilen ve umut vadeden bir kariyerdir. İyi hackerları takdir ediyorum ama kötü hackerlardan nefret ediyorum. Sözde kötü hacker, karşı taraftaki birinin fazla mesai yapmasına neden olan türden bir adamdır.

    SYN Flood saldırıları tipik bir hizmet redetme saldırısıdır. Sözde hizmet redetme saldırısı, mağdur ana veya ağın iyi hizmet sunamamasını engelleyerek saldırının amacına dolaylı olarak ulaşmaktır. Hackerlar, karşı tarafı fazla mesai yapmaya zorlayarak dengeli, yetenekli ve cesur olduklarını göstermek için bunu oynamayı severler, ama aslında hiçbir şey değil.

   1: SYN Flood saldırısı nedir?

    SYN Flood saldırıları, IPv4'teki TCP protokolünün üç el sıkışma sürecinden faydalanır. Bu protokol, bir uç diğer uca TCP bağlantısı başlatmak isterse, önce diğer tarafa bir TCP SYN (senkronize) paketi göndermesini, diğer tarafın aldıktan sonra TCP SYN + ACK paketini geri göndermesini ve başlatıcının TCP ACK (ACKnowledge Karakteri) paketini geri göndermesini ve böylece üç el sıkışmanın sona ermesini önler.

    Yukarıdaki süreçte bazı önemli kavramlar vardır:

    Kuyruk bağlı değil: Üç el sıkışma protokolünde, sunucu, her istemcinin SYN paketi (syn=j) için bir giriş açan bağlantısız bir kuyruk tutar; bu giriş sunucunun SYN paketini aldığını gösterir ve müşteriye onay verir, müşterinin onay paketini bekler. Bu girişlerle tanımlanan bağlantı sunucuda Syn_RECV durumdadır ve sunucu müşteriden onay paketi aldığında giriş silinir ve sunucu KURULMUŞ duruma girer. Başka bir deyişle, TCP sunucusu TCP SYN isteği paketini aldığında, TCP SYN+ACK paketini TCP istemcisine geri göndermeden önce, TCP sunucusu önce bu el tarafından oluşturulan TCP bağlantısına hizmet etmek için bir veri alanı ayırmalıdır. Genellikle, SYN paketi alındığında bağlantı durumu ACK paketi henüz alınmamış olsa daYarı açık bağlantı(Yarı açık bağlantı)。

    Backlog parametresi: Bağlantısız kuyruk sayısının maksimum sayısını gösterir.

    SYN-ACK yeniden iletim sayısı: Sunucu SYN-ACK paketini gönderdikten sonra, müşteri onay paketi alınmazsa, sunucu ilk yeniden iletimi yapar, bir süre bekler ve müşteri onay paketini almaz; ikinci yeniden iletimi yapar; yeniden iletim sayısı sistemin belirttiği maksimum yeniden iletim sayısını aşarsa, sistem bağlantı bilgilerini yarı bağlantı kuyruğundan siler. Her tekrar geçiş için bekleme süresinin mutlaka aynı olmadığını unutmayın.

    Yarı bağlantılı hayatta kalma süresi: Yarı bağlantı kuyruğundaki bir girişin hayatta kaldığı maksimum süreyi ifade eder; yani, servisin SYN paketini aldığı andan paketin geçersiz olduğu onaylandığı zamana kadar olan maksimum süredir ve zaman değeri, tüm yeniden iletim isteği paketleri için maksimum bekleme süresinin toplamıdır. Bazen yarı bağlantılı hayatta kalma süresi, SYN_RECV hayatta kalma süresi de diyoruz.

    En yaygın SYN flood saldırısında, saldırgan kısa sürede kurbana çok sayıda TCP SYN paketi gönderir; bu noktada saldırgan TCP istemcisi, mağdur ise TCP sunucusudur. Yukarıdaki açıklamaya göre, kurban her TCP SYN paketine belirli bir veri bölgesi atayacak, yeter ki SYN paketleri farklı kaynak adreslere sahip olsun (ki saldırganlar için kolayca sahte olurdu). Bu, TCP sunucu sistemine büyük bir yük getirir ve sonunda sistemin düzgün çalışmamasına neden olur.

    2. SYN çerezlerinin ilkesi

    SYN Flood saldırılarını etkili bir şekilde önlemenin yollarından biri SYN çerezleridir. SYN Kurabiye Sebebi D. J. Bernstain ve Eric Schenk tarafından icat edilmiştir.

    SYN çerezleri, SYN Flood saldırılarını önlemek için TCP sunucu tarafı üç yönlü el sıkışma protokolünün bir modifikasiyasıdır.İlkesi şudur:TCP sunucusu bir TCP SYN paketi alıp TCP SYN+ACK paketi döndürdüğünde, özel bir veri alanı tahsis etmez, ancak bu SYN paketine dayalı bir çerez değeri hesaplar. Bir TCP ACK paketi alındığında, TCP sunucusu bu çerez değerine göre TCP ACK paketinin meşruiyetini kontrol eder. Eğer yasalsa, gelecekteki TCP bağlantılarını yönetmek için özel bir veri alanı tahsis edilir.

    Linux ve FreeBSD'de SYN çerezlerini uygulamak için çekirdek parametrelerinin nasıl yapılandırılacağından bahsedelim

    Üç: Linux ayarları

    Sunucu yapılandırmanız iyi değilse, TCP TIME_WAIT soket sayısı 20.000 veya 30.000'e ulaşır ve sunucu kolayca sürüklenebilir. Linux çekirdeği parametreleri değiştirilerek sunucudaki TIME_WAIT soket sayısı azaltılabilir.

    TIME_WAIT aşağıdaki komutla görüntülenebilir:

Linux'ta, örneğin CentOS'ta, bunu /etc/sysctl.conf dosyasını değiştirerek başarabilirsiniz.

    Aşağıdaki satırları ekleyin:

Göstermek:

net.ipv4.tcp_syncookies = 1, SYN Çerezlerinin etkin olduğu anlamına gelir, bu da BOOLEAN'dır. SYN kuyruğun taşmasını beklediğinde, çerezlerin bununla ilgilenmesini etkinleştirin, bu da az sayıda SYN saldırısını önleyebilir ve varsayılan 0 olur, yani kapalıdır.
net.ipv4.tcp_tw_reuse = 1, yeniden kullanımın etkin olduğu anlamına gelir, bu da bir BOOLEAN'dır. Yeni TCP bağlantıları için TIME-WAIT soketlerinin yeniden kullanılmasına izin verir, varsayılan olarak 0 olur ve kapanmayı gösterir;
net.ipv4.tcp_tw_recycle = 1, TCP bağlantılarında TIME-WAIT soketlerinin hızlı geri dönüşümünü etkinleştirmek anlamına gelir; bu bir BOOLEAN'dır ve varsayılan 0'dır, yani kapalıdır.
net.ipv4.tcp_fin_timeout = 30, soket yerel bir istekle kapatıldığında, bu parametrenin FIN-WAIT-2 durumunda ne kadar kalacağını belirlediği anlamına gelir. Birim saniyelerdir.
net.ipv4.tcp_keepalive_time = 1200, keepalive kullanıldığında TCP'nin ne sıklıkla keepalive mesajı gönderdiğini gösterir. Varsayılan süre 2 saat, 20 dakikaya değiştirildi. Birim saniyelerdir.
net.ipv4.ip_local_port_range = 1024 65000, dışa bağlantı için kullanılan port aralığını gösterir. Varsayılan durum küçüktür: 32768'den 61000'e, 1024'ten 65000'e değiştirildi.
net.ipv4.tcp_max_syn_backlog = 8192, varsayılan olarak 1024 olan SYN kuyruğunun uzunluğunu gösterir ve bağlantı bekleyen daha fazla ağ bağlantısını karşılamak için artırılmış kuyruğun uzunluğu 8192'dir.
net.ipv4.tcp_max_tw_buckets = 5000, sistemin aynı anda TIME_WAIT tuttuğu maksimum soket sayısını gösterir ve bu sayı aşılarsa, TIME_WAIT soket hemen temizlenir ve uyarı mesajı basılacaktır. Varsayılan değer 180000, 5000 olarak değiştirildi. Apache ve Nginx gibi sunucular için önceki satırlardaki parametreler soket sayısını TIME_WAIT kadar azaltabilir, ancak Squid için bu etki pek iyi değil. Bu parametre, Squid sunucusunun çok sayıda TIME_WAIT soketi tarafından sürüklenmesini önlemek için maksimum TIME_WAIT soket sayısını kontrol eder.
net.ipv4.tcp_synack_retries ve net.ipv4.tcp_syn_retries SYN deneme sayısını tanımlar.

Konfigürasyonun etki edilmesi için aşağıdaki komutu çalıştırın:

/etc/sysctl.conf modunu değiştirmek istemiyorsanız, bunu yapmak için şu komutu da kullanabilirsiniz:

Dördüncüsü, FreeBSD altında kuruldu

    yayu'nun kişisel öğrenme bakış açısı: FreeBSD'deki syn'e karşı savunma, Linux'taki gibi olmayabilir, yapılandırılan parametreler tamamen aynı olmayabilir ve ilgili yapılandırma ile anlayış doğru olmayabilir:)

    TCP bağlantısında bir tane varMSL(maksimum segment ömrü)KavramMaksimum üretim süresiGenel uygulamalarda MSL değeri 30 saniye alırken, bazı uygulamalar 2 dakika sürer. TCP durum makinesinde "pasif kapatma": CLOSE_WAIT'den LAST_ACK'e kadar şu kural vardır: TCP aktif kapatma gerçekleştirip son ACK'yi geri gönderdiğinde, bağlantı MSL'den iki kat daha uzun süre TIME_WAIT durumunda kalmalıdır. Bu, TCP'nin son ACK'yı tekrar göndermesini sağlar, eğer ACK kaybolursa (diğer uç zamanla dolup son FIN'i tekrar gönderir).

    Bu kuralın varlığı, o adresteki bağlantının (istemci adresi, port ve sunucu tarafı adresi, port) bu 2*MSL süresi boyunca kullanılamayacağı sonucuna yol açar. Örneğin, bir bağlantıyı oluşturduktan sonra kapatıp hızlıca yeniden başlatırsak, port kullanılabilir olmaz.

    TIME_WAIT zaman 2*MSL. Yani net.inet.tcp.msl ayarlarıyla TIME_WAIT zamanı azaltabilirsiniz. Web sunucusu için bu değer 7500 veya 2000 olarak ayarlanabilir (bir web erişimi, sayfa 4~15 saniyeden fazla yanıp sönmemesi, vazgeçmeyi düşünebilirsiniz -_- )

    Parametre ayarı referansı:

FreeBSD'de yayu, /etc/sysctl.conf içeriğini etkili hale getirebilecek "/sbin/sysctl -p" gibi bir komut görmedi, bu yüzden sadece şu komutu kullandı: