Syn Cookie/Syn Proxy Kullanan Sistemleri Belirleme

Günümüz DDoS saldırılarında en sık tercih edilen yöntemlerden biri SYN flood saldırılarıdır. Bu saldırı tipinde amaç hedef sistemin yarı açık bağlantı limitlerini zorlayarak hizmet veremez hale getirilmesidir. Önlem alınmayan bir sisteme yönelik gönderilecek  ortalama 2000 – 30000 SYN paketi ile  hedef sistem servis veremez hale getirilebilir.

Güvenlik sektöründe bu saldırıyı engellemek amacıyla iki temel yöntem geliştirilmiştir.

Syn cookie ve syn proxy. Her iki yöntemde de amaç kaynağı doğrulanmamış SYN paketlerinin korunaklı sisteme ulaştırılmamasıdır. Yani öndeki sistem (Firewall/IPS, DDoS engelleme sistemi, Load balancer vs) gelen her SYN paketi için geriye bir adet SYN paketi göndererek son ACK paketinin gelmesini bekler. Son ACK paketi gelmezse gönderici sahte ip adresindendir diyerek sistemden kaynak ayırmaz, son ACK paketi gelirse aradan çekilerek arkadaki sisteme paketleri iletmeye başlar.

Not: İki yöntem haricinde yaygın kullanılmayan bazı yöntemler de mevcuttur.

Hedef Sistem Önündeki Syn Proxy/Syn Cookie Koruması Nasıl Belirlenebilir?

Mantık: hedef sisteme önce üçlü el sıkışmayı tamamlamamış paketler göndererek dönen SYN-ACK cevaplarındaki TTL değerine bakmak, ardından üçlü el sıkışma tamamlanarak dönen paketler arasındaki TTL değerlerine bakmaktır. Eğer iki TTL değeri arasında fark varsa önde bir koruma sistemi var ve Syncookie/synproxy yapıyor yorumu yapılır.

Burada dikkat edilmesi gereken en önemli husus: Bu tip yöntemlerin %100 kesin sonuç vermeyeceğidir. Bazı sistemlerde SYN Cookie belirli sayıda SYN paketi geldikten sonra devreye giriyor olabilir. Bazı sistemlerde de her gelen paket için syncookie/synproxy’lik yapıyor olabilir. Bu ip yapılandırmalar da çeşitli ek testlerle ortaya çıkartılabilir.

Hedef Sisteme SYN paketi gönderme:

root@bt:~# hping3 -p 80 -S synack.bga.com.tr -c 1
HPING synack.bga.com.tr (eth1 50.22.202.132): S set, 40 headers + 0 data bytes
len=46 ip=50.22.202.132 ttl=51 DF id=36533 sport=80 flags=SA seq=0 win=0 rtt=146.5 ms
— synack.bga.com.tr hping statistic —
1 packets tramitted, 1 packets received,
0% packet loss round-trip min/avg/max = 146.5/146.5/146.5 ms

Karşı taraftan sönen SYN-ACK paketi incelenirse pakete ait TTL değerinin 51 olduğu görülecektir.

Bu paketi inceleyerek şu şekilde bir yorum yapılabilir: Hedef sistem gönderilen SYN paketlerine karşılık TTL değeri 64’den başlayan SYN-ACK paketi dönmektedir. Aynı hedefe yönelik üçlü el sıkışmasını tamamlayacak şekilde paket gönderip sonraki paketlerin TTL değerlerini incelersek arada bir sistem var mı, yok mu? Anlaşılabilir.

Hedef sistemin 80. portuna telnet ile bağlanıp HEAD komutu gönderildiğinde karşı tarafta bu paketler SYN cookie/proxy yapan sistemi aşıp gerçek sisteme ulaşacaktır ve bu isteğe yanıt olarak synproxylik yapan sistem değil de arkadaki gerçek sistem cevap dönecektir.

Örnek:
root@bt:~# telnet synack.bga.com.tr 80
Trying 50.22.202.132…
Connected to synack.bga.com.tr.
Escape character is ‘^]’.
HEAD / HTTP/1.1
Connection closed by foreign host.

Hedef sisteme gidip gelen paketler tcpdump ile incelenirse…

root@bt:~# tcpdump -i eth1 -nt host synack.bga.com.tr -v
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes

SYN paketi
IP (tos 0x10, ttl 64, id 54116, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.101.49711 > 50.22.202.132.80: Flags [S], cksum 0xbed6 (incorrect -> 0xa01c), seq 3236392130, win 14600, options [mss 1460,sackOK,TS val 6668198 ecr 0,nop,wscale 5], length 0

SYN_ACK Paketi, TTL değeri 51
IP (tos 0x0, ttl 51, id 4731, offset 0, flags [DF], proto TCP (6), length 44) 50.22.202.132.80 > 192.168.1.101.49711: Flags [S.], cksum 0x88fc (correct), seq 3752820895, ack 3236392131, win 0, options [mss 1452], length 0

ACK paketi
IP (tos 0x10, ttl 64, id 54117, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.101.49711 > 50.22.202.132.80: Flags [.], cksum 0xbec2 (incorrect -> 0x67a9), ack 1, win 14600, length 0
IP (tos 0x0, ttl 51, id 4775, offset 0, flags [DF], proto TCP (6), length 40) 50.22.202.132.80 > 192.168.1.101.49711: Flags [.], cksum 0x89e1 (correct), ack 1, win 5840, length 0 ….

Hedef sistemden dönen paket incelenirse TTL değeri 50 olarak gözükecektir.

IP (tos 0x0, ttl 50, id 33611, offset 0, flags [DF], proto TCP (6), length 40) 50.22.202.132.80 > 192.168.1.101.42004: Flags [.], cksum 0xb96a (correct), ack 21, win 5840, length 0

Böylece biz hedef sistemin önünde syncookie/synproxylik yapan bir mekanizmanın olduğu şeklinde yorum yapabiliriz.

SYN Cookie/Proxy Koruması Olmayan Sisteme Yönelik Deneme:

# hping3 -p 80 -S www.cnn.com -c 1
HPING www.cnn.com (eth1 157.166.226.26): S set, 40 headers + 0 data bytes
len=46 ip=157.166.226.26 ttl=49 id=51742 sport=80 flags=SA seq=0 win=5840 rtt=167.9 ms TTL değeri 49. .

Dönen paketin TTL değeri 49. Ardından cnn.com’a üçlü el sıkışmayı tamamlayıp ek paketler gönderelim ve cevap olarak dönecek paketlerin TTL değerlerine bakalım.

root@bt:~# tcpdump -i eth1 -nt host cnn.com -v
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes

IP (tos 0x10, ttl 64, id 62142, offset 0, flags [DF], proto TCP (6), length 60) 192.168.1.101.57316 > 157.166.226.26.80: Flags [S], cksum 0x41fd (incorrect -> 0x59da), seq 2650161938, win 14600, options [mss 1460,sackOK,TS val 6795692 ecr 0,nop,wscale 5], length 0

IP (tos 0x0, ttl 49, id 29835, offset 0, flags [none], proto TCP (6), length 60) 157.166.226.26.80 > 192.168.1.101.57316: Flags [S.], cksum 0x6f81 (correct), seq 117734108, ack 2650161939, win 5792, options [mss 1460,sackOK,TS val 1238647033 ecr 6795692,nop,wscale 7], length 0

IP (tos 0x10, ttl 64, id 62143, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.101.57316 > 157.166.226.26.80: Flags [.], cksum 0x41f5 (incorrect -> 0xb2f9), ack 1, win 457, options [nop,nop,TS val 6795735 ecr 1238647033], length 0 …

IP (tos 0x0, ttl 49, id 29840, offset 0, flags [none], proto TCP (6), length 52) 157.166.226.26.80 > 192.168.1.101.57316: Flags [F.], cksum 0x8ba8 (correct), seq 169, ack 20, win 46, options [nop,nop,TS val 1238655298 ecr 6797758], length 0

Bakılacak olursa TTL değeri hep 49 olmaktadır. Bu da bize hedef sistem önünde devrede Syn cookie/proxylik yapan bir sistem olmadığını veya belirli bir paket gönderildikten sonra devreye gireceğini gösterir.

Ek olarak SYNProxy ile korunan sistemlere yönelik yapılacak klasik port tarama(SYN Scan) sonucu aşağıdaki gibi gözükecektir. SYNPRoxy’lik yapan sistem arkada hangi portun açık olup olmadığını bilmeksizin her gelen SYN paketi için SYN-ACK cevabı dönmektedir.

[root@depdep ~]# nmap test.bga.com.tr –top-ports 20 -sS
Starting Nmap 5.30BETA1 ( ) at 2011-06-19 14:17 EEST
Nmap scan report for test.bga.com.tr (1.2.3.4)
Host is up (0.0068s latency).
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp
53/tcp open domain
80/tcp open http
110/tcp open pop3
111/tcp open rpcbind
135/tcp open msrpc
139/tcp open netbios-ssn
143/tcp open imap
443/tcp open https
445/tcp open microsoft-ds
993/tcp open imaps
995/tcp open pop3s
1723/tcp open pptp
3306/tcp open mysql
3389/tcp open ms-term-serv
5900/tcp open vnc
8080/tcp open http-proxy
Nmap done: 1 IP address (1 host up) scanned in 0.59 seconds

1 Yorum

  1. db43hacks 21 Aralık 2015 19:15

    İlk olarak ellerinize sağlık, belirtmek istediğim birkaç nokta var. Siz de belirtmişsiniz her durumda doğru olamayabileceğini ben bunların nedenlerinden bahsetmek isterim: veriyi gönderdiğimiz cihazın internete geçidine kadar farklı yollar kullanılmasından dolayı oluşabilecek TTL değeri farklılıkları -görece olarak iç ağdakinden daha düşük- , iç ağda oluşabilecek TTL farklılıkları (ağ basitleştikçe olasılık azalır, intranet ve ağ cihazları geliştikçe artar), pasif OS belirleme yöntemlerine karşın rastgele üretilen TTL değerleri aklıma gelen parametreler.

    Diğer bir konu ise yine bu tarz saldırılara karşı kullanılan SYN Cach yöntemi, sizin bu yöntemlere karşın geliştirdiğiniz metotlara benzer şekilde SYN Cache keşfi için de bağlantı düşme süresi kıyaslanabilir. Bazı sistemlerde SYN Cache dolduğunda SYN Cookie kullanılıyormuş sayfasında dediğine göre kriptografik işlemler sisteme işlem yükü oluşturduğundan) bu aralığa denk getirirsek de işler karışır herhalde 🙂 , emeğinize sağlık kolay gelsin.

Yorum Yaz

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

*
*

Mail listemize üye olarak eğitim fırsatlarını kaçırmayın!
Eğitim ve ücretsiz etkinliklerizden haberdar olmak için e-posta listesimize üye olun!.