9.04.2015

Log Parser Studio (LPS)

Çok sevdiğim bir araç vardı: Log Parser. Her türlü log formatını okuyabilen, SQL sorguları ile logların üzerinde işlem yapılmasını sağlayan Microsoft aracı olan Log Parser, artık Log Parser Studio (LPS) olarak görsel bir arayüze kavuştu.

LPS'nin babası olan Log Parser, Exchange Server geliştiricileri tarafından logların incelenmesi amacıyla tasarlanmış bir araç. LPS de bu amaçla büyük işler başarıyor. Ama bununla sınırlı değil. Web server logları, Windows Evet Log'ları hatta başka log formatlarını kolayca okuyabiliyor. Dahası grafikler çizebiliyor.


Varsayılan olarak üzerinde bir çok örnek sorgu ile geliyor. Tek yapmak gereken logları nereden okuyacağını seçmek. Örnek olarak Exchange protokol loglarını (RECEIVE) incelemekle başlayalım. Server üzerinden ilgili loglara ister doğrudan erişebilir, istersek de bu dosyaları sabit diskinizin içindeki bir klasöre kopyalayıp devam edebiliriz. D:\Logs klasörüne kopyaladığımızı düşünelim. Araç çubuğundaki Log butonuna (soldan 5. buton) basarak loglarımızın yerini gösterelim.


Arından yeni bir sorgu yaratma butonuna (en soldaki) basarak pencerenin alt bölümündeki sorgu ekranına şu satırları yazarak başlayalım:
SELECT *
FROM '[LOGFILEPATH]'
WHERE (context LIKE '%LogonDenied%')
Bu şekilde SMTP receive logları üzerinden gelen yanlış kullanıcı adı / parola hatasına sebep olan LogonDenied kayıtlarına ulaşabiliriz. Log tipini seçmeyi unttum. Bunun için de sorgu ekranının hemen üzerinde kalan Log Type bölümünden EELLOG'u seçmek gerek. İstenirse SELECT * yerine daha net alanlar belirtilebilir. Örneğin şöyle bir sorgu sonuçları güzel oluyor:

SELECT ADD(TO_TIMESTAMP(EXTRACT_PREFIX([#Fields: date-time],0,'.'),'yyyy-MM-ddTHH:mm:ss'),SYSTEM_UTCOFFSET()) AS LocalDateTime,
session-id, connector-id, [sequence-number] AS SeqNum, [remote-endpoint] AS RemoteIP, event, data, context FROM '[LOGFILEPATH]'
WHERE (context LIKE 'User Name:%')
Burada SELECT'ten sonra gelen ilk alanda log satırındaki tarih ve saat alanı uygun TIMESTAMP'e çevrilip yerel saate göre ayarlanıyor.

Başka bir örnek olarak WEB sunucu üzerindeki muhtemel SQL injection denemeleri görülebilir:

SELECT TO_TIMESTAMP(date,time) as DateTime, cs-uri-stem as page, cs-uri-query as query, c-ip as RemoteIP, sc-status as StatCode, cs(User-Agent) as UserAgent
FROM '[LOGFILEPATH]'
WHERE ((query LIKE '%--%') or (query LIKE '%@@%') or (query LIKE '%version%') or (query LIKE '%exec%') or (query LIKE '%declare%') or (query LIKE '%cast%') or (query LIKE '%select%') or (query LIKE '%union%') or (query LIKE '%update%')) and (StatCode=200)
ORDER BY DateTime ASC
Burada adres satırıından gönderilen bazı anahtar kelimelerin varlığı denetleniyor. Bu tam bir SQL injection varlığı belirlemesi olmayabilir, ama yine de faydalı bilgiler verir.

Ve en sevdiklerimden biri, domain controller'lar üzerinde oluşan account lockout olaylarının takibi için Security log'da 4625 (hatalı kullanıcı adı/parola) ve 4740 (lockout) olayları aranıyor.
SELECT TOP 100 TimeGenerated, EventID, ComputerName,
EXTRACT_TOKEN(Strings,0,'|') AS Field_0,
EXTRACT_TOKEN(Strings,1,'|') AS Field_1,
EXTRACT_TOKEN(Strings,4,'|') AS Field_4,
EXTRACT_TOKEN(Strings,5,'|') AS Field_5,
EXTRACT_TOKEN(Strings,19,'|') AS Field_19
FROM \\server1\security,\\server2\security
WHERE (EventID=4740 OR EventID=4625)
ORDER BY TimeGenerated DESC
Bu sorgu için Log Type kısmından EVTLOG seçilmeli. Burada FROM'dan sonra '[LOGFILEPATH]' yazmaya gerek yok. Field_0'dan Field_19'a kadar olan alanlar 4625 ve 4740 olayları için önemli olabilecek bazı alanlar içeriyor.

Son olarak bir de FileZilla FTP server logları için olan sorgusu var. FileZilla FTP Server nedense garip bir log formatı seçmiş. Örneğin satırlar şöyle:

(000233) 19.09.2014 23:01:14 - (not logged in) (xxx.xxx.xxx.xxx)> Connected, sending welcome message...
(000233) 19.09.2014 23:01:14 - (not logged in) (xxx.xxx.xxx.xxx)> disconnected.
(000234) 19.09.2014 23:01:22 - (not logged in) (xxx.xxx.xxx.xxx)> Connected, sending welcome message...
(000234) 19.09.2014 23:01:24 - (not logged in) (xxx.xxx.xxx.xxx)> USER zxin10
(000234) 19.09.2014 23:01:24 - (not logged in) (xxx.xxx.xxx.xxx)> 331 Password required for zxin10
(000235) 19.09.2014 23:01:25 - loggedinuser (xxx.xxx.xxx.xxx)> 200 Type set to I
(000235) 19.09.2014 23:01:25 - loggedinuser (xxx.xxx.xxx.xxx)> TYPE A
(000234) 19.09.2014 23:01:26 - (not logged in) (xxx.xxx.xxx.xxx)> QUIT
(000234) 19.09.2014 23:01:26 - (not logged in) (xxx.xxx.xxx.xxx)> 221 Goodbye
(000234) 19.09.2014 23:01:26 - (not logged in) (xxx.xxx.xxx.xxx)> disconnected.

Log dosyaları günlük olarak tutuluyor. Bu durumda yukarıdaki veriyi bir CSV (virgülle ayrılmış değerler) dosyasına yazmak için şu sorgu kullanılabilir:

SELECT SUBSTR(EXTRACT_TOKEN(Text,0,' - '),1,6) as order,
TO_TIMESTAMP(SUBSTR(EXTRACT_TOKEN(Text,0,' - '),9),'dd.MM.yyyy HH:mm:ss') as datetime,
EXTRACT_TOKEN(EXTRACT_TOKEN(EXTRACT_TOKEN(Text,1,' - '),0,'> '),0,' (') as user,
REPLACE_STR(EXTRACT_TOKEN(EXTRACT_TOKEN(EXTRACT_TOKEN(Text,1,' - '),0,'> '),1,' ('),')','') as ip,
EXTRACT_TOKEN(EXTRACT_TOKEN(Text,1,' - '),1,'> ') as message
INTO 'D:\Log\Filezilla.csv'
FROM '[LOGFILEPATH]'

EXTRACT_TOKEN() ve diğer fonksiyonlar hakkında yardım için şu sayfadan yararlanılabilir. Sayfa aslında Log Parser Plus için, ama LPS'ye de uygulanabilir.

Yetenekleri bununla kısıtlı değil. Biraz yaratıcılık, biraz da  deneme yanılmayla herşey mümkün.

15.07.2016 ekleme:
Log Parser Studio'nun bir sürü klavye kısayolu varmış; yeni keşfediyorum. Örneğin her seferinde FROM'dan sonra gelecek ve ayarlanmış log dosyası konumunu belirten '[LOGFILEPATH]' yazmak yerine F7 tuşuna basabilir ve eğer sonuçları bir CSV dosyası olarak export etmek isterseniz F8'e basabilir ve '[OUTFILEPATH]\Output.CSV' ekleyebilirsiniz. Klavye kısayollarının tam listesi için şu sayfa çok faydalı olabilir diye düşünüyordum ama sayfanı sonuna kadar okuyunca farkettim ki aslında Ctrl+K kombinasyonu klavye kısayolları sayfasını görüntülüyormuş :)

23.01.2015

PsPing

Bilişim teknolojileriyle uğraşanlar klasik ping komutunu gayet sık olarak kullanırlar. Hedef bilgisayarın çalışır durumda olduğunu doğrulamak için ICMP protokolünü kullanarak basit bir veri paketi gönderilir ve karşı tarafın da aynı paketi geri göndermesi beklenir. Eğer hedefteki bilgisayar (veya genel anlamda ağ bağlantısına sahip cihaz) açık ve ulaşılabilir bir durumdaysa ping aşağıdaki gibi bir çıktı üretir.


Burada benim bilgisayarım, www.google.com'dan sorumlu sunucuya 4 tane 32 byte'lık bir ICMP verisi gönderdi, karşı taraf da aldığı veriyi geri göndererek ulaşılabilir olduğunu gösterdi. En altta 4 paket gönderip alma işlemi ile ilgili istatistikler var.

Uzun süredir kullanılmakta olan ping komutu ile ilgili bir sorun var; o da ICMP protokolünün kendisiyle ilgili. Bazı sunucular ICMP protokolüne tamamen kapalıdır. Bu durumda hedefteki bilgisayar HTTP veya DNS hizmetlerini vermeye devam etse de ping isteklerine cevap vermez. Bunun sebebi de her konuda olduğu gibi ICMP'de de durumun ping of death veya ping flood gibi bir yöntemlerle suistimal edilmiş olmasındandır. Google bu gibi durumlarda ping ile gönderilen paketlerin belli bir boyutun üzerinde olması durumunda daha küçük paketlerle cevap veriyor. Örneğin -l 1000 anahtarını kullanarak 32 byte yerine 1000 byte'lık bir paket ile Google sunucularına gönderdiğimde bana 64 byte'lık paketlerle cevap dönülür.


Ama yine de ICMP'yi tamamen engelleyen sistemler de var. Örneğin amazon.com:


Bununla ilgili son zamanlarda alternatif yöntemler TCP veya UDP kullanarak hedef sistemin erişilebilirliğinin denenmesidir. Sysinternals Suite ile gelen PsPing aracı da bu çözümlerden biri. Uzun süredir Sysinternals paketlerini kullanıyor olsam da maalesef bu pakete dahil olan PsPing'in varlığını farketmem biraz zaman aldı. Farkeder farketmez de kullanmaya başladım.

Önce standart ping işlemi. ping www.google.com'a eşdeğer komut şu:

psping www.google.com



Bu komut, ICMP'yi kullanıyor. Aynısını TCP ile yapmak istersek tek yapmamız -bir TCP bağlantısından söz etmek için bir port bilgisi olması gerektiğinden- hedefin sonuna :XX ile port numarasını eklemek. Örneğin 80 numaralı HTTP denemesi için:

psping www.google.com:80

demek yeterli.


İkisinin arasındaki fark, 5 ping paketinden sonraki satırda. TCP kullanınca "TCP connect statistics..." yazıyor, görüldüğü gibi.

Daha önce amazon.com'u ICMP ile pingleyememiştik. Bir de TCP ping ile deneyelim.


TCP bağlantısı için herhangi portu seçmek teknik olarak mümkün, ama hedef sunucunun sadece belli başlı TCP portlarının dışında (80, 21, 25, 110, 53 gibi) bir güvenlik duvarı ile korunduğu gerçeğinden yola çıkarak rastgele port numaralarını seçmek iyi bir fikir değil. Örneğin 1234 numaralı port için google.com'dan alacağımız cevap şöyle olur:


Standart ping komutundan farklar ise şöyle:

Warmup: Yukarıdaki örneklerde hep giden/gelen 5 paket gözüküyor. Bunun ilk gönderileni warmup olarak geçiyor. Bu warmup paketleri istatistiklere dahil edilmiyor, hesaplamalara girmiyor. Warmup paketi sayısını değiştirmek için -w anahtarı kullanılabilir.

Histogram: İstenen sayıda ping paketi gönderildikten sonra aşağıda yazan istatistiksel verilerin yeterli gelmediği durumlarda histogram çıktısı istenebilir. Bu durumda gecikme bakımından kaç paket hangi aralıklarda yer almış bu görülebilir. Örneğin google.com'a 100 ping (-n 100) gönderelim. Ping paketleri arasında hiç süre bırakmayalım, çabuk bitsin (-i 0). IP4 kullanalım (-4), ve gecikmelerin 10 bölmeli bir histogramda raporlanmasını isteyelim (-h 10). Bu durumda komutumuz:

psping -4 -i 0 -h 10 www.google.com

olur. 100 adet ICMP ping'inden sonra da çıktı şöyle olur:


Çıkan sonuç; 100 ping paketinden en çabuk cevap alınanı 58,66 ms, en geç cevap alınanı 68,12 ms. Bunları Ping statistics altında Minimum ve Maximum bölümlerinde görebiliyoruz. Bu aralığı (58,66 - 68,12 arasını) 10 düzgün parçaya (bucket) bölüp, her parçaya kaç paket düştüğünü de son bölümde verdi. Yani

58,66 ms - 59,71 ms arasında geciken paket sayısı : 8
59,71 ms - 60, 76 ms arasında geciken paket sayısı : 9
60,76 ms - 61,81 ms arasında geciken paket sayısı : 8
61,81 ms - 62,86 ms arasında geciken paket sayısı : 20
62,86 ms - 63,91 ms arasında geciken paket sayısı : 19
63,91 ms - 64,97 ms arasında geciken paket sayısı : 15
64,97 ms - 66,02 ms arasında geciken paket sayısı : 20
66,02 ms - 67,07 ms arasında geciken paket sayısı : 0
67,07 ms - 68,12 ms arasında geciken paket sayısı : 0
68,12 ms gecikmeye sahip paket : 1

Son satır bir aralık değil. Bu sonuçtan anlayabiliriz ki istatistiksel ağırlık 61,81 ms ile 66,02 ms arasında.

Bu arada düzgün 10 aralık değil de başka birşey istiyorsak h anahtarının ardından çift tırnak içinde, virgülle ayrılmış değerlerle bu aralık sınırlarını belirtebiliriz.

Latency test: Gecikme durumunu ayrıntılı olarak inceleyebilmek için hattın iki ucunda birer makinenin psping'i çalıştırması beklenir. Uçlardan birisi sunucu olarak seçilir ve bu sunucu üzerinde dinleyen bir servis başlatılır. Anahtar sırası için psping -? l ile erişilen yardımdaki sıraya önem vermek gerek. Örneğin:

psping -4 -f -s 192.168.1.105:1200

-4: IP4 kullan
-f : firewall'da port aç (yönetici hakları gerekir)
-s : sunucu ol (portu dinle)
192.168.1.105:1200 : Sunucunun IP adresi. 1200 de TCP (-u kullanılmadığından, varsayılan bu) portu

İstemci olan cihazdan da bu sisteme bağlanılır:

psping -4 -l 1000 -n 10 192.168.1.105:1200

-4 : IP4 kullan
-l 1000 : Paket boyutu 1000 byte olsun
-n 10 : 10 paket gönder
192.168.1.105:1200 : Sunucunun IP adresi ve sunucunun dinlediği port numarası. -u anahtarı kullanılmadığından varsayılan TCP.
Ayrıca -h 10 gibi bir anahtar ile historgram çıkış istenebilir.

Bandwidth test: Latency testine benzer bir şekilde iki nokta arasında bant genişliği tesi yapar. Yine sunucu üzerinde bir dinleyen hizmet başlatalım.

psping -u -4 -f -s 192.168.1.105:8080

- u : Bu sefer UDP kullanalım
-4 : IP4 kullan
-f : Firewall'da port aç
-s : sunucu ol (portu dinle)
192.168.1.105:8080 : Aynı sunucu IP adresinde, bu sefer 8080 numaralı UDP portunu dinle

İstemci üzerinde de yapılacak latency test'e göre tek farklı şey -b anahtarını kullanmak:

psping -b -u -4 -l 1000 -n 10 192.168.1.105:8080

-b : bandwidth test
-u : UDP
-4 : IP4
-l 1000 : Paket boyutu 1000 byte
-n 10 : 10 paket üzerinden hesapla
192.168.1.105:8080 : sunucu IP adresi ve portu

Yine -h anahtarı ile histogram çıktısı faydalı olabilir.

Hatırlatmakta fayda var, sunucu tarafında -s anahtarından sonra sunucunun IP adresi ve portu olmalı, sıra önemli.

6.01.2015

Tarayıcı kullanımı

Yıllarca süren Internet Explorer'ın egemenliğinde varolma savaşı veren Firefox'un zar zor ve yavaş yavaş yükselişte olduğu dönemde çıktı Google Chrome. Şimdi en çok kullanılan tarayıcı (browser) oldu.

Ocak 2012 tarihli şu yazımda Chrome'un, isteksiz ve beceriksiz bir projenin ürünü gibi gözüken Internet Explorer'ın karşısındaki yükselişinden bahsederken heyecanlı bir dil kullanmışım. O günden bu güne çok şey değişmiş. Aşağıdaki dünya haritası artık neredeyse tek renkli:


Wikipedia'nın söylediğine göre bu harita Ekim 2014 verilerine dayanarak StatCounter tarafından hazırlanmış. Yeşiller, tahmin edeceğiniz gibi, Chrome. Turuncu ise Firefox. Dünyanın hiç tahmin etmediğim bölgelerinde kullanılıyor olması güzel. Mavi ise faydasız IE.

Geçen ay [1,2] IE geliştirici şefi Dean Hachamovitch'in Microsoft'tan ayrıldığına dair bazı haberler vardı. Yeni CEO'su Satya Nadella önderliğinde kalıplaşmış bazı önyargılarından [1,2] kurtulan Microsoft'taki bu gelişmenin yeni başka gelişmelerin işareti olduğu belliydi. Hachamovitch'in gidişinin ardından Windows 10'da (Neden 9 değil?)IE'nin yerini alacak yepyeni bir tarayıcının olacağına dair haberler duyulmaya başlandı [1,2].

Bu harita çok renkliyken standartlaşma sorunları vardı. Ama tek renkliyken de tekelleşme sorunları olacak. IE'nin %70'lerle piyasanın hakimi olduğu dönemlerin kimseye faydası olmamıştı. Bu duruma acil bir çözüm lazım bence. Nedense arkasında Microsoft veya Google gibi büyük bir güç olmayan Firefox ve Opera gibi tarayıcılar bana daha güvenli geliyor. Ama gayri ihtiyari Chrome kullanır olduk.