Bu başlık, Almanya'nın ulusal siber olaylara müdahale ekibi olan CERT-Bund'dan gelen bir bildirimle açıldı: sunucumuz 111 numaralı portta, internetin her yerinden gelen portmapper sorgularını yanıtlıyordu. Yazının ilk sürümünde o gün çalıştırdığımız dört systemctl komutu vardı. Bu sürüm, aynı bildirim size ulaştığında izleyebileceğiniz bir müdahale kılavuzu (runbook) olarak yeniden yazıldı. Servisin ne olduğunu ve ona neyin bağlı olduğunu anlatıyor. Servisi kalıcı olarak kapatmayı ya da erişimini daraltmayı, portu da sunucunuzda gerçekten kullandığınız güvenlik duvarında (firewall) engellemeyi gösteriyor. Düzeltmeyi dışarıdan doğrulama ve bildirime yanıt verme adımlarıyla bitiyor.
Kısa cevap: Sunucu NFS ya da NIS kullanmıyorsa önce systemctl disable --now rpcbind.socket rpcbind.service, ardından systemctl mask rpcbind.socket rpcbind.service komutlarını çalıştırın. 111/tcp ve 111/udp portlarını IPv4 ve IPv6 için kapatın. Son olarak ağınızın dışındaki bir makineden rpcinfo -u genel-ip-adresiniz 100000 2 (UDP) ve rpcinfo -p genel-ip-adresiniz (TCP) komutlarının ikisinin de yanıt alamadığını doğrulayın; IPv6 adresini de nmap -6 ile kontrol edin (5. bölüm).
1. Portmapper ne işe yarar, 111 numaralı port neden bildirilir?
ONC RPC servislerinin çoğu ("Sun RPC" ailesi: NFSv3 ve onun mount ve kilit yardımcıları, NIS) sabit bir porta bağlı değildir. Her biri program numarasını, sürümünü ve dinlediği portu makinedeki bir kayıt servisine bildirir; istemciler de 111 numaralı portta çalışan bu servise nereye bağlanacaklarını sorar. Bu işi eskiden portmap adlı servis yapardı; protokol ise hâlâ portmapper adıyla anılır. Güncel Linux dağıtımlarında bu işi rpcbind yapar; protokolün 3. ve 4. sürümlerinin yanında portmapper (2. sürüm) sorgularını da yanıtlar. Ad sık sık "postmapper" diye yanlış yazılır (bu başlıkta da olduğu gibi); doğrusu portmapper'dır.Servis internetten erişilebilir olduğunda üç sorun doğar:
- Yansıtma ve yükseltme (reflection/amplification): UDP'de el sıkışma (handshake) yoktur. Bu yüzden saldırgan, kaynak adresi olarak kurbanın IP'sini yazdığı (IP spoofing) küçük bir sorgu gönderebilir. Sunucunuz da çok daha büyük bir yanıtı, yani kayıtlı RPC programlarının listesini, kurbana gönderir. ABD siber güvenlik ajansı CISA'nın UDP tabanlı yükseltme saldırıları hakkındaki TA14-017A uyarısı, Portmap (RPCbind) için bant genişliği yükseltme katsayısını (bandwidth amplification factor) 7 ile 28 arasında verir. Sunucunuz ve bant genişliğiniz, üçüncü bir tarafa yönelik bir DDoS saldırısının parçası olur.
- Bilgi sızıntısı: Aynı yanıt, hangi RPC servisinin hangi portta çalıştığını gösterir. mountd da erişilebilir durumdaysa showmount -e komutu NFS paylaşımlarınızı (export) listeler.
- Servisin kendi saldırı yüzeyi: rpcbind servisinde uzaktan tetiklenebilen hatalar görülmüştür. Örneğin CVE-2017-8779 ("rpcbomb") açığında, 111 numaralı porta gönderilen özel olarak hazırlanmış bir UDP paketi, rpcbind servisinin bir daha serbest bırakmadığı bellek ayırmasına yol açar; saldırgan bunu uzaktan hizmet engelleme (DoS) için kullanabilir.
Bu bildirimleri kim gönderir? CERT-Bund raporları, IP bloğu için RIPE veritabanında kayıtlı abuse adresine otomatik olarak gider; sağlayıcılardan da raporu etkilenen müşteriye iletmeleri istenir. BSI'nin SSS sayfasına göre veriler, tüm IPv4 adreslerinin her gün taranmasından gelir. Başka ulusal CERT'ler (örneğin İrlanda'nın NCSC'si) ve barındırma sağlayıcıları da benzer bildirimler gönderir. Bunlar çoğu zaman kâr amacı gütmeyen Shadowserver Vakfı'nın verilerine dayanır. Bize gelen bildirimin Almanca konu satırı "Offene Portmapper-Dienste" ("açık portmapper servisleri") ifadesiyle başlıyordu. Bildirimde IP adresimiz, UTC zaman damgaları ve sunucumuzun döndürdüğü RPC yanıtı yer alıyordu.
2. Kontrol: 111'de ne dinliyor ve neden?
İşe sunucunun kendisinde başlayın. -n seçeneğini atlamayın; o olmadan ss, port numarası yerine 111'in /etc/services dosyasındaki karşılığı olan "sunrpc" adını yazar ve grep hiçbir şey bulmaz:
Bash:
sudo ss -tulpn | grep ':111'
sudo ss -tulpn 'sport = :111' # tam eşleşme; grep ise 1110 veya 11111 gibi portları da yakalar
Code:
udp UNCONN 0 0 0.0.0.0:111 0.0.0.0:* users:(("rpcbind",pid=812,fd=5),("systemd",pid=1,fd=41))
tcp LISTEN 0 4096 0.0.0.0:111 0.0.0.0:* users:(("rpcbind",pid=812,fd=4),("systemd",pid=1,fd=40))
udp UNCONN 0 0 [::]:111 [::]:* users:(("rpcbind",pid=812,fd=7),("systemd",pid=1,fd=43))
tcp LISTEN 0 4096 [::]:111 [::]:* users:(("rpcbind",pid=812,fd=6),("systemd",pid=1,fd=42))
Bash:
rpcinfo -p localhost
systemctl status rpcbind.socket rpcbind.service
systemctl list-dependencies --reverse rpcbind.socket| Program | Ad | Anlamı |
|---|---|---|
| 100000 | portmapper | rpcbind servisinin kendisi |
| 100003 | nfs | bu makine bir NFS sunucusu |
| 100005 | mountd | sunucudaki NFSv3 mount servisi |
| 100021 | nlockmgr | NFSv3 dosya kilitleme (lockd) |
| 100024 | status | rpc.statd, NFSv3 kilit kurtarma (istemci veya sunucu) |
| 100004 / 100007 | ypserv / ypbind | NIS sunucusu / NIS istemcisi |
rpcbind paketini hangi paketin getirdiğini ve kaldırırsanız yanında neyin gideceğini bulun:
Bash:
# Debian / Ubuntu
apt-cache rdepends --installed rpcbind
apt-get -s remove rpcbind # yalnızca simülasyon: kaldırılacak her şeyi listeler
# RHEL, AlmaLinux, Rocky Linux, CentOS Stream, Fedora
rpm -q --whatrequires rpcbind
Bash:
findmnt -t nfs,nfs4 # bu makinede bağlı NFS paylaşımları
nfsstat -m # her NFS bağlamasının seçenekleri: vers=3 mü, vers=4.x mi
grep -E '\snfs4?\s' /etc/fstab
for u in nfs-server ypbind ypserv; do echo "$u: $(systemctl is-active $u)"; done
cat /etc/exports 2>/dev/null # bu makinenin dışa açtığı paylaşımlar3. Hangi yol size uygun?
| Durum | Yapılacak |
|---|---|
| NFS de NIS de yok (tipik web, e-posta ve veritabanı sunucuları) | rpcbind servisini durdurun, devre dışı bırakın ve maskeleyin (3a); isterseniz paketi kaldırın; 111'i güvenlik duvarında da kapatın |
| NFS istemcisi, bütün bağlamalar NFSv4 | rpcbind ve rpc-statd birimlerini maskeleyin (3a); /etc/fstab içinde vers=4.2 veya 4.1 sabitleyin |
| NFS sunucusu, bütün istemciler NFSv4 kullanabiliyor | Sunucuyu yalnızca NFSv4 sunacak şekilde yapılandırın (3b) |
| Kalması gereken bir NFSv3 istemcisi veya sunucusu | rpcbind kalsın; 111'e yalnızca güvenilen makinelerden izin verin (3c ve 4. bölüm) |
3a. NFS veya NIS yoksa: durdurun, devre dışı bırakın, maskeleyin
Bash:
sudo systemctl disable --now rpcbind.socket rpcbind.service
sudo systemctl mask rpcbind.socket rpcbind.service
sudo systemctl mask --now rpc-statd.service # yalnızca nfs-common / nfs-utils kurulu kalacaksa
systemctl is-enabled rpcbind.socket rpcbind.service # beklenen: masked, masked
sudo ss -tulpn 'sport = :111' # beklenen: yalnızca başlık satırıBu yazının ilk sürümü disable adımında durmuş ve servisin artık başka bir servis tarafından yeniden etkinleştirilemeyeceğini söylemişti. Bu yanlıştı. disable yalnızca enable komutunun oluşturduğu sembolik bağlantıları (symlink) kaldırır; devre dışı bırakılmış bir birim elle ya da bir bağımlılık üzerinden yine başlatılabilir. nfs-utils projesinin kendi (upstream) birim dosyalarında rpc-statd.service, rpcbind.socket birimini zorunlu bağımlılık (Requires) olarak tanımlar; nfs-server.service ise onu zayıf bağımlılık (Wants) olarak çeker. mount.nfs de bir NFSv3 paylaşımını bağlarken rpc-statd servisini başlatır. Bunlardan herhangi biri, bir sonraki yeniden başlatmada ya da bağlamada 111 numaralı portu geri getirir. mask ise birim dosyasını /dev/null'a yönlendiren bir sembolik bağlantı oluşturur; systemctl kılavuzu bunu, elle başlatma dahil her türlü etkinleştirmeyi engelleyen işlem olarak tanımlar. Düzeltmeyi kalıcı yapan adım budur.
Paketi kaldırmak (isteğe bağlı). Debian ve Ubuntu'da simülasyonun listesinde ihtiyacınız olan bir paket yoksa sudo apt purge rpcbind en temiz yoldur; nfs-common da onunla birlikte kaldırılır. NFS araçları üzerine kurulu platformlarda önce bu listeyi okuyun. Örneğin Proxmox VE kullanıcıları, apt paket yöneticisinin proxmox-ve ve pve-manager paketlerini de kaldırmayı önerdiğini bildiriyor; orada kaldırmak yerine maskeleyin. RHEL ailesinde dnf remove rpcbind, nfs-utils paketini ve ona bağlı paketleri de kaldırır; dnf onay istemeden önce işlemin tamamını gösterir. Yalnızca maskelemek de yeterlidir.
3b. NFS sunucusu: yalnızca NFSv4'e geçin
NFSv4, kilitlemeyi protokolün içinde yapar ve yalnızca 2049/TCP portuna ihtiyaç duyar. nfs(5) kılavuzu, NFSv4 istemcilerinin rpcbind servisine danışmadan doğrudan 2049 numaralı porta bağlandığını belirtir. Red Hat'in "Configuring an NFSv4-only server" yönergesi (RHEL 9 belgeleri) üç ana adımdan oluşur: NFSv3'ü kapatmak, NFSv3 servislerini maskelemek ve rpc.mountd servisinin NFSv3 mount isteklerini dinlemesini bir systemd drop-in dosyasıyla (ek yapılandırma parçası) durdurmak:
INI:
# /etc/nfs.conf
[nfsd]
vers3=n
# /etc/systemd/system/nfs-mountd.service.d/v4only.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/rpc.mountd --no-tcp --no-udp
Bash:
sudo systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket
sudo systemctl daemon-reload
sudo systemctl restart nfs-mountd nfs-server
sudo firewall-cmd --permanent --add-service=nfs && sudo firewall-cmd --reload # yalnızca 2049/tcp
cat /proc/fs/nfsd/versions # -3 görüyorsanız NFSv3 kapalıdır, ör. -3 +4 +4.1 +4.2
sudo ss -tulpn 'sport = :111' # yalnızca başlık satırı3c. NFSv3 kalmak zorundaysa: rpcbind kalsın, erişimi daraltın
NFSv3 kalacaksa rpcbind de kalır ve işi güvenlik duvarı üstlenir. 111 numaralı porta (TCP ve UDP) yalnızca ihtiyaç duyan makinelerden izin verin, diğer herkesten gelen paketleri düşürün (drop). NFSv3 sunucusunda mountd, statd ve lockd, /etc/nfs.conf içinde sabitlenmedikçe rastgele portlar kullanır; bu portları da aynı şekilde kısıtlayın. NFSv3 istemcisinde güvenilen makine NFS sunucusudur. Sunucu, kilitler ve kilit kurtarma için istemcideki lockd ve statd servislerine geri çağrı (callback) yapar. rpcbind servisini yalnızca özel (private) bir IP adresinde dinletmek için rpcbind.socket biriminin Listen satırlarını bir drop-in dosyasıyla değiştirmeniz gerekir (-h seçeneği soket etkinleştirmede yok sayılır); bir güvenlik duvarı kuralını denetlemek ise daha kolaydır.4. Güvenlik duvarı kuralları: sunucunuzda hangi araç çalışıyorsa
Önce sunucuda kuralları hangi güvenlik duvarı aracının yönettiğini bulun. Aynı kural setini değiştiren iki ayrı araç, "kapattım ama hâlâ açık" durumlarının sık rastlanan bir sebebidir. Örneklerde 192.0.2.10 güvenilen bir NFS makinesini temsil ediyor; 111'e kimsenin ihtiyacı yoksa bu satırları atlayın.
Bash:
systemctl list-units --type=service --state=active | grep -Ei 'firewalld|ufw|nftables|iptables|netfilter-persistent|csf|lfd'firewalld (RHEL ailesi)
Bash:
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all --zone=public
sudo firewall-cmd --permanent --zone=public --remove-service=rpc-bind
sudo firewall-cmd --permanent --zone=public --remove-port=111/tcp --remove-port=111/udp
# isteğe bağlı: tek bir güvenilen istemci
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.10" service name="rpc-bind" accept'
sudo firewall-cmd --reloadnftables
Bash:
sudo nft list ruleset | grep -n 'dport 111'
sudo nft insert rule inet filter input iifname != lo udp dport 111 drop
sudo nft insert rule inet filter input iifname != lo tcp dport 111 drop
# isteğe bağlı güvenilen makine: en son eklendiği için drop satırlarının üstüne yerleşir
sudo nft insert rule inet filter input ip saddr 192.0.2.10 udp dport 111 accept
sudo nft insert rule inet filter input ip saddr 192.0.2.10 tcp dport 111 acceptiptables ve ip6tables
Bash:
sudo iptables -S INPUT | grep -- '--dport 111'
# önce isteğe bağlı güvenilen makine, sonra drop kuralları
sudo iptables -I INPUT 1 -s 192.0.2.10 -p udp --dport 111 -j ACCEPT
sudo iptables -I INPUT 2 -s 192.0.2.10 -p tcp --dport 111 -j ACCEPT
sudo iptables -I INPUT 3 ! -i lo -p udp --dport 111 -j DROP
sudo iptables -I INPUT 4 ! -i lo -p tcp --dport 111 -j DROP
# IPv6 için ayrı bir tablo var
sudo ip6tables -I INPUT 1 ! -i lo -p udp --dport 111 -j DROP
sudo ip6tables -I INPUT 2 ! -i lo -p tcp --dport 111 -j DROPufw (Ubuntu)
Bash:
sudo ufw status verbose # etkin mi? gelen trafik için varsayılan politika ne?
sudo ufw status numbered
sudo ufw delete 5 # 111'e izin veren kuralın numarasını yazın
# isteğe bağlı güvenilen makine, ardından açık bir deny kuralı
sudo ufw allow from 192.0.2.10 to any port 111
sudo ufw deny 111cPanel ve DirectAdmin sunucularında CSF
CSF (ConfigServer Security & Firewall) yalnızca /etc/csf/csf.conf içinde listelenen portları açar. Önce dört port listesine (TCP_IN, UDP_IN, TCP6_IN, UDP6_IN) ve doğru bir listeyi boşa çıkarabilecek iki ayara bakın:
Bash:
grep -nE '^(TESTING|IPV6|TCP_IN|UDP_IN|TCP6_IN|UDP6_IN) ' /etc/csf/csf.conf
INI:
# önce: UDP_IN = "20,21,53,111,853,80,443"
# sonra: UDP_IN = "20,21,53,853,80,443"
TESTING = "0"
# yalnızca sunucunun bir IPv6 adresi varsa:
IPV6 = "1"
Code:
tcp|in|d=111|s=192.0.2.10
udp|in|d=111|s=192.0.2.10Sağlayıcı veya bulut güvenlik duvarı
Aynı kısıtlamayı sağlayıcınızın ağ güvenlik duvarında ya da güvenlik grubunda (security group) da uygulayın. Bunların çoğu izin listesi (allow-list) mantığıyla çalışır, yani 111 listede yer almamalıdır. IPv4 ve IPv6 kurallarını ayrı ayrı kontrol edin. Bu katman, sunucudaki güvenlik duvarı yanlışlıkla boşaltılsa bile korumayı sürdürür.5. Dışarıdan doğrulayın: IPv4 ve IPv6
Testi ağınızın dışından yapın; örneğin başka bir sağlayıcıdaki bir sunucudan. BSI'nin portmapper HOWTO sayfası, testin sunucunun kendisinde veya yerel ağda yapılmamasını söyler. nmap'in UDP taraması (-sU) root yetkisi ister. rpcinfo ve showmount, rpcbind ve NFS istemci paketleriyle gelir; ama tek başına nmap de yeterlidir. rpcinfo için test makinesine rpcbind kurarsanız oradaki servisi de maskeleyin; uzak sorgular yerel rpcbind servisine ihtiyaç duymaz. Örneklerdeki 203.0.113.25 ve 2001:db8::25, belgelerde kullanılmak üzere ayrılmış adreslerdir; yerlerine kendi adreslerinizi yazın.
Bash:
sudo nmap -sU -sT -p 111 203.0.113.25
sudo nmap -sU -sV -p 111 203.0.113.25 # "open" ile "open|filtered" sonucunu ayırır
rpcinfo -u 203.0.113.25 100000 2 # UDP: 111/udp üzerinden portmapper'a ping
rpcinfo -p 203.0.113.25 # TCP: kayıtlı programların dökümü
showmount -e 203.0.113.25
sudo nmap -6 -sU -sT -p 111 2001:db8::25 # test makinesinde IPv6 olmalı| Sonuç | Anlamı |
|---|---|
| 111/tcp closed veya filtered | TCP tarafı düzeltilmiş |
| 111/udp closed | Düzeltilmiş: dinleyen yok ya da güvenlik duvarı reddediyor (reject) |
| 111/udp open|filtered | Yanıt gelmedi; DROP kuralıyla beklenen sonuç budur, rpcinfo -u ile teyit edin |
| 111/udp open, servis rpcbind | Hâlâ açık |
| rpcinfo -u: program 100000 version 2 ready and waiting | Hâlâ açık: 111/udp yanıt veriyor, yansıtmada kullanılan taraf da bu |
| rpcinfo -u bir RPC hatasıyla bitiyor, genellikle Timed out (yaklaşık bir dakika sonra) ya da Unable to receive; tam metin sürüme göre değişir | UDP tarafı düzeltilmiş |
| rpcinfo -p bir program listesi yazdırıyor | Hâlâ açık (TCP) |
| rpcinfo -p: RPC: Remote system error - Connection timed out ya da Connection refused | TCP tarafı düzeltilmiş |
6. CERT'e veya abuse bildirimine yanıtta ne yazmalı?
Bildirimi sağlayıcınız ilettiyse yanıtı onun kanalından ve verdiği süre içinde gönderin. Bir CERT size doğrudan yazdıysa bildirimdeki talimatları izleyin. Etkilenen IPv4 ve IPv6 adreslerini, nedeni, UTC saatiyle düzeltmeyi, dışarıdan doğrulamayı ve sorunun tekrarlanmasını neyin engellediğini yazın. BSI, CERT-Bund raporlarının dijital olarak imzalandığını belirtir. Şüpheli görünen bir e-postada bağlantılara tıklamak yerine kendi IP adresinizi kendiniz test edin. Yabancı bir CERT'e veya sağlayıcıya yazıyorsanız aynı maddeleri İngilizce yazın; bu başlığın İngilizce sürümünde hazır bir örnek var.
Code:
Konu: Re: <bilet veya rapor numarası> 203.0.113.25 üzerinde açık portmapper
Merhaba,
Bildirilen bulgu doğrulandı ve giderildi.
Sunucu: 203.0.113.25 (IPv6: 2001:db8::25)
Neden: rpcbind, NFS istemci araçlarının bağımlılığı olarak kurulmuştu ve
111/tcp ile 111/udp üzerinde dinliyordu. Sunucuda NFS veya NIS kullanılmıyor.
Düzeltme (27.10.2026 09:40 UTC): rpcbind.socket ve rpcbind.service
durduruldu ve maskelendi; 111/tcp ve 111/udp sunucu güvenlik duvarında
(IPv4 ve IPv6) ve sağlayıcının ağ güvenlik duvarında kapatıldı.
Doğrulama (27.10.2026 09:55 UTC, harici bir makineden):
"rpcinfo -u 203.0.113.25 100000 2" (UDP) ve "rpcinfo -p 203.0.113.25" (TCP)
yanıt alamıyor; nmap hem IPv4 hem IPv6 adresinde 111/tcp için filtered,
111/udp için RPC yanıtı olmadan open|filtered gösteriyor.
Önleme: 111 numaralı port haftalık dış port kontrolümüze eklendi.
Saygılarımızla,
<ad, şirket, iletişim>7. Önleme: minimal kurulum ve dış taramalar
Minimal kurulum. Minimal bir imajla başlayın ve NFS istemci araçlarını yalnızca NFS paylaşımı bağlayan makinelere kurun. Sunucuyu hazırladıktan ve yeni paket kurduktan sonra ss -tulpn çıktısını beklediğiniz servis listesiyle karşılaştırın.İki katmanda varsayılan engelleme (default-deny). Sunucu güvenlik duvarı da sağlayıcı güvenlik duvarı da yalnızca gerçekten hizmet verdiğiniz portları listelesin. Yapılandırma yönetimi aracınız (Ansible vb.) da yeniden kurulan sunucularda rpcbind servisini maskeli tutsun.
Sunucularınızı düzenli olarak dışarıdan tarayın; bunu başka bir ağdaki bir makineden yapın:
Bash:
#!/bin/sh
# /usr/local/bin/check-portmapper.sh: ağınızın DIŞINDAKİ bir makinede çalıştırın
# crontab: 0 6 * * 1 /usr/local/bin/check-portmapper.sh
# IPv6 adresleri için 5. bölümdeki nmap -6 kontrolünü aynı takvime ekleyin
for ip in 203.0.113.25 203.0.113.26; do
if timeout 30 rpcinfo -u "$ip" 100000 2 >/dev/null 2>&1; then
echo "UYARI: $ip üzerinde portmapper 111/udp üzerinden yanıt veriyor"
fi
if timeout 30 rpcinfo -p "$ip" >/dev/null 2>&1; then
echo "UYARI: $ip üzerinde portmapper 111/tcp üzerinden yanıt veriyor"
fi
doneSorun giderme
| Belirti | Olası neden | Çözüm |
|---|---|---|
| "Warning: Stopping rpcbind.service, but it can still be activated by: rpcbind.socket" (systemd 254 ve öncesi) ya da "Stopping 'rpcbind.service', but its triggering units are still active: rpcbind.socket" (systemd 255 ve sonrası) | Yalnızca servis durduruldu | rpcbind.socket birimini de devre dışı bırakıp maskeleyin |
| 111 yeniden başlatmadan veya paketin yeniden kurulmasından sonra geri geldi | Birimler maskelenmemiş, yalnızca devre dışı bırakılmış: nfs-server, rpc-statd veya bir NFSv3 bağlaması rpcbind.socket birimini başlattı ya da yeniden kurulum birimi tekrar etkinleştirdi | İki birimi de maskeleyin (maske /etc/systemd/system altında durur, güncellemeler ona dokunmaz); systemctl list-dependencies --reverse rpcbind.socket çıktısına bakın |
| Her şey maskeli ama 111'de hâlâ bir şey dinliyor | Başka bir süreç; örneğin host ağını kullanıp kendi rpcbind servisini çalıştıran bir konteyner ya da 111 numaralı portu yayımlayan bir konteyner için docker-proxy | ss -tulpn çıktısındaki süreç sütununu okuyun ve o servisle ilgilenin |
| mount.nfs: rpc.statd is not running but is required for remote locking | Makine bir NFSv3 paylaşımı bağlıyor | Sunucu destekliyorsa vers=4.2 ile bağlayın; desteklemiyorsa maskeyi kaldırın (unmask), rpcbind kalsın ve 3c'yi izleyin |
| NFSv4'e geçişten sonra istemciler bağlanamıyor | İstemciler NFSv3 istiyor ya da bir betik showmount -e komutuna dayanıyor | İstemcilerde vers=4.2 veya 4.1 kullanın; sunucuda /proc/fs/nfsd/versions çıktısını kontrol edin |
| 111 hiçbir CSF listesinde yok ama hâlâ açık | TESTING = "1" kuralları her başlatmadan birkaç dakika sonra siliyor; IPV6 = "0"; csf durmuş ya da firewalld etkin olduğu için hiç başlamamış | TESTING = "0" yapın (sunucuda IPv6 varsa IPV6 = "1"), firewalld'yi durdurup devre dışı bırakın, csf -ra çalıştırın |
Sıkça sorulan sorular
Web veya e-posta sunucusunda rpcbind servisini kapatmak güvenli mi?Genellikle evet. Tipik bir web, e-posta veya veritabanı yazılım yığını ONC RPC kullanmaz. İstisnalar NFSv3 bağlamaları (yedeklerin bir NFS paylaşımına yazılması sık görülen bir örnektir), NIS ile oturum açma ve rpcbind servisine kaydolan nadir eski araçlardır; 2. bölümdeki kontroller üçünü de ortaya çıkarır.
NFSv4 için 111 numaralı port gerekli mi?
Hayır. NFSv4, TCP 2049'u kullanır ve kilitlemeyi protokolün içinde yapar. rpcbind ise NFSv2, NFSv3 ve bunların yardımcı servisleri (mountd, statd, lockd) ile NIS için gereklidir.
Bir güvenlik duvarı kuralı yetmez mi?
Açığı kapatır; NFSv3 kullanan bir makinede de asıl kontrol odur. Ama kural setleri boşalabilir ya da kaybolabilir: CSF'nin test modu kuralları siler, kimsenin kaydetmediği bir iptables kuralı da ilk yeniden başlatmada gider. Maskeleme dinleyen servisi ortadan kaldırır; böylece güvenlik duvarındaki bir hata sorunu geri getirmez.
Bildirim yalnızca IPv4'ten söz ediyor. IPv6'yı da kontrol etmem gerekir mi?
Evet. BSI'nin SSS sayfası IPv4 adreslerinin tarandığını anlatır; yani IPv6 üzerindeki bir açık bu raporlarda hiç görünmeyebilir. Oysa rpcbind.socket varsayılan olarak [::]:111 adresini de dinler ve yalnızca IPv4'e uygulanan bir kural (ip6tables olmadan iptables ya da IPV6 = "0" ayarlı CSF) bu kapıyı açık bırakır.
Bildirimler ne zaman kesilir?
BSI'nin SSS sayfasına göre sorun giderildikten sonra daha yeni zaman damgalı bir bildirim gelmemesi gerekir. Düzeltmeden sonra gelen ama zaman damgası düzeltmeden önceye ait olan bildirim, eski bir taramanın sonucudur. Daha yeni zaman damgalı bir bildirim ise portun bir yerde, belki başka bir IP adresinizde, hâlâ erişilebilir olduğunu gösterir.
Sonuç ve sonraki adımlar
Açık portmapper sorunu kısa sürede çözülür ve sık yapılan hatalar bellidir: rpcbind maskelenmeden yalnızca devre dışı bırakılır, IPv4 kapatılırken IPv6 açık unutulur ya da UDP tarafı yalnızca TCP'yi sınayan rpcinfo -p ile "doğrulanır". rpcbind servisini neyin kullandığını bulun. Hiçbir şey kullanmıyorsa servisi maskeleyin; makine bir NFS sunucusuysa onu yalnızca NFSv4'e geçirin. 111'i gerçekten kullandığınız güvenlik duvarında kısıtlayın, iki IP sürümünde hem TCP'yi hem UDP'yi dışarıdan test edin ve bildirime saat ve kanıtla yanıt verin. Sonraki adım olarak dış kontrolü takvime bağlayın. Daha geniş bir sıkılaştırma (hardening) temeli için 2026'da Sunucu Sıkılaştırma: Canlı Linux Sunucular için Asgari Güvenlik ve Canlı Sistemler için Sunucu Sıkılaştırma: Paranoyasız Katmanlı Savunma başlıklarını inceleyin. Bu işi bir ekibe bırakmak isterseniz AIOR'un siber güvenlik, yedekleme ve veri koruma hizmetleri sunucu sıkılaştırmayı ve port güvenliğini kapsar. Kendi dağıtımınıza veya kontrol panelinize özel sorularınızı bu başlıkta sorabilirsiniz.A notice from CERT-Bund, Germany's national CERT, started this thread: our server was answering portmapper requests on port 111 from anywhere on the internet. The first version of this post listed the four systemctl commands we ran. This revision is a runbook for the day the same notice reaches you. It covers what the service is, what depends on it, how to switch it off for good or restrict it, and how to close the port in the firewall you actually use. It ends with how to prove the fix from outside and answer the report.
Short answer: if the server uses neither NFS nor NIS, run systemctl disable --now rpcbind.socket rpcbind.service, then systemctl mask rpcbind.socket rpcbind.service. Block 111/tcp and 111/udp for IPv4 and IPv6, and confirm from a host outside your network that neither rpcinfo -u your-public-ip 100000 2 (UDP) nor rpcinfo -p your-public-ip (TCP) gets an answer. Check the IPv6 address with nmap -6 as well (section 5).
1. What portmapper does and why port 111 gets reported
Most ONC RPC services (the "Sun RPC" family: NFSv3 with its mount and lock helpers, NIS) are not tied to fixed ports. Each registers its program number and version with a local directory, and clients ask that directory, on port 111, where to connect. The old daemon was called portmap and the protocol is still known as portmapper. Current Linux distributions run rpcbind, which answers portmapper (version 2) queries alongside versions 3 and 4. You will also see the name misspelled "postmapper", as in this thread's title; the correct term is portmapper.When the service is reachable from the internet, it causes three problems:
- Reflection and amplification: UDP has no handshake, so an attacker can send a small query with the victim's address forged as the source. Your server then sends its much larger answer, the list of registered RPC programs, to the victim. CISA's alert TA14-017A on UDP-based amplification attacks lists Portmap (RPCbind) with a bandwidth amplification factor of 7 to 28. Your server and your bandwidth become part of a DDoS attack on a third party.
- Information disclosure: the same answer shows which RPC services run on which ports. If mountd is reachable too, showmount -e lists your NFS exports.
- Its own attack surface: rpcbind has had remotely triggerable bugs, such as CVE-2017-8779 ("rpcbomb"), where a crafted UDP packet to port 111 makes rpcbind allocate memory that it never frees, allowing a remote denial of service.
Who sends these notices. CERT-Bund reports go automatically to the abuse contact registered at RIPE for the IP range, and providers are asked to forward them to the affected customer. According to the BSI's FAQ, the data comes from daily scans of all IPv4 addresses. Other national CERTs (Ireland's NCSC, for example) and hosting providers send similar notices, often based on data from the non-profit Shadowserver Foundation. Ours had a German subject beginning "Offene Portmapper-Dienste" (open portmapper services) and listed our IP, UTC timestamps and the RPC response our server had returned.
2. Check what is listening and why
Start on the server. Keep -n, otherwise ss prints "sunrpc" (the /etc/services name for port 111) and the grep finds nothing:
Bash:
sudo ss -tulpn | grep ':111'
sudo ss -tulpn 'sport = :111' # exact match; the grep also matches ports such as 1110 or 11111
Code:
udp UNCONN 0 0 0.0.0.0:111 0.0.0.0:* users:(("rpcbind",pid=812,fd=5),("systemd",pid=1,fd=41))
tcp LISTEN 0 4096 0.0.0.0:111 0.0.0.0:* users:(("rpcbind",pid=812,fd=4),("systemd",pid=1,fd=40))
udp UNCONN 0 0 [::]:111 [::]:* users:(("rpcbind",pid=812,fd=7),("systemd",pid=1,fd=43))
tcp LISTEN 0 4096 [::]:111 [::]:* users:(("rpcbind",pid=812,fd=6),("systemd",pid=1,fd=42))
Bash:
rpcinfo -p localhost
systemctl status rpcbind.socket rpcbind.service
systemctl list-dependencies --reverse rpcbind.socket| Program | Name | Meaning |
|---|---|---|
| 100000 | portmapper | rpcbind itself |
| 100003 | nfs | this host is an NFS server |
| 100005 | mountd | NFSv3 mount service on a server |
| 100021 | nlockmgr | NFSv3 file locking (lockd) |
| 100024 | status | rpc.statd, NFSv3 lock recovery (client or server) |
| 100004 / 100007 | ypserv / ypbind | NIS server / NIS client |
Find the package that pulled rpcbind in, and what removing it would take along:
Bash:
# Debian / Ubuntu
apt-cache rdepends --installed rpcbind
apt-get -s remove rpcbind # simulation only: lists everything that would be removed
# RHEL, AlmaLinux, Rocky Linux, CentOS Stream, Fedora
rpm -q --whatrequires rpcbind
Bash:
findmnt -t nfs,nfs4 # NFS shares mounted on this host
nfsstat -m # options of each NFS mount: vers=3 or vers=4.x
grep -E '\snfs4?\s' /etc/fstab
for u in nfs-server ypbind ypserv; do echo "$u: $(systemctl is-active $u)"; done
cat /etc/exports 2>/dev/null # shares this host exports3. Decide which path is yours
| Situation | Action |
|---|---|
| No NFS, no NIS (typical web, mail and database servers) | Stop, disable and mask rpcbind (3a); optionally remove the package; block 111 anyway |
| NFS client, every mount is NFSv4 | Mask rpcbind and rpc-statd (3a); pin vers=4.2 or 4.1 in /etc/fstab |
| NFS server, every client can use NFSv4 | Convert it to an NFSv4-only server (3b) |
| An NFSv3 client or server that must stay | Keep rpcbind; allow 111 only from trusted hosts (3c and section 4) |
3a. No NFS or NIS: stop, disable and mask
Bash:
sudo systemctl disable --now rpcbind.socket rpcbind.service
sudo systemctl mask rpcbind.socket rpcbind.service
sudo systemctl mask --now rpc-statd.service # only if nfs-common / nfs-utils stays installed
systemctl is-enabled rpcbind.socket rpcbind.service # expect: masked, masked
sudo ss -tulpn 'sport = :111' # expect: the header line onlyThe first version of this post stopped at disable and claimed the service could no longer be reactivated by another service. That was wrong. disable only removes the symlinks that enable created, so a disabled unit can still be started by hand or as a dependency. In the upstream nfs-utils units, rpc-statd.service requires rpcbind.socket and nfs-server.service wants it. mount.nfs also starts rpc-statd when it mounts an NFSv3 share. Any of these brings port 111 back at the next reboot or mount. mask links the unit to /dev/null, which the systemctl manual describes as prohibiting all kinds of activation, manual starts included. That is what makes the fix stick.
Removing the package (optional). On Debian and Ubuntu, sudo apt purge rpcbind is clean when the simulation lists nothing you need; nfs-common goes with it. Read that list first on platforms built on the NFS tools. Proxmox VE users, for example, report apt proposing to remove proxmox-ve and pve-manager too, so mask instead. On the RHEL family, dnf remove rpcbind also removes nfs-utils and its dependents, showing the transaction before it asks. Masking alone is enough.
3b. NFS server: switch to NFSv4-only
NFSv4 handles locking inside the protocol and needs only TCP 2049. The nfs(5) manual notes that NFSv4 clients connect to 2049 without consulting rpcbind. Red Hat's procedure "Configuring an NFSv4-only server" (RHEL 9 documentation) has three parts: turn NFSv3 off, mask the NFSv3 services, and stop rpc.mountd from listening for NFSv3 mount requests:
INI:
# /etc/nfs.conf
[nfsd]
vers3=n
# /etc/systemd/system/nfs-mountd.service.d/v4only.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/rpc.mountd --no-tcp --no-udp
Bash:
sudo systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket
sudo systemctl daemon-reload
sudo systemctl restart nfs-mountd nfs-server
sudo firewall-cmd --permanent --add-service=nfs && sudo firewall-cmd --reload # 2049/tcp only
cat /proc/fs/nfsd/versions # NFSv3 is off when you see -3, e.g. -3 +4 +4.1 +4.2
sudo ss -tulpn 'sport = :111' # header line only3c. NFSv3 must stay: keep rpcbind, restrict it
If NFSv3 must stay, so does rpcbind, and the firewall does the work. Allow 111 (TCP and UDP) only from the hosts that need it and drop it for everyone else. On an NFSv3 server, mountd, statd and lockd use random ports unless you pin them in /etc/nfs.conf, so restrict those the same way. On an NFSv3 client, the trusted host is the NFS server, which calls back the client's lockd and statd for locks and lock recovery. Binding rpcbind to a private address means overriding the Listen lines of rpcbind.socket with a drop-in (its -h option is ignored under socket activation), and a firewall rule is easier to audit.4. Firewall recipes for the tool your server runs
First find out which firewall tool manages the rules. Two tools editing one rule set are a common cause of "closed, but still open" cases. In the examples, 192.0.2.10 stands for a trusted NFS host; skip those lines if nobody needs 111.
Bash:
systemctl list-units --type=service --state=active | grep -Ei 'firewalld|ufw|nftables|iptables|netfilter-persistent|csf|lfd'firewalld (RHEL family)
Bash:
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all --zone=public
sudo firewall-cmd --permanent --zone=public --remove-service=rpc-bind
sudo firewall-cmd --permanent --zone=public --remove-port=111/tcp --remove-port=111/udp
# optional: a single trusted client
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.10" service name="rpc-bind" accept'
sudo firewall-cmd --reloadnftables
Bash:
sudo nft list ruleset | grep -n 'dport 111'
sudo nft insert rule inet filter input iifname != lo udp dport 111 drop
sudo nft insert rule inet filter input iifname != lo tcp dport 111 drop
# optional trusted host: inserted last, so these land above the drops
sudo nft insert rule inet filter input ip saddr 192.0.2.10 udp dport 111 accept
sudo nft insert rule inet filter input ip saddr 192.0.2.10 tcp dport 111 acceptiptables and ip6tables
Bash:
sudo iptables -S INPUT | grep -- '--dport 111'
# optional trusted host first, then the drops
sudo iptables -I INPUT 1 -s 192.0.2.10 -p udp --dport 111 -j ACCEPT
sudo iptables -I INPUT 2 -s 192.0.2.10 -p tcp --dport 111 -j ACCEPT
sudo iptables -I INPUT 3 ! -i lo -p udp --dport 111 -j DROP
sudo iptables -I INPUT 4 ! -i lo -p tcp --dport 111 -j DROP
# IPv6 has its own table
sudo ip6tables -I INPUT 1 ! -i lo -p udp --dport 111 -j DROP
sudo ip6tables -I INPUT 2 ! -i lo -p tcp --dport 111 -j DROPufw (Ubuntu)
Bash:
sudo ufw status verbose # active? default policy for incoming?
sudo ufw status numbered
sudo ufw delete 5 # use the number of any rule that allows 111
# optional trusted host, followed by an explicit deny
sudo ufw allow from 192.0.2.10 to any port 111
sudo ufw deny 111CSF on cPanel and DirectAdmin servers
CSF (ConfigServer Security & Firewall) opens only the ports listed in /etc/csf/csf.conf. Start by reading the four port lists (TCP_IN, UDP_IN, TCP6_IN, UDP6_IN) and the two settings that can undo a correct list:
Bash:
grep -nE '^(TESTING|IPV6|TCP_IN|UDP_IN|TCP6_IN|UDP6_IN) ' /etc/csf/csf.conf
INI:
# before: UDP_IN = "20,21,53,111,853,80,443"
# after: UDP_IN = "20,21,53,853,80,443"
TESTING = "0"
# only if the server has an IPv6 address:
IPV6 = "1"
Code:
tcp|in|d=111|s=192.0.2.10
udp|in|d=111|s=192.0.2.10Provider or cloud firewall
Repeat the restriction in your provider's network firewall or security group. Most of these are allow-lists, so 111 simply must not be listed. Check the IPv4 and IPv6 rules separately. This layer still holds if the host firewall gets flushed by mistake.5. Verify from outside, over IPv4 and IPv6
Test from outside your network, for example from a server at another provider. The BSI's portmapper HOWTO warns against testing on the host itself or from the local network. nmap's UDP scan (-sU) needs root. rpcinfo and showmount come with the rpcbind and NFS client packages, but nmap alone is enough. If you install rpcbind on the test host to get rpcinfo, mask the service there too; remote queries do not need a local rpcbind. 203.0.113.25 and 2001:db8::25 are documentation addresses; use your own.
Bash:
sudo nmap -sU -sT -p 111 203.0.113.25
sudo nmap -sU -sV -p 111 203.0.113.25 # separates "open" from "open|filtered"
rpcinfo -u 203.0.113.25 100000 2 # UDP: ping portmapper over 111/udp
rpcinfo -p 203.0.113.25 # TCP: dump the registered programs
showmount -e 203.0.113.25
sudo nmap -6 -sU -sT -p 111 2001:db8::25 # the test machine needs IPv6| Result | Meaning |
|---|---|
| 111/tcp closed or filtered | Fixed for TCP |
| 111/udp closed | Fixed: nothing listens, or the firewall rejects |
| 111/udp open|filtered | No answer came back, the expected result with a DROP rule; confirm with rpcinfo -u |
| 111/udp open, service rpcbind | Still exposed |
| rpcinfo -u: program 100000 version 2 ready and waiting | Still exposed: 111/udp answers, and that is the side used for reflection |
| rpcinfo -u ends with an RPC error, usually Timed out (after about a minute) or Unable to receive; the exact text varies by version | Fixed for UDP |
| rpcinfo -p prints a program list | Still exposed (TCP) |
| rpcinfo -p: RPC: Remote system error - Connection timed out, or Connection refused | Fixed for TCP |
6. What to put in your reply to the CERT or abuse report
If your provider forwarded the notice, answer through its channel and within its deadline. If a CERT wrote to you directly, follow the instructions in the notice. Give the affected IPv4 and IPv6 addresses, the cause, the fix with a UTC time, the external verification and what prevents a repeat. The BSI says CERT-Bund reports are digitally signed. If an e-mail looks suspicious, test your IP yourself instead of following its links.
Code:
Subject: Re: <ticket or report number> open portmapper on 203.0.113.25
Hello,
The finding is confirmed and fixed.
Host: 203.0.113.25 (IPv6 2001:db8::25)
Cause: rpcbind was installed as a dependency of the NFS client tools and
listened on 111/tcp and 111/udp. The server does not use NFS or NIS.
Fix (2026-10-27 09:40 UTC): rpcbind.socket and rpcbind.service stopped
and masked; 111/tcp and 111/udp blocked in the host firewall (IPv4 and
IPv6) and in the provider's network firewall.
Verification (2026-10-27 09:55 UTC, from an external host):
"rpcinfo -u 203.0.113.25 100000 2" (UDP) and "rpcinfo -p 203.0.113.25"
(TCP) get no answer; nmap reports 111/tcp filtered and 111/udp
open|filtered with no RPC reply, on both the IPv4 and the IPv6 address.
Prevention: port 111 is now part of our weekly external port check.
Regards,
<name, company, contact>7. Prevention: minimal installs and external scans
Minimal installs. Start from a minimal image and install NFS client tools only where NFS is mounted. After provisioning, and after adding packages, compare ss -tulpn with the services you expect.Default-deny on two layers. The host firewall and the provider firewall should each list only the ports you serve, and configuration management should keep rpcbind masked on rebuilt servers.
Scan your servers from outside, on a schedule, from a host in another network:
Bash:
#!/bin/sh
# /usr/local/bin/check-portmapper.sh, run from a host OUTSIDE your network
# crontab: 0 6 * * 1 /usr/local/bin/check-portmapper.sh
# IPv6 addresses: add the nmap -6 check from section 5 to the same schedule
for ip in 203.0.113.25 203.0.113.26; do
if timeout 30 rpcinfo -u "$ip" 100000 2 >/dev/null 2>&1; then
echo "ALERT: portmapper answers on $ip over 111/udp"
fi
if timeout 30 rpcinfo -p "$ip" >/dev/null 2>&1; then
echo "ALERT: portmapper answers on $ip over 111/tcp"
fi
doneTroubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| "Warning: Stopping rpcbind.service, but it can still be activated by: rpcbind.socket" (systemd 254 and older) or "Stopping 'rpcbind.service', but its triggering units are still active: rpcbind.socket" (systemd 255 and newer) | Only the service was stopped | Disable and mask rpcbind.socket as well |
| Port 111 is back after a reboot or a package reinstall | Disabled, not masked: nfs-server, rpc-statd or an NFSv3 mount pulled rpcbind.socket in, or a reinstall enabled it again | Mask both units (the mask lives in /etc/systemd/system and updates leave it alone); check systemctl list-dependencies --reverse rpcbind.socket |
| Everything is masked, yet something still listens on 111 | Another process, for example a container that runs its own rpcbind with host networking, or docker-proxy for a container that publishes port 111 | Read the process column of ss -tulpn and deal with that service |
| mount.nfs: rpc.statd is not running but is required for remote locking | The host mounts an NFSv3 share | Mount with vers=4.2 if the server supports it; otherwise unmask, keep rpcbind and follow 3c |
| Clients cannot mount after the NFSv4-only change | They ask for NFSv3, or a script relies on showmount -e | Use vers=4.2 or 4.1 on the clients; check /proc/fs/nfsd/versions on the server |
| 111 is in no CSF list but still open | TESTING = "1" flushes the rules a few minutes after each start; IPV6 = "0"; csf is stopped, or never started because firewalld is active | Set TESTING = "0" (and IPV6 = "1" if the server has IPv6), stop and disable firewalld, run csf -ra |
FAQ
Is it safe to turn rpcbind off on a web or mail server?Usually, yes. A typical web, mail or database stack does not use ONC RPC. The exceptions are NFSv3 mounts (backups to an NFS share are a common case), NIS logins and the rare legacy tool that registers with rpcbind; the checks in section 2 reveal all three.
Does NFSv4 need port 111?
No. NFSv4 uses TCP 2049 and handles locking inside the protocol. rpcbind is needed for NFSv2 and NFSv3 with their helpers (mountd, statd, lockd), and for NIS.
Isn't a firewall rule enough?
It closes the hole, and on an NFSv3 host it is the main control. But rule sets do get emptied or lost: CSF's test mode flushes them, and an iptables rule nobody saved disappears at the next reboot. Masking removes the listener, so a firewall slip does not bring the problem back.
The notice only mentions IPv4. Do I need to care about IPv6?
Yes. The BSI's FAQ describes scans of IPv4 addresses, so an IPv6 exposure may never show up in a report. rpcbind.socket still listens on [::]:111 by default, and an IPv4-only rule (iptables without ip6tables, or CSF with IPV6 = "0") leaves that open.
When do the notices stop?
According to the BSI's FAQ, no notification with a later timestamp should arrive once the problem is fixed. A notice that arrives after your fix but carries a timestamp from before it reflects an older scan. One with a later timestamp means the port is still reachable somewhere, perhaps on another of your IPs.
Conclusion and next steps
An open portmapper is a short fix, and the common mistakes are predictable: rpcbind gets disabled but not masked, IPv4 gets closed while IPv6 stays open, or the UDP side is "verified" with rpcinfo -p, which only tests TCP. Find what uses rpcbind and mask it if nothing does, or move NFS to NFSv4-only. Restrict 111 in the firewall you actually run, test TCP and UDP from outside over both IP versions, and answer the report with times and evidence. Next, schedule the external check and work through the wider baseline in Server hardening in 2026: minimum viable security for production Linux and Server hardening for production teams: defence in depth, without paranoia. If you would rather hand this to a team, AIOR's cybersecurity, backup and data protection services include server hardening and port security. Questions about your own distribution or control panel are welcome in this thread.
Last edited:
