Sunucularınızın kalbi olan SSH erişimi, siber saldırganların hedef listesinin en başında yer alır. Brute-force saldırılarından, kimlik bilgisi hırsızlığına kadar birçok tehdit, SSH portu üzerinden sistemlerinize sızmaya çalışır. Peki, bu kritik kapıyı nasıl daha güvenli hale getirebiliriz? Bu makalede, SSH güvenliğinizi katmanlı bir yaklaşımla artırmanın yollarını, Fail2Ban, Nftables ve Bulut Güvenlik Duvarları gibi güçlü araçlarla adım adım inceleyeceğiz. Bu sayede, sunucularınızı potansiyel tehlikelere karşı daha dirençli hale getirebilirsiniz.
SSH Neden Bu Kadar Önemli ve Nasıl Korunmalı?
Secure Shell (SSH), uzak sunuculara güvenli bir şekilde erişim sağlamanın ve komut çalıştırmanın standart yoludur. Geliştiricilerden sistem yöneticilerine, herkesin günlük iş akışının vazgeçilmez bir parçasıdır. SSH’in sağladığı şifreli tünel sayesinde, hassas veriler ağ üzerinden güvenle aktarılır. Ancak bu kritik erişim noktası, aynı zamanda kötü niyetli aktörler için de birincil hedeftir. Zayıf şifreler, varsayılan yapılandırmalar ve güncel olmayan sistemler, saldırganların kolayca içeri sızmasına olanak tanır. Bir saldırgan, SSH erişimi elde ettiğinde, sunucunuz üzerinde tam kontrol sağlayabilir; bu da veri hırsızlığı, hizmet kesintisi, fidye yazılımı bulaşması veya sunucunuzun botnet ağına dahil edilmesi gibi ciddi sonuçlara yol açabilir. Bu nedenle, SSH güvenliği, herhangi bir sunucu veya altyapı için temel bir gerekliliktir.
SSH’i korumak için çok katmanlı bir strateji benimsemek hayati önem taşır. Tek bir güvenlik önlemi genellikle yeterli değildir; bunun yerine, birbirini tamamlayan çeşitli mekanizmaların bir araya getirilmesi gerekir. Örneğin, basit bir parola yerine güçlü SSH anahtarları kullanmak, brute-force saldırılarına karşı ilk ve en etkili savunmalardan biridir. Ancak bu bile, sürekli tarama yapan botlara karşı tam koruma sağlamaz. İşte bu noktada, Fail2Ban gibi otomatik IP engelleme araçları devreye girer. Başarısız giriş denemelerini izleyerek şüpheli IP adreslerini otomatik olarak yasaklar ve böylece saldırı yüzeyinizi önemli ölçüde daraltır. Ayrıca, sunucu düzeyinde bir güvenlik duvarı olan Nftables, hangi trafiğin sunucunuza ulaşabileceğini hassas bir şekilde kontrol etmenizi sağlar. Belirli portlara erişimi kısıtlamak veya yalnızca güvenilir IP adreslerinden gelen bağlantılara izin vermek, yetkisiz erişim riskini en aza indirir. Son olarak, bulut sağlayıcılarının sunduğu güvenlik duvarları, ağ katmanında ek bir koruma katmanı sağlayarak trafiği sunucunuza ulaşmadan filtreler. Bu entegre yaklaşım, SSH erişiminizi çok daha dayanıklı hale getirir ve sunucularınızın genel güvenliğini önemli ölçüde artırır. Bu adımlar, sadece basit birer yapılandırma değişikliği olmanın ötesinde, siber güvenlik duruşunuzu güçlendiren stratejik hamlelerdir.
Fail2Ban Nedir ve Brute-Force Saldırılarına Karşı Nasıl Kalkan Olur?
Fail2Ban, Linux sistemlerinde çalışan, günlük dosyalarını izleyerek otomatik olarak IP adreslerini engelleyen bir saldırı önleme yazılımıdır. Özellikle SSH gibi servislerdeki brute-force saldırılarına karşı oldukça etkilidir. Temel çalışma prensibi oldukça basittir: Sistemdeki çeşitli servislerin (SSH, Apache, Nginx, Postfix vb.) log dosyalarını tarar. Belirli bir zaman dilimi içinde, bir IP adresinden gelen başarısız giriş denemelerinin sayısını önceden tanımlanmış bir eşiğin üzerine çıktığını tespit ettiğinde, o IP adresini güvenlik duvarı kuralları (iptables veya nftables aracılığıyla) ekleyerek geçici veya kalıcı olarak engeller. Bu sayede, saldırganlar sürekli deneme yaparak sisteme sızma şanslarını kaybeder ve sunucunuzun kaynakları gereksiz yere meşgul edilmez. Fail2Ban, sadece SSH için değil, web sunucularında (WordPress, Joomla gibi CMS’lerdeki giriş denemeleri), e-posta sunucularında (SMTP, POP3, IMAP) ve FTP sunucularında da kullanılabilir, böylece geniş bir koruma yelpazesi sunar.
Fail2Ban’ı kurmak ve yapılandırmak oldukça kolaydır. Çoğu Linux dağıtımının paket yöneticilerinde bulunur. Örneğin, Ubuntu/Debian tabanlı sistemlerde aşağıdaki komutla kolayca kurulabilir:
sudo apt update
sudo apt install fail2ban
Kurulumdan sonra, Fail2Ban’ın temel yapılandırma dosyası olan /etc/fail2ban/jail.conf dosyasını doğrudan düzenlemek yerine, /etc/fail2ban/jail.local adında yeni bir dosya oluşturarak özelleştirmeler yapmak en iyi yöntemdir. Bu, gelecekteki güncellemelerde yapılandırmanızın üzerine yazılmasını engeller. İşte temel bir jail.local yapılandırma örneği:
[DEFAULT]
bantime = 10m
findtime = 10m
maxretry = 5
destemail = sizin_epostaniz@example.com
sendername = Fail2Ban
mta = sendmail
action = %(action_mwl)s
[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Yukarıdaki yapılandırmada:
bantime: Bir IP adresinin ne kadar süreyle engelleneceğini (örneğin, 10 dakika) belirtir.findtime: Belirtilen deneme sayısının (maxretry) hangi zaman aralığında aranacağını (örneğin, 10 dakika) gösterir.maxretry: Bir IP adresinin engellenmeden önce kaç başarısız deneme yapabileceğini (örneğin, 5 deneme) belirler.destemail: Engelleme durumunda bildirim gönderilecek e-posta adresidir.action: Engelleme eylemini tanımlar.action_mwl, IP’yi engeller, bir e-posta gönderir ve whois bilgilerini loglar.
Bu ayarları yaptıktan sonra Fail2Ban servisini yeniden başlatmanız gerekir:
sudo systemctl restart fail2ban
Vaka Analizi: Sürekli Brute-Force Saldırısı Altındaki Bir Web Sunucusu
Bir e-ticaret sitesi barındıran sunucunun yöneticisi, SSH giriş denemelerinde sürekli bir artış fark etti. Güvenlik loglarını incelediğinde, dünyanın dört bir yanından gelen IP adreslerinden binlerce başarısız SSH denemesi olduğunu gördü. Başlangıçta, bu denemeler sunucu performansını ciddi şekilde etkilemese de, potansiyel bir güvenlik ihlali riski taşıyordu. Yönetici, Fail2Ban’ı kurmaya karar verdi. Varsayılan yapılandırmayla (5 başarısız deneme, 10 dakika engelleme) Fail2Ban’ı devreye aldı. Sadece birkaç saat içinde, Fail2Ban’ın engellediği IP adreslerinin sayısı binleri buldu. SSH logları temizlendi ve sunucu kaynakları üzerindeki yük azaldı. En önemlisi, bu otomatik savunma mekanizması sayesinde, yönetici manuel olarak IP engellemekle uğraşmak zorunda kalmadı ve sunucu, olası bir brute-force saldırısına karşı etkin bir şekilde korundu. Bu durum, Fail2Ban’ın pasif bir log izleyiciden öte, proaktif bir güvenlik aracı olduğunu açıkça gösterdi.
Nftables ile Sunucu Düzeyinde Detaylı Güvenlik Duvarı Kuralları Nasıl Oluşturulur?
Nftables, Linux çekirdeğinin yeni nesil paket filtreleme çerçevesidir ve eski iptables, ip6tables, arptables ve ebtables araçlarının yerini almıştır. Daha esnek, daha performanslı ve daha kolay yönetilebilir bir sentaks sunar. Nftables, sunucu düzeyinde detaylı güvenlik duvarı kuralları oluşturarak, hangi trafiğin sunucunuza girip çıkabileceğini hassas bir şekilde kontrol etmenizi sağlar. Bu, SSH gibi kritik servisler için ek bir güvenlik katmanı oluşturmanın yanı sıra, genel sunucu güvenliğini de önemli ölçüde artırır. Nftables ile, belirli portları açabilir, IP adreslerini engelleyebilir, hız sınırlamaları uygulayabilir ve hatta paket içeriklerini bile denetleyebilirsiniz.
Nftables’ın temel yapısı tablolar (tables), zincirler (chains) ve kurallardan (rules) oluşur. Bir tablo, bir veya daha fazla zincir içerir ve her zincir de bir dizi kuraldan oluşur. Paketler, zincirlerdeki kurallara göre işlenir. Kurulum genellikle paket yöneticiniz aracılığıyla yapılır:
sudo apt update
sudo apt install nftables
Kurulumdan sonra, Nftables servisini etkinleştirmeniz ve başlatmanız gerekir:
sudo systemctl enable nftables
sudo systemctl start nftables
Şimdi, SSH için temel Nftables kurallarını oluşturalım. Varsayılan olarak tüm gelen bağlantıları reddeden ve yalnızca belirli portlara izin veren bir yaklaşım benimsemek en güvenli yoldur. Aşağıdaki örnek, SSH (varsayılan 22. port), HTTP (80) ve HTTPS (443) bağlantılarına izin veren basit bir kural setidir. Bu kuralları /etc/nftables.conf dosyasına ekleyebilirsiniz:
#!/usr/sbin/nft -f
flush ruleset
table ip filter {
chain input {
type filter hook input priority 0; policy drop;
# Loopback arayüzünden gelen tüm trafiğe izin ver
iif "lo" accept
# Daha önce kurulmuş bağlantılara ve ilgili trafiğe izin ver
ct state { established, related } accept
# SSH (Port 22 veya değiştirdiğiniz port)
tcp dport 22 accept
# HTTP
tcp dport 80 accept
# HTTPS
tcp dport 443 accept
# ICMP (Ping) trafiğine izin ver
ip protocol icmp accept
# Geriye kalan her şeyi reddet (policy drop ile zaten yapılıyor, ama açıkça belirtmek iyi bir pratik)
# Bu kurala genellikle gerek kalmaz çünkü zincirin varsayılan politikası "drop" olarak ayarlanmıştır.
}
chain forward {
type filter hook forward priority 0; policy drop;
}
chain output {
type filter hook output priority 0; policy accept;
}
}
Bu kuralları uyguladıktan sonra, Nftables yapılandırmasını kontrol edin ve yükleyin:
sudo nft -f /etc/nftables.conf
sudo nft list ruleset
Bu yapılandırma, sunucunuza yalnızca belirli portlar üzerinden erişilmesine izin verirken, diğer tüm bağlantı denemelerini engeller. SSH portunu değiştirdiyseniz, tcp dport 22 accept kuralını yeni port numaranızla güncellemeniz gerektiğini unutmayın. Örneğin, SSH portunuz 2222 ise, kural tcp dport 2222 accept şeklinde olmalıdır. Ayrıca, Fail2Ban ile Nftables’ı birlikte kullanırken, Fail2Ban otomatik olarak Nftables kurallarını ekleyip kaldıracaktır, bu da ikisinin sorunsuz bir şekilde entegre çalıştığı anlamına gelir.
Vaka Analizi: Yanlış Nftables Kuralının Neden Olduğu Kesinti ve Çözümü
Bir DevOps mühendisi, yeni bir web uygulamasını dağıttığı sunucusunun güvenliğini artırmak için Nftables kurallarını yapılandırıyordu. Tüm gelen trafiği engellemek ve sadece web (80, 443) ile SSH (22) portlarına izin vermek istiyordu. Ancak, aceleyle yazdığı bir kural setinde, SSH portuna izin veren kuralı yanlışlıkla tcp sport 22 accept (kaynak port) olarak belirlediği için, sunucunun dışarıdan SSH bağlantılarına tamamen kapandığını fark etti. Kuralı uyguladıktan hemen sonra, SSH bağlantısı kesildi ve sunucuya uzaktan erişim imkansız hale geldi. Panik içinde, mühendis, sunucu sağlayıcısının konsol erişimini kullanarak (genellikle bulut sağlayıcılarının web arayüzünden sunulan bir özellik) sunucuya doğrudan erişim sağladı. Hatalı Nftables yapılandırma dosyasını düzeltti (tcp dport 22 accept olarak), ardından sudo nft -f /etc/nftables.conf komutunu çalıştırarak yeni kuralları uyguladı. Bu olay, güvenlik duvarı kurallarını uygulamadan önce daima dikkatli bir şekilde gözden geçirmek ve bir “can kurtarma” erişim yoluna sahip olmanın ne kadar kritik olduğunu gösterdi. Hatta birçok yönetici, olası bir kilitlenme durumunda otomatik olarak geri yüklenen geçici kurallar kullanmayı tercih eder veya konsol erişimini birincil acil durum planı olarak saklar.
Bulut Güvenlik Duvarları Ek Bir Güvenlik Katmanı Nasıl Sağlar?
Bulut sağlayıcılarının sunduğu güvenlik duvarları (AWS Security Groups, Azure Network Security Groups, Google Cloud Firewall Rules gibi), sunucu düzeyindeki güvenlik duvarlarına ek olarak ağ katmanında güçlü bir koruma katmanı sağlar. Bu bulut tabanlı güvenlik duvarları, trafiği sanal makinelerinize (VM’ler) ulaşmadan önce filtreler, böylece kötü niyetli veya istenmeyen trafiğin sunucunuzun kaynaklarını tüketmesini veya güvenlik duvarı kurallarınızı zorlamasını engeller. Bu, özellikle büyük ölçekli altyapılar veya birden fazla sunucu içeren ortamlar için hayati öneme sahiptir, çünkü merkezi bir noktadan tüm kaynaklarınızın ağ erişimini yönetmenize olanak tanır. Bulut güvenlik duvarları, esneklik, ölçeklenebilirlik ve kolay yönetim gibi avantajlar sunar ve genellikle sunucunuzun işletim sistemi içinde çalışan güvenlik duvarlarından (Nftables gibi) daha önce devreye girer.
Bulut güvenlik duvarlarının temel prensibi, belirli IP adreslerinden, portlardan veya protokollerden gelen/giden trafiğe izin vermek veya reddetmektir. Her sanal makine veya kaynak grubu için ayrı güvenlik kuralları tanımlanabilir. Örneğin, bir web sunucusu için sadece HTTP (80) ve HTTPS (443) portlarını dünyaya açarken, SSH (22) portunu sadece kendi ofisinizin veya VPN sunucunuzun IP adresine kısıtlayabilirsiniz. Bu, SSH erişimini sadece güvenilir kaynaklarla sınırlar ve genel saldırı yüzeyini önemli ölçüde azaltır. Bulut sağlayıcıları genellikle bu güvenlik duvarlarını web tabanlı konsollar veya API’ler aracılığıyla yönetmenize olanak tanır, bu da yapılandırmayı oldukça kolaylaştırır.
Örnek Yapılandırma Senaryosu (Kavramsal):
Bir bulut sağlayıcısında (örneğin AWS) bir EC2 örneği için güvenlik grubu yapılandırması aşağıdaki gibi düşünülebilir:
- Gelen Kurallar (Inbound Rules):
- SSH (Port 22):
- Kaynak: Sadece ofis IP adresiniz (örneğin,
203.0.113.42/32) - Protokol: TCP
- Port Aralığı: 22
- Kaynak: Sadece ofis IP adresiniz (örneğin,
- HTTP (Port 80):
- Kaynak: Her Yer (
0.0.0.0/0) - Protokol: TCP
- Port Aralığı: 80
- Kaynak: Her Yer (
- HTTPS (Port 443):
- Kaynak: Her Yer (
0.0.0.0/0) - Protokol: TCP
- Port Aralığı: 443
- Kaynak: Her Yer (
- SSH (Port 22):
- Giden Kurallar (Outbound Rules):
- Genellikle varsayılan olarak tüm giden trafiğe izin verilir (
0.0.0.0/0, tüm portlar, tüm protokoller). Bu, sunucunuzun dışarıdaki kaynaklara (güncelleme sunucuları, API’ler vb.) erişmesini sağlar. Daha kısıtlayıcı bir politika da uygulanabilir, ancak dikkatli olunmalıdır.
- Genellikle varsayılan olarak tüm giden trafiğe izin verilir (
Bu yapılandırma ile, SSH portuna sadece belirli bir IP adresinden erişilebilirken, web trafiği tüm dünyadan gelebilir. Bu katmanlı yaklaşım, SSH’i doğrudan internete açık bırakmaktan çok daha güvenlidir. Ayrıca, bu güvenlik duvarları genellikle durum bilgisi (stateful) özelliğine sahiptir, yani bir bağlantı kurulduğunda, o bağlantının geri dönüş trafiğine otomatik olarak izin verilir, bu da kuralları basitleştirir.
Vaka Analizi: Bulut Güvenlik Duvarının Bir DoS Saldırısını Nasıl Engellediği
Küçük bir startup, yeni ürününü piyasaya sürdüğünde beklenmedik bir trafik patlaması yaşadı. Ancak bu trafiğin büyük bir kısmı, ürünün DDoS saldırısına uğradığını gösteren kötü niyetli isteklerden oluşuyordu. Saldırganlar, sunucunun web portunu (80) hedef alarak, sunucuyu aşırı yüklemeye çalışıyordu. Şirket, AWS’in güvenlik gruplarını kullanıyordu ve web sunucusunun güvenlik grubunda sadece HTTP (80) ve HTTPS (443) portlarına izin veren kurallar tanımlanmıştı. SSH portu (22) ise sadece belirli bir yönetici IP adresine açıktı. Saldırı başladığında, bulut güvenlik duvarı, sunucunun CPU ve bellek kullanımını artırmadan önce kötü niyetli trafiğin çoğunu ağ katmanında filtreledi. Güvenlik grubu kuralları sayesinde, saldırganlar SSH portuna dahi ulaşamadılar. Bu durum, sunucuya yönelik DoS saldırılarının etkisini önemli ölçüde azalttı ve şirket, hizmet kesintisi yaşamadan saldırıyı atlatabildi. Bulut güvenlik duvarlarının bu erken aşamada filtreleme yeteneği, sunucu kaynaklarının korunmasında ve hizmet sürekliliğinin sağlanmasında kritik bir rol oynadı.
SSH Güvenliğini İleri Düzeyde Sertleştirme İpuçları ve En İyi Uygulamalar
SSH güvenliğini artırmak sadece Fail2Ban ve güvenlik duvarları ile sınırlı değildir. Daha kapsamlı bir koruma için ek adımlar atmak, sunucularınızı siber tehditlere karşı daha da dirençli hale getirecektir. Bu ipuçları, hem yeni başlayanlar hem de deneyimli sistem yöneticileri için SSH erişimini sertleştirmede kritik öneme sahiptir.
SSH Anahtar Kimlik Doğrulaması Kullanmak: Parolaları Geride Bırakın
Parola tabanlı kimlik doğrulama, tahmin edilebilirliği veya brute-force saldırılarına açıklığı nedeniyle SSH güvenliğindeki en zayıf halkalardan biridir. Bunun yerine, SSH anahtar çifti (public/private key pair) kullanmak çok daha güvenlidir. Özel anahtarınız yerel makinenizde kalırken, genel anahtarınız sunucuya kopyalanır. Bağlantı kurulduğunda, sunucu genel anahtarla özel anahtarı doğrular. Bu yöntem, brute-force saldırılarını neredeyse imkansız hale getirir, çünkü anahtarlar çok uzundur ve tahmin edilemezdir. Özel anahtarınızı bir parola (passphrase) ile şifrelemek, ek bir güvenlik katmanı sağlar.
SSH anahtar çifti oluşturma:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
Genel anahtarınızı sunucuya kopyalama:
ssh-copy-id user@your_server_ip
Bu işlemden sonra, sunucudaki SSH yapılandırma dosyasını (/etc/ssh/sshd_config) düzenleyerek parola tabanlı kimlik doğrulamayı devre dışı bırakabilirsiniz:
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
Değişikliklerden sonra SSH servisini yeniden başlatmayı unutmayın: sudo systemctl restart sshd
Varsayılan SSH Portunu Değiştirmek: Hedef Olmaktan Çıkın
SSH’in varsayılan portu olan 22, siber saldırganların ilk hedefidir. Portu değiştirmek, otomatik bot taramalarının çoğundan kurtulmanızı sağlar. Bu, bir güvenlik önlemi olmaktan ziyade, saldırı gürültüsünü azaltan bir “güvenlik belirsizliği” önlemidir. Portu değiştirmek için /etc/ssh/sshd_config dosyasını düzenleyin:
#Port 22
Port 2222 # Örneğin, 2222 portunu kullanın
Yeni portu güvenlik duvarınızda (Nftables veya bulut güvenlik duvarı) açmayı ve SSH servisini yeniden başlatmayı unutmayın. Aksi takdirde kendinizi sunucudan kilitleyebilirsiniz.
Root Girişini Engellemek: Ayrıcalıklı Erişimi Kısıtlayın
root kullanıcısının doğrudan SSH ile giriş yapmasına izin vermek, büyük bir güvenlik riskidir. Bir saldırgan root parolasını ele geçirdiğinde, sunucu üzerinde tam kontrole sahip olur. Bunun yerine, normal bir kullanıcıyla giriş yapın ve ayrıcalıklı komutlar için sudo kullanın. /etc/ssh/sshd_config dosyasında:
PermitRootLogin no
Bu ayarı yaptıktan sonra, normal bir kullanıcıyla giriş yapın ve sudo su - veya sudo -i komutunu kullanarak root yetkilerine geçin.
İki Faktörlü Kimlik Doğrulama (2FA) Entegre Etmek: Ek Bir Kilit Daha
SSH anahtarları bile yeterli gelmeyebilir. İki faktörlü kimlik doğrulama (2FA), SSH girişine ek bir güvenlik katmanı ekler. Bu, kullanıcı adı ve parolanın veya SSH anahtarının yanı sıra, tek kullanımlık bir kod (genellikle bir mobil uygulama aracılığıyla üretilen) gerektirir. Google Authenticator gibi araçlar, Linux sistemleriyle kolayca entegre edilebilir.
sudo apt install libpam-google-authenticator
Ardından, /etc/pam.d/sshd dosyasını düzenleyin ve şu satırı ekleyin:
auth required pam_google_authenticator.so
Ve /etc/ssh/sshd_config dosyasında:
ChallengeResponseAuthentication yes
UsePAM yes
Bu adımların ardından, her kullanıcının google-authenticator komutunu çalıştırması ve QR kodunu mobil uygulamasına kaydetmesi gerekecektir.
SSH Yapılandırmasını Düzenli Olarak Gözden Geçirmek ve Güncellemek
Güvenlik politikaları zamanla değişebilir ve yeni tehditler ortaya çıkabilir. SSH yapılandırma dosyanızı (sshd_config) düzenli olarak gözden geçirmek ve gereksiz özellikleri devre dışı bırakmak önemlidir. Örneğin, X11 yönlendirmesi veya Agent yönlendirmesi gibi özellikler kullanılmıyorsa kapatılabilir. Ayrıca, sunucunuzdaki tüm yazılımları, özellikle SSH ve işletim sistemi çekirdeğini güncel tutmak, bilinen güvenlik açıklarına karşı korunmanın en temel yoludur.
X11Forwarding no
AllowTcpForwarding no
chmod 400 ~/.ssh/id_rsa) ayarlayın.
Sonuç: Katmanlı Bir Yaklaşımla Güvenliği Maksimuma Çıkarmak
SSH, uzak sunucu yönetiminin vazgeçilmez bir bileşenidir ve bu nedenle siber güvenlik stratejilerinin merkezinde yer almalıdır. Bu makalede ele aldığımız Fail2Ban, Nftables ve Bulut Güvenlik Duvarları gibi araçlar, SSH erişiminizi çeşitli tehditlere karşı korumak için güçlü bir katmanlı savunma mekanizması sunar. Fail2Ban, otomatik brute-force engellemesiyle sürekli taramaları durdururken, Nftables sunucu düzeyinde detaylı trafik kontrolü sağlar. Bulut güvenlik duvarları ise ağ katmanında ilk savunma hattını oluşturarak istenmeyen trafiği daha sunucuya ulaşmadan engeller. Bu araçların yanı sıra, SSH anahtar kimlik doğrulaması kullanmak, varsayılan portu değiştirmek, root girişini engellemek ve iki faktörlü kimlik doğrulamayı entegre etmek gibi ileri düzey güvenlik ipuçları, savunma hattınızı daha da güçlendirir. Unutulmamalıdır ki, güvenlik statik bir durum değil, sürekli bir süreçtir. Düzenli güncellemeler, yapılandırma denetimleri ve güvenlik politikalarının gözden geçirilmesi, sunucularınızın uzun vadede güvende kalmasını sağlar. Bu entegre ve proaktif yaklaşım sayesinde, SSH erişiminiz sadece işlevsel değil, aynı zamanda siber saldırılara karşı son derece dirençli hale gelecektir.
Sıkça Sorulan Sorular
1. Fail2Ban sadece SSH için mi kullanılır?
Hayır, Fail2Ban sadece SSH için değil, aynı zamanda Apache, Nginx, Postfix, FTP ve diğer birçok servis için de kullanılabilir. Her servisin log dosyasını izleyerek başarısız denemeleri tespit edebilir ve ilgili IP adreslerini engelleyebilir. Bu, geniş bir uygulama yelpazesinde brute-force saldırılarına karşı koruma sağlar.
2. Nftables ve iptables arasındaki temel fark nedir? Hangisini kullanmalıyım?
Nftables, iptables’ın modern ve daha esnek bir halefidir. Daha basit bir sentaks, daha iyi performans ve tüm protokoller (IPv4, IPv6, ARP, bridge) için tek bir arayüz sunar. Yeni projeler ve mevcut sistemlerin güncellemeleri için Nftables kullanılması önerilir. İptables hala işlevsel olsa da, Nftables geleceğin standartıdır.
3. Bulut güvenlik duvarları, sunucumdaki Nftables’ın yerini tutar mı?
Hayır, birbirlerinin yerini tutmazlar; aksine, birbirlerini tamamlarlar. Bulut güvenlik duvarları, trafiği ağ katmanında, sanal makinenize ulaşmadan önce filtreler. Nftables ise sanal makinenizin işletim sistemi içinde çalışır ve daha detaylı, uygulama düzeyinde kurallar uygulamanıza olanak tanır. Katmanlı bir güvenlik yaklaşımı için her ikisini birlikte kullanmak en iyi uygulamadır.
4. SSH anahtarları kullanmak, parolalardan ne kadar daha güvenlidir?
SSH anahtarları, parmak izi gibi benzersiz ve çok uzun (genellikle 2048 veya 4096 bit) kriptografik anahtarlardır. Parolalar tahmin edilebilir veya brute-force saldırılarıyla kırılabilirken, SSH anahtarlarının kırılması mevcut hesaplama gücüyle pratik olarak imkansızdır. Bu nedenle, SSH anahtarları parola tabanlı kimlik doğrulamadan kat kat daha güvenlidir.
5. SSH portunu değiştirmek gerçekten güvenliği artırır mı?
SSH portunu değiştirmek, doğrudan bir güvenlik açığını kapatmaz ancak “güvenlik belirsizliği” prensibiyle çalışır. Otomatik botlar ve tarayıcılar genellikle varsayılan 22. portu hedefler. Portu değiştirmek, bu yaygın taramalardan kaynaklanan gürültüyü ve log kaydını azaltır, böylece gerçek tehditleri daha kolay tespit edebilirsiniz. Bu, tek başına yeterli bir önlem olmasa da, diğer güvenlik önlemleriyle birlikte kullanıldığında faydalıdır.