Alper YALÇINER

iptables belirli bir tablo ( table ) ve zincir ( chain ) yapısıyla gelir. Sistemimize giren bir paketin hangi sıra ve hiyerarşi ile  işlem göreceğine, yada yazmış olduğumuz kuralları amaçlarına göre bu tablolara yerleştirmek efektif bir iptables kural dizisi yazmak için son derece önemlidir. konuyu daha iyi kavramak için öncelikle tablolara ( tables ) göz atalım.

Mangle Table

Mangle’in ingilizce olarak kelime manalarından bir tanesi bozmak olsada tam olarak buradaki kullanımının karşılığını bulamadım.Mangle table iptablesda paketlerin bazı değerlerini değiştirmek için kullanılır, bunlar :

• TOS
• TTL
• MARK
• SECMARK
• CONNSECMARK

1. TOS :

TOS nedir ? sorusunun cevabını, TC ile Fifo yazımda değinmiştim. Mangle table içerisinde gerekli görüldüğünde paketlerin TOS field’larının içerikleri değiştirilebilir. Örneğin başka bir router’i bilgilendirmek, Routing parametrelerini değiştirmek veya iproute2 paketini bilgilendirmek gibi.

Örnek :

bash-3.2# iptables -A PREROUTING -t mangle -p tcp –dport 22 -j TOS –set-tos Minimize-Delay
bash-3.2#

Örnekte ssh için TOS Düşük gecikme için işaretlenmiş oldu.

2. TTL

TTL nedir ? “Time To Live” yaşam süresi Kaynaktan çıkan internet paketleri belirli bir TTL değeri ile oluşturulurlar. Hedefe ulaşana kadar üzerinden geçilen her Router bu değeri bir azaltarak  sonraki noktaya iletir. TTL Sifir’a eşit olduğunda TTL’in 0 olduğu router paketin kaynağına ICMP Unreachable döndürerek bağlantının kapatılmasını sağlar. ve paketi daha ileri noktalara ulaştırmaz. Örneğin network router’ımızın tamamen görünmez olmasını sağlamak istediğimizde TTL değerlerini “–ttl-inc 1″  parametresini kullarak bir düşürdüğümüz TTL değerini geri yükseltebiliriz.

3. MARK

iproute2 paketi ile haberleşmek için kullanılır.

4. SECMARK

SELinux ve benzeri yapıları haberdar etmek için kullanılır. tek bir paketin SElinux için işaretlenmesine yarar.

5. CONNSECMARK

SECMARK ile kullanıcı amacı aynıdır farkı, komple bağlantıların işaretlenmesi için kullanılmasıdır. konumuz SELinux olmadığı için bunların ayrıntılarına girmeyeceğim.

NAT Table :

İsminden kullanım amacı gayet net anlaşılan bir tablo. Network Adress Transilation’için kullanılır. Kullanılabilecekler :

• DNAT
• SNAT
• MASQUERADE
• REDIRECT

1. DNAT

DNAT ” Destination Network Address Transilation” Hedefe dayalı NAT, genellikle local networkde verilen hizmeti internete açmak gibi amaçlarla kullanılır. DNAT’in çalıştığı firewall a gelen istekler isteğin geldiği ip adresi, isteğin yapıldığı protokol port gibi bilgilere dayanarak başka bir ip adresine gönderilir. Kısacası pkaet header’da destination adres değiştirilerek yeniden yazılır.

2. SNAT

SNAT ” Source Network Address Transilation” Kaynak NAT, Paket header’da DNAT in yaptığının tersine Destination adresi değil source adresi değiştirir.

3. MASQUERADE

Masquerade kullanımı SNAT’a benzerlik taşır.

En büyük farkı transilate edilecek olan ip adresini otamatik olarak kontrol etmesidir ki buda bize ppp gibi dinamik ip adresi ile çalışan interface’ler üzerinden nat yapmamızı sağlar. daha basit yaklaşacak olursak evimizde bulunan ADSL bağlantımızı lokal istemcilerimize MASQUERADE sayesinde paylaştırırız.

4. REDIRECT ( paketin yolunu değiştirmek )

Redirect ( yeniden yönlendirme ) tam olarak gelen paketi, iptables olan makinada başka bir porta yönlendirmek için kullanılır. paketin Source ve Destination parametrelerini değiştirmez. örneğin herhangi bir adrese yapılan http ( TCP 80 ) isteğini Kendi üzerinde bulunan veya diğer bir makina üzerinde bulunan squid proxy için 3128 nolu porta göndererek transparent proxy yapılandırmak gibi.

RAW Table :

RAW ( işlenmemiş ham ) table, temel olarak tek bir amaç için kullanılır. NOTRACK opsiyonu ile beraber connection tracking ( ip_conntrack ) tarafından bir paketin dokunulmaması, takip edilmemesi. Daha önceden’de gördüğümüz üzere linux connection tracking ile gerçekten sistem kaynaklarını tüketebiliyor. gerek duymadığımız veya sisteme büyük yük getiren paketleri sınıflandırarak bu işlemin dışarısında tutabilmemiz için oluşturulmuştur.2.6 kernelin ilk sürümlerinde ve daha önceki kernel sürümlerinde mevcut değildir.

FILTER Table :

Filter ( filitre ) tablosu paketler üzerinde Drop,Accept gibi filtre şlemlerini uygulayabileceğimiz ve işaretleme için filitre uygulayabileceğimiz bir tablodur.

Şimdi Chains konusuna yeniden göz atalım. Chains yani zincirler iptables kuralları arasında grupları temsil eder, örneğin default olarak iptables ile beraber gelen 3 tane chain ( grup ) vardır. INPUT bilgisayara gelen ler için tanımladığımız kuralları , FORWARD bilgisayarımız üzerinden başka bir kaynağa yönlendiren kuralları. OUTPUT ise bilgisayarımızdan çıkıp başka yerlere giden bağlantılar için koyduğumuz kuralları temsil eder. Demiştik. Peki Netfilter üzerinde bir paketin yolculuğu nasıl oluyor ve kurallarımızı neye göre yazmalıyız. öncelikle paketlerin iptables üzerinde akış diyagramına bakalım.

Şeklimizi biraz açıklayalım. RAW,MANGLE,NAT,FILTER tablolarının ne işe yaradıklarına değinmiştik. interface’imize gelen bir paket öncelikle PREROUTING chain e gelir. paketin destination adresi değiştirilecekse burada yapılır. örneğin NAT. daha sonra Routing kararı paket hedefi local host ise input, başka bir hedef ise FORWARD chain’e gönderilir.  bundan sonrasını daha iyi anlamak için değişik senaryolar üzerine gidelim.

örnek1 : paket hedefi local host ( linux router in kendisi )

İnterface’imiz üzerine gelen paket ( mesela ethernet ) her ne durumda olursa olsun PREROUTING zinciri üzerinden geçmek zorunda kalıyor. daha sonra ROUTING kararı hedefin local process yani linux üzerinde bulunan bir ip adresi olduğu yönünde olduğu için INPUT zincir ine yönlendirilerek işleniyor. örneğin linux üzerinde çalışan apache web server’e gelen istekler iptables üzerinde bu yolu izler. Yapılan işlemleri biraz daha yakından inceleyecek olursak :

1. RAW PREROUTING : connection tracking module’ün bu paketi izleyip izlemiyeceğine karar verebileceğimiz yer.
2. MANGLE PREROUTING : gelen paketin işlenmesi için gerekli değerlerin değiştirilmesi ( TOS vb )
3. NAT PREROUTING : şayet paket NAT gibi bir işleme tabi tutulacaksa işlenmesi.
   
4. ROUTING Kararı : paket in local işlem için INPUT zincir ine yönlendirilmesi.
5. MANGLE INPUT : Mangle işleminin sadece local paketler için gerçekleştirilmesi
6. FILTER INPUT : Drop deny Accept gibi kuralları local e gelen paketler için uyguladığımız yer. burada gelen interface ve hangi yönden geldiğinin önemi yoktur.
7. LOCAL İŞLEM : server veya client proğramı örneğin apache web server e ulaştırılması ve işlenmesi.

örnek2 : kaynak biz hedef başka adres :

Local bir process tarafından üretilen paketin ( istemci veya server ) iptables üzerinde işlenme sırası.

1. LOKAL İŞLEM : Server veya Client paketi üretiyor.
2. ROUTING kararı : Hangi source adresin kullanılacağı, hangi çıkış interface’inin kullanılacağı, gibi bilgilerin işlendiği yer
3. RAW OUTPUT : ürettiğimiz paketin connection tracking tarafından işlenmemesi gerektiğini belirttiğimiz yer.
4. MANGLE OUTPUT : paketler de Mangle işlemini yaptığımız yer. bazı yan etkileri olduğu için burada kullanılması tavsiye edilmiyor.
5. NAT OUTPUT : Lokal proğram tarafından üretilen paketin NAT yapıldığı yer.
   
6. FILTER OUTPUT : Drop Deny Accept gibi işlemler.
7. ROUTING kararı : burası local üretilen paketler için işlevsizdir ( yok kabul edilir )
8. MANGLE POSTROUTING :  Firewall imizi paket terketmeden önce Mangle yaptığımız yer.
9. NAT POSTROUTING : SNAT ” Source Network Address Transilation”‘in gerçekleştiği yer. dikkat eilecek konu : burada filter yapılmaması, bazı paketler default drop olduğu halde buradan geçebiliyor.
10. Çıkış interface’i örneğin ethernet

örnek3 : FORWARDED paketler. ( kaynak ve hedef firewall in kendisi değil )

1. RAW PREROUTING : connection tracking module’ün bu paketi izleyip izlemiyeceğine karar verebileceğimiz yer.
2. MANGLE PREROUTING : gelen paketin şlenmesi için gerekli değerlerin değiştirilmesi ( TOS vb )
3. NAT PREROUTING : DNAT işleminin uygulandığı yer.
   
4. ROUTING Kararı : paket in forward edilmesi için FORWARD zincirine yönlendirilmesi.
5. MANGLE FORWARD : Son routing kararı verilmeden önce yapılması istenen mangle işlemleri için.
6. FILTER FORWARD : forwarded paketler için filter kurallarımızı uyguladığımız yer. dikkat edilmesi gereken nokta tek bir yöne giden paketlerin değil tüm forward edilmiş paketlerin buradan geçtiği. kuralları yazarken dikkat edilip göz önüne alınması gerekiyor.
   
7. MAGLE POSTROUTING : Firewall imizi paket terketmeden önce Mangle yaptığımız yer.
8. NAT POSTROUTING : SNAT ” Source Network Address Transilation”‘in gerçekleştiği yer. dikkat edilecek konu : burada filter yapılmaması, bazı paketler default drop olduğu halde buradan geçebiliyor. MASQUAREDE’de burada gerçekleştirilir.
9. Çıkış interface’i örneğin ethernet.

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.

iptables genel kullanımı :

iptables [-t table] command [match] [target/jump]

iptables komutunun en temel kullanımı yukarda görüldüğü şekildedir.

-t table :

“-t table” kullanılarak default table harici başka bir table’a eklemek için kullanılır. kullanılması zaruri bir parametre değildir. table belirtilmediği müddetçe rule default table a eklenir. “-t table” kural içerisinde hernangi bir yere konulabilir, kural başlangıcına konulmak zorunda değildir.

command :

command ( komut ) herzaman en başa  gelmelidir. sadece “-t table” kullanıldığında table parametresinden sonra kullanılabilir. command iptables ‘a ne yapacağını söyledeğimiz yerdir örneğin : kural ekle, kural sil gibi.

match :

kernel’e kural için geçerli olan ip paketinin karakteristiği hakkında bilgi vermek için kullanılır örneğin : şu ip adresinden gelen, şu protokol, şu port vb gibi.

target :

paketler için gerekli şartlar sağlandığında match gibi kurallar tuttuğunda kernel’e söz konusu paket ile ne yapacağını söylemek amacı ile kullanılır. örneğin : paketi başka bir hain e yönlendir, paketi göz ardı et, başka bir kaynağa yönlendir gibi.

Commands ( Komutlar ) :

Şimdi iptables ile kullanabileceğimiz komutlara bir göz atalım ;

-A –append

iptables -A INPUT

Bu komut belirtilen zincir’in en sonuna belirtilen kuralı ekler. Başka bir deyişle daha sonra bir kural daha eklenmediği müddetçe bu kural zincir içerisinde en son paketin kontrol edileceği yer olur.

-D –delete

iptables -D INPUT –dport 80 -j DROP, iptables -D INPUT 1

Bir zincirdeki belirtilen kuralı siler. İki türlü kullanımı vardır , Silmek istediğiniz kuralı aynen belirterek silebilirsiniz veya kurallar eklenirken tüm kurallara 1 den başlayarak bir numara verilir söz konusu rule numarası belirtilerek’de silinebilir.

-R –replace

iptables -R INPUT 1 -s 192.168.0.1 -j DROP

Yer değiştirmek. daha önceden girilmiş olan bir kuralı silmek yerine yenisi ile değiştirmek amacı ile kullanılır. kullanımı -D ile aynı olup farkı silmek yerine yeni eklediğiniz kural ile yerdeğiştirmesidir. yukarıdaki örnekde INPUT içerisindeki 1 nolu kuralı yer değiştiriyor.

-I –insert

iptables -I INPUT 1 –dport 80 -j ACCEPT

Belirtilen zincirde belirtilen kural sıralamasında araya bir kural eklemek için kullanılır. örneğin yeni bir kural eklemek istiyoruz. daha önceden eklediğimiz bir yada bir kaç kural söz konusu paket için farklı işlemleri daha önceden gerçekleştirdiği için bu kural kullanılmaz duruma düşüyorsa söz konusu kurallardan önce bu kuralı araya girmemiz gerekebilir. daha basit anlatımıyla 192.168.1.1 den gelen tüm paketleri drop eden bir kuralımız varsa sonradan ekleyeceğimiz bu ip adresinden gelen http isteklerine izin veren kural tamamen işlevsiz olacaktır. söz konusu drop kuralından öncesine rule numarası girerek “insert” ederiz.

-L –list

iptables -L INPUT

Belirtilen tablo veya zincirdeki kuralları listeler.  örneğimizde INPUT zinciri içerisindeki tüm kuralları listeliyoruz. Çıktı sonuçları opsiyonlara göre değişebilir -n -v gibi opsiyonlar kullanılabilir. ( opsiyonlara az sonra değineceğim )

-F –flush

iptables -F INPUT

Bir zincir’in içerisindeki tüm kuralları silmek için kullanılır. Söz konusu zincir içerisindeki kuralların hepsini silmek istediğimizde tek tek -D komutu kullanmaktan hızlı olduğu için eklenmiştir. zincir belirtilmediği takdirde belirli tabloların içerisindeki tüm kuralları siler.örneğimizde INPUT zinciri içerisindeki tüm kuralları siliyor.

-Z –zero

iptables -Z INPUT

iptables kuralları sayaçlara sahiptir. Bu sayaçlar söz konusu kural ile eşleşmiş olan paketler hakkında bilgileri içerir. herhangi bir amaç için bu sayaç bilgilerini resetlemek istediğinizde -Z kullanılır. -Z sayaçların değerlerini göstermeden sildiği için genelde -L ile beraber kullanılır. Belirli bir kuralın veya komple bir zincirin içerisindeki kuralların sayaçlarını sıfırlamak için kullanılabilir.

-N –new-chain

iptables -N izinliler

Yeni bir chain eklemek için kullanılır ( bir önceki yazımda görmüştük )

-X –delete-chain

iptables -X izinliler

Belirtilen zinciri silmek için kullanılır.  Bu komutun kullanılması için , söz konusu zincir içerisinde herhangi bir kuralın bulunmaması gerekmektedir. Herhangi bir zincir adı belirtilmediğinde belirli tablo içerisindeki tüm zincirleri siler. -X şeklinde değişik bir parametrenin kullanılma sebebini coder daha iyi tüm harflerin daha önceden başka amaçlar için kullanılması olarak belirtmiş. rneğimizde izinliler zinciri siliniyor.

-P –policy

iptables -P INPUT DROP

Daha önceki yazımda policy nedemek görmüştük. -P parametresi ile belirtilen zincir ierisinde paket herhangi bir kurala uymazsa pakete nasıl davranılacağını belirtmek için kullanılır. Buradaki örnekte INPUT zincirinde herhangi bir kural tarafından işlenmeyen paketin default olarak drop edileceği belirtiliyor.

-E –rename-chain

iptables -E izinliler izinsizler

Belirtilen zincir isminin yeni bir isimle değiştirilmesi için kullanılır. izinliler zincirinin izinsizler olarak yeniden adlandırılması gibi.

Opsiyonlar :

opsiyon : -v –verbose

Beraber kullanılabileceği komutlar : –list, –append, –insert, –delete, –replace

İlgili komutlarla beraber daha ayrıntılı çıktı almak için kullanılır. örneğin –list ile birlikte kullanıldığında, kuralin ilgili olduğu interface adresini , rule opsiyonlarını, TOS marklari da gösterir. aynı zamanda byte ve paket sayaçlarını da gösterir. sayaçlar -K X1000 -M X1000000 -G X1000000000 gibi değerlerle görünebilir. bunu engellemek için -x opsiyonu ile beraber kullanarak tam sonuçlar alınabilir.

opsiyon : -x –exact

Beraber kullanılabileceği komutlar : –list

verbose çıktının kısaltmalar halinde değil tam değerini görmek için kullanılır.

opsiyon : -n –numeric

Beraber kullanılabileceği komutlar :–list

list ile beraber kullanılır sadece, söz konusu görüntülenen kuraldaki değerlerin numara olarak görüntülenmesi amacı ile kullanılır örneğin hostname yerine ip adresi www yerine tcp 80 şeklinde görünmesi gibi. söz konusu değerler şayet numeric değerlere değiştirilebiliyorsa numeric olarak gösterilir. örneğin çözümlenemeyen dns adresleri isim olarak görünmeye devam edecektir.

opsiyon : –line-numbers

Beraber kullanılabileceği komutlar : –list

Sadece –list ile beraber kullanılan bu opsiyon kuraları listelerken başlarına Satır numaraları verir. Söz konusu satır numaraları kural numarasına eşittir. insert komutu ile yeni bir kural ekleneceği zaman kuralın hangi numara ile ekleneceğini belirlemek gibi amaçlarla kullanılır.

opsiyon : -c –set-counters

Beraber kullanılabileceği komutlar : –insert, –append, –replace

Yeni bir kural oluştururken yada yapılandırırken kuralın sayaçlarını modifiye etmek için kullanılır. örneğin : –set-counters 20 4000 şeklinde kullanarak paket counter’i 20 ye ve byte counter’ını 4000′e ayarlayabiliriz.

opsiyon : –modprobe

Beraber kullanılabileceği komutlar : Hepsi

iptables kuralı herhangi bir modüle gerek duyarsa yüklemek amacıyla kullanılır.  Tüm komutlarla beraber kullanılabilir.

iptables ile kullanılan komut ve opsiyonları kısaca görmüş olduk.

iptables terimleri :

iptables ile ilgili yazılı dökümanları daha iyi anlamak için ipfilter’ile kullanılan terimlere  daha yakından bakmamız yerinde olur.

Drop/Deny :

Bir paket için Drop veya Deny terimi kullanıldığında söz konusu paket basitçe yok olur. istemciye herhangi bir cevap gönderilmez. paket firewall da sonlanmış olur.

Reject :

Reject Deny/Drop ile aynı şekilde davranır, farkı istemciye paketin göz ardı edildiği veya düşürüldüğüne dair  bir cevap döner. Nomal şartlarda paketin neden geri çevirildiğine dair bilgi ekleyebilsekte. iptables default olarak bunu desteklemez. otamatik olarak üretilen cevap geri gönderilir.

Not : Drop kullanımı geriye bir paket göndermediği için çok daha avantajlı gibi görünsede özellikle host’un DDOS için koruması olmadığı durumlarda bir çok zarar meydana getirebilir. örneğin router arkasında paketleri droplamak routing table’in overload olarak cevap veremez hale düşmesine kısacası aldığımız tedbirin kendimize zarar vermesine sebebiyet verebilir. Alınan her tedbirin yeni bir potansiyel tehdit sahası oluşturduğunu göz ardı etmeyiniz.Drop kesinlikle bir çare olsaydı ipfilter ekibi reject gibi bir terim eklemeye gerek duymazlardı !

State :

Statefull firewall’ing için kullanılır. bir önceki yazımda statfull firewall’ları görmüştük. state ilgili bağlantıların kayıtlarını tutar..

Chain :

Chain ingilizcem manasında olduğu gibi tamamen zincir mantığı ile çalışır. bir zincir içerisindeki kurallar sırasıyla ilgili paket üzerinde uygulanır. Zincirler iyi bir firewall yapılandırmasında belirli amaçlar için düzenlenirler. örneğin : Belirli bir host veya ip grubu hakkında kurallar düzenlemek veya belirli bir uygulama hakkında kurallar düzenlemek için. Zincirlerin çalışma şeklini sanırım aşağıdaki resimden daha net anlayabilirsiniz.

Table :

Tablolar belirli amaçlara göre üretilmiştir. Netfilter 4 adet default table içerir raw, nat mangle ve filter.  bu tabloların ayrıntılarına daha sonra değineceğim. bir tablo içerisinde bir yada daha fazla chain içerebilir.

Match :

Paket header’ina bakılarak söz konusu paketin belirli şartlara uyup uymadığını anlamak için kullanılır. örneğin filter içerisinde -source match kullanılarak paketin belirli bir ip den gelip gelmediğine bakılabilir.

Target :

Bir iptables kuralında söz konusu paket için belirli Match şartları uyuyorsa ( belirli bir ip den gelen gibi ) o paket ile ne yapacağımızı belirtebilmemiz için kullanılır. örneğin başka bir chain e yönlendirmek veya nat yapmak gibi.

Rule :

Rule yani kural, bir Match veya target için eklediğiniz her bir kurala denilsede iptables tek bir kural içerisinde bir çok match ve target tanımlamayı mümkün kılar. kısaca iptables içerisinde tanımladığımız her bir kural demek daha uygun olur sanırım.

Ruleset :

Bir table’in içerdiği tüm kuralların oluşturduğu gruba denir.

Jump :

Jump (sıçramak) mana olarak ve yaptığı iş olarak target ile aynısını yapsada sadece chain ler için geçerlidir. yukardaki resimdeki gibi bir yapı oluşturmak istediğimizde farklı bir chain’i göstermek için jump kullanılabilir. jump başka bir hedef ip göstermk için kullanılamaz.

Accept :

Paketi kabul etmek için kullanılır. kısaca Drop/Deny yada reject etmeyip bir paketin kabulü için kullanılır.

Policy :

Politika kural. Firewall larda default policiy şayet bir paket hiç bir kurala uymuyorsa ne yapacağını belirtmek için kullanılır. örneğin Default policy drop olan bir firewall da hiç bir kurala match olmayan bir paket göz ardı edilecektir.

Connection tracking :

Baplantı izleme, statefull firewall larda kullanılır. iptables ile beraber kullanıldığında çok daha fazla cpu ve ram kullanacağını göz ardı etmemek gerekir. yaklaşık olarak şu şekilde bilgi içerir.

tcp      6 299 ESTABLISHED src=10.70.20.3 dst=86.65.39.15 sport=43426 dport=6667 packets=8 bytes=566 src=86.65.39.15 dst=10.70.20.3 sport=6667 dport=43426 packets=5 bytes=2834 [ASSURED] mark=0 secmark=0 use=1

Connection tracking’in ram ve cpu maliyetlerini göz ardı etmeyiniz. 128 mb ram ayırarak 8192 adet aktif ipv4 bağlantı izleyebileceğinizi belirtmek sanırım iyi bir referans olur.

De-Militarized Zone (DMZ) nedir ?

DMZ’ler genellikle internetten ( yada farklı network kaynaklarından ) ulaşılan server’lerimizi korumak ve aynı zamanda local networklerimizde oluşabilecek virus veya spam gibi tehditlerden söz konusu server’leri korumak için oluşturulan networklerdir. internetten bulduğum aşağıdaki resim sanırım sözden daha güzel açıklıyor.

Firewall Nedir ?

Firewall ( Ateş duvarı ), Internet ve local ağ trafiğinin , kontrol ve denetlemesini yapan yazılımlardır ( hardware firewall’lar olsada içlerinde bir yazılım olmak zorunda olduğunu unutmayın ) . Firewall sayesinde Internet ve local ağ üzerinden belirli portlar, yada belirli ip adresi veya ip gruplarının erişimini engelleyebiliriz. Sanırım iptables ile ilgili bir yazı okumaya karar veren kişi firewall nedemek konusunda hali hazırda fikir sahibidir o yüzden fazla uzatmayacağım

Packet filtering firewall :

Bildiğimiz en basit haliyle firewall’dir, istek yapan kişinin ip adresine, port adresine veya gidecek olduğu hedefin port ip adresine yada komple bir ip blok’u için kurallar tanımlamamızı sağlarlar.

örneğin :

1.1.1.1 ip adresinden 80 nolu TCP portu üzerinden erişimi engellemek bu tür bir firewall uygulamasıdır. en yeteneksiz ve basit firewall’dir. bunun yanında en az cpu ve ram ihtiyacı duyan firewall yapısıdırda. diğer firewall yapılarıyla birlikte kulanıldığında kesin olarak bildiğimiz erişimleri bu şekilde denetleyerek engellemek firewall üzerinde cpu ve ram avantajı yaratacaktır. ( etkin bir saldırı veya yanlış yapılandırmada en güçlü firewall cihaz yada yazılımlarının yetersiz kalacağını göz ardı etmeyiniz )

Aplication level firewall : Uygulama Seviyesi firewall

Bu firewall lar Sadece port veya ip yani temel ağ bilgilerine bakmazlar. http://alper.web.tr adresine ulaşmak istediğinizde hedef http://alper.web.tr port 80 ulaşım serbest demek yerine, web sayfasını ziyaret etmek için browserinizin koyduğu içeriği analiz ederek http bilgisisnin olup olmadığınıda kontrol eder.

Statefull firewall :

Statefull firewall yukarıdaki Packet filtering firewall ile aynı mantıkla çalışır, farkı örneğin TCP bağlantıdaki 3 way handshaking dediğimiz olayı kontrol edebilirsiniz. 3 way handshaking de  a makinasından b makinası syn paketi daha sonra b den a‘ ya syn/ack ve yeninden b ye ack paketi gelerek bağlantı kurulmuş olur. Statefull firewall in çalışma şekli genel olarak , istenilen şartlar ( 3way handshaking gibi ) yerine getirildiğinde sadece o bağlantıya özel bir kural eklenerek iletişim sağlanır. herhangi bir saldırı anında saldırganın devamlı olarak syn paketi göndererek sisteminize zarar vermesi bu şekilde önlenmiş olur. Söz konusu eklenen kurallar ram’de yer işgal etsede Aplication lvl firewall lar kadar sistem kaynağı tüketmezler.

Firewall’lar tüm bu özelliklerinin yanında hala bir ip paketinin gerçekten kötü amaçlı olup olmadığını analiz edemezler. Bunları sağlamak için IPS/IDS denilen yazılımlar kullanılırki şu an için bunlara çok fazla giremeyeceğim. günümüzde UTM denilen , ( Unified Threat Management ) firewall,antivirüs, antispam, ids/ips, vpn,router,gibi özellikleri içerisinde barındıran   yazılımsal ve donanımsal firewallar  çıkmıştır. ilk çıktıkları tarihlerde çok başarılı olamasalarda günümüzde oldukça etkin şekilde kullanılıyorlar. Statefull firewall Checkpoint firması tarafından bulunmuş ve standart halini almıştır.

Netfilter nedir ?

Linux kernelinde ( 2.3 ve sonrasında ) , Standart firewalling işlemlerini  ( filtering nat mangle ) yapan kısımdır.

iptables nedir ?

Linux Netfilter için kullanıcı arayüzüdür en basit anlatımıyla.

iptables gerçektende bize standart firewall ihtiyaçlarını fazlasıyla sağlamaktadır.  iptables yukarda saydığımız tüm özellikleri Extensions ( genişleme paketleri )sayesinde sağlayabilir. Linux sistem içerisinde bulunan diğer proğramlarla etkileşimli olarak çalışması için yapılandırılabilir. özellikle iptroute2 paketi ile beraber kullanıldığında routing ve QOS özellikleriyle birlikte paralı bir çok firewall ürününün özelliklerinden fazlasını sağlar.Snort gibi yazılımlarla beraber kullanarak IPS ve IDS gibi özellikleri elde etmeyi mümkün kılar. Günümüzde hemen hemen tüm linux sürümlerinde iptables ve iproute2 paketleri hazır gelmektedir. ( en azından paket yöneticinizle ekleyebilirsiniz ), Bu ilk yazımda iptables oldukça geniş bir konu olduğu için sadece temel bir kaç şeye değineceğim.

iptables ile kuralları görüntülemek :

bash-3.2# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
bash-3.2#

açıklaması :

iptables -L komutu ile daha önceden girilmiş iptables kurallarını görüntüleyebilirsiniz. eğer natd kuralları tanımlı ise görmek için iptables -t nat -L kullanılır.

Chains nedir ?

Chains yani zincirler iptables kuralları arasında grupları temsil eder, örneğin default olarak iptables ile beraber gelen 3 tane chain ( grup ) vardır. INPUT bilgisayara gelen ler için tanımladığımız kuralları , FORWARD bilgisayarımız üzerinden başka bir kaynağa yönlendiren kuralları. OUTPUT ise bilgisayarımızdan çıkıp başka yerlere giden bağlantılar için koyduğumuz kuralları temsil eder. ( nat ve raw a daha sonra değineceğim )

Yeni bir Chain nasıl oluşturulur?

kendi firewall kurallarımızın içerisinde olduğu yeni bir chain ( grup) nasıl oluştururuz ?

bash-3.2# iptables -N yenibirchain
bash-3.2# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain yenibirchain (0 references)
target     prot opt source               destination
bash-3.2#

‘iptables -N ‘ diyerek yeni bir chain oluşturabilriz oluşturduğumuz chainleri silmek istediğimizde -X yada –delete kullanabiliriz.

Not : Aynı isimde ikinci bir chain oluşturulamaz !

Oluşturmuş oldğumuz bir chain’i silmek :

bash-3.2# iptables -X yenibirchain
bash-3.2# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
bash-3.2#

Chain’lerin oluşturulması sanırım anlaşıldı, ( iptables kullanmış olduk )  bu gruplar ilerde düzenleyecek olduğunuz kompleks firewall yapılarında yönetimi önemli ölçüde kolaylaştırmaktadır. söz konusu örneklerde bu daha iyi anlaşılacaktır. Burada iptables kullanımını bir yazı ile anlatıp geçmeyi düşünüyordum ama internet okadar çok iptables dökümanı ile doluki ne gönlüm razı oluyor nede bir tane daha yazmaya gerek var. Diğer yazılarımı sabırlı olarak okuyacaklara iptables’i etkili şekilde kullanmaları için yardımcı olabileceğimi sanıyorum. iptables hakkında çok geniş bilgiye ihtiyaç duymayıp basitçe kullanmak isteyen arkadaşlara Enver Altın ( Skyblue ) tarafından yazılmış dökümanı tavsiye ederim.

Hierarchical Token Bucket

HTB, CBQ gibi bize link sharing yani bant genişliği yönetimi yapmamızı sağlayan bir queuing disiplinidir. kısaca 2 mbit interetimizi servislerimiz veya istemcilerimiz arasında bant genişliği olarak paylaştırmamızı sağlar.

örneğin :

yada şu şekilde bir yapılandırmayı :

Sanırım resimler HTB ile yapabileceklerimizi gayet güzel açıklıyor. CBQ ile HTB temel olarak aynı görevi yapsada Linux üzerinde HTB kullanımı çokndaha istikrarlı, sorunsuz ve yapılandırması kolaydır.

Hemen basit bir örnek yapalım : 10.70.20.0/24 networküne giden bağlantılara 1024kbit HTB ile bant genşiliği tanımlayalım.

bash-3.2# tc qdisc add dev wlan0 root handle 1:0 htb
bash-3.2# tc class add dev wlan0 parent 1:0 classid 1:1 htb rate 1024Kbit

bash-3.2# tc filter add dev wlan0 parent 1:0 protocol ip prio 1 u32 match ip src 10.70.20.0/24 flowid 1:1

neler yaptık : htb için root qdisc oluşturduk, ikinci satırda 1024kbit bir class oluşturup üçüncü satırda kaynağı 10.70.20.0/24 olan paketleri filter tanımlayarak bu class’a atadık. oldukça basit kullanımı.

şimdi koyduğumuz kurala bakalım :

bash-3.2# tc -s -d qdisc show dev wlan0
qdisc htb 1: root r2q 10 default 0 direct_packets_stat 296 ver 3.17
Sent 47788511 bytes 36235 pkt (dropped 0, overlimits 61757 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
bash-3.2# tc -s -d class show dev wlan0
class htb 1:1 root prio 0 quantum 12800 rate 1024Kbit ceil 1024Kbit burst 1599b/8 mpu 0b overhead 0b cburst 1599b/8 mpu 0b overhead 0b level 0
Sent 47730662 bytes 35950 pkt (dropped 0, overlimits 0 requeues 0)
rate 2072bit 1pps backlog 0b 0p requeues 0
lended: 35950 borrowed: 0 giants: 0
tokens: 11781 ctokens: 11781

bash-3.2# tc -d -s filter show dev wlan0
filter parent 1: protocol ip pref 1 u32
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1
match 0a461400/ffffff00 at 12
bash-3.2#

Gayet güzel şimdi biraz daha ayrıntıya girelim.

daha farklı bir yapımız olduğunu düşünelim, yukardaki örnekte, 10.70.20.0 network’üne komple 1 mbit bant genişliği tanımladık, peki farklı ipler için farklı bant genişlikleri tanımlasaydık ne olurdu ? 1 den fazla class oluşturup, tc filter ile ip adreslerine göre gelen paketleri sınıflandırıp bu classlara tanımlardık. hatta TOS, DS field, tcp port ptokol gibi istediğimiz tüm verilere göre. buradaki ana problem şudur. hiç kimse kullanıcılarını yada hizmetleri, belirli bir bant genişliğine sınırlayıp diğer hizmetlerin kullanmadığı bant genişliğini atıl durumda bırakmak istemez. bunun için HTB gibi protokollerde borrow ( ödünç alma ) mantığı geliştirilmiştir. temel olarak borrow, bir class in diğer class ların kullanmadığı bant genişliğini ödünç almasıdır.

HTB de borrow ( ödünç alma ) ceil parametresi ile belirtilir. bir class in ödünç alabileceği maksimum değer bir üst class in ulaşabileceği maksimum değerdir. örneğin : rate 1024Kbit ceil 2048Kbit şeklinde belirttiğimizde söz konusu class 1024Kbit garanti edilen hıza VE diğer class lar kullanmadığı takdirde 2048Kbit e kadar ödünç alarak çıkabileceK hızı belirtir.

Burst : anlık paket gönderimi daha önceki TBF yazımda da göreceğiniz üzere. Linux kernelinde belirtilen CONFIG_HZ olarak belirtilen bir zamanlayıcı vardır. ethernet interface i üzerinden bu değere bağlı oalrak her seferinde bir paket olmak üzere 1 sn de bu değerin gösterdiği kadar ayrı hızlarda giden paketlerin toplamı bize 1 saniye deki hızımızı örneğin 1024Kbits/sec verir. burst ve min burst her bir parçanın alabileceği maksimum ve minumum büyüklüğü tanımlayarak, 1 saniye içerisinde bir paketin diğerlerininkinden çok daha fazla oaarak onların gerçek değerlerinin dışına çıkmasını engeller. örneğin :

bash-3.2# cat /proc/config.gz | gunzip - | grep ^CONFIG_HZ= | sed s/CONFIG_HZ=//g
300
bash-3.2#

Sistemimde bu değer 300 hz olarak elde ettim, elde etmek istediğim değer, 1024KBits olduğuna göre 1024/300=3.413 1 sn içerisinde bazı HZ lerde gereken den yavaş aktarım olabileceğini ve paketlerdeki kayıplarıda göz önüne alarak yaklaşık 5Kbit burst değeri verecek olursak her bir Hz e denk gelen paket hızını optimize etmiş oluruz.

Priority : HTB priority fifo gibi diğer qdisc lerden farklı çalışır. HTB üzerinde belirtilen priority, ceil ile belirtmiş olduğumuz borrow ( ödünç alma ) işleminin gerçekleştiği durumda, hangi paketin bu ödünç almayı ilk yapacağını önceliklendirme için kullanılır.

Burst gibi kavramlarla HTB de uğraşmanın pratikte gerçek bir faydası olmuyor, hatta zaman zaman zararı olduğu dahi gözlemlenebiliyor. HTB manual inda da belirtidiği üzere özellikle paket gecikmelerinin çok önemli olduğu yapılarda HTB rate limitinin interface hızında bir miktar az tanımlanması önemli ölçüde verimliliği arttıracaktır örneğin : 1024 Kbits bantgenişliği olan bir interface için 900 Kbit gibi bir değer vermek son derece güzel bir çözümdür.

örneğin :

bash-3.2# tc class add dev wlan0 parent 1:0 classid 1:1 htb rate 900Kbit
bash-3.2# tc class add dev wlan0 parent 1:1 classid 1:10 htb rate 400Kbit ceil 900Kbit prio 1

ref : htb manual

Bir önceki yazımda RED ve kullanımını anlatmıştım. RED kullanımında birden çok servis veya bilgisayar için ayrı kurallar tanımlamak istediğimizi düşünelim. RED bu konuda yeterli değildir. Bu noktada devreye GRED giriyor. GRED temel olarak RED qdisc le aynı olmakla beraber bize hizmetler ve istemciler için ayrı sınıflar oluşturmamızı ve priority ( öncelik) tanımlamamızı sağlar. GRED de RED gibi özellikle backbone yapılarında faydalıdır. GRED yetenek olarak cisco sistemlerde WRED ve Distributed WRED’e karşılık gelir.

Yukardaki çizimde görülene benzer bir yapımız olduğunu, hatta Cisco üzerinden VOIP hizmetimizinde internetten geldiğini düşünelim. elbetteki voip,SQL,MAIL hepsinin red tarafından droplanma ihtimalinin aynı olmasını istemeyiz. hemen bunun için yapılmış olan örnek planlama tablosuna göz atalım.

tabloda görüleceği üzerine hizmetlerin önemine ve çalışma şekline göre farklı gecikme ve umulan bant genişliği ayırılmış . GRED de RED gibi bant genişliği kontrolü yapmaz. bu ayarlar kuyruk oluştuğunda hangi paketin düşürüleceği ile ilgilidir. Kısacası GRED ile fifo dan daha iyi bir önceliklendirme yapılandırmak istiyoruz. VOIP ve DNS de dikkat ederseniz düşürülme ihtimali N/a verilmiş. bunun sebebi bu hizmetlerin TCP değil UDP üzerinden verilmesi.

GRED in diğer önemli farkı ise oluşturduğumuz sanal qdisc ler içerisinde priority belirleyerek hiyerarşik bir yapı oluşturabilmemiz. sanırım fazla karışıklık yaratmadan örneklere geçmek iyi olacak.

evet resimdeki komutu açıklayalım. tc qdisc ekle dev eth0 üzerinde çalışsın. gred algoritması kullansın. 8 sanal qdisc oluştursun ve grio olsun, grio bize az sonraki örneklerde kullanılan priority leri tanımlamamızı sağlar. şimdi hesaplanmış olan tabloya göz atalım :

Bu değerler nasıl hesaplanıyor ?

.                                          0.01 * Bandwidth Share * Desired Latency * Network Bandwidth
Maximum Threshold = —————————————————————————————————————
.                                                                  8 bits/byte* 1000 ms/sec
Minimum Threshold = 1/2 * Maximum Threshold
Avpkt = Average Packet Length
Burst = ( 2 * MinThreshold + MaxThreshold) / ( 3 * Avpkt )
Limit = 4 * MaxThreshold

Network Bandwidth (10Mbps) = 10 * 1024 * 1024 bits/sec = 10.485.760 bits/sec

SQL için örnek hesaplama :

.                                     0.01 * 25 * 100 * 10.485.760
Maximum Threshold = ———————————————— = 32768 bytes
.                                                 8 * 1000
Minimum Threshold = 1/2 * 32768 = 16384
Avpkt = 1024
Burst = ( 2 * 32768 + 16384 ) / ( 3 * 1024 ) = 27
Limit = 4 * 32768 = 131072

dikkat edilecek nokta UDP hizmetlerde MAX ve MIn değerleri arasında fark olmaması, UDP paketler kendilerini TCP’deki bir mantıkla ayarlayamazlar. UDP akışının TCP bağlantılara zarar vermemesi için minumum ve maximum aynı verilmiş. tc filter min ve max değerlerinin aynı olmasına izin vermediği için örneklerde hesaplanan değerin bir fazlası kullanılmıştır.

şimdi tablonun uygulamasını yapalım :

bash-3.2#  tc qdisc add dev eth0 root gred setup DPs 8 default 8 grio
RTNETLINK answers: Invalid argument
diyerek grio yani priority destekli 8 sanal qdisc içeren root qdisc oluşturup default sanal qdisc’i 8 inci olarak eklemeye çalışıyor ve hata veriyor neden ? çünkü herzamanki gibi linux saymaya 0 dan başlıyor ve herzamanki gibi referans sitelerimizdeki dökümanlar yanlış!

bash-3.2#  tc qdisc add dev eth0 root gred setup DPs 8 default 7 grio
bash-3.2#
şimdi oldu.

voip servisi için tablomuzdaki değerleri girelim :

bash-3.2# tc qdisc change dev eth0 root gred limit 3146 min 393 max 394 burst 5 avpkt 128 bandwidth 10Mbit DP 1 probability 1 prio 1

bash-3.2#

Referans da bu şekilde verilmiş. ama DP 0 dan saymaya başladığı için DP 0 yerine 1 den başlamak bir kaç defa denedim TC’yi tamamen kullanılmaz duruma soktu. girdiğim kuralları dahi silemedim. o yüzden bu şekilde düzelterek tablodaki tüm verileri en baştan başlayarak girelim.

bash-3.2# tc qdisc add dev eth0 root gred setup DPs 8 default 7 grio
bash-3.2# tc qdisc change dev eth0 root gred limit 3146 min 393 max 394 burst 5 avpkt 128 bandwidth 10Mbit DP 0 probability 1 prio 1
bash-3.2# tc qdisc change dev eth0 root gred limit 5243 min 655 max 656 burst 4 avpkt 256 bandwidth 10Mbit DP 1 probability 1 prio 2
bash-3.2# tc qdisc change dev eth0 root gred limit 131072 min 16384 max 32768  burst 27 avpkt 1024 bandwidth 10Mbit DP 2 probability 0.01 prio 3
bash-3.2# tc qdisc change dev eth0 root gred limit 41943 min 5243 max 10486  burst 17 avpkt 512 bandwidth 10Mbit DP 3 probability 0.01 prio 4
bash-3.2# tc qdisc change dev eth0 root gred limit 104858 min 13107 max 26214  burst 21 avpkt 1024 bandwidth 10Mbit DP 4 probability 0.04 prio 5
bash-3.2# tc qdisc change dev eth0 root gred limit 52429 min 6554 max 13107  burst 11 avpkt 1024 bandwidth 10Mbit DP 5 probability 0.04 prio 6
bash-3.2# tc qdisc change dev eth0 root gred limit 31457 min 3932 max 3933  burst 6 avpkt 1024 bandwidth 10Mbit DP 6 probability 1 prio 7
bash-3.2# tc qdisc change dev eth0 root gred limit 104858 min 13107  max 26214  burst 21 avpkt 1024 bandwidth 10Mbit DP 7 probability 0.04 prio 8

Şİmdi girmiş olduğumuz değerleri görelim :

bash-3.2# tc -s -d qdisc show dev eth0
qdisc gred 8001: root
DP:0 (prio 1) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0)
limit 3146b min 393b max 394b ewma 2 Plog 1 Scell_log 5
DP:1 (prio 2) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0)
limit 5243b min 655b max 656b ewma 2 Plog 1 Scell_log 6
DP:2 (prio 3) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0)
limit 128Kb min 16Kb max 32Kb ewma 4 Plog 21 Scell_log 10
DP:3 (prio 4) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0)
limit 41943b min 5243b max 10486b ewma 4 Plog 20 Scell_log 9
DP:4 (prio 5) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0)
limit 104858b min 13107b max 26214b ewma 4 Plog 19 Scell_log 10
DP:5 (prio 6) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0)
limit 52429b min 6554b max 13107b ewma 3 Plog 18 Scell_log 9
DP:6 (prio 7) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0)
limit 31457b min 3932b max 3933b ewma 2 Plog 1 Scell_log 8
DP:7 (prio Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0)
limit 104858b min 13107b max 26214b ewma 4 Plog 19 Scell_log 10
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
bash-3.2#

Bu yukarıdaki ilk şekilde görmüş olduğumuz işin henüz yarısı. öncelikle yazmış olduğumuz GRED kurallarında dikkat ederseniz hiçbir tc filter girmedik. yani hangi paketin hangi VQ’ya atanacağını belirtmedik. bunu yapmak için iki yöntem kullanabiliyoruz.

1. eth1 için ingress qdisc oluşturup filter ile paketleri işaretlemek ( package tagging, marking )

2. paketleri işaretlemek için iptables ( netfilter ) yardımı almak.

hemen örneklerimizi verelim :

bash-3.2# iptables -t mangle -A PREROUTING -i wlan0 -p udp –dport 5001: –sport 5001: -j MARK –set-mark 0
bash-3.2#

voip trafiği için 5001 den gelip 5001 e gidenleri 0 için markladik. ( pek uygun bir yöntem değil basitçe örneklemiş olduk. kendime ait donanımda eth1 olmadığı için örneği wlan0 için yaptım )

filter ile işaretlemek :

ingress qdisc ekleyelim :

bash-3.2#  tc qdisc add dev wlan0 ingress
bash-3.2#

ilk önce iptables ile işaretlediğimiz paketimiz için filter ekleyelim :

bash-3.2# tc filter add dev wlan0 parent ffff: protocol ip prio 1 handle 1 fw flowid :0
bash-3.2#

açıklayalım : tc ile filter ekliyoruz dev wlan0 için parent ffff: yani ingress qdisc , prio 1 diğe rule lar arasında önce prio 1 işlem görecek, sonra prio 2 bu sıralama sayesinde gecikmenin önemli olduğu voip paketlerini bir an önce process ettik. filter’ımıza handle verdik ve flowid:0 diyerek gred VQ0 e gönderdik.

tc -d -s filter show dev wlan0 parent ffff: diyerek eklediğimiz filter’ı görebiliriz.

şimdi 5 nolu VQ yani mail içi girdiğimiz kural için filter ekleyelim :

bash-3.2# tc filter add dev wlan0 parent ffff: protocol ip prio 6 u32 match ip src 192.168.1.50/32 flowid :5

yine aynı şeklde ekledik. u32 filter kullanarak sadece 192.168.1.50 ipsinden gelen paketleri ( mail server varsayılan ip adresi ) VQ5 e gönderdik. tc filter show ip adreslerini hex olarak gösterir.

filter protocol ip pref 6 u32 fh 800: ht divisor 1
filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid :5
match c0a80132/ffffffff at 12

Sanırım bukadarı diğer kuralları yazmak için yeterli olur.

RED algoritmasına daha önce kısaca değinmiştik.

Random Early Detection (RED)

QOS yapılandırmamız ne kadar mükemmel olursa olsun, servislerin ve kullanıcıların internet kullanımına yüklenmesinden dolayı bazı paketlerimiz kuyrukta yığılarak düşürülmek zorunda kalacaktır. RED algoritmasi bize bu meydana gelmeden  hangi paketin düşürüleceğine öncelik tanıma hakkı verir. RED genellikle backbone sistemlerde tercih edilen bir algoritmadır.

Şimdi RED’i biraz daha açalım.

Tüm queuing disiplinlerinde FIFO, PRIO, TBF, SFQ ve HTB gibi, belirlenen değerlerin üzerinde bir paket akışı olursa, FIFO mantığı ile hareket ederek kuyruktaki en son paket düşürülür. bu yüzden tüm bunlar droptail algoritmalar olarakta bilinir. Peki bir çok kaynaktan bir çok paketin gelerek overflow yaptığını, yani qdisc kuyruğundaki paketkerin drop’lanmaya başladığını düşünelim. sistemimiz kuyruğun en sonuna gelen paketleri drop’ladığı için bir çok bağlantıya cevap veremez hale gelecektir. özellikle TCP bağlantılarda bu pek istenen bir durum değildir. söz konusu durum yaşandığında kuyruktaki tüm paketler düşürüleceği için, TCP bağlantılar bant genişliği kullanımlarını düşürecekler buda network performasımızın altında bir değer yaratacaktır.

Biraz daha basite imdirgemeye çalışacağım. flasget,wget,IDM gibi download hızlandırıcıları hepiniz bilirsiniz. standart download yollarıyla yaptığınız downloadlardan belirli bir oranda daha iyi olduklarını gözlemlemişsinizdir. peki bunu nasıl yapıyorlar ?

Yukardaki şekilde göreceğiniz gibi, kırmızı ile çizilen tcp bağlantı için anlık hızı gösteriyor, yeşil ise avarage yani ortalama hızı gösteriyor. bir TCP bağlantı oluşturulduğunda örneğin http ile dosya download ettiğimizde; TCP olabilecek en yüksek hızı deneyecektir. Bu denenmekte olan hız router’ımızın limitlerinin üzerinde olacaktır. örneğin 56mbit wifi ile bağlandığımız ADSL router’ımızın 1 Mbit olması. bu durumda FIFO da gelen fazla paketin düşürülmesinden başka çıkar yol yoktur. TCP bağlantımız paket kaybını gördüğünde olabilecekten daha hızlı aktarım yapmaya çalıştığını anlayacaktır. yalnız çok büyük paket kayıplarında özellikle  gerçekten ne kadar hızlı aktarım yapması gerektiğini anlayamayaktır. sonuç olarak hız sağlanabilecek değerin çok daha altına inecektir. bir süre sonra TCP yeniden en yüksek değeri deneyecek ve aynı şey tekrar tekrar yaşanacaktır. bizim gerçek download hızımız ise, 1 saniyede elde ettiğimiz maksimum ve minumum dosya aktarım hızlarının ortalamasından  kaybolan paketlerin miktarının çıkartılması sonucu elimizde kalan yeşil ile çizilmiş ortalama değer olacaktır. Download hızlandırıcıların ise genel olarak yaptıkları birden çok bağlantı açarak minumum değerlerin görüldüğü yerlerde başka bir tcp bağlantının daha hızlı transfer yapmasını sağlayıp, bu değerlerin avarage yani ortalamasını yükseltmek olur.

RED’ ile yaptığımız ise, max threshold değeri girerek. bir nevi TCP istemciyi daha önceden uyarıp, paket kayıplarını azaltarak verimi yükseltmektir.

Cisco Sitesinden almış olduğum resim RED’in bu faydasını açık olarak göstermektedir. mavi ile gösterilmiş kontrol edilmeyen trafiğin durumunu ve kesik çizgilerle belirtilmiş ortalama değerini. yeşil ile RED uygulanmış bir bağlantının değerlerini görüyorsunuz. RED’in yaptığı randomize olarak önceden paketleri droplamak olsada, kayıplar kontrolsüz trafikteki kayıplardan çok daha az olduğu için verimi arttırmaktadır. RED genel olarak diğer QOS algoritmaları ile beraber kullanılır. Bu noktada ECN ye değinelim.

ECN nedir ?

ECN , RED ile beraber çalışmakla beraber ana farkı iki ayrı host ( firewall router veya client ) üzerinde çalışır client RED ile paketi düşürmek yerine etiketleyerek server’a gönderir, server client in isteği doğrultusunda gerekiyorsa  bu paketi düşürür. söz konusu ikinci router RED’in yapması gerekeni yaparak optimizasyonu sağlar.

RED ile kullanılan parametreler :

Min : paketlerin kuyrukta biriktiğinde RED tarafından dikkate alınıp işaretlenmesi için gereken minumum değer. birimi byte dır. örneğin : 12000 byte Min değerinin hesaplanması arzu edilen bant geişliği / arzu edilen gecikmedir. örnek verecek olursak. 1024 kbits bağlantımız için 200 ms kuyrukta paketler beklemeye başladığında RED’in drop için işaretlemeye başlamasını  istiyoruz.  hızımız 1024 kbit/s 200ms saniyenin 5/1′i 1024000/5=204800 byte a çevirelim 204800/8=25600byte 1024k bant genişliği arzu edilen en düşük dikkate alınacak 200 ms değeri için atanması gereken Min değeri olur. Bu değeri çok düşürmek efektif bant genişliğimizi düşürür. çok artırmak ise paket gecikmelerini çok yüksek değere taşıyabilir. çok yavaş bant genişliği sağlayan bağlantılarda MTU değeri küçültülerek daha iyi verim alınabilir.

Max : paketlerin kuyrukta birikebileceği en yüksek değer. Bir çok dökümanda Min değerinin 2 katı olmak zorundadır şeklinde değinilmiş, ama hiç bir örnekte uygulanmamış. Cisco dökümanlarının da kaynak olarak kullanılmasıyla çıkmış olduğum sonuç max=3*min veya max=2*min değerleri arasında olmalıdır. Min değerinin hesaplanması ile aynı mantıkla hesaplanabilir Bant genişliği / arzu edilen maksiumum gecikme.

probability : Kuyruktaki paketlerin droplanmak için işaretlenme ihtimali ( yani direk olarak düşürülmesi ), 0.0 1.0 arasıdır. tavsiye edilen değerler 0.01 ve 0.02 dir. ( %1-2 ye denk gelir )

limit : hard limit. kuyrukta bekleyen paketlerin bu ölçüye ulaştığında paket ayırt edilmeksizin hepsinin droplanması amacı ile konulur. limit değeri kesinlikle max + Burst dan fazla olmalıdır. tavsiye edilen hesaplamam max*8 dir örneğin : 32000 byte max için 256000 . limit konulmaması durumunda RED tarafından düşürülen paketler yeterli olmadığı durumlarda ( örneğin DDOS ) kuyruktaki aşırı yığılım kaçınılmaz olacaktır. limit yığılımın belirtilen limit’te kesin olarak sonlandırılmasını sağlar.

burst : paketlerde ani yığılma başladığında, tepe noktaya ulaşmadan önce önlem alınması için yapılması gereken hesaplamalarda kullanılan değerdir. . hesaplama formülü : (min+min+max)/(3*avpkt) dir. burst değeri asla min/avpkt değerinden düşük olmamalıdır.

avpkt : değeri byte’dir. Burst ile birlikte kullanılır. burst ile beraber yaptıkları görev sonuç olarak, kuyruktaki değişimlerin süreleri hesaplanarak. hızlı değişimler olduğunda, kuyrukta yığılıma mahal vermeden önlem almak için gerekli hesaplamalarda kullanılır. 1000 avpkt için iyi bir değer olduğu TC dökümanlarında belirtilmiş.

bandwidth : değeri kilobit/s’dir internet interface’inizin bant genişliğini ifade eder . idle olan zamanlarda, ortalama kuyruk boyutunu hesaplamak için kullanılır. RED bant genişliğinizi kontrol etmez ! opsiyonel olarak kullanılır.

ECN : yukarda ECN’yi açıkladığımız şekilde. RED paketleri drop edebilir veya işaretleyebilir. ECN parametresi kullanıldığında paketler droplanmak yerine işaretlenerek sonraki noktaya gönderilecektir.

Şimdi TC ile RED kullanımına bakalım :

Örnek bir uygulama ile çalışır hale getirelim.

1024 Kbits bağlantımız için RED yapılandırmak istiyoruz.resimdeki sarı ile belirtilmiş verileri dolduralım.

ilk olarak min değerimizi hesaplıyoruz : min için istediğimiz değer 200 ms olsun :  hızımız 1024 kbit/s 200ms saniyenin 5/1′i 1024000/5=204800 byte a çevirelim 204800/8=25600byte

min=25600

şimdi max değerimizi hesaplıyoruz : max değerimiz 500ms olsun 1024kbit /500 1/2 saniye 1024000/2=512000 byte a çeviriyoruz. 512000/8=64000byte ( yukarda belirttiğimiz 2-3 katı değerlerine yakın istersek direk olarak 25600*3 kullanabiliriz. )

max=64000

limit değerimiz : max*8 max=64000 bulmuştuk. 64000*8= 512000 bytes

limit=512000

avpkt = önerildiği üzere 1000 kullanalım 1000bytes

avpkt=1000

burst= packets formülümüz (min+min+max)/(3*avpkt) idi yani (25600+25600+64000)/3*1000)=38.4 39 diyelim.

burst=39

probability = tavsiye edilen değer üzerine 0.02 kullanalım

probability = 0.0.2

bandwidht = band genişliğimiz 1024 Kbits ( kbits olarak değer )

bandwidth = 1024

örneğimizi uyguluyoruz :

bash-3.2# tc qdisc add dev wlan0 root red limit 512kb min 25600 max 64kb avpkt 1000 burst 39 probability 0.02 bandwidth 1024
bash-3.2# tc -s -d qdisc show dev wlan0
qdisc red 8005: root limit 512Kb min 25Kb max 64Kb ewma 4 Plog 21 Scell_log 23
Sent 132 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
marked 0 early 0 pdrop 0 other 0
bash-3.2#

örnekde gördüğünüz üzere, byte değerlerini yazılımı kısaltmak için kbyte a çevirebilirsiniz.

Eğer router’ımız destekliyorsa opsiyonel olarak ECN kullanabiliriz.

tc qdisc add dev wlan0 root red limit 512kb min 25600 max 64kb avpkt 1000 burst 39 probability 0.02 bandwidth 1024 ecn

SFQ : Stothastic Fairness Queuing tcp ve udp bağlantıları eşit olarak dağıtmaya çalışarak tek bir bağlantının tüm hattı bloke etmesini önler.

Yukardaki resimden anlayacağınız üzere , SFQ için ayrılmış qdisc’e gelen tcp udp flow lar belirli sayıdaki kanallara bölünüp scheduler dan geçerek port a giderler. SFQ hangi flow’un hangi kapıya gideceğini round-robbin ile karar verir ( neredeyse rasgele ) . yani bir kuyrukta birden fazla flow olabilir. SFQ bunu engellemek için belirli aralıklarla bu dağılımı yeniden configure eder. hemen uygulamaya geçersek daha iyi anlaşılacağını düşünüyorum.

bash-3.2# tc qdisc add dev wlan0 root sfq perturb 10
bash-3.2# tc qdisc show dev wlan0
qdisc sfq 8001: root limit 127p quantum 1514b perturb 10sec
bash-3.2#

önce komutumuzu inceleyelim :

tc, wlan0 device i için qdisc ekle sfq için root olsun dağıtımı 10 saniyede bir yeniden düzenle.

ve gördüğümüz çıktı :

qdisc sfq : SFQ için qdisc

8001: eklediğimiz kural için otamatik atanmış handle ( manual da verebilirdik )

root limit 127p : bu kuyrukta 127 paket bekleyebilir.

quantum 1514b : bir stream de izin verilen byte miktarı ( MTU dan düşük ayarlanamaz ! )

perturb 10sec : her 10 saniyede bir dağılımı yeniden konfigure eder.

sfq ile verilebilecek parametreler :

perturb : kaç saniyede bir dağılımın yeniden konfigure edileceği. kesinlikle atanmalıdır.

quantum : bir stream de izin verilen byte miktarı, MTU dan düşük olmamalı ne yaptığınızı bilmiyorsanız kesinlikle kullanmayın.

limit : kuyrukta kaç paket bekleyebileceği.

SFQ her hangi bir bant genişliği tanımlamamıza izin vermez. hangi paketin hangi öncelikle işleneceğine de izin vermez. bunun yanında ayarlanması en kolay queuing disiplini olması sebebiyle diğer algoritmalar la sık sık kullanılır. tek başına kullanıldığında sadece giden trafik tamamiyle dolu ise işe yarar.

Token Bucket Filter ( TBF)’in ne olduğunu daha önceki qos yazımda değinmiştim. Egress trafiği basitçe sınırlamak için kullanılabilecek en basit yöntemdir. sonderece düşük cpu ve ram kullanır.

Token Bucket Filter’ı açıklamak için tüm bulduğum kaynaklarda bir benzetme yapılmış sanırım nasıl çalıştığını anlamanın da tek yoluda bu.

Token Bucket Filter direk olarak türkçeye ” Jeton kova filitresi” şeklinde çevirilebilir. Paketlerin kuyrukta beklediklerini ve kernelden interface’e ( örneğin  kernelden ethernete ) teleferik benzeri bir sistemle kova ile taşındıklarını düşünelim. bir kovanın 10 kbit taşıyabildiğini ve kuyrukta 100 kova olduğunu. Saniyede 100 kova nın sırada döndüğünü ve 1 inci kovaya sıra geldiğini düşünelim. 100 kova X 10 kbit =  saniyede 1000 kbit taşınabileceği manasına gelir. ( 1mbits )
Peki 1Mbit’in üstünde paket geldiğinde ne olacak ? kovalar daha fazlasını taşıyamadığı için paketler sırada yığılıp beklemeye başlayacaklardır.  gelen paketlere geçiş haklarını tanımlayıp sıraya koymak için jeton verelim.Böylece kuyrukta bekleye paketlere de bir düzen getirmiş olduk. Bu sisteme kısaca Token Bucket Filter’deniyor
Burada dikkat edilecek nokta TBF in bir paketin önceliğini değiştirmemesi. Sadece bir tarafdan bir tarafa 1 mbit den daha fazla paket geçirilememesini sağlamakta. kovalar saniyede 1 tur attığı 100 kova olduğu için ve her kova 10 kbit taşıya bildiği için üstü mümkün değildir.
Şimdi örneğimizi biraz gerçek hayata çevirelim. Linux umuz da 100 mbit/s ethernet bağlı yani üzerinden saniyede 1000 kova yük geçirebilir. ama internet bağlantımız ADSL ve upload’ımız 1 mbit. yani 100 kova yük taşıyabilmekte.  Linux’umuzun ethernet üzerinden gönderdiği 1000 kova paket sadece 100 kova taşıyabilen ADSL hattımıza geldiğinde tıkanma ve yığılım meydana gelecek ve sorun yaratacaktır. bunu engellemek için linux da sadece 100 kova çıkmasını sağlamak amacıyla TBF yani bu telefirik sistemini kurarak çıkan paketleri 1 Mbit/s sınırlayabiliriz. ADSL hattında oluşabilecek muhtemel tıkanmaları önleyecektir.

Peki nedir bu 100 kova hikayesi ? Linux kernelinde CONFIG_HZ diye tanımladığımız bir zamanlayıcı vardır. ( jiffies ) , tc-tbf man’i yazıldığında default linux için 100 hz olduğu için TBF saniyede 100 bucket refereans alınarak yazılmış peki bizim sistemimizde bunun değeri kaçtır ?

bash-3.2# cat /proc/config.gz | gunzip - | grep ^CONFIG_HZ= | sed s/CONFIG_HZ=//g
300
bash-3.2#

Şu an var olan sistemimde 300 olduğunu görüyoruz. birazdan bunun önemine değineceğim.

Şimdi TBF parametrelerine göz atalım :

limit or latency “(size -in bytes- of the packets queue)” :

limit  kendisine sıra gelmeden önce kaç byte bilginin kuyrukta bekleyebileceğini belirtir. latency ise ne kadar süreyle bekleyebileceğini belirtir. örneğin  : linux üzerinden 100 mbits ile dosya transferi yapılmak isteniyor ve limitimiz 1 mbits. Kuyrukta bekleyen paketler yığılmaya başlayacaktır. limit 1 mbyte verdiğimizde kuyrukta bekleyen paketler 1 mbyte i geçtiğinde droplanmaya başlayacaktır. bunun yerine lanency vrdiğimizde ise paket belirlenen süre kadar kuyrukta bekleyip hala işlem yapılmadıysa droplanacaktır.

burst/buffer/maxburst “(size -in bytes- of the token queue)” :

Rate için bir kovanın taşıyabileceği maximum byte. yapmış olduğum denemelerde 1540 byte dan düşük bucketlerde iletişim de aksama oldu, daha ufağını kullanmamaya özen gösterin.

rate :

sanırım fazla açıklamaya gerek yok kısaca : rate 256kbit şeklinde kullanıyor 1 mbits hat için rate 1000kbit

peakrate :

kurmuş olduğumuz yapının maksimum taşıyabileceği bant genişliği.

mtu/minburst :

Kabaca peakrate . bir kovanın kaç byte taşıyabileceğini işaret eder. örneğin 1 mbits için bir TBF oluşturduğumuzda benim sahip olduğum sistemde HZ=300 olduğuna göre 1000/300=3.3… yani 3 kbyte lık bir bucket yeterli olacaktır.

örnek :

tc qdisc add dev wlan0 root tbf rate 220kbit latency 50ms burst 1540

bu şekilde wlan0 interface imiz üzerinde 220 kbit bant genişliği 50 ms gecikme ve 1540 byte bucket tanımlayıp 220 kbits bant genişliği elde etmemiz gerekiyor ki çalışmıyor ! 140 kbit gibi bir bant genişliği uyguluyor. hemen tbf-man inda ki örneği yapalım :

bash-3.2# tc qdisc add dev wlan0 root tbf rate 0.5mbit burst 5kb latency 70ms peakrate 1mbit minburst 1540
bash-3.2#
ilginç buda çalışmıyor. 0.5 mbit değil 368 kbit gibi bir değer görüyor.

bash-3.2# tc qdisc add dev wlan0 root tbf rate 0.5mbit burst 5kb latency 70ms peakrate 1mbit minburst 5kb
bash-3.2#

şeklinde örneğimizi değiştirdiğimiz de ise sorunsuz olarak çalışıyor ( ölçümleri local de yaptım ) 5kb minburst = 5*300 = 1.5 mbit gibi bir değere denk geliyor. ilk örneğimizin de sorunsuz çalışmış olması lazımdı. tc-tbf man inda verilmiş olan değerler HZ 100 için verildiği için en kötü ihtimal daha yüksek bant genişliği elde etmemiz gerekirdi. ama aksine değerler oldukça düşük çıkıyor.  Sebepleri MTU ile alakalı veya HZ ile alakalı olabilir. açıkçası incelemiyorum, pek zevk almadığımı itiraf etmeliyim. internetteki çalışan tüm örneklerde burst 10k verildiğini belirteyim. 5k ve üstü burst verdiğiniz sürece prolemsiz olarak kullanabilirsiniz.