Beklenmeyen Açık Portun Sahibi Nasıl Bulunur?

Port taramasında görünen beklenmeyen bir portu kapatmadan önce onu açan süreci ve dinleme kapsamını bulmak gerekir. Aynı port bir uygulama süreci, systemd socket birimi, container yönlendirmesi veya çekirdek özelliği tarafından açılmış olabilir. İncelemeyi soketten PID'ye, PID'den servis tanımına doğru ilerletin.

Portun gerçekten dinlemede olduğunu doğrulayın

sudo ss -lntup
sudo ss -lntp 'sport = :8080'
sudo ss -lnup 'sport = :5353'

-l dinleyen, -n sayısal, -t TCP, -u UDP ve -p süreç bilgisini gösterir. 127.0.0.1:8080 yalnızca yerelden, 0.0.0.0:8080 tüm IPv4 arayüzlerinden, [::]:8080 ise IPv6 üzerinden dinler. IPv6 soketinin IPv4 bağlantıları da kabul edip etmediği sistem ayarına bağlı olabilir.

İkinci araçla PID ve dosya tanıtıcısını doğrulayın

sudo lsof -nP -iTCP:8080 -sTCP:LISTEN
sudo lsof -nP -iUDP:5353

ss ile lsof aynı PID'yi gösteriyorsa sürece geçin. Çok kısa yaşayan süreçlerde kayıt iki komut arasında kaybolabilir; port yeniden açılıyorsa bir supervisor veya restart politikası devrede olabilir.

PID'nin çalıştırılabilir dosyasını ve komut satırını okuyun

PID=1102
ps -fp "$PID"
sudo readlink -f "/proc/$PID/exe"
sudo tr '\0' ' ' < "/proc/$PID/cmdline"
echo

ps içindeki kısa süreç adına güvenmeyin. /proc/PID/exe gerçek çalıştırılabilir dosyayı, cmdline başlangıç parametrelerini gösterir. Komut satırında parola veya token bulunabileceği için çıktıyı kayıt sistemine koymadan önce temizleyin.

Süreci systemd birimine bağlayın

sudo systemctl status "$PID" --no-pager
systemctl show example.service -p FragmentPath -p ExecStart -p Restart
systemctl cat example.service

Servis Restart=always ile çalışıyorsa yalnızca PID'yi sonlandırmak portu kalıcı kapatmaz; systemd yeni süreç başlatır. Değişiklikten önce servisin uygulama bağımlılığını, bakım etkisini ve geri dönüş komutunu belirleyin.

Systemd socket activation olasılığını kontrol edin

systemctl list-sockets --all
systemctl status example.socket --no-pager
systemctl cat example.socket

Socket activation kullanılan sistemlerde portu systemd açar ve bağlantı geldiğinde servis başlatılır. Bu durumda uygulama süreci sürekli görünmeyebilir. ListenStream veya ListenDatagram tanımını socket biriminde inceleyin.

Container ve ayrı ağ ad alanlarını unutmayın

sudo lsns -t net
docker ps --format 'table {{.ID}}\t{{.Names}}\t{{.Ports}}' 2>/dev/null
sudo nft list ruleset

Bir container portu host üzerinde proxy süreci veya NAT kuralıyla yayımlanabilir. Hostta görünen PID, uygulamanın kendisi olmayabilir. Container tanımındaki port eşlemesini ve hedef container içindeki dinleme adresini birlikte kontrol edin.

Dışarıdan erişilebilirliği ayrı ölçün

nc -vz 203.0.113.10 8080
sudo ufw status numbered

Bir soketin 0.0.0.0 üzerinde dinlemesi, internetten kesin erişilebilir olduğu anlamına gelmez; host firewall, bulut güvenlik grubu ve ağ ACL'si trafiği engelleyebilir. Tersi şekilde localhost dinlemesi de reverse proxy üzerinden dolaylı erişilebilir olabilir. Testi beklenen istemci ağından yapın.

Kapatma kararını hizmet seviyesinde verin

Port gereksizse önce ilgili uygulamayı kontrollü durdurun, ardından otomatik başlangıcı değerlendirin:

sudo systemctl stop example.service
sudo systemctl disable example.service
sudo ss -lntup
systemctl status example.service --no-pager

Bir paketi kaldırmak veya servisi maskelemek daha kalıcı ve etkili işlemlerdir; bağımlılıklar doğrulanmadan uygulanmamalıdır. Port gerekli fakat yanlış arayüzde dinliyorsa firewall eklemek yerine uygulamanın bind adresini yönetim veya localhost arayüzüyle sınırlandırmak daha doğru olabilir.

İnceleme tamamlandığında portun protokolü, dinleme adresi, sahibi, systemd veya container ilişkisi, dış erişim kapsamı ve iş gerekçesi belgelenmiş olmalıdır. Sahibi bilinmeyen bir porta rastgele allow ya da deny kuralı eklemek bu zincirin yerini tutmaz.

Teknik başvuru: systemd.socket ve systemctl kılavuzları.