Syn Cookie/Syn Proxy Kullanan Sistemleri Belirleme

  Notlarım arasından Mersin Üniversitesinde katıldığım Akademik Bilişim - Güvenlik 101 kursu, Bilgi Güvenliği Akademisi'nden Mehmet Hocamın notlarından esinlenerek Bilgi Güvenliği Akademisi (BGA) sitesinden aldığım yazıyı paylaşmak isterim. 

    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. Her ikisi ile ilgili detay bilgi için http://www.bga.com.tr/wp-content/plugins/download-monitor/download.php?id=28 adresi ziyaret edilebilir. *İ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 basit: 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 bakmak. Eğer iki TTL değeri arasında fark varsa önde bir koruma sistemi var ve Syncookie/synproxy yapıyor diyebiliriz. 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 3'lü el sıkışmasını tamamlayacak şekilde paket gönderip sonraki paketlerin TTL değerlerini incelersek arada bir sistem var mı yok mu bulabiliriz. 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 synproxy'lik 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 [.], ck sum 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 ( http://nmap.org ) 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

Nmap done: 1 IP address (1 host up) scanned in 0.59 seconds