550 SC-001 Mail rejected by Windows Live Hotmail for policy reasons. Reasons for rejection may be related to content with spam-like characteristics or IP/domain reputation problems. If you are not an email/network admin please contact your E-mail/Internet Service Provider for help. Email/network admins, please visit http://postmaster.live.com for email delivery information and support

diye şikayet etmeye başlarlarlar. Sonra sunucunuzu dnsstuff.com'dan ya da mxtoolbox.com dan spam listelerine girip girmediğine bakmak istediğinizde size 3-5 noktası kırmızı işaretli bir liste çıkar. Yani sunucumuz spam yollamaya başlamıştır. İşte asıl sorun bundan sonra başlar. Sunucuzda bu tip bir durumda yapabileceğiniz bazı işlemleri anlatmaya çalışacağım.

İlk olarak sunucumuzun bu mailleri yollayabilmesinin başlıca iki yolu vardır. Birincisi Exim ile, ikincisi sunucuda çalışan bir script ile. Exim ile yollanıyor ise, sunucuda tanımlı eposta hesaplarından birisinin hacklenmiş olması, hesabın kotasının dolmuş olması ve bu yolla backscatter yapılıyor olması muhtemeldir. Exim ile işimiz, elimizde log olması nedeni ile nispeten kolaydır. WHM üzerindeki "Mail Queue Manager" ile mail kuyruğunu takip edebilirsiniz ve spam olması muhtemel epostaların içini açıp gönderenini  görebilrisiniz. Backscatter konusunda ise yine aynı yolu takip edip bounce mailleri yakalamanız gerekli. Backscatter tekniği basitçe, kotası dolan posta kutularının mesajı reddetmesi ilkesine dayanıyor. Mailin asıl yollanmak istendiği yer, mailin kaynağı gibi size iletiliyor ve siz de red cevabını bu postaya yolluyorsunuz gerçek atan yerine ve giden spam mailin göndereni konumuna düşüyorsunuz. Sunucumuzda SPF kontrolünü aktif etmek bu sorunu çözebiliyor ancak SPF kaydı olmayan birçok domainden de mail akışını engellemiş olabiliyoruz. Bir çeşit trade-off durumu ortaya çıkıyor.

Sunucumuzdan giden spam postaların yakalanması zor kaynağı ise sunucudaki scriptlerdir. Sunucuzdaki herhengi bir kullanıcının upload ettiği basit bir script ile, exim'i bypass ederek istenilen heryere eposta atılabilir. Popülerliği nedeni ile en çok php ile bu tip işlemler yapılmakta. Bu scriptlerin herhangi bir log tutmaması, yani atılıdıktan sonra sunucuda bir iz bırakmaması tespitini zorlaştırmakta. Fakat buna da birkaç çözüm yolu mevcut. Bence en kolay olanlarından birisi, Easyapache ye eklenen MailHeaders özelliği.  Sunucuda kurulu php'ye Easyapache vasıtası ile yapılan bu yama sayesinde, sunucudan php ile giden tüm maillerin başlıkları etiketlenmekte.

X-PHP-Script: www.example.com/~user/testapp/send-mail.php for 10.0.0.1

Bu şekilde etiketlenen mailler, size ya da ISP nizin abuse departmanına şikayet edildiğinde, problemli scripti yakalayabiliyorsunuz. Ayrıca şimdiye kadar denemediğim ancak işe yaraması muhtemel bir yok, iptables'ın user eklentisi. Sunucudan giden bağlantıları, bağlantıyı açan işlemin kullanıcı numarasına göre tasnif edebilen bu eklenti ile sadece Exim'in uid değerini taşıyan işlemlere izin verebilir, diğerlerine izin vermeyebilir, ya da loglayabilirsiniz.

Son olarak birkaç öneri daha. Sunucunuzda ASSP, Spamassasin gibi bir spam koruma, gelen postalarınız için kesinlikle aktif olmalı. Zira sunucuzdan dışarı giden spam maillerin sebebi olabilirler. WHM de son zamanlarda eklenen , her alan adının mail yollarken kendi ip adresini kullanmasını sağlayan "Automatically send outgoing mail from the account's IP address instead of the main IP address" özelliği sunucuzda aktif olsun.  Bu şekilde birden fazla ip adresi kullanıyor ise sunucumuz, sorunu sunucudaki tüm kullanıcılara yansıtmamış olur, sadece problemli ip adresine odaklanmış oluruz. Spamsız günler

X-PHP-Script: www.example.com/~user/testapp/send-mail.php for 10.0.0.1
X-PHP-Script: www.example.com/~user/testapp/send-mail.php for 10.0.0.1

Belki de en önemli özelliklerden birisi, protokolün zorunlu olarak Ipsec kullanması. Şu anda Ipv4 protokolüne istendiğinde eklenebilen şifreleme özelliği, Ipv6 protokolünde zorunlu olarak bulunmakta. Bu artık ağımızdaki snifferlardan korkmamamız gerektiği (!) anlamına gelebilir.

Yeni protokolün en ilginç özelliklerinden birisi ise taşınabilirlik (mobility) özelliği. Bir anlamda ip adresimizi yanımızda taşıyabilmemiz anlamına gelen bu özelliğin detaylarına, diğer özellikleri gibi diğer yazılarımda değinmeye çalışacağım.

Ülkemizde de bu geçiş için çalışmalar hızlanmakta. Bunun en güncel örneği Bilgi Teknolojileri ve İletişim Kurumu tarafından kamu kurumları arasında düzenlenen anket. BTK düzenlediği anket ile kamu kurumlarının Ipv6 yatırımları ve planlarını toparlamaya çalışmakta.

Ipv6 Task Force'un yaptığı araştırmalara göre, bu hızla gidilirse 2011 yılında Ipv4 stoğu tükenecek.  Ripe.ncc'nin açtığı http://www.ipv6actnow.org/ sitesinin girişindeki kapılara yüklenmiş insanları gösteren bu resim sanırım olayın ciddiyetini gayet güzel ifade ediyor.

• Graph-based presentation of current reseller limits and usage.
• Detailed view of each reseller.
• Mail notifications for reseller and sysadmins on limit violations.
• Auto-suspend reseller account.
• Run limit check tasks manually or cron based.
• View task logs.

To download , please use this link. All comments are precious for me. Thank you for comments.

]]> http://www.volkanoransoy.com/virus-bulasan-siteler-ve-gumblar-saldirisi/feed/ 0 http://www.volkanoransoy.com/mysql-sunucu-optimizasyonu/ http://www.volkanoransoy.com/mysql-sunucu-optimizasyonu/#comments Tue, 26 May 2009 20:31:49 +0000 admin http://www.volkanoransoy.com/?p=75 Php ile beraber birçok web scriptinin vazgeçilmez gereksinimi MySQL sunucusudur.  Günümüzde, birçok webhosting sunucusunda , en fazla işlem yükü getiren servis, hiç şüphesiz MySQL servisidir. Özellikle I/O noktasında sunuculara ciddi... Read more

Php ile beraber birçok web scriptinin vazgeçilmez gereksinimi MySQL sunucusudur.  Günümüzde, birçok webhosting sunucusunda , en fazla işlem yükü getiren servis, hiç şüphesiz MySQL servisidir. Özellikle I/O noktasında sunuculara ciddi disk yükleri getirmektedir. Bu sebep ile MySQL servisinin yoğun çalıştığı sunucularda, özellikle disk okuma ve yazma hızlarının ciddi kapasitelerde olması önerilir. Bu tip servislerin optimizasyonunda ve performans noktasında ilk ve en önemli unsur donanım özellikleri olmakta.

Buna karşın, sadece iyi donanım bu gibi servislerin hızlı ve stabil çalışmasını sağlayamamakta.  Servislerin çalışma parametreleri, performanslarını önemli derecede etkilemekte. Her sunucu, üzerinde çalışan uygulamanın karakterine göre, farklı parametrelere gereksinim duyabilir. Şüphesiz MySQL servisine ayar yapabilmek için , bu konuda bilgi sahibi olmak gerekmekte.  Fakat bu işi kısa yoldan çözebilmek için mümkün bazı küçük ipuçlarını sizlerle paylaşmak isterim.

MySQL servisi, ana ayar dosyası olarak /etc/my.cnf dosyasını kullanmakta. Bu dosya içinde, MySQL in çalışmasına etki eden tüm değişkenler tanımlıdır. Sunucumuzun yüküne ve kapasitesine göre, kurulum esnasında gelen bazı hazı ayar şablonları aslında sisteminizde mevcuttur.

root@localhost[~]# ls -an /usr/share/mysql/*.cnf
-rwxr-xr-x 1 0 0  4972 Feb 24 01:14 /usr/share/mysql/my-huge.cnf*
-rwxr-xr-x 1 0 0 20970 Feb 24 01:14 /usr/share/mysql/my-innodb-heavy-4G.cnf*
-rwxr-xr-x 1 0 0  4948 Feb 24 01:14 /usr/share/mysql/my-large.cnf*
-rwxr-xr-x 1 0 0  4955 Feb 24 01:14 /usr/share/mysql/my-medium.cnf*
-rwxr-xr-x 1 0 0  2526 Feb 24 01:14 /usr/share/mysql/my-small.cnf*

Bu dosylardan, sunucunuza uyanı, /etc/my.cnf ile değiştirmeniz, kısa yoldan birçok değişkeni tanımlamanızı sağlayacaktır. Genellikle 4GB ve üzeri RAM bulunan sunucularda my-huge.cnf  uygun görünmektedir.

Bir diğer konfigürason yardımcısı, MySQL Performance Tuning Primer Script adlı küçük bir scripttir. Bu scripti sunucunuza indirip çalıştırdığınızda, size çalışan servise ait istatistikler ile ayar dosyanız arasındaki uyumlu ve uyumsuz noktaları listeleyecektir.

wget http://day32.com/MySQL/tuning-primer.sh
sh tuning-primer.sh

Kırmızı ile belirtilen noktalar, servis istatistikleri ile ayar dosyası arasındaki sorunlu noktaları göstermekte ve önerilerde bulunmaktadır. Bu önerilere göre ayar dosyanızı düzenleyebilirsiniz.

Bunlara ek olarak, bazı performans arttırıcı önerilerim mevcut. Örneğin, eğer geriye dönük data kurtarma işlemi yapmayacaksanız, ayar dosyanızdaki --log-bin parametresini kaldırmalısınız. Bu parametre, binary formatında sql işlemlerini loglamakta. Bu işlem, olası verikayıplarında, geriye dönük verilerin kurtarılmasını sağladığı gibi ciddi bir performans yükü getirmekte sunuculara.  Ayrıca query_cache_size  ve table_cache değerlerini, sunucunuzun limitleri elverdiği kadar yüksek tutmanız, disk yükünü hafifletecektir. MySQL kaynaklı disk yükünü hafifletebilmenin bir diğer yolu da, MySQL tarafından tutulan geçici dosyaların , diskten ziyade RAM de tutulmasını sağlamaktır. Bunu sağlayabilmek için de tmp_table_size ve max_heap_table_size değerlerinin yükseltilmesi iyi olacaktır.

]]>

wget http://garr.dl.sourceforge.net/sourceforge/pyzor/pyzor-0.5.0.tar.gz
tar zxvf pyzor-0.5.0.tar.gz
cd pyzor*
python setup.py install

Şu anda kurulum tamamlandı ve kurulumu şu şekilde test edebiliriz.

pyzor discover

Alacağınız çıktı aşağıdaki gibi ise sorunsuz bir kurulum yapılmıştır.

downloading servers from http://pyzor.sourceforge.net/cgi-bin/inform-servers-0-3-x

Şimdi sıra Pyzor'u Spamassassin'e entegre etmeye geldi. Bunun için /etc/mail/spamassassin/local.cf içine pyzor ile ilgili bir satır eklememiz gerekli. Ardından Pyzor'un etkileşimli olacağı sunucuları bulup ayar dosyasına yazmasını sğlayacağız.

echo "pyzor_options --homedir /etc/mail/spamassassin" >> /etc/mail/spamassassin/local.cf
pyzor --homedir /etc/mail/spamassassin discover

Bu komut işimizi görecektir. Son olarak exim servisini yeniden başlatıyor ve kurulumumuzu test ediyoruz.

/etc/init.d/exim restart
echo "test" | spamassassin -D pyzor 2>&1 | less

Bu komutun sonundaki çıktı, spamassassin'in Pyzor ile beraber "test" kelimesini analiz ettiğini gösterecek. Benim sunucumda, gayet güzel sonuçlar verdiğini söyleyebilirim. Spamsız günler

wget http://members.dslextreme.com/users/andylee/unixbench-4.1.0-wht.tar.gz
gunzip -dvc unixbench-4.1.0-wht.tar.gz | tar xvf -
cd unixbench-4.1.0-wht*
 make
./Run

Intel Xeon E5405 işlemcili,  4GB ramli ve SATA diskli sunucuma verdiği puan aşağıda.

BYTE UNIX Benchmarks (Version 4.1-wht.2)
System -- Linux example.com 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:10:25 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
/dev/sda3            470862840  31056964 415501540   7% /
Start Benchmark Run: Tue May 19 00:20:35 EEST 2009
 00:20:35 up 29 days,  9:25,  1 user,  load average: 0.38, 0.28, 0.20
End Benchmark Run: Tue May 19 00:30:51 EEST 2009
 00:30:51 up 29 days,  9:36,  2 users,  load average: 15.96, 6.98, 3.1
                     INDEX VALUES
TEST                                        BASELINE     RESULT      INDEX

Dhrystone 2 using register variables        376783.7 17168901.4      455.7
Double-Precision Whetstone                      83.1     1448.4      174.3
Execl Throughput                               188.3    10323.9      548.3
File Copy 1024 bufsize 2000 maxblocks         2672.0   177180.0      663.1
File Copy 256 bufsize 500 maxblocks           1077.0    49710.0      461.6
File Read 4096 bufsize 8000 maxblocks        15382.0   953573.0      619.9
Pipe-based Context Switching                 15448.6   917224.5      593.7
Pipe Throughput                             111814.6  2664563.7      238.3
Process Creation                               569.3    31956.8      561.3
Shell Scripts (8 concurrent)                    44.8     2372.0      529.5
System Call Overhead                        114433.5  2282900.7      199.5
                                                                 =========
     FINAL SCORE                                                     418.7

MaxClients : Aynı anda sunucuya kurulabilecek bağlantı sayısıdır. Bu hesabı kabaca RAM miktarınıza göre yapmanızı tavsiye ederim.  Gigabyte başı 100 kullanıcı olarak hesap edilebilir. Şunu da belirtelim ki, aylık ortalama 1 TB veri transferi yapan bir sunucuda bu değer ortalama 75-100 arasında oluşmaktadır.

MaxRequestsPerChild: İşte en belirleyici değişkenlerden birisi. Bu değişken, bir Apache işlevinin sonlandırılıp yeniden başlatılması için kaç isteğe cevap vermesi gerektiğini belirtir. Burada belirtilen sayıya ulaşılınca, bu işlev biter ve sıfırdan tekrar bir işlev oluşur. Bu sayının düşük olması , her seferinde bir işlevin kendini yenilemesi nedeni ile sunucu yükünü arttırır. Fazla olması ise , olası sorunlarda bu işlevlerin kararsız kalmasına neden olabilir.

MinSpareServers ve MaxSpareServers: Adından da anlaşılacağı gibi, Apache'nin yedekte bekleteceği sunucu işlevi sayısıdır. Bu sayıların 5/10 olarak kalması normal kabul edilir. MaxSpareServers ne kadar büyük olur ise, harcanan kaynak o kadar artacaktır.

KeepAlive: Bu değişken de Apache performansına birinci dereceden etki eder. Aşılmış olan oturum, MaxKeepAliveRequests ile belirtilen süre geçmeden kapatılmaz. Bu da özellikle bir siteyi barındıran sunucularda iyi sonuçlar verir. Ancak özellikle paylaşımlı hosting hizmeti veren sunucularda, bu değerin açık olması, özellikle gelen isteklerin dağınık olması sebebi ile olumsuz sonuçlar doğurabilir. Eğer KeepAlive açık ise, MaxKeepAliveRequests in 3-5 gibi düşük değerlere ayarlanması uygun olacaktır.

Yazımızın başında da belirttiğimiz gibi, performans sadece bu değişkenlere bağlı değildir. Bu sebep ileweb sunucunuzun performansını bir bütün olarak düşünmeniz gerekir.

<?
$myfile = fopen ('/etc/passwd', 'r') or die ("Dosyayi acamiyorum!");
while (!feof($myfile)){
$line = fgets($myfile,5000);
print "$line
"; }
fclose($myfile);
?>

Bu scriptin daha komplike olanlarını sizler c99 , r57 gibi isimlere duymuş olabilirsiniz. Php safe_mode, basitçe bu tip sorunların önüne geçmeye çalışan bir mekanizma. Php scriptlerinin, kendisini çalıştıran kullanıcıdan farklı bir kullanıcıya ait olan dosyalara erişimini kısıtlamakta.

Safe_mode ile benzer bir amaca hizmet eden bir başka php mekanizma ise open_basedir dir. Bu direktif ise php derleyicisine, scripti çalıştıran kulanıcının ev dizini haricindeki dosyalara erişmemesini sağlar.

Bu iki direktifin aktif olması ,  paylaşımı sunuculardaki çokça problemi gidermektedir.  Tabi php'nin, php.ini dosyalarını çalışma esnasında değiştirebildiği "ini_set" gibi fonksiyonlarını kapatmazsak, bu değişkenler, scriptin kendisi tarafından değiştirilebilir, devredışı bırakılabilir.

Bu arada, çok önemli bir noktayı atlamamamız lazım ki, hep scripti çalıştıran kullanıcıdan bahsettik, ancak bazı sunucular, özellikle performans kaygısı ile , apache ye gömülü mod_php kullanmaktalar ki bu şekilde çalışan sunucularda, tüm php işlemleri, web sunucusunun kullanıcısı ile çalışmaktadır. Dolayısı ile bu php direktifleri çalışmaz hale gelmektedir.

Tabi tüm bu tehlike, bu şartları sağladığınızda ortadan kalkmıyor. Zira sadece php kısmında alınmış tedbirler bunlar. Cgi desteği olan bir sunucuda, python, perl, bash gibi scriptin dilleri ile aynı işlemler rahatça yapılabilir. Bu programlama dillerinde, php.ini  mantığı olmadığı için, bir seçenek haricinde yapılacak şey yok. Cgi desteğini kapamak

Sonuç olarak, eğer sitenizi kendinize ait bir sunucuda barındıramıyorsanız , güvenliğiniz açısından, size paylaşımlı hosting sağlayan sunucuda  aramanız gereken özellikler:

• php safe_mode un aktif olması
• open_basedir kısıtlamasının aktif olması
• sunucunun suphp olarak çalışması
• cgi desteği verilmemesi

Unutmayın, en güvenli sistem kapalı olanıdır