Açık Portları Listeleme (ss ve netstat)

Bir sunucuyu güvenli tutmanın ilk şartı, o sunucunun dış dünyaya tam olarak hangi kapıları açtığını bilmektir. Her dinlenen port, internete bakan bir kapıdır; birileri o kapıyı çalabilir, zorlayabilir, hatta içeride unutulmuş bir servis üzerinden sunucuya sızabilir. "Benim sunucumda sadece web ve SSH açık" diye düşünürken, aslında arka planda bir veritabanının bütün arayüzlere bağlanmış olması, bir yönetim panelinin 8080'de dinlemesi ya da eski bir test servisinin hâlâ ayakta durması hiç de nadir değildir. Bu yüzden "hangi portlar açık ve o portu kim tutuyor?" sorusu, sistem yönetiminin en temel ve en sık sorulması gereken sorularından biridir.

Bu rehberde bu soruyu yanıtlamanın iki klasik aracını gerçek örneklerle ele alacağız: modern ve hızlı ss (socket statistics) ile onun yıllardır bilinen atası netstat. Amacımız komutları ezberletmek değil; çıktının hangi sütununun ne anlattığını kavratmak, belirli bir portu tutan süreci (PID) saniyeler içinde bulabilmenizi sağlamak ve en önemlisi bu bilgiyi güvenlik pratiğine, yani gereksiz açık portları kapatmaya bağlamaktır. Örnekler bir VDS ya da bulut sunucuda olduğu gibi paylaşımlı olmayan her Linux ortamında aynı mantıkla çalışır.

Port, Soket ve Dinleme Kavramı#

Konuya girmeden önce üç kavramı netleştirelim çünkü çıktıyı doğru okumak buna bağlı. Bir port, bir IP adresi üzerindeki numaralı bir iletişim kapısıdır (0-65535 arası). Web trafiği tipik olarak 80 ve 443, SSH 22, MySQL 3306, PostgreSQL 5432 portunu kullanır. Bir soket ise IP adresi ile portun birleşiminden oluşan somut bağlantı ucudur; örneğin 0.0.0.0:443 tüm arayüzlerde 443'ü, 127.0.0.1:3306 yalnızca yerel makinede 3306'yı temsil eder.

En kritik ayrım ise dinleme ile bağlantı arasındaki farktır. Bir soket iki durumdan birinde olabilir: LISTEN (dinliyor) durumundaki bir soket, "bu porta gelen bağlantıları kabul etmeye hazırım" diyen bir servistir; işte güvenlik açısından asıl ilgilendiğimiz kapılar bunlardır. ESTABLISHED (kurulu) durumundaki bir soket ise o an fiilen kurulmuş, veri akan bir bağlantıdır. Aşağıdaki tablo en sık göreceğiniz soket durumlarını özetler:

Bu ayrımı kavradığınızda komutların bayraklarını da mantıklı bulursunuz: dinleyen kapıları ararken LISTEN durumunu, trafik incelerken ESTAB durumunu filtreleyeceksiniz.

ss ile Dinlenen Portları Listeleme#

ss, günümüz Linux dağıtımlarının varsayılan aracıdır ve iproute2 paketiyle birlikte gelir; yani neredeyse her yerde kuruludur. netstat'a göre çok daha hızlıdır çünkü çekirdek bilgisine doğrudan (netlink üzerinden) erişir, binlerce bağlantısı olan yoğun sunucularda bu fark açıkça hissedilir. Dinlenen portları listelemenin en pratik biçimi şu tek komuttur:

ss -tulpn

Bu bayrakları tek tek açalım çünkü bunları ezberlemek işinizi ömür boyu kolaylaştırır. -t TCP soketlerini, -u UDP soketlerini gösterir; -l yalnızca dinleyen (LISTEN) soketleri filtreler; -p her soketi tutan süreci (program adı ve PID) ekler; -n ise port ve adresleri isimlere çevirmez, sayısal bırakır (yani 443 yerine https yazmaz, çözümleme beklemediği için daha hızlıdır). Süreç bilgisini eksiksiz görmek için bu komutu genellikle root ile ya da sudo ile çalıştırmalısınız; aksi halde başka kullanıcılara ait süreçlerin adı görünmez.

Tipik bir çıktı şuna benzer:

Netid  State   Recv-Q  Send-Q   Local Address:Port    Peer Address:Port  Process
tcp    LISTEN  0       128            0.0.0.0:22           0.0.0.0:*      users:(("sshd",pid=812,fd=3))
tcp    LISTEN  0       511            0.0.0.0:80           0.0.0.0:*      users:(("nginx",pid=1042,fd=6))
tcp    LISTEN  0       511            0.0.0.0:443          0.0.0.0:*      users:(("nginx",pid=1042,fd=8))
tcp    LISTEN  0       80           127.0.0.1:3306         0.0.0.0:*      users:(("mysqld",pid=1330,fd=21))
udp    UNCONN  0       0            127.0.0.53:53          0.0.0.0:*      users:(("systemd-resolve",pid=640,fd=12))

Yalnızca TCP dinleyenleri isterseniz -u'yu düşürüp ss -tlpn, sadece UDP için ss -ulpn yazarsınız. Belirli bir portu doğrudan sorgulamak için de ss kendi filtre dilini sunar:

# Yalnızca 443 portunda dinleyenler
ss -tlpn 'sport = :443'

# 22 numaralı porta ait tüm soketler (dinleyen + kurulu)
ss -tanp 'sport = :22'

ss Çıktısını Doğru Okumak#

Çıktıyı hızlıca gözden geçirip yanlış sonuca varmamak için sütunları tek tek anlamak gerekir. Local Address:Port sütunu en kritik olanıdır çünkü servisin hangi arayüzde dinlediğini söyler. Buradaki adres üç ana biçimde karşınıza çıkar ve her birinin güvenlik açısından çok farklı anlamı vardır:

• 0.0.0.0:PORT — servis tüm IPv4 arayüzlerinde, yani internete açık şekilde dinliyor. Web sunucusu için normaldir; ama bir veritabanı için tehlikeli olabilir.
• 127.0.0.1:PORT — servis yalnızca yerel makinede (loopback) dinliyor; dışarıdan erişilemez. MySQL, Redis gibi arka servisler ideal olarak burada olmalıdır.
• [::]:PORT — IPv6 karşılığıdır; 0.0.0.0'ın IPv6 hali gibi düşünün, tüm IPv6 arayüzlerinde dinlemeyi ifade eder.

State sütunu dinleme durumunu, Process sütunu ise soketi tutan program adını, PID'sini ve dosya tanımlayıcısını (fd) verir. Yukarıdaki örnekte MySQL'in 127.0.0.1:3306'da dinlemesi güvenli bir yapılandırmadır; eğer orada 0.0.0.0:3306 görseydiniz, veritabanınız bütün internete açık demektir ve bu, acilen kapatılması gereken ciddi bir açıktır. Recv-Q ve Send-Q sütunları dinleyen soketlerde sırasıyla bekleyen bağlantı kuyruğu ve backlog sınırını gösterir; kurulu bağlantılarda ise henüz işlenmemiş veriyi temsil eder. Recv-Q'nun sürekli yüksek olması, uygulamanın gelen bağlantıları yeterince hızlı kabul edemediğine işaret edebilir.

Çıktıyı özetleyen faydalı bir alışkanlık, dinlenen portları tek bakışta bağlanma adresine göre sıralamaktır:

# Dinleyen TCP portlarını adres:port sütununa göre sırala
ss -tlpn | sort -t: -k2 -n

netstat Karşılığı ve İki Aracın Karşılaştırması#

netstat, yıllarca standart araç oldu ve internetteki eski belgelerin çoğu hâlâ onu anlatır. Ancak modern dağıtımlarda net-tools paketi varsayılan gelmediği için netstat çoğu yeni sunucuda kurulu bile değildir; "command not found" hatası alırsanız şaşırmayın. Yine de komutu bilmek gerekir çünkü hâlâ yaygın olarak karşınıza çıkar. ss -tulpn komutunun netstat karşılığı şudur:

# Dinleyen TCP + UDP portları ve süreçleri (netstat)
netstat -tulpn

# netstat kurulu değilse (Debian/Ubuntu)
apt install net-tools

# AlmaLinux / Rocky
dnf install net-tools

Bayrakların çoğu ortaktır: -t TCP, -u UDP, -l dinleyen, -p süreç, -n sayısal. Yani netstat -tulpn ile ss -tulpn neredeyse birebir aynı sonucu verir. Aşağıdaki tablo iki aracı pratik açıdan karşılaştırır:

Kısa özet: yeni yazacağınız betiklerde ve günlük kullanımda ss tercih edin. netstat'ı yalnızca eski bir belgeyi takip ederken ya da alışkanlıktan kullanmanız gerekiyorsa çevirisi bu tablodadır. Sunucu güvenliğine bütünsel bakış için sunucu güvenliği temelleri yazımız bu port denetimini daha geniş bir çerçeveye oturtur.

Belirli Bir Portu Tutan Süreci (PID) Bulma#

Günlük hayatta en sık ihtiyaç duyacağınız senaryo şudur: bir servisi başlatmaya çalışıyorsunuz ve Address already in use hatası alıyorsunuz; yani port zaten dolu. O portu kimin tuttuğunu bulmanın birden fazla yolu vardır. En doğrudan yöntem ss'in port filtresidir:

# 80 portunu şu an kim tutuyor?
ss -tlpn 'sport = :80'

Alternatif ve çok sevilen bir araç lsof'tur (list open files); soketler de birer dosya sayıldığı için portu tutan süreci net biçimde verir:

# 8080 portunu dinleyen süreç
lsof -i :8080

# TCP 8080'i tutan sürecin sadece PID'si
lsof -t -i tcp:8080

Bir de klasik fuser yöntemi vardır; portu tutan PID'yi verir, hatta doğrudan sonlandırmaya da yarar:

# 3000 portunu tutan sürecin PID'sini göster
fuser 3000/tcp

# 3000 portunu tutan süreci sonlandır (dikkatli olun)
fuser -k 3000/tcp

PID'yi öğrendikten sonra sürecin tam kimliğini görmek için ps ile teyit etmeniz iyi bir alışkanlıktır; yanlış süreci sonlandırmamak için:

# Bulunan PID'nin gerçekte ne olduğunu doğrula
ps -p 1042 -o pid,user,comm,args

Buradaki altın kural şudur: bir portu tutan süreci körlemesine kill etmeyin. Önce hangi servis olduğunu doğrulayın; eğer o servis systemd altında yönetiliyorsa (Nginx, MySQL gibi), süreci elle öldürmek yerine systemctl stop nginx gibi düzgün yoldan durdurmak daha temizdir, çünkü aksi halde systemd süreci yeniden başlatabilir ya da tutarsız bir durum oluşabilir.

Kurulu Bağlantıları Sayma ve İzleme#

Dinlenen portların yanı sıra, o an sunucuya fiilen kaç bağlantı geldiğini bilmek de performans ve güvenlik açısından önemlidir. Ani bir trafik artışı, bir kaba kuvvet saldırısı ya da yavaşlayan bir servis, çoğu zaman kurulu bağlantı sayısında kendini gösterir. Belirli bir portta kaç aktif bağlantı olduğunu saymak için:

# 443 portundaki kurulu (ESTAB) bağlantı sayısı
ss -tan 'sport = :443' state established | grep -c ESTAB

Sunucuya bağlanan IP adreslerini en çok bağlantı yapandan aza doğru sıralamak, olağandışı bir kaynağı yakalamanın klasik yoludur:

# 443'e bağlanan IP'leri bağlantı sayısına göre sırala
ss -tan 'sport = :443' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

Tek bir IP'nin anormal derecede çok bağlantısı varsa, bu bir saldırı ya da yanlış yapılandırılmış bir istemci işareti olabilir; böyle bir durumda o adresi güvenlik duvarında engellemek isteyebilirsiniz. Bağlantı durumlarının genel dağılımını özetlemek için de şu komut çok işe yarar:

# Soket durumlarının özeti (LISTEN, ESTAB, TIME-WAIT sayıları)
ss -s

ss -s size TCP, UDP ve toplam soketlerin özet sayımını verir; çok sayıda TIME-WAIT genellikle normaldir, ama binlerce CLOSE-WAIT görürseniz bir uygulamanın bağlantılarını düzgün kapatmadığından (soket sızıntısı) şüphelenmelisiniz. Bu tür trafik anormalliklerini kalıcı olarak yönetmek için genellikle bir WAF ya da uygulama katmanı koruması devreye alınır.

Gereksiz Açık Portları Tespit Edip Kapatma#

Buraya kadar öğrendiklerimizi bir güvenlik pratiğine dönüştürelim, çünkü açık portları listelemenin asıl amacı budur. Sağlıklı bir sunucuda kural basittir: yalnızca gerçekten ihtiyaç duyulan portlar dinlemede olmalıdır. Dinleyen her fazladan port, potansiyel bir saldırı yüzeyidir. Denetimi şöyle bir mantıkla yürütürsünüz. Önce dinleyen tüm portları listeleyin, sonra her birini "bu servise gerçekten dışarıdan erişilmesi gerekiyor mu?" sorusuyla sınayın.

# Denetim başlangıcı: dinleyen her şeyi listele
ss -tulpn

Bu listede tipik olarak şu ayrımı yaparsınız. Web sunucusu (80, 443) ve SSH (22) dış dünyaya açık olmak zorundadır. Ancak MySQL (3306), Redis (6379), PostgreSQL (5432) gibi arka servisler neredeyse her zaman yalnızca 127.0.0.1 üzerinde dinlemeli, dışarı açılmamalıdır. Eğer bunları 0.0.0.0'da görüyorsanız, iki katmanlı bir çözüm uygulayın: birincisi, servisin yapılandırmasından dinleme adresini yerelle sınırlayın (örneğin MySQL'de bind-address = 127.0.0.1); ikincisi, bir güvenlik duvarıyla o portu dışarıya kapatın.

Güvenlik duvarı tarafında en pratik araç ufw'dir. Yalnızca gereken portları açıp gerisini varsayılan olarak kapatmak, en sağlam yaklaşımdır:

# Varsayılanı reddet, sadece gerekenleri aç
ufw default deny incoming
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Güvenlik duvarı yalnızca dış erişimi engeller; ama servisin kendisi hâlâ tüm arayüzlerde dinliyorsa, bu iki kademeli savunmanın yalnızca dış katmanıdır. En temiz sonuç, servisi zaten dinlememesi gereken yerde dinletmemektir. Artık kullanmadığınız bir servisi (örneğin bir zamanlar kurulmuş ama unutulmuş bir FTP ya da test sunucusu) tamamen durdurup devre dışı bırakmak, portu kökten kapatır:

# Kullanılmayan bir servisi durdur ve açılışta başlamasını engelle
systemctl stop vsftpd
systemctl disable vsftpd

ufw kurallarını sıfırdan öğrenmek ve daha ileri senaryoları görmek için UFW güvenlik duvarı rehberimiz adım adım ilerler. Port denetimini düzenli aralıklarla, özellikle her yeni yazılım kurulumundan sonra tekrarlamak, sunucunuzun saldırı yüzeyini yıllarca dar tutar. Sunucu yönetimini uzmana bırakmak isterseniz sunucu yönetimi hizmetimiz bu denetimleri sizin adınıza düzenli olarak yürütür.

Sıkça Sorulan Sorular#

ss ve netstat arasındaki fark nedir, hangisini kullanmalıyım?#

İkisi de dinlenen portları ve bağlantıları gösterir, ancak ss modern, hızlı ve çoğu dağıtımda varsayılan kurulu olan araçtır; netstat ise eski net-tools paketine aittir ve yeni sunucularda genellikle ayrıca kurulması gerekir. Günlük kullanımda ve yeni yazacağınız betiklerde ss kullanmanızı öneririz. netstat'ı yalnızca eski bir belgeyi takip ediyorsanız ya da alışkanlığınız varsa tercih edin; komut karşılıkları neredeyse birebir aynıdır.

Belirli bir portu hangi sürecin tuttuğunu nasıl bulurum?#

En hızlı yol ss -tlpn 'sport = :PORT' komutudur; bu, o portu dinleyen sürecin adını ve PID'sini doğrudan verir. Alternatif olarak lsof -i :PORT ya da fuser PORT/tcp komutlarını da kullanabilirsiniz. Süreç bilgisini eksiksiz görmek için bu komutları sudo ile çalıştırmayı unutmayın, aksi halde başka kullanıcılara ait süreçlerin adı görünmeyebilir.

Bir portu tutan süreci güvenle nasıl sonlandırırım?#

Önce ps -p PID -o pid,user,comm,args ile sürecin gerçekte ne olduğunu doğrulayın; yanlış süreci öldürmemek için bu adım kritiktir. Eğer süreç Nginx, MySQL gibi systemd altında yönetilen bir servisse, onu elle kill etmek yerine systemctl stop servisadi ile durdurun. Aksi halde systemd süreci yeniden başlatabilir veya sistem tutarsız bir duruma düşebilir.

0.0.0.0 ve 127.0.0.1 adreslerinde dinlemek arasındaki fark nedir?#

0.0.0.0:PORT servisin tüm ağ arayüzlerinde, yani internete açık şekilde dinlediği anlamına gelir; web sunucusu için normaldir ama veritabanı gibi arka servisler için tehlikelidir. 127.0.0.1:PORT ise servisin yalnızca yerel makinede dinlediğini, dışarıdan erişilemediğini gösterir. MySQL, Redis gibi servisleri güvenlik gereği 127.0.0.1 üzerinde dinletmeli, dışarı açmamalısınız.

netstat komutum çalışmıyor, command not found hatası alıyorum, ne yapmalıyım?#

Bu tamamen normaldir; modern Ubuntu, Debian, AlmaLinux ve Rocky sürümlerinde net-tools paketi varsayılan gelmez. Ya ss kullanın (zaten kurulu ve daha hızlıdır), ya da netstat'a ihtiyacınız varsa Debian/Ubuntu'da apt install net-tools, AlmaLinux/Rocky'de dnf install net-tools komutuyla kurun. Uzun vadede ss'e geçmek en pratik çözümdür.

Sunucumda hangi portların açık olması gerektiğini nasıl bilirim?#

Genel kural, yalnızca dışarıdan erişilmesi gereken servislerin portlarının açık olmasıdır. Tipik bir web sunucusunda 80, 443 (web) ve 22 (SSH) dışa açık olur; MySQL, Redis, PostgreSQL gibi arka servisler ise yalnızca yerelde (127.0.0.1) dinlemeli, dışarı kapalı olmalıdır. ss -tulpn çıktısındaki her satır için "buna gerçekten internetten erişilmesi gerekiyor mu?" diye sorun; yanıt hayırsa hem servisin dinleme adresini yerelle sınırlayın hem de güvenlik duvarında o portu kapatın.

Kapanış#

Açık portları listelemek, sunucunuzun dış dünyaya açtığı kapıları görünür kılan basit ama son derece güçlü bir alışkanlıktır. ss -tulpn ile dinlenen portları anında görmeyi, lsof ve fuser ile bir portu tutan süreci bulmayı, ss -s ile bağlantı durumlarını özetlemeyi öğrendiniz. En önemlisi, bu bilgiyi güvenlik pratiğine bağladınız: gereksiz açık portları tespit edip servisleri yerelle sınırlamak ve güvenlik duvarıyla kapatmak, saldırı yüzeyinizi kalıcı biçimde daraltır. Bu denetimi özellikle her yeni yazılım kurulumundan sonra tekrarlamayı alışkanlık hâline getirin.

Bu tür güvenlik ve yönetim işlerini üzerinize almak yerine güçlü bir altyapının hazır gelmesini istiyorsanız, Clou.TR olarak sizi doğru çözüme yönlendirebiliriz. Tam kök erişimli, izole kaynaklara sahip VDS sunucularımız ile port ve güvenlik yapılandırmasının tümüne siz hükmedebilir; ya da düzenli port denetimi, güvenlik duvarı yönetimi ve sertleştirme dahil her şeyi bizim yürütmemizi istiyorsanız sunucu yönetimi hizmetimizle uzman ekibimize güvenebilirsiniz. İhtiyacınıza en uygun sunucu çözümünü birlikte belirleyelim.