İşte bu gibi durumlarda yapılabilecek şeylerden biri şifreyi hatırlamak bir diğeri ise şifreyi resetlemektir. Neyseki mysql’in şifre resetleme prosedürü bir iki adımda halledilebilecek kadar basit bir olay. İnternette konu ile ilgili bulabileceğiniz bir çok dökümanın bir benzeri olan ve kendime not olması açısından yazdığım bu postta da, mysql şifrelerinin kolayca nasıl resetlenebileceği anlatılmaktadır.

İzlenmesi gereken adımlar şöyle:

Mysql’i durdurun.

# /etc/init.d/mysqld stop

Stopping MySQL:            [  OK  ]

Şimdi, skip-grant özelliği ile tekrar başlatın:

# mysqld_safe --skip-grant-tables &

Starting mysqld daemon with databases from /var/lib/mysql

Mysql’e passwordsüz bağlanın.

# mysql -u root

Welcome to the MySQL monitor.  Commands end with ; or g.
Your MySQL connection id is 1
Server version: 5.0.45 Source distribution

Type 'help;' or 'h' for help. Type 'c' to clear the buffer.

mysql>

Aşağıdaki komutları sırası ile vererek yeni şifrenizi belirleyin.

mysql> use mysql;
mysql> update user set password=PASSWORD("Yeni_Sifreniz") where User='root';
mysql> flush privileges;
mysql> quit;

Mysql’i yeniden stop edin.

# /etc/init.d/mysqld stop

Stopping MySQL:      [  OK  ]
[1]+  Done mysqld_safe --skip-grant-tables

Son olarak normal bir şekilde başlatın.

# /etc/init.d/mysqld start

Hepsi bu.
Artık yeni şifreniz ile login olabiliyor olmalısınız.

Bu işlem bir CentOS üzerinde yapıldı, kullanığınız dağıtıma göre init scriptinin yeri değişebilir. Ayrıca, mesela FreeBSD kullanıyorsanız start stop scripti bildiğiniz gibi /usr/local/etc/rc.d/mysql-server şeklindedir. Bunun dışında kalan diğer her adım aynıdır.

Kaynak:

http://www.cyberciti.biz/tips/recover-mysql-root-password.html

GreenSQL, sql injection saldırıları için database’leri koruma altına almak üzere geliştirilmiş bir database firewall uygulamasıdır. MySQL ve PostgreSQL’ler için destek sunan GreenSQL temel olarak proxy olarak çalışarak gerçek database’in önünde durur ve web uygulamasından gelen sql bağlantı isteklerini karşılayarak SQL komutlarını inceler ve bir risk scoring matrix kullanarak ilgili sql cümlelerini analiz ederek aksiyon alır.

Bu şekilde, web uygulamanızda bir sql injection açığı bulunsa dahi GreenSQL sayesinde açıktan etkilenmemeniz mümkün olabilir.  Detaylarına yazının devamında değineceğim GreenSQL temel olarak, default 3305 portunu dinler ve gelen sql istekleri için risk analizi yapar; güvenli olmaları durumunda komutları arkadaki sql sunucusuna iletir, eğer sql cümleleri güvenli değil ve daha önceden de Whitelist’e eklenmemişlerse blocklar ve uygulamaya boş bir cevap döndürür. GreenSQL’in IPS, IDS, Firewall ve Learning gibi modlarda çalıştırabilirsiniz. Özellikle learning modu false positive durumların önüne geçmek için çok kullanışlıdır. Ayrıca GreenSQL fiziksel olarak database sunucunuz ile aynı makinada çalışabilir ya da ayrı bir makina üzerine konumlandırabilirsiniz.

GreenSQL Çalışma Mantığı

Bu bölümde yukarıda kısaca değindiğim konuların detaylarını aktaracağım sonraki bölümlerde de kurulum ve yapılandırmaya değineceğim.

GreenSQL reverse proxy olarak uygulamanıza ait database’in önünde çalışmaktadır. Bu şekilde uygulama üzerinden yapılan SQL işlemleri gerçek database’de çalıştırılmaktansa GreenSQL’e gelir ve burada analiz edilmesi sağlanır. Aşağıdaki şemada GreenSQL’in çalışma mantığı daha net anlaşılmaktadır.

Şemada da görüldüğü üzere web uygulaması sql işlemlerini doğrudan GreenSQL’e göndermektedir; sql query’ler burada analiz edildikten sonra arkadaki gerçek database’e iletilir. GreenSQL’in güzel yanlarından birisi de gerçek database’in bulunduğu fiziksel sunucuda kullanılabilmesidir. Default olarak 3305. portu dinlediğinden dolayı Sql sunucusu ile aynı makina üzerinde çalışabilir, böylece herhangi bir donanım yatırımına gerek kalmaz. Yapmanız gereken tek şey web uygulamanızın sql connection ayarlarını GreenSQL’e bağlanacak şekilde set etmektir. Örnek olarak web uygulamanız ile sql sunucu aynı makinada çalışıyorsa, web uygulamasının sql connection satırını 127.0.0.1:3306 yerine 127.0.0:3305 yapmaniz yeterli olacaktır.

Ayrıca, GreenSQL’i dedice bir sunucuya kurup birden fazla database server için merkezi proxy olarak da kullanmanız mümkündür. Böylece web uygulamalarınızın sql bağlantı ayarlarını GreenSQL’in ipsi ve 3305. port olarak set etmeniz yeterli olacaktır.

GreenSQL Çalışma Mod’ları

GreenSQL’i bir kaç farklı modda çalıştırabiliyorsunuz. Bu modlar ve açıklamaları şöyle:

• Simulation Mode (database IDS) Bu modda, grensql herhangi bir blocklama işlemi yapmaz. Sadece web uygulamasından gelen sql işlemlerini alır inceler ve sonucu loglar, daha sonra da database’e iletir. Bu şekilde çalıştırılan şüpheli sql cümlelerinden haberdar olursunuz.  Herhangi blocklama işlemi de yapılmadığından false positive durumlarla karşılaşmazsınız.
• Blocking Suspicious Commands (database IPS) Bu modda, illegal sql komutları blocklanmaktadır.  Sisteme illegal bir query geldiği zaman öncelikli olarak Whitelist kontrolü yapılır. Eğer ilgili query listede bulunamazsa, komut blocklanır ve web uygulamasına boş bir cevap döndürülür. Bu modda false positive ya da false negative durumlarla karşılaşılabilir.
• Learning Mode Learning modu, yukarıdaki iki moda nazaran en kullanışlı olanıdır. GreenSQL’i belirli bir süre için learning moda aldığınız zaman gelen tüm sql komutları whitelist’e alınır, learning periyodu bittiğinde ise Active protection from unknown queries denilen moda geçer. Bu aşamada white listte olmayan tüm queryler blocklanırlar.  Learning modu süresiz olarak devreye alabilir sonra istediğiniz bir zamanda manuel olarak Active Protection moduna sokabilirsiniz. Veya 3 ya da 7 günlük Learning Mod seçenekleri bulunmaktadır. Bu durumda belirlenen süre sonunda GreenSQL otomatik olarak ilgili db için Active Protection moduna geçer.Learning modunu kullanarak, GreenSQL’in web uygulamanıza ait doğru sql komutlarını öğrenmesini ve learning mode sonunda, öğrenilen komutlar dışında kalan daha önce rastlanılmamış sql cümlelerini blocklamasını sağlayabilir ve false positive durumları en aza indirgeyebilirsiniz.

Bu modların yanı sıra, GreenSQL CREATE, DROP vs. gibi bilinen database yönetim komutlarını da tamamen blocklayabilmektedir. İhtiyacınıza göre bu özellikten de faydalanabilirsiniz.

Illegal Querylerin Tespiti

GreenSQL bir query’nin illegal olup olmadığınu tespit etmek için aşağıdaki metodları kullanır.

• Yönetimsel ve Sensitive Query’lerin saptanmasıGreenSQL imza tabanlı bir sistem kullanır ve querylerin, database yapısını değiştirmek, sistem dosyalarına erişmek vs. gibi yönetimsel ve hassas işlev içerip içermediğin tespit eder ve bu tip query’leri illegal olarak değerlendirir. Eğer web uygulamanız böyle query’ler çalıştırıyorsa, bunları spesifik olarak whiteliste’e ekleyerek false positive durumların önüne geçebilirsiniz.
• Query Risk Hesaplaması
  
  GreenSQL, bir query’inin risk derecesini hesaplamak için örnek olarak aşağıdaki faktörleri göz önüne alır.
  1. Users, Accounts vs. gibi hassas tablolara erişim.
  2. Sql komutlarının içinde yorum ifadeleri bulunması.
  3. Boş password stringi.
  4. Query içerisinde “or” token’i bulunması.
  5. SQL tautology

GreenSQL ile ilgili teorik bilgiler hemen hemen bu kadar. Şimdi kurulum ve yaplandırma işlemlerine geçelim.

GreenSQL Kurulumu

GreenSQL RedHat, CentOS, Fedora, SuSe, Mandriva, Debian, Ubuntu gibi GNU/Linux dağıtımları ve FreeBSD sistemler için pre-compiled paketi bulunuyor.  Böylece kurulumu, sisteminizin paket yöneticisini kullanarak yapabiliyorsunuz. Ben burada Greensql’in CentOS 5.2 üzerine kurulumundan bahsedeceğim ancak siz download sayfasından kendi dağıtımınıza ait pre-compiled paketi indirebilirsiniz.  Paketin yüklenmesi dışındaki tüm işlemler aynıdır.

Ayrıca, GreenSQL’in web tabanlı bir yönetim arayüzü bulunduğundan dolayı, sunucunuzda apache, php ve mysql bileşenleri bulunmalıdır. Dolayısı ile şimdi bahsedeceğim işlemlere başlamadan önce sunucunuzda bu bileşenlerin bulunduğuna emin olun.

Download

Sisteminize uygun paketi, http://www.greensql.net/download adresinden download edebilirsiniz. Ben CentOS 5.2 kullandığım için greensql-fw-1.2.2-17.1.i386.rpm isimli rpm paketini indiriyorum.

Kurulum

Kurulumu herzamanki rpm install yönetimi ile yapıyoruz.

# rpm -ihv greensql-fw-1.2.2-17.1.i386.rpm

Yapılandırma

GreenSQL, yapılandırma ayarları ve alert loglarını bir database’de (MySQL ya da PostgreSQL) tutuyor. Database ayarlamalarını ve temel yapılandırma için /usr/sbin/greensql-config betiğini çalıştırmak yeterli oluyor.

# /usr/sbin/greensql-config

Bu komutu çalıştırdığınız zaman yapılandırma ile ilgili bir iki soru soruluyor. Üzerinde MySQL server çalışan bir makinadaki örnek bir ekran çıkıtısı aşağıdaki gibidir.

executing /usr/bin/greensql-create-db.sh
which: no psql in (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)

mysql binary file located: /usr/bin/mysql
mysqladmin binary file located: /usr/bin/mysqladmin

Database type (mysql or pgsql) [mysql]:
MySQL server address [127.0.0.1]:
MySQL port number [3306]:
MySQL admin user [root]:
MySQL admin password [root-sifreniz]:
GreenSQL config db name [greendb]:
GreenSQL DB user name [green]:
GreenSQL DB user password [pwd]:
Would you like to set up the database and tables automatically [Y/n]:

Creating MySQL database...
Adding MySQL user green...
Creating MySQL tables...
Modifing /etc/greensql/greensql.conf...

Görüldüğü gibi GreenSQL yapılandırma aracı sistemde PostgreSQL ve MySQL kontrolü yapıyor ve bizim örneğimizde MySQL sunucusunu tespit ederek sunucuya ait bilgileri girmenizi istiyor. Daha sonra da öntanımlı greendb isimli bir database oluşturup, bir kullanıcı ve şifre atıyor. (Default olarak user: green pass: pwd) Daha sonra da greenSQL için gerekli olan database’in otomatik olarak set edilmesini isteyip istemediğimizi soruyor.

Son olarak da işlemleri gerçekleştirip yapılandırmayı /etc/greensql/greensql.conf dosyasına yazıyor.

GreenSQL servisinin start edilmesi

Yapılandırma işlemlerinden sonra servisi başlatıyoruz.

# /etc/init.d/greensql-fw start

Servis sorunsuz başladıysa, şimdi web tabanlı yönetim konsolunu devreye alabiliriz.

GreenSQL Management Console Yapılandırması

Bu web konsolu, GreenSQL firewall tanımlamalarının yapılması ve hertürlü yönetim işleminin gerçekleştirilmesi için kullanılmaktadır. Burada, back-end database’lerinizi tanımlayarak bu database’ler için GreenSQL’in hangi modda çalışacağını ayrı ayrı belirleyebilirsiniz.

GreenSQL web interface’ine ait dosyalar öntanımlı olarak /usr/share/greensql-fw/ dizininde bulunmaktadır. Bu dizini web sunucunuzun document root’una taşıyarak ya da document root’tan orjinal dizine link yaratarak kolayca devreye alabilirsiniz.
Örnek olarak CentOS 5.2′de apache 2.2′nin default document root’u /var/www/html’dir. Bu durumda linkleme işlemini şu şekilde yapabilirim:

# cd /var/www/html
# ln -s /usr/share/greensql-fw/ greensql

Son olarak da greensql dizini içinde bulunan templates_c dizinine yazma izni vermek gerekiyor. Bu dizinde cachelenen sayfalar tutulacağı için web suncusunun bu dizine yazabilmesi gerekir.

# cd /var/www/html/greensql
# chmod 0777 templates_c

Herşey yolunda gittiyse, web interface erişileiblir durumdadır. Browser’ınıza http://sunucu-ip-adresi/greensql yazarak interface’e erişebilirsiniz. Herhangi bir sorun varsa, greensql dizinindeki config.php dosyasında mysql bağlantı bilgilerinizi kontrol edebilirsiniz.

Login ekrani aşağıdaki gibidir ve default kullanıcı “admin” şifre “pwd” dir.

Web interface’i ile ilgili apache ayarlarınızı düzenleyebileceğiniz bir de /etc/greensql/greensql-apache.conf isimli dosya bulunmaktadır. Buradan ihtiyacınız olan düzenlemeleri yapabilirsiniz.

Bir testlik yoksa, GreenSQL şu an çalışmaktadır ve tcp 3305 portunu dinlemektedir. Kontrol etmek için netstat komutundan yararlanabilirsiniz.

# netstat -anp |grep 3305
tcp        0      0 127.0.0.1:3305              0.0.0.0:*                   LISTEN      8296/greensql-fw

Görüldüğü gibi GreenSQL 127.0.0.1′e bind edilmiş 3305′i dinlemekte.

Ayrıca, sql komut satırına da bağlanarak durumu check edebilirsiniz.

# nmysql -h 127.0.0.1 -P 3305 -u root -p

Önemli Not: Mysql’e localhost şeklinde değil de 127.0.0.1 olacak şekilde bağlantı kurmanız gerekir. Zira eğer localhost derseniz bağlantı tcp stack yerine unix domain socket kullanacaktır. Ancak GreenSQL şu an unix domain socket desteklemiyor. Bu nedenle bağlantıyı tcp stack ile yapmak için -h parametresi kullanarak 127.0.0.1 şeklinde yapmanız gerekir.

Çıktı şuna benzer olacaktır:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 174
Server version: 5.0.77 Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

Normal mysql komut satırından farklı olmayan bu ekranda aslında GreenSQL’in komut satırına bağlanmış bulunuyoruz. Burada örnek olarak sunucu üzerindeki db’leri görüntülemek istersek aşağıdaki gibi boş sonuç döndürülecektir.

mysql> show databases;
Query OK, 0 rows affected (0.00 sec)

Bunun nedeni, sensitive bilgilere erişmek istememiz nedeni ile GreenSQL’in bu isteği (default olarak) blocklamış olmasıdır. Block durumunu web interface’in Alerts kismindan gözlemleyebilirsiniz.

Temel yapılandırma işlemleri bu kadar. Bundan sonra web interface’i kullanarak, proxy uygulaması yapılacak db’lerinizi GreenSQL’e tanımlamak ve web uygulamanızın mysql connection ilgilerini 3305′e bağlanacak şekilde değiştirmekten ibaret.

Örnek olarak web uygulamanızın sql connection satırı aşağıdaki gibiyse:

$link = mysql_connect('localhost', 'mysql_user', 'mysql_password');

şu şekilde bir değişiklik yapmanız yeterli olacaktır:

$link = mysql_connect('127.0.0.1:3305', 'mysql_user', 'mysql_password');

Web interface’de düzenleme yapmadan önce GreenSQL’in demosuna aşağıdaki adresten erişip, genel ayarlara göz atabilirsiniz.

http://demo.greensql.net/login.php

Performans

http://www.greensql.net/publications/greensql-performance-test

Daha fazla bilgi için bkz:
http://www.greensql.net

Önce IPFIREWALL.

IPFIREWALL NEDİR ?

Namı diğer IPFW, FreeBSD tarafından geliştirilen hem Stateless hem de Statefull firewall mimarisini üzerinde barındıran güzel bir ip tabanlı firewall yazılımıdır. Ayrıca,  traffic shaping, transparent forwarding ile NAT ve PATgibi özellikler sağlar. Bu özellikler ile ilgili detayli bilgiyi, dökümanın “ipfw komutları” bölümünde bulabilirsiniz. Öncelikle nasıl kurulduğuna değineceğim.

NASIL KURULUR ?

Aslında IPFW, FreeBSD ile birlikte loadable module olarak geldiği için NAT uygulaması kullanmak istemeniz haricinde ekstradan herhangi bir kuruluma ihtiyaç duymazsınız. Açılışta firewall’un devreye girmesi için rc.conf dosyasına aşağıdaki satırı girmeniz yeterlidir.

firewall_enable="YES"

Ancak NAT kullanmak istemeniz durumunda (ki snort_inline için gerekmektedir.) kernelinize options IPDIVERT satırını eklemeniz ve yeniden derlemeniz gerekmektedir.  Kernelinizi yeniden nasıl derleyebileceğiniz ile ilgili bilgiye, daha önce yazmış olduğum Custom Kernel dökümanından ulaşabilirsiniz.

NAT dışında gerekli olmasa da bilgi olması açısından IPFW’nin kernel opsiyonları şu şekilde.

KERNEL OPTIONS:

options    IPFIREWALL
Firewall’un enable edilmesi için.

options    IPFIREWALL_VERBOSE
Firewall’un üzerinden geçen trafiği loglamak için kullanılır. Kurallarınızın nasıl işlediğini /var/log/security isimli log dosyasından takip edebilirsiniz.

options    IPFIREWALL_VERBOSE_LIMIT=200
Bir kurala ait işlemin kaç kez loglanacağını belirler. Bu örnekte 200 satır. Herhangi bir kuralla ilgili olarak loglanan bir işlem 200 kere tekrarlandığı zaman, loglama işlemi o kural için durdurulur. Loglama işlemine kısıtlama getirerek servera binen işlemci yükünü hafifletebilirsiniz. Ayrıca birinin firewall’unuza devamli paket göndermesi ve bunların hepsini loglamanız durumunda oluşacak syslog flooading (DoS) saldırısının da önüne geçmiş olabilirsiniz.

options    IPFIREWALL_DEFAULT_TO_ACCEPT
Bu opsiyon default olarak gelen ve giden herşeyin kabul edilmesini sağlar. Bu opsiyon aktifleştirilmezse firewall’unuz closed modda çalışacaktır. Yani herşey deny edilecektir. Bu durumda izin vermek istediğiniz bağlantılar için rulelar oluşturmanız gerekir.
NOT: Eğer firewall ile ilgili işlemleri SSH bağlantısı ile uzaktan yapıyorsanız, bu seçeneği aktif etmemeniz ya da kendiniz için SSH bağlantısına izin veren bir rule tanımlamamanız durumunda bindiğiniz dalı kesmiş olursunuz. Bir console bağlantısına sahip olmanız yararınızadır  Ya da kerneli yeniden derlemeden önce rc.conf dosyanıza firewall_type=”open” satırını ekleyip gelen giden herşeye izin verebilirsiniz. Firewall_Type ile ilgili rc.conf seçeneklerini bir sonraki bölümde bulabilirsiniz.

options    IPV6FIREWALL
options    IPV6FIREWALL_VERBOSE
options    IPV6FIREWALL_VERBOSE_LIMIT
options    IPV6FIREWALL_DEFAULT_TO_ACCEPT
IP Version6 için gerekli opsiyonlar. Gördüğünüz gibi IPv4 opsiyonları ile aynı.

options    IPDIVERT
NAT (Network Address Translation) yapabilmek için gerekli opsiyon. Ayrıca, Snort_Inline gibi Divert soketinden paketleri alıp inceleyen yazılımlara yönlendirme yapmak için de gerekiyor. Bu özellik default olarak gelmemekte, devreye almak için bu kernel parametresini girip kerneli yeniden derlemeniz gerekmektedir.

options    DUMMYNET
Trafik shaping yapmak için. Banwith limitlemesi ya da queue düzenlemesine olanak sağlar.

RC.CONF SEÇENEKLERİ:

firewall_enable=”YES”
Açılışta firewall’u devreye alır.

firewall_type=”open”
Firewall’un hangi tipte çalışacağını belirler. Seçenekler ve ne iş yaptılkları şöyle:

open : Gelen giden herşeye izin ver.
client : Sadece bu makineyi koru.
simple : T0üm ip networkünü koru.
closed : Loopback interfacei hariç gelen giden herşeyi yasakla.
filename : firewall rulelarini içeren dosya.

Kurallarınızı firewall’a uygulamanız için iki yol bulunmaktadır. Birincisi rc.conf dosyasında

firewall_type="filename"

parametresi ile belirttiğimiz rule dosyamıza yazacağımız rulların açılışta devreye alınmasını sağlamak.

Mesela, /etc dizini altında ipfw.rules isimli bir dosya oluşturalım ve içerisine aşağıdaki “gelen giden herşeye izin ver” anlamındaki firewall rulelarını yazalım.

add any in  all
add any out all

Sonra /etc/rc.conf dosyamıza  firewall_type=”/etc/ipfw.rules” satırını ekleyip kaydedelim. Bu durumda serverı restart ettiğiniz zaman açılışta firewall devreye alınacak  ve type satırında yazan pathteki dosyada bulunan rulelar sisteme eklenecektir.  Bu şekilde herhangi bir command-line komutu kullanmadan rulelarınızı devreye alabilirsiniz.

Bir diğer yöntem ise bir shell script oluşturup ruleları sisteme eklemektir:
Gene /etc altında ipfw.rules isimli bir dosya oluşturup içerisine aşağıdaki satırları girelim.

#!/bin/sh
ipfw -q flush
ipfw add block in  all
ipfw add block out all

Daha sonra /etc/rc.conf dosyasına firewall_script=”/etc/ipfw.rules” yazalım.

Şimdiki yöntemde rc.conf dosyasında firewall’a ruleları içeren script dosyasının yerini söyleyip restart ettiğiniz zaman, açılışta firewall devreye alındıktan sonra bu script dosyası çalıştırılacak ve rulelar sisteme eklenecektir. Bu yöntemin güzel bir özelliği rule scriptinde herhangi bir değişiklik yaptıktan sonra sistemi restart etmenize gerek kalmaksızın script dosyasını çalıştırmak suretiyle değişiklikleri devreye almanıza izin vermesidir. Rule Script’ konusunda detaya “Ipfw komutları” bölümünde yer vereceğim.

firewall_logging=”YES”
Firewall üzerinden geçen trafiği loglamak için. Bu noktada dikkat etmek gereken bir şey var. Normalde bu satırı eklediğiniz zaman net.inet.ip.fw.verbose isimli sysctl variable’ı 1 olarak set ediliyor ve devreye alınıyor.Ancak log limiting için herhangi bir rc.conf ayarı yok. Eğer kernelinizi options IPFIREWALL_VERBOSE_LIMIT=200 satırı ile yeniden derlemediyseniz, bu ayarı /etc/sysctl.conf dosyanızda manuel olarak girmeniz gerekiyor.

net.inet.ip.fw.verbose_limit=5

Not: Benim kurulumunda, kernel’i log limit seçeneği ile yeniden derlemiş olmama rağmen logginde sorun çıkmıştı. Bu nedenle sysctl.conf dosyasına net.inet.ip.fw.verbose=1 satırını manuel olarak ekledim. Ayrıca limit işlemi için de script dosyası içerisinde “logamount” isimli ipfw komutunu kullanıyorum. Bu komutla ilgili bilgi “ipfw komutları” kısmında bulunuyor.

gateway_enable=”YES”
Bu parametre, FreeBSD’yi gateway olarak kullanmak ve ethernet kartları arasında geçiş sağlamak için gereklidir. Bir firewall kurduğumuza ve muhtemelen networkümüzün çıkış kapısı olarak kullanacağımıza göre bu FreeBSD’yi gateway olarak kullanmanız gerekecektir.

tcp_drop_synfin=”YES”
SYN+FIN içeren TCP paketlerini drop eder. Bu özelliğin nmap ile işletim sisteminizin algılanmaması gibi işlevleri vardır.

ÇALIŞMA PRENSİBİ

IPFW’yi devreye aldıktan sonra, sıra  networkümüze ve güvenlik politikamıza göre kurallar oluşturmaktan ibaret geliyor. Ancak önce ipfw’nin mantığından ve söz diziminden bahsedelim. Öncelikle yazının başında adı geçen statless ve stateful firewall kavramlarına değinmekte yarar var. Zira bu her iki firewall kavramını IPFW’de uygulamanız mümkün.

Sateless Firewall:

Stateles (durum kontrolsüz) firewall, kuralların statik olarak tanımlandığı temel paket filtreleme yöntemidir. Ancak eski ve çeşitli alanlar haricinde pek güven vermeyen bir yöntemdir. Zira ilk nesil paket filtreleme teknolojisi olan bu yöntem, IP ve transport layer’da çalışan ve gelen paketlerin sadece header bilgilerinden hareketle karar veren bir yapı olduğu için oldukça basit olarak çalışır. Data akışını kontrol etmeksizin gelen ya da giden paketlerin kaynak ipsini, ulaşmak istediği port ve protokolünü inceler.  Eğer üzerinde  bağlantı isteğine uyan bir  kural varsa , kuralın aksiyon bölümünden hareketle paketi geçirir ya da keser. Bağlantının akışını takip etmediğinden dolayı, firewall’dan daha önceden geçerek kurulmuş bir bağlantının abuse edilmesi suretiyle sisteme saldırıda bulunulmasının önüne geçemez.

Eski olmasına ve güven vermemesine rağmen çeşitli ortamlarda halen kullanmak mümkündür. Örneğin iki farklı lokasyonunuz olması durumunda lokasyonlar arası trafik için stateless kurallar kullanabilirsiniz. Zira kendi kendinize saldırmak gibi bir durum söz konusu olmaz heralde.

Stateful Firewall:

Stateful inspection (durum kontrolü) olarak da anılan Stateful (dinamik filtreleme) yapısı, stateless yapısından ayrı olarak bağlantı oturumlarını da gözeterek kuralları bu doğrultuda uygulayan bir yöntemdir ve dinamik kurallar oluşturarak işlem yapabilen mimarilerdir.  Bu yapıya ait örnekleri söz dizimi ve komutlar kısmında bulabilirsiniz.

Stateful ve Stateless kavramlarına kısaca değindikten sonra, firewall’un çalışma prensibine geçelim.

Her bir rule için bir kural numarasına ihtiyaç vardır ve ipfw 65535 adet kural tanımlamasına izin vermektedir. Firewall tipini closed olarak tanımladıysanız. 65535 nolu kural “deny ip from any to any“ olacak ve gelen giden herşeyi yasaklayacaktır. Firewall mantığında gelen paketler kural numaralarına göre yukarıdan aşağıya doğru adım adım incelenir, paket birinci kural ile eşleşmiyorsa ikinci kurala ikinci ile eşleşmiyorsa üçüncü, dördüncü vs. şeklinde incelenir. Eğer hiçbir kural ile eşleşmeyen bir paket varsa o zaman 65535 no’lu kural devreye girer ve paket bu kurala göre muamele görür. Eğer kernelinizi IPFIREWALL_DEFAULT_TO_ACCEPT opsiyonu ile yeniden derlediyseniz 65535. kural herşeyi geçir manasına gelen “allow ip from any to any” olacaktır.

Bence bir firewall uygulamasında izlenmesi gereken yöntem. Firewall’u closed modda çalıştırmak ve daha sonrasında izin vermek istediğimiz bağlantı çeşitleri için kurallar oluşturmaktır. Ancak henuz bu konuda pek tecrübeli değilseniz başlangıç için firewall’unuzu open modda çalıştırmak ve yasaklamak istediğiniz bağlantılar için kurallar oluşturarak denemeler yapmak iyi bir fikirdir. Konuyu özümsedikten sonra firewall’unuzu closed moda alıp kurallarınızı yeniden oluşturabilirsiniz.

SÖZ DİZİMİ VE KOMUTLAR:

Temel olarak ipfw söz dizimi şu şekildedir.

Komut Kural_Numarası Aksiyon Loglama Seçenek

İşte bu söz dizimine uygun stateles bir ipfw kuralı.

#ipfw add 00010 allow log all from any to any

Bu komutu command-line’dan girdiğiniz zaman firewall’a  gelen ve giden tüm paketler için izin ver manasına gelen bir rule tanımlamış olursunuz.

Söz dizimine ait açıklamalar şöyle;

Komut: Örnekte kural eklemek için ipfw add, silmek için ipfw delete.

Kural_Numarası: Her bir kuralın bir numarası olması gerektiğini söylemiştik. 1 ile 65534 (65535 default kural için kullanılır) arasında olabilir. Eşleştirme işlemi kural numaralarına göre yukarıdan aşağıya doğru yapıldığından sıralamaya dikkat etmeniz gerekmektedir.

Aksiyon:

Bir çok aksiyon seçeneği bulunmaktadır.

allow : Paketin geçmesine izin verir. Allow yerine aynı anlama gelen “accept”, “pass” ya da “permit” kelimelerini de kullanabilirsiniz.

deny : Paketin geçnesine izin vermez. Ilgili paket silinir. deny yerine aynı anlama gelen “drop” kelimesini de kullanabilirsiniz.

check-state : Stateful kurallar aracılığı ile oluşturulmuş dinamik rulların kontrol edilmesini sağlar. Paker dinamik kurallar ile eşleşmezse bir sonraki kuraldan arama devam eder.

count : Kuralla eşleşen paketleri saymak için kullanılır. Arama işlemi sonraki kuraldan devam eder.

divert (port):  Divert soketi kullanan herhangi bir yazılıma port yönlendirmesi yapmak için kullanılır. Eşleşen paketler kuralda belirtilen porta yönlendirilir. Bu özelliği snort_inline için kullanacağız. Yazının başında bahsettiğim gibi bu özellikten yararlanmak için kernelinize options IPDIVERT satırını ekleyip yeniden derlemeniz gerekmektedir.

fwd (ipaddr[port]): Paketi herhangi bir porta ya da ip adresine yönlendirir. Bu sayede belirlediğiniz tarzdaki bağlantılar için routing işlemi yapabilir birden çok gateway kullanabilirsiniz. Ayrıca mesela hedefi 80 olan istekleri port forwarding ile proxy serverınızın portuna yönlendirebilir ve transparent proxy uygulaması yapabilirsiniz.

nat (numara): Network address translation için kullanılır.

pipe (numara): Bantgenişliğini düzenlemek için kullanılır. Bu sayede limitleme işlemi yapabilirsiniz.

queue (numara):  Paket kuyruklarını düzenlemek için kullanılır.

skipto (numara): Paketin diğer kurallarla eşleştirilmeden verilen numaradan başlayarak incelenmesini sağlar.

reset : Eşleşen paketin reddedilmesini sağlar ve karşı tarafa TCP reset (RST) uyarısı gönderir.

tee (port): Eşleşen paketin bir kopyasını divert kullanan bir yazılıma ait porta gönderir. Arama bir sonraki kuraldan devam eder.

Log : İlgili kurala ait işlemlerin loglanmasını sağlar. log logamount (numara) derseniz ilgilil kuralın kaç satır boyunca loglanacağını belirtmiş olursunuz.

Seçenek : Bu kısımda protokol’ü, (tcp/udp/icmp), kaynağı, hedefi, port numarasını, geliş ya da gidişi, hangi interface üzerinden geçtiğini, TCP bağlantı requesti olması durumunda SYN flag ile başlaması gerektiğini ve ilgili kural için dinamik kural oluşturulup oluşturulmayacağını belirleyebilirsiniz.

Temel olarak söz dizimi ile ilgili bilgiler hemen hemen bu kadar. Daha fazlası için ipfw(8) man dosyasını okuyabilirsiniz.

IPFW’nin durumu ile ilgili bilgi almak için komutlar ise şu şekilde:

ipfw list : Kuralları listeler.

ipfw -d list : Dinamikler de birlikte olmak üzere tüm kuralları listeler.

ipfw -d -e list : Expire olmuş dinamik kuralları listeler.

ipfw show : Kuralları, sayaçlarla birlikte listeler.

ipfw zero : Sayaçları resetler.

ipfw resetlog : Log sayaçlarını resetler. (kernelinize, options IPFIREWALL_VERBOSE_LIMIT=200 satırını eklediyseniz ya da logamount ile loglanacak kurallar için satır sınırlaması yaptığınız zaman bu komut oldukça işinize yarayacaktır.)

Söz dizimi ve temel komutlar bu şekildeydi.

Şimdiki aşamada örnek olması açısından kendi kurduğum IPFW konfigurasyonu ve açıklamalarına değinmek istiyorum.

Öncelikle Firewall için kurduğum FreeBSD’nin kerneli’ni aşağıdaki parametrelerle yeniden derledim. Kernel derlemek adetimdir

options         IPFIREWALL
options         IPFIREWALL_VERBOSE
options         IPFIREWALL_VERBOSE_LIMIT=200
options         IPFIREWALL_FORWARD
options         IPDIVERT
options         DUMMYNET
options         IPSTEALTH

Serverın gateway olarak kullanılması ve açılışta firewall’un devreye girerel kuralların sisteme tanımlanması için /etc/rc.conf dosyasına  aşağıdaki  satırları ekledim.

gateway_enable="YES"
firewall_enable="YES"
firewall_script="/etc/ipfw.rules"
firewall_logging="YES"
tcp_drop_synfin="YES"

/etc/ipfw.rules isimli bir script dosyası yaratarak içerisine kurallar ile ilgili tanımlamaları girdim.
Script dosyasının örnek içeriği şu şekilde.

# FW Listesini sil..
ipfw -q -f flush

# Prefixler 

lanif="fxp0"
wanif="fxp1"
lan="192.168.0.0/24"
cmd="ipfw -q add"
log="log logamount 200"

#KURALLAR
$cmd 00010 allow all from any to any via lo0
$cmd 00020 allow all from $dmz to $lan
$cmd 00030 allow all from $lan to $dmz
$cmd 00040 check-state
$cmd 00050 allow tcp from 192.168.0.199 to me 22 setup keep-state

Şimdi açıklamalar.

Bu yapıda FreeBSD restart olduğu zaman rc.conf dosyasında belirtilmiş olan script dosyası çalıştırılıyor ve kural tanımlamaları otomatik olarak yapılıyor. Yazının başında kurallar için izlenebilecek iki yöntem olduğunu bahsetmiştim ve ikinci yöntem olan script ile kural tanımlamanın daha iyi bir yol olduğunu, çünkü kural tanımlamalarında yapılan değişikliklerden sonra sistemi reboot etmeye gerek kalmadığını söylemiştim.

Herhangi bir ayar değişikliği yapmanız durumunda, yeni ayarlar için script dosyasını çalıştırmanız yeterlidir.

sh /etc/ipfw.rules

Yukarıdaki örnek script dosyasının içeriğine dair açıklamalar ise şöyle;

ipfw -q -f flush
Daha önceden eklenmiş kuralları siler.

Prefixler:
Script dosyasına bir kural eklerken işin tembelliğine kaçmak için güzel bir yol. Örnekte gördüğünüz gibi kendi network kartlarınızı ve ip networklerinizi prefix olarak ekleyebilirsiniz. Ayrıca ipfw -q add ve log logamount komutunu da ekleyip, kural tanımlamasında $lan vs. gibi bu prefixleri kullanabilirsiniz.

$cmd 00010 allow all from any to any via lo0
Bu kural ile Firewall’un loopback interfaceindeki işlemlerin hepsine izin vermiş oluyoruz.

$cmd 00020 allow all from $dmz to $lan
$cmd 00030 allow all from $lan to $dmz
DMZ’ten LAN’a, LAN’dan DMZ’te gidiş geliş full erişim sağlayan stateless kural.

$cmd 00040 check-state
Daha önceden oluşturulmuş dinamik rulların kontrol edilmesini sağlayan tanımlama. (Stateful)

$cmd 00050 allow tcp from $lan to me 22 setup keep-state
LAN’dan gelip Firewall’un 22.(SSH) portuna erişmek isteyen paketler için izin veren stateful kural.

Bu örnek script dosyası ile firewall’a SSH ve LAN DMZ arası trafik için izin verdik. Firewall closed olarak çalıştığı için geri kalan herşer yasaklı durumda. Gördüğünüz gibi yukarıdaki 00040 ve 00050 numaralı kurallar stateful. Bu kurallarda geçen stateful firewalling için kullanılan kelimelerin anlamlarına bakarak bu mimari konusunda daha iyi fikir sahibi olabiliriz.

keep-state :
0005o numaralı kuralda geçen keep-state ibaresi bu kural ile eşleşen paketler için birer dinamik kural oluşturulmasını söylüyorlar. Yani siz LAN’dan firewall’un 22. portuna doğru bir bağlantı açarsanız şu şekilde bir kural oluşturulur.

00050    158    18403 (300s) STATE tcp 192.168.0.254 7313 <-> 192.168.0.1 22

SSH bağlantısı kurdunuz ve dinamik rule oluşturuldu. Artık sizin ip’niz ve source portunuz ile serverin 22. portu arasında tcp trafiğine izin veren bir kural oluşmuş bulunuyor. Kuralın lifetime’ı süresince -ki birazdan lifetime konusunda değineceğim.- ilgili kural sistemde tanınımlı olarak bulunacaktır. 00040 numaralı kural, daha önceden oluşturulan dinamik kuralları check et manasına geldiği için bu tcp bağlantısında giden gelen paketler, dinamik kural ile eşleşecek ve izin verilecektir.

Oluşturulan her dinamik kuralın bir lifetime’ı bulunmaktadır ve süresi biten kurallar sistemden silinir. Lifetime’lar ise paket içeriklerine göre sysctl variable’larıyla belirlenir. Default olarak tanımlanmış bu variableları görmek için aşağıdaki komutu kullanabilirsiniz.

# sysctl -a | grep 'dyn.*lifetime'

Default değerler şöyledir.

net.inet.ip.fw.dyn_short_lifetime: 5
net.inet.ip.fw.dyn_udp_lifetime: 10
net.inet.ip.fw.dyn_rst_lifetime: 1
net.inet.ip.fw.dyn_fin_lifetime: 1
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_ack_lifetime: 300

Yukarıdaki dinamik rule örneğinde lifetime olarak belirlenen  (300s), açılan oturum için gerçekleştirilen three-way handshake işleminin son adımı olan, client tarafından servera gönderilen ACK paketinden kaynaklanmaktadır. Yani client olarak siz servera bir ACK paketi gönderdiniz ve oturumu açmış oldunuz. Bu durumda firewall sizin bağlantınız için ömrü 300 s olan bir dinamik rule oluşturdu. Söz konusu olan işlem SYN paketi içeren bir bağlantı isteğine ait olsaydı kuralın lifetime’ı 20 saniye olacaktı. Çıktıda gördüğünüz gibi UDP bağlantılar için 10 saniye süre belirlenmiş durumda. short_lifetime değeri ise ICMP paketleri için kullanılıyor.

setup :
Yukarıda, three-way handshake işleminden bahsettim, setup’in tam olarak ne işlevi olduğunu idrak etmek için bu handshake olayına da değinmek gerekiyor. Normalde bir yerden bir yere bir tcp bağlantısı kurmak istediğiniz zaman gerçekleşen adımlar şöyle:

1 – Client bligisayar, bağlantı kurma isteğini belirtmek için bir SYN (Synchronization) paketi gönderir.
2 – Server SYN paketini aldığını belirtmek üzere cliente bir ACK (Acknowledge) paketi ve bir SYN paketi gönderir. (ACK+SYN)
3 – Son adım olarak client, servera bir ACK paketi gönderir ve oturum başlatılmış olur.

Dolayısı ile bu three-way handshaking işlemi bir oturum açmak üzere izlenmesi gereken bir durumdur. Aksi data transferi için bir oturum açılamaz. İşte stateful bir mimari, yukarıda bu konu ile ilgili kısa bilgi verdiğim bölümde de söylediğim gibi bu oturum durumlarını inceleyerek usulsüz bir durum oluşması durumunda gelen paketi otomatik olarak engelleyebilir. Setup ibaresi bu durumu göz eder ve mesela eğer bir SYN/ACK paketi bir oturumun devamı olmaması durumunda engellenmesini sağlar. Ya da bağlantı isteğinin nereden başlatılması gerektiğini belirleyebilir ve aksi durumlarda engellenmesini sağlayabilir. Bu ifade TCP flaglarının kullanımından da anlaşıldığı üzere sadece tcp bağlantılar için oluşturulan kurallar da kullanılmaktadır.

check-state, keep-state ve setup ifadeleri kullanılarak oluşturulmuş güzel bir örnek var. Bu örnek üzerenden ifadelerin çalışma prensibini inceleyelim.

$cmd 01000 check-state
$cmd 02000 allow tcp from any to any 22 in setup keep-state

Firewall closed modda çalışıyor ve bu iki kural tanımlanmış durumda. Bu senaryoya göre, firewall’a hedef portu 22 olan bir paket ulaştığı zaman oluşacak işlem adımları şu şekilde.

1 – 172.16.0.1 ip adresli bir bilgisayarın 1234 numaralı portundan, firewall’un arkasında bulunan 192.168.0.1 ip’li bir serverın 22. portuna erişmek üzere legal bir bağlantı isteği (SYN) içeren bir paket geliyor.

2 – 01000 numaralı kural, dinamik ruleları check eden kural olduğundan dolayı kaynağı  172.16.0.1:1234 ve hedefi 192.168.0.1:22 olan hanhangi bir dinamik rule olup olmadığını kontrol ediyor ve daha önce böyle bir bağlantı kurulmamış olduğundan bulamıyor.

3 – Dinamik bir rule bulunamamasından dolayı arama işlemi 02000 numaralı kuraldan devam ediyor. Paket bu kuralda kontrol ediliyor ve eşleşme sağlanıyor. Ayrıca kuralın söz diziminde “keep-state” ifadesi kullanıldığı için bu bağlantı için 20 saniye lifetime’ı olan dinamik bir kural oluşturuluyor. (daha önce bahsettiğim gibi SYN paketleri için default sysclt variable’i 20 saniyedir.)

4 – Şimdiki aşamada, Server, cliente onay niteliğindeki bir ACK paketini gönderiyor.(Ayrıca bir de SYN paketi gönderiyor.)

5 -  Normal şartlarda client, serverdan gelen SYN paketini aldığını belirten bir ACK paketi gönderiyor. Bu paket firewall’a ulaştığı zaman tekrar arama işlemi yapılıyor 01000 numaralı kural dinamik ruleları check ediyor ve paket daha önce oluşturulan ve lifetime’ı bitmemiş dinamik rule ile eşleşiyor ve paket firewall üzerinden geçiriliyor. Bu durumda da oturum başlatılmış oluyor.

6 – Eğer 5. adımda client tarafından gönderilen ACK paketi spoof edilmiş olsaydı ve firewall stateless olarak çalışsaydı, spoof edilen paketin geçişine izin verilecekti.

7 – Ama 5. adımda gönderilen ACK paketi spoof edilerek gönderildi ve firewall stateful kurallarımız var. Bu durumda ilgili paket firewall’a geldiğinde 01000 numaralı kural, dinamik ruleları kontrol edecek, ancak herhangi eşleşen bir kayıt bulamayacak. Zira spoof edilmiş paketlerin hedef ip ve portu aynı olmasına rağmen kaynak ip ve portu atakta bulunan kişiler tarafından değiştirilir. Bu durumda 01000 ile eşleşmeyen paket için arama bir sonraki kuraldan devam edecektir.

8 – 02000 numaralı kurala gelen paket, içerisinde SYN flagi içermediğinden dolayı bu kural ile de eşleşmeyecektir. (Zira bu kuralda setup ifadesini kullandık ama bu paketin içeriğinde SYN değil ACK paketi var ve kaynak ip ve portu elimizdeki dinamik ruleda belirtilen kaynak ip ve port numarası ile uyuşmuyor.) Haliyle arama işlemi bir sonraki kuraldan devam edecek.

9 – Firewall closed olduğu ve 65535 numaralı son kuralımız herşeyi yasaklıyor olduğundan dolayı spoof edilen paket bu kurala takılacak ve sistemden geçirilmeyecektir.

Böylece, stateful mimari kullanan iki adet rule ile bir spoof atağı kesmiş olduk. Ancak elbette IPFW ile DoS atakları kesme konusunda belli bir oranda başarı sağlayabilrisiniz. Zira çok yüklü miktarda istek geldiği zaman başetmek de o oranda zorlaşacaktır ki DoS atakların temeli, çok hızlı ve fazla sayıda istekte bulunarak karşı tarafın kaynaklarını tüketmekten ibarettir. Ayrıca her türlü DoS atağı kesmek de pek mümkün değildir.

established :
Son olarak, yukarıdaki örnekte geçmeyen ancak stateful mimarisinde kullanılan “established” ifadesine de değinmek istiyorum. Daha önceden kurulmuş olan bir oturuma ait paketlere default izin vermek için kullanılan established ifadesininin geçtiği kuralın söz dizimi şöyledir.

$cmd 00500 allow tcp from any to any established

Bu kural daha önceden kurulmuş bağlantılara ait paketlerin geçişine izin veren genel geçer bir durum olduğundan dolayı, hedef ve kaynak any olarak kullanılmaktadır. Ancak bir önceki spoof edilmiş paket ile ilgili anlatılan örnekte, eğer bu kuralı da kullanmış olsaydık, spoof edilmiş ilgili paket SYN içermemesine rağman, zaten kurulmuş bir bağlantıya ait olduğu gerekçesi ile 00500 tarafından sistemden geçirilecekti.

Stateful ve Stateles firewalling konusuna değindikten sonra, biraz da IPFW’nin trafik limitleme ve kullanım kolaylığı sağlayarak çok işe yarayan table kullanımıyla ilgili örneklere yer vermek istiyorum.

Pipe :

Mesela, kullanıcılarınızdan bazıları tüm interneti download etmek için yanıp tutuşuyor ve internete çıkmak için kullandığınız hatlarda hep bir satürasyon durumu yaşıyorsunuz. Bu durumda bazı kullanıcılar, servisler vs. için bandwidth limitleme ihtiyacı hissedebilirsiniz. Bu işlem için firewallunuza pipe ifadesi içeren rulelar girmeniz ve istediğiniz tipteki trafik için limitleme yapmanız gerekecektir. İşte bir torrent yazılımının kullandığı portlar için uygulanan bir limitleme işlemine ait kurallar.

$cmd pipe 1 tcp from $lan to any 43871
$cmd pipe 2 udp from any to $lan 20228
ipfw pipe 1 config bw 1024Kbit/s
ipfw pipe 2 config bw 512Kbit/s

1. satır lokal networkten, bir torrent yazılımının download için kullandığı 43871 numaralı porta doğru olan tarfik için bir pipe tanımlamasından ibaret.

2. satır ise, aynı torrent yazılımının upload için default olarak kullandığı 20228 numaralı port için pipe işlemi.

3. satırda, torrent download için 1Mbit sınırlama getiriliyor.

4. satır ise torrent upload için 512Kbit sınırlama getiren tanımlama.

Table :

Kaynak adresi ya da hedef adresi birden cok ip’den olusan kurallar girmeye ihtiyacınız olabilir. Normalde bu işi subneting ile yapmak mümkün. Ama bir server farmınız olduğunu ve bu farmdaki serverların bazıları için uygulanacak ortak bir kural girmeniz gerektiğini ancak ilgili serverlara ait ip adreslerinin ardaşık ve subneting ile ifade edilemeyecek adresler olduğunu düşünelim. Bu durumda her bir server için bir kural tanımlamak mi gerekiyor ? IPFW’nin table özelliğini kullanırsanız hayır.
Aynı şey birden çok ip networkü tanımlamak için de geçerlidir.

İşte şöyle.:

ipfw table <tablo_numarası> add <Ip adresi ya da (ip network/subnet)>

Eklemek istediğiniz ip adresi ya da networkleri bu komut ile bir tabloya atayabilirsiniz. Sonra ipfw’ye

ipfw add 00500 allow all from “table(0)” to any keep-state

gibi bir kural girip 0 numaralı tablo içerisinde bulunan tüm ipler için tek kural ile tanımlama yapabilirsiniz. Sisteme 0 ile 127 aralığında ancak 128 adet tablo ekleyebilirsiniz. Tablo kullanımı ile ilgili diğer temel kurallar ise şöyle;

Tablodaki kayıtları görmek için:
ipfw table <tablo_no> list

Tablodan bir kayıt silmek için:
ipfw table <tablo_no> delete <ip adresi ya da (ip network/subnet)>

Herhangi bir tabloyu sıfırlamak.
ipfw table <tablo_no> flush

Tablo kullanımı ile ilgili dikkat edilmesi gereken bir şey var. Tablolarınızı ilgili komutları vererek oluşturup, table ifadesi içeren kurallarınızı yazdınız. Herşer serverı ilk reboot edişinize kadar güzel çalışacaktır. Ancak reboottan sonra tablo kayıtları uçacağı için yazdığınız kurallar bir şey ifade etmeyecektir.

Bu durumu aşmanın yolu ise, açılış sırasında (firewall kurallarının eklenmesi gibi) tabloların da sisteme eklenmesini sağlamaktır. Ben bu iş için gene bir script dosyası kullanıyorum.

/etc/ altında ipfw.tablolar isimli bir dosya açın ve tablo tanımlarınızı girin; mesela şöyle.

Bu dosya gördüğünüz gibi önce eski tabloların içeriğini siliyor; sonra ekleme işlemlerini yapıyor.

Daha sonra, sistem açılışında çalışığ, fw kurallarını otomatik olarak tanımlamak için rc.conf dosyana yazdığımız  ipfw.rules dosyasının içerisine (kural satırlarından önce)  /etc/ipfw.tablolar satırını girin. Bu şekilde, sistem açılırken ipfw.rules dosyası çalışacak ve ipfw.tablolar scriptini çalıştırarak tabloları oluşturacak ve kuralları devreye alacaktır.

Not: Eğer table kullanımında, ilk önce tabloları flush etmezseniz ya da daha script içerisinde ayni ifade iki kere geçerse, bu nedenle hata alır ve sorun yaşarsınız. bu konuya dikkat etmeniz iyi olur

IPFW ile ilgili kurulum notları, açıklamalar ve örnekler bu kadar. Bu yazının ikinci bölümünde IPFW kullanarak divert ile snort_inline kurulumu ve konfigurasyonuna ait notları paylaşacağım.

Bkz:  http://blog.cagriersen.net/2008/07/snort_inline-kurulumu/

Kaynaklar:

http://www.freebsd.org/doc/en/books/handbook/firewalls-ipfw.html
http://en.wikipedia.org/wiki/Ipfw
http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO
http://www.enderunix.org/docs/ipfwbook/
http://www.enderunix.org/docs/ipfw/

Bir SSH bağlantısını, bağlanılmak istenen sisteme direk olarak kullanıcı adı ve şifre göndermek sureti ile gerçekleştirebildiğimiz gibi bağlantıyı SSH Key-Based Authentication isimli yöntemle kullanıcı adı ve şifreye gerek kalmaksızın sağlayabiliyoruz. Yönetiminden sorumlu olduğunuz birden çok *nix tabanlı serverınız olması durumunda Key-Based kimlik doğrulama yöntemi elbette işleri epey kolaylaştırıyor.

Bu yöntemde, uzaktaki sisteme bağlantıda bulunacağınız bilgisayarda public ve private key diye tabir edilen iki adet anahtar dosyası oluşturuyorsunuz, Public Key uzaktan erişim sağlanacak hedef bilgisayarda tutuluyor ve Private Key de, key’i oluşturduğunuz bilgisayarda kalıyor.  Kullanıcı private key’ini kullanarak bağlantı isteğinde bulunduğu zaman hedef bilgisayar gelen isteği elindeki public key ile karşılaştırıp doğruluyor bağlantıyı gerçekleştiriyor. Bağlantı sırasında bilmeniz gereken tek şey keyleri oluşturma sırasında belirlenen Passphrase denilen private key şifresi oluyor. Hatta isterseniz Passphrase dahi kullanmayabilirsiniz. Bu uygulamayı *nix tabanlı sistemlerinizde yaptığınız zaman uzaktan erişim işlemlerinde herserverin kullanıcı adı ve şifresini teker teker girmenize gerek kalmıyor.

Ancak, elbette bu uygulama tahmin edebileceğiniz gibi bazı güvenlik açıklarına neden olabiliyor; bu yazının ana konusu da aslında bu.

Key-Based Authentication kullanışlı olmasına rağmen aynı zamanda sistem güvenliğinizin yumuşak karnı da olabilecek bir potansiyele sahiptir. Zira client bilgisayarda bulunan bir private key başkalarının eline geçerse aynen sizin gibi o kişiler de sistemlerinize kullanıcı adı ve şifre olmaksızın bağlanabileceklerdir.

Bunun yanı sıra aslında bu bu yazıyı yazmamın ana nedeni yukarıdaki yumuşak karın mevzusundan çok, US-CERT tarafından 26 Ağustos’ta açıklanan, Linux Tabanlı işletim sistemleri için, key-based erişim uygulamasında keşfedilen bir saldırı yöntemi.

http://www.us-cert.gov/current/index.html#ssh_key_based_attacks adresinde yayınlanan rapora göre, Linux tabanlı sistemlerde SSH Key-Based authentication kullanılması durumunda ortaya çıkabilecek yeni bir saldırı şekli tespit edilmiş. Buna göre saldırı şekli, ilk olarak SSH keyleri çalarak sisteme login olunup, sonrasında lokal kerneldeki zayıflıklardan yararlanılarak root erişiminin sağlanmasıymış. Root olarak sisteme erişildikten sonra ise sisteme “phalanx2″ isimli bir rootkit kurulduğu söyleniyor.

Raporda, Phalanx2′nin amacının sistematik olarak, -key-based auth. konfigurasyonları nedeni ile- güvenilir olarak algılanan diğer sistemlerin SSH keylerini çalmak ve atakta bulunan kişiye göndermekten ibaret olduğu açıklandı. Böylece attacker bu keylerle, ilgili tüm sistemlere erişimde bulunmayı deneyerek sonuca ulaşmaya çalışıyormuş.

Sisteminizde bu rootkitin yüklü olup olmadığını anlamak için aşağıdaki adımlar işinize yarayabilir.

• rootkit /etc/khubd.p2/ dizininde bulunabiliyormuş. Ancak ls komutu ile bu dizini görmek mümkün değil; bu nedenle cd komutu ile dizinin içerisine girmek gerektiği söyleniyor.
• /dev/shm/ dizini altında atakla ilgili dosyaların bulunabileceği belirtiliyor.
• Ayrıca sistemde çalışan gizli bir proses olup olmadığının araştırılması,
• /etc’nin alt dizinlerini count ederek adet bilgisini “ls /etc” çıktısında belirtilen rakamla tutup tutmadığının kontrol edilmesi öneriliyor.

Hal böyle olunca bu ataktan etkilenmemek için, Key’lere muhakkak Passphrase tanımlamak, Tcp erişimlerini gözden geçirmek, sisem patchlerini düzenli geçmek gibi önlemler almak gerekiyor. Hatta belki de key-based authentication yöntemini rafa kaldırmak en iyisi gibi görünüyor.

wget http://www.ni.net.tr/dosya/Linux/Bit…cc29x.i586.rpm

işlem bittikten hemen sonra rpm dosyamızı install edelim

rpm -i BitDefender-Console-Antivirus-7.0.1-3.linux-gcc29x.i586.rpm

Hata verirse herhangi bir paketin yüklü olmadığını söylerse yum -y ile hata veren paketi install yada upgrade edelim…

Hatasız bir şekilde yüklendiyse nasıl kullanacağınızı biraz anlatayım

bdc –update

Yukarıda yer alan komut ile öncelikle virüs veritabanını güncelliyoruz..

bdc –files /home

yukarıda yer alan ise –files sonrası yazılan dizinde tarama yapar bunu özelleştirebilirsiniz örneklersek /home/kullaniciadi/public_html gibi..

bdc –delete silincek dosya yolu

üst kısımda yer alan komut ilede listelenen virüslerin dizinlerini –delete den sonra yazarak silme işlemini yapabilirsiniz.

Yükleme Sırasında hata alırsanız sırasıyla şu komutları uygulayın ve yüklemeyi tekrar deneyin :

yum -y install libstdc++-libc6.2-2.so.3

rpm -i BitDefender-Console-Antivirus-7.0.1-3.linux-gcc29x.i586.rpm

rpm -Uvh BitDefender-Console-Antivirus-7.0.1-3.linux-gcc29x.i586.rpm

Daha sonra burada “PHP open_basedir Tweak” bölümünde en başta yer alan Enable php open_basedir Protection. seçeneyini aktif yaparak Save butonuna basınız..

Daha sonra aynı bölümden (Security Center) “mod_userdir tweak” bölümüne geçiş yaparak Enable mod_userdir Protection. seçeneyini aktif yapıp Save butonuna basıyoruz.

sunucumuzda Zend kurulu ise

/usr/local/Zend/etc/php.ini

bölümünde bulunan php.ini dosyamızı açıyoruz (Zend dışında farklı bir modül kurulu ise veya hiçbir modül kurulu değil ise php.ini yolunu ” <?php phpinfo() ?> ” bu php kodu ile bulabilirsiniz)

nano /usr/local/Zend/etc/php.ini

php.ini dosyamızda yer alan safe_mode bölümünü On yapıyoruz.. ve sonra yine php.ini içinde yer alan disable_functions karşısına = işaretinden sonra bir alt satıra inmeksizin alt kısımda yer alan kodları yazıyoruz.

restore_ini,glob,hopenbasedir,f_open,system,dl,pas sthru,cat,exec,popen,proc_close,proc_get_status,pr oc_nice,proc_open,escapeshellcmd,escapeshellarg,sh ow_source,posix_mkfifo,mysql_list_dbs,get_current_ user,getmyuid,pconnect,link,symlink,pcntl_exec,ini _alter,parse_ini_file,leak,apache_child_terminate, posix_kill,posix_setpgid,posix_setsid,posix_setuid ,proc_terminate,syslog,fpassthru,stream_select,soc ket_select,socket_create,socket_create_listen,sock et_create_pair,socket_listen,socket_accept,socket_ bind,foreach,socket_strerror,pcntl_fork,pcntl_sign al,pcntl_waitpid,pcntl_wexitstatus,pcntl_wifexited ,pcntl_wifsignaled,pcntl_wifstopped,pcntl_wstopsig ,pcntl_wtermsig,openlog,apache_get_modules,apache_ get_version,apache_getenv,apache_note,apache_seten v,virtual

php.ini dosyamızı kaydediyor ve apache’yi yeniden başlatıyoruz

/etc/init.d/httpd restart

bununla beraber R57.php yi önlemiş bulunuyoruz C99.php için Mod Security’ye ihtiyacımız olacak bunun için WHM den Mod Security kurulumu yapmamız gerekiyor WHM panel de Cpanel bölümü altında yer alan “Plugins” bölümüne giriyor ve Mod Security’yi seçip kaydediyoruz kurulum bitince whm panelden çıkıp tekrar giriyoruz kurulumun sorunsuz şekilde olup olmadığını En alt kısımdan görebiliriz menü olarak “Mod Security” bölümünün gelmiş olması gerek.

sonrasında ssh dan işlemlerimize devam ediyoruz..

cd /usr/local/apache/conf/
rm -rf modsec.conf
wget www.ni.net.tr/dosyalar/modsec.conf.txt
mv modsec.conf.txt modsec.conf

yukarda yer alan komutları sırası ile yaptıktan sonra tekrar apache’yi restart ediyoruz

/etc/init.d/httpd restart

ve modsec.conf sayesinde c99.php’yi de önlemiş oluyoruz..

SYN (TCP bağlantı isteği), aşağıdaki karakteristiklere sahip çok yaygın bir DoS saldırısıdır:

1. Saldırgan Internette kullanılmayan IP adreslerini aldatma ile kullanarak (kaynak adresi olarak kullanarak – spoof) birçok SYN paketini hedef makinaya yollar.

2. Alınan her SYN pakedi için, hedef makina kaynak ayırır ve onay paketini (SYN-ACK) (SYN pakedinin yollandığı) kaynak ip adresine yollar.

3. Hedef makina, saldırı yapılan makinadan yanıt alamayacağından dolayı, SYN-ACK paketini 5 kez tekrar edecektir. Bunun tekrar süreleri, 3, 6, 12, 24 ve 48 saniyedir. Ayırdığı kaynağı boşa çıkartmadan evvel, 96 saniye sonra son bir kez SYN-ACK denemesi yapacaktır. Hepsini topladığınızda, görüldüğü gibi hedef makina ayırdığı kaynakları 3 dakika gibi bir süre tutacaktır. Bu sadece her bir SYN atağı için gerçekleşecek süredir.

Saldırgan bu tekniği tekrarlanan bir şekilde gerçekleştirdiği zaman, hedef makina ayırdığı kaynaklardan dolayı kaynak yetersizliğine kadar ulaşır ve artık yeni bir bağlantı karşılayamayacak duruma gelir. Ve bu durumda yetkili kullanıcılar bile makinaya bağlanamaz.

Sisteminizde böyle bir atakla karşı karşıya olup olmadığınızı anlamak için, komut satırında :

netstat -n -p tcp

yazmanız yeterli olacaktır. Çıkan sonuca bakıp, SYN_RECEIVED durumunda olan çıkışları kontrol edebilirsiniz. Eğer bu tip duruma sahip birçok bağlantı varsa, sisteminiz bu saldırıya maruz kalmıştır.

Sisteminizi korumak için: Ateş duvarları (firewall) tabii ki sisteminizi bu tip saldırılardan koruyacaktır, ve eğer mümkünse ateş duvarı kullanmanız gerekmektedir. Fakat, windows da hali hazırda zaten bu saldırılara karşı korunmanın bir yolu mevcuttur ve SYN isteklerini daha çabuk zaman aşımına uğratabilirsiniz. Bu özelliği çalışır duruma getirebilmek için izlenmesi gereken adımlar şunlardır:

1. Registry editörünüzü çalıştırın ve HKLM(HKEY_Local_Machine)/SYSTEM/CurrentControlSet/Services/TcpipParameters değerini bulun

2. Edit menüsünden Yeni bir DWORD değeri oluşturmayı seçin ve

3. Adını “SynAttackProtect” verin.

4. Yarattığınız anahtarın üzerinde çift tıklayın ve değerini “2″ verin..

5. Registry editörünü kapatın ve makinanızı tekrar başlatın.

Burada “SynAttackProtect” değişkeninin kabul edilen başlangıç değeri 0 (sıfır) dır. Ve koruma kapalıdır.

Verilecek “1″ değeri ise en yüksek TCP bağlantı değerine ulaşıldığında (Örneğin; bağlantının SYN_RECEIVED durumu TcpMaxHalfOpen olarak bilinir) ve tekrar ile karşılaşıldığında (Örneğin; TcpMaxHalfOpenRetried) SYN tekrarını ve yönlendirme bellek değerinin bekleme süresini limitler.

Eğer “SynAttackProtect” değeri “2″ olursa, sonuç 1 verildiğindekine benzer olacaktır fakat SYN işlemindeki 3-yollu el sıkışma bitene kadar bekleyen bir geciktirilmiş Winsock notification içerir.

Çünki Windows “SynAttackProtect” değerini, “TcpMaxHalfOpen” ve “TcpMaxHalfOpenRetried” da tanımlanan değerlere ulaştığında çağırıp kullanacaktır. Size tavsiyemiz bu iki değeride aynı registry konumunda (HKLMSYSTEMCurrentControlSetServicesTcpipPara meters) oluşturmanız ve değerlerini aşağıdaki gibi girmenizdir.

TcpMaxHalfOpen=100
TcpMaxHalfOpenRetried=80