Switch Hardening: Yan Projelerde Neden Hep İkinci Plana Atılır?

Geçenlerde kendi finansal hesaplayıcılarımın bulunduğu yan ürünümün altyapısını gözden geçirirken fark ettim ki, temel ağ güvenliği konusunda büyük kurumsal yapılarda ne kadar titiz davransam da, kendi “hobi” veya “yan” projelerimde aynı özeni göstermekte zorlanıyorum. Bu sadece benim kişisel bir zaafım değil, yıllardır farklı ekiplerde ve projelerde gözlemlediğim, genel bir “olur o kadar” yaklaşımının yansıması. Özellikle switch hardening gibi, gözle görülür bir özellik eklemeyen ama sistemin temelini oluşturan konular, çoğu zaman “şimdilik kalsın” denilerek ikinci plana atılıyor.

Bu durum, aslında genel bir zihniyetin sonucu: hızlıca bir şeyler ortaya koyma, kullanıcıya değer katma, önce çalışır hale getirme. Kurumsal hayatta, bir bankanın iç platformu ya da büyük bir üretim firmasının ERP’si üzerinde çalışırken, en ufak bir güvenlik açığı bile kabul edilemez. Oysa kendi küçük dünyalarımızda, “kim uğraşacak benim minik sitemle” düşüncesiyle hareket ediyoruz. Bu yazıda, switch hardening’in neden bu kadar göz ardı edildiğini, bunun getirdiği riskleri ve benim kendi deneyimlerimde bu konuya nasıl yaklaştığımı ele almak istiyorum.

Yan Projelerde ‘Hızlı Başla, Hızlı Bitir’ Zihniyeti ve Güvenlik

Yan projeler, doğası gereği hızlı prototipleme ve hızlı iterasyon üzerine kuruludur. İnsanlar, bir fikri hayata geçirmek, geri bildirim almak ve mümkünse para kazanmak isterler. Bu süreçte, “minimum viable product” (MVP) kavramı devreye girer ve bu, genellikle güvenlik gibi “görünmez” katmanların ihmal edilmesine yol açar. Ben de kendi Android spam blocker uygulamamın ilk versiyonlarını geliştirirken, uygulamanın temel fonksiyonelliğine odaklanmış, güvenlik katmanlarını ise hep “sonra hallederim” diye ertelemiştim.

Bu zihniyetin temelinde birkaç faktör yatıyor: zaman kısıtlaması, maliyet ve bilgi eksikliği. Çoğu yan proje tek kişilik veya çok küçük ekiplerle yürütülüyor. Kısıtlı zaman diliminde, bir yandan kod yazıp bir yandan da ağ altyapısının her detayını düşünmek, hatta switch’in CLI’ına girip karmaşık komutlar öğrenmek, çoğu geliştiricinin veya girişimcinin öncelikleri arasında yer almıyor. Mesela, bir arkadaşımın e-ticaret sitesi projesinde, sunucuların VLAN’lara ayrılması veya port güvenlik ayarlarının yapılması yerine, “ürün listeleme sayfasının performansı nasıl artırılır” gibi konulara saatlerini harcadığını gördüm. Temel network prensiplerini bilse de, pratikte bu derinliği uygulamak için ek motivasyon bulamadığını itiraf etti.

Bu durum, aslında bir trade-off meselesi. Bir yandan hızlıca bir şeyler üretmek isterken, diğer yandan sistemin sağlamlığını ve güvenliğini düşünmek gerekiyor. Kurumsal dünyada bu denge, genelde daha fazla kaynak ve uzmanlık ile kurulur. Ancak yan projelerde, bu yük tamamen kişinin omuzlarında. Bu yüzden, çoğu zaman “olur o kadar” diyerek riskleri göz ardı etme eğilimine giriyoruz. Küçük ofis ağlarında temel switch hardening ayarlarının bile yapılmadığını sık görürüm; bu, “küçük balık” sendromunun bir göstergesidir: “Kim bizi hedefleyecek ki?”

Bare-Metal ve Container Ortamlarında Temel Ağ Güvenliğinin Önemi

Ben bare-metal + container hibrit dağıtım modelini seven biriyim. Yani sunucular fiziksel, ama uygulamalar Docker veya benzeri container orkestrasyon araçları içinde çalışıyor. Bu yaklaşım, bana hem esneklik hem de performans sağlıyor. Ancak bu yapıda bile, temel ağ altyapısının güvenliği kritik önem taşıyor. Çünkü container’lar ne kadar izole olursa olsun, altındaki fiziksel ağ katmanı bir zafiyet barındırıyorsa, tüm sistem tehlikeye girebilir. Container’lar arası trafiğe çok katı kurallar uygulanırken, altlarındaki fiziksel switch’lerdeki port güvenlik ayarlarının es geçilmesi sık rastlanan bir durum; bu, aslında tüm mimariyi zayıflatan bir noktadır.

Şöyle düşünelim: bir uygulamanız var, container içinde çalışıyor, network policy’ler ile sıkı bir şekilde izole edilmiş. Harika! Ama ya aynı fiziksel switch’e bağlı başka bir sunucu, ağ içinde bir saldırı başlatırsa? Örneğin, ARP spoofing ile trafiği kendi üzerinden geçirmeye çalışırsa? İşte tam bu noktada, switch hardening devreye giriyor. Container güvenliği, L7 katmanında önemli bir koruma sağlarken, switch hardening L2/L3 katmanında temel bir savunma hattı oluşturuyor. Bu iki katmanı birbirinden bağımsız düşünmek, büyük bir hata olur.

Benim kendi sistemlerimde, özellikle bir yan ürünümün backend’ini barındırdığım VPS üzerinde bile bu prensiplere dikkat etmeye çalışıyorum. Her ne kadar VPS ortamında fiziksel switch’e doğrudan erişimim olmasa da, kendi sanal ağ mimarimde VLAN benzeri segmentasyonlar oluşturarak ve güvenlik duvarı kurallarını sıkı tutarak bu prensibi uygulamaya çalışıyorum. Ancak fiziksel switch’lere sahip olduğumuz ortamlarda, bu sorumluluk doğrudan bize ait. Bir üretim ERP’sinin altyapısını tasarlarken, veritabanı sunucularının ve uygulama sunucularının ayrı VLAN’larda olmasını, bu VLAN’lar arası trafiğin de firewall üzerinden geçmesini şart koştum. Bu, sadece yazılımsal güvenlik değil, aynı zamanda fiziksel ağ katmanında da bir izolasyon sağlamaktı.

Yani, ister container’lar ister sanal makineler kullanın, alttaki fiziksel ağ omurgası sağlam değilse, güvenlik mimariniz kumdan bir kaleye benzer. Bu yüzden, switch hardening, özellikle hibrit ortamlarda, “olmazsa olmaz” bir adımdır ve asla göz ardı edilmemelidir.

DHCP Snooping ve ARP Inspection: İhmal Edilen İlk Savunma Hatları

Yan projelerde en çok göz ardı edilen, ama aslında en temel ağ güvenliği özelliklerinden ikisi DHCP Snooping ve Dynamic ARP Inspection (DAI). Bunlar, özellikle Layer 2 (veri bağlantı katmanı) saldırılarına karşı ilk ve en kritik savunma hatlarını oluşturuyor. Kurumsal ağlarda standart olan bu ayarlar, yan projelerde “zaten küçük bir ağım var, kim ne yapsın” düşüncesiyle genelde açılmaz. Ancak ben kendi deneyimlerimde, bu basit ayarların ne kadar büyük sorunları engelleyebileceğini gördüm.

DHCP Snooping, ağdaki yetkisiz DHCP sunucularının trafik dağıtmasını engeller. Düşünün, bir saldırgan kendi DHCP sunucusunu ağa takıp, tüm cihazlara kendi IP adreslerini dağıtabilir. Bu durumda, tüm ağ trafiği saldırganın üzerinden geçebilir (man-in-the-middle saldırısı). Benzer bir senaryoyu, bir müşteri projesinde, ofis içinden gelen bilinçsiz bir “misafir” cihazın, kendi DHCP sunucusuyla ağdaki diğer cihazların IP adreslerini bozduğunu görmüştüm. Bu, küçük bir ağda bile büyük bir kaosa yol açmıştı. DHCP Snooping bu durumu baştan engellerdi.

# Cisco Switch üzerinde DHCP Snooping yapılandırma örneği
# Global olarak DHCP snooping'i etkinleştir
ip dhcp snooping

# VLAN'lar için etkinleştir (örneğin VLAN 10 ve 20)
ip dhcp snooping vlan 10,20

# Güvenilir portu belirle (DHCP sunucusunun bağlı olduğu port)
interface GigabitEthernet0/1
 ip dhcp snooping trust

# Diğer portlar için rate limit belirle (saniyede en fazla 10 DHCP paketi)
interface GigabitEthernet0/2
 ip dhcp snooping limit rate 10

Dynamic ARP Inspection (DAI) ise ARP spoofing saldırılarına karşı koruma sağlar. ARP (Address Resolution Protocol), IP adreslerini MAC adreslerine eşleştirmek için kullanılır. ARP spoofing’de bir saldırgan, yanlış ARP yanıtları göndererek, trafiği kendi üzerinden geçirebilir. DAI, switch’in DHCP snooping tablosu veya statik ARP girdileri üzerinden IP-MAC eşleşmelerini doğrular ve geçersiz ARP paketlerini düşürür. Bu, özellikle aynı VLAN içinde kritik sunucuların bulunduğu bir ortamda olmazsa olmazdır. Benim bir zamanlar kendi web sunucumun bulunduğu küçük bir ofis ortamında, bu tür bir saldırının test edildiğini ve DAI olmadığı için trafiğin kolayca ele geçirildiğini görmüştüm. Öğrenciyken yaptığım bu hatayı, sonraki projelerimde asla tekrarlamadım.

Bu iki özellik, küçük bir yan proje ağında bile, sistemin temel güvenliğini katbekat artırır. Kurulumları nispeten basit olsa da, “gerek yok” düşüncesiyle çoğu zaman es geçilirler. Oysa benim deneyimimde, bu küçük adımlar, ileride yaşanabilecek büyük sorunların önüne geçer.

VLAN Segmentasyonu ve Zero-Trust Yaklaşımının Yan Projelere Adaptasyonu

Kurumsal ağlarda VLAN (Virtual Local Area Network) segmentasyonu, artık bir standart. Farklı departmanların, sunucuların, kullanıcı gruplarının ağ trafiğini birbirinden ayırmak, hem güvenliği artırır hem de ağ yönetimini kolaylaştırır. Ancak yan projelerde veya küçük ölçekli girişimlerde, “zaten 5 bilgisayarız, ne gerek var VLAN’a” düşüncesiyle bu konuya genellikle soğuk bakılır. Ben ise, kendi yan ürünlerimin backend’lerini barındırdığım ortamlarda bile, en temel seviyede de olsa bir segmentasyon yapmaya çalışıyorum. Bunun arkasında yatan felsefe, Zero-Trust mimarisine olan inancım.

Zero-Trust (Sıfır Güven) yaklaşımı, “ağın içindeki herkes güvenilmezdir” prensibine dayanır. Yani, bir cihaz veya kullanıcı ağa dahil olduğunda otomatik olarak güvenilmez kabul edilir ve erişim sağlaması için kimlik doğrulaması ve yetkilendirmeden geçmesi gerekir. Bu, geleneksel “çevre güvenliği” modelinin aksine, ağın içinden gelebilecek tehditlere karşı da koruma sağlar. Bir üretim firmasının ERP’sinde çalışırken, üretim hatlarının PLC’leri, operatör ekranları ve sunucuların ayrı ayrı VLAN’larda olduğunu gördüm. Bu segmentasyon, olası bir siber saldırının yayılma alanını ciddi şekilde kısıtlıyordu.

Yan projelerde bu seviyede bir karmaşıklık beklemek gerçekçi değil. Ancak, en azından “yönetim ağı” (switch, router erişimi için), “sunucu ağı” ve “kullanıcı/misafir ağı” gibi basit bir segmentasyon bile büyük fark yaratır. Örneğin, benim kendi siteme yaptığım otomasyonların bir kısmı, kendi ayrı VLAN’ında veya izole bir network segmentinde çalışır. Bu sayede, eğer bir otomasyon makinesi tehlikeye girerse, bu durum ana sunucularımı doğrudan etkilemez.

# Basit bir Cisco switch üzerinde VLAN yapılandırma örneği
# VLAN 10 (Sunucu Ağı) oluştur
vlan 10
 name Servers

# VLAN 20 (Yönetim Ağı) oluştur
vlan 20
 name Management

# Port GigabitEthernet0/1'i VLAN 10'a ata (Access Port)
interface GigabitEthernet0/1
 switchport mode access
 switchport access vlan 10

# Port GigabitEthernet0/2'yi VLAN 20'ye ata (Access Port)
interface GigabitEthernet0/2
 switchport mode access
 switchport access vlan 20

Bu tür basit bir VLAN yapısı bile, yan projelerde güvenlik seviyesini önemli ölçüde artırır. Bir zamanlar, kendi yan ürünümün test ortamında, tüm sunucuların aynı düz ağda olduğunu fark ettim. Bir test sunucusundaki zafiyetin, diğer tüm sunuculara kolayca yayılma potansiyeli vardı. Bu durum, bana Zero-Trust’ın sadece kurumsal değil, küçük ölçekli yapılarda da ne kadar önemli olduğunu bir kez daha gösterdi.

VLAN segmentasyonu ve Zero-Trust prensiplerini yan projelere adaptasyonu, “gereksiz karmaşıklık” olarak değil, “temel güvenlik hijyeni” olarak görülmelidir. Bu adımlar, ileride yaşanabilecek potansiyel güvenlik kabuslarının önüne geçebilir ve size uzun vadede çok daha fazla zaman ve emek kazandırır.

Port Security ve MAC Adres Güvenliği: Fiziksel Erişim Kontrolü

Ağ güvenliği denince akla genellikle firewall’lar, IDS/IPS’ler veya yazılımsal zafiyetler gelir. Ancak fiziksel erişim kontrolü, özellikle switch portları üzerindeki güvenlik, çoğu zaman göz ardı edilir. Yan projelerde, evde veya küçük ofis ortamlarında kullanılan switch’ler genellikle “tak çalıştır” modunda kalır. Bu da, herhangi birinin switch portuna bir cihaz takıp ağa erişebileceği anlamına gelir. İşte bu noktada Port Security ve MAC Adres Güvenliği devreye giriyor.

Port Security, bir switch portuna bağlanabilecek MAC adreslerinin sayısını sınırlamanızı ve hatta belirli MAC adreslerini o porta kilitlemenizi sağlar. Bu sayede, yetkisiz bir cihazın ağa bağlanması engellenir. Örneğin, bir port sadece benim sunucumun MAC adresini kabul edecek şekilde ayarlanabilir. Eğer başka bir cihaz takılırsa, o port otomatik olarak kapanır veya bir alarm tetiklenir. Bunu, bir üretim firmasının operatör ekranları için kullandığı switch’lerde uygulamıştım. Her ekranın MAC adresi belirlenmiş, başka bir cihaz takıldığında anında alarm düşüyordu. Bu, üretim hattının güvenliği için kritikti.

# Cisco Switch üzerinde Port Security yapılandırma örneği
interface GigabitEthernet0/3
 switchport mode access
 switchport port-security
 switchport port-security maximum 1           # Sadece 1 MAC adresi kabul et
 switchport port-security mac-address sticky  # İlk öğrenilen MAC adresini kilitle
 switchport port-security violation restrict # İhlal durumunda paketi düşür ve logla

Sticky MAC özelliği, bir portun ilk öğrendiği MAC adresini otomatik olarak konfigürasyona kaydetmesini sağlar. Bu, manuel olarak her port için MAC adresi girmekten çok daha pratiktir. İhlal durumunda restrict modu, paketi düşürür ve bir log mesajı üretir, ancak portu kapatmaz. shutdown modu ise portu tamamen kapatır ve manuel müdahale gerektirir. Ben genellikle restrict modunu tercih ederim çünkü acil durumlarda portun tamamen kapanması yerine bir uyarı almayı tercih ederim.

Kendi yan projelerimde, özellikle backend sunucularımın bulunduğu küçük altyapılarda, kritik portlara Port Security uyguluyorum. Bu, fiziksel erişimim kısıtlı olsa bile, ek bir güvenlik katmanı sağlıyor. Bir keresinde, kendi geliştirdiğim bir göre yönetim uygulamasının backend’ini barındırdığım sunucunun bulunduğu bir ortamda, yanlışlıkla bir test cihazını ana ağa takmıştım. Port Security sayesinde, bu cihazın ağa tam erişim sağlaması engellendi ve anında bir uyarı aldım. Bu tür küçük “kaza” anları bile, bu tip güvenlik önlemlerinin ne kadar değerli olduğunu gösteriyor.

Port Security ve MAC Adres Güvenliği, çoğu zaman “gereksiz görülen” ancak fiziksel ağdaki yetkisiz erişimi ve saldırıları engellemek için kritik öneme sahip özelliklerdir. Yan projelerde, bu basit ayarlar bile ağınızın güvenliğini önemli ölçüde artırabilir.

İzleme ve Anomali Tespiti: “Olur O Kadar” Demeden Önce

Switch hardening ayarlarını yapmak elbette önemli bir adım, ancak iş burada bitmiyor. Yaptığımız yapılandırmaların doğru çalıştığından emin olmak ve ağdaki olası anormallikleri tespit etmek için sürekli izleme şart. Yan projelerde bu konuyu da çoğu zaman es geçiyoruz. “Ayarları yaptım, bitti” diye düşünüyoruz. Oysa biliyorum ki, en iyi yapılandırılmış sistem bile izlenmezse, bir gün mutlaka sürprizlerle karşılaşırız. Logları düzenli izlemediğiniz bir sistemde, ortaya çıkan bir sorunu çok daha geç fark edersiniz.

Switch’lerin loglarını düzenli olarak kontrol etmek, port durumlarını izlemek ve beklenmedik trafik artışlarını veya düşüşlerini takip etmek, potansiyel sorunları erken aşamada yakalamamızı sağlar. Örneğin, bir portun sürekli olarak port-security violation uyarısı vermesi, o portta yetkisiz bir cihazın takılmaya çalışıldığına veya bir saldırı denemesine işaret edebilir. Ben kendi sistemlerimde, bu tür uyarıları anında alabilmek için basit bir log toplama ve alarm sistemi kurdum. Bu, büyük kurumsal yapılardaki tahminsel/anomali tabanlı izleme sistemlerinin çok daha basit bir versiyonu olsa da, işini görüyor.

# Cisco Switch'ten logları izleme komutu
show logging

# Port security ihlallerini görmek için
show port-security interface GigabitEthernet0/3

# Arayüz durumunu ve hatalarını görmek için
show interface GigabitEthernet0/3 status
show interface GigabitEthernet0/3 errors

Bu komutlarla elde ettiğimiz bilgiler, bize ağdaki durum hakkında önemli ipuçları verir. Örneğin, show interface errors çıktısında CRC hatalarının artması, fiziksel bir kablo sorununa işaret edebilir. Veya bir portta beklenmedik bir şekilde fazla broadcast trafiği görülmesi, bir döngüye veya bir cihazdaki hataya işaret edebilir. Bir sunucunun ağ arayüzündeki aşırı paket düşüşü, çoğu zaman switch tarafındaki bir port-security ihlali ve ardından portun kapanma moduna geçmesiyle açıklanabilir; düzenli izleme bu tür sorunları erkenden yakalamayı sağlar.

Özetle, switch hardening ayarlarını yapmak bir başlangıçtır, ancak sürekli izleme ve anomali tespiti, bu ayarların etkinliğini sürdürmek ve potansiyel sorunları proaktif olarak çözmek için hayati öneme sahiptir. “Olur o kadar” demeden önce, sistemin ne durumda olduğunu bilmek, beni her zaman büyük sürprizlerden korumuştur.

Sonuç: Temel Ağ Güvenliğini Göz Ardı Etmek Bir Seçenek Değil

Hem kurumsal hem de kişisel projelerde edindiğim tecrübelerle anladım ki, switch hardening gibi temel ağ güvenliği konularını yan projelerde göz ardı etmek, uzun vadede bize daha çok baş ağrısı yaratıyor. “Hızlı başla, hızlı bitir” zihniyeti, maliyet kaygıları ve bilgi eksikliği gibi faktörler bu durumu tetiklese de, bunun bir mazeret olmadığını defalarca gördüm. Bazen en temel zafiyetler bile en karmaşık sorunlara yol açabiliyor.

Bare-metal ve container hibrit dağıtımlarda dahi, fiziksel ağ katmanının güvenliği, tüm sistemin sağlamlığı için kritik. DHCP Snooping ve Dynamic ARP Inspection gibi basit görünen ama etkili önlemler, ağdaki temel saldırıların önüne geçiyor. VLAN segmentasyonu ve Zero-Trust yaklaşımını yan projelere uyarlamak, kısıtlı kaynaklarla bile önemli güvenlik kazanımları sağlıyor. Port Security ile fiziksel erişim kontrolü, gözden kaçan ama hayati bir katman. Ve tüm bunların üzerine, düzenli izleme ve anomali tespiti, sistemin sürekli güvende kalmasını sağlıyor.

Unutmayalım ki, siber güvenlik bir zincirin halkaları gibidir. Zincirin en zayıf halkası, tüm zincirin gücünü belirler. Çoğu zaman bu zayıf halka, “en temel” ve “en sıkıcı” görünen kısımlar oluyor. Benim kendi finansal hesaplayıcılarımın bulunduğu yan ürünüm için de, Android spam blocker uygulamam için de, bu prensipleri uygulamaya devam ediyorum. Belki kurumsal projelerdeki kadar detaylı ve katı değil, ama “yeterince iyi” bir seviyede.

Net pozisyonum: yan projelerde bile temel ağ güvenliğini hafife almayın. Zaman ayırın, öğrenin ve uygulayın. İnanın bana, bu küçük yatırımlar, ileride sizi çok daha büyük sorunlardan kurtaracak.