Yöneticimi SUNUCU ÜZERİNDE Java'nın güvensiz olmadığı konusunda nasıl ikna edebilirim?

Uygulama

Bir web sunucusundan yüklenen dosyaları almak, işlemek ve sonuçlarla birlikte bazı e-postalar göndermek için bazı Deve rotalarını kullanan küçük bir Java uygulamamız var.

Bu uygulamanın çalıştığı sunucu devre dışı bırakıldı. Şimdilik, yöneticiyi web sunucusuna bir JRE (aslında çok amaçlı bir sunucu) yüklemeye ikna edemediğimiz için düşük güçle çalışan donanım üzerinde çalıştırmak zorundayız.

Korku

Ben bir Java Uygulama Mühendisiyim, haftada on binlerce € değerinde B2B işlemlerini gerçekleştiren, yaşamak için JEE kodu yazıyorum. Ancak java'nın güvensiz olduğu mitini çürüten güvenilir kaynaklar bulmakta sorun yaşıyorum.

Yöneticinin bir JRE yüklemesine karşı iki ana argümanı:

1. Java uygulamaları tüm RAM'imi tüketiyor
2. Java güvenlik açıklarıyla dolu

Doğrusu?

Java uygulamaları söz konusu olduğunda koç yiyor. Şey ... Xmx için uygun değerleri ayarlamamız gerektiğini söyleyebilirim. Bitti.

Şimdi Java'nın birçok güvenlik açığı hakkında konuşan birçok kaynak var. Bu kaynaklar çoğunlukla Redmond / ABD'deki bir şirketten belirli bir işletim sistemi çalıştıran son kullanıcıları hedeflemektedir. AFAIK, tüm uygulamaları otomatik olarak yürütmek üzere yapılandırılmış Java Tarayıcı Eklentisi'nin eşleşmemiş sürümleri için, bir sürücünün enfeksiyondan kurban olma olasılığı oldukça yüksektir. Tıpkı işe giderken treninizde eveyone ile korunmasız seks yaparken cinsel yolla bulaşan hastalıkları yakalama riski olduğu gibi.

Ancak dünya çapında interwebz'de sunucu uygulamaları veya başsız çalışan JRE'ler hakkında konuşan kimseyi bulamadım. Bu başka bir şey.

Yoksa burada bir şey mi eksik?

[değiştir 2014-08-28] açıklama: Yalnızca sunuculardaki Java ile ilgileniyorum. Java Eklentisi ve / veya java'da geliştirilen belirli yazılımlarla ilgili sorunları umurumda değil.

Ek güvenlik yüzeyi java ortamınıza karmaşıktır ve onu görmezden gelmemek veya basitleştirmeye çalışmak önemlidir.

İlk olarak, JRE'nin güvenlik hatalarına sahip olduğu için korkunç bir kayıt var. Belirli bir noktaya işaret etmek zordur ve bu korkunç bir parçadır - böcekler, belirtilmemiş vektörlerle ezici bir şekilde tanımlanmamış güvenlik açıklarıdır.

Bir güvenlik danışmanı olarak, "uzak bir saldırgana izin verir" gibi cümleleri anlamlarına ilişkin daha fazla yeterlilik olmadan okuduğumda, belirli bir işleve giren belirli parametrelerin, yalnızca yazdığınız kodu çalıştırıyor. Ve belirtilmemiş oldukları için etkilenip etkilenmediğinizi bilmiyorsunuz.

Daha da iyisi, Oracle tarafından yayınlanan standart JRE, neredeyse tüm güvenlik güncellemeleri de dahil olmak üzere kritik güncellemeler için üç aylık bir güncelleme döngüsüne sahiptir. Son dört yıl içinde toplamda 11 kez devir yamaları oluşturdular. Bu , herhangi bir sorunu çözmeden önce bildirildikten üç ay sonrasına kadar bir güvenlik hatasına karşı savunmasız olma olasılığınız olduğu anlamına gelir .

Java ile buraya girmeyeceğim başka sorunlar var, ama gerçekten, özellikle çok amaçlı bir sunucu için haklı bir endişe var gibi görünüyor. Böyle şeyler yürütmeniz gerekiyorsa, en azından bunun için tek amaçlı bir VM yapmalı ve diğer şeylerden soyutlamalısınız.

Özellikle, JRE'de bir saldırganın RCE kazanmasına izin veren bir uzaktan kumanda ve PHP'de de aynı şeyi yapan başka bir tane ve Ruby'de de aynı şeyi yapan başka bir uzaktan kumanda varsa, üçünü de yamalamanız gerekir. Bu şeyler giderken her üçü de biraz muhtemel görünüyor ve saldırgan hangisinin en uygun olduğunu seçiyor ve ardından tüm sunucunun sahibi oluyor. Bu nedenle VM'leri yazılımı, özellikle de yönetilen dil çerçeveleri gibi buggy yazılımları ve özellikle de yılda sadece dört kez güvenlik yamaları paketleyen ve paragon olduklarını gösteren tüm kanıtlar karşısında bir satıcıya ait olan yazılımları ayırmak için kullanmalıyız. güvenlik.

Güncellemek için, gösteri yoluyla ChrisS'in bağlantılı CVE araştırmasından seçtiğim bazı CVE'ler.

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5884
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5910
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5456
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3007
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2454
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2447
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1557

Ve benim favorim, orada olduğumdan beri:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1488

Bu arada, sadece küçük bir örnekleme.

Java uygulamaları tüm RAM'imi tüketiyor

RAM kullanmanın alternatifi RAM israfıdır. Daha sonra saklayamazsınız.

Java güvenlik açıklarıyla dolu

Bu gerçekten önemli değil, çünkü JVM'yi dünyaya maruz bırakmayacaksınız. Herhangi bir düşmanca program çalıştırmayacağınızı varsayıyorum ve eğer öyleyse, Java diğer dillerden daha güvenlidir. Önemli olan uygulamalarınızın güvenlik açıkları olup olmadığıdır.

Programınızda statik analiz yapması için bir şirket kiralayın. Örneğin Veracode, geçmişte özellikle Java programlarının kod güvenliğini denetlemek için kullandığım bir şirket.

Yönetici ekibinizin ücret kodunu açıkça faturalandırın.

Diğer tüm dillerin (veya sanal makinelerin), tıpkı Java'da olduğu gibi, kendilerine dağıtılan kodla güvensiz hale getirilebileceğini açıklayın. Diğer platformların güvenliği doğru bir şekilde ele almadan doğal olarak güvenli (veya Java'dan daha güvenli) olduğunu düşünürse, o zaman kuruntu olur.

Şirketiniz açıkça bir Java geliştiricisi işe yatırım yaptı, sysadmin neden şirketin kullanmaya karar verdiği bir teknolojiyi desteklemeyi reddediyor?

Soruyu çevirir ve ona hangi alternatifleri önerdiğini ve en son Server JRE'den çok daha güvenli bir şekilde nasıl daha güvenli olduklarını sorarım. Bu arada, teknolojinizi, olası saldırı yüzeyini ve onu en aza indirmek için çalıştığınızı göstermeye çalışın (örn. Gereksiz çerçeveler, 3. taraf kodu, vb.). Kodunuzu doğrulayın, son X yılda güvendiğiniz çerçeveler için yayınlanan güvenlik açıklarını arayın, diğer dillerle / çerçevelerle karşılaştırın (pazar paylaşımını da dahil ettiğinizden emin olun, yayınlanmış güvenlik açıkları olmadan belirsiz çerçeveler hiçbir şey ifade etmiyor).

İkiniz arasındaki dönüşümün nasıl gerçekleştiğini muhtemelen bilemeyiz, ancak bu onun iki argümanı olsaydı, bir genç sistem yöneticisi ile uğraştığınıza inanıyorum. Java uygulama sunucuları konusunda tecrübesi var mı? Belki de teknolojiden rahatsız olur ve iyice anlamadan bir şeyi üretime sokmaktan korkar (o zaman iyi sysadmin tutumu).