SSH Lockout: Port 22’yi Kapatma Kararımın Hikayesi

SSH Lockout: Port 22’yi Kapatma Kararımın Hikayesi

Bir sunucunun kapıları, dijital dünyadaki evinizin girişine benzer. Bu kapılardan biri olan Port 22, SSH (Secure Shell) protokolü sayesinde uzaktan güvenli erişim imkanı sunar. Ancak bu kolaylık, doğru yapılandırılmadığında kabusa dönüşebilir. Bu makalede, benim yaşadığım SSH lockout (erişim engelleme) deneyimini, bu deneyimin beni Port 22’yi sonsuza dek kapatmaya nasıl ittiğini ve sunucularınızı siber tehditlere karşı nasıl daha güvenli hale getirebileceğinizi adım adım keşfedeceğiz. Kendi tecrübelerimden yola çıkarak, sıfırdan başlayıp ileri seviyeye kadar SSH güvenliği stratejilerini inceleyecek ve bir daha asla aynı hataya düşmemeniz için pratik çözümler sunacağım.

SSH Nedir ve Neden Hayati Öneme Sahiptir?

SSH, yani Secure Shell (Güvenli Kabuk), internet üzerinden iki bilgisayar arasında şifrelenmiş bir bağlantı kurmak için kullanılan bir ağ protokolüdür. Temel amacı, güvensiz bir ağ üzerinden bile güvenli bir şekilde komut satırı (CLI – Command Line Interface) erişimi sağlamaktır. Sunucu yöneticileri, geliştiriciler ve hatta bazı ileri düzey kullanıcılar için SSH, uzak sunuculara erişimin, dosya transferlerinin ve komut çalıştırmanın olmazsa olmaz aracıdır. Bu protokol, verilerinizi şifreleyerek üçüncü şahısların (man-in-the-middle saldırıları gibi) bağlantıyı dinlemesini veya müdahale etmesini engeller. Bu sayede, hassas bilgilerinizin ve komutlarınızın güvenliği sağlanmış olur.

SSH’in çalışma prensibi oldukça basittir ancak altında yatan kriptografik (şifreleme bilimi) mekanizmalar oldukça güçlüdür. Bir SSH bağlantısı kurulduğunda, istemci (sizin bilgisayarınız) ve sunucu (erişmek istediğiniz uzak makine) arasında bir el sıkışma (handshake) süreci başlar. Bu süreçte, sunucu kimliğini kanıtlar ve bir oturum anahtarı (session key) oluşturulur. Bu anahtar, bağlantı süresince tüm iletişimi şifrelemek için kullanılır. Kimlik doğrulama genellikle parola veya SSH anahtar çiftleri (public/private key pair) ile yapılır. Parola tabanlı kimlik doğrulama daha yaygın olsa da, SSH anahtarları çok daha güvenli bir yöntem sunar ve çoğu profesyonel ortamda tercih edilir.

Peki, SSH neden bu kadar hayati öneme sahiptir? Dijital dünyada, sunucularımız genellikle fiziksel olarak uzakta bulunur ve onlara erişim sağlamak için güvenli bir kanala ihtiyaç duyarız. SSH, bu kanalı sağlar. Bir web sunucusu yönetiyor, bir veritabanı sunucusuna bağlanıyor veya bulut tabanlı bir sanal makine üzerinde çalışıyorsanız, SSH sizin için bir köprü görevi görür. Örneğin, bir web sitesi güncellemesi yaparken, dosyaları sunucuya güvenli bir şekilde aktarmak için SCP (Secure Copy Protocol) veya SFTP (SSH File Transfer Protocol) gibi SSH tabanlı araçları kullanırız. Ayrıca, sunucu üzerindeki log dosyalarını incelemek, yazılım paketlerini güncellemek veya sistem hizmetlerini yeniden başlatmak gibi görevler de SSH üzerinden gerçekleştirilir. Kısacası, SSH olmadan modern sunucu yönetimi neredeyse imkansız hale gelir. Bu nedenle, SSH bağlantılarının güvenliği, genel sistem güvenliğimizin temel taşlarından biridir. Ancak bu temel taş, bazen beklenmedik ve can sıkıcı sorunlara yol açabilir, tıpkı benim yaşadığım lockout deneyiminde olduğu gibi.

O Kara Gün: SSH Lockout Deneyimi Nasıl Yaşandı?

Her şey, yeni bir sunucu yapılandırması üzerinde çalışırken başladı. Bir proje için hızlıca bir sanal sunucu (VPS – Virtual Private Server) kurmam gerekiyordu ve her zaman yaptığım gibi temel güvenlik ayarlarını yapmaya başladım. Amacım, sunucuyu daha güvenli hale getirmek ve kaba kuvvet (brute-force) saldırılarına karşı korumaktı. Planım şuydu: root (yönetici) kullanıcısının doğrudan SSH erişimini kapatmak, parola ile kimlik doğrulamayı devre dışı bırakmak ve sadece anahtar tabanlı kimlik doğrulamasını etkinleştirmek. Bu adımlar, SSH güvenliği için altın standart olarak kabul edilir ve genellikle sorunsuz bir şekilde uygulanır.

Yapılandırma dosyası olan /etc/ssh/sshd_config üzerinde gerekli değişiklikleri yaptım. PermitRootLogin no ve PasswordAuthentication no satırlarını ekledim veya mevcut olanları düzenledim. Ardından, kendi kullanıcı hesabım için bir SSH anahtar çifti oluşturup, genel anahtarımı (public key) sunucuya kopyaladım. Her şey yolunda görünüyordu. Yapılandırma değişikliklerinin etkili olması için SSH hizmetini yeniden başlatmam gerekiyordu. Büyük bir özgüvenle sudo systemctl restart sshd komutunu girdim. İşte tam bu an, felaketin kapısı aralandı. Komut sorunsuz çalışmış gibi görünüyordu ve herhangi bir hata mesajı almadım. Eski SSH oturumumu kapatıp, yeni ayarların doğru çalışıp çalışmadığını test etmek için yeni bir bağlantı denemesi yaptım.

Klavyemden ssh benimkullanicim@sunucu_ip_adresi komutunu girdim ve enter tuşuna bastım. Birkaç saniye süren bekleyişin ardından, beklediğim gibi bir parola istemi gelmedi. Ancak beklediğim SSH kabuğu (shell) yerine, şu mesajla karşılaştım: Permission denied (publickey). İlk başta panik yapmadım. Muhtemelen anahtarımı yanlış kopyaladım veya izinleri (permissions) yanlış ayarladım diye düşündüm. Hızlıca kontrol etmek için tekrar denedim, farklı bir anahtarla denedim, hatta root olarak bağlanmayı bile denedim (ki bu zaten kapatılmıştı). Her denememde aynı Permission denied hatasını aldım. Birkaç dakika sonra, kalbim hızla çarpmaya başladı. Sunucuya artık erişemiyordum. Ne parola ile ne de SSH anahtarı ile. Tüm kapılar üzerime kapanmıştı.

Bu an, bir sunucu yöneticisinin yaşayabileceği en kötü senaryolardan biriydi. Sunucu hala çalışıyordu, web sitesi yayındaydı ama ben ona erişemiyordum. Sanki kendi evinizin anahtarını kaybetmiş ve kapıda kalmışsınız gibi bir durumdu. Yedek bir erişim yöntemim yoktu. Konsol erişimi (VNC veya web tabanlı konsol) de ne yazık ki o an için mevcut değildi. Günlerce süren bir projenin tam ortasındayken, tüm ilerlemem tehlikedeydi. O anki çaresizlik hissi, beni Port 22’ye karşı köklü bir karar almaya itecekti. Bu deneyim, bana güvenlik yapılandırmalarını test etmenin ve yedek erişim yollarını her zaman hazır bulundurmanın ne kadar kritik olduğunu acı bir şekilde öğretti.

Güvenlik Açıkları ve Port 22’nin Hedef Olması

SSH, sunduğu güvenlik katmanına rağmen, varsayılan yapılandırmaları ve standart port kullanımı nedeniyle sürekli siber saldırıların hedefi haline gelmektedir. Özellikle Port 22, SSH’in varsayılan portu olduğu için, internete açık her sunucu için potansiyel bir zayıflık noktasıdır. Siber suçlular ve botnetler, sürekli olarak interneti tarayarak açık Port 22’ye sahip sunucuları tespit etmeye çalışır. Tespit ettiklerinde ise, bu sunuculara karşı kaba kuvvet (brute-force) saldırıları başlatırlar. Kaba kuvvet saldırıları, belirli bir kullanıcı adı (genellikle ‘root’ veya ‘admin’) ve milyonlarca olası parola kombinasyonunu deneyerek sunucuya yetkisiz erişim sağlamayı amaçlar.

Bu saldırılar genellikle otomatik botnetler tarafından gerçekleştirilir. Bu botnetler, dünyanın dört bir yanındaki binlerce hatta milyonlarca zombi bilgisayardan oluşur ve eş zamanlı olarak farklı IP adreslerinden sunucunuza saldırmaya çalışır. Sunucunuzun log dosyalarını (örneğin /var/log/auth.log veya /var/log/secure) incelediğinizde, bu tür saldırıların ne kadar yaygın olduğunu dehşetle görebilirsiniz. Başarısız oturum açma denemeleriyle dolu yüzlerce, hatta binlerce satırla karşılaşmak işten bile değildir. İşte size tipik bir log çıktısından bir örnek:

Dec 15 10:30:01 sunucum sshd[12345]: Failed password for root from 192.0.2.1 port 54321 ssh2
Dec 15 10:30:02 sunucum sshd[12346]: Failed password for invalid user admin from 198.51.100.2 port 12345 ssh2
Dec 15 10:30:03 sunucum sshd[12347]: Failed password for root from 203.0.113.3 port 67890 ssh2
      

Bu loglar, sunucunuzun sürekli olarak saldırı altında olduğunu gösterir. Başarılı bir kaba kuvvet saldırısı, sunucunuzun tamamen ele geçirilmesine, veri ihlallerine, kötü amaçlı yazılım yüklenmesine veya sunucunuzun bir botnet’in parçası haline gelmesine neden olabilir. Bu nedenle, Port 22’nin güvenliğini sağlamak, sunucu yönetiminin en temel ve en önemli görevlerinden biridir. Varsayılan ayarlar, çoğu zaman yeterli korumayı sağlamaz ve ek güvenlik önlemleri alınması zorunludur. Benim lockout deneyimim, bu önlemlerin ne kadar kritik olduğunu ve yanlış bir adımın nelere mal olabileceğini acı bir şekilde kanıtladı.

Unutmamak gerekir ki, güvenlik bir süreçtir, tek seferlik bir işlem değil. Sürekli olarak yeni tehditler ortaya çıkmakta ve mevcut sistemlerin güncellenmesi gerekmektedir. Port 22’nin hedef olması, sadece bir başlangıç noktasıdır. SSH güvenliğini artırmak için atılacak adımlar, sadece kaba kuvvet saldırılarını değil, aynı zamanda diğer potansiyel zafiyetleri de hedef almalıdır. Bu, hem sunucu yöneticileri hem de siber güvenlik uzmanları için sürekli bir mücadeledir.

SSH Güvenliğini Artırmanın İlk Adımları: Temel Yapılandırmalar

SSH lockout deneyimimden sonra, sunucu güvenliği konusunda çok daha titiz davranmaya başladım. Port 22’yi tamamen kapatma kararıma gelmeden önce, SSH güvenliğini artırmak için uygulanabilecek temel yapılandırmaları detaylı bir şekilde araştırdım ve uyguladım. Bu adımlar, çoğu sunucu için başlangıç seviyesinde dahi büyük bir güvenlik artışı sağlar ve kaba kuvvet saldırılarına karşı önemli bir bariyer oluşturur. İşte bu temel adımlar:

1. Parola Yerine Anahtar Tabanlı Kimlik Doğrulama Kullanımı

Parolalar, ne kadar karmaşık olursa olsunlar, her zaman kaba kuvvet saldırılarına veya sosyal mühendislik (social engineering) taktiklerine karşı savunmasızdır. SSH anahtar çiftleri (public/private key pair), çok daha güvenli bir alternatif sunar. Bir anahtar çifti oluşturduğunuzda, özel anahtarınız (private key) bilgisayarınızda güvende tutulur ve asla sunucuya gönderilmez. Genel anahtarınız (public key) ise sunucudaki ~/.ssh/authorized_keys dosyasına yerleştirilir. Bağlantı kurulduğunda, sunucu genel anahtarınızı kullanarak özel anahtarınızın sizde olup olmadığını kriptografik olarak doğrular. Bu yöntem, parolaların tahmin edilmesini veya çalınmasını neredeyse imkansız hale getirir.

Anahtar oluşturma ve kopyalama adımları genellikle şöyledir:

1. Kendi bilgisayarınızda anahtar çifti oluşturun:

   
   ssh-keygen -t rsa -b 4096
                 

   Bu komut, 4096 bit RSA anahtar çifti oluşturur. Bir parola (passphrase) belirlemeniz şiddetle tavsiye edilir.

2. Genel anahtarı sunucuya kopyalayın:

   
   ssh-copy-id kullaniciadi@sunucu_ip_adresi
                 

   Alternatif olarak, genel anahtar dosyasının içeriğini (genellikle ~/.ssh/id_rsa.pub) sunucudaki ~/.ssh/authorized_keys dosyasına manuel olarak kopyalayabilirsiniz.

Anahtar tabanlı kimlik doğrulamasını etkinleştirdikten sonra, /etc/ssh/sshd_config dosyasında PasswordAuthentication no yaparak parola ile oturum açmayı tamamen devre dışı bırakmalısınız. Bu, benim lockout yaşamama neden olan kritik adımlardan biriydi, ancak doğru uygulandığında en önemli güvenlik artırıcı önlemdir.

2. Root Erişimi Kapatma

Root kullanıcısı, Linux sistemlerinde en yüksek yetkilere sahip kullanıcıdır. Bu nedenle, siber saldırganların birincil hedefidir. Root kullanıcısının doğrudan SSH üzerinden oturum açmasını engellemek, sunucunuzun güvenliğini önemli ölçüde artırır. Bunun yerine, normal bir kullanıcı hesabı ile oturum açıp, gerektiğinde sudo komutunu kullanarak yönetici yetkileri almanız önerilir. Bu ayarı yapmak için /etc/ssh/sshd_config dosyasında şu satırı düzenleyin:

PermitRootLogin no
      

Bu değişiklikten sonra, root olarak SSH ile bağlanma denemeleri başarısız olacaktır. Normal kullanıcı hesabınızın sudo yetkisine sahip olduğundan emin olun.

3. SSH Portunu Değiştirme (Non-Standard Port)

Port 22, SSH’in standart portu olduğu için sürekli taranır ve saldırıya uğrar. SSH portunu farklı, standart olmayan bir porta (örneğin 2222, 22222 veya rastgele yüksek bir port numarası) değiştirmek, otomatik botnet saldırılarının büyük bir kısmını engeller. Bu, “güvenlik için belirsizlik” (security through obscurity) olarak adlandırılsa da, pratik anlamda saldırı yüzeyinizi önemli ölçüde daraltır. /etc/ssh/sshd_config dosyasında şu satırı düzenleyin:

Port 2222
      

Bu değişikliği yaptıktan sonra, güvenlik duvarınızda (firewall) yeni portu açmayı unutmayın! Aksi takdirde, kendinizi yine bir lockout durumunda bulabilirsiniz. Örneğin, UFW (Uncomplicated Firewall) kullanıyorsanız: sudo ufw allow 2222/tcp.

4. İzin Verilen Kullanıcıları ve Grupları Belirleme

SSH erişimine izin verilen kullanıcıları veya grupları açıkça tanımlamak, yetkisiz kullanıcıların sisteme sızmasını zorlaştırır. /etc/ssh/sshd_config dosyasında AllowUsers veya AllowGroups direktiflerini kullanabilirsiniz:

AllowUsers benimkullanicim digerkullanici
AllowGroups sshusers
      

Bu ayarlar, sadece belirtilen kullanıcıların veya belirtilen gruplara üye olan kullanıcıların SSH ile bağlanmasına izin verir.

Tüm bu değişiklikleri yaptıktan sonra, SSH hizmetini yeniden başlatmayı ve yeni bir terminal penceresinden bağlantıyı test etmeyi unutmayın. Eski oturumunuzu açık tutarak, olası bir lockout durumunda geri dönebilir ve hataları düzeltebilirsiniz. Bu, benim lockout deneyimimden çıkardığım en önemli derslerden biriydi.

Port 22’yi Kapatmak Yerine Alternatif Güvenlik Stratejileri

Port 22’yi tamamen kapatmak, bazı durumlarda aşırı bir önlem gibi görünebilir. Ancak benim yaşadığım deneyim, bu radikal kararın arkasında yatan mantığı anlamamı sağladı. Yine de, her zaman Port 22’yi kapatmak zorunda değilsiniz. Çeşitli alternatif güvenlik stratejileri mevcut olup, bu stratejilerle SSH bağlantılarınızı önemli ölçüde güçlendirebilirsiniz. Bu bölümde, Port 22’yi açık tutarken bile güvenliği artırmanın yollarını keşfedeceğiz.

1. Güvenlik Duvarı (Firewall) Kullanımı

Bir güvenlik duvarı, sunucunuza gelen ve giden trafiği kontrol eden ilk savunma hattıdır. Sadece belirli IP adreslerinden veya belirli ağlardan SSH erişimine izin vermek, kaba kuvvet saldırılarını büyük ölçüde azaltır. Örneğin, UFW (Uncomplicated Firewall) veya iptables gibi araçlarla bu kuralları kolayca yapılandırabilirsiniz. Eğer belirli bir ofis IP adresiniz veya VPN ağınız varsa, sadece o IP adreslerinden Port 22’ye erişime izin verebilirsiniz:

# UFW ile belirli bir IP'den SSH erişimine izin verme
sudo ufw allow from 203.0.113.100 to any port 22

# iptables ile aynı kural
sudo iptables -A INPUT -p tcp --dport 22 -s 203.0.113.100 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j DROP
      

Bu kurallar, 203.0.113.100 IP adresinden gelen bağlantılar dışındaki tüm SSH bağlantılarını reddeder. Bu, özellikle sabit bir IP adresine sahipseniz veya bir VPN üzerinden bağlanıyorsanız son derece etkili bir yöntemdir.

2. Fail2ban Entegrasyonu

Fail2ban, sunucunuzdaki log dosyalarını (günlük kayıtlarını) izleyen ve belirli bir süre içinde çok sayıda başarısız oturum açma denemesi yapan IP adreslerini otomatik olarak engelleyen bir intrusion prevention (izinsiz giriş önleme) yazılımıdır. Bu, kaba kuvvet saldırılarına karşı en popüler ve etkili çözümlerden biridir. Fail2ban, SSH bağlantılarının yanı sıra web sunucuları, FTP ve e-posta sunucuları gibi diğer hizmetler için de yapılandırılabilir. Kurulumu ve yapılandırması nispeten kolaydır:

1. Kurulum: sudo apt install fail2ban (Debian/Ubuntu)
2. Yapılandırma: /etc/fail2ban/jail.local dosyasını düzenleyerek SSH için bir bölüm ekleyebilirsiniz:

   
   [sshd]
   enabled = true
   port = ssh
   filter = sshd
   logpath = /var/log/auth.log
   maxretry = 3
   bantime = 3600
                 

   Bu yapılandırma, 3 başarısız denemeden sonra IP adresini 1 saat (3600 saniye) boyunca engeller.

Fail2ban, sunucunuzun sürekli taranan Port 22’sini korumak için vazgeçilmez bir araçtır ve botnet saldırılarının etkisini önemli ölçüde azaltır.

3. VPN veya Bastion Host Kullanımı

Daha yüksek güvenlik seviyeleri için, sunucularınıza doğrudan internet üzerinden erişmek yerine bir VPN (Sanal Özel Ağ) veya bir bastion host (sıçrama tahtası sunucusu) kullanmayı düşünebilirsiniz. Bu yöntemlerde, SSH bağlantılarınız önce güvenli bir VPN ağı üzerinden veya internete açık tek bir “güvenli” sunucu (bastion host) üzerinden yapılır. Ardından, bu VPN ağı veya bastion host üzerinden iç ağdaki sunucularınıza erişim sağlarsınız. Bu, saldırı yüzeyini tek bir noktaya indirger ve iç sunucularınızın doğrudan internete açık olmasını engeller. Özellikle birden fazla sunucu yönetiyorsanız, bu merkezi erişim noktası çok daha güvenli ve yönetilebilir bir çözüm sunar.

4. Çok Faktörlü Kimlik Doğrulama (MFA)

Parola veya SSH anahtarlarına ek olarak, çok faktörlü kimlik doğrulama (MFA – Multi-Factor Authentication) kullanmak, güvenliği en üst düzeye çıkarır. Bu, genellikle bir mobil uygulama (Google Authenticator gibi) tarafından üretilen tek kullanımlık bir kod veya fiziksel bir güvenlik anahtarı (YubiKey gibi) ile sağlanır. MFA etkinleştirildiğinde, bir kullanıcı SSH ile bağlanmak istediğinde, hem doğru anahtarı/parolayı girmesi hem de ek bir doğrulama faktörünü sağlaması gerekir. Bu, bir saldırganın sadece anahtarınızı veya parolanızı ele geçirmesi durumunda bile sisteme erişmesini engeller.

Bu stratejiler, Port 22’yi tamamen kapatmadan bile sunucunuzun SSH güvenliğini önemli ölçüde artırabilir. Her bir yöntemin kendi avantajları ve uygulama zorlukları vardır. En iyi güvenlik yaklaşımı, genellikle bu stratejilerin bir kombinasyonunu kullanmaktır. Ancak benim için, yaşanan lockout deneyiminin travması ve sürekli saldırı loglarını görmenin verdiği rahatsızlık, daha radikal bir karara itti: Port 22’yi tamamen kapatmak.

Benim Nihai Kararım: Port 22’yi Sonsuza Dek Kapatmak

Yaşadığım SSH lockout deneyimi ve sonrasında sunucu loglarında gördüğüm bitmek bilmeyen kaba kuvvet saldırısı denemeleri, beni Port 22’nin standart kullanımına karşı köklü bir karara itti. Her ne kadar yukarıda bahsettiğim güvenlik önlemlerinin çoğu etkili olsa da, sürekli bir “kedi-fare” oyununun içinde olmak yorucuydu. Sunucumun, sadece varsayılan bir portta çalıştığı için sürekli saldırı altında olması fikri beni rahatsız ediyordu. Bu nedenle, sunucu güvenliğimi en üst düzeye çıkarmak ve zihinsel olarak daha rahat etmek adına Port 22’yi tamamen kapatma kararı aldım. Bu, benim için bir güvenlik duruşu ve siber tehditlere karşı kesin bir mesajdı.

Peki, Port 22’yi kapattıktan sonra sunucularıma nasıl erişiyorum? Cevap, çok basit: SSH portunu değiştirmek ve sadece belirli IP adreslerinden erişime izin vermek. Artık tüm sunucularımda SSH hizmeti, standart Port 22 yerine rastgele seçilmiş, yüksek numaralı bir portta (örneğin 49152 ile 65535 arasındaki bir port) çalışıyor. Ayrıca, güvenlik duvarı kurallarımı (UFW veya iptables) yapılandırarak, sadece kendi statik IP adresimden veya güvendiğim VPN ağından bu yeni porta erişime izin veriyorum. Bu, iki katmanlı bir güvenlik sağlıyor: birincisi, portun standart olmaması nedeniyle otomatik tarayıcılar tarafından kolayca bulunamaması; ikincisi, bulunsa bile sadece belirlenmiş güvenilir kaynaklardan erişime izin verilmesi.

Bu radikal kararın bana sağladığı en büyük fayda, tartışmasız zihinsel rahatlıktı. Artık sunucu loglarımda her gün yüzlerce başarısız SSH denemesi görmüyorum. Sunucularımın “sessiz” ve güvende olduğunu bilmek, bana büyük bir huzur veriyor. Elbette, bu yaklaşımın bazı küçük dezavantajları da yok değil. Örneğin, her yeni sunucuya bağlanırken veya farklı bir konumdan erişim sağlamam gerektiğinde, güvenlik duvarı kurallarını güncellemem veya yeni bir IP adresini beyaz listeye almam gerekiyor. Ancak bu küçük zahmetler, elde ettiğim güvenlik ve huzur karşısında devede kulak kalıyor.

Bu deneyimden çıkardığım ders şuydu: Güvenlik, sadece teknik bir konu değil, aynı zamanda bir zihniyet meselesidir. Risk toleransınızı belirlemeli ve ona göre önlemler almalısınız. Benim için Port 22’yi kapatmak, bu risk toleransımı sıfıra indirme kararıydı. Herkesin bu kadar radikal bir adım atması gerekmeyebilir, ancak herkesin SSH güvenliğini ciddiye alması ve en azından temel önlemleri uygulaması şarttır. Unutmayın, en zayıf halka kadar güçlüsünüzdür. Kendi güvenlik zincirinizdeki Port 22’nin güçlü olduğundan emin olun.

Sıkça Sorulan Sorular

SSH güvenliği ve Port 22 ile ilgili merak edilen bazı soruları burada yanıtlamak istedim:

• S: Port 22’yi kapatmak gerçekten gerekli mi?

  C: Her zaman gerekli olmasa da, sunucunuzun güvenlik duruşunu önemli ölçüde artırır. Eğer statik bir IP adresiniz varsa veya VPN kullanıyorsanız, Port 22’yi kapatıp SSH’i farklı bir portta sadece bu güvenli kaynaklardan erişime açmak çok daha güvenlidir. Bu, kaba kuvvet saldırılarını büyük ölçüde engeller.

• S: SSH portunu değiştirmek yeterli bir güvenlik önlemi midir?

  C: Hayır, tek başına yeterli değildir. Port değiştirme, otomatik botnet taramalarını engellese de, kararlı bir saldırgan port taraması yaparak yeni portunuzu bulabilir. Bu nedenle, anahtar tabanlı kimlik doğrulama, Fail2ban ve güvenlik duvarı kuralları gibi ek önlemlerle birlikte kullanılmalıdır.

• S: SSH anahtarlarımı nasıl güvende tutmalıyım?

  C: Özel anahtarınızı (private key) bilgisayarınızda güvenli bir yerde saklayın ve asla kimseyle paylaşmayın. Üzerine bir parola (passphrase) eklemek, ek bir güvenlik katmanı sağlar. Ayrıca, anahtar dosyalarının izinlerini (permissions) chmod 400 ~/.ssh/id_rsa gibi komutlarla yalnızca sizin okuyabileceğiniz şekilde ayarlayın.

• S: SSH lockout durumunda ne yapmalıyım?

  C: En iyi senaryo, sunucu sağlayıcınızın size bir konsol (VNC, web tabanlı konsol) erişimi sunmasıdır. Bu sayede sunucuya doğrudan erişip sshd_config dosyasını düzeltebilirsiniz. Eğer konsol erişiminiz yoksa, sağlayıcınızla iletişime geçerek sunucunuzu kurtarma modunda (rescue mode) başlatmalarını veya size geçici bir erişim sağlamalarını isteyebilirsiniz. Her zaman bir yedek erişim planınızın olması kritik öneme sahiptir.

• S: Fail2ban, SSH saldırılarını tamamen engeller mi?

  C: Fail2ban, kaba kuvvet saldırılarına karşı çok etkili bir savunma mekanizmasıdır, ancak tamamen engellemez. Belirli bir süre içinde çok sayıda başarısız deneme yapan IP’leri engeller. Ancak çok sayıda farklı IP adresinden gelen dağıtık (distributed) saldırılara karşı tek başına yeterli olmayabilir. Diğer güvenlik önlemleriyle birlikte kullanılması önerilir.

Bu makalede, SSH lockout deneyimimden yola çıkarak Port 22’nin güvenlik risklerini, SSH’i güvenli hale getirme yöntemlerini ve nihayetinde neden Port 22’yi tamamen kapatma kararı aldığımı anlattım. Umarım bu bilgiler, kendi sunucularınızın güvenliğini artırmanıza yardımcı olur ve sizi benim yaşadığım türden bir kabustan korur. Güvenliğiniz her zaman önceliğiniz olsun!

#SSH #SunucuGüvenliği #SiberGüvenlik #Port22 #Linux #SistemYönetimi