Ahmet Öztürk Web Günlüğü

Java Uygulama sunucu olarak JBoss kullanan birçok kişi/kurum JBoss ile birlikte gelen ve ön tanımlı olarak çalışan yönetim konsolu uygulamasının ne kadar çok bilgi sızdırabileceğinin farkında değil. Kendi bilgisayarım üzerinden örneklerle gidip erişim kısıtlama yöntemlerini anlatmaya çalışacağım:

Ben de birçok işi başından aşkın veya tembel sistem yöneticisi gibi http://www.jboss.org sitesinden sözkonusu uygulama sunucusunu (sürüm 4.2.2.GA) indirdim ve hemen çalıştırdım.

# unzip jboss-4.2.2.GA.zip

# cd jboss-4.2.2.GA/bin

# ./run.sh &

Kabul ediyorum ben yukarıda bahsettiğim tembel sistem yöneticilerinden daha tembelim. Onlar en azından sistem her kapanıp açıldığında uygulama sunucusu başlasın diye açılış betiklerine birkaç satır ekliyorlardır

Uzun lafın kısası şu anda 8080 numaraları portta çalışan bir JBoss uygulama sunucum var. Artık diğer uygulamaların yanında, bir de öntanımlı olarak gelen web-console ve jmx-console uygulamaları da bu sunucu üzerinden erişilebilir durumdalar ve sistemle ilgili pek çok kritik bilgiyi isteyene sunuyorlar.

Web tarayıcımı http://localhost:8080/web-console/ adresine yönlendiriyorum:

Yukarıda görüldüğü gibi sistemin iç ağda kullandığı IP adresi, İşletim sistemi, Jboss’un kurulduğu dosya yolu vb. bilgilere ulaşılabiliyor.

Bunun yanında ikinci ekran görüntüsünde farketmiş olabileceğiniz gibi, uygulama sunucusuna o anda gelmiş olan GET veya POST istekleri de görüntülenebiliyor. Yani, kullanıcı adı ve parola bilgisi alan bir uygulamanız varsa buradan bu bilgilerinde görüntülendiğini bilmelisiniz.

Bu durumda sisteminizle ilgili bilgileri bütün dünyaya açmak yerine basit 1-2 ayarlama ile sadece sizin erişebileleceğiniz hale getirebilirsiniz. Bunun için aşağıdaki adımları izlemeniz yeterli:

I. JBoss kurulum dizini altındaki web-console.war/WEB-INF/web.xml dosyasına aşağıdaki satırları ekleyin:

<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the
role JBossAdmin to access the HTML Web console web application
</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>


II. JBoss kurulum dizini altındaki web-console.war/WEB-INF/classes/web-console-users.properties dosyasındaki admin kullanıcısının parolasını değiştirin:


admin=yeni_admin_parolası


III. JBoss kurulum dizini altındaki web-console.war/WEB-INF/jboss-web.xml dosyasına aşağıdaki satırı ekleyin:

<security-domain>java:/jaas/web-console</security-domain>


IV. JBoss’u yeniden başlatın.

JBoss artık web-console uygulamasına bağlanırken kullanıcı adı ve parola girmenizi isteyecektir:

————————————————————————————————–

Şimdi de JMX Management Console uygulamasına bakalım:
Web tarayıcımı http://localhost:8080/jmx-console/ adresine yönlendirdiğimde yine sunucum ile ilgili kritik bilgilerin görüntülendiği ve daha kötüsü değiştirilebildiği bir arayüzle karşılaşıyorum:

web-console uygulaması için yaptıklarımızın benzerini yaparak jmx-console uygulamasına erişim de kısıtlayabiliriz:

I. JBoss kurulum dizini altındaki deploy/WEB-INF/web.xml dosyasına aşağıdaki satırları ekleyin:

<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the
role JBossAdmin to access the HTML JMX console web application
</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint>


II. JBoss kurulum dizini altındaki conf/props/jmx-console-users.properties dosyasındaki admin kullanıcısının parolasını değiştirin:


admin=yeni_admin_parolası


III. JBoss kurulum dizini altındaki deploy/jmx-console.war/WEB-INF/jboss-web.xml dosyasına aşağıdaki satırı ekleyin:


<security-domain>java:/jaas/jmx-console</security-domain>


IV. JBoss’u yeniden başlatın.

Artık jmx-console uygulaması da kullanıcı adı / parola soracaktır.

—

Haftabaşında ofiste Kevin Mitnick’ten girip, sosyal mühendislikten çıkan muhabbetler yapılırken, benim internetle tanıştığım zamanlar (~1995-96) geldi aklıma. Sonrasında da o dönemde güvenlikle ilgili konular nelerdi diye düşünürken, vakti zamanında okuduğum bir makaleyi hatırladım. Hemen kitaplıktan arayıp buldum. (Hiç birşeyi atmaya kıyamamamın işe yaradığı ender durumlardan biri)

“The greatest cracker-case in Denmark: The detecting, tracing and arresting of two international crackers” başlıklı makale 14-16 Eylül 1992 tarihlerinde Maryland,Baltimore’da gerçekleşen USENIX (Use UNIX) Unıx Security III sempozyumunda Jorgen Bo Madsen tarafından sunulmuş.

1991 yılında, 2 Danimarka’lı gencin, yanlış yapılandırılmış modem hatlarını kullanarak Danimarkada UNI-C, ve NBI (Niels Bohr Institute) ve ABD’de NASA bilgisayarlarına eriştiklerinin farkedilmesi üzerine yapılan takip ve yakalama çalışmasının Danimarka hukuk tarihinde ilk olma özelliği var.

Makalenin sonuç kısmı ise evlere şenlik. Gençlere verilen cezayı az bulan Bo Madsen, resmi makamlara yazılan raporların bilgisayarlar hakkında bilgisi olmayan birinin bile anlayacağı bir dilde ve günlük hayattan örnekler içermesi gerektiğini söylüyor. Sonuç maddelerinden bazıları şöyle:

- .netrc dosyalarnın kullanımını yasaklayan bir kanun olması gerekir.

- Damiarka ile diğer ülkeler arasında tftp kullanımı durdurulmuştur ve bir daha asla açılmayacaktır.

- Cracking işleri ağır çalışmak sayılır ve boşanma sebebi olabilir

Bu eğlenceli ve sürükleyici makaleye buradan ulaşabilirsiniz. Bu makaleyi yazarın copyright notunu gözönüne alarak sadece eğitim ve araştırma amaçlı olarak yayınladığımı belirtmek isterim.

herkese iyi okumalar

0. Amaç:

Bir süredir disk şifreleme programları ile biraz oynamak istiyordum, ama fırsat bulup da elimi sürememiştim. Bu hafta artık bu işe el atayım dedim (Önce arkadaş tavsiyesi Luks ile başladım ama daha sonra kendime kurban olarak Truecrypt’i seçtim.) Hatta el atmışken biraz da uykusuz kalıp, hangi şifreleme algoritması ne kadar yük getiriyor test ettim. Aslında internette aranırken birkaç karşılaştırmaya denk geldim ama tatmin edici değillerdi, ben de kendime göre bir test ortamı geliştirdim. Testleri ve sonuçları sizlerle paylaşayım:

I. Test ortamı:

Testleri gerçekleştirdiğim sistemin özellikleri:

- 2 x 2GHz AMD Turion 64 CPU (512 MB Cache)

- 2 GB RAM

- 160 GB SATA Disk (5400 RPM - dahili)

- USB 500 GB (7200 RPM * 8 MB cache - harici)

- İşletim Sistemi: GNU/Linux-2.6.24

- Yazılım: Truecrypt 5.1a

Bütün testleri dahili disk üzerinde aynı disk bölümlemesini şifreleyerek gerçekleştirdim, Testlerin bir kısmında şifrelenmemiş harici diskten şifrelenmiş dahili diske kopyalama işlemleri gerçekleştirip sonuçları gözlemeye çalıştım. Testlerin tanımlarını aşağıda ayrıca detaylı olarak vereceğim

II. Veri Setleri:

Salt arabelleklenen okuma/yazma (buffered read/write), veya ardışık okuma/yazma (sequential read/write) testleri yapmak yerine kendi davranışlarımdan yola çıkarak, data somut işlemleri test etmeye çalıştım. Çok sayıda küçük boylu dosya kopyalama, büyük dosya kopyalama, tar arşivi açmak, arşiv oluşturmak, program derlemek gibi. Bu testler sırasında kullandığım veri setlerinin listesi:

data-set1: 9321 dosya - 145184 KB -> ortalama 15.5 KB/dosya

date-set2: 21 dosya -99568 KB -> ortalama 4741.3 KB/dosya

data-set3: 12 dosya -2139672 KB -> ortalama 178306 KB/dosya

data-set4: 1 dosya -2139608 KB -> ortalama 2139608 KB/dosya

Bunlar dışında ayrıca bir arşiv işlemleri için linux çekirdek kaynak kod arşivini (linux-2.6.25.6.tar.bz2) ve derleme işlemleri için Truecrypt-5.1a kaynak kodunu kullandım.

III. Testler (Tanımlar ve Test Sonucçları):

Testlerin tanımlarını ve nasıl gerçekleştirdiğmi aşağıda açıklayacağım. Bu testleri Truecrypt’in desteklediği bütün şifreleme algoritmaları için, SHA-512 hash algoritması kullanarak, aynı sıra ile, her ardışık test arasında 10 sn. bekleyerek gerçekleştirdim. Burada amacım, bir test sırasında işlemcide oluşabilecek olası yükün, ardından gelen teste etki etmesini önlemekti. Aşağıda açıklayacağım her bir test adımının ne kadar zamanda tamamlandığını kaydedip, aynı işlemlerin şifrelenmemiş disk üzerinde gerçekleştirildiğinde alınan sonuzlar ile normalize ettim. (şifrelenmemiş disk üzerindeki test sonuçlarını 1 birim kabul ettim.)

Test adımlarını okumayı kolaylaştırmak için, ufak bir not:

SOURCE = usb harici disk üzerinde şifrelenmemiş bir ext3 disk bölümü

TARGET = dahili SATA disk üzerinde şifrelenmiş bir ext3 disk bölümünü şu parametreler ile oluşturdum:

# mkfs.ext3 -j -m 1 -O dir_index,filetype,sparse_super

Şimdi test adımarını sıralayabilirim:

-Test1: Küçük dosya kopyalama

# cp -pr $SOURCE/data-set1 $TARGET/

-Test2: Orta büyüklükte dosya kopyalama (MP3′lerimi kopyalasam ne olur?)

# cp -pr $SOURCE/data-set2 $TARGET/

- Test3: Büyük boyutlu dosya kopyalama (internetten indirdiğim dizinin 1. ve 2. sezon bölümleri:) )

# cp -pr $SOURCE/data-set3 $TARGET/

- Test4: 2 GB civarında tek dosya kopyalama testi:

# cp -pr $SOURCE/data-set4 $TARGET/

- Test5: Küçük dosyalardan olşan bir arşivin açılması:

# cd $TARGET/ && tar -jxf linux-2.6.25.6.tar.bz2

-Test6: Kaynak kod derleme testi (Truecrypt 5.1.a):

# cd $TARGET/truecrypt-5.1a-source && make WX_ROOT=$TARGET/wxWidgets-2.8.7 wxbuild && make

-Test7: Küçük dosyaların arşivlenmesi:

# cd $TARGET && tar czf kernel-surce.tar.gz linux-2.6.25.6

- Test8: Büyük bir arşiv oluşturulması:

# cd $TARGET && tar cf data-set3.tar data-set3

- Test9: Büyük bir dosya okuma:

# cd $TARGET && cat data-set3.tar > /dev/null

Testlerin Toplamı:

IV. Yorumlar:

Testlerin genelinde AES ve Twofish şifreleme yöntemleri en az gecikmeye yol açan yöntemler olarak görülüyor, gecikmeler genelde %20 - %50 civarında. Ard-arda sıralı (cascade) yöntemler beklenildiği gibi çok daha yavaş kalıyorlar; özellikle büyük dosyalar ile yapılan işlemlerde (kopyalama, arşiv oluşturma ve okuma) bu yavaşlama diğer işlemlere nazaran çok daha hissedilir oluyor. Kod derleme testinde ise belirgin bir farklılık göze çarpmıyor.

Not:Testlerin tamamlanma zamanları ile ilgili tabloya buradan erişebilirsiniz.

Emre ve Oya ile birlikte, güzel bir (plansız) pazar günü planı yapmıştık. Sabah buluşup Ankara civarında bir yerlerde piknik yapıp biraz yürüyelim istiyorduk. Yola çıktıktan bir süre sonra Beynam Atatürk Ormanı’na gitmeye karar verdik. Ormana vardığımızda gördüğümüz şeyler hiç de iç açıcı değildi. Büyük ihtimalle ÖSS nedeniyle ortalık pek de kalabalık değildi ama her taraf çöp içerisindeydi. Her yere atılmış poşetler, kağıtlar, yiyecek maddeleri.. aklınıza gelebilecek bütün pislikler bir araya özellikle toplanmış gibilerdi. Zar zor görece temiz bir bölge bulup karnımızı doyurduk ve oradan kaçtık.

Ben ayrılırken arabanın camından 1-2 fotoğraf çektim. Akılsızlığın, sorumsuzluğun, saygısızlığın, insanların içine işlemiş pisliğin fotoğrafları:

Ormanda kurulu bulunan Orman İşletme şefliği ne iş yapar?, buradan sorumlu bir belediye yada kurululuş yok mudur? İnsanlar bu rezilliğin içinde nasıl yaşar?

Her neyse, Beynam Ormanı’na gitmeyi düşünenlere, kafalarını belediye çöp kamyonunun arka tarafına sokmalarını öneriyorum, daha temiz olabilir.

Ayağımdaki problem nedeniyle, 1 haftadır sadece internetten acaba çıktı mı diye kontrol edebilğim Pentagram 20. yıl konser DVD’sini, bugün dışarı çıkmışken denk gelince hemen aldım. Not düşmek için otelin lobisine indim. Hemen yukarıçıkıp izlemek istiyorum. Heyecanlıyım…

Slashdot‘ da “Microsoft Developing News Sorting Based On Political Bias” başlıklıklı yazıyı ilk başta bir şaka olduğunu düşünerek okudum Nedense Slashdot ve Microsoft diyince ciddi birşeyler beklemiyor insan, ama konu gerkekmiş

BLEWS kısa adı ile geliştirilen projenin amacı, önceden sınıflandırılmış/belirlenmiş politik bloglardan verilen linklere ve kullanılan dile göre haber sitelerindeki haberleri kategorize etmek, ve son kullanıcıya bunu grafik olarak sunmak. Blog yazarlarını liberal veya muhafazakar olarak etiketleyip bu etiketi/sınıflandırmayı topluma yaymanın ayıbı bir kenara, açıkçası Amerikan politik sistemi hiç ilgimi çekmiyor.

Bu projenin nerede kullanışlı olabileceğini düşünürken Slashdot yorumları arasında aradığımı buldum: “emacs vs. vim?”

techrepublic‘de rastladığım bir yazıyı sizinle de paylaşmak istedim. Chad Perrin güvenlik ile ilgili 5 olmazsa olmaz kaynağı listelemiş. Bu kaynaklardan bir tanesi de A Chronology of Data Breaches sayfası.Her ne kadar sadece A.B.D’deki olanları listelemiş olsa da 2005 yılından beri gerçekleşen olaylara göz atmak bazı konularda farkındalık yaratmak açısından iyi olabilir. Hassas veri kaybı/hırsızlıklarının büyük kısmı dizüstü bilgisayar çalınmaları sonucunda meydana gelmiş. (Bu verilerin dizüstü bilgisayarlarda ne işi olduğu sorusu geliyor tabii hemen akla). Hırsızlıkların yanında, ilginç birkaç olay daha var:

• Jax Federal Credit Union - 1 Haziran 2007: Kredi kuruluşu, müşterilerinin sosyal güvenlik numarası ve hesap numaralarını içeren bilgiyi yazıcıya şifrelemeden gönderdiğinde ve bu bilgi yazıcının web arayüzünden erişilebilir hale gelmesi ve google tarafından bu bilginin indekslenmesi.
• Idaho Power Co. - 4 Mayıs 2006: Şirketin CEO’sunun gizli notlarını da içeren binlerce belgeyi içeren 4 adet sabit diskin eBay üzerinden satılması. (İvedik şehir hurdalığında satılan disklerden kimbilir neler çıkıyor? )
• Johns Hopkins University and Johns Hopkins Hospital - 7 Şubat 2007: Toplam 135.000 kişiye ait çalışan ve hasta bilgilerinin içeren 9 adet yedek teyp kartuşunun “kaybolması”.

Bunlar listteye hızlıca göz atarken gözüme çarpanlar. Daha kimbilir neler var.

Bu arada konu dizüstü bilgisayar hırsızlığından açılmışken, vakti zamanında eşimin bana izlettiği bir youtube videosunun linkini vereyim. X-RAY cihazlarının olduğu yerlerde bu tarz bir hızsızlığın nasıl gerçekleşebileceğine ilişkin eğitici bir video:

http://xkcd.com/327