IP Bloğunun Sahibi Değişti mi? Origin ASN Takibi ve Dışarıdan Doğru Ölçüm

Origin ASN takibi, bir IP prefiksini BGP’de hangi otonom sistemin duyurduğunu zaman içinde ölçüp değişimi yakalama işidir. RIPEstat’ın ücretsiz API’si bunu tek curl ile verir: 109.160.32.0/24 bloğu 30 Eylül 2026’da AS197170’ten AS198364’e geçti ve ASN numarasına göre yazılmış engelleme kuralları bloğu o andan sonra tutmaz. Yaklaşık otuz satırlık bir betik bu değişimi günde bir kez yakalar.

Bu hafta aynı konunun iki yüzüyle uğraştım. Birincisi honeypot verisinde: SSH sözlüğüne ajan adlarını ekleyen blok bayrak değiştirdi ve ASN’e göre sayan her pano onu iki ayrı aktör gibi gösterdi (Tellal bülteni). İkincisi ölçümün kendisinde: bir sunucuyu yanlış ağdan, bir posta servisini ise düğümlerinin bir kısmı zaten SMTP’ye kapalı bir araçtan ölçerken ilk sonuçlarım yanlış çıktı. İkisinin dersi aynı: bir etiket ya da tek bir ölçüm noktası, gerçeğin yerini tutmaz. Üç ölçümü ve üç betiği sırayla veriyorum.

Origin ASN, engelleme kararında neden önemli?

Çünkü engelleme listeleri iki biçimde yazılır ve ikisi de eskir. ASN numarasına göre üretilen liste, bir prefiks başka bir ASN’e geçtiğinde o prefiksi kaybeder; prefikse göre yazılan liste prefiksi tutmaya devam eder ama sahibin değiştiğini bilmez. 109.160.32.0/24 birinci duruma örnek.

Blok 1-30 Eylül arasında AS197170 (TechTies) adına duyuruldu, 30 Eylül 16:00 UTC’den beri AS198364 (Banatsync) adına. Honeypot veritabanımızda bloktaki 115 adres bugün iki etikete bölünmüş durumda ve aynı filo iki ayrı aktör gibi görünüyor. “AS197170’in duyurduğu prefiksler” listesini 30 Eylül’den sonra yenileyen biri bu bloğu listeden düşürdü; filo ise o blokta çalışmaya devam etti.

Bir ayrıntı daha: blok yeni bir yol açmadı. RIPEstat’ın 12 Ekim’de gözlediği 371 BGP yolunun hepsinde blok AS198364’ten çıkıyor ve yolun bir önceki halkası AS197170. Yani bloğa giden yol hâlâ eski sağlayıcıdan geçiyor. Bu tek başına kötü niyet kanıtı değil, bir kiralama ya da devir sonucu olabilir. Engelleme açısından anlamı şu: kararı hiçbir tek etikete bağlamayın.

RIPEstat ile bir prefiksin origin geçmişi nasıl sorgulanır?

routing-history ucu, prefiksin hangi ASN tarafından hangi tarih aralığında duyurulduğunu döndürür. Tek curl ve jq yeterli, API anahtarı gerekmez.

curl -s "https://stat.ripe.net/data/routing-history/data.json?resource=109.160.32.0/24&starttime=2026-09-01&sourceapp=origin-watch" \
  | jq -r '.data.by_origin[] | .origin as $o | .prefixes[]
           | "AS\($o)  \(.prefix)  \(.timelines[0].starttime[:16]) -> \(.timelines[-1].endtime[:16])"'

12 Ekim 2026’da aldığım çıktı:

AS197170  109.160.32.0/24  2026-09-01T16:00 -> 2026-09-30T15:59
AS198364  109.160.32.0/24  2026-09-30T16:00 -> 2026-10-12T08:00

Son satırdaki bitiş zamanı bir çekilme değil, RIPEstat’ın işlediği en son BGP dökümünün zamanıdır. Şu andaki origin için prefix-overview daha kısa:

curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=109.160.32.0/24&sourceapp=origin-watch" \
  | jq -c '{announced: .data.announced, origin: [.data.asns[] | "AS\(.asn) \(.holder)"]}'
# {"announced":true,"origin":["AS198364 BANATSYNC-SRL BANATSYNC SRL"]}

Yolun bir önceki halkasını bgp-state verir. Aynı ASN’in art arda tekrarlandığı prepend satırlarını ayıklamak gerekir:

curl -s "https://stat.ripe.net/data/bgp-state/data.json?resource=109.160.32.0/24&sourceapp=origin-watch" \
  | jq -r '.data.bgp_state[].path | map(tostring)
           | reduce .[] as $a ([]; if .[-1] == $a then . else . + [$a] end)
           | .[-2:] | join(" -> ")' \
  | sort | uniq -c
#     371 197170 -> 198364

Tek bir IP’nin ASN’i için Team Cymru’nun DNS arayüzü yeterli. IP’nin oktetleri ters yazılır:

dig +short TXT 10.32.160.109.origin.asn.cymru.com
# "198364 | 109.160.32.0/24 | BG | ripencc | 2009-08-27"

Engelleme listesindeki tüm bloklar için günlük kontrol nasıl kurulur?

Her prefiksin güncel origin’ini prefix-overview ile okuyup bir önceki çalıştırmanın kaydıyla karşılaştıran bir betik ve bir cron satırı yeterli. Betik değişiklik bulursa 2 koduyla çıkar, böylece cron e-postası ya da izleme sistemi yakalar.

#!/usr/bin/env bash
# origin-watch.sh: engelleme listesindeki her prefiksin BGP origin ASN'ini RIPEstat'tan
# okur, önceki çalıştırmayla karşılaştırır, değişeni yazar. Değişiklik varsa çıkış kodu 2.
# Kullanım: ./origin-watch.sh prefixes.txt origin-state.tsv
set -euo pipefail

LISTE="${1:-prefixes.txt}"       # her satırda bir prefiks: 109.160.32.0/24
DURUM="${2:-origin-state.tsv}"   # prefiks<TAB>origin (bir önceki ölçüm)
API="https://stat.ripe.net/data/prefix-overview/data.json"

touch "$DURUM"
YENI="$(mktemp)"
trap 'rm -f "$YENI"' EXIT
degisti=0

while read -r prefiks; do
  [[ -z "$prefiks" || "$prefiks" == \#* ]] && continue
  origin="$(curl -sf -m 20 "$API?resource=$prefiks&sourceapp=origin-watch" \
    | jq -r 'if .data.announced then ([.data.asns[].asn] | sort | map("AS\(.)") | join(",")) else "DUYURULMUYOR" end')" \
    || { echo "HATA    $prefiks sorgulanamadı, durum dosyası değişmedi" >&2; exit 1; }
  onceki="$(awk -F'\t' -v p="$prefiks" '$1 == p {print $2}' "$DURUM")"
  printf '%s\t%s\n' "$prefiks" "$origin" >> "$YENI"
  if [[ -z "$onceki" ]]; then
    echo "İLK     $prefiks  $origin"
  elif [[ "$onceki" != "$origin" ]]; then
    echo "DEĞİŞTİ $prefiks  $onceki -> $origin"
    degisti=1
  fi
  sleep 1   # RIPEstat'a nazik davran
done < "$LISTE"

mv "$YENI" "$DURUM"
trap - EXIT
[[ $degisti -eq 0 ]] || exit 2

Dört prefiklik bir listeyle ilk çalıştırmada her satır İLK olarak kaydedilir. Değişimin nasıl göründüğünü denemek için durum dosyasında 109.160.32.0/24 satırını elle AS197170 yaptım ve yeniden çalıştırdım; yani 30 Eylül öncesinin kaydını simüle ettim:

$ ./origin-watch.sh prefixes.txt origin-state.tsv
İLK     109.160.32.0/24  AS198364
İLK     77.239.124.0/24  AS198364
İLK     45.153.34.0/24  AS197170
İLK     203.0.113.0/24  DUYURULMUYOR

$ ./origin-watch.sh prefixes.txt origin-state.tsv; echo "çıkış=$?"
DEĞİŞTİ 109.160.32.0/24  AS197170 -> AS198364
çıkış=2

Cron satırı:

17 6 * * * /usr/local/bin/origin-watch.sh /etc/engelleme/prefixes.txt /var/lib/origin-watch/durum.tsv || echo "origin-watch: değişiklik ya da hata" | mail -s "origin-watch" [email protected]

Betikte üç tasarım kararı var. Durum dosyası yalnız listenin tamamı okunduktan sonra güncellenir; yarıda kalan bir çalıştırma dünün kaydını bozmaz. DUYURULMUYOR da bir değerdir: prefiks yayından kalkarsa bu da değişiklik olarak görünür. Son olarak RIPEstat’ın kurallarına uyuyor: istek sayısı için resmi bir sınır yok, tek IP’den aynı anda sekiz isteğe izin veriliyor ve düzenli kullanımda sourceapp ile kimlik bildirmeniz isteniyor. Betik prefiksleri art arda ve aralarında bir saniye bekleyerek sorar.

Origin değişince engelleme kuralı ne olmalı?

Kural prefikse yazılmalı, kayıt bir son kullanma süresi taşımalı ve origin değişimi otomatik genişletme değil yeniden inceleme tetiklemeli. Gerekçe: ASN değişimi her zaman kötü niyet göstergesi değildir (kiralama, devir, sağlayıcı değişimi aynı sonucu verir), ama sahibi değişen bir blok için eski engelleme gerekçesi artık geçerli olmayabilir.

MikroTik’te (RouterOS 7) süreli adres listesi ve raw tablosunda ucuz bir drop kuralı bu işi görür:

/ip firewall address-list
add list=blk-ssh address=109.160.32.0/24 timeout=30d comment="ajan sözlüğü filosu 2026-10-12"

/ip firewall raw
add chain=prerouting action=drop protocol=tcp dst-port=22 src-address-list=blk-ssh comment="blk-ssh"

timeout=30d kaydı 30 gün sonra listeden düşürür; blok hâlâ saldırıyorsa kaydı yenilersiniz, susmuşsa kendiliğinden temizlenir. raw tablosu bağlantı izlemesinden önce çalıştığı için drop kuralı işlemciyi yormaz. Kural yalnız 22. porta iniyor; blok başka bir portu taramıyorsa gereğinden fazlasını kapatmayın. Brute force koruması için tam kural seti MikroTik Firewall: Brute Force Koruması yazısında. Sunucu tarafında parola girişini kapatmak ise SSH sertleştirme yazısındaki ilk adımdır.

Eşiği adres değil /24 bazında kurmak da fark yaratıyor. Banatsync bloğunda adres başına yaklaşık 500 deneme düşüyor ve bu 31 adrese yayılıyor; adres bazlı bir eşik filoyu görmez, /24 bazlı eşik ilk saatte yakalar.

Bir hizmet dışarıdan gerçekten kapalı mı, nasıl doğru ölçülür?

Hedefi birkaç ülkedeki düğümden ölçün ve aynı düğümlerden bir kontrol hedefini de ölçün: kontrol açıkken hedef kapalıysa sorun hedeftedir. check-host.net bunu anahtarsız bir API ile verir; betik bu mantığı otomatikleştirir.

12 Ekim sabahı Yandex 360 kullanan bir kurumun Outlook’u 0x80042109 hatasıyla giden postayı gönderemedi, web mail çalışıyordu. smtp.yandex.com, check-host’un çok sayıda ülkedeki düğümünden 25, 465 ve 587 portlarında Connection refused verdi; IMAP 993 her yerden açıktı. Yandex 360 durum sayfasında posta bileşeni “olay yok” gösteriyordu; genel kayıtta ise yükü azaltmak için bazı işlevlerin bilerek kısıldığı yazıyordu. 14:11 UTC’de aynı ölçümde SMTP portları açıldı.

Ölçümün tuzağı şu: seçilen düğümlerin bir kısmı kendi SMTP çıkışını kapatmıştır. Hedef o düğümden kapalı görünür, ama o düğüm Gmail’in SMTP’sini de açamaz. Kontrol hedefi bu yüzden zorunlu.

#!/usr/bin/env bash
# dis-olcum.sh: bir TCP portunu check-host.net'in dış düğümlerinden ölçer ve AYNI düğümlerden
# bir kontrol hedefini de ölçer. Kontrol açıkken hedef kapalıysa sorun hedeftedir.
# Kullanım: ./dis-olcum.sh smtp.yandex.com 587 [kontrol_host kontrol_port]
set -euo pipefail

HEDEF="$1"; PORT="$2"
KONTROL="${3:-smtp.gmail.com}"; KPORT="${4:-$PORT}"
API="https://check-host.net"

istek() { curl -sf -m 20 -H 'Accept: application/json' "$@"; }
hazir() { jq -e 'all(.[]; . != null)' >/dev/null; }

# 1) hedefi ölç, seçilen düğümleri al
YANIT="$(istek "$API/check-tcp?host=$HEDEF:$PORT&max_nodes=10")"
ID_HEDEF="$(jq -r .request_id <<<"$YANIT")"
DUGUMLER="$(jq -r '.nodes | keys[] | "&node=" + .' <<<"$YANIT" | tr -d '\n')"

# 2) kontrol hedefini AYNI düğümlerden ölç
ID_KONTROL="$(istek "$API/check-tcp?host=$KONTROL:$KPORT$DUGUMLER" | jq -r .request_id)"

# 3) sonuçlar hazır olana kadar bekle (en çok ~40 sn)
for _ in $(seq 1 10); do
  sleep 4
  H="$(istek "$API/check-result/$ID_HEDEF")"; K="$(istek "$API/check-result/$ID_KONTROL")"
  hazir <<<"$H" && hazir <<<"$K" && break
done

# 4) düğüm başına bir satır: düğüm, hedef sonucu, kontrol sonucu
SATIRLAR="$(jq -rn --argjson h "$H" --argjson k "$K" '
  def durum: if . == null then "bekliyor" elif .[0].error then .[0].error else "açık" end;
  $h | to_entries[]
  | [(.key | sub("\\.node\\.check-host\\.net"; "")), (.value | durum), ($k[.key] | durum)]
  | @tsv')"

{ printf 'düğüm\t%s\tkontrol\n' "$HEDEF:$PORT"; printf '%s\n' "$SATIRLAR"; } | column -t -s $'\t'
echo
awk -F'\t' '
  $3 == "açık"                { kontrol_acik++ }
  $3 == "açık" && $2 != "açık" { hedef_kapali++ }
  $3 != "açık"                { atla++ }
  END { printf "kontrol açıkken hedef kapalı: %d / %d düğüm\n", hedef_kapali, kontrol_acik
        printf "kontrolün kendisi kapalı (düğümün kısıtı, sayma): %d düğüm\n", atla }' <<<"$SATIRLAR"

SMTP açıkken 12 Ekim akşamı aldığım çıktı. nl1 düğümü hem hedefte hem kontrolde reddediyor: bu düğüm hiçbir SMTP sunucusuna ulaşamıyor, Yandex’in suçu değil.

$ ./dis-olcum.sh smtp.yandex.com 587
düğüm   smtp.yandex.com:587  kontrol
de1  açık                   açık
de2  açık                   açık
es1  açık                   açık
hu1  açık                   açık
id1  açık                   açık
ir3  açık                   açık
ir7  açık                   açık
nl1  Connection refused     Connection refused
ru1  açık                   açık
vn1  açık                   açık

kontrol açıkken hedef kapalı: 0 / 9 düğüm
kontrolün kendisi kapalı (düğümün kısıtı, sayma): 1 düğüm

Gerçekten kapalı bir hedef şöyle görünür (smtp.yandex.com üzerinde dinlenmeyen 9999 portu):

$ ./dis-olcum.sh smtp.yandex.com 9999 smtp.gmail.com 587 | tail -3
ro1  Connection timed out  Connection timed out

kontrol açıkken hedef kapalı: 9 / 9 düğüm
kontrolün kendisi kapalı (düğümün kısıtı, sayma): 1 düğüm

Karar kuralı tek satır: sorunu hedefe yazmak için “kontrol açıkken hedef kapalı” sayısı toplam açık-kontrollü düğüm sayısına yaklaşmalı. Bu sayı sıfırsa sorun sizin tarafınızda ya da ölçüm aracındadır.

Ölçtüğüm ağ, ölçmek istediğim ağ mı?

Ölçüm noktasının hedefe giden yolu sandığınız yol olmayabilir; bunu SSH host anahtarının parmak iziyle doğrularsınız. Parmak izi eşleşiyorsa doğru makineyle konuşuyorsunuz, eşleşmiyorsa ya da cevap yoksa ölçümünüzün sonucuna güvenmeyin.

Bu hafta ilk ölçümüm yanlış ağı gösterdi. İki ayrı lokasyondaki ağlarımız aynı özel adres aralığını kullanıyor. Bir lokasyondan diğerindeki sunucuya ping attığımı sandım, ama paket kendi tarafımdaki aynı numaralı komşuya gitti, cevap gelmedi ve “sunucu kapalı” sonucuna vardım. Sunucu dışarıdan, genel adresinden hiçbir sorun olmadan cevap veriyordu. Önce ölçümün kendisini sınamam gerekirdi.

Kontrol tek komut: sunucunun host anahtarının parmak izini bir kez kaydedin, sonra her ölçümde karşılaştırın.

#!/usr/bin/env bash
# dogru-makine-mi.sh: bağlandığım uç, beklediğim makine mi? SSH host anahtarının
# parmak izini, daha önce kaydettiğim parmak iziyle karşılaştırır.
# Kullanım: ./dogru-makine-mi.sh sunucu.ornek.com SHA256:beklenen_parmak_izi
set -euo pipefail

HOST="$1"; BEKLENEN="$2"
ANAHTAR="$(ssh-keyscan -t ed25519 -T 5 "$HOST" 2>/dev/null || true)"

if [[ -z "$ANAHTAR" ]]; then
  echo "CEVAP YOK  $HOST: SSH anahtarı alınamadı (port kapalı ya da yanlış ağ)"; exit 2
fi

GELEN="$(ssh-keygen -lf - <<<"$ANAHTAR" | awk '{print $2}')"
if [[ "$GELEN" == "$BEKLENEN" ]]; then
  echo "DOĞRU      $HOST: parmak izi eşleşti ($GELEN)"
else
  echo "YANLIŞ     $HOST: beklenen $BEKLENEN, gelen $GELEN"; exit 1
fi

Herkese açık bir sunucuyla denediğimde üç sonuç da beklendiği gibi çıktı (github.com’un yayımlanmış ed25519 parmak iziyle):

$ ./dogru-makine-mi.sh github.com SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU
DOĞRU      github.com: parmak izi eşleşti (SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU)

$ ./dogru-makine-mi.sh github.com SHA256:yanlisParmakIzi
YANLIŞ     github.com: beklenen SHA256:yanlisParmakIzi, gelen SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU

$ ./dogru-makine-mi.sh 203.0.113.7 SHA256:x
CEVAP YOK  203.0.113.7: SSH anahtarı alınamadı (port kapalı ya da yanlış ağ)

SSH olmayan hizmetlerde aynı mantık TLS sertifikasının parmak iziyle çalışır:

echo | openssl s_client -connect github.com:443 -servername github.com 2>/dev/null \
  | openssl x509 -noout -fingerprint -sha256

Parmak izi, ölçümün doğru uca gittiğini söyler; hizmetin sağlıklı olup olmadığını söylemez. İkisi ayrı sorudur ve ayrı ölçülür. Port açıklığını dışarıdan ölçmenin başka bir örneği MySQL portunu kapattığınızı sanıyorsunuz yazısında.

Sağlayıcı kesintisinde durum sayfası mı, kendi ölçümüm mü esas?

Kendi ölçümünüz esas, durum sayfası ikinci kaynak. Yandex’in Sasovo, Kaluga ve Vladimir veri merkezleri 8-11 Ekim 2026’da İHA saldırılarıyla durdu veya hasar gördü; Yandex altyapıyı “acil durum modunda” tanımladı ve 11 Ekim’de açılan durum kaydında yükü azaltmak için bazı işlevlerin bilerek kısıldığını yazdı. Posta bileşeni ise aynı sayfada “olay yok” gösteriyordu (Al Jazeera, AIF, Yandex 360 durum sayfası). SMTP’nin kısılan işlevlerden biri olup olmadığını Yandex doğrulamadı; elimizdeki tek kanıt dışarıdan yapılan ölçüm.

Veri merkezi sürekliliğinin kurumsal tarafı, yani posta, bulut ve veri kopyalarının hangi arıza alanına yerleştirileceği SiberKale’deki yazıda ele alındı.

Bu üç ölçümün ortak kuralı nedir?

Etiketi ve ölçüm noktasını ayrı ayrı sınayın. Bir IP bloğunun ASN etiketi bir tarihte doğrudur ve ertesi gün değişebilir: origin’i günlük ölçün. Bir dış ölçümün “kapalı” sonucu o düğümün kısıtı olabilir: kontrol hedefiyle eşleyin. Bir iç ölçümün “cevap yok” sonucu yanlış ağa gitmiş olabilir: host anahtarının parmak iziyle doğrulayın. Üçünün de maliyeti birkaç satır betik; üçünü de atlamanın bedeli yanlış bir engelleme kararı, yanlış bir “sunucu çöktü” alarmı ya da yanlış bir sağlayıcı suçlaması.