In: Genel


giriiş

Bu yazıda, maruz kaldığım önlemlere ek bazı önlemleri incelemek istiyorum. ilk makalem, evimizin içindeki sistemlerin oldukça yüksek düzeyde kontrol ve korunmasını sağlar. İhtiyaçlarına bağlı olarak bunları uygulayıp uygulamama seçimini okuyucuya bırakacağım.

Dahili SSL

Genellikle kişisel projelerin bir parçası oldukları için evdeki dahili ağ içinde çeşitli bir uygulama ekosistemine sahip olduğumuzda, VPN kullanmak gibi basit çözümler lehine dahili güvenliği hafife alırız.

Genellikle unutulan şeylerden biri, dahili hizmetler için SSL sertifikalarının oluşturulmasıdır. Bir SSL sertifikasının kullanışlılığının yalnızca tarayıcıların sertifika yetkilisinin güvenilir olduğunu göstermesini sağlamakla kalmayıp, hizmetler arasındaki iletişimde şifreleme kullanımına izin verdiğini hatırlayalım.

Dahili SSL sertifikalarını yönetmek için sahip olduğumuz olası seçeneklerden bazıları:

  • Komut satırını kullanarak bir SSL sertifikası oluşturma: Bu, en az ilk çalışmayı gerektiren seçenektir. Temel olarak, örneğin OpenSSL kullanarak herhangi bir alan için bir SSL sertifikası oluşturuyoruz. 100 yıl sonra sona erecek bir sertifika bile üretebiliriz. Tabii ki, o sertifikayı dahili hizmetlerimize yüklememiz, tarayıcılara istisnalar eklememiz, böylece uyarıların görünmemesi ve genellikle HTTPS protokolü ile ilişkilendirilen “güven” kısmına sahip olmadığımızı anlamamız gerekecek.
  • Sertifika oluşturma otomatizmlerini uygulayın: Bunlardan biri sertifika robotu bu, teorik olarak SSL sertifikalarının (örneğin Let’s Encrypt’inkiler) oluşturulmasını ve bazen kurulumunu otomatikleştirmeye izin verir. Docker’da bir hizmet olarak bile kurulabilir.

Port Vurma

Bir sunucuya bağlanmak için, o sunucunun içindeki saldırı yüzeyini büyütme konusunda bazı tavizler vermemiz gerektiğini hepimiz biliyoruz. Bu örneklerden biri de portların açılmasıdır. Bir sunucuya güvenli bir şekilde bağlanmak için ona bağlı, açık portlu bir ssh sunucusu kullanabiliriz. Ne zaman bağlanmak istediğimizi bilmediğimiz için bu portu her zaman açık bırakmalıyız.

İstemci ve sunucu arasında önceden anlaşarak bu saldırı yüzeyini azaltabilir miyiz? Liman çalma kavramının cevaplamaya çalıştığı şey budur.

Bu fikri gangsterler ve yasadışı kulüplerle ilgili filmlerde gördük. Herhangi bir işaret olmayan kapalı bir kapıya girmek için belirli sayıda vurmanız gerekir, aksi takdirde açılmazlar. Port çalma durumunda, tüm sunucu portlarını kapatacağız ve sadece belirli bir “isabet” dizisi yaparken, bu durumda, paketleri belirli portlara gönderirken, bir port açacak mıyız (genellikle ssh sunucu portu) .

Ve sunucu, kapısını çaldıklarını nasıl anlayacak? Sadece boş bağlantı noktalarına gelen paketleri günlüğe kaydederek ve söz konusu günlüğü analiz ederek.

Bir ubuntu sunucusu olduğunu varsayarak bağlantı noktası çalmayı yapılandırmak için şunları yürüteceğiz:

 sudo apt install -y knockd

Ardından, yapılandırma dosyasını açacağız:

  sudo nano /etc/knockd.conf
  [options]
          UseSyslog

  [openSSH]
          sequence    = 7000,8000,9000
          seq_timeout = 5
          command     = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
          tcpflags    = syn

  [closeSSH]
          sequence    = 9000,8000,7000
          seq_timeout = 5
          command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
          tcpflags    = syn

Burada gözlemleyebiliriz:

  • sıra: bu kuralı etkinleştirmek için çağrılması gereken portlar sırayla
  • seq_timeout: tüm dizinin yürütülmesi gereken toplam saniye
  • komut: bağlantı noktası açma, iptables yürütme biçiminde
  • OpenSSH, closeSSH: kural tanımlama adları (istediğinizi koyabilirsiniz)

Genellikle bağlantı noktası listesini değiştiririz (belirli protokol her bağlantı noktasında belirtilebilir, örneğin, 2222:udp,5736:tcp) ve uzaktan bağlanırken olası gecikme sorunlarından emin değilsek zaman aşımını artırırız. .

Bu yapılandırıldıktan sonra, “arama” yapmak için birkaç seçeneğimiz var. Mobil bağlantı noktası çalma uygulamaları vardır ve kutudan çıktığı gibi, başka bir makineye yüklenen knockd paketi, aşağıdaki gibi bir komutla çalıştırılabilen vuruntu istemcisi ile birlikte gelir:

knock –v ip_servidor 7000 8000 9000

DNS ve Qname minimizasyonu

Çoğu zaman teorik güvenlikle ilgili kararlar diğer iki kavramla, mahremiyet ve kontrolle ilgilidir.

İyi bildiğimiz gibi, bir tarayıcıda yazdığımız veya çeşitli API’lere eriştiğimiz web adreslerini IP adreslerine çeviren DNS adı verilen İnternet’in varlığına yardımcı olan bazı makineler var.

DNS sahtekarlığı veya DNS önbellek zehirlenmesi adı verilen, bir DNS sunucusunu bir web adresi için yanlış bir IP adresi sunacak şekilde kontrol etmekten veya kandırmaktan oluşan, genellikle orijinal hizmetin kötü niyetli bir kopyasına işaret eden, veriyi ele geçirmek için bir saldırı türü vardır. kullanıcı girer.

Bu saldırıya karşı kendimizi nasıl koruyabiliriz? Olası cevaplardan biri kontroldür.

benimkini hatırlarsak önceki makale, web adresi düzeyinde potansiyel tehditleri engelleyen PiHole adında bir DNS filtreleme sistemimiz var. Ancak aşağıdaki Pi-Hole, standart yapılandırmayla Cloudflare gibi tescilli DNS kullanır.

Bu durumda Unbound ile kendi DNS’imizi kurarak (örneğin Pi-Hole ile aynı makineye veya farklı bir kapsayıcıya) biraz daha fazla kontrol uygulayabiliriz. olduğu için belirli bir kuruluma girmeyeceğim. resmi rehber.

Unbound yapılandırıldığında, zaten kendi DNS’imiz var, ancak daha fazla kontrole sahip olmak için bir seçenek var (ve bu durumda gizlilik de ekliyor), QName Minimization.

Bunu açıklamak için bir örnek kullanacağız. DNS’imiz bilgilerini global TLD (Üst Düzey Etki Alanları) sunucularından alır. Web’i talep ettiğimizi düşünelim foo.bar.combu web adresinin IP’sini almak için aşağıdaki TLD’lere başvurmamız gerektiğini söyleyelim:

  • .com’u bilen TLD 1
  • .bar’ı bilen TLD 2

Normal kullanımda, her iki sunucuya da tam adres olan foo.bar.com’u göndeririz. Ancak QName Minimization’ı etkinleştirirsek, yalnızca her biri için geçerli olan adres yığınını göndeririz:

  • TLD 1, “.com”
  • TLD 2, “.bar”

Bu şekilde TLD’lere gereksiz bilgi göndermekten kaçınır ve ilgili tüm TLD’lerin aranan tam adresi bilmesini de önleriz.

Çözüm

Bu yazıda yerel altyapımız üzerinde bazı gelişmiş koruma ve kontrol noktalarına girmek istedim. Daha önce de belirttiğim gibi, çoğu durumda bu güvenlik ve kontrol düzeyine ulaşmak gerekli değildir (ancak bilgiyi artırmak için iyi bir alıştırma olabilir). Gerekli olduğunu düşündüğünüz durumlarda, umarım size yardımcı olur.

Bir cevap yazın

Ready to Grow Your Business?

We Serve our Clients’ Best Interests with the Best Marketing Solutions. Find out More

How Can We Help You?

Need to bounce off ideas for an upcoming project or digital campaign? Looking to transform your business with the implementation of full potential digital marketing?

For any career inquiries, please visit our careers page here.
[contact-form-7 404 "Bulunamadı"]