ss Komutu ile Port ve Soket Durumu İzleme

Ağ sorunlarını debug ederken ya da sistemde hangi portların açık olduğunu kontrol etmek istediğinde, eski alışkanlıkla netstat komutunu çağırıyorsun ama bir süre sonra fark ediyorsun: artık pek çok modern Linux dağıtımında netstat varsayılan olarak kurulu gelmiyor. İşte tam bu noktada ss komutu devreye giriyor. ss, Socket Statistics’in kısaltması ve netstat‘ın yerini almak üzere tasarlanmış, çok daha hızlı ve modern bir araç. Bugün bu komutu her açıdan ele alacağız.

ss Komutu Nedir ve Neden Kullanmalısınız?

ss komutu, Linux çekirdeğinin sunduğu netlink arayüzünü kullanarak soket bilgilerini doğrudan çekirdekten alır. netstat ise /proc dosya sistemini okur. Bu fark, büyük sistemlerde ciddi bir performans avantajı yaratır. Binlerce bağlantı olan bir sunucuda netstat dakikalarca sürebilirken, ss aynı bilgiyi saniyeler içinde getirir.

ss komutu iproute2 paketinin bir parçasıdır. Sisteminizde kurulu olup olmadığını kontrol etmek için:

which ss
ss --version

Eğer kurulu değilse:

# Debian/Ubuntu
sudo apt install iproute2

# RHEL/CentOS/Fedora
sudo yum install iproute2

Temel Kullanım ve Parametreler

ss komutunu parametresiz çalıştırdığında, o anda kurulu olan tüm TCP bağlantılarını listeler. Ama asıl güç, parametrelerle birlikte kullanıldığında ortaya çıkar.

Temel parametreler şunlardır:

-t: Yalnızca TCP soketlerini gösterir
-u: Yalnızca UDP soketlerini gösterir
-l: Yalnızca dinleme (listening) modundaki soketleri gösterir
-a: Hem dinleyen hem de bağlı olan tüm soketleri gösterir
-n: Servis isimlerini çözümleme, sayısal IP ve port göster
-p: Soketi kullanan process bilgisini gösterir
-e: Genişletilmiş soket bilgisi gösterir
-s: Özet istatistikleri gösterir
-4: Yalnızca IPv4 soketlerini filtreler
-6: Yalnızca IPv6 soketlerini filtreler
-x: Unix domain soketlerini gösterir
-r: IP adreslerini hostname olarak çözümlemeye çalışır
-o: Timer bilgisini gösterir
-m: Bellek kullanım bilgisini gösterir

En sık kullandığım kombinasyon şu:

ss -tulpn

Bu komut; TCP ve UDP, listening modunda, process ismiyle birlikte ve sayısal format olarak soketleri listeler. Bir sunucuda ne çalışıyor diye baktığında bu komut sana her şeyi bir anda gösterir.

Pratik Kullanım Senaryoları

1. Hangi Portlar Açık?

Sunucuda hangi servislerin ayakta olduğunu görmek için en klasik kullanım:

ss -tulpn

Çıktı şöyle görünecek:

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=1234,fd=3))
tcp    LISTEN  0       511     0.0.0.0:80           0.0.0.0:*          users:(("nginx",pid=5678,fd=6))
tcp    LISTEN  0       511     0.0.0.0:443          0.0.0.0:*          users:(("nginx",pid=5678,fd=7))
tcp    LISTEN  0       128     127.0.0.1:3306       0.0.0.0:*          users:(("mysqld",pid=9012,fd=21))
udp    UNCONN  0       0       0.0.0.0:53           0.0.0.0:*          users:(("named",pid=3456,fd=512))

Bu çıktıdan şunları okuyabilirsin: SSH 22’de dinliyor, Nginx 80 ve 443’te açık, MySQL sadece localhost’tan erişilebilir (bu güvenlik açısından doğru), DNS ise 53 portunda UDP ile çalışıyor.

2. Belirli Bir Porta Bağlantıları İzleme

Bir uygulamaya kaç bağlantı geldiğini görmek istiyorsun, örneğin web sunucuna:

ss -tn dst :80

Ya da dport filtresiyle daha açık bir şekilde:

ss -tn dport = :443

Bir portu dinleyen process’i bulmak istiyorsun ama sadece o porta odaklanmak istiyorsun:

ss -tlpn sport = :8080

Bu özellikle birden fazla servis çalıştırdığında ve belirli bir portu kimin tuttuğunu hızlıca bulmak istediğinde işe yarıyor.

3. Belirli Bir IP’den Gelen Bağlantılar

Güvenlik olayı inceliyorsun ve belirli bir IP’nin sunucuna bağlandığını görüyorsun. O IP’den gelen tüm bağlantıları listelemek için:

ss -tn src 192.168.1.100

Ya da o IP’ye giden bağlantılar:

ss -tn dst 10.0.0.50

Daha da spesifik olmak istersen, hem IP hem port filtreleyebilirsin:

ss -tn dst 10.0.0.50 dport = :5432

4. TCP Durum Filtrelemeleri

TCP bağlantılarının durumlarını izlemek çok değerli. Özellikle TIME_WAIT ve CLOSE_WAIT durumları sorun yaratabilir.

# Sadece ESTABLISHED bağlantılar
ss -tn state established

# TIME_WAIT durumundaki bağlantılar
ss -tn state time-wait

# CLOSE_WAIT durumundaki bağlantılar
ss -tn state close-wait

# SYN_SENT durumundaki bağlantılar (bağlantı kurmaya çalışıyor)
ss -tn state syn-sent

# Birden fazla durum birlikte
ss -tn state established state time-wait

Kullanabileceğin TCP durumları şunlardır:

established: Aktif bağlantılar
syn-sent: SYN paketi gönderildi, cevap bekleniyor
syn-recv: SYN alındı, SYN-ACK gönderildi
fin-wait-1: Bağlantı kapatma başladı
fin-wait-2: Uzak tarafın FIN’i bekleniyor
time-wait: 2MSL bekleme süresi
close-wait: Uzak taraf bağlantıyı kapattı, yerel kapanma bekleniyor
last-ack: Son ACK bekleniyor
listen: Dinleme modunda
closing: Her iki taraf da aynı anda kapanıyor

5. Bağlantı Sayısını İzleme ve Raporlama

Sunucuda kaç aktif bağlantı var, özet istatistik almak için:

ss -s

Bu komut şöyle bir çıktı verir:

Total: 342
TCP:   287 (estab 245, closed 28, orphaned 3, timewait 25)

Transport Total  IP  IPv6
RAW       0      0   0
UDP       8      6   2
TCP       259    201 58
INET      267    207 60
FRAG      0      0   0

Bu özet, sisteminizin genel bağlantı sağlığını hızlıca anlamanı sağlar. Özellikle timewait ve closed sayıları dikkat gerektiren durumlarda yükseliyor.

İleri Seviye Kullanım

Process Bilgisiyle Soket Takibi

Belirli bir process’in hangi soketleri kullandığını görmek:

ss -tulpn | grep nginx

Ya da PID ile filtrelemek:

ss -tulp | grep pid=1234

Servis restart ettikten sonra yeni PID ile port’un bağlandığını doğrulamak için harika:

# Nginx restart et
sudo systemctl restart nginx

# Yeni PID ile portu kontrol et
ss -tlpn sport = :80

Unix Domain Soketleri

Sadece TCP/UDP değil, Unix domain soketlerini de izleyebilirsin. Bu özellikle MySQL, PostgreSQL, PHP-FPM gibi servislerde önemli:

ss -x

Sadece dinleyen Unix soketleri:

ss -xl

PHP-FPM’in socket dosyasını kontrol etmek için:

ss -xl | grep php

Bellek Kullanımı ile Birlikte

Soket başına bellek kullanımını görmek için:

ss -tm

Bu çok fazla bellek tüketen bağlantıları tespit etmede yardımcı olur. Büyük bir recv-q veya send-q değeri, bir uygulama sorununa işaret edebilir.

Timer Bilgisi

Bağlantılardaki timer durumlarını görmek için:

ss -to

Bu özellikle keepalive timer’larını ve time-wait süresini izlemek için kullanışlı.

Gerçek Dünya Senaryoları

Senaryo 1: “Sunucu Yavaşladı” Diyorlar

Klasik bir production sorunu: Gece yarısı alarm geliyor, uygulama yavaş çalışıyor. İlk yapacağın şey bağlantı durumunu kontrol etmek:

# Genel özet
ss -s

# TIME_WAIT bağlantı sayısını kontrol et
ss -tn state time-wait | wc -l

# CLOSE_WAIT bağlantılarını kontrol et (uygulama hatası işareti)
ss -tn state close-wait | wc -l

# Hangi IP'den en fazla bağlantı var
ss -tn state established | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Eğer binlerce TIME_WAIT görüyorsan, bu genellikle kısa süreli çok fazla bağlantının açılıp kapandığı anlamına gelir. Connection pooling eklemek ya da net.ipv4.tcp_tw_reuse kernel parametresini ayarlamak çözüm olabilir.

Eğer çok fazla CLOSE_WAIT görüyorsan, bu uygulama tarafının bağlantıları düzgün kapatmadığını gösterir. Genellikle kod seviyesinde bir bug’dır.

Senaryo 2: Port Çakışması Debuglama

Uygulama deploy ediyorsun ama “address already in use” hatası alıyorsun:

# Hangi process 8080'i tutuyor
ss -tlpn sport = :8080

# Ya da daha hızlı
ss -tlp | grep :8080

# PID'i bulduktan sonra
ps aux | grep [PID]

Bu, lsof -i :8080 komutuna iyi bir alternatif. Üstelik daha hızlı.

Senaryo 3: Firewall Kurallarını Doğrulama

Yeni bir firewall kuralı ekledin ve bir servisin sadece belirli bir IP’den erişilebilir olup olmadığını doğrulamak istiyorsun:

# Sadece belirli bir interface'den dinleyen servisleri gör
ss -tlpn | grep "10.0.0.1:"

# Dışarıdan erişilebilen portları listele (0.0.0.0 ile bind edilmiş)
ss -tlpn | grep "0.0.0.0:"

# Sadece localhost'tan erişilebilen portları listele
ss -tlpn | grep "127.0.0.1:"

Senaryo 4: Sürekli İzleme Scripti

Bir sorunu takip etmek için küçük bir monitoring scripti yazalım:

#!/bin/bash
# connection_monitor.sh
# Belirli aralıklarla bağlantı durumunu loglar

LOG_FILE="/var/log/connection_monitor.log"
INTERVAL=60

while true; do
    echo "=== $(date '+%Y-%m-%d %H:%M:%S') ===" >> $LOG_FILE
    
    # Özet istatistikler
    echo "--- Özet ---" >> $LOG_FILE
    ss -s >> $LOG_FILE
    
    # TIME_WAIT sayısı
    TW_COUNT=$(ss -tn state time-wait | wc -l)
    echo "TIME_WAIT bağlantı sayısı: $TW_COUNT" >> $LOG_FILE
    
    # CLOSE_WAIT sayısı
    CW_COUNT=$(ss -tn state close-wait | wc -l)
    echo "CLOSE_WAIT bağlantı sayısı: $CW_COUNT" >> $LOG_FILE
    
    # En fazla bağlantı kuran IP'ler
    echo "--- Top 5 Bağlantı Kaynağı ---" >> $LOG_FILE
    ss -tn state established | awk 'NR>1 {print $5}' | cut -d: -f1 | 
        sort | uniq -c | sort -rn | head -5 >> $LOG_FILE
    
    echo "" >> $LOG_FILE
    sleep $INTERVAL
done

Bu scripti systemd servisi ya da screen session’ı içinde çalıştırabilirsin.

Senaryo 5: DDoS veya Port Scan Tespiti

Güvenlik açısından şüpheli bir durum var, birinin sistemi taradığından şüpheleniyorsun:

# SYN_RECV durumunda çok fazla bağlantı var mı? (SYN flood işareti)
ss -tn state syn-recv | wc -l

# Hangi IP'lerden SYN gelmiş
ss -tn state syn-recv | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn

# Aynı IP'den çok sayıda farklı porta bağlantı (port scan işareti)
ss -tn | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -10

ss Çıktısını Anlamak

ss çıktısındaki sütunları doğru okumak önemli:

Netid: Soket tipi (tcp, udp, u_str, unix vs.)
State: Bağlantı durumu (LISTEN, ESTABLISHED, TIME-WAIT vs.)
Recv-Q: Uygulamanın henüz okumadığı veri miktarı (byte)
Send-Q: Karşı tarafa henüz iletilmemiş veri miktarı (byte)
Local Address:Port: Yerel adres ve port
Peer Address:Port: Uzak adres ve port
Process: Soketi kullanan process bilgisi

Recv-Q değeri sürekli yüksekse, uygulama gelen veriyi yeterince hızlı işleyemiyor demektir. Bu bir performans darboğazına işaret eder.

Send-Q değeri yüksekse, ağ yavaş ya da karşı taraf veriyi almıyor olabilir.

grep ile Kombinasyon Kullanımı

ss çıktısını grep ile filtrelemek çok yaygın:

# Sadece nginx soketleri
ss -tulpn | grep nginx

# 3306 portunu kullanan tüm bağlantılar
ss -tn | grep :3306

# 192.168 ile başlayan IP'lere bağlantılar
ss -tn | grep "192.168."

# LISTEN durumunda olmayan TCP bağlantıları
ss -tn | grep -v LISTEN

netstat ile Karşılaştırma

Eğer netstat kullanmaya alışkınsın, eşdeğer komutlar şunlar:

netstat -tulpn yerine ss -tulpn
netstat -an yerine ss -an
netstat -s yerine ss -s
netstat -rn için ss‘in bir karşılığı yok, bunun için ip route kullan

ss‘in avantajı açık: kernel space’den doğrudan bilgi alır, proc filesystem parse etmez. Sistemde 10.000 bağlantı varsa, netstat dakikalarca sürebilirken ss saniyeler içinde sonuç döner.

Alias ve Kısayollar

Sık kullandığın ss komutlarını .bashrc veya .bash_profile dosyasına alias olarak ekleyebilirsin:

# ~/.bashrc dosyasina ekle
alias ports='ss -tulpn'
alias connections='ss -tn state established'
alias listenwho='ss -tlpn'
alias sssum='ss -s'
alias timewait='ss -tn state time-wait | wc -l'

Sonra source ~/.bashrc ile aktif hale getir. Artık sunucuya bağlandığında ports yazmanız yeterli.

Sonuç

ss komutu, modern Linux sistemlerinde ağ soket izlemesi için standart araç haline geldi ve bunu hak ediyor. Hızı, esnekliği ve netstat‘a kıyasla sunduğu ekstra özelliklerle günlük sysadmin işlerinde vazgeçilmez bir araç. Özellikle ss -tulpn kombinasyonunu ezberlemen, pek çok sorunu saniyeler içinde teşhis etmene yardımcı olacak.

Akılda tutulması gereken en önemli nokta şu: soket durumlarını anlamak ve doğru okumak, sadece komutu bilmekten daha değerli. TIME_WAIT, CLOSE_WAIT, SYN_RECV gibi durumların ne anlama geldiğini kavradığında, ss sana sistemin ağ sağlığı hakkında çok detaylı bir hikaye anlatmaya başlıyor.

Production ortamında bir sonraki sorun anında, ss -s ile başla, oradan ss -tulpn ile devam et ve gerekirse state filtreleriyle derine in. Bu yaklaşım, çoğu ağ sorununu çok daha hızlı çözmeni sağlayacak.

ss Komutu ile Soket ve Port Durumu İzleme