Selamlar, bu yazımda Android TV’den Splunk’a: Akıllı Televizyon Loglarının Merkezi Analizini ele aldım. Şimdiden keyifli okumalar. 🙂

1. Giriş

Günümüzde akıllı televizyonlar yalnızca yayın izlemek amacıyla kullanılan cihazlar olmaktan çıkarak işletim sistemine, uygulamalara, ağ bağlantılarına ve çeşitli arka plan servislerine sahip IoT cihazlarına dönüşmüştür.

Android TV işletim sistemine sahip televizyonlar; uygulama çalıştırma, internet erişimi, sistem servisleri ve donanım bileşenlerinin yönetimi gibi birçok işlemi gerçekleştirmektedir. Bu işlemler sırasında işletim sistemi üzerinde çeşitli log kayıtları üretilmektedir.

Peki, evimizde kullandığımız bir Android TV’nin sistem loglarını merkezi bir SIEM platformuna aktarabilir miyiz?

Bu sorudan yola çıkarak evimde bulunan ONVO Android TV cihazının sistem loglarını Splunk Enterprise ortamına aktarmaya yönelik bir laboratuvar çalışması gerçekleştirdim.

Çalışmanın temel amacı, Android TV üzerinde oluşan sistem ve uygulama kayıtlarını herhangi bir Splunk Universal Forwarder kurulumu gerçekleştirmeden toplamak, Splunk üzerinde anlamlandırmak ve izlenebilir hale getirmekti.

Bu kapsamda Android Debug Bridge (ADB), Windows PowerShell ve Splunk HTTP Event Collector (HEC) bileşenlerini kullanarak uçtan uca bir log toplama mimarisi oluşturdum.

Çalışma boyunca karşılaştığım bağlantı, JSON formatı, SSL/TLS sertifika güveni ve log parsing problemlerini de ele aldım.

---

2. Laboratuvar Ortamı ve Mimari

Çalışmayı mevcut Splunk Enterprise laboratuvar ortamım üzerinde gerçekleştirdim.

Kullandığım Splunk kurulumu standalone mimariye sahipti. Android TV ise ev ağımda bulunuyordu. Splunk sunucusuna VPN üzerinden erişim sağladığım için doğrudan televizyon ile Splunk sunucusu arasında bağlantı kurmak yerine Windows bilgisayarımı aracı log toplama bileşeni olarak konumlandırdım.

2.1. Kullanılan bileşenler

Bileşen	Açıklama
Log Kaynağı	ONVO Android TV
İşletim Sistemi	Android TV OS
Log Toplama	Android Debug Bridge (ADB)
Collector	Windows PowerShell
Merkezi Log Platformu	Splunk Enterprise
Veri Aktarım Yöntemi	HTTP Event Collector
İletişim Protokolü	HTTPS / TCP 8088
Splunk Index	android_tv
Sourcetype	android
Ağ Bağlantısı	Yerel Wi-Fi

2.2. Log toplama mimarisi

Oluşturduğum mimaride Android TV üzerinde çalışan log servislerine ADB aracılığıyla eriştim.

Windows bilgisayarım televizyonla aynı yerel ağ üzerinde bulunduğu için ADB bağlantısını doğrudan Windows üzerinden gerçekleştirdim.

Toplanan logları PowerShell aracılığıyla işleyerek HTTPS üzerinden Splunk HEC servisine ilettim.

Veri akışı aşağıdaki şekilde gerçekleşmektedir:

              ONVO Android TV
              Android Logcat
                    |
                    |
              ADB / Wi-Fi
                    |
                    v
             Windows Collector
              PowerShell Script
                    |
                    |
                 VPN
                    |
                    v
             Splunk Enterprise
               HEC / 8088
                    |
                    v
              index=android_tv
                    |
                    v
           Parsing & Dashboard

Bu mimarinin avantajı, televizyon üzerine herhangi bir Splunk ajanı kurulumuna ihtiyaç duyulmamasıdır.

Ayrıca ADB erişimi yerel ağ içerisinde tutulurken Splunk’a veri aktarımı VPN üzerinden gerçekleştirilmektedir.

---

3. Android TV Üzerinde Geliştirici Modunun Etkinleştirilmesi

Android TV üzerinde sistem loglarına erişim sağlayabilmek için ilk olarak geliştirici seçeneklerini etkinleştirdim.

Televizyonda aşağıdaki menüyü takip ettim:

Ayarlar → Cihaz Tercihleri → Hakkında

Bu bölümde yer alan Android TV işletim sistemi derleme bilgisine art arda yedi kez basarak geliştirici modunu aktif hale getirdim.

Ardından:

Ayarlar → Cihaz Tercihleri → Geliştirici Seçenekleri

menüsüne girerek USB hata ayıklama özelliğini etkinleştirdim.

3.1. Kablosuz hata ayıklama

İlk aşamada televizyon Ethernet kablosuyla ağa bağlıydı. Kablosuz hata ayıklama özelliğini etkinleştirmeye çalıştığımda bu işlem gerçekleşmedi.

Televizyonu Wi-Fi ağına bağladıktan sonra kablosuz hata ayıklama özelliğini başarılı şekilde etkinleştirdim.

Bu aşamada Android TV tarafından ADB bağlantısı için bir IP adresi ve dinamik TCP portu oluşturuldu.

Laboratuvar çalışmamda kullanılan bağlantı bilgileri:

Android TV IP : 192.168.1.181
ADB Port      : 33307/TCP

Kablosuz hata ayıklama özelliğinde kullanılan portlar dinamik olduğundan cihaz yeniden başlatıldığında veya özellik yeniden etkinleştirildiğinde değişebilmektedir.

---

4. Windows Üzerinde ADB Kurulumu

Android TV loglarını toplamak için Google tarafından sunulan Android SDK Platform Tools paketini kullandım.

Kurulum paketini aşağıdaki resmi bağlantıdan indirdim:

https://developer.android.com/tools/releases/platform-tools

İndirdiğim paketi Windows üzerinde aşağıdaki dizine çıkardım:

C:\platform-tools

Ardından PowerShell üzerinden ADB sürümünü kontrol ettim.

cd C:\platform-tools

.\adb.exe version

Komut sonucunda Android Debug Bridge sürüm bilgisi görüntülendi ve kurulumun başarılı olduğu doğrulandı.

---

5. Android TV ile ADB Eşleştirmesi

ADB kurulumunu tamamladıktan sonra Android TV ile Windows bilgisayarım arasında güvenilir bağlantı oluşturmak için kablosuz eşleştirme işlemini gerçekleştirdim.

Televizyon üzerinde:

Geliştirici Seçenekleri → Kablosuz Hata Ayıklama → Eşleştirme Koduyla Cihaz Eşleştir

bölümüne girdim.

Bu ekranda Android TV tarafından eşleştirme kodu ve ayrı bir TCP portu oluşturuldu.

Windows PowerShell üzerinde aşağıdaki komutu kullandım:

.\adb.exe pair 192.168.1.181:ESLESTIRME_PORTU

Komut sonrasında televizyon ekranında görüntülenen eşleştirme kodunu girerek cihazı eşleştirdim.

Başarılı eşleştirme sonrasında aşağıdaki mesajı aldım:

Successfully paired to 192.168.1.181:PORT

5.1. ADB bağlantısının kurulması

Eşleştirme tamamlandıktan sonra televizyonun ADB bağlantı portunu kullanarak bağlantı gerçekleştirdim.

.\adb.exe connect 192.168.1.181:33307

Bağlantıyı doğrulamak için:

.\adb.exe devices -l

komutunu çalıştırdım.

Komut çıktısında ONVO Android TV’nin device durumunda listelendiğini gördüm.

5.2. Birden fazla ADB bağlantısı problemi

Test sırasında adb logcat komutunu çalıştırdığımda aşağıdaki hata ile karşılaştım:

error: more than one device/emulator

Bu durumun nedeni, aynı Android TV cihazının ADB üzerinde iki farklı bağlantı tanımıyla görüntülenmesiydi.

Problemi çözmek için ADB komutuna -s parametresini ekleyerek kullanılacak bağlantıyı açıkça belirttim.

.\adb.exe -s 192.168.1.181:33307 logcat -d -t 50

Bu işlem sonrasında televizyonun gerçek Android sistem loglarına erişim sağladım.

---

6. Android Sistem Loglarının İncelenmesi

ADB üzerinden elde ettiğim loglarda Android işletim sisteminin farklı bileşenlerine ait kayıtların üretildiğini gözlemledim.

Bu kayıtlar arasında uygulama servisleri, donanım yönetimi, ses işlemleri, görüntü işleme ve arka plan servislerine ait mesajlar bulunuyordu.

Örnek log formatı:

10-13 10:55:44.323 561 766 E <MI_PQ> : <ERR>_MI_PQ_CalculateSubwinCrop[6050]: invalid input

Android logcat tarafından üretilen bu format belirli alanlardan oluşmaktadır.

Alan	Açıklama
10-13	Ay ve gün
10:55:44.323	Logun oluşma saati
561	Process ID
766	Thread ID
E	Log seviyesi
MI_PQ	Logu üreten bileşen
invalid input	Log mesajı

Android log seviyeleri genel olarak aşağıdaki şekilde sınıflandırılmaktadır:

• V – Verbose: Ayrıntılı işlem kayıtları
• D – Debug: Hata ayıklama kayıtları
• I – Info: Bilgilendirme kayıtları
• W – Warning: Uyarı kayıtları
• E – Error: Hata kayıtları
• F – Fatal: Kritik hata kayıtları

Bu aşamada Android TV’nin farklı sistem bileşenlerinden log ürettiğini doğruladım.

---

7. Android Loglarının Windows Üzerinde Toplanması

ADB bağlantısını doğruladıktan sonra logları Windows üzerinde bir dosyaya aktarmaya başladım.

PowerShell üzerinde aşağıdaki komutu kullandım:

.\adb.exe -s 192.168.1.181:33307 logcat -v threadtime |
    Out-File -FilePath "C:\platform-tools\android_tv.log" -Encoding utf8

Bu komut, Android TV üzerinden alınan canlı logları android_tv.log dosyasına yazmaktadır.

Dosyanın oluştuğunu kontrol etmek için:

Get-Item C:\platform-tools\android_tv.log |
Select-Object Name, Length, LastWriteTime

komutunu kullandım.

Ardından dosyadaki son kayıtları görüntüledim:

Get-Content C:\platform-tools\android_tv.log -Tail 20

Dosyaya yeni logların yazıldığını doğrulamak için ise:

Get-Content C:\platform-tools\android_tv.log -Wait -Tail 10

komutuyla canlı takip gerçekleştirdim.

---

8. Splunk Üzerinde Index ve HEC Yapılandırması

Android loglarını merkezi olarak tutmak amacıyla Splunk Enterprise üzerinde ayrı bir index oluşturdum.

Settings → Indexes → New Index

bölümünden aşağıdaki index’i tanımladım:

android_tv

Bu sayede Android TV loglarını diğer veri kaynaklarından bağımsız şekilde yönetebilecek bir yapı oluşturdum.

8.1. HTTP Event Collector yapılandırması

Logları Splunk’a göndermek için HTTP Event Collector yöntemini tercih ettim.

Splunk Web üzerinden:

Settings → Data Inputs → HTTP Event Collector

bölümüne girdim.

HEC servisini etkinleştirdikten sonra Android TV için özel bir token oluşturdum.

Kullandığım temel ayarlar:

Token Name : ONVO_Android_TV
Sourcetype : android:logcat
Index      : android_tv
HEC Port   : 8088
SSL        : Enabled

HEC sayesinde Windows üzerinde çalışan collector’ın logları HTTPS üzerinden Splunk’a göndermesini sağladım.

---

9. VPN Üzerinden Splunk HEC Erişiminin Doğrulanması

Splunk laboratuvar sunucum farklı bir ağ üzerinde bulunduğundan Windows bilgisayarımdan VPN aracılığıyla erişim sağladım.

İlk olarak HEC portuna erişimi kontrol ettim.

Test-NetConnection 10.100.201.162 -Port 8088

Komut sonucunda:

TcpTestSucceeded : True

yanıtını aldım.

Ardından HEC servisinin sağlık durumunu kontrol ettim.

curl.exe -vk https://10.100.201.162:8088/services/collector/health

Splunk aşağıdaki yanıtı döndürdü:

{
  "text": "HEC is healthy",
  "code": 17
}

Bu sonuç HEC servisinin çalışır durumda olduğunu gösteriyordu. Ancak verinin indekslendiğini doğrulamak için ayrıca test event’i göndermem gerekiyordu.

---

10. HEC Veri Formatı Problemi ve Çözümü

İlk testler sırasında HEC servisine gönderdiğim bazı event’lerde aşağıdaki hata ile karşılaştım:

{
  "text": "Invalid data format",
  "code": 6,
  "invalid-event-number": 0
}

Bu hata, gönderilen verinin Splunk HEC tarafından geçerli event formatında işlenemediğini gösteriyordu.

Windows PowerShell ve curl.exe ile JSON gönderiminde çift tırnakların korunması ve dosya kodlaması gibi konuları kontrol ettim.

Özellikle Windows PowerShell 5.1 ortamında -Encoding UTF8 ile oluşturulan dosyalarda UTF-8 BOM bulunabilmesi önemliydi.

Bu nedenle JSON verisini UTF-8 BOM olmadan dosyaya yazdırdım.

$body = @{
    event      = "ONVO Android TV HEC TEST"
    host       = "ONVO-TV"
    source     = "adb:logcat"
    sourcetype = "android:logcat"
    index      = "android_tv"
} | ConvertTo-Json -Compress

[System.IO.File]::WriteAllText(
    "C:\platform-tools\hec_test.json",
    $body,
    (New-Object System.Text.UTF8Encoding($false))
)

Ardından dosyayı --data-binary parametresiyle gönderdim.

curl.exe -ksS `
-H "Authorization: Splunk $token" `
-H "Content-Type: application/json" `
--data-binary "@C:\platform-tools\hec_test.json" `
"https://10.100.201.162:8088/services/collector/event"

Bu düzenleme sonrasında HEC üzerinden başarılı veri gönderimi gerçekleştirdim.

{
  "text": "Success",
  "code": 0
}

Burada -k parametresini yalnızca ilk bağlantı testlerinde kullandım. Sonraki aşamada TLS sertifika güvenini ayrıca yapılandırdım.

---

11. Splunk HEC SSL/TLS Sertifika Probleminin Çözülmesi

Çalışma sırasında karşılaştığım önemli problemlerden biri SSL/TLS sertifika doğrulamasıydı.

Windows PowerShell üzerinden HEC servisine bağlantı kurmaya çalıştığımda aşağıdaki hatayı aldım:

Could not establish trust relationship
for the SSL/TLS secure channel.

Problemi incelemek için Splunk sunucusunda OpenSSL üzerinden sertifika bilgilerini kontrol ettim.

openssl s_client \
-connect 127.0.0.1:8088 \
-showcerts </dev/null

Çıktıda Splunk’ın varsayılan sertifikasının kullanıldığını gördüm:

subject=CN = SplunkServerDefaultCert
issuer=CN = SplunkCommonCA

Verify return code: 19
(self-signed certificate in certificate chain)

Bu nedenle Windows’un mevcut sertifika zincirine güvenmediğini tespit ettim.

11.1. HEC için özel CA oluşturulması

Mevcut Splunk sunucu sertifikasını değiştirmeden yalnızca HEC servisinde kullanılmak üzere özel bir sertifika oluşturmaya karar verdim.

İlk olarak sertifika dizinini oluşturdum:

mkdir -p /opt/splunk/etc/auth/hec
cd /opt/splunk/etc/auth/hec

Ardından laboratuvar ortamına özel CA sertifikasını oluşturdum.

openssl req -x509 -newkey rsa:3072 \
-sha256 -days 365 -nodes \
-keyout lab-ca.key \
-out lab-ca.crt \
-subj "/CN=Splunk-Lab-HEC-CA" \
-addext "basicConstraints=critical,CA:TRUE" \
-addext "keyUsage=critical,keyCertSign,cRLSign"

11.2. HEC sunucu sertifikasının oluşturulması

HEC sunucusunun IP adresini Subject Alternative Name (SAN) alanına ekleyerek ayrı bir sunucu sertifikası hazırladım.

openssl req -new -newkey rsa:3072 -nodes \
-keyout hec-server.key \
-out hec-server.csr \
-subj "/CN=10.100.201.162"

SAN yapılandırması:

subjectAltName=IP:10.100.201.162
basicConstraints=critical,CA:FALSE
keyUsage=critical,digitalSignature,keyEncipherment
extendedKeyUsage=serverAuth

Sertifikayı oluşturduğum CA ile imzaladım.

openssl x509 -req \
-in hec-server.csr \
-CA lab-ca.crt \
-CAkey lab-ca.key \
-CAcreateserial \
-out hec-server.crt \
-days 365 \
-sha256 \
-extfile hec.ext

Sertifikanın doğrulamasını gerçekleştirdim:

openssl verify -CAfile lab-ca.crt hec-server.crt

Başarılı çıktı:

hec-server.crt: OK

11.3. Sertifikanın Splunk HEC servisine tanımlanması

Sertifika ve private key dosyalarını Splunk’ın kullanabileceği PEM formatında birleştirdim.

cat hec-server.crt hec-server.key lab-ca.crt > hec-server.pem

Ardından HEC sertifika yapılandırmasını ayrı bir Splunk uygulamasında tanımladım.

/opt/splunk/etc/apps/TA_onvo_hec_tls/local/inputs.conf

Yapılandırma:

[http]
enableSSL = 1
serverCert = /opt/splunk/etc/auth/hec/hec-server.pem

Dosya izinlerini düzenledikten sonra btool üzerinden etkin yapılandırmayı doğruladım.

/opt/splunk/bin/splunk btool inputs list http --debug

Splunk restart sonrasında HEC’nin yeni sertifika ile hizmet vermesini sağladım.

11.4. Windows sertifika güveninin yapılandırılması

Oluşturduğum CA sertifikasının public bölümünü Windows bilgisayarıma aktardım.

lab-ca.crt

CA private key dosyasını Windows’a taşımadım.

Ardından güvenilir kök sertifika deposuna ekledim.

Import-Certificate `
-FilePath "C:\platform-tools\lab-ca.crt" `
-CertStoreLocation "Cert:\LocalMachine\Root"

Sertifikanın yüklendiğini doğruladım:

Get-ChildItem Cert:\LocalMachine\Root |
Where-Object {
    $_.Subject -like "*Splunk-Lab-HEC-CA*"
}

Böylece Windows tarafından laboratuvar CA sertifikasının tanınmasını sağladım.

11.5. Sertifika iptal kontrolü problemi

CA sertifikasını Windows’a ekledikten sonra bağlantı sırasında aşağıdaki hata ile karşılaştım:

CRYPT_E_NO_REVOCATION_CHECK

Bu durumun nedeni laboratuvar CA altyapısında sertifika iptal durumunun CRL veya OCSP üzerinden doğrulanamamasıydı.

Laboratuvar testi kapsamında aşağıdaki komutla yalnızca erişilemeyen iptal kontrolü durumlarını tolere ederek bağlantıyı tekrar denedim.

curl.exe -v --ssl-revoke-best-effort `
"https://10.100.201.162:8088/services/collector/health"

Test sonucunda:

HTTP/1.1 200 OK

{"text":"HEC is healthy","code":17}

yanıtını aldım.

Bu şekilde sertifika zinciri doğrulamasını bütünüyle kapatmadan HEC servisine erişebildim.

Bu yöntemin bir laboratuvar istisnası olduğunu belirtmek isterim. Üretim ortamlarında sertifika yaşam döngüsünün ve iptal kontrol mekanizmalarının uygun şekilde yönetilmesi gerekir.

---

12. Android TV Loglarının Splunk’a Gönderilmesi

HEC bağlantısını doğruladıktan sonra Windows üzerinde toplanan gerçek Android sistem loglarını Splunk’a göndermeye başladım.

İlk etapta test amacıyla log dosyasındaki son 10 kaydı seçtim.

$logs = Get-Content "C:\platform-tools\android_tv.log" |
Where-Object { $_ -match '^\d{2}-\d{2}\s' } |
Select-Object -Last 10

Ardından her log satırını Splunk HEC formatına dönüştürdüm.

$events = foreach ($log in $logs) {
    @{
        event = [string]$log
        host = "ONVO-TV"
        source = "adb:logcat"
        sourcetype = "android:logcat"
        index = "android_tv"
    } | ConvertTo-Json -Compress
}

Burada özellikle [string]$log kullanarak PowerShell nesnesine ait PSPath, PSChildName gibi ek alanların event içeriğine dahil edilmesini engelledim.

Daha sonra JSON verisini UTF-8 BOM olmadan dosyaya kaydettim.

[System.IO.File]::WriteAllText(
    "C:\platform-tools\android_events.json",
    ($events -join "`n"),
    (New-Object System.Text.UTF8Encoding($false))
)

Oluşturduğum dosyada 10 adet JSON event kaydı bulunduğunu doğruladım.

(Get-Content C:\platform-tools\android_events.json).Count

Sonuç:

10

12.1. HEC üzerinden gönderim

Hazırladığım veriyi HEC aracılığıyla Splunk’a aktardım.

curl.exe -sS --ssl-revoke-best-effort `
-H "Authorization: Splunk $token" `
-H "Content-Type: application/json" `
--data-binary "@C:\platform-tools\android_events.json" `
"https://10.100.201.162:8088/services/collector/event"

Token değerini komut içerisinde sabit olarak tutmak yerine çalışma anında değişkene aldım.

Splunk HEC başarılı gönderim sonucunda:

{
  "text": "Success",
  "code": 0
}

yanıtını döndürdü.

Splunk Search üzerinden aşağıdaki sorguyu çalıştırarak kayıtları doğruladım.

index=android_tv sourcetype="android:logcat"
| table _time host source _raw

Böylece ONVO Android TV tarafından üretilen gerçek sistem logları Splunk üzerinde görüntülenebilir hale geldi.

---

13. Canlı Log Aktarımının Otomatikleştirilmesi

Manuel log gönderimini başarılı şekilde tamamladıktan sonra bu işlemi sürekli hale getirmek için PowerShell tabanlı basit bir collector geliştirdim.

Collector’ın temel görevi:

1. ADB üzerinden Android TV loglarını okumak.
2. Gelen logları HEC formatına dönüştürmek.
3. Kayıtları belirli gruplar halinde göndermek.
4. HEC yanıtını kontrol etmek.

Collector dosyasını aşağıdaki konumda oluşturdum:

C:\platform-tools\onvo_collector.ps1

13.1. Collector yapılandırması

Script içerisinde ADB bağlantı bilgilerini ve HEC endpoint adresini tanımladım.

$adb = "C:\platform-tools\adb.exe"
$device = "192.168.1.181:33307"
$hec = "https://10.100.201.162:8088/services/collector/event"

$token = Read-Host "HEC Token"

Logları canlı olarak okumak için:

& $adb -s $device logcat -v threadtime -T 1

komutunu kullandım.

Gelen logları JSON formatına dönüştürerek her 10 event’te bir HEC servisine gönderecek bir batch mekanizması hazırladım.

if ($batch.Count -ge 10) {
    # Batch dosyasını oluştur
    # HEC servisine gönder
    # HEC yanıtını doğrula
}

Script’in test sırasında kullandığım sürümünde HEC tarafından başarılı kabul edilen her 10 event için aşağıdaki mesajı ürettim:

10 Android logu Splunk'a gonderildi.

Bu yöntem, her event için ayrı HTTP isteği oluşturmak yerine logları küçük gruplar halinde göndermemi sağladı.

13.2. PowerShell Execution Policy problemi

Collector scriptini ilk çalıştırdığımda Windows üzerinde aşağıdaki hata ile karşılaştım:

running scripts is disabled on this system

Test kapsamında yalnızca mevcut PowerShell oturumu için yürütme politikasını düzenledim.

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Ardından collector’ı başlattım.

cd C:\platform-tools

.\onvo_collector.ps1

Collector çalışmaya başladıktan sonra Android TV’den gelen logları HEC üzerinden sürekli olarak Splunk’a göndermeye başladı.

13.3. Collector’ın mevcut sınırları

Geliştirdiğim ilk collector sürümü laboratuvar testi için hazırlanmıştır.

Bu sürümde aşağıdaki geliştirmelere ihtiyaç bulunmaktadır:

• ADB bağlantısının kesilmesi durumunda otomatik yeniden bağlantı
• VPN veya HEC kesintilerinde kalıcı disk kuyruğu
• Başarısız gönderimlerin kontrollü şekilde yeniden denenmesi
• Batch gönderimlerinde mükerrer kayıtların azaltılması
• Android logunun gerçek olay zamanının kullanılması
• Windows açılışında otomatik başlatma
• Collector sağlık durumunun izlenmesi

Özellikle HEC’nin code=0 yanıtı isteğin kabul edildiğini gösterse de uçtan uca, sıfır kayıplı aktarım garantisi sağlamaz.

Bu nedenle mevcut çalışmayı başarılı bir canlı aktarım PoC’si olarak değerlendirdim.

---

14. Android Loglarının Splunk Üzerinde Parse Edilmesi

Logların Splunk’a ulaşması tek başına yeterli değildi. Merkezi izleme ve analiz gerçekleştirebilmek için logların içerisindeki alanların ayrıştırılması gerekiyordu.

Örneğin:

10-13 10:55:44.323 561 766 E <MI_PQ> : <ERR>_MI_PQ_CalculateSubwinCrop[6050]: invalid input

Bu kayıttan aşağıdaki alanları çıkarmayı hedefledim:

android_date
android_time
pid
tid
log_level
component
message

14.1. Search-time field extraction

Splunk üzerinde özel bir Technology Add-on oluşturdum.

/opt/splunk/etc/apps/TA_onvo_android/local/props.conf

Yapılandırma:

[android:logcat]
EXTRACT-android_logcat = ^\s*(?<android_date>\d{2}-\d{2})\s+(?<android_time>\d{2}:\d{2}:\d{2}\.\d+)\s+(?<pid>\d+)\s+(?<tid>\d+)\s+(?<log_level>[VDIWEFS])\s+(?<component>.*?)\s*:\s*(?<message>.*)$

EVAL-component = if(trim(component)="", "unknown", trim(component))

EVAL-severity = case(log_level="V","Verbose",log_level="D","Debug",log_level="I","Info",log_level="W","Warning",log_level="E","Error",log_level="F","Fatal",log_level="S","Silent")

Bu yapılandırma ile Android loglarını search-time aşamasında ayrıştırdım.

Böylece indekslenmiş mevcut logları yeniden ingest etmeden alan bazlı arama ve analiz gerçekleştirebildim.

14.2. Parsing doğrulaması

Ayrıştırma sonrasında aşağıdaki SPL sorgusunu kullandım:

index=android_tv sourcetype="android:logcat"
| table _time android_date android_time pid tid log_level severity component message

Bu sayede Android TV kayıtlarını ham log formatı yerine ayrı alanlar halinde görüntüledim.

---

15. Android TV Loglarının Analizi

Parsing işlemi sonrasında Splunk Patterns özelliğini kullanarak en sık tekrarlanan log mesajlarını inceledim.

İlk analizde iki log pattern’inin toplam kayıtların önemli bir bölümünü oluşturduğunu gördüm.

Log Pattern	Oran
b2r sel src / vcount	%38,14
MI_PQ – invalid input	%36,19
cqmt – Group name missing	%2,60
CVTE servis logları	%1,24
Diğer kayıtlar	Kalan oran

Bu sonuçlarda özellikle görüntü işleme bileşenleriyle ilişkili kayıtlar dikkat çekiyordu.

15.1. MI_PQ hata analizi

Aşağıdaki hata mesajı sık tekrarlanan kayıtlar arasındaydı:

<MI_PQ> : <ERR>_MI_PQ_CalculateSubwinCrop[6050]: invalid input

Bu kayıt, görüntü işleme bileşeninde geçersiz bir girdiye ilişkin hata mesajı üretildiğini göstermektedir.

Ancak bir logun Error seviyesinde olması doğrudan güvenlik ihlali yaşandığı anlamına gelmemektedir.

Bu nedenle söz konusu kayıtları öncelikle sistem sağlığı ve hata yoğunluğu açısından değerlendirdim.

15.2. Hata üreten bileşenlerin analizi

Aşağıdaki SPL ile hangi bileşenlerin daha fazla hata oluşturduğunu inceledim:

index=android_tv sourcetype="android:logcat"
log_level=E
| stats count by component
| sort - count

Bu sorgu sayesinde hata üreten servisleri sayısal olarak karşılaştırabildim.

---

16. Android TV Security & System Monitoring Dashboard

Log toplama ve parsing işlemlerini tamamladıktan sonra verileri merkezi olarak takip edebilmek amacıyla Splunk üzerinde özel bir dashboard tasarladım.

Dashboard’un amacı yalnızca toplam log sayısını göstermek değil, Android TV’nin sistem davranışını ve hata yoğunluğunu analiz edilebilir hale getirmekti.

Dashboard içerisinde aşağıdaki metrikleri ele aldım:

Dashboard Paneli	Açıklama
Total Events	Toplam log sayısı
Error Events	Hata seviyesindeki kayıtlar
Warning Events	Uyarı kayıtları
Fatal Events	Kritik hata kayıtları
Event Volume Over Time	Zaman bazlı log yoğunluğu
Severity Distribution	Log seviyesi dağılımı
Top Components	En fazla log üreten bileşenler
Top Error Messages	En sık tekrarlanan hata mesajları
MI_PQ Analysis	Görüntü işleme hatalarının takibi
Parsing Coverage	Ayrıştırma başarısı
Log Ingestion Health	Log aktarımının son görülme zamanı

Dashboard sayesinde belirli bir bileşenin normalden fazla hata üretip üretmediğini ve log akışında değişiklik olup olmadığını inceleyebilecek bir temel oluşturdum.

---

17. Çalışmanın Güvenlik Açısından Değerlendirilmesi

Bu çalışma, geleneksel sunucu ve istemci sistemlerinin dışında kalan Android tabanlı IoT cihazlarından da merkezi log toplanabileceğini göstermektedir.

Splunk üzerinde oluşturulan yapı sayesinde Android TV tarafından üretilen erişilebilir sistem logları analiz edilebilmektedir.

Bu veriler aracılığıyla:

• Sistem hata ve uyarılarının takip edilmesi
• Uygulama ve servis hatalarının incelenmesi
• Anormal log yoğunluğunun araştırılması
• Belirli bileşenlerde tekrarlayan hataların tespit edilmesi
• Log akışının kesintiye uğrayıp uğramadığının izlenmesi

gibi analizler gerçekleştirilebilir.

Bununla birlikte Android logcat kayıtları cihazdaki bütün güvenlik aktivitelerini veya ağ trafiğini eksiksiz temsil etmez.

Örneğin televizyonun hangi IP adresleriyle bağlantı kurduğu, DNS sorguları veya bütün ağ paketlerinin içeriği için router, firewall, DNS sunucusu veya ağ trafiği izleme araçlarından ek veri toplanması gerekebilir.

Ayrıca ADB erişiminin yalnızca yetkili cihazlar üzerinden ve güvenilir ağlarda kullanılmasına dikkat edilmelidir.

---

18. Sonuç

Bu laboratuvar çalışmasında evimde bulunan ONVO Android TV cihazının sistem loglarını, televizyon üzerine herhangi bir Splunk Universal Forwarder kurmadan merkezi bir Splunk Enterprise ortamına aktarmayı başardım.

Çalışma kapsamında Android Debug Bridge üzerinden log toplama, Windows PowerShell ile veri işleme, VPN üzerinden HEC aktarımı, SSL/TLS sertifika yapılandırması, field extraction ve dashboard oluşturma aşamalarını ele aldım.

Özellikle HEC veri formatı ve TLS sertifika güveni sırasında karşılaştığım problemler, log toplama süreçlerinde yalnızca ağ erişiminin değil, veri formatının ve güvenli iletişimin de doğru yapılandırılması gerektiğini gösterdi.

Sonuç olarak Android tabanlı akıllı televizyonlardan erişilebilir sistem loglarının Splunk üzerinde merkezi olarak toplanması ve analiz edilmesi mümkündür.

Bu çalışma, daha kapsamlı bir IoT Security Monitoring mimarisinin başlangıcı olarak değerlendirilebilir.

İlerleyen aşamalarda Android TV’nin DNS ve ağ bağlantısı kayıtlarını da Splunk’a dahil ederek sistem logları ile ağ davranışlarını birlikte analiz etmeyi hedefliyorum.

Böylece yalnızca cihaz üzerinde oluşan hataların değil, cihazın ağ üzerindeki iletişim davranışlarının da merkezi olarak izlenebildiği daha kapsamlı bir yapı oluşturulabilir.