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

service httpd stop
ps ax | grep httpd (Verify that no httpd process still running)
cd /usr/local/apache
mkdir /home2/apache ( Considering /home2 as your new drive)
mv domlogs /home2/apache/
ln -s /home2/apache/domlogs /usr/local/apache/domlogs
ls -la /usr/local/apache/ (Verify the link)
service httpd start

http://forums.cpanel.net/f5/move-apache-domlogs-second-disk-drive-98821.html

Using Lenny-Backports you can install Pidgin 2.6.2 on Debian Lenny.

Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. I recommend you to pick out single backports which fits your needs, and not to use all backports available here.

-from backports.org

To add backports to your apt sources do the following steps.

open up /etc/apt/sources.list in your editor of choice (as root)

add the line:  deb http://www.backports.org/debian lenny-backports main contrib non-free

save the sources.list

apt-get update

Now you need to add key from backports.

apt-get install debian-backports-keyring

or

gpg –keyserver hkp://subkeys.pgp.net –recv-keys 16BA136C
gpg –export 16BA136C | apt-key add -

or

wget -O – http://backports.org/debian/archive.key | apt-key add -

Now I would suggest removing the current pidgin install.

apt-get remove pidgin

Once it is removed use the -t lenny-backports flag to install pidgin.

apt-get install -t lenny-backports pidgin

http://www.debiantoday.com/install-pidgin-2-6-2-on-lenny/

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = "en_DE:en_US:en_GB:en",
        LC_ALL = (unset),
        LANG = "en_US"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

dpkg-reconfigure locales

good luck ...

# wget http://rarlab.com/rar/rarlinux-3.7.1.tar.gz
# tar xvzf rarlinux*
# cd rar
# make
# make install

Hope this helps.

rm /etc/xinet.d/pure-ftpd

Bu islem yeterli gelir , sorun duzelmezse eger , pure-ftpd yi  kaldirip tekrar kurmamiz gerekir.

yum remove pure-ftpd
yum install pure-ftpd

Daha sonra yapmamiz gereken daha onceki kayitli olan `lxadmin tarafindan olusturulan fptuser larimizi tanitmamiz lazim` pureftpd.pdb  pure-ftp.conf dosyamizda etkinlestiriyoruz.

nano /etc/pure-ftpd/pure-ftpd.conf
dosyayi actiktan sonra
#PureDB                        /etc/pure-ftpd/pureftpd.pdb
yukardaki satiri asagidaki sekilde degistiriyoruz
PureDB                        /etc/pure-ftpd/pureftpd.pdb

Kayit edip cikiyoruz.`ctrl-x` pure-ftpd yi durdurup tekrar baslatiyoruz. hepsi bukkadar.

/etc/init.d/pure-ftpd stop
/etc/init.d/pure-ftpd start

cat timezone -->America/New_York ->Europe/Istanbul

olarak   biz bu degeri  degisitiriyoruz ve bu sorundan kurtuluyoruz.

This tutorial will explain how to install zgegblog-themes in ubuntu jaunty and intrepid
Thanks to Zgegblog for this fantastic themes

First edit /etc/apt/sources.list file

sudo gedit /etc/apt/sources.list

add the following lines

deb http://ppa.launchpad.net/bisigi/ppa/ubuntu karmic main
deb-src http://ppa.launchpad.net/bisigi/ppa/ubuntu karmic main

Save and exit the file

add the GPG key using the following command

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 1781bd45c4c3275a34bb6aec6e871c4a881574de

Update the source list using the following command

sudo aptitude update

Install all the themes using the following command

sudo aptitude install zgegblog-themes

http://www.ubuntugeek.com/nice-ubuntu-themes-for-jaunty-and-intrepid-users.html

Karsilastigim bir sorunun cozumunu paylasmak istedim, Apache sunucumda , sitemaplari gosterirken belli bir kayittan sonra sitemap.php dosyasi hata veriyordu, 404 yada 500  hatasi veriyordu , bu sorunu  ModSecurity SecResponseBodyLimit  degerini arttirarak cozebilirsiniz.

After you have enter the RCON password you can access all the RCON capabilities, by typing:
/rcon [command]
RCON Commands

These commands allow individuals to remotely administer a server. Their use is based on having the RCON password. These commands are to be used in the console.
Kicking

There are two ways to do this. The first is to kick them using their player name:
/rcon kick [playername]

The second is to use their user number on the server:
/rcon status (this is to get a list of players and their user numbers)
/rcon clientkick [usernumber]
Restart Server

While you can't actually restart the server, you can reload the server.cfg, which amounts to about the same thing.
/rcon exec server.cfg
Ban an IP

The first thing that you have to do before banning anyone is to add this line to the server.cfg file:
set filterBan 1

Now you can add an IP to the ban list by typing at the console:
/rcon addIP [ip_address] (you can also use IP masks)

To remove an IP from the list:
/rcon removeIP [ip_address]

To list the IPs currently banned use the banlist.txt file.
Referees

Referees are a feature that has been added to help server admins manage their servers. The referee is like a less powerful version of RCON: you can set a password and give it out to trusted players. Unlike RCON, the referee has limited control over how they can affect the server. It gives them the ability to do things like mute annoying players, kick them and even ban them from the server for up to 3 hours. All referee commands start with the ref command. The basic referee command looks something like this:
ref {refcommand} [{parameters} ...]

Referee commands can only be used by a client who has logged on as a referee using the reflogin command with a valid password. If a password has not been set, or if the server has disabled the referee function, no one will be able to login as a referee.
Enabling Referees

To enable a referee, a server admin first needs to set the referee password:
/g_refpass "password"

Then set whether the referee can ban people:
/g_refNoBan 0 (to give them ban power)
/g_refNoBan 1 (to stop them from banning players)

Finally enable referees:
/g_referee 1

Be very careful with allowing referees to ban players on your server, unless you can trust them to use the power responsibly. Otherwise, you might find angry players boycotting your server!
Log on as Referee

To login as a referee you need to ask the server administrator for the referee password. Once you have it, you can login by pulling down the Quake III console and typing:
/reflogin "password"

If you enter the password correctly and the server is set up to allow referees, then you will receive a message telling you that you have successfully logged in. Once logged in you can use all the referee commands. These commands and their effects are listed below.