Alper YALÇINER

Statefull firewall ne demek daha önce değinmiştik. şimdi iptables’ile bunun nasıl gerçekleştirildiğine daha yakından bakalım.

Statefull firewaling için linux State machine dediğimiz olaydan daha çok tracking machine olarak çalışır ( iz sürme makinası ), Sıksık ikisinin manası birbiri ile karıştırılsada aslında farklıdır. Yazıyı okuyup nasıl çalıştığı hakkında daha iyi bilgi edindiğinizde bunun önemini daha iyi anlayacağınızı ümit ediyorum.

.

Connection Tracking :

Linuxda connection tracking bazı özel uygulamalar haric ( irc, ftp vb ), ip_conntrack modülü ile sağlanır. hemen modüle yakından göz atalım.

bash-3.2# modprobe ip_conntrack
bash-3.2#
cat /proc/net/ip_conntrack dediğimizde şu şekilde bir çıktı alırız.

bash-3.2# cat /proc/net/ip_conntrack
tcp      6 98 TIME_WAIT src=10.70.20.3 dst=78.129.231.111 sport=60842 dport=80 packets=9 bytes=3980 src=78.129.231.111 dst=10.70.20.3 sport=80 dport=60842 packets=8 bytes=1154 [ASSURED] mark=0 secmark=0 use=1
tcp      6 38 TIME_WAIT src=10.70.20.3 dst=78.129.231.111 sport=60841 dport=80 packets=9 bytes=3804 src=78.129.231.111 dst=10.70.20.3 sport=80 dport=60841 packets=8 bytes=1154 [ASSURED] mark=0 secmark=0 use=1
tcp      6 431756 ESTABLISHED src=10.70.20.3 dst=93.94.250.210 sport=46845 dport=80 packets=10 bytes=1258 src=93.94.250.210 dst=10.70.20.3 sport=80 dport=46845 packets=8 bytes=10356 [ASSURED] mark=0 secmark=0 use=1
tcp      6 291 ESTABLISHED src=213.219.249.66 dst=10.70.20.3 sport=6667 dport=38699 packets=419 bytes=153150 src=10.70.20.3 dst=213.219.249.66 sport=38699 dport=6667 packets=459 bytes=29964 [ASSURED] mark=0 secmark=0 use=1
bash-3.2#

Biraz karışık gibi görünsede aslında oldukça basit, en alttaki freenode bağlantımızı alıp yakından inceleyelim.

tcp      6 291 ESTABLISHED src=213.219.249.66 dst=10.70.20.3 sport=6667 dport=38699 packets=419 bytes=153150 src=10.70.20.3 dst=213.219.249.66 sport=38699 dport=6667 packets=459 bytes=29964 [ASSURED] mark=0 secmark=0 use=1

Girdimiz bize ne diyor ?

• Bir protokolümüz var ve bu TCP dir.
• 6 yine TCP protokolüne  işaret edip tcp yerine decimal code olarak işaret edilmiş.
• Bu conntrack girdisi ne kadar süreyle kalmalı ( yaşamalı ) 291 sn eğer linux üzerinden söz konusu bağlantı ile ilgili hiç bir trafik geçmezse azalarak 0 a ulaştığında bu girdi silinir. (CLOSED )
• ESTABLISHED TCP bağlantının gerçekleştirildiğini ve iki nokta arasında data akışı olduğunu gösteriyor ( daha sonra ayrıntılarına gireceğiz. )
• src : paketi gönderen kaynak adresi, dikkat edilmesi gereken konu freenode server’a irc için bağlantı isteğini ilk ben göndermeme rağmen, kaynak freenode hedef benim local ip adresim görünüyor
• dst : paketin gideceği hedef adres benim local ip adresim.
• sport : bağlantı yapan kaynak adresdeki kaynak port numarası yani freenode üzerinde irc server’inden istek geliyor.
• dport : hedef tcp portu
• packets : 459 bytes 1 tcp paketinin boyutu
• bytes : bu bağlantı için gelen byte miktarı
• Buradan sonrası yukarıdakilerle aynı farkı ise tcp connection iki taraflı olduğu için busefer bizden freenode a giden bağlantının bilgilerini gösteriyor.
• mark=0 secmark=0 use=1 şu an için bizi ilgilendirmiyor.
• ASSURED bağlantının iki taraftanda yapılıp gerçekleştiğini belirtiyor. İstek yapılıp cevap dönmemiş olsaydı UNREPLIED olarak işaretlenecekti.

iptables ile statefull firewalling sanıldığından daha kompleks bir konudur. Eğer webde biraz araştırma yapacak olursanız forumların bunun la ilgili yaşanan problemlerle dolup taştığını gözlemlersiniz. Sorun linux da herhangi bir eksiklik olmasından değl, konunun tam olarak anlaşılmamasından dolayı çıkmaktadır. bu yüzden öncelikle ip_conntrack modülünün yapılandırılmasına daha yakından göz atalım.

/proc/sys/net/ipv4/netfilter/ip_conntrack_max

Aynı anda kaç adet connection tracking yapabileceğimizi belirtir. ” cat /proc/net/ip_conntrack | wc -l ” diyerek anlık kaç bağlantı olduğunu görebilirsiniz.

” cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max ” izin verilen maximum girdiyi gösterir. Aynı çıktıya sysctl ile bakmak için ” sysctl -n net.ipv4.netfilter.ip_conntrack_max ” komutunu kullanabilirsiniz. Ne kadara izin verilmesi gerektiğinin gerçekten bir ölçüsü yok, resferans olmamak kayıdı ile normal bir web kullanıcısını 50 yi geçmediğini, torrent kullanıcısının 250 ye erişebildiğini söyleyebilirim. Eğer bir web server imiz varsa her bir kullanıcının 1 adet girdi işgal edeceğini belirtmeye gerek yok sanırım. söz konusu limit dolduğunda “ip_conntrack: table full, dropping packet.” hatası alınır.

Connection tracking RAM ve CPU harcamasında hiç te iktisatlı değildir. Düşük limit vermek paketlerimizin drop olmasına yol açarken yüksek limit vermekte sistem kaynaklarımızın bitmesine sebebiyet verebilir. 1 gb ram için bu değer “net.ipv4.netfilter.ip_conntrack_max = 65536″ olarak görülebilir. Peki 1 gb ram’imiz yoksa ? connection tracking kernel’de çalıştığı için swap kullanamaz. Bu değeri’de elimizde bulunan boş ram miktarına göre optimize etmeliyiz. Table dolduğunda yeni paketler droplanmakla beraber daha önceden yapılmış bağlantılar işlerine devam edeceklerdir. Söz konusu sorun özellikle şirketlerde firma tarafından tavsiye edilen, makimum client adedinden daha fazlasının bağlanmış olduğu linux tabanlı ADSL modem/router larda yada networkde kaynakları tüketen bir virus olduğunda aktif bağlantıların ( irc download rdp vb. ) işlerine devam edebildiği halde yeni bir bağlantıya izin vermemesi şeklinde görülür. örneğin yeni bir websayfası açıldığında internet bağlantınız yokmuş gibi sayfa görüntülenemiyor hatası alırsınız ama hali hazırda devam eden işlemleriniz kesintiye uğramaz.

ip_conntrack_max değerinin ram’e göre hesaplama formülü :

CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (x / 32)

Buradaki X değeri CPU architecture gösterir. 32bit veya 64 bit gibi
örneğin 1gb ram için CONTRACK değeri 65536 32 bit sistemler için 64 bit sistemler için ise 131072 dir.( firewall sistemleri 64 bit üzerine kurmak için jiffie hariç ikinci bir sebep )

echo “yenideğer” > /proc/sys/net/ipv4/netfilter/ip_conntrack_max diyerek yeni değeri girebilirsiniz. yada sysctl kullanarak : sysctl net.ipv4.netfilter.ip_conntrack_max=65536 gibi. Bu değeri /etc/sysctl.conf içerisine girerek her açılışta aktif olmasını sağlayabilirsiniz.

.

Kullanıcı Tarafındaki State’ler :

Connection tracking tablolarındaki state’ler ; kullanılan protokole bağlı olarak bir çok değer içerebilir. bunun yanında –state parametresi ile iptables’kullanabileceğimiz ana state ( durum)’lar mevcuttur. bunlar.

NEW :

Örneğin tcp bağlantıda SYN isteği gönderilip herhangi bir data geri dönmemişse NEW şeklinde bir state alırız. Ne yazıkki durum her zaman bu şekilde değildir. Bazı durumlarda, SYN olmasada state table a yeni girmiş paketler NEW olarak adlandırılabilirler. Diğer firewallarla yapılan bağlantılar kaybolduğunda, Bağlantı timeout olduğu halde oturumun kapatılmadığı gibi durumları tesbit etmek için kullanılabilir.

ESTABLISHED :

En basit anlatımıyla Bir host diğer bir host a bir paket gönderip diğer taraf ona cevap verdiğinde paketin State table’da durumu NEW olmaktan çıkarak ESTABLISHED durumuna geçer. protokole göre değişik şartlar gerekebilir. örneğin : ICMP reply mesajları yeterlidir.

RELATED :

Hali hazırda State table içerisinde ESTABLISHED olarak bilinen bir bağlantı varsa, Server tarafından ikinci bir bağlantı yapılmaya çalışılıp kernel tarafından bunun söz konusu ESTABLISHED bağlantı ile alakalı olduğu anlaşılırsa RELATED state durumu söz konusu olur. basitleştirmek için örnek verecek olursak : dcc için irc modülü yüklendiğinde kernel DCC isteği geldiğinde bunun irc bağlantısı için olduğunu çözümleyerek RELATED olarak işaretlemektedir. ( bu konuya daha sonra ayrıntılı değineceğiz Kompleks bağlantılar )

INVALID :

Bu Bilinen diğer State kavramlarına giren paketleri belirtmek için kullanılır. genellikle sistem ram i tükendiğinde veya, bilinmeyen bir ICMP error mesajı dönüldüğü gibi sebeplerden oluşur. genel olarak bu durumdaki paketlerin droplanması iyi bir yöntemdir.

UNTRACKED :

iptables tarafından -j NOTRACK olarak işaretlenmiş paketlerdir. bu durumda paketlerin Statelerinin izlenemeyeceğini göz ardı etmeyiniz. ( Statefull firewaling ve nat helpers kullanılamaz bu pakette )

.

TCP Bağlantılar :

Bir TCP bağlantısı her zaman için 3 way handshaking  ( 3 yollu el sıkışması ) ile oluşur. Önce bir host diğerine SYN isteği gönderir. İstek gönderilen host SYN/ACK ile geri döner, son olarakta ilk isteği yapan host ACK göndererek bağlantı kurulmuş olur. Linux connection tracking ile buna biraz daha yakından bakalım.

Kullanıcı tarafındaki stateler’de de gördüğümüz gibi linux connection tracking kullanıcı bakış açısıyla gerçekten TCP bağlantıları bu şekilde takip etmez. Host SYN isteği gönderdiğinde kullanıcı için bu NEW karşı taraf SYN/ACK gönderdiğinde ise ESTABLISHED bağlantı olarak adlandırılır ( işaretlenir )

Bu resim gerçektende TCP connection tracking’in nasıl çalıştığını basit ve hoş bir şekilde anlatıyor. Şimdi ” cat /proc/net/ip_conntrack ” çıktısında görülecek olan çıktılara göz atalım. Host un SYN paketi gönderip henüz cevap almadığı durumda aşağıdaki gibi bir çıktı alırız.

tcp     6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \
dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \
dport=1031 use=1

Gördüğünüz üzere, SYN_SENT flag’i atanmış durumda, henüz bir cevap gelmediği içinde UNREPLIED olarak görünüyor. Şimdi SYN gönderilen Host dan SYN/ACK geldiği duruma göz atalım.

tcp     6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \
dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \
use=1

SYN_RECV , bize SYN paketimizin karşıya doğru olarak ulaştırılıp,SYN/ACK doğru olarak yeniden döndüğünü gösteriyor, yalnız 3 way handshaking hala tamamlanmadığı için ESTABLISHED duruma geçmedi,

tcp     6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \
sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \
sport=23 dport=1031 [ASSURED] use=1

Ve sonunda, ACK paketi döndürülerek, bağlantının gerçekleştiğini ve 3 way handshake’in tamamlandığını ESTABLISHED flag’indan anlıyoruz. Bağlantının gerçekleştiği ASSURED flag i alarak temin edilmiş oluyor.

Peki TCP bağlantımız sonlanırken ne olur ? yine 1 resim kullanımı anlamamız için  en kısa yol olacaktır.

Resimde gayet net olarak görüldüğü gibi normal şartlar altında sadece son ACK paketi gidene kadar bağlantı hala ESTABLISHED kalıyor. Normal şartlar harici bir bağlantının bitirildiği durumlarda mevcuttur. örneğin TCP/RST gönderildiğinde bağlantı anında sonlanacak yani CLOSED durumuna geçecektir. CLOSED’ dan sonra contrack içerisinde bağlantı TIME_WAIT flag’i alır. TIME_WAIT  sisteme pakette olan herhangi bir gecikmeye karşı, işini tamamlaması için bir buffer amacı ile konulmuştur. default olarak genel linux sürümlerinde süresi 2 dakikadır.

TCP RST paketi geldiğinde bağlantı 10 saniye içerisinde kapatılır. bununla ilgili değerlere bakmak ve değiştirebilmek için Sistemimizde bulunan timeout değerlerine bakalım :

contrack timeouts :

ESTABLISHED

bash-3.2# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
432000
bash-3.2#
432000 saniye = 5 gün

SYN_SENT

bash-3.2# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent
120
bash-3.2#

SYN_RECV

bash-3.2# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv
60
bash-3.2#

FIN_WAIT

bash-3.2# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
120
bash-3.2#

TIME_WAIT

bash-3.2# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
120
bash-3.2#

CLOSE

bash-3.2# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
10
bash-3.2#

CLOSE_WAIT

bash-3.2# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
60
bash-3.2#

LAST_ACK

bash-3.2# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack
30
bash-3.2#

yukardaki değerleri /proc içerisinden değiştirmeniz mümkün olduğu gibi sysctl ile de ulaşmak mümkündür ( Kişisel tercihim sysctl kullanılması yönünde  )

sysctl -a | grep tcp_time

conntrack’in tcp flaglarına userland statelerde bakmaması genel bir dez avatajdır. örneğin iptables ile NEW flag’ina izin verdiğinizde ilk gelen bağlantı bir syn paketi olmasa bile NEW olarak algılanacaktır. bununla ilgili iptables kuralları ile durumu kontrol atlına alabileceğiniz gibi, firewall harici bir çözüm daha vardır ;

bash-3.2# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose
1
bash-3.2#

söz konusu değeri proc içerisinden veya sysctl ile 0 değerine aldığınızda, SYN flag’i almamış tüm tcp paketleri kernel tarafından düşürülecektir. tcp_window_tracking extension paketi daha önce patch-o-matic ile beraber eklenmesi gereksede güncel bir çok linux sürümlerinde default gelmektedir.

.

UDP Bağlantılar :

UDP bağlantılar yapıları itibari ile statefull bağlantılar değillerdir. Yinede buna rağmen elde edilen verilere dayanarak linux kerneli bunu gerçekleştirmeye çalışır. Her nekadar basit bir yöntem olsada bir dereceye kadar firewall ların güvenliklerini arttırmakta yeterlidir.

Yukarıda da göreceğiniz gibi yenibir UDP bağlantı yapılmaya çalışıldığında NEW durumuna, karşı taraftan cevap geldiği anlaşıldığında ise basitçe ESTABLISHED durumuna geçer. paket header’larında bununla ilgili bir girdi olmadığı için mantıksal olarak yapılır. UDP paket ilk gönderildiğinde ( istek yapıldığında ) conntrack içerisinde aşağıdaki gibi bir veri elde ederiz.

udp     17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 \
[UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 \
dport=137 use=1
görüldüğü üzere UNREPLIED olarak işaretlenmiş. karşı taraftan ilk cevap geldiğinde ise :

udp     17 170 src=192.168.1.2 dst=192.168.1.5 sport=137 \
dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 \
dport=137 [ASSURED] use=1
Conntrack paketi ASURED olarak işaretliyor. ikisi arasındaki temel farklar, UNREPLIED durumundaki paket için timeout süresi 20 ms, ASURED durumundaki ise 180 ms ( default )’dir. ESTABLISHED yazısı gelmesede UNREPLIED in silinmesi established bağlantı kurulduğuna işaret eder.

UDP paketlerde oturum kapatmak için TCP de bulunan FIN ve RST gibi kavramlar olmadığı için, ESTABLISHED ve UNREPLIED paketler için timeout süreleri atanmıştır ve başka bir parametre içermezler. Bu süreçler zarfında herhangi bir paket iletişimi olmazsa conntrack sonlandırılır.

UDP Time out süreleri için sysctl değişkenleri :

net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180

stream ESTABLISHED için, diğeri ise UNREPLIED içindir. aynı şekilde /proc altındanda veya sysctl ile bu değişkenler tanımlanabilir.

bash-3.2# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
30
bash-3.2# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
180
bash-3.2#

.

ICMP bağlantılar :

ICMP protokolü kontrol amaçlı bir protokol olduğu için asla ESTABLISHED bir bağlantıya ihtiyaç duymaz. Bu yüzden statefull bir paket değildir. Yine UDP’de olduğu gibi netfilter mantık yoluyla ICMP paketlerini track eder.

Resimde de görüldüğü üzere, Server üzerinden ICMP echo isteği ( ping ) istemciye gönderiliyor. Bu durumda conntrack paketi UNREPLIED olarak işaretler. echo reply geri döndüğünde ise bağlantı ESTABLISHED duruma geçer.  şimdi UNREPLIED için girdimize bakalım.

icmp     1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 \
id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 \
type=0 code=0 id=33029 use=1

Değişkenler şimdiye kadar gördüklerimizle aynı sanırım kolaylıkla çözümleyebilirsiniz. Burada fazladan eklenmiş olan iki adet alan mevcut. code ve id code standart ICMP kodlarına tekamül eder. type=8 echo isteğini gösteriyor.

ICMP kodları.

Type Name Reference
—- ————————- ———
0 Echo Reply [RFC792]
1 Unassigned [JBP]
2 Unassigned [JBP]
3 Destination Unreachable [RFC792]
4 Source Quench [RFC792]
5 Redirect [RFC792]
6 Alternate Host Address [JBP]
7 Unassigned [JBP]
8 Echo [RFC792]
9 Router Advertisement [RFC1256]
10 Router Solicitation [RFC1256]
11 Time Exceeded [RFC792]
12 Parameter Problem [RFC792]
13 Timestamp [RFC792]
14 Timestamp Reply [RFC792]
15 Information Request [RFC792]
16 Information Reply [RFC792]
17 Address Mask Request [RFC950]
18 Address Mask Reply [RFC950]
19 Reserved (for Security) [Solo]
20-29 Reserved (for Robustness Experiment) [ZSu]
30 Traceroute [RFC1393]
31 Datagram Conversion Error [RFC1475]
32 Mobile Host Redirect [David Johnson]
33 IPv6 Where-Are-You [Bill Simpson]
34 IPv6 I-Am-Here [Bill Simpson]
35 Mobile Registration Request [Bill Simpson]
36 Mobile Registration Reply [Bill Simpson]
37 Domain Name Request [RFC1788]
38 Domain Name Reply [RFC1788]
39 SKIP [Markson]
40 Photuris [RFC2521]
41 ICMP messages utilized by experimental [RFC4065]
mobility protocols such as Seamoby
42-255 Reserved [JBP]

ICMP kodlarının ayrıntılarına burada daha fazla girmek istemiyorum. Sanırım yukarıdaki tablo yeterli referans olur. ICMP ID alanı ise, tüm ICMP paketlerinin içerisinde, ne zaman gönderildiği,alıcının nezaman aldığı parametrelerine bağlı olarak doldurulur. Bu şekilde alıcının doğru icmp paketine cevap verdiği doğrulanmış olur. a bilgisayarından b bilgisayarına aynı anda 2 adet icmp echo isteği gönderdiğimizde TCP gibi port kavramı olmadığı için ID field olmadan bu paketlerin birbirinden ayrılması imkansız olurdu. Pakete ICMP REPLIED mesajı geldiğinde ise ESTABLISHED duruma geçer.

ICMP nin temel kullanımı oldukça basit olsada diğer bir kullanım yeri daha vardır.TCP veya UDP bağlantı kurmaya çalıştığımızda karşı tarafta herhangi bir şekilde paketin ulaşamaması durumunda HOST veya router paketin akibeti hakkında ICMP cevabı döner örneğin host-unrechable ( host ulaşılamaz ).

Resimden de anlaşılacağı üzere. istemcimiz bir SYN isteği göndererek server üzerinde bir TCP hizmeti almak istiyor. söz konusu network ulaşılamadığı için server ICMP NET Unreach mesajı geri gönderiyor. Söz konusu mesajı alan istemci Abort ederek oturumu sonlandırıyor. bu durumda söz konusu ICMP paketi için conntrack girdisi RELATED olarak işaretlenir.

Benzer bir durum yukardaki resimde görüldüğü üzere UDP içinde geçerlidir. UDP kendisi Statefull bir protokol olmasada Server üzerinde firewall veya farklı bir yönetimsel engel ile karşılaşılıp server ICMP Net Prohibited ( yasaklanmış) mesajı dönebilir. bu durumdada ICMP paketi RELATED olarak işaretlenerek client üzerinde UDP oturumu sonlandırılır.

ICMP için timeout parametresi /proc altında :

bash-3.2# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
30
bash-3.2#

yani 30 saniye sysctl ile ise :

bash-3.2# sysctl -n net.ipv4.netfilter.ip_conntrack_icmp_timeout
30
bash-3.2#

Şeklindedir.

.

Varsayılan bağlantılar :

Bazen bir paketin herhangi bir sınıfa conntrack tarafından sınıflandırılamadığı durumlarda default connections ( var sayılan bağlantılar ) için geçerli ayarlar dikkate alınır. kullanılan protokole ( örneğin ETBLT, MUX and EGP. ) ve link e göre ayarlama gerektiği durumlar olabilir.

proc değeri :

bash-3.2# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
600
bash-3.2#
yeni kernellerde ( 2.6.29 örneğin ) daha eskilerde ise “/proc/sys/net/ipv4/netfilter/ip_ct_generic_timeout” olarak rastlanabilir.

sysctl ile ise :

bash-3.2# sysctl -n net.ipv4.netfilter.ip_conntrack_generic_timeout
600
bash-3.2#

Yani 10 dakika

.

Kompleks bağlantılar :

Bazı bağlantıların takibi oldukça kompleksdir. Örneğin ftp bağlantıları, ftp client’i ilk önce ftp control session olarak bilinen bir bağlantı kurar (TCP Port 21 ), buraya kadar yukarıda gördüğümüz standart TCP bağlantı ile aynıdır. Daha sonra ftp iki türlü yapılıyor olabilir aktif veya pasif ftp. Aktif ftp bağlantısı yapıldığında client bağlandıktan sonra server’a yeni bir port ve ip adresi bildirir. ftp client söz konusu portu açar ve server in bu portdan yeni bir bağlantı kurması için beklemeye başlar. söz konusu açılan port 1024-65535 arasında  rasgele seçilir. FTP client in istemiş olduğu data bu port üzerinden server in sağladığı bağlantı üzerinden gönderilir. Bu durumda firewall’in yeni oluşturulacak bağlantı portları hakkında bilgisi yoktur. Söz konusu bilgiler paket header içerisinde değil payload data ( server e gönderilen bilgi ) içerisinde bulunur. Normal şartlar altında server’in yeni oluşturmak istediği TCP bağlantı firewall tarafından engellenecektir. FTP connection tracking modülü söz konusu port ve ip bilgilerini data içerisinden alarak Server üzerinden gelen paketleri RELATED olarak işaretleyerek bu durumun önüne geçer.

Resimde görüldüğü gibi FTP için server in gönderdiği SYN isteği RELATED olarak işaretlendi. takibinde SYN/ACK oluşması ile ESTABLISHED durumuna geçti.

Pasif FTP bağlantılarda ise tersi bir durum söz konusudur. Client FTP bağlantısını sağlayıp pasive mode’a geçtikten sonra Data aktarımları 20 nolu port ( FTP-DATA port ) üzerinden gerçekleştirilir.Data aktarımları için 20 nolu port üzerinden yapılan bağlantılar yine RELATED olarak işaretlenir.

Linux altında şekilde olduğu gibi bir yapı oluşturabilmek için ftp connection tracking modulü olan ftp conntrack modülünü yüklememiz gerekir.

bash-3.2# modprobe ip_conntrack_ftp
bash-3.2#

Elbette Bu şekilde kompleks bağlantı sadece FTP için geçerli değildir. söz konusu conntrack modullerinden sisteminizde hangilerine sahip olduğuna şu şekilde bakabilirsiniz.

bash-3.2# cat /proc/config.gz | gunzip | grep CONNTRACK
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_PPTP=m
CONFIG_NF_CONNTRACK_SANE=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_NF_CONNTRACK_IPV6=m
bash-3.2#

Kompleks bağlantılar sadece statefull firewalling için değil aynı zamanda NATD arkasında çalışan clientler için de geçerlidir. söz konusu istemcilerin sağlıklı çalışmaları için NETFILTER natd modulleride içerir.

bash-3.2# cat /proc/config.gz | gunzip | grep CONFIG_NF_NAT_
CONFIG_NF_NAT_NEEDED=y
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_DCCP=m
CONFIG_NF_NAT_PROTO_GRE=m
CONFIG_NF_NAT_PROTO_UDPLITE=m
CONFIG_NF_NAT_PROTO_SCTP=m
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_TFTP=m
CONFIG_NF_NAT_AMANDA=m
CONFIG_NF_NAT_PPTP=m
CONFIG_NF_NAT_H323=m
CONFIG_NF_NAT_SIP=m
bash-3.2#

Linux dağıtımınızda ihtiyacç duyduğunuz bir conntrack modülü mevcut değilse patch-o-matic ile kurabilirsiniz.

Optimizasyon :

Yazımızın başındada belirttiğimiz gibi conntrack gerçekten cpu ve ram canavarı haline dönüşebilir. İyi bir firewall planlamasında, Bağlantı izleme ve Statefull firewalling özelliklerine ihtiyaç duymadığımız, yada elimizdeki hardware’in kaldıramayacağı ölçüde yük getiren hizmetleri NOTRACK olarak işaretlemeliyiz. NOTRACK kullanımına daha sonraki yazılarımda ayrıntılı olarak değineceğim.