Eğer nmap'i kendi sunucunuza dışarıdan çalıştırdıysanız ve çıktı 22, 80 ve 443'ten fazlasını gösteriyorsa, o anda bir karar vermeniz gerekir: bu portlardan hangisi kapatılmalı ve hangisi gerçekten açık kalmalı. Bu metin tam da o referanstır; ne kurulum eğitimi ne de giriş niteliğinde bir yazı.
Tablodan önce bir not: "servis portu" sadece bir sayı değildir. Anlam kazanan şey protokol, port ve bind adresinin birleşimidir. 127.0.0.1 üzerindeki 3306/tcp bir şeydir, aynı port 0.0.0.0 üzerinde başka bir şeydir. Gördüğüm olayların çoğu ikinci türdendi, birinci türden değil.
Yaygın servis portları tablosu
| Port | Protokol | Servis | İnternette açık olmalı mı? |
|---|---|---|---|
| 22 | TCP | SSH | Sadece anahtar ve IP kısıtlamasıyla |
| 25 | TCP | SMTP | Neredeyse asla (çoğu sağlayıcı kapatmıştır) |
| 53 | TCP/UDP | DNS | Sadece genel resolver; açık recursive değil |
| 80 | TCP | HTTP | Evet, sadece HTTPS'e yönlendirme için |
| 110 / 143 | TCP | POP3 / IMAP | Sadece TLS'li sürüm |
| 443 | TCP/UDP | HTTPS / HTTP3 | Evet |
| 587 / 465 | TCP | SMTP submission | Evet, kimlik doğrulamayla |
| 993 / 995 | TCP | IMAPS / POP3S | Evet |
| 1433 | TCP | MSSQL | Hayır |
| 3000 / 8000 / 8080 | TCP | Uygulama (Node, Django, …) | Hayır; reverse proxy arkasında |
| 3306 | TCP | MySQL / MariaDB | Hayır |
| 5432 | TCP | PostgreSQL | Hayır |
| 6379 | TCP | Redis | Hayır, asla |
| 27017 | TCP | MongoDB | Hayır |
Son sütunu ciddiye alın. 6379, 27017 ve 3306 portları otomatik taramalarda en çok kurbanı alır, çünkü birçok dağıtımın varsayılan kurulumu bunları tüm arayüzlerde bind eder ve kullanıcı da fark etmez.
Açık olmaları felaket anlamına gelen portlar
Üç kategoriyi ayırıyorum, çünkü çözümleri aynı değil.
1. Veritabanları
MySQL, PostgreSQL, Redis ve MongoDB asla internetten erişilebilir olmamalıdır. Uygulama aynı sunucudaysa, bind'i local'e alın. my.cnf içinde:
[mysqld]
bind-address = 127.0.0.1
skip-networking = 0PostgreSQL'de de postgresql.conf içinde listen_addresses = 'localhost' değerini ve pg_hba.conf içinde sadece 127.0.0.1/32 adresine izin verin. Veritabanı başka bir sunucudaysa, port açmak yerine SSH tüneli kurun. MySQL güvenliği ve erişimlerin kısıtlanması rehberi bu yolu adım adım ele alıyor.
2. Redis ve kimlik doğrulaması olmayan servisler
Redis varsayılan olarak parolasızdır. Bulut sunucusundaki yeni bir kurulum, birkaç dakika ile birkaç saat arasında taranır. Eğer dışarıdan redis-cli -h <ip> ping çıktısı PONG döndürüyorsa, sunucunuz şu anda tehlikede. Çözüm: bind 127.0.0.1 ::1 ile birlikte protected-mode yes ve gerekirse requirepass.
3. Yönetim panelleri ve hata ayıklama portları
Panel için 8080 portu, Elasticsearch için 9200, TLS'siz Docker daemon için 2375. Sonuncusu en kötüsü: 2375/tcp'ye erişim, sunucunuzda root erişimiyle istediğiniz container'ı çalıştırmak anlamına gelir. Docker'ı yeni kurduysanız, VPS'te Docker kurulumu yazısını okuyun ve soketi sadece TLS veya SSH üzerinden expose edin.
Gerçekte neyin açık olduğunu nasıl anlarız
Sunucu içinden ss -tulpn listener'ların listesini verir. Ancak bu yeterli değil; çünkü güvenlik duvarı bazılarının önünü kesmiş olabilir. Gerçek test dışarıdan yapılır:
nmap -sS -Pn -p- --min-rate 2000 203.0.113.10-p- bayrağı 65535 portun tamamını tarar ve --min-rate hızı artırır. Normal bir sunucuda tam tarama 30 ile 90 saniye arasında sürer. Dışarıdan tarama yapmak istemiyorsanız, en azından ss -tulpn | grep -v 127.0.0.1 çalıştırın ve 0.0.0.0 üzerinde neyin dinlediğini görün.
Güvenlik duvarı için yeni sistemlerde nftables, daha eskilerde ufw veya firewalld yaygındır. Sadece 22, 80 ve 443'ü açık bırakan basit bir nftables kuralı:
nft add rule inet filter input tcp dport { 22, 80, 443 } ct state new accept
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input dropSıralama önemlidir. Drop kuralını ilk başa koyarsanız, kendiniz de bağlantıyı kaybedersiniz. Uygulamadan önce her zaman ikinci bir SSH oturumu açık tutun.
Burada hata yapıyorlar
Gördüğüm en yaygın hata şudur: kullanıcı portu güvenlik duvarında kapatır, içi rahatlar, ama servis hâlâ 0.0.0.0 üzerinde dinlemektedir. Sonra bir gün güvenlik duvarını başka bir iş için geçici olarak kapatır ve o anda veritabanı çıplak kalır. Belirtisi de açıktır: MySQL logunda bilinmeyen IP'lerden Aborted connection ... (Got an error reading communication packets) gibi satırlar veya Redis'te uygulama trafiği olmadan keyspace_hits değerinde ani sıçrama.
İkinci hata: 22 portunu herkese açık bırakıp parolaya güvenmek. Genel sunucularda SSH'a yönelik brute-force saldırısı günlük binlerce deneme yapar. sshd_config içine PasswordAuthentication no ve PermitRootLogin prohibit-password koyun ve parola yerine anahtar kullanın.
Standart dışı port: değer mi?
SSH'ı 2222 veya 49152 gibi alışılmadık bir porta taşımak, otomatik taramaların hacmini ciddi ölçüde azaltır. Ancak gerçek güvenlik getirmez; sadece gürültüyü azaltır. Ben şahsen bunu yapıyorum, ama ikinci katman olarak, anahtar ve güvenlik duvarının yerine değil. Eğer 22 portuna bağımlı bir destek ekibiniz veya izleme aracınız varsa, maliyeti faydasından fazladır ve aynı 22 portu IP kısıtlamasıyla yeterlidir.
Buna karşılık, iki sunucu arasındaki API gibi dahili servisler için özel ağ üzerinde standart dışı port değerlidir. Sunucular aynı dahili ağdaysa, genel portu hiç kullanmayın.
Erişimi kaybettiğinizde
En kötü durum, güvenlik duvarı kuralını yanlış uygulayıp SSH bağlantısının kesilmesidir. Konsol erişiminiz varsa, KVM veya web konsolu üzerinden girip kuralı geri alın. Yoksa, sunucuyu rescue moduna alıp dosya sistemini dışarıdan mount etmeniz gerekir. Adımları Sunucuyu yeniden kurma ve rescue moduyla çalışma yazısında yer alıyor. Kişisel bir kural: her güvenlik duvarı değişikliğinden önce nft list ruleset > /root/nft-backup-$(date +%F).txt alın. Otuz saniye sürer ve bir gece uykusuzluğu ortadan kaldırır.
Sunucunuz bulut altyapısındaysa, genellikle işletim sistemi güvenlik duvarının üstünde bir Security Group katmanı da vardır. Bu ikisi birbirinin yerine değil, birbirine eklenir. Portu işletim sisteminde kapatıp Security Group'ta kapatmayın, tersini de yapmayın. Bulut sunucu üzerinde çalışıyorsanız, bu noktayı başlangıç tasarımında hesaba katın ki sonradan tüm kuralları yeniden yazmak zorunda kalmayasınız.
Sık sorulan sorular
8080 portu nedir ve açık olmalı mı?
8080 portu genellikle alternatif HTTP portu olarak kullanılır; yönetim panelleri, Tomcat, Jenkins ve reverse proxy'ler için. İnternette açık olması neredeyse her zaman yanlıştır. Uygulama 8080 üzerinde dinliyorsa, onu Nginx arkasında 443'e koyun ve 8080'in kendisini sadece 127.0.0.1 üzerinde açık bırakın.
Sunucumda hangi portların açık olduğunu nasıl anlarım?
Sunucu içinden ss -tulpn ile listener'ların listesini görün ve dışarıdan nmap -sS -Pn -p- <ip> ile doğrulayın. Bu iki çıktı arasındaki fark, güvenlik duvarının engellediği şeydir. Sadece iç çıktıya güvenmeyin, çünkü güvenlik duvarı sonradan kapatılabilir.
SSH portunu değiştirmek güvenliği artırır mı?
Biraz, ama sanıldığı kadar değil. Asıl faydası log gürültüsünü ve otomatik taramaları azaltmaktır. Gerçek güvenlik, parolayla girişi devre dışı bırakmaktan, anahtar kullanmaktan ve IP kısıtlamasından gelir. Bu üçü varsa, port değiştirmek isteğe bağlıdır.
3306 portunu kapattım ama MySQL hâlâ dışarıdan yanıt veriyor; neden?
Çünkü muhtemelen güvenlik duvarı kuralı yanlış zincirde veya hatalı sırayla uygulanmış ya da servis başka bir arayüzde bind edilmiş. ss -tulpn | grep 3306 ile bind adresinin ne olduğunu görün. Eğer 0.0.0.0:3306 ise, güvenlik duvarı tek savunma katmanınızdır ve bind-address değerini de düzeltmelisiniz.
Şimdi bir kez ss -tulpn çalıştırın ve 0.0.0.0 veya :: ile başlayan her satırı not edin. Sonra her biri için neden internetten erişilebilir olması gerektiğine dair bir cümle yazın. Cevabını bulamadığınız o satır, bu gece kapatmanız gereken porttur.