Syn Proxy'nin bilinmeyenleri - Nass oluyor da oluyor?

Bu blog yazısında Syn Flood saldırılarına karşı kullanılan savunma mekanizmalarından Syn Proxy'yi anlatacağım. İnternet servis sağlayıcılarından Superonline'da katıldığım görüşmede açıldı bu konu,soruyu soran garibanın da detayları bilmediği anlaşılıyordu. Blogun teması az bilineni anlatmak olduğu için ana fikirden kısaca aşağıdaki grafikle bahsedeceğim.Bizi ilgilendiren,syn-proxy bahsinin geçtiği her yerde gördüğünüz bu grafikte anlatılmayanlar;

Resim 1. Güvenlik çözümü ( FW / IPS ) hedef sunucu imiş gibi istemciden gelen iletişim isteklerini karşılar. İletişim isteği spoofed yani sahte bir kaynaktan gelmiyorsa şayet ve güvenlik çözümü istemciyle 3 yollu el sıkışmayı (3-way-handshake) tamamlayabildiyse bu isteği bu defa istemci imiş gibi sunucuya iletir, bir başka deyişle 3-way-handshake i tekrar eder (replay). Daha sonra istemci ve sunucu arasındaki veri iletişmi, kurulan bu bağlantı üzerinden devam eder.İstek spoofed Ip adresinden geliyorsa güvenlik çözümünün SYN-ACK bayraklı paketi ACK bayraklı paketle cevaplanmayacaktır,dolayısıyla istek sunucuya iletilmeyecektir. Sunucu da olan bitenden habersiz mutlu mesut çalışmaya devam eder.

Bildiğiniz ya da bildiğinizi umduğum gibi UDP'den farklı olarak TCP iletişimin kontrol altında olduğu bir prokol ve bu kontrol de Sequence Number, Acknowledgement Number, Window, Checksum gibi TCP headerlarla sağlanıyor. Alış verişi yapılan paketler özellikle Sequence ve Acknowledgement sayılarına göre sıraya konuyor, alınmadıysa tekrar gönderilmesi isteniyor ya da paket değerlendirilmeye alınmıyor. 3-way handshake sırasında her iki ucun oluşturduğu Sequence number dediğimiz değer ise tahmin edilemez olmalı aksi halde protokol yeni tehditlere ve saldırılara açık hale gelir ( ki geçmişte bu zaafiyetin kullanıldığı saldırı teknikleri de geliştirilmiştir bkz TCP Sequence Number Prediction ve TCP Reset Attacks ).

Birinci 3-way-handshake de güvenlik çözümü, sunucu imiş gibi davranırken kendince bir sequence number üretir ve handshake'i bu sequence number ile tamamlar. İkinci 3-way-handshake'de ise sunucu kendince bir sequence number üretecektir.Anlaşılması gereken istemci ve güvenlik çözümü arasındaki birinci 3-way-handshake sonunda güvenlik çözümünün üreteceği Sequence sayısı ile güvenlik çözümü ve sunucu arasındaki ikinci 3-way-handshake sonunda sunucunun üreteceği Sequence sayısının birbirinden farklı olacağı (bakınız bir önceki paragraf), sunucunun ürettiği gerçek Sequence numarasını ve sunucu Receive Buffer boyutunu (Window Size) bilmeden istemcinin sunucu ile nasıl iletişim kuracağı.

Resim 2

Resim 2'de gösterildiği gibi istemci ve sunucu, kendileriyle yapılan 3-yollu-el sıkışma sonucunda üretilen Sequence numaralarıyla doğrudan iletişim kuramazlar. Bunu yapmaya çalıştıklarında Sequence numaraları uyuşmazlık göstereceği için karşılıklı birbirlerinin paketlerini - herhangi bir iletişimin parçası olmadığı düşüncesiyle - kabul etmezler ve binbir zahmetle kurulan iletişim 3-yollu el sıkışmanın hemen sonrasında kesilir.

Bu problemin çözümü ve cevabı yine güvenlik çözümünde saklı, Syn-Proxy mekanizmasında alışverişi yapılan paketler aslında Resim 3'de gösterildiği gibi;

Resim 3. Syn-Proxy korumasında HTTP erişimi

İletişimin sağlıklı yapılması için gerekli Windows Size ( receive buffer'da ne kadar boş alan kaldığı) değeri ise şu şekilde istemciye bildirilir; 2 No'lu paketle güvenlik çözümü window size'ı 0 olan bir cevap gönderir ve 5. adımda sunucunun window size'ını yani asıl alabileceği veri boyutunu gösteren değeri (Resimde w ile gösterilen) 7 No'lu pakette istemciye bildirir.Böylelikle istemci sunucuya gönderebileceği veri miktarını daha doğrusu sunucunun bu bağlantı için ayırdığı Receive Buffer değerini öğrenmiş olur. Güvenlik çözümü 2 No'lu paket ile Window Size'ı 0 olarak bildirdiği için istemci Windows Size değeri artana kadar (Paket 7 - Window Update) sunucuya veri göndermez.Genel inanışın ve Resim 1'deki yaygın gösterişin aksine güvenlik çözümünüz 3-yollu el sıkışmadan sonra "Benden bu kadar kardeşler,siz güzel güzel konuşun" deyip aradan çekilmez,kurulan bağlantıda alınan-gönderilen her pakete müdahele eder ve paketin yönüne bağlı olarak Sequence ve Acknowledgement sayılarını olması gerektiği gibi ( taraflarla yapılan 3'lü el sıkışmada kullanılan Sequence numaralarına göre) değiştirir. Bu yüzden Syn-Proxy statefull bir koruma yöntemidir ve Syn-Cookie yöntemine göre daha fazla CPU kaynağı gerektirir,güvenlik çözümünde etkin hale getirilirken eşik değerler iyi değerlendirilmeli ve belirlenmelidir.

Syn-Cookie mekanizmasını çeşitli Linux işletim sistemlerinde de görebilirsiniz ama Syn-Proxy yapısı gereği sadece Firewall ve IPS gibi güvenlik çözümlerinde kullanıldığında etkili olabilen bir yöntemdir. Bir sonraki muhtemelen Syn-Cookie hakkında olur, ya da olmayabilir de :)