Takip et

Squid Proxy Güvenliğinde ACL Sıralaması ve Varsayılan Kapalı Politikanın Önemi

Squid Proxy Güvenliğinde ACL Sıralaması ve Varsayılan Kapalı Politikanın Önemi Squid forward-proxy kullanırken ağ güvenliğinizi en üst düzeye çıkarmak için Erişim Kontrol Listesi (ACL) sıralamasının ve varsayılan kapalı politikanın neden hayati olduğunu merak mı ediyorsunuz?

Squid Proxy Güvenliğinde ACL Sıralaması ve Varsayılan Kapalı Politikanın Önemi

Squid forward-proxy kullanırken ağ güvenliğinizi en üst düzeye çıkarmak için Erişim Kontrol Listesi (ACL) sıralamasının ve varsayılan kapalı politikanın neden hayati olduğunu merak mı ediyorsunuz? Bu makale, yanlış yapılandırmaların yol açabileceği riskleri ve doğru güvenlik stratejilerini adım adım açıklıyor. Ağ yöneticilerinin en sık karşılaştığı güvenlik açıkları genellikle yanlış yapılandırılmış proxy sunucularından kaynaklanır ve Squid, bu bağlamda doğru yapılandırıldığında güçlü bir kalkan, yanlış yapılandırıldığında ise potansiyel bir zafiyet kaynağı olabilir. Güvenli bir ağ ortamı oluşturmak, sadece güvenlik duvarları ve antivirüs yazılımları ile sınırlı kalmayıp, ağın her katmanındaki bileşenlerin doğru yapılandırılmasını gerektirir. İşte bu noktada, bir forward-proxy olarak Squid’in rolü ve özellikle ACL’lerin doğru uygulanması kritik bir önem taşır.

Squid Proxy Nedir ve Ağ Güvenliğinde Neden Kritik Bir Rol Oynar?

Squid, HTTP, HTTPS, FTP ve diğer ağ protokolleri için bir önbellekleme (caching) ve iletme (forwarding) proxy sunucusudur. Genellikle ağ trafiğini optimize etmek, bant genişliği kullanımını azaltmak ve erişim kontrolü sağlamak amacıyla kullanılır. Bir forward-proxy olarak, kullanıcıların internete erişim taleplerini alır, bu talepleri kendi üzerinden geçirir ve yanıtları kullanıcılara geri iletir. Bu süreç, Squid’e ağ trafiği üzerinde kapsamlı bir kontrol yeteneği kazandırır. Ancak bu kontrol yeteneği, aynı zamanda büyük bir sorumluluğu da beraberinde getirir.

Squid’in ağ güvenliğindeki kritik rolü birkaç ana başlık altında toplanabilir:

  • Erişim Kontrolü: Squid, hangi kullanıcıların veya IP adreslerinin hangi web sitelerine veya kaynaklara erişebileceğini belirlemek için güçlü Erişim Kontrol Listeleri (ACL’ler) sunar. Bu, yetkisiz erişimi engellemenin ve ağ kaynaklarını korumanın temel bir yoludur. Örneğin, belirli bir departmanın sadece iş ile ilgili sitelere erişmesine izin verilirken, diğer kategorideki sitelere erişimi engellemek mümkündür.
  • Kötü Amaçlı Yazılım ve Kimlik Avı Koruması: Squid, zararlı web sitelerine veya bilinen kimlik avı (phishing) sitelerine erişimi engelleyerek ağınızı kötü amaçlı yazılımlardan korumaya yardımcı olabilir. Bu, özellikle büyük kuruluşlarda, çalışanların yanlışlıkla zararlı içeriklere maruz kalmasını önlemek için hayati bir önlemdir.
  • Bant Genişliği Yönetimi ve Performans: Squid’in önbellekleme özelliği, sık erişilen web sitelerinin içeriklerini yerel olarak saklayarak bant genişliği kullanımını azaltır ve web sayfalarının daha hızlı yüklenmesini sağlar. Bu, doğrudan bir güvenlik önlemi olmasa da, ağ performansını artırarak genel ağ sağlığına katkıda bulunur.
  • Görünürlük ve Denetim: Tüm internet trafiği Squid üzerinden geçtiği için, ağ yöneticileri trafik günlüklerini (logs) inceleyerek kullanıcı davranışlarını izleyebilir ve potansiyel güvenlik tehditlerini tespit edebilir. Bu günlükler, adli analizler (forensic analysis) için de değerli bilgiler sağlar.

Yanlış yapılandırılmış bir Squid proxy’si ise bir güvenlik açığına dönüşebilir. Örneğin, yanlışlıkla genel internetten proxy sunucusuna erişime izin verilmesi, sunucunun bir açık proxy (open proxy) haline gelmesine ve kötü niyetli kişiler tarafından anonim saldırılar düzenlemek veya spam göndermek için kullanılmasına neden olabilir. Bu durum, kurumunuzun IP adresinin kara listelere girmesine ve itibar kaybına yol açabilir. Dolayısıyla, Squid’in yapılandırma dosyası olan squid.conf içindeki her bir kuralın, özellikle de ACL’lerin ve http_access direktiflerinin titizlikle gözden geçirilmesi ve doğru bir şekilde uygulanması büyük önem taşır. Güvenli bir Squid yapılandırması, ağınızı dış tehditlere karşı korurken, iç ağ politikalarınıza uygun bir internet erişimi sağlamanın temelini oluşturur.

Erişim Kontrol Listeleri (ACL’ler): Squid’in Güvenlik Kalkanı Nasıl Çalışır?

Erişim Kontrol Listeleri (ACL’ler), Squid proxy sunucusunun güvenlik politikasını tanımlayan temel bileşenlerdir. ACL’ler, belirli koşulları tanımlayan kurallar setidir ve bu koşullar, gelen bir isteğin (request) belirli bir özelliğiyle eşleşip eşleşmediğini kontrol etmek için kullanılır. Squid, bir isteği işlerken bu ACL’leri değerlendirir ve hangi erişim kurallarının uygulanacağına karar verir. ACL’ler olmadan, Squid ya herkese tam erişim sağlar ya da kimseye erişim izni vermezdi ki bu da pratik ve güvenli bir çözüm olmazdı.

Squid’de birçok farklı ACL türü bulunur ve her biri belirli bir kriteri kontrol etmek için tasarlanmıştır. İşte en yaygın kullanılan ACL türlerinden bazıları:

  • src (Kaynak IP Adresi): Bu ACL türü, isteği yapan istemcinin IP adresini veya IP adresi aralığını tanımlar. Örneğin, sadece belirli bir iç ağdan gelen isteklere izin vermek için kullanılabilir.
    acl localnet src 192.168.1.0/24

    Bu kural, 192.168.1.0/24 ağındaki tüm IP adreslerini “localnet” olarak tanımlar.

  • dst (Hedef IP Adresi): İsteğin gitmek istediği sunucunun IP adresini veya IP adresi aralığını kontrol eder.
    acl internal_servers dst 10.0.0.0/8

    Bu, dahili sunucu ağını tanımlar.

  • dstdomain (Hedef Alan Adı): İsteğin gitmek istediği web sitesinin alan adını kontrol eder. Belirli sitelere erişimi engellemek veya izin vermek için çok kullanışlıdır.
    acl social_media dstdomain .facebook.com .twitter.com

    Bu kural, sosyal medya sitelerini tanımlar.

  • port (Hedef Bağlantı Noktası): İsteğin kullanmak istediği TCP/UDP bağlantı noktasını kontrol eder. Örneğin, sadece HTTP (80) ve HTTPS (443) portlarına izin vermek için kullanılabilir.
    acl safe_ports port 80 443 21

    Bu kural, güvenli olarak kabul edilen portları listeler.

  • url_regex (URL Düzenli İfade): İsteğin URL’sini düzenli bir ifade (regular expression) kullanarak kontrol eder. Çok esnek olup, belirli desenlere uyan URL’leri engellemek veya izin vermek için kullanılır.
    acl forbidden_keywords url_regex -i porn sex gambling

    Bu kural, URL’lerde belirli anahtar kelimeleri arar.

  • time (Zaman): İsteğin yapıldığı günün saatini veya haftanın gününü kontrol eder. Örneğin, çalışma saatleri dışında belirli sitelere erişimi kısıtlamak için kullanılabilir.
    acl work_hours time M T W H F 09:00-17:00

    Bu kural, hafta içi mesai saatlerini tanımlar.

  • maxconn (Maksimum Bağlantı): Belirli bir kaynaktan gelen eşzamanlı bağlantı sayısını sınırlar. DDoS (Distributed Denial of Service) saldırılarına karşı bir miktar koruma sağlayabilir.

ACL’ler tek başlarına bir şey yapmazlar; ancak http_access direktifleriyle birlikte kullanıldıklarında güçlü erişim kontrol kuralları oluştururlar. http_access direktifleri, tanımlanan ACL’lere dayalı olarak bir isteğe izin verilip verilmeyeceğini (allow) veya reddedilip reddedilmeyeceğini (deny) belirler. Örneğin, http_access allow localnet kuralı, “localnet” ACL’si ile eşleşen isteklere izin verir.

ACL’lerin etkin bir şekilde kullanılması, ağ yöneticilerine kullanıcıların internet erişimini detaylı bir şekilde kontrol etme, istenmeyen içerikleri filtreleme ve potansiyel güvenlik tehditlerini azaltma yeteneği sağlar. Ancak bu gücün doğru bir şekilde kullanılması, ACL’lerin sıralamasına ve genel güvenlik politikasına sıkı sıkıya bağlı kalmayı gerektirir. Yanlış bir sıralama veya eksik bir varsayılan kural, tüm güvenlik çabalarınızı boşa çıkarabilir ve ağınızı savunmasız bırakabilir. Bu nedenle, ACL’lerinizi tanımlarken ve http_access kurallarınızı yazarken son derece dikkatli olmak ve her bir kuralın potansiyel etkisini anlamak hayati önem taşır.

ACL Sıralamasının Güvenlik Üzerindeki Kritik Etkisi: Neden Önemli?

Squid’deki Erişim Kontrol Listeleri (ACL’ler) ve bunlara bağlı http_access kuralları, yapılandırma dosyasında (genellikle squid.conf) yukarıdan aşağıya doğru sırasıyla işlenir. Bu “ilk eşleşme kazanır” (first match wins) prensibi, Squid’in güvenlik politikasının temelini oluşturur ve doğru bir şekilde anlaşılmadığında ciddi güvenlik açıklarına yol açabilir. Bir istek geldiğinde, Squid http_access kurallarını listelediğiniz sırayla kontrol eder ve istekle eşleşen *ilk* kuralı uygular. Bu kural allow ise, istek geçer, deny ise, istek reddedilir ve sonraki kurallara bakılmaz.

Bu sıralama mantığı, güvenlik politikalarınızı tasarlarken stratejik düşünmeyi gerektirir. Örneğin, belirli bir zararlı web sitesine erişimi tamamen engellemek isteyebilirsiniz, ancak aynı zamanda genel internet erişimine de izin vermeniz gerekmektedir. Eğer zararlı siteyi engelleyen kural, genel erişime izin veren kuraldan sonra gelirse, zararlı siteye erişim zaten genel izin kuralı tarafından sağlanmış olacağından, engelleme kuralı hiçbir zaman tetiklenmeyecektir.

Bu durumun önemini daha iyi anlamak için bir vaka analizi yapalım:

Vaka Analizi: X Şirketi ve Yanlış ACL Sıralaması

X Şirketi, çalışanlarının internet erişimini kontrol etmek ve verimliliği artırmak amacıyla bir Squid proxy sunucusu kurdu. Güvenlik ekibi, belirli sosyal medya sitelerine (Facebook, Twitter vb.) ve eğlence sitelerine (YouTube, Netflix vb.) çalışma saatleri içinde erişimi engellemek istedi. Ayrıca, ağdaki belirli geliştirici ekibine, araştırma amaçlı olarak bazı teknik forumlara ve yazılım depolarına tam erişim sağlamaları gerekiyordu.

Yapılandırma dosyası squid.conf aşağıdaki gibi düzenlendi:


# 1. Genel ağ tanımı
acl localnet src 192.168.1.0/24

# 2. Geliştirici ekibinin IP adresi
acl dev_team src 192.168.1.50

# 3. Yasaklı sosyal medya siteleri
acl social_media dstdomain .facebook.com .twitter.com

# 4. Yasaklı eğlence siteleri
acl entertainment dstdomain .youtube.com .netflix.com

# 5. Genel internet erişimine izin ver
http_access allow localnet

# 6. Sosyal medya ve eğlence sitelerini engelle
http_access deny social_media
http_access deny entertainment

# 7. Geliştirici ekibine özel izinler
http_access allow dev_team
http_access deny all
  

İlk bakışta mantıklı gibi görünen bu yapılandırmada, aslında kritik bir güvenlik ve erişim hatası bulunmaktadır. Çalışanlar, sosyal medya ve eğlence sitelerine sorunsuz bir şekilde erişmeye devam etti. Güvenlik ekibi, yapılandırmayı defalarca kontrol etmesine rağmen hatayı bulamadı. Sorun, ACL sıralamasındaydı.

* Kural 5 (http_access allow localnet), localnet içindeki tüm kullanıcılara genel internet erişimine izin veriyordu.
* Kural 6 (http_access deny social_media ve http_access deny entertainment) bu kuraldan sonra geliyordu.

Squid, bir istek geldiğinde (örneğin, bir çalışan Facebook’a erişmek istediğinde), önce Kural 5’e bakıyordu. Çalışan localnet içinde olduğu için, bu kural eşleşiyor ve isteğe izin veriliyordu. Kural 6’ya hiçbir zaman ulaşılamadığı için, sosyal medya ve eğlence sitelerini engelleme politikası tamamen etkisiz kalıyordu. Geliştirici ekibine özel izinler de benzer şekilde Kural 5 tarafından gölgede kalıyordu.

Doğru ACL Sıralaması Nasıl Olmalıydı?

Doğru yaklaşım, daha kısıtlayıcı veya özel kuralları, daha genel kurallardan önce yerleştirmektir. Yani, engelleme kuralları genellikle izin verme kurallarından önce gelmelidir.


# 1. Genel ağ tanımı
acl localnet src 192.168.1.0/24

# 2. Geliştirici ekibinin IP adresi
acl dev_team src 192.168.1.50

# 3. Yasaklı sosyal medya siteleri
acl social_media dstdomain .facebook.com .twitter.com
acl entertainment dstdomain .youtube.com .netflix.com

# 4. Geliştirici ekibine özel izinler (daha özel kural)
http_access allow dev_team

# 5. Sosyal medya ve eğlence sitelerini engelle (daha kısıtlayıcı kural)
http_access deny social_media
http_access deny entertainment

# 6. Genel internet erişimine izin ver (daha genel kural)
http_access allow localnet

# 7. Her şeyi engelle (varsayılan kapalı politikası)
http_access deny all
  

Bu yeni sıralamada:
* Bir geliştirici Facebook’a erişmek istediğinde, Kural 4 (http_access allow dev_team) eşleşir ve eğer bu kural, geliştiricinin erişmesi gereken bir siteyi kapsıyorsa, erişime izin verilir. (Ancak burada da geliştiricilerin sosyal medyaya erişimi engellenmek isteniyorsa, dev_team kuralının kapsamı iyi ayarlanmalı veya deny social_media kuralı dev_team kuralından önce gelmelidir. Bu, karmaşık senaryolarda ne kadar dikkatli olunması gerektiğini gösterir.)
* Normal bir çalışan Facebook’a erişmek istediğinde, Kural 4 eşleşmez. Kural 5 (http_access deny social_media) eşleşir ve erişim reddedilir.
* Normal bir çalışan iş ile ilgili bir siteye erişmek istediğinde, Kural 4 ve Kural 5 eşleşmez. Kural 6 (http_access allow localnet) eşleşir ve erişime izin verilir.
* Kural 7 (http_access deny all) ise her zaman en sonda olmalı ve varsayılan kapalı politikasını sağlamalıdır.

Bu örnek, ACL sıralamasının, bir güvenlik politikasının başarılı bir şekilde uygulanmasında ne kadar kritik olduğunu net bir şekilde göstermektedir. Yanlış bir sıralama, farkında olmadan ağınızı ciddi risklere açabilir veya uyguladığınız politikaları tamamen etkisiz hale getirebilir. Bu nedenle, Squid yapılandırmalarınızı her zaman dikkatlice planlamalı, test etmeli ve en kısıtlayıcı kuralları en başa, en genel kuralları ise sona doğru yerleştirmelisiniz.

Varsayılan Kapalı (Default Deny) Politikası: En Güvenli Yaklaşım Nasıl Uygulanır?

Ağ güvenliğindeki en temel ve en güçlü prensiplerden biri “varsayılan kapalı” (default deny) veya “açıkça izin verilmeyen her şey yasaktır” politikasıdır. Bu prensip, bir sistemin veya ağın, açıkça izin verilmeyen tüm eylemleri veya erişim girişimlerini otomatik olarak reddetmesi gerektiğini savunur. Squid proxy bağlamında, bu, yapılandırma dosyanızdaki http_access kurallarının sonunda her zaman bir http_access deny all kuralının bulunması gerektiği anlamına gelir.

Peki, neden bu kadar önemlidir?

Gelin, bu politikanın önemini ve nasıl uygulanacağını detaylandıralım:

  • Kapsamlı Güvenlik: Varsayılan kapalı politikası, bilinmeyen veya öngörülemeyen tehditlere karşı bir güvenlik ağı oluşturur. Eğer bir erişim kuralı yanlışlıkla atlanır veya bir saldırgan yeni bir yöntem bulursa, varsayılan kapalı politikası, bu erişimin otomatik olarak engellenmesini sağlar. Bu, “beyaz liste” (whitelist) yaklaşımıdır: sadece açıkça izin verilenler geçer, geri kalan her şey reddedilir.
  • Saldırı Yüzeyini Azaltma: Varsayılan kapalı politikası olmadan, Squid’e gelen her istek, açıkça reddedilmediği sürece potansiyel olarak kabul edilebilir. Bu, saldırı yüzeyini büyük ölçüde artırır. deny all kuralı ile, saldırganların sistemdeki bir boşluktan yararlanma şansı önemli ölçüde azalır, çünkü izin verilmeyen hiçbir şey varsayılan olarak geçemez.
  • Yapılandırma Hatalarını Telafi Etme: ACL sıralamasının kritik öneminden bahsetmiştik. Ancak insan hatası her zaman mümkündür. Eğer bir http_access kuralı yanlışlıkla eksik bırakılır veya yanlış sıraya konulursa, deny all kuralı son çare olarak devreye girer ve istenmeyen erişimi engeller. Bu, ciddi bir güvenlik açığının oluşmasını önleyebilir.
  • Denetlenebilirlik ve Yönetim Kolaylığı: Varsayılan kapalı politikası, ağ yöneticilerinin sadece izin vermeleri gereken şeylere odaklanmasını sağlar. Bu, güvenlik politikasını daha anlaşılır ve yönetilebilir hale getirir. Ne kadar çok şeyi açıkça reddetmeye çalışırsanız, o kadar çok şeyi kaçırma riskiniz olur. Bunun yerine, sadece neye ihtiyacınız olduğunu belirlemek ve gerisini engellemek daha basittir.

Uygulama: http_access deny all Kuralı

http_access deny all kuralı, squid.conf dosyasındaki tüm diğer http_access kurallarından sonra, listenin en sonuna eklenmelidir. Bu, Squid’in diğer tüm kuralları kontrol ettikten sonra, eğer hiçbir kural eşleşmezse, isteği otomatik olarak reddedeceği anlamına gelir.

Örnek bir yapılandırma:


# ACL Tanımları
acl localnet src 192.168.1.0/24
acl trusted_users src 192.168.1.10 192.168.1.11
acl restricted_sites dstdomain .malicious-site.com .phishing-scam.net
acl work_hours time M T W H F 09:00-17:00
acl allowed_ports port 80 443

# Erişim Kuralları (Sıra Önemlidir!)

# 1. Kötü amaçlı sitelere erişimi her zaman engelle
http_access deny restricted_sites

# 2. Güvenilir kullanıcılara özel izinler (varsa)
http_access allow trusted_users

# 3. Mesai saatleri içinde yerel ağdan belirli portlara erişime izin ver
http_access allow localnet work_hours allowed_ports

# 4. Yukarıdaki kurallardan hiçbirine uymayan her şeyi engelle
http_access deny all
  

Bu örnekte, http_access deny all kuralı en sonda yer alarak, yukarıdaki kuralların hiçbirine uymayan her türlü erişim isteğini engeller. Bu, ağınız için güçlü bir son savunma hattı oluşturur.

Vaka Analizi: Banka Ağı ve Varsayılan Kapalı Politikası

Bir bankanın iç ağında, yüksek güvenlik standartları gereklidir. Banka, çalışanlarının sadece onaylanmış ve iş ile ilgili web sitelerine erişmesine izin veren bir Squid proxy kullanmaktadır. Eğer http_access deny all kuralı eksik olsaydı, yanlışlıkla veya gözden kaçan bir http_access allow kuralı, çalışanların kısıtlı sitelere erişmesine veya daha da kötüsü, kötü niyetli dış aktörlerin bankanın iç kaynaklarına erişim sağlamasına neden olabilirdi.

Banka, deny all kuralını uygulayarak, sadece açıkça izin verilen sitelere ve hizmetlere erişimi garanti altına alır. Örneğin, sadece finansal işlemler için gerekli olan bankacılık sitelerine ve kurum içi portallara izin verilir. Diğer tüm siteler, sosyal medya, eğlence, kişisel e-posta vb., otomatik olarak engellenir. Bu yaklaşım, bankanın hassas verilerini korumak ve regülasyonlara uymak için vazgeçilmezdir.

Sonuç olarak, varsayılan kapalı politikası, Squid proxy güvenliğinin temel direğidir. Her zaman squid.conf dosyanızın sonunda bir http_access deny all kuralı bulundurarak, ağınızı beklenmedik tehditlere ve yapılandırma hatalarına karşı koruyabilir, böylece güvenli ve kontrol edilebilir bir internet erişim ortamı sağlayabilirsiniz.

Pratikte Squid ACL Yapılandırması: Adım Adım Güvenlik Uygulamaları

Squid’in gücünü tam olarak kullanmak ve ağınızın güvenliğini sağlamak için ACL’leri ve http_access kurallarını doğru bir şekilde yapılandırmak esastır. Bu bölümde, gerçek dünya senaryolarına uygun adım adım bir yapılandırma örneği sunacağız. Amacımız, hem güvenliği hem de işlevselliği bir arada sunan, iyi sıralanmış ve anlaşılır bir squid.conf dosyası oluşturmaktır.

Aşağıdaki örnekte, tipik bir şirket ağında karşılaşılabilecek ihtiyaçları ele alacağız:

  • Yerel ağdaki kullanıcılara genel internet erişimi sağlamak.
  • Belirli kötü amaçlı veya dikkat dağıtıcı sitelere erişimi engellemek.
  • Sadece belirli güvenli portlara (HTTP, HTTPS) izin vermek.
  • Belirli IP adreslerine sahip yöneticilere veya özel kullanıcılara daha geniş erişim sağlamak.
  • Varsayılan kapalı politikasını uygulamak.

İşte squid.conf dosyasında bu senaryoyu uygulayan bir örnek:


# -----------------------------------------------------------------------------
# ACL (Erişim Kontrol Listesi) Tanımlamaları
# Bu bölümde, erişim kontrol kurallarımız için gerekli koşulları tanımlarız.
# -----------------------------------------------------------------------------

# Yerel Ağımızı Tanımla: İç ağımızdaki IP adres aralığı.
# Bu, genellikle şirket içi kullanıcıların bulunduğu ağdır.
acl localnet src 192.168.1.0/24

# Yöneticiler için Özel IP Adresleri:
# Bu IP'ler, genellikle daha fazla erişim yetkisine sahip olacaklardır.
acl admins src 192.168.1.100 192.168.1.101

# Güvenli Portlar: Sadece HTTP (80) ve HTTPS (443) portlarına izin ver.
# Diğer portlar (FTP, SSH vb.) genellikle doğrudan proxy üzerinden geçirilmez.
acl safe_ports port 80 443

# SSL Portu: Sadece HTTPS (443) portuna izin ver.
# CONNECT metodu ile gelen HTTPS istekleri için kullanılır.
acl ssl_ports port 443

# CONNECT Metodu: Sadece güvenli portlara CONNECT metoduna izin ver.
# Bu, HTTPS trafiği için tünelleme sağlar.
acl CONNECT method CONNECT

# Yasaklı Siteler: Çalışanların erişmesini istemediğimiz siteler.
# Bu listeyi şirket politikalarınıza göre genişletebilirsiniz.
acl forbidden_sites dstdomain .facebook.com .twitter.com .youtube.com .gambling.com

# Kötü Amaçlı Siteler: Bilinen zararlı veya kimlik avı siteleri.
# Bu listeyi güncel tutmak için harici kaynaklar kullanılabilir.
acl malicious_sites dstdomain .malware-domain.com .phishing-scam.net

# -----------------------------------------------------------------------------
# http_access Kuralları
# Bu bölümde, tanımladığımız ACL'leri kullanarak erişim izinlerini belirleriz.
# Sıralama KRİTİKTİR! İlk eşleşen kural uygulanır.
# -----------------------------------------------------------------------------

# 1. CONNECT metoduna sadece SSL portları için izin ver.
# Bu, HTTPS trafiğinin tünellenmesi için gereklidir.
http_access allow CONNECT ssl_ports

# 2. Yasaklı ve kötü amaçlı sitelere erişimi her zaman engelle.
# Bu kurallar, diğer izin veren kurallardan önce gelmelidir.
http_access deny malicious_sites
http_access deny forbidden_sites

# 3. Yöneticilere tüm (veya daha geniş) erişime izin ver.
# Yöneticiler genellikle kısıtlamaların dışında tutulur.
http_access allow admins

# 4. Yerel ağdaki kullanıcılara güvenli portlar üzerinden erişime izin ver.
# Bu, genel internet erişimini sağlar.
http_access allow localnet safe_ports

# 5. Güvenli olmayan portlara erişimi engelle.
# Eğer yukarıdaki safe_ports kuralı eşleşmediyse, diğer portları engelle.
http_access deny !safe_ports

# 6. Varsayılan Kapalı Politikası: Yukarıdaki kurallardan hiçbirine uymayan her şeyi engelle.
# Bu kural, her zaman en sonda olmalıdır ve güvenlik için hayati öneme sahiptir.
http_access deny all

# -----------------------------------------------------------------------------
# Diğer Genel Ayarlar (Örnek)
# Bu bölüm, proxy'nin diğer davranışlarını yapılandırır.
# -----------------------------------------------------------------------------

# Proxy'nin dinleyeceği port (genellikle 3128 veya 8080).
http_port 3128

# Önbellek dizini ve boyutu (örnek).
# cache_dir ufs /var/spool/squid 100 16 256

# Önbelleği temizlemek için cache_dir satırını yorum satırı yapın ve Squid'i yeniden başlatın.
# Daha sonra yorumu kaldırıp tekrar başlatabilirsiniz.

# Hata sayfalarını özelleştirmek için.
# error_directory /usr/share/squid/errors/Turkish

# Proxy'nin görünen ana bilgisayar adı.
# visible_hostname myproxy.example.com

# Proxy'nin yönetici e-posta adresi.
# cache_mgr webmaster@example.com

# -----------------------------------------------------------------------------
# Yapılandırma Sonu
# -----------------------------------------------------------------------------
  

Yapılandırma Adımları ve Açıklamalar:

1. ACL Tanımları: Öncelikle, erişim politikamız için gerekli olan tüm koşulları acl direktifleriyle tanımlıyoruz. localnet, admins, safe_ports, ssl_ports, CONNECT, forbidden_sites ve malicious_sites gibi ACL’ler, daha sonra http_access kurallarında kullanılmak üzere mantıksal gruplamalar oluşturur. !safe_ports gibi tersine çevrilmiş ACL’ler de kullanılabilir.
2. http_access Kuralları: Burası, güvenlik politikasının kalbinin attığı yerdir. Kuralların sırası son derece önemlidir:
* Özel İzinler (CONNECT metoduna izin): http_access allow CONNECT ssl_ports kuralı, HTTPS trafiğinin tünellenmesi için gereklidir ve genellikle deny all kuralından önce gelmelidir.
* En Kısıtlayıcı Kurallar (Engellemeler): http_access deny malicious_sites ve http_access deny forbidden_sites gibi engelleme kuralları, diğer tüm izin verme kurallarından önce gelmelidir. Bu, zararlı veya istenmeyen sitelere erişimin kesinlikle engellenmesini sağlar.
* Özel İzinler (Yöneticiler): http_access allow admins kuralı, belirli kullanıcılara veya IP’lere genel kuralların dışında özel erişim sağlamak için kullanılır. Bu, engelleme kurallarından sonra, ancak genel izin verme kurallarından önce gelmelidir.
* Genel İzinler: http_access allow localnet safe_ports kuralı, yerel ağdaki genel kullanıcılara güvenli portlar üzerinden internet erişimi sağlar. Bu, en geniş kapsamlı izin verme kuralıdır.
* Kalan Portları Engelle: http_access deny !safe_ports kuralı, güvenli olarak tanımlanmayan tüm portlara erişimi engeller. Bu, güvenli portlar dışındaki potansiyel güvenlik açıklarını kapatır.
* Varsayılan Kapalı Politikası: En sona http_access deny all kuralı eklenir. Bu, yukarıdaki hiçbir kurala uymayan tüm isteklerin reddedilmesini sağlar ve ağ güvenliği için vazgeçilmez bir son savunma hattıdır.
3. Diğer Genel Ayarlar: http_port, cache_dir, visible_hostname gibi diğer ayarlar, proxy’nin genel davranışını ve performansını etkiler. Bu ayarlar güvenlik ACL’leriyle doğrudan ilgili olmasa da, proxy’nin doğru çalışması için önemlidir.

Test ve Doğrulama:

Yapılandırma değişikliklerinden sonra, Squid servisini yeniden başlatmadan önce squid -k parse veya squid -f /etc/squid/squid.conf -k parse komutunu kullanarak yapılandırma dosyanızda sözdizimi hataları olup olmadığını kontrol edin. Herhangi bir hata yoksa, systemctl restart squid (veya service squid restart) komutuyla servisi yeniden başlatın.

Yeniden başlatmanın ardından, farklı kullanıcı gruplarından (örneğin, normal bir kullanıcı ve bir yönetici) ve farklı sitelere (yasaklı, izinli, bilinmeyen) erişim denemeleri yaparak yeni güvenlik politikanızın beklendiği gibi çalışıp çalışmadığını test edin. Bu test süreci, olası yanlış yapılandırmaları veya gözden kaçan detayları ortaya çıkaracaktır. Unutmayın, güvenlik sürekli bir süreçtir ve yapılandırmalarınızı düzenli olarak gözden geçirmek ve güncellemek önemlidir.

Gelişmiş ACL Teknikleri ve Yaygın Hatalardan Kaçınma Yolları

Squid’in ACL sistemi oldukça esnektir ve basit IP tabanlı kontrollerin ötesinde gelişmiş güvenlik senaryolarını destekler. Ancak bu esneklik, yanlış yapılandırma riskini de beraberinde getirir. Bu bölümde, daha karmaşık güvenlik ihtiyaçlarını karşılamak için kullanabileceğiniz bazı ileri düzey ACL tekniklerine ve sık yapılan hatalardan nasıl kaçınabileceğinize odaklanacağız.

Gelişmiş ACL Teknikleri:

1. Dış ACL Türleri (external_acl_type):
Squid, yerleşik ACL’lerinin yanı sıra, harici programlar aracılığıyla kullanıcı kimlik doğrulaması veya karmaşık veritabanı sorguları gibi özelleştirilmiş erişim kontrolleri yapmanıza olanak tanır. Örneğin, bir LDAP sunucusuna veya Active Directory’ye bağlanarak kullanıcıların kullanıcı adı ve şifreleriyle kimlik doğrulaması yapmasını sağlayabilirsiniz.


    # Harici bir kimlik doğrulama programı tanımla (örneğin, LDAP sorgusu yapan bir script)
    external_acl_type ldap_auth %LOGIN /usr/lib/squid/basic_ldap_auth -b "dc=example,dc=com" -D "cn=squid,dc=example,dc=com" -w "password" -f "uid=%s" ldap_server

    # Kimlik doğrulaması gerektiren kullanıcılar
    acl authenticated_users external ldap_auth

    # Sadece kimliği doğrulanmış kullanıcılara izin ver
    http_access allow authenticated_users
      

Bu, kullanıcı bazında erişim kontrolü sağlamak için çok güçlü bir yöntemdir ve IP adresleri sürekli değişen mobil cihazlar veya uzaktan çalışanlar için idealdir.

2. Zaman Tabanlı ACL’ler (time):
Belirli zaman dilimlerinde veya haftanın belirli günlerinde erişimi kısıtlamak veya izin vermek için time ACL’sini kullanabilirsiniz. Bu, çalışma saatleri içinde sosyal medya erişimini engellemek gibi senaryolar için mükemmeldir.


    acl work_hours time M T W H F 09:00-17:00
    acl social_media dstdomain .facebook.com .twitter.com

    http_access deny social_media !work_hours  # Mesai saatleri dışında sosyal medyaya izin ver
    http_access deny social_media work_hours   # Mesai saatleri içinde sosyal medyayı engelle
      

Bu örnekte, !work_hours (mesai saatleri dışı) ile work_hours (mesai saatleri içi) kombinasyonları, politikayı daha esnek hale getirir.

3. URL Yeniden Yazma Programları (url_rewrite_program):
Squid, bir kullanıcının talep ettiği URL’yi değiştirmek için harici programlar kullanabilir. Bu, kullanıcıları belirli bir engelleme sayfasına yönlendirmek, URL’leri temizlemek veya belirli parametreleri eklemek gibi amaçlar için kullanılabilir.


    # URL yeniden yazma programını tanımla
    url_rewrite_program /usr/local/bin/my_rewrite_script.sh

    # Rewrite programına gönderilecek maksimum istek sayısı
    url_rewrite_children 5 startup=1 idle=1

    # Rewrite programının zaman aşımı
    url_rewrite_concurrency 0
      

my_rewrite_script.sh dosyası, gelen URL’leri işleyerek yeni bir URL döndüren bir betik olacaktır.

Yaygın Hatalardan Kaçınma Yolları:

1. http_access deny all Kuralını Unutmak veya Yanlış Yere Koymak:
Bu, en sık yapılan ve en tehlikeli hatadır. deny all kuralının eksik olması, yukarıdaki hiçbir kuralın eşleşmediği tüm isteklere örtülü olarak izin verileceği anlamına gelir ki bu da proxy’nizi bir açık proxy haline getirir. Bu kural her zaman http_access listesinin en sonunda olmalıdır.

2. http_access allow all Kuralını Çok Erken Koymak:
Eğer http_access allow all kuralını listenin başına yakın bir yere koyarsanız, bu kural, daha sonra gelen tüm deny kurallarını geçersiz kılacaktır. Örneğin, yasaklı siteleri engelleyen kurallardan önce gelirse, o sitelere erişim sağlanacaktır. allow all kuralı genellikle kullanılmamalıdır; bunun yerine, varsayılan kapalı politikası (deny all) ile birlikte açıkça izin verilenleri belirtmek (allow specific_acl) çok daha güvenlidir.

3. Örtüşen ACL’ler ve Beklenmedik Davranışlar:
Birden fazla ACL tanımladığınızda ve bunlar birbirini kapsadığında veya çeliştiğinde, beklenen davranış yerine farklı bir sonuç elde edebilirsiniz. Örneğin, hem localnet hem de restricted_users ACL’leri aynı IP aralığını içeriyorsa ve farklı http_access kurallarına bağlıysa, sıralama kritik hale gelir. Her ACL’nin ve kuralın tam olarak neyi hedeflediğini anlamak ve çakışmaları önlemek için dikkatli olmak gerekir.

4. Yapılandırmayı Test Etmemek:
Yeni bir yapılandırma veya değişiklik yaptıktan sonra, squid -k parse komutuyla sözdizimi hatalarını kontrol etmek yeterli değildir. Farklı senaryoları (izin verilen, reddedilen, özel kullanıcılar) manuel olarak test etmek, politikanızın gerçekten beklendiği gibi çalıştığından emin olmanın tek yoludur.

5. ACL’leri Yetersiz Tanımlamak:
Sadece IP adreslerine güvenmek yeterli olmayabilir. Örneğin, src ACL’si VPN kullanan veya dinamik IP alan kullanıcılar için yetersiz kalabilir. Bu durumlarda, external_acl_type ile kullanıcı kimlik doğrulaması gibi daha sağlam yöntemlere başvurmak gerekir.

6. Güvenlik Güncellemelerini İhmal Etmek:
Squid, sürekli gelişen bir yazılımdır ve güvenlik açıkları zaman zaman keşfedilebilir. Squid sunucunuzu düzenli olarak güncellemek, bilinen zafiyetlere karşı korunmanızı sağlar.

Bu ileri düzey teknikler ve dikkat edilmesi gereken noktalar, Squid’in sadece bir önbellekleme aracı olmaktan öte, ağ güvenliğiniz için güçlü bir erişim kontrol mekanizması olduğunu göstermektedir. Doğru uygulama ve sürekli dikkat ile Squid, ağınızı birçok tehdide karşı koruyabilir.

Vaka Analizi: Yanlış ACL Yapılandırmasının Yıkıcı Sonuçları

ACL sıralamasının ve varsayılan kapalı politikasının önemini vurgulamak için, gerçek hayattan esinlenilmiş bir vaka analizi sunalım. Bu senaryo, basit bir hatanın bir şirketin itibarını ve finansal durumunu nasıl tehlikeye atabileceğini göstermektedir.

Vaka: “TeknoÇözüm A.Ş.” ve Açık Proxy Faciası

TeknoÇözüm A.Ş., orta ölçekli bir yazılım geliştirme şirketidir. Geliştiricilerin internet erişimini optimize etmek ve bant genişliğini korumak amacıyla bir Squid proxy sunucusu kurmaya karar verdiler. Şirketin yeni başlayan bir sistem yöneticisi olan Can, squid.conf dosyasını yapılandırmakla görevlendirildi. Can, internet üzerindeki çeşitli örnekleri inceleyerek bir yapılandırma oluşturdu.

Can’ın ilk squid.conf yapılandırması aşağıdaki gibiydi:


# ACL Tanımları
acl localnet src 192.168.1.0/24  # Şirket içi ağ
acl office_hours time M T W H F 09:00-18:00
acl social_media dstdomain .facebook.com .twitter.com

# http_access Kuralları
http_access allow localnet  # Şirket içi ağa izin ver
http_access deny social_media office_hours  # Mesai saatlerinde sosyal medyayı engelle

# Diğer ayarlar...
http_port 3128
  

Can, yapılandırmanın yeterli olduğunu düşündü. Şirket içinden sosyal medya erişimi mesai saatleri içinde engelleniyordu ve genel internet erişimi sağlanıyordu. Ancak Can’ın gözden kaçırdığı kritik bir nokta vardı: http_access deny all kuralı eksikti ve http_access allow localnet kuralı çok genel bir şekilde tanımlanmıştı.

Felaketin Başlangıcı:

Birkaç hafta sonra, TeknoÇözüm A.Ş.’nin IT ekibi, şirket IP adreslerinin çeşitli spam ve kötü amaçlı yazılım dağıtımı kara listelerine girdiğini fark etti. Ayrıca, şirket ağı üzerinden kaynaklandığı anlaşılan yoğun ve şüpheli dış ağ trafiği raporları almaya başladılar. Şirketin internet bağlantısı yavaşlamış, hatta bazı durumlarda tamamen kesintiye uğramıştı.

Yapılan detaylı incelemede, Can’ın yapılandırdığı Squid proxy sunucusunun bir “açık proxy” (open proxy) haline geldiği anlaşıldı. http_access allow localnet kuralı, sadece localnet ACL’si ile eşleşen isteklere izin vermesi gerekirken, http_access deny all kuralının eksik olması ve localnet tanımının sadece kaynak IP’ye odaklanması, dışarıdan gelen ve herhangi bir deny kuralına takılmayan tüm isteklere örtülü olarak izin verilmesine neden olmuştu.

Kötü niyetli aktörler, internet üzerinde port taraması yaparak TeknoÇözüm A.Ş.’nin Squid proxy sunucusunu keşfetmiş ve onu, IP adreslerini gizleyerek spam göndermek, kimlik avı saldırıları düzenlemek ve hatta DDoS saldırılarına katılmak için kullanmaya başlamıştı. Şirket, farkında olmadan kötü niyetli faaliyetlerin bir parçası haline gelmişti.

Yıkıcı Sonuçlar:

  • İtibar Kaybı: Şirketin IP adresleri kara listelere girdiği için, müşterilere gönderilen e-postalar spam olarak işaretlenmeye başlandı. Bu durum, şirketin profesyonel imajına ciddi zarar verdi ve güvenilirliklerini sorgulattı.
  • Finansal Zarar: Kara listelerden çıkmak, ciddi bir çaba ve zaman gerektirdi. Ayrıca, aşırı bant genişliği kullanımı nedeniyle internet servis sağlayıcısından ek ücretler talep edildi. İş kesintileri ve verimlilik kaybı da finansal olarak büyük bir yük oluşturdu.
  • Güvenlik Açığı: Proxy sunucusunun kötüye kullanılması, şirket ağının genel güvenliğini tehlikeye attı. İç ağa yönelik potansiyel saldırılar için bir köprü görevi görmesi riski ortaya çıktı.
  • Operasyonel Kesintiler: İnternet bağlantısındaki sürekli yavaşlama ve kesintiler, geliştirme ekiplerinin çalışmalarını aksattı, proje teslim tarihlerini geciktirdi ve genel işleyişi felç etti.

Alınan Dersler ve Çözüm:

Bu olaydan sonra, TeknoÇözüm A.Ş., güvenlik politikalarını kökten değiştirdi. Can, deneyimli bir güvenlik uzmanının rehberliğinde squid.conf dosyasını yeniden yapılandırdı. Yeni yapılandırma, aşağıdaki temel prensiplere sıkı sıkıya bağlı kaldı:

1. Varsayılan Kapalı Politikası: http_access deny all kuralı, tüm http_access kurallarının en sonuna eklendi. Bu, açıkça izin verilmeyen her şeyin otomatik olarak reddedilmesini sağladı.
2. ACL Sıralamasının Önemi: Daha kısıtlayıcı kurallar (örneğin, kötü amaçlı siteleri engelleme), daha genel izin verme kurallarından önce yerleştirildi.
3. Spesifik İzinler: http_access allow kuralları, yalnızca kesinlikle gerekli olan erişimlere izin verecek şekilde çok daha spesifik hale getirildi (örneğin, http_access allow localnet safe_ports).
4. Dış Erişim Engeli: Proxy sunucusuna dış ağlardan gelen erişim, güvenlik duvarı kuralları ve Squid ACL’leri ile tamamen engellendi.

Bu vaka analizi, küçük bir yapılandırma hatasının bile ne kadar büyük ve yıkıcı sonuçlara yol açabileceğini açıkça göstermektedir. Squid gibi güçlü bir aracın potansiyeli, ancak doğru ve dikkatli bir yapılandırma ile tam olarak ortaya çıkarılabilir. Güvenlik, “her şey varsayılan olarak kapalıdır” ilkesiyle başlar ve bu ilke, ACL sıralamasıyla birleştiğinde, sağlam bir ağ savunmasının temelini oluşturur.

Sonuç: Güvenli Bir Ağ İçin Squid’in Gücünü Doğru Kullanın

Squid forward-proxy, ağ trafiğini yönetmek, performansı artırmak ve özellikle erişim kontrolü sağlamak için inanılmaz derecede güçlü ve esnek bir araçtır. Ancak bu gücün, doğru bir şekilde yapılandırılmadığında ciddi güvenlik risklerine dönüşebileceğini bu makale boyunca detaylıca inceledik. Ağ güvenliğinizin, Squid proxy’nizin Erişim Kontrol Listeleri (ACL’ler) ve varsayılan kapalı politikasıyla doğrudan ilişkili olduğunu artık biliyorsunuz.

ACL sıralamasının “ilk eşleşme kazanır” prensibi, güvenlik politikanızın uygulanmasında hayati bir rol oynar. Yanlış bir sıralama, engellemek istediğiniz trafiğin kolayca geçmesine izin verebilirken, izin vermek istediğiniz trafiği de gereksiz yere engelleyebilir. Bu nedenle, daha kısıtlayıcı veya özel kuralları her zaman daha genel kurallardan önce yerleştirmek, ağınızı istenmeyen erişimlere karşı korumanın temelidir.

Öte yandan, “varsayılan kapalı” (default deny) politikası, yani http_access deny all kuralının squid.conf dosyasının en sonunda yer alması, ağ güvenliğiniz için bir son savunma hattı oluşturur. Bu kural, açıkça izin verilmeyen her türlü erişim girişimini otomatik olarak reddederek, bilinmeyen tehditlere ve yapılandırma hatalarına karşı sizi korur. Bu prensip, güvenli bir sistemin temelini oluşturur: sadece açıkça izin verilenler geçerlidir, geri kalan her şey engellenir.

TeknoÇözüm A.Ş. vaka analizinde gördüğümüz gibi, bu temel prensiplerin göz ardı edilmesi, bir şirketin itibarını, finansal durumunu ve operasyonel sürekliliğini tehlikeye atabilecek yıkıcı sonuçlara yol açabilir. Bu tür senaryolardan kaçınmak için, Squid yapılandırmalarınızı titizlikle planlamalı, adım adım uygulamalı, farklı senaryoları kapsayan kapsamlı testler yapmalı ve düzenli olarak gözden geçirmelisiniz.

Unutmayın ki güvenlik sürekli bir süreçtir. Ağınızın ihtiyaçları değiştikçe, Squid yapılandırmalarınızı da buna göre güncellemeniz gerekecektir. Gelişmiş ACL tekniklerini öğrenmek ve yaygın hatalardan kaçınmak, Squid’i bir güvenlik kalkanı olarak en üst düzeyde kullanmanıza yardımcı olacaktır. Squid, doğru ellerde, ağınızı kötü niyetli aktörlerden korurken, kullanıcılarınıza verimli ve güvenli bir internet deneyimi sunabilen güçlü bir müttefiktir.

Sıkça Sorulan Sorular

  • S1: Squid ACL’leri neden bu kadar önemli?
    C1: Squid ACL’leri (Erişim Kontrol Listeleri), hangi kullanıcıların, hangi ağlardan, hangi web sitelerine veya kaynaklara, hangi portlar üzerinden erişebileceğini tanımlayan kurallar setidir. Bu kurallar, ağ güvenliğinizi sağlamak, yetkisiz erişimi engellemek, zararlı içerikleri filtrelemek ve ağ trafiğini yönetmek için temeldir. Doğru yapılandırılmadığında, ağınızı güvenlik açıklarına karşı savunmasız bırakabilirler.
  • S2: http_access deny all kuralını nereye koymalıyım?
    C2: http_access deny all kuralı, squid.conf dosyasındaki tüm diğer http_access kurallarından sonra, listenin en sonuna konulmalıdır. Bu, Squid’in diğer tüm kuralları kontrol ettikten sonra, hiçbir kural eşleşmezse isteği otomatik olarak reddetmesini sağlar ve “varsayılan kapalı” güvenlik politikasını uygular.
  • S3: ACL sıralamasında hata yaparsam ne olur?
    C3: Squid, http_access kurallarını yukarıdan aşağıya doğru sırasıyla işler ve istekle eşleşen *ilk* kuralı uygular. Eğer daha genel bir izin verme kuralı (örneğin, http_access allow localnet) daha kısıtlayıcı bir engelleme kuralından (örneğin, http_access deny social_media) önce gelirse, engelleme kuralı hiçbir zaman tetiklenmez ve kullanıcılar engellenmesi gereken sitelere erişebilir. Bu, ciddi güvenlik açıklarına yol açabilir.
  • S4: Squid’i daha güvenli hale getirmek için başka neler yapabilirim?
    C4: Squid’i daha güvenli hale getirmek için şunları yapabilirsiniz: düzenli olarak güncelleyin, dış kimlik doğrulama (LDAP/Active Directory) kullanın, şeffaf proxy yerine açık proxy olarak yapılandırın ve sadece belirli portlarda dinlemesini sağlayın, güvenlik duvarı kurallarıyla Squid’e dışarıdan erişimi kısıtlayın, detaylı günlük tutun ve bu günlükleri düzenli olarak izleyin.
  • S5: external_acl_type ne işe yarar?
    C5: external_acl_type, Squid’in harici programlar veya betikler aracılığıyla özelleştirilmiş erişim kontrolleri yapmasına olanak tanıyan gelişmiş bir ACL türüdür. Bu, kullanıcı kimlik doğrulaması (örneğin, LDAP veya Active Directory entegrasyonu), veritabanı sorguları veya diğer karmaşık mantıklar kullanarak erişim kararları almak için kullanılabilir. Bu sayede, IP adreslerinden bağımsız olarak kullanıcı bazında daha esnek ve güçlü erişim kontrolleri sağlayabilirsiniz.
  • #SquidProxy
  • #AğGüvenliği
  • #ACL
  • #ForwardProxy
  • #SiberGüvenlik
  • #ProxyServer
Yorumlar
İçeriği beğendiniz mi? Bir tartışma başlatın veya görüşlerinizi paylaşın.
Yorum Yaz

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Gönder

E-posta Bülteni
Yazılım Topluluğuna Katılın
En son güncellemeleri, yaratıcı ipuçlarını ve özel kaynakları doğrudan e-posta kutunuza alın. Tasarım ve inovasyonun geleceğini birlikte keşfedelim.
Mobil sürümden çık