UnrealIRCd 6 Sunucu Linkleme Güvenliği: spkifp Doğrulama, serversonly TLS Portu ve Hub/Leaf Rehberi

Bir IRC ağında sunucu linki, tek bir kullanıcı bağlantısıyla kıyaslanamayacak kadar yüksek güven taşır. Link kurulduğu anda karşı taraf; kullanıcı listesini, kanal durumlarını, mod değişikliklerini ve oper komutlarını ağa yayabilir. Bu nedenle yanlış yapılandırılmış tek bir link bloğu, tüm ağın devralınmasıyla sonuçlanabilir.

UnrealIRCd 6, bu riski azaltmak için parola yerine spkifp (SPKI parmak izi) doğrulamasını, yalnız sunuculara ayrılmış TLS portlarını ve hub/leaf topoloji kısıtlarını sunar. Bu rehberde iki sunucuyu güvenli biçimde linklemeyi, sertifika parmak izi doğrulamasını, Let's Encrypt ile sertifika yönetimini ve sık yapılan hataları inceleyeceğiz.

1. Link güvenliğinin katmanları

Katman	Ne yapar?	Atlanırsa ne olur?
Ayrı serversonly port	Sunucu linkini kullanıcı portundan ayırır	Kullanıcılar link portunu tarar ve deneme yapar
TLS zorunluluğu	Link trafiğini şifreler	Parola ve ağ trafiği yolda okunabilir
spkifp doğrulama	Karşı sunucunun anahtarını kriptografik olarak bağlar	Parolayı ele geçiren herkes sunucu olabilir
incoming::mask	Bağlantıyı belirli IP'lerle sınırlar	Dünyanın her yerinden deneme yapılabilir
class limitleri	Ping/bağlantı davranışını ayırır	Kullanıcı sınıfı limitleri linki bozar
hub/leaf	Topolojiyi zorunlu kılar	Yetkisiz sunucu ağa dallanabilir
deny link	Belirli link kalıplarını reddeder	Beklenmeyen rota kabul edilir

Bu katmanların hiçbiri tek başına yeterli değildir. Özellikle parola tek başına bir kimlik doğrulama değildir: yapılandırma dosyası sızdığında ya da yedekten okunduğunda parola saldırgana geçer. spkifp ise karşı tarafın özel anahtarını gerektirir.

2. Sunuculara ayrılmış TLS portu

İlk adım, kullanıcı portlarından tamamen ayrı bir link portu tanımlamaktır. Geleneksel tercih 6900/TCP'dir.

CODE TERMINAL

listen {
    ip *;
    port 6900;
    options { tls; serversonly; }
};

serversonly seçeneği, bu porta bağlanan istemcilerin kullanıcı olarak kabul edilmesini engeller. tls seçeneği ise bağlantının baştan şifreli olmasını sağlar; düz metin link portu 2026 koşullarında kabul edilebilir değildir.

Portu internete tamamen açmak da gerekmez. Link yalnız bilinen bir IP'den gelecekse, güvenlik duvarında bu porta erişimi o adrese kısıtlayın:

CODE TERMINAL

# Yalnız karşı sunucunun IP'sine izin ver
iptables -A INPUT -p tcp --dport 6900 -s 203.0.113.25 -j ACCEPT
iptables -A INPUT -p tcp --dport 6900 -j DROP

Böylece IRCd'ye ulaşan deneme sayısı en baştan sıfıra iner. Bu, uygulama katmanındaki kontrolün yerine geçmez; onu tamamlar.

3. Sunucu sınıfı (class) tanımı

Sunucu linkleri kullanıcı sınıfıyla aynı limitlere tabi tutulmamalıdır. Bir link, kullanıcıdan çok daha uzun süre açık kalır ve çok daha büyük veri aktarır.

CODE TERMINAL

class servers {
    pingfreq 60;
    maxclients 10;
    sendq 20M;
    recvq 8000;
};

pingfreq kullanıcı sınıfına göre daha uzun tutulur; gereksiz kopmayı azaltır.
maxclients ağdaki sunucu sayısına göre belirlenir, bol bırakılmaz.
sendq netsplit sonrası burst trafiğini karşılayacak kadar geniş olmalıdır; düşük değer link kopmalarına yol açar.
recvq sunucu linklerinde kullanıcı sınıfındaki gibi agresif tutulmaz.

Küçük bir `sendq` değeri, özellikle büyük kanalların senkronize olduğu ilk saniyelerde "Max SendQ exceeded" hatasıyla linkin sürekli kopmasına neden olur. Bu, sahada en sık karşılaşılan link sorunudur.

4. spkifp parmak izini alma

SPKI parmak izi, sunucunun TLS sertifikasındaki açık anahtarın özetidir. Sertifika yenilendiğinde anahtar değişmediği sürece parmak izi de değişmez; bu, Let's Encrypt gibi kısa ömürlü sertifikalarla çalışırken belirleyici bir avantajdır.

*NIX sistemlerde UnrealIRCd dizininde:

CODE TERMINAL

./unrealircd spkifp

Windows üzerinde:

CODE TERMINAL

unrealircdctl spkifp

Çıktı şu biçimdedir:

CODE TERMINAL

SPKI Fingerprint=AHMYBevUxXKU/S3pdBSjXP4zi4VOetYQQVJXoNYiBR0=

Buradaki en kritik kural şudur: link bloğuna karşı sunucunun parmak izi yazılır, kendi sunucunuzunki değil. Bu ayrım, linkleme sırasında en sık yapılan hatadır ve "no matching link block" benzeri yanıltıcı hatalarla sonuçlanır.

5. Link bloğu: iki taraflı örnek

İki sunucu düşünelim: irc1.example.net (hub, 203.0.113.10) ve irc2.example.net (leaf, 203.0.113.25). Bağlantıyı leaf başlatsın.

Hub tarafında (`irc1` üzerinde, irc2'yi tanımlar):

CODE TERMINAL

link irc2.example.net {
    incoming {
        mask 203.0.113.25;
    }
    password "AHMYBevUxXKU/S3pdBSjXP4zi4VOetYQQVJXoNYiBR0=" { spkifp; }
    class servers;
};

Leaf tarafında (`irc2` üzerinde, irc1'i tanımlar):

CODE TERMINAL

link irc1.example.net {
    incoming {
        mask 203.0.113.10;
    }
    outgoing {
        bind-ip *;
        hostname irc1.example.net;
        port 6900;
        options { tls; autoconnect; }
    }
    password "yZkIeP0y7RDfJ3n7qBQvW1sVn1mQK2u4Xe8CkKdAs0Y=" { spkifp; }
    hub *;
    class servers;
};

Dikkat edilecek noktalar:

Her iki tarafta da `password` alanı karşı tarafın SPKI parmak izidir; iki taraf farklı değer içerir.
`{ spkifp; }` eki olmadan değer düz parola gibi yorumlanır.
`incoming::mask` her iki tarafta da tanımlanmalıdır; yalnız outgoing tanımlamak gelen bağlantıyı sınırlamaz.
`outgoing` bloğu yalnız bağlantıyı başlatan tarafta gereklidir.
`options { tls; }` yazılmazsa bağlantı şifresiz denenebilir.
`autoconnect` yalnız tek tarafta açılmalıdır; iki taraf da açarsa çakışan bağlantılar oluşur.

6. hub, leaf ve leaf-depth

Topoloji kısıtları, ele geçirilmiş ya da yanlış yapılandırılmış bir sunucunun ağa beklenmeyen bir dal eklemesini engeller.

Ayar	Anlamı	Tipik kullanım
hub <mask>	Bu sunucunun hangi sunucuları ağa tanıtabileceği	Hub üzerinde `hub *;`
leaf <mask>	Bu sunucunun kendi altına sunucu bağlayamayacağı	Uç sunucularda `leaf *;`
leaf-depth <n>	İzin verilen dallanma derinliği	Küçük ağlarda 1

Yaygın ve güvenli bir kalıp, uç sunucuların hiçbir sunucuyu tanıtamamasıdır:

CODE TERMINAL

link irc2.example.net {
    incoming { mask 203.0.113.25; }
    password "..." { spkifp; }
    leaf *;
    class servers;
};

Bu tanım, irc2 ele geçirilse bile onun üzerinden ağa yeni bir sunucu sokulmasını engeller. Yalnız hub rolündeki sunucularda `hub *;` kullanılmalıdır.

7. Let's Encrypt ve parmak izi kararlılığı

Let's Encrypt sertifikaları kısa ömürlüdür ve sık yenilenir. Sertifika her yenilendiğinde sertifika parmak izi (certfp) değişir; ancak yenileme sırasında aynı özel anahtar korunursa SPKI parmak izi sabit kalır.

Bu, spkifp'yi certfp'ye tercih etmenin en pratik nedenidir. Yenileme sırasında anahtarın korunması için:

CODE TERMINAL

certbot renew --reuse-key --deploy-hook "/usr/local/bin/unreal-cert-deploy.sh"

Dağıtım betiği, sertifikayı IRCd'nin beklediği konuma kopyalayıp yapılandırmayı yeniden yüklemelidir:

CODE TERMINAL

#!/bin/sh
set -e
DOM=irc1.example.net
DEST=/home/ircd/unrealircd/conf/tls
install -m 0640 -o ircd -g ircd \
    /etc/letsencrypt/live/$DOM/fullchain.pem $DEST/server.cert.pem
install -m 0600 -o ircd -g ircd \
    /etc/letsencrypt/live/$DOM/privkey.pem  $DEST/server.key.pem
su - ircd -c "/home/ircd/unrealircd/unrealircd reloadtls"

reloadtls, sertifikayı mevcut bağlantıları koparmadan yeniden yükler; tam REHASH veya yeniden başlatma gerekmez.

Yenilemeden sonra parmak izinin gerçekten değişmediğini doğrulayın:

CODE TERMINAL

./unrealircd spkifp

Değer değiştiyse karşı sunucudaki link bloğu da güncellenmelidir; aksi halde bir sonraki bağlantı denemesi reddedilir. `--reuse-key` kullanıldığı sürece bu durum beklenmez.

8. TLS seçenekleri

Link bloğu içinde taşıma katmanı ayarları ayrıca sıkılaştırılabilir:

CODE TERMINAL

link irc1.example.net {
    outgoing {
        hostname irc1.example.net;
        port 6900;
        options { tls; autoconnect; }
        tls-options {
            protocols "TLSv1.2,TLSv1.3";
            ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384";
        }
    }
    password "..." { spkifp; }
    class servers;
};

TLS 1.0 ve 1.1 kesinlikle kapatılmalıdır.
`options { insecure; }` otomatik TLS yükseltmesini devre dışı bırakır; kullanılmamalıdır.
Eski `verify-certificate` ayarı kullanımdan kaldırılmıştır; yerine spkifp kullanın.
Sertifika dosyalarının izinleri 0600 olmalı ve yalnız IRCd kullanıcısına ait olmalıdır.
Özel anahtar hiçbir zaman yapılandırma yedeğiyle birlikte paylaşılmamalıdır.

9. Devreye alma ve doğrulama

Her iki sunucuda 6900 portunu serversonly ve tls seçenekleriyle tanımlayın.
Güvenlik duvarında bu porta erişimi karşı IP ile sınırlayın.
Her iki sunucuda `servers` sınıfını oluşturun.
Her iki sunucuda `./unrealircd spkifp` çalıştırın ve çıktıları güvenli bir kanalla paylaşın.
Link bloklarını karşılıklı olarak, karşı tarafın parmak iziyle yazın.
Yapılandırmayı `./unrealircd configtest` ile sözdizimi açısından doğrulayın.
Oper olarak `/REHASH` çalıştırın.
Bağlantıyı `/CONNECT irc1.example.net` ile tetikleyin.
`/MAP` ve `/LINKS` çıktısıyla topolojinin beklenen şekle geldiğini doğrulayın.
Sunucu günlüklerinde link olayını ve TLS sürümünü kontrol edin.

Link kurulduktan sonra günlükte sunucu adı, IP ve doğrulama yönteminin göründüğünü teyit edin. Doğrulama yönteminin beklenenden farklı olması (örneğin parola ile geçilmiş olması), spkifp ekinin unutulduğunu gösterir.

10. Sık karşılaşılan hatalar

Belirti	Olası neden
No matching link block	Sunucu adı, mask veya parmak izi eşleşmiyor
Kendi parmak izini yazmak	Link bloğuna karşı tarafın değeri yazılmalı
Max SendQ exceeded	servers sınıfında sendq çok düşük
Sürekli kopup bağlanma	İki tarafta da autoconnect açık
Bağlantı kabul edilmiyor	Güvenlik duvarı 6900'ü kapatıyor
Kullanıcılar link portuna düşüyor	Listen bloğunda serversonly eksik
Yenileme sonrası link kopuyor	Sertifika --reuse-key olmadan yenilenmiş
Şifresiz link	options içinde tls yazılmamış

11. Link sonrası güven yönetimi

Link kurulması, karşı sunucunun sonsuza kadar güvenilir olduğu anlamına gelmez. Ağı ortak işleten taraflar arasında minimum birkaç kural yazılı hale getirilmelidir:

Her sunucunun oper listesi ve yetkileri karşılıklı bilinmelidir.
Yeni sunucu ekleme süreci tek kişinin kararına bırakılmamalıdır.
`options { quarantine; }` gerektiğinde bir linkten gelen operlerin yetkisini engeller.
Sunucu günlükleri merkezî olarak toplanmalı ve karşılıklı erişilebilir olmalıdır.
Parmak izi değişikliği yalnız doğrulanmış bir kanaldan bildirilmelidir.
Ağdan çıkarılan bir sunucunun link bloğu iki taraftan da silinmelidir.

Son madde özellikle önemlidir: kullanılmayan ama silinmeyen link blokları, zamanla kimsenin kontrol etmediği bir kabul yüzeyine dönüşür.

Sonuç

Güvenli bir UnrealIRCd 6 linki; ayrı bir serversonly TLS portu, karşı tarafın SPKI parmak izine bağlı doğrulama, IP maskesiyle sınırlanmış incoming bloğu, sunuculara özel bir sınıf ve hub/leaf topoloji kısıtlarının birlikte kullanılmasıyla elde edilir. Let's Encrypt ile çalışırken `--reuse-key` ve `reloadtls` ikilisi, sertifika yenilemesinin linki bozmasını engeller. Parolaya değil anahtara dayanan bir link, ağın en kritik güven sınırını kriptografik bir temele oturtur.

Resmî kaynaklar

TR Siber Ekibi Yazar · X

Kaynak bağlantısı ← Ana sayfaya dön