web-gelistirme-sc.com

İşletim sistemi neden "Bu bir Unix sistemi!" yaygın olarak uygulanmadı mı?

Başlıkta atıfta bulunulan Jurassic Park scene , teknoloji okuryazarı olanlara ne kadar gülünç geldiği için ünlüdür. Ama aynı zamanda web güvenliğinde, özellikle IoT cihazlarında göze çarpan büyük bir delik gibi görünen şeyleri de gösteriyor - saldırganlar bir sunucu veya kamera veya bebek monitörü linux çalıştırdığında, anında nasıl çalıştıklarını biliyorlar. Sudo gibi komutların büyük sulu hedefler olduğunu biliyorlar ve Shell erişiminin beraberinde ls ve cat gibi yararlı araçların getireceğini biliyorlar.

Peki neden OS gizleme bir şeyden daha fazla değil? Sadece web üstbilgilerinde sürümü gizlemekten bahsetmiyorum. JavaScript minyatürüne veya gizlemeye benzer şekilde, işletim sisteminin kendisinde ikili dosyaların ve dosya yollarının adlarını değiştirmekten bahsediyorum. İşletim sisteminde Sudo ve ls yerine ha7TrUO Ve RRI6e29 Komutları varsa, tüm saldırı sınıfları pratik olarak işe yaramaz mı? Bir şekilde uzaktan kök erişimi kazanan bir hacker düşünün - herhangi bir komut bilmiyorlarsa ne yapacaklar?

Derleyiciler için uygulama oldukça kolay olacaktır. "Bu işlevi ve tüm çağrıları yeniden adlandırın" en basit durumunu ele alalım. Bir OS derleyicisine ve bir uygulama derleyicisine aynı rastgele adları verebilirsiniz ve birbirleriyle konuşabilirler. Ancak uygulamanın güvenliği zayıf olsa ve bash enjeksiyonuna karşı savunmasız olsa bile, bu tür saldırılar sonuç vermez.

Açıkçası bu teknik tüm senaryolarda kullanılamaz. İnsan sistem yöneticileri tarafından tutulan sunucular gibi senaryoları bir kenara bırakarak, otomasyonla yönetilen herhangi bir cihazın veya sunucunun bu savunma için birincil aday olduğu anlaşılıyor.

Sanırım soruların biraz daha somut olması gerekiyor:

  1. Açıklandığı gibi OS gizleme yaygın olarak kullanılıyor mu ve ben sadece karşılaşmadım?
  2. Yaygın olarak kullanılmazsa kullanımın pratik veya teknik engelleri nelerdir?
156
Indigenuity

Fikrinizi ayırmadan önce, bunun gerçekten ilginç bir fikir olduğunu ve düşünmek çok eğlenceli olduğunu söyleyeyim.

Lütfen kutunun dışında düşünmeye devam edin ve ilginç sorular sorun!

Tamam, hadi yapalım!


Bir adım geri gidelim ve bebek monitörünün neden Linux çalıştırdığını soralım. İşletim sistemi yoksa ve uygulama çıplak mikrodenetleyici koduyla yazılmışsa (Arduino kodunu düşünün) ne olacak? O zaman Sudo veya ls veya saldırganın kullanması için bir Kabuk olmaz, değil mi?

Burada bir uzman değilim, ancak bir endüstri olarak, Linux'u geliştirici rahatlığı için büyük ölçüde çalıştırmak için yeterince büyük bir şeye koymaya yönelmemizi bekliyorum:

  1. Geliştirme süresini azaltma: WiFi ve bluetooth özellikli web tarafından yönetilen bulut senkronizasyonlu kendinden yamalı fısıltıyı tamamlayıcı Android ve iOS uygulamalarıyla oluştururken, Linux tüm kitaplıklar, yardımcı programlar ve Bunu yapmanız gereken sürücüler.
  2. Artan test edilebilirlik: Cihaz bir SSH bağlantı noktasıyla bash veya busybox çalıştırıyorsa, ürün testi aşamasında bağlantı kurmak ve neyin yanlış gittiğini anlamak çok kolaydır.

Gizleme fikrinizin çalışması için, sadece Sudo ve ls gibi komut satırı yardımcı programlarının adlarını değil, aynı zamanda her Linux çekirdek API'sı saldırganın çekirdeği doğrudan çağıran derlenmiş ikili dosyalarına düşmesini önlemek için. Şimdi fikrinize bir göz atalım:

Derleyiciler için uygulama oldukça kolay olacaktır. "Bu işlevi ve tüm çağrıları yeniden adlandırın" en basit durumunu ele alalım. Bir OS derleyicisine ve bir uygulama derleyicisine aynı rastgele adları verebilirsiniz ve birbirleriyle konuşabilirler.

Bu rastgele derlemeyi kendiniz yapmanız gerekecek; aksi halde birisi Google'daki eşlemeleri arayabilir.

Bu nedenle, "gizlenmiş derleyiciniz" ile çekirdeği kaynağından oluşturmanız gerekir, böylece gizlenmiş çekirdek API'lerinin eşlemelerini yalnızca siz bilirsiniz. (linux çekirdeğini kaynağından hiç inşa ettiniz mi? Kesinlikle docker pull Alpine 'den daha fazla angarya, dev kültürünün gittiği yön budur).

Ancak bir işletim sistemi çekirdekten daha fazlasıdır. Bu mini-pc cihazında gelen Broadcom BCM2837 wifi çipi için sürücüler ister misiniz? Broadcom size kaynak kodunu bile verecekse, bu sürücüyü derleyicinizle birlikte gelen çekirdeğinize karşı kurmanız gerekir. Daha fazla GNU wifi ve ağ yazılım yığınları oluşturmak gerekir.) Çalışan bir işletim sisteminiz olmadan önce kaynak bulmak ve ekleme boru hattı eklemek için kaç şey daha gerekir?

Oh, ve bu şeylerden herhangi birinin akış yukarı depoları bir yama yayınlarsa, şimdi onu yeniden oluşturmaktan sorumlusunuz (derleyici gizleme eşleme dosyalarını kaydettiğinizi varsayarsak) ve itmek çünkü - tasarımlarına göre - cihazlarınız satıcı tarafından üretilen yama ikili dosyalarını kullanamaz.

Oh, ve bilgisayar korsanlarını folyolamak için, bunların hiçbiri olmayacak "İşte Whizpopper 1.4.7 için ikili dosyalar", oh hayır, her şeyin benzersiz bir şekilde gizlenmiş bir versiyonunu oluşturmanız gerekecek Çekirdekten yukarı cihaz başına gönderiyorsunuz.


Sorularınız için:

  1. Açıklandığı gibi OS gizleme yaygın olarak kullanılıyor mu ve ben sadece karşılaşmadım?
  2. Yaygın olarak kullanılmazsa kullanımın pratik veya teknik engelleri nelerdir?

Cevap, açıkladığınız şeyin, kelimenin tam anlamıyla her şeyi kaynaktan bulmanız ve oluşturmanız gerektiğinde, önceden var olan yazılım bileşenlerini kullanma amacını tamamen yendiğini düşünüyorum. Aslında işletim sistemini tamamen boşaltmak, 1960 olduğunu iddia etmek ve uygulamanızı doğrudan CPU mikrokoduna yazmak daha az çaba gösterebilir.

Güvenliği çoğu geliştiriciden daha çok seviyorum, ama f * that ​​gibi.

235
Mike Ounsworth

Mike'ın cevabı, temelde bunun neden bir gelişim perspektifinden kötü bir fikir olduğu hakkında sunmam gereken her şeyi söylüyor (ve Ghedipunk'ın yorumunun söylediği gibi, kullanılamaz bir güvenlik özelliği güvenlik sağlamaz). Bunun yerine, neden güvenlik açısından bakalım, bunu asla yapmazsınız.

Cevap aslında şaşırtıcı derecede basit: zaman kaybı ve kesinlikle daha iyi seçenekler var. Her aptal IoT doodad'ı (hatırlayın, "IoT" içindeki "s", Güvenli anlamına gelir), cehennemin önerdiğiniz gibi bir yaklaşımla gitmeyeceğinden emin olarak bu tür özellikleri uygulama zahmetine girmez.

  1. Tüm fikir, sistem çağrılarını kısıtlamak için işe yaramaz. Bir saldırgan birkaç kayıt ayarlayabilir ve bir opcode ve boom çağırabilir, seçtikleri sistem çağrısını yürüten çekirdeğin içindedir; sembolik isminin kimin umrunda? Tabii, bunu karmaşıklaştırmak için sistem çağrısı tablosuna müdahale edebilirsiniz (her şeyi yeniden derlemeniz ve özel çekirdeğinizde hata ayıklama yapmanın bir sakıncası yoksa), işletim sistemini işletimde gizlemek gibi; neden bu kadar az aday varken rahatsız oluyorsun ki? Saldırgan, sistemdeki mevcut kodu tersine çevirmek istemese bile, kullanılabilir çağrı indekslerinin arama alanı gömülü bir sistemde gördüğümden daha geniş olmadığı sürece kaba zorlama mümkün olmalıdır.
  2. Komut adlarını tamamen erişilemez hale getirdiğinizde neden gizleyin? Bir chroot Shell yerleşik olarak çalışmaz bir Shell çalıştırıyorsanız, ancak diğer her şey için iyi çalışıyor ve gerçekten, neden özel olarak oluşturulmuş single'ınız -amaç-app-in-a-box bir kabuk çalışıyor? Yani, dev ünitelerinde test amaçlı bir tane yüklü olacaktı ve belki de perakende imajınızda kaldırılmayacak çünkü tembel ya da tekrar ihtiyacınız olacağını düşünüyorsunuz. Ancak bir saldırgan, onu uygulamasının çalıştığı bağlamdan çalıştıramaz. Basit bir chroot (veya daha karmaşık bir sanal alan/hapishane/kapsayıcı), programın işi için gerekli olanların ötesinde herhangi bir dosyayı çalıştıramamasına, hatta erişememesine neden olabilir.
  3. Neden bunlara erişimi kaldırabildiğinizde neden çekirdek API'lerini gizlemelisiniz? Bir süreci (ya da torunlarını ... herhangi bir tane oluşturmasına izin veriliyorsa) yapabileceklerini kısıtlayabilen bir dizi sanal alan sistemi vardır. Bakınız https://stackoverflow.com/questions/2146059/limiting-syscall-access-for-a-linux-application
88
CBHacking

Amacınız ls ve cat saldırganını mahrum etmekse, şaşırtmaya daha iyi bir alternatif var: sadece bu programları yüklemeyin.

Bu yaygın olarak uygulama yaklaşımı olduğunu söyleyemesem de, en azından uygulamaktır. Örneğin, içinde neredeyse hiçbir şey olmayan bir liman işçisi resminin bir koleksiyonu olan distroess düşünün. Bazılarının (gitmek için olduğu gibi) tam anlamıyla hiçbir şeyleri yoktur. Böyle bir kapsayıcıda çalışan bir sisteme yapılan saldırı, Shell erişimi alamaz çünkü çalıştırılacak Kabuk yoktur.

O zaman böyle bir kaptaki bir uygulamaya saldırarak Shell erişimini elde etmenin tek yolu, kapsayıcı çalışma zamanını atlatmaktır.

Bağlantı istasyonu görüntüsünün bir örneğini verirken, aynı konsept genellikle işletim sistemlerine uygulanabilir. Örneğin, ls ve cat, Debian'daki coreutils paketinin bir parçasıdır. apt-get remove coreutils ve bir saldırganın bir saldırının parçası olarak ls veya cat kullanamayacağından emin olun. Tabii ki bu da onları kullanamayacağınız ve muhtemelen kaldırılması gereken coreutils'ye bağlı olan birçok şey var, ancak gömülü bir cihaz veya yalnızca bir şey yapan bir sunucu için bu iyi olabilir.

Genel ilke "saldırı yüzeyini" azaltmaktır: bir hedef ne kadar "şey" olursa, taviz vermek o kadar kolay olur. Bunlar açık ağ bağlantı noktaları, kod satırları veya kurulu ikili dosyalar olabilir. Artan güvenlik hedef ise, gereksiz tüm "şeylerin" kaldırılması iyi bir başlangıçtır.

30
Phil Frost

Çünkü gizleme güvenlik değildir ve işletim sistemi gizlemesi temelde saçmalıktır.

Sadece çok sayıda yaygın işletim sistemi ve eğitimli tahminler yapmanın birçok yolu vardır. IIS veya MSSQL Server) çalıştırdığımı tespit ederseniz, altında hangi işletim sisteminin çalıştığına dair bir tahmininiz vardır.

Bir şekilde temel işletim sistemim hakkında hiçbir şey söylemeyen bir yığın çalıştırmayı başarabilsem ve aynı zamanda diğer tüm ipuçlarını maskeleyebilsem bile (parmak izi bir şeydir), hala çok kazanamadım.

Güvenlik açısından, Linux çalıştırdığımı veya Debian 8 çalıştırdığımı bile biliyorsunuz, üzerinde çalışacak çok şey veya endişelenecek çok şey vermiyorsunuz. Eğer düzgün bir şekilde sertleştirilmiş ve yamalıysam, ne istersen biliyor olabilirsin. Dün yazılım müzesine başvuran bir yama düzeyindeysem, saldırı paketiniz hepsini deneyerek beni tamamen açık kılacak ve işletim sistemimi şaşırtmak sizi birkaç işe yaramaz istismar daha fazla denemeye zorluyor. Otomatik bir saldırıda, sizi birkaç saniyede yavaşlatır.

Şaşkınlık işe yaramıyor. İnsanlar, neyin işe yaradığını görmek için sizi tarayabilir, parmak izinizi kaydedebilir veya tüm istismar kütüphanelerini atabilir.

Eğer gerçek sertleşmeye harcayabileceğiniz zaman harcarsanız, aslında güvenliğinize zarar verirsiniz.

Uygun sertleştirme işleri. Yukarıda "ne istersen biliyorsun" dedim . IP adresimi gönderdim ve root şifresi güvenlik konferanslarında konuştum. Uzaktan kök girişi ve bir grup hizmet etkinleştirilmiş SSH. Ciddi derecede sertleştirilmiş SELinux makinesi. Kimse konuşmamı kesmeyi başaramadı, ancak bir kişi bir keresinde politikam henüz mükemmel olmadığında bir metin dosyasını kök dizine bırakmayı başardı.


Zeyilname: Başlangıç ​​noktanız bir filmdi. Şaşkınlık harika bir film aracıdır, çünkü böyle bir vahiy izleyicilere kahramanın (veya kötü adamın) bir parça bilgi bulduğunu ve böylece ilerleme kaydettiğini söyler. Yine de koda ihtiyacınız olsa bile, kasanın nerede olduğunu bulmak için bilgisayar eşdeğeri. Gerçekte doğru olup olmadığı, izleyiciye uygun duygusal mesajı iletmesi önemli değildir.

13
Tom

Son derece yaygın bir örnek olarak, kendi işletim sistemine sahip Intel Yönetim Motoru, bir ürün yazılımı güncelleme mekanizması olduğu, ancak ürün yazılımının ayrıntıları gizli olan çok özel bir formatta olması gereken böyle bir şey yapar. Bilinmeyen parametrelerle Huffman kodlamasını içeriyor gibi görünüyor. Teklifinize benzer şekilde (temel olarak ürün yazılımının simetrik olarak şifrelenmesi) ME, ürün yazılımı hazırlama zamanında belirli değişiklikler gerektirir ve yürütme sırasında standart mekanizmalardan eşleşen bir sapmaya sahiptir.

7
Roman Odaisky

Açıkladığınız şeye "Belirsizlik Yoluyla Güvenlik" denir ve yaygın olarak bilinen bir güvenlik antipatternidir . Yani bu yeni bir fikir değil, eski, kötü bir fikir, güvenlik felsefesine katılmayanların içine düşmemek için eğitilmeleri gerekiyor.

Bir evi güvenli olacak şekilde tasarladığınızı ve belirsizliğin umut verici bir strateji olduğunu düşündüğünüzü düşünün. Tüm evler koridorlardan ve odalardan, kapı kolları, ışık anahtarları, vb. İnşaat prensiplerini sıfırdan yeniden tasarlamaya çalışabilir, kapı düğmelerini rubik küpleriyle değiştirebilir, davetsiz misafirleri karıştırmak için yarım yükseklikte tavanlar vb. Yapabilirsiniz. ve en kötüsü hiçbir şey için değildir çünkü içeride bir kez herhangi bir davetsiz misafir gözleriyle etrafa bakabilir ve beynini anlamak için kullanabilir. Hackerlar kalp bulmaca bağımlıları vardır.

Evinizi korumanın çözümü standart olmayan bir yapıya sahip olmak değil, daha iyi kilitlere, güvenli pencerelere, uygun bir güvenlik sistemine vb. Sahip olmaktır. Altınızı gizli bir geçitte gizlemek istemezsiniz, çünkü sonunda Abbot Costello da bu mum çubuğuna yaslanacak ve yanlışlıkla açacak. Altınızı iyi bir gizli kombinasyon ve kurcalama alarmı ile bir kasaya koyun. Bilgisayar eşdeğeri, ortak anahtar şifrelemesi, sınırlı kullanıcı erişim rolleri, izleme sistemleri, açıkta kalan yüzey alanını azaltma, giriş tehdidi vektörü azaltma vb.

Bir bilgisayar sistemini daha belirsiz hale getirme çabaları, sisteminizi sadece destekten daha uzak, daha zor elde etmek güvenlik yamalar, daha güvenli güvenli bir şekilde kullanmak .

Düzenleme: Bazen, bazı güvenlik gerçek güvenliğe ek olarak kullanıldığında belirsizlik kabul edilebilir. Yaygın bir örnek, SSH'yi 30000 gibi bir yüksek bağlantı noktasında çalıştırmaktır. SSH şifreli ve erişim kimlik doğrulamalı bir kimlik doğrulamanın arkasında, bu sizin gerçek güvenliğiniz. Ancak yüksek bir bağlantı noktasına sahip olmak, birisinin hızlı taramalar yapmasıyla başlamayı daha az fark edilir kılar. İşletim sisteminizi gizlemeye çalışmak gibi bundan daha kıvrımlı olan her şey, onu gerçek bir güvenlik önlemi (yamalar konusunda güncel olmak gibi) zorlaştıracak operasyonel bir kabus haline getirir.

5
user1169420

Düşün kullanılabilirlik

  • Yeni sistem yöneticinize Sudo yerine ls, ha7TrUO Yerine RRI6e29 Vurması gerektiğini açıklamaya çalışın ... Evet, sadece öğrenmen gereken bir çeviri listesi var !
  • yerel ağa göz atma da mümkün olmamalı: genel bir görünüm elde etmek için kağıt listesini tutmalısınız !?

  • Tüm kritik komutu yeniden adlandırırsanız, sistem yükseltmesi yapmak için bunu sürmeniz gerekir!

  • Ve Nick2253 yorum) , Gömülü sistem oluşturmaya çalışırsanız, son ürünü yayınlamadan önce şaşkınlık yapın, son ürünü test etmeniz gerekecektir.

    • Her şeyi gizlemek için bağlamak için home made komut dosyası oluşturmanız gerekir.
    • Bir şeyler ters giderse, hata ayıklama zor olur.
    • Bazı hata ayıklama yapabilmek için ev yapımı deobfuscation komut dosyaları oluşturmanız gerekir.
    • Özel geri besleme (günlük dosyaları ile) de deobfuscated olmalıdır.

    Bunu yaptığınızda, yeni potansiyel hatalarla önemli bir çalışma katmanı ekleyeceksiniz.

    Çok az güvenlik iyileştirmesi için daha fazla bilgi edinin

Belirsizlik kendinize zarar verebilir.

Düşün daha düşük seviye

  • Dosyaları yeniden adlandırmaya çalışsanız bile, uygulama ve os düzeyinde işlev görürseniz, tüm bunlar standart kütüphaneler kullanır ve saldırgan ikili çalıştırılabilir dosyalar gönderirse doğrudan çağrılacaktır. Hatta tüm standart kütüphaneleri gizlemeyi düşünebilirsiniz! (Dosya sistemi, ağ protokolleri dahil ...)

  • Değiştirilmemiş çekirdek kullanırken, standart değişkenleri ve ad alanlarını kullanırlar. Yani, gizlenmiş sürüm çekirdek oluşturmalısınız ...

... Sonra her şeyi birbirine bağlayın!

Her şey gizlendiğinde bile, uygulama internet ile uğraşmak zorunda kalacak. Şaşkınlık bu konuda kavramsal hatalar önlemek olmaz!

Belirsizlik Her düzeyde değilse güvenliği artırmaz.

Tam müstehcenlik İnternetle başa çıkabilmek için standart protokollerin kullanılması gereği gerçekten mümkün değil.

Düşün lisans

dağıtınGNU/Linux , kaynak kodunu GNU GENEL KAMU LİSANSI GPLv ve/veya - bölümünde açıklandığı gibi paylaşmanız gerekir. GNU LESSER GENEL HALK LİSANSI LGPLv (kullanılan uygulama ve kütüphanelere bağlı olarak). Bu, her dağıtılmış ürünle birlikte gizleme yönteminin yayınlanmasını gerektirecektir.

İki sorunuza kesin olarak cevap vermek:

Ben uzman bir şeyim, ama çok küçük bir odağı var. Birçok farklı küçük işletme altyapısı üzerinde çalışırken birkaç yıl önce bazı seçimler yaptım. Evrim ve tarih seçimlerimi doğruluyor gibi görünüyor, ama bu sadece benim kişisel isteğim.

Açıklandığı gibi OS gizleme yaygın olarak kullanılıyor mu ve ben sadece karşılaşmadım?

Bu yüzden, hangi oranda şaşırtmanın yaygın olarak kullanıldığını bilmiyorum, ama kullanmıyorum belirsizliğe göre güvenlik = ve tavsiye etmeyin.

Yaygın olarak kullanılmazsa kullanımın pratik veya teknik engelleri nelerdir?

Engel yok! Sadece karşı üretken. Zaman maliyeti hızla devasa hale gelir ve güvenlik iyileştirmesi cazibedir.

Tabii ki, bazı minimal şeyler yapmak:

  • Gerekmiyorsa ssh sunucusunu başlatmayın
  • Sudo kurmayın, doğru izinler, gruplar ve koherant yapısını kullanın.
  • Global altyapınızı güncel tutun !!!

Küçük örnek when light come over obscurity

  • ssh güvenliğini sağlama: iki yönlü.

    • Ssh portunu 22'den 34567'ye taşı

      • hafif ve hızlı bir şekilde yapılır, ancak

      bir saldırgan onları bulursa, son kullanıcı onları bulana kadar bu bağlantı noktasına çok sert bir kuvvet uygulayabilir.

    • güvenlik duvarı yükle

      • Daha güçlü, daha fazla bilgi gerektirir, ama.

      Güncel durumdayken daha güvenli.

4
F. Hauri

İşletim sisteminde Sudo ve ls yerine ha7TrUO ve RRI6e29 komutları varsa, tüm saldırı sınıfları pratik olarak işe yaramaz mı? Bir şekilde uzaktan kök erişimi kazanan bir hacker düşünün - herhangi bir komut bilmiyorlarsa ne yapacaklar?

Daha iyi bir alternatif, bu komutları ilk etapta yüklememek olacaktır. Başlangıçta --- sysV-init veya systemd dışında bir şey olduğu anlamına gelse de, aslında bir Linux çekirdeği çalıştırmak için bir Shell need olduğuna inanmıyorum.

Diğerlerinin de belirttiği gibi, bu güvenlik ve kalkınma kolaylığı arasında bir denge. Ne yazık ki, birçok cihaz üreticisi ikincisine öncekinden çok daha fazla önem veriyor.

Derleyiciler için uygulama oldukça kolay olacaktır. "Bu işlevi ve tüm çağrıları yeniden adlandırın" en basit durumunu ele alalım. Bir OS derleyicisine ve bir uygulama derleyicisine aynı rastgele adları verebilirsiniz ve birbirleriyle konuşabilirler. Ancak uygulamanın güvenliği zayıf olsa ve bash enjeksiyonuna karşı savunmasız olsa bile, bu tür saldırılar sonuç vermez.

derleyicinin yardımına ihtiyacınız olduğundan emin değilim. Bence bunu çoğunlukla tüm sembol adlarına bir randomizasyon uygulamak için linker ¹ değiştirerek yapabilirsiniz. Muhtemelen sadece üretici tarafından bilinen bir tuz ile bir hash fonksiyonu uygulamak yeterli olacaktır. Bunu yapmak için kaynak koduna bile ihtiyacınız olduğundan emin değilim, yani ben düşünüyorum zaten derlenmiş koda mangling uygulayabilirsiniz.

(¹ Bunun bir yalan olduğunu düşünüyorum. Sembol adlarını değiştirmek için nesne kodunu değiştirmeniz gerekebilir, ancak bu yine de daha çok montajcı seviyesine benziyor, yani a) hepsini yapmıyorsunuz hard C/C++/etc derleme bitleri. b) C/C++/herhangi bir kaynak koduna ihtiyacınız yoktur. OTOH Cihaz kodunuz bunun yerine Python gibi bir şeyse bu tür bir şey yapabileceğinizden emin değilim.)

Bununla birlikte, süreci tersine mühendislikle yapmak için hala bazı olasılıklar vardır ve dahası, amacı bozacak tuzu vermedikçe GPL²'yi (özellikle GPLv3) ihlal edebilir.

Aslında, "GPL nedeniyle" muhtemelen bunu görmemenizin ana sebebidir; her bir cihazı yapmaktan başka yararlı bir şekilde uygulamak zor olurdu farklı. OTOH, en azından saldırganların "herhangi Linux x.y.z çalıştıran cihazdaki bir güvenlik açığından yararlanabilmek yerine yalnızca belirli cihazları hedefleyebileceği anlamına gelir.

(² Basitlik için, sadece "GPL" kullanacağım, ancak bunun genellikle L GPL'd şeyler için de geçerli olduğunu unutmayın.)

Bununla birlikte, kaynakları "değiştirdiğiniz" için GPL'nin tuzu yayınlamanızı gerektirmediğini unutmayın. Sembol adı rasgeleleştirme derleme zamanında gerçekleşirse, kaynakları değiştirmediniz değiştirdiniz. Tuzu yayınlamanız gerekmesinin nedeni, GPL'nin kullanıcıların, tuzu bilmedikçe yapamayacakları bir GPL'd kütüphanesinin kendi sürümleri yerine geçmesini gerektirmesidir. (Belirtildiği gibi, GPLv2 ile bundan kaçınabilirsiniz, ancak teknik efektler, GPLv3'ün özellikle adreslemek için yazdığı "yalnızca imzalı yazılımı çalıştır" ile benzerdir.)


Nihayetinde, burada bazı avantaj olabilir, ancak herhangi bir belirli sistemi daha güvenli hale getirmeyeceksiniz ("müstehcenlikten güvenlik" genellikle hayır güvenlik). yapabileceğiniz gerçekleştirdiğiniz şey, birçok sistemi tek bir vektör üzerinden hedeflemeyi zorlaştırmaktır.

4
Matthew

Bunu hacker bakış açısından nasıl gördüğümü söylerdim.

Kesinlikle, tüm programları yeniden adlandıracaksanız - bu benim için işleri daha zor ve daha az rahat hale getirecek, ama ne yapabilirim?

  1. Sistemdeki Shell'e zaten erişebilseydim, sadece busybox'ı (bir ikili dosyadaki tüm temel yardımcı programlar) veya temel işlemler için ihtiyacım olan ikili dosyaların tamamını yüklerdim.

  2. Ayrıcalıkları daha da arttırmak için, suid-root ikili dosyalarını aramam gerekebilir ve bunlardan sadece birkaçı vardır (Sudo, mount, vb.). Hacker bu tür dosyaları yükleyemez (zaten kök değilse). Basit küçük linux sistemimde sadece 24 intihar ikili var. Her birini manuel olarak denemek çok kolay.

Her neyse, katılıyorum, bu bu kutuyu hacklemeyi zorlaştıracak. Bu sistemi kullanmak (kesmek) acı olurdu, ama mümkün. Bilgisayar korsanı saat, gün veya ay boyunca sistemde çalışır ... ancak yönetici/kullanıcı sistemde yıllarca çalışabilir ve ha7TrUO ve RRI6e29 adlarını hatırlayamaz. Belki kimse sistemi hacklemeye bile çalışmaz, ancak yönetici her gün acı çekecektir.

Ancak ... güvenliği çok yüksek, ancak kullanıcı/yönetici için rahatsız ederseniz, genellikle güvenliği daha düşük hale getirirsiniz. 20'den fazla karakter içeren karmaşık şifreleri uygularsanız, büyük olasılıkla şifreler monitördeki notlara yazılır. Sistemi böyle gizlenmiş yapacaksanız - iyi kullanıcılar için üzerinde çalışmak çok zor olacaktır. Ve hayatlarını kolaylaştırmak için bazı şeyler yapmak zorunda kalacaklar. Örneğin, meşgul kutusu ikili dosyalarını yükleyebilirler. Geçici Çölleştirici. Ve bunu unutacaklar veya kasıtlı olarak orada bırakacaklar (çünkü daha sonra kullanmayı planlıyorlar).

1
yaroslaff

Aslında bu olur, çünkü ssh bağlantıları şifrelenir. Bazı temel ikili dosyaların adlarını değiştirmek bundan daha fazlasını yapamaz. Ayrıca çok fazla kaosa neden olur: ör. bu yardımcı programlara dayanan herhangi bir komut dosyası kullanılamaz hale gelir veya bir saldırı vektörü olarak sonuçlanacak bir tür proxy "deobfuscator" olması gerekir. Ancak ben kök oturum açma izin vermeyen, bunun yerine Sudo kullanmaya zorlayan bazı sunucular gördüm. Sudo kullanıcılarının kullanıcı adları biraz gizli kalıyor. Ne kadar güvenli olduğundan emin değilim, ama uzman değilim.

0
galaktycznyseba

Neden tüm kapıların on anahtar deliği yok, bunlardan sadece biri anahtar veya kilit seçimleri için çalışıyor? Cevap: Çoğunlukla rahatsız bir hırsızın zamanının on saniyesine değmez.

Milyonlarca benzersiztek başına oluşturulmuş kaynak kodu işletim sistemleri varsa, saplantı yaygın olabilir. Bununla birlikte pratik bir konu olarak, ortak kullanımda kabaca dört benzersiz kod tabanımız var - olay zamanlaması ile kendileri hakkında tüm sızıntı bilgileri ve yonga üreticilerinin belirli işlemci özelliklerini etkinleştirmek veya erişmek için öngörülen makine bit kodu dizileri verdiği birkaç düşük seviyeli işletim sistemi işlevi için, hepsinin tam olarak aynı kodu içeren kısa dizileri olabilir.

0
Dusty