Kıyamet ertesi

0
conan
Evet hepimiz biliyoruz ki SQ_Hell, Slammer, veya ne isim verirseniz bu kurtçuk Internet'i hafta sonundan itibaren esir aldı. Bizlere fazlamesai yaptırdı, bolbol küfür ettirirken bazı şeylere de dikkatimizi çekmeyi sağladı. Örneğin patch ne demek bir kere daha ögrendik. Ya da geç kalınmış ve tamamen test edilmemiş SP'lerin insanların başına neler getirebildiğini gördük. Ama bunlardan bahsetmeyeceğim. Bahsedeceğim şey neden Internetin bu problemden dolayı durma aşamasına geldiği?
Olay sadece aşırı UDP trafiği miydi? Yoksa onun yanında etkileşimden oluşan yan trafiklerin de bu kıyamette etkisi oldu mu?

Öncelikle aşırı UDP trafiğini biraz açıklamak istiyorum. MSSQL server 1434 numaralı portundan tek bytelik bir UDP paket aldığında (0x0A) bu paketi yollayana aynı paketle aynı porta cevap verir. Bunu bir çesit SQL pingi olarak isimlendirebiliriz. UDP `connectionless´ bir protocoldur (bağlantısız) Yani bir önceki paketten haberdar değildir. A sunucusu B sunucusuna bir SQLping yolladığında B sunucusu da aynı paketle A sunucusuna bu pinge cevap verdiğinde, A sunucusuna ilk pingleyen taraf olduğunu bildiğinden B`den gelen pakete cevap vermez. (Normalde A da aynı paketi aldığına göre cevap vermeliydi değil mi? ;) Peki diyelim ki kötü insan C bu iki SQL sunucusu birbirine düşürmek istiyor. Ne yapıyor? A´dan geliyormuş gibi bir paket yaratıyor ve B´ye yolluyor. (kaynak adresi: A) B ise aynı paketi ping cevabı şeklinde A´ya geri yolluyor, A ise bu durumdan haberdar değil! A da B`nin onu pinglediğini sanıyor ve aynı paketi geri yolluyor, B -> A, A -> B.... bu böyle sunuculardan birisi kapatılana kadar sürüyor. UDP bağlantısız bir protokol olduğundan TCP`den çok çok daha hızlı hareket edebiliyor. Böylece trafik katlanarak çoğalıp network`u doldurmaya başlıyor. (Basit ama gerçek, bu tip problemler 96`dan beri tartışılmakta: www.cert.org/advisories/CA-1996-01.html)

Gelelim yan etkilere. Peki dünya üzerinde SQL sunucu sayısı web sunucu sayısından daha az, neden code red yayılırken Internet durma noktasına gelmedi de bu olayda %95`lere varan ping kayıpları oldu? Bunun asıl cevabı UDP`nin hızlı trafiği olsa da buna bağlı olarak bence bir de SQL hizmeti sunmayan bilgisayarların (1434/1433 UDP port açık olmayan diyelim) geriye döndürdüğü ICMP cevaplarının (port unreachable gibi) routerları doldurup durma noktasına getirmesi de önemli bir unsurdu. ICMP önemli bir trafik. Çünkü birçok routerda üstünlük tanınabilen bir protokol. QoS önemli olduğu network uygulamalarında, ya da genel olarak karşı tarafın durumunun bilinmesinin hayati önem taşıdığı hallerde (VOIP, Video Stream, Finansal iletisim, vs...) ICMP öncelikli pakettir. ICMP paketlerindeki dramatik artış bu tip uygulamaların çalışmamasına sebep olabilir. (Bank of America ATMlerinin durması bu nedenden olabilir)

Evet, günümüzde yanlış yazılmış kodların ve bunların duzeltilmesine rağmen ihmal edilmelerinin önüne geçebildiğimizi, ve de geçebileceğimizi söylemek çok güç. Bu boyle geldi uzun bir süre daha böyle gidecek gibi gözüküyor. Ama hey? bi dakka! böyle gitmezse bizler aç kalırız değil mi? ;) (Işler böyle gitmesin, ben aç kalmaya razıyım)

Mini kaynakça:
Unauthenticated Remote Compromise in MS SQL Server 2000
CERT® Advisory CA-1996-01 UDP Port Denial-of-Service Attack
Sapphire worm code disassembled (eEye Digital Security: Jan 25, 2003)

Görüşler

0
sundance
Valla eline sağlık Conan, böyle yazılar gördükçe ulan iyi ki FM var, iyi ki böyle insanları tanıyorum diye seviniyorum :)
0
Nightwalker
>Valla eline sağlık Conan, böyle yazılar gördükçe ulan iyi ki FM var, iyi ki böyle insanları tanıyorum diye seviniyorum :)

Ehu... Burdan kendimize pay mı çıkartıyoruz sundance ? :)
Ama bu payı çıkartmakta bütüm FM ekibinin hakkı galiba :)
Bu arada yazı güzel olmuş conan , eline sağlık...
0
conan
once senin aklina gelseydi de sen de kendine pay cikarsaydin ;) Tabii ki pay cikaracak adam, FM ekibinden once boyle bir olusum var miydi? yoktu! :)

>Bu arada yazı güzel olmuş conan , eline sağlık...
Bu arada tesekkurler :)
0
tongucyumruk
Conan! yazılarının kalitesini düşür, çıtayı çok yükseltiyorsun affetmeyiz sonra...

--
Makale Mafyası
0
cazz
Evet ne demisler (kim demis? ;) ) ceken bilir!
Conan'cim eline saglik, kufur ede, kufur ede! cildirmadan icini bosaltmissin! helalinden :)

eline agzina parmaklarina saglik!
0
FZ
Bir sürü İngilizce makale okudum şu SQLSlammer ile ilgili, %80´i posa idi; sonra bilgisayarı açtım, FM sitesine bağlandım, anadilimde yazılmış ve tam da olması gereken teknik seviyedeki bu makaleyi okudum, aydınlandım.

FM sitesini takip etmenin faydasını, ayrıcalığını bir kez daha yaşadım. Bu arada SQLSlammer ile ilgili ilk haberi FM sitesinden aldığımı söylememe bilmem gerek var mı (pek çok arkadaşım da ilk kez buradan öğrendiğini söylüyor).

Teşekkürler!
0
anonim
itiraf edeyim ki ben okuyup birsey anlayamamistim sagda solda. Simdi aydinlandim
0
conan
once ingilizce makaleleri okuyup sonra FM`ye bakman buyuk hata! ;)

Ben ilk slammeri cep telefonuma yagan sapik otesi alarmlardan ogrendim hehe! servers down! move your @55 system slave!!!
0
anonim
Vallahi bende anlatım diline hayran kaldım. Abi sen linux, programlama yada iyi bildiğin konularda kitap yazsana. :)) Dalga geçmiyorum gerçekten acayip para kazanırsın. :)) Cidden çok güzel basit ve anlaşılır şekilde anlatmışsın açıkçası hayran kaldım.

Sevgi, Saygı, Linux, MySQL
Yüksel ÖZCAN
0
anonim
Her ne kadar ilk basta yayinlanan yazilarda wormun ''karsilikli ping'' acigini kullandigindan bahsedilmis olsa da, Son analizlerde bu DoS etkisinin sadece wormun sonsuz bir dongu icerisinde rastgele IP adreslerine kendisini iceren UDP paketlerini gondermesinden kaynaklandigi ortaya cikti. Bu UDP paketini alan yamanmamis SQL server makineler de ayni sekilde saldiriya basliyorlardi ...
Görüş belirtmek için giriş yapın...

İlgili Yazılar

Açık Sistemler ve Güvenlik - 2

FZ

"Güvenlik de tıpkı doğruluk gibi bir sisteme sonradan eklenebilecek bir özellik değildir." Andrew S. Tanenbaum

Öncelikle bu yazıya başlayıp da 1. bölümü okumamış olanlara durmalarını ve hemen dönüp http://fazlamesai.net/makale.php3?sid=1107 adresindeki 1. bölümü okumalarını tavsiye ediyorum. Oradaki uygulamaları, bilgileri pratik olarak sindirdikten sonra buradan devam edebilirler.

SecureProgramming.com: Güvenli Programlama Teknikleri

FZ

Süper bir uygulama geliştitiriyorsunuz, keskin bir C/C++ (ya da Java, PHP, vs.) programcısı olduğunuzu düşünüyorsunuz, uygulamanızı diğerleri ile de paylaşıyor ve bununla gurur duyuyorsunuz.

Birkaç gün sonra defalarca ıncığına cıncığına dek test ettiğiniz uygulamadaki açıklar SecurityFocus gibi sitelerde yayınlanıyor... Klasik ve kulağa tanıdık gelen bir senaryo değil mi?

Ciddi anlamda uygulama geliştiren ve abuk sabuk güvenlik açıklarına yazılımlarında yer vermek istemeyen programcıların, Secure Programming Cookbook for C and C++ kitabının yazarları tarafından kamuya açılan http://www.secureprogramming.com sitesini ziyaret etmelerinde fayda var.

BugTraq Tarayıcı Testi

Soulblighter

SecurityFocus sitesinde Michal Zalewski tarafından gerçekleştirilmiş bir tarayıcı testi var. Ben de bu testin çevirisini (özetle) burada sunuyor ve yorumlarınızı merakla bekliyorum :)

Çok kullanılan web tarayıcılarının potansiyel saldırılara ve DoS ataklarına ne kadar dayanabildiklerini ölçmek istedim. Bu amaçla kullanışlı bir araç hazırladım.

Biyometrik Güvenlik ve Uygulama Kolaylığı

FZ

Pek çok filmde biyometrik güvenlik ile karşılaşmışsınızdır. Mesela adam kapıya elini koyar ve adamı tanıyan sistem kapıyı açar, kadın asansöre biner ve bir kat numarası söyler ve kadının sesini analiz eden asansör bilgisayarı kadın eğer yetkili ise hareket etmeye başlar veya bir sistemi kullanmaya çalışan kişi karşısındaki kameraya bakar bakmaz sistem iris tabakası şeklini analiz eder ve elindeki eski bilgilerle bir kıyaslama yapar...

Kulağa hoş geliyor değil mi? Yani taşımanız gereken bir anahtar veya akıllı kart yok, hatırlamanız gereken ve zırt pırt unuttuğunuz bir sürü parola, şifre vs. yok. Tamamen sizi bedensel özelliklerinize yani size özgü ve taklit edilmesi nerede ise imkansız işaretlere dayanan güvenlik sistemleri.

Klavyeden Çıkan Sesler Ne Yazıldığını Ele Veriyor

FZ

University of California, Berkeley araştırmacıları klavyede tuşa basarken çıkan sesleri analiz edip hangi tuşlara basıldığını anlamanın yolunu keşfetti.

10 dakikalık bir kaydı dinleyen sistem yazılanların %96sını çözebiliyor.

Bu tekniğin çalışmasının sebebi ise "a" tuşuna basıldığında çıkan sesle, mesela "t" tuşuna basıldığında çıkan ses arasında fark olması. Bilgisayar bilimleri profesörü Doug Tyger yapılan işin bir davulun değişik yerlerine vurulduğunda değişik ses çıkmasının fark edilmesine benzetti.